For DeinterlacingBob mode with rate=field, the frame number of output
should equal 2x input total since only intra deinterlace is used.
Currently for "backward_ref = 0, rate = field", extra_delay is
introduced. Due to the async without flush, frame number of output is
[expected_number - 2].
Specifically, if the input only has 1 frame, the output will be empty.
Add deint_vaapi_request_frame for deinterlace_vaapi, send NULL frame
to flush the queued frame.
For 1 frame input in Bob mode with rate=field,
before patch: 0 frame;
after patch: 2 frames;
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i input.h264 -an -vf
deinterlace_vaapi=mode=bob:rate=field -f null -
Tested-by: Mark Thompson <sw@jkqxz.net>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
MSDK vc1 and av1 sometimes output frame into the same suface, but
ffmpeg-qsv assume the surface will be used only once, so it will
unref the frame when it receives the output surface. Now change
it to unref frame according to queue count.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Trying to write too much will currently overwrite previous data. Trying
to read too much will either av_assert2() in av_fifo_drain() or return
old data. Trying to peek too much will either av_assert2() in
av_fifo_generic_peek_at() or return old data.
Return an error code in all these cases, which is safer and more
consistent.
It returns a pointer inside the fifo's buffer, which cannot be safely
used without accessing AVFifoBuffer internals. It is easier and safer to
use av_fifo_generic_peek_at().
FLAC parser currently uses AVFifoBuffer in a highly non-trivial manner,
modifying its "internals" (the whole struct is currently public, but no
other code touches its contents directly). E.g. it does not use any
av_fifo functions for reading the FIFO contents, but implements its own.
Reimplement the needed parts of the AVFifoBuffer API in the FLAC parser,
making it completely self-contained. This will allow us to make
AVFifoBuffer private.
mvhd and tkhd present the post-editlist duration, while mdhd should
have the pre-editlist duration. Regression since c2424b1f3.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was accidentally comparing s->colorspace against out->colorspace,
which is wrong - the intent was to compare in->colorspace against
out->colorspace.
We also forgot to strip mastering metadata. Finally, the order is sort
of wrong - we should strip this side data *before* process_frames,
because otherwise it may end up being seen and used by libplacebo.
Signed-off-by: Niklas Haas <git@haasn.dev>
Commit 8b83dad825 introduced a
regression in a way that scaling via vpp_qsv doesn't work any longer
for devices with an MSDK runtime version lower than 1.19. This is true
for older CPUs which are stuck at 1.11.
The commit added checks for the compile-sdk version but it didn't test
for the runtime version.
Signed-off-by: softworkz <softworkz@hotmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Return an error directly if pixfmt is not supported for encoding, otherwise
it may be hidden until query/check in MSDK.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Channel reordering is removed from this patch because the new channel layout
API will support it properly.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes decoding of sample https://streams.videolan.org/ffmpeg/incoming/720p60.mp4
on RPi4 after kernel driver commit:
staging: bcm2835-codec: Format changed should trigger drain
Reference:
linux/Documentation/userspace-api/media/v4l/dev-decoder.rst
"A source change triggers an implicit decoder drain, similar to the
explicit Drain sequence. The decoder is stopped after it completes.
The decoding process must be resumed with either a pair of calls to
VIDIOC_STREAMOFF and VIDIOC_STREAMON on the CAPTURE queue, or a call to
VIDIOC_DECODER_CMD with the V4L2_DEC_CMD_START command."
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Reference:
linux/Documentation/userspace-api/media/v4l/dev-decoder.rst
"During the resolution change sequence, the OUTPUT queue must remain
streaming. Calling VIDIOC_STREAMOFF() on the OUTPUT queue would
abort the sequence and initiate a seek.
In principle, the OUTPUT queue operates separately from the CAPTURE
queue and this remains true for the duration of the entire
resolution change sequence as well."
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Ming Qian <ming.qian@nxp.com>
avcodec_open2() is supposed to be thread-safe (those codecs
whose init functions are not thread-safe are guarded
by a global lock).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the MPEG-4 parser no longer initializes some MPEG-4 VLCs,
no VLC is initialized concurrently by multiple threads
(initializing static VLCs is guarded by locks and nonstatic VLCs
never posed an issue in this regard). So remove the code
in bitstream.c that only exists because of this possibility.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It can't any longer, because all users of ff_rl_init() are now
behind ff_thread_once() or the global codec lock. Therefore
the check for whether the RLTable is already initialized can be removed;
as can the stack buffers that existed to make sure that nothing is ever
set to a value different from its final value.
Similarly, it is not necessary to check whether the VLCs associated
with the RLTable are already initialized (they aren't).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both the MPEG-4 parser as well as the decoder initialized
several VLCs. There is a "static int done = 0;" in order to
guard against initializing these multiple times, but this does
not work when several threads try to initialize these VLCs
concurrently, which can happen when initializing several parsers
at the same time (they don't use the global lock that is used
for codecs without the FF_CODEC_CAP_INIT_THREADSAFE cap; actually,
they don't use any lock at all).
Since ff_mpeg4_decode_picture_header() now aborts early when called
from the parser, it no longer needs to have these VLCs initialized
at all. This commit therefore does exactly this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely, skip some elements that are only useful for a decoder
when calling ff_mpeg4_decode_picture_header() from the MPEG-4 parser.
In particular, this ensures that the VLCs need no longer be
initialized by the parser.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case it means moving ff_h263_pred_dc() resp. ff_h263_pred_acdc()
to ituh263enc.c resp. ituh263dec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
41f213c3bf accidentally added
an unused pixel_format option to the v210(x) demuxers.
Remove it before it really becomes part of the API.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is possible here, because the values of ff_log2_run used
here are actually in the range 0..15 given that run_index is
in the range 0..31.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Matroska muxer has quite a lot of dependencies and lots of them
are unnecessary for WebM. By disabling the Matroska-only code
at compile time one can get rid of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
iec61883_parse_queue_hdv() is only called when the mpegts-demuxer
is available and can be optimized away when not. Yet this
optimization is not a given and it fails with e.g. GCC 11 when
using -O0 in which case one will get a compilation error
because the call to the unavailable avpriv_mpegts_parse_packet()
is not optimized away. Therefore #if the offending code away
in this case.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes build errors if libzvbi is enabled while libzvbi_teletextdec
is disabled.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
parse_rtsp_message() is only called if the rtsp demuxer is enabled
and so it is normally compiled away if said demuxer is disabled.
Yet this does not happen when compiling with -O0 and this leads
to a linking failure because parse_rtsp_message() calls functions
that may not be available if the rtsp demuxer is disabled.
Fix this by properly #if'ing the unused functions away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
