x264 VFW GUI専用スレ Part5

Nero＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞QuickTime Player確定か

http://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mode=one&namber=3185&type=0&space=0&no=0

>>570
問題の本質が何も見えてないんじゃないか？

・・・とはいえ俺もちゃんと理解できてるか不安なので自分なりに整理してみる。
ちょうどググりながら勉強中だったので、ちと長くなるが誰か添削してくれ・・・。

　１．Bフレームを使うと合計１フレーム分、-b-pyramidを使うと合計２フレーム分の初期ディレイが発生する。

　２．再生時の初期ディレイの扱いはスプリッタ等によって異なる。
　　　GabestやQuickTimeやFlashPlayerは何もしないでそのまま遅延させるし、
　　　Haaliの20091219版やNeroは初期ディレイを自動的にカットして再生する。

　３．再生環境によって見え方が変わってしまうというのは好ましくない。
　　　seraphy版のx264にある「初期ディレイカット（DTS Compression）」は、こういった再生環境に依存せずに
　　　初期ディレイを打ち消す方法を模索した結果考えられた手法であった。
　　　DTSとCTSというものをいじることにより、早めにデコードさせて表示を間に合わせるとかそんな感じ。
　　　この手法なら、たいていの再生環境で同じ見え方をするようになっていた。
　　　だが、この機能はseraphy版ではr1400から削除された。（x264が以下に示す４の実装になったため）

　４．x264 r1379から、MP4出力時は初期ディレイ分の遅延を、MP4コンテナのEditBox(edts)というもので打ち消すという仕様になった。
　　　（初期ディレイに相当する時間分、映像トラックを時間的に前にシフトするような感じ？
　　　　MP4Boxのdelayオプションの正体はedtsだが、実はMP4Boxにもバグがあり負のdelayの扱いが間違っている。）

　５．edtsはMP4の規定にあるもののオプション的なものなので、これにまともに対応しているスプリッタ等がほぼ無い。
　　　まともに対応しているのはQuickTimeくらいというのが現状。（←ここ大事）
　　　したがって、再生環境によって見え方が変わってきてしまうというのが現状。

　　　　　　Haali20091219 →edtsの解釈が間違っているのでr1379以降で出力したMP4を再生すると
　　　　　　　　　　　　　　　　　冒頭部のフレームが超速再生されてしまうというバグがある。
　　　　　　　　　　　　　　　　　それを修正したテストビルドもあるが、他のバグを作りこんでしまったためイマイチ。
　　　　　　　　　　　　　　　　　作者は状況を理解しているので、早く正式修正版をリリースしてくれると嬉しいな的な状況。

　　　　　　Gabest（MPC-HC） →そもそもedtsを見てない。初期ディレイはそのまま遅延する。
　　　　　　　　　　　　　　　　　　　　状況は把握しておりedts対応を進めようとしている模様。

　　　　　　FlashPlayer →そもそもedtsを見ていない。初期ディレイはそのまま遅延する。対応予定不明。

　　　　　　Nero →よくわからんが>>570の掲示板にあるMP4がうまく再生できてるってことはedtsを見てないのだろう。
　　　　　　　　　　　たまたまちゃんと再生できているように見えるが、仕様に従った動作ではない。

　６．x264的な立場としては、各種再生環境がedtsに対応するよう働きかけていきたいというスタンス。

そんなわけで、>>570の件については

　　●QuickTimeは仕様どおりの再生を行なっているので最後が白フレームになるのは仕方ない。
　　 　（２フレーム分早めて再生しているのだから最後２フレーム足りなくなるのは当たり前？
　　　　見栄えとしては最終フレームがずっと表示されてくれたほうが嬉しいような気がするけど・・・。）

　　●Neroはたまたまうまく再生できているように見えるだけで仕様に従った動作ではない。
　　　　（もしかしてMP4Boxでdelayを与えてもそれを無視するってことなのかな・・・？
　　　　　まあMP4Boxもバグってるらしいけど。）

　　●つまり仕様どおりの実装度という点で見ればむしろ
　　　　　　QuickTime>>>>>>>>>>Nero
　　　　となるが、当面まともに再生できる（ように見える）という点では、
　　　　　　Nero > QuickTime
　　　　と言えなくもない。

　　●まあでもHaaliの正式修正版が来たらそんな優劣どうでもいいよねみたいな。
　　　　ちなみに暫定修正のテストビルドは以下の２つ。
　　　　　　ttp://haali.su/mkv/mkx.e.7.exe
　　　　　　　　負のdelayの処理を修正したので、この問題については見え方は
　　　　　　　　Neroと似たような感じになる（処理は全然違うけど）が、正のdelayがおかしいというバグあり
　　　　　　ttp://haali.su/mkv/mkx.e.9.exe
　　　　　　　　正のdelayを与えると負を含む全てのdelayが無効になるというバグあり

ってことになると思うんだけど、間違ってるかな？

>>573
Neroに関しては
ttp://seraphy.fam.cx/~seraphy/cgi-bin/cbbs.cgi?mo=1&mode=one&namber=3031&type=3030&space=15&no=0


r1376を使えばedts未対応の環境でも対応済みの環境でも問題になる事が無いので
再生側が完全対応するまではコレを使うのがベターだろうな

三行で
コピペ荒らしかとオモタ

流石に三行は無理でしょう。凄く参考になった。ありがとう。
私は現状、AviUtlではｒ1376を使って再生環境は、mkx.e.9.exe＋MPCHCなんだけど
mkx.e.7.exeの方がマシなのかなぁ。

まあ、最近のx264+Haaliの20091219版でもrawで出力してmp4boxでmuxすれば良いんだけど
mkx.e.7.exeは逆にedts付いてないmp4だとちょとタイミングがズレて音が聞こえる気がするな

今までSeraphy氏の1100番台を使ってきたがx264.1471.release03.rarに乗り換えた。
同じようなオプションを使ったら2pass目のログに
　　　Quantization overflow. Your CQM is incompatible with QP < 1,
　　　but min chroma QP is implied to be 0.
と表示されてエラーダイアログ
　　　x264エンコーダエンジンのオープンに失敗しました。
が出る。--cqmを"jvt"から"flat"にしたら解決した。
--cqmには"jvt"を使うなってことなのだろうか。

もうｊｖｔ使う意味がないし

いや別に皆黙ってSeraphyの初期ディレイカット最終版使い続ければ済む話じゃないか
初期ディレイカットさえすればNeroでもMPCでもQTでも哈日でもなんでもちゃんと再生できるんだから
なんでいちいちわざわざ都合の悪い仕様に従う必要がある？

一般人の言うコンピューターが得意な人（藁）っていうのは新しいもの好きが多くてね
特にプログラムは必要性の有無に関わらず0.00001でもバージョンが上のものを使わないと
下痢になるわ水虫になるわ誤嚥はするわ最後には精神に異常をきたすんだよ

それなら仕方ないな

>>577
＞まあ、最近のx264+Haaliの20091219版でもrawで出力してmp4boxでmuxすれば良いんだけど
＞mkx.e.7.exeは逆にedts付いてないmp4だとちょとタイミングがズレて音が聞こえる気がするな

間違ってるかもしれないけど、
　　１．Haaliは元々初期ディレイを自動で捨てていた。
　　２．mkx.e.7.exeではedtsに対応したので、従来自動でやっていた初期ディレイ捨て処理はやめた。
　　３．この結果、edtsのないmp4を再生した場合は、映像の初期ディレイがそのまま反映され、
　　　　音に対して映像が１，２フレーム分遅れて見える
ってことじゃないかなあ。
間違ってたら誰か指摘お願い。

あ、>>583は初期ディレイカットしてない場合ね。

>音に対して映像が１，２フレーム分遅れて見える

おまえ、ボクサーにでも転向したら？ｗ

実はHaaliの初期ディレイカット処理をやめたのはmkx.e.5.exeより。
(Haali) VFR_maniac: http://haali.su/mkv/mkx.e.5.exe is a test build with ctts correcion disabled

QuickTime format fileの仕様では注意書きで、
もしedtsが存在しないならばメディア全体をトラック内で使用すると仮定し、トラックの表示は直ちに行われるとある。
ISOベースメディアの規格書では、
もしedtsが存在しないならばメディア時間軸と表示時間軸は一対一の対応を仮定し、
トラックの表示は(ムービー全体の)表示時刻の最初から始めるとある。

つーわけなので, Neroや現在の正式リリースHaaliの挙動は規格的には好ましくないです。

自分の公開しているx264gui.auoのソースをちょこっと弄ってビルドすれば、
デフォで初期ディレイカットするように出来るんですけどね。
自分がseraphy氏の公開しているソースに手を加えたのはptsにtimebase_numを含ませないようにしたこと。
実はnal-hrdのコミットではptsにtimebase_numを含ませないようにしています。(これはmuxer側で乗じます)
Dark Shikari氏が言うにはVFR ratecontrolに必要だとか。(どうしてなのかは詳しく知りませんが)
とりあえずflv muxerのために初期ディレイカット機能はlibx264(エンコーダ)に内蔵させているので
ソース中のb_dts_compressを1にするだけで初期ディレイカットが有効になります。
(timescaleが元の2倍か3倍になっちゃうんですけど、まぁ普通は問題ないです。)

>>578
ええと。英語を機械翻訳機にでも掛けました？
最小QPを0にしてない？
あなたの使っているcqmはQP<1と互換がない上で最小chroma QPが0になることを暗示している
っていうエラーメッセージなんだけど。

muken, the VFR maniac @ なんか規制が解除されてる

>>585
いや、Bフレーム由来の初期ディレイが１，２フレームだからというだけだけど。
>>577がどういうmp4を見てるのかは知らんけど、仕組み上の話から推測してみただけ。

このスレに張り付いてるのに最新版使わないのは許されません

>>585
2フレーム音ズレしたら違和感あるからわかるでしょ

>>586-587
なるほどね
mkx.e.7.exeだと初期ディレイカット機能かedtsが必要なのね

Haali Media Splitter
Changes

* 27/03/2010
o New Features:
+ Added AC-3 in MP4 support
o Fixed items:
+ Show error code in GDSMux when muxing is aborted
+ Accept more AAC media types in the muxer
+ Use correct timescales when processing MP4 edit lists
+ Scan the folder for more segments only if the file references external segments

うおおおおおおおおおおお？！

な、なんだｔｔ−　Σ (ﾟДﾟ;）

ハーリーは昔インストールした時に
色々求めないことまで勝手にやられて苦労したトラウマで使えない
イメージ的にはRealplayerをインストールするような感じに似てる

10fps以下ぐらいでちょっとずれても分かるような自作のMP4を
ブラウザのFlashで再生させる必要があるなんとか厨ぐらいしか
そのedtsとかいう話題は関係ないんだよね？

>>594
Da bomb!

スレに勢いがあるなと思ったら、なんで今更edtsの話になってんだw

>>594
俺もそのなんとか厨だと思うんだけど、なんとか厨はむしろ影響度が低い気がする。

　理由１．なんとか動画ではCFRが推奨されており、初期ディレイカットを使ったMP4を上げると
　　　　　　エコノミー視聴用の動画がひどい画質崩壊を起こすことがあるので、初期ディレイカットはOFF推奨とされている。
　理由２．FlashPlayerはedtsを見ていない。

つまり、なんとか厨は初期ディレイ上等で動画を扱ってることが多い（意識してる人は少ないかもだが）ので、
edtsに関するx264の仕様変更は、現在のFlashでの再生を前提とするなんとか厨にはあまり関係ない。
音ズレを気にするような場合は音声の頭に無音をつけてずらしたりしてたんじゃないかなあ・・・。知らんけど。

30fpsくらいならBフレーム由来の初期ディレイも気にならないことが多いだろうし、neroAacEncの
エンコード（デコード？）ディレイもあるからそれらが打ち消しあってそこそこシンクロするってのをどっかで見た気がする。

Flashがedtsに対応したら、それはそれで面倒なことになる気もするけど。

ああ、でもローカルに落として再生とかする場合はもろに影響出るのか。まあどうでもいいか。

ｔｖｋの一部は2フレーム音が先行するから、
合計で4フレームずれるという訳か。

>596
再生しかしない人間も徐々に異変に気付き始めた
もちろん音と映像のずれに気付いたわけではなく
ケツのエンドカードが表示されたりされなかったりで

エンドカード尻切れか・・・それは由々しき事態だなｗ