で、とりあえず、lacingというのがわかりにくかった。
matroskaでは、EBMLに従ったデータを扱うことで、容量を節約しています。
http://matroska.org/technical/specs/index.html#EBML_ex
データを表現するときに、始めのビットがでてくる部分で、データ長がきまるみたいな感じです。
たとえば、5を表現する場合はビットにすると
0000 0101
１バイトで表現できるので、始めのビットを初っ端にいれてやって
1000 0101→16進数にすると0x85となります。
800を表現する場合、ビットにすると
0000 0011 0010 0000となります。
2ビット必要になるので・・・
0100 0011 0010 0000→16進数で0x4320となります。
matroskaでは、各データはmp4みたいにelementという単位で取り扱いします。
http://matroska.org/technical/specs/index.html#LevelEBML
[タグ][データの長さ][データ]という構成でできています。
タグはEBMLでつくられたデータで1バイト〜4バイトでできています。
データの長さは、1バイト〜8バイトでできているEBMLで表現した数値になっています。
データの部分は各タグ次第という感じです。
とりあえずCodecPrivateの中にFlvでいうところのMediaSequenceHeaderのデータがあったこと。
BlockもしくはSimpleBlockの中に各データが入っていること。
Seek関連の部分が、Segmentの中の各要素の位置情報がはいっていることを確認してあります。
で、問題の中身で注意しないといけなさそうなのは・・・
１：Seek関連のSeekPositionのデータの中身ですが、数値でSegment領域の内容データの先頭からの相対位置で格納されているみたいです。
[タグ][サイズ][データ....]のデータの始まりの位置からの相対位置です。
２：BlockとSimpleBlockにあるLaceについて
http://matroska.org/technical/specs/index.html#lacing
読んでもはじめなんのこっちゃわかりませんでした。
とりあえずサンプルデータ
まずlacingというのは、ブロックにいれるにしては、データが細かすぎて何度もブロックをつくるのはもったいないというときに利用します。
１つのブロックの中に複数のデータがはいっているという状況を作り出します。
まずタグの部分、先頭の0xA1がそうです。これはBlockの方です。
続く0x4ADAの部分がデータサイズになります。EBMLの数値なので0x0ADAになります。
続く0x82がトラックIDを示しています。これもEBMLの数値なので0x02になります。
このデータでは、Track:0x01がh.264の映像データ Track:0x02がmp3の音声データになっています。
続く２バイトがこのブロックのtimestamp情報になります。このBlockが含まれているClusterのtimecodeからの差分として、記録されています。
0x0000になっているので、timestampは0になります。この数値はEBMLではないです。
続く0x06の部分が、各種フラグになっています。0x06は0000 0110となりこのBlockがEBMLLacingを利用していることがわかります。
次の0x07の部分がこのブロックが保持しているlacingされているデータの数-1になっています。この数値はEBMLではないみたいです。
7なので、MP3のデータが8個はいっていることになります。
この後の数値7つ(EBML表記)が各lacingされているデータのサイズになっています。
このサンプルの場合は
0x41A1 0x01A1
0x5F97 0x1F97
0xBF 0x3F
0xF3 0x73
0x8B 0x0B
0xF3 0x73
0x8B 0x0B
となっています。
この数値ですが、どうやら始めのデータは単にデータ量なんですが、その後のデータは前のデータとの差分量になっているみたいです。
で、その差分量の計算方法が結構ややこしいです。
まず先頭の0x41A1ですが、EBMLの数値にしたがって、0x01A1が始めのデータになります。
以降のデータですが、各バイトの中間値を０とする数値になるみたいです。
0x5F97に対応する数値は0x1F97
2バイトのデータは0x0000〜0x3FFFですが、中間値は0x1FFFになります。
0x1F97 - 0x1FFF = -0x68が差分になります。
よって0x01A1 - 0x68を計算してやって0x139が次のデータ量になります。
次のデータは0xBF・・・EBMLを解除すると0x3F
１バイトのデータは0x00 〜 0x7Fで中間値は0x3Fになります。
0x3F - 0x3F = 0x00これが差分になるため、0x139が次のデータ量になります。
続くデータは0xF3(0x73)、先ほどと同じく中間値は0x3Fなので
0x73 - 0x3F = +0x34
よって0x139 + 0x34 = 0x16Dがデータ量になります。
こうして計算していくと
0x01A1
0x0139
0x0139
0x016D
0x0139
0x016D
0x016D
0x0139
最後の８個目のデータはこのブロックの残りデータすべてとなります。
0x016D
最後の８個目のデータはこのブロックの残りデータすべてとなります。
0x016D
という風に計算して導きだすことができます。
本来はここまでしなくても、単にffmpegにデータを出力させてwebmのストリーミングするだけならできるのですが・・・
解析に利用しているrtypeDeltaの動画がちょっと壊れているらしく、その原因を知りたいなとおもっているため、回り道しています。(また、可能だったら正しいデータに復元してやって、他のところで利用したいと思っています。)
ちなみに解析に利用しているデータはこちらのr-typeDeltaの動画です。(再生は可能ですが、30分あたりで止まるっぽいです。続きにシークすれば、続きの再生も可能です。
matroskaのデータが壊れているのは確認済みです。)
では、また〜
