[Matroska-devel] Re: Element order in EBML/libebml

Cyrius suiryc at yahoo.com
Fri Oct 17 17:23:02 CEST 2003


--- Pamel <paul at msn.com> wrote:
> You could still edit them because you would be able
> to tell what frames were
> still needed by references.  Reorganizing the frames
> for a specific codec type
> should be fine, as long as you are ABLE to.
Yeah true I forgot the references. This indeed allow
to edit the file without having to know about the
codec ^^; (my error)
However even if you are able to know which frames you
have to keep, that doesn't help with codecs that need
to decode frames in a certain order (nowadays I think
that means all the codecs ;)). So in this case if
there is a problem with ordering then applications
would be unable to serve data in the correct order to
the codec, meaning that till now we were really lucky
that Matroska files play correctly :P

> > Last but not least. Let's consider why a new
> ordering
> > element (KaxContentEncoding) has been asked :
> > > Bad!  Order sensitive data is a nono in EBML.
> > I don't think that's really true. Ebml by itself
> > introduce order (when you read an EBML stream,
> > elements have been written in a certain order).
> 
> Right, its was my booboo.
:) yup, anyway the problem I talked about mainly
concerns libebml and the Matroska specs, not EBML by itself.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com



More information about the Matroska-devel mailing list