無題ドキュメント

「オンデマンド配信、ストリーミング配信のしくみ」

FourTwoTwoCompany ＜http://www.ftt.co.jp＞
尾上泰夫＜onoe@ftt.co.jp＞

｢インターネットを使った映像の配信｣
インターネットを使った映像の配信の方法には、大きく分けて2つの方式がある。1つはオンデマンド配信、もう1つはストリーミング配信である。
オンデマンド配信とは、すでに録画済みの映像のストックを画像サーバに蓄積し、その映像の中からユーザーが自由に見たいコンテンツを選択して視聴できるインタラクティブな映像配信方式である。
またストリーミング配信は、基本的にはカメラ等で撮影されたライブ映像を、そのままインターネットのサーバ経由で視聴者にダイレクトに配信するシステムである。
この両者は、同じストリーミング技術ではあるが、目的も用途も、またシステムの構造自体もかなり異なっている。

｢オンデマンド配信｣
オンデマンド配信は一般的に、すでに作成済みのコンテンツが、番組データとして画像データベースに蓄積されている。その中からユーザーの望む映像を各種の条件を指定しながら検索し、選択できるというシステムである。ポイントとなる点は、多数のユーザーが色々な検索方式に基づいてそのコンテンツにたどり着いたとき、そのコンテンツが同じであっても (ファイルが1つしかなくても)、再生のタイミングが異なっていても、必ずそのコンテンツのはじめから見ることが可能である。簡単に言うならば、見たいときに見たいところから見ることができるシステムである。
オンデマンドで映像が配信できると、メニューをズラリと並べておく、もしくはその映像を探すための検索のシステムも重要になってくる。オンデマンドの場合は番組表というのは当然存在しないわけで、コースの料理みたいに決まったものが次々と出てくるのではなくて自分の見たいものがそれぞれ選べる自由さがある。どれでもどうぞ、どこからでもどうぞ、というようなスタイルである。
構造的にいうならば、配信サーバと視聴者の間には視聴者が指定した場所の映像のストリーミングのデータがそのつどサーバから送られてくることになる。常に視聴者が、サーバのストリーミングのコンテンツをコントロールしているわけである。ゆえに、オンデマンド方式のストリーミングのサーバにはかなりの負担がかかることになる。
この方式では同じ配信サーバのコンテンツを同時に複数で見るということには、おのずと限界が見えてくる。そのために同じコンテンツのストリーミングファイルのコピーをいくつもつくっておいて、なるべく1つのサーバを複数のユーザーが同時にアクセスしないようにする工夫が必要となってくる。
今のコンピューターのネットワークとのやり取りを考えた場合に、CPUの能力そのものよりもネットワークのインターフェイスの能力(伝送能力）、もしくはそれを分けるための能力に限界が来るのでコンピューターの性能はあまり映像の伝送能力には影響を与えていない。料金徴収も大変やりやすい。許認可をどう与えるかということと、お金を回収するのを一体化することで、1コンテンツに対していくらと言うような回収の仕方が便利になってきた。

｢ストリーミング配信｣
ストリーミング配信は、実時間で流すかたちで時間の方向が常に一定、つまりカメラから入ってくる映像を扱うわけだから当然、一時停止、巻き戻し、早送りはできない。次に何が起こるか見たいと思っても、実際カメラでまだ取れていないのだから見られない。ものすごくテレビに近い配信の仕方である。
ストリーミングのコンテンツ自身のコントロールは視聴者側からはできないのである。
もう少しわかりやすくいうならば、各種の放送局が毎日流しているTV放送がそれである。何時何分から何時何分まで決められた映像が流れてくる。そのチャンネルに切り替えてその時間になったら、その映像が見えるという方式である。
　これはシステム上かなり負荷が少なくてすむことになる。例えば、1時間のライブ放送を送信するのにそれを中継するストリーミングのサーバの必要となる記憶容量は、そのライブ映像のほんの数秒分の記憶容量だけあればよいのである。
　実際にはその数秒分のバッファーのような画像データが、そのつどインターネット経由で全世界に配信されていることになる。その配信しているそのタイミングに合わせて、そのＵＲＬにリンクすれば、そこで、今配信されているデータそのもののフレームがユーザー側のブラウザーに表示されることになる。そしていったんブラウザーに表示されればそのデータの目的は達成されどんどん消去されていって、端末側には一切残らないのである。
　サーバ側もまったく同じ考えである。1時間、ずっとサーバが中継基地の役割を果たすが、30分たっても1時間たってもそのサーバの中で消費している記憶エリアの容量は数秒間の最新映像分にしか過ぎないのである。
　その時に、放送されている最新の数秒間しか記録(一時保管)されないのである。ところてん方式のようにどんどん後ろから映像のデータが押されてくるのである。そして古いデータから消えていく。この方式のメリットはかなり小規模なシステムで、ハイクォリティなライブ中継ができることにある。数秒間分の映像を保存できるパフォーマンスさえあれば、サーバは絶えず映像を送り続けることができるのである。実際にこのライブ映像配信用サーバは、一般的なホームページのサーバでも十分耐えられる。
さらにそのライブ映像を見るユーザーの数についても、1人から2人、2人から10人に増えたとしても、サーバの処理能力がそれだけいるわけではない。いつも数秒間のシーンが複数の人が見られるように準備されているだけなのである。かなりの人数を同時にこなすことが可能である。ライブ方式と呼ばれることもある。

｢マルチキャスト｣
この辺の方式の中にマルチキャストと言われるものがある。テレビに比較的近いかたちで配線には負担をかけないようにたくさんの人に見せたい。そのマルチキャストの方式というのは、サーバから1つの映像が取り出され、受け取り側が2人いるとサーバも2つ出さなくてはならないという今までの方式を変えて、1つの映像が流れていくとそれぞれのルーターやハブで、そこから受け取る人に対して、同じものを流せるような伝送の仕方を定義している。サーバがその機能を持っているのと一緒に、純粋にインターネットでは今のところできない。ただマルチキャストと同じような役目をサーバに持たせて、それを各地に置くことで同じようにルーターをまたいで、違うところにいるお客さんに対して配信をすることは可能である。ここまで運ぶのは1つの映像でいいよという伝送のしかたが実現できるので、割と多くの人に見てもらうのに便利なしくみと言える。これはあくまでも今そのものを見せるブロードキャストのかたちの放送の方式なのでテレビに非常に近いモデルと言えるかもしれない。2746

インターネットのメディアはその高速化・大容量の変化に伴って一般的な放送メディアとして変化しつつある。この新しいメディアを広告や情報の配信といった分野の一部分を担うことになるのは、大容量のインフラ普及を待つばかりである。

コラム
｢ライブ＋オンデマンド｣
ライブ方式のもう1つの方法として、すでに作成済みの映像を、一度サーバ側に保存し、そのデータをサーバから再生しながらライブ放送と同じ方式で配信する方法もある。要するにライブをカメラから撮影した映像を流すのではなく、保存済みの映像コンテンツを再生させて、それをあたかもライブ放送かのように配信するのである。
　この方式を応用すれば、前述のオンデマンド方式と同じようにストックされた映像の中から見たい映像を検索して再生させることも可能ではあるが、同時にその映像をアクセスしようとすると、そのタイミングによってはすでに映像が流れ始めていて途中から見ることになる場合もあるであろう。ある程度尺が短くてループして再生されている映像なようなものであれば、応用させることも可能かもしれない。オンデマンドのインタラクティブ性とライブの中継サーバを用いた軽いシステムでの配信が可能となるのである。

・エンコードファイルの種類
ビデオ映像のように多量のデータをネットワークに流す時、決められた回線帯域の中で効率よく、しかも品質を稼ぎ出すには、最適な圧縮の方法が求められる。エンコードの後に、サーバーへ配置するファイル形式は、それぞれに専用のクライアントソフトでデコードすることによって目に見える映像へ戻す事ができる。
エンコードファイルの種類はコーデックの種類とも言える。
ネットワークでストリーミング配信するためには、サーバーで配信可能なフォーマットへエンコードする必要がある。ファイル転送のダウンロードではないため、エンドユーザーのプレイヤーソフトでデコードすることによってのみ表示される。
したがってユーザーのところでコンテンツを保存しないですむので著作権などの管理が適切に行う事ができる。さらに、エンコード作業の中でDRMのための「すかし」を埋め込む事や、ダウンロードしても、視聴期間や回数を制限できる機能を埋め込む事も可能になっている。

・ビットレートによる画質の差
最高の状態である品質を非圧縮のそれとして、圧縮する度合いが多くなりにしたがって画質は損なわれていく。だからこそ、限られた条件下での視聴に適した圧縮で、適正な転送レートを維持する事が大切だ。
ビットレートは秒間にどれだけの情報量を与えるかを示した数値だ。
現在ブロードバンドの高品質なコンテンツとしては最大のハイビジョン映像でさえ6MBPSで配信する事が可能だ。最近ではパソコンの画面で視聴するテレビの機能も話題になっているが、同様の画質の映像をネットワーク経由で2MBPSもあれば視聴できる。サムネール的なサンプルなら300KBPSでも使用に耐える。携帯電話のような小型の液晶画面であれば実用的にさらに高圧縮で転送する事ができる。
同じビットレートでも良好な画質を維持できるコーデックに人気が高まっているのもうなずける。逆の使い方では、良いコーデックは同じ画質を低いビットレートで実現できるのだ。

・回線容量（ADSLから光へ）の進化とそれに伴う画質の向上
回線容量は値段との相談になる。費用対効果の問われるところだ。現在日本はエンドユーザーのインターネット回線が世界で比較して安価な状態となっている。中でも光回線は家庭まで引き込めるコストの安い恵まれた国と言えよう。ベストエフォートという回線を共有する方式で、帯域はそのときに使用する人たちの使用条件によって異なるために運次第だが、大変安価に利用する事ができる。
アナログ回線を利用したADSLは、非対称の通信によりさらに安価な通信料金を実現している。登りと下りの回線スピードを変えることで、一般ユーザーには満足の行くサービスを提供してくれる。多量の情報を多くのエンドユーザーへ配信するには現在のインターネットの定めるルーティングポリシーでは、配信サーバーへ過度の負担が集中する。ネットワークでサーバーの負荷分散を図るためには、サーバー数を増やし、エンドユーザーのプロバイダーごとにサーバーを配置すれば、多くの問題は解決する。キャッシュサーバーとか、エッジとも呼ばれるサーバーで、プロバイダーを跨がずにコンテンツを効率よく視聴できるシステムが必要になっているのだ。

・ビデオオンデマンドなど期待されるコンテンツの話
映像コンテンツは多くの場合、映画やテレビ番組などを再利用することで、コストを下げるように工夫されているが、マスを対象に制作されたコンテンツが、個人の個性があらわになるインターネットに最適なコンテンツであるとは限らない。オンデマンドに求められる個性的な内容と、自由な視聴時間は、編成で決められた放送番組のそれとは異なる工夫が求められている。個人向けにアレンジされたコンテンツの制作は、むしろ視聴者の好みを反映したリアルタイムエディットのようなシステムで支えられたオンリーワン対応を求めているのかもしれない。