[FFmpeg-devel] [PATCH] Make a clear distinction between an unsupported codec and an unknown one

[Robert Swain]

2008/8/31 Peter Ross <pross at xvid.org>:
> On Sun, Aug 31, 2008 at 12:53:34PM +0200, Michael Niedermayer wrote:
>> On Sun, Aug 31, 2008 at 06:56:48AM +0200, Vitor Sessak wrote:
>> > See $subj. I got pretty confused by "Stream #0.1: Audio: 0x0000, 5512 Hz,
>> > mono, s16" meaning that a codec is known, but unsupported...
>> >
>> > -Vitor
>>
>> > Index: libavcodec/utils.c
>> > ===================================================================
>> > --- libavcodec/utils.c      (revision 15050)
>> > +++ libavcodec/utils.c      (working copy)
>> > @@ -1091,8 +1091,12 @@
>> >                       (enc->codec_tag >> 16) & 0xff,
>> >                       (enc->codec_tag >> 24) & 0xff,
>> >                        enc->codec_tag);
>> > +        } else if (enc->codec_id) {
>> > +            snprintf(buf1, sizeof(buf1), "unsuported (id 0x%04x)", enc->codec_id);
>> > +        } else if (enc->codec_tag) {
>> > +            snprintf(buf1, sizeof(buf1), "unknown (0x%04x)", enc->codec_tag);
>> >          } else {
>> > -            snprintf(buf1, sizeof(buf1), "0x%04x", enc->codec_tag);
>> > +            snprintf(buf1, sizeof(buf1), "unknown");
>> >          }
>>
>> I think this is inconsistant now
>> Before it just printed the tag now it prints the tag when its
>> printable, if not and codec_id is not 0 the id and if not and
>> id is 0 and the tag is not 0 the tag and ...
>> Printing the ID in addition to the tag and "NONE" instead of
>> 0x0000 or so seems more consistent to me
>
> An enhancement to the unsupported case would be to actually print
> the name of the codec. e.g. i am always forgetting which 0x16X
> twocc refers to wmav3.

Indeed. In my opinion it should print the codec name if possible and
if the codec is unsupported maybe state such in brackets afterwards.
If the codec is not known, then printing that is useful information as
I guess it means the file is broken, one of demuxers/parsers isn't
quite correct for this particular file, the codec is actually one of
which we do not yet know.

I don't about the consistency of this suggestion, but I think it is
the most useful. If a codec is unsupported, it is useful to see in
some human-readable form what the 'unsupported' codec is to check
whether an external library is needed for the moment.

I suppose ideally if a codec is known and support is available via an
external library against which these FFmpeg libraries are not built
then printing the missing codec/library would be most direct.

Regards,
Rob