630 :
名無しさん@編集中:2014/09/03(水) 19:13:56.87 ID:H2sVwh/v
>>624 なんでMicrosoftの過去の遺物である「Avisynth」なんか使っているの?
HDTV時代ではffmpegとx264、Mp4boxとTSMuxerで十分だろう。 入力は
Captured_TSだと思うが、エラーや虫食いのないTSを入力する限りは、音ズレ
は発生しないよ。 ffmpeg/x264共に映像PTSと音声PTSで同期をとって両者各々の
頭出しをするので問題はありません。 無理やり分離してから個別にエンコード
するなら、Murdocを改造するなどして、先頭映像GOPに残存する、切り落とされた
先行GOP対応の音声パケットを除去したり、demux-muxを行って、映像開始PTSと音声開始PTSの時間差を
最小限にとどめておく必要があります。 また、CMカットなどマージ処理を行う際には、
TSの先頭だけでなく末尾についても同じようにPTS揃えを行っておかないと、
接合によって接合箇所以後の音ズレが出ますので、最低限でもPTSによる
パケット選別を行って映像長さと音声長さをそろえておく必要があります。
接合をしないのなら、末尾の処置は不要でしょう。
631 :
名無しさん@編集中:2014/09/04(木) 22:03:32.74 ID:wRbYSvw1
音ズレ対策用にMurdocのクリップファイルを使って、映像音声をほぼ同期して
切り出すツールを作りました。 「無劣化TSカッター(Murdoc利用)」
http://filescase.com/ にUPしてあります。
パス=「1234」です。 大したものではありませんが、使ってみてください。
632 :
名無しさん@編集中:2014/09/04(木) 22:27:04.93 ID:wRbYSvw1
>>631 aftermurdoc.exeで切り出した後で、出力ファイルをTSmuxeRにかけて、
demuxを行い、.m2vと.aacを再度TSMuxeRでmuxすれば、開始PTS=00:10:00
で連続したPTSを持つきれいなTSが出来上がります。
(TSMuxeRでのdemux時にエラーメッセージが出ますが、音声パケット連番
不連続の付け替えのメッセージですので無視してください)
Murdocで切っても音欠けはしても別に音ズレはしないけど
634 :
名無しさん@編集中:2014/09/05(金) 00:06:02.39 ID:PvdQZgXN
>>633 aftermurdocを使うと、音欠けがなくなります。
単一のクリップでは、Murdocで単純切り出しでも、通常のエンコーダーの場合、
頭出し同期をするので音ズレしません。 また、CMカットなどのように複数断片の
接合がある場合、先行クリップの切り落とされた最終GOP対応音声パケット長が、
次のクリップ先頭の切り落とされた先行GOP対応音声パケットで補完されるので、
結果として音ずれを感じなくなります。 前のクリップ最後の音欠けが次の
クリップのゴミ音で代替されるわけです。 aftermurdocを使うと、前が音欠けせず、
後ろのゴミがなくなりますが、200msec〜400msecのdurationの話であり、画像も
切り替わるので気が付かないことが多いと思います。
aftermurdocの効果は独立にクリップ収録された2つのTSファイルを接合する際に、
顕著に表れます。 というのは、ほとんどのエンコーダーは出だしの頭合わせは
行いますが、末尾の尻合わせは行わないので、生成.m2tsなどを接合した際には、
前段ファイルの映像長/音声長のずれが、後続部分の音ズレの原因になってしまいます。
aftermurdocを使うと、これが抑止できます。
音ズレ確認はAviUtlプラグインの「ちょっと音再生(MAD用)」で1フレーム単位で行うから
200msどころか33ms単位で気付く
>>630 TSファイルをx264で変換する場合、
Avisynthを使わない場合、Avisynthでしていたフレーム単位の編集、
インターレース解除、リサイズ、各種フィルタはどうやってするんですか?
その説明ではよく分りません。
637 :
名無しさん@編集中:2014/09/05(金) 14:58:20.12 ID:PvdQZgXN
>>636 Mencoderでの前処理、およびオプションパラメーターの設定で逆テレシネやインタレ
解除、画素クリップ、トリミングなど可能です。 Mediacoderを使えばパラメーター設定を序動的にやってくれます。
フレーム単位の編集(切り落としかな)の必要性がよくわかりませんが、必要がないのでは?
ffmpegの時間指定がもうちょっと細かくできるようになればいいんだけどな
639 :
名無しさん@編集中:2014/09/08(月) 21:21:45.76 ID:5RWVbZHq
音ズレ対策用にMurdocのクリップファイルを使って、映像音声をほぼ同期して
切り出すツールを作りました。 「無劣化TSカッター(Murdoc利用)」
http://up.mapopi.com/ にUPし直しました。
パス=「7890」です。 大したものではありませんが、使ってみてください。
これ、あっちのと同じもの?
キー通らんがな
642 :
名無しさん@編集中:2014/09/09(火) 03:41:58.22 ID:vYJSAl3z
>>641 ごめんなさい。 キーの設定を間違えていました。
上げ直して、落とせることを確認しましていますので、ヨロシク。
643 :
名無しさん@編集中:2014/09/11(木) 18:29:40.73 ID:HG945PbQ
>>642 少し、手直ししましたので、パスなしでUPしなおしました。
644 :
名無しさん@編集中:2014/09/12(金) 23:22:16.42 ID:gBnzVoM6
TSSniper_0_80_0_600でも映像/音声を出来るだけ同期したクリップが出来ますが、幾つかのTSSniperの出力ファイルを調べたところ、
全てのTSについて、音声のクリップ動作は開始部分では映像開始時刻より数ミリsec遅れたPTSを持つから開始するので、
映像/音声が揃っていますが、末尾部分では映像終了時刻を過ぎて、更に50〜80msecの間、映像より長く音声パケットをクリップして
いることがわかりました。 そのような仕様にした理由は不明ですが、各クリップでは常に映像長より50〜80msec長い音声長が
取られる動作をしています。 この為、CMカットなど断片数が多い断片接合ファイルの場合、PTS参照で再生するplayer(TVtestなど)では
ちゃんと再生できるのかもしれませんが、demuxerや通常のエンコーダー(DODEC変換ツール)のように、頭合わせだけで以後は映像/音声が
別々に処理されるアプリでは、後ろに行くほど音声が遅れる性質を持つ成果物が得られてしまいます。 TSSniperでは10か所接合すると、
音声遅延は0.5〜1秒にもなりますが、afterMurdocを使ったやり方ですと±10msec程度に収まります。
また、単一断片の場合、(音声長−映像長)はMurdoc-Cutterのみでは -(マイナス)250〜500msec、TSSniperでは+(プラス)50〜80msecなので、
.mp4や.m2tsなどの成果物をマージした際には、Murdoc由来のTS入力で作成した.mp4/.m2tsでは再生すると接合点以降は音声が先行する
統合物得られ、TSSniper由来のTSで作った.mp4/.m2tsでは再生すると接合点以降で音声が遅延する統合物が得られてしまいますが、
MurdocCutter+aftermurdocで作ったTS由来の.mp4/.m2tsでは統合しても、音ズレは20msec以内になるはずです。
645 :
名無しさん@編集中:2014/09/22(月) 00:51:19.57 ID:it7fk+RH
「aftermurdoc Rev.4」
MurdocCutterで作ったクリップリスト利用の無劣化TSカッター(Murdoc利用)を
http://up.mapopi.com/ にUPし直しました。
書き出し時間が元のMurdocと同程度になりました(若干速いかも)。
647 :
名無しさん@編集中:2014/10/18(土) 20:38:04.46 ID:eBy4bJpA
>>646 一般論ですが、、、
元のTSをMurdocのパケットチェック機能でエラーがないことを確認し、
終始一貫して同じ音声モードになっていることを確認しておいてください。
Stereo-mono-Stereoやstereo-5.1のようになっているTSでは音ズレが出て
当然です。 CMカットのように断片接合したものでは、接合の仕方が悪いと
音ズレしますよ。
Mediacoderでx264変換する場合は、パラメーター設定をちゃんとやらなければ、
変換自体がコケてしまいますので、設定には気を付けてください。
648 :
名無しさん@編集中:2014/10/18(土) 20:48:03.47 ID:eBy4bJpA
当方はMediacoderでmpeg2/aac/ts→H.264/AC3/m2tsを日常的に行っていますが、
事前にTSをTSmuxerにかけてDemuxして.mpvと.aacを作り、これを再度TSmuxerで
muxして、先頭のPTSが揃ったTSをgetし、これをMediacoderで処理します。
Mediacoderのsource/format/encoderの設定は映像:mencoder/h.264/x264、音声:auto/AC3/ffmpeg
出力コンテナはM2TSです。 H.264/LC-AAC/mp4への変換の場合は映像:mencoder/h.264/x264、
音声:auto/LC-AAC/neroで出力コンテナをMP4にします。
>>645 試してみました
GopファイルをソースTSと同じフォルダに置いて、
murdoccutterで編集して、saveで生成されるbinファイルが入力ファイルになるんですよね?
>aftermurdoc.exe c:\tmp\hoge.bin c:\tmp\hoge.ts
0バイトのtsファイルが生成されるのみで、うまく動作させられません
以下メッセージ
1th clip from sourcefle: D:\VIDEO\hoge.ts
******* start/end bytes ***
ca 00 00 00 9b 0f 00 00
201th GOPfile line: 100E,,,1356106744,836391
202th GOPfile line: 100E,,,1356151789,839565
3995th GOPfile line: 100E,,,1521265738,14825491
******* preset clip parameters *********
start gop = 202(0x000000ca)th ( 839565th packet), pts= 1356151789(0x050d53bed)
HH:MM:SS startpts = 04:11:08.3532, floating startpts = 1356151789.000000
end up to gop = 3995(0x00000f9b)th ( 14825491th packet), pts= 1521265738(0x05aacac4a)
HH:MM:SS endpts = 04:41:42.9526, floating endpts = 1521265738.000000
check up to gop = 3997(0x00000f9d)th ( 14830248th packet), pts= 1521355828(0x05aae0c34) sum= 13990683 packets
1th clip PID list:
PID type name
続く
********** 1th clip list end ******
1th clip(packets) start from 839565th untill 14830248th : 13990683 packets
1 th SELECTED clip( GOP ) start from 202th untill 3995th : 3793 GOPs
1 th SELECTED clip(PACKETS) start at 839565th untill 14825491th : 13985926 packets
clip MARGIN = 900.000000
1th clip: read stopped at 14825491th packet
between SELECTED GOPs: wpackets=0 wpackets(total)=0
end gop = 3995(0x00000f9b)th ( 14825491th packet), pts= 1521265738(0x05aacac4a)
HH:MM:SS endpts = 04:41:42.9526, floating endpts = 1521265738.000000
check end gop = 3999th ( 14830248th packet) sum= 13990683 packets
clip MARGIN = 900.000000
1th ADDITIONAL tail clip(packets) start from 14825491th untill 14830248th : 4757 packets
between ADDITIONAL GOPS: wpackets=0 wpackets(total)=0
********** 1th clip output 0 packets appended ******
********** Summary ********(starting top audio-delay is ignored)
Clip No. Source start end duration diff(start) diff(end) diff(duration) diff(sum)
0 th:D:\VIDEO\hoge.ts
video(0000): 04:11:08.3532 -- 04:41:42.9526 00:30:34.5994
上記binファイルは、murdoccutter用のMurdocBatch.exeを使うと正常にファイルが出力されます。
使用法が何か間違ってますか?
ついでに要望ですけど、出来ればgopファイルは場所を指定出来るようにするか
MurdocCutterの保存設定した場所に対応してくれる嬉しいです
それと、上書き警告なしで強制的に上書き出来るオプションもあったほうがいいかな
651 :
名無しさん@編集中:2015/01/19(月) 04:46:12.79 ID:wCCRj9Fg
>>649-650 「aftermurdoc.zip」のreadme.txtに書かれているが、
「 MurdocCutter(19g1)で作成したクリップリストファイルとGOPファイルをもとに、TSファイルの無劣化クリップを行います。
1.9f4以前のMurdocCutterではクリップリストのファイル保存機能がありませんので、Murdocは19g1にバージョンアップしておいてください。
選択PIDの指定はMurdocの左側ウィンドウ左下の「PID」ボタンを押して、必要なPIDを選んでください(PAT,PMT,PCR,Video,Audioが必須です)。
クリップファイルはMurdocの右側ウィンドウ右下の「Save」ボタンを押して作成します。 MurdocCutterの仕様ではPIDが選択モードで指定されて
いないとクリップファイル中に選択PIDリストが作成されませんので、aftermurdocの出力は空になります。 切り落とすPIDがなくて選択モードにできない場合には
使うことのないNetworkのPIDの選択チェックを外せば選択モードになりますので、Network(不要)を外してください。」
652 :
名無しさん@編集中:2015/01/19(月) 05:09:08.98 ID:wCCRj9Fg
>>649-650 MurdocCutterは入力TSをロードした際のデフォルトだと、PIDボタンで表示すると
全PIDに選択チェックが付いているが、この状態でクリップリストファイル(.bin)
を作ると、.binの中には選択PIDリスト情報がない仕様になっています。 MurdocCutterの
仕様(バグ?)ですので、どうしようもありません。
選択PIDリストを.bin中に書くには、PIDボタンで表示されたPID群の1個以上の
チェックマークをはずしておく必要があります。 各クリップ個別のPIDを右側のPID
ボタンで調べた時、選択PIDが表示されないクリップには.bin中に選択情報が書き込まれませんので、
.binの書き出しの前に全クリップの各々についてちゃんと選択PIDが指定されていることを確認しておかなければいけません。
PID指定がないクリップに対応する出力は0バイトです。
−−−.binファイルをダンプして、解析するとMurdocの仕様(バグ?)がわかります。
653 :
名無しさん@編集中:2015/01/19(月) 17:44:17.10 ID:wCCRj9Fg
>>649-650 >>ついでに要望ですけど、出来ればgopファイルは場所を指定出来るようにするか
MurdocCutterの保存設定した場所に対応してくれる嬉しいです
それと、上書き警告なしで強制的に上書き出来るオプションもあったほうがいいかな
.binファイルの中に各クリップの元のTSとGOPファイルの絶対パスが書き込まれていますので、
TSファイル、GOPファイルの場所はクリップごとにここから読み込みます。
GOPファイルはMurdocでスキャンした際にTSファイルと同じフォルダーに名前を自動生成して書き込まれますので、
これらを変更することはトラブルのもとになります。
強制上書きオプションは間違って上書きしてしまう悲惨な状況を避けるために、用意すべきではありません。
tsMuxeRで音声DEMUXすればデレイ0のAAC出力してくれる
655 :
名無しさん@編集中:2015/02/01(日) 16:46:24.33 ID:p5QuhjWL
>>654 そのとうりだ。
しかし、先頭は揃うが、末尾については全くなにもしてくれない。
1分の.mpvと2分の音声をTSMuxeRすると、映像1分間、音声2分間のTSになります。
MurdocCutter用がいかに優れているか再認識した
657 :
名無しさん@編集中:2015/02/10(火) 10:32:29.92 ID:OISDMrmG
aftermurdocを試しましたが、番組情報がありません。tsを保存する場合ぜひともほしいものなので何とかならないものかと。
658 :
名無しさん@編集中:2015/02/10(火) 14:06:22.51 ID:qnA+O++1
MurdocCutterの仕様ではPIDの非選択モードでクリップする場合は
選択GOP範囲の全パケットを出力ファイルにコピーしますが、PID
選択モードで出力ファイルに転送するPIDが指定されている場合は、
指定されたPIDのパケットのみ出力ファイルに転送するようになっています。
番組情報(EIT)など放送のTSに特有であって、一般のTSファイルの中の
パケットとしては使われないパケットは、PID選択の対象にはなっておらず
指定することができません。 この為、PID選択モードでクリップを設定すると、
本来のMurdocCutterの出力でも、EITが含まれない出力になりますので、
EITを含んだ出力を得るためにはPID非選択モード(PID選択を行わない状態、
左側のPIDボタンではPIDが選択されているように表示されるが、
実は右側のPIDボタンで確認すると選択されたPIDがない)でクリップを
設定しなければなりません。 MurdocCutterはPIDの選択指定がないと、
単純に指定GOP範囲内の全パケットを出力し、クリップリストファイル
(.binファイル)にも選択PID情報が書き込まれません。
aftermurdocはMurdocCutterが作成した選択PID情報を.binファイルから
読み取って出力対象とすべきPIDを決定しますので、.binファイルに
EITのPIDが書かれていない以上、EITパケットを出力に含ませられません。
選択GOP範囲にtail部の音声はみだし部分を加えた範囲のPID取捨選択に限って、
他の全パケットは出力するようにするか、MurdocCutterのPID選択を無視して、
aftermurdoc側で別途PID選択画面を用意するように書き換えればEITを
含めさせることもできると思いますが、もともとエンコーダーへの入力を
事前に適正化するために作ったものなので、エンコーダーに悪影響を与える
可能性のある(少なくともパフォーマンス低下がある)パケットを出力に含める
改造には気が進みませんね。
659 :
名無しさん@編集中:2015/02/10(火) 23:21:30.16 ID:OISDMrmG
詳細な説明に感謝です。最強の組合わせと思ったのですが残念です。
bcaslist
661 :
名無しさん@編集中:2015/02/20(金) 09:22:32.04 ID:teE9344s
この件で対策スレの方でいいのか分からないんですか・・・
先ほど問題が出たので質問を
PT3にて録画ファイルで、たまに音がずれているファイルが出来ますが
原因としては何があるんでしょうか?そして解決方法はありますか?
Aviutlで見てみると、どうやら全体がぐっとずれてるんではなく
徐々にずれてるようなんです
また最初は合っている、ではなく番組冒頭からすでにずれています
.errファイルの方は問題なく0となってます
CMごとにずれてしまうとかあるんでしょうか?
放送の質だとしても毎日同じ時間に録ってるファイルなのにいきなり今日出たり
HDDを始め同じ環境なのにそれだけずれるとか
どう考えたらいいものかと
前後の番組は問題無しです
そんなファイルは出来ない
プレイヤーが糞か入力プラグインが糞かPCスペックが糞なだけ
663 :
名無しさん@編集中:2015/02/21(土) 04:15:40.83 ID:1Rf7h3hn
>>661 再生に使用するプレーヤーソフトの問題だと思います。
664 :
名無しさん@編集中:2015/02/25(水) 23:40:51.00 ID:Z2MhGhu4
「Rev.7 MurdocCutterで作ったクリップリスト利用の無劣化TSカッター(Murdoc利用)」
を
http://up.mapopi.com/ にUPしました。
従来は、開始GOPの前方参照Bフレームに音声開始をセットしていましたが、
Iフレームに音声開始位置をセットするように変更しました(約67msec異なります)。
試してみてください。
665 :
名無しさん@編集中:2015/03/01(日) 01:03:21.52 ID:O9SDrh51
>>664 前後カットのみの単独クリップだと、I-フレーム時刻基準の音声カットの方が、
そのまま無補正で扱えるエンコーダーが多いので、I-フレーム時刻基準を用意したのですが、
CMカットのように多数のクリップを接合する場合には、I-フレーム時刻基準だと
TSmuxeRでdemux-Muxすると、接合部移行で音ズレが出てしまうことが多いことがわかりました。
そこで
(1)aftermurdoc.exe: B-フレーム時刻基準の音声カット
(2)aftermurdoc-zero.exe: I-フレーム時刻基準の音声カット
の2種類を用意しました。 作成TSの事後利用に合わせて、使い分けてください。
?
667 :
長文書くぞ:2015/03/04(水) 18:48:39.54 ID:XpgAtruG
TSファイルの中でのGOPの各映像フレームの出現順序は、時刻の若い順に収納されてはいません。
GOP中最初に出現するIフレームを0番とし、次の時刻のフレームを1番、2番、、、と表現することに
すると、TSファイル先頭部分での映像フレームの出現順序は
0番(I)、−1番(B)、−2番(B)、1番(I)、、、の順になっています。
10:00:00から始まるGOPがMurdocCutterで表示されるとき、Murdocが画面表示するのはIフレームですので
この画像のPTSの表示は10:00:66になっています。 仮に、10:00:66の画像が表示されるGOPから、
20:00:66の画像が表示されるGOP(クリップされるのはこの直前)までをクリップ指定した時、
作成されるTSファイルの映像範囲は10:00:66-20:00:66ではなくて、10:00:00-20:00:00になります。
従って、クリップファイルに含む音声パケットの範囲も、10:00:00-20:00:00にするのが正しい姿
(「ノーマルTS」と命名)と考えられます。
しかしながら、先頭部分の-1番(B)と-2番(B)フレームは先行するGOPが存在しないため意味を持たず、
再生ソフトやエンコーダーではこの部分(67msec)の映像は無視することになります。
この為、これに合わせてTSの音声範囲を10:00:66-20:00:66とした(「BタイプTS」と命名)ほうが都合がよい
再生ソフトやエンコーダーソフトも多く存在します(末尾を20:00:66とするのは、分割したものを
再結合した際に原状復帰できるようにするため)。 正確には時刻範囲を設定値に一致させることは
できませんが、作成するTS目標を「ノーマルTS」にするのか、「BタイプTS」にするのかは、適切に
選択すべきです。
668 :
長文書くぞ:2015/03/04(水) 18:49:50.26 ID:XpgAtruG
TSファイルでは定義がはっきりしない「audio-delay」というパラメーターは、先頭音声パケットのPTS
と先頭映像パケットのPTSの差ですが、この際の先頭映像パケットを無効である-2番(B)を取るか、有効な
0番(I)をとるかで67msecの違いが出てきます。 例での映像/音声ともに10:00:00-20:00:00の
TSパケットのaudio-delay値はTsMuxeR(Bフレーム基準)では0msecですが、MediaInfo(Iフレーム基準)では
-67msecになります。 解析ソフトで表示されるTSのaudio-delay値はどちらの基準で算出されているものかを
確認しておくべきでしょう。 少なくとも、解析ソフトのaudio-delayの算出基準とエンコーダーのaudio-delay
補正値の算出基準が同じなのか違うのかを知っていないと、誤りを犯すことになります。
TSの先頭部分の音声がBフレーム相当時刻(上例では10:00:00)から始まろうが、Iフレーム相当時刻
(上例では10:00:66)から始まろうが、 映像/音声のPTSの同期をとりながらハンドリングする良質の
再生ソフトやエンコーダーソフトでは、10:00:00-10:00:66の音声があっても、これを無視しますので、
「ノーマルTS」/「BタイプTS」のどちらを使っても同じ結果になりますが、映像と音声を分離して
各々、独立の処理を行った後にMUXする作りのソフト(処理高速化のために大半がこのタイプ)では
audio-delay値に応じた補正が必要であり、無補正でも音ズレがnegligible-smallになるようにするには
「BタイプTS」が便利です。 エンコーダーソフトでは、ノーマルTSの場合には67msec分の補正パラメーターを
与えなければならない物が多いように感じます。
669 :
長文書くぞ:2015/03/04(水) 18:51:09.98 ID:XpgAtruG
「ノーマルTS」、あるいは(audio-delay < 0)のTSを入力した場合、エンコーダーの同期動作としては
(1)音声はそのまま最初からの音声を使い、映像は最初の2フレームのBフレームの代わりにブラック画面を挿入する
(2)映像は先頭の2つのBフレームを無視し、音声は最初の67msec分を捨てる
(3)映像は先頭の2つのBフレームを無視し、音声はそのまま最初から全てを使う
の3つの扱いが考えられます。
また、audio-delayが数100msecと大きなプラス値のTS(最初部分が音なし)を入力した場合、
(1)映像はそのまま使って、音声は無音を挿入して補てん
(2)音声が出現するまでの映像フレームを破棄
加えて、末尾部分でも先頭部分と同様の同期操作が必要です。
先頭、末尾についての同期処理(特に末尾の処理)については、どのような処理を行っているかを説明していない
アプリが殆どなのでアプリの選択には注意が必要です。
常時使うアプリがどのタイプなのかは把握しておいたほうがよいと思います。
670 :
名無しさん@編集中:2015/03/04(水) 20:41:33.99 ID:XpgAtruG
「映像/音声のPTSの同期をとりながらハンドリングする良質のエンコーダーソフト」
のつくりとしては、PTS同期チェックをしながらパケット選別して、映像/音声の
両パケットを仕分けして、パイプで映像エンコーダー」と音声エンコーダーに
渡していきつつ、逐次処理する作りのものがベストと思います。
最初に、映像/音声を完全分離して別々のファイルを作成したのち、個々に
エンコードするやり方では、音ズレが発生した時点以後の部分で修正回復することができません。
つーかもろもろの問題を回避するためにMurdocCutterはわざと音声の頭を削ってるんじゃないの
どのみちts切り出す時は1GOP以上ののりしろをつけるから1GOP未満頭欠けは問題にならないし
672 :
名無しさん@編集中:2015/03/04(水) 21:27:49.56 ID:XpgAtruG
>>
MurdocCutterは音声の頭を削ったりしていないよ。
パケットの並び順として音声パケットは対応する映像パケットから
ずっと遅れた順番の場所にあるので、映像GOPの切れ目(Iフレーム)の
開始点から切り出すと、最初に現れる音声パケットは先頭Iフレームより
200〜400msec(5〜15フレーム)前の音のパケットだよ。
Murdocがこの遅れた頭を落とさないから、aftermurdocを用意したんだ。
ただ、aftermurdocは末尾で落ちこぼれになっている音声を拾い上げるのが
その第1の目的で、先頭の余分な遅れ頭を除くのはそれに伴ってできる
付録です。
一人でやっとけ
少なくともここから出てくんな
(´・ω・`)?
675 :
名無しさん@編集中:2015/03/08(日) 02:29:48.12 ID:+tCMqGxB
aftermurdoc-zero.exe で末尾処理にバグが発見されましたので修正しました。
「Rev.8 MurdocCutterで作ったクリップリスト利用の無劣化TSカッター(Murdoc利用)」
として、aftermurdoc.zip(aftermurdoc.exe、aftermurdoc-zero.exe、readme.txt)
をを
http://up.mapopi.com/ にUPしました。
676 :
名無しさん@編集中:2015/03/10(火) 21:33:05.25 ID:F3RYJOwY
「?」の人のために、まとめてみます。
(1)TSファイルの中で、映像パケットに後続する音声パケットのPTSは先行映像パケットのそれより200〜500msec小さい。
即ち、映像パケットの後に位置する音声パケットは、その映像より(5〜15)フレーム前の映像に対応するものであり、
映像パケットに対応する音声パケットは、映像よりずっと後方に出現するように並んでいる。
(2)映像GOPはTSファイル内で映像フレームが時刻順に0,1,2,3...と並ぶのではなく、0(I),-1(B),-2(B),1(I),...の順に
並んでいる。 30fpsだと1フレームあたり33msecのPTS増加となる。 MurdocCutterで画面表示されている画像は
GOP先頭のIフレームであり、表示されるPTSは0(I)の時刻。 表示されているPTSより67msec(66.666..msec)前の
-2(B)フレームのPTSがが本当の映像GOPの開始時刻。
(3)「audio-delay」値は、TSファイル中の先頭GOP以降で最初に出現する音声パケットのPTS(PTS(A))と映像パケットの
PTS(PTS(V))の差: = PTS(A) - PTS(V) だが、PTS(V)を0(I)フレームとするか-2(B)フレームとするか、2つの
流儀がある(Mediainfoは0(I)、TSMuxeRは-2(B)のPTSを使う) エンコーダーに与える補正値はaudio-delayを
調べた時のアプリ、エンコーダーが各々0(I)、-2(B)どちらに基づいているかに注意して設定することが必要。
677 :
名無しさん@編集中:2015/03/10(火) 21:33:59.60 ID:F3RYJOwY
例として、MurdocCutterで画面表示 00:10:00.667のGOPから00:20:000.667のGOP直前までを切り出す場合を挙げると、
作成されるTSの 映像PTS範囲は 00:10:00.000−00:20:00.000 音声のそれは 00:09:59.600−00:19:59.600 となって
先頭部に切り落とした映像に対応する音声400msecが残り、末尾では 00:19:59.600−00:20:000.000 の400msecの
音声が失われてしまいます(末尾の音欠け)。 A/V同期を考慮せずまた、単純にA/V分離して、各々エンコード処理を
行なった後にmuxすると、400msec音ズレしてしまいます。
(A)aftermurdoc.exeは 映像00:10:00.000−00:20:00:000、音声00:10:00.000−00:20:00:000(出来るだけこれに近く)
(B)aftermurdoc-zero.exeは 映像00:10:00.000−00:20:00:000、音声00:10:00.667−00:20:00:667(出来るだけこれに近く)
のTSを各々作成します。 作成されたTSでは先頭のGOPの-1(B)、-2(B)フレームは先行映像がないためにエンコーダーでは
無視されますので、A/V同期を考えると、00:10:00.000−00:10:00.667の音声は不要となりますが、(A)タイプのTSを入力
した場合に、67msecの補正値を与えないと正確なA/V同期が実現できないエンコーダーが多いため、いちいちこれを入力する
のが面倒な場合には、(B)タイプのTSを作って入力すれば補正値なし(=0)でエンコードすれば、末尾は67msec余分な
音声が付く可能性がありますが、便利です。 作成TSをどう使うのかによって、「aftermurdoc」「aftermurdoc-zero」を
使い分けてください。
678 :
名無しさん@編集中:2015/03/10(火) 22:01:16.54 ID:F3RYJOwY
>>676 >>677 67msecを書くのに「.667」と書いてしまいました。 正しくは「.067」です。
全て、読み替えてください。
679 :
名無しさん@編集中:
>>677 を書き直しておきます。
例として、MurdocCutterで画面表示 00:10:00.067のGOPから00:20:000.067のGOP直前までを切り出す場合を挙げると、
作成されるTSの 映像PTS範囲は 00:10:00.000−00:20:00.000 音声のそれは 00:09:59.600−00:19:59.600 となって
先頭部に切り落とした映像に対応する音声400msecが残り、末尾では 00:19:59.600−00:20:000.000 の400msecの
音声が失われてしまいます(末尾の音欠け)。 A/V同期を考慮せずまた、単純にA/V分離して、各々エンコード処理を
行なった後にmuxすると、400msec音ズレしてしまいます。
(A)aftermurdoc.exeは 映像00:10:00.000−00:20:00:000、音声00:10:00.000−00:20:00:000(出来るだけこれに近く)
(B)aftermurdoc-zero.exeは 映像00:10:00.000−00:20:00:000、音声00:10:00.067−00:20:00:067(出来るだけこれに近く)
のTSを各々作成します。 作成されたTSでは先頭のGOPの-1(B)、-2(B)フレームは先行映像がないためにエンコーダーでは
無視されますので、A/V同期を考えると、00:10:00.000−00:10:00.067の音声は不要となりますが、(A)タイプのTSを入力
した場合に、67msecの補正値を与えないと正確なA/V同期が実現できないエンコーダーが多いため、いちいちこれを入力する
のが面倒な場合には、(B)タイプのTSを作って入力すれば補正値なし(=0)でエンコードすれば、末尾は67msec余分な
音声が付く可能性がありますが、便利です。 作成TSをどう使うのかによって、「aftermurdoc」「aftermurdoc-zero」を
使い分けてください。
Aftermurdocを使わず、MurdocCutterで切り出したTSをdemuxして.mpvと.aacを作り、これらをmuxする手順で、先頭部分の
A/Vが同期したTSを得る事ができることが知られていますが、この場合は 映像00:10:00.000−00:20:00:000、
音声00:10:00.000−00:19:59:600となって、末尾の400msecが音欠けします。 aftermurdocで切り出したせば末尾の音欠けは
ないので、aftermurdocのほうがいいと思いますが、完璧を期すにはaftermurdocで切り出したものをTSmuxeRでdemux-mux
すれば良いと思います。