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

[Michael Niedermayer]

On Tue, Jan 01, 2008 at 01:17:57PM +0300, Evgeniy Stepanov wrote:
> On 12/31/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > such data belongs in AVCodecContext.extradata/extradata_size
> 
> They are not related to any stream. 

Then no stream needs them per definition, and they can be droped.


> Should I add a fake stream with
> attachments as extradata ? 

this does not sound reasonable ...


> Or even as data packets, since there could
> be a lot of them.

The awnser depends on random access issues.
Lets assume we have a stream (could be audio,video or subtitles).
The API (as well as most containers) gives you 2 things
1. extradata
2. packets

data packets can be keyframes or non keyframes
one requirement is that you can start decoding from a keyframe + extradata
that is without having ever seen, or having any means to see previous packets.
so if the attachments are not globally needed then maybe packets are
approproiate. If they are global you would have to duplicate them in front of
every keyframe.

as far as i understand matroska attachments, they are a mere duplication of
extradata. It seems everyone thinks the codec or container they designed has
special needs outside what already exists. Completely missing that the problem
if one exists at all really applies to all codecs. And then goes on designing
a new fancy solution not really solving anything ... other codecs store their
huffman tables, vector quantizer tables, quantization tables, ... in extradata
or before every keyframe. Fonts for subtitles are not different from other
tables needed for decoding streams.

If theres a problem with size of the fonts, maybe the designers of the
codec (ASS/SAA here) should have spend more time thinking about the format
in which fonts are stored, or
have a minimum required set of fonts which every decoder must contain and
which thus become unneeded to be stored in videos. Or even store fonts in
files seperate of the videos.

The only way to see fonts as special relative to global data (=extradata)
would be if one argues that a subtitle decoder outputs UTF-8 + position
+ font name + color + size + ...
in that case fonts would be an rendering hint but unneeded for decoding
the subtitle stream (as the decoder doesnt output bitmaps ...). 
the problem here is that this is not how subtitles
are currently implemented in libavcodec so if you want to pursue this
direction you would first need to extend the existing subtitle handling
to output such textual rendering info instead of bitmaps.

anyway comments welcome!
but most important is that we need generic solutions, not something which
can only be used with mkv-ass (= no hacks)

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- 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/20080101/68ea524a/attachment.pgp>