A POLLERR occurs when libavcodec attempts to dequeue output buffers
before enqueuing capture buffers. This could happen to an application
deciding to send the first coded packet. Suppress these POLLERRs when
the buffers are uninitialized and avoid crashing because of enumerating
uninitialized buffers.
See https://trac.ffmpeg.org/ticket/9957 for the original bug report.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Decoder-only, as the dimensions are set by the user when encoding.
Also fixup the other headers a bit while removing unnecessary internal.h
inclusions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Return proper error when frame buffers are full. This path is triggered
on the DragonBoard 410c since the encoding API change in commit
827d6fe73d.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
V4L2 api can indicate that flushing of the capture buffers is completed
by setting the V4L2_BUF_FLAG_LAST flag.
Use guards because the flag was only defined in Linux v4.2.
Reference:
linux/Documentation/media/uapi/v4l/dev-decoder.rst
"The client must continue to handle both queues independently,
similarly to normal decode operation. This includes:
...
- queuing and dequeuing CAPTURE buffers, until a buffer marked with
the V4L2_BUF_FLAG_LAST flag is dequeued"
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
v4l2_m2m devices may send an empty packet/frame while draining
to indicate that all capture buffers have been flushed.
Currently, the empty packet/frame is not handled correctly:
When encoding, the empty packet is forwarded to the muxer, usually
creating warnings.
When decoding, a reference to the memory is created anyway. Since in
the past this memory contained a decoded frame, it results in an extra
frame being decoded.
This commit discards the empty packet/frame.
References:
linux/Documentation/media/uapi/v4l/dev-decoder.rst:
"The last buffer may be empty (with :c:type:`v4l2_buffer` bytesused = 0)
and in that case it must be ignored by the client, as it does not
contain a decoded frame."
linux/Documentation/media/uapi/media/v4l/vidioc-encoder-cmd.rst:
"...This buffer may be empty, indicated by the
driver setting the ``bytesused`` field to 0."
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
v4l2_m2m uses device memory mapped buffers to store dequeued
frames/packets (reference counted by AVBufferRef). When the reference
count drops to zero, the buffer ownership is returned back to the
device, so that they can re-filled with frames/packets.
There are some cases when all the capture buffers are in userspace
(i.e. due to internal buffering in ffmpeg). On the s5p-mfc this causes
an infinite wait when polling to dequeue the buffers, which can be
prevented by increasing the total number of buffers. This commit adds a
warning when all the capture buffers are dequeued.
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
When flushing the capture buffers, the driver may send a V4L2_EVENT_EOS
to notify that draining is completed. Currently, v4l2_m2m does not
subscribe to this event, which can cause some devices (i.e. imx8qm) to
hang at the end of encoding/decoding. Support for handling the event is
added in this commit.
Some devices may not signal V4L2_EVENT_EOS. This is logged as a warning
message during initialization and not treated as a fatal error.
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Before this commit v4l2_m2m used two different logging contexts (from
V4L2m2mPriv and AVCodecContext). For consistency always use AVCodecContext.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
On the RPI, three different /dev/video devices exist (decoder, scaler, encoder).
When probing the devices in order, the originally requested pix fmt
would be mutated causing the wrong one to be chosen when a matching
device was finally found.
Signed-off-by: Aman Gupta <aman@tmm1.net>
ENOMEM indicates an allocation failure, and there are no allocations
happening here. The buffers are pre-allocated and there are simply
none available at this time.
Signed-off-by: Aman Gupta <aman@tmm1.net>
During the initialization stage, the codec attempts to get free
buffers from the driver before any have been queued (this is to keep
the code simple and generic)
When the kernel driver detects this situation, it returns POLLERR in
revents and ffmpeg therefore raises a warning.
This commit disables the warning since no buffers were queued to the
driver yet.
Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Qualcomm's db410c/db820 Venus driver currently present in mainline
kernel has a bug which mishandles the CMD_STOP requests causing the
decoder to block while draining [1].
This patch removes the workaround that was used to prevent that
situation.
Encoding/Decoding tested on db820c.
[1] on CMD_STOP, the driver is flushing all buffers and never raising
IPIPE which ends up in blocking on poll.
Fixes a warning on recent Linux:
libavcodec/v4l2_context.c: In function 'ff_v4l2_context_set_status':
libavcodec/v4l2_context.c:496:26: warning: comparison is always false due to limited range of data type
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for s5p-mfc [1]
Most drivers should be able to calculate this value from the frame
dimensions and format - or at least have their own default.
However since this work around should not impact those drivers doing
the "right thing" this commit just provides such a default.
The calculations were extracted from the v4l2 driver used to develop
the ffmpeg v4l2_m2m support [2]. See venc.c and vdec.c
[1] linux.git/drivers/media/platform/s5p-mfc
[2] linux.git/drivers/media/platform/qcom/venus/
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been tested on Qualcomm's DragonBoard 410c and 820c
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
Tested decoders:
- h264
- h263
- mpeg4
- vp8
- vp9
- hevc
Tested encoders:
- h264
- h263
- mpeg4
Tested transcoding (concurrent encoding/decoding)
Some of the changes introduced:
- v4l2: code cleanup and abstractions added
- v4l2: follow the new encode/decode api.
- v4l2: fix display size for NV12 output pool.
- v4l2: handle EOS (EPIPE and draining)
- v4l2: vp8 and mpeg4 decoding and encoding.
- v4l2: hevc and vp9 support.
- v4l2: generate EOF on dequeue errors.
- v4l2: h264_mp4toannexb filtering.
- v4l2: fixed make install and fate issues.
- v4l2: codecs enabled/disabled depending on pixfmt defined
- v4l2: pass timebase/framerate to the context
- v4l2: runtime decoder reconfiguration.
- v4l2: add more frame information
- v4l2: free hardware resources on last reference being released
- v4l2: encoding: disable b-frames for upstreaming (patch required)
[1] https://lwn.net/Articles/697956/
System Level view:
v42l_m2m_enc/dec --> v4l2_m2m --> v4l2_context --> v4l2_buffers
Reviewed-by: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Reviewed-by: Alexis Ballier <aballier@gentoo.org>
Tested-by: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: wm4 <nfxjfg@googlemail.com>