[FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Wednesday, February 9, 2022 6:49 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC
> hwaccel code
> 
> Quoting Soft Works (2022-02-08 22:34:42)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Tuesday, February 8, 2022 10:37 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC
> > > hwaccel code
> > >
> > > Quoting Soft Works (2022-02-07 03:18:54)
> > > > I sometimes wonder whether there exists a single API user who
> > > > really understands this (very special) kind of logic and
> > > > would make decisions based on that understanding.
> > > >
> > > > When it's not even fully understood internally, how should it
> > > > be understood externally?
> > >
> > > The rule for API users is simple: you are not allowed to assume a
> > > specific component (like a decoder, demuxer or hwaccel) will be
> > > available at runtime*. You are supposed to check for it using the
> APIs
> > > provided for this purpose. In this case, AV_PIX_FMT_XVMC will just
> > > stop
> > > being offered in get_format().
> > >
> > > Not to mention that I very much doubt there are any users of xvmc
> > > left,
> > > besides the original mplayer.
> > >
> > > * unless you are running with a very specific verified build, in
> which
> > >   case a removal like this should be caught at the build stage
> >
> > Thanks for the explanation. I misunderstood this a bit - when the
> > only effect of the "removal" is an output like when the libs
> wouldn't
> > have been compiled with that part, then that's maybe nothing to
> > be blamed for.
> > On the other side: when somebody is using it and updates the libs
> > to a point where it's missing, it will be broken for her/him.
> > So the outcome might not be _that_ different for any other breaking
> > changes being made.
> 
> I agree that in general removing random components would be a bad
> thing
> to do, even though it's not technically an API break. That's why we
> don't do it if there's any chance the component in question is useful.
> 
> The argument _in this specific case_ is that xvmc is not useful to
> anyone and has not been for a very long time, so no valid use cases
> are
> broken by its removal. In fact its only user ever I'm aware of is the
> original mplayer (mplayer2, which was later forked into mpv, dropped
> it
> in 2011).

Sure. Don't understand my reply as an objection I don't even know what
xvmc is (or was). I rather see the burden and effort that it takes 
to retain all those compatibility paths and at the same time how it
is blocking innovation and progress. 
Compatibility is important - without question, but doing it in a way
that libs from different versions can be combined, is a somewhat crazy
endeavor. I keep wondering who would be the developer whose dreams
this might fulfil.. 
The discussion about that seems to have gotten stuck about whether
to merge libs together or not, or how, but I haven't followed in 
detailed, so please excuse the question (which has probably been
covered before): 
Why can't ffmpeg simply declare that starting from version X, it
will be a requirement that all libs are from the same version?
(of course after equalizing)

BR,
softworkz