もたもたしている内に前回から一ヶ月程経過してしまいましたが、前回からの続きです。
ポイント５：Silverlight版再生プレイヤーではサポートできない機能があるSilverlightはWMV形式の動画の再生をサポートしていますが、WMV形式と一口に言っても、その種類や配信方法は多種多様です。
しかし、SilverlightはWindows Media Playerや、Webブラウザ向けのWindows Media Player プラグインが再生可能なWMV形式の動画の全てをサポートしているわけではありません。
その理由としては、Silverlightは開発当初からランタイムパッケージのファイルサイズを極力抑えるという目標があったので機能を削らざるを得なかった、あるいはSilverlightは将来的に携帯端末のハードウェアデコーダをサポートする予定があるのでそちらに合わせて機能を絞った等の理由が考えられますが、これらは一部外者の単なる想像に過ぎません。
ともあれ、WMV配信サイトは幸いなことに、WMV形式の種類に関しては、唯一の例外である音声のデュアルモノを除けば従来からSilverlightでの再生が可能な形式を使っていましたので、その点ではほとんど問題はありません。
細かい話をすれば、SilverlightではWMVファイル本体に埋め込まれたメタデータ、例えば動画のタイトル、製作者名や著作権表記を読み込めないという制限はあるのですが、これは別途、Windows Media向けのメタファイルである.ASXファイルに記述すれば済む話です。
しかし、配信手法に関しては、SilverlightがHTTPプロトコルでのメディア配信にしか対応していないために、今まで提供していた非HTTPのメディア配信プロトコルやダウンロードコンテンツと呼ばれる配信方法を見送らざるを得ませんでした。
ここでは、これらの機能の概要を順に説明します。
1. デュアルモノSilverlightで使える音声コーデックとしては、1.0と2で利用可能なMP3とWMA、3で新しく追加されたAACがあります。これらのコーデックは全て、一つのステレオ音声のストリームの左右２つのチャネルに別の音声を割り当てて、２つのモノラル音声として扱うデュアルモノという機能を仕様上持っています。
具体的な用途としては、アナログTV放送の二ヶ国語放送や副音声付放送のような使い方ができます。
実際には、動画の配信で二ヶ国語や副音声をサポートしている例は滅多にないのですが、講演や演説の中継で日本語と英語の両方の音声をサポートするようなケースがたまにあります。
最近では、MicrsoftのReMIX Tokyo 09というイベントのキーノート中継が日本語と英語の音声をサポートしようとしていました。
しかし、Silverlightではデュアルモノをサポートしていませんし、デコード後の音声データをアプリケーションが取得する手段が提供されていないので、左右どちらかのチャネルのモノラル音声を左右両方のチャネルに流す手段がありません。
先のイベントでは苦肉の策として、左右に音を振るパン機能を使って、日本語音声の選択時には右スピーカーだけで日本語音声を流し、英語音声の選択時には左スピーカーだけで英語を流すという方法をとっていました。
スピーカーならまだいいのですが、ヘッドフォンで音声が片方からしか流れないのはなかなかツラい物があります。
Silverlightを実際に開発しているのはアメリカですが、二ヶ国語音声のサポートについては、日本や他の国から積極的に提案しないと採用は難しそうです。二ヶ国語音声をデュアルモノを使わずに実現する方法としては、複数の音声ストリームとその切り替えをサポートするような方法も考えられます。
MSKK(Microsoftの日本法人)の中の人には、今後のキーノート中継のためにも、ぜひ本家に対して何らかの提案を行って頂きたいと思います。
2. 非HTTPのメディア配信プロトコルプロトコルとは、簡単に説明するとデータを送受信する手続きのことです。
プロトコルの種類はうんざりする程多いので、国際標準化されたプロトコルをインターネット向けに限定しても、辞典が作れるぐらいの種類があります。
しかし、最近のWebサービスではプロクシサーバを越えてサービスを提供したいという事情から、目的や用途を問わず、HTTPのみをプロトコルとして利用しようとする強い風潮があり、Silverlightもその例外ではありません。
ただ、昔は、まだHTTPのバージョンが古く、今ならほとんどの環境で使えるいくつかの機能が欠けていたこともあって、サービスの目的や用途に応じて専用のプロトコルを利用するのが一般的でした。
Microsoft(以下MS)社製のストリーミングメディアサーバである、Windows Media Serviceも、古くから使われているサーバですので、RTSP (Real Time Streaming Protocol)やMMS (Microsoft Media Services)等の、メディア配信用の専用プロトコルが既定のプロトコルになっています。
正直に言えば、私はRTSPとMMSの細かい違いは知らないのですが、昔はMS社が開発した独自のプロトコルであるMMSを使っていたものの、ベンダー独自仕様を避ける世の中の流れを受けて、Windows Media 9以降は（主にDRM方面でのMS社独自の拡張の追加はあるものの)国際標準規格であるRTSPを既定のプロトコルとして利用するようになったという事情があるようです。
結局、現在のWindows Media Serviceは、既定のプロトコルとしてはRTSPを用い、RTSPには対応していない古いクライアントに対してはMMSで試してみて、それでもダメなら、いくつかの機能制限はあるものの、HTTP(とその亜種)を使用するという処理が自動的に実行されるようになっています。
尚、上記の処理をMicrosoft社はプロトコルロールオーバーと呼んでいるので、以下ではそう呼ぶことにします。
さて、上述したいくつかの機能制限の話ですが、具体的には、
ライブ配信、マルチビットレート(MBR)、マルチキャストの３つが挙げられます。
2-1. ライブ配信
Winows Media Serviceは、蓄積された映像を配信するオンデマンド配信と、生中継の映像を配信するライブ配信の２つの機能をもっているのですが、プロトコルとしてHTTPを使う場合は、ライブ配信には対応していません。(ちょっと自信なし)
Silverlightが対応しているプロトコルは基本的にHTTPだけなので、プロトコルロールオーバーを使って、コンテンツ配信サーバは変えずに再生ができるようになっているのですが、映画やTV放送のような既に存在する映像のオンデマンド配信はできても生中継のライブ配信はできません。
残念ながら、Windows Media Service(あるいはその業務版？)を使用している既存のWMV配信サイトでは、当分の間は、ライブ配信については対象をWindows Media Playerのみとし、Silverlightは対応外ということになりそうです。
先ほどのReMIX Tokyo 09では、Windows Media Serviceではないサーバを使ってSilverlightでのライブ配信を実現していますが、その話はちょっと後回しにさせてください。(^^;)【訂正】Windows Media ServiceでもSilverlight向けにライブ配信は可能とのことです。Live Smooth Streamingが登場するまでは、Smooth Streamingでライブ配信はできなかったという話を、Silverlightでライブ配信はできなかったという話と誤解していました。お詫びして訂正します。(2009/10/06)2-2. マルチビットレートWindows Media Serviceには、マルチビットレート(MBR)という機能があります。
マルチビットレートのビットレートとは一秒間に送れるデータ量の単位を指します。
最近流行のHD映像は今までの映像よりも解像度が高いので、それに伴ってデータ量も増え、結果としてビットレートも高くなるので、速い回線速度を必要とします。
しかし、ユーザ側の回線環境は様々ですし、配信中に状況が変化することも多々あります。回線が細くなって映像に必要なビットレートを保てなくなると、結果として映像がガクガクになりますし、音声も乱れてしまいます。
マルチビットレートはこれを解決するために、異なるビットレートでエンコードした複数の映像データを事前に用意しておいて、再生プレイヤー側の状況に応じて適切なビットレートのデータを選択し、それに切り替えて配信する仕組みです。
ShowTime をWindowsで視聴した経験がある方の中には、高画質で映像を再生している時に、映像がボケボケの低画質になったり、静止画像が数秒に一度程度更新されたり、画面が暗くなったまま音声だけ流れる状態になった経験がある方がいらっしゃると思いますが、これがマルチビットレートの結果です。
細かい話をすると、実際にはマルチビットレート以外にもクライアント側で回線状況の悪化に対応する技術も使われているのですが、話が長くなるので今回は省略させてください。m(__)m
ShowTimeでは高画質と標準画質の2つのビットレートの動画を再生前に選択することはできるのですが、再生中にこの2つを切り替えることはできないので、慎重に選ぶ必要があります。
2-3. マルチキャストマルチキャストにはいくつか種類があるのですが、基本的には誰かが送りたいデータを全ユーザに送り、必要なユーザだけがそれを受け取る仕組みということになります。
しかし、その仕組み上、送られるデータが同一である必要がありますので、ライブ配信向けの技術ということになります。
オンデマンド配信の場合は、例え一つの映像しか流さなかったとしても、同一時刻に再生されている画面は視聴しているユーザによって変わりますので、マルチキャストができないということです。
現在のところ、Silverlightはマルチキャストに対応していません。
3. ダウンロードコンテンツいわゆるダウンロードコンテンツとは、映像データをストリーミングによってネットから流し続けるのではなく、一度動画ファイルをダウンロードして、オフライン状態で視聴するサービスです。
そのためにはクライアントPCに、映像の全データを保存しておく必要があるのですが、Silverlightはセキュリティ上の都合から、クライアントPCのローカルなファイルへのアクセスが大幅に制限されています。
ほぼ唯一の例外として分離ストレージという領域を利用することはできるのですが、これはユーザのホームディレクトリ以下の特定の場所に隔離されていますので、ファイルサイズの大きい動画データの全てを常に同じ場所に保存するしかなく、ファイル移動も簡単にはできないというデメリットがあります。
Windows Media Playerが提供されていないMac OS Xの様なOSや、ネットワークに常時接続可能とは限らないモバイル端末のような環境でもダウンロードコンテンツを再生可能にするための何らかの方策を考えて欲しいものです。
ポイント６：Silverlightのメディアエンジンはエラー耐性が低いSilverlightで動画や音声を再生するソフトウェアをメディアエンジンと呼んでいるのですが、Silverlightは、これをWindows Media Playerとは別に、自前で持っています。
機能はほとんど被っているので無駄なようにも見えますが、SilverlightはMac OS X等Windows以外の環境でも実行されるのでメディアエンジンを統一したかったのかもしれませんし、レガシーなコーデックもサポートしていてたまにセキュリティ的な脆弱性が発見されるフルスペックのメディアデコーダの使用を避けて、一から必要最低限のデコーダを作成することで、セキュリティを高めたいという目的があったのかもしれません。
さて、動画を視聴している時間が長い方はご存知だと思いますが、映像の中に緑やピンクの四角を見たことはありませんでしょうか？
これはブロックノイズと呼ばれるノイズの一種で、大抵は映像データのエラーが原因です。
Windows Media PlayerやWebブラウザ向けのWindows Media Player Pluginであればエラーに耐性があるので、画面が多少乱れはするもののそのまま再生が続行されるのですが、SilverlightでこのようなWMVファイルを再生した場合、エラーが発生した時点で問答無用で再生を終了してしまいます。
これはSilverlightのメディアエンジンのエラー耐性が低いからであると考えられます。
Silverlightのメディアエンジンのエラー耐性が低いことで発生しうる問題は、主に３つあります。
１つめは、WMVファイルを単純に複数のファイルに分割して複数のWMVファイルにして再生する場合です。
この場合、分割された2番目以降のファイルを最初から再生しようとしても全く再生されません。
ただ、正規のWMV配信サービスでこのようなデータが配信されることは基本的にはありえません。
強いて言えば、WMV以外の映像形式の話になりますが、FlashでH.264/AAC形式で提供されている動画配信サービスをSilverlightに移植する場合に、問題になるぐらいでしょうか。
Flashの動画配信サービスでは、HTTPを使ったプログレッシブダウンロードのいくつかの欠点を補うために、サーバ上の単一の動画ファイルを、クライアントからは、単純に分割された複数のファイルとして見えるように見せかけて動画のシークを早める技術(正式名称は知りません)を使っている事例があります。
他には、一つの映像を映像の仕様上は分断してはいけない箇所で分断して別々の映像として配信している事例もあるようです。先日の大臣就任会見の映像で、このような映像を見かけました。
Flashの動画デコーダはエラー耐性があるので、このようなファイルであっても最初は画面が乱れるものの何とか再生できてしまうのですが、Silverlightでは、サーバ側で独立した複数の動画ファイルを単一の動画ファイルとして正しくなるように辻褄を合わせない限り再生できないことになります。
エラー耐性の低さが問題になるケースの２つめはデータの転送経路にノイズが多い経路が含まれていたために、動画データが意図せずにほんの少しだけ壊れていた場合です。
これが実際に問題になるのは、生放送をライブ配信して、複数の離れた中継地点から現場中継するような状況です。
この場合、カメラから電波で映像を飛ばすことになると思われますが、電波はノイズが多い媒体なので中継中に画像が乱れることがあるのはよくご存じだと思います。
先日のテレビで中継していた日食の映像で、画面が停まったり多少ノイズが発生するような映像が流れることがありましたが、Silverlightの場合は再生自体が終了することになります。
これを防ぐ方法としてはエラーの混じった映像データを、再度エラーがない映像としてエンコードし直すような方法が考えられますが、再エンコードは一般的に画質が落ちますし、エラーのある映像データをピンポイントで修正するようなソフトは今のところ見たことがありません。
さて、エラー耐性の低さが問題になるケースの３つめは、非MS製のエンコーダがWMVとしては不正なデータを出力するケースです。
MS社製のエンコーダであれば、そのようなデータを出力することはないはずなのですが、世の中にはハードウェア、ソフトウェアを問わず、様々なWMVエンコーダがあり、残念ながら常に正しい映像データが出力されるとは限りません。
具体的にはWMV形式で提供されているゲームのデモムービーの一部でブロックノイズが発生する動画があり、Silverlightではそれ以降の映像が全く再生できないという事例がありました。
デモムービーは通常はWindows Media Playerを対象としていますから、多少のエラーはエラー補正によって解決されるために見逃されてしまうようなのですが、後で同じ映像データをSilverlightでも再生する必要が生じた場合に問題になってしまいます。
コンテンツを作成する方には、納品データがWMV形式の場合は、極力MS社で確認済みのエンコーダを使い、Silverlightでも再生可能かどうかをチェックすることをオススメしたいと思います。
（その３に続く）
