TSファイルから番組内容を取得する

epgrec が内部で使っているepgdumpというプログラムが、なんか引数にontv codeというのをとるので、これはontv japanをスクレイピングしているのかと思っていたが、その割にはtsファイルのパスも必要だしどうなってるんだと思ってよくよくソースを読んでみたら、tsファイルを解析していることがわかった。日本の地上デジタル放送はMPEG-2 TSという形式が採られていて、動画データや音声データのほかに時刻情報やら番組情報やら、いろんなメタデータが付加されている。そこらへんの仕様がデジタル放送に使用する番組配列情報(ARIB STD-B10)というARIBが公開している資料に書かれているということなので、読んでみることにした。

MPEG-2 TSファイルの内容はNHKの資料や朋栄IBEの資料に詳しい。すなわち、TSファイルは188バイトのパケットを1単位として構成されていて、パケットの先頭4バイトがヘッダ、残り184バイトがアダプテーションフィールド(ヘッダを拡張したもの)とペイロード(情報本体)のどちらか、または両方となっている。パケットの先頭バイトは必ず0x47であり、ペイロードの中身が何であるかはPIDと呼ばれる13ビットのフィールドで分かる。一連の情報が複数のパケットに分割されることもあり、その場合の先頭パケットはPayload-unit start indicatorフラグが1かどうかで判断できる。パケットが欠落することもあるが、Countinuity indexという4バイトのフィールドがあり、もし欠落していたらこの値が飛ぶので判断できる(16パケット一度に飛んだ場合は判断できない)。

番組情報はEIT(Event Information Table)というテーブルに記述され、PIDは0x12, 0x26, 0x27である。EITテーブルには1つ以上のイベント(=テレビ番組ひとつひとつ)が含まれ、そのイベントにも1つ以上の記述子が含まれている。EITテーブルの定義はARIB STD-B10 第2部の表5-7にあるとおり、以下のようになっている。

イベントと記述子が複数あるため、一連のパケットのうちどこまでがひとかたまりなのかはsection_lengthの値を見ないと分からない。section_lengthの値は、section_lengthフィールドの後に何バイト続くかであることに注意する必要もある。各記述子は、共通して先頭1バイトが記述子タグ、2バイトが記述子長であるので、先頭2バイトを見ればどの種類の記述子が何バイト続くかが分かる。記述子長も、やはり記述子長フィールドの後に何バイト続くかの数値なので、記述子全体の長さはそれに+2したものになる。それぞれが何回繰り返されるかは、section_length、descriptors_loop_length、descriptor_lengthの値から求められる。パケットの途中でテーブルの記述が終わった場合は、残りが0xFFで埋められる。

どの記述子がどのテーブルにひもづいて登場しうるかはARIB STD-B10 第2部の表6-1に定義されており、EITでは短形式イベント記述子が必須、ほか数項目が任意となっている。短形式イベント記述子は番組名と番組内容を定義するもの(ARIB STD-B10 第1部 図6-32)である。epgdumpなどの既存のtsファイルパーサもこの記述子の内容を見て、どういう番組が何時から何時まで放送されるのか表示している。地デジテレビの番組表表示機能もおそらくこのフィールドを見ているのだろう。

ただ、このフィールドのデータがいまいち使えない。フォーマットが番組によってバラバラなのである。たとえば以下のような感じ (ARIB外字は既存のepgdumpの実装通りに展開):

ざっとみて以下のようなパターンがあるようである:

• サブタイトルを番組名フィールドに置くか、番組記述フィールドに置くか、表示しないか
• 話数を表示するか、しないか。表示する場合はどう表示するか
• その話の要約があるか、番組全体の要約(というかキャッチフレーズ)があるか

録画したアニメのファイルを管理するのに、タイトルと話数とサブタイトルはもっとも重要な要素だといえる。その重要な要素が、短形式イベント記述子からは体系だてて取得しにくい。しょぼいカレンダーなどの人力ソリューションは、おそらくそこら辺の問題からの需要も強いのだろう。ただし、しょぼいカレンダーのヘルプに「編集者が「視聴または録画するデータしか登録してはいけない」というルールがある」というとおり、必ずしもすべてのアニメ情報が配信されるとは限らない。最近だと、黄金の法とかはれときどきぶたの再放送などが配信されなかった。

なんかいい方法はないかとARIBのドキュメントを引き続き読み進めて行ったら、「シリーズ記述子」という便利そうなものが定義されていることが分かった。

この記述子は、シリーズ化された複数のイベントを識別するために用いる。個々のシリーズはシリーズ識別により識別される。受信機では、シリーズ化されたイベント群に対して一括の操作(予約等)を行う際に用いることができる。

シリーズ記述子は記述子タグ0xD5で定義され、以下のフィールドを持つ:

• シリーズ識別
• 再放送ラベル
• 編成パターン (週に1回放送とか、帯番組だとか)
• 有効期限フラグ
• 有効期限 (最終話が認識できなかった場合、ここで指定した日を過ぎたら放送終了とみなす)
• 話数
• 番組総数
• シリーズ名

こんな便利な情報が定義されているなら話は早い。再放送ラベルを見れば、「もしドラ」や「バクマン」の同じ話がなんども録画されるのを避けられるし、シリーズ名や話数が取れるので録画したファイルのネーミングに使える。(サブタイトルを定義するフィールドがないことに気づいたが、短形式イベント記述子から正規表現とか使って持ってこれないこともないだろう)

ということで、シリーズ記述子を捕まえるべく、TSファイルから記述子を取得するコードを書いてみた。

実行結果は以下のとおりである:

なんということだ、シリーズ記述子がEITパケットに含まれていない!

ていうか、そういう記述子が含まれているなら既存の類似実装が見逃すはずがないのであった。たとえば、Rec10のepgdump/eit.cは、実際に配信されているコンテント記述子・コンポーネント記述子・音声コンポーネント記述子は値を取得している(738行目付近以降)が、シリーズ記述子はパースしたあとデータを取り込んでいない。

ということで、EPGデータは全放送データが含まれていて量はよいが内容が適切に表現されていないところがあって質が良くない。しょぼいカレンダーはフォーマットがしっかりしていて内容を再利用しやすいが配信されない番組がある。両者をおりまぜていい感じに使うのがよい。