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 296AB42DCF for ; Wed, 8 Jun 2022 08:04:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6485768B688; Wed, 8 Jun 2022 11:04:56 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 07AB668B440 for ; Wed, 8 Jun 2022 11:04:50 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 45979240175 for ; Wed, 8 Jun 2022 10:04:49 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 9K0dJP8IGnJa for ; Wed, 8 Jun 2022 10:04:48 +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 41C6F2400F5 for ; Wed, 8 Jun 2022 10:04:48 +0200 (CEST) Received: by lain.khirnov.net (Postfix, from userid 1000) id 62E991601B2; Wed, 8 Jun 2022 10:04:48 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB0365F95C1E9F2C9C4222BDF6BAA49=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?= <165466902879.5088.14253593912707356675@lain.khirnov.net> =?utf-8?q?=3CDM8P?= =?utf-8?q?223MB036505AC3D4B249D6F66F803BAA49=40DM8P223MB0365=2ENAMP223=2EPR?= =?utf-8?q?OD=2EOUTLOOK=2ECOM=3E?= <165467214169.13099.10591659789295187077@lain> =?utf-8?q?=3CDM8P223MB0365F9?= =?utf-8?q?5C1E9F2C9C4222BDF6BAA49=40DM8P223MB0365=2ENAMP223=2EPROD=2EOUTLOO?= =?utf-8?q?K=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Wed, 08 Jun 2022 10:04:48 +0200 Message-ID: <165467548837.5088.14494376448659698736@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 09:43:19) > > Do we need to do anything about it? I am not a fan of inventing fake > > codec ids for every conceivable kind of data. lavf already exports the > > MIME type, that should be enough. Maybe the way it is printed can be > > improved, but that is not urgent as far as I'm concerned. > > ffprobe provides multiple output formats which are intended to be machine- > readable (e.g. xml, json). > If it was just about interactive reading by a user, then it might > in fact not matter that much. But for a machine, it was "text" and the patch > changes it to "none". When we add a new codec ID, what was previously "none" changes to an actual codec name. Users for whom any change at all is a problem should simply not update their binaries. > > > I am not a fan of inventing fake > > codec ids for every conceivable kind of data. > > This surely makes sense from a larger perspective, but when such fake ids are > already being used, then it doesn't matter how many. 5 or 6 - 33 or 34 - that > doesn't have relevant impact. At one point in the future, we might get rid of > them for something better, but - again - the count won't be of much relevance. I disagree. The more of them we add, the harder it becomes to remove them. My points are - the relevant information is already available in mimetype, adding a fake codec id does not give you anything new - there is an effectively unlimited number of such codec ids, it would be absurd to add them all - codec ids are meant to identify different kinds of data that can be handled by libavcodec; the data in question here is outside the scope of libavcodec, therefore it should not have a codec id > > > > 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. > > > > > > Sounds good to me, but I'm not sure whether everybody would be ok > > > doing it exactly like this, as somebody might argue they would rely > > > on ffprobe failing in such cases. > > > I can submit a patch for that - unless no objections or better ideas > > > would appear.. > > > > https://xkcd.com/1172/ > > I don't think it's absurd, neither hypothetical to ask whether somebody, > would object a certain change --- BEFORE working spending time on it. It does makes sense to consider it, but at some point you have to accept that ANY change you make can possibly break somebody's use case. So being overly considerate means no useful development gets done. -- 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".