(57)【特許請求の範囲】
【請求項１】
ストリーミングビデオを復号し得るビデオデコーダ用のデコーダバッファ装置であって、ストリーミングビデオ送信機から前記ストリーミングビデオを含むデータパケットを受信し、前記データパケットを複数のアクセス単位に蓄積し、前記アクセス単位の各々が前記ストリーミングビデオ内の選択フレームと関連する少なくとも１つのデータパケットを保持し得るデコーダバッファ装置において、前記デコーダバッファ装置は、
前記ビデオデコーダによりすぐには必要とされないデータパケットを蓄積し得る少なくとも１つのアクセス単位を具える第1バッファ領域と、
前記ビデオデコーダにより最もすぐに必要とされるデータパケットを蓄積し得る少なくとも一つのアクセス単位を具える再送信領域と、
前記再送信領域内の欠落データパケットを検出するモニタ部と、
前記欠落データパケットの検出に応答して、前記ストリーミングビデオ送信機に前記欠落パケットを再送信するよう要求するコントローラ部と、
を具えることを特徴とするデコーダバッファ装置。
【請求項２】
前記データパケットの少なくとも一つを前記第1バッファ領域に前記デコーダバッファの始動遅延に等しい期間に亘り蓄積することを特徴とする請求項１記載のデコーダバッファ装置。
【請求項３】
前記データパケットを最初に前記第1バッファ領域に蓄積し、前記再送信領域へシフトさせることを特徴とする請求項１記載のデコーダバッファ装置。
【請求項４】
前記第1バッファ領域が前記再送信領域から分離していることを特徴とする請求項１記載のデコーダバッファ装置。
【請求項５】
前記第1バッファ領域が前記再送信領域の少なくとも一部分とオーバラップしていることを特徴とする請求項１記載のデコーダバッファ装置。
【請求項６】
前記第1バッファ領域が前記再送信領域の全部とオーバラップしていることを特徴とする請求項１記載のデコーダバッファ装置。
【請求項７】
前記第１バッファ領域が前記再送信領域から第２バッファ領域により分離され、前記第２バッファ領域において遅いデータパケットを前記遅いデータパケットの到達予想時間に対し遅らせるが、前記遅いデータパケットの再送信を必要とするほど十分には遅らせないことを特徴とする請求項１記載のデコーダバッファ装置。
【請求項８】
符号化ストリーミングデータを受信し得る受信機であって、
1)前記符号化ストリーミングデータと関連するストリーミングビデオデータを表示すること、及び2)前記符号化ストリーミングデータと関連するストリーミングオーディオデータを可聴再生すること、の少なくとも一つが可能な装置と、
請求項１〜７のいずれかに記載のデコーダバッファ装置と、
を具えることを特徴とする受信機。
【請求項９】
ストリーミングビデオを復号し得るビデオデコーダにおいてストリーミングビデオをバッファリングする方法であって、
ストリーミングビデオ送信機から前記ストリーミングビデオを含むデータパケットを受信し、前記データパケットをデコーダバッファ装置内の複数のアクセス単位に蓄積し、前記アクセス単位の各々が前記ストリーミングビデオ内の選択フレームと関連する少なくとも１つのデータパケットを保持するステップと、
前記ビデオデコーダによりすぐには必要とされないデータパケットを前記デコーダバッファ装置の少なくとも一つのアクセス単位を具える第1バッファ領域に蓄積するステップと、
前記ビデオデコーダにより最もすぐに必要とされるデータパケットを前記デコーダバッファ装置の少なくとも一つのアクセス単位を具える再送信領域に蓄積するステップとを具え、前記デコーダバッファ装置が、前記再送信領域内の欠落データパケットの検出に応答して、ストリーミングビデオ送信機に前記欠落パケットを再送信するよう要求することを特徴とするバッファリング方法。
【請求項１０】
前記データパケットの少なくとも一つを前記第1バッファ領域に前記デコーダバッファ装置の始動遅延に等しい期間に亘り蓄積することを特徴とする請求項９記載の方法。
【請求項１１】
前記データパケットを最初に前記第1バッファ領域に蓄積し、前記再送信領域へシフトさせることを特徴とする請求項９記載の方法。
【請求項１２】
前記第1バッファ領域が前記再送信領域から分離していることを特徴とする請求項９記載の方法。
【請求項１３】
前記第1バッファ領域が前記再送信領域の少なくとも一部分とオーバラップしていることを特徴とする請求項９記載の方法。
【請求項１４】
前記第1バッファ領域が前記再送信領域の全部とオーバラップしていることを特徴とする請求項９記載の方法。
【請求項１５】
前記第１バッファ領域が前記再送信領域から第２バッファ領域により分離され、前記第２バッファ領域において遅いデータパケットを前記遅いデータパケットの到達予想時間に対し遅らせるが、前記遅いデータパケットの再送信を必要とするほど十分には遅らせないことを特徴とする請求項９記載の方法。
【請求項１６】
プロセッサで実行されると、請求項９〜１５のいずれかに記載の方法を実行するプログラム命令が記憶されたコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【０００１】
発明の技術分野
本発明は、一般的にはビデオ処理システムに関し、特にはストリーミングビデオ受信機用のデコーダバッファに関するものである。
尚、本発明は米国暫定特許出願第６０／１０８，９３９号、出願日１９９８年１１月１８日、タイトル「SCALABLE VIDEO STREAMING USING MPEG-4」に関連するものである。この関連暫定特許出願に開示された内容はあらゆる目的の参考のために本明細書に記載されているものとする。
【０００２】
発明の背景
近年、インターネットプロトコル（ＩＰ）ネットワーク上のマルチメディアコンテントのリアルタイムストリーミングが一般的なアプリケーションになってきている。ニュースコンデマンド、ライブＴＶヴュー、ビデオ会議等のような広範囲の双方向及び非双方向マルチメディアインターネットアプリケーションがエンドツーエンドストリーミングの新技術に依存している。最初に「非リアル」タイムに検索し、後で視聴又は再生することができる「ダウンロード」ビデオファイルと異なり、ストリーミングビデオアプリケーションはビデオ信号を符号化しネットワークを経てビデオ受信機に送信するビデオソースを必要とし、ビデオ受信機はビデオ信号を復号しリアルタイムで表示する必要がある。ビデオ受信機はネットワークから符号化されたビデオデータパケットを受信しこれらのパケットをビデオデコーダに転送するデコーダバッファを必要とする。
【０００３】
ストリーミングビデオ信号がインターネットのような非保証サービス品質（QoS）ネットワークで伝送されるとき、２つの問題が生ずる。第１の問題はストリーミングビデオ送信機とストリーミングビデオ受信機との間のネットワーク内のエンドトーエンド変動（例えば遅延ジッタ）であり、エンドツーエンド遅延が一定でない。第２の問題は、通常、非QoSネットワーク伝送にはかなり大きなパケット損失率が存在し、しばしば再送信が必要とされる点にある。損失データパケットは対応するフレームを復号すべき時間前に回復させる必要がある。そうでなくても、アンダーフロー事象が起る。更に、予測圧縮を用いる場合には、損失データパケットによるアンダーフローは処理中の現フレームに影響を与えるのみならず多くの後続のフレームにも影響を与え得る。
【０００４】
損失パケットの再送信はパケットネットワークでの連続メディア通信に対し実行可能な回復手段であること周知である。多くのアプリケーションは損失パケットの再送信と関連して否定自動反復要求（ＮＡＣＫ）を使用している。これらのアプローチは送信機と受信機との間の往復遅延及び遅延ジッタの両方を考慮する必要がある。
【０００５】
例えば、パケット音声伝送用の再送信手段付きエンドツーエンドモデルが開発されている。このモデルは、音声データが短いトークスパートセグメントにより分離された無音期間からなることを利用している。このモデルは更に各トークスパートが固定数の固定サイズのパケットからなるものとしている。しかし、このモデルは圧縮ビデオ（１ビデオフレームにつき可変数のバイト又はパケットを有し得る）の特性を捕らえるには一般に十分でない。
【０００６】
従って、改良形ストリーミングビデオ受信機の分野では非QoSネットワークに固有の変動を補償する必要がある。特に、改良形受信機のデコーダバッファは転送遅延パラメータ（例えばエンドツーエンド遅延及び遅延ジッタ）及びビデオエンコーダバッファ制約の両方を考慮する必要がある。特に、改良形デコーダバッファは、遅延ジッタを除去し損失データを回復するのに通常使用されるネットワーク転送バッファとビデオデコーダバッファとに分離しなくてよいようにする必要がある。
【０００７】
発明の概要
本発明は統合転送デコーダ（Integrated  Transport Decoder：ＩＴＤ）バッファモデルに基づくデコーダバッファに具体化される。ＩＴＤモデルの１つの重要な利点は、遅延ジッタを除去し損失データを回復するのに通常使用されるネットワーク転送バッファをビデオデコーダバッファから分離する必要がなくなる点にある。これはエンドツーエンド遅延を大きく低減し、受信機リソース（例えばメモリ）の使用を最適化することができる。
【０００８】
本発明の主な目的は、ストリーミングビデオを復号し得るビデオデコーダ用に、ストリーミングビデオ送信機からストリーミングビデオを含むデータパケットを受信し、データパケットを複数のアクセス単位に蓄積し得るデコーダバッファを提供することにある。各アクセス単位はストリーミングビデオ内の選択したフレームと関連する少なくとも１つのデータパケットを保持し得る。デコーダバッファは、1)ビデオデコーダによりすぐには必要とされないデータパケットを蓄積し得る少なくとも一つのアクセス単位を具える第1バッファ領域と、2)ビデオデコーダにより最もすぐに必要とされるデータパケットを蓄積し得る少なくとも一つのアクセス単位を具える再送信領域とを具え、再送信領域内の欠落(ミッシング)データパケットの検出に応答して、ストリーミングビデオ送信機に欠落パケットを再送信するよう要求する。
【０００９】
本発明の一実施例では、少なくとも一つのデータパケットを第1バッファ領域にデコーダバッファの始動遅延に等しい期間に亘って蓄積する。
本発明の他の実施例では、データパケットを最初に第1バッファ領域に蓄積し、次いで再送信領域へシフトさせる。
本発明の更に他の実施例では、第1バッファ領域は再送信領域から分離している。
本発明の更に他の実施例では、第1バッファ領域は再送信領域の少なくとも一部分とオーバラップしている。
本発明の更に他の実施例では、第1バッファ領域は再送新領域の全部とオーバラップしている。
本発明の更に他の実施例では、第１バッファ領域は再送信領域から第２バッファ領域により分離され、第２バッファ領域において遅いデータパケットをこの遅いデータパケットの到達予想時間に対し遅らせるが、遅いデータパケットの再送信を必要とするほど十分には遅らせない。
【００１０】
以上、本発明の特徴及び技術的利点をかなり広義に概略的に説明したので、当業者は以下に記載する本発明の詳細な説明を良く理解することができるはずである。以下に記載する本発明の追加の特徴及び利点は本発明の請求項の要旨を構成する。当業者であれば以下に記載するコンセプト及び特定の実施例に基づいて容易に本発明の同一の目的を実現する構造を変更する又は他の構造を設計することができる。更に、当業者であればこのような等価な構造を本発明の広義の範囲を逸脱しないで実現することができる。
【００１１】
「実施例の詳細な説明」の前に、本明細書中に使用されている所定の語句の定義について述べるのが有益である。語「含む」及び「具える」は限定を意図しない含む意味であり、語「又は」は及び／又はの意味を含み、句「〜と関連する」は、〜と相互連結する、〜を含む、〜に含まれる、〜に（と）連結する、〜に（と）結合する、〜と伝達可能、〜と協動する、〜とインターリーブする、〜と並置する、〜と堅く結びついている、〜を有する、〜の特性を有する、等を意味し、語「コントローラ」は少なくとも１つの動作を制御する任意の装置、システム又はその一部分を意味し、このような装置はハードウエア、ファームウエア又はソフトウエア、又はそれらの少なくとも２つの組合せで実現することができる。特定のコントローラと関連する機能は、局部的に又は遠隔的に、集中させても分散させてもよい点に注意されたい。本明細書中の語句の定義を与えたので、当業者はコントローラのような定義を従来技術に適用するとともに将来も使用すべきである。
【００１２】
実施例の詳細な説明
以下に説明する図１−図５及び本発明の原理を説明するための種々の実施例は例示であって、本発明の範囲を制限するものではない。当業者であれば、本発明の原理をストリーミングビデオ受信機に任意に適当に実現することができることは容易に理解される。
更に、当業者であれば、以下に記載する本発明の実施例は主としてストリーミングビデオに指向しているが、これは一例にすぎないことは容易に理解される。実際上、以下に記載する改良形統合転送デコーダバッファは、デコーダに所要の速度で供給する必要のあるストリーミングオーディオデータ又は他のストリーミングデータに容易に適応させることができる。
【００１３】
図1はストリーミングビデオ送信機１１０からデータネットワーク１２０を経て本発明の一実施例に従うストリーミングビデオ受信機１３０へ伝送するストリーミングビデオのエンドツーエンド伝送を示す。アプリケーションに応じて、ストリーミングビデオ送信機１１０はデータネットワークサーバ、テレビジョン放送局、ケーブルネットワーク、デスクトップパーソナルコンピュータ（ＰＣ）等を含む種々のビデオフレームソースの任意の一つとすることができる。ストリーミングビデオ送信機１１０はビデオフレームソース１１２、ビデオエンコーダ１１４及びエンコーダバッファ１１６を具える。ビデオフレームソース１１２は、テレビジョンアンテナ及び受信ユニット、ビデオカセットプレーヤ、ビデオカメラ、「生」ビデオクリップを記憶し得るディスク記憶装置等を含む、圧縮されてないビデオフレームのシーケンスを発生し得る任意の装置とすることができる。
【００１４】
未圧縮ビデオフレームはビデオエンコーダ１１４に所定の画像レート（又は「ストリーミングレート」）で入力し、既知の圧縮アルゴリズム又はＭＰＥＧ−４エンコーダのような装置により圧縮される。ビデオエンコーダ１１４は圧縮ビデオフレームをエンコーダバッファ１１６に送出し、データネットワーク１２０による伝送に備えてバッファリングする。データネットワーク１２０は任意の適当なＩＰネットワークとすることができ、インターネットのような公衆データネットワーク及びエンタープライズローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）のようなプライベートデータネットワークの両ネットワークの一部分を含むこともできる。
【００１５】
ストリーミングビデオ受信機１３０はデコーダバッファ１３１、ビデオデコーダ１３４及びビデオディスプレイ１３６を具える。デコーダバッファ１３１はデータネットワーク１２０からストリーミング圧縮ビデオフレームを受信し蓄積する。次いでデコーダバッファ１３１は圧縮ビデオフレームを要求に応じビデオデコーダ１３４に送出する。ビデオデコーダ１３４はビデオフレームをビデオエンコーダ１１４の圧縮レートと（理想的には）同一のレートで圧縮解除する。
【００１６】
デコーダバッファ１３１は更に統合転送デコーダ（ＩＴＤ）バッファ１３２、ＩＴＤバッファモニタ１３８及び再送信コントローラ１３９を具える。本発明の原理に従って，ＩＴＤバッファ１３２は時間占有考察とデータ単位占有考察を統合してビデオデコーダ１３４に圧縮ビデオフレームをアンダーフロー状態を避けるのに十分なレートで供給する。アンダーフロー状態ではビデオデコーダ１３４は圧縮ビデオデータをもらえなくなる。
【００１７】
ＩＴＤバッファ１３２はＩＴＤバッファモニタ１３８及び再送信コントローラ１３９と協力してこれを達成する。ＩＴＤバッファモニタ１３８はＩＴＤバッファ１３２内のデータ占有レベルをモニタし、欠落データパケット及び潜在的アンダーフロー状態を検出する。ＩＴＤバッファモニタ１３８からの通知に応答して、再送信コントローラ１３９はアンダーフローを避けるためにＩＴＤバッファ１３２から欠落しているデータの再送信を要求する。本発明の有利な実施例では、ＩＴＤバッファ１３２、ＩＴＤバッファモニタ１３８及び再送信コントローラ１３９を、ストリーミングビデオ及び／又はオーディオを例えばインターネットから高速データラインを経て受信するパーソナルコンピュータ（ＰＣ）で実現する。このような実施例では、ＩＴＤバッファ１３２はＰＣの主ランダムアクセスメモリ（ＲＡＭ）又はビデオカード上のＲＡＭで実現することができ、ＩＴＤバッファモニタ１３８及び再送信コントローラ１３９はＰＣのＣＰＵで実現することができる。ＩＴＤバッファ１３２をＰＣ環鏡で実現するには、ＩＴＤバッファ１３２は、ストリーミングビデオ受信機１３０内の取外し可能なディスクポート１４１に装填し得るＣＤ−ＲＯＭ、コンピュータディスケット、又はその他の類似装置のような記憶媒体１４０にプログラムとして記憶したコンピュータ実効可能命令として具体化することができる。
【００１８】
圧縮ビデオフレームの連続復号化はストリーミングビデオのようなリアルタイムマルチメディアアプリケーションの重要な要件である。この要件を満足させるために、通常はデコーダ−エンコーダバッファモデルを用いてアンダーフロー及びオーバーフロー事象が起らないようにしている。これらの制約はエンコーダバッファに入力するビデオ画像のサイズ（ビット単位）を制限する。これらの制約は、受信機側での圧縮ビデオストリームの連続復号化及び表示を保証するエンコーダバッファの限界(範囲)によって通常表わされる。
【００１９】
図２はビデオ符号化システムの理想的なエンコーダ−デコーダモデルを示す。この理想モデルの下では、圧縮されてないビデオフレーム２０１−２０３が、時間軸(1)で示すように、エンコーダ２１４の圧縮エンジンに所定の画像レート（Ｘフレーム/秒）で入力する。圧縮されたフレームが、時間軸(2)で示すように、同一のＸフレーム/秒でエンコーダ２１４から出てエンコーダバッファ２１６に入力する。同様に、圧縮フレームはＸフレーム/秒でエンコーダバッファ２１６から出てチャネル２２０に入力する。チャネル２２０は圧縮ビデオフレームを送信ソースから受信機へ転送するインターネットのような任意の伝送媒体の包括的表現である。理想的な場合には、チャネル２２０の遅延(δc)は一定である。
【００２０】
次に、圧縮フレームは、時間軸(3)で示すように、チャネル２２０をエンコーダ２１４の入力及び出力と同一のＸフレーム/秒で出てデコーダバッファ２３２に入力する。デコーダバッファ２３２は圧縮フレームをデコーダ２３４に送出し、デコーダ２３４は圧縮フレームを圧縮解除し、圧縮解除フレーム２５１−２５３をエンコーダ２１４のフレーム入力と同一のＸフレーム/秒で出力する。
【００２１】
理想的には、エンドツーエンドバッファリング遅延（即ちエンコーダバッファ２１６とデコーダバッファ２３２の両方で受ける総合遅延）は一定である。しかし、圧縮ビデオデータの同一部分（例えばビデオストリームの特定のバイト）がエンコーダバッファ２１６及びデコーダバッファ２３２において異なる遅延を受ける。理想モデルでは、エンコーダ２１４における符号化及びデコーダ２３４における復号化は瞬間的であって、実行時間が零であり、データパケットは失われない。
【００２２】
エンコーダバッファの限界(範囲)は離散時間加法を用いて表わすことができる。離散時間領域分析では、Δを時間単位のエンドツーエンド遅延(即ちエンコーダバッファ２１６及びデコーダバッファ２３２の遅延とチャネル遅延δcを含む)とする。所定のビデオ符号化システムにおいては、Δはエンコーダ−デコーダバッファモデルに入力する全てのフレームに適用し得る定数である。
【００２３】
離散時間分析を簡単にするために、エンドツーエンドバッファリング遅延（ΔＴ＝Δ−δc）はフレーム持続時間（Ｔ）の整数倍であるものと仮定する。従って、ＮΔ＝Ｎ（Δ−δc）/Ｔはエンコーダ及びデコーダバッファの遅延をビデオフレームの数（Ｎ）を用いて表わしたものである。本発明の原理の説明を明瞭且つ簡単にするために、本明細書の残部ではフレーム周期間隔で規定される時間単位を使用する。例えば、図２に示すエンコーダ時間基準を用いて、第ｎ番フレームはエンコーダバッファ２１６に時間インデックス“ｎ”で入力するという。デコーダバッファ２３２のデコーダ時間基準はエンコーダバッファ２１６に対しチャネル遅延(δc)だけシフトする。
【００２４】
フレーム間隔“ｉ”におけるエンコーダ(e)２１４の出力のデータレート(r)はre(i)と表わすことができる。ここで、「データレート」は包括的に使用し、ビットレート、バイトレート又はパケットレートも意味する。同様に、デコーダバッファ２３２の入力におけるデータレートはrd(i)と表わすことができる。理想モデルに基づくと、re(iT)＝rd(iT+δc)である。更に、上述した規約に基づくと、re(i)＝rd(i)である。従って、エンコーダバッファ２１６の限界(範囲)は次式で表わせる。
【数１】
0004524042.tif 000002
ここで、Ｂmaxd及びＢmaxeはそれぞれ最大デコーダバッファサイズ及び最大エンコーダバッファサイズである。
【００２５】
理想的な場合には、また、エンコーダ２１４は第１フレームがエンコーダ２１４に入力した直後にデータの送信を開始するものと仮定される。これがため、始動遅延ddf(即ち第１画像からのデータの第１部分が復号化前にデコーダバッファ２３２で過ごす遅延時間)はエンドツーエンド、エンコーダ−デコーダバッファ遅延に等しい（ddf＝ΔＴ＝Ｔ・ΔＮ）。
【００２６】
本発明の一実施例では、ＩＴＤバッファ１３２が理想バッファモデルの上述の問題及び理想エンコーダ−デコーダバッファの制約を考慮してアンダーフロー事象を最少にする。ＩＴＤバッファ１３２は再送信を用いる損失パケット回復に基づく。
【００２７】
図３は再送信の支援のない代表的なエンドツーエンド伝送の簡略ブロック図である。説明を簡単且つ明瞭にするために、ストリーミングビデオ送信機１１０を圧縮ビデオソース３０５と置き換え、データネットワーク１２０をチャネル３２０と置き換えてある。圧縮ビデオソース３０５はデータパケットをレートre(n)で送信し、チャネル３２０はデータパケットをレートrtd(n)で送信する。ビデオ再送信はこの実施例に対しては支援されてないので、ＩＴＤバッファモニタ１３８及び再送信コントローラ１３９は図から省略されている。ストリーミングビデオ受信機１３０は簡単化され、ＩＴＤバッファ１３２及びビデオデコーダ１３４で表わされている。
【００２８】
上述したように、ＩＴＤバッファ１３２は時間単位占有モデルとデータ単位占有モデルを統合する。ＩＴＤバッファは各“Ｔ”秒の時間セグメントに分割される。例えば、パラメータＴはビデオシーケンスのフレーム周期とすることができる。所定の持続時間Ｔと関連するデータパケット(ビット、バイト又はパケット)は対応する時間セグメントでバッファされる。時間単位と関連するデータパケットのすべてを「アクセス」単位という。例えば、データパケット３５１、３５２及び３５３はアクセス単位Ａn+1を構成し、データパケット３５４はアクセス単位Ａn+２を構成し、データパケット３５５及び３５６はアクセス単位Ａn+３を構成する。
【００２９】
時間間隔ｎにおいて、第ｎ番アクセス単位Ａnがデコーダ１３４で複合化されるとともに、アクセス単位Ａn+1がＩＴＤバッファ１３２の出力に最も近い時間セグメントに蓄積される。アクセス単位はオーディオフレーム、ビデオフレーム又はＧＯＢ(グループオブブロック)のようなビデオフレームの一部分とすることができる。これがため、アクセス単位を復号し表示するのに要する時間は時間セグメントＴの持続時間と同一である。時間間隔ｎにおいて、データがＩＴＤバッファ１３２に入力するレートはrtd(n)である。各アクセス単位内のデータパケットの数は同一にする必要はない。ビデオエンコーダ１１４で使用される種々の圧縮アルゴリズムにより連続するアクセス単位内のパケットが異なる量で圧縮されるが、各アクセス単位は同一持続時間の時間単位を表わす。
【００３０】
例えば、アクセス単位Ａn+1内の３つのデータパケット３５１-３５３は完全なビデオフレーム、フレーム１、を構成するものとし得る。アクセス単位Ａn+２内の単一のデータパケット３５４はフレーム１と異なるフレーム２の部分を表わすものとすることができる。これは、フレーム１のデータが予め既知であればフレーム２の生成にはデータパケット３５４で十分であるためである。フレーム１及びフレーム２は同一の持続時間であるため、時間セグメントＴはアクセス単位Ａn+1及びＡn+２に対し同一である。
【００３１】
各時間セグメントは各々最大サイズｂmax(ビット又はバイト)を有する最大数Ｋmaxのパケットを保持する。これがため、アクセス単位の最大サイズＳmaxはＳmax≧Ｋmax（ｂmax）で表わすことができる。ビデオエンコーダ１１４は各アクセス単位を当該アクセス単位内にのみ存在する新パケットから始めるものとする。
【００３２】
時間インデックスｎにおけるＩＴＤバッファ１３２内のデータ量Ｂtd(n)はＢa(n)及びＢb(n)で表わすことができる。Ｂa(n)は時間間隔ｎの開始時におけるＩＴＤバッファ１３２内の連続且つ完全なアクセス単位の数を表わし、Ｂb(n)は時間間隔ｎの終了時におけるＩＴＤバッファ１３２内の総連続データ量を表わす。Ｂa(n)に対しては、部分データを含む時間セグメントは数えず、部分セグメントに後続する全てのセグメントも、それらが完全なアクセス単位分のデータを含んでいても数えない。従って、Ｔ・Ｂa(n)は、（それ以上データが到来しなくてもアンダーフローになることなく）ＩＴＤバッファ１３２が時間インデックスｎにおいて保持する時間単位(例えば秒)当たりのビデオ量を表わす。
【００３３】
これがため、Ｓnがアクセス単位ｎのサイズを示すものとすると、ＢaとＢbとの関係は下記の式２として表わせる。
【数２】
0004524042.tif 000003
ここで、Ｓjは時間セグメントｊに対するアクセス単位の最大サイズ及びＵaＢ(n)+1は時間インデックスｎの開始時に時間セグメントＢa(n)+1に蓄積されているアクセス単位Ａn+Ｂa(n)+1の部分(不完全)データである。
【００３４】
一実施例として再送信を支援する場合には、ＩＴＤバッファ１３２はa）各時間間隔ｎの開始時に１時間セグメント（Ｔ）分のデータを出力すること；b)損失パケットを検出し、関連する否定肯定（ＮＡＣＫ）メッセージを送信機１１０又は３０５に送信すること；C)新たに到来する一次(即ち再送信でない)パケットを連続的に蓄積すること；d)再送信されたパケットを蓄積することができる必要がある。理想ＩＴＤバッファ１３２はビデオストリームのデータレートを維持し、任意の損失データの再送信により遅延を生じない。換言すれば、re(n)が無損失の環鏡の下で理想ビデオエンコーダ１１４により使用される送信データレートである場合には、理想ＩＴＤバッファ１３２は再送信処理により生ずる劣化なしにこのデータレートを維持する。再送信要求の数に応じて、エンコーダバッファ１１６はその出力データレートre(n)を調整し、対応する調整がＩＴＤバッファ１３２により行われる。
【００３５】
一実施例では、デコーダバッファ１３１は損失データの検出及び回復に必要とされる時間を補償するとともに「リアル」ワールドの実現と関連する遅延を補償するために入力ビームストリームに対し追加のバッファリングを行う。全入力ビデオストリームをこの補償時間だけ遅延させることにより、デコーダバッファ１３１はビデオストリームデータを復号化に必要な連続レートで出力する。再送信コントローラ１３９及びＩＴＤバッファ１３２はパケットの不在を検出する時間を最小にする処理とストリーミングビデオ送信機１１０による再送信のためにＮＡＣＫを転送する処理とを併合する。所定数の損失パケットを検出するのに要する最小持続時間をＴＬで表わす。一般に、ＴＬはＩＴＤバッファ１３２による予測より遅く到達するデータにより生ずる遅延ジッタの関数である。
【００３６】
パケット損失の宣言後にストリーミングビデオ受信機１３０がパケットを回復するのに要する時間の最小量をＴＲで表わす。時間ＴＲはストリーミングビデオ受信機１３０がＮＡＣＫをストリーミングビデオ送信機１１０に送るのに要する時間と、再送信データがストリーミングビデオ受信機１３０に到達するのに要する時間とを含む（ＮＡＣＫ及び再送信データは失われないものとする）。
【００３７】
代表的なデコーダバッファ１３１は再送信パケットを損失パケット時間間隔中に最小の遅延（ＴＬ＋ＴＲ）で転送する。理想デコーダバッファ１３１において任意のビデオデータが経験する最小遅延をddminで表わば、再送信のための総合遅延を補うためにこの最小遅延に加えることができる遅延量ΔＲは、
【数３】
0004524042.tif 000004
である。ここで、ｘ＞０に対しu(x)=x、ｘ≦０に対しu(x)=0である。
【００３８】
デコーダバッファ１３１はデータの復号化及び転送用の時間を与えるために遅延ΔＲを加え、ビデオデコーダ１３４への全出力データをバッファリングして、連続ビデオストリームを生じさせる。これがため、エンコーダバッファ１１６−デコーダバッファ１３２の総合出力遅延(ΔＴＯＴ)は次式で表わすことができる。
【数４】
0004524042.tif 000005
【００３９】
ＩＴＤバッファ１３２は、再送信時間要求の補償として及びアンダーフロー事象の予防として最少数の時間セグメント（Ｂamin）をバッファリング（蓄積）する。ＩＴＤバッファ１３２のサイジングは、例えば時間セグメントを蓄積する最小及び最大限界(範囲)に基づくものとすることができる。これらの限界(範囲)を決定するプロセスについて以下の段落に記載する。
【００４０】
損失パケット及びジッタ遅延がない場合には、任意の時間インデックスｎにおいて、ＩＴＤバッファ１３２は次の占有能力：
【数５】
0004524042.tif 000006
をあたえる。
【００４１】
理想ＩＴＤバッファ１３２は最大復号遅延ddmaxを有する。ここで、ddmax≧Δideal。従って、損失パケット及び遅延ジッタのない場合には、理想ＩＴＤバッファ１３２は次の要件：
【数６】
0004524042.tif 000007
を満足する。
【００４２】
更に、損失データ及び遅延ジッタのない場合には、理想ＩＴＤバッファ１３２はＴＢa(n)データに対し次のように限界される蓄積要件を提供する。
【数７】
0004524042.tif 000008
【００４３】
遅延ジッタを考慮したＩＴＤバッファ１３２の蓄積能力は次のように表わすことができる。
【数８】
0004524042.tif 000009
ここで、ＴＥはＩＴＤバッファ１３２に予想より早く到来するパケットと関連する遅延ジッタである。これがため、ＢamaxをＩＴＤバッファ１３２が保持する時間セグメントの最大数とすると、
【数９】
0004524042.tif 000010
となる。
【００４４】
ＩＴＤバッファ１３２の蓄積能力は上述の等式、最小理想蓄積要件及びデータ転送と関連する遅延に基づく。ＩＴＤバッファ１３２は理想エンコーダバッファ１１６により決まる最小サイズを有し、Ｂamaxで表わされる。ＩＴＤバッファ１３２はＩＴＤバッファ１３２により導入される遅延及び予想より早く到来するデータを調整する追加の蓄積を提供する。これらの代表的な遅延を吸収するＩＴＤバッファ１３２の蓄積要件はＴextraで表わされ、次式で与えられる。
【数１０】
0004524042.tif 000011
【００４５】
この関係を用いると、Ｂbmax上限(時間単位)を満足するＩＴＤバッファ１３２の蓄積要件は次の上限限界の関係式で示される。
【数１１】
0004524042.tif 000012
【００４６】
理想ＩＴＤバッファ１３２は零に等しい最小復号遅延(ddmin)及び理想エンドツーエンドバッファリング遅延(Δideal)に等しい最大復号遅延(ddmax)を有する。理想ＩＴＤバッファ１３２はＴＬ＋ＴＲに等しい追加の最小遅延を与える大きさにする(ここでＴＬ及びＴＲは持続時間Ｔの整数倍であるものとする)。最小時間遅延要件は理想バッファ領域ddmin＝０及びdmax＝Δidealを前記のΔＴＯＴの式に代入することにより見出せる。この追加のバッファ要件はＮＬ＋ＮＲ個の時間セグメントを蓄積する(ここで，ＮＲ＝ＴＲ/Ｔ及びＮＬ＝ＴＬ/Ｎ)。従って，ＩＴＤバッファ１３２は次の数の時間セグメントの蓄積を与える。
【数１２】
0004524042.tif 000013
【００４７】
最大復号遅延、ddmax=Δideal=ΔＴ、はΔＮの時間セグメントに対応するため、Ｂbmaxは更に次のように表わせる。
【数１３】
0004524042.tif 000014
ここで、ＮＥ＝ＴＥ/Ｔ
【００４８】
図４は、ddmin=０（下限レベル）及びdmax=Δidealの仮定の下で、デコーダバッファ１３１のＩＴＤバッファ１３２の種々の領域を通るデータパケットの流れを示すシーケンス図である。ＩＴＤバッファ１３２のデータは図の右側から入力し、左側からビデオデコーダ１３４へ出力する。最も最近受信されたデータは「再送信要求には早すぎる領域」（尚早領域）と呼ぶバッファ領域にある。バッファの尚早領域内の位置に応じて、ＩＴＤバッファ１３２はＮＥ、ΔＮ又はＮＬで示すバッファ遅延を導入する。この尚早バッファ領域の理想遅延ΔＮを具える部分を理想バッファ領域と呼ぶ。ＩＴＤバッファ１３２は理想バッファ領域を理想ビデオバッファとして管理し、即ちこの領域を流れるデータパケットはバッファ素子の固有の特性により遅延されるだけである。理想ＩＴＤバッファ１３２の尚早バッファ領域の残部はストリーミングビデオ送信機１１０からデコーダバッファ１３１へのビデオデータの転送と関連する遅延（ＮＥ）と遅延又は損失ビデオパケットにより生ずる遅延（ＮＬ）とを補償する。
【００４９】
ＩＴＤバッファ１３２は再送信要求の開始及び受信に対し予想される時間要件を補償するために再送信領域において遅延ＮＲを与える。代表的なデコーダバッファ１３１は再送信要求を再送信領域と関連する期間中に開始する。
理想バッファ領域と再送信領域は、種々の遅延パラメータ(ddmin，ＴＲ，ＴＬ)の値に応じて、オーバラップさせることができる点に注意されたい。しかし、ddmin=0を有する代表的な理想ＩＴＤバッファ１３２の場合には、再送信領域と理想バッファ領域はオーバラップさせない。
【００５０】
ＩＴＤバッファ１３２において、ＮＥは第１画像(又はアクセ単位)の復号化前にバッファに入力するデータの各第１部分が受ける遅延量に対応する初期復号化遅延(ddf)を表わす。このddfは、特に、経過時間ddf中のストリーミングビデオ送信機１１０及びデータネットワーク１２０のデータ伝送レートに基づく。理想的な場合には、ＩＴＤバッファ１３２は受信データをそのバッファ(蓄積)領域に入力するのにこの同一のデータレートを使用する。理想デコーダバッファ１３１はそのＩＴＤバッファ１３２のバッファ領域内のデータ量を第１アクセス単位がＢd0データとして複合化される直前に認識する。このＢd0（始動遅延ともいう）は次式により決定される。
【数１４】
0004524042.tif 000015
【００５１】
ddmin=０の場合、理想デコーダバッファ１３１の再送信処理は次のプロシージャからなる。
理想バッファ領域が始動遅延と関連する全データがバッファに入るまで満たされる。損失事象がこの時間間隔中にも起り得るので、これらのデータを特別の方法で、例えば高信頼度の伝送(例えばＴＣＰ)を用いて処理することができる。無損失データに対する理想状態が、
【数１５】
0004524042.tif 000016
であるとき、満足される。ここで、Ｂｋは任意の瞬時において理想ＩＴＤバッファ１３２の時間セグメントｋに蓄積されるデータ量である。
【００５２】
式１５が満足された後、ＩＴＤバッファ１３２は全ての時間蓄積セグメントの内容を１セグメントだけバッファ出力の方へ進める。次に、理想ＩＴＤバッファ１３２はこのプロセスを毎Ｔ時間単位ごとに繰り返す。ＮＬ＋ＮＲのＴ周期後(即ちＴＬ＋ＴＲ後)に、デコーダ１３４が第１アクセス単位を複合化し始める。第１アクセス単位の復号化が開始するとき開始する時間周期をＴ１で示す。従って、任意の時間周期n(Ｔn）の開始はアクセス単位Ａn+kが時間セグメントｋに移動される時間を表わす。理想ＩＴＤバッファ１３２は再送信バッファ領域の時間セグメントＮＲ内において欠落しているデータを損失とみなす。この状態は、
【数１６】
0004524042.tif 000017
の場合に発生する。ここで、ＢＮR(n)は時間周期ｎにおける時間セグメントＮＲ内のデータ量であり，Ｓjはアクセス単位のサイズである。理想デコーダバッファ１３１はデータが欠落していることを決定するとき、再送信要求をストリーミングビデオ送信機１１０に送出する。
【００５３】
理想ＩＴＤバッファ１３２は到来する再送信データを再送信領域のそれらの対応する時間セグメント内に置く。再送信データが受信されたものとすると，ＩＴＤバッファ１３２は再送信データをそれらの対応するアクセス単位の復号時間前にビデオデコーダ１３４に転送する。
【００５４】
図５は、理想バッファ領域と再送信領域との間にオーバラップを有する場合の代表的なＩＴＤバッファ１３２の種々の領域を通るデータパケットの流れを示すシーケンス図である。この場合には、ＩＴＤバッファ１３２は最大外側限界（ここではddmin≧ＴＬ＋ＴＲ）に対し構成され、その理想バッファ領域がその再送信領域と全体的にオーバラップされている。従って、デコーダバッファ１３１は始動遅延と関連するデータの全てが到来した後に受信ビデオストリームをビデオデコーダ１３４に転送する。次いでビデオデコーダ１３４が第１アクセス単位を他の遅延なしで復号化する。デコーダバッファ１３１は上述したように再送信機能を実行する。
【００５５】
同様に、デコーダバッファ１３１は、ddminが最小及び最大限界域間の値を有する一般的場合、（即ち０＜ddmin＜ＴＬ＋ＴＲの場合）には、ストリーミングビデオ送信機１１０とビデオデコーダ１３４との間のデータ転送に（ＴＬ＋ＴＲ−ddmin）の追加の遅延を与える。
以上本発明を詳細に説明したが、当業者であれば本発明の範囲を逸脱することなく種々の変更、置換及び変形を行うことができること勿論である。
【図面の簡単な説明】
【図１】  ストリーミングビデオ送信機からストリーミングビデオをデータネットワークを経て本発明の一実施例に従う代表的なストリーミングビデオ受信機へ伝送するエンドツーエンド伝送を示す。
【図２】  ビデオ復号化システムの理想エンコーダ−デコーダモデルを示す。
【図３】  圧縮ビデオソースからストリーミングビデオをチャネルを経て本発明の一実施例に従う、再送信の支援のない、代表的な統合トランスポートデコーダバッファへ伝送するエンドツーエンド伝送を示す。
【図４】  代表的な理想統合トランスポートデコーダバッファの種々の領域を通るデータパケットの流れを示すシーケンス図である。
【図５】  最大外部限界範囲に対し構成された代表的な理想統合トランスポートデコーダバッファの種々のオーバラップ領域を通るデータパケットの流れを示すシーケンス図である。
【図１】
0004524042.tif 000018
【図２】
0004524042.tif 000019
【図３】
0004524042.tif 000020
【図４】
0004524042.tif 000021
【図５】
0004524042.tif 000022