[FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs

[Jorge Ramirez]

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
>> [1]).
>>
>> This has been tested on Qualcomm's DragonBoard 410c and 820c
>>
>> Tested decoders:
>>         - h264
>>         - mpeg4
>>         - vp8
>>         - vp9
>>         - hevc
>>
>> Tested encoders:
>>         -h264
>>         -h263
>>         -mpeg4
>>
>> 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.
>>
>> [1] 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 building.

> On a system with a recent enough kernel to run this, you would also
> have matching headers, so IMHO this should behave like any external
> library dependency and just check that the headers are recent enough
> to build our code, and just skip building the module otherwise.

but what if the user is running of vendor trees with some hacked 
versions of these files in the rootfs? this way at least he'll know 
exactly what he is building. And if wishes some custom behavior, we are 
enforcing that he changes the UAPI v4l2 in the ffmpeg _tree_
Seems coherent to me.

also notice, that having a recent enough kernel does allows the user to 
build, will not guarantee that we will be able to run these 
encoders/decoders (the user will need actual hardware support for that 
and the v4l2 driver in the kernel)

>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel