パケ死 ~TSパケットのドロップ判定~

いつの間にか「パケ死」という言葉が、パケット通信料が高額な様からデータ通信料を超えた様に変化していました。でも「パケット」「死」から連想されるのはそれだけではないでしょう。そう、みんな大好きTSのドロップです。
どうも、らんだむです。この記事は DTV Advent Calendar 2016 22日目の記事です。
ドロップがなぜ起こるかは去年のAdvent Calendarで書いた覚えがあります。今回はドロップの理由ではなく、ドロップの判定について書きたいと思います。

パケット

MPEG-2 TS では、パケットという単位でデータを扱います。一つのパケットは固定長で、(日本の一般的なテレビ放送では)188バイトです。パケットには必ずヘッダがあり、その後に内容があります。

PID

ヘッダには「PID」が存在し、データの種類を識別するために使用します。

エラー

ヘッダには「transport error indicator」が存在しています。これは、必ず0で送信されますが、うまく受信できなかった等の理由で1になってしまった場合は、パケットにエラーが存在すると判断されます。ドロップとは違うかもしれませんが、このパケットを棄却した場合、パケットがドロップします。

カウンター

ヘッダには「continuity counter」というカウンターも存在しています。そしてこれがドロップ判定の主要素となります。このカウンターは、同一PIDのパケットを送信するたびに1増加し、0から15までの値をとります。具体的には以下のようになります。

送信順(TS全体) 1 2 3 4 5 6 7 8 9 10
PID 0 14 15 0 1
PID 1 6 7
PID 2 4 5 6 7

送信順に見ると、6, 4, 14, 5, 15 ...とバラバラに見えますが、PIDごとに見ると、14, 15, 0, 1のように順番に並んでいることが見て取れます。つまり、カウンターの値が不連続であれば、ドロップしているといえます。

重送

MPEG-2 TS では、パケットの重送を一度だけ認めています。つまり、同じカウンターの値が連続する場合があり、カウンターの値が不連続となりますがドロップにはなりません。ただし、同じカウンターの値が連続していても、パケットが16つドロップしている場合と区別がつきません。本当に重送であるかどうか判断したい場合は、内容が同じであるかどうかを検証しなければなりません。

送信順(PID毎) 1 2 3 14 15 16 17 18
重送 6 6 7 2 3 4 5 6
ドロップ 6 7x 8x 4x 5x 6 7 8

不連続

今度はヘッダではなく、アダプテーションフィールドと呼ばれる領域に「discontinuity indicator」が存在します。これは、カウンターの値が不連続になることを示します。この場合、カウンターの値が不連続でもドロップとなりません。

まとめ

ドロップ判定の流れとしては以下のようになります。

  1. パケットにエラーがあるか
  2. discontinuity indicatorで不連続になるか
  3. カウンターが不連続で、重送でないか

… DTV AC、まだ1日目と15日目を書いていないので、辛いです…


AutoConvert v3.0.0

AutoConvertの前のバージョンを見ました。アップロード日が2013/09/22であることに驚愕し、そして、今2016年であることにも驚愕しております。お待たせしました。

公開するかも迷ったのですが、できているものを公開しないのもアレなので、公開します。ただ、問題はありまして、2014年辺りに作ったので、作った本人がすでに仕様を理解していないことをご了承ください。あと、こちらのデザインはろっと氏(@aayh)に担当していただきました。HTAだと思えないほどのUIになっていますので、御覧ください。

例のごとく、以下のページで公開しています。

AutoConvert