表 1. 画像レート
+--------------+-------------------------+
| picture_rate | picture per second |
+--------------+-------------------------+
| 0000 | forbidden |
| 0001 | 23.976 |
| 0010 | 24 |
| 0011 | 25 |
| 0100 | 29.97 |
| 0101 | 30 |
| 0110 | 50 |
| 0111 | 59.94 |
| 1000 | 60 |
| ... | reserved |
| 1111 | reserved |
+--------------+-------------------------+
MPEG はハードウェアデコーダがスムーズにデコードできることを最大の課題にして、 さまざまな仕組みをいれた。 その際、ソフトウェアデコーダにとっては単に不利なものであっても、 問題にされなかったという面がある。 例えば、MPEG の VBV バッファは、その基本的考え方自体、 ソフトウェアデコーダにとっては、ほとんど、なにも意味しない。 ソフトウェアデコーダにとっては、低い画像レートはなんら問題ではなかった。 逆に高い画像レートに対応した、高い必要処理量の面では LSI には対抗できなかった。 低い画像レートを標準に入れて、ソフトウェアデコーダにも MPEG の道を開くことを LSI メーカーは防いだのである。
ところがいま、時代は MPEG-1 のデコーダ LSI を陳腐化しようとしている。 ソフトウェアデコーダは、CPU の高速化につれて自然に高速化してきた。
(脚注) インターフェース 1993 年 3 月号" '92年 10月 MPEG 標準化会議とソフトウェアデコーダの話題" では、私は不覚にも、このフランス提案に対する MPEG の結論を、間違って報告した。
私は 92 年の会合当時は、70 MIPS といわれた、MIPS の R4000 CPU (内部 clock 100MHz) のワークステーションを使っていた。 そのころより少し前から自身で C 言語で書いた X に表示する MPEG-1 デコーダは、 1.15Mbit/s の SIF (352x240サイズ) の典型的ビットストリームで 7Hz であった。 このデコーダは速度も求めたが、むしろ画質優先のデコーダである。
その後、DEC Alpha 5000 という 200 MHz の 64 bit マシンに移ったとき、14 Hz になった。 現在までの最適化、つまりプログラミングの改良で、同じ機械で通常表示 36 Hz、 拡大表示(縦、横ともに 2 倍の大きさで表示すること)で、24 Hz が出るようになった。 最近、Pentium 150 MHz と Linux でデコーダの性能を比較すると、 Pentium 用には全く最適化していないのに alpha の 70%の性能 (通常表示で 26.5Hz、拡大表示で 20 Hz) を出していた。
当然のことだが、ソフトウェアデコーダの速度は CPU 速度が最も主要な要素である。 プログラミングの技術以外としてはほとんど CPU の速度に依存するのである。 最新の 200 MHz PentiumPro(または MMX) であれば、Pentium 150 MHz の 2 倍(MMX で 1.5 倍、 アセンブラで MMX 対応をすれば 5, 6 倍)程度出ると予測される。もしそうなら、 通常表示で 50 Hz、拡大表示で 40 Hz が出ることになる。 いまや、 MPEG-1 は速度の問題はなくなり、 次の目標は MPEG-2 のソフトウェアデコードだと、業界の巷でいわれるのも、 多少の誇張はあっても、あながち嘘ではない。(嘘であるのは、全画面表示の時の速度と画質だろう。)
ソフトウェアデコーダのすごいところは、場所をとらない、 幾つも同時に動かせることだけでなく、放っておいても高速になることである。 しかも 92 年のソフトウェアは、基本的にいまも現役である。 LSI を作ってしまってはこういうことはない。
例えば、OMWF の Internet MPEG 小委員会で実験に供された Sony の MPEG の低レートのビットストリームでは、 64 kbit/s QSIF(176x112)で、上で説明したデコーダが Pentium 150 MHz で、 通常表示 173 Hz、拡大表示 117 Hz、3 倍拡大表示 65 Hz、4 倍拡大表示で 47Hzを出すのである。
つまり、低レートはソフトウェアデコーダにとって有利であり、ソフトウェアでも高速デコードは難しくはない。 この結果を見るとき、デコーダの速度向上に苦しんだ私は、一体なんだったのかと思ってしまう。 ソフトウェアデコーダにとって低レートは天国である。 低レートではソフトウェアデコーダは、ハードウェアと互角以上に戦える。 ハードウェアはインターフェースのためのソフトウェアを必要とするからである。
QSIF 画像、64 kbit/s 以下では、MPEG-1 であろうとテレビ電話の H.261/H.263 であろうと、 画像符号化の符号化(脚注参照)復号処理は、もはやソフトウェア以外には、選択の余地はないだろう。
*(脚注) 低レート MPEG-1 のソフトウェアエンコーダがリアルタイムで動作するか、という問題はかなり微妙である。 低レート H.261/263 ではデコード、エンコードともにかなりの高速化手法があって解決可能だが、 MPEG-1 は蓄積メディア用だから画質が悪くてはリアルタイムであってもほとんど意味がない。 低レートなら前述の Alpha で、QSIF 64 kbit/s 10Hz 画像が Conjugate サーチでは18.4 Hz 程度である。 再量子化係数ドロップまでして 15.6 Hz であるが、フルサーチでは、 メモリーアクセスを最適化したものでも 5 Hz しかでない。
インターネットでの動画像の応用 (1)ビデオメール (2)動画像のブラウジング、動画像リトリーバル (3)VOD (Video on Demand) (4)インターネットフォン (5)パネルディスカッション (6)実況中継インターネット上の動画像応用を考えると、(1)ビデオメール、通常の e-mail の動画像版がある。 (2)動画像のブラウジング(慨覧)、動画像リトリーバルがある。 現在、静止画をダウンロードしてみている応用が動画像に代わるものである。 (3)VOD (Video on Demand) 要求に合わせて、動画像を供給するしくみがある。 映画などの観賞用、個人毎に FF, Rewind などのトリックプレイをサポートする。 (4)インターネットフォン、これはインターネットでの(テレビ)電話である。 ここまでは、ネットワーク上の IP アドレス間の1対1の通信のしくみのまま問題なく使えるだろう。 ところが、(5)パネルディスカッションのように、数人のおしゃべりを他の大勢が聞けるよう にしたものがある。さらには、(6)実況中継が、すでに実験的に行なわれている。 これらは、マルチキャストが使われれなければ、通信用のバスであるインターネットのチャネルの ひどい無駄使いとなる応用である。さらに、(7)放送、はもっとこの問題を先鋭化するだろう。 ネットワークのパイプが太くなれば解決するいう問題ではなく、マルチキャスト処理を各ノードが対応し、 パケットの枝分かれが実現されないと解決しない問題だろう。マルチキャストによって数千人、 数万人という大勢が一ヶ所に同時にアクセスしても、問題のないネットワークにすることができる。
ミニ放送局が大量に生まれるという夢は、そのとき現実化するだろう。 認可、免許などの制度の問題が出ずに、だれもが放送しようと思えばできる仕組みにしなければならない。 すでにインターネットは国際的に結合していて、法律が制御できる範囲はないだろう。 また、すでに視聴者は、このネットワーク上のアドレスを無数に選べるわけだから、 特定のアドレスだけが放送の権利をもつことには、正当化できる理由がなくなっている。 放送は、独占と利権の巣となりやすい。これは、その意味で重要なテーマであり、 マルチキャストは、うまく設計されると、既存の放送システムを陳腐化するぐらいのインパクトをもつだろう。 インターネットという通信の仕組みが放送に利用されようとしている事自体、 すでにマスメディアの終瑙であり、放送はすでに教育にも娯楽にも、役に立たなくなっているのかもしれない。
ソフトウェアデコーダにとってこれらの応用は、本当に低レートだろうか。 ネットワークを流れるビットレートが低レートであると仮定すると、(1)〜(7) について 考えることができる(*脚注参照)。
(2)動画像のブラウジング、動画像リトリーバル
ブラウジングでは、エンコードはリアルタイムである必要はなく、
サーバは高級なエンコードをしたビットストリームを用意すればよく、
デコードだけ対ネットワークのリアルタイムであればよい。
リトリーバルのように、ディスクにセーブして後で表示するのなら、
対ディスクのリアルタイムであり、低レートである必要もない。
(3)VOD
エンコードはリアルタイムである必要はない。
デコードは対ネットワークのリアルタイムであるため低レートになる。
ただ、個人毎のトリックプレイをサポートするくせにセーブを許さない仕組みでは、
ユーザとネットワークの両方にとってメリットがないように思える。
(4)インターネットフォン
これは対ネットワークのリアルタイムエンコードとデコードが必要で基本的に低レートだろう。
通信であるからローディレイの要求もあり、画質上はもっとも厳しい条件である。
(5)パネルディスカッション、(6)実況中継も、(7) 放送も、 (4) と同じ対ネットワークのリアルタイムエンコードデコードである。 ただ、放送をしようとすると高級なエンコーダを用意するだろう。 それにしても、インターネットの高度な応用(4)〜(7)がすべて低レート、 リアルタイムエンコード／デコードという特色をもっているとは驚きである。 もちろん放送も、映画を放送したい場合はリアルタイムエンコードである必要はないが、 そのときにはもう、映画を放送局から放映する意味はほとんどないだろう。
*(脚注)ネットワークを流れるビットレートが低レートであるという仮定は正しいのだろうか、 いつまでも低レートでないのかもしれない。CATV のネットワークでのケーブルモデムの普及が進むと 状況は一変するかもしれない。
この低レート符号化では、例えば 30 Hz のような元の画像レートのままで符号化することは現実的でない。 10 Hz 程度に画像を時間方向にサブサンプリングした画像を符号化する。 どうしてかというと、画質がでないからである。 それだけでなく、あまりに低レートすぎて符号化の処理が正常に動作しない。 まず、SIF 画像では、通常に動くような画像で、レートコントロールが 64 kbit/s に入らなくなる。
最初の OMWF の会合(1996年 7 月 31 日)では、次回までに動画像の符号化実験として、64 kbit/s と 20 kbit/s で、符号化してみようということになった。1996 年 9 月 18 日の第 2 回 OMWF Internet MPEG 小委員会用に実験した MPEG-1 の低レートエンコード結果のビットストリームを表 2 に示そう。
シーケンスは MPEG で用いられた標準画像(著作権は ITU-R にある。) Bicycle, Bus, Flower Garden, Football, Mobile and Calendar, Table Tennis を使った。これらは各 5 秒のシーケンスで、 ITU-R 601 フォーマットから SIF に MPEG-1 の SM3 に従ってフィルターでダウンサンプルしている。 MPEG-1 のエンコーダ は SM3 にレートコントロールだけ MPEG-2 の TM0 レートコントロールを入れた ものである(インターフェース 1992 年 8 月号 "MPEG の概要と標準化動向", pp.124-146 参照。)。
表 1.a を見ていただくと 1 Mbit/s ではレートコントロールが正常に機能している (1 Mbit/s * 5s /8bit = 625 kbyte となる) ことが分かるだろう。 ファイル名に "q" の文字がついたものは、QSIF である( QSIF は、次回から 176x112 としたが、 このときは 176x128 としていた。)。 SIF から QSIF へもやはり同じ 7 tap のフィルター ([-29, 0, 88, 138, 88, 0, -29]//256) で、縦横とも 1/2 にダウンサンプルしている。
表 2. MPEG-1 で符号化したビットストリームファイル長
表2.a 1 Mbit/sで符号化
-rw-rw---- 1 katayama 240 625234 08月11日 1996 bic1000.mpg
-rw-rw---- 1 katayama 240 624937 08月11日 1996 bic1000q.mpg
-rw-rw---- 1 katayama 240 624916 08月11日 1996 bus1000.mpg
-rw-rw---- 1 katayama 240 624807 08月11日 1996 bus1000q.mpg
-rw-rw---- 1 katayama 240 625442 08月11日 1996 flr1000.mpg
-rw-rw---- 1 katayama 240 625009 08月11日 1996 flr1000q.mpg
-rw-rw---- 1 katayama 240 624554 08月11日 1996 ftb1000.mpg
-rw-rw---- 1 katayama 240 624978 08月11日 1996 ftb1000q.mpg
-rw-rw---- 1 katayama 240 625071 08月11日 1996 mac1000.mpg
-rw-rw---- 1 katayama 240 624901 08月11日 1996 mac1000q.mpg
-rw-rw---- 1 katayama 240 625573 08月11日 1996 tbl1000.mpg
-rw-rw---- 1 katayama 240 624975 08月11日 1996 tbl1000q.mpg
*(脚注)この SIF 500 kbit/s 程度の画像が 91 年頃の標準画像の 1.15 Mbit/s のシミュレーションと 画質的に一致している。当時から、エンコーダ事項だけで符号量が 1/2 になったのである。 当時の 8-escape, B-quant の事を知る人は少ないだろうが、SM-3 を読もうと努力してごらんなさい。 どれだけの混乱がこの公式文書に残っているか知ると、標準化の作業の難しさに多少でも触れることができる。
表2.b 500 kbit/sで符号化
-rw-rw---- 1 katayama 240 388391 08月11日 1996 bic500.mpg
-rw-rw---- 1 katayama 240 312490 08月11日 1996 bic500q.mpg
-rw-rw---- 1 katayama 240 311443 08月11日 1996 bus500.mpg
-rw-rw---- 1 katayama 240 312448 08月11日 1996 bus500q.mpg
-rw-rw---- 1 katayama 240 331216 08月11日 1996 flr500.mpg
-rw-rw---- 1 katayama 240 312540 08月11日 1996 flr500q.mpg
-rw-rw---- 1 katayama 240 317271 08月11日 1996 ftb500.mpg
-rw-rw---- 1 katayama 240 312319 08月11日 1996 ftb500q.mpg
-rw-rw---- 1 katayama 240 313711 08月11日 1996 mac500.mpg
-rw-rw---- 1 katayama 240 312465 08月11日 1996 mac500q.mpg
-rw-rw---- 1 katayama 240 313085 08月11日 1996 tbl500.mpg
-rw-rw---- 1 katayama 240 312529 08月11日 1996 tbl500q.mpg
表 2.c の250 kbit/sでは、SIF はどれもレートがコントロールできていない。 QSIF ではどのシーケンスもまだ問題が出ていない(156 kbyte になっている)。
表 2.c 250 kbit/sで符号化
-rw-rw---- 1 katayama 240 383756 08月11日 1996 bic250.mpg
-rw-rw---- 1 katayama 240 156478 08月11日 1996 bic250q.mpg
-rw-rw---- 1 katayama 240 271972 08月11日 1996 bus250.mpg
-rw-rw---- 1 katayama 240 156260 08月11日 1996 bus250q.mpg
-rw-rw---- 1 katayama 240 326590 08月11日 1996 flr250.mpg
-rw-rw---- 1 katayama 240 156391 08月11日 1996 flr250q.mpg
-rw-rw---- 1 katayama 240 281751 08月11日 1996 ftb250.mpg
-rw-rw---- 1 katayama 240 155893 08月11日 1996 ftb250q.mpg
-rw-rw---- 1 katayama 240 293243 08月11日 1996 mac250.mpg
-rw-rw---- 1 katayama 240 156263 08月11日 1996 mac250q.mpg
-rw-rw---- 1 katayama 240 196628 08月11日 1996 tbl250.mpg
-rw-rw---- 1 katayama 240 156329 08月11日 1996 tbl250q.mpg
表 2.d 125 kbit/sで符号化
-rw-rw---- 1 katayama 240 382209 08月11日 1996 bic125.mpg
-rw-rw---- 1 katayama 240 112971 08月11日 1996 bic125q.mpg
-rw-rw---- 1 katayama 240 270527 08月11日 1996 bus125.mpg
-rw-rw---- 1 katayama 240 81745 08月11日 1996 bus125q.mpg
-rw-rw---- 1 katayama 240 325214 08月11日 1996 flr125.mpg
-rw-rw---- 1 katayama 240 89405 08月11日 1996 flr125q.mpg
-rw-rw---- 1 katayama 240 279786 08月11日 1996 ftb125.mpg
-rw-rw---- 1 katayama 240 86746 08月11日 1996 ftb125q.mpg
-rw-rw---- 1 katayama 240 291963 08月11日 1996 mac125.mpg
-rw-rw---- 1 katayama 240 79644 08月11日 1996 mac125q.mpg
-rw-rw---- 1 katayama 240 194354 08月11日 1996 tbl125.mpg
-rw-rw---- 1 katayama 240 78176 08月11日 1996 tbl125q.mpg
表 2.e 64 kbit/s では QSIF もすべてだめである。 40 kbyte を大きく超えている。
表 2.e 64 kbit/s で符号化
-rw-rw---- 1 katayama 240 111973 08月11日 1996 bic64q.mpg
-rw-rw---- 1 katayama 240 80239 08月11日 1996 bus64q.mpg
-rw-rw---- 1 katayama 240 88282 08月11日 1996 flr64q.mpg
-rw-rw---- 1 katayama 240 84043 08月11日 1996 ftb64q.mpg
-rw-rw---- 1 katayama 240 78898 08月11日 1996 mac64q.mpg
-rw-rw---- 1 katayama 240 55041 08月11日 1996 tbl64q.mpg
QSIF にするだけではレートが 64 kbit/s に収まらないことが分かったため、単純に画像レート を下げてみた。それでも、いくつかの画像は 64 kbit/s に収まらないため、量子化マトリックス を数回、倍化(2 倍して 255 を超えると 255 にする)してテストした。
画質評価に使うリアルタイムデコーダとして私の作成したソフトウェアデコーダが使われた。 拡大表示で 4 つ同時デコード拡大表示(約 30Hz まで可能)で画質の比較ができる。 とくに X のカラーマップの操作によって、デコード画像のウィンドウ以外を 真っ黒にして画像を比較するのは、非常に効果的で的確に画質を評価できる。
この実験で、符号化画像を見て、64 kbit/s 程度では一般的に、QSIF の 10 Hz 位が動きと 画像のぼけとのバランスがよいことが分かった。
表 2.f 64 kbit/s で符号化
-rw-r--r-- 1 10007 240 39887 09月09日 1996 bic_64_15_q_1.mpg
-rw-r--r-- 1 10007 240 40025 09月09日 1996 bus_64_15_q_1.mpg
-rw-r--r-- 1 10007 240 40029 09月09日 1996 flr_64_15_q_1.mpg
-rw-r--r-- 1 10007 240 39990 09月09日 1996 ftb_64_15_q_1.mpg
-rw-r--r-- 1 10007 240 40122 09月09日 1996 mac_64_15_q.mpg
-rw-r--r-- 1 10007 240 39969 09月09日 1996 mad_64_15_q.mpg
-rw-r--r-- 1 10007 240 40192 09月09日 1996 tbl_64_15_q.mpg
-rw-r--r-- 1 10007 240 39475 09月12日 1996 bic_64_10_q_1.mpg
-rw-r--r-- 1 10007 240 38653 08月29日 1996 bus_64_10_q.mpg
-rw-r--r-- 1 10007 240 39613 08月29日 1996 flr_64_10_q.mpg
-rw-r--r-- 1 10007 240 39693 08月29日 1996 ftb_64_10_q.mpg
-rw-r--r-- 1 10007 240 41081 08月29日 1996 mac_64_10_q.mpg
-rw-r--r-- 1 10007 240 41348 08月29日 1996 mad_64_10_q.mpg
-rw-r--r-- 1 10007 240 39635 08月29日 1996 tbl_64_10_q.mpg
-rw-r--r-- 1 10007 240 37657 08月29日 1996 bic_64_5_q.mpg
-rw-r--r-- 1 10007 240 37863 08月29日 1996 bus_64_5_q.mpg
-rw-r--r-- 1 10007 240 37992 08月29日 1996 flr_64_5_q.mpg
-rw-r--r-- 1 10007 240 38813 08月29日 1996 ftb_64_5_q.mpg
-rw-r--r-- 1 10007 240 39095 08月29日 1996 mac_64_5_q.mpg
-rw-r--r-- 1 10007 240 39883 08月29日 1996 mad_64_5_q.mpg
-rw-r--r-- 1 10007 240 39378 08月29日 1996 tbl_64_5_q.mpg
-rw-r--r-- 1 10007 240 38751 09月09日 1996 bic_64_5_3.mpg
-rw-r--r-- 1 10007 240 40842 09月09日 1996 bus_64_5_2.mpg
-rw-r--r-- 1 10007 240 40895 09月09日 1996 flr_64_5_2.mpg
-rw-r--r-- 1 10007 240 40630 09月09日 1996 ftb_64_5_2.mpg
-rw-r--r-- 1 10007 240 39527 09月09日 1996 mac_64_5_1.mpg
-rw-r--r-- 1 10007 240 39164 09月09日 1996 mad_64_5_0.mpg
-rw-r--r-- 1 10007 240 40006 09月09日 1996 tbl_64_5_1.mpg
表 2.g 20 kbit/s で符号化
20 kbit/s では符号化できないわけではないが、画像の質は、かなり落ちる。
-rw-r--r-- 1 10007 240 11926 09月09日 1996 bic_20_5_q_2.mpg
-rw-r--r-- 1 10007 240 11873 09月09日 1996 bus_20_5_q_2.mpg
-rw-r--r-- 1 10007 240 13159 09月09日 1996 flr_20_5_q_1.mpg
-rw-r--r-- 1 10007 240 13135 09月09日 1996 ftb_20_5_q_1.mpg
-rw-r--r-- 1 10007 240 12372 09月09日 1996 mac_20_5_q_1.mpg
-rw-r--r-- 1 10007 240 12354 09月09日 1996 mad_20_5_q_0.mpg
-rw-r--r-- 1 10007 240 11386 09月09日 1996 tbl_20_5_q_1.mpg
MPEG-1 は、CD-ROM、Video-CD などの 1.5 Mbit/sの媒体を応用として作成された標準である。 64 kbit/s は、MPEG-1 のシミュレーションに使われた 1.15 M bit/s からいうと 1/16 である。 これには、画像レートを 10 Hz (1/3) に下げ、画像を QSIF (176 x 112) 程度にして面積で 1/4 以下に小さくして、全体の符号量を 1/16 に下げるというのが妥当な戦略である。
この最初の実験時に、NASA の用意した MPEG-1 ビットストリームもデコーダのデモとして表示した。 ネットワークからダウンロードしておいたものをデコード表示したのである。 NASA の MPEG-1 画像は数 100 kbit/s でエンコードされていて画質もよく楽しめる。
Sony の作った QSIF(176x112) 30 Hz 64kbit/s の画像も、 ネットワーク(TCP-IP)を直接通したリアルタイム表示(動画像ブラウジング)として GCL でデモをすることができた。 赤ん坊がシャボン玉と戯れる画像で非常にきれいな画像である。素材の選択がうまいことと、 Sony のエンコーダの性能が期待できることを示していた。デコーダも非常に軽く動作する。 ローカルな表示なら 4x4 拡大表示で 44〜45 Hz (当時)出た。 これは、前述の "低レートは天国" の話題で示したビットストリームである。
ネットワークの動画像リトリーバルとリアルタイム表示は同時にでき、 ネットワークの状態によって時々画像は停止するが、これは有望な応用であると思われる。
このころまでに低レート用の Sony の方式が明確になっていた。 画像構造としては 30 Hz M=3 (M とは I,P の周期)だが、その内の 2/3 の B-picture は 全て空の画像にしていた。名目の画像レートは 30 Hz であるが、実質の画像レートは 10 Hz である。 空の B-picture を作り出すためのオーバーヘッドを小さいとすると、これは通常の 10 Hz M=1 (I,P だけの画像) に相当する。それに対して GCL のシミュレーションは 10 Hz M=3 である。 一方の Sony は MPEG-1 の画像レート規定に従っている。GCL の実験で行なった直接の 10 Hz は MPEG-1 の画像レート規定から外れているが、10Hz 画像に B-picture を使うことができる。 そこで、両者の性能を比較する必要があった。
次回は、この条件(QSIF, 10Hz, 64 kbit/s )で B-picture の有効性の実験をする。 GCL は 10 Hz のままで、M=1 と M= 3 を実験する。 低レートでレートコントロールの Step 3 の有効性が疑問なのでこれも調べる。 Sony はハードウェア製品なので、実質 M=3 にする方法がない。 エンコードのアルゴリズムも SM3 +TM0RC とは違うので、同じシーケンスを使って GCL と画像の比較をする。
シーケンスとしては、典型的なものを選択して、Table Tennis, Bicycle, Flower Garden の三つを使うことに決めた。その他の N (I の周期)と QSIF のサイズなどの条件もできるだけ 合わせてやる。シーケンスヘッダも 5 秒なら 1 つでよいとした。
原画像順で、BBIBBP...となっているとして BB の画像をすべて後ろの I, P 画像と同じにする。 B-picture の中ではスライスは一つにする。スライスの先頭のマクロブロックと最後のマクロブロックを、 動きベクトル (0,0) の逆方向予測の NotCoded にして、両者の間のマクロブロックは、 すべて skipped マクロブロックにする。つまり、この画像は逆方向予測だけで完全に予測され、 B-picture の符号がほとんど無しですむ。
変化する中身のある画像は I,P だけにして B を使わない。こうすると実質 10 Hz画像を名目 30 Hz にすることができる。 標準に従うかぎり、こうした方法を取らざるを得ない。
ただ、この方法には限界があることもすぐに明らかになる。中身のある 10 Hz の画像には B-picture が使えない。中身のある画像に B-picture を使うと、(中身が後ろの画像と同じ B-picture を b と書く。) bbIbbBbbPbb.. という画像の並びでは、Bの直前のbb の各 b は B と同じだけの符号量を発生してしまい、 符号化効率が悪くなる。空の P-picture でも IppPppPppP... という並びを作ることができ、 B を空にするのと効率は同じである。
B-picture の強力な双方向予測は、MPEG-1 の効率的な符号化の最大の技術的成果である。 これを放棄することは、テレビ電話の符号化 H.261 に逆もどりではないか。悪く言えば、 単に標準の仕様の問題を、ユーザーに押しつけているのではないか。あの 1992 年のロンドン会合で、 空っぽの画像を利用して画像レートが低下できる、といって MPEG Video の議長のLeGal (ルガール)が、 フランスの意見を退けた内容が、こんなものだったとは、その会合の出席者だった私は、当時気が付かなかった。
シーケンス: Table Tennis, Flower Garden, Bicycle
共通条件:
・QSIF (176x112) 10 Hz
・N= 12
30 Hz 原画像で、N=30 である Sony の条件に合わせた N=10 では M=3 の倍数でないので、
これに近い N=12 とした。符号化画像数は 48 である。
シーケンスヘッダは、シーケンス全体で一つにすることはまだできてなくて、
4 つの I-picture 毎についている。
・量子化マトリックス: Table Tennis は Default 量子化マトリックスを使い、 Flower Garden と Bicycle は、ビットレートを 64 kbit/s に収めるため、 TM の量子化マトリックスを 2 倍して使った。
・動き推定: ダイレクトフルサーチ ( +-7/(10Hz のフレーム間隔) )。
表 3. B-picture の有効性(輝度のSNR)
+-------------------+-----------+------------+------------------+
| シーケンス | M=1 | M=3 | 差 (M=3)-(M=1) |
+-------------------+-----------+------------+------------------+
| Table Tennis | 27.48 | 28.20 | +0.72 |
| without RCstep3 | 28.37 | 29.17 | +0.80 |
+-------------------+-----------+------------+------------------+
| Flower Garden | 20.28 | 21.20 | +0.92 |
| without RCstep3 | 20.84 | 21.69 | +0.85 |
+-------------------+-----------+------------+------------------+
| Bicycle | 20.59 | 20.80 | +0.21 |
| without RCstep3 | 21.11 | 21.26 | +0.15 |
+-------------------+-----------+------------+------------------+
動きの大きい Bicycle では M=3 の効果が小さいが、その他のシーケンスでは M=3 の効果は+1.0 dB 近くあり、 M=1 と M=3 の違いは画像を目で比較した場合に視認できる程度である。 この差は、約 2 dB の差があった MPEG-1 の 30 Hz のB-picture の効果と比べると小さい。
Sony の画像とGCL の画像との比較では 3 つの標準画像のシーケンスでは M= 1 と M= 3 との違いよりも 2 社の画像の差の方が大きいことが分かった。 必要なのは M=1 と M=3 の性能の差を客観的に把握することでであり、 ハードウェアとソフトウェアでは容易なことと困難なことが異なる。 また、Sony のエンコーダは標準画像よりも容易な画像にチューニングしてあるとの Sony のコメントもあった。 M=1 と M=3 の差が会社の差より小さいということは、B-picture を取り立てて望むべきでないのかもしれない。 画像構造の符号化効率の違いが、 エンコーダのアルゴリズムの違いに隠れてしまう程度 (+1dB 以内) であるということである。 しかし、Sony が M=1 にあたる方法でありながら、GCL の M=3 よりも良い画像を出してくれたら、 すぐに私は、M=3 の案を引っ込めていただろう。実際は、その逆であった。 これでは、B-picture の有効性の立証もできなかったし、有効性の否定の立証もできなかったという、 宙ぶらりんの状態になってしまった。
会合では、次回までに(1)量子化マトリックスを修正しなくても符号量が目的の範囲に入るように、 GCL のエンコーダに係数 drop によるレートコントロールを入れようということになった。 MQUANT が 31 にへばり付いてしまうことを DCT 係数の除去で避けるものである。 これは昔から多くの会社でエンコーダをロバストにするため使われる技術であるが、 MPEG-1 の SM, MPEG-2 の TM などには記述されていないものである。
もう一つは努力目標であるが (2)QSIF フィルタのチェックである。601 to SIF は 7 tap の [-29, 0, 88, 138, 88, 0, -29]//256 の フィルタが使われているが、 SIF to QSIF も同じものでサブサンプルしている。 高域強調効果のあるフィルタを 2 回も掛けるのは何かおかしい、 ということで QSIF の原画像をチェックしたいということである。 また、Sony のエンコーダは 601 から独自なフィルターで 1/4 ダウンサンプルして QSIF を作り出しているため、その効果も確かめたい。
(1)なにも変えない。完全に従う。
MPEG-1 はすばらしい。完ぺきで欠点がない。非難されるべきものは全くない、という考えであれば (1) である。
(2)なにも変えない。従えない項目は無視する。
現在のほとんどの実用的な速度のソフトウェアデコーダはこの態度であるようにみえる。
画像レートも到達目標でしかなく、VBV は関係なさそうで、IDCT 精度などほっておけという態度である。
(3)全く従わない。
これなら MPEG など気にすることもない。ソフトウェアの M 社、 A 社、 Game のメーカーなどは
MPEG みたいな重たいものは使えないという意見をもっているのではと思う。
各社独自方式は技術を盗まれることも少ない。読まれる事も少ない。一般大衆は独自性を買う。
(4)補足または解釈を作成する。
標準を尊重して解釈をする。例えば、(a)スライスに Gap (ギャップ)を許し、
B-picture の Gap は Video output buffer からの forward MV=(0,0) Not Coded とする。
という解釈をすると、bbIbbBbbPbbBbbP のような画像構造が効率的にとれる。
(b)I,P,B,D 以外の画像は空であるという解釈をしてもよい。
(c)Temporal Reference を優先し skipped picture があるものとする。
(a)(b)(c)いずれでも、画像レートを追加せずに低い画像レートになる。
残念なのは、標準の技術的内容を変えない限り、これらの解釈は間違っているということである。
こうしなくとも、つぎの (5) のように画像レートを追加するべきではないだろうか。
(5)真正面から変更を提起する。
画像レート(picture_rate) は ISO がまだ拡張できる "reserved" が 7 つあるので、
15, 12.5, 12, 10, 8.333, 8, 6 (または 92 年の フランス提案のように、
23.976/2= 11.988, 24/2= 12, 25/2= 12.5, 29.97/2= 14.985, 30/2= 15 )
を追加する。その場合、R/P ＜＝ 1.856 Mbit/23.976 として、
デコーダの入力バッファの最大値は変えないようにする。(R:bitrate, P:picture rate)
これは R が低レートなら、低い画像レートも入力バッファの大きさに影響を与える必要はない。
これを MPEG-1 の改定時期(1998 年)に提案することは可能であろうか。
LSI メーカーはこういう改定を許すだろうか。恐らく否定的だろう。
(6)規定の修正は考えず、それ以外の事を考える。
面倒な改定の標準化作業を避けて、私は低レートの交換形式を作成するのであって、
MPEG 規定には関係有りませんという態度をとること。しかしこれも実質的に MPEG-1 を非難している。
MPEG はもともと交換形式だったのだから。
しかし、Internet の中での動画像伝送には 1 Mbit/s は望めない。 現在は 20〜40 kbit/s 程度であろうし、1〜2 年後に 64 kbit/s 程度を越す程度だろう。 基本的に低レートであることは変わりがないだろう。低レート用交換形式ならあり得るかもしれない。
B-picture の有効性実験で見たように TM0 のレートコントロールでは 10 Hz, 64 kbit/s に適用するとレートコントロールできない画像がある。 Table Tennis, Bicycle, Flower Garden のうち、Bicycle と Flower Garden でレートを制御できない。 これは MQUANT が最大値 31 にへばり付いていると思われる。 そのため、次の (b), (c) の 2 つのレートコントロール方法を作成し、符号化結果を比較した。
(a) 量子化マトリックス倍化 (参照用)
あらかじめ量子化マトリックスを 2 倍する。(値が 255 を超える場合は 255 とする。)
画質が高いが 1 パス処理でないのでレートコントロールできたとはいえない。
(b) 周波数 Drop 法
Buffer からくる、 Mquant (Step 2 の量子化パラメータ $Q_i$)を[1,31]に制限して mq とし、
係数位置のジグザグ順で、66-mq*2 番目以降をすべて 0 にする。
(c) 再量子化 Drop 法 (Level Drop)
TMレートコントロール Step 3 の Activity で変化させ、[1,31] に制限する前の Mquant を使って
量子化し、0 になる係数の原係数値を 0 として、再度 [1,31] に制限した Mquant で通常に量子化する。
表 4. レートコントロール方法の SNR の比較
+--------------------------+------------------------+
| シーケンス | SNR(Y,Cb,Cr) |
+--------------------------+------------------------+
|Bicycle (a) | 20.97 29.15 28.43 |
| (b) | 20.10 29.54 28.72 |
| (c) | 20.86 29.05 28.58 |
+--------------------------+------------------------+
|Flower Garden (a) | 21.47 26.39 30.19 |
| (b) | 20.14 26.63 30.59 |
| (c) | 21.41 26.40 30.18 |
+--------------------------+------------------------+
|Table Tennis (a) | 28.47 35.36 33.18 |
| (b) | 26.89 35.47 33.32 |
| (c) | 28.78 35.28 33.16 |
+--------------------------+------------------------+
表 4. に 3 つの符号化結果を示す。結果を説明すると、(a)を基準として、(b)は色差の SNR は 多少向上しているが、輝度 SNR が大きく(0.7〜1.6dB 程度) 低下する。それに比較して、 (c)は色差、輝度とも SNR は -0.1dB 〜 +0.3dB であり、 一般的な係数ドロップによるレートコントロールに付き物の SNR 低下がない。 (c) の方式は低レートのレートコントロール用に有効であり、 レートコントロール能力が上がり、符号化できる画像の範囲が広がる。
(2)十分高いレートとして 1 Mbit/s と 2 Mbit/s で QSIF 64 kbit/s 10 Hz を符号化し、 デコーダで QSIF 画像を確認する。これには Sony も 1 Mbit/s と 2 Mbit/s のビットストリーム を作成した。これは Sony の符号化前処理( 601 から直接、長い tap のフィルタで QSIF を作成している。) の効果を見ることにもなる。
表 5. フィルターの比較をしたときの SNR (十分高いことを確認するだけ(GCL)) bic_1m.log:total SNR (48 frames) 38.03 38.51 39.32 bic_2m.log:total SNR (48 frames) 43.82 45.72 46.41 flr_1m.log:total SNR (48 frames) 39.81 40.09 40.39 flr_2m.log:total SNR (48 frames) 45.18 46.15 46.46 tbl_1m.log:total SNR (48 frames) 45.27 47.76 47.24 tbl_2m.log:total SNR (48 frames) 45.77 47.90 47.50
これらの目視による確認で、4 画素平均処理では明らかに画質が低下していることを確認した。 GCL の入力処理 (2 段階 7 tap フィルター)と Sony のフィルターの間も明確に違いが分かり、 2 段階 7 tap フィルターは高域強調が、かなり強いことも分かった。
インターネット上での AVアクセス, VOD, リアルタイム画像通信を目的として MPEG-1 の シンタックス上のパラメータの範囲の限定を推奨するのである。そしてそれを交換形式と呼ぼう。 交換形式は低レート伝送と MPEG-1 ソフトウエアデコーダでの再生を主に考慮して作成するため、 低レートの効率を最優先する。パラメータ制限を満たすビットストリームは、 そのまま交換形式に変換できる。これを満たさないものは、その幾つかの項目値の値を無視すれば、 交換形式に変換できる。
低レート用交換形式は MPEG-1 のパラメータ制限として作成されるので、Backward Compatibility (逆方向互換性) をもつ。パラメータ制限だけなら、MPEG-1 よりも強い制約であり、 MPEG-1 を壊すことにはならない。交換形式は画像レート以外は MPEG-1 のシンタックスの部分集合である。
交換形式はパラメタを制限するのでシンタックスを単純化できる。 省略時値(default)をもたせた多くの MPEG-1 の項目は、省略して伝送を避けることができ、 客観的な評価基準である符号化効率が向上する。
つまり、交換形式の構文は MPEG-1 の構文と違っていて、より効率的でありうるのである。 MPEG-1 のビットストリームからトランスコーダ(符号変換器)によって変換でき、 トランスデコーダ(符号逆変換器)によって高速に MPEG-1 のシンタックスに戻せることを前提にする。 交換形式から MPEG-1 のシンタックスへの逆変換が可能なら、 MPEG-1 のソフトウェアデコーダには問題なくデコード可能となるだろう。
単純な交換形式を明示する事は、MPEG-1 のどの項目が無視できるかを明確にするためと、 低レートでの効率向上を定量的に評価をするためにも必要である。
ソフトウェアデコーダの直前にトランスデコーダを仲介して、 シンタックスの逆変換と画像レート調整をする。 別シンタックスのビットストリームは、トランスデコーダによって MPEG-1 のシンタックスに戻され、 同時に画像毎の表示時間を調整して遅い画像レートにすることができる。 ソフトウェアデコーダであれば入力するビットストリームが停止して、そのまま画像が停止するだけであり、 なんら問題にはならないだろう。 トランスデコーダは UNIX の標準入力出力でつながったフィルタとして考えると容易であることがわかる。
表 6. に、MPEG-1 のヘッダのビット数を示す。 表 6.a は、シーケンスヘッダの構文要素のビット数とそれらの合計である。 2 つの量子化マトリックスを含める場合は、それぞれ 512 ビットずつ増える。 含めないとき 96 ビットになる。
表 6.a シーケンスヘッダ
--------------------------------+-------------+
構文要素 | ビット数 |
--------------------------------+-------------+
sequence_header_code | 32 |
horizontal_size | 12 |
vertical_size | 12 |
pel_aspect_ratio | 4 |
picture_rate | 4 |
bit_rate | 18 |
marker_bit | 1 |
vbv_buffer_size | 10 |
constaraint_parameter_flag | 1 |
load_intra_quantizer_matrix | 1 (+512) |
load_non_intra_quantizer_matrix | 1 (+512) |
--------------------------------+-------------+
total | 96(+512+512)|
--------------------------------+-------------+
括弧()内は量子化マトリックスを付けた場合のビット数。
表 6.b は GOP ヘッダである。合計は 64 ビットになる。
表 6.b GOP ヘッダ
--------------------------------+-------------+
構文要素 | ビット数 |
--------------------------------+-------------+
group_start_code | 32 |
time_code | 25 |
closed_gop | 1 |
broken_link | 1 |
zero stuff | 5(*) |
--------------------------------+-------------+
total | 64 |
--------------------------------+-------------+
(*)次のスタートコードのバイト配置を保つための stuffing ビット
表 6.c ピクチャーヘッダ
--------------------------------+-------------+
構文要素 | ビット数 |
| (I,P,B) |
--------------------------------+-------------+
picture_start_code | 32 |
temporal_reference | 10 |
picture_coding_type | 3 |
vbv_delay | 16 |
full_pel_forward_vector | 0, 1, 1 |
forward_f_code | 0, 3, 3 |
full_pel_backward_vector | 0, 0, 1 |
bakcward_f_code | 0, 0, 3 |
extra_bit_picture | 1 |
zero stuff | 2, 6, 2(*) |
--------------------------------+-------------+
total | 64, 72, 72 |
--------------------------------+-------------+
(*)次のスタートコードのバイト配置を保つための stuffing ビット
表 6.d は スライスヘッダの構文要素とそれらのビット数である。合計は 38 ビットである。
表 6.d スライスヘッダ
--------------------------------+-------------+
構文要素 | ビット数 |
--------------------------------+-------------+
slice_start_code | 32 |
quantizer_scale | 5 |
extra_bit_slice | 1 |
--------------------------------+-------------+
total | 38 |
--------------------------------+-------------+
ところがこのスライスヘッダの符号量は、MPEG-1 のシンタックスのままでも、 スライスの長さをピクチャー全体まで拡大して節約できるのである。 この方法は低レートでは、当然利用するべきだろう。 すなわち、最低 1 つのスライスが必要で、これとピクチャーヘッダを合わせたものが MPEG-1 シンタックスに従うときのオーバーヘッドの大半であろう。 シーケンスヘッダとGOB ヘッダの符号量は無視しても大差はない。 これは 30 Hz では (72+38) * 30= 3300 bit/s となる。
これは 64 kbit/s というビットレートでは 5% 程度で大した量ではないが、 それより更に低いビットレートでは、大きな比率を占めるようになるだろう。 例えば 20 kbit/s では 3.3 kbit/s は 16.5%になり、これほどの無駄は避けたいのではないだろうか。 いずれにしてもこれは、そのような低レートにおいてだけ問題になるものである。 それではヘッダ類は、交換形式では、どこまで簡単化できるのだろうか。
方針として、MPEG-1 のシンタックスに戻せるシンタックスを考え、 その中で低レートに最適化したシンタックスは何かを考える。
これらは結局 MPEG-1 のパラメータの制限であり、この制限に従って作成したビットストリームは、 MPEG-1 のデコーダによって復号できる。つまり、"逆方向互換性" をもつといえる。 しかし次のシンタックスの簡単化をすると互換性はなくなるのであるが。
次に、ピクチャーヘッダを簡単化する。MPEG のスタートコードは、23 個の"0"と、それに続く"1"で 始まるため、シーケンスヘッダとスタートコードを区別するには、最低 25 bit 必要である。 ピクチャヘッダにこれを残すと効率は十分改善されない。 ユニークコードを使った同期機能(エラーからの回復機能)はシーケンスヘッダだけにする。 ピクチャースタートコードを完全になくすことは、マクロブロックの位置と個数を管理すれば可能であるが、 画面サイズに依存する処理になるためそれは避ける。 トランスデコードを容易にするため、ピクチャのスタートコードは、マクロブロックアドレス(MBA)の VLC との混同を避け、その余白の VLC "0000 0000 1" 9 bit を使う。
ピクチャヘッダに最低限、必要な f_code は、参照画像の距離を表すもので、 P-pictureでは 1 つ B-picture では順方向と逆方向とで 2 つある。 これと、もともとスライスにあった量子化パラメータをもつ。
上位のレイヤでは GOP ヘッダはなくし、シーケンスヘッダに I-picture を対応させると、 I-picture のヘッダとシーケンスヘッダは一体になる。
表 7.a にシーケンスヘッダ、表 7.b にピクチャーヘッダを示す。これらは MPEG-1 のシンタックスと比べて、 極端に単純化されていることが分かる。 ヘッダは 2 種類であり、I,P,B-picture それぞれに 47, 17, 19 ビットである。 10 Hz の M= 3 では、シンタックスオーバヘッドは、200 bit/s 程度になる。
表 7.a シーケンスヘッダ(= I ピクチャヘッダ)
--------------------------------+-------------+
構文要素 | ビット数 |
--------------------------------+-------------+
sequence_header_code | 24 |
horizontal_size | 7 |
vertical_size | 7 |
picture_rate | 4 |
quantizer_scale | 5 |
--------------------------------+-------------+
total | 47 |
--------------------------------+-------------+
表 7.b P,B ピクチャヘッダ
--------------------------------+-------------+
構文要素 | ビット数 |
| (P, B) |
--------------------------------+-------------+
picture_start_code | 9 |
picture_coding_type | 1 |
forward_f_code | 2, 2 |
bakcward_f_code | 0, 2 |
quantizer_scale | 5 |
--------------------------------+-------------+
total | 17,19 |
--------------------------------+-------------+
B-picture のヘッダ以外に最初のマクロブロックに 6 bit (MBA 1 bit + MBT 3bit +MV 2 bit)、 最後のマクロブロックに同様な 6 bit (MBA 1 bit + MBT 3bit +MV 2 bit)と、 35 bit (MBA の macroblock_escape 11 * 2 + 8 + 5 bit))必要で、 (QSIF は 11 * 7 の 77 マクロブロックである。 MBA で、76 を表すには 33 の escape を 2 回と残りの 10 を表す MBA の VLC 8 bit がいる。) 合計で 41 bit 必要である。20 Hz の B-picture であるから、 41*20= 820 bit/s、これが名目 30 Hz のオーバーヘッドである。 MPEG-1シンタックスのオーバヘッドと加算して 3300 bit/s + 820 bit/s= 4120 bit/s が無駄と なっている。
これはシンタックスの簡単化によって、(19+41)*20= 1200 bit/s 程度になる。 しかしシンタックス変更までしては、 せっかくMPEG-1の画像レートに完全に合わせた名目 30 Hz 方式の利点が失われる。 しかし、名目 30 Hz 方式もパラメータ制限であると考え、低レート交換形式で縮約すると考えることができる。 そうすると、これらのオーバーヘッドはすべて解消できる。そのときはトランスデコーダは、 空っぽの B-picture を作成する機能をもつ。しかし、10 Hz に B-picture を使えるわけではない。
空の B-picture を複製するだけでなく、空の P-picture をも複製する機能をトランスデコーダがもてば、 10 Hz MPEG-1 は完全に 30 Hz に戻すことができる。こんなトランスデコーダは意味があるだろうか。 これについて議論はあるだろう。
現状では、TCP/IP でソフトウェアエンコーダ/デコーダを通信に使うときは、 デコーダはフルスピードで動作し、相手側のエンコーダがフレームレートを決めるという動作が普通であろう。 デコーダにとってデータが来なければ画像とデコードをそのまま止めて待つのが最も単純な動作である。
動画像ブラウジングでは送り出し側が制御しなければ、デコード側がフレームレートを制御する必要がある。 しかし一般には、ビットレートが画像レートを決めてしまうだろう。64 kbit/s で符号化すると 40 kbit/s でしか流れないときは、そのまま多少のスローモーションになるだけである。
このような MPEG-1 標準方式の動画像転送は、すでにあるインターネットの応用とどんな関係になるだろうか。 転送レートの保証のないインターネットで、通信の応用としてはそのままは使えない。 動画像リトリーバルでは大いに使われている。
対ネットワークのリアルタイム転送の要求は品質を保証したプロトコル(TCP)さえも使えないとして、 UDP の中にのせる RTP: A Transfer Protocol for Real-Time Applications (IETF の Network Working Group RFC1889, 1890, 2038) が注目されている。 そこでは MPEG-1/-2 の低レートの非効率性には着目していない。 RTP は MPEG の Video にヘッダをつけてさらに非効率にしている。 つまり将来的には対ネットワークリアルタイム応用も低レートではないのかもしれない。 もし本当にそうなら、ここでの議論はかなりの方向修正を必要とする。
これらは現在進行形の会議の中間報告でしかない。会議の結論はまだなく、 有用な結論が作成できるかどうかも見えない。 この領域に興味のある方々のへのレポートとして有益であればまずまずであり、 その方々への参加を促せたら、さらに成功だと思っている。