[FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
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
> 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
-> 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
-> 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
(do you have this guarantee with all the other APIs that you are using?)
> - Hendrik
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel