Analysis

圧縮の常識、非常識

2007/04/02

　圧縮するとデータの保存に必要な容量は減るが速度が犠牲になる――。最近、そんな圧縮の常識を覆される例を2つほど知った。

　1つは東京エレクトロンデバイス（TED）が3月12日に発売した米Storewizのストレージデータ圧縮装置の新製品「STN-6000」（参考記事：ストレージ容量を倍増させられる技術とは？）だ。NASの手前に配置し、クライアントPCやサーバからのデータの書き込みや読み出しのデータを圧縮・伸長するアプライアンスだ。NASにストアされるデータ量が減ることは容易に想像ができるが、冒頭に書いた“圧縮の常識”によれば、それによってデータの読み書き速度は若干犠牲になると考えたくなる。しかし、実際には圧縮、伸長のプロセスが入ることによって、むしろ読み書きの速度は向上することがあるという。今やボトルネックとなるのは圧縮のための処理時間ではなく、むしろ物理的なディスクのI/Oにあるというわけだ。

　もう1つは、Oracle Database 10gにあるデータセグメント圧縮の機能だ。この圧縮オプションは、Oracle 9iリリース2 Enterprise Editionで実装された機能だ。問い合わせへの高速な応答が求められるデータベースの世界で圧縮というのは、ちょっと考えると常識に反する選択だが、実際にはディスク上で必要な容量が減るばかりでなく、I/Oアクセスが減ることから多くの場合に高速化も期待できるという。データセグメント圧縮のアルゴリズムは、同一ブロック内で頻出するデータの値を辞書とするという比較的シンプルなもの。そのため、圧縮処理のオーバーヘッドが小さいことも、全体としての高速化に寄与している。

その常識は、今でも本当に気にするべき常識ですか

　圧縮と速度はトレードオフの関係にあるのは真実だ。しかし、ディスクI/Oのコストが無視できなくなった今は、圧縮専用の機器を用意したり、圧縮方式を見直すことで、圧縮した方が結果的に速くなるケースがある。

　プロセッサの処理能力、ストレージの容量やアクセス速度、ネットワークの帯域など、こうしたリソースのコストバランスは常に変化している。そのため、一度は常識と思われたことが、簡単に常識でなくなってしまうことがある。

　かつて、インタープリタ型のスクリプト言語はコンパイル型の言語に比べて実行速度が遅いといわれていた。しかし、PHP、Perl、Rubyなどのスクリプト言語は、今やインターネットを舞台裏で支える重要な技術となっているし、多くの場面で十分な速度を出せる。同様に、「整数を64ビットで持つと遅いのではないだろうか」、「日本語を扱うならUTF-8よりシフトJISのほうがストレージ容量の点で有利ではないだろうか」、「ガベージコレクタのある言語はオーバーヘッドは大きいのではないか」などは古い常識、あるいは先入観と呼ぶべきものだろう。個々に見れば答えがイエスとなるようなものでも、設計全体のことや実時間での実行速度、利用可能なリソースのことを考えると、今や取るに足りない問題であることも多い。

本当にH.264がベストな選択か

　急激にリソースのバランスが変わったために動画圧縮に関しても、ほんの半年か1年前の常識が通用しなくなったように感じている。

　以前、私は動画を撮影するために三洋電機の「Xacti C4」を購入したことがある。2005年の春頃だ。Xactiは早い時期からISO標準準拠のMPEG-4に対応しており、動画を高い圧縮率でSDカードに保存できる数少ない機種だった。しかし購入して気付いたのだが、その当時、ISO標準のMPEG-4が扱えるソフトウェアは少数派である上に、同じ“MPEG-4”でも規格が混乱していて再生環境にすら不安を感じた。むしろMotionJPEGやDVコーデックの方が、容量のことを除けば取り扱いは楽だった。これは基本的に今でも変わっていない。

　そして時代が変わり、今や2GBのSDカードが2000円で買える時代である。こうなると圧縮率優先という発想が常にベストの選択とは限らない。三洋電機がユーザー調査で明らかにしているように（参考記事）、デジカメで撮影する動画は短い。Xactiユーザーの場合、撮影時間は70％以上が30分以内で、10分以内というユーザーも29％もいる。個人的な感想を言わせてもらえるなら、デジカメかDVかを問わず、1カットで3分以上もカメラを回しても散漫な映像にしかならない。あらかじめ、その映像で何を伝えるかを決めて、せいぜい30秒も回せば1カットは終わりという風に撮影しないと、後で編集する気がなくなる。

　そのように短い映像を扱うのであれば、MotionJPEGで十分だ。例えばキヤノンのIXY Digital 900 ISは動画コーデックとして圧縮率の低いMotionJPEGを採用するが、640×480ドット、30fpsでも4GBあれば約30分は撮影できる。320×240ドット、30fpsであれば2GBでも約1時間も撮影できる。

　ハードディスクの容量単価も安いため、撮影した5分の動画ファイルが200MBであるか80MBかは重要と思えない。もしサイズが気になるなら、むしろPCでトランスコードすればいい話で、カメラ側に高度な圧縮処理チップを搭載する必要が本当にあるのかどうか分からない。MotionJPEGであれば、静止画撮影用のJPEGの処理回路がそのまま流用できる。

　少なくとも私はMotionJPEGで少しも困っていないし、むしろMPEG-4よりも画質がきれいになって良かったと思えるほどだ。

ハイビジョンでもMotionJPEG

　米Tzeroテクノロジーズは、UWBを利用して家電やゲーム機を無線でテレビに接続するための送受信モジュールを開発している。彼らが選択した圧縮方式はMPEG-2やH.264ではなく、MotionJPEGだ。JPEGよりやや圧縮率の高いJPEG2000を用いるものの、MPEG-2に比べるとデータサイズは2割増、MPEG-4に比べると約2倍になる。しかし、圧縮も伸張も静止画と同等だからシンプルで、比較的安価なハードウェアでリアルタイムの圧縮が可能だ。

　MPEGのように参照フレームという概念がなく常に各フレームが静止画として伝送されているため、チャンネル切り替えは一瞬でできるし、エラーが発生したときにブロックノイズが画面にしばらく残るといったこともない。なおかつ、ハイビジョンの映像を3本以上同時に伝送する容量を持つ。

　H.264が次世代の動画圧縮技術の標準となることはもはや間違いないだろうが、だからといって、どこもかしこもH.264でという話にはならない。WiFiとUWBではネットワーク帯域が約10倍違うので、圧縮のコストのほうがネットワーク帯域のコストよりも高くなる。

　以上、ストレージ、データベース、動画と、いくつかの事例を見てきたが、圧縮するかしないか、あるいはどんな圧縮方式を使うべきかの答えは、経済的なコスト、処理時間のコスト、利便性のコストなどを天秤にかけて初めて出てくるもので、一般的な結論はないということだ。急激に各種リソースの単価が変わるときには、そのバランス点も変わる。

（＠IT 西村賢）

情報をお寄せください：