- use snprintf instead of strncat (better behavior - always appends \0 and
no need to subtract 1 from len /and expecting that there is \0 at the end)
- use actual string length with sizeof than STR_LEN (which may get
removed because it is misleading in respect to global STR_LENi value)
Send only one channel in RFC-compliant mode even if there are more,
just print an error.
The point is that even though the default audio capture channel count
is 1, some devices may not support mono (eg. DeckLink) and produce more
channels (usually 2) anyways.
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.
added a limit to number of frames/seconds that can be cached
The user may enter some huge value by mistake and since FHD UYVY frame
takes 4M, it can exhaust the memory quite quickly. So the limit is set
to 2000 frames or 60 sec, which is in the case of 30p video up to 8 GB
of memory.
\+ print the user selection to console
As there is no line decoder for I420, because it is a planar format,
added regular decompress to be able to display simple uncompressed I420
as in the this command: `uv -t testcard:c=I420 -d gl`
Fixes the commit b62566ca72 (2th Oct 2023), which caused that lavd was
always selected as the decoder, even though not designated. Eg.:
```
$ uv -t testcard:codec=I420 -d gl
Decompressor "libavcodec" initialized successfully.
[lavd] Unsupported codec!!!
```
The problem was that on probe ugc==VC_NONE and HW acceleration is not
set, thus hw_accel_to_ug_pixfmt(0) return also VC_NONE, in which case
the decoder is unconditionally selected for all formats.
Although there is cmd/PS in process tree, it may be used just like shell
(eg. when run over SSH) so that the terminal may be eg. some Linux
terminal emulator.
In W11, there is a cycle between processes services.exe and wininit.exe:
```
[utils/win] have_ancestor: services.exe PID: 788, PPID: 892
[utils/win] have_ancestor: wininit.exe PID: 892, PPID: 788
```
which caused infinite cycle between these 2 processes.
Those terminal emulators block stdout/stderr output when scrolled,
which effectively stops UltraGrid. The behavior doesn't occur in MS
Terminal app, which is encouraged instead.
Note that Windows Terminal still runs cmd.exe or powershell.exe as a shell
while the cmd/PS process can acts like both terminal emulator and
shell. We also do not trigger the warning if UG is run from within
MSYS2 terminal.
This fixes all occurences of `cmake --build` as it already was in one
case with commit HEAD~7.
If omitted, CMake leaves the number of processes used on underlying
implementation, which turns out to `make -j`, thus unlimited number of
cores, which is undesirable.
use same syntax for all HANDLE_ERR definitions
\+ pass the function name in the definition (might be __func__ directly
in HANDLE_ERR_ACTION in future)
\+ do not use 'do {} while(0)' pattern as it consumes `continue`, use
if-else instead
Using `cmake --build . --parallel` actually doesn't limit the number
of processes because it just passes the number (here none) to make,
resulting in `make -j`.
This is a possible explanations of macOS runner freezes, as eg. here:
<https://github.com/MartinPulec/UltraGrid/actions/runs/7641831068>
(last relevant message in log is `[100%] Built target joysticks`).
added resolve_fourcc to utils/string
- fixed wrong signal.h include guard (it should be definitely included
in mac, it was perhaps meant to be MSW, but it is needed there too)
- removed config*h
It seems like the first DWORD of subtype GUID
(mediaType->subtype.Data1[0-3]) doesn't always contain FourCC, namely for RGB types, eg.
MEDIASUBTYPE_RG24 (the others seem to be be mostly OK).
Instead of getting full format from vidcap_dshow_get_video_desc(), which
translates the source pixel format to UG one, use the FourCC directly. Do
write just the format, the same for grabber and then the complete output
format (after eventual UG conversion). Except of the format, every other
parameters should be currently the same.
The previous approuach didn't work when there was either no VFW->UG
mapping (I420 etc.) or there was not 1:1 mapping, eg. NV12 was displayed
as UYVY because the conversion is such, which might be misleading.
