[Matroska-cvs] [www] r1086 -
trunk/www.matroska.org/data/technical/specs
robux4 at matroska.org
robux4 at matroska.org
Sun Jun 25 16:08:03 CEST 2006
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
===================================================================
--- 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="#simpleblock_structure">SimpleBlock Structure</a>)</td>
<td>Similar to <a href="#Block">Block</a> but without all the extra information, mostly used to reduced overhead when no extra feature is needed.</td>
</tr>
+<tr class="version2" id="EncryptedBlock">
+ <td>EncryptedBlock</td>
+ <td>2</td>
+ <td>[AF]</td>
+ <td>-</td>
+ <td>*</td>
+ <td>-</td>
+ <td>-</td>
+ <td>binary (see <a href="#encryptedblock_structure">EncryptedBlock Structure</a>)</td>
+ <td>Similar to <a href="#SimpleBlock">SimpleBlock</a> but the data inside the Block are Transformed (encrypt and/or signed).</td>
+</tr>
<tr id="Track">
<th colspan="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 data inside ContentCompression and/or ContentEncryption)</td>
</tr>
<tr id="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="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="3">(possibly) Laced Data</th></tr>
+<tr><td>0x00</td><td>must</td><td>Consecutive laced frames</td></tr>
</tbody></table></div>
@@ -2541,7 +2554,7 @@
<div>
<h4 id="simpleblock_structure">SimpleBlock Structure</h4>
-<p>The SimpleBlock is very inspired by the <a href="simpleblock_structure">Block structure</a>. The main differences are the added Keyframe flag and Discardable flag. Otherwise everything is the same.</p>
+<p>The SimpleBlock is very inspired by the <a href="#block_structure">Block structure</a>. The main differences are the added Keyframe flag and Discardable flag. Otherwise everything is the same.</p>
<p>Size = 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 "coding order". 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 considered bad/void.</p>
@@ -2576,11 +2589,57 @@
<tr><th colspan="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="3">(possibly) Laced Data</th></tr>
+<tr><td>0x00</td><td>must</td><td>Consecutive laced frames</td></tr>
</tbody></table></div>
</div>
<div class="version2">
+<h4 id="encryptedblock_structure">EncryptedBlock Structure</h4>
+<p>The EncryptedBlock is very inspired by the <a href="#simpleblock_structure">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 Transformed 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 be the same for all frames within the EncryptedBlock).</p>
+<p>Size = 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 "coding order". 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 considered bad/void.</p>
+<p>There can be many Blocks in a BlockGroup provided they all have the same timecode. It is used with different parts of a frame with different priorities.</p>
+<div class="techdef">
+<table>
+<tbody><tr><th colspan="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="Block_Track">Track Number (Track Entry). It is coded in EBML like form (1 octet if the value is < 0x80, 2 if < 0x4000, etc) (most significant bits set to increase the range).</td></tr>
+<tr><td>0x01+</td><td>must</td><td id="Block_Timecode">Timecode (relative to Cluster timecode, signed int16)</td></tr>
+<tr><td>0x03+</td><td>-</td><td>
+ <table border="1">
+ <tbody><tr><th colspan="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 frame 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="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="3">(possibly) Laced Data</th></tr>
+<tr><td>0x00</td><td>must</td><td>TransformID (EBML coded integer value). Value 0 = Null Transform</td></tr>
+<tr><td>0x01+</td><td>must</td><td>Consecutive laced frames</td></tr>
+</tbody></table></div>
+</div>
+
+<div class="version2">
<h4 id="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 independent 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="#block">Block</a>.</p>
More information about the Matroska-cvs
mailing list