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

[Jorge Ramirez]

On 08/28/2017 11:52 AM, wm4 wrote:
> On Sun, 27 Aug 2017 18:26:32 +0200
> Jorge Ramirez<jorge.ramirez-ortiz at linaro.org>  wrote:
>
>> On 08/25/2017 05:35 PM, wm4 wrote:
>>> That looks generally OK. Is there any chance a hwaccel approach would
>>> be possible instead? If I've learned anything about hardware decoding,
>>> then that hwaccel is vastly superior to vendor-implemented full stream
>>> decoders.
>> could you help me understand what would that entitle and what how would
>> that be beneficial to the users?
>> I just dont feel I can answer that question properly...
> With hwaccels, the hardware gets only the slice data (and a bunch of
> API parameters with information about the bitstream etc.) instead of
> the full bitstream. The advantage is that higher level bitstream
> parsing, metadata retrieval, reference frame management, frame
> reordering, etc. are all done by the already existing native codec
> implementation.
>
>> v4l2 provides a generic API  which is what the patchset uses to perform
>> encoding/decoding on any v4l2 supported hardware (it is completely
>> vendor independent)
>>
>>   From the layer above (libavcodec) all it needs is a way to get the
>> frame information and after processing to pass it back; so in principle,
>> if the hwaccel API provides that, I could just move it all to use those
>> calls if you think that fits better with ffmpeg.
>>
>> but I dont think I understand the benefit of changing from the ffmpeg
>> encoding/decoding API to hwaccel API.
>>
>>> I don't think I like the attempt of sharing the v4l helper functions
>>> between libavdevice and libavcodec, but I can't tell how much it helps.
>> ok. I am of course open to suggestions on this (I didnt see any issues
>> with what the patchset provides or I would have done it differently).
> Just forget that libavdevice exists, and keep it correct and simple in
> libavcodec.

[resending to the ML];

but I do need to use some of the functions supported in libavdevice for 
its v4l2 frame grabber support; ignoring that code means I will have to 
pretty much duplicate it with a couple of additions that said..
is this what you are suggesting or am I misunderstanding you?

I'll post v7 after this last bit (this dependency seemed to also be a 
source of concern for Paul Mahol)