When compressing very small video (16x16) with libx265, first frame is
2690 B, which is more than W*H*4 (1024) leading to a crash on assert.
steps to reproduce the fixed problem:
uv -t testcard:size=16x16 -c libavcodec:encoder=libx265
Previously, actually the same version was used but downloaded directly
and installed with dpkg, because it has been used a version from U20
(now default) to U18.
Don't use bundled Wayland libraries when running on Wayland but use it
otherwise to satisfy possibly unsatisfied dependencies.
See also previous commit - Wayland libraries seem not to be portable and
prevent SDL2 native run on Wayland. After this change, SDL2 runs on
U22.04 in Weston (without Xwayland).
SDL2 now obviously works on U20.04, because we are building there. It
doesn't work on U22.04, but neither the build with SDL 2.0.20 nor 2.26.2
does.
The problem seems actually to be the inclusion of Wayland libraries in
AppImage.
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.
