In case that the input has 1 channel and 8 kHz, the packet type was not
set to 14, because the first if branch was entered instead of else-if
(not setting anything).
Fixed the condition that applied only if fixed PT was used for the
audio. But dynamic packet type is used when more channels are used,
in which case the condition didn't hold, which caused the stream not
being handled appropriately (interleaving the channels).
replace "H264 standard" with "RTP standard (using RTSP)" - the "standard"
protocol (on the sender) is no longer restricted to H264 - JPEG is also
possible as well as couple of audio codecs.
Do not deduce audio properties from command-line parameters but from
the actual format that is being to sent.
Until now, the properties like ch_count and sample rate was deduced from
command-line parameters (ch_count from `-a channels=` and sample rate from
`-A xxx:sample_rate`). However, this is a bit fragile - the source may not
respect the `-a` parameters and also the `-A sample_rate` doesn't need
to be set, like in the following case:
```
uv -x rtsp -A A-law -a sample_r=8000 -s testcard
```
Here the capture sample_rate is set to 8000 but not parsed from parameters
(it must have been in `-A`). So SDP parameeters for RTSP was set
incorrectly (48000).
The audio state is always present (even if no audio rx/tx is used),
so set this always.
This will allow setting the data also for tx (the vrxtx) - the check if
either audio tx or rx is unnecessary (as indicated above).
renamed to rtsp_type_audio and rtsp_type_video
Although not causing probles by now, the name itself (which is as a
part of unscoped struct global) is very common so it could have caused
conflicts in future.
print the SDP without need for connected client
Previously, the generated SDP was printed just as a client connects
because the sdpLines() member is called just after that (with appropriate
IP version).
If video is not used, run the RTSP server immediately. This fixes the
commit 75f86ba6 (from 2024-08-01) that changed the behavior (delays RTSP
server start until video format is known).
Generate rtpmap lines even for formats with statically assigned PT -
bluenviron/mediamtx does it as well and it is nicer, although not
necessary.
RFC 3555
Although RFC 2435 supports YUV 422, it has to have sampling factors
h: 2,1,1 v: 1,1,1
FFmpeg built-in JPEG encoder generates h: 2,1,1 v: 2,2,2 and
it cannot changed (set by function ff_mjpeg_init_hvsample() in
libavcodec/mjpegenc_common.c).
STR_LENGTH was very similar name to STR_LEN, even set to the same value
so replace its ocuurences simply by STR_LEN.
This also allows putting it to headers because the constant is public.
We pass the video_codec as RTSP parameters but until we receive first frame
we cannot know the actual codec, so that delay the creation until we receive
the first frame.
