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

[Jorge Ramirez]

On 08/02/2017 10:51 PM, Reimar Döffinger wrote:
> 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.

well this is not the case.

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

unfortunately  we will _always_ have that with the v4linux codecs.
Only at runtime the user will discover if the codecs can be run in their 
platform

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

sure but why not have it without requiring a cross compiler if we can 
get it for free...
>
>> 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.

ok, I feel like I am wasting everyones time (so I must be wrong then 
when this is so evident to everyone else...I must be getting old :) 
)...I will simply amend the commit and move on.
thanks for you comments btw!



>
>> (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).
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel