- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。
この記事はshon3i氏のdoom9での発言に依存しており、彼のpostが不正確であった場合、'''この記事は全く正しくない可能性があります'''。BDの仕様書が手に入らないので仕方がありません。
!!!x264とBlu-ray
x264は2010/04/25に、フリーソフトウェアとして初の''Blu-ray disc向けのエンコーダ''になったと[公式にアナウンスした|http://x264dev.multimedia.cx/?p=328]。
これまでも各種パッチを使用すればBDプレーヤで再生可能なコンテンツを作成することはできたが、r1480で--nal-hrdオプション等を公式に取り込み、規格適合性を検証するソフトウェアの''検査にパスした''ことが大きかったのだろう。
この記事では、x264でBlu-ray規格に適合するH.264ストリームを作成するための情報を''メモレベルで''記載する。この記事の執筆にあたり、きっかけと情報を提供してくれた''JEEB氏に感謝''する。
主な元ネタは、x264のr1480のchangelogと、以下のdoom9の2つのpost。
* http://forum.doom9.org/showpost.php?p=1375937&postcount=103
* http://forum.doom9.org/showpost.php?p=1315154&postcount=106
なお、ここで述べるのはH.264ストリームのエンコード方法だけであり、音声やコンテナ、オーサリングなどは一切扱わない。また、コマンドラインを丸ごと知りたければ[Authoring a professional Blu-Ray Disc with x264|http://sites.google.com/site/x264bluray/]に多数列挙されている。
!!2011.05.18追記：This article is highly outdated
記事を掲載してから相応の時間が経過し、現在ではこの記事はかなり時代遅れになってきている。しかし書き直すだけの時間もないため、ここで状況の変化に関して大きなポイントを箇条書きにしておく。
*--bluray-compatが導入された(r1935)。
**Blu-ray互換エンコードでは必須。
**互換性上必須ないくつかのパラメータが強制される。
**open-gop blurayが単項オプションになり、bluray-compatで中身が変わるものになった。
*--weightp 1が使用可能になった(r1802)。
*--weightp 1が安心して使用可能になった(r1802)。
**weightp=1の内容が変わったため。「解析なし・dupあり」→「解析あり・dupなし」。
*VBV関連やfps、level、解像度などは自分で適合するパラメーターを指定する必要がある。
詳細はいつか時間があれば…あれば……ないな…。
!!x264に指定すべきパラメータ
x264のr1480では、以下の例が示されている。
{{bq
x264 --crf 16 --preset veryslow --tune film --weightp 0 --bframes 3 --nal-hrd vbr --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 24 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 -o
}}
このうち、--weightp 0以降のパラメータ指定が必須であるとされているが、doom9へのshon3i氏のpostを読むと語弊がありそうに思われるので、''筆者の理解''を以下で説明していく。
!必須パラメータ
これらは有無を言わせずにこのまま書く必要があるパラメータであると思われる。
{{pre
--nal-hrd vbr --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
}}
色空間に関しては注意しておきたいところだ。
!weightp, b-pyramid, slices
理由は様々だが、これらは問題の発生を回避するため、ある範囲に設定を収めた方がよいオプションである。
weightpは本来Blu-rayの仕様上は自由に使用できるオプションであるが、r1480のchangelogには一部のプレーヤ、特にMediatekのもので問題が発生すると記載されている。このため''0が推奨''される。
Blu-rayの仕様上、b-pyramidはstrictかnoneである必要がある。実際にはnormalでも再生できてしまうことはあるだろうが、それでは明確に規格違反をしてしまうことになる。
個人的にはnoneを推奨したいくらいだが、x264の開発者は自信を持って''strictで問題ないと明言している''ので、使用者の判断にお任せしたい。
なお、元ネタでも「b-pyramidは使用しないこと」とあるが、これはこのpostがb-pyramidにstrictが実装された2009年10月以前であることによる。
実際、その後[shon3i氏自身がstrictなら問題ないと発言|http://forum.doom9.org/showpost.php?p=1368828&postcount=2]している。
また、以前にあったrefを-1するという対応も今では不要である。
Blu-rayの仕様上、slicesはLevel 4.1では4以上が必須とされている。逆に言えばLevel4.1未満ではslicesは必須ではないはずだ。slicesの値は上げすぎるとBD規格ではなくH.264規格のSliceRateに違反する可能性があり、画質対ビットレートでも不利になるため、最低限の''4が最も適切''だ。
!bframes, keyint, min-keyint
bframesは一律で3が最大とされている。3以下でも構わない。
min-keyintは2が、そしてkeyintは様々な兼ね合いから24がよいだろう。
元ネタによると、keyintとmin-keyintは2-24の値が推奨されるが、1-30の値が使用可能ではある。
ただし、keyintの方は別途bframesの値によって、以下のように制限される。
*bframes=1の場合、2の倍数(2, 4, 6, 8...)でなければならない。
*bframes=2の場合、3の倍数(3, 6, 9, 12...)でなければならない。
*bframes=3の場合、4の倍数(4, 8, 12, 16...)または30でなければならない。
最後のbframes=3の場合に30というパターンから外れる選択肢に関しては、本当なのか、情報提供者のtypoなのか分からない。いずれにせよ2-24が推奨とされているので、避けた方が無難だろう。
また、オーサリングアプリケーションではmin-keyintに2が使用されることが多いらしいので、これも参考にしたい。
!vbv-maxrate, vbv-bufsize, level, ref
解像度も含めて、以下のようになる。
,Level,vbv-maxrate{{br}}kbps,vbv-bufsize{{br}}kbit,解像度{{br}}（最大ref）
,4.1,40000,30000,1920x1080(4){{br}}1440x1080(4){{br}}1280x720(6){{br}}720x576(6){{br}}720x480(6)
,4,24000,30000,1920x1080(4){{br}}1440x1080(4){{br}}1280x720(6){{br}}720x576(6){{br}}720x480(6)
,3.2,24000,24000,720x576(6){{br}}720x480(6)
,3.1,16800,16800,720x576(6){{br}}720x480(6)
,3,12000,12000,720x576''(5)''{{br}}720x480(6)
上級者向け：これは恐らくNAL-HRDレベルの制限であり、[[x264(vbv-maxrate,vbv-bufsize,profile,level), H.264(Profile/Level)]]で掲載しているVCL-HRD基準の制限値とは少々意味合いが異なるかもしれない。
!!その他
*BD規格では24fpsも23.976fpsも使用可能。(23.976 (actually 24/1.001) and 24.000)
**ただしハリウッドの市販メディアは23.976。
**プレーヤによるコンポジット出力などを考えた場合23.976の方が無難。
**米国では24fpsをうまく再生出来ない（バグのある）テレビが存在する。
*DVDメディアでのAVCHDの場合、VBVには15000/15000が良いと思われる。
**余裕を持って14750や14500とする説もある。
*BDの仕様自体はインターレースも可、ほとんどのAVCHDカムはTFFなので--tffで使用することを推奨。
*制限の中で特に厳しいのはkeyintだが、BDの仕様ではOpenGOPは許されている。
**x264では現在、未完成のOpenGOPパッチが存在する。
*15Mbps以下の場合に2秒分までのkeyintが使用可能であるとも言われるが、根拠が謎。
**http://forum.doom9.org/showpost.php?p=1390375&postcount=520
**http://forum.doom9.org/showpost.php?p=1361135&postcount=3
**恐らく上記表のvbv-bufsizeの半分以下にすれば2秒分が使用可能という論理か？
**個人的にはこの判断は危険に感じる。素直にビットレートを増した方が安全。
以下のpostやthreadも参考になる。
*http://forum.doom9.org/showpost.php?p=1369280&postcount=21
*http://forum.doom9.org/showthread.php?t=154192
*http://forum.doom9.org/showthread.php?t=154209
*http://forum.doom9.org/showthread.php?t=152127
*http://forum.doom9.org/showthread.php?t=152403
!!内部制約
（未執筆：x264のオプションで指定するのものではないが、内部的な制約を此処に書く。）
!!この記事の信頼性について
この記事を''メモレベル''としているのは、情報が色々と不確かなことによる。
その不確実な点について、少々書いておく。
!適合する規格
Blu-ray discには、映像に関する規格が色々とある。
関連のある系統で区別すると、大きくBDMVとBDAVに分かれる。
*BDMV（DVDメディアにおけるDVD-Videoに相当）
**AVCHD（DVDメディアのビデオカメラ向け規格にもかかわらずBDMVと共通性がある）
*BDAV（DVDメディアにおけるDVD-VRに相当）
**AVCREC（BDAVをDVDメディアにバックポートしたような規格）
このうちx264が対応していると主張しているのは恐らくBDMVとAVCHDになるのだと思われる（サンプルがこれらである）。
これらの規格には、H.264のエンコードで選択可能なパラメータに関して、当然それぞれ別個に規定があるだろう。
しかし、x264ではその情報に関して詳細を公式にアナウンスしておらず、changelogで一例が述べられているに過ぎない。
つまり規格に適合する一例は示されているが、どの範囲でどのように使用すればどの規格に適合するかは必ずしも明確ではない。
!情報の信頼性
前項に従い、このページで述べる情報の殆どは、公式に得たものではない。
BD規格がH.264に追加で行っている制限について述べているpostがdoom9にあり、''又聞き''としてそれをx264の設定としてこの記事にまとめているだけである。
筆者がBDの仕様書を直接に確認したわけではなく、この情報が十分に検証されているとも言い難い。なにせ、今回リリースされたx264を除き、これほど詳細にパラメータを設定できたり、内部動作が明確であるエンコーダもない。
!x264の実装レベル
一応、BD規格への適合性を判定するソフトウェアのテストには合格したというものの、本当に''規格に定められている隅々まで問題ないのか''、という点に関しては実はまだ疑問が残る。
こんな事を言ってしまうと身も蓋もないのだが、規格適合性の検証ソフトウェアと言えども、抜けが無いとは限らない。
また、エンコードされる素材やパラメータによって、問題が出るケースがないとは限らない。
筆者も製品の開発現場にいた際には、''特定条件下で規格に準拠しない出力を行ってしまう例''は何度か見ている。
そのような製品では、一般的ではないものも含む、何千、何万というパターンでテストを行っているにも関わらず、問題が発生している。x264はもちろんまだそれほどにはテストされていない。
例えばx264はH.264が定める''SliceRate''という値を一切気にしていない。通常の使用ではこの値に違反することはないだろうが、現状のx264はこれを制御する術を持っていない。
また、NAL-HRDは実装されているが、''VCL-HRD''は実装されていない。これは実質的にはNAL-HRDがカバーできる範囲ではあるが、VCL-HRDデータは符号化されていないし、VCL-HRDとNAL-HRDを個別に制御する方法も用意されていない。
他には[[x264でp4x4を使用しない方がよい理由]]で書いたような問題も存在する。
H.264自体に対してもこの状況であるのだから、Blu-rayに関しても同じような問題は存在してもおかしくない。
ただし、商用製品の中にも問題のあるものは多数存在するのであり、それらと比べてx264が確実に劣るのはテスト回数だけで、これは今後世界中のユーザによって、商用ソフトウェアを遥かに凌ぐ勢いで改善されることは間違いない。
!オプションの煩雑性と確定性
x264はr1583現在、BDでの再生互換性を一括で確保するためのオプションを用意していない。
--profileのように、これさえ指定すれば他が滅茶苦茶でも強制的に非互換のオプションを修正してくれればよいのだが、そうはなっていない。
これはつまり、今後オプションのデフォルト値が変わったり、新たなオプションが導入された際に、この記事やr1480での例示では正しくエンコードできない可能性がある事を意味する。
つまり、この記事は''状況の変わりやすい題材を扱っており、決定版とは言えない''。
