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

Michael Niedermayer michaelni
Sun Jan 20 21:37:30 CET 2008

On Sun, Jan 20, 2008 at 09:34:56PM +0200, ods15 at ods15.dyndns.org wrote:
> On Sun, Jan 20, 2008 at 04:05:21PM +0000, M?ns Rullg?rd wrote:
> > [...]
> I'm a bit late in the thread, but it sounds to me like the "ideal" system 
> would be:
> codec id: an enum, extracting the maximum amount of information from the 
> container codec tag, to identify the codec. This would mean you would have 
> several codec id's for xvid/divx4/divx5/whatever - but only for ones 
> where it would be useful! If for example "div5" and "xvid" have 
> absoloutely no difference in decoding workarounds, they should have the 
> same codec id.
> This would be the only useful value for doing playback, and if the codec 
> tag could not be identified to a codec id, then that means that there 
> probably isn't a decoder for this file anyway. However, codec id should be 
> user-forcable.

well, that is surely possible ...
though you would need quite a few dummy decoders to handle the ids
if people agree that they want that we surely could add these 10-15
dummy codec_ids
also what codec_id would cou give the 2 h264 HDDVD / mpeg1/2 ids
they would have to be distinct from MPEGVIDEO and H264. And which
codec should decode it? mans wants mpeg1/2 because the spec says so
everyone else wants h.264 because it is h.264 in practice

> codec-tag -> codec-id tables should be container dependent, and not some 
> huge table for everything (this could mean anything in actual 
> implementation, it can still be a shared table, but the design is this...)

see AVCodecTag and AVIn/OutputFormat.codec_tag

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- 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/1189d522/attachment.pgp>

More information about the ffmpeg-devel mailing list