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

Jorge Ramirez jorge.ramirez-ortiz at linaro.org
Wed Aug 2 20:14:17 EEST 2017

>> I am probably not the best person to discuss why other libraries/codecs are
>> managed the way they are(I lack the background and I would probably be
>> spawning discussions that have been already had);
> We could ask it the other way around: do you propose that every single
> application that wants to use v4l should duplicate its headers? And, for
> that matter, the headers of all the libraries it uses?

how can I propose that "every single application duplicate headers" 
without knowing their use cases? that sort of generalization seems silly 
to me.
there is no silver bullet to these kind of problems as you probably know.

having said that, all the relevant applications that I know in fact do 
(ie, GStreamer, and other proprietary ones in the automotive industry)

>> If they use configure I _suppose_ it might be because those "apis" do not
>> risk/benefit from being extended with every single kernel version (I used
>> the word extended intentionally - API open for extension, closed for
>> modification)...so they wont leverage the kernel's development cycle.
> If the new v4l APIs are so unstable that they break compatibility at
> every single kernel version, then maybe they are not yet mature enough
> for programs like FFmpeg.

nope, non sequitur.
since when open for extension and closed for modification is unstable?
is actually the opposite...and exactly the sort of thing I am asking 
that we take advantage of.

> And if they are, we can just use the installed headers.
>> but sure, all my reasons lead to the same conclusion (isn't that how is
>> supposed to be in any coherent argument?).
> Exactly. And since the conclusions are obviously wrong, you can deduce
> the reasons are invalid.

:) why? I am still waiting for some actual reasoning on this matter.

>> but sure whatever system will have a well maintained version.
>> Only thing is, servers will have old copies of the API preventing users from
>> building (think kernel 3.13?)
>> is this what the project wants? Only being able to build in a system that
>> "might" be able to run?
> It is better than duplicating the Universe.

it depends...duplicating the Universe might serve its purpose (you seem 
to go blindly against duplication...dont you have two lungs?)

anyway, if you and other maintainers want to simply use the "authority" 
card fine by me.
lets save time and I will just modify configure (is a 5 minutes job)

I just think is wrong and I am a bit surprised we could have no real 
argument on the matter.

but please do confirm and I will amend the commit.

> Regard,

More information about the ffmpeg-devel mailing list