The fix commit 8c19440a (2025-10-01) locked in flush_capture_data(),
which was ok when called from rewind_file(). But that function is
called also from vidcap_file_process_message() which is called with
mutex already held (CID 896223).
So moving the lock from flush_captured_data() up to rewind_file().
Also CID 896221 is fixed - subsequent s->new_msg was called seemingly
without lock (double lock + 1x unlock considered unlocked). Now in this
context one pair lock/unlock was removed which means that the lock is
still held.
fixes CID 896221, CID 896223, commit 8c19440a
Since the commit 443fe59d (2023-04-11), the sole CS change was not
handled.
There can be 2 cases:
1. bit-depth change (without color-space), which was not handled
2. CS changed was even more harmful because no signal was detected then
The above cases should be handled. The bit-depth handle should be
ignored just if codec= is explicitly specified, in which case the depth
is taken from the argument (specified codec CS is not honored - YUV must
be captured as YUV, RGB similarly).
The [file] (URL few commits below) has actually set r_frame_rate as
1/1200k, which causes the libavcodec JPEG decoder crash (received is
something like 1792i due to overflow). avg_frame_rate contains 1/25.
Prior to the commit 9891f19a (HEAD~3) avio_seek was called prior to
avformat_seek_file. This worked fine for normal containers (eg. MP4). But
after this was swapped, avio_seek after that broke that.
In order to work properly, run avio_seek() just if avformat_seek_file
fails (fixes temporarily broken .mp4 loop). Only case remaining is
JPEG/MJPEG file loop, which returns 0 for the avformat_seek_file() call.
This is handled ad hoc (I don't have any better solution now).
Rewinding the file (:loop option) doesn't work using raw HEVC like with
the [file].
avformat_seek_file retrurns EPERM, which was handled as an error, so
stopped the worker.
avio_seek seems to do the job but must be performed _after_ (unsuccessful)
avformat_seek_file.
[file]:
https://ultravideo.fi/video/ReadySetGo_3840x2160_120fps_420_8bit_HEVC_RAW.hevc
not sure why `if [ test $4 ... ]` worked... (excess [], which are possibly
consumed/erased by m4)
- check that $4 is set and avoid splitting on spaces (should not happen)
- use -eq instaead of = (should be 0 or 1)
Not tested but trivially, libgdk-3.so.0 from (build) Ubuntu 22.04
should not be incompatible when running on the same distro.
This is not known to cause issues but better to remove this since it
the original use case seem no longer being valid. Track just the
excludelist from AppImage creator.
commented out libgdk_pixbuf-2.0.so.0
Normal build no longer runs on Rocky Linux 9 but alternative build (built
on centos 7) does. But conversly excluding the files causes dependency
problems for vcap/file vcomp/lavc, vdisp.file, vdisp/gl. Tested on Alma
9.6, which shuld be basically the same as Rocky. After re-adding the
problem disappears.
Doesn't seem to be required and nwo (since the new PPA use) causes following error:
```
ultragrid_vidcap_rtsp.so: /lib/x86_64-linux-gnu/libgnutls.so.30: undefined symbol: nettle_siv_gcm_aes256_decrypt_message, version NETTLE_8
``
(obviously) when libgnutls30 is not installed, eg. in Ubuntu 24.04.
fixes the commit 69024468 (from 2022-08-18) that has broken:
`uv -F split:2:1 -t testcard:fps=30p -c lavc`
The problem is that the `tile_cnt` was set _prior_ to the vcompress
state reconfigure, which will yield 2 states. But prior that, the count
was 1. The task was started for tile_cnt (== 1) but waited upon for
separate_tiles.size() (== 2)!
Since the pulsation issue, it was not much usable, anyways and this
clean-ups the code a bit.
Also the behavior will be now more deterministic - it behaved differently
with patched FFmpeg (most likely GH Linux builds), othewrise differntly.
+ enable the header-inserter if user expliclty requesetd intra-refresh
refers to GH-114
assume that FFmpeg is already patched with SVT-VP9 patch
As a side effect, the SVT-VP9 patch doesn't need to be patched (these
patches conflicted because VP9 applied after HEVC, which is now not
the case).
The patch no longer compiles with upstream FFmpeg (moreover the history
of 5000 commits is now too shallow.
Use a updated custom version now - the SVT-HEVC is archived, anyways so
the upstream won't be updated.
This reverts commit a30a8945e3.
This doesn't seem to be required anymore (at least xv30 and yuvx work
with Arc A770 and Raptor Lake-P GPU on i7-1355U).
As the patches need to be applied against specific version of FFmpeg
(pinned in db308b17 2023-02-03). Currently the version is from 23th Dec
2024, which is slightly old. That is a half of the year but we also
depend on the cartwheel version bump, which is a bit unfortunate, whereas
is now not cerain, if there is something needed.
Set the metadata for parallel conversion later - av_frame_make_writable()
may actually alter that (at least pointer but perhaps also linesize), those
old values might have been invalidated by that lavc call.
fix the situation when most recent release doesn't include the asset
matching the patern (but some other does)
notes:
- the assets are included directly in /releases, no need for subsequent fetch
- use -e to fail jq if the result is null
- $pattern doesn't need to be anchored
Fix decoding of HEVC streams with intra-refresh and current Git FFmpeg
code. When intra-refresh is enabled and we are not catching the first
frame, no frame will be decoded without the flag
AV_CODEC_FLAG_OUTPUT_CORRUPT. This corresponds with FFmpeg commit
bc1a3bfd (2025-02-20), not yet included in current 7.1.1 / lavc 61,
should appear in lavc 62.
Steps to reproduce:
```
uv -t testcard -c lavc:e=libx265 -d gl
```
fixed log_level shadowing
The vulkan_sdl mapped log_level shadows the global log_level variable,
so that automatic variable log_level is compared to itself (always true).
Fixes the UG crashes caused by the multiplication of
"@executable_path/../libs/" caused by replacing multiple (originally
distinct) LC_RPATH values with this one.
+ removed invalid comment from Makefile (actually was related to
"bundle-nolib" target that is no longer present)
closes GH-436
The development in PCP seem to be very turbulent these days and it breaks
Win builds often so pin a commit in Windows CI until the situation calms
down a bit.
