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