Deleted 2 unneeded lines:
1. OLDPWD - not used
2. comment - no longer valid - the cached environment key contains hash
of .github/scripts/Linux/arm/bootstrap.sh, which means that if the file
changes, the old env is not used, anyways
For following command, deduced conversion is to 10-bit YUV:
$ uv -t testcard:c=RGB -c libavcodec:enc=libx264 -d gl
[to_lavc_vid_conv] converting RGB to yuv444p10le over R12L
(and over R10k for RGBA) which is correct, because we don't have any
8-bit YUV pixfmt keeping 4:4:4 subsampling.
But this is quite ineffective because the conversions are more expensive
and we are needlessly compressing 10-bit YUV instead of 8-bit.
Thus (as we don't have any UG 8-bit YUV444 pixfmt) the rgb_to_yuv444p
conversion was added.
Issue a warning if unable to set the buffers andreceiving uncompressed
stream, but not not on initial setting, only if increase requested.
The logic is not entirely straightforward - as we are increasing only,
do not assume that the buffer is set to the initial size but rather read
the actual value, which will be less if wasn't possible to set. So the
second attemp issues the warning.
Re-added check to GL_NV_vdpau_interop removed by mistake in commit
bf3b2b3b (21st Apr 2022).
In the previous solution error was written but retval was not checked,
causing a crash. Now only warning is issued and HW_VDPAU is not
offered. In state_vdpau::init() is used assertion.
The loading of samples with negative value was not working properly
because of sign expansion. The storing works fine, because samples are
only ever written with the same or less BPS.
This reverts commit 586c3fc585.
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.
Check if video subsampling is 4:2:0 from sw_pix_fmt than iterating over
received pix_fmts. This is simplier and more effective since the SW
format is set the get_format() callback to the nominal SW format (if any).
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>
Advertise conversion to HW-accelerated codecs (eg. HW_VDPAU, RPI4_8)
only if probe (which now works in the same way as regular init since
HEAD^) would initialize to an accelerated codec.
This would prevent situations, when eg. `--param use-hw-accel=vaapi -d
gl` is used, in which case HW_VDPAU was selected as a display codec,
although not intended.
We want rather mimic the actual initialization in the probe.
Also avoid errors like:
````
[lavc hevc @ 0x7f4b0c002700] A hardware frames or device context is required for hardware accelerated decoding.
[lavc hevc @ 0x7f4b0c002700] Failed setup for format vdpau: hwaccel initialisation returned error.
````
Currently, if probing, hw acceleration is skipped, but this will change
so this is done in preparation to this.
Also print in verbose mode now (it is now more useful to debug).
Previously, if '--param use-hw-accel' was specified but the hw
acceleration was not compiled-in, unknown parameter was reported.
This is not entirely acurate and can be a little misleading, rather
print that the support is not enabled directly.
With current zfec code, fec_init() needs to be called prior to fec_new(),
otherwise the later one returns NULL.
\+ updated submodule to the current zfec version (requiring fec_init();
but UG will compile with the older zfec version as well)
