リモートデスクトップエンジニアのブログ。

Murakumoβテスターの当選通知は始まっておりますが、まだまだβテスターの方は募集中で御座います。

http://murakumo.x-row.net/

さて。

予告通り、Murakumoの映像圧縮についてちょっと書いてみませう。とかいーつつもスペシャルサイトにもありますよーに、映像圧縮にはWebMを使っているのではありますが、ライブラリの細かいところまでは調べていないのでどこがどーなっているのかとかそーゆー細かいところまではちょっとわからないまま利用している状況では御座いますが。いやそれでも時間を見つけては詳細な分を調べて高速化してみたいとは思っておりますけどね。Googleの技術者の人がカスタマイズしているかとは思いますが、それでもＣ言語の部分が大部分ですので、アセンブラに書き直したら少しではあるかもですが高速になるのでは？と思った矢先にWebMがバージョンアップとかゆーそーゆー流れでなかなか難しいところではありますけれども。

ちなみに、映像圧縮となるとWebMとゆーかVP8で御座いますね。御存じのとーり、WebMとは、映像圧縮のVP8と音声圧縮のVorbisをMatroskaとゆーコンテナで包んだコーデックで御座います。が、Murakumoでは、ちょっとその辺を一旦分解して欲しいとこだけ抽出して再合成してます。その過程でMatroskaコンテナは使ってませんけどね。なんか昔からコンテナとゆーのがどーも使いづらいとゆーかあんまり好きくないんですよね。Vorbisも単体ではOggVorbisとゆー感じが有名かと思いますが、このOggコンテナもあまり好きくないんですよね。自分的にはちょっと扱いづらい感じがします。いえ、緻密に考えられていて合理的ではあるんでしょうが、恐らく用途によってなんでしょうけど、自分みたいにリアルタイムで使うよーなそれでいてシンプルさを求めるとヘッダー部とデータ部を分ける位で丁度良いんです。えぇ、コボラーで育ってますのでｗ

Oggで思いだしたんですけど、ちょっと前にOggVorbisからVorbisだけを取り出してみよーと思って挫折した記憶がありました。一筋縄ではいかなくって結局切り離せなかった記憶があります。Googleはいとも簡単？にOggとVorbisを分離させたんでしょうか。てか作ったOn2社が分離するのは容易なんでしょうが。元々別々のアルゴリズムですし。いやそれにしても音声圧縮のアルゴリズム自体さっぱりワカランのですけどね。いやそもそも「音」をデータにする原理とか未だにパッと思い出せないですけどね。何回聞いても頭に入らないのは、自分ではそれほど重要だと思っていないから、と言いますが、その辺はその辺の詳しい方に御願いします、と思っている自分がいたりしますけれども。ライブラリで提供して頂ければ自分としてはそれなりに楽しめてます、はい。

さて。

そのコンテナ部分は自作とユー事なんですが、厳密にはコンテナって程でも無くって、Brynhildrからそーなんですけど、映像と音声は別々に通信していますので、コンテナみたいに包括されていない感じですね。まぁ、映像と音声の同期を取るといった意味でもコンテナは便利なのですが、音声はデータ量の変化があまりありませんが、映像はデータ量の変化が激しいです。例えば動きが激しいといったシーンになると映像のデータ量も著しく変化します。映像圧縮のVP8にもCBRとかVBRとかありますけれども、そーいったシーンでリアルタイムとなるとあまり大きな違いは無いのかなとは自分では思っております。そんな事もありますので、変化の大きい映像データと、変化の少ない音声データを別々に通信するというのは、結構気に入った方式であるとは思っております。現にMurakumoは、例えば解像度をフルHDにして動きの激しいシーンの映像ですとFPSは下がるものの、音は途切れる事無く鳴らす事が出来ている感じです。あまり映像が音声に影響を与えないといった感じでしょうか。

あと、Murakumoのテストでは、遠隔地にあるパソコンにセットされたDVDの映画を観てみる、といった事を実施しております。まぁツタヤで借りてきた映画のレンタルDVDなんすけど。まぁその遠隔地のパソコンてのは自宅なんすけど。つまり、「自宅」のパソコンにセットされたツタヤでレンタルしてきた映画のDVDを、「出張先」とか「事務所」とかから視聴してみるとゆーサボリ・・・じゃなくってテストです。それが違和感無く視聴できるとゆーのが目標ですかね。

その視聴テストで発生するトラブルとは？

また長くなってしまったので続く。