歴史

歴史 #

このセクションは進行中であり、まだすべての事実を把握しているわけではありません。デジタルコミュニケーションの歴史を構築するためにインタビューを行っています。

RTP #

RTPおよびRTCPは、WebRTCのすべてのメディア転送を処理するプロトコルです。1996年1月にRFC 1889で定義されています。 著者の一人であるRon Frederickが自ら語ってくれるというのはとてもラッキーです。Ronは最近アップロードした Network Video toolをアップロードしました。このプロジェクトはRTPに影響を与えました。

彼自身の言葉です。

1992年10月、私はIPマルチキャストをベースにしたネットワークビデオ会議ツールを書こうと思い、Sun VideoPixフレームグラバーカードの実験を始めました。このプログラムは、LBLで開発されたオーディオ会議ツール「vat」をモデルにしたもので、会議に参加するユーザーに同様の軽量なセッションプロトコルを使用し、特定のマルチキャストグループにデータを送り、他のグループメンバーからのトラフィックを監視するだけのものでした。

このプログラムを成功させるためには、ネットワークに出す前にビデオデータを圧縮する必要がありました。私の目標は、家庭用ISDN回線の帯域幅である128kbps程度に収まる、見た目にも美しいデータストリームを作ることでした。さらに、その半分の帯域で見られるようなものを作りたかった。そのためには、画像サイズとフレームレートに応じて、約20倍の圧縮が必要でした。私はこの圧縮を実現し、使用した技術の特許を申請しました。これは後に特許US5485212Aとして認められました: 電話会議のためのソフトウェアビデオ圧縮。

1992年11月初旬、私はビデオ会議ツール「nv」(バイナリ形式)をインターネットコミュニティに公開しました。初期テストの後、 このツールを使って、 11月のインターネット技術タスクフォースの一部を世界中にビデオキャストしました。15カ国の約200のサブネットでこの放送を受信することができ、1週間のうちに約50~100人が「nv」を使ってビデオを受信しました。

その後、オーストラリアの「NetWorkshop」、MCNCの「Packet Audio and Video」、スウェーデンの「MultiG Workshop on Distributed Virtual Realities」など、他の3つのワークショップやいくつかの小規模な会議でも「nv」を使ってインターネット全体に向けた放送が行われました。

1993年2月には「nv」のソースコードを公開し、3月にはウェーブレットベースの圧縮方式を導入したバージョンを公開しました。1993年5月には、カラービデオにも対応しました。

nv」をはじめとするインターネット会議ツールのネットワークプロトコルは、インターネット技術タスクフォース(IETF)で標準化されたリアルタイム・トランスポート・プロトコル(RTP)をベースにしています。RFC 1889-1890で最初に発表され、その後RFC 3550-3551で改訂され、音声やビデオの特定フォーマットを伝送するためのプロファイルをカバーするさまざまな他のRFCも追加されました。

その後、数年にわたって「nv」の開発が続けられ、多くのハードウェアプラットフォームやビデオキャプチャーデバイスにツールが移植されました。当時、インターネット上で会議を中継するための主要なツールの一つとして使われ続け、NASAからシャトルミッションのライブ中継に選ばれたこともある。

1994年には、他社が開発したビデオ圧縮アルゴリズムを「nv」でサポートするようにした。これには、SunVideoビデオキャプチャカードがサポートするCellBフォーマットなどのハードウェア圧縮方式も含まれる。これにより、「nv」はCUSeeMeフォーマットでビデオを送信できるようになり、MacやPCでCUSeeMeを実行しているユーザーにビデオを送信できるようになりました。

「nv」が最後に公開されたのは、1994年7月にリリースされた「3.3beta」だった。私は「nv」をRTPプロトコルのバージョン2に移行させることを目的とした「4.0alpha」のリリースに取り組んでいましたが、私が他のプロジェクトに移ったため、この作業は完了しませんでした。4.0αのコードは、Network Video toolのアーカイブに含まれていますが、未完成であり、特にRTPv2のサポートが不完全であるなど、既知の問題があります。

「nv」で提供されたフレームワークは、後にXerox PARCの「Jupiter multi-media MOO」プロジェクトにおけるビデオ会議の基礎となり、後にMicrosoftに買収されたスピンオフ企業「PlaceWare」の基礎となりました。また、このコードは、高帯域幅のイーサネットやATMネットワーク上でNTSC放送品質のビデオを送ることができる多くのハードウェアビデオ会議プロジェクトの基礎としても使われました。 また、このコードの一部は、ネットワークベースのビデオ録画・再生サービスである「Mediastore」のベースとしても使用しました。

ドラフトに参加していた他のメンバーの動機やアイデアは覚えていますか?

私たちは皆、IPマルチキャストの研究者で、インターネット・マルチキャスト・バックボーン(通称MBONE)の構築に携わっていました。MBONEは、IPマルチキャストを最初に開発したスティーブ・デアリング、ヴァン・ジェイコブソン、スティーブ・キャスナーの3人によって作られました。スティーブ・デアリングと私はスタンフォード大学で同じ指導教官でしたが、スティーブはスタンフォード大学を辞めてXerox PARCで働くことになりました。私はインターンとしてXerox PARCでIPマルチキャスト関連のプロジェクトにひと夏を過ごし、スタンフォード大学在学中はパートタイムで、その後はフルタイムで働き続けました。ヴァン・ジェイコブソンとスティーブ・キャスナーは、ヘニング・シュルツリンと私と一緒に、初期のRTP RFCの4人の著者のうちの2人でした。私たちは皆、様々な形のオンラインコラボレーションを可能にするMBONEツールを開発していましたが、これらのツールが使用できる共通のベースプロトコルを作ろうとしたことがRTPにつながったのです。

マルチキャストはとても魅力的です。WebRTCは完全にユニキャストですが、その点について説明していただけますか?

スタンフォード大学に入学してIPマルチキャストについて学ぶ前、私はコンピュータを使って人々が互いにコミュニケーションを取る方法について長い間研究してきました。私は80年代初頭にダイアルアップの掲示板システムを運営していましたが、そこでは人々がログオンしてお互いにメッセージを残すことができ、プライベートなもの(電子メールに相当するもの)とパブリックなもの(ディスカッショングループ)がありました。同じ頃、CompuServeというオンラインサービスの存在も知りました。CompuServeの優れた機能の一つに「CB Simulator」というものがあり、人々がリアルタイムで会話をすることができました。すべてテキストベースでしたが、本物のCBラジオのように「チャンネル」という概念があり、同じチャンネルにいる限り、複数の人が他の人の入力した内容を見ることができました。 私は、タイムシェアリングシステム上で動作する自作のCBを作り、そのシステム上のユーザーがリアルタイムにメッセージを送れるようにしました。実は、そのうちの1つのシステムは今でも稼働していて、30数年前に大学で一緒だった人たちと毎日のように会話をしているんですよ。

しかし、スタンフォード大学でIPマルチキャストについて学んだとき、マルチキャストを使って真の「ラジオ」のようなものを手に入れることができるという考えに興味を持ちました。偶然にも、私がIPマルチキャストのコードを移植していたコンピュータは、サンの第一世代のSPARCステーションで、実は電話品質のオーディオハードウェアを内蔵していたのです。 マイクからの音をデジタル化して、内蔵スピーカー(またはヘッドフォン出力)で再生できるのです。そこで私が最初に考えたのは、IPマルチキャストを使ってその音声をリアルタイムでネットワーク上に送る方法を見つけ出し、テキストの代わりに実際の音声を使って「CBラジオ」に相当するものを作れないかということでした。

コンピュータは一度に1つのオーディオストリームしか再生できないので、複数の人が話している場合には、再生する前に複数のオーディオストリームを数学的に1つに「ミックス」する必要があるなど、いくつか厄介な点がありましたが、オーディオサンプリングの仕組みを理解すれば、ソフトウェアですべて解決することができました。このオーディオアプリケーションがきっかけで、私はMBONEに取り組み、最終的には「nv」でオーディオからビデオへと移行しました。

プロトコルに含まれていないもので、追加しておけばよかったと思うものはありますか? プロトコルの中で後悔していることはありますか?

後悔しているとまでは言いませんが、RTPに対する大きな不満のひとつは、RTPのデータトラフィックと並行して走る制御プロトコルであるRTCPの実装が複雑だったことです。RTPが広く採用されなかったのは、この複雑さが大きく影響していると思います。特にユニキャストの場合は、RTCPの機能の一部がそれほど必要ではありませんでした。 ネットワークの帯域幅が希少ではなくなり、輻輳がそれほど大きな問題ではなくなったため、多くの人がオーディオやビデオを普通のTCP(後にはHTTP)でストリーミングするようになり、一般的には「十分に」機能するのでRTPを扱う価値はありませんでした。

残念なことに、TCPやHTTPを使用すると、マルチパーティのオーディオやビデオのアプリケーションは、同じデータをネットワーク上で何度も送信しなければならず、それを受信する必要のある各ピアに送信しなければならず、帯域幅の観点からは効率が非常に悪くなります。私は、IPマルチキャストの採用を研究機関だけでなく、もっと推進していればよかったと思うことがあります。 そうすれば、ケーブルテレビや放送テレビからインターネットベースのオーディオやビデオへの移行を、もっと早く実現できたと思います。

RTPでどんなものが作られると想像していましたか?RTPを使ってどんなものが作られると想像していましたか?また、失われてしまったクールなRTPプロジェクトやアイデアはありますか?

私が作って面白かったのは、IPマルチキャストを使った古典的な「Space War」ゲームのバージョンでした。セントラルサーバを持たずに、複数のクライアントがそれぞれspacewarバイナリを実行し、自機の位置、速度、向いている方向、発射した「弾」の同様の情報をブロードキャストし始めると、他のすべてのインスタンスがその情報を拾ってローカルにレンダリングし、ユーザーはお互いの自機や弾を見ることができ、自機がお互いに衝突したり、弾が当たったりすると「爆発」します。爆発の際に発生する「破片」は、他の船を破壊できる生きたオブジェクトにして、時には連鎖反応を起こすようにしました。

オリジナルのゲームの精神に則り、シミュレートされたベクターグラフィックスを使ってレンダリングしました。船自体は、PARCの同僚にデザインを手伝ってもらったベクター形式の線分の束で、みんなの船がユニークな外観になっています。

基本的にRTPは、完全なインオーダー・デリバリーを必要としないリアルタイム・データ・ストリームの恩恵を受けられるものであれば、何でも利用できる。つまり、オーディオやビデオに加えて、共有のホワイトボードのようなものを構築できます。ファイル転送でも、特にIPマルチキャストとの組み合わせでは、RTPの恩恵を受けることができます。

BitTorrentのようなものを想像してみてください。ただし、ピア間でポイント・ツー・ポイントでデータをやり取りする必要はありません。オリジナルのシーダーは、マルチキャストストリームをすべてのリーチャーに一度に送信することができ、途中でパケットロスがあっても、データの受信に成功したピアからの再送ですぐに解決できます。ネットワークの真ん中でパケットロスが発生すると、その地点から下流にいるたくさんのクライアントが同じデータを逃してしまうことになるからです。

なぜ独自の動画圧縮を行う必要があったのですか?当時は他になかったのでしょうか?

私が「nv」を作り始めた当時、ビデオ会議を行うシステムは非常に高価な専用ハードウェアしかありませんでした。例えば、スティーブ・カスナーはBBN社の「DVC」(後に「PictureWindow」として商品化)というシステムを利用していました。圧縮には専用のハードウェアが必要だが、解凍はソフトウェアで行うことができた。 nv」がユニークなのは、圧縮と解凍の両方をソフトウェアで行い、必要なハードウェアは入力されたアナログビデオ信号をデジタル化するものだけだということです。

映像を圧縮するための基本的なコンセプトは、「nv」と同時期に登場したMPEG-1規格などによってすでに確立されていましたが、MPEG-1を使ったリアルタイムのエンコーディングは、当時は絶対にできませんでした。私が行った変更は、これらの基本的な概念を、より安価なアルゴリズムで近似することでした。コサイン変換や浮動小数点などは避け、SPARCステーションでは非常に遅いため、整数の乗算も避けました。加減算とビットマスク、シフトだけでできる限りのことをしようとしました。そうすることで、ビデオのような感覚を維持するのに十分なスピードを取り戻すことができました。

「nv」がリリースされてから1〜2年も経たないうちに、MBONEだけでなく、Macに搭載されたCU-SeeMeツールなど、さまざまなオーディオ・ビデオツールが登場しました。そのため、明らかに時代に合ったアイデアだと思いました。実際、私は「nv」をこれらのツールの多くと相互運用できるようにしましたし、いくつかのケースでは、他のツールが私の「nv」コーデックをピックアップして、私の圧縮スキームを使用する際に相互運用できるようにしました。

SDP #

ICE #

SRTP #

SCTP #

DTLS #