- 【開発】 TS関連ソフトウェア総合スレ Part13
643 ：名無しさん＠編集中[]：2014/08/01(金) 17:50:37.97 ID:cGYkbcVK - >>640 「音声Delayのマイナス値は、映像に対しての遅れ値だよ 」
.mpgなどPSファイルの場合はそういう意味になるが、TSの場合はどこにも
定義されていない値のはずだ。 ファイルに出現する最初の映像パケットと
最初の音声パケットのPTS時刻差を「audio-delay」として報告する解析ツールが多いが、
解析するツールによって映像パケットの最初のPフレーム(前映像がないので意味がない)
を無視するものと無視しないものがあり、両社で63msec(1/29.97)の違いがある。
>>634
TSで映像パケットが先行するのは再生機ででコーディングに時間がかかるためといわれている。
LANパケットでは経路制御で送出順と同じ順で着信するとは限らないので、
受信側で並べなおされ、再送要求もあるが、放送では一方的な垂れ流しなので、
映像を先に送っておくことで再生での時刻遅延を少なくしようと考えたのだと思う
（LAN通信の場合はtimeoutまで受信遅れを許容し、アプリによっては再送要求を含め
1時間以上許される場合もある）
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
644 ：名無しさん＠編集中[]：2014/08/01(金) 17:54:47.31 ID:cGYkbcVK - >> 63msecは2フレーム分の2/29.97secだった。
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
645 ：名無しさん＠編集中[]：2014/08/01(金) 17:57:07.02 ID:cGYkbcVK - >>はたまたごめん。 両者で67msec(2/29.97fps)でした。
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
647 ：名無しさん＠編集中[]：2014/08/01(金) 18:21:16.32 ID:cGYkbcVK - >>64
おっしゃる通り、Murdocで切り出したTS先頭では200〜500msec音声パケットが
先行する(PTS値が小さい)のが通例です。
私が言いたいのは、先頭の映像PTSと音声PTSの時刻差を「audio-delay」として
報告する値がツールによって67msec違うということです。
TSmuxerで「audio-delay」が-400msecと報告されているTSがMediainfoで調べると
-467msecであることです。
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
648 ：名無しさん＠編集中[]：2014/08/01(金) 18:25:47.50 ID:cGYkbcVK - >> 「xport」はソースが公開されているので、これを改造して自分なりの
TS解析ツールが作れます。
「他人の作ったツールの出力とかを鵜呑みにするんじゃなくてさ。」と同じく
鵜呑みにするなと言っているのですよ。
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
656 ：名無しさん＠編集中[]：2014/08/01(金) 19:53:45.66 ID:cGYkbcVK - >>649
私の「先行」の言葉の使い方に問題があったのかもしれませんね。
読み直すと確かに変ですね。
同時刻に対応する映像/音声の各パケットがパケット列の並び順(送信時刻順)と
して前にある時に「先行する」と表現しているつもりなのですが、この意味では
>>647 の「200〜500msec音声パケットが 先行する(PTS値が小さい)のが通例です。 」
というのは音声パケットが「遅れている」と書くべきだったとおもいます。
>>602-603 の列車表現を使って言えば、乗客と手荷物が隣接車両にある理想的
（仮想的）TSにたいして、「先行」「遅延」しているという意味合いです。
>>633-634 のデータは自作あるいは何らかのツールの出力だと思いますが、
パケット順に並んでいると考え、12:04:03.400をPTS時刻のfタイプ表現だとすると
「+00089540=#2992: 12:04:03.400 #2 pic=112203
....
+00089250=#2988: AAC-Audio 12:04:02.985488」
ですので 映像；12:04:03.400、音声12:04:02.985 ですから
同時刻対応の映像パケットはその音声パケットより前に位置しており、
「先行」しており、それより前の位置により早い時刻の音声パケット群
(400msec分）が含まれています。 放送波が映像を先に送るという概念と
切り落としで前時刻の音声パケットが残存するという問題が併存しているために
表現の解釈が混乱しているようです。
あなたの、「GOP単位で考えても音声の方が400ms近く先行してるのが分かるだろ？」
の「先行」の意味がわからなくなりました。 先頭付近のパケットのPTS値として
若いPTSを持つものを「先行」と呼ばれているのであれば理解できますが。。。。
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
659 ：名無しさん＠編集中[]：2014/08/01(金) 20:14:44.06 ID:cGYkbcVK - TSsniperで切り出したTSを調べたら、先頭箇所の映像/音声のPTS差は
数msec(MediaInfo報告)だった。 もっともGOPではなくframe単位で
切り出せるらしいので、無劣化編集であるはずはなく、エンコード
処理されていると考えられるので、エンコードにより前段切り捨て部の
音声パケットが除去されているのだと思う。
先頭部の無劣化処理はffmpegやx264などのCODEC変換処理への適正入力
を準備するために重要なのだが、忘れがちなのは末尾部分の処理である。
Murdocを基準に取ると、末尾処理では音声を失った映像パケットに対し、
正確なPTSのadjustmentは無理であるにしても
(1)そのまま放置
(2)当該の映像パケットを破棄する
(3)当該の映像パケットにつぃおうする時間帯分の無音音声パケットを付加する。
の3種類の処置が考えられる。
通常は(1)にして後続CODEC変換処理のツールでのエラー処理に任せて
しまっていると思うが、TSの無劣化編集で(2)か(3)を行うことができないものか？
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
660 ：名無しさん＠編集中[]：2014/08/01(金) 20:21:55.99 ID:cGYkbcVK - >>658
>>602-603 の列車表現を使うとMurdocは特に何も意識せずに
GOP先頭機関車の前の連結器を切り離しているだけだと思います。
TSを切り出す際に1カタマリで切り出したものと、途中で切って
2つの断片にしておいたものを、再度Murdocで結合したものは、
完全に一致します。
|
- 【開発】 TS関連ソフトウェア総合スレ Part13
662 ：名無しさん＠編集中[]：2014/08/01(金) 21:17:27.13 ID:cGYkbcVK - >>661
TSをTSMuxerでdemuxして.mpvと.aacを作り、再度TSMuxerでこれらをmuxすると、
先頭にPAT、PMTをもった新しいTSができます。 また、先頭部分の残存音声
パケットは除去され、もとが断片結合のTSであっても、新TSは一貫して連続した
PTSが振られたものになります。 但し、先頭部の残存音声パケットが除去
されるのに反し、末尾部分では音なし映像パケットは除去されずに
そのままになります。
TSmuxeRによるこのやり方では、断片集合のTSファイルについて、
通常の放送TSのCMカット版では音ズレは感じられません。
しかしながら、映像時間と音声時間が１０秒以上異なる特殊なTSを作成し、
これらをMUrdocで接合して(Murdocは連結器をつなぐだけ)作った
テストファイルをTSmuxeRに入れて実験してみたところ、
断片の接合部での音ズレ発生は防止できていませんでした。
|