追記(2012/08/29):
 システムソフトウェアv1.80にて一部仕様変更されているため、こちらを踏まえてお読みください。

昨日発売されたSCEの新携帯ゲーム機「PS Vita」ですが、ゲームはもちろんのこと、ブラウザやソーシャルツール、リッチコンテンツの処理能力も PSP とは比較にならないほど強化されました。

ここでゲームや Twitter クライアントの話題を書いても、ズコー! とコケられそうなので、システムソフトウェア Version 1.50 で再生可能な MPEG-4/AVC(以下H.264) の情報をお伝えしたいと思います。Level3.1 は意図的なリミットかな? と想像するに十分な情報や、BT.709 にはどうやら対応していない PS Vita のカラーマトリクス検証などを交えてお贈りします。

追記(2011-12-25): 「パネルがHDじゃないからBT.709だと思うのがおかしい」という事について、「カラーマトリクスは解像度で定義されているわけではない」という内容の注釈文を加えました。

対応は High Profile Level 3.1 縛りだが、デコード性能は Level 4.x 相当
公式のユーザーズガイドで示されているとおり、PS Vita の H.264 対応状況は 1280x720 の High Profile Level 3.1 迄で、現在のところ Level 3.2 以上の動画ファイルはコンテンツ管理アシスタントで転送できないようになっています。
↑コンテンツ管理アシスタントを利用すると、非対応ファイルはコピー選択時点で拒否される。なお、コンテンツ管理アシスタントはファイルのハッシュを見ており、同一ファイルのファイル名のみを変えて転送しようとすると「コピー先にある」との旨が表示される。
↑コンテンツ管理アシスタントを経由せず PS Vita へファイルを放り込む方法のひとつに、HTTP経由でダウンロードする手がある。HTTPでのダウンロードではファイルの種類だけチェックしているようで、非対応であってもとりあえず PS Vita に入れられる。
↑ダウンロードしたファイルは、その種類別に自動管理される仕組みとなっており、動画ファイルの場合はビデオコンテンツとして自動的にビデオ管理エリアに登録される。

H.264 High Profile Level3.1 は、108,000マクロブロック/s、最大映像レート17.5Mbps、DPB(Decoded Picture Buffering)18,000マクロブロックという仕様であり、解像度 1280x720 であれば最大 30fps で参照フレーム数5を保証する仕様です。

■ PS Vita の MPEG-4/AVC(H.264)デコード能力 #システムソフトウェアv1.50

 
デコード可能な値や機能
x264 エンコード時の該当オプションと注釈
Level
3.1
--level 3.1
High Profile
対応
*8x8dctやカスタム量子化行列等が使える
High10 Profile
非対応
--profile high10(非対応データで再生不可)
解像度
1280x720(最大)
*960x540(or544)や720x480等も可
DPBマクロブロック数
39,600以上(18,000)*2
*解像度と参照フレーム数から算出した筆者予測値
最大フレームレート
60fps(30fps)*2
*120fpsでも再生可だが激しくドロップする
可変フレームレート(VFR)
対応
*PSPやPS3同様、対応している
参照フレーム数(*1)
1280x720で11(5)*2 960x540以下で16(8)*2
--ref
Bフレーム連続数
16
--bframes
最大ビットレート
約40Mbps(17.5Mbps)*2
*40Mbps前後でドロップを確認
音声の最大ビットレート
AAC 256kbps
*映像項目ではないが、音声がないと非対応データとなる
ピラミッド参照
対応
--b-pyramid
OpenGOP
対応
--open-gop
フルレンジ判定
非対応
--range(RGBへはYC伸張変換で固定)
480i のデインタレース再生
対応
--tff or --bff (フィールドオーダーに合わせる)
カラーマトリクス
BT.601(固定)
BT.709非対応

*1 参照フレーム数 = 最大DPBマクロブロック数/(横マクロブロック数*縦マクロブロック数) #1マクロブロックサイズは16x16 *2 括弧内は Level3.1本来のリミット値

High Profile Level3.1
ファームウェア Version 1.50 でのリミット値。Level 3.2 以上はコンテンツ管理アシスタントで PS Vita に転送できず、HTTP 経由などで直接ダウンロードしても「非対応データ」として扱われ再生不可。

High10 Profile
YUV各10bit深度のデータで扱えるプロファイル。これも非対応。

解像度
1280x720 以下であればとくに制限無し(ただし、プログレッシブ映像で2の倍数解像度。インタレース映像の場合は横が2・縦が4の倍数解像度)。エンコーダによっては縦横16の倍数でないと受け付けないかもしれないが、x264 は前述の解像度であれば処理できる。

DPBマクロブロック数
1280x720 で参照フレームを11扱えるというテスト結果から逆算した値。これだけ見ると、Level4.2 と同等かそれ以上のデコードバッファを取れることに。

最大フレームレート
Level3.1 なら30fpsがリミット。テスト結果では60fpsのデコードが可能で名実ともに「720p」対応。一応120fps映像もデコードできるものの、解像度を 320x180@120fps 程度まで落としても激しくドロップするため、内蔵デコーダは60fpsまでの対応と見てよさそう。

参照フレーム数
Level 3.1 を大幅に上回る値が使える。DPB がそれなりに大きく、Level 4.1~4.2 相当の実装ではないかと勘ぐるには充分な数値。

Bフレーム数
制限無し。最大の16を指定しても大丈夫だが、よほど動かない映像でもない限りBフレームが長く連続して扱われる可能性は低い。

最大ビットレート
デコーダの限界なのか、それとも Vita メモリカードのデータ転送レートに起因するものなのか判断が難しいものの、約40Mbps(40Mbit/秒)辺りまでは何とかドロップせずデコードができた。携帯機で観られれば良い程度に圧縮することを考えると、かなりオーバースペックともいえる。ビットレートについてはエンコード時に配慮する必要はないかもしれないが、ハイビットレートでエンコードした際、瞬間的に最大レートを超える可能性はあるため、vbv-maxrate や vbv-bufsize を指定しておいて損は無い。Level3.1 を守り --vbv-maxrate 17500 --vbv-bufsize 17500 で17.5Mbpsリミットを掛けても、大抵の映像であれば余りある画質が期待できる。

なお、PS Vita のGPU IPコア(PowerVR SGX543MP4+)を提供しているImagination Technologies社のPowerVR VXDデコーダを内蔵しているとすれば、古めの VXD370 シリーズで High Profile Level 4.1 / 50Mbps ストリーム、最新の VXD390 シリーズ(スケーラー内蔵)で High Profile Level 4.2 までサポートしているため、これらのチェック結果と仕様が酷似しており辻褄は合う。

ピラミッド参照化
Bフレームを参照フレームとして扱い、時間軸的により近いフレーム間で参照することにより予測誤差を小さくできる。PSP ではデコードできなかった(ただしBフレーム長が1なら作用しないため影響がない)が、PS Vita ではピラミッド参照化を利用したストリームのデコードが可能となった。

OpenGOP
OpenGOP は1つ前の GOP を跨いで参照できるBフレームを持ち、若干の予測精度向上が期待できる。これも PSP ではデコード非対応だったが、Vita では問題なく処理できる。

フルレンジ判定
ストリームに「これはフルレンジ映像ですよ」というフラグを VUI(Video Usability Info)としてセットし、そのフルレンジフラグを参照してポストプロセスに活かすための仕様。PS Vita のデコーダはフルレンジフラグを見ないため、YUV → RGB 色空間変換時の処理はYC伸張(Y16-235,UV16-240 → RGB0-255変換)固定。おそらく、VUI そのものを参照しないのかもしれないが、RGB への変換は理に適っているので問題ない。

480iのデインタレース再生
地味だが、480i のSD映像をデインタレース(I/P変換)再生することも可能。PSP でデインタレース再生できなくなった(昔はできた)動画も、PS Vita は難なく処理。

カラーマトリクスは BT.601 固定だった
注:システムソフトウェアv1.80からBT.709に対応しています

これが最大の落とし穴。今どきの映像コンテンツ、TV・Blu-ray は BT.709 が主流であるため、それらに合わせてマスタリングされた映像をカラーマトリクス変換せずそのままエンコード・PS Vitaで再生すると正しい色が表示できません(PS Vita は --colormatrix といった VUI セッティングが執筆現在では反映されない)。ある映像を視聴していたとき、「あれ? 色がおかしい気がする」と気付いたのがきっかけでチェックをしてみたのですが、論より証拠、以下のテスト映像をご覧ください。

まず、BT.601 と BT.709 カラーマトリクスのチェック用映像として、G(緑):235 の地に G:255 で映像中央に「PS Vita」という文字を乗せた24bit RGB の簡素な素材を用意。その画像をAviSynthで以下のように処理して720フレーム長の24fps映像にします。PS Vita は映像ストリームのみだと非対応データになるため、著作権フリーのBGMデータも併せて処理。カラーマトリクスをチェックするだけの静止画素材なので、再生状況を判断する為にも無音ではなくBGMはあったほが有り難いという判断です。

ImageSource("hogehoge_image.bmp", end=719, use_DevIL=true)
AudioDub(last, WavSource("hogehoge_bgm.wav"))

# BT.709用は ConvertToYV12(matrix="rec709")とする
ConvertToYV12(matrix="rec601")

このように BT.601/BT.709 カラーマトリクスを用いてそれぞれ YUV 色空間に変換し、x264 で PS Vita 用にエンコードしました(VUIにはそれぞれのカラーマトリクス情報を指定)。それを PS Vita で再生し、各カラーマトリクスにどう対応するか、正しく表示できるかチェックする方法です。

  • ダウンロード
  • BT.601カラーマトリクスの映像(PS Vitaチェック用)
    BT.709カラーマトリクスの映像(PS Vitaチェック用)

    # PS Vitaでブラウズして保存すると、自動的にビデオコンテンツとして登録されます
    # PCなどでダウンロードした場合は、コンテンツ管理アシスタントで2つの動画を PS Vita へ転送してください

    映像のチェックポイントとしては──

    ・PS Vita が BT.709 であれば、BT.709 用の映像と元素材が同じ表示となり、文字が薄っらと見える。BT.601 用の映像はやや暗めに表示される。

    ・PS Vita が BT.601 であれば、BT.601 用の映像と元素材が同じ表示となり、文字が薄っらと見える。BT.709 用の映像は緑がすべて255に飽和して「PS Vita」の文字が見えなくなる

    ・PS Vita が VUIを見て BT.601/BT.709 両対応であれば、どちらの映像も文字が薄っすらと見え同様の色で表示される

    実際に PS Vita で表示された映像は後者になったはずです。BT.601 用の映像は「PS Vita」の文字が見え正常に表示される一方、BT.709 用の映像は緑一色で「PS Vita」の文字が背景と同化して見えません。これは、BT.709 のデータを BT.601 カラーマトリクスで RGB にすると係数が異なるため誤変換される現象です。例えば、緑はやや余計に伸張されるため「緑の最大値付近に有るはずの色が飽和して潰れる」という状況に陥ります(このチェックはこれを利用した視認法)。もちろん、他の色も僅かに狂うなどして、正しく表示されません。

    このように、PS Vita は BT.601 カラーマトリクス固定であることがわかります。市販・フリーのお手軽エンコーダやトランスコーダでは、720p以上のHD映像をBT.709で決め打ち、もしくはカラーマトリクス変換できないものがあるため注意が必要ですし、PS Vita ゲーム開発においても、MPEG-4/AVC(H.264)なムービーを制作・エンコードする場合はBT.601マトリクスでRGB→YUV色空間変換するといった配慮が求められます(システムソフトウエアv1.80以降で改善されてるため、現在は使用したカラーマトリクスに合わせてエンコード時にVUIを指定すれば問題ありません)。

  • 注釈
  • 某掲示板のまとめだと思われますが、「パネルがHD解像度ではないのだからBt.601。BT.709と思うのがおかしい」というコメントを拝見しました。しかし、それは半分正解で半分間違いです。なぜなら──
    ・カラーマトリクスは解像度で定義・規格化されているものではない
    ・カラーマトリクスは映像ストリームに適用されるのであって、表示パネルの解像度では左右されない
    からです。

    BT.601(SMPTE 170M)というのは、NTSC伝送時代の放送で主に使用されていました。そして現在はHDTVになりBT.709ベースです。つまり、一般的なソフトやデコーダがカラーマトリクスの違い(昔の制作フォーマットか今のフォーマットか)を「高確率で判別する手法」のひとつとして”解像度”を見ているわけです。

    要は「昔の映像(BT.601)はSD解像度だったから、解像度で判別すれば的を射やすい」というだけであって、カラーマトリクスをデコード時(正確にはデコード後のポストプロセス。色空間変換時)に選択する一手段でしかありません。例えば、現在のHDTVでは映像ストリームの解像度に関係無く BT.709 固定であり、マルチチャンネル放送といったSD解像度送信であってもBT.709です。この事は、ARIB STD-B32 第1部 5.2「低解像度映像サービスにおける映像符号化パラメータの制約条件」にも明記されていますのでご一読ください(つまり、カラーマトリクスは解像度で決められているのではなく、規格に内包されている一仕様に過ぎない)。

    さらに誤解の無いよう書いておくと、PS Vita はテレビではありません。ですので、BT.709 を使おうが BT.601 を使おうが自由ですし、BT.601 だから悪いというわけでなく、「現在主流の映像コンテンツの多くがBT.709を使用しているからには、それらの映像を本来の色で観る場合 BT.601 へ変換したほうがいいよね」ということです。

    PS Vita 用の映像を x264 でエンコードするには
    High Profile については、8x8dct が x264 で標準的にオンであることから特に設定は要りませんし、解像度やフレームレートはソース映像に依るものですので、基本的に x264 側で指定する事はありません。

    ただし、前述したように PS Vita のカラーマトリクスを考慮すると、映像ソースがYUVの場合は BT.601 へ事前に変換する必要があります。AviUtl であれば、色変換で入力を BT.709、出力を BT.601 に。AviSynth であれば、 ColorMatrix プラグインで ColorMatrix(mode="Rec.709->Rec.601") としましょう。

    x264 への指定オプションは──

    x264 --level 3.1 --vbv-maxrate 17500 --vbv-bufsize 17500 --colormatrix smpte170m -o "out_video.mp4" "in_video"

    が、最低限となります(--ref を省略するとデフォルト値 ref 3 が内部指定されるため支障はない)。また、b-pyramid や open-gop はお好みで加え、Bフレーム数やエンコード時のビットレート(crf や bitrate)も好みで指定して構いません。ref も先に書いたとおり5以上を指定できますが、極端に増やしても劇的に画質が改善するわけではありませんし、エンコード速度もそれなりに低下しますので、これも程々が良いでしょう。ピクセルアスペクト比を変えたい場合は --sar の指定も必要です。colormatrix は今のところ指定しても無意味(PS Vita は VUI を見ない模様)ですが、将来的に対応した場合の”保険”にはなるので、指定しても損はありません。vbv-maxrate と vbv-bufsize は必須でないものの、映像をドロップさせず確実にデコードしたい場合は指定しておいたほうが良いでしょう。

    そのほかは分析系オプションですので、基本的に自由に使えます。

  • リンク
  • PlayStasion Vita オフィシャルサイト
    PS Vita ユーザーズガイド(対応フォーマット)
    コンテンツ管理アシスタント for PlayStation
    PowerVR VXD390 デコーダ プレスリリース
    AViUtl のお部屋
    AviSynth ColorMatrix Filter

    1件のコメント

    1. ピンバック: PS Vitaは動画の色がまともに表示されないとネガキャンされるけど違いがわからない件wwww « フェレット速報@ゲーム

    2. ピンバック: PC Wonder » PS Vita用動画エンコード方法

    3. ピンバック: 某水姬的实验室 » Blog Archive » x264帧结构控制参数对比特率和压制速度的影响探究

    コメントを残す

    メールアドレスが公開されることはありません。 が付いている欄は必須項目です

    13 − 12 =

    このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください