[FFmpeg-devel] [PATCH] attachments support in matroska demuxer

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Sun, Jan 20, 2008 at 04:05:21PM +0000, M?ns Rullg?rd wrote:
>> Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
>> 
>> > Hi
>> >
>> > Michael Niedermayer wrote:
>> >> (not that mpeg-ps/ts and matroska would set codec_tag correctly ...)
>> >
>> > Yes, mpeg-ps should set codec_tag to startcode.
>> 
>> There is no logical value to put there for mpeg-ps.  For mpeg-ts, the
>> codec ID from the PMT would be a natural, albeit pointless, choice.
>> The same value is used in the MPEG-PS PSM when present, but since PSM
>> is optional when only MPEG1/2 video and audio is present, there is no
>> obvious choice for codec_tag.
>> 
>
>> Based on what you say, I have to consider the entire concept of
>> codec_tag flawed.  Since the decoder does not in general (and
>> certainly should not) know what container the data came in, it cannot
>> know how to interpret the value of codec_tag.  
>
> Well fact is, the system is extreemly simple and works extreemly well in
> detecting buggy divx and xvid whithout false detections, at least none an
> alternative system would avoid.

System?  What system?

> And no the demuxer has no knowledgle of the container.
             ^^^^^^^
I assume you meant decoder.

> And hell the whole mplayer uses avi fourccs internally to identify codecs

Well, mplayer is basically an AVI player that also happens to support
a some other formats.  Besides, MPlayer is hardly a good example of
how to do anything whatsoever.

> and mplayer plays many files your program doesnt, it cant as you already
> said you ignore codec_tag which is essential to the playback of many files.

Samples, please.

>> Similarly a muxer, whether transcoding or copying, does not know
>> the source of the codec_tag value, and thus cannot interpret it one
>> way or another.
>
> The user app can set codec_tag to 0 for the muxer
> or set it to a value that is valid for the container, it can do that
> by using the AVCodecTag table from the muxer.

What would be the point in doing that?

> You shouldnt blame the API if the user app sets the codec_tag to a
> value which isnt valid ...

I'm blaming the API for existing in the first place.

>> I feel sorry for all you people who were raised on AVI files.  I
>> really do...
>
> I feel happy for you all who like mpeg with its 3 different ways to
> identify codecs. And then for a dozen cases reuse all ids so the
> streams need analyzing to identify the codec.
>
> (minor snippet of mpeg.c
>     } else if (startcode >= 0x1e0 && startcode <= 0x1ef) {
>         static const unsigned char avs_seqh[4] = { 0, 0, 1, 0xb0 };
>         unsigned char buf[8];
>         get_buffer(s->pb, buf, 8);
>         url_fseek(s->pb, -8, SEEK_CUR);
>         if(!memcmp(buf, avs_seqh, 4) && (buf[6] != 0 || buf[7] != 1))
>             codec_id = CODEC_ID_CAVS;
>         else
>             codec_id = CODEC_ID_MPEG2VIDEO;
>         type = CODEC_TYPE_VIDEO;

It's not the fault of MPEG that the Chinese chose to ignore the spec.

>     } else if (startcode >= 0x1c0 && startcode <= 0x1df) {
>         type = CODEC_TYPE_AUDIO;
>         codec_id = m->sofdec > 0 ? CODEC_ID_ADPCM_ADX : CODEC_ID_MP2;

It's not the fault of MPEG that whoever is behind ADX chose to ignore
the spec.

> avi doesnt have such entertaining identifer system, but uses boring 4 
> character codes with some similarity to the codec name and suprisingly
> that anarchistic system is free of colissions while the great mpeg
> is full of collisions.

Well, with AVI the problem is the opposite.  Every codec has a zillion
different identifiers.  This is because of fundamental misconceptions
in the way AVI and VFW were originally conceived.  I've discussed
these at length in the past, and I don't feel inclined to repeat it
all again.

-- 
M?ns Rullg?rd
mans at mansr.com