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

[Anton Khirnov <anton@khirnov.net>]

Quoting Soft Works (2022-02-08 22:34:42)
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Anton Khirnov
> > Sent: Tuesday, February 8, 2022 10:37 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@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).

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".