【糞環境】TSパケットエラー報告【とは言わせない】

知っていると得する(かもしれない)dropネタを３つ

[ネタ１] 〜録画アプリがtransport_error_indicator=1のパケットを捨てる場合がある〜
dropの原因がアンテナ系(含:分配での劣化・糞なチューナー・パソコンからのノイズ)に
あるかどうかを判断するとき、transport_error_indicator=1のパケットがあるかどうか
(tsselectでbiterror、Multi2DecWinで「ﾋﾞｯﾄｴﾗｰ」欄)が一番の目安になるが、録画アプリ
がtransport_error_indicator=1のパケットを捨てる場合があり、この場合は録画したフ
ァイルをtsselect/Multi2Decに通しても参考にはならない。
＜録画アプリがtransport_error_indicator=1のパケットを捨てる例＞
* EpgDataCap_Bon Ver8.x (transport_error_indicator=1のパケットを捨ててdropにカウ
ント。Ver9.xは未確認)
* 他のアプリでも「指定サービスのみ」にした場合、エラーの結果PIDがそのサービスに
含まれないIDになった場合、そのパケットは捨てられる。
＜transport_error_indicator=1のパケットを捨てないアプリの例＞
* SimpleApp (http://2sen.dip.jp/cgi-bin/friioup/source/up0776.zipに付属)

[ネタ２] 〜discontinuity_indicatorを考慮していないアプリがある〜
番組の変わり目などで元々のデータ自身がcontinuity_counterが不連続の場合、放送局側
でdiscontinuity_indicator=1として送出(これは不連続であってもdropではない)するが、
アプリによってはdiscontinuity_indicatorを考慮していないため、これをdropとしてカ
ウントするものがある。
＜discontinuity_indicatorを考慮していないアプリの例＞
* BonEngin(BonTest)をベースとしたアプリ全般
＜discontinuity_indicatorを考慮しているアプリの例＞
* tsselect0.1.5以降 (ソース・ReadMeでdiscontinuity_counterとなっているのはご愛嬌)
* BonSDK(新しいMulti2Dec)はソースを見る限り考慮してるようだが、正しく機能している
かどうかは未確認。

[ネタ３] 〜最新tsselectでもdropでないものを誤ってdropと判断する場合がある〜
放送途中で一時的にPID自身が無くなっていて(PMTからも消えていて)その前後でcontinuity_
counterが不連続の場合(PMTから一旦消えれば別ストリームなので、不連続であってもdrop
では無い)、tsselectでも誤ってdropと判断をしている。
＜放送途中で一時的にPID自身が無くなっている(PMTからも消えている)例＞
* NHKで5.1ch音声のスポーツ中継の途中でニュースが挟まった場合の5.1ch音声のストリーム