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.
we can accept all codecs, not only BGR or YUYV/YUY2
Note that the codec is used as both streaming and grabber codecs,
the converting logic doesn't seem to have been working in the past,
although Pavel Troubil's original code had RGB fixed as the codec.
Commented out the block setting the mediaformat - now the matching format
is already set, unsure about semantic of this block.
Respect RGB for key/value syntax as indicated in help.
This can be particularly useful when capturing eg. MJPEG, which we want
to recompress or process later.
OpenCV in Buster (Linux armhf build) doesn't have
INTER_LINEAR_EXACT. Similarly to INTER_NEAREST_EXACT, this doesn't seem
to be necessary so enable it for now (althoug compat macros should be
possible as well).
