JP4504749B2

JP4504749B2 - Ｒｔｐペイロード形式

Info

Publication number: JP4504749B2
Application number: JP2004198165A
Authority: JP
Inventors: エム．アルコーブジェームズ; イー．クレメンツアンダース
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2003-07-03
Filing date: 2004-07-05
Publication date: 2010-07-14
Anticipated expiration: 2024-07-05
Also published as: US20090135849A1; CN1578311B; US20050002525A1; IL162304A0; JP2005027325A; KR20110013561A; SG129298A1; EP1494425A1; US7876896B2; MXPA04006449A; CA2469830A1; EP1494425B1; NZ533297A; US7483532B2; CN1578311A; CA2786809A1; MY146788A; KR101026565B1; IL199658A0; KR101022894B1

Description

本発明は、リアルタイムトランスポートプロトコル（ＲＴＰ）に関し、より詳細には、インターネットなどのネットワークを介したストリーミングメディア（たとえば音声、映像）のためのＲＴＰワイヤフォーマットに関する。

以下の説明は、読者が非特許文献１および非特許文献２についての知識があることを前提にしている。

リアルタイムトランスポートプロトコル（ＲＴＰ）は、非特許文献１で定義されているように、リアルタイムのデータ、たとえば音声、映像またはシミュレーションデータを、マルチキャストまたはユニキャストネットワークサービスを介して伝送するアプリケーションに適したエンドツーエンドのネットワーク移送機能を提供する。こうした移送機能は、対話用の音声および映像など、リアルタイム特性を有するデータのためのエンドツーエンドの配信サービスを提供する。このようなサービスは、ペイロードタイプの識別、シーケンス番号付与、タイムスタンプ付与、および配信の監視を含む。ＲＴＰは、基底（ｕｎｄｅｒｌｙｉｎｇ）ネットワークによって提供される場合、マルチキャストによる配布を用いて、複数の宛先へのデータ転送をサポートする。

非特許文献１は、適時配信を確実に行うためのどのような機構も提供せず、他のサービス品質も保証しないが、そうしたことを行うために、より下位層のサービスに依拠する。非特許文献１は、配信の保証も順不同な配信の防止も行わず、基底ネットワークが信頼できるものであること、およびパケットを順番通りに配信することも前提としない。ＲＴＰに含まれるシーケンス番号は、受信側が送信側のパケットシーケンスを復元することを可能にするが、シーケンス番号は、たとえば映像のデコードにおいて、シーケンス中のパケットを必ずしもデコードせずに、パケットの適切な位置を判定するのに使われることもできる。

ＲＴＰの一般的なアプリケーションは、データのストリーミングを含み、このストリーミングにおいて、拡張システム形式（ＡＳＦ）の音声映像（ＡＶ）データのパケットは、ＲＴＰパケットの形で、ネットワークを介してサーバからクライアントへ、またはピアツーピアで送信される。ＡＳＦの音声および映像データは、１つのＡＳＦパケットに共に格納することができる。このように、ＲＴＰパケットは、音声および映像データ両方を含むことができる。

ＲＴＰは、非特許文献１で定義されているように、複数のペイロードを単一のＲＴＰパケットに共にグループ化するとともに１つのペイロードを複数のＲＴＰパケットに分割するような柔軟性がない。また、非特許文献１は、メタデータがＲＴＰパケット中の各ペイロードと共に配信することができる形式も定義していない。非特許文献１の別の欠点は、データの暗号化ブロックをネットワーク全体にストリーミングする機構であって、暗号化ブロックの受信側がデータの暗号化ブロックを暗号解除することができるように各暗号化ブロックのブロック境界を保持する機構がないことである。ＲＴＰストリーミングに対する機能強化として、このような柔軟性を提供することは、当該分野において進歩であろう。

IETF RFC 1889 standard - RTP: A Transport Protocol for Real-Time Applications IETF RFC 1890 standard - RTP Profile for Audio and Video Conferences with Minimal Control

したがって、このような柔軟性を提供することができる、改良された方法、コンピュータ可読媒体、データ構造、装置、および計算装置が必要である。

一実装形態では、拡張システム形式（ＡＳＦ）の音声映像（ＡＶ）データのパケットが、ＡＶデータをストリーミングするようにとの要求に応答して、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットに再パケット化され、ネットワークを介してサーバからクライアントへ、またはピアツーピアネットワーク通信によって送信される。ＡＶデータは、暗号化されて、暗号ユニットを形成する。再パケット化処理は、暗号ユニットをＲＴＰパケットにパケット化することを含み、ＲＴＰパケットはそれぞれ、ＲＴＰパケットヘッダ、共通データストリームの１つまたは複数のペイロード、および各ペイロードに対するＲＴＰペイロード形式（ＰＦ）ヘッダを含む。ＲＴＰＰＦヘッダは、対応する暗号ユニットに対して、ペイロードに対する境界を含む。ＲＴＰパケット中のペイロードは、１つまたは複数の暗号ユニットでも、暗号ユニットのフラグメント（ｆｒａｇｍｅｎｔ）でもよい。ＲＴＰパケットがネットワークを介して送信された後、受信されたＲＴＰパケットに含まれる暗号ユニットは、再アセンブルされる。再アセンブリ処理は、ＲＴＰパケット中のペイロード、およびそれぞれのＲＴＰＰＦヘッダ中のそれぞれの境界を使用する。再アセンブルされた暗号ユニットは、レンダリング（ｒｅｎｄｅｒｉｎｇ）のために暗号解除（ｄｅｃｒｙｐｔ）することができる。各ＲＴＰＰＦヘッダは、ペイロードをレンダリングするのに使用することができる、各ＲＴＰＰＦヘッダに対応するペイロードの属性を有することができる。

上記の実装形態に対する変形形態では、ＡＳＦ以外の形式のデータが、ＲＴＰパケットを形成するのに使われる。上記の実装形態に対するさらに別の変形形態では、ＲＴＰパケットは、暗号化されていないペイロードを含むように形成される。

さらに別の実装形態では、Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａデジタル著作権管理（ＷＭＤＲＭ）で保護されたデータの暗号化ブロックを、ＲＴＰパケットの形でネットワーク全体にストリーミングする（たとえば、ＷＭＤＲＭ保護された内容をストリーミングする）ためのワイヤフォーマットが提供される。各ＲＴＰパケットは、暗号化ブロック境界を保持するためのヘッダデータを含み、そうすることによって、各暗号ユニットは、暗号ユニットの受信側によって暗号解除することができるようになる。ＷＭＤＲＭプロトコルを用いて暗号解除を行うと、ストリームデータは、受信側によってレンダリングすることができる。

本明細書において開示される実装形態では、単一データストリームおよび混合データストリーム、たとえばＷｉｎｄｏｗｓ（登録商標）のメディアデータを、リアルタイムトランスポートプロトコル（ＲＴＰ）を介して配信するためのワイヤフォーマットを定義する。こうした配信は、サーバとクライアントの間でもよく、ピアツーピアの状況（たとえば、Ｗｉｎｄｏｗｓ（登録商標）メッセンジャー（商標）の音声映像会議用ソフトウェア環境）でもよい。

ワイヤフォーマットは、様々な実装形態において、非特許文献１を、ＲＴＰ配信をより柔軟にするように拡張する。いくつかの実装形態は、ＲＴＰパケット中の映像データとは別個である、ＲＴＰパケット中の音声データをストリーミングする機構を提供する。いくつかの実装形態は、ペイロードを記述する豊富な情報を提供するメタデータが、ＲＴＰパケット中の各ペイロードと共に配信することができるワイヤフォーマットも提供する。さらに他の実装形態は、データの暗号化ブロックをネットワーク全体にストリーミングする一方、暗号化ブロックの受信側がデータの暗号化ブロックを暗号解除することができるように各暗号化ブロックのブロック境界を保持する機構を提供する。別の実装形態では、ワイヤフォーマットは、データの配信がレンダリングのために暗号化されなくてよいようにＷｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａデジタル著作権管理（ＷＭＤＲＭ）で保護されたデータの配信を実現する。

本明細書において開示される様々な実装形態では、システム層ビットストリームに含まれる一連のメディアパケットに、データを再パッケージ化する。こうしたデータは、システム層ビットストリームがＲＴＰにマッピングされるように、非特許文献１に従って、それをさらに機能拡張したやり方で、ＲＴＰパケットにパケット化される。このマッピングにおいて、各メディアパケットは、１つまたは複数のペイロードを含む。いくつかのシステム層ビットストリーム中には、たとえば音声データ、映像データ、プログラムデータ、ＪＰＥＧデータ、ＨＴＭＬデータ、ＭＩＤＩデータなどのデータを有する混合メディアパケット（ｍｉｘｅｄｍｅｄｉａｐａｃｋｅｔ）が存在し得る。混合メディアパケットとは、そのペイロードの２つ以上が、異なるメディアストリームに属すメディアパケットである。

様々な実装形態が、各メディアパケットが単一のメディアパケットであるシステム層ビットストリームに適用される。単一のメディアパケットでは、メディアパケット中のペイロードすべてが、同じメディアストリームに属す。他の実装形態は、各メディアパケットが常にただ１つのペイロードを含むシステム層ビットストリームに適用される。さらに別の実装形態では、メディアパケット中の「ペイロードヘッダ」のサイズがゼロであり、このことは、各メディアパケットが単一のペイロードのみを含む場合によく起こるが、メディアパケットヘッダが、各ペイロードのサイズに関する情報を含む複数のペイロードが存在する場合にも起こり得る。

図１〜２は、データをそれぞれが有する一連の拡張システム形式（ＡＳＦ）のパケットを、システム層ビットストリームが含む例示的な実装形態を示す。こうしたデータは、非特許文献１に従って、それをさらに機能拡張したやり方で、ＲＴＰパケットにパケット化される。このように、システム層ビットストリームは、ＡＳＦパケットである一連のメディアパケットを含み、各ＡＳＦパケット中のペイロードは、ＡＳＦペイロードである。ＡＳＦパケットは例として使用されているが、ＲＴＰパケットの作成は、本明細書において開示される他の実装形態では、ＡＳＦ形式のデータの使用に限定されるわけではなく、ストリーミングされるデータが格納される他の形式を使うことができる。こうした他の形式、ならびにＡＳＦ形式は一般に、本明細書ではデータをそれぞれが有する複数のメディアパケットを含むシステム層ビットストリームとして記載され、こうしたデータは、様々な実装形態においてＲＴＰにマッピングされる。

ＡＳＦストリーム音声映像（ＡＶ）データ１００が、図１に示されている。ＡＳＦストリームＡＶデータ１００は、音声データ１０２および映像データ１０４を含み、ＡＳＦパケットＡ１０６およびＡＳＦパケットＢ１０８にパケット化されている。ＡＳＦパケットＡ１０６は、第１のＡＳＦヘッダ、ＡＳＦペイロードヘッダ、音声データ１０２、第２のＡＳＦヘッダ、および映像データ１０４の映像データＡフラグメントを含む。ＡＳＦパケットＢ１０８は、ＡＳＦヘッダ、ＡＳＦペイロードヘッダ、および映像データ１０４の映像データＢフラグメントを含む。

ＡＳＦパケットＡ１０６およびＡＳＦパケットＢ１０８で表現されるＡＳＦストリームＡＶデータ１００は、一実装形態では、複数のＲＴＰパケットにパケット化することができる。図１に見られるように、こうした複数のＲＴＰパケットは、ＲＴＰパケットＡ１１０、ＲＴＰパケット１１２（１）からＲＴＰパケット１１２（Ｎ）、およびＲＴＰパケットＤ１１６を含む。各ＲＴＰパケットは、非特許文献１によると、ＲＴＰパケットヘッダ、ペイロード、およびＲＴＰペイロード形式（ＰＦ）ヘッダを有する。本明細書で使用されるＲＴＰＰＦヘッダは、ＲＴＰパケット中のペイロードヘッダである。ただ１つのタイプのメディアがＲＴＰパケット中にある。言い換えると、ＲＴＰパケットは、混合メディアペイロードを含まない。図１に示される実装形態において、ＡＳＦパケットＡ１０６の映像データＡは、単一のＲＴＰパケットに収まるには大きすぎる。したがって、ＡＳＦパケットＡ１０６の映像データＡは、ＲＴＰパケット１１２（１）からＲＴＰパケット１１２（Ｎ）に分割される。ＲＴＰパケットのサイズは、ＲＴＰパケットがそれを介して伝送されるべき基底ネットワークの物理特性、または基底ネットワークの管理者によって作成され得るような、パケットサイズに関する管理方針、または基底ネットワークの伝送帯域幅の評価の関数であり得る。

図１に示されるＲＴＰパケット化の説明を続けると、音声データ１０２がＲＴＰパケットＡ１１０に含まれ、ＡＳＦパケットＢ１０８の映像データＢがＲＴＰパケットＤ１１６に含まれる。各ＲＴＰパケットの各ＲＴＰＰＦヘッダは、音声データおよび映像データの、それぞれ別個のＲＴＰパケットへの分離に関する情報を含むことができる。したがって、Ａ／Ｖストリームサンプルデータ１２４は、ＲＴＰパケットＡ１１０中の音声データ、それぞれのＲＴＰパケット１１２（１）から１１２（Ｎ）の中の映像データＡフラグメント１から映像データＡフラグメントＮ、およびＲＴＰパケットＤ１１６中の映像データＢから復元することができる。Ａ／Ｖストリームサンプルデータ１２４の復元が完了すると、その中にある音声サンプルデータ１２０および映像サンプルデータＡ＋Ｂ１２２は、ストリーミング状況においてレンダリングすることができる。上記のことを考えると、図１は、より小さいＲＴＰパケットがより大きいＡＳＦパケットから作成されるワイヤフォーマットを示しており、このワイヤフォーマットでは、パケット化によって、それ自体のＲＴＰＰＦヘッダをそれぞれが有する別個のパケットに、異なるデータストリームのペイロードが書き込まれる。図１は、ＡＳＦパケットに暗号化されパケット化された元の音声サンプルおよび映像サンプルが、ＲＴＰパケットに対して実施される暗号解除機構によって復元することができるように、各ペイロードに対するブロック境界が保存されるワイヤフォーマットの実装形態も示す。

ＡＳＦストリームＡＶデータ２００が、図２に示されている。ＡＳＦストリームＡＶデータ２００は、映像データ２０２を含み、ＡＳＦパケットＡ２０８およびＡＳＦパケットＢ２１０にパケット化されている。ＡＳＦパケットＡ２０８は、ＡＳＦヘッダ、ＡＳＦペイロードヘッダ、および映像データＡ２０４を含む。ＡＳＦパケットＢ２１０は、ＡＳＦヘッダ、ＡＳＦペイロードヘッダ、および映像データＢ２０６を含む。図２は、非特許文献１に従って、それをさらに機能拡張したやり方で、ＡＳＦストリームＡＶデータ２００をＲＴＰパケットにパケット化する２つの代替形態を示す。

第１の代替形態では、矢印２５０に続いて、映像データＡ２０４および映像データＢ２０６が、ＲＴＰヘッダを有する単一のＲＴＰ代替パケットＡ２１２にパケット化される。映像データＡ２０４および映像データＢ２０６のそれぞれの前にＲＴＰＰＦヘッダがある。ＲＴＰ代替パケットＡ２１２は、非特許文献１によると、ＲＴＰヘッダ、複数のペイロード、およびそれぞれのＲＴＰＰＦヘッダを有する。

第２の代替形態では、やはり矢印２５０に続いて、それぞれのＡＳＦパケットからの映像データＡ２０４および映像データＢ２０６が、ＲＴＰヘッダを有するＲＴＰ代替パケットＢ２１４にパケット化される。映像データＡ２０４および映像データＢ２０６は、ＲＴＰ代替パケットＢ２１４中のペイロードとして、隣接してアセンブルされる。このペイロードは、ＲＴＰＰＦヘッダに先行される。ＲＴＰ代替パケットＢ２１４は、非特許文献１によると、ＲＴＰヘッダ、ペイロード、および１つのＲＴＰＰＦヘッダを有する。

図２に示されるＲＴＰパケット化に続いて、映像データＡおよびＢ（２０４、２０６）が、ＲＴＰ代替パケットＡ２１２またはＲＴＰ代替パケットＢ２１４のいずれかに含められる。各ＲＴＰＰＦヘッダは、対応するペイロードに関する情報を含むことができる。代替ＲＴＰパケット２１２、２１４はそれぞれ、映像データＡおよびＢ（２０４、２０６）をその中に取得するように、ＡＳＦパケットＡ２０８およびＡＳＦパケットＢ２１０を復元するのに十分なデータを含む。映像サンプルデータ２２２の復元が完了すると、映像サンプルデータ２２２は、ストリーミング状況においてレンダリングすることができる。上記のことを考えると、図２は、より大きいＲＴＰパケットがより小さいＡＳＦパケットから作成されるＲＴＰワイヤフォーマットを示しており、このワイヤフォーマットでは、２つのＡＳＦパケットに暗号化されパケット化された元の映像サンプルが、ＲＴＰパケットに対して実施される暗号解除機構によって復元することができるように、各ペイロードに対するブロック境界が保存される。

図３ａは、ＲＴＰヘッダ中のフィールド向けのデータ構造の配置図を示す。ＲＴＰヘッダは、非特許文献１において、より十分に説明されている。ＲＴＰヘッダ中のタイムスタンプフィールドは、ＲＴＰパケットに含まれるサンプルの提示時間に設定されるべきである。一実装形態では、クロック周波数は、ＲＴＰに依存しない手段によって、それ以外の値に指定されない限り、１ｋＨｚである。

ＲＴＰヘッダの先頭から８番目のビットは、マーカ（Ｍ）ビットフィールドと解釈される。Ｍビットは、ゼロにセットされるが、サンプルのフラグメントではないペイロード、サンプルの最終フラグメントを含むペイロード、またはＲＴＰパケット中の複数の完全なサンプルの１つであるペイロードを、対応するＲＴＰパケットが有するときは常に、１にセットされる。Ｍビットは、デコードし提示するための完全なサンプルの受信を検出するために、受信側によって使われることができる。したがって、ＲＴＰヘッダ中のＭビットは、パケットストリーム中の重大なイベント（たとえば、映像サンプルフレーム境界）に印をつけるのに使われることができる。

図３ｂは、ＲＴＰペイロード形式（ＰＦ）ヘッダ、すなわちペイロードヘッダの一実装形態を示す。ＲＴＰＰＦヘッダは、可変長部分によって後続される１６ビットの固定長部分を有する。図３ｂに示されるＲＴＰＰＦヘッダのフィールドは、文字フィールド「ＳＧＬＲＴＤＸＺ」、長さ／オフセットフィールド、相対タイムスタンプフィールド、圧縮解除時間フィールド、持続期間フィールド、ならびにペイロード拡張（Ｐ．Ｅ．）長さフィールドおよび対応するＰ．Ｅ．データフィールドによって示される８ビットの文字列を含み、こうしたフィールドはそれぞれ、以下で説明される。

Ｓフィールドは、長さが１ビットであり、対応するペイロード（たとえば、サンプル、サンプルのフラグメント、またはサンプルの組合せ）がキーサンプル、すなわち画像内エンコード（ｉｎｔｒａｃｏｄｅｄ）サンプル、あるいはＩフレームである場合、１にセットされる。そうでない場合は、ゼロにセットされる。同じサンプルのフラグメントに先行するすべてのＲＴＰＰＦヘッダ中のＳビットは、同じ値にセットされなければならない。

Ｇフィールドは、長さが１ビットであり、単一のサンプルを作り上げる、対応するペイロード中の下位サンプルをグループ化するのに使われる。Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｄｉａデジタル著作権管理（ＷＭＤＲＭ）では、「ＡＳＦペイロード」境界に基づいて、内容を暗号化する。この内容が正しく暗号解除されるようにするために、ペイロード中の下位サンプルの境界は、ペイロードを受信すべきクライアントに伝達することができる。たとえば、暗号ユニットは、伝送されるべき複数の伝送単位（たとえば、別個のパケット中に置かれる）に区切られるように、パケット化することができる。区切られた複数の伝送単位は、受信側クライアントにおいて暗号解除することができないうちに、元の暗号化形態に再アセンブルされなければならない。他の暗号解除方法および機構と同様、クライアントは、暗号化された内容の暗号解除の準備において、暗号化された暗号ユニットを正しく復元するのに境界を使うことができる。したがって、各「ＡＳＦペイロード」の前には、このＲＴＰＰＦヘッダがなければならない。

Ｇフィールドのビットは、暗号化された「ユニット」がフラグメント化されていることを示すために、ゼロ（「０」）にセットされるべきである。ＡＳＦが使われている場合、暗号ユニットはＡＳＦペイロードであり、そのビットは、最後のＡＳＦペイロードを除くすべてのフラグメント化されたＡＳＦペイロードにおいてゼロ（「０」）にセットされる。この場合、サンプルがフラグメント化されているかどうかは問題でない。ＡＳＦが使われていない場合、暗号ユニットはメディアサンプルであり、この場合、Ｇビットは、最後のサンプルを除くすべてのフラグメント化されたメディアサンプルにおいてゼロ（「０」）にセットされる。後者の場合に関しては、ＡＳＦが使われていないので、ＡＳＦペイロードがフラグメント化されているかどうかに関する問題は適切でない。

Ｌフィールドは、長さが１ビットであり、長さ／オフセット（Ｌｅｎｇｔｈ／Ｏｆｆｓｅｔ）フィールドが長さを含む場合、１にセットされる。そうでない場合は、ゼロ（「０」）にセットされ、長さ／オフセットフィールドは、オフセットを含む。Ｌビットは、対応するペイロード中の完全な（フラグメント化されていない）サンプルに先行するすべてのＲＴＰＰＦヘッダにおいて１にセットされなければならず、フラグメント化されたサンプルを含むペイロードに先行するすべてのＲＴＰＰＦヘッダにおいて、ゼロにセットされなければならない。

Ｒフィールドは、長さが１ビットであり、ＲＴＰＰＦヘッダが相対的なタイムスタンプを含む場合、１にセットされる。そうでない場合は、ゼロにセットされる。同じサンプルのフラグメントに先行するすべてのヘッダ中のＲビットは、同じ値にセットされなければならない。

Ｔフィールドは、長さが１ビットであり、ＲＴＰＰＦヘッダが圧縮解除時間を含む場合、１にセットされる。そうでない場合は、ゼロにセットされる。同じサンプルのフラグメントを含むペイロードに先行するすべてのＲＴＰＰＦヘッダ中のＴビットは、同じ値にセットされなければならない。

Ｄフィールドは、長さが１ビットであり、ＲＴＰＰＦヘッダがサンプル持続期間を含む場合、１にセットされる。そうでない場合は、ゼロにセットされる。同じサンプルのフラグメントを含むペイロードに先行するすべてのＲＴＰＰＦヘッダ中のＤビットは、同じ値にセットされなければならない。

Ｘフィールドは、長さが１ビットであり、任意選択による使用または特定されない使用のためのものである。ＲＴＰパケットの送信側は、このビットをゼロにセットすべきであり、受信側は、このビットを無視することができる。

Ｚフィールドは、長さが１ビットであり、対応するペイロードに関するメタデータであり得るペイロード拡張（Ｐ．Ｅ．）データをＲＴＰＰＦヘッダが含む場合、１にセットされる。そうでない場合、Ｚフィールドは、ゼロにセットされる。Ｚフィールドのビットは、ＭビットがゼロであるすべてのＲＴＰＰＦヘッダに対してゼロでよいが、対応するペイロードが、関連づけられたＰ．Ｅ．データを有する場合は、Ｍビットが１にセットされているすべてのＲＴＰＰＦヘッダに対してセットされるべきである。

長さ／オフセットフィールドは、長さが２４ビットであり、複数のＲＴＰパケットにフラグメント化されている単一のサンプルの長さまたはオフセットの値を表す。Ｌビットはゼロにセットされ、長さ／オフセットフィールドは、対応するペイロードの先頭からの、このフラグメント（たとえば、サンプルまたはサンプルのフラグメント）の第１バイトのバイトオフセットを含む。１つまたは複数の完全なサンプルがＲＴＰパケットに含まれる場合、Ｌビットは、各ＲＴＰＰＦヘッダにおいて１にセットされ、サンプルの長さ／オフセットフィールドは、（ＲＴＰＰＦヘッダを含む）サンプルの長さを含む。

相対タイムスタンプ（ＲｅｌａｔｉｖｅＴｉｍｅｓｔａｍｐ）フィールドは、長さが３２ビットであり、Ｒビットが１にセットされている場合のみ示される。このフィールドは、対応するＲＴＰヘッダ中のタイムスタンプに関して、対応するサンプル用の相対的なタイムスタンプを含む。使用されるタイムスケールは、ＲＴＰヘッダ中のタイムスタンプに使用されるものと同じである。相対タイムスタンプフィールドは、ＲＴＰヘッダのタイムスタンプからの負のオフセットを可能にするための、符号付きの３２ビット数として指定される。相対タイムスタンプフィールドが存在しない場合、ゼロであるデフォルトの相対タイムスタンプを使うことができる。

圧縮解除時間（ＤｅｃｏｍｐｒｅｓｓｉｏｎＴｉｍｅ）は、長さが３２ビットであり、Ｔビットが１にセットされている場合のみ示される。圧縮解除時間は、ＲＴＰヘッダ中のタイムスタンプに相対的な圧縮解除時間を含む。使用されるタイムスケールは、ＲＴＰヘッダ中のタイムスタンプに使用されるものと同じである。このフィールドは、ＲＴＰヘッダ中のタイムスタンプからの負のオフセットを可能にするための、符号付きの３２ビット数として指定される。

持続期間（Ｄｕｒａｔｉｏｎ）フィールドは、長さが３２ビットであり、Ｄビットが１にセットされている場合のみ示される。このフィールドは、対応するサンプルの持続期間を含む。使用されるタイムスケールは、ＲＴＰヘッダ中のタイムスタンプに使用されるものと同じである。持続期間フィールドは、同じサンプルのフラグメントに先行するすべてのＲＴＰＰＦヘッダにおいて、同じ値にセットされるべきである。このフィールドが存在しない場合、デフォルトの持続期間は、サンプルデータから自動的にまたは明示的に取得される。これが実行できない場合、デフォルトは、このサンプルのタイムスタンプと次のサンプルのタイムスタンプとで異なる。

ペイロード拡張（Ｐ．Ｅ．）データ長さ（ＰａｙｌｏａｄＥｘｔｅｎｓｉｏｎ（Ｐ．Ｅ．）ＤａｔａＬｅｎｇｔｈ）フィールドは、長さが１６ビットであり、Ｚビットが１にセットされている場合のみ示される。このフィールドは、ＲＴＰＰＦヘッダの固定部分の後に含まれるＰ．Ｅ．データのバイト数を含む。Ｐ．Ｅ．データは可変長であり、Ｐ．Ｅ．データが前にある、対応するペイロードを記述する１つまたは複数の属性を含む。Ｐ．Ｅ．データ長フィールドは、ペイロードヘッダの固定部分のすぐ後に続き、実際のＰ．Ｅ．データを含むいくつかのバイトである。Ｐ．Ｅ．データの構造は、クライアントとサーバの間で（またはピアツーピアで）、たとえばＳＤＰの記述を介して伝達される。ＷＭＤＲＭで保護された内容に対する一実装形態では、すべてのサンプルに関連づけられたＷＭＤＲＭペイロードＩＤを表す少なくとも４バイトのＤＵＥデータがあり得る。

図３ａ〜３ｂは、ＲＴＰヘッダおよびＲＴＰＰＦヘッダ用の様々なフィールドを様々な順序で示すが、すべてのフィールドが必要とされるわけではなく、その順序は、並べ替えることができる。したがって、いくつかの実装形態では、必要とされるフィールドおよび順序は、非特許文献１の柔軟性に従い、さらに拡張することができる。図３ａ〜３ｂの説明のためにＡＳＦパケットが使われているが、ＲＴＰパケット、ＲＴＰＰＦヘッダおよびペイロードの作成はしたがって、本明細書において開示される他の実装形態において、ＡＳＦ形式のデータの使用に限定されるのではなく、ストリーミングされるデータが格納される他の形式を使うこともできる。

一般的なネットワーク構造
図４は、本発明によるクライアント／サーバネットワークシステム４００および環境を示す。一般に、システム４００は、１つまたは複数（ｍ個）のネットワークマルチメディアサーバ４０２、および１つまたは複数（ｋ個）のネットワーククライアント４０４を含む。コンピュータは、図４において有線／無線ネットワーク４０６を含むデータ通信ネットワークを介して、互いに通信する。データ通信ネットワーク４０６は、インターネット、またはローカルエリアネットワークおよび専用ワイドエリアネットワークを含むこともできる。サーバ４０２およびクライアント４０４は、非常に様々な公知のプロトコル、たとえば伝送制御プロトコル（ＴＣＰ）やユーザデータグラムプロトコル（ＵＤＰ）のどれを介しても、互いに通信する。

マルチメディアサーバ４０２／クライアント４０４は、様々なメディアストリームの形式におけるストリーミングメディアの内容へのアクセス権を有する。こうしたメディアストリームは、個別のメディアストリーム（たとえば、音声、映像、画像、シミュレーションなど）でも、あるいは、このような複数の個別のストリームを含む複合メディアストリームでもよい。一部のメディアストリームは、データベース（たとえば、ＡＳＦファイル）または他のファイル記憶システムにファイル４０８として格納することができ、他のメディアストリーム４１０は、他のデータソース構成要素からマルチメディアサーバ４０２またはクライアント４０４に、専用の通信チャネルまたはインターネット自体を介して、「ライブ（ｌｉｖｅ）な」状態で供給することができる。

サーバ４０２またはクライアント４０４から受信されたメディアストリームは、クライアント４０４において、サーバ４０２／クライアント４０４の１つまたは複数からのメディアストリームを含むことができるマルチメディア表現としてレンダリングされる。こうした様々なメディアストリームは、同じまたは異なるタイプのメディアストリームの１つまたは複数を含むことができる。たとえば、１つのマルチメディア表現が、２つの映像ストリーム、１つの音声ストリーム、および１つのグラフィックイメージのストリームを含むことができる。クライアント４０４におけるユーザインターフェース（ＵＩ）は、ユーザに様々な制御を許可することができ、たとえば、ユーザが、メディア表現がレンダリングされる速度を上昇または低下させることを可能にする。

例示的なコンピュータ環境
以下の説明において、本発明は、１つまたは複数の従来のパーソナルコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令という一般的な状況において説明される。一般に、プログラムモジュールは、特定のタスクを実施しまたは特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、本発明は、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースの家電製品またはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど、他のコンピュータシステム構成を有して実施することができることが、当業者には理解されよう。分散型コンピュータ環境では、プログラムモジュールは、ローカルおよびリモートメモリ記憶装置両方に置くことができる。あるいは、本発明は、ハードウェアでも、ハードウェア、ソフトウェア、および／またはファームウェアの組合せでも実装することができる。たとえば、１つまたは複数の特定用途集積回路（ＡＳＩＣ）は、本発明を実施するためにプログラミングすることができる。

図４に示すように、本発明によるネットワークシステムは、複数のメディアストリームがそこから利用可能であるネットワークサーバ（群）４０２およびクライアント４０４を含む。いくつかの場合において、メディアストリームは、ネットワークサーバ（群）４０２およびクライアント４０４によって実際に格納される。それ以外の場合では、ネットワークサーバ（群）４０２およびクライアント（群）４０４は、他のネットワークソースまたは装置からメディアストリームを入手することができる。一般に、ネットワーククライアント４０４は、選択されたマルチメディアコンテンツに対応するメディアストリームを要求するためのユーザ入力を担う。マルチメディアコンテンツに対応するメディアストリームに対する要求に応答して、ネットワークサーバ（群）４０２およびクライアント４０４は、要求されたメディアストリームを、要求側ネットワーククライアント４０４に、ＲＴＰワイヤフォーマットに従ってストリーミングする。クライアント４０４は、それぞれのＲＴＰパケット中のペイロードを暗号解除し、その結果得られる、暗号化されていないデータストリームをレンダリングして、要求されたマルチメディアコンテンツを作成する。

図５は、サーバ４０２またはクライアント４０４（たとえば、ピア）に対するＡ／Ｖストリームデータの入力および格納を示す。図５は、様々な実装形態による、サーバとクライアントの間（４０２−４０４）の、またはピアツーピア（４０４−４０４）での通信も示す。概観として、サーバ４０２またはクライアント４０４は、入力装置５０３からＡ／Ｖストリームデータの入力を受信する。サーバ４０２またはクライアント４０４は、コーデックのエンコーダを用いて、入力をエンコードする。エンコードは、ＡＳＦ形式のデータに対して実施することができるが、実施されなくてもよい。ＡＳＦ形式のデータが使われる場合、エンコードは、ＡＳＦヘッダと、ＡＳＦペイロードヘッダと、ＡＶ（音声および／または映像）ペイロードとをそれぞれが含むＡＳＦパケットに対して実施される。エンコードは、たとえばＷＭＤＲＭが用いられる場合は暗号化を含むことができる。ＡＳＦパケットは、同じものに対する今後の要求にサービスするために、サーバ４０２／クライアント４０４によって格納される。

続いて、クライアントは、対応するＡＶデータストリームを、サーバ／クライアントに要求する。サーバ／クライアントは、サーバ／クライアントが格納しておいた、対応するＡＶストリームを取り出し、クライアントに送信する。受信すると、クライアントは、ＡＶデータストリームをデコードし、暗号化された区切られたＡＶデータストリームサンプルを、対応するＲＴＰＰＦヘッダで伝達された境界を用いて復元し暗号解除する。クライアントは、次いで、ストリーミングされたＡＶデータのレンダリングを実行することができる。

データの流れは、図５において、ブロック５０４〜５３０に見られる。ブロック５０４で、入力装置は、Ａ／Ｖストリームデータを含む入力を、サーバ４０２／クライアント４０４に供給（５０２）する。例として、Ａ／Ｖストリームデータは、サーバ４０２／クライアント４０４に、入力装置によって「ライブな」状態で、専用の通信チャネルまたはインターネットを介して供給（５０２）されてもよい。Ａ／Ｖストリームデータは、ブロック５０４で、データをＡＳＦパケット中に配置するためにエンコーダに供給される。ブロック５０６で、任意選択によるＷＭＤＲＭ暗号化が行われ、ＡＳＦパケットが、サーバ４０２／クライアント４０４において格納される。ＷＭＤＲＭ暗号化およびパケット化の結果、暗号ユニットが、複数の別個のパケットに区切られることになり得る。区切られた複数の伝送単位は、受信側クライアントの所で暗号解除することができないうちに、受信側クライアントの所で元の暗号ユニットに再アセンブルされなければならない。このようにして、区切られた伝送単位の境界は、ブロック５０６で、ＡＳＦペイロードヘッダに格納される。

ブロック５０８で、クライアント４０４は、図５の矢印５１０に見られるように、サーバ４０２／クライアント４０４に送信されるＡ／Ｖデータストリームを要求する。ブロック５１２で、サーバ４０２／クライアント４０４は、この要求を受信する。要求されたＡ／Ｖデータストリームを含む、対応するＡＳＦパケットが取り出される。ブロック５１４で、ＡＳＦパケット中の音声ペイロードおよび映像ペイロードは、ＲＴＰパケットに別個にパケット化することができるように、論理的に分離される。論理的に別個の各音声および映像ペイロードの境界が識別される。

ＲＴＰパケットが伝送されるべきネットワークの帯域幅が決定される。この決定は、所定のＲＴＰパケットサイズを導き出すのに用いられる。ＡＳＦパケットサイズが所定のＲＴＰパケットサイズより小さい場合、同類型のペイロードが、単一のＲＴＰパケットに組み合わせることができる。ＡＳＦパケットサイズが所定のＲＴＰパケットサイズより大きい場合、ＡＳＦペイロードは、単一のＲＴＰパケットに１つのペイロードとして配置されるために、フラグメント化することができる。各ＲＴＰペイロードに対する境界は、ＡＳＦパケットの、対応する論理的に別個の音声および映像ペイロードを用いて決定される。

ステップ５１６で、ＲＴＰヘッダ、ＲＴＰＰＦヘッダ、およびそれぞれのペイロードが、各ＲＴＰパケットごとにアセンブルされる。このように、複数のＡＳＦパケットを表す複数のＲＴＰパケットが形成されており、ＡＳＦパケットは、クライアント４０４によって要求されたＡ／Ｖデータストリームを含む。ＲＴＰパケットは、クライアント４０４の所でレンダリングされるために、ブロック５１８で、伝送関数を介してサーバ４０２／クライアント４０４からストリーミングされる。

図５の矢印５２０は、サーバ４０２／クライアント４０４からクライアント４０４への、ＲＴＰパケットの送信を示す。ブロック５２２で、クライアント４０４は、ＲＴＰパケットを受信する。ブロック５２４で、クライアント４０４のＲＴＰデコーダが、ＲＴＰヘッダおよびＲＴＰＰＦヘッダを含む、受信した各ＲＴＰパケットをデコードする。ブロック５２６で、処理は、要求されたＡ／Ｖデータストリームを含むＡＳＦパケットのデフラグ（ｄｅｆｒａｇｍｅｎｔａｔｉｏｎ）および復元を実行する。デフラグおよび復元は、たとえば、サンプルまたはサンプルのフラグメントを含む、対応する各ペイロードに対して、ＲＴＰＰＦヘッダ中で設定された境界を利用する。

ブロック５２８で、復元されたＡＳＦパケットが、ブロック５３０でのレンダリングのために暗号解除される。ＲＴＰパケット中のＲＴＰＰＦヘッダは、対応するペイロードを記述するペイロード拡張（Ｐ．Ｅ．）データを含むことができる。したがって、Ｐ．Ｅ．データはブロック５３０での、対応するＲＴＰパケット中のペイロードのレンダリングの間に使うことができるメタデータを提供することができる。ブロック５２２〜５３０は、クライアント４０４で受信される各ＲＴＰパケットに対して繰り返され、そうすることによって、レンダリングのためにサーバ４０２／クライアント４０４からのＡ／Ｖデータのストリーミングを達成する。

図６は、本発明に従って使うことができるコンピュータ６４２の一般的な例を示す。コンピュータ６４２は、図４〜５のどのクライアント４０４またはサーバ４０２の機能も実施することができるコンピュータの例として示される。コンピュータ６４２は、１つまたは複数のプロセッサまたは処理装置６４４と、システムメモリ６４６と、システムメモリ６４６など様々なシステム構成要素をプロセッサ６４４に結合するシステムバス６４８とを含む。

バス６４８は、様々なバスアーキテクチャのどれをも使用するメモリバスまたはメモリコントローラ、周辺バス、グラフィック専用高速バス（ａｃｃｅｌｅｒａｔｅｄｇｒａｐｈｉｃｓｐｏｒｔ）、およびプロセッサまたはローカルバスなどいくつかのタイプのバス構造のいずれかの１つまたは複数を表す。システムメモリは、読出し専用メモリ（ＲＯＭ）６５０およびランダムアクセスメモリ（ＲＡＭ）６５２を含む。キャッシュ６７５は、Ｌ１、Ｌ２、およびＬ３のレベルを有し、ＲＡＭ６５２に含めることができる。基本入出力システム（ＢＩＯＳ）６５４は、たとえば起動中にコンピュータ６４２内部の要素間の情報の転送を助ける基本ルーチンを含み、ＲＯＭ６５０に格納される。コンピュータ６４２は、ハードディスク（図示せず）からの読出しおよびそこへの書込みをするハードディスクドライブ６５６、取外し可能な磁気ディスク６６０からの読出しまたはそこへの書込みをする磁気ディスクドライブ６５８、および、ＣＤＲＯＭや他の光学媒体などの取外し可能な光ディスク６６４からの読出しまたはそこへの書込みを行う光ディスクドライブ６６２をさらに含む。

ハードディスク（図示せず）、磁気ディスクドライブ６５８、光ディスクドライブ６６２、または取外し可能光ディスク６６４はいずれも、記録された情報を有する情報媒体でよい。こうした情報媒体は、１つまたは複数のデータパケットを含有するパケット領域をそれぞれが含むストリームパケットを用いてストリームデータを記録するデータ領域を有する。例として、各データパケットは、処理装置６４４において実行するアプリケーションプログラム６７２のコーデックによって、エンコードおよびデコードされる。したがって、エンコーダは、ストリームパケット中のデータパケット領域にストリームデータを分散し、そうすることによって、分散されたストリームデータが、エンコードアルゴリズムを用いてデータパケット領域に記録されるようになる。あるいは、データパケットのエンコードおよびデコードは、処理装置６４４上で実行されるオペレーティングシステム６７０の機能として実行されることもできる。

ハードディスクドライブ６５６、磁気ディスクドライブ６５８、および光ディスクドライブ６６２は、ＳＣＳＩインターフェース６６６または適切な他の何らかのインターフェースによって、システムバス６４８に接続される。ドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピュータ６４２のための他のデータの不揮発性記憶を実現する。本明細書で説明される例示的な環境では、ハードディスク、取外し可能磁気ディスク６６０、および取外し可能光ディスク６６４を使用しているが、コンピュータによるアクセスが可能なデータを格納することができる他のタイプのコンピュータ可読媒体、たとえば磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）なども例示的な動作環境において使うことができることが、当業者には理解されよう。

オペレーティングシステム６７０、１つまたは複数のアプリケーションプログラム６７２（コーデックを含むことができる）、他のプログラムモジュール６７４、およびプログラムデータ６７６など、いくつかのプログラムモジュールが、ハードディスク、磁気ディスク６６０、光ディスク６６４、ＲＯＭ６５０、またはＲＡＭ６５２に格納することができる。ユーザは、キーボード６７８およびポインティングデバイス６８０などの入力装置を介して、コマンドおよび情報をコンピュータ６４２に入力することができる。他の入力装置（図示せず）には、マイクロホン、ジョイスティック、ゲーム用パッド、衛星パラボラアンテナ、スキャナなどが含まれ得る。こうした入力装置および他の入力装置は、システムバスに結合されるインターフェース６８２を介して処理装置６４４に接続される。モニタ６８４または他のタイプの表示装置も、ビデオアダプタ６８６などのインターフェースを介してシステムバス６４８に接続される。モニタに加えて、パーソナルコンピュータは通常、他の周辺出力装置（図示せず）、たとえばスピーカおよびプリンタを含む。

コンピュータ６４２は、リモートコンピュータ６８８など、１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続された環境において動作する。リモートコンピュータ６８８は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでよく、通常、コンピュータ６４２に関連して上述した要素の多くまたはすべてを含むが、メモリ記憶装置６７２のみが図６に示されている。図６に示される論理接続は、ローカルエリアネットワーク（ＬＡＮ）６９０およびワイドエリアネットワーク（ＷＡＮ）６９２を含む。このようなネットワーク環境は、会社、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいてよく見られる。本発明の、説明された実施形態において、リモートコンピュータ６８８は、インターネットウェブブラウザプログラム、たとえばワシントン州Ｒｅｄｍｏｎｄのマイクロソフトコーポレーションによって製造され販売されるインターネットエクスプローラ（登録商標）ウェブブラウザを実行する。

ＬＡＮネットワーク環境において使われる場合、コンピュータ６４２は、ネットワークインターフェースまたはアダプタ６９４を介してローカルネットワーク６９０に接続される。ＷＡＮネットワーク環境において使われる場合、コンピュータ６４２は通常、モデム６９６、または、インターネットなどのワイドエリアネットワーク６９２を介した通信を確立する他の手段を含む。モデム６９６は、内部にあっても外部にあってもよく、シリアルポートインターフェース６６８を介してシステムバス６４８に接続することができる。ネットワーク接続された環境では、パーソナルコンピュータ６４２に関連して図示されるプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納することができる。図示されるネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使うことができることが理解されよう。

一般に、コンピュータ６４２のデータプロセッサは、コンピュータの様々なコンピュータ可読記憶媒体に別々のときに格納された命令を使って、プログラミングされる。プログラムおよびオペレーティングシステムは通常、たとえばフロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭに分散される。そこから、コンピュータの補助記憶装置にインストールされまたはロードされる。実行時は、コンピュータの電子的主記憶装置に少なくとも部分的にロードされる。このような媒体が、マイクロプロセッサまたは他のデータプロセッサに関連して特許請求の範囲に記載されるステップを実装する命令またはプログラムを含む場合、本明細書に記載される本発明は、こうしたコンピュータ可読記憶媒体および他の様々なタイプのコンピュータ可読記憶媒体を含める。本発明は、特許請求の範囲に記載される方法および技術に従ってプログラミングされる場合、コンピュータ自体も含める。さらに、コンピュータの特定の下位構成要素は、特許請求の範囲に記載される機能およびステップを実施するようにプログラミングすることができる。本発明は、このような下位構成要素が記載されているようにプログラミングされる場合、それを含める。さらに、本明細書に記載されている本発明は、特許請求の範囲に記載されるデータ構造を、様々なタイプの記憶媒体上で具体化されるものとして含める。

説明のために、オペレーティングシステムなどのプログラムおよび他の実行可能なプログラム構成要素は、本明細書において、別々のブロックとして説明されているが、このようなプログラムおよび構成要素は、コンピュータの異なる記憶要素内に様々なときに存在し、コンピュータのデータプロセッサ（群）によって実行されることが理解されよう。

結論
本明細書において開示される実装形態は、サーバとクライアントの間での、およびピアツーピアでの、ＲＴＰを介したマルチメディアデータの配信において使うことができるワイヤフォーマットを定義する。このワイヤフォーマットにより、ＲＴＰ配信用に現在採用されている非特許文献１よりも一層の柔軟性が可能になる。ワイヤフォーマットの実装形態は、暗号化されたデータのストリーミングを実現し、ＲＴＰを介したサンプルメタデータごとの配信を行う機構を提供し、ＷＭＤＲＭで保護されたデータのストリーミングを実現する。

本発明は、構造的な特徴および／または方法のための動作に特有の言葉で説明されているが、特許請求の範囲において定義される本発明は、説明されている特定の特徴にも動作にも必ずしも限定されないことを理解されたい。そうではなく、こうした特定の特徴および動作は、権利請求される本発明を実装する例示的な形態として開示されるものである。

本発明の実施形態による、拡張システム形式（ＡＳＦ）の音声映像（ＡＶ）データの２つのパケットを、４つのＲＴＰパケットに変換する例示的な処理を示す図である。音声データおよび映像データは、その結果得られるＲＴＰパケットに別個にパケット化され、各ペイロードに対するブロック境界は、２つのＡＳＦパケットに暗号化されパケット化された元のＡＶサンプルが暗号解除機構によって復元することができるように保存されている。本発明の異なる実施形態による、ＡＳＦ映像データの２つのパケットを１つのＲＴＰパケットに変換する例示的な代替処理を示す図である。一方の代替処理が、ＡＳＦパケットのペイロードを、ＲＴＰパケット中の別個のペイロードに移動させ、他方の代替処理が、ＡＳＦパケットのペイロードを組み合わせて、ＲＴＰパケット中の組み合わされたペイロードを作成し、各ペイロードに対するブロック境界は、２つのＡＳＦパケットに暗号化されパケット化された元の映像サンプルが暗号解除機構によって復元することができるように保存されている。本発明の実施形態による、ＲＴＰヘッダのデータ構造を示す配置図である。本発明の実施形態による、図３ａのＲＴＰヘッダに対応するペイロードヘッダのデータ構造を示す配置図である。本発明の実施形態による、サーバによってクライアントに対して、またはピアツーピアでストリーミングが実行することができる、ネットワーク接続されたクライアント／サーバシステムを示すブロック図である。本発明の実施形態による、サーバ（またはクライアント）とクライアントの間の通信を示すブロック図である。サーバ（またはクライアント）は、クライアントに対して、クライアントがレンダリングすることのできる、要求された音声映像データストリームを与える。本発明の実施形態による、サーバまたはクライアントのどちらかを実装するのに使うことができる、ネットワーク接続されたコンピュータを示すブロック図である。

符号の説明

１００ＡＳＦストリームＡ／Ｖデータ
１０２音声データ
１０４映像データ
１０６ＡＳＦパケットＡ
１０８ＡＳＦパケットＢ
１１０ＲＴＰパケットＡ
１１２（１）ＲＴＰパケット
１１２（Ｎ）ＲＴＰパケット
１１６ＲＴＰパケットＤ
１２０音声サンプルデータ
１２２映像サンプルデータＡ＋Ｂ
１２４Ａ／Ｖサンプルデータ
２００ＡＳＦストリーム映像データ
２０２映像データ
２０４映像データＡ
２０６映像データＢ
２０８ＡＳＦパケットＡ
２１０ＡＳＦパケットＢ
２１２ＲＴＰ代替パケットＡ
２２２映像サンプルデータ
４０６有線／無線ネットワーク（群）
４０８ストリームデータファイル
４１０ストリームデータ
４０２マルチメディアサーバ（１）
４０２マルチメディアサーバ（ｍ）
４０４クライアント（１）
４０４クライアント（ｋ）
５０３入力装置
６４４処理装置
６４６システムメモリ
６４８バス
６７０オペレーティングシステム
６６６ＳＣＳＩインターフェース
６６８シリアルポート
６７２アプリケーションプログラム（たとえばコーデック）
６７４他のモジュール
６７５キャッシュ
６７６プログラムデータ
６７８キーボード
６８２キーボード／マウスインターフェース
６８６ビデオアダプタ
６９０ローカルエリアネットワーク
６９２ワイドエリアネットワーク
６９４ネットワークインターフェース
６９６モデム

Claims

任意のブロックサイズを有するデータストリームを暗号化して、複数の暗号ユニットを形成する手段と、
拡張システム形式（ＡＳＦ）の音声および映像のデータのパケットをＲＴＰパケットに変換する手段であって、前記音声および映像のデータは、別個にパケット化される手段と、
各ペイロードに対する暗号化ブロック境界を保持するためのデータを保存する手段であって、各ペイロードに対する前記暗号化ブロック境界は、ＡＳＦフォーマットの対応する別個の音声ペイロードと映像ペイロードとにより決定される手段と、
別個のＲＴＰパケットに異なるデータストリームのペイロードを書き込む手段と、
前記複数の暗号ユニットを、複数のＲＴＰパケットにパケット化する手段と
を備える装置であって、前記複数のＲＴＰパケットはそれぞれ、
（ａ）ＲＴＰパケットヘッダと、
（ｂ−１）１つまたは複数の暗号ユニットと、
（ｂ−２）１つの暗号ユニットのフラグメントと
からなるグループから選択される、（ｂ）共通データストリームの１つまたは複数のペイロードと、
（ｃ）各ペイロードに対する１つのＲＴＰペイロード形式ヘッダと
を含み、前記ＲＴＰペイロード形式ヘッダは、対応する前記暗号ユニットに対して、任意のブロックサイズの暗号化ブロック境界を保持するためのデータを含み、
混合メディアペイロードを含まないように、前記ＲＴＰパケット内に音声データと映像データとの分離があり、
各パケットの前記ＲＴＰパケットヘッダは、前記音声データと映像データとの前記分離に関する情報を含み、各ペイロードに対する前記暗号化ブロック境界を保持するためのデータは、暗号化されパケット化された元の音声および映像のデータを暗号解除によって復元することができるように、保存される
ことを特徴とする装置。
前記複数のＲＴＰパケット中の前記ペイロードと、
前記それぞれのＲＴＰペイロード形式ヘッダ中の前記任意のブロックサイズに対する前記それぞれの境界と
を使用して、前記複数の暗号ユニットを再アセンブルする手段と、
前記複数の暗号ユニットを暗号解除して、前記データストリームを形成する手段と
をさらに備えることを特徴とする請求項１に記載の装置。
前記各ＲＴＰペイロード形式ヘッダは、対応する前記ペイロードの１つまたは複数の属性をさらに含み、
対応する前記ペイロードの前記属性を用いて、前記形成されたデータストリームをレンダリングする手段であって、前記レンダリングは、要求されたマルチメディアコンテンツを作成するために行われる手段をさらに備えることを特徴とする請求項２に記載の装置。
各ＲＴＰペイロード形式ヘッダ中の１つまたは複数の属性は、
タイミング情報と、
映像圧縮フレーム情報と
からなるグループから選択されることを特徴とする請求項２に記載の装置。
前記複数のＲＴＰパケットを、ネットワークを介して伝送する手段をさらに備えることを特徴とする請求項２に記載の装置。
複数のメディアデータタイプを含む、データストリーム中の前記メディアデータタイプを論理的に分離する手段と、
前記データストリームから複数のＲＴＰパケットを形成する手段と
を備える装置であって、各ＲＴＰパケットは、
ただ１つのメディアデータタイプと、
１つのＲＴＰパケットヘッダと、
それぞれが１つまたは複数の属性を有する、１つまたは複数の可変長ＲＴＰペイロード形式ヘッダと、
前記各ＲＴＰペイロード形式ヘッダに対応し、前記各ＲＴＰペイロード形式ヘッダ中の前記１つまたは複数の属性によって記述されるＲＴＰペイロードと
を含み、混合メディアペイロードを含まないように、前記ＲＴＰパケット内に音声データと映像データとの分離があり、各パケットの前記ＲＴＰパケットヘッダは、前記音声データと映像データとの前記分離に関する情報を含み、前記情報は、パケット化された元の音声および映像のデータを復元することができるように保存されることを特徴とする装置。
前記複数のＲＴＰパケットから前記ペイロードを抽出する手段と、
前記複数のＲＴＰパケット中の各ペイロードを、対応する前記ＲＴＰペイロード形式ヘッダ中の前記１つまたは複数の属性を用いてレンダリングするであって、前記レンダリングは、要求されたマルチメディアコンテンツを作成するために行われる手段と
をさらに備えることを特徴とする請求項６に記載の装置。
各ペイロードは、映像データを含み、
前記各ＲＴＰペイロード形式ヘッダ中の前記属性は、
タイミング情報と、
映像圧縮フレーム情報と
からなるグループから選択されることを特徴とする請求項７に記載の装置。
前記抽出する手段は、各ＲＴＰペイロードごとに、
前記ＲＴＰペイロードが前記メディアデータタイプの１つである複数の部分を含む場合、前記メディアデータタイプの１つである前記複数の部分を、隣接するペイロードにアセンブルする手段と、
前記ＲＴＰペイロードが前記メディアデータタイプの１つである一部分を含む場合、前記メディアデータタイプの１つである前記１つの部分を、隣接するペイロードにアセンブルする手段と、
前記ＲＴＰペイロードが前記メディアデータタイプの１つである一部分のうち１つのフラグメントを含む場合、前記メディアデータタイプの１つである前記一部分の前記フラグメントすべてを、隣接するペイロードにアセンブルする手段と
をさらに含むことを特徴とする請求項７に記載の装置。
メディアファイルの前記複数のメディアデータタイプに対応するそれぞれの時系列順に、前記隣接するペイロードをアセンブルする手段と、
前記メディアファイルの前記複数のメディアデータタイプである、前記時系列順に隣接するペイロードを、同時にレンダリングする手段と
をさらに備えることを特徴とする請求項９に記載の装置。
任意のブロックサイズを有するデータストリームを暗号化して、複数の暗号ユニットを形成するステップと、
拡張システム形式（ＡＳＦ）の音声および映像のデータのパケットをＲＴＰパケットに変換するステップであって、前記音声および映像のデータは、別個にパケット化されるステップと、
各ペイロードに対する暗号化ブロック境界を保持するためのデータを保存するステップであって、各ペイロードに対する前記暗号化ブロック境界は、ＡＳＦの対応する別個の音声ペイロードと映像ペイロードとにより決定されるステップと、
前記複数の暗号ユニットを、複数のＲＴＰパケットにパケット化するステップであって、前記複数のＲＴＰパケットはそれぞれ、
（ａ）ＲＴＰパケットヘッダと、
（ｂ−１）１つまたは複数の暗号ユニットと、
（ｂ−２）１つの暗号ユニットのフラグメントと
からなるグループから選択される（ｂ）共通データストリームの１つまたは複数のペイロードと、
（ｃ）前記各ペイロードに対する１つのＲＴＰペイロード形式ヘッダであって、対応する前記暗号ユニットに対して、前記任意のブロックサイズの暗号化ブロック境界を保持するためのデータ含む１つのＲＴＰペイロード形式ヘッダと
を含むステップと、
別個のＲＴＰパケットに異なるデータストリームのペイロードを書き込むステップと
を備える方法であって、
混合メディアペイロードを含まないように、前記ＲＴＰパケット内に音声データと映像データとの分離があり、
各パケットの前記ＲＴＰパケットヘッダは、前記音声データと映像データとの前記分離に関する情報を含み、各ペイロードに対する前記暗号化ブロック境界を保持するためのデータは、暗号化されパケット化された元の音声および映像のデータを暗号解除によって復元することができるように、保存されることを特徴とする方法。
前記複数のＲＴＰパケット中の前記ペイロードと、
前記それぞれのＲＴＰペイロード形式ヘッダ中の前記任意のブロックサイズに対するそれぞれの前記境界と
を使用して、前記複数の暗号ユニットを再アセンブルするステップと、
前記複数の暗号ユニットを暗号解除して、前記データストリームを形成するステップと
をさらに備えることを特徴とする請求項１１に記載の方法。
前記各ＲＴＰペイロード形式ヘッダは、対応する前記ペイロードの１つまたは複数の属性をさらに含み、
対応する前記ペイロードの前記属性を用いて、前記形成されたデータストリームをレンダリングするステップであって、前記レンダリングするステップは、クライアントコンピューティングデバイスが備えるプロセッサによって、要求されたマルチメディアコンテンツを作成するために行われるステップをさらに備えることを特徴とする請求項１２に記載の方法。
前記各ＲＴＰペイロード形式ヘッダ中の前記属性は、
タイミング情報と、
映像圧縮フレーム情報と
からなるグループから選択されることを特徴とする請求項１２に記載の方法。
前記再アセンブルするステップに先立って、前記再アセンブルが実施されるクライアントに、ネットワークを介して前記複数のＲＴＰパケットを伝送するステップをさらに備えることを特徴とする請求項１２に記載の方法。
実行されると、請求項１１に記載の方法を実施する機械可読命令を備えることを特徴とするコンピュータ可読媒体。
複数のメディアデータタイプを含む１つのデータストリームから、複数のＲＴＰパケットを形成するステップを備える方法であって、各ＲＴＰパケットは、
ただ１つのメディアデータタイプと、
１つのＲＴＰパケットヘッダと、
それぞれが１つまたは複数の属性を有する、１つまたは複数の可変長ＲＴＰペイロード形式ヘッダと、
各ＲＴＰペイロード形式ヘッダに対応し、前記各ＲＴＰペイロード形式ヘッダ中の前記１つまたは複数の属性によって記述されるＲＴＰペイロードと
を含み、混合メディアペイロードを含まないように、前記ＲＴＰパケット内に音声データと映像データとの分離があり、各パケットの前記ＲＴＰパケットヘッダは、前記音声データと映像データとの前記分離に関する情報を含み、前記情報は、パケット化された元の音声および映像のデータを復元することができるように保存されることを特徴とする方法。
前記複数のＲＴＰパケットから前記ペイロードを抽出するステップと、
前記複数のＲＴＰパケット中の各ペイロードを、対応する前記ＲＴＰペイロード形式ヘッダ中の前記１つまたは複数の属性を用いてレンダリングするステップであって、前記レンダリングするステップは、クライアントコンピューティングデバイスが備えるプロセッサによって、要求されたマルチメディアコンテンツを作成するために行われるステップと
をさらに備えることを特徴とする請求項１７に記載の方法。
各ＲＴＰペイロード形式ヘッダ中の前記属性は、
タイミング情報と、
映像圧縮フレーム情報と
からなるグループから選択されることを特徴とする請求項１８に記載の方法。
前記複数のＲＴＰパケットから前記ペイロードを抽出するステップは、
前記メディアデータタイプの１つである複数の部分を含む各ＲＴＰペイロードごとに、前記メディアデータタイプの１つである前記複数の部分を、隣接するペイロードにアセンブルするステップと、
前記メディアデータタイプの１つである一部分を含む各ＲＴＰペイロードごとに、前記メディアデータタイプの１つである前記一部分を、隣接するペイロードにアセンブルするステップと、
前記メディアデータタイプの１つである一部分のうち１つのフラグメントを含む各ＲＴＰペイロードごとに、前記メディアデータタイプの１つである前記一部分の前記フラグメントすべてを、隣接するペイロードにアセンブルするステップと
をさらに含むことを特徴とする請求項１８に記載の方法。
メディアファイルの前記複数のメディアデータタイプに対応するそれぞれの時系列順に、前記隣接するペイロードをアセンブルするステップと、
前記メディアファイルの前記複数のメディアデータタイプである、前記時系列順に隣接するペイロードを、同時にレンダリングするステップと
をさらに備えることを特徴とする請求項２０に記載の方法。
プロセッサで実行されると、請求項１７に記載の方法を実施するコンピュータ可読命令を備えることを特徴とするコンピュータ可読記録媒体。
プロセッサで実行されると、請求項１８に記載の方法を実施するコンピュータ可読命令を備えることを特徴とするコンピュータ可読記録媒体。
複数の単一メディアパケットを１つの混合パケットに変更するステップを備える方法であって、
各単一メディアパケットは、
暗号化されており、任意のブロックサイズを有する、１つのデータストリームのペイロードと、
前記ペイロードに対するペイロードヘッダであって、前記任意のブロックサイズに対する境界を含むペイロードヘッダと
を含み、前記混合パケットは、前記複数の単一メディアパケットに対応し、
同様のデータストリームの１つまたは複数のペイロードであって、前記複数の単一メディアパケットのそれぞれのペイロードに対応する１つまたは複数のペイロードと、
前記混合パケット中の各ペイロードに対するペイロードプロファイル形式ヘッダであって、前記複数の単一メディアパケットの前記ペイロードヘッダに対応するペイロードプロファイル形式ヘッダと
を含み、前記ペイロードプロファイル形式ヘッダは、前記混合パケット中のそれぞれのペイロードのペイロード境界を保持するためのデータを有し、前記ペイロード境界を保持するためのデータは、前記複数の単一メディアパケット中の前記ペイロードの順序を識別し、暗号化された元のデータを暗号解除によって復元することができるように、保存されることを特徴とする方法。
前記混合パケットは、
前記複数の単一メディアパケットの各々に対するパケットヘッダに対応する１つのパケットヘッダと、
構成単位と
をさらに含み、前記構成単位は、
それぞれが、対応するペイロードプロファイル形式ヘッダを有する複数のペイロードと、
１つのペイロードおよび対応するペイロードプロファイル形式ヘッダと
からなるグループから選択されることを特徴とする請求項２４に記載の方法。
各単一メディアパケットは、
基底ネットワークの物理特性と、
パケットサイズに関する管理方針と、
前記基底ネットワークの伝送帯域幅の評価と
からなるグループから選択される関数である所定のサイズより小さいことを特徴とする請求項２４に記載の方法。
前記データストリームは、音声データ、映像データ、プログラムデータ、ＪＰＥＧデータ、ＨＴＭＬデータ、およびＭＩＤＩデータからなるグループから選択されることを特徴とする請求項２４に記載の方法。
各混合メディアパケットは、拡張システム形式（ＡＳＦ）のデータストリームの一部分、ＡＳＦパケットヘッダ、および少なくとも１つのＡＳＦペイロードヘッダを含み、
各単一メディアパケットは、ＲＴＰパケットヘッダ、１つのＲＴＰペイロード形式ヘッダ、およびＲＴＰデータストリームの一部分を含むことを特徴とする請求項２４に記載の方法。
前記ペイロードプロファイル形式ヘッダは、固定長部分および可変長部分を含み、
前記可変長部分は、対応する前記ペイロードの属性を含むことを特徴とする請求項２４に記載の方法。
抽出するステップをさらに備える請求項２４に記載の方法であって、前記抽出するステップは、各ＲＴＰペイロードに対し、
前記ＲＴＰペイロードが複数の部分を含む場合、前記メディアデータタイプの１つである前記複数の部分を、隣接するペイロードにアセンブルするステップと、
前記ＲＴＰペイロードが前記メディアデータタイプの一部分を含む場合、前記メディアデータタイプの１つである前記一部分を、隣接するペイロードにアセンブルするステップと、
前記ＲＴＰペイロードが前記メディアデータタイプの１つである一部分のうち１つのフラグメントを含む場合、前記メディアデータタイプの１つである前記一部分の前記フラグメントすべてを、隣接するペイロードにアセンブルするステップと
であることを特徴とする方法。
プロセッサで実行されると、請求項２４に記載の方法を実施するコンピュータ可読命令を備えることを特徴とするコンピュータ可読記録媒体。