Re: [FFmpeg-devel] [PATCH 1/8] lavc/avcodec: simplify codec id/type validity checking

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Anton
> Khirnov
> Sent: Sunday, June 5, 2022 9:01 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/8] lavc/avcodec: simplify codec id/type
> validity checking
> 
> Quoting Soft Works (2022-06-05 07:23:18)
> > This is causing a regression in ffprobe.
> >
> > The commit removes the special-case check for AVMEDIA_TYPE_ATTACHMENT which
> > was required for ffprobe and had been added with
> e83c716e16c52fa56a78274408f7628e5dc719da.
> >
> > The demand from the commit message is not yet guaranteed to be fulfilled:
> >
> > > On entry to avcodec_open2(), the type and id either have to be
> > > UNKNOWN/NONE or have to match the codec to be used.
> >
> > I have one verified example (maybe a second will follow), which is an MKV
> with
> > an attachment "stream" of type "text".
> > The found codec will be textdec of type 'subtitle' even though the stream
> type
> > is attachment. Without the special condition for attachment streams, this
> > is now causing ffprobe to error out with non-zero exit code and incomplete
> > output.
> >
> >
> > ------------------------------------------------------------------------
> > Example:
> >
> >   [...]
> >   Stream #0:9: Attachment: text
> >     Metadata:
> >       filename        : textfile.text
> >       mimetype        : text/plain
> > [text @ 000001AC32310340] Codec type or id mismatches
> > Could not open codec for input stream 9
> > ------------------------------------------------------------------------
> 
> This sounds very much like a bug in ffprobe. It makes no sense to call
> avcodec_open2() with the AVMEDIA_TYPE_ATTACHMENT type.

You make a behavioral change to an API function that had this behavior 
established and constant over more than 10 years, and when that change 
breaks functionality, it's the callers' fault?
How does this go together with all that peanut counting of major, minor
and micro version numbers per library? What is this versioning good for,
when you can make breaking changes and declare the breakage as bugs?


Though, I don't want to say that your change is wrong or shouldn't be made. 
Yet, the change requires ffprobe to be adjusted (I just wouldn't call 
it a "bug fix"..)

Thanks,
softworkz
_______________________________________________
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".