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

[Michael Niedermayer]

On Sun, Jan 20, 2008 at 06:35:58PM +0000, M?ns Rullg?rd wrote:
[...]

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

yes


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

try http://samples.mplayerhq.hu/V-codecs/UMP4/clip10-640x480-550k.avi
it should look better with properly set codec_tag

any fourcc=XVIX avi will work as well and show a much bigger difference but
it seems theres none on mphq at least not where it should be ...
and i cant find one on my disk either ...

or old xvid like:
87fa4caf85a38d2151f4fcae6848723b  green.avi (dunno if its on mphq still or
deleted by BOFH)

anyway just try old divx/xvid with no divx/xvid build id in the stream many
will show artifacts if the fourcc isnt passed to the decoder
id search the server for you if i had a account but i wont download all files
to find out if there are any left which havnt been "deleted because they work
now" or whatever the excuse ...


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

well, some hardware players only support some codec_tags, if you choose
the wrong one it simply wont play
And as said above the codec_tag is critical to decoding some old xvid/divx
xvix/ump4 and likely others, so it has to be preserved on stream copy


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

You are really becoming annoying, i can accept that you dont like avi
and prefer mpeg, that all fine but you should aceppt that there are people
who like to be able to watch their files. codec_tag is needed for that.
And irronically it would also solve the hddvd h264 problem with mpeg


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

its not the fault of the AVI spec that random people ignore it


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

I just an hour ago wanted to add proper AVCodecTag tables to mpeg, guess why
i didnt? Because mpeg has ten times more redundant identifers.
but lets just see the code:
    } else if (startcode >= 0x1e0 && startcode <= 0x1ef) {
....
    } else if (startcode >= 0x1c0 && startcode <= 0x1df) {
....
    } else if (startcode >= 0x80 && startcode <= 0x87) {
....
    } else if ((startcode >= 0x88 && startcode <= 0x8f)
....
    } else if (startcode >= 0xa0 && startcode <= 0xaf) {
        type = CODEC_TYPE_AUDIO;
        codec_id = CODEC_ID_PCM_S16BE;
    } else if (startcode >= 0xb0 && startcode <= 0xbf) {
        type = CODEC_TYPE_AUDIO;
        codec_id = CODEC_ID_MLP;
    } else if (startcode >= 0xc0 && startcode <= 0xcf) {
        /* Used for both AC-3 and E-AC-3 in EVOB files */
        type = CODEC_TYPE_AUDIO;
        codec_id = CODEC_ID_AC3;
    } else if (startcode >= 0x20 && startcode <= 0x3f) {
        type = CODEC_TYPE_SUBTITLE;
        codec_id = CODEC_ID_DVD_SUBTITLE;
    } else if (startcode >= 0xfd55 && startcode <= 0xfd5f) {

why has every codec such a huge range?!

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080120/3a9f6bd8/attachment.pgp>