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 72A6640AE3 for ; Sun, 5 Jun 2022 08:20:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B655368B69C; Sun, 5 Jun 2022 11:20:09 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A7DB268B5B0 for ; Sun, 5 Jun 2022 11:20:03 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 236AE240175 for ; Sun, 5 Jun 2022 10:20:03 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id um_BVwCYmplT for ; Sun, 5 Jun 2022 10:20:01 +0200 (CEST) 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 B80682400F5 for ; Sun, 5 Jun 2022 10:20:01 +0200 (CEST) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id CFACE1601B2; Sun, 5 Jun 2022 10:20:01 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB036512ED3D29D532CECAF58DBAA39=40DM8P223MB?= =?utf-8?q?0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= References: <20220323155720.20017-1-anton@khirnov.net> =?utf-8?q?=3CDM8P223M?= =?utf-8?q?B0365783CC5AF48817C137226BAA39=40DM8P223MB0365=2ENAMP223=2EPROD?= =?utf-8?q?=2EOUTLOOK=2ECOM=3E?= <165441247425.5088.1095760194724448724@lain.red.khirnov.net> =?utf-8?q?=3CD?= =?utf-8?q?M8P223MB036512ED3D29D532CECAF58DBAA39=40DM8P223MB0365=2ENAMP223?= =?utf-8?q?=2EPROD=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Sun, 05 Jun 2022 10:20:01 +0200 Message-ID: <165441720181.5088.3725748658698613904@lain.red.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavc/avcodec: simplify codec id/type validity checking 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-06-05 09:54:51) > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of Anton > > Khirnov > > Sent: Sunday, June 5, 2022 9:01 AM > > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavc/avcodec: simplify codec id/type > > validity checking > > > > Quoting Soft Works (2022-06-05 07:23:18) > > > This is causing a regression in ffprobe. > > > > > > The commit removes the special-case check for AVMEDIA_TYPE_ATTACHMENT which > > > was required for ffprobe and had been added with > > e83c716e16c52fa56a78274408f7628e5dc719da. > > > > > > The demand from the commit message is not yet guaranteed to be fulfilled: > > > > > > > On entry to avcodec_open2(), the type and id either have to be > > > > UNKNOWN/NONE or have to match the codec to be used. > > > > > > I have one verified example (maybe a second will follow), which is an MKV > > with > > > an attachment "stream" of type "text". > > > The found codec will be textdec of type 'subtitle' even though the stream > > type > > > is attachment. Without the special condition for attachment streams, this > > > is now causing ffprobe to error out with non-zero exit code and incomplete > > > output. > > > > > > > > > ------------------------------------------------------------------------ > > > Example: > > > > > > [...] > > > Stream #0:9: Attachment: text > > > Metadata: > > > filename : textfile.text > > > mimetype : text/plain > > > [text @ 000001AC32310340] Codec type or id mismatches > > > Could not open codec for input stream 9 > > > ------------------------------------------------------------------------ > > > > This sounds very much like a bug in ffprobe. It makes no sense to call > > avcodec_open2() with the AVMEDIA_TYPE_ATTACHMENT type. > > You make a behavioral change to an API function that had this behavior > established and constant over more than 10 years, and when that change > breaks functionality, it's the callers' fault? > How does this go together with all that peanut counting of major, minor > and micro version numbers per library? What is this versioning good for, > when you can make breaking changes and declare the breakage as bugs? We maintain compatibility for valid API usage. We do not maintain bug compatibility. I fail to see how calling avcodec_open2() with AVMEDIA_TYPE_ATTACHMENT is valid API usage. What do you expect it to do? There are no AVMEDIA_TYPE_ATTACHMENT decoders. More generally, arguments along the line of "change is needed to keep program working>" on their own sound very shady to me and suggest that perhaps program should not be doing whatever it is doing. -- 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".