記録されたマテリアルを伝送すること
ビデオのような記録されたマテリアルは、受信データレートと続くデコーダによって消費されるデータレートとの間の差異を平滑化するためのバッファを有する受信機に、圧縮形式で伝送される。バッファアンダーフローが起こらないように、記録全体が再生を開始するポイントを決定するために分析され、該デコーダはこのポイントに到達した場合にだけ再生を開始する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ、リアルタイムで再生される他のマテリアルの音声等の記録されたマテリアルを、ネットワーク上で伝送するための方法及び装置に関する。
【発明の開示】
【０００２】
本発明の１つの態様によると、
−記録の伝送を開始することと、
−受信機バッファ内に受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備え、
バッファアンダーフロー(buffer underflow)が発生しないように再生を開始するポイントを決定するために記録全体を分析するステップと、このポイントに達したときだけに再生を開始するステップと、により特徴付けられる、記録を伝送する方法が提供される。
【０００３】
別の態様では、本発明は、
−記録の伝送を開始することと、
−受信機バッファ内に受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備え、
記録が、任意の長さの続くセクションのタイミングエラーの最大より大きいか又は等しい再生時間間隔をカバーするという条件を満たす、記録の最初に第１のセクションを特定するために記録全体を分析するステップであって、各タイミングエラーがそれぞれの続くセクションの伝送時間がその再生時間間隔を超える範囲として定義されるものと、該受信機に、前記第１のセクションが受信された後にだけ再生を開始させるステップと、によって特徴付けられる、記録を伝送する方法を提供する。
【０００４】
本発明の追加の態様は、特許請求の範囲に述べられている。
【０００５】
本発明のいくつかの実施形態は、添付図面を参照し、ここに一例として説明される。
【発明を実施するための最良の形態】
【０００６】
図１では、ストリーマ１が、それぞれが、ＩＴＵ規格Ｈ．２６１またはＨ．２６３、あるいはＩＳＯ ＭＰＥＧ規格の内の１つに定められるアルゴリズムのような、従来の圧縮アルゴリズムを使用して符号化されているビデオシーケンスの圧縮バージョンであるファイルが記憶される、メモリ（store）１１を含む（またはメモリ１１にアクセスする）。当然、追加ビデオシーケンスの類似した記録を記憶してよいが、これは動作原理にとっては重要ではない。
【０００７】
「ビットレート」によって、ここでは元のエンコーダによって生成され、最終的なデコーダによって消費されるビットレートが意味される。一般的には、これは、伝送側ビットレートと呼ばれる、ストリーマが実際に伝送する速度と同じではない。これらのファイルが可変ビットレート（ＶＢＲ）で作成される−つまり、ビデオの任意の特定のフレームのために生成されるビット数がピクチャコンテンツに依存することにも留意する必要がある。その結果、前記の低（など）ビットレートに対する参照は、平均ビットレートを参照する。
【０００８】
サーバは、ネットワーク２を介してデータを端末３に出力するのに役立つ送信機１２を有する。該送信機は、おそらくＴＣＰ／ＩＰ等の周知のプロトコルで動作する従来のものである。制御装置１３はある特定のシーケンスの配信のために端末から要求を受信し、送信機がそれらを受信できる限り、送信機１２に送信するためにメモリ１１からデータのパケットを読み取るために従来の方式で働く。ここでは、単一のフレームのために複数のパケットを生成する可能性は排除されないが、データは別々のパケット、多くの場合ビデオのフレームあたり１パケットとして、読み出されると仮定される。（原則的には単一のパケットが複数のフレームのためのデータを含むことは可能であるが、これは通常、実際にはそれほど重要ではない。）
これらのパケットが、ネットワーク２で使用される任意のパケット構造に必ずしも関連していないことに留意されたい。
【０００９】
端末３は、受信機３１、バッファ３２及びデコーダ３３を有する。
【００１０】
（ＴＣＰ／ＩＰネットワークを含む）いくつかのネットワークは、使用可能な伝送側データレートが、ネットワークでのロードの程度に従って変動するという特徴を有する。
【００１１】
何らかの理論的な説明がこの時点で望ましい。
【００１２】
図２に示されているように、符号化されたビデオシーケンスはＮ個のパケットからなる。各パケットは時間指数ｔｉ（ｉ＝０．．．Ｎ−１）を含むヘッダを有し（リアルディスプレイ時間に関して−例えば、これはビデオフレーム番号である場合があるであろう）、ｂｉビットを含む。この分析は、パケットｉが、それが復号できる前に完全に受信されていなければならないと仮定する（つまり、最初にパケット全体をバッファに入れなければならない）。
【００１３】
単純なケースでは、各パケットは１つのフレームに対応し、タイムスタンプｔｉはすべてのｉについて単調に、つまりｔｉ＋１＞ｔｉで増加する。しかしながら、フレームが２つ以上パケットを増加できる場合（各々同じｔｉで）ｔｉ＋１≧ｔｉである。フレームが（ＭＰＥＧにおいてのように）捕捉及び表示シーケンスを使い切ることがある場合には、ｔｉは単調に増加しない。また、実際には、いくつかのフレームが削除されてよく、その結果ｔｉの特定の値のためのフレームがないであろう。
【００１４】
これらの時間は相対的である。受信機がパケット０を受信し、時間ｔｒｅｆ＋ｔ０でパケット０の復号を開始すると仮定する。ｔｒｅｆ＋ｔｇという「今の時間」に、受信機はパケットｔｇ（及び、場合によってはさらに多くのパケット）も受信し、パケットｇの復号を開始したところである。
【００１５】
パケットｇからｈ−１はバッファ内にある。（単純なケースでは）ｈ＝ｇ＋１である場合には、バッファの中にパケットｇだけが含まれることに留意されたい。時間ｔｒｅｆ＋ｔｊでは、デコーダはパケットｊの復号を開始することを要求される。したがって、時間ｔｒｅｆ＋ｔｊでは、デコーダはパケットｊを含むまですべてのパケットを受信することを必要とする。
【００１６】
現在から
【数１】
【００１７】
まで使用可能な時間。
【００１８】
その時間内で送信されるデータは、パケットｈからｊまでのための時間であり、つまり、
【数２】
【００１９】
伝送レートＲで以下の伝送持続時間を必要とするであろう。
【数３】
【００２０】
これは、この伝送持続時間が使用可能な時間以下の場合にだけ、つまり現在使用可能な伝送レートＲが不平等を満たすときにだけ可能である。
【数４】
【００２１】
これが、パケットｊの満足のいく受信及び復号の条件であることに留意されたい。残りのシーケンスの全体の満足のいく伝送には、すべてのｊ＝ｈ．．．Ｎ−１についてこの条件が満たされることが必要になる。
【００２２】
明らかになる理由から、方程式（４）は以下のとおりに書き換えられる。
【数５】
【数６】
【００２３】
の場合
【数７】
【００２４】
であることに留意されたい。
【００２５】
また、
【数８】
【００２６】
を定義する。
【００２７】
ｔｈ−１−ｔｇが、バッファ内で最も最近受信されたパケットのタイムスタンプと、バッファ内で最も最近にではなく受信されたパケット−つまり、ちょうど復号し始めたパケット−のタイムスタンプの差異であることに留意されたい。
【００２８】
その結果、条件は、
【数９】
【００２９】
である。
【００３０】
最後のパケットＮ−１までの伝送が成功した場合、この条件は任意の考えられるｊについて満たさなければならない。つまり、
【数１０】
【００３１】
方程式（７）の左側は、パケットｈの伝送からシーケンスの最後までに発生する可能性のある最大タイミングエラーを表し、該条件は、事実上、その現在の内容を考えてこのエラーがそれを収容する受信機バッファの能力を超えてはならないと述べる。便宜上、方程式（７）の左側をＴｈと名付ける−つまり、
【数１１】
【００３２】
したがって、方程式（７）は以下のように書かれてもよい。
【数１２】
【００３３】
時間ｔｇ＝ｔ０での状況、つまりデコーダが第１のパケットの復号を開始するときを考える。一般的なケースでは、前記条件は、バッファ（ｈ＝１）内に唯一のパケットがあるときに満たされないであろう。受信機は、それが復号を開始する前に、バッファコンテンツが満足のいくレベルに達するのを待機する。前記条件を使用すると、受信機は少なくともバッファがパケットＨ−１を含むまで待機しなければならず、この場合Ｈは以下の条件が満たされるｈの最小値であることが明らかになる。
【数１３】
【００３４】
本発明の本実施形態では、制御装置１３の機能の内の１つは、それがパケットを送信機１２に伝送するたびに、方程式１０で具現化されたテストを評価するという点である。
【００３５】
図３は、制御装置の動作を示すフローチャートである。ステップ１０１では、パケットカウンタがリセットされる。その結果（１０２）、第１のパケット（または以後の反復では、次のパケット）がメモリ１１から読み取られ、送信機１２に伝送される。ステップ１０３では、制御装置はＴｎの値を計算する。この点では、カウンタｎは伝送された最後のパケットを指すが、方程式（１０）はｈ−１である最後に伝送されたパケットについて定式化される。その結果、ステップ１０３の計算はＴｎ＋１のものであり、ステップ１０４で実行されるテストは、
【数１４】
【００３６】
であるかどうかである。
【００３７】
このテストに合格しないと、パケットカウンタは１０６で増分され、送信機がそれを受信する準備が完了するやいなや、追加のパケットが読み出され伝送される、ステップ１０２に制御が戻る。テストに合格すると、受信機がこのパケットを受信するやいなや復号を安全に開始できることが知られる。したがって、ステップ１０５では、制御装置は受信機に送信される「開始」メッセージを送信機に送信する。受信機はこの開始メッセージを受信すると、復号を開始する。メッセージが、それらが伝送されたのとは異なる順序で受信される可能性がある場合には、復号を開始する前にパケットｎが実際に受信されたことを受信機がチェックできるように、開始メッセージはパケットインデックスｎを含む必要がある。代わりに、送信機は受信機にＴｎ＋１という値を伝送でき、受信機自体がテストを実行する。
【００３８】
「開始」メッセージの伝送に続き、パケットカウンタは１０７で増分され、別のフレームは１０８で伝送される。これらのステップは、ファイルの最後に到達するまで繰り返され、これは１０９で認識され、プロセスは１１０で終了する。
【００３９】
前記説明では、制御装置が、送信機にパケットを伝送するたびにこの計算を実行すると仮定しており、計算上、きわめて集約的である。代替策は、計算をあまり頻繁にではなく、おそらく５パケットに１度、実行することであり、それは計算量を削減するが、必要とされる以上のフレームをバッファに入れることになる可能性がある。
【００４０】
別の代替策は、それがそうすることができるとすぐに（つまり、次のパケットを待機せずに）計算を完了し、その結果受信機に（開始するパケット番号とともに）開始メッセージを伝送することである。さらに追加の代替策は、あらゆるパケットを伝送する前に計算を実行することである。いったんｈという値が求められたら、次にパケット０をｈ−１に逆の順序（パケットｈ−１、パケットｈ−２、．．．パケット０）で伝送する。この場合、明示的な「開始」コマンドを伝送することは必要でなくなる。ＵＤＰトランスポートプロトコルをサポートする標準的な受信機は、パケットを並び替えることができ、パケット０が復号を開始する前に到達するまで自動的に待機するであろう。事実上、パケット１からｈ−１が伝送された後（その順序は重要ではない）までパケット０が保留されることで十分である。
【００４１】
しかしながら、これは待機期間中にデータレートＲを伝送する際の変更を考慮する可能性を排除するため、このような変更が予想されない場合にだけ満足が行く。
【００４２】
（方程式（３）を検査することにより）、レートＲの意義がパケットｈをｊへ送信するために要する時間を計算することにあることに留意されたい。したがって、パケット０をｈ−１へ伝送するために使用される実際のレートは、それがその結果に影響を及ぼさないため重要ではない。
【００４３】
別の魅力的なオプションは、事前に計算の可能な限り多くを実行することである。Ｒというただ１つの値だけが可能であるシステムが考えられる、或いは許可される場合には、ステップ１０３でのＴｎ＋１の計算及びステップ１０４のテストは、テストが合格するポイントまでのフレームごとに事前に実行することができ、結果は、例えばファイルの開始時に別個のフィールドにｎという対応する値を記録することによって、あるいはフレームｎ自体に特殊なフラグを取り付けることによって、ファイルの中に記録される。このようにして、図３では、ステップ１０３と１０４は、テスト「ｎという現在値はファイルに記憶されているｎという値に等しいか」あるいは「現在のフレームは開始フラグを含むか」によって、置換されるであろう。代わりに、別個のフィールド（またはフラグ）は受信機に転送され、この認識プロセスは受信側で実行できるであろう。
【００４４】
図４は、伝送データレートＲが変化する状況に対処するためのプロセスのフローチャートである。原則的に、これはパケットごとにＴｈ、及びこの値をパケットヘッダに記憶することを必要とする。しかしながら、実際には、この期間内にテストに合格すると確信があるシーケンスの始まりで、十分な数のフレーム（毎秒２５フレームでおそらく２５０フレーム）についてそれらを計算することが必要である。残念なことに、Ｔｈの計算は、この前処理の時点でもちろん未知であるＲという値を含む。したがって、（ＲＡが問題のファイルの平均ビットレートである場合に）例えばＲという考えられる値の選択についてＴｈを計算することによって先に進む。
【数１５】
【００４５】
したがって、各パケットｈはその中に記憶されたＴｈというこれらの５個の事前に計算された値を有する。（後述されるために）必要とされる場合、また、方程式（８）の中の最大が発生する相対的な時間位置、つまりＴｈが得られるｔｊｍａｘが方程式８のｊという値である
【数１６】
【００４６】
を記憶してもよい。
【００４７】
このケースでは、フローチャートは、フレームｎの伝送に続き以下のように進む。
【００４８】
１１２：使用可能な伝送レートＲを求めるために送信機１２を調べる。
【００４９】
１０３Ａ：Ｒが、Ｔｈが事前に計算されたレートの内の１つに一致する場合には、メモリからこの値を読み取る。
【００５０】
または−Ｒが一致しない場合には、Ｒの実際の値未満であるレートＲ１．．．Ｒ５の内の最高の値（Ｒ−）に一致し、それからＴｈを推定するＴｈ（及び必要とされる場合、ｔｈｍａｘ）の値をメモリから読み取る、かのどちらかである。
【００５１】
１０４Ａ：テスト
【数１７】
【００５２】
を適用し、この場合Δは固定された安全マージンである。
【００５３】
前記とおりに続行する。
【００５４】
Ｔｈの推定値は、単にＲ−と関連付けられた値Ｔｈ−を使用することによって実行できるであろう。これはうまくいくであろうが、それはＴｈを過大評価するであろうため、時折、受信機が必要以上に待機することになるであろう。別のオプションは、実際の値Ｒの各側にＲ１．．．Ｒ５の２つの値について記憶されたＴｈの値の間の、線形（または他の）補間であろう。しかしながら、我々の好ましい手法は以下に従って推定値を計算することである。
【数１８】
【００５５】
Ｒ−がＲの実際値未満であるレートＲ１．．．Ｒ５の内の最高の値である場合、Ｔｉ−はこのレートのために事前に計算されたＴｈであり、
【数１９】
【００５６】
は、Ｔｉ−が得られるｔｉからの時間（つまり、
【数２０】
【００５７】
の添付値）である。この方法が負の値を返す場合には、それをゼロに設定する。
【００５８】
Ｔｈはレートの非線形関数であるため、これが推定値に過ぎないことに留意されたい。しかしながら、この方法を使用すると、Ｔｉ−はつねに真の値より高く、（前記に示されたマージンΔが省略できるように）自動的に安全マージンを提供する。
【００５９】
これらの方程式は、符号化プロセスが１フレームについて（ｔｉが等しい）２個以上のパケットを生じさせる状況に、及びフレームが昇順ｔｉよりむしろ復号される必要のある順序で伝送される、双方向予測が行われるＭＰＥＧで遭遇する状況に有効であることに留意されたい。
【００６０】
ここで、数学が、パケットごとに個別に計算を実行するよりむしろ、先行するパケットについてすでに行われた計算を利用する同等な形式に変換される、代替実施形態を説明する。方程式（８）を思い出すと、
【数２１】
【００６１】
は、以下のように書き換えられてよい。
【数２２】
【００６２】
ファイルの始まりで真となるであろうＴｈ＋１≧０であるならば、これは以下になる。
【数２３】
【００６３】
あるいは一般的に、
【数２４】
【００６４】
ｂ＝ｈ−ａの場合には、
【数２５】
【００６５】
であり、
【数２６】
【数２７】
【００６６】
に代わる。
【数２８】
【００６７】
ａ＝０の場合には、
【数２９】
【００６８】
ａ＝１の場合には、
【数３０】
【００６９】
テスト
【数３１】
【００７０】
を検討すると、
【数３２】
【００７１】
に書き換えられてよい。
【００７２】
ａ＝０の場合、これは以下になる。
【数３３】
【００７３】
ｔ−１が、それが任意の値を与えることができるように（不等式の両側に現れる）意味のない量であることに留意すると、ｔ−１をｔ０に等しいと定めることは便利であり、そこから以下が得られる。
【数３４】
【００７４】
したがって、方程式（１０）のテスト
【数３５】
【００７５】
は、代わりに以下のように書くことができるであろう。
【数３６】
【００７６】
第１のテスト（ｈ＝１）がテスト１である場合には、
【数３７】
【００７７】
あるいは、
【数３８】
【００７８】
を定める場合には、第１のテストはＺ１≦０であるか？
第２のテストはＺ２≦０である。
【００７９】
Ｘ番目のテストはＺＸ≦０である。
【００８０】
しかしながら、
【数３９】
【００８１】
したがって、各テストは、図５のフローチャートに示されるように、Ｚの前の値を更新できる。第１に、ステップ２０１では、Ｔ０は方程式（８）に従って計算され、その場合（ステップ２０２）Ｚ０はＴ０に等しく設定される。ステップ２０３では、パケットカウンタがリセットされる。それから（２０４）では、第１のパケット（あるいは以後の反復時では、次のパケット）がメモリ１１から読み取られ、送信機１２に伝送される。ステップ２０５では、制御装置はＺｎ＋１の値を計算し、テストはＺｎ＋１≦０であるかどうかに関して、ステップ２０６で実行される。テストに合格すると、受信機が、このパケットを受信するとすぐに復号を開始するのが安全であることが知られる。したがって、ステップ２０７では、制御装置は受信機に送信される「開始」メッセージを送信機に送信する。受信機は、この開始メッセージを受信すると復号を始める。パケットカウンタは２０８で増分され、制御は、送信機がそれを受け入れる準備が完了するとすぐに、追加パケットが読み出され伝送される、ステップ２０４に戻る。
【００８２】
Ｔ０を計算するステップ２０１は、事前に実行され、値は記憶できるであろう。この手順が、Ｒの異なる値に対応するために、前述された方式と同様の方式でもちろん適応され得る。
【００８３】
このプロセスがＴ０で開始することは必須ではない。Ｔ１（その場合、第１のテストはＴ１≦０であるか？）で開始することができる、あるいは少なくとも２個（または３個以上）のパケットをつねにバッファに入れることを選ぶ場合には、Ｔ２等で開始できるであろう。
【００８４】
示されている例は符号化されたビデオのためでである、同じ方法は符号化された音声、または事実上、リアルタイムで再生される他のいかなるマテリアルにも適用できる。
【００８５】
必要に応じて、複数レートシステムにおいては、これらの方法は、本発明者らの国際特許出願ＷＯ０４／０８６７２１号に記載されているレート切り替え方法と組み合わせて用いられてもよい。
【図面の簡単な説明】
【００８６】
【図１】本発明を具現化する伝送システムのブロック図である。
【図２】タイミング図である。
【図３】図１に示されている制御装置の動作を説明するフローチャートである。
【図４】制御装置の動作の代替モードを説明するフローチャートである。
【図５】さらに追加のバージョンを説明するフローチャートである。
【技術分野】
【０００１】
本発明は、ビデオ、リアルタイムで再生される他のマテリアルの音声等の記録されたマテリアルを、ネットワーク上で伝送するための方法及び装置に関する。
【発明の開示】
【０００２】
本発明の１つの態様によると、
−記録の伝送を開始することと、
−受信機バッファ内に受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備え、
バッファアンダーフロー(buffer underflow)が発生しないように再生を開始するポイントを決定するために記録全体を分析するステップと、このポイントに達したときだけに再生を開始するステップと、により特徴付けられる、記録を伝送する方法が提供される。
【０００３】
別の態様では、本発明は、
−記録の伝送を開始することと、
−受信機バッファ内に受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備え、
記録が、任意の長さの続くセクションのタイミングエラーの最大より大きいか又は等しい再生時間間隔をカバーするという条件を満たす、記録の最初に第１のセクションを特定するために記録全体を分析するステップであって、各タイミングエラーがそれぞれの続くセクションの伝送時間がその再生時間間隔を超える範囲として定義されるものと、該受信機に、前記第１のセクションが受信された後にだけ再生を開始させるステップと、によって特徴付けられる、記録を伝送する方法を提供する。
【０００４】
本発明の追加の態様は、特許請求の範囲に述べられている。
【０００５】
本発明のいくつかの実施形態は、添付図面を参照し、ここに一例として説明される。
【発明を実施するための最良の形態】
【０００６】
図１では、ストリーマ１が、それぞれが、ＩＴＵ規格Ｈ．２６１またはＨ．２６３、あるいはＩＳＯ ＭＰＥＧ規格の内の１つに定められるアルゴリズムのような、従来の圧縮アルゴリズムを使用して符号化されているビデオシーケンスの圧縮バージョンであるファイルが記憶される、メモリ（store）１１を含む（またはメモリ１１にアクセスする）。当然、追加ビデオシーケンスの類似した記録を記憶してよいが、これは動作原理にとっては重要ではない。
【０００７】
「ビットレート」によって、ここでは元のエンコーダによって生成され、最終的なデコーダによって消費されるビットレートが意味される。一般的には、これは、伝送側ビットレートと呼ばれる、ストリーマが実際に伝送する速度と同じではない。これらのファイルが可変ビットレート（ＶＢＲ）で作成される−つまり、ビデオの任意の特定のフレームのために生成されるビット数がピクチャコンテンツに依存することにも留意する必要がある。その結果、前記の低（など）ビットレートに対する参照は、平均ビットレートを参照する。
【０００８】
サーバは、ネットワーク２を介してデータを端末３に出力するのに役立つ送信機１２を有する。該送信機は、おそらくＴＣＰ／ＩＰ等の周知のプロトコルで動作する従来のものである。制御装置１３はある特定のシーケンスの配信のために端末から要求を受信し、送信機がそれらを受信できる限り、送信機１２に送信するためにメモリ１１からデータのパケットを読み取るために従来の方式で働く。ここでは、単一のフレームのために複数のパケットを生成する可能性は排除されないが、データは別々のパケット、多くの場合ビデオのフレームあたり１パケットとして、読み出されると仮定される。（原則的には単一のパケットが複数のフレームのためのデータを含むことは可能であるが、これは通常、実際にはそれほど重要ではない。）
これらのパケットが、ネットワーク２で使用される任意のパケット構造に必ずしも関連していないことに留意されたい。
【０００９】
端末３は、受信機３１、バッファ３２及びデコーダ３３を有する。
【００１０】
（ＴＣＰ／ＩＰネットワークを含む）いくつかのネットワークは、使用可能な伝送側データレートが、ネットワークでのロードの程度に従って変動するという特徴を有する。
【００１１】
何らかの理論的な説明がこの時点で望ましい。
【００１２】
図２に示されているように、符号化されたビデオシーケンスはＮ個のパケットからなる。各パケットは時間指数ｔｉ（ｉ＝０．．．Ｎ−１）を含むヘッダを有し（リアルディスプレイ時間に関して−例えば、これはビデオフレーム番号である場合があるであろう）、ｂｉビットを含む。この分析は、パケットｉが、それが復号できる前に完全に受信されていなければならないと仮定する（つまり、最初にパケット全体をバッファに入れなければならない）。
【００１３】
単純なケースでは、各パケットは１つのフレームに対応し、タイムスタンプｔｉはすべてのｉについて単調に、つまりｔｉ＋１＞ｔｉで増加する。しかしながら、フレームが２つ以上パケットを増加できる場合（各々同じｔｉで）ｔｉ＋１≧ｔｉである。フレームが（ＭＰＥＧにおいてのように）捕捉及び表示シーケンスを使い切ることがある場合には、ｔｉは単調に増加しない。また、実際には、いくつかのフレームが削除されてよく、その結果ｔｉの特定の値のためのフレームがないであろう。
【００１４】
これらの時間は相対的である。受信機がパケット０を受信し、時間ｔｒｅｆ＋ｔ０でパケット０の復号を開始すると仮定する。ｔｒｅｆ＋ｔｇという「今の時間」に、受信機はパケットｔｇ（及び、場合によってはさらに多くのパケット）も受信し、パケットｇの復号を開始したところである。
【００１５】
パケットｇからｈ−１はバッファ内にある。（単純なケースでは）ｈ＝ｇ＋１である場合には、バッファの中にパケットｇだけが含まれることに留意されたい。時間ｔｒｅｆ＋ｔｊでは、デコーダはパケットｊの復号を開始することを要求される。したがって、時間ｔｒｅｆ＋ｔｊでは、デコーダはパケットｊを含むまですべてのパケットを受信することを必要とする。
【００１６】
現在から
【数１】
【００１７】
まで使用可能な時間。
【００１８】
その時間内で送信されるデータは、パケットｈからｊまでのための時間であり、つまり、
【数２】
【００１９】
伝送レートＲで以下の伝送持続時間を必要とするであろう。
【数３】
【００２０】
これは、この伝送持続時間が使用可能な時間以下の場合にだけ、つまり現在使用可能な伝送レートＲが不平等を満たすときにだけ可能である。
【数４】
【００２１】
これが、パケットｊの満足のいく受信及び復号の条件であることに留意されたい。残りのシーケンスの全体の満足のいく伝送には、すべてのｊ＝ｈ．．．Ｎ−１についてこの条件が満たされることが必要になる。
【００２２】
明らかになる理由から、方程式（４）は以下のとおりに書き換えられる。
【数５】
【数６】
【００２３】
の場合
【数７】
【００２４】
であることに留意されたい。
【００２５】
また、
【数８】
【００２６】
を定義する。
【００２７】
ｔｈ−１−ｔｇが、バッファ内で最も最近受信されたパケットのタイムスタンプと、バッファ内で最も最近にではなく受信されたパケット−つまり、ちょうど復号し始めたパケット−のタイムスタンプの差異であることに留意されたい。
【００２８】
その結果、条件は、
【数９】
【００２９】
である。
【００３０】
最後のパケットＮ−１までの伝送が成功した場合、この条件は任意の考えられるｊについて満たさなければならない。つまり、
【数１０】
【００３１】
方程式（７）の左側は、パケットｈの伝送からシーケンスの最後までに発生する可能性のある最大タイミングエラーを表し、該条件は、事実上、その現在の内容を考えてこのエラーがそれを収容する受信機バッファの能力を超えてはならないと述べる。便宜上、方程式（７）の左側をＴｈと名付ける−つまり、
【数１１】
【００３２】
したがって、方程式（７）は以下のように書かれてもよい。
【数１２】
【００３３】
時間ｔｇ＝ｔ０での状況、つまりデコーダが第１のパケットの復号を開始するときを考える。一般的なケースでは、前記条件は、バッファ（ｈ＝１）内に唯一のパケットがあるときに満たされないであろう。受信機は、それが復号を開始する前に、バッファコンテンツが満足のいくレベルに達するのを待機する。前記条件を使用すると、受信機は少なくともバッファがパケットＨ−１を含むまで待機しなければならず、この場合Ｈは以下の条件が満たされるｈの最小値であることが明らかになる。
【数１３】
【００３４】
本発明の本実施形態では、制御装置１３の機能の内の１つは、それがパケットを送信機１２に伝送するたびに、方程式１０で具現化されたテストを評価するという点である。
【００３５】
図３は、制御装置の動作を示すフローチャートである。ステップ１０１では、パケットカウンタがリセットされる。その結果（１０２）、第１のパケット（または以後の反復では、次のパケット）がメモリ１１から読み取られ、送信機１２に伝送される。ステップ１０３では、制御装置はＴｎの値を計算する。この点では、カウンタｎは伝送された最後のパケットを指すが、方程式（１０）はｈ−１である最後に伝送されたパケットについて定式化される。その結果、ステップ１０３の計算はＴｎ＋１のものであり、ステップ１０４で実行されるテストは、
【数１４】
【００３６】
であるかどうかである。
【００３７】
このテストに合格しないと、パケットカウンタは１０６で増分され、送信機がそれを受信する準備が完了するやいなや、追加のパケットが読み出され伝送される、ステップ１０２に制御が戻る。テストに合格すると、受信機がこのパケットを受信するやいなや復号を安全に開始できることが知られる。したがって、ステップ１０５では、制御装置は受信機に送信される「開始」メッセージを送信機に送信する。受信機はこの開始メッセージを受信すると、復号を開始する。メッセージが、それらが伝送されたのとは異なる順序で受信される可能性がある場合には、復号を開始する前にパケットｎが実際に受信されたことを受信機がチェックできるように、開始メッセージはパケットインデックスｎを含む必要がある。代わりに、送信機は受信機にＴｎ＋１という値を伝送でき、受信機自体がテストを実行する。
【００３８】
「開始」メッセージの伝送に続き、パケットカウンタは１０７で増分され、別のフレームは１０８で伝送される。これらのステップは、ファイルの最後に到達するまで繰り返され、これは１０９で認識され、プロセスは１１０で終了する。
【００３９】
前記説明では、制御装置が、送信機にパケットを伝送するたびにこの計算を実行すると仮定しており、計算上、きわめて集約的である。代替策は、計算をあまり頻繁にではなく、おそらく５パケットに１度、実行することであり、それは計算量を削減するが、必要とされる以上のフレームをバッファに入れることになる可能性がある。
【００４０】
別の代替策は、それがそうすることができるとすぐに（つまり、次のパケットを待機せずに）計算を完了し、その結果受信機に（開始するパケット番号とともに）開始メッセージを伝送することである。さらに追加の代替策は、あらゆるパケットを伝送する前に計算を実行することである。いったんｈという値が求められたら、次にパケット０をｈ−１に逆の順序（パケットｈ−１、パケットｈ−２、．．．パケット０）で伝送する。この場合、明示的な「開始」コマンドを伝送することは必要でなくなる。ＵＤＰトランスポートプロトコルをサポートする標準的な受信機は、パケットを並び替えることができ、パケット０が復号を開始する前に到達するまで自動的に待機するであろう。事実上、パケット１からｈ−１が伝送された後（その順序は重要ではない）までパケット０が保留されることで十分である。
【００４１】
しかしながら、これは待機期間中にデータレートＲを伝送する際の変更を考慮する可能性を排除するため、このような変更が予想されない場合にだけ満足が行く。
【００４２】
（方程式（３）を検査することにより）、レートＲの意義がパケットｈをｊへ送信するために要する時間を計算することにあることに留意されたい。したがって、パケット０をｈ−１へ伝送するために使用される実際のレートは、それがその結果に影響を及ぼさないため重要ではない。
【００４３】
別の魅力的なオプションは、事前に計算の可能な限り多くを実行することである。Ｒというただ１つの値だけが可能であるシステムが考えられる、或いは許可される場合には、ステップ１０３でのＴｎ＋１の計算及びステップ１０４のテストは、テストが合格するポイントまでのフレームごとに事前に実行することができ、結果は、例えばファイルの開始時に別個のフィールドにｎという対応する値を記録することによって、あるいはフレームｎ自体に特殊なフラグを取り付けることによって、ファイルの中に記録される。このようにして、図３では、ステップ１０３と１０４は、テスト「ｎという現在値はファイルに記憶されているｎという値に等しいか」あるいは「現在のフレームは開始フラグを含むか」によって、置換されるであろう。代わりに、別個のフィールド（またはフラグ）は受信機に転送され、この認識プロセスは受信側で実行できるであろう。
【００４４】
図４は、伝送データレートＲが変化する状況に対処するためのプロセスのフローチャートである。原則的に、これはパケットごとにＴｈ、及びこの値をパケットヘッダに記憶することを必要とする。しかしながら、実際には、この期間内にテストに合格すると確信があるシーケンスの始まりで、十分な数のフレーム（毎秒２５フレームでおそらく２５０フレーム）についてそれらを計算することが必要である。残念なことに、Ｔｈの計算は、この前処理の時点でもちろん未知であるＲという値を含む。したがって、（ＲＡが問題のファイルの平均ビットレートである場合に）例えばＲという考えられる値の選択についてＴｈを計算することによって先に進む。
【数１５】
【００４５】
したがって、各パケットｈはその中に記憶されたＴｈというこれらの５個の事前に計算された値を有する。（後述されるために）必要とされる場合、また、方程式（８）の中の最大が発生する相対的な時間位置、つまりＴｈが得られるｔｊｍａｘが方程式８のｊという値である
【数１６】
【００４６】
を記憶してもよい。
【００４７】
このケースでは、フローチャートは、フレームｎの伝送に続き以下のように進む。
【００４８】
１１２：使用可能な伝送レートＲを求めるために送信機１２を調べる。
【００４９】
１０３Ａ：Ｒが、Ｔｈが事前に計算されたレートの内の１つに一致する場合には、メモリからこの値を読み取る。
【００５０】
または−Ｒが一致しない場合には、Ｒの実際の値未満であるレートＲ１．．．Ｒ５の内の最高の値（Ｒ−）に一致し、それからＴｈを推定するＴｈ（及び必要とされる場合、ｔｈｍａｘ）の値をメモリから読み取る、かのどちらかである。
【００５１】
１０４Ａ：テスト
【数１７】
【００５２】
を適用し、この場合Δは固定された安全マージンである。
【００５３】
前記とおりに続行する。
【００５４】
Ｔｈの推定値は、単にＲ−と関連付けられた値Ｔｈ−を使用することによって実行できるであろう。これはうまくいくであろうが、それはＴｈを過大評価するであろうため、時折、受信機が必要以上に待機することになるであろう。別のオプションは、実際の値Ｒの各側にＲ１．．．Ｒ５の２つの値について記憶されたＴｈの値の間の、線形（または他の）補間であろう。しかしながら、我々の好ましい手法は以下に従って推定値を計算することである。
【数１８】
【００５５】
Ｒ−がＲの実際値未満であるレートＲ１．．．Ｒ５の内の最高の値である場合、Ｔｉ−はこのレートのために事前に計算されたＴｈであり、
【数１９】
【００５６】
は、Ｔｉ−が得られるｔｉからの時間（つまり、
【数２０】
【００５７】
の添付値）である。この方法が負の値を返す場合には、それをゼロに設定する。
【００５８】
Ｔｈはレートの非線形関数であるため、これが推定値に過ぎないことに留意されたい。しかしながら、この方法を使用すると、Ｔｉ−はつねに真の値より高く、（前記に示されたマージンΔが省略できるように）自動的に安全マージンを提供する。
【００５９】
これらの方程式は、符号化プロセスが１フレームについて（ｔｉが等しい）２個以上のパケットを生じさせる状況に、及びフレームが昇順ｔｉよりむしろ復号される必要のある順序で伝送される、双方向予測が行われるＭＰＥＧで遭遇する状況に有効であることに留意されたい。
【００６０】
ここで、数学が、パケットごとに個別に計算を実行するよりむしろ、先行するパケットについてすでに行われた計算を利用する同等な形式に変換される、代替実施形態を説明する。方程式（８）を思い出すと、
【数２１】
【００６１】
は、以下のように書き換えられてよい。
【数２２】
【００６２】
ファイルの始まりで真となるであろうＴｈ＋１≧０であるならば、これは以下になる。
【数２３】
【００６３】
あるいは一般的に、
【数２４】
【００６４】
ｂ＝ｈ−ａの場合には、
【数２５】
【００６５】
であり、
【数２６】
【数２７】
【００６６】
に代わる。
【数２８】
【００６７】
ａ＝０の場合には、
【数２９】
【００６８】
ａ＝１の場合には、
【数３０】
【００６９】
テスト
【数３１】
【００７０】
を検討すると、
【数３２】
【００７１】
に書き換えられてよい。
【００７２】
ａ＝０の場合、これは以下になる。
【数３３】
【００７３】
ｔ−１が、それが任意の値を与えることができるように（不等式の両側に現れる）意味のない量であることに留意すると、ｔ−１をｔ０に等しいと定めることは便利であり、そこから以下が得られる。
【数３４】
【００７４】
したがって、方程式（１０）のテスト
【数３５】
【００７５】
は、代わりに以下のように書くことができるであろう。
【数３６】
【００７６】
第１のテスト（ｈ＝１）がテスト１である場合には、
【数３７】
【００７７】
あるいは、
【数３８】
【００７８】
を定める場合には、第１のテストはＺ１≦０であるか？
第２のテストはＺ２≦０である。
【００７９】
Ｘ番目のテストはＺＸ≦０である。
【００８０】
しかしながら、
【数３９】
【００８１】
したがって、各テストは、図５のフローチャートに示されるように、Ｚの前の値を更新できる。第１に、ステップ２０１では、Ｔ０は方程式（８）に従って計算され、その場合（ステップ２０２）Ｚ０はＴ０に等しく設定される。ステップ２０３では、パケットカウンタがリセットされる。それから（２０４）では、第１のパケット（あるいは以後の反復時では、次のパケット）がメモリ１１から読み取られ、送信機１２に伝送される。ステップ２０５では、制御装置はＺｎ＋１の値を計算し、テストはＺｎ＋１≦０であるかどうかに関して、ステップ２０６で実行される。テストに合格すると、受信機が、このパケットを受信するとすぐに復号を開始するのが安全であることが知られる。したがって、ステップ２０７では、制御装置は受信機に送信される「開始」メッセージを送信機に送信する。受信機は、この開始メッセージを受信すると復号を始める。パケットカウンタは２０８で増分され、制御は、送信機がそれを受け入れる準備が完了するとすぐに、追加パケットが読み出され伝送される、ステップ２０４に戻る。
【００８２】
Ｔ０を計算するステップ２０１は、事前に実行され、値は記憶できるであろう。この手順が、Ｒの異なる値に対応するために、前述された方式と同様の方式でもちろん適応され得る。
【００８３】
このプロセスがＴ０で開始することは必須ではない。Ｔ１（その場合、第１のテストはＴ１≦０であるか？）で開始することができる、あるいは少なくとも２個（または３個以上）のパケットをつねにバッファに入れることを選ぶ場合には、Ｔ２等で開始できるであろう。
【００８４】
示されている例は符号化されたビデオのためでである、同じ方法は符号化された音声、または事実上、リアルタイムで再生される他のいかなるマテリアルにも適用できる。
【００８５】
必要に応じて、複数レートシステムにおいては、これらの方法は、本発明者らの国際特許出願ＷＯ０４／０８６７２１号に記載されているレート切り替え方法と組み合わせて用いられてもよい。
【図面の簡単な説明】
【００８６】
【図１】本発明を具現化する伝送システムのブロック図である。
【図２】タイミング図である。
【図３】図１に示されている制御装置の動作を説明するフローチャートである。
【図４】制御装置の動作の代替モードを説明するフローチャートである。
【図５】さらに追加のバージョンを説明するフローチャートである。
【特許請求の範囲】
【請求項１】
−記録の伝送を開始することと、
−受信機バッファに受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備える記録を伝送する方法であって、
バッファアンダーフローが発生しないように、再生を開始するポイントを決定するために記録の全体を分析するステップと、
このポイントに達したときにだけ再生を開始するステップと、
によって特徴付けられる、方法。
【請求項２】
−記録の伝送を開始することと、
−受信機バッファに受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備える記録を伝送する方法であって、
記録が、任意の長さの続くセクションのタイミングエラーの最大より大きいか又は等しい再生時間間隔をカバーするという条件を満たす、記録の始まりで第１のセクションを特定するために記録全体を分析し、各タイミングエラーが、それぞれの続くセクションの伝送時間がその再生時間間隔を超える範囲として定められるステップと、
前記受信機に、前記第１のセクションが受信された後にだけ再生を開始させるステップと、
によって特徴付けられる、方法。
【請求項３】
前記第１の部分の伝送後に、前記受信機に再生を開始する命令を伝送することをさらに備える、請求項２に記載の方法。
【請求項４】
前記第１のセクションを指定する命令を前記受信機に伝送することを備え、前記受信機が、それが、前記第１のセクションがバッファ内にあることを認識するときに再生を開始する、請求項２に記載の方法。
【請求項５】
前記分析は、
（ａ）前記送信機において、シーケンスの異なる部分について前記最大タイミングエラー値を計算することと、
（ｂ）前記受信機において、前記第１のセクションが前記バッファ内にある場合を認識するために、前記値を該バッファコンテンツと比較することと、
を備える、請求項２に記載の方法。
【請求項６】
前記第１のセクションの残りが伝送されるまで記録の初期の部分の伝送を保留することと、前記初期部分を伝送することとを備え、前記受信機は、前記初期部分が受信されるときにだけ再生を開始する、請求項２に記載の方法。
【請求項７】
事前に前記分析を実行することと、前記記録の中の前記識別されたセクションを記すこととを含む、請求項２、請求項３、請求項４及び請求項６のいずれか１項に記載の方法。
【請求項８】
前記分析は、複数の伝送データレートに対応するタイミングエラー値を事前に計算し、それらを記憶することと、及び以後そこから実際の伝送データレートに対応するエラー値を推定することとを含む、請求項２乃至請求項６のいずれか１項に記載の方法。
【請求項９】
前記分析は、前記記録の連続部分について評価されるタイミングエラーパラメータをテストすることを備え、タイミングエラーパラメータは、最初に記録の第１のまたは早期の部分に関して計算され、以後の部分についてのタイミングエラーパラメータは、前記部分について得られるパラメータを更新することによって得られる、請求項１乃至請求項８のいずれか１項に記載の方法。
【請求項１０】
前記記録はビデオ記録である、請求項１乃至請求項９のいずれか１項に記載の方法。
【請求項１１】
前記記録は音声記録である、請求項１乃至請求項１０のいずれか１項に記載の方法。
【請求項１】
−記録の伝送を開始することと、
−受信機バッファに受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備える記録を伝送する方法であって、
バッファアンダーフローが発生しないように、再生を開始するポイントを決定するために記録の全体を分析するステップと、
このポイントに達したときにだけ再生を開始するステップと、
によって特徴付けられる、方法。
【請求項２】
−記録の伝送を開始することと、
−受信機バッファに受信されたデータを保持することと、
−前記受信されたデータの再生を開始することと、
を備える記録を伝送する方法であって、
記録が、任意の長さの続くセクションのタイミングエラーの最大より大きいか又は等しい再生時間間隔をカバーするという条件を満たす、記録の始まりで第１のセクションを特定するために記録全体を分析し、各タイミングエラーが、それぞれの続くセクションの伝送時間がその再生時間間隔を超える範囲として定められるステップと、
前記受信機に、前記第１のセクションが受信された後にだけ再生を開始させるステップと、
によって特徴付けられる、方法。
【請求項３】
前記第１の部分の伝送後に、前記受信機に再生を開始する命令を伝送することをさらに備える、請求項２に記載の方法。
【請求項４】
前記第１のセクションを指定する命令を前記受信機に伝送することを備え、前記受信機が、それが、前記第１のセクションがバッファ内にあることを認識するときに再生を開始する、請求項２に記載の方法。
【請求項５】
前記分析は、
（ａ）前記送信機において、シーケンスの異なる部分について前記最大タイミングエラー値を計算することと、
（ｂ）前記受信機において、前記第１のセクションが前記バッファ内にある場合を認識するために、前記値を該バッファコンテンツと比較することと、
を備える、請求項２に記載の方法。
【請求項６】
前記第１のセクションの残りが伝送されるまで記録の初期の部分の伝送を保留することと、前記初期部分を伝送することとを備え、前記受信機は、前記初期部分が受信されるときにだけ再生を開始する、請求項２に記載の方法。
【請求項７】
事前に前記分析を実行することと、前記記録の中の前記識別されたセクションを記すこととを含む、請求項２、請求項３、請求項４及び請求項６のいずれか１項に記載の方法。
【請求項８】
前記分析は、複数の伝送データレートに対応するタイミングエラー値を事前に計算し、それらを記憶することと、及び以後そこから実際の伝送データレートに対応するエラー値を推定することとを含む、請求項２乃至請求項６のいずれか１項に記載の方法。
【請求項９】
前記分析は、前記記録の連続部分について評価されるタイミングエラーパラメータをテストすることを備え、タイミングエラーパラメータは、最初に記録の第１のまたは早期の部分に関して計算され、以後の部分についてのタイミングエラーパラメータは、前記部分について得られるパラメータを更新することによって得られる、請求項１乃至請求項８のいずれか１項に記載の方法。
【請求項１０】
前記記録はビデオ記録である、請求項１乃至請求項９のいずれか１項に記載の方法。
【請求項１１】
前記記録は音声記録である、請求項１乃至請求項１０のいずれか１項に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２００７−５３１３６５（Ｐ２００７−５３１３６５Ａ）
【公表日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願番号】特願２００７−５０４４５８（Ｐ２００７−５０４４５８）
【出願日】平成１７年３月１６日（２００５．３．１６）
【国際出願番号】ＰＣＴ／ＧＢ２００５／００１０１１
【国際公開番号】ＷＯ２００５／０９３９９５
【国際公開日】平成１７年１０月６日（２００５．１０．６）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
【公表日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願日】平成１７年３月１６日（２００５．３．１６）
【国際出願番号】ＰＣＴ／ＧＢ２００５／００１０１１
【国際公開番号】ＷＯ２００５／０９３９９５
【国際公開日】平成１７年１０月６日（２００５．１０．６）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
[ Back to top ]