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.
- use custom IPv6 black hole address 100::556C:7472:4772:6453 instead
of 100::1, which a user may use explicitly to signalize server mode
- check just the one address, not the black hole prefix in general
(again, the user may select the discard address intentinally without
knowing our semantics)
- removed the black hole handling functions (no longer needed)
- compute the actual in6_addr from the string with inet_pton instead of
hard coding the value
Those doesn't need to be signalized in any way (PT is defined), so that
the receiver can play the streams directly without SDP - eg. `ffplay
rtp://[::1]:5004` (and similarly on port 5006).
MP3 (just added std TX) is set as default for RTSP as well - perhaps
not a big difference if MP3 or Opus so we do not need to handle two
cases. Also MP3 could be more compatible.
The condition was written incorrectly, because it disallows only
combination of video-attached and standalone audio drivers but allowed
2 audio standalone drivers, which is unsupported as well.
For uninit, screen-capture-recorder-x86.dll calls CoInitialize(0) and
fails because it fails.
Curiously this doesn't occur for register, which should be equivalent.
SIGPIPE signals may be delivered externally if user uses a named pipe
eg. as file capture input or file display output. We want to exit
gracefully in this case.
modernized video display, audio playback and vo postprocess APIs
THe APIs were already recently updated so modernize it by using bool
where the return value is semantically boolean value. Using TRUE/FALSE is
inherently ambiguous because it is not obvious from the prototype if
success is 0 or TRUE (1).
Semantics of '-A' parameters has changed from audio receiver address
(distinct than video) to audio codec. It is, however, doubful if someone
uses it, but just in case.
This compat message could (and should) be deleted later.
'A' seems to be better but it was originally used by --audio-host. This
argument isn't supposed to be important and isn't perhaps used, anyways,
so use this and for the --audio-host keep only the long opt.
`-s` parameter now sets audio only to following video capture, just like
`-F` (capture filter) does.
This allows different setting for different audio connectors for
different video sources, namely for switcher, eg.:
uv -t switcher -s analog -t decklink:device=1 -s embedded -t \
decklink:device=2
refer to GH-318
