Interlacing is not honored by libx265, anyways, and this saves the
eventual HWacc warning.
It is still passed to QSV even for HEVC, anyways. Not sure how the API
handles that but FFmpeg seems to pass it.
\+ remove "and not 4:2:0" from subs complaint - it is perhaps needlessly
verbose (other feature doesn't name the correct value. user should be
aware, anyways, and there is also a hint below.
Set AVHWFramesContext::sw_format to first of av_hwframe_transfer_get_formats().
This is consistent how MPV does that. Fixes NV12 being transmitted
despite AVHWFramesContext::sw_format was set to yuv420p causing chroma
channels corruption (because the nv12 data was misinterpreted as the
latter one) occuring on AMD cards, steps to reproduce:
```
uv -t testcard -c lavc:enc=libx264:safe -d gl --param use-hw-accel=vaapi
```
See also:
<66e30e7f2f>
Warn in the same way as when non-4:2:0 video is encoded - intra refresh
might be problematic as well.
Do not warn if enabled explicitly (`:intra_refresh`).
Enable the inserter automatically - the h264_omx is not producing SPS/PPS
periodically with plain RPi OS FFmpeg (FFmpeg needs to be patched).
The OMX API seems to getting deprecated, anyways.
Write uncompressed output only if user explicitly specifies NUT container
to avoid unexpected results when `-d file` is writing overwhelming amount
of data.
\+ ignore leading AUD NALU if present (add own 4B start code instead) -
it could have produced problems when AUD+SPS+PPS is prepended to regular
frame that is not an IDR frame
The option solves a problem with streams that do not correctly prepend
video headers, namely (and currently only implemented) SPS/PPS in
H.264 stream. Support for HEVC can be added later.
Actually all options can be passed as a c-string with av_opt_set(),
which then converts it to a correct type. So use to_string to convert
non-cstrings to std::string.
some codecs have alread default value in the description, eg. profile
- _Set the profile (default main)_, thus it is unneeded to print the
information second times.
\+ do not print float default vals with "F" suffix because it can be a
little bit misleading, indicate the type in braces instead
Modified the API in order to fetch additional frames from compression
with iterative passing NULL pointer (similarly as for audio).
This is particularly usefull when inter-frame compression outputs 2
frames at once, which can occur when B-frames would be enabled. It,
however sometimes happen even when B-frames are disbled, eg. with
h264/hevc_mf HW encoder on AMD (AMDh265Encoder; see commit d70e2fb3c).
Please note that semantic of passing NUL frame is different in this API
to that in async API, where it works as a poison pill.
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).
