[FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain attachments to AV_CODEC_ID_TEXT

[Anton Khirnov]

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