-記録の伝送を開始することと、-受信機バッファに受信されたデータを保持することと、-前記受信されたデータの再生を開始することと、を備える記録を伝送する方法であって、バッファアンダーフローが発生しないように、再生を開始するポイントを決定するために記録の全体を分析するステップと、このポイントに達したときにだけ再生を開始するステップと、によって特徴付けられる、方法。-記録の伝送を開始することと、-受信機バッファに受信されたデータを保持することと、-前記受信されたデータの再生を開始することと、を備える記録を伝送する方法であって、記録が、任意の長さの続くセクションのタイミングエラーの最大より大きいか又は等しい再生時間間隔をカバーするという条件を満たす、記録の始まりで第1のセクションを特定するために記録全体を分析し、各タイミングエラーが、それぞれの続くセクションの伝送時間がその再生時間間隔を超える範囲として定められるステップと、前記受信機に、前記第1のセクションが受信された後にだけ再生を開始させるステップと、によって特徴付けられる、方法。前記第1の部分の伝送後に、前記受信機に再生を開始する命令を伝送することをさらに備える、請求項2に記載の方法。前記第1のセクションを指定する命令を前記受信機に伝送することを備え、前記受信機が、それが、前記第1のセクションがバッファ内にあることを認識するときに再生を開始する、請求項2に記載の方法。前記分析は、a前記送信機において、シーケンスの異なる部分について前記最大タイミングエラー値を計算することと、b前記受信機において、前記第1のセクションが前記バッファ内にある場合を認識するために、前記値を該バッファコンテンツと比較することと、を備える、請求項2に記載の方法。前記第1のセクションの残りが伝送されるまで記録の初期の部分の伝送を保留することと、前記初期部分を伝送することとを備え、前記受信機は、前記初期部分が受信されるときにだけ再生を開始する、請求項2に記載の方法。事前に前記分析を実行することと、前記記録の中の前記識別されたセクションを記すこととを含む、請求項2、請求項3、請求項4及び請求項6のいずれか1項に記載の方法。前記分析は、複数の伝送データレートに対応するタイミングエラー値を事前に計算し、それらを記憶することと、及び以後そこから実際の伝送データレートに対応するエラー値を推定することとを含む、請求項2乃至請求項6のいずれか1項に記載の方法。前記分析は、前記記録の連続部分について評価されるタイミングエラーパラメータをテストすることを備え、タイミングエラーパラメータは、最初に記録の第1のまたは早期の部分に関して計算され、以後の部分についてのタイミングエラーパラメータは、前記部分について得られるパラメータを更新することによって得られる、請求項1乃至請求項8のいずれか1項に記載の方法。前記記録はビデオ記録である、請求項1乃至請求項9のいずれか1項に記載の方法。前記記録は音声記録である、請求項1乃至請求項10のいずれか1項に記載の方法。図1では、ストリーマ1が、それぞれが、ITU規格H.261またはH.263、あるいはISOMPEG規格の内の1つに定められるアルゴリズムのような、従来の圧縮アルゴリズムを使用して符号化されているビデオシーケンスの圧縮バージョンであるファイルが記憶される、メモリstore11を含むまたはメモリ11にアクセスする。当然、追加ビデオシーケンスの類似した記録を記憶してよいが、これは動作原理にとっては重要ではない。ビットレートによって、ここでは元のエンコーダによって生成され、最終的なデコーダによって消費されるビットレートが意味される。一般的には、これは、伝送側ビットレートと呼ばれる、ストリーマが実際に伝送する速度と同じではない。これらのファイルが可変ビットレートVBRで作成される-つまり、ビデオの任意の特定のフレームのために生成されるビット数がピクチャコンテンツに依存することにも留意する必要がある。その結果、前記の低などビットレートに対する参照は、平均ビットレートを参照する。サーバは、ネットワーク2を介してデータを端末3に出力するのに役立つ送信機12を有する。該送信機は、おそらくTCP/IP等の周知のプロトコルで動作する従来のものである。制御装置13はある特定のシーケンスの配信のために端末から要求を受信し、送信機がそれらを受信できる限り、送信機12に送信するためにメモリ11からデータのパケットを読み取るために従来の方式で働く。ここでは、単一のフレームのために複数のパケットを生成する可能性は排除されないが、データは別々のパケット、多くの場合ビデオのフレームあたり1パケットとして、読み出されると仮定される。原則的には単一のパケットが複数のフレームのためのデータを含むことは可能であるが、これは通常、実際にはそれほど重要ではない。これらのパケットが、ネットワーク2で使用される任意のパケット構造に必ずしも関連していないことに留意されたい。端末3は、受信機31、バッファ32及びデコーダ33を有する。TCP/IPネットワークを含むいくつかのネットワークは、使用可能な伝送側データレートが、ネットワークでのロードの程度に従って変動するという特徴を有する。何らかの理論的な説明がこの時点で望ましい。図2に示されているように、符号化されたビデオシーケンスはN個のパケットからなる。各パケットは時間指数tii=0...N-1を含むヘッダを有しリアルディスプレイ時間に関して-例えば、これはビデオフレーム番号である場合があるであろう、biビットを含む。この分析は、パケットiが、それが復号できる前に完全に受信されていなければならないと仮定するつまり、最初にパケット全体をバッファに入れなければならない。単純なケースでは、各パケットは1つのフレームに対応し、タイムスタンプtiはすべてのiについて単調に、つまりti1>tiで増加する。しかしながら、フレームが2つ以上パケットを増加できる場合各々同じtiでti1≧tiである。フレームがMPEGにおいてのように捕捉及び表示シーケンスを使い切ることがある場合には、tiは単調に増加しない。また、実際には、いくつかのフレームが削除されてよく、その結果tiの特定の値のためのフレームがないであろう。これらの時間は相対的である。受信機がパケット0を受信し、時間treft0でパケット0の復号を開始すると仮定する。treftgという今の時間に、受信機はパケットtg及び、場合によってはさらに多くのパケットも受信し、パケットgの復号を開始したところである。パケットgからh-1はバッファ内にある。単純なケースではh=g1である場合には、バッファの中にパケットgだけが含まれることに留意されたい。時間treftjでは、デコーダはパケットjの復号を開始することを要求される。したがって、時間treftjでは、デコーダはパケットjを含むまですべてのパケットを受信することを必要とする。現在からまで使用可能な時間。その時間内で送信されるデータは、パケットhからjまでのための時間であり、つまり、伝送レートRで以下の伝送持続時間を必要とするであろう。これは、この伝送持続時間が使用可能な時間以下の場合にだけ、つまり現在使用可能な伝送レートRが不平等を満たすときにだけ可能である。これが、パケットjの満足のいく受信及び復号の条件であることに留意されたい。残りのシーケンスの全体の満足のいく伝送には、すべてのj=h...N-1についてこの条件が満たされることが必要になる。明らかになる理由から、方程式4は以下のとおりに書き換えられる。の場合であることに留意されたい。また、を定義する。th-1-tgが、バッファ内で最も最近受信されたパケットのタイムスタンプと、バッファ内で最も最近にではなく受信されたパケット-つまり、ちょうど復号し始めたパケット-のタイムスタンプの差異であることに留意されたい。その結果、条件は、である。最後のパケットN-1までの伝送が成功した場合、この条件は任意の考えられるjについて満たさなければならない。つまり、方程式7の左側は、パケットhの伝送からシーケンスの最後までに発生する可能性のある最大タイミングエラーを表し、該条件は、事実上、その現在の内容を考えてこのエラーがそれを収容する受信機バッファの能力を超えてはならないと述べる。便宜上、方程式7の左側をThと名付ける-つまり、したがって、方程式7は以下のように書かれてもよい。時間tg=t0での状況、つまりデコーダが第1のパケットの復号を開始するときを考える。一般的なケースでは、前記条件は、バッファh=1内に唯一のパケットがあるときに満たされないであろう。受信機は、それが復号を開始する前に、バッファコンテンツが満足のいくレベルに達するのを待機する。前記条件を使用すると、受信機は少なくともバッファがパケットH-1を含むまで待機しなければならず、この場合Hは以下の条件が満たされるhの最小値であることが明らかになる。本発明の本実施形態では、制御装置13の機能の内の1つは、それがパケットを送信機12に伝送するたびに、方程式10で具現化されたテストを評価するという点である。図3は、制御装置の動作を示すフローチャートである。ステップ101では、パケットカウンタがリセットされる。その結果102、第1のパケットまたは以後の反復では、次のパケットがメモリ11から読み取られ、送信機12に伝送される。ステップ103では、制御装置はTnの値を計算する。この点では、カウンタnは伝送された最後のパケットを指すが、方程式10はh-1である最後に伝送されたパケットについて定式化される。その結果、ステップ103の計算はTn1のものであり、ステップ104で実行されるテストは、であるかどうかである。このテストに合格しないと、パケットカウンタは106で増分され、送信機がそれを受信する準備が完了するやいなや、追加のパケットが読み出され伝送される、ステップ102に制御が戻る。テストに合格すると、受信機がこのパケットを受信するやいなや復号を安全に開始できることが知られる。したがって、ステップ105では、制御装置は受信機に送信される開始メッセージを送信機に送信する。受信機はこの開始メッセージを受信すると、復号を開始する。メッセージが、それらが伝送されたのとは異なる順序で受信される可能性がある場合には、復号を開始する前にパケットnが実際に受信されたことを受信機がチェックできるように、開始メッセージはパケットインデックスnを含む必要がある。代わりに、送信機は受信機にTn1という値を伝送でき、受信機自体がテストを実行する。開始メッセージの伝送に続き、パケットカウンタは107で増分され、別のフレームは108で伝送される。これらのステップは、ファイルの最後に到達するまで繰り返され、これは109で認識され、プロセスは110で終了する。前記説明では、制御装置が、送信機にパケットを伝送するたびにこの計算を実行すると仮定しており、計算上、きわめて集約的である。代替策は、計算をあまり頻繁にではなく、おそらく5パケットに1度、実行することであり、それは計算量を削減するが、必要とされる以上のフレームをバッファに入れることになる可能性がある。別の代替策は、それがそうすることができるとすぐにつまり、次のパケットを待機せずに計算を完了し、その結果受信機に開始するパケット番号とともに開始メッセージを伝送することである。さらに追加の代替策は、あらゆるパケットを伝送する前に計算を実行することである。いったんhという値が求められたら、次にパケット0をh-1に逆の順序パケットh-1、パケットh-2、...パケット0で伝送する。この場合、明示的な開始コマンドを伝送することは必要でなくなる。UDPトランスポートプロトコルをサポートする標準的な受信機は、パケットを並び替えることができ、パケット0が復号を開始する前に到達するまで自動的に待機するであろう。事実上、パケット1からh-1が伝送された後その順序は重要ではないまでパケット0が保留されることで十分である。しかしながら、これは待機期間中にデータレートRを伝送する際の変更を考慮する可能性を排除するため、このような変更が予想されない場合にだけ満足が行く。方程式3を検査することにより、レートRの意義がパケットhをjへ送信するために要する時間を計算することにあることに留意されたい。したがって、パケット0をh-1へ伝送するために使用される実際のレートは、それがその結果に影響を及ぼさないため重要ではない。別の魅力的なオプションは、事前に計算の可能な限り多くを実行することである。Rというただ1つの値だけが可能であるシステムが考えられる、或いは許可される場合には、ステップ103でのTn1の計算及びステップ104のテストは、テストが合格するポイントまでのフレームごとに事前に実行することができ、結果は、例えばファイルの開始時に別個のフィールドにnという対応する値を記録することによって、あるいはフレームn自体に特殊なフラグを取り付けることによって、ファイルの中に記録される。このようにして、図3では、ステップ103と104は、テストnという現在値はファイルに記憶されているnという値に等しいかあるいは現在のフレームは開始フラグを含むかによって、置換されるであろう。代わりに、別個のフィールドまたはフラグは受信機に転送され、この認識プロセスは受信側で実行できるであろう。図4は、伝送データレートRが変化する状況に対処するためのプロセスのフローチャートである。原則的に、これはパケットごとにTh、及びこの値をパケットヘッダに記憶することを必要とする。しかしながら、実際には、この期間内にテストに合格すると確信があるシーケンスの始まりで、十分な数のフレーム毎秒25フレームでおそらく250フレームについてそれらを計算することが必要である。残念なことに、Thの計算は、この前処理の時点でもちろん未知であるRという値を含む。したがって、RAが問題のファイルの平均ビットレートである場合に例えばRという考えられる値の選択についてThを計算することによって先に進む。したがって、各パケットhはその中に記憶されたThというこれらの5個の事前に計算された値を有する。後述されるために必要とされる場合、また、方程式8の中の最大が発生する相対的な時間位置、つまりThが得られるtjmaxが方程式8のjという値であるを記憶してもよい。このケースでは、フローチャートは、フレームnの伝送に続き以下のように進む。112:使用可能な伝送レートRを求めるために送信機12を調べる。103A:Rが、Thが事前に計算されたレートの内の1つに一致する場合には、メモリからこの値を読み取る。または-Rが一致しない場合には、Rの実際の値未満であるレートR1...R5の内の最高の値R-に一致し、それからThを推定するTh及び必要とされる場合、thmaxの値をメモリから読み取る、かのどちらかである。104A:テストを適用し、この場合Δは固定された安全マージンである。前記とおりに続行する。Thの推定値は、単にR-と関連付けられた値Th-を使用することによって実行できるであろう。これはうまくいくであろうが、それはThを過大評価するであろうため、時折、受信機が必要以上に待機することになるであろう。別のオプションは、実際の値Rの各側にR1...R5の2つの値について記憶されたThの値の間の、線形または他の補間であろう。しかしながら、我々の好ましい手法は以下に従って推定値を計算することである。R-がRの実際値未満であるレートR1...R5の内の最高の値である場合、Ti-はこのレートのために事前に計算されたThであり、は、Ti-が得られるtiからの時間つまり、の添付値である。この方法が負の値を返す場合には、それをゼロに設定する。Thはレートの非線形関数であるため、これが推定値に過ぎないことに留意されたい。しかしながら、この方法を使用すると、Ti-はつねに真の値より高く、前記に示されたマージンΔが省略できるように自動的に安全マージンを提供する。これらの方程式は、符号化プロセスが1フレームについてtiが等しい2個以上のパケットを生じさせる状況に、及びフレームが昇順tiよりむしろ復号される必要のある順序で伝送される、双方向予測が行われるMPEGで遭遇する状況に有効であることに留意されたい。ここで、数学が、パケットごとに個別に計算を実行するよりむしろ、先行するパケットについてすでに行われた計算を利用する同等な形式に変換される、代替実施形態を説明する。方程式8を思い出すと、は、以下のように書き換えられてよい。ファイルの始まりで真となるであろうTh1≧0であるならば、これは以下になる。あるいは一般的に、b=h-aの場合には、であり、に代わる。a=0の場合には、a=1の場合には、テストを検討すると、に書き換えられてよい。a=0の場合、これは以下になる。t-1が、それが任意の値を与えることができるように不等式の両側に現れる意味のない量であることに留意すると、t-1をt0に等しいと定めることは便利であり、そこから以下が得られる。したがって、方程式10のテストは、代わりに以下のように書くことができるであろう。第1のテストh=1がテスト1である場合には、あるいは、を定める場合には、第1のテストはZ1≦0であるか第2のテストはZ2≦0である。X番目のテストはZX≦0である。しかしながら、したがって、各テストは、図5のフローチャートに示されるように、Zの前の値を更新できる。第1に、ステップ201では、T0は方程式8に従って計算され、その場合ステップ202Z0はT0に等しく設定される。ステップ203では、パケットカウンタがリセットされる。それから204では、第1のパケットあるいは以後の反復時では、次のパケットがメモリ11から読み取られ、送信機12に伝送される。ステップ205では、制御装置はZn1の値を計算し、テストはZn1≦0であるかどうかに関して、ステップ206で実行される。テストに合格すると、受信機が、このパケットを受信するとすぐに復号を開始するのが安全であることが知られる。したがって、ステップ207では、制御装置は受信機に送信される開始メッセージを送信機に送信する。受信機は、この開始メッセージを受信すると復号を始める。パケットカウンタは208で増分され、制御は、送信機がそれを受け入れる準備が完了するとすぐに、追加パケットが読み出され伝送される、ステップ204に戻る。T0を計算するステップ201は、事前に実行され、値は記憶できるであろう。この手順が、Rの異なる値に対応するために、前述された方式と同様の方式でもちろん適応され得る。このプロセスがT0で開始することは必須ではない。T1その場合、第1のテストはT1≦0であるかで開始することができる、あるいは少なくとも2個または3個以上のパケットをつねにバッファに入れることを選ぶ場合には、T2等で開始できるであろう。示されている例は符号化されたビデオのためでである、同じ方法は符号化された音声、または事実上、リアルタイムで再生される他のいかなるマテリアルにも適用できる。必要に応じて、複数レートシステムにおいては、これらの方法は、本発明者らの国際特許出願WO04/086721号に記載されているレート切り替え方法と組み合わせて用いられてもよい。