このページの全ては誤っているかもしれません。[[x264関連の記事に関して]]を読んでください。 !!!x264(vbv-maxrate,vbv-bufsize,profile,level),H.264(Profile/Level) H.264のプロファイルとレベルのまとめ。 他のサイトにも同じような表はあるが、聞かれる度に答えるのも面倒なので。 なお、Blu-ray等のH.264関連規格では、H.264で指定されているものとは別にプロファイル・レベルに相当する内容が規定されていることがある。それらはここでは扱わない。Blu-rayでの制限に関しては、メモレベルの記事ではあるが、[[x264とBlu-ray]]を参照のこと。 また、vbv-bufsize/vbv-maxrateに指定する''値''ではなく、 その''正体''（中身）を知りたい方は[[x264(nal-hrd),H.264/AVC(HRD),MPEG-1/2(VBV)]]や[[CBRの幻想]]を参照してほしい。 !!前置き H.264は、モバイルからHDまで様々な用途に対応する映像圧縮の規格だ。しかし、同じH.264対応だからと言って、大きなTVから携帯電話やiPodまでもが同じ動画ファイルを再生できるわけでは、当然ない。 このため、機器の処理能力に合わせて、再生互換性に関するある程度の''範囲''を定めたのがプロファイルとレベルである。''プロファイルは主に圧縮率に関連する'''''機能の範囲'''であり、''レベルは主に解像度やフレームレートに関連する'''''量的な範囲'''である。 多くの機器では、例えマニュアルに記載がなくとも、このプロファイルとレベルが合わなければ問答無用で再生不能と判断されてしまう。''画質云々以前の問題''だ。 なお、プロファイルとレベルは、多くの機器で「必要条件」ではあるが「十分条件」ではない。 つまり、''対応のプロファイル・レベルを正しく使用しても、'''''必ず再生できるとは限らない'''。 x264では当然これらの指定が可能であるが、その指定方法には多少のノウハウが必要であるため、この記事にまとめた。レベルと非常に関連の深い（むしろ''レベルの一部''と言うべきである）--vbv-maxrate/--vbv-bufsizeに指定する値も併せて掲載している。 !!プロファイル x264ではプロファイルは使用する「機能（オプション）」によって自動的に決定される。 プロファイルは--profileで強制することが可能で、この場合、指定したプロファイルで無効な機能は、強制的にOFFにされる。 プロファイルは圧縮率に大きく影響するため、できれば再生機器が許す限り、常に高機能なHigh Profileを使いたいところだが、例えば[PSPはMain Profileまで|http://manuals.playstation.net/document/jp/psp/current/video/filetypes.html]しか再生出来ない。 なお、規格上のプロファイルは多数存在するが、ここではx264r1542現在で--profileに指定できるものに限る。 ,Profile,B-frame,interlace,CABAC,Weighted{{br}}Prediction,8x8dct,CQM ,Baseline,no,no,no,no,no,no ,Main,yes,yes,yes,yes,no,no ,High,yes,yes,yes,yes,yes,yes 各機能に関して簡単に説明しておこう。 ::B-frame :::noであるBaselineでは-bまたは--bframesを0で指定する必要がある。 :::これに伴い、Bフレーム関連の機能、つまり--b-adapt, --b-bias, --b-pyramid, --weightb, --pbratioや--partitionsのb8x8等の機能は意味を持たなくなる。 ::interlace :::--interlace, --tff, --bff等で指定するインターレースモードの事で、noであるBaselineでは使用できない。x264で使用可能なMBAFFに限った話ではなく、他のエンコーダで使用可能なPAFFも許可されないので注意。 ::CABAC :::noであるBaselineでは--no-cabacを指定する必要がある。 :::これによって--trellisもOFFになる。 :::なお、x264ではロスレスの場合には--no-cabacに伴い8x8dctもOFF（--no-8x8dct）になる。 :::が、そもそもロスレスは他に色々な制限を含んでおり、かつx264のロスレスはr994以降、High 4:4:4 Predictive Profileなのでここでは扱わない。 ::Weighted Prediction :::noであるBaselineでは、--weight''p'' 0を指定する必要がある。 :::weight''b''も使用できないが、そもそもBフレームが使用できないため--no-weightbは指定しなくともよい（強制でOFFになる）。 :::なおx264ではr1542現在、未実装であるために、weightpとインターレースは併用出来ない。 :::両方指定している場合はインターレースが優先される。 ::8x8dct :::noであるBaseline/Mainでは--no-8x8dctを指定する必要がある。 :::これに伴い、--partitionsのi8x8は意味を持たなくなる。 ::CQM :::noであるBaseline/Mainでは、--cqm, --cqmfile, --cqm4, --cqm8等のカスタムマトリックスが意味を持たず、--cqm flatである必要があることを意味する。 :::デフォルトで--cqmはflatなので特段指定の必要はない。 中でもB-frame, interlace, CABACは非常に大きな要素で、これらの選択次第で映像の見た目、または出力サイズに大きく影響する。正直、Baseline ProfileではH.264のメリットは激減する。つまり、可能な限りMain Profileは使用したい。 !!レベル x264ではレベルは解像度等から自動的に決定される。 ストリームに埋め込まれるレベルの情報は--levelで強制することができる。 上記の--profileと異なり、このオプションは''ストリーム中に埋め込まれるレベルのフラグを指定するのみ''で、指定のレベルに併せて他のオプションを変更したりはしない（例外あり）。 例えば、--levelの自動・手動設定の別に関わらず、''最大ビットレート(MaxBR:--vbv-maxrate)とバッファサイズ(MaxCPB:--vbv-bufsize)は自分で指定する必要がある。'' レベルはプロファイルに比べれば選択の幅がある再生機器が多いが、x264ではプロファイルと違い、レベルと関連のある機能（オプション）を強制できない。 このため、プロファイルよりも注意して見なければ再生互換性に支障を来す可能性が大きい。 また、''レベルはむやみに高くしても、画質が良くなるとは限らない''。 単に再生可能な機器の幅を狭めるだけの結果になることもある。よって、変換元の動画ファイルの条件に従い、解像度・フレームレートの例の範囲にちょうど収まる程度のレベルを選択するのが適切だ。 MaxBR(vbv-maxrate)/MaxCPB(vbv-bufsize)は基本的にはレベルで決まるのだが、プロファイルにも影響を受けて最大値が異なる。 High ProfileのMaxBR/MaxCPBはBaseline/Main Profileの25%増しで計算出来るが、 ここでは利便性のために全てを一覧にする。 なお、バッファにはここで一覧にしているCPBの他、もう一つDPBというバッファが存在する。 DPBそのものの値は一般的には知る必要がないが、それに依存する''参照できるフレーム数(--ref)の最大値''は重要であるため、解像度の例と合わせて表記している。 DPBはプロファイルで変化しないため、--refの最大値も変化しない。 !一覧 数値は最大値であり、それ以下であれば問題ない。 ,Level{{br}}--level,MaxBR{{br}}--vbv-maxrate{{br}}(kbits/s){{br}}Baseline/Main,MaxCPB{{br}}--vbv-bufsize{{br}}(kbits){{br}}Baseline/Main,MaxBR{{br}}--vbv-maxrate{{br}}(kbits/s){{br}}High,MaxCPB{{br}}--vbv-bufsize{{br}}(kbits){{br}}High,interlace{{br}}--interlace/{{br}}--tff/--bff,解像度・{{br}}fpsの例{{br}}(--refの最大値) ,1,64,175,80,218※,no,128x96@30.9(8){{br}}176x144@15.0(4) ,1b,128,350,160,437※,no,128x96@30.9(8){{br}}176x144@15.0(4) ,1.1,192,500,240,625,no,176x144@30.3(9){{br}}320x240@10.0(3){{br}}352x288@7.5(2) ,1.2,384,1000,480,1250,no,320x240@20.0(7){{br}}352x288@15.2(6) ,1.3,768,2000,960,2500,no,320x240@36.0(7){{br}}352x288@30.0(6) ,2,2000,2000,2500,2500,no,320x240@36.0(7){{br}}352x288@30.0(6) ,2.1,4000,4000,5000,5000,yes,352x480@30.0(7){{br}}352x576@25.0(6) ,2.2,4000,4000,5000,5000,yes,352x480@30.7(10){{br}}352x576@25.6(7){{br}}720x480@15.0(6){{br}}720x576@12.5(5) ,3,10000,10000,12500,12500,yes,352x480@61.4(12){{br}}352x576@51.1(10){{br}}''720x480@30.0''(6){{br}}720x576@25.0(5) ,3.1,14000,14000,17500,17500,yes,720x480@80.0(13){{br}}720x576@66.7(11){{br}}''1280x720@30.0''(5) ,3.2,20000,20000,25000,25000,yes,''1280x720@60.0''(5){{br}}1280x1024@42.2(4) ,4,20000,25000,25000,31250,yes,1280x720@68.3(9){{br}}''1920x1080@30.1''(4){{br}}2048x1024@30.0(4) ,4.1,50000,62500,62500,78125,yes,1280x720@68.3(9){{br}}''1920x1080@30.1''(4){{br}}2048x1024@30.0(4) ,4.2,50000,62500,62500,78125,no,''1920x1080@64.0''(4){{br}}2048x1080@60.0(4) ,5,135000,135000,168750,168750,no,1920x1080@72.3(13){{br}}2048x1024@72.0(13){{br}}2048x1080@67.8(12){{br}}2560x1920@30.7(5){{br}}3680x1536@26.7(5) ,5.1,240000,240000,300000,300000,no,1920x1080@120.5(16){{br}}4096x2048@30.0(5){{br}}4096x2304@26.7(5) ※本来はそれぞれ218.75と437.5だがx264は整数しか受け取らないので切り捨て表記とした。 ''インターレースを使用できるのはLevel2.1〜4.1のみ''で、それ以外では使用できない(frame_mbs_only_flag=1)。 !!注意事項 上記では規格の中から抜粋して掲載している。 実際の規格ではもっと様々な規定が行われているが、一般にはあまり気にされていない。 例えばレベルには1秒間に処理できるマクロブロック数が規定されており、 これに従ってフレームのサイズやDPBのサイズが規定されている。 また、x264がr1456で対応した、一部のBlu-ray規格の検証機で検査されるMinCR(Min compression ratio)や、 [[x264でp4x4を使用しない方がよい理由]]で少し触れているMaxMvsPer2Mbも規定されている。 他に、以下のような注意事項がある。 *--refの最大値はレベルで一律決まるのではなく、解像度とレベルの''組み合わせ''で異なる。 **上記の表に記載された解像度の例の範囲で使うことを推奨する。 *上記のMaxMvsPer2Mbの問題に絡み、''Level3以上ではp4x4を使用すると規格に違反する''可能性が高い。 **今後x264の--partitionsにb4x4（つまりbsub8x8）が実装された場合、これにも同様の制限が発生すると思われる。 ***また、b4x4(bsub8x8)は"A.3.3 Profile-specific level limits"のe)に規定するように、MinLumaBiPredSizeにより、Baseline Profile以外かつLevel3.1以上の場合は使用できない。 *x264cliのr1452現在、--refを明示的に指定しなかった場合に限り、レベルに合わせてデフォルトの--ref=3に対する自動的な調整が行われる。 *上記の表のMaxBR/MaxCPBはVCL-HRDのものであり、NAL-HRDでは本来20%増しとなる。 **r1260でVBVをNALレベルで行うようになったx264ではそちらの値でもいいのかもしれない。 **ただし、同時にVCL-HRDを守れているのかは猫研では確認出来ていない。 ***規格書の"C.3 Bitstream conformance"のNOTE 1の解説は気になるが…。 **個人的には安全の為に上記のVCL-HRDの値を使用すること推奨する。 **H.264の規格書では"A.3.1 Level limits common to the Baseline, Constrained Baseline, Main, and Extended profiles"のj)を見よ。 *High Profileの25%増しの根拠については規格書の"A.3.3 Profile-specific level limits"のg)とh)、そして"Table A-2 Specification of cpbBrVclFactor and cpbBrNalFactor"を見よ。 *ここで言う規格書は、200503(Version 3)以降のものを参照すること。 !!おまけ：DPBと--refの最大値の計算 DPBに関してはユーザ側で定義することは何もなく、間接的に--refが影響されるだけなのだが、おまけとして少々触れておく。 DPB(Decoded Picture Buffer)は、デコードされた''生のピクセルデータ''、つまりYUV4:2:0等のそのまま表示可能なデータが置かれるバッファだ。 これらは被参照フレームとなるためにDPBに置かれる。 H.264では複数参照フレームが許されているため、DPBはMPEG-2などに比べて大きい。 この''DPBに置けるフレームの枚数が、すなわち--refの最大値''となる。 200903版(Version 11)のH.264の規格書ではMaxDPBは''マクロブロックの個数(MBs)''を単位として以下のように規定されている（200711版：Version 8までは規定の仕方が異なるので注意）。 ,Level,1,1b,1.1,1.2,1.3,2,2.1,2.2,3,3.1,3.2,4,4.1,4.2,5,5.1 ,MaxDpbMbs,396,396,900,2376,2376,2376,4752,8100,8100,18000,20480,32768,32768,34816,110400,184320 単位がMBsであるため、フレームの枚数もMBs基準で計算する必要がある。ここでは1920x1080をLevel4でエンコードする場合を例に計算してみよう。マクロブロックは16x16ピクセルであること、小数点以下は切り''上げ''になることに注意して欲しい。 {{pre マクロブロック単位の幅　 = 1920 / 16 = 120 マクロブロック単位の高さ = 1080 / 16 = 67.5 → 68 1フレームに含まれるマクロブロック数 = 120 * 68 = 8160 }} この値で上記のMaxDpbMbsを割れば、--refの最大値が求まる。今度は小数点以下が切り''捨て''になるので注意。 {{pre --refの最大値 = 32768 / 8160 = 4.0156... → 4 }} この前掲の表と照らし合わせて見てもらえば、Level4での--refの最大値はこの計算で求まった4になっていることが確認できる。なお、MaxDPBによる制約とは別に、--refの最大値は16であるため、この計算で16を超えてもそれ以上は使用できない。 この式は、"A.3.1 Level limits common to the Baseline, Constrained Baseline, Main, and Extended profiles"のh)と"A.3.2 Level limits common to the High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra, and CAVLC 4:4:4 Intra profiles"のf)に規定されている。 なお、インターレースを使用している場合、マクロブロック単位の高さを求める際には''偶数に切り上げ''がなされる。例えば解像度が1280x720の場合、プログレッシブでは {{pre マクロブロック単位の高さ = 720 / 16 = 45 }} だが、インターレース使用時には {{pre マクロブロック単位の高さ = 720 / 16 = 45 → 46 }} としなければならない。"Annex A Profiles And levels"だけを読んでいても気づきにくいが、"7.4.2.1.1 Sequence parameter set data semantics"で以下のように規定されているからだ。 {{pre FrameHeightInMbs = ( 2 − frame_mbs_only_flag ) * PicHeightInMapUnits }} これによってインターレースエンコードの場合、FrameHeightInMbsは常に偶数になる。 これはMBAFFが高さ方向に2つのマクロブロックを連結してエンコードするため、切りの良い単位が16ではなく32になることに起因する。高さを32で割って端数を切り上げ、その値を2倍すると考えてもいい。 一般的なインターレース素材である480iや1080iではこれによって差異が出ないため問題にならないが、上記のような変わった解像度でインターレースを使用する場合は注意しなければならない。