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.
If the compression cannot make it, print a hint that would perhaps
increase a latence and thus is not enabled by default.
As as consequence of that, set NVENC delay to 0 again to be consistent
with the other compressions (latency preferred).
The bug is induced by upstream FFmpeg changes, in particular:
28680e2f41
Supposedly "disabled" is the only supported b_ref_mode for Pascal cards
and it fails if not set (set otherwise). We don't use B-frames at all so
it can be disabled by default, anyways.
closes GH-273
If earlier codec is convertible, use this. In other words, prefer first
codecs, not those most easily convertible.
The point is, that the list passed to get_format lavd callback is
usually ordered from best codecs so we want to keep it.
It also fixes a "regression" from 4c5cf6f2 (given by the different
selection schemes in original and the replacement):
uv -t testcard:codec=R12L -c libavcodec:encoder=libsvt_hevc -d dummy \
--param force-lavd-decoder=libde265 -V
decoding YUYV, not v210 (from AVPixelFomat AV_PIX_FMT_YUV444P10LE)
Fixed incorrectly selected UYVY with following command:
uv -t testcard:codec=R12L -c libavcodec:encoder=hevc_nvenc --param force-lavd-decoder=hevc_cuvid -d dummy -V
There were 2 problems:
1. probed codec should be returned after first successful decoded frame
because in the above case, the decoder offers nv12 via get_frame
callback first and it changes later to yuv444p16le if decoding
continues and succeeds (see also 2.)
2. get_format_callback() returned VIDEO_CODDC_NONE on probe but that
caused subsequent initialization of 'hevc' decoder (because lavd
thought that it failed). Because of that, the probe couldn't have
proceeded.
After the changes, the probed format is R10k (correct for now -
get_best_ug_codec_to_av({AV_PIX_FMT_YUV444P16, 0}, 0) returns R10k).
