On 08/02/2017 10:51 PM, Reimar Döffinger wrote:
On 02.08.2017, at 19:53, Jorge Ramirez <jorge.ramirez-or...@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-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.
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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
