Use wider types to keep the timestamp monotonous at least at the sender -
all current sources (DeckLink, file, testcard) should be compatible now.
This will have advantage for audio compression where there will be no
need to tackle with the work-around.
Since there are now hw accels available on other plaforms (videotoolbox
on mac and maybe vulkan decode on Windows) it no longer makes sense to
hide the option on those platforms.
Allow 32-bit builds on Buster. This has some advantages
regarding supported HW accelerations in UltraGrid, eg. h264_omx is not
supported in higher versions of the system.
It is not enabled by default but can be enabled easily by switching the
value in YAML file.
refers to GH-344
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).
