徹底研究"Penryn" - Yorkfieldで探る45nm世代Intel Architectureの真実

基本的なアーキテクチャその3

最初に挙げた4つの特徴に関連する新機能のうち、大半はその1とその2で確認したが、全く手付かずなのがSSE4.1である。こちらでもレポートした通り、総当りを掛けた場合には(SSE2を使った場合に比べて)確かにSSE4の効用が確認できるが、DivX独自のサーチアルゴリズムを使ったほうがむしろ高速、という結果がでている。ただPreviewでも述べた通り、本当に意味があるのかを考慮する必要がある。

以前こちらでも触れた話だが、おさらいを兼ねて簡単にまとめておこう。一般論として、MPEG方式の動画の場合、図1の様な構造になっている。I PictureはIntra Pictureと呼ばれ、JPEGなどと同様にその1枚だけで画像を生成できるが、P/B Pictureは前後の画像をもとにした「差分」である。PとBの違いは、Pが片方向予測なのに対し、Bが双方向予測ということであるが、これはそれほど重要ではない。そのPictureの内部をものすごく大雑把にまとめると、図2の様になっている。

さてこの中で、

ヘッダのサイズ : フォーマットによって一意に決まる
動きベクトル : 概ね、画面の大きさによって決まる
音声 : チャネル数・フォーマット・及びビットレートで決まる

という形になっており、変化があるのは動き補償の部分である。この部分は、要するに「動きベクトルを使って再構成した画像と実際の画像の差分」であり、理論上は動きベクトルが正しく検出できていれば、差分が小さくなるために、結果的に画質が上がる事になる。

ちょっと実例を示してみよう。DVDの場合、720×480ピクセル@30fpsで1時間のMovieを収めるためには、概ねビットレートを9Mbps程度に抑えれば良いとされる。これは音声も含めた分であり、音声にDolby Digitalの448Kbpsを当てるとすると、純粋に映像だけのビットレートは8.5Mbpsほど。8.5Mbpsを30fpsで割ると、映像1枚あたり283.3Kbps≒35KBとなる。画像の性質にもよるが、これは結構厳しい場合がある。

論より証拠、例えばPhoto04の画像の場合、720×480ピクセルのJPEGであるが、ファイルサイズは479KBにもなる。これを無理やり35KB以下に抑えたのがこちら(Photo05)で、遠目には判りにくいだろうがディテールが極端に落ちてしまっている。両者の差をとったのがこちら(Photo06)。白べたに近い、DIMMスロットの爪以外のほぼ全ての箇所で画像が異なってしまっている。実際Photo05はかなり「眠たい」画像であり、画質重視のところでこれだと厳しいだろう。