recisdb で B25 デコードを行うと、ファイルサイズが arib-b25-stream-test を使用した時と比べて若干減る

[tsukumijima]

再生そのものは問題ないし番組情報も取れているが、arib-b25-stream-test だとスクランブル前の TS よりもファイルサイズが若干減ってしまう。(10秒間録画した TS で 6MB ほどもの差がある)
本来であれば、スクランブル前の TS とスクランブル後の TS のファイルサイズは完全に一致するはず。
何かしらのデータが抜け落ちているとしか考えられないのだが…。

[tsukumijima]

ちなみに B25 デコードに関しては、recpt1 側で他にも下記 Issue が上がっていて、既知の問題が多いことで知られている。

arib-b25-stream-test が主流なのも、recpt1 --b25 よりも安定動作するとされているため。

もし recpt1 を参考に実装したなら、下記のバグも再現しないかしっかりテストする必要があると思う。

• 同じTSIDを共有するマルチCHストリームのb25デコードにおいてTSペイロード破綻が起こる stz2012/recpt1#10
• 地デジの放送停止時刻以降録画データ(.m2ts)が再生できなくなってしまう stz2012/recpt1#9
• https://github.com/Chinachu/Mirakurun/issues/107

[tsukumijima]

別の TS ファイル (30分あって 3GB 程度の TS ファイル) を試しにデコードしてみたところ、ファイルサイズ差が数百B程度で収まっていました。
もしかすると、放送局ごとに減る量に差があるのかもしれません。
なお、x64 環境 (SSD, HDD) と arm64 環境 (NanoPi R6S: eMMC) では減った後のファイルサイズが共通だったため、ディスクやアーキテクチャに依存する問題ではないと考えられます。

[tsukumijima]

原因がわかりました！

結論から述べると、recisdb decode でのデコード処理が、libaribb25 に含まれる b25 コマンドで -s 1 オプションを使った際同様、TS ストリーム内に含まれる NULL パケットを除去するようになっているからでした。

• recisdb decode
• b25 -s 0
• b25 -s 1

の3パターンで試してみましたが、b25 -s 0 (-s 0 は何も引数を設定しなかった場合のデフォルトでもある) のファイルサイズは、デコード前の TS ファイルと完全に一致しました。
また、recisdb decode と b25 -s 1 でデコードされた TS ファイルはファイルサイズも MD5 ハッシュも同一でした。
このことから、b25 と recisdb decode で動作に違いはないと思われます。

通常 B25 デコードしたデータは元 TS と同一のファイルサイズになるはずなのでデータが不可逆的に失われていないか心配していましたが、その心配は不要そうです。

[tsukumijima]

https://www.marumo.ne.jp/db2008_3.htm

放送波では常に一定の帯域で放送する必要があるので、NULL パケットは確か帯域を完全に埋めきれなかった際にパディングとして挿入するもののはずです。つまり置いといてもサイズの無駄なので、削除しておくに越したことはないでしょう（おそらくは）。

とはいえ、将来的にはオプションとして用意しておいてもいいとは思います（上記事情を鑑みると、その際もデフォルトは NULL パケット削除の挙動の方が良さそう）。

[kazuki0824]

recisdb のDecoderOptions構造体にstripというオプションがあるので、それが関係ありそうですね。 コマンドラインオプションに—no-stripというのを追加してあげて、そこの値次第で渡すDecoderOptionsを変化させるようにすれば良さそうと思いました。

…

On Thu, Aug 10, 2023 at 8:51 tsukumi ***@***.***> wrote: [image: image] <https://user-images.githubusercontent.com/39271166/259575741-815ffd92-d390-4ace-a615-ce76ffa46346.png> https://www.marumo.ne.jp/db2008_3.htm 放送波では常に一定の帯域で放送する必要があるので、NULL パケットは確か帯域を完全に埋めきれなかった際にパディングとして挿入するもののはずです。つまり置いといてもサイズの無駄なので、削除しておくに越したことはないでしょう（おそらくは）。 とはいえ、将来的にはオプションとして用意しておいてもいいとは思います（上記事情を鑑みると、その際もデフォルトは NULL パケット削除の挙動の方が良さそう）。 — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGAM4HJKP7P4ICYLBTKFCTXUQPBLANCNFSM6AAAAAAZY6VOJ4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>