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

From: Soft Works <softworkz@hotmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code
Date: Tue, 8 Feb 2022 21:34:42 +0000
Message-ID: <DM8P223MB0365F37305BDDD1C1F4FC3D3BA2D9@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <164431301321.19727.453011583235613178@lain.red.khirnov.net>

> -----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. And that's what I meant to point out:
On one side, we are carefully curating those versioning changes
(individually for each lib!) with a complex set of rules and 
considerations to be made, while in the majority of cases I tend
to believe that not many really care that much about it, instead
sitting there, happily using it until the moment "Oh it's broken -
- need to do something - fix it and go on.." :-)

softworkz

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