- 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)
null string pointer was passed for look_ahead instead of zero
Removed the option altogether since it is 1. not supported for hevc_qsv
and 2. default for h264_qsv in FFmpeg since 2018-03-01 (commit 0645698).
see failed run https://github.com/CESNET/UltraGrid/actions/runs/3657908562
See also 438dbfa4 - `aptitude build-dep` for whatever reason fails on GH
CI ON installation of debhelper-compat(=12), which is a virtual package
provided by debhelper, apt doesn't.
log:
+ sudo aptitude -y build-dep libsdl2-mixer libsdl2-ttf libsdl2-dev:
[...]
Building tag database...
Unable to apply some actions, aborting
Unable to satisfy the build-depends: Build-Depends: debhelper-compat (= 12)
bpp represented rather the container size, so both for RGBA and R10k it
was 32 b (and eg. for v210 21.33 instead of actual 20). bpc (bit depth
per component) seems to be more comprehensible value.
Added option "size" instead of separate "widht"/"height". Both
dimensions need to be entered, anyway, so it is not needed to type more
characters than necessary.
Width/height param is parsing is left for compatibility (for now).
Note that only copy mode is supported right now - meaning that decoded
frames are copied from the GPU to the system memory. For simpler codecs
like H.264 this could actually be slower than sw. decoding. VDPAU is
probably still a better choice for codecs supported by it.
Right now ffmpeg prioritizes vdpau, so this will get selected only when
vdpau is unavailable or fails to initialize.
