[Matroska-devel] [Fwd: Re: Dirac mapping for Matroska]

[David Flynn]

On 2008-06-29, Steve Lhomme <slhomme at matroska.org> wrote:
> Sebastian Dröge wrote:
>> - A Matroska block/lace contains all Dirac packets up to and
>>   including a picture. This means, all padding, maybe a sequence
>>   header and maybe auxiliary data and then the picture for which
>>   all this previous data was. This makes demuxing much easier
>>   and prevents broken streams created by a muxer or demuxer.
> I liked the previous proposal better. Is there a reason why you to store 
> metadata in the "playback blocks" ? Only data needed for decoding should 
> be put in a cluster. There is room for plenty of metadata elsewhere 
> (tracks, tags, chapters and more can be added if necessary). Does it 
> also include padding ???

Our general desire for a wrapping format is to provide muxing, substream
sync (eg, a/v), seeking, metadata and optionally end-to-end sync (eg, PCR
in mpegts).  What isn't really required is messing about with the
elementary stream itself.

There is no carraige of 'nonessential' metadata in a dirac elementary
stream.  A sequence header is essential.

Duplicating essential parameters contained in the sequence header
into well defined aspects of the wrapper's metadata structures is fine.
Eg, frame width, height, physical aspect ratio, sample aspect ratio,
frame rates, colour space, etc.,

If your experience is that decoders rely on some of this information
being in the wrapper, then by all means mandate duplicating it.

Things like copyright statements, authors, titles, etc., all belong with
the wrapper.  I'd even go so far to say timecodes belong there too -- as
long as they have a good definition.

However striping things out of the elementary stream (even padding data)
isn't a good idea.  If it is in the elementary stream, the coder has a
pretty good reason for it being there.  Temporal ordering of the data is
important, so hiding parts of it in private data sections and expecting
a demuxer to get it right when reconstructing it all just sounds like a
severe ammount of extra work.

Put slightly differently:

The only point we can give you guarantees on decodeability is when a
sequence header occurs.  It isn't wise to assume that any old 'I'frame
could have a sequence header (that has been stashed away somewhere in
the wrapper) inserted infront of it to make it into some form of random
access point.

> You mean it's as close to the original as possible. Except it doesn't 
> take of matroska to store the data in the appropriate place. Using VfW 
> will give the same (bad) result.

Please could you elaborate on 'appropriate place' and what the bad
result is?