do not crash after `uv --video-protocol rtsp:help` call
Note: other video_rxtx modules handle help differently, eg. h264_sdp
throws 0 from constructor instead of returning nullptr from ::create.
Maximal number of channels was chosen instead of
DEFAULT_AUDIO_CAPTURE_CHANNELS. This was noticable especially for
Pulseaudio plugin, which has 64 channels.
fixes commit 89747981
Used msys/curl instead of clang64/mingw-w64-clang-x86_64-curl for the
upload.
For whatever reason, the other curl variant ceased to collaborate with
GitHub, see failed run (and subsequent ones):
https://github.com/CESNET/UltraGrid/actions/runs/4223917061/jobs/7334218587
I didn't manage to reproduce it on a local Windows machine so there is
perhaps some hidden factor present.
This change is just a workaround and should be removed when not needed.
The handling of source::sr is MT-Unsafe when the library is used from
within 2 threads. Typically when running `uv -t testcard -d dummy` (with
-DDEBUG), check_database() is run from sender thread while process_rtcp_sr
from receiver thread leading to a crash on line 589 using the old
structure data that has been freed and overwritten by some new data.
The above mentioned crash doesn't usually occur since check_database()
is run only if DEBUG is defined. However, in theory it may happen that
both threads accidentaly run process_rtcp_sr() (alhough not observed). In
that case either double-free or a leak could occur if the runs of
process_rtcp_sr() is interleaved in a wrong way. Unfortunately, as the
RTP library is originally mt-unsafe, there can be plenty of similar
undiscovered problems.
(Note: to test the check_database() crash, running in GDB seems to
increase the likelihood that it crashes. This change on the other hand
seems to retuce that, but clearly doesn't eliminate that because the
content of the struct is read while it may be freed by the other thread.)
Three digit subsampling is obsolete, now the format 'JabA' is used (so
4220 instead of 422), so represent it internally in that way in order to
the comparison work.
With the change in f67aa7c, the input buffer pointers should not be
simpley unset by av_freep because then final av_free_frame would crash
on double-free when AVFrame::data were freed by av_freep (which is
basically a wrapper over free()). The buffers AVFrame::buf still remain
allocated and the destructor would free them on the second time.
- fixed filters that multiply output images than receive, like
double_framerate
- refuse filter chain (longer than 1) from complex filter - it doesn't
currently work
In Windows, uv.exe is directly in top-level directory, not in "bin"
subdirectory. Thus, cut "bin" suffix only if there is any.
This fixes Vulkan shaders not being found - eg. "C:\UltraGrid\uv.exe"
resulted in shaders being searched in "C:\shaders"
(UltraGrid/../shaders).
Printout by video decoder might have been incorrect if there is a
postprocessor that changes properties, eg.:
uv -t testcard:fps=50i -d gl -p double_framerate
printed 50i but display was actually set to 50p.
- fixed taking codec from input frame (that may be NULL)
- set drop policy only if option nodelay is used - after the previous
changes, the second frame is correctly output and the filter delays
it output automatically (until "nodelay" is used)
