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

[Nicolas George]

Le quintidi 15 thermidor, an CCXXV, Jorge Ramirez a écrit :
> 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.

You said yourself: the same reasons lead to the same conclusions. Since
all reasons you have given in this discussion apply equally to all
libraries and all applications, therefore the same conclusions should
apply too.

Since this is completely ridiculous, you have to understand that there
is something flawed in your reasoning.

> >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.

Good.

> since when open for extension and closed for modification is unstable?

Have you noticed that my sentence starts with "if"? You told the
condition was not meant, and I assume you know how an if/else clause
works, so you know that you should have answered to the next paragraph
and not this one:

> >And if they are, we can just use the installed headers.

Unfortunately, you neglected to answer that.

> it depends...duplicating the Universe might serve its purpose

Yes, indeed: to shift a little burden from your shoulders into somebody
else's, hugely inflating it at the same time as Reimar explained. You
will forgive us for not being receptive.

>								(you seem to
> go blindly against duplication...dont you have two lungs?)

I hope burning these straw men keeps you warm during these cold summer
days.

> anyway, if you and other maintainers want to simply use the "authority" card
> fine by me.

I still hope you can be convinced to understand proper design
principles. But if that cannot be achieved,then authority it is.

> 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.

I can say the same about any other library and any other application
using them. You have not proven, as Hendrik requested, that V4L was
exceptional.

> 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)

I can say the same about any other library and any other application
using them. You have not proven, as Hendrik requested, that V4L was
exceptional.

> 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

I can say the same about any other library and any other application
using them. You have not proven, as Hendrik requested, that V4L was
exceptional.

> 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?)

Libraries following a disciplined development cycle do guarantee that
indeed.

Since you have not proven that V4L was special, we will assume it is not
and treat it as any other library. configure checks and no headers
duplication please.

> 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

That can be said of any device: sample rates supported by ALSA devices,
resolutions supported by broadcast cards, etc. It is entirely normal.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170803/b60fef8f/attachment.sig>