| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
Cleanup after commit 3fc72c9fc16df3b7edc329ed9eeaaa1e65976c33.
Fixes coverity ticket #1497095.
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Ming Qian <ming.qian@nxp.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
change event
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
event
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
827d6fe73d2f5472c1c2.
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>
|
|
|
|
|
| |
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
|
|
|
|
|
|
| |
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
|
|
|
|
|
| |
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
| |
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
|
|
| |
This will allow re-use of the m2m backend with AVFilterContext
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
are probed
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>
|
|
|
|
|
| |
Signed-off-by: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
| |
Signed-off-by: Aman Gupta <aman@tmm1.net>
|
|
|
|
|
|
| |
Fixes CID 1418358
Signed-off-by: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/
|
|
|
|
|
| |
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
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>
|