MJPEG does produce wrong JPEGs[^1] if either slices or threads == 1 and
the other not (until now also the implicit case, because the values
are auto-adjusted).
So if either is 1, auto-set the other value to 1 as well. If both are
set and either is 1 and the other not, issue at least a warning.
[^1]: for the s=1 && t>1, FFmpeg own decoder is capable to decode,
but the bitstream is definitely wrong - instead of RST markers there
are EOI markers.
If both encoder and decoder of the same name is present, eg. jpeg2000,
print help for both encoder and decoder. Since for the decoder, options
are also printed with enc=<enc>:help, print both enc and dec at the
same time.
In case that set_param callback modifies some field use a copy to be
reentrant for next attempted pixfmt (or reconfiguration).
The other alternative would be to set the pointer to setparam struct
const, but some setters currenty really modify the params.
User may be tempted to set the bitrate although CRF is now default,
so unset pred-struct (because it won't work with current
ffmpeg/libxsvtav1).
But issue a (serious) warning in this case.
This reverts commit fa8bb8ca8e.
Actually this worsened the behavior significantly by increasing the
latency in the order of 100 frames (depending on properties). This
(currently) disallows setting the bitrate, using CRF/CQP is only possible
because the FFmpeg plugin isn't able to set CBR for now.
set_forced_idr function was unnecessary - the error handling can now
do chec_av_opt_set(). Moreover it prints out the setting to std output
even when succeeded.
set fast-decode as suggested by SVT AV1:
```
Svt[warn]: If you are using tiles with the intent of increasing the
decoder speed, please also consider using --fast-decode 1, especially if
the intended decoder is running with limited multi-threading capabilities.
````
currently it causes following error:
```
Svt[error]: VBR Rate control is currently not supported for SVT_AV1_PRED_LOW_DELAY_B, use CBR mode
```
Setting the CBR mode is currently not possible with current FFmpeg patch
- only possibility is to set rc_max_rate=bit_rate ([1] but this triggers
another error:
```
Svt[error]: Instance 1: Max Bitrate only supported with CRF mode
Svt[error]: CBR Rate control is currently not supported for SVT_AV1_PRED_RANDOM_ACCESS, use VBR mode
```
It is also not clear if the pred-struct set to SVT_AV1_PRED_LOW_DELAY_B
has some impact in situation when UG does not use B frames.
[1]: 5d54a25eea/libavcodec/libsvtav1.c (L224)
Acually there is quite a few that can be set:
1. default compression (witout RC) works quite good
2. bitrate as well (if the bitrate isn't too low)
3. quality controlled RC doesn't seem to work good
Slice considerations:
- 32 (default) triggers a warning for FullHD and OpenH264 will use
16 -> this is OK
- slices=0 would disable multithreading
- setting max_nal_size (with slices=0) would help as well, but it is
not clear what is the "good" value
Not yet added to CI (libopenh264 is included in Ubuntu 22.04, now using
20.04 for the build).
CQP just for number validity (not sure about the reange now), CRF also
the ranged (0-63 - 63 for 10-bit H.264, otherwise 51 /also for higher
bit depth HEVC).
Set automatic number (== 0) of threads if codec advertises
AV_CODEC_CAP_OTHER_THREAD implicitily, with exceptions:
1. AOM AV1, rav1e - seems not to set the number automatically
2. libx26* - allow setting but enables frame threading internally
(which is undesirable)
the current setting applies not just to libvpx* but also to
eg. libopenh264.
Warn if requesting input encoder pixel formats but the encoder is
not specified explicitly, eg. for
`uv -c lavc:codec=H.264 --param lavc-use-codec=help`
we cannot know, whinch encoder will be used in the
end (usually libx264 for YCbCr and libx264rgb for RGB pixel formats).
Use a word 'coders' instead of 'decoders' to point out to potentially
unsupported features, because not only decoders may be affected, so make
it clear.
Moved metadata housekeeping to store_metadata() and removed the
assert. The idea is to prevent crashes on assert when some encode fails.
In some malicous case (eg. when the latency is higg), the metadata can be
now released prior to restoring, so print at least a warning about that.
The SVT HEVC compression has (for UG) an ugly feature that it caches
internally in some cases a huge amount of frames, leading to increased
latency and also memory consumption. The first problem is dealt with
at least with the warning (commit e3f64d56, 2024-04-12).
if running
`uv -t testcard:c=RG48:s=3840x2160:fps=240 -c lavc:enc=libsvt_hevc`
with default preset (7) the latency grew up to some 430 frames, triggering
the assertion in store_metadata().
Setting the preset (for the above command - it is size/FPS depending)
to 11 shrinks the amount of frames cached to some 40 frames, that seem
more acceptable.
There are actually 2 places where avcodec_receive_packet() is called
and the error handling is the same so move it to a separate function.
\+ report (in debug) EAGAIN
\+ move HOUSEKEEP_INTERVAL at the beginning of the file (there already
is an eligible enum)
I assume that the pts should be always set on output if set on input so
assert it. If this proves wrong, it would need to be handled specially
(but also it will break the mechanism of metadata storing/restoring).
Can indicate a problem, eg. currently SVT HEVC when doesn't manage to
compress real-time.
It can also indicate eg. B-frames presence which may be desired (requested
by user parameters) but we can at least point it out.
Repeat the message every 30 secods - it is potentially important
information and when printed only once, the user may miss the point when
there is plenty of messages (especially at the beginning).
\+ do the same also for decompress
Fixed a crash in situation where compressing stream with properties A,
then B but init fails and then again A.
This can occur when using switcher for 1->2->1 when compress reconf
fails for 2. But because `saved_desc` is set if reconf succeeds and
was already set on first configure, the state is inconsistent because
partially de/configured for 2 but it looks like it is still correctly
configured to input 1 because `saved_desc` was not cleared.
refers to GH-365
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`).
