timestamp wraparound was not properly handled
Until 3480fc647 (2023-06-28) this occured just after 13 hrs (2^32 overflow
with 90 kHz clock) because the timestamp initial random offset was taken
from uninitilaized random generator. Since this change, this can can
occur randomly every those 13 hrs.
- avoid computing line len from (line_start - pos), because this gives
raw line length, but we want net (without esc seqences)
- unconditional line wrap - moved after normal processing. The reason is
to wrap something linke "word <other_100_char_word>" between the 2
words
- when line was wrapped, the vars were incorrectly set, namely in the
else-branch, `pos` should have been `last_space + 1` not `next + 1`
("b <very_long_word> c" evaluated after the long word)
fixes CID 415859
mkappimage now tries to automatically upload the asset if it detects
running in GitHub CI, which is not the behavior we perhaps want because
it deletes and recreates our _continuous_ release.
See following failed run:
https://github.com/CESNET/UltraGrid/actions/runs/5575039257/jobs/10185765784
+ fixed `wget` presence check in `create-appimage.sh`
Since the FFmpeg commit 7eeef72c6, the IDR period is set to gopLength
unconditinally even for intra-refresh mode, which is what the removed
patch did.
+ do not check if FFmpeg is patched (the macro is )
libavcodec audio decoder has assertion on channel non-emptiness (which
is perhpas correct - there cannot be anything done there) so do not pass
emtpy channels.
refer to GH-316
if no configuration is set, empty string ("") is passed, not NULL
This resulted in wrong device set 0 set because the atoi doesn't check
its arguments. Example of fixed behavior:
uv -s testcard -r coreaudio
`AudioUnitSetProperty(s->auHALComponentInstance, kAudioOutputUnitProperty_CurrentDevice,
kAudioUnitScope_Global, 1, &device, sizeof(device));` succeeded with 0
for some reason (but not with other values).
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.)
