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

Jorge Ramirez jorge.ramirez-ortiz at linaro.org
Wed Aug 2 20:53:59 EEST 2017


On 08/02/2017 07:40 PM, Hendrik Leppkes wrote:
> On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez
> <jorge.ramirez-ortiz at linaro.org> wrote:
>> I just think is wrong and I am a bit surprised we could have no real
>> argument on the matter.
>>
> I've asked for your arguments on why v4l2 is so special that it
> warrants special treatment above any other external library/headers,
> and I have not heard any that would differentiate v4l2 from anything
> else.
> If you can provide any, we can discuss those.

[paste from previous exchange]

1. reduction in the frequency of the maintenance tasks.
When they need to be performed (ie new format or fourcc or whatever), 
the user will be updating for the _future_ since it will import many 
other updates.
-> You can't say the same about maintaining configure.

2. the build environment is always sane no matter where you build.
This translates in more extensive testing since it enables building on 
more environments.
-> You can't say the same about checking against whatever API was 
installed in the build environment (could be 8 years old)

3. you can build encoders natively on a 14.04 server running a 3.3 
kernel and execute them on a target running a recent kernel
-> that can't be done the way you propose

And since the kernel guarantees that will not break userspace, there is 
zero risk to the users if we import the V4L2 API just as other projects 
have done.
(do you have this guarantee with all the other APIs that you are using?)



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



More information about the ffmpeg-devel mailing list