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

[Reimar Döffinger]

On 02.08.2017, at 19:53, Jorge Ramirez <jorge.ramirez-ortiz at linaro.org> wrote:

> 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.

Unless you know that the v4l2 headers never, ever, in any circumstance will have bug fixes, it is a HUGE maintenance effort: namely someone must continuously monitor upstream for such fixes and import them.
Besides that I thought that importing files was commonly accepted to be a horrible practice.

> 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)

The flip side is it will be enabled and look to be available on systems where it CANNOT work.

> 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

Generally the solution is to have a proper cross-compile setup (or if you are really so lucky that everything else is close enough in versions, by adding an extra include path).

> 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.

Only if the header is guaranteed bug-free.

> (do you have this guarantee with all the other APIs that you are using?)

Every library SHOULD have such guarantee as long as the major version is not being bumped, so in theory it's nothing special (though admittedly in practice most libraries are a lot more careless than kernel).