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

[Steve Lhomme]

David Flynn wrote:
> 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.

I agree the elementary stream should keep all the information it needs, 
regardless of the container. If this is what you propose, then it's 
fine. I just had the impression that a lot more stuff was stored in such 
matroska blocks, where they don't belong.

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

Again, this is about all data that are not necessary for playback, that 
I don't want to end up in the blocks. If this is the case, then it's fine.

Steve