On 08/02/2017 07:40 PM, Hendrik Leppkes wrote:
On Wed, Aug 2, 2017 at 7:14 PM, Jorge Ramirez
<jorge.ramirez-or...@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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
