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

[Soft Works]

> -----Original Message-----
> From: Soft Works
> Sent: Wednesday, June 8, 2022 1:30 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: RE: [FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain
> attachments to AV_CODEC_ID_TEXT
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Anton
> > Khirnov
> > Sent: Wednesday, June 8, 2022 10:05 AM
> > To: FFmpeg development discussions and patches <ffmpeg-devel at 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".
> >
> > 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.
> 
Just to clarify:
 
 - it's the other way round:
   - currently it is "text"
   - after the patch it becomes "none"


BEFORE:

  Stream #0:9: Attachment: text
    Metadata:
      filename        : ...
      mimetype        : text/plain


AFTER:

  Stream #0:9: Attachment: none
    Metadata:
      filename        : ...
      mimetype        : text/plain



It also affects ffmpeg stream information output.