Added additional number validitiy check (to newly created parse_number
function). Mainly to cover inputs like '1something' where it should
not be parsed correctly as being 1.
Do not use positional references to printf format string, which is a
POSIX extension and not supported by Windows C library.
+ write the optarg string (in case that is only partionally parsed -
atoi stopped at first non-number)
refers to GH-437
The commit b785c3d8 from 2024-08-05 changed the default unconditionally
to PCM, but this has been true just for UltraGrid RTP, not RTSP or SDP
that used MP3, so this change reverts it back.
If the input is already compressed, try to pass it further. Initialize
the compression just if receiving uncompressed data.
This is implemented in the same way as it already is in vrxtx/sdp.
refers to GH-433
select the color automatically (lime for +- 2-5%, brown for >5% diff)
This simplifies the code by sharing the logic in common; also exceeding
FPS is now colored (until this just lower than nominal was colored).
The actual value (5,2,1)/5 didn't match peach fuzz (255,190,152)/255
but the rather closest color is Tomato (255,99,71)/255.
The T_DARKER_ORANGE is poorly defined but its value (3,1,0)/5 matches
approximately the X11 color Saddle Brown (139,69,19)/255.
This is a hack to check whether given invalid_argument message belongs
to stoi/stod. It is usually used to catch non-numeric user input where
a number was expected.
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.
