[FFmpeg-devel] [PATCHv2 4/4] libavcodec: v4l2: add support for v4l2 mem2mem codecs
george at nsup.org
Wed Aug 2 19:55:13 EEST 2017
Le quintidi 15 thermidor, an CCXXV, Jorge Ramirez a écrit :
<snip 100+ lines of useless quote>
Could at least one of you trim their mail once in a while please?
> 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?
> 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.
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.
> 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.
More information about the ffmpeg-devel