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 5DCFA42D9D for ; Wed, 8 Jun 2022 06:17:21 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B0EAE68B5DD; Wed, 8 Jun 2022 09:17:17 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B2DB268B335 for ; Wed, 8 Jun 2022 09:17:10 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 1776E240175 for ; Wed, 8 Jun 2022 08:17:10 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id xjU6vPHWl5zS for ; Wed, 8 Jun 2022 08:17:08 +0200 (CEST) Received: from lain.khirnov.net (lain.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.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id A579C2400F5 for ; Wed, 8 Jun 2022 08:17:08 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id D6DD31601B2; Wed, 8 Jun 2022 08:17:08 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB0365397786EAF497BA5DC577BAA49=40DM8P223MB?= =?utf-8?q?0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= References: <20220607115839.18515-1-anton@khirnov.net> =?utf-8?q?=3CDM8P223M?= =?utf-8?q?B03650454F09DE4D7C396CFB4BAA49=40DM8P223MB0365=2ENAMP223=2EPROD?= =?utf-8?q?=2EOUTLOOK=2ECOM=3E_=3CDM8P223MB0365397786EAF497BA5DC577BAA49=40D?= =?utf-8?q?M8P223MB0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 08 Jun 2022 08:17:08 +0200 Message-ID: <165466902879.5088.14253593912707356675@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain attachments to AV_CODEC_ID_TEXT 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-08 05:45:38) > You might allow me the question whether we can be sure that > this is the only case which is subject to the regression? > > Besides from what I reported above (and you might probably come up > with a new codec ID for discriminating text subs vs. text > attachments), this surely fixes the specific case I reported, > but I wonder whether other cases could exist? > (it's meant to be a normal question - I just don't know) We can never be truly sure of anything except our own existence. As far as I can tell, only two bits of code in lavf can export AVMEDIA_TYPE_ATTACHMENT: apetag and matroskadec. apetag does not set codec id at all, while matroskadec will now only export codec ids that do not (and most likely will not) have decoders: fonts and generic binary data. So after this patch, to the best of my knowledge, there should never be a case where an AVMEDIA_TYPE_ATTACHMENT stream has a decodable codec id. Then again this does not exclude all possible cases of a mismatch between a stream's codec type and id. Overall I'd say this just strengthens the case for my original lavc commit, since it is clearly helpful in exposing bugs in other code. > Here's another thought that might be worth consideration: > What turned this from a minor into a major issue (from my pov), > is that it is causing ffprobe to fail and exit with error > and incomplete output. > What I'm wondering about in this context, is whether it > even has to be like that? > > I mean, an unknown codec doesn't cause ffprobe to error-exit, > does it need to do so when avcodec_open2() returns error? > > I would find that behavior ok and consistent when the same > would happen when running ffmpeg (ffprobe fails <=> ffmpeg fails). > But ffmpeg doesn't fail (unless you use the stream), so does > ffprobe even need to fail in these cases? I suppose it can make sense to log an error and continue when opening the codec fails. This could be useful also for probing genuinely broken streams where e.g. extradata parsing fails. There could also be an option like ffmpeg's -xerror that would make ffprobe exit on failure. -- 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".