マルチメディア通信 (WIP)
略歴
動画配信の初期、おそらく 1990 年代は、まず HTTP の利用が試みられていたらしい。しかし、当時の 28 kbps, 56 kbps モデムで利用可能な帯域の制限もあって、その品質は満足いくものではなかった。さらに、動画は一度全てダウンロードしてからでなければ再生や操作を行うことができなかった。 これに対して、動画を段階的に DL し DL 中にも再生可能にする HTTP Progressive Download の技術が利用されるようになった。しかし、シークや DL 中に任意の位置から再生したい要求等に対して課題があった。また、一度動画が再生されると、その再生が途中で止められた場合でもできる限り早くデータを最後まで届けるよう試みられるため、その分の転送が無駄になってしまうといった問題もあった。 他の Web コンテンツと同様に映像データが扱えるために実装が簡単であり、CDN のサポートも豊富で、ファイアウォールにブロックされることもない.
再生開始前に映像の品質を選択しておく必要がある。
Streaming Protocol
1990 年代から 2000 年代初めにかけて、インターネット上の映像配信には主に RTP や RTCP 等 UDP ベースの Streaming Protocol が利用されていた 映像配信
映像配信の方式には、映像データを細かいチャンクに分割して送信し、クライアント側がそれらを順次つなぎ合わせて再生を行うような ストリーミング 方式と、映像データをまず直接クライアントデバイス上にダウンロードしてからそれを再生する ダウンロード 方式がある。近年利用されているのは専ら前者。映像配信のためのプロトコルの流れを追ってみる。
HTTP ベースでない Streaming Porotocol 低遅延や様々な配信機能を実現するための専用のプロトコルがいくつか存在している。
RTMP (Real-Time Messaging Protocol, Adobe) HTTP ベースの pull-based な通信ではなく、サーバ > クライアント方向の push-based な配信が実現できるため、低レイテンシが簡単に実現できるのが特徴 RTP (Real-Time Transport Protocol), RTCP (RTP Control Protocol) UDP ベースであるため、アプリケーションレイヤから制御できない TCP 自体の仕組みであるパケット再送や輻輳制御等の影響で転送に遅延が生じる可能性が少ない 逆に UDP ベースであるが故に、CDN が対応していなかったり UDP-blocked なファイアウォールにブロックされてしまったり等の問題がある MMS (Microsoft Media Server, Microsoft) 段階的にファイルを DL することで、メディアデータ全体の DL 完了をまたずとも順次再生できるような配信方式。