Enqueue/dequeue of the capture buffers should continue while draining.
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"
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
This part of the code counts the number of planes returned by the v4l2
device for each queried capture/output buffer.
When testing the GPU h264 encoder on Nvidia's Jetson Nano, this caused an
infinite loop because avbuf->buf.length included some empty buffers (i.e.
where avbuf->buf.m.planes[i].length = 0), meaning that the counter was
never incremented and break was never reached.
This is fixed in the commit by using a well defined iteration range.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Without this ffmpeg will attempt to copy the dts from the
most recently enqueued packet into the most recently dequeued
frame, which does not account for the buffering inside v4l2
and is not accurate.
Signed-off-by: Aman Gupta <aman@tmm1.net>
Frames are generally dequeued into capture buffers, so using
the output properties here was incorrect. It happened to work
fine for decoding, since the output/capture buffers have the same
dimensions.
For the v4l2 scaler, the dimensions can be different between output
and capture. Using the buffer's associated context makes this code
work correctly regardless of where the frame is coming from.
Signed-off-by: Aman Gupta <aman@tmm1.net>
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.
Refcount all of the context information. This also fixes a potential
segmentation fault when accessing freed memory (buffer returned after
the codec has been closed).
Tested-by: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com>
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>
Ming Qian
Andriy Gelman
Aman Gupta
Maxime Jourdan
Lukas Rusak
Dave Stevenson
Mark Thompson
Jorge Ramirez-Ortiz