2004年1月、RealVideo 10 関連のプレビュー版が一通り出そろった。 エンコーダの Helix DNA Producer 10 Preview (Ver. 10.0.0.74)、 RealPlayer 10.0 (Beta Build: 6.0.12.687) などだ。 2004年1月24日頃 guliverkli からリリースされた RealMediaSplitter 1.0.0.9 により Windows 上で RMVB コンテナの AAC, HE-AAC が一通りサポートされ、作成・再生の両面で RV10 が使えるようになった。
注意: 記事の情報は、それぞれの日付の時点でのもので、 バージョンアップにつれて状況が変わることがあります。
RV10 では、RV9 よりさらに品質が向上したばかりか、 AAC, HE-AAC, Lossless の音声圧縮もサポートされるなど、 可能性が広がっている。いくつかのポイントをメモしておこう。
2004年3月1日 RealVideo 10 'Elysian' について追記
RealPlayer そのものに対する嫌悪感はほとんど変わらないものの、 RV9以降、コーデックに対する純粋に技術的な評価は高まった。 低レートでは明らかに DivX5/XviD より有利(何もしなくてもそこそこの結果が出る)、 高レートでも優劣つけがたい(特にアナモルフィックのネイティブサポートが注目に値する)。 使い勝手は XviD のほうが良いし、 RVは再生プレーヤーが限られてしまうのも問題だが、 Media Player Classic (MPC) で簡単に再生できるのは大きい。
RealPlayerをインストールする場合、スパイウェアめいた悪いふるまいをやめさせるように十分に注意してほしい。 こうやってコーデックの RV9 をかなりほめて書いている自分ですら、RealPlayer は起動するたびに腹が立って、全削除したい衝動に駆られる。 「RealPlayer を使わなくては再生できない」としたら、どんなにコーデックが良くても、これほど人気は出なかっただろう。 RealPlayer は部品取りのためのインストールと割り切って、MPC を使うことを推奨。 RealMediaSplitterをインストールすれば .rm/.rmvb は Windows Media Player などの任意のDSプレーヤーでも再生できるようになる。
手元では低レートねらいはあまりしないし、 Real に対する不信感がぬぐい去れないので、やはり常用は XviD で(こちらも、いよいよ 1.0 RC1 が出ている)、2004年1月現在基本的には XviD がイチオシだが、 純粋に技術的には、RV9/10 も無視できない存在になってきている。 エンコーディング作業の内容を XML で指定する方法にも、技術的に非常に興味を感じる。
RealPlayerがスパイウェアめいているとしても、 その活動を完全に封じエンコード結果だけを任意のプレーヤーで利用する方法がある以上、 それができるユーザにとっては、一応選択肢に入ってくる。 DivX5 と同じだ。実際に使う使わないはともかく、後学のために幅広く試しておいて損はない。 (といってもまあ、Real のコーデックなど、できれば使いたくないというのが本音だが、それは会社が嫌いなだけで、 コーデックが悪いわけではないので、無関係な感情をまぜこぜにしないように理性的に割り切る必要がある。)
ビデオ成分は、再生側から見る分には同じ FourCC = RV40 だ。 改善されたのはエンコーディング側で、RV9のEHQが、RV10のデフォルトだ。 RV9のHigh設定が、RV10のLow設定に相当する。RV10は「最低画質・最高速」エンコでもRV9で「高画質」を選択した場合と同じになる。 RV10 High = RV9-EHQ 85 だ。
オーディオ成分は、AACが使えるようになった(FourCC = RAAC)。 ライセンスがきついのは同じだが、 AACはRealAudioよりずっとオープンな規格なので、やはり再利用性などの点で好ましい。 ただ、Real の AACエンコーダの品質は、今のところは、あまりあてにできないようだ。 特に HE-AAC (FourCC = RACP)は公式リリースでは使えない。 DLLにバグがあることと、ライセンスの関係で racp.dll が同梱されてないため。 修正版の rnaudiocodec.dll に置き換え、 racp.dll も用意すれば使えるが、 手元のテストでは、入力のサンプリングレートにかかわらず、出力のサンプリングレートが 22050 になってしまった。 実験目的以外では、 そうまでして RACP を使う意味がない。
(2004年1月27日追記): もしかすると、ダウンサンプリングは仕様で間違いではないのかもしれない。 HE-AAC音声のRMVBの再生には、RealMediaSplitter 1.0.0.9 以降、または MPC 6.4.7.6 以降が必要。 音声を再生できないケースもある。 古いバージョンの mkvwriter.dll にはMKVのヘッダを正しく書き出さず、 ビデオのフレームレートをゼロにしてしまうバグがある。 再生には問題ないが、VDMで編集できなくなる。 (追記終わり)
(2004年1月28日追記): AAC/HE-AACでは、ソースにかかわらず、44100または22050にダウンサンプリングされる。 別のAACエンコーダを使うほうがよい。 (追記終わり) (追記の追記@2004年8月28日: RealPlayer10 for Linux & HE-AAC clips)
(2004年3月14日追記):Producer 10 Beta の AACエンコーダは、音質が悪い。 音質はどうでもよく、とにかく手っ取り早くやりたいなら、すべて Real でもいいかもしれないが、 品質志向なら、他のAACエンコーダを使って、あとから映像と合体させるほうがいい。 (追記終わり)
RV9でも、MKVコンテナにすればAACやHE-AACを自由に使えたから、実質的なメリットは少ないが、 RMVBコンテナにAACを格納できるようになったこと、 またNero以外ではおそらく初めてのメジャーなHE-AACエンコーダのリリース、 というようなことで、注目に値する。 さらに、ロスレス圧縮も新たにサポートされている。
2004年1月現在、定型的な作業なら、RealAnime がある。
(2004年3月2日追記):2004年2月には、それを強化した RealBatch がリリースされた(関連スレ、開発者サイト)。こちらを推奨。
(2004年6月14日追記):Easy RealMedia Producer(別記事)が現在、最も良い。
これらはGUIフロントエンドでRV10に対応しており、HE-AAC (RACP) も使える。 経験者は、jobファイルを直接操作するのがいちばん速く、柔軟だ。
Producer は一次的にはhelixcommunityにあるが、 DLには登録が必要だ。 10.0.0.74 は RealBatch にも付属している(rnaudiocodec.dll もバグ修正版になっていて、HE-AACも可能)。 souxinからも入手できる(rnaudiocodec.dllは公式リリースのもの)。 RealBatch にも付属している。
別記事「RealBatch で RV9 (.rmvb)」 「[RV9] jobファイルによる.rmvbの作成」参照。 jobファイルの使い方はRV10でもほとんど同じだが、EHQについては、 How to set encoding complexity in RV10を参照。
<?xml version="1.0" encoding="utf-8"?> <job xmlns="http://ns.real.com/tools/job.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://ns.real.com/tools/job.2.0 http://ns.real.com/tools/job.2.0.xsd"> <enableTwoPass type="bool">true</enableTwoPass> <parInputs> <input xsi:type="avFileInput"> <filename type="string">R:\elves9\huff+wav16.avi</filename> </input> </parInputs> <parOutputs> <output> <destinations> <destination xsi:type="fileDestination"> <filename type="string">R:\elves9\rv9.rmvb</filename> </destination> </destinations> <mediaProfile> <audioMode type="string">music</audioMode> <audienceRefs> <audienceRef>myaud</audienceRef> </audienceRefs> </mediaProfile> </output> </parOutputs> <audiences> <audience> <avgBitrate type="uint">450000</avgBitrate> <maxBitrate type="uint">2250000</maxBitrate> <name type="string">myaud</name> <streams> <stream xsi:type="videoStream"> <pluginName type="string">rn-videocodec-realvideo</pluginName> <codecName type="string">rv9</codecName> <encodingComplexity type="string">high</encodingComplexity> <codecProperties type="bag"> <firstPassComplexity type="uint">85</firstPassComplexity> <customPacketSize type="uint">16000</customPacketSize> </codecProperties> <encodingType type="string">vbrBitrate</encodingType> <quality type="uint">75</quality> <maxStartupLatency type="double">60</maxStartupLatency> <maxFrameRate type="double">23.976</maxFrameRate> <maxKeyFrameInterval type="double">10</maxKeyFrameInterval> <enableLossProtection type="bool">false</enableLossProtection> </stream> <stream xsi:type="audioStream"> <codecFlavor type="uint">2</codecFlavor> <codecName type="string">raac</codecName> <pluginName type="string">rn-audiocodec-realaudio</pluginName> <streamContext type="bag"> <audioMode type="string">music</audioMode> <presentationType type="string">audio-video</presentationType> </streamContext> </stream> </streams> </audience> </audiences> </job>
現在開発中であるRV10の、機能向上版のコードネーム。 RV9の発展途上で現れたEHQが注目されたように、RV10におけるElysianは新機軸。 エンコードとデコードの両面に関係する。
Elysian でのエンコードを試してみたい場合、新しい erv4.dll を手に入れて、producer\codecs のものと置き換える。 Jobファイルの新オプションなど、詳細は RealVideo 10 'Elysian' を参照。
NOTE: 10.0.0.195 Command Line App (Beta) には、既に新しいバージョンが含まれている。 ファイルバージョンは同じだが rv10_elysian_022404.zip のものよりさらに新しいビルド。 10.0.0.72 Command Line App (Preview) の erv4.dll は Elysian 未サポート。
新方式のレートコントロール(RC)を有効にすると(rcEnableCurveCompression = true)、 従来のレートコントロールの設定(maxStartupLatency = 60.0 など)は関係なくなるが、 互換性のため、そうした古いRCのパラメータも依然、形式的に残す必要がある。
アニメに特化したような新オプションもある。RV系は少しディテールが失われてのっぺりした印象になることが多い、 という評判に答えてか、細かい部分をシャープに出すオプションなどが追加されている。 上のサンプルは、 とりあえず、だいたいデフォルトどおり。 同様の理由からか、HFE (High Frequency Emphasis) というデコード時処理オプションも追加されている。
もうひとつの目玉は2パスの Curve Compression で、 XviD のアルゴリズムからいいとこどりをしたそうだ。 ビット配分のカーブをどうするかは DivX3 SBC 時代から常に議論が分かれる問題ながら、 基本的には、リニアに(あれこれ色をつけず、 画像複雑度に応じて単純にそのまま)ビットを割り振るのが結局最善と考えられる(異論もある)。 RVの特質的にどうなのかはまた別だが、 「Iフレームが連続しているから無駄だし、2個めは少しビットを節約しても目立たないだろう」といった理論的考察と、 実際の人間の視覚心理は必ずしも一致しない。「これで決まり」と言える補償モデルがないので、カーブに色をつけるのは難しい。 もくろみがはずれれば逆効果だ。そのぶん、図に当たれば効果が高いとも言える。 期待はできるが実装や設定しだいで逆効果になる可能性もある諸オプションだ。
XviDは、あるレート以下ではものすごくブロックが出て画像が破綻する。 しかしそれは極端に低い場合だけで、高いレートでは、XviD は極めて美しい。 RV9/10は、相当レートを下げても破綻せず、そこそこ見られる。高レートでも最近のRVは美しい。 それでもRVが圧倒的に優位なのは低レートの場合で、高レートでも悪くはないのだが、RVは再生環境が限られてしまううえ、 再生時負荷もかなり高いので、現実的に高レートでの使用はどうかとも思う。 再生まわりなどの現実的要因を考えず、純粋にコーデックの性能ということを考えるなら、確かに素晴らしいが。