【開発】 TS関連ソフトウェア総合スレ Part14at AVI
【開発】 TS関連ソフトウェア総合スレ Part14 - 暇つぶし2ch2:名無しさん@編集中
14/09/02 00:11:41.75 TuPiuEnm
z

3:名無しさん@編集中
14/09/05 00:44:31.45 PvdQZgXN
音欠け、音ズレ対策用にMurdocのクリップファイルを使って、映像音声をほぼ同期して
切り出すツールを作りました。 「無劣化TSカッター(Murdoc利用)」
URLリンク(filescase.com)  にUPしてあります。 
パス=「1234」です。 大したものではありませんが、使ってみてください。
aftermurdoc.exeで切り出した後で、出力ファイルをTSmuxeRにかけて、
demuxを行い、.m2vと.aacを再度TSMuxeRでmuxすれば、開始PTS=00:10:00
で連続したPTSを持つきれいなTSが出来上がります。
(TSMuxeRでのdemux時にエラーメッセージが出ますが、音声パケット連番
不連続の付け替えのメッセージですので無視してください)
ほとんどのエンコーダーやdemuxerは出だしの頭合わせは
行いますが、末尾の尻合わせは行わないので、個別に生成した.ts、.m2tsを接合した際には、
前段ファイルの映像長/音声長のずれが、後続部分の音ズレの原因になってしまいます。
aftermurdocを使うと、映像長/音声長がほぼ揃うので、これが抑止できます。

4:名無しさん@編集中
14/09/05 00:47:15.62 AyIBOvNB
おおこれは期待

5:名無しさん@編集中
14/09/05 07:01:50.44 1mbQYFen
めんどくさそうなツールだな。
それは長時間録画したTSとか読ませるとちゃんと処理できるのか?
たとえばフェスとかの6時間番組とか

6:名無しさん@編集中
14/09/05 07:04:14.92 1mbQYFen
それとtsmuxerを介していることからTSに元から含まれているEIT情報は破棄しそうだな。
demux時のエラーメッセージがでるのはEIT情報に2バイト文字が含まれているためだし。

7:名無しさん@編集中
14/09/05 12:34:50.02 znHwX2RL
Qonohaで再生すれば無問題

8:名無しさん@編集中
14/09/05 12:39:09.65 1mbQYFen
tvtestで再生したいんだよ。
そして右側のパネルウィンドウが空になるとなにか大事なものを失った気分になる

9:名無しさん@編集中
14/09/05 13:50:58.15 7dyG5H/U
番組情報はともかく、データ字幕を捨てるのは有り得んな
字幕はセルBDにも収録されないことが多いから字幕付き放送版は貴重なんだぞ

10:名無しさん@編集中
14/09/05 14:20:38.35 P5edwRpZ
んだ。BDにくらい字幕入れて欲しいわ

11:名無しさん@編集中
14/09/05 20:08:19.47 pTxvRHGs
>>8
TVTest なら、映像と音声の同期ちゃんと取るので小細工する必要なし。
一般的に行われているカットと同時にエンコでももちろん必要なし。
音声再エンコなら 1ms のズレもないようにすることも可能だが、
こういう小細工をしないと音ズレするような方法で最終的に処理するなら、
せっかく再エンコしたのに AAC フレーム単位の誤差は残るという
残念な結果にしかならない。
前スレから散々言われてたが、ほとんどの人にはメリットのないツール。

12:名無しさん@編集中
14/09/05 20:09:40.80 pTxvRHGs
>>10
字幕は局が作っており局の著作物なので簡単にはいかないらしい。
テレビ東京の字幕を BSJ で使えない有様。

13:名無しさん@編集中
14/09/05 20:11:28.23 pTxvRHGs
ところで、BS-TBS のろこどる最新回(08/30 深夜)の枠最後の10秒弱、
Murdoc Cutter で画が出ない(変化しない)んだけど、どういう状態なんだろうか。
完全な静止画だが I フレはあるわけでこうなる理由がわからない。

14:名無しさん@編集中
14/09/05 20:55:26.60 PvdQZgXN
>>11
「TVtest」ってplayerでしょう。 Playerは相手にしていない。
エンコーダーで末尾部分の映像/音声の同期をとって、1msecのずれがないように
できるものがあるなら、紹介してよ。

15:名無しさん@編集中
14/09/05 21:03:38.60 7dyG5H/U
ID:PvdQZgXN は、AAC ADTSの規格を知らないみたいね

16:名無しさん@編集中
14/09/05 21:15:20.07 PvdQZgXN
(1)映像長さ100secの.mpv、音声長さ200secの.aacをmuxして作った「TS-1」
(2)映像長さ200secの.mpv、音声長さ100secの.aacをmuxして作った「TS-2」

「TS-1」、「TS-2」をh264変換して、.mp4なり.m2tsで
映像長さ=音声長さ=100sec、または映像長さ=音声長さ=200secのものが
得られるエンコーダーって存在しますか? 私は見つけていません。

17:名無しさん@編集中
14/09/05 22:01:24.11 PvdQZgXN
>>15  経験豊富な方のように思えますので、教えてください。

NHKアーカイブスでよくあるパターン: 
(1)stereoの前解説、後解説に5.1chの本編が挟まれた順序で放送された番組
(2)1トラックstereoの前解説、後解説に2トラック2か国語の本編が挟まれた順序で放送された番組
(3)1トラックstereoの前解説、後解説に0chスレレオ方式2か国語の本編が挟まれた順序で放送された番組

(1)-(3)の番組をcaptureして得たTS(mpeg2/aac)から一本物の.mp4(H.264/aac)か.m2ts(H.264/ac3)を得ろという
課題があったとき、あなたならどう対処されますか?

18:名無しさん@編集中
14/09/05 22:09:51.40 ubJ1o+5o
>>17
現行の放送でH.264もないしac3もないですが?

19:名無しさん@編集中
14/09/05 22:29:45.29 PvdQZgXN
>>18 当然ながら、CODEC変換処理(俗にいう「エンコ」)を行って、
.ts(mpeg2/aac)→.mp4(H.264/aac)、.ts(mpeg2/aac)→.m2ts(H.264/ac3)を得ます。
尚、>>17 の課題では(1)から5.1ch音声もの1本、(2)から2トラックもの1本、
(3)から2トラックもの1本の、各々の成果物をgetするものとします。

20:名無しさん@編集中
14/09/05 23:44:54.91 mpCp4JCh
DGIndexなら連続したまま出力できると思うけど
聞きたいのはマルチチャンネルのこと?

21:名無しさん@編集中
14/09/05 23:58:38.54 pTxvRHGs
>>14
>>16
だから、なんで TS をバラバラにしてからそれぞれエンコして結合しようとしてるの?
カットと同時にエンコすれば末尾がどうなってようが関係ないでしょ。

>>17
課題というか実際にやってるわけだが、
x264 で作った H.264
ts2aac -M -z -e 0 で作った AAC
ts2aac -M -z -e 1 で作った AAC(あれば)
を mp4box で mux するだけ。音声がどうだろうと同じ。
6ch や 0ch の再生どうするんだって話はあるが、それはプレイヤーの問題で、
とりあえず音ズレについては、中抜きしてようが、
再エンコなしでの原理上仕方のない最大 10ms の誤差以外ない。

22:名無しさん@編集中
14/09/05 23:58:43.92 zZRisJ5S
そもそもエンコードする前提ならデコード時点なりエンコード前の編集なりで調整すればいいだけだと思うけど

23:名無しさん@編集中
14/09/06 00:14:24.65 gFYf8jHY
>>21
ac3への場合はどうするの?

24:名無しさん@編集中
14/09/06 00:16:31.50 gFYf8jHY
>>21
問題の解決策が浮かばないので、問題の存在そのものを否定しているだけ。
あなたの方法では終始一貫した音声モードを持つ成果物は得られません。

25:名無しさん@編集中
14/09/06 00:19:19.64 gFYf8jHY
>>21
最終目的はH264-BD-Video円盤の作成ですので、.mp4ではなく、.m2ts(H.264/ac3)が本丸です。

26:名無しさん@編集中
14/09/06 01:07:06.03 gFYf8jHY
>>21 「ts2aac -M -z -e 1 で作った AAC(あれば) 」
前解説、後解説の部分は0トラックから、本編は1トラックから取ってくる
ことができるとは思いません。 本編部分のみの.aacが得られると思います。
.264、0.aac(前解説-本編-後解説)、1.aac(本編のみ)をmp4boxでmuxして、1.aacが
本来の本編の位置に入ったものが得られるのでしょうか?

27:名無しさん@編集中
14/09/06 01:26:54.32 YlJZxpG1
ac3にしたいならwav変換したらいいんじゃないの

28:名無しさん@編集中
14/09/06 02:27:24.04 gFYf8jHY
>>27
aac→ac3は直接に変換可能です。 問題は音声モードの変化に自動追随して変換できる
トランスコーダーは、現時点では見つけていませんので、異なる音声モードが
連結されているaacをac3に変換する際、音声モードごとにaacを切断して
各断片を変換(stereo→5.1chでは強制変換になる)しなければいけない点に
あります。 

29:名無しさん@編集中
14/09/06 02:30:49.89 zlEbRdVY
>>24
知らんがな。
自分的には、音声モードを全体で統一させることこそ逃げで、
元の状態をなるべくそのまま残したいという終始一貫した考えでやってるだけ。

>>26
-e 1 で AAC を作るとき、前解説の部分は丸々ドロップしているのと同じ判定になり、
その時間分の無音(正確には最初の AAC フレームのコピーのようで
小さなノイズになることもある)が挿入されるので、本編部分は映像と同期する。

>>23
>>25
再エンコは専門外なので詳しくないが、
AviUtl が 5.1ch を直接扱えないので、6ch 分の .wav に分け、
それぞれ読み込んでカットしてからエンコとかめんどくさそうなやり方を見たことはある。
音声モードを統一させるなら事前に処理しとけば前解説の部分の問題はないわけだよね?
デュアルステレオも同様な方法でいける。
とりあえず原理上 1ms のズレもないはず。
TS いじるプログラム書けるなら、AviUtl に作らせた Trim 見ながら
全自動処理するツールくらい作れるんじゃないかな。
これは結構需要ありそうだから喜ばれると思うw

30:名無しさん@編集中
14/09/06 02:41:11.47 gFYf8jHY
従って、私の現状では、前解説部分、本編、後解説部分のaac断片化のために、
TSを3つに分け、(1)では前後解説部分のstereo-aacを5.1-ac3に変換、本編は5.1aacを
5.1ac3に変換、(2)では前後解説部分の1トラック部分をac3変換後に複製して、
2トラックのac3に、(3)では同様に解説部分を2トラック化し、本編はBonTSDemuxで
左右別々のwavを作成し、これをac3-stereoに(モノラル-stereoへの強制変換)します。
3つのac3を連結して1本化し、断片化させない元TS全体から変換した.264とmuxして
1本の.m2tsにする方法と、3つのTSごとに.m2tsを作成してこれらを連結して1本の
.m2tsにする方法が考えられますが、各部分部分を再生してチェックできることから、
現在は後者を選んでいます。
3つの断片TS

31:名無しさん@編集中
14/09/06 03:04:57.33 gFYf8jHY
>>29
ffmpegなどトランスコーダーは入力ソースの途中での音声モード変化には
自動追随はしません。 またPS(.mpgなど)が持っているようなプログラム
ヘッダーはTSにはありませんので、TS入力の場合、殆どのトランスコーダーは
最初の数パケットを見て、音声トラック数、チャンネル数、bitrate(A/V)を
判定し、全体がそうなっている前提で処理します。 従って、作成した.m2ts
の再利用(cropやトリミング、画素ダウン)を行う際には、終始同じ音声モードに
なっていないと、作業ごとに毎回、同じ苦しみを味わうことになります。

32:名無しさん@編集中
14/09/06 11:09:47.37 E3pvoTdW
>>14
エンコ目的ならx264+avisynthでズレは解消できるだろう?
dgindexでd2vを作る祭にaacのms値をdelayaudioで指定するだけで補正できるしな

33:名無しさん@編集中
14/09/06 12:12:38.87 gFYf8jHY
>>32
出来上がった成果物の映像長と音声長をそろえなければいけません。
音ズレはないが、末尾が不揃いで、後ろに別のコンテンツをマージした場合に、
追加部分で音ズレしないようにするためには、映像長と音声長が揃った成果物を得なければ
いけません。 delayaudioで補正すると、その補正により末尾での音声「はみ出し」、
ないしは「早じまい」が出てしまいます。

34:名無しさん@編集中
14/09/06 12:22:47.82 gFYf8jHY
音ズレをどうやって解消するかを問題にしているのではなくて、
将来に音ズレを発生させる可能性がある要因をいかに取り除くかを問題にしているのです。
問題は先頭の頭合わせではなくて、末尾部分の長さ合わせなのです。
エンコーダーもplayerも、注意を払うのは頭合わせですが、私たち自身、
音ズレれなく市長さえできればいいという観点で、ファイル処理しますが、
末尾部分に潜む音ズレの種については無関心です。
この無関心でいる箇所がどうなっているのかを語ろうというのが、今回の問題提起です。
>>16 に挙げた事例を考えてみてください。

35:名無しさん@編集中
14/09/06 12:35:01.72 E3pvoTdW
> 音ズレはないが、末尾が不揃いで、後ろに別のコンテンツをマージした場合に、
> 追加部分で音ズレしないようにするためには

mkvmergeでappendしていけば?

36:名無しさん@編集中
14/09/06 12:36:57.23 E3pvoTdW
つーかそこまで必死に編集したところで1度見たら消すか
全く見ないまま行方不明なファイルになるのがオチじゃね。

37:名無しさん@編集中
14/09/06 12:46:03.15 y7bY09wt
>>3
いいね!

38:名無しさん@編集中
14/09/06 13:43:04.93 gFYf8jHY
動画ファイルの分析ツール、あるいは再生Player画面では「長さ」が表示されるが、
殆どの場合、これがどの長さを意味するのか説明されていないようである。

(1)実際のvideo長
(2)形式上のVideo長(虫食いTSやPTS付け替えが行われていないマージproduct)
(3)実際の音声長
(4)形式上のAudio長((2)のVideo同様)

編集、変換して得た生成ファイルとしては、
映像開始PTS=音声開始PTS、映像終了PTS=音声終了PTS(終了PTSはデータとして
ファイル中にはないので計算で算出することになる) になっていることが理想だが、
.ts(mpeg2/aac)を除けば、大概の形式のファイルではこの確認が困難であり、
生成ファイルを再び編集素材として用いて新たなファイルを作成しようとした際に、
映像音声の長さ不一致に気が付くのではないだろうか。
フリーウェア、有料の種別にかかわりなく、アプリの評価基準としてこの「長さズレ」
を問題としたい。

39:名無しさん@編集中
14/09/06 13:44:09.40 gFYf8jHY
A/Vの出だし頭合わせを行う場合にも、
(1)ブランク画像挿入(SmartCutterなどで行われている)
(2)先頭部不要画像の切り落とし
(3)先行部対応音声切り落とし
(4)無音パケット挿入
(5)無音パケットを挿入せず、音声パケットを後方遅延
などの手段が取られるが、どのようなやり方を採用しているかについて十分な説明を行って
いるものは皆無といってよかろう。

ましてや、頭だし処理と合わせて必要な長さ合わせのための末尾部分については全く説明が
行われていない。 これは、見れればいいというユーザーがほとんどであるため、あえて
恥部をさらけ出して、評価を落としたくないという配慮であろう。 A/V長さ不一致による
接合障害は接合時に処置すればいいという「囲い込み」のやり方もあるが、A社製ツールで
作成したファイルとB社製ツールで作成したファイルをC社製アプリで接合する場合のことを
考えると、A/V頭出しが一致するとともにA/V長さも一致した成果物が得られるツールが
優れていることは自明である。 

各種ツールの行う末尾処理についての情報交換を行っていきたい。

40:名無しさん@編集中
14/09/06 13:49:12.83 gFYf8jHY
>>16 に挙げた
(1)映像長さ100secの.mpv、音声長さ200secの.aacをmuxして作った「TS-1」
(2)映像長さ200secの.mpv、音声長さ100secの.aacをmuxして作った「TS-2」

を処理した場合に、どのようなProductが得られるのかを、お使いのツールで
試してみてください。

41:名無しさん@編集中
14/09/06 14:33:50.99 zlEbRdVY
>>36
それは自分を含め大半に当てはまることなので言っちゃ駄目w
まあ、エンコしたら TS は消す、
エンコしないなら TS はいじりたくないって人がほとんどだろうね。

どんな連結でも完全にズレないようにできるならともかく、
AAC の境界問題から映像と音声を完全に揃えることは不可能で、
連結数に応じて誤差が蓄積され、GOP 構造は一定とは限らないので
切り口の各ツールの扱いの違いからそれ以上にズレる可能性もあるという中途半端さ。
それでいて字幕や番組情報等は失われてしまう。

……そんなものを作って喜ぶ奇特な人がそうそういるとは思えない。
別の方法が提示されても頑なに考えを変えないみたいだし、もうほっとくしかないだろう。

42:名無しさん@編集中
14/09/06 14:45:24.08 mk5D4sa5
悪いバグ報告の典型みたいでろくに読んでなかったが
趣旨は「各種ツールの行う末尾処理についての情報交換を行っていきたい。」のようだからな
言い出したやつの責任で各ツールの出力結果を一覧まとめてくれればいいんじゃね

現状でもやり方を工夫すれば実質問題なくはできるわけだし
普通はまず非可逆のものを素材としてこねくり回すなんてしないから困らないしね

43:名無しさん@編集中
14/09/06 14:46:40.09 gFYf8jHY
>>41
「AAC の境界問題から映像と音声を完全に揃えることは不可能」
AACフレームを再構築すれば可能です。

44:名無しさん@編集中
14/09/06 14:49:46.95 UyKQ0cCG
10msずれてるかどうかってどのソフトで確認できまつか

45:名無しさん@編集中
14/09/06 15:00:38.28 VeVqO+Jo
>>41
自分の用途に合わないから欲しがる人なんていない、無くてもいいってのはちっと違うだろう
基本的に選択肢が増えるのは悪い事ではない
それに映像と音声のデータ上の配置ズレは400ms以上の幅を持っていて、
AACフレーム20個分近い量なので連結数に応じて蓄積というのと同列に語るのはかなり微妙な話になるよ

個人的には頭や末尾をカットする時は何かあったら困るからというのと再生デコーダ側の問題への配慮で
いつもマージンを取っていて、常々邪魔なゴミだなと思っているからこの方向性自体は支持する

ただ自分はMurdocCutterのUIを支持しておらず独自CUIツールで対応しているから(PATやPMT周りの配慮他)、
MurdocCutterの事後処理という位置付けで出されて来ると使用対象からも外れちゃうけどな
ソースが公開されていれば自分に必要な部分だけ精査+流用or参考って流れはあるが

46:名無しさん@編集中
14/09/06 15:03:01.09 E3pvoTdW
>>41
俺は3時間番組とかを分割エンコして都度mkvで保存したものを
事後にmkvmergeでappendさせて1つのながーいmkvにすることは多々あるが
音がズレたことは一度もない。

分割する箇所はavspmodで確認しつつシーンチェンジごとにtrimさせれば
つなぎ目が変になることも避けられる。音声が5.1->2.0->5.1になってしまうソースは
2.0の部分だけ5.1にさせて統一させればいい。tvtestみたいに勝手に検知して
変えてくれるわけもないからな。ってTSとは全く無関係な例だったなすまん。m(_ _)m

47:名無しさん@編集中
14/09/06 15:20:57.92 gFYf8jHY
>>44 音声CODEC変換してしまうと、ほぼ追跡不能と思われる。
現状では元のTSをダンプしてPTS、durationを比較するしかない。
最終PTSはデータとして存在しないので、計算で求める。

48:名無しさん@編集中
14/09/06 15:30:09.52 zlEbRdVY
>>43
揚げ足取りもいい加減にしろよな。
あんたの作ったツールはやってないだろ?
文脈からそういう意味で書いてることくらい読み取ってくれ。

再構築でいいなら良い方法があるよ。
映像を Motion-JPEG、音声を WAV に変換するんだ。
どう編集しようが、WAV のサンプリング周期レベルの誤差しか生じないのでお勧め。

49:名無しさん@編集中
14/09/06 15:30:48.29 zlEbRdVY
>>42
多分、ほとんどのツールが出力可能な最大限残してるだけだろうけどね。
なるべく元の状態を維持するのが、おかしなトラブルを呼ばない基本。
これを手抜きと取るなんてリスペクトしないにも程がある。
例外で思いつくのは、m2v がエンコクラッシュ対策だとかで最後2フレ減らしてる。

>>45
選択肢が増えること自体が良いことなのはわかってる。
ただ、完璧なツールではないのに良いことばかりで欠点を表明しないので、
よくわからない人が勘違いしないようにしてるだけ。
で、まただらだら垂れ流し始めたからほっとこうと<提案>したまでっす。

50:名無しさん@編集中
14/09/06 15:38:11.55 VeVqO+Jo
>>49
それを言うならそれこそ「連結数に応じて蓄積される誤差」を分量も示さずに
持ち出してよく分かってない人を煙に巻く詭弁は止めておきなよ

AACフレーム、PESフレーム、音声と映像の送信時ズレ、各々の時間の分量がどれだけ違うかくらい知ってるだろ?

51:名無しさん@編集中
14/09/06 15:44:31.67 YlJZxpG1
ageてる人の目的がわからん
まずGOPフレームとAACフレームを秒数でみたら割り切れないんじゃないの
それを映像音声合わせますって事自体眉唾物

52:名無しさん@編集中
14/09/06 15:48:49.68 zlEbRdVY
>>50
言葉が足りなかったのなら、スマン。
音声再エンコなしの場合、どの位置でも最大 10ms なのが、理想ではないが現実解。
運次第で誤差がそれ以上蓄積される可能性があるようでは、とても実用的とは思えない。
もちろん、音声再エンコするなら、1ms のズレもないようにしたいよね。
方法次第で可能なのだから。
そういう話。

53:名無しさん@編集中
14/09/06 15:53:36.98 l2LwpNjd
ここでやるなとは言わないし続けてくれて構わないんだけど、ツールのサイトを作って、
仕組み、やってること、それをやってる理由、どういうメリット・デメリットがあるか、などなど
わかりやすく端的にまとめておいてくれると助かるかな・・・。
俺は細かいことわからないから眺めてることしかできないけど、なんかこう殴り合い的な話になってるというか、
ここで乱戦的な長文流すよりも論理的に筋道立てた文章をまとめておいてくれるといいなというか・・・。

54:名無しさん@編集中
14/09/06 16:08:50.30 gFYf8jHY
>>46
mkv作成に使っている、映像/音声のdecoder/enoderはそれぞれ何を使っていますか?

55:名無しさん@編集中
14/09/06 16:11:07.36 VeVqO+Jo
>>52
話が噛み合ってないぞ、というかあんたは恐らくこのツールの一番の目的を誤解している

AACフレームの単位時間(21ms)が映像側との同期を考慮しないのは
仕様上・運用上の話で、TSという形態である限り同期の責任が再生側にあるのは不変だ

今話題に上がってるツールは、説明を読む限り末端の対応に注意を払った内容だろう
つまり普通に目的とする映像のポイントで切り出した際に配信ズレ分だけ失われる
音声(400ms)を失う事なく、余分な映像ゴミを付与する事もなくカットすると言っているように見える

あんたの言う同期ズレは恐らくファイル化したTSだけを対象として、TVTestのような
随時同期を持たない再生プレイヤーが連結部分で問題を起こす話だろう
そういう特定の再生側の固有事情の話ではなく、単純にバイナリカットしただけでは映像ゴミが付与するか
音声ソースが大きく失われるかの2拓しかない状況を、TSを維持したまま改善させるという話だと思うぞ?

56:名無しさん@編集中
14/09/06 16:23:39.65 F/4UNBbg
MurdocCutter+MurdocCutter用+MurdocBatchで連番分割->個別エンコ->MP4Boxで結合をおこなってる。
この方法をとるとMP4Boxは各mp4の映像と音声の短い方に切り捨てて結合されてしまうという問題がある
MurdocCutterだと音声が常に末尾で短くなってるので映像側が切り捨てられていることになる。

aftermurdocを使うと音声長さが映像長さ±10ms以内になって、切り落としが最大でも1フレームになるということだよね。

でも本当に欲しいのは音声側を長めに残してもらって映像が切り落とされないようにしたい。
なので、音声が長く残るオプションをつけてくれるとうれしい。

57:名無しさん@編集中
14/09/06 16:42:31.71 zlEbRdVY
>>55
この人は、バラバラにした TS をそれぞれエンコし、
それらを tsMuxeR で mux したときに音声の足りない分だけズレる
ということから始まっている。
つまりは、随時同期しないプレイヤーでの再生と同じ現象。
最終的に同じ処理をするのなら、10ms の誤差は蓄積される。

中抜き継ぎ接ぎ TS を随時同期しないプレイヤーで再生したい人がいるなら
役に立つと思うが、>>14 で言ってるように本人はそれを想定していない。
目的はあくまで音ズレしないエンコらしいので、色々言いたくなる……。

あと、TVTest はきちんと同期取るので念のため。

58:名無しさん@編集中
14/09/06 16:51:59.49 VeVqO+Jo
誤読して来るんじゃないかなと思ったけどやっぱりか

TVTestのような随時同期を持たない再生プレイヤーが
→TVTestが備えているような随時同期を持たない再生プレイヤーが

これで伝わるかね?

>中抜き継ぎ接ぎ TS を随時同期しないプレイヤーで再生したい人がいるなら

だから違うって
再生上の同期とは別にソース自体が存在するかどうかって問題が単純な切断と結合では発生するんだよ
TVTestを例に取ると、内部のDirectShowフィルタグラフではPTS付きで音声が丸投げされるため再生ズレは発生しないが、実際には欠落した音声の分だけ結合部分で無音区間が生じている
単純なバイナリカットを改善すればその問題が解消される訳で、その処理を供給するツールなら普通に価値はあるわなって話

59:名無しさん@編集中
14/09/06 17:17:28.70 zlEbRdVY
>>56
>この方法をとるとMP4Boxは各mp4の映像と音声の短い方に切り捨てて結合されてしまう
おお、これは知らなかったなあ。
ズレはどの位置でも最大 10ms で収まるように調整してくれるんだろうか。

>>58
スマン、TVTest のことは完全な誤読だ。
最初はちゃんと読めてたのに、読み返したときに改行に惑わされたみたいw

あなたの言ってる趣旨は、>>45 を読んだときからわかってるよ。
件の人の意図はともかく、たまたまあなたが問題視していることを
解決するツールになっていたってことでしょ。

それはいいんだけど、自分の発言動機は、
>ただ、完璧なツールではないのに良いことばかりで欠点を表明しないので、
>よくわからない人が勘違いしないようにしてるだけ。
>目的はあくまで音ズレしないエンコらしいので、色々言いたくなる……。
あたりなので、そう突っかかってこないでくれ……。

60:名無しさん@編集中
14/09/06 17:39:40.49 VeVqO+Jo
まあレスの組み方とかやり方をもう少し考えた方がいいかなって話なら分かる
話していく内に説明が必要になって掘り下げるのは仕方ないが、今一かけた行数に
対して構成がまずいというか内容が見合ってないというか…

ただ特定の誰かの要不要でツールが排除されちまうような空気はスレ的には良くないと思う訳よ
レスの内容には微妙な部分はあるが、一つの問題解決の目的があってそのための開発という労力自体は
基本的に批判されるべきではないと一開発者としては思う訳だ

ぶっちゃけ自分だと基本切り継ぎだけで再エンコしない人だからここで話題になるツールの7、8割位は
興味すらないけど、だからって不要だなんて考えた事もないし口を出さないのが筋だと思ってる
いずれ興味を持ってその時必要になる可能性だってある訳だしさ

だから>>41みたいなのは流石に流せない
何であんたが他の奴のTS運用の全体像まで勝手に定義してんだよって突っ込まざるを得ない
だから黙って見てる事と賛同してる事はイコールじゃないぞって事を一応言わせてもらった

個人の意見として言ってるだけだったら何も言やせんかったよ

61:名無しさん@編集中
14/09/06 17:54:22.42 zlEbRdVY
>>60
まあ、前スレから延々続いているので……。
そのへん見てなかったのなら、
前スレを読んでもらえれば少しはわかってもらえるかもしれない。

そういや、先頭付近は映像パケットのみ、末尾部分は音声パケットのみが延々続くという
イレギュラーな状態になるので、改善どころか別の問題が発生する懸念もあり、
あなたの理想には程遠いかも。
使用例のように tsMuxeR で mux し直せばいいが、
字幕や番組情報等が失われてしまう。
出力順を並び替えるように改良してくれれば解決するが。

62:名無しさん@編集中
14/09/06 18:32:29.89 VeVqO+Jo
方向性自体は支持すると言ったけど、詳細に関してはまあ微妙な部分は色々あるだろうとは感じてるよ
組んだ処理の比重としては恐らくこんな感じじゃないかな

・基準映像PTSに対する音声PTSのポイント合わせ
(単純なリニアシークか多少でも配慮した最適化を行なっているか)
・切断点はPESレベルかADTSレベルか
・ADTSレベルならPESの組み直しはどのような方式か
・PID毎の切断点を決める際、決定処理と実際の抽出処理は分離されているか
(コールバック/中間データ等方式含めて、ソースの流用や応用が可能な形か)
・切断点の決定にどの程度の調整を許すI/F構成になっているか(切り捨て/切り上げ/+nフレ等)
・PCR他、周辺PIDの調整はどうか

コードとしてはこの辺の労力がそのまま価値だし、既に実TSでの再生試験を通過しているならその実績自体が価値
個人的にはパッケージとして使えるかは枝葉で、意味のある労力が投入されているかが一番重要だな
新しい開発なんてそれでいいと思ってる、自分の用途に合わない部分は直せばいい
TVTestだって前身は別のパッケージで、その成果を応用発展させたものだったりするしな

ちなみに前スレには居合わせているから、レスのつけ方にはまあ概ね言いたい事は分かるよ
ただ意義のある話も含まれていると自分は感じたから、開発スレとしてはまあいいんじゃないかなと個人的には思う
エンドユーザー用のスレだったら完全アウトかも知れないが・・・

63:名無しさん@編集中
14/09/06 18:45:02.43 DRlX2cSc
長文書き込み率半端ねえなここ

64:名無しさん@編集中
14/09/06 19:22:00.11 E3pvoTdW
>>54
触りだけ。

基本はdgindex.exeで解析した時のaacもしくはmp2を使う。
avsを編集し終わったらwavを吐き出すために avs2wav2g.exe を使っている。
ちなみに2.0->5.1の変換はsoxfilter.dllを使う
さらにそれらを音声エンコする場合は -ignorelength を付けた neroaacenc.exe
もしくは flac.exeを使う。

mkvmergeは少し古いv5.5.0を愛用。マージ用の処理もバッチファイルで
一括処理できるようにしているので、タイムコードとチャプタファイルとEIT情報も一緒に
コンテナにいれてる。なのでTSからEIT情報を省くわけにはいかない。
EIT情報はeittextout.exeで。

65:名無しさん@編集中
14/09/06 19:49:05.88 zlEbRdVY
>>64
あ、>>46 が自分へのレスだと気付かず無視した形になってしまっていた。すまない。
>どんな連結でも完全にズレないようにできるならともかく、
>>3 を使った場合の話で、一般論のつもりじゃない。

あなたが実現できているのなら、
音声再エンコ時にフレーム長可変かなんかで長さが完全に揃えられているか、
mkv のコンテナに何か特殊な仕組があるとかかな?
どちらも専門外なので超憶測だけどw

66:名無しさん@編集中
14/09/06 20:08:48.93 gFYf8jHY
>>65

59 :名無しさん@編集中:2014/09/06(土) 17:17:28.70 ID:zlEbRdVY>>56
>この方法をとるとMP4Boxは各mp4の映像と音声の短い方に切り捨てて結合されてしまう
おお、これは知らなかったなあ。
ズレはどの位置でも最大 10ms で収まるように調整してくれるんだろうか。

と同じように、MP4Boxでのマージの際に映像/音声が揃えられてからマージされているのではないかな。
これだと>>3を使おうが、使うまいが、CODEC変換処理後のproductが映像長/音声長不揃いであっても、
切り落としはあるかもしれないが音ズレ的にはOK。

67:名無しさん@編集中
14/09/06 20:18:02.02 gFYf8jHY
ちなみに、TSMuxeRでの.m2ts(H.264/ac3)のJOIN接合では、入力ファイルの
映像長/音声長の調整はなされず、.ts(mpeg2/aac)の時と同様に、PTS付け替えもなく
単純マージされてしまいますので、個々の入力ファイルの映像長/音声長をできるだけ
揃えておく必要があります。

68:名無しさん@編集中
14/09/06 20:20:34.09 gFYf8jHY
コンテナ形式だけの違いですので.m2tsを.mp4(H.264/ac3)にしておいて、
MP4boxで統合し、統合物を.m2tsに戻すというやり方もあるのかもしれませんね。


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch