mpegtsについて調査してみます。その２

mpegtsのデータの最小ユニットはトランスポートパケット(tsパケット)という188バイトのデータの連続になっている。

先頭の4バイトは内容が何であるかという記述がはいっているようです。
47 40 11 10
始めの47は固定
次の2バイトのうち下位13ビットがPIDというパケットがなにであるか判別するためのID
この場合は40 11 & 1F FFの結果で0x11になります。
最期の1バイトの下位4ビットが巡回カウンターらしいです。
たぶんそれ以外のビットはランダムではいっているものかなと想像しています。
(これについては、今後のパケットを読み込むときに明らかになるでしょう。)

PIDには固定されているものと、こちら側で自由につけれるものがあるみたいです。
とりあえず固定されているものを列挙しておきます。

PSI(基本情報)
0x0000 PAT 内包しているPID一覧を持たせることでこのtsストリームがどういう情報をもっているのか、わかるようにするものです。本の目次みたいなものですね。
0x0001 CAT 限定受信をサポートする情報を持つ(多分いらない)
SI(拡張情報)
0x0010 NIT チャンネル番号や変調方式、ガードインターバル等、送信するネットワークに関するもの
0x0024 BIT 放送局個別情報(多分いらない)
0x0011 SDT チャンネルの名称(冒頭であげたデータがこれに相当します。)ffmpegなんたらという情報がはいっていました。削除しても問題ないみたいなので、今回たぶん出力しない。
0x0012 EIT 番組の名称や放送日時、放送内容等、番組の内容・・・(多分いらない)
0x0014 TOT 現在の日付、時刻、サマータイム情報(いらないと思う。時間処理にかかわるならでてくるだろうか？)
0x0014 TDT 現在の日付、時刻に関する情報(同上)

こんなところですね。

さて、解析を進めます。
先頭のSDTはとりあえず、無視します。
PATのパケットはすべて47 40 00 1*という形でした。なのでtsファイルを生成するときには、これに準拠します。
間隔はざっとみたところ50パケットずつくらいに挿入されていました。tsファイルの形でTCP転送するので、パケットロスはまぁないことを期待して、tsファイルそれぞれの先頭にいれる程度でもいい気がします。そのあたりはおいおい調整する方向でいきたいとおもいます。
内容は47 40 00 11 [00 00 b0 0d 00 01 c1 00 00 00 01 ef ff 36 90 e2 3d]
こんな感じ
http://nomanganolife.blogspot.jp/2009/12/mpeg2-ts.htmlこちらの図を参考にすると、先頭の00が気に入りませんが
[00]テーブル識別
[b0 0d]([1][011][0000 00001101])
セクションシンタクス指示 1
続く3ビット 011固定
セクション長は0x00d(13バイト)
[00 01]トランスポートストリーム識別 1
[c1]([11][00000][1])
2ビット11固定
バージョン番号5ビット 0
カレントネクスト指示 1
[00]セクション番号
[00]最終セクション番号
ここから含まれるpid情報
[00 01]放送番組番号識別
[ef ff]([111] [01111111111111111])
３ビットの111固定
ネットワークPID 0xFFF(4095番)
最期にこのパケットのCRC情報
[36 90 e2 3d]

というのが延々と続いていました。
番組的には音声と映像がわかれているということはないみたいです。
今後生成するtsファイルも１tsストリームにつき１放送しか扱わないのでこのデータをそのままコピーして成立しそうな予感です。

今後は0xFFF番のトラックにメディアデータが格納されているであろう・・・ということですね。

ここで0xFFF(映像データ)と0x000(PAT)をのぞいたデータをDumpしてみました。
ざっと目についたのが
47 41 00 n*
47 01 00 n*
(nの部分は1,2,3を確認、たぶんなんでもいいのかもしれない。)
という0x100のデータ

47 4101 n*
47 0101 n*
(nの部分は1,3のみ確認、こちらもnは好きな数字でいけるとかな気がする。)
という0x101のデータ

47 1f ff 10
(これはnullパケットと呼ばれる伝送ビットレートの調整用のパケットらしい。内容はffで埋められていました。)
この３つがありました。

0x100と101はいったいなんなんだろうか・・・
一覧化してみたところどうやら0x100が映像パケット0x101が音声パケットっぽいですね。
100側
47 41 00 1*
47 41 00 3*
47 01 00 1*
47 01 00 2*
47 01 00 3*

101側
47 41 01 1*
47 01 01 1*
47 01 01 3*

以上が確認できました。それ以外はないみたいです。

さて、映像と音声はとっておきにしたいので、先にfff番のパケットについて調査を進めます。

調べてみましたPMTというやつですね。

47 4f ff 1*のみで内容はすべて同じみたいです。

どうやらPATと同じく含まれている音声と映像のPID情報を保持しているようです。

47 4f ff 11 00 02 b0 17 00 01 c1 00 00 e1 00 f0 00 1b e1 00 f0 00 03 e1 01 f0 00 4e 59 3d 1e

http://allegro.dtiblog.com/blog-entry-187.html
http://nomanganolife.blogspot.jp/2009/12/mpeg2-ts_09.html
こちらの記事を参考にやってみると
47 4f ff 10(TSヘッダ)
00
[02] [b0 17] 00 01 c1 00
00 e1 00 f0 00 1b e1 00 f0 00 03 e1 01 f0 00
4e 59 3d 1e(CRC)

[02]まず先頭の02ですが、これがPMTの識別する値みたいです。
[b0 17]つづく上位４ビットbの部分が固定で残りの0x017が今回のPMTデータの長さになるらしい。
0x17がデータ長なので23バイトが今回のデータみたいです。
00 01 c1 00 00 e1 00 f0 00 1b e1 00 f0 00 03 e1 01 f0 00 4e 59 3d 1e
この部分がちょうど23バイトになっていますので、正解です。


47 4f ff 10(TSヘッダ)
00
02 b0 17 00 01 c1 00 00
e1 00 f0 00
1b e1 00 f0 00
03 e1 01 f0 00
4e 59 3d 1e(CRC)

つづく00 01 c1 00の部分はPATと同じみたいです。

PAT 47 40 00 11 00 00 b0 0d 00 01 c1 00 00 00 01 ef ff 36 90 e2 3d

e1 00 f0 00の部分ですが

e1 00の部分、先頭3ビットは111固定残り13ビットがPCR_PIDとのことです。今回は0x100になります。

f0 00の部分は先頭４ビットが1111固定(fの部分)残りの12ビットは今後の番組情報長の基底ですが、0なので情報はありません。

あとの残りは

1b e1 00 f0 00
03 e1 01 f0 00
緑がストリーム形式種別
青が上位3ビット 111固定と下位13ビットがエレメントのPID
fの部分は４ビット1111固定で
赤の部分がデータ長(中身がないので0固定)
となります。

エレメントのPIDが0x100と0x101になったので、これは先ほどのデータと一致しますね。
1bと03のストリーム形式種別については、とりあえず1bを映像 03を音声と考えて処理しますが、いろんなファイル変換してみて、どうなるか確認するつもり。
PMTの情報も今回の出力結果をコピーしてつかって問題なさそうな予感です。
エレメントの内容は次回・・・