From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 4330C40E73 for ; Wed, 9 Feb 2022 05:49:32 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 80CE868B140; Wed, 9 Feb 2022 07:49:30 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 363A668AF07 for ; Wed, 9 Feb 2022 07:49:24 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 98E4B240179 for ; Wed, 9 Feb 2022 06:49:23 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GBx3KI0_47-P for ; Wed, 9 Feb 2022 06:49:22 +0100 (CET) Received: from lain.red.khirnov.net (lain.red.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.red.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 8621F240175 for ; Wed, 9 Feb 2022 06:49:22 +0100 (CET) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id B6D361601AD; Wed, 9 Feb 2022 06:49:22 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB0365F37305BDDD1C1F4FC3D3BA2D9=40DM8P223MB?= =?utf-8?q?0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= References: <20220201100227.18928-1-anton@khirnov.net> =?utf-8?q?=3CAM7PR03M?= =?utf-8?q?B6660368FF770BF9CFF25DFB38F2C9=40AM7PR03MB6660=2Eeurprd03=2Eprod?= =?utf-8?q?=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CDM8P223MB0365?= =?utf-8?q?2A19235F0878A58FEC2DBA2C9=40DM8P223MB0365=2ENAMP223=2EPROD=2EOUTL?= =?utf-8?q?OOK=2ECOM=3E?= <164431301321.19727.453011583235613178@lain.red.khirnov.net> =?utf-8?q?=3CD?= =?utf-8?q?M8P223MB0365F37305BDDD1C1F4FC3D3BA2D9=40DM8P223MB0365=2ENAMP223?= =?utf-8?q?=2EPROD=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 09 Feb 2022 06:49:22 +0100 Message-ID: <164438576271.9519.10531238838401724055@lain.red.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavc/mpeg*: drop the XvMC hwaccel code X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Soft Works (2022-02-08 22:34:42) > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Tuesday, February 8, 2022 10:37 AM > > To: FFmpeg development discussions and patches > 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".