JP2015530041A - Ｍｐｅｇ−２トランスポートストリームにおけるｉｓｏ−ｂｍｆｆイベントボックスの搬送 - Google Patents

Abstract

ネットワークデバイスによって実施されるメディアストリーミングの方法であって、当該方法は、セグメントにおいてメッセージボックスを１又はそれ以上のパケットにカプセル化し、前記セグメントをストリーミングクライアントへ直接的又は間接的に送信することを有する。

Description

［関連出願の相互参照］
本願は、Alexander Giladiによって２０１２年８月２２日付けで出願された、“Carriage of ISO-BMFF Event Boxes in MPEG-2 TS”と題された米国特許仮出願第６１／６９２０９９号に基づく優先権を主張するものであり、この米国出願は、その全文を参照により本願に援用される。
［連邦政府による資金提供を受けた研究開発の記載］

該当なし。
［マイクロフィッシュ付録の参照］

該当なし。

メディアコンテンツの提供者又は配布者は、メディアコンテンツをストリーミングクライアントへストリーミングしてよい。ストリーミングクライアントは、テレビ受信機、ノートブックコンピュータ、及び携帯電話機のような、様々なユーザエンドデバイスの形をとることができる。メディアコンテンツは、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）及び複数のメディアセグメントを有してよく、それらは、メディアストリームにおいて搬送されてよい。ＭＰＤは、メディアコンテンツ、例えば、その様々な表現、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）アドレス、及び他の特性など、を記述する拡張可能マークアップ言語（ＸＭＬ）ファイル又はドキュメントであってよい。例えば、メディアコンテンツは、幾つかのメディアコンポーネント（例えば、オーディオ、ビデオ、及びテキスト）を有してよく、それらの夫々は、ＭＰＤにおいて特定される異なった特性を有してよい。夫々のメディアコンポーネントは、実際のメディアコンテンツの部分を含む複数のメディアセグメントを有し、セグメントは、集合的に単一のファイルにおいて又は個別的に複数のファイルにおいて格納されてよい。夫々のセグメントは、所定のバイトサイズ（例えば、１０００バイト）又はメディアコンテンツの再生時間のインターバル（例えば、２又は５秒）を有してよい。

メディアコンテンツは、ネットワーク条件、デバイス機能、及びユーザ選択のような様々な要因に適応的に基づいて、ストリーミングサーバからストリーミングクライアントへ配信されてよい。ＴＳの受信時に、ストリーミングクライアントは、ＴＳをパースしてその中から情報を取り出してよい。適応ストリーミング技術は、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）（ＤＡＳＨ）、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）、Ａｄａｐｔｉｖｅ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍｉｎｇ（ＡＴＳ）、又はＩｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓ（ＩＩＳ） Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇのような、実施又は開発されている様々な技術又は標準を含んでよい。

例えば、適応ストリーミングの１タイプとして、ＤＡＳＨは、国際標準においてＩｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ（ＩＳＯ）及びＩｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ（ＩＥＣ）によって定義されている。通例ＩＳＯ／ＩＥＣ２３００９−１として識別されている標準は、“Information technology − Dynamic adaptive streaming over HTTP (DASH) − Part1: Media presentation description and segment formats”と題されており、参照により本願に援用される。ＩＳＯ／ＩＥＣ２３００９−１の最近の改正は、ＩＳＯ−Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（ＢＭＦＦ）ボックスを用いてイベントメッセージ（ｅｍｓｇと表される。）を運ぶ方法を提供している。ｅｍｓｇボックスは、ＩＳＯ−ＢＭＦＦメディアセグメントに特有であってよく、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−２（ＭＰＥＧ−２）標準によって定義されるトランスポートストリーム（ＴＳ）のメディアセグメントにおいてはｅｍｓｇイベントの一般的対応物が存在しないことがある。結果として、適応ストリーミングは、ＭＰＥＧ−２ ＴＳサポートを備えたユーザデバイスへ都合良く配信されないことがある。

一実施形態において、本開示は、ネットワークデバイスによって実施されるメディアストリーミングの方法であって、セグメントにおいてメッセージボックスを１又はそれ以上のパケットにカプセル化し、前記セグメントをストリーミングクライアントへ直接的又は間接的に送信する方法を含む。

他の実施形態において、本開示は、メッセージボックスを１又はそれ以上のトランスポートストリーム（ＴＳ）パケットにカプセル化し、該１又はそれ以上のＴＳパケットを有するメディアセグメントを生成するよう構成されるプロセッサと、該プロセッサへ結合され、前記メディアセグメントを送信するよう構成される送信器とを有するネットワークデバイスを含む。

更なる他の実施形態において、本開示は、ストリーミングクライアントとして機能する装置であって、複数のパケットを含むＴＳを受信するよう構成され、前記パケットのうちの１又はそれ以上のパケットは、該１又はそれ以上のパケットにカプセル化されたイベントメッセージボックスを有する、受信器と、該受信器へ結合され、前記１又はそれ以上のパケットをパースすることによって前記イベントメッセージボックスを取り出すよう構成されるプロセッサとを有する装置を含む。

これら及び他の特徴は、添付の図面及び特許請求の範囲に関連して説明される以下の詳細な説明から、より明らかに理解されるであろう。

本開示のより完全な理解のために、これより、添付の図面及び詳細な説明に関連して説明される以下の簡単な説明が参照される。なお、同じ参照番号は、同じ部分を表す。

メディアストリーミングアーキテクチャの実施形態を表す。

パケットを有するメディアセグメントの実施形態を表す。

ストリーミングクライアントによるボックス抽出のための例となる擬似コードのセクションを表す。

メディアストリーミング方法の実施形態を表す。

ネットワークデバイスの実施形態を表す。

１又はそれ以上の実施形態の実例となる実施が以下で与えられるが、開示されるシステム及び／又は方法は、現在知られていようと、あるいは存在していようと、いくつでも技術を用いて実施されてよいことが、冒頭で理解されるべきである。本開示は、ここで図解及び記載されている例となる設計及び実施を含む、以下で説明される実例となる実施、図面、及び技術に決して制限されるべきではないが、添付の特許請求の範囲及びその均等の全範囲の適用範囲内で変更されてよい。

Ｓｏｃｉｅｔｙ ｏｆ Ｃａｂｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｎｇｉｎｅｅｒｓ（ＳＣＴＥ）は、イベントメッセージングをメディアストリームに加えるために使用され得る標準を定義している。標準は、“Digital Program Insertion Cueing Message for Cable”と題された、ＳＣＴＥ３５と呼ばれる。標準は、動的な広告（略してａｄ）の挿入（例えば、ａｄブレイクの境界を作ること）、アドを加える要求、及びスケジュール変更通知（例えば、プログラムの中断又は超過）に関連したメッセージの比較的複雑且つ豊かな構造を使用してよい。

しかしながら、幾つかの問題が、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）（ＤＡＳＨ）クライアントにおけるＳＣＴＥ３５の使用により生じることがある。例えば、最初に、ＤＡＳＨクライアントは、ＳＣＴＥ３５コマンドをパースすることが可能である必要があり得る。ＳＣＴＥ３５コマンドは、ＳＣＴＥ３５スタックに加えて、更にＭＰＥＧ−２ ＴＳヘッダ及びＰｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ（ＰＳＩ）をパースすることを暗示することがある。第２に、ＳＣＴＥ３５は、サポートされる必要があり得るそれ自身の条件付きアクセスモデルを有する。このことは、ＤＡＳＨクライアントにおける実施に対して複雑性を加えうる。このように、ＳＣＴＥ３５サポートは、ａｄ挿入がしばしば行われ得るケーブルヘッドエンドにおけるサーバ側に偏在し得る一方、ＳＣＴＥ３５サポートは、クライアント側に事実上存在し得ない。第３に、ＳＣＴＥ３５は所定のイベントを有し、そして、より一般化された形のイベントを有し得るように、拡張性が潜在的な問題であり得る。例えば、ＳＣＴＥ３５により定義されるイベントは、その長さを２３５バイトに制限され得る。このサイズ制限は、一般的なｅｍｓｇボックスを搬送するのに十分でないことがある。時々、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ） Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）はこの制限を越えることがある。

ＳＣＴＥ３５において新しい記述子を作成することが可能であるが、その場合、サイズ制限は４Ｋ（キロ）バイトになり得る。このサイズ制限は、幾つかの場合にとって十分であり得るが、例えば、ＭＰＤの部分がボックス内に埋め込まれる場合に、より大きいボックスを有することが依然として起こり得る。他の潜在的な問題は、新しい記述子を加えることが新しい実施を必要とすることがあることであり得る。加えて、ＭＰＥＧ−２ ＴＳ及びＩＳＯ−ＢＭＦＦの両方のメディアセグメントのためにイベントメカニズムを可能な限り同じようにすることが望ましい。ＤＡＳＨクライアント側における最低限の実施が望ましい。

本開示は、ｅｍｓｇボックスのようなメッセージボックスが１又はそれ以上のパケットにカプセル化又はパケット化され得る代替の解決法を教示する。１又はそれ以上のパケットは、メディアセグメントに含まれてよい。更に、メッセージボックスを搬送する全てのパケットは、固定のパケット識別子（ＰＩＤ）の値、例えば、適応ストリーミングのためにＭＰＥＧ−２によってリザーブされる０ｘ０００４の１３ビットの値、を有するよう構成されてよい。メッセージボックスをカプセル化する最初のパケットは、カプセル化の開始を示すパケットヘッダと、メッセージボックスのヘッダを含むパケットペイロードとを有してよい。加えて、最後のパケットは、１又はそれ以上のスタッフィングバイトにより埋められたアダプテーションフィールドを有してよい。他方で、受信されたＴＳのメディアセグメントからイベントメッセージボックスを識別し取り出すよう、ストリーミングクライアントは、１又はそれ以上のパケットのパケットヘッダをパースしてよい。ストリーミングクライアントは、必要に応じてアダプテーションフィールドをスキップしてよい。全体として、ここで教示される実施形態は、ＤＡＳＨクライアントのためのコード再利用を最大限にすることができる。

図１は、メディアストリーミングアーキテクチャ１００の実施形態を表す。メディアストリーミングアーキテクチャ１００は、メディアコンテンツをストリーミングサーバ又はプロバイダ１２０からストリーミングクライアント１１０へ配信するよう実施されてよい。例えば、ストリーミングアーキテクチャ１００は、ＤＡＳＨ、ＭＰＥＧ−２ ＴＳ、又は他のタイプのストリーミングスキームを必要としてよい。ストリーミングクライアント１１０は、ユーザデバイスのオペレーティングシステムにおいて実施されるプログラム又はアプリケーションであってよく、あるいは、それは、ウェブプラットフォームにおいてアクセスされるウェブクライアントであってよい。ストリーミングクライアント１１０は、携帯電話機、ノートブック、コンピュータ、テレビ受信機、等のようなあらゆるユーザデバイスにおいて実施されてよい。ＤＡＳＨが使用される場合は、ストリーミングクライアント１１０はＤＡＳＨクライアントであり、ストリーミングサーバはＨＴＴＰサーバ又はプロキシであってよい。

ストリーミングサーバ１２０に保存されるメディアコンテンツは、ストリーミングメディア準備ユニット１３０によって生成又は準備されてよい。メディア準備ユニット１３０は、ストリーミングサーバ１２０において又は別な場所に（例えば、コンテンツプロバイダにおいて）設置されてよい。ストリーミングサーバ１２０は、コンテンツプロバイダの部分であってよく、あるいは、コンテンツ分配ネットワーク（ＣＤＮ）におけるノードであってよい。例えば、ストリーミングサーバ１２０は、ＣＤＮにおけるエッジノードであってよく、コンテンツプロバイダからストリーミングクライアント１１０への最終ホップとして働いてよい。メディアコンテンツは、コンテンツプロバイダによって生成され、次いでＣＤＮノードへ送信されてよい。ストリーミングサーバ１２０におけるメディアコンテンツは、ＭＰＤ及び複数のセグメントを有してよい。望まれる場合は、ＭＰＤ及びセグメントは異なるサーバにおいて保存され、異なるサーバからストリーミングクライアント１１０へ送信されてよい点が留意されるべきである。加えて、ここで記載されているストリーミングサーバは、単にサーバの一例として役割を果たし、よって、ここで開示されている実施形態はあらゆる他の適切なタイプのサーバにおいても実施されてよい点が理解されるべきである。

ストリーミングクライアント１１０は、メディアコンテンツについてのストリーミングサーバ１２０への要求を送信してよい。それに応じて、ストリーミングサーバ１２０は、ＭＰＤをストリーミングクライアント１１０へ配信するために、最初にＭＰＤ配信機能１４０を使用してよい。ＭＰＤは、ＨＴＴＰ、電子メール、サムドライブ、ブロードキャスト、又はあらゆる他のトランスポートを用いて配信されてよい。ＭＰＤをパースすることによって、ストリーミングクライアント１１０は、プログラムのタイミング、メディアコンテンツの利用可能性、メディアタイプ、解像度、最小及び最大のバンド幅、マルチメディアコンポーネントの様々な符号化された代替物の存在、アクセシビリティ機能及び必要とされるデジタル権限管理（ＤＲＭ）、ネットワーク上の夫々のメディアコンポーネントの位置、並びにメディアコンテンツの他の特性のような、メディアコンテンツに関する情報を学習してよい。この情報を用いて、ストリーミングクライアント１１０は、適切な符号化表現又は代替物を選択し、メディアセグメントをフェッチすること、例えば、ＭＰＥＧ−２ ＴＳ標準に従うこと、によってメディアコンテンツをストリーミングし始めてよい。

ストリーミングサーバ１２０は、メディアセグメントをストリーミングクライアント１１０へ配信するためにセグメント配信機能を使用してよい。メディアセグメントは、少なくとも１つのメッセージボックス（例えば、ｅｍｓｇボックス）がカプセル化されている１又はそれ以上のＴＳパケットを有してよい。ストリーミングクライアント１１０は、例えば、ネットワークバンド幅の使用を最大限にするために、複数のストリーミングサーバからセグメントをダウンロードしてよい点が留意されるべきである。ストリーミングクライアント１１０は、ストリーミングサービスをストリーミングクライアント１１０のユーザへ提供するために、ダウンロードされたメディアを適切にレンダリングしてよい。ストリーミングクライアント１１０は、ＭＰＤに含まれるＵＲＬによって特定される場所に基づきセグメントを取得してよいが、時々、セグメントは、ＨＴＴＰキャッシュ１５０（例えば、ストリーミングサーバ１２０にある）において保存されてよく、それにより、ストリーミングクライアント１１０は、それらをより有効に受信することができる。

図２は、メディアセグメント２００の実施形態を表す。メディアセグメント２００は、ストリーミングプロバイダからストリーミングクライアントへ伝達される有効なＴＳであってよい。サブセグメントがメディアセグメント２００において使用される場合は、ここで記載されている実施形態は、それらがセグメントに当てはまるであろうようにサブセグメントに当てはまることができる。

セグメント２００は、複数のＴＳパケットを有してよく、パケットのうちの１又はそれ以上のパケットは、メッセージボックスをカプセル化するために使用されてよい。すなわち、１つのメッセージボックスは、１つのパケットを用いて、又は複数のパケット（連続的であってもなくてもよい。）を用いて、カプセル化されてよい。メッセージボックスをカプセル化する際に使用されるパケットの数は、メッセージボックスのサイズのような要因に依存してよい。メッセージがボックスの単位で運ばれるとして、メッセージは、以降、メッセージボックスとも呼ばれることがある。一例として、図２に示されるパケット２１０、２２０及び２３０は、イベントメッセージ（ｅｍｓｇ）ボックス２４０のカプセル化において使用される。ｅｍｓｇは、ボックスのカプセル化又はパケット化の原理を明示するために、例となるメッセージとして使用されるが、当業者は、ここで開示されている原理があらゆる他の適切なタイプのイベントメッセージボックス又は一般的なメッセージボックスに当てはまると認識するであろう。

メッセージボックス（例えば、ＩＳＯ−ＢＭＦＦボックス）は、ボックスフォーマット（例えば、ＤＡＳＨによって定義される。）において、イベントメッセージ、ＥｖｅｎｔＭｅｓｓａｇｅＢｏｘ（ｅｍｓｇ）のようなメッセージを搬送してよい。ＤＡＳＨ標準において、例えば、ｅｍｓｇボックスは、メディア提示時間に関連したジェネリックイベントのためのシグナリングを提供してよい。ｅｍｓｇボックスのセマンティックは、ＭＰＤイベントのためのそれらに従ってよく、ｅｍｓｇイベントはまた、ＤＡＳＨ動作に特有のシグナリングを提供してよい。メディアセグメントは、ＩＳＯ ＢＭＦＦにおいてカプセル化される場合に、１又はそれ以上のパケット化されたｅｍｓｇボックスを含んでよい。存在する場合は、あらゆるｅｍｓｇボックスは、望まれる場合に同じくカプセル化され得るあらゆる‘ｍｏｏｆ’ボックスの前に置かれてよい。メッセージボックスは、ストリーミングクライアントにそれがＭＰＤ（ＤＡＳＨの改正において標準化される。）をリフレッシュすべきことを通知すること、ＭＰＤに適用すべきパッチを提供すること、及び／又は来るａｄに関する情報（例えば、ＳＣＴＥ３５、Ｉｎｔｅｒａｃｔｉｖｅ Ａｄｖｅｒｔｉｓｉｎｇ Ｂｕｒｅａｕ（ＩＡＢ） Ｖｉｄｅｏ Ａｄ Ｓｅｒｖｉｎｇ Ｔｅｍｐｌａｔｅ（ＶＡＳＴ）、及び／又はＩＡＢ Ｖｉｄｅｏ Ｍｕｌｔｉｐｌｅ Ａｄ Ｐｌａｙｌｉｓｔ（ＶＭＡＰ））を提供することといった様々な目的のために使用されてよい。イベントメッセージボックスの例となる実施形態に関する更なる詳細は、ＤＡＳＨ標準の改正のセクション５．１０．３．３において見出され得る。改正書類は、“Information technology − Dynamic adaptive streaming over HTTP (DASH) − Part 1: Media presentation description and segment formats, AMENDMENT 1”と題されたＩＳＯ／ＩＥＣ２３００９−１：２０１２／Ａｍｄ．１：２０１３（Ｅ）として識別され、参照により本願に援用される。

ＴＳパケット２１０、２２０及び２３０の夫々は、例えば、１８８バイトの固定長さを有してよい。１８８バイト長は、長さＡｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ（ＡＴＭ）セルと大いに互換性があり、有効且つロバストなエラー訂正符号化へのその適用性のために一般にＭＰＥＧ−２ ＴＳセグメントにおいて使用されている。例となるパケットとしてのパケット２１０は、パケットヘッダ２１１を有してよい。パケットヘッダは、同期フィールド２１２、トランスポートエラーインジケータ２１３、ペイロード・ユニット開始インジケータ２１４（payload_unit_start_indicatorと表される。）、トランスポート優先フィールド２１５、ＰＩＤ２１６、トランスポート・スクランブル制御フィールド２１７、アダプテーションフィールド制御フラグ（adaptation_field_controlと表される。）２１８、及び連続性インデックス２１９を含む様々なフィールドを有してよい。パケットヘッダ及びそのフィールドは、あらゆる適切なサイズを有するよう構成されてよい。実施形態において、パケットヘッダ２１１は、８ビットの同期フィールド２１２、１ビットのトランスポートエラーインジケータ２１３、１ビットのペイロード・ユニット開始インジケータ２１４、１ビットのトランスポート優先フィールド２１５、１３ビットのＰＩＤ２１６、２ビットのトランスポート・スクランブル制御フィールド２１７、２ビットのアダプテーションフィールド制御フラグ２１８、及び４ビットの連続性インデックス２１９を持って、４バイト（すなわち、３２ビット）の固定長さを有する。

パケットヘッダにおけるアダプテーションフィールド制御フラグは、ヘッダに続くアダプテーションフィールド、若しくはペイロード、又はその両方の存在を示してよい。例えば、adaptation_field_control＝‘０１’は、ペイロードがヘッダに続くことを示してよく、adaptation_field_control＝‘１０’は、アダプテーションフィールドがヘッダに続くこと示してよく、そして、adaptation_field_control＝‘１１’は、アダプテーションフィールド及びペイロードの両方がヘッダに続くことを示してよい。

パケットヘッダにおけるＰＩＤは、パケットの異なるタイプを識別してよい。例えば、約８０００タイプが、１３ビットのフィールドを用いて識別されてよい。０ｘ０００４（０ｘは１６進値を示す。）のＰＩＤ値を有するＴＳパケットが、適応ストリーミングメッセージのために特にリザーブされ得るとして、実施形態に従って、ｅｍｓｇボックスの少なくとも一部をカプセル化する夫々のパケットは、０ｘ０００４のＰＩＤを与えられてよい。加えて、パケットヘッダにおけるペイロード・ユニット開始インジケータは、ペイロードユニット、例えば、単一のファイルレベルのメッセージボックス、の開始を示してよい。トランスポート・スクランブル制御フィールドは、ペイロードセクションがスクランブルをかけられているかどうかを示してよく、連続性インデックスは、パケットの不連続性を検出するために使用されてよい。

メディアセグメントはＭＰＥＧ−２ ＴＳであってよく、ＴＳパケットにカプセル化されている１又はそれ以上のイベントメッセージ（‘ｅｍｓｇ’）ボックスを含んでよい。実施形態において、ｅｍｓｇボックス２４０を搬送する１又はそれ以上のＴＳパケットは、０ｘ０００４のリザーブされた又は固定のＰＩＤ値を使用してよい。ｅｍｓｇボックスの開始（ボックスヘッダ）を搬送するＴＳパケットは、オンされている（例えば、‘１’に設定されている）payload_unit_start_indicatorを有してよい。パケットペイロードは、ｅｍｓｇボックス２４０の先頭から始まってよい。Box.typeと表される完全ボックスタイプフィールド２４２は、この最初のパケットに存在する必要があり得、そして、ペイロードサイズは、少なくとも４バイトであってよい。ボックスタイプフィールド２４２は、ｅｍｓｇボックス２４０のヘッダの部分であってよく、ボックスがｅｍｓｇボックスであることを示すために使用されてよい。セクションも、パケット化されたエレメンタリストリーム（ＰＥＳ）パケットも、メッセージボックスをカプセル化すること又は搬送することにおいて使用され得ない点に留意されたい。

パケットペイロードは、メッセージボックスの先頭（ボックスヘッダ）から、又はボックスヘッダが後に続く固定Ｎバイトのヘッダから、始まってよい。Ｎバイトのヘッダは、追加の情報（例えば、ボックスのインテグリティを確かめるためのチェックサム又は暗号ハッシュ）を提供し、あるいは、ボックスのエンドに続くそのような情報の利用可能性を示してよい。いずれのヘッダも最初のパケットに存在してよく、よって、アダプテーションフィールドのサイズは、多くても１８２−Ｎ−８バイトである。ボックスデータの連続は、同じＰＩＤを有するＴＳパケットに続いて占有してよい。自身にカプセル化されたメッセージボックスを有するパケットは、パケットが同じＰＩＤを含むとして、例えば、ストリーミングクライアントによって、検出又は識別されてよい。ボックスのエンドを搬送する最後のパケットは、アダプテーションフィールドのスタッフィングバイトを用いて埋め込まれてよい。スタッフィングバイトは、ランダムな又は予めセットされた値を有してよい（例えば、スタッフィングバイトは、２５５に等しい固定８ビット値として設定され得る。）。スタッフィングバイトは、エンコーダ、又はマルチプレクサ、パケッジャー、等のような何らかのネットワーク内デバイスによって挿入され、次いでデコーダによって廃棄されてよい。追加の“フッター”は、ボックスのエンドの後に置かれてよい。０ｘ０００４のＰＩＤ値を有するいずれかのパケットについて、transport_scrambling_controlフィールドの値は、スクランブルがペイロードセクションにおいて使用されていないことを示すよう‘００’に設定されてよい。

セグメントは１又はそれ以上の完全なメッセージボックス（例えば、ｅｍｓｇボックス２４０の全体）を含んでよい点に留意されたい。ストリーミングクライアントは、メッセージボックスが完全であるかどうかを、ボックスのサイズを有するボックスのヘッダを調べることによって検出してよい。更に、@bitstreamSwitchingのフィールドが設定され、サブセグメントが使用される場合は、サブセグメントは１又はそれ以上の完全なｅｍｓｇボックスを含んでよい。ビットストリームスイッチングセグメントは、存在する場合に、セグメント割り当てられる表現へと切り替わる必須のデータを含んでよい。例えば、ビットストリームスイッチングセグメントにおいて“真”に設定されている@bitstreamSwitchingのフィールドは、セグメントの連なりが有効なＴＳ（例えば、ＭＰＥＧ−２ ＴＳ）であることを示してよい。

教示されるようにＭＰＥＧ−２ ＴＳパケットにおいてイベントボックスを搬送する解決法は、一般的な解決法であり得る。ＭＰＥＧ−２システム標準によって課されるボックスサイズに関する制限は存在しないので、あらゆるボックス長さが使用可能であり、一方、ボックスサイズはボックスヘッダにおいて与えられてよい。加えて、ｅｍｓｇボックスのカプセル化は、直接的なＭＰＥＧ−２ ＴＳトランスポートが必要であると考えられる何らかの他のボックスのために、取るに足りない複雑性を伴って拡張されてよい。加えて、あらゆるＩＳＯ−ＢＭＦＦボックス又は他のタイプのメッセージボックスは、ここで記載されている実施形態とともに使用されてよい点が理解されるべきである。加えて、ボックスシンタックスを用いる如何なるデータも適応され得る。

ここで記載されている実施形態の他の利点は、ｅｍｓｇボックスの導出プロシージャを使用し、次いでｅｍｓｇを何らかのセグメントフォーマットに埋め込むことが可能であるとして、ＩＳＯ−ＢＭＦＦと共通であり得る。加えて、本開示は、ＩＳＯ−ＢＭＦＦアダプテーションセット（AdaptationSetと表される。）要素と同じ周期におけるＴＳに基づくイベント専用のアダプテーションセットの使用を可能にすることができる。例えば、本開示は、ａｄに関連したメタデータをＳＣＴＥ３５を越えてパスすることを可能にし、且つ、ＴＳに基づくクライアントのためのＭＰＤ終了のインジケーションを可能にすることができる。ＤＡＳＨを越えて、ここで開示されている実施形態は、メディアがＭＰＥＧ−２ ＴＳパケットにカプセル化されるあらゆるシステムにおいて使用されてよい。

ストリーミングプロバイダ又はサーバは、メディアセグメントを有するＴＳをストリーミングクライアントへ直接的又は間接的に送信してよい。１つのメディアセグメントにおいて、１又はそれ以上のパケットは、自身にカプセル化されている少なくとも１つのメッセージボックスを含んでよい。ストリーミングクライアントの側では、ＴＳが受信されてよく、メッセージボックスはパーシングを介してメディアセグメントから取り出されてよい。図３は、ストリーミングクライアントによるボックス抽出のための例となる擬似コードのセクションを表す。図３における擬似コードは、当業者が、メッセージボックスの開始より前のパケットと、スタッフィングバイトとを飛ばし読みし、それにより完全なメッセージボックスを生成することを可能にしてよい。ストリーミングクライアントは、完全なメッセージボックスがＴＳパケットにおいてカプセル化されているかどうかを、パケットのＰＩＤをパースすることによって検出してよい。１又はそれ以上のパケットが。０ｘ０００４のリザーブされたＰＩＤ値を有する場合は、それは、少なくとも１つのメッセージボックスがカプセル化されていることを示してよい。パケットヘッダを検出することに関わる計算複雑性は、メディアセグメントが完全に暗号化されない限り些末であり得る。

また、イベント抽出を実行するよう、完全なボックスのみがセグメント内に存在し得る点に留意されたい。論理アンド（ＡＮＤ）演算は、パケット化されたｅｍｓｇボックスを見つけるために擬似コードにおいて使用される。アダプテーションフィールド制御フラグは異なる値（例えば、‘０１’、‘１０’、又は‘１１’）に設定され得るので、ストリーミングクライアントは、必要に応じてアダプテーションフィールドをスキップしてよい点に留意されたい。

タイミングデータは、クライアント側でのイベント提示時間の計算を簡単にするために必要とされることがある。実施形態において、ボックスヘッダに含まれ、emsg.presentation_time_deltaと表されるフィールドは、セグメントの最先の提示時間と相対的であってよい。ＤＡＳＨクライアントがセグメントの最先の提示時間を知り得る一方、ＭＰＥＧ−２ ＴＳはこの情報を欠くことがあり、よって、ヘッダにおいて任意のpts_offsetフィールドを有することは、emsg.presentation_time_deltaを知らないユーザ設備内でイベントを処理するのを支援することができる。

図４は、ストリーミングサーバ（例えば、ストリーミングサーバ１２０）によって実施され得るメディアストリーミング方法４００の実施形態を表す。方法４００は、ステップ４１０において始まる。ステップ４１０で、ストリーミングサーバは、メッセージボックスを１又はそれ以上のパケットにカプセル化してよい。実施形態において、メッセージボックスは、ＤＡＳＨに特有のｅｍｓｇボックスであり、パケットは、ＭＰＥＧ−２に特有である。カプセル化の結果として、メッセージ（例えば、イベントメッセージ）ボックスはパケット化され、１又はそれ以上のパケットに含まれる。ステップ４２０で、方法４００は、１又はそれ以上のパケットを有するセグメント（例えば、メディアセグメント）を生成してよい。ステップ４３０で、方法は、セグメントをストリーミングクライアントへ直接的又は間接的に送信してよく、このとき、セグメントは、メッセージボックスがカプセル化されている１又はそれ以上のパケットを有する。

方法４００の変形物が存在し、ここで開示されている原理によって包含される点が理解されるべきである。例えば、ストリーミングサーバが、予め用意されたトランスポートストリームを受信するＣＤＮエッジノードである場合は、メッセージボックスのカプセル化及びセグメントの生成は、異なるデバイスによって、例えば、コンテンツ準備の間にコンテンツプロバイダによって、行われてよい。この場合に、方法４００におけるステップの一部しかストリーミングサーバでは実施されない。他の例に関し、セグメントのトランスコーディング、暗号化、復号化のような他のステップが、メディアストリーミングサービスを促進するために、適切な場合はいつでも、方法４００に組み入れられてよい。

上述されたスキームは、ネットワークコンポーネント又はノード、例えば、自身に置かれている必然的なワークロードを処理するために十分な処理能力、メモリリソース、及びネットワークスループット能力を備えたネットワークノードにおいて、実施されてよい。図５は、メディアストリーミング方法４００のような、ここで開示されている方法／スキームの１又はそれ以上の実施形態を実施するのに適したネットワークノード又はデバイス５００の実施形態を表す。更に、ネットワークデバイス５００は、ストリーミングクライアント１１０又はストリーミングサーバ１２０のような、ここで記載されている装置のいずれかを実施するよう構成されてよい。

ネットワークデバイス５００は、二次記憶装置５０４を含むメモリデバイス、読出専用メモリ（ＲＯＭ）５０６、ランダムアクセスメモリ（ＲＡＭ）５０８、入力／出力（Ｉ／Ｏ）デバイス５１０、及び送信器／受信器５１２と通信するプロセッサ５０２を有する。単一のプロセッサとして表されているが、プロセッサ５０２はそのように制限されず、複数のプロセッサを有してよい。プロセッサ５０２は、１又はそれ以上の中央演算処理装置（ＣＰＵ）チップ、コア（例えば、マルチコアプロセッサ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、及び／又はデジタル信号プロセッサ（ＤＳＰ）として実施されてよく、且つ／あるいは、１又はそれ以上のＡＳＩＣの部分であってよい。プロセッサ５０２は、メディアストリーミング方法４００を含む、ここで記載されているスキームのいずれかを実施するよう構成されてよい。プロセッサ５０２は、ハードウェア又はハードウェア及びソフトウェアの組み合わせを用いて実施されてよい。

二次記憶装置５０４は、通常は、１又はそれ以上のディスクドライブ又はテープドライブから成り、データの不揮発性記憶のために、且つ、ＲＡＭ５０８が全ての作業データを保持するのに十分に大きくない場合はオーバーフローデータ記憶デバイスとして、使用される。二次記憶装置５０４は、ＲＡＭ５０８にロードされるプログラムを、そのようなプログラムが実行のために選択される場合に記憶するために使用されてよい。ＲＯＭ５０６は、プログラム実行中に読み出される命令及びおそらくデータを記憶するために使用される。ＲＯＭ５０６は、二次記憶装置５０４のより大きいメモリ容量と比較して通常は小さいメモリ容量を有する不揮発性メモリデバイスである。ＲＡＭ５０８は、揮発性のデータを記憶するために、且つ、おそらく命令を記憶するために、使用される。ＲＯＭ５０６及びＲＡＭ５０８の両方へのアクセスは、通常は、二次記憶装置５０４へよりも高速である。

送信器／受信器５１２は、ネットワークデバイス５００の出力及び／又は入力デバイスとして働いてよい。例えば、送信器／受信器５１２が送信器として動作している場合は、それはネットワークデバイス５００からデータを送出してよい。送信器／受信器５１２が受信器として動作している場合は、それはネットワークデバイス５００にデータを読み込んでよい。送信器／受信器５１２は、モデム、モデムバンク、イーサネット（登録商標）カード、ユニバーサルシリアルバス（ＵＳＢ）インターフェースカード、シリアルインターフェース、トークンリングカード、光ファイバー分散データインターフェース（ＦＤＤＩ）カード、無線ローカルエリアネットワーク（ＷＬＡＮ）カード、無線トランシーバカード、例えば、符号分割多重アクセス（ＣＤＭＡ）、グローバルシステム・フォー・モバイルコミュニケーションズ（ＧＳＭ（登録商標））、ロングタームエボリューション（ＬＴＥ）、マイクロ波アクセスのための世界的相互運用（ＷｉＭＡＸ）、及び／又は他のエアインターフェースプロトコルラジオトランシーバカード、並びに他のよく知られているネットワークデバイスの形をとってよい。送信器／受信器５１２は、プロセッサ５０２がインターネット又は１以上のイントラネットと通信することを可能にしてよい。Ｉ／Ｏデバイス５１０は、ビデオモニタ、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、又はビデオを表示するための他のタイプのビデオディスプレイを有してよく、ビデオを捕捉するためのビデオ記録デバイスを更に有してよい。Ｉ／Ｏデバイス５１０は、１又はそれ以上のキーボード、マウス、若しくはトラックボール、又は他のよく知られている入力デバイスを更に有してよい。

実行可能な命令をネットワークデバイス５００上にプログラミング及び／又はロードすることによって、プロセッサ５０２、二次記憶装置５０４、ＲＡＭ５０８、及びＲＯＭ５０６のうちの少なくとも１つは変更されて、ネットワークデバイス５００を部分的に特定の機械又は装置（例えば、本開示のよって教示される新規の機能を備えたストリーミングサーバ又はクライアント）に変形させる点が理解される。実行可能な命令は、二次記憶装置５０４、ＲＯＭ５０６、及び／又はＲＡＭ５０８に記憶され、実行のためにプロセッサ５０２にロードされてよい。実行可能なソフトウェアをコンピュータにロードすることによって実施され得る機能が、よく知られている設計規則によってハードウェア実施へ変換され得ることは、電気工学及びソフトウェア工学において基本的なことである。ソフトウェア又はハードウェアのいずれにおいて概念を実施するかという決断は、通常は、ソフトウェア領域からハードウェア領域へ移行することに関わるいずれの問題よりもむしろ、設計の安定性及び製造されるべきユニットの数の考察次第である。一般に、頻繁な変更に今なお影響を受けやすい設計は、ハードウェア実施のリスピンがソフトウェア設計のリスピンよりも高価であるために、ソフトウェアにおいて実施されることが好まれ得る。一般に、大容量において製造される安定した設計は、大規模なプロダクションランに関しハードウェア実施がソフトウェア実施よりも安価であり得るために、ハードウェアにおいて、例えば、特定用途向け集積回路（ＡＳＩＣ）において実施されることが好まれ得る。しばしば、設計は、ソフトウェアの形で開発及び試験され、後に、よく知られている設計規則によって、ソフトウェアの命令をハードウェアに組み込む特定用途向け集積回路において等価なハードウェア実施へ変形されてよい。新しいＡＳＩＣによって制御される機械が特定の機械又は装置であるのと同じようにして、同様に、実行可能な命令によりプログラミング及び／又はロードされたコンピュータは、特定の機械又は装置と見なされてよい。

少なくとも１つの実施形態が開示されており、当業者によって為されるその実施形態及び／又はその実施形態の特徴の変形、結合、及び／又は改良は、本開示の適用範囲内である。実施形態の特徴を結合、一体化、及び／又は削除することをもたらす代替の実施形態も本開示の適用範囲内である。数値範囲又は制限が明示的に述べられる場合に、そのような明示された範囲又は制限は、明示的に述べられている範囲又は制限内にある同様の大きさの逐次的な範囲又は制限を含むと理解され得る（例えば、約１から約１０までは２、３、４等を含み、０．１０よりも大きいとは０．１１、０．１２、０．１３等を含む。）。例えば、下限Ｒ_ｌ及び上限Ｒ_ｕを有する数値範囲が開示されているときはいつでも、その範囲内にある如何なる数も具体的に開示されている。特に、その範囲内にある次の数が具体的に開示されている：Ｒ＝Ｒ_ｌ＋ｋ×（Ｒ_ｕ−Ｒ_ｌ）。ここで、ｋは、１パーセントのインクリメントにより１パーセントから１００パーセントの範囲で起こる変数である。すなわち、ｋは１パーセント、２パーセント、３パーセント、４パーセント、５パーセント、・・・、５０パーセント、５１パーセント、５２パーセント、・・・、９５パーセント、９６パーセント、９７パーセント、９８パーセント、９９パーセント、又は１００パーセントである。加えて、先に定義されたように２つのＲの数字によって定義される如何なる数値範囲も更に、具体的に開示されている。語“約”の使用は、別なふうに述べられない限り、それに続く数字の±１０パーセントを意味する。請求項のいずれかの要素に対する語“任意に”の使用は、その要素が必要とされ、あるいは代替的に、その要素が必要とされないことを意味し、両方の選択肢がその請求項の適用範囲内にある。有する、含む、及び備えるといったより広い用語の使用は、〜から成る、本質的に〜から成る、及び実質的に〜から構成されるといったより狭い用語へのサポートを提供すると理解されてよい。然るに、保護の適用範囲は、先に提示された記載によって制限されず、続く特許請求の範囲によって定義される。特許請求の範囲の適用範囲は、特許請求の範囲の対象の全ての同等物を含む。１つ１つの請求項は、更なる開示として明細書に組み込まれ、特許請求の範囲は、本開示の実施形態である。本開示における参考文献の議論は、それが先行技術、特に、本願の優先日より後の公開日を有するあらゆる参考文献であると認めるわけではない。本開示で引用されている全ての特許、特許出願及び出版物の開示は、それらが例となる、手続き上の、又は他の詳細の補足を本開示に適用する限りにおいて、参照により本願に援用される。

幾つかの実施形態が本開示において提供されているが、開示されているシステム及び方法は、本開示の趣旨又は適用範囲から逸脱することなしに、多くの他の具体的な形態において具現されてよい点が理解され得る。目下の例は、限定ではなく実例として解されるべきであり、意図は、ここで与えられている詳細に制限されない。例えば、様々な要素又はコンポーネントは、他のシステムにおいて結合又は一体化されてよく、あるいは、特定の特徴は、省略されるか、又は実施されなくてよい。

加えて、個別的又は別々として様々な実施形態において記載及び図示されている技術、システム、サブシステム、及び方法は、本開示の適用範囲から逸脱することなしに、他のシステム、モジュール、技術、又は方法と結合又は一体化されてよい。互いと結合又は直接に結合若しくは通信するよう図示又は議論されている他の項目は、電気的であろうと、機械的であろうと、又は別なやり方であろうと、何らかのインターフェース、デバイス、又は中間コンポーネントを通じて間接的に結合又は通信してよい。変更、置換、又は代替の他の例は、当業者によって確認可能であり、ここで開示されている趣旨及び適用範囲から逸脱することなしに為されてよい。

図１は、メディアストリーミングアーキテクチャ１００の実施形態を表す。メディアストリーミングアーキテクチャ１００は、メディアコンテンツをストリーミングサーバ又はプロバイダ１２０からストリーミングクライアント１１０へ配信するよう実施されてよい。例えば、ストリーミングアーキテクチャ１００は、ＤＡＳＨ、ＭＰＥＧ−２ ＴＳ、又は他のタイプのストリーミングスキームを必要としてよい。ストリーミングクライアント１１０は、ユーザデバイスのオペレーティングシステムにおいて実施されるプログラム又はアプリケーションであってよく、あるいは、それは、ウェブプラットフォームにおいてアクセスされるウェブクライアントであってよい。ストリーミングクライアント１１０は、携帯電話機、ノートブック、コンピュータ、テレビ受信機、等のようなあらゆるユーザデバイスにおいて実施されてよい。ＤＡＳＨが使用される場合は、ストリーミングクライアント１１０はＤＡＳＨクライアントであり、ストリーミングサーバ１２０はＨＴＴＰサーバ又はプロキシであってよい。

図４は、ストリーミングサーバ（例えば、ストリーミングサーバ１２０）によって実施され得るメディアストリーミング方法４００の実施形態を表す。方法４００は、ステップ４１０において始まる。ステップ４１０で、ストリーミングサーバは、メッセージボックスを１又はそれ以上のパケットにカプセル化してよい。実施形態において、メッセージボックスは、ＤＡＳＨに特有のｅｍｓｇボックスであり、パケットは、ＭＰＥＧ−２に特有である。カプセル化の結果として、メッセージ（例えば、イベントメッセージ）ボックスはパケット化され、１又はそれ以上のパケットに含まれる。ステップ４２０で、方法４００は、１又はそれ以上のパケットを有するセグメント（例えば、メディアセグメント）を生成してよい。ステップ４３０で、方法４００は、セグメントをストリーミングクライアントへ直接的又は間接的に送信してよく、このとき、セグメントは、メッセージボックスがカプセル化されている１又はそれ以上のパケットを有する。

Claims (20)

1. ネットワークデバイスによって実施されるメディアストリーミングの方法であって、
   セグメントにおいてメッセージボックスを１又はそれ以上のパケットにカプセル化し、
   前記セグメントをストリーミングクライアントへ直接的又は間接的に送信する
   方法。
2. 前記メッセージボックスは、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）（ＤＡＳＨ）に特有のイベントメッセージを搬送し、
   前記イベントメッセージは、前記セグメントのメディア提示時間に関連したジェネリックイベントためのシグナリングを提供し、
   前記パケットは、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−２（ＭＥＰＧ−２）トランスポートストリーム（ＴＳ）パケットである、
   請求項１に記載の方法。
3. 前記１又はそれ以上のパケットの全ては、同じパケット識別子（ＰＩＤ）を有し、
   前記１又はそれ以上のパケットの夫々は、オフされるトランスポート・スクランブル制御フィールドを有する、
   請求項１に記載の方法。
4. 前記ＰＩＤは、０ｘ０００４の１３ビットのリザーブされた値を有し、
   前記トランスポート・スクランブル制御フィールドは、ｔｒａｎｓｐｏｒｔ＿ｓｃｒａｍｂｌｉｎｇ＿ｃｏｎｔｒｏｌと表され、００の２ビットの値を有する、
   請求項３に記載の方法。
5. 前記１又はそれ以上のパケットにおける最初のパケットは、パケットヘッダ及びパケットペイロードを有し、
   前記パケットヘッダは、オンされるペイロード・ユニット開始インジケータを有し、
   前記ペイロード・ユニット開始インジケータは、前記メッセージボックスが前記最初のパケットにおいて始まることを示し、
   前記パケットペイロードは、前記メッセージボックスのボックスヘッダを有する、
   請求項１に記載の方法。
6. 前記ペイロード・ユニット開始インジケータは、‘１’の１ビットの値を有し、
   前記ボックスヘッダは、前記メッセージボックスのタイプフィールドを有し、
   前記パケットペイロードのサイズは、少なくとも４バイトである、
   請求項５に記載の方法。
7. 前記メッセージボックスのエンドを搬送する前記１又はそれ以上のパケットにおける最後のパケットは、スタッフィングバイトにより埋められたアダプテーションフィールドを有し、
   前記アダプテーションフィールドは、前記メッセージボックスの前記エンドを示し、
   前記スタッフィングバイトの埋め込みは、前記最後のパケットのパケットヘッダに含まれるアダプテーションフィールド制御フラグに基づく、
   請求項１に記載の方法。
8. 前記セグメントは、ビットストリームスイッチングセグメントである、
   請求項１に記載の方法。
9. 前記１又はそれ以上のパケットの夫々は、サイズが１８８バイトであり、４バイトの固定サイズを有するパケットヘッダを含み、
   夫々のパケットヘッダは、８ビットの同期フィールド、１ビットのトランスポートエラーインジケータ、１ビットのペイロード・ユニット開始インジケータ、１ビットのトランスポート優先フィールド、１３ビットのパケット識別子（ＰＩＤ）、２ビットのトランスポート・スクランブル制御フィールド、２ビットのアダプテーションフィールド制御フラグ、及び４ビットの連続性インデックスを有する、
   請求項１に記載の方法。
10. メッセージボックスを少なくとも１つのトランスポートストリーム（ＴＳ）パケットにカプセル化し、該少なくとも１つのＴＳパケットを有するメディアセグメントを生成するよう構成されるプロセッサと、
    前記プロセッサへ結合され、前記メディアセグメントを送信するよう構成される送信器と
    を有するネットワークデバイス。
11. 前記メッセージボックスは、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）（ＤＡＳＨ）に特有のイベントメッセージを搬送し、
    前記メディアセグメントは、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−２（ＭＥＰＧ−２）標準によって定義される、
    請求項１１に記載のネットワークデバイス。
12. 前記１又はそれ以上のＴＳパケットの全ては、同じパケット識別子（ＰＩＤ）を有し、
    前記１又はそれ以上のＴＳパケットの夫々は、オフされるトランスポート・スクランブル制御フィールドを有する、
    請求項１０に記載のネットワークデバイス。
13. 前記ＰＩＤは、０ｘ０００４の１３ビットのリザーブされた値を有し、
    前記トランスポート・スクランブル制御フィールドは、ｔｒａｎｓｐｏｒｔ＿ｓｃｒａｍｂｌｉｎｇ＿ｃｏｎｔｒｏｌと表され、００の２ビットの値を有する、
    請求項１２に記載のネットワークデバイス。
14. 前記１又はそれ以上のＴＳパケットにおける最初のＴＳパケットは、パケットヘッダ及びパケットペイロードを有し、
    前記パケットヘッダは、オンされるペイロード・ユニット開始インジケータを有し、
    前記パケットペイロードは、前記メッセージボックスのボックスヘッダを有する、
    請求項１０に記載のネットワークデバイス。
15. 前記メッセージボックスのエンドを搬送する前記１又はそれ以上のＴＳパケットにおける最後のＴＳパケットは、スタッフィングバイトにより埋められたアダプテーションフィールドを有し、
    前記スタッフィングバイトの埋め込みは、前記最後のＴＳパケットのパケットヘッダに含まれるアダプテーションフィールド制御フラグに基づく、
    請求項１０に記載のネットワークデバイス。
16. ストリーミングクライアントとして機能する装置であって、
    複数のパケットを含むトランスポートストリーム（ＴＳ）を受信するよう構成され、前記パケットのうちの１又はそれ以上のパケットは、該１又はそれ以上のパケットにカプセル化されたイベントメッセージボックスを有する、受信器と、
    前記受信器へ結合され、前記１又はそれ以上のパケットをパースすることによって前記１又はそれ以上のパケットから前記イベントメッセージボックスを取り出すよう構成されるプロセッサと
    を有する装置。
17. 前記１又はそれ以上のパケットの全ては、０ｘ０００４の固定値を有する同じパケット識別子（ＰＩＤ）を有する、
    請求項１６に記載の装置。
18. 前記１又はそれ以上のパケットにおける最初のパケットは、パケットヘッダ及びパケットペイロードを有し、
    前記パケットヘッダは、オンされるペイロード・ユニット開始インジケータを有し、
    前記パケットペイロードは、前記イベントメッセージボックスのヘッダを有する、
    請求項１７に記載の装置。
19. 前記イベントメッセージボックスは、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）（ＤＡＳＨ）標準によって定義され、
    前記受信されたＴＳは、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−２（ＭＥＰＧ−２）ＴＳである、
    請求項１６に記載の装置。
20. 前記１又はそれ以上のパケットをパースすることは、
    前記イベントメッセージボックスが前記１又はそれ以上のパケットにカプセル化されていると決定するよう、前記１又はそれ以上のパケットの夫々において同じパケット識別子（ＰＩＤ）を識別することと、
    前記１又はそれ以上のパケットにおける最後のパケットが、スタッフィングバイトにより埋められたアダプテーションフィールドを有すると決定することと
    を有する、
    請求項１６に記載の装置。
    

Images