[FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
h.leppkes at gmail.com
Wed Aug 2 16:28:33 EEST 2017
On Wed, Aug 2, 2017 at 11:39 AM, Jorge Ramirez
<jorge.ramirez-ortiz at linaro.org> wrote:
> On 08/02/2017 09:33 AM, Hendrik Leppkes wrote:
>> On Tue, Aug 1, 2017 at 2:54 PM, Jorge Ramirez-Ortiz
>> <jorge.ramirez-ortiz at linaro.org> wrote:
>>> From: Alexis Ballier <aballier at gentoo.org>
>>> This patchset enhances Alexis Ballier's original patch and validates
>>> it using Qualcomm's Venus hardware (driver recently landed upstream
>>> This has been tested on Qualcomm's DragonBoard 410c and 820c
>>> Tested decoders:
>>> - h264
>>> - mpeg4
>>> - vp8
>>> - vp9
>>> - hevc
>>> Tested encoders:
>>> Tested transcoding (concurrent encoding/decoding)
>>> Some of the changes introduced:
>>> - v4l2: code cleanup.
>>> - v4l2: follow the decode api.
>>> - v4l2: fix display size for NV12 output pool.
>>> - v4l2: handle EOS.
>>> - v4l2: vp8 and mpeg4 decoding.
>>> - v4l2: hevc and vp9 support.
>>> - v4l2: generate EOF on dequeue errors.
>>> - v4l2: h264_mp4toannexb filtering.
>>> - v4l2: import compat/v4l2 header files.
>>>  https://lwn.net/Articles/697956/
>>> Reviewed-by: Jorge Ramirez <jorge.ramirez-ortiz at linaro.org>
>>> Reviewed-by: Alexis Ballier <aballier at gentoo.org>
>>> Tested-by: Jorge Ramirez <jorge.ramirez-ortiz at linaro.org>
>>> Changelog | 3 +-
>>> compat/v4l2/v4l2-common.h | 107 ++
>>> compat/v4l2/v4l2-controls.h | 987 +++++++++++++++++
>>> compat/v4l2/videodev2.h | 2402
>> As commented on IRC before, I'm not a fan of importing Linux kernel
>> headers for the only reason because its convenient to always have
>> recent headers available.
> Hi Hendrik,
> but what is wrong with convenience? as a matter of fact, this will not add
> any 'major' maintenance task.
> Only when the ffmpeg v4l2 support is modified to add a more recent call (or
> some new fourcc) these headers will have to be updated accordingly (ie do a
> copy paste for files that are easily avaialable)
> IMO, this seems much easier, less error prone - and consistent - than
> modifying configure every time looking for what needs to be checked before
(Re-send because I didn't send it to the List by accident)
You could bring that argument for every single external library/API we
support, and that is just not something we should be doing.
We require headers to be available in the system for practically every
other external API/library with only very few exceptions which have
extraordinary circumstances beyond "I don't want to maintain configure
So no, we should not be doing this.
More information about the ffmpeg-devel