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

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Anton
> Khirnov
> Sent: Wednesday, June 8, 2022 10:05 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain
> attachments to AV_CODEC_ID_TEXT
> 
> 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".
> 
> 
> >
> > > 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

When it's your plan way to eliminate the others at some time soon, then it
would make sense to me of course. 



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

I very much agree to this. But I'm wondering how this can go together 
with versioning the code by 24 different numbers (8 libs * 3 integers).
Even when you make a change that is undoubtedly correct and justified and 
right - when it changes behavior it breaks compatibility, even when the
previous behavior was totally bad and wrong.

Once you leave that path and replace it by some "custom" judgement with regards
to what's compatible and what's breaking and consider a change to be non-breaking 
because it changes only "illegitimate" behavior, it's still a breaking and 
incompatible change. 
When it's not possible to rely on a precise and strict compatibility based 
on these version numbers with major, minor and micro for every single lib,
and you say - nevermind, every change will break something, what are all
those numbers for? They would be pointless, wouldn't they?

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

How should those users know when the library version numbering doesn't 
indicate that breaking change?


Thanks,
sw










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