[Matroska-devel] Re: Dirac Video Codec
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:
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
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.
ICQ - xmpp://firstname.lastname@example.org xmpp://email@example.com
http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Arioch<at>nm<dot>ru
More information about the Matroska-devel