In case that the encoder buffers frame for whatever reason (NVENC
with delay, hevc_mf sometimes batching 2 frames /returned frames count
0,1,2,0,1,2.../) so that output frame doesn't match the currently
enqueued onei, metadata would be incorrect (currently enqueued copied
to non-matching dequeued one).
removed explicit preset handling
Actually with current encoder set, having the preset is rather exceptional
- some codecs to not recognize the presets with any encoder, eg. MJPEG,
Other have a different keyword like "usage" (VP9). Even with eg. H.265
different encoders use different keywords ("scenario" for QSV and MF) etc.
So give up explicit handling of presets - those (or those under different
names) can be configure in codec specific configure callbacks.
There is also a change that the default preset is always set, previously
not if _preset_ was detected in cmdline params. This doesn't seem to be
a problem, however. The user-specified options are set after the
codec-specific configure callback so that it should override the default.
set default values
Seting hw_encoding=1 (force) - otherwise, the API seems to be using SW
encode. Moreover, using _hevc_mf_ fails to init (at least in some setups)
while the GPU supports that so that enforcing that makes it work.
When trying to init _any_ codec (for the further use with swscale), do not
try already tried pixfmts. Plus do not print that we will try with swscale
when there is no AV pixfmt left (it is a bit misleading in the UG output).
Since 2022-06-18 (commit cbc548d3), dynamic rate limiter allows
overshooting one frame by the factor of 50% so we can safely set the
default factor to 1.5 now.
see also GH-114
This reverts commit e457ab87f7 but the
patch is updated to match current FFmpeg.
The FFmpeg commit that seemed to do the same (7eeef72c6) is not working
correctly because it assigns idrPeriod cc->gopLength, which was set to
NVENC_INFINITE_GOPLENGTH above in case of intra-refresh.
refer to GH-330
Current libavcodec version is still 60.22.100 so intra-refresh has been
disabled since e457ab8 because the version is still not strictly greater
(is equal). Using non-strict equality breaks the compilation with version
60.22.100 prior to FFmpeg commit e457ab8 (perhaps not a big deal).
refer to GH-330
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 )
Compared to codec options set by UltraGrid impliclty, if user-set option
fails, it is taken as an error. But the log message didn't indicate that
the option setting was actually fatal, so use error verbosity which
makes it more visual apparent.
While on x86_64 is libsvtav1 still slightly ahead, on the M1 mac, the
AOM AV1 performs significantly better (2x faster).
The above holds for native builds, it actually looks like the x86_64
build running SVT AV1 on M1 mac doesn't run correctly at all - it
produces just blank picture (green as is zeroed YCbCr buffer).
+ do not allocate it ahead in _init
For HuffYUV and FFV1 this caused crash (perhaps deconfigure was run twice
for those codecs with extradata /it uses a different path than usual
codecs without that data/, leaving the AVpacket pointer nullptr after
first run).
Unreferencing should not be necessary - we are not refcounting it and
FFmpeg example (decode_video.c), which works similarly, doesn't do that,
anyways. Also av_packet_free() should unreference it according to doc.
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
Set to DEFAULT_CQP (21) instead of DEFAULT_CQP_QSV (5000). The usable
range here seem to be in tens, not thousands as for the other constant
so set it accordingly the detail to work satisfactorily when the quality
(cqp) parameter is not given explicitly.
AV_CODEC_FLAG_QSCALE is used to signalize that fixed qscale should be
used and some codecs like QSV ones require it to signalize that CQP is
used.
refer to GH-298
mjpeg encoders (FFmpeg embedded and QuickSync) don't respond to bitrate
setting, so set cqp by default. This gives user a guidance (via the log
msg, that cqp param may be set).
Setting the constant quality is quite per-codec specific so do not
provide 2 distinct options with similar semantic that are mutually
incompatible.
Instead, try to interpret the cqp parameter and set codecs' properties
individually.
Since the conversion policy is now "dsc" (depth-subs-cs) by default,
it may trigger more costly conversions so print a hint to enforce the
old behavior if not managing to keep the decode window and pixfmt change
takes at least 1/4 of overal de/compress time.
