【開発】 TS関連ソフトウェア総合スレ Part13

1 ：名無しさん＠編集中：2014/01/05(日) 00:15:08.32 ID:e/ygnYY5.net

専用スレが立っていないTS周り諸々のソフトウェアについて語りましょう

過去スレ
【開発】PT1 Friio HDUS bon系 TS関連ｿﾌﾄｳｪｱ総合ｽﾚ (Part1)
http://pc11.2ch.net/test/read.cgi/avi/1230739003/
【開発】 TS関連ソフトウェア総合スレ Part2
http://pc11.2ch.net/test/read.cgi/avi/1235667096/
【開発】 TS関連ソフトウェア総合スレ Part3
http://pc11.2ch.net/test/read.cgi/avi/1240726004/
【開発】 TS関連ソフトウェア総合スレ Part4
http://pc11.2ch.net/test/read.cgi/avi/1246099246/
【開発】 TS関連ソフトウェア総合スレ Part5
http://pc11.2ch.net/test/read.cgi/avi/1252674823/
【開発】 TS関連ソフトウェア総合スレ Part6
http://pc11.2ch.net/test/read.cgi/avi/1259061990/
【開発】 TS関連ソフトウェア総合スレ Part7
http://pc11.2ch.net/test/read.cgi/avi/1269400568/
【開発】 TS関連ソフトウェア総合スレ Part8
http://hibari.2ch.net/test/read.cgi/avi/1279108411/
【開発】 TS関連ソフトウェア総合スレ Part9
http://hibari.2ch.net/test/read.cgi/avi/1314275425/
【開発】 TS関連ソフトウェア総合スレ Part10
http://toro.2ch.net/test/read.cgi/avi/1323049561/
【開発】 TS関連ソフトウェア総合スレ Part11
http://toro.2ch.net/test/read.cgi/avi/1341073328/
【開発】 TS関連ソフトウェア総合スレ Part12
http://toro.2ch.net/test/read.cgi/avi/1358933709/

621 ：名無しさん＠編集中：2014/07/30(水) 09:45:13.04 ID:LyfFU8DZ.net

>>613
オレと同じやり方だなあ

・MurdocCutterでは連結しない
・頭は1GOP、ケツは2GOPののりしろをつくる

これが確実で手軽

622 ：名無しさん＠編集中：2014/07/30(水) 12:18:28.83 ID:Tend+7aT.net

連結はavs+trimでやれば確実じゃね。
aviutlは編集中にいきなりutlがアプリエラーを吐いて
フリーズすることがあるからあまり信用してない。

エンコしない人は、tvtplay+tslistファイルみたいなプレイリストへ
順番に追加していけば特に問題ないと思われ。

623 ：名無しさん＠編集中：2014/07/31(木) 02:28:28.24 ID:V2mUjRHN.net

>>619
AAC のフレームは 21ms じゃない？
ts2aac で、音声を映像に一番近くなるように調整しつつ
ズレを DELAY として出力する -z スイッチを付けると、-10〜10ms の DELAY になる。
ちなみに、生 TS だろうと Murdoc Cutter で切った TS だろうと、
約 20 フレーム（フジのように可変 GOP だともっと小さいことも）スキップするので、
>>617-616 の言うように先頭には音声が余ってる。

自分は基本前後カットしかせずゴミは気にしないので
Murdoc Cutter で切ってそのままエンコし ts2aac -z の出力と mux するだけ。
たまに長い番組の一部分しかいらず冒頭に予告みたいのがあると中抜きするが、
ts2aac に -M スイッチ付けとけば音ズレしない。盛大にブロックノイズ出るがｗ

624 ：名無しさん＠編集中：2014/07/31(木) 07:48:16.98 ID:bGDRQy4/.net

DGIndexをcmdで呼び出す時引数で-hideを設定しても
ウィンドウフォーカスのアクティブをDGIndexが持っていくみたいで少し困ってる
どうにかできないかなあ

625 ：名無しさん＠編集中：2014/07/31(木) 09:44:48.78 ID:s//BJFZc.net

笑いたきゃ笑えw

@echo off

set DGIndex="C:\DGIndex\DGIndex.exe"
set AVS="C:\hoge\template.avs"

%DGIndex% -i "%~1" -o "%~dpn1" -ia 5 -fo 0 -yr 2 -om 1 -at %AVS% -hide -exit

626 ：名無しさん＠編集中：2014/07/31(木) 09:54:57.13 ID:fU03++aT.net

>>623
スマン
ADTSフレーム21msって昔自分で書いてたわ
まあ言いたかった事は放送波ってのはリアルタイム視聴特化の仕様で、
映像と音声の同期はプレイヤーに依存する設計になってるって事だ

音声が余るってのは恐らく変換ツールがPTSでなく「TS的に」
一番近いフレーム境界しか見ずに各ストリームを切った結果じゃねーか？

送信側じゃAACとMPEG-2のエンコ負荷や経路には当然差がある訳だが、
同期する義務は受信側にあるから早くエンコが終わって準備完了した方を
一旦バッファリングしてトラポンを構築なんて無駄な事をする義務はない

もちろん放送の途中でその差に揺らぎが出てもそれを同期調整する義務は
受信側にあるので、変換ツールがその義務を果たさず頭と終わりしか見ない場合も
放送によってはおかしな事になるんじゃねーかな (TvTestは当然この調整を随時行っている)

627 ：名無しさん＠編集中：2014/07/31(木) 15:18:07.41 ID:c1rJueNh.net

>>624
-hideじゃなくて-minimizeなら大丈夫じゃねーかな

628 ：名無しさん＠編集中：2014/07/31(木) 19:04:45.97 ID:W1ksspHL.net

>>627
大丈夫だったわthx
ただ画面端のウィンドウの残りカスがきになるわソース触るしか無いな

629 ：名無しさん＠編集中：2014/07/31(木) 22:07:50.46 ID:kzsuUvv7.net

-hide -exit>nulじゃダメなん

630 ：名無しさん＠編集中：2014/08/01(金) 00:00:24.78 ID:fBJp1lbx.net

>>626
＞音声が余るってのは恐らく変換ツールがPTSでなく「TS的に」
＞一番近いフレーム境界しか見ずに各ストリームを切った結果じゃねーか？
変換ツールっていうか Murdoc Cutter のことね。
恐らく GOP 境界で各パケットを単純に切り出してるだけなので、
音声はフレーム境界ですらないところで切れてるはず。
で、そんな細かいズレ以前に、放送波の時点で約 20 フレームも音声が遅れてるってこと。
AAC フレームより GOP のほうが大分長いし、エンコ自体映像のほうが重いし、
何も考えなければ映像のほうが遅れそうなので、
なんらかの理由によりあえて映像を先行させてるんだろうね。

＞もちろん放送の途中でその差に揺らぎが出てもそれを同期調整する義務は
＞受信側にあるので、変換ツールがその義務を果たさず頭と終わりしか見ない場合も
＞放送によってはおかしな事になるんじゃねーかな (TvTestは当然この調整を随時行っている)
Murdoc Cutter で中抜きすると音ズレするとかいう言いがかりは正にそういうことだよね。
悪天候でちょっとドロップしたのと似たような状態なんだし、
音ズレしたままになるなら TS 再生環境として不完全ということ。

631 ：名無しさん＠編集中：2014/08/01(金) 00:24:27.55 ID:fBJp1lbx.net

あ、ts2aac -z は、その余った部分をスキップしてくれるので音ズレしないからね。
-M ありなら中抜き部分も補正してくれる。
最大で 10ms の誤差が出るのは原理上仕方ないが。

変換ツールうんぬんのくだりがそれをわかってなさそうにも見えたので念のため。

632 ：名無しさん＠編集中：2014/08/01(金) 00:41:14.04 ID:shtF18Gh.net

なるほど

633 ：名無しさん＠編集中：2014/08/01(金) 07:17:50.57 ID:SpFCJqj7.net

ザ

634 ：名無しさん＠編集中：2014/08/01(金) 07:29:46.71 ID:4ZYPvFOp.net

世界

635 ：名無しさん＠編集中：2014/08/01(金) 08:11:30.44 ID:2GohebBd.net

>>630
＞なんらかの理由によりあえて映像を先行させてるんだろうね。

ダウト。
どれでもいいから直接TS覗いてみるといい。
要はこういう事。

+00089540=#2992: 12:04:03.400 #2 pic=112203 SEQ EXT EXT GOP I-PIC EXT SLICE_MIN
+000A64A4=#3623: 12:04:03.366 #0 pic=33881 B-PIC EXT SLICE_MIN
+000AEEB4=#3811: 12:04:03.383 #1 pic=30542 B-PIC EXT SLICE_MIN
+000B6C48=#3982: 12:04:03.632 #5 pic=25072 P-PIC EXT SLICE_MIN
+000BD54C=#4125: 12:04:03.416 #3 pic=20425 B-PIC EXT SLICE_MIN
+000C2D6C=#4245: 12:04:03.433 #4 pic=24280 B-PIC EXT SLICE_MIN
+000C943C=#4385: 12:04:03.682 #8 pic=21540 P-PIC EXT SLICE_MIN
+000CF180=#4512: 12:04:03.649 #6 pic=19487 B-PIC EXT SLICE_MIN
+000D4538=#4626: 12:04:03.665 #7 pic=24126 B-PIC EXT SLICE_MIN
+000DACC4=#4767: 12:04:03.732 #11 pic=25132 P-PIC EXT SLICE_MIN
+000E1684=#4911: 12:04:03.699 #9 pic=13134 B-PIC EXT SLICE_MIN
+000E5144=#4991: 12:04:03.715 #10 pic=19625 B-PIC EXT SLICE_MIN

636 ：名無しさん＠編集中：2014/08/01(金) 08:12:32.35 ID:2GohebBd.net

(続き)
+000EA7EC=#5109: 12:04:03.782 #14 pic=20257 P-PIC EXT SLICE_MIN
+000F00C8=#5230: 12:04:03.749 #12 pic=13036 B-PIC EXT SLICE_MIN
+000F3D00=#5312: 12:04:03.765 #13 pic=20868 B-PIC EXT SLICE_MIN
+000F9520=#5432: 12:04:04.014 #2 pic=111216 SEQ EXT EXT GOP I-PIC EXT SLICE_MIN
..

+00089250=#2988: AAC-Audio 12:04:02.985488
+00090948=#3150: AAC-Audio 12:04:02.996155
+00099DA0=#3352: AAC-Audio 12:04:03.006822
...

というか最初言ってた

＞>>617-616 の言うように先頭には音声が余ってる。

で合ってたから分かってるもんだと思ってたが、
一体何をソースにTS内で映像フレームの方が先行してるなんて考えたんだ・・・？
TS回りのプログラム一度も組んだ事ねーのか？

637 ：名無しさん＠編集中：2014/08/01(金) 14:40:11.64 ID:xMHL32bU.net

TS回りのプログラム組んだ事ある人なんてそんなにいないと思うが・・・

638 ：名無しさん＠編集中：2014/08/01(金) 15:46:16.28 ID:2ZJnSyCW.net

俺はある

639 ：名無しさん＠編集中：2014/08/01(金) 16:22:43.38 ID:X0XxUvei.net

ここ開発スレだよね？

640 ：名無しさん＠編集中：2014/08/01(金) 16:30:05.18 ID:xMHL32bU.net

Σ(・ω・ ) ﾊｯ!

641 ：名無しさん＠編集中：2014/08/01(金) 16:43:08.35 ID:4ZYPvFOp.net

まゆげがないいいいいいいいいいいいいい

642 ：名無しさん＠編集中：2014/08/01(金) 16:43:48.86 ID:JynNVvs3.net

音声Delayのマイナス値は、映像に対しての遅れ値だよ
プラスだと音声先行

643 ：名無しさん＠編集中：2014/08/01(金) 16:46:06.04 ID:JynNVvs3.net

TS初心者勉強会 27頁目
http://peace.2ch.net/test/read.cgi/avi/1397459139/

644 ：名無しさん＠編集中：2014/08/01(金) 16:51:52.24 ID:jnMOqA6U.net

>>639
初めてスレタイの【開発】に気付いた

645 ：名無しさん＠編集中：2014/08/01(金) 17:50:37.97 ID:cGYkbcVK.net

>>642 「音声Delayのマイナス値は、映像に対しての遅れ値だよ 」
.mpgなどPSファイルの場合はそういう意味になるが、TSの場合はどこにも
定義されていない値のはずだ。　ファイルに出現する最初の映像パケットと
最初の音声パケットのPTS時刻差を「audio-delay」として報告する解析ツールが多いが、
解析するツールによって映像パケットの最初のPフレーム(前映像がないので意味がない)
を無視するものと無視しないものがあり、両社で63msec(1/29.97)の違いがある。
>>636
TSで映像パケットが先行するのは再生機ででコーディングに時間がかかるためといわれている。
LANパケットでは経路制御で送出順と同じ順で着信するとは限らないので、
受信側で並べなおされ、再送要求もあるが、放送では一方的な垂れ流しなので、
映像を先に送っておくことで再生での時刻遅延を少なくしようと考えたのだと思う
（LAN通信の場合はtimeoutまで受信遅れを許容し、アプリによっては再送要求を含め
1時間以上許される場合もある）

646 ：名無しさん＠編集中：2014/08/01(金) 17:54:47.31 ID:cGYkbcVK.net

>>　63msecは2フレーム分の2/29.97secだった。

647 ：名無しさん＠編集中：2014/08/01(金) 17:57:07.02 ID:cGYkbcVK.net

>>はたまたごめん。　両者で67msec(2/29.97fps)でした。

648 ：名無しさん＠編集中：2014/08/01(金) 18:05:03.31 ID:2GohebBd.net

>>645
わざわざ生データのPTS値を張ってやったんだからちゃんと見ろよｗ
GOP単位で考えても音声の方が400ms近く先行してるのが分かるだろ？

だから一度TSを覗いて映像と音声のPTSを自分の目で確かめてみろよ。
他人の作ったツールの出力とかを鵜呑みにするんじゃなくてさ。

ここまでの受け答えの感じだと、何か出力ってよりその解釈を間違えてそうな気もするけどな。

649 ：名無しさん＠編集中：2014/08/01(金) 18:21:16.32 ID:cGYkbcVK.net

>>64
おっしゃる通り、Murdocで切り出したTS先頭では200〜500msec音声パケットが
先行する(PTS値が小さい)のが通例です。
私が言いたいのは、先頭の映像PTSと音声PTSの時刻差を「audio-delay」として
報告する値がツールによって67msec違うということです。
TSmuxerで「audio-delay」が-400msecと報告されているTSがMediainfoで調べると
-467msecであることです。

650 ：名無しさん＠編集中：2014/08/01(金) 18:25:47.50 ID:cGYkbcVK.net

>>　「xport」はソースが公開されているので、これを改造して自分なりの
TS解析ツールが作れます。
「他人の作ったツールの出力とかを鵜呑みにするんじゃなくてさ。」と同じく
鵜呑みにするなと言っているのですよ。

651 ：名無しさん＠編集中：2014/08/01(金) 18:47:25.03 ID:2GohebBd.net

>>648で言ってるのは>>645の後半に対してなんだが。
前半は俺に対するレスじゃないし、誰が何のツールを使ってその出力をどう信じてるとかはどうでもいい。
俺が言ってるのはここだ。

＞TSで映像パケットが先行するのは

してねーから一度生データを確認してみろと。
もしPTSの変換式を知らないとしても、バイト列さえ切り出せば単純なビッグエンディアン数値の大小で真偽は判断出来るからさ。

念の為補足しておくが>>635-634はEDCBが録画したままの裸のデータだからな。

652 ：名無しさん＠編集中：2014/08/01(金) 19:35:02.05 ID:fBJp1lbx.net

>>635-634
悪いが、何を言いたいのかわからん。
その例でも、映像が音声より 400ms 程先行しているように見えるが。
送信側で、映像と音声それぞれをエンコ完了次第最速で出力しているとしたら、
12:04:03.366〜12:04:03:8xx の GOP が完成したのが #2992 だから、
音声は #2988 の時点で 12:04:03.8xx 付近を出力できるはず。
つまり、音声を最低でも１秒近くバッファリングさせていることになる。
実際は、映像エンコにはもっと時間がかかるのでさらに差が付くはずだが。

>>642
だから、DELAY がマイナスということは、映像先行でいいんだよね？

653 ：名無しさん＠編集中：2014/08/01(金) 19:35:45.81 ID:fBJp1lbx.net

＞TS回りのプログラム一度も組んだ事ねーのか？
ないよ。自分のプログラマとしてのピークは 68000 アセンブリで、C はまあ使えるが、
C++ で自分の書いたコードがどういうバイナリになるのか予想できなくなって嫌いになり、
Win のイベントどんぶりで完全につまらなくなりほぼ卒業した。
デジタル放送に関わるようになって久しぶりに興味がわいたけど、
統合開発環境嫌いという大きな壁がｗ

>>639
開発スレだからといって、開発者しかいちゃいけないわけではないと思うが。
適切なフィードバックができるならそれは有用な情報だし、
雑談の中で新たなツール開発のきっかけが生まれることもある。
それに、>>1 の文言を見る限り、別に開発限定スレでもないのでは？
にわかなので良く知らないが。

654 ：名無しさん＠編集中：2014/08/01(金) 19:40:34.46 ID:0qw4o0Ic.net

一体何を問題視しているのかが全然わからん

655 ：名無しさん＠編集中：2014/08/01(金) 19:43:45.53 ID:fBJp1lbx.net

>>645
＞解析するツールによって映像パケットの最初のPフレーム(前映像がないので意味がない)
＞を無視するものと無視しないものがあり、両社で63msec(1/29.97)の違いがある。
P じゃなく B ね。シーン検出で GOP 構造が変わり、
I から始まったり Closed GOP になったりする局もあるから単純じゃないけど。
だから、基本的に映像と音声は同一ツールの出力を使う必要がある。
ちなみに、ts2aac は GOP 構造は解析するものの Closed GOP フラグは見ないようで、
旧わかさトラップ等では -B を付けないと実は２フレームズレる。
かなりエンコしてから気付いたので面倒になり気にしないことにしたがｗ

＞映像を先に送っておくことで再生での時刻遅延を少なくしようと考えたのだと思う
いや、せっかく映像のデコードが完了しても、
音声が届いてなかったら同期再生できないが。
実際には 1GOP のデコードに 400ms 以上かかるだろうから問題ないが、
別に音声が先行していても大した量じゃないんだしバッファリングしておけばいいだけ。
まあ、再生側の負担を減らすため、
デコード完了時に大体揃うようにしているんじゃないかとは思う。

656 ：名無しさん＠編集中：2014/08/01(金) 19:49:03.30 ID:2GohebBd.net

>>652
＞で、そんな細かいズレ以前に、放送波の時点で約 20 フレームも音声が遅れてるってこと。

これが間違ってるという以外にどんな解釈のしようがあるってんだ・・・。


＞その例でも、映像が音声より 400ms 程先行しているように見えるが。

お前が一体何を見てるのかこそさっぱりだ。逆だよ。

＞+00089250=#2988: AAC-Audio 12:04:02.985488
＞+00090948=#3150: AAC-Audio 12:04:02.996155

＞+00089540=#2992: 12:04:03.400 #2 pic=112203 SEQ EXT EXT GOP I-PIC EXT SLICE_MIN
＞+000A64A4=#3623: 12:04:03.366 #0 pic=33881 B-PIC EXT SLICE_MIN
＞+000AEEB4=#3811: 12:04:03.383 #1 pic=30542 B-PIC EXT SLICE_MIN

まさか数字が読めないとか言わねーだろうな・・・？

657 ：名無しさん＠編集中：2014/08/01(金) 19:50:18.19 ID:4ZYPvFOp.net

最低限けつ穴は開発してないと

658 ：名無しさん＠編集中：2014/08/01(金) 19:53:45.66 ID:cGYkbcVK.net

>>651
私の「先行」の言葉の使い方に問題があったのかもしれませんね。
読み直すと確かに変ですね。
同時刻に対応する映像/音声の各パケットがパケット列の並び順(送信時刻順)と
して前にある時に「先行する」と表現しているつもりなのですが、この意味では
>>649　の「200〜500msec音声パケットが 先行する(PTS値が小さい)のが通例です。 」
というのは音声パケットが「遅れている」と書くべきだったとおもいます。
>>604-603　の列車表現を使って言えば、乗客と手荷物が隣接車両にある理想的
（仮想的）TSにたいして、「先行」「遅延」しているという意味合いです。
>>635-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を持つものを「先行」と呼ばれているのであれば理解できますが。。。。

659 ：名無しさん＠編集中：2014/08/01(金) 20:03:02.51 ID:SJGtyrYi.net

元の映像と音声の並び
..V3V4V5V6..
..A3A4A5A6..

TSでは音声を少し「遅らせて」パケット載せる
V3V4V5V6..
A2A3A4A5..

途中でぶった切ると、 >>635-634
V3V4V5
A2A3A4

再生側でデコードし、同期して再生。（余ったA2は捨てる）
V3V4V5
A3A4

660 ：名無しさん＠編集中：2014/08/01(金) 20:11:06.15 ID:2GohebBd.net

ヤベェ
数字が読めてないのは俺の方だった
生データで先行してんのは確かに映像の方だな、スマン

>>658
いや言葉の使い方に何も問題はない、こっちがちょっとボケてただけだ
悪かった


しかしそうなるとMurdocCutterが先頭に音声余りを出すって仕様は
手抜きでなく意図的って事になるが・・・PATやPMTを頭に余分に残すのは
意味のある事だが、音声を余分に残すのはどういう意図なんだろうな

少なくともDirectShowのMPEG-2デコーダはどのベンダもClosedGOPの有無と関係なく
基本先頭数フレームを出力から外すから、むしろ映像の方が余分にないと都合が悪いんだが

661 ：名無しさん＠編集中：2014/08/01(金) 20:14:44.06 ID:cGYkbcVK.net

TSsniperで切り出したTSを調べたら、先頭箇所の映像/音声のPTS差は
数msec(MediaInfo報告)だった。　もっともGOPではなくframe単位で
切り出せるらしいので、無劣化編集であるはずはなく、エンコード
処理されていると考えられるので、エンコードにより前段切り捨て部の
音声パケットが除去されているのだと思う。
先頭部の無劣化処理はffmpegやx264などのCODEC変換処理への適正入力
を準備するために重要なのだが、忘れがちなのは末尾部分の処理である。
Murdocを基準に取ると、末尾処理では音声を失った映像パケットに対し、
正確なPTSのadjustmentは無理であるにしても
(1)そのまま放置
(2)当該の映像パケットを破棄する
(3)当該の映像パケットにつぃおうする時間帯分の無音音声パケットを付加する。
の3種類の処置が考えられる。
通常は(1)にして後続CODEC変換処理のツールでのエラー処理に任せて
しまっていると思うが、TSの無劣化編集で(2)か(3)を行うことができないものか？

662 ：名無しさん＠編集中：2014/08/01(金) 20:21:55.99 ID:cGYkbcVK.net

>>660
　>>604-603　の列車表現を使うとMurdocは特に何も意識せずに
GOP先頭機関車の前の連結器を切り離しているだけだと思います。
TSを切り出す際に1カタマリで切り出したものと、途中で切って
2つの断片にしておいたものを、再度Murdocで結合したものは、
完全に一致します。

663 ：名無しさん＠編集中：2014/08/01(金) 20:44:42.09 ID:2GohebBd.net

ああ意図的に映像の切断点より前のAACパケットを残してる訳じゃなくて、
元々時間差がある分が勝手に残ってるって意味か・・・それなら納得だ

しかしそこまで手抜きしてるとなると、映像の切断点より前のPATやPMTはきちんと何個か残してるのか？
はっきり覚えてないがTvTest内部で丸投げしてるDirectShowの標準スプリッタはPATやPMTが来る前に
来たMPEG-2ストリームは無視する仕様だったはずだから、PATとPMTは最低限頭に残さないと
GOPの頭からデータを入力しても再生が頭欠けするはずだぞ、自作のカッターでもそこを対応した記憶がある

>>661
(3)は原理的には可能だが実装したがる人が少ないんじゃねーかな
映像ストリームと違ってADTSフレームはPESフレームと境界が一致しないという点と、CRCが生きてる所が割と面倒なので
そういや昔MPEG-2デコーダの先頭数フレーム無視問題に対応するため切断点の先頭に黒画面の映像フレームを1GOP追加する機能を
実装しようとして、画素数対応とかが面倒で結局やってないな・・・

664 ：名無しさん＠編集中：2014/08/01(金) 21:17:27.13 ID:cGYkbcVK.net

>>663
TSをTSMuxerでdemuxして.mpvと.aacを作り、再度TSMuxerでこれらをmuxすると、
先頭にPAT、PMTをもった新しいTSができます。　また、先頭部分の残存音声
パケットは除去され、もとが断片結合のTSであっても、新TSは一貫して連続した
PTSが振られたものになります。　但し、先頭部の残存音声パケットが除去
されるのに反し、末尾部分では音なし映像パケットは除去されずに
そのままになります。
TSmuxeRによるこのやり方では、断片集合のTSファイルについて、
通常の放送TSのCMカット版では音ズレは感じられません。
しかしながら、映像時間と音声時間が１０秒以上異なる特殊なTSを作成し、
これらをMUrdocで接合して(Murdocは連結器をつなぐだけ)作った
テストファイルをTSmuxeRに入れて実験してみたところ、
断片の接合部での音ズレ発生は防止できていませんでした。

665 ：名無しさん＠編集中：2014/08/01(金) 21:35:20.05 ID:3mTSRceG.net

とりあえず、murdoccutterの編集結果をTrim値で出力するツールがあったらいいなと

666 ：名無しさん＠編集中：2014/08/01(金) 21:49:41.27 ID:fBJp1lbx.net

>>663
＞しかしそこまで手抜きしてるとなると、映像の切断点より前のPATやPMTはきちんと何個か残してるのか？
手抜きではなく、あえてそのままにしてるんだと思うぞ。
どんなパケットもそのまま残せるのが最大のメリットなんだから。
GOP 境界でバイナリカットしたのとほぼ同じなので、
別の箇所でそれぞれドロップした同一番組の複数の TS から、
タイムコードが連続するように結合することで簡単にニコイチできる。
結合点で PAT と PMT だけ１ドロップ（実際には恐らく重複）出るので、
そのままというポリシーに反し、あなたの言うような対策だけはしてると思われる。
ニコイチしたいときには邪魔なんだけどねｗ

あと自己レスだが、
>>655
＞いや、せっかく映像のデコードが完了しても、
＞音声が届いてなかったら同期再生できないが。
＞実際には 1GOP のデコードに 400ms 以上かかるだろうから問題ないが、
自分の MPEG についての知識が間違ってないとしたら、
原理上、GOP 全体が揃う前でも届いた部分から順次デコードできるはず。
フレームタイプによってデータ量が違うので正確な計算はできないが、
仮に BBI だけで半分使ってたとして、７〜８フレ遅れ。
音声が 400ms 遅れてたら、せっかく最速でデコードしても待たなきゃならなくなるな。

667 ：名無しさん＠編集中：2014/08/01(金) 22:06:16.52 ID:2GohebBd.net

>>664
言葉の選び方が悪かった
(MurdocCutterの切断が)そこまで手抜きしてるとなると〜(MurdocCutterは切断時に)きちんと何個か残してるのか？
と言いたかった

まあどうせあの辺のパケットは、残さないサービスの枝をカットして再生成する需要もあるだろうから、
オリジナルを残す事に拘る必要もないのはその通りではある

音ズレの発生が防止できていないというのはPS化したファイルでなくTSとして再生成したファイルを
TvTestで再生した時の話だろうか？
AAC音声はデコーダの都合上フィルタグラフでやや特殊な経路を通るけど、時刻付きでDirectShowの
管理下に入るのは同じだから自動で同期されるはずなんだけどな・・・
ADTSフレーム境界がTSパケット境界を全く考慮しない問題はAACデコーダのsync word同期で解消
されてたはずなので、ひょっとするとDirectShowの同期には限界があるのかも知れないな
待機バッファリングの容量配慮とかの

668 ：名無しさん＠編集中：2014/08/01(金) 22:10:05.11 ID:znZ3h68x.net

Murdoc Cutterってなんでキーボード操作できないんだろう…
再生画面にフォーカスあわせたときに前後移動だけ辛うじてできるけど

マウスで小さなボタンにカーソル合わせてカチカチ始点終点を指定するのがちょいと不便だ。

669 ：名無しさん＠編集中：2014/08/01(金) 22:30:40.82 ID:2GohebBd.net

>>666
＞TSを切り出す際に1カタマリで切り出したものと、途中で切って
＞2つの断片にしておいたものを、再度Murdocで結合したものは、
＞完全に一致します。

この「完全に一致」はバイナリ的な一致の意味だろうから、俺は残してない公算の方が高いと見てる
あとTSにおけるドロップ報告は通常は単純にcontinuity_counterの不連続部分の検出なので、パケットを残したかという判断には使えんよ
残していようがいまいが、continuity_counterの再調整を全PAT、PMTに対してかけない限りは
接合部ではドロップ検出が報告される(1/16の確率で0にはなるが)

670 ：名無しさん＠編集中：2014/08/02(土) 01:19:00.35 ID:DLJioiIO.net

>>668
初心者スレかここか忘れたけど、キーボード操作で完結させようって奴が色々書いてたはず
俺はマウスで全然問題ないし、それで相当使いやすいと思うけどね

671 ：名無しさん＠編集中：2014/08/02(土) 01:30:00.75 ID:eqaSJCwN.net

>>667 「音ズレの発生が防止できていないというのはPS化したファイルでなくTSとして再生成したファイルを
TvTestで再生した時の話だろうか？ 」

無劣化編集されたTSファイルについてです。　PSファイルは当然、エンコード
された結果得られたものですので、変換ソフトでのエラー処理に依存します。
再生レベルでの音ズレは再生ソフトの仕様に大きく依存します。
従って、いかなる変換ソフトであろうが、いかなる再生ソフトを使おうが、
音ズレしないTSを作成することが理想です。

672 ：名無しさん＠編集中：2014/08/02(土) 01:42:18.19 ID:eqaSJCwN.net

>>　PSファイルから変換ソフトで作成したTSファイルは理想のものになっていると思います。
captured-TSをこれと同等にしたいと思います。　当然のことながら、
ファイルの途中で音声モードが変化したり、2ヶ国語音声になるような
ものにはならず、終始同一の音声トラック数、音声モードになります。

673 ：名無しさん＠編集中：2014/08/02(土) 19:04:10.05 ID:eqaSJCwN.net

Murdocを改造したいのだけど、ソースの入手法を知っている人いますか？

674 ：名無しさん＠編集中：2014/08/02(土) 19:04:58.58 ID:DLJioiIO.net

作者の目前に札束を積む

675 ：名無しさん＠編集中：2014/08/02(土) 19:24:49.02 ID:PUUudc1P.net

公開は善意に因るものだから確かに買取が普通だわね

676 ：名無しさん＠編集中：2014/08/02(土) 19:28:00.13 ID:8uZA0RQx.net

Murdoc Cutterってそもそもデジタル放送を想定したソフトでは無いじゃない。
その割に随分健闘してるよね。

677 ：名無しさん＠編集中：2014/08/02(土) 19:41:14.95 ID:1euL79Pw.net

>>673
バイナリを書き換えてしまえばいいんじゃね？っていう。

678 ：名無しさん＠編集中：2014/08/02(土) 21:22:54.64 ID:eqaSJCwN.net

Murdocの作りとしては、入力ファイルを逐次読み出しながら、選択したPIDのパケットを出力ファイルに
appendして行く単純なもののように思います。　映像GOPで指定したPTS位置でappend開始するかskipするの
フラグをON/OFF制御しているだけのように思えるのです。　そうであるなら、他のパケットはこれに従うものの、
音声パケットについては、このフラグに関係なく、パケットごとにPTSを調べてappendするかskipするかを
決めるようにすると、切断点で放棄部分に対応する音声パケットが残存することもなくなりますし、
末尾部分で音声パケットが切り捨てられることもなくなると思います。　要するに、連結されている数万、
数十万の車両を順に調べて、最初にPIDフィルタリングしたのち、廃棄用線路に入れるか、収集用線路に
入れるかポイント切り替えを行って、結果として収集用線路側に目的の編成列車が出来上がるように
すればいいわけで、現状は指定GOP到達の時のみポイント切り替えしていますが、これを1パケットごとに
チェックして切り替えるように改めたいと思います。
切断点指定のGUIが面倒なのですが、Murdocには切断点指定(領域選択)をファイルに出力する機能が
あるようなので、これが使える(十分な精度でPTSが記述されている)のであれば、ファイルin/ファイルout
のコマンドラインアプリとして自作できそうです。　　とりあえず、領域選択のセーブファイルを見てみます。

679 ：名無しさん＠編集中：2014/08/02(土) 21:35:41.28 ID:DLJioiIO.net

「murdoc cutter用」のソース参考にしたら？

680 ：名無しさん＠編集中：2014/08/02(土) 23:31:55.93 ID:YEDC+uCm.net

要するに音声Delay 0 になる仕様で音声を付け直したTSを出力するツールを作りたいってことかな？

681 ：名無しさん＠編集中：2014/08/02(土) 23:59:23.00 ID:+kUVWsEL.net

頭切りと尻尾切りをやりたいだけなら考え方は問題ないと思うけど、
CMカット用に後で結合を考えてるなら音ズレ以外にも少し注意しないといけない点があるかもよ

映像ストリームの方はGOPの境界が必ずTSパケットの境界と一致する
(GOP間が無効バイトでパディングされている)運用なので適切なTSパケットの捨て方を
する事でゴミを出さずにGOP単位で編集が出来るんだけど、音声ストリームの方は
この手のパディングを行わない運用なので、ADTSフレームの境界がTSパケットの境界と
一致せず、TSパケットを捨てるだけだとほぼ確実にそこにはゴミが存在する

で、２つのTSを単純に結合するとこの関連性のない中途半端なADTSフレームの残骸同士が結合する
厄介な事に(今も実装が変わっていなければ)TvTestはADTSフレームのCRCチェックを行っていないので、
前方のADTSフレーム残骸が正しいADTSヘッダを丸々残していた場合はそれを不正なフレームと検知して
破棄して即座に再syncにかかるという事が出来ず、ノイズが発生したり一瞬音飛びするTSが出来上がる
かも知れないという問題を抱えてる

なので、そこが問題になった場合はカット部分のTSパケットのpointer fieldかadaptationを使って
ゴミを除去する処理が必要になってくるかも知れない

682 ：名無しさん＠編集中：2014/08/03(日) 01:55:54.25 ID:yy+S7Abx.net

おっしゃるとおりですね。
最終的な微調整は、demux-再muxによってdemuxerの同期エラー処理に任せるか、
mpeg2/aac-mpeg2/aacの再エンコードを行って、変換ソフトのエラー処理に任せるか
しかないのでしょうが、音ズレ抑止は使用するツールの仕様に大きく依存します。
放送送出前の送出エンコーダーに入力されるアナログ信号に比較してみた時の、
「完全に音ズレなし」には出来ないとは思いますが、生成TSは論理的には
エラーのないものになるはずで、再生ソフトやCodec変換ソフトには支障なく
使えるものになります。　
パケット単位で含有されるA/Vの時間帯を揃えておくことで、「のりしろ」を使った
簡便カットで見られるようなゴミフレームはなくせますし、音飛びも人が認識できる
範囲以下に収まるはずです。

683 ：名無しさん＠編集中：2014/08/03(日) 02:01:41.78 ID:yy+S7Abx.net

>>680
audio-delay=0 は先頭だけの話ですのでdemux-再muxで簡単にできます。
要はお尻の部分の処理が問題です。　お尻の処置がちゃんとできた後に
「断片接合」の問題が続いていますが、これはエンコーダーやdemuer任せになります。

684 ：名無しさん＠編集中：2014/08/03(日) 03:44:57.92 ID:YfDLxJZr.net

ゴミを無くすのは音声PESと映像PESのPTSを揃えるだけだと無理だと思う

TS境界　PES境界　ADTS境界
--------=========
#a #1 #A
--------
#b 　 　 　 　 　 ________

--------
...
--------=========
#2 #B
--------
...
--------

--------=========
#3
--------
　 　 　 　 　 　________
--------
... 　 　 　 　 　#C
--------

685 ：名無しさん＠編集中：2014/08/03(日) 03:48:24.27 ID:YfDLxJZr.net

自分も最初に実データを見た時は唖然としたけど、AAC音声ストリームは
こういう凶悪な運用になってるので
PESのPTSをキリよく揃えても#Aや#CのゴミはTSパケットやPESフレームと
いう単位では捨てようがなく、#1のPESフレーム境界を#BのADTS境界先頭までズラして
#bのpointer fieldやadaptationを修正(#bの有効長を縮める)して
ゴミを無効化するか、#BのADTSフレーム境界が#1か#2のPESフレーム境界と
一致するよう以降全てのADTSフレームをズラす位しか方策がない
まあどちらかを自動でやってくれるTS結合ツールが分かってるならそれを使えばいい訳だけど

ちなみにADTSフレームは固定で１つ21msなのに>>636でPESがその間隔になっていないのもそのせい
ADTSフレームは展開時データが固定長(1024サンプル)なだけでAAC圧縮データは全く固定長ではないので、
TS境界との不規則な揺れ動きっぷりはマジで酷い
AAC音声の無劣化TS編集が原理的には可能なはずなのに何故かツールを見かけなかったり、
TvTestがCRCチェックの実装を敬遠してる理由もこの辺で、TS回りのツール作る時は甚だ面倒な仕様だったりする

(*)スペース調整を一部ミスって色々ズレたのでそこは自力で補完して眺めて欲しい

686 ：名無しさん＠編集中：2014/08/03(日) 14:41:40.51 ID:+SxsZe/R.net

そもそもTSに出力する必要あんの？
エンコの為なら、むしろTS[出力なんて過程が邪魔くさいだけなんだけど

687 ：名無しさん＠編集中：2014/08/03(日) 15:14:16.20 ID:WBJ0USy0.net

TS関連スレだし人それぞれでしょ。

688 ：名無しさん＠編集中：2014/08/03(日) 16:06:56.44 ID:6qoHOYK7.net

>>686
スカパープレミアムならそうかもしれないが
e2ならTSとして出力してくれる方が色々ツールが使えて捗るだろう？

689 ：名無しさん＠編集中：2014/08/03(日) 17:19:43.94 ID:bZtRGsW+.net

自分的には、映像のみ mp4 に変換してほかは全部そのままな TS の再構築が、
多重音声やら字幕やら考えると理想なんだが、できるようになる気配すらない。
これだけは簡単にトランスコードできる家電に完全に負けてる。

690 ：名無しさん＠編集中：2014/08/03(日) 17:42:32.10 ID:6qoHOYK7.net

そこは家電というよりコピー制限チューナーとでも書くべきじゃね。
昔、B-CAS社に個人情報を渡すのが嫌で生粕をもらうために
そういうチューナーを買ったこともあるしｗ

691 ：名無しさん＠編集中：2014/08/03(日) 17:51:35.26 ID:yy+S7Abx.net

私なりに問題点をまとめると、
Murdocは簡便で使いやすいが、GOP先頭映像パケットでの単純切り離しであるため
(1)切り離された先行映像に対応する音声パケットが取得ファイル先頭に残存する
(2)後続映像GOP以後のパケットが全て切り落とされるために、選択範囲の末尾映像
　のいくつかのパケットに対応する音声パケットが切り落とされてしまう。　別の
　表現としては、対応音声を持たない映像パケットが末尾に存在することになる。
の欠点がある。　これは、出来上がったTS断片を数個使って、これらを並べ替えたり、
任意に配置して接合する、無劣化編集をする際に不都合であり、(1)(2)の欠点を克服
して、全く正確ではないにしろ映像／音声のPTS範囲が揃ったTS断片を用意したい。
断片接合で問題となるGOP/ADTSの境界問題は「無劣化編集」では解決できないので、
現段階では不問とする。

先頭部の(1)については、事後処置が可能でありどうにでもなるのだが、(2)については
必要な音声パケットを喪失しないようにするためには、切り出しツール即ちMurdoc自体を
改造するか、(2)が発生しないような他のカッティングツールを使う必要がある。
目につくフリーウェアcutterでは、先頭/末尾の音声パケットの扱いについての説明がない。
Murdocのクリップリストを活用する方式で自作してしまったほうが確実だろう。

MurdocのGOPファイルは(映像PID番号,,,GOP先頭のPIDの10進表記,開始のパケット番号)を
1行として列記したGOPリストであり、また、クリップリストファイルは(ffffffff)を
デリミタにして、各クリップの（入力ファイル名、PIDリスト[選択フラグ付]、
選択開始GOP番号[32bit]、選択終了GOP番号＋１[32bit]）が列記されているので、
クリップリストファイルに記述されているGOP番号を、元TSのGOPリストファイルから調べれば
選択範囲のPTS範囲を知ることができますし、対称映像GOPのパケット連番を使って、
処理をskipして処理時間短縮もできます。
クリップリストファイルのフォーマット解析結果の確証が得るべく、奮闘中です。

692 ：名無しさん＠編集中：2014/08/03(日) 17:58:37.76 ID:YpV+0Kst.net

細切れにした後で編集をしたいというのはかなり特殊なニーズだから自分で作るしかないな

693 ：名無しさん＠編集中：2014/08/03(日) 18:04:36.12 ID:bZtRGsW+.net

>>690
揶揄するのは勝手だが、ただのチューナーじゃトランスコードできねえよｗ

694 ：名無しさん＠編集中：2014/08/03(日) 18:29:33.95 ID:yy+S7Abx.net

>>692 CMカットも「細切れにした後で編集」ですよ。　特殊なニーズとは思いません。
特殊な例としては、イントロタイトル部分がstereoで本編が5.1chの映画コンテンツを、
タイトル部分と本編を分けて、本編を強制5.1ch変換して、全編が5.1chのコンテンツにしたり、
NHKアーカイブスで座談会部分は日本語のみ(1トラック)、本編が2か国語(2トラック)のものの場合、
座談会を強制2トラック化したのち、本編とマージして全編２トラックのものにするような場合があります。

695 ：名無しさん＠編集中：2014/08/03(日) 18:54:10.17 ID:6qoHOYK7.net

>>693
普通にできるだろ、牛のチューナーとか使えば。

696 ：名無しさん＠編集中：2014/08/03(日) 18:58:27.45 ID:YpV+0Kst.net

普通、CMカットとかは編集のときにやるから
カットツールで細切れにしたファイルを編集ツールに読み込んでもう一回切り直してくっつけるなんて二度手間はしない

697 ：名無しさん＠編集中：2014/08/03(日) 18:58:57.39 ID:bZtRGsW+.net

>>694
いや、普通のＣＭカットは、細切れと同時にエンコじゃね？
エンコしない人は多少余裕を持たせて切っとくだけ。
あなたがなぜそれで満足できないのかイマイチわからんが。

音声については、自分はいじりたくないかなあ。
つか、ＣＭこそ保存しておく意味があると思いカットしないので、
本編モノラルＣＭステレオとか再エンコしない限りどうしようもないし。

698 ：名無しさん＠編集中：2014/08/03(日) 19:09:22.73 ID:bZtRGsW+.net

>>695
それはチューナーじゃなくてチューナー用ソフトがやってるだけだろ。
牛は家電じゃねえしｗ

……つか、牛のソフトでそんな高度なことできんの？
本当ならそっちがビックリなんだが。

699 ：名無しさん＠編集中：2014/08/03(日) 19:27:06.68 ID:YfDLxJZr.net

>>697
無劣化編集という部分の価値をどう見るかって話じゃないかな
5.1chの場合はまた話が違って来るけど、モノラル→ステレオはADTSフレームの構造上再エンコとか必要なく無劣化で可能だと思う
もう1ch分同じAAC圧縮データを含ませてADTSヘッダのsf_index、CRC、frame_lengthとかその辺を修正するだけ
確かTvTestがモノラル音声を再生する時も同じような処理をやってたからレベル調整も発生しないんじゃないかな

問題はADTSの修正じゃなくてそのガワである所のPESの辻褄合わせが激しく面倒臭いって所なんだけどな…

700 ：名無しさん＠編集中：2014/08/03(日) 19:33:05.88 ID:6qoHOYK7.net

>>698
高度なことってそのぐらい普通じゃね?
PTやPXが限定的な機能しか搭載させてないだけだしな。

701 ：名無しさん＠編集中：2014/08/03(日) 19:36:09.08 ID:DcG6xuDt.net

俺はバッファローのHDDレコーダーとかのことを言ってるのかと思ってたよ
チューナーも色々だな

702 ：名無しさん＠編集中：2014/08/03(日) 19:37:56.87 ID:YfDLxJZr.net

あーすまない、意味を取り違えた
想定してるのは本編のモノラル→ステレオ化じゃなくてCMのステレオ→モノラル化での一本化の方か
そりゃ再エンコしない限り無理だ、どうしようもないわ

703 ：名無しさん＠編集中：2014/08/03(日) 22:08:33.67 ID:WBJ0USy0.net

>>689
mp4エンコで、aacコピーすりゃいいんじゃないの。字幕もsrtとかでいいだろうし。どうしてもtsなのかねぇ。

704 ：名無しさん＠編集中：2014/08/03(日) 22:41:59.83 ID:yy+S7Abx.net

TV-captured-TS(mpeg2/aac)の話に終始しているけれど、BD-VideoやAVCHDで
使われる.m2ts(H.264/ac3)のTSファイルの編集について語りたいね。
h264ts_cutterやH.264-m2tsの編集ができるといわれているTSsniperの性能は
どうなのでしょうか？

705 ：名無しさん＠編集中：2014/08/03(日) 22:53:36.63 ID:ga6pvkUe.net

そこら辺はTMSR4が出て以来死滅した気がする

706 ：名無しさん＠編集中：2014/08/04(月) 03:23:06.24 ID:+fye/ehZ.net

>>705 TMSR4は金持ちのツールだろう。
　フリーウェア、できればソース公開のLINUX上で動かせるものがいい。

707 ：名無しさん＠編集中：2014/08/04(月) 03:28:38.26 ID:GfWv4vN0.net

TSつってもそれスレ違いだろ

708 ：名無しさん＠編集中：2014/08/04(月) 07:05:13.26 ID:48ull2G3.net

>>699
圧縮音声って、ジョイントステレオやらなんやらあるし、簡単じゃないと思ってたわ。
実は、無理矢理統一させようとヘッダ書き換えてみたことあるんだけど、
修正箇所が足りなかったのか単なるノイズになってしまったしｗ

>>702
いや、多少の劣化はともかく、情報が根本的に失われるのは論外という考えなので、
やるとしたらモノラルをステレオだよ。

＞問題はADTSの修正じゃなくてそのガワである所のPESの辻褄合わせが激しく面倒臭いって所なんだけどな
こういった変換が許されるくらいなら、
とりあえず単一のビットデータ列にしてから、パケットを再構築でいいんじゃないかな。
断片ごとの DELAY が揃わないのはとりあえず気にしないみたいだし。

709 ：名無しさん＠編集中：2014/08/04(月) 07:05:47.16 ID:48ull2G3.net

>>700
いや、>>689 のことだよ？
家電の場合、多重音声や字幕が元の TS(DR) と同様に扱えさえすれば、
内部的に TS で再構築されている必要はないが。

>>703
うん、今はそれで妥協してる。
.srt だと位置情報とか残せないので、.ass を別ファイルで。
ただ、TS の字幕は複雑怪奇だし
アニメーションアイコンなんかの再現は根本的に無理なので、>>689 が理想。

710 ：名無しさん＠編集中：2014/08/04(月) 10:32:28.39 ID:F2masugw.net

それいいなあ
映像のみmp4差し替えtsが簡単に作れるようになると嬉しいなー

711 ：名無しさん＠編集中：2014/08/04(月) 11:12:38.14 ID:iceRW9dQ.net

スレのレベルが夏休み
687といいmp4はコンテナだぁー

712 ：名無しさん＠編集中：2014/08/04(月) 11:13:15.97 ID:+fye/ehZ.net

>>710 言葉の使い方の間違いなんだろうけれど、
「mp4」はコンテナの名称だから、「mp4のTS」というのはあり得ない。
「映像がH.264のTS」の意味だろうと思うけれど。。。。
.264と.aacをmp4box(yam)でmuxすれば出来るよ。

713 ：名無しさん＠編集中：2014/08/04(月) 13:03:01.51 ID:I5/zQ9SJh

放送TSのMPEG2Video部分のみをH264に入れ替えたいという意味だと思われ

714 ：名無しさん＠編集中：2014/08/04(月) 15:04:15.25 ID:LNvYrdFe.net

それって字幕とかEPGとかデータ放送とかもろもろ全部再現できるの?

もともと>>689は映像以外ぜんぶそのままなTSってことなんだが...

715 ：名無しさん＠編集中：2014/08/04(月) 15:13:47.86 ID:+fye/ehZ.net

ケツはちゃんと拭いておかないと、パンツをはいたときトラブルになる。

TS先頭部分の先行部残留音声パケットについては、音ズレ対策として
Codec変換の事前、あるいはCodec変換時に処置するのが普通だが、
TS末尾については無対策でCodec変換することが多いのではないだろうか。
TS(mpec2/aac）から.m2ts(H264/ac3)への変換を例にとると、変換処理に続いて
生成された.264と.ac3をmuxして.m2tsを作るが、TSmuxerなど殆どのmuxアプリは
長さの違う映像PESと音声PESを単純に混合するだけなので、(audio-delay)と同程度分
だけ映像が長い(遅く終わる)姿の.m2tsができる(末尾のこれを「末尾audio-delay」と
呼ぶことにする)。
複数個の.m2tsをAVCHDやBD-Videoにオーサリングする際、個別タイトルとする場合には
問題がないが、タイトルヘッダーやイントロ動画などと本編を1塊にして１タイトルとして
オーサリングソフトに入れたい時には、TSmuxeRのJOIN機能を使って複数本の.ts/.m2tsを
連結してmuxし1本の.m2tsとすることになるが、JOINは単純マージとPTSの付け直しであり、
muxerは映像パケットは映像パケットだけで通しPTSを付け、音声は音声だけでPTSを
振りなおすため、連結部では前段部分の映像に後段部分先頭の音声が対応することになり、
結果として接合部分以降は音声が「末尾auio-delay」分だけ先に再生されるものが出来
上がってしまいます。　「末尾audio-delay」の解消は1つのTSだけの場合には気にしなくて
いいのですが、複数を接合する際には解消しておかないと後でトラブルの原因になります。
　CMカットなどでは先行部残留音声パケット、欠拭き処理は意識せずに、単純接合して、
一つの全体TSを作成し、出来上がったTSの先行部残留音声パケット処置をするだけのやり方でも、
音ズレなく再生できるTSや変換成果物を得ている人も多いと思います。　これは、
接合部では「末尾audio-delay」の余分映像パケットに続行断片の先行部残留音声パケットが
対応することで、PTS増減が相殺されて認識限度内(0〜50msec程度)のずれに収まりますので、
見かけ上は音ヅレが認知されずに再生されるのだと考えます。

716 ：名無しさん＠編集中：2014/08/04(月) 17:19:27.69 ID:+fye/ehZ.net

「TS-timekeeper」なるソフトがあって、PTSをそろえてくれるそうだが、
多分このソフトは、先頭部の先行残留パケットを切り落として、映像／音声の
開始PTSをそろえて、以後は映像パケットと音声パケットとを各々独立に
通しのPTSを振付けるものではないのかな。　これも多分ケツ部分の処理は行わないのだろうな。

717 ：名無しさん＠編集中：2014/08/04(月) 17:42:01.35 ID:6Db+WJif.net

ダウンロードして同梱されてるソース読めば分かることを「多分」とか

頭おかしいのかお前

718 ：名無しさん＠編集中：2014/08/04(月) 21:47:56.48 ID:+fye/ehZ.net

ダウンロードして同梱されてるソースを読みましたが、やっぱり想像どおり、
PTSを通し番号に付け直しているだけでした。　ケツは拭いていないし、後続
断片の先頭での先行残留パケット除去も行う仕様ではありませんでした。

719 ：名無しさん＠編集中：2014/08/05(火) 04:02:55.78 ID:RcOkvBh/.net

なんつーかおまえの書き込みって表現がグロすぎるな。

720 ：687：2014/08/05(火) 07:38:50.52 ID:meBzT9BR.net

>>711
うわ、恥ずかしい。
x264 に .mp4 作らせて .aac と mux させてるので、頭の中ですっかり mp4 になってたぜ。
はい、MPEG-4 AVC/H.264 のつもりでした。

721 ：名無しさん＠編集中：2014/08/05(火) 07:58:56.66 ID:meBzT9BR.net

>>715
＞　CMカットなどでは先行部残留音声パケット、欠拭き処理は意識せずに、単純接合して、
＞一つの全体TSを作成し、出来上がったTSの先行部残留音声パケット処置をするだけのやり方でも、
＞音ズレなく再生できるTSや変換成果物を得ている人も多いと思います。　これは、
＞接合部では「末尾audio-delay」の余分映像パケットに続行断片の先行部残留音声パケットが
＞対応することで、PTS増減が相殺されて認識限度内(0〜50msec程度)のずれに収まりますので、
＞見かけ上は音ヅレが認知されずに再生されるのだと考えます。
いや、そんなこと日常的にやってる人は少ないと思うよ。
Murdoc Cutter で中抜きして音ズレしたというのをよく見かけるので、
やって使いものにならないと気付いた人は沢山いそうだが。
ズレるのわかりきってるので試したことないけど、
カット箇所が多いと誤差が蓄積されてどうしようもないかと。

あなたの考える末尾調整をしたところで、これと似たような状態にしかならないので、
今まで誰もやろうとしなかったんではないかな。
TS としてきちんと同期再生できるなら、いずれにせよ問題ないわけだし。

念のためだが、ts2aac -M での誤差は蓄積されず
どのタイミングにおいても最大で 10ms ということなので、
認識できるようなズレにはならない。