[www] r1086 - trunk/www.matroska.org/data/technical/specs

Author: robux4
Date: 2006-06-25 18:07:55 +0400 (Sun, 25 Jun 2006)
New Revision: 1086

Modified:
   trunk/www.matroska.org/data/technical/specs/index.html
Log:
Add EncryptedBlock (version2 for the moment until fully accepted)

Modified: trunk/www.matroska.org/data/technical/specs/index.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/www.matroska.org/data/technical/specs/index.html	2006-06-03 19:=
42:36 UTC (rev 1085)
+++ trunk/www.matroska.org/data/technical/specs/index.html	2006-06-25 14:=
07:55 UTC (rev 1086)
@@ -829,6 +829,17 @@
   <td>binary (see <a href=3D"#simpleblock_structure">SimpleBlock Structu=
re</a>)</td>
   <td>Similar to <a href=3D"#Block">Block</a> but without all the extra =
information, mostly used to reduced overhead when no extra feature is nee=
ded.</td>
 </tr>
+<tr class=3D"version2" id=3D"EncryptedBlock">
+  <td>EncryptedBlock</td>
+  <td>2</td>
+  <td>[AF]</td>
+  <td>-</td>
+  <td>*</td>
+  <td>-</td>
+  <td>-</td>
+  <td>binary (see <a href=3D"#encryptedblock_structure">EncryptedBlock S=
tructure</a>)</td>
+  <td>Similar to <a href=3D"#SimpleBlock">SimpleBlock</a> but the data i=
nside the Block are Transformed (encrypt and/or signed).</td>
+</tr>
 <tr id=3D"Track">
   <th colspan=3D"9">Track</th>
 </tr>
@@ -1475,9 +1486,10 @@
   <td>1</td>
   <td>u-integer</td>
   <td>A bit field that describes which elements have been modified in
-  this way. Values can be OR'ed. Possible values:<br/>
+  this way. Values (big endian) can be OR'ed. Possible values:<br/>
   1 - all frame contents,<br/>
-  2 - the track's private data</td>
+  2 - the track's private data,<br/>
+  4 - the next ContentEncoding (next ContentEncodingOrder. Either the da=
ta inside ContentCompression and/or ContentEncryption)</td>
 </tr>
 <tr id=3D"ContentEncodingType">
   <td>ContentEncodingType</td>
@@ -1488,7 +1500,7 @@
   <td>-</td>
   <td>0</td>
   <td>u-integer</td>
-  <td>A value describing what kind of modification has been
+  <td>A value describing what kind of transformation has been
   done. Possible values:<br/>
   0 - compression,<br/>
   1 - encryption</td>
@@ -2467,7 +2479,8 @@
 <tr><th colspan=3D"3">Lace (when lacing bit is set)</th></tr>
 <tr><td>0x00</td><td>must</td><td>Number of frames in the lace-1 (uint8)=
</td></tr>
 <tr><td>0x01 / 0xXX</td><td>must*</td><td>Lace-coded size of each frame =
of the lace, except for the last one (multiple uint8). *This is not used =
with Fixed-size lacing as it is calculated automatically from (total size=
 of lace) / (number of frames in lace).</td></tr>
-<tr><td>-</td><td>must</td><td>Consecutive laced frames</td></tr>
+<tr><th colspan=3D"3">(possibly) Laced Data</th></tr>
+<tr><td>0x00</td><td>must</td><td>Consecutive laced frames</td></tr>
 </tbody></table></div>
=20
=20
@@ -2541,7 +2554,7 @@
=20
 <div>
 <h4 id=3D"simpleblock_structure">SimpleBlock Structure</h4>
-<p>The SimpleBlock is very inspired by the <a href=3D"simpleblock_struct=
ure">Block structure</a>. The main differences are the added Keyframe fla=
g and Discardable flag. Otherwise everything is the same.</p>
+<p>The SimpleBlock is very inspired by the <a href=3D"#block_structure">=
Block structure</a>. The main differences are the added Keyframe flag and=
 Discardable flag. Otherwise everything is the same.</p>
 <p>Size =3D 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets.</p=
>
 <p>Bit 0 is the most significant bit.</p>
 <p>Frames using references should be stored in &quot;coding order&quot;.=
 That means the references first and then the frames referencing them. A =
consequence is that timecodes may not be consecutive. But a frame with a =
past timecode must reference a frame already known, otherwise it's consid=
ered bad/void.</p>
@@ -2576,11 +2589,57 @@
 <tr><th colspan=3D"3">Lace (when lacing bit is set)</th></tr>
 <tr><td>0x00</td><td>must</td><td>Number of frames in the lace-1 (uint8)=
</td></tr>
 <tr><td>0x01 / 0xXX</td><td>must*</td><td>Lace-coded size of each frame =
of the lace, except for the last one (multiple uint8). *This is not used =
with Fixed-size lacing as it is calculated automatically from (total size=
 of lace) / (number of frames in lace).</td></tr>
-<tr><td>-</td><td>must</td><td>Consecutive laced frames</td></tr>
+<tr><th colspan=3D"3">(possibly) Laced Data</th></tr>
+<tr><td>0x00</td><td>must</td><td>Consecutive laced frames</td></tr>
 </tbody></table></div>
 </div>
=20
 <div class=3D"version2">
+<h4 id=3D"encryptedblock_structure">EncryptedBlock Structure</h4>
+<p>The EncryptedBlock is very inspired by the <a href=3D"#simpleblock_st=
ructure">SimpleBlock structure</a>. The main differences is that the raw =
data are Transformed. That means the data after the lacing definition (if=
 present) have been processed before put into the Block. The laced sizes =
apply on the decoded (Inverse Transform) data. This size of the Transform=
ed data may not match the size of the initial chunk of data.</p>
+<p>The other difference is that the number of frames in the lace are not=
 saved if "no lacing" is specified (bits 5 and 6 set to 0).</p>
+<p>The Transformation is specified by a TransformID in the Block (must b=
e the same for all frames within the EncryptedBlock).</p>
+<p>Size =3D 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets.</p=
>
+<p>Bit 0 is the most significant bit.</p>
+<p>Frames using references should be stored in &quot;coding order&quot;.=
 That means the references first and then the frames referencing them. A =
consequence is that timecodes may not be consecutive. But a frame with a =
past timecode must reference a frame already known, otherwise it's consid=
ered bad/void.</p>
+<p>There can be many Blocks in a BlockGroup provided they all have the s=
ame timecode. It is used with different parts of a frame with different p=
riorities.</p>
+<div class=3D"techdef">
+<table>
+<tbody><tr><th colspan=3D"3">EncryptedBlock Header</th></tr>
+<tr><th>Offset</th><th>Player</th><th>Description</th></tr>
+<tr><td>0x00+</td><td>must</td><td id=3D"Block_Track">Track Number (Trac=
k Entry). It is coded in EBML like form (1 octet if the value is &lt; 0x8=
0, 2 if &lt; 0x4000, etc) (most significant bits set to increase the rang=
e).</td></tr>
+<tr><td>0x01+</td><td>must</td><td id=3D"Block_Timecode">Timecode (relat=
ive to Cluster timecode, signed int16)</td></tr>
+<tr><td>0x03+</td><td>-</td><td>
+ <table border=3D"1">
+ <tbody><tr><th colspan=3D"3">Flags</th></tr>
+ <tr><th>Bit</th><th>Player</th><th>Description</th></tr>
+ <tr><td>0</td><td>-</td><td>Keyframe, set when the Block contains only =
keyframes</td></tr>
+ <tr><td>1-3</td><td>-</td><td>Reserved, set to 0</td></tr>
+ <tr><td>4</td><td>-</td><td>Invisible, the codec should decode this fra=
me but not display it</td></tr>
+ <tr><td>5-6</td><td>must</td><td>Lacing<ul>
+
+ <li>00 : no lacing</li>
+
+ <li>01 : Xiph lacing</li>
+
+ <li>11 : EBML lacing</li>
+
+ <li>10 : fixed-size lacing</li>
+
+ </ul></td></tr>
+ <tr><td>7</td><td>-</td><td>Discardable, the frames of the Block can be=
 discarded during playing if needed</td></tr>
+ </tbody></table>
+</td></tr>
+<tr><th colspan=3D"3">Lace (when lacing bit is set)</th></tr>
+<tr><td>0x00</td><td>must*</td><td>Number of frames in the lace-1 (uint8=
) *Only available if bit 5 or bit 6 of the EncryptedBlock flag is set to =
one.</td></tr>
+<tr><td>0x01 / 0xXX</td><td>must*</td><td>Lace-coded size of each frame =
of the lace, except for the last one (multiple uint8). *This is not used =
with Fixed-size lacing as it is calculated automatically from (total size=
 of lace) / (number of frames in lace).</td></tr>
+<tr><th colspan=3D"3">(possibly) Laced Data</th></tr>
+<tr><td>0x00</td><td>must</td><td>TransformID (EBML coded integer value)=
. Value 0 =3D Null Transform</td></tr>
+<tr><td>0x01+</td><td>must</td><td>Consecutive laced frames</td></tr>
+</tbody></table></div>
+</div>
+
+<div class=3D"version2">
 <h4 id=3D"block_virtual">Virtual Block</h4>
 <p>The data in matroska is stored in coding order. But that means if you=
 seek to a particular point and a frame has been referenced far away, you=
 won't know while playing and you might miss this frame (true for indepen=
dent frames and overlapping of dependent frames). So the idea is to have =
a placeholder for the original frame in the timecode (display) order.</p>
 <p>The structure is a scaled down version of the normal <a href=3D"#bloc=
k">Block</a>.</p>