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

Michael Niedermayer michaelni
Sun Jan 20 17:47:22 CET 2008


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.
And no the demuxer has no knowledgle of the container.
And hell the whole mplayer uses avi fourccs internally to identify codecs
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.


> 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.
You shouldnt blame the API if the user app sets the codec_tag to a
value which isnt valid ...


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

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.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/3c075d85/attachment.pgp>



More information about the ffmpeg-devel mailing list