[Matroska-devel] Re: Dirac Video Codec

Arioch /BDV/ the_Arioch at nm.ru
Mon Oct 4 10:56:42 CEST 2004


The stars so gaily glistened... (Fri, 1 Oct 2004 11:20:40 -0500 @722)
...while the fading voice of Paul whispered through the darkness:

[Sorry, skipped] 
 PB> As he says, it is very useful to have as much data as possible
 PB> available at the container level for authoring purposes.  This is part 
 PB> of the philosophy of Matroska.

I guess what is file size overhead here, comparing to plain MPEG or OGG or even AVI

[Sorry, skipped] 

 PB> in a Matroska file, the next audio and video packets to be found will
 PB> have timecodes.  Instead of the application having to guess at the
 PB> timing of the packets relative to each other, it can instead know for

In other words, each packet is having non-relative timecode, which is again longer than relative timecode with shorter value?
Or if it is relative - then application seems to meet almost the same troubles.

If i got it, in MKV timestamps are relative to upper EBML block, so within one block, all sub-blocks might be taken as they were absolutely stamped, but will this upper-level block be damaged, then all sub-blocks inside will lost its timestamps (read: sync) ?

So in desync is not eliminated, it is just more varied in severity of damage after the random place, where the file was corrupt.

[Sorry, skipped] 


-- 
ICQ - xmpp://arioch@jabber.ru  xmpp://93438391@icq.jabber.ru
http://Arioch.nm.ru/FL/Fidolook_SL.png    Mail: the_Arioch<at>nm<dot>ru


More information about the Matroska-devel mailing list