[Matroska-devel] Element order in EBML/libebml

Steve Lhomme steve.lhomme at free.fr
Fri Oct 17 19:58:06 CEST 2003


Cyrius wrote:
>>But that's a
>>problem for hardware 
>>players that can't reorder frames easily (BTW, it
>>has always been said 
>>that a Cluster should be held full in memory)...
> 
> So in this case libebml/EBML doesn't guarantee the
> order of the data, and thus nobody can tell for sure
> that data will be send in correct order to the codec.
> So actually when we write a Matroska file we don't
> know if the codec will be able to decode the data we
> would send (in an unpredictible order), and if the
> file will be playable.

No, because you forget one part. For example the MPEG4 native matroska 
stream is in coding order. But we don't assume ALL MPEG4 decoder uses 
this order. That's the job of the link between the matroska reader and 
the codec to please everyone.

But where you are right is that the coding order is defined. But it's 
not enforced. Unless we can find a way to do so. Maybe adding a Block 
Order number to each BlockGroup ? But in general (at least in my mind) 
the order of elements is never assumed.

Also for files produced with other players, the order of the mandatory 
elements doesn't matter, as on reading we erase all of them prior to 
reading.




More information about the Matroska-devel mailing list