From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
	by master.gitmailbox.com (Postfix) with ESMTP id 296AB42DCF
	for <ffmpegdev@gitmailbox.com>; 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 <ffmpeg-devel@ffmpeg.org>; 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 <ffmpeg-devel@ffmpeg.org>; 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 <ffmpeg-devel@ffmpeg.org>;
 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 <ffmpeg-devel@ffmpeg.org>; 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 <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
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
 <ffmpeg-devel@ffmpeg.org>
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 <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/165467548837.5088.14494376448659698736@lain.khirnov.net/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>

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