(57)【要約】トランスミッターがＦＥＣを用いてエンコードされたメディア・ストリームをレシーバーに送信する通信システムは、前記トランスミッターでエンコードされたメディア・ストリームをデコードするための、前記トランスミッターにある少なくとも１つの仮想ＦＥＣデコーダを含んでいる。トランスミッターは、少なくとも１つの仮想ＦＥＣデコーダの出力が与えられるレシーバーに何の最適化信号を供給するかを決定し、これらの最適化信号をレシーバーに信号送信する。最適化信号は、メディア消費量の減速、可変バッファリング・パラメーターの指示、及び／又は、ＦＥＣ及びソースのデータ順序の指示を含みうる。
2011524698.tif 000002
【特許請求の範囲】
【請求項１】
トランスミッターがＦＥＣを使用してエンコードされたメディア・ストリームをレシーバーに送信する通信システムであって、
前記トランスミッターでエンコードされた前記メディア・ストリームをデコードするための、前記トランスミッターにある少なくとも１つの仮想ＦＥＣデコーダと、
少なくとも１つの仮想ＦＥＣデコーダの出力が与えられるレシーバーに何の最適化信号を供給するかを決定するための、前記トランスミッターにあるロジックと、
前記レシーバーに前記最適化信号を送信するための、前記トランスミッターにあるロジックと
を備える。
【請求項２】
前記最適化信号は、メディア消費量の減速を含む請求項１に記載の通信システム。
【請求項３】
前記最適化信号は、可変のバッファリング・パラメーターの指示を含む請求項１に記載の通信システム。
【請求項４】
前記最適化信号は、ＦＥＣ及びソースのデータ順序の指示を含む請求項１に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願のクロス・リファレンス
本開示は、以下の本発明の譲受人に譲渡された出願／/特許と関係し得る。
【０００２】
この出願は、「仮想ＦＥＣデコーダ及び初期デコーディング」と題され、２００８年６月１２に出願された同時係属中の米国仮特許出願６１／０６１，０７３号の優先権を主張し、全ての目的のために、あたかもこの文書に全て示されているかのように、それは参照によってここによって組み込まれる。
【０００３】
米国特許出願１１／２２６，９１９（現在は米国特許７，２３３，２６４）も参照によって組込まれる。
【０００４】
「前方誤り訂正（ＦＥＣ）エンコード及びストリーミング」と題された米国特許出願１１／４２３，３９１も参照によって組込まれる。
【０００５】
これらの出願/特許の各々の開示は、すべての目的のために、それらの全体の参照によって、ここに組み入れられる。
【０００６】
本発明は、一般にはメディア提供、そして特にストリーミング・メディアを伝達するトランスミッターとデコーディング処理で使用するレシーバーに信号を送信するデコーディングに関する。
【背景技術】
【０００７】
パケット・ストリームを産出するメディア・サーバーを想定する。パケット・ストリームは、各パケットとある正確な相対的タイミングに関連付けされている。この正確な相対的タイミングは、レシーバーでメディア・クライアントに転送されるパケット・ストリームが復元される前に、レシーバーで復元される必要がある。例えば、固定ビットレートは維持される必要があるかもしれない。
【０００８】
パケット・ストリームに加えて、ＦＥＣデコーダによって生成されるあるパリティ・データが送られるかもしれない。ＦＥＣが適用される場合、エンコーダは、修理データを生成するためにある量のパケットを格納する。そのための修理データが生成されるデータの収集は、ソース・ブロックと呼ばれる。
【０００９】
ストレージの持続時間だけでなくソース・ブロックを生成するために保存されるデータ量もフレキシブルかもしれない。
【００１０】
さらに、データとＦＥＣデータを多重送信し、それからそれらをチャネルによって送信する、それはパケットのうちいくつかを失うかもしれない、マルチプレクサにメディア・パケットが転送される前に、あるソース・ブロックからのメディア・パケットが他のソース・ブロックからのパケットにインタリーブされるかもしれない。さらに、データ・パケットの送出順序は、ＦＥＣエンコードプロセスによって変更されるかもしれない。
【００１１】
各パケットが各ソース・ブロックでの位置だけでなくソース・ブロック・ナンバーとタイプを確認するために十分な情報を持っていると想定する。
【００１２】
そのような手続きがされる場合があるいくつかの例：
−  アプリケーション・レイヤＦＥＣ[3GPP TS26.346]によるＭＢＳストリーミング配信、ここで、ＵＤＰペイロードのフレキシブルな量は、シングル・ソース・ブロックに挿入することができる。
【００１３】
−  ＩＰＴＶにおけるアプリケーション・レイヤＦＥＣ、例えばＤＶＢ−ＩＰＴＶ[ETSI TS102 034 v1.3.1]、アネックスＥ
−  ドキュメントＤＶＢ ＴＭ−…に規定されるラプター符号又はリード・ソロモン符号と共に使用される、ＤＶＢ−ＳＨにおけるＭＰＥ−ＩＦＥＣ
−  ドラフトＥＴＳＩ ＥＮ ＸＸＸＸＸＸ．で規定されるＤＶＢ−ＲＣＳにおけるリンク・レイヤＦＥＣ
−  …の使用を伴うＴＩＡ−１０９９、メディアフロー（ＭｅｄｉａＦｌｏ）
−  他のもの
レシーバーでは、ＦＥＣデコーダは、あるソース・ブロックから受信したソースと修理データを集めて、ソース・ブロックのソース・パケットを復元するためにこの情報を使用する。
【００１４】
損失から回復するために生成されたＦＥＣ修理パケットを使用するデコーダでは、デコーダは、受信したデータ・パケット及び修理パケットを格納する。デコーダが十分に長く待っている場合のみ、あるソース・ブロックと関連する全ての修復パケット及び全てのデータが受信されるようにするため、送信されている情報を最良に使用していることをデコーダは保証することができる。さらに、ＦＥＣデコーダは、それがソース・データの相対的タイミングを復元したことを確かめるべきである。
【００１５】
これが起こることを保証するために、そのような情報を利用するデコーダは、次を必要とする:
−  デコーダで、あるソース・ブロックのパケットをバッファリングしなければならない最大時間
−  全ての受信したソース及び修理データを格納することができることを保証する十分なストレージ
トランスミッターは、デコーダに信号を送信するか、そうでなければ、デコーダは、次の２つの値で予め設定される：
−  初期バッファリング遅れ  最小バッファ時間(min-buffer-time)
−  最大のバッファ・サイズ(maximum buffer size)  最大バッファ・サイズ(max-buffer-size)
ＦＥＣデコーダは、それから、ストリームを得た後に以下のように動作する:最初のデータ・パケットの受信とともに、それは、正確な最小バッファ時間のためにＦＥＣデコーダでデータ・パケットを格納し、このソース・ブロックでソース・パケットを回復することを試みるために、このソース・ブロックのために受信した全てのデータを考慮する。デコーディングに成功したかどうかにかかわらず、ＦＥＣデコーダは、最小バッファ時間の後に最初の受信データ・パケットを放出し、それから、メディア・クライアントへのさらなるデータ・パケットの放出について厳格なタイミングを維持する。そうすることによって、ＦＥＣデコーダは、次を確信する。
【００１６】
−  それは、すべての将来のパケットに対し厳格なタイミングを遂行することができる。
【００１７】
−  その最大バッファ・サイズは、受け取られたすべてのデータ・パケットを処理するのに十分である。
【００１８】
したがって、それのＦＥＣ符号化演算、遅延、インタリーブ、及び多重伝送のオペレーションは、上記のアクションを実行することによって、デコーダがタスクを完了することができるようなものであることを保証することは、送信器の任務である。
【００１９】
上記の観点からのデコーダ・アクションは、「仮想ＦＥＣデコーダ」と呼ばれ、また、トランスミッターは、パラメータ（最小バッファ時間、最大バッファ・サイズ）を持つ仮想ＦＥＣデコーダによって、送信されたソース＋ＦＥＣストリームを処理することができ、アウトゴーイング(outgoing)・ストリームは、オリジナルのメディア・ストリームと同じ厳格な相対的タイミングを持つことができ、パケットが失われないことを保証する。
【発明の概要】
【００２０】
ＦＥＣを使用してエンコードされたメディア・ストリームをトランスミッターがレシーバーに送信する通信システムは、前記トランスミッターでエンコードされた前記メディア・ストリームをデコードするための、前記トランスミッターにある少なくとも１つの仮想ＦＥＣデコーダを含んでいる。トランスミッターは、少なくとも１つの仮想ＦＥＣデコーダの出力が与えられるレシーバーに何の最適化信号を供給するかを決定し、これらの最適化信号をレシーバーに送信する。最適化信号は、メディア消費量の減速、可変のバッファリング・パラメーターの指示、および／またはＦＥＣ及びソースのデータ順序の指示を含みうる。
【００２１】
添付の図面とともに以下の詳細な説明は、本質のよりよい理解と本発明の利点を提供する。
【図面の簡単な説明】
【００２２】
【図１】従来の通信システムを示すブロック図。
【図２】仮想のデコーダを使用する従来の通信システムを示すブロック図。
【図３】デコーダに与えるためのデコーディング最適化信号を決定するための複数の仮想のデコーダをトランスミッターが使用する通信システムを示すブロック図。
【図４】ＤＶＢ−Ｈデコーディングを示すブロック図。
【図５】ＤＶＢ−ＳＨデコーディングを示すブロック図。
【発明を実施するための形態】
【００２３】
改良された通信システムをここに述べる。このシステムでは、トランスミッターは、デコーダのパフォーマンスを評価し、かつそのためにデコーダ最適化パラメータを決定するために仮想のデコーダを使用し、それらは、メディア・ストリームとともに、その後デコーダに伝えられ、メディア・ストリームをデコードし、かつそれをするためにデコーダによって使用される。
【００２４】
従来の「仮想ＦＥＣデコーダ」システムでは、データ・ストリームは、前方誤り訂正を使用してトランスミッターでエンコードされ、例えば、最小のバッファ時間（最小バッファ時間）及び最大のバッファ・サイズ（最大バッファ・サイズ）を考慮して、個々のストリームを正常にデコードできるのであれば、それがデコードする方法をトランスミッターが知るように、それは仮想ＦＥＣデコーダを通過する。そのような仮想ＦＥＣデコーダの一例は、3GPP TS26.346、節8.2.2.11で規定される。
【００２５】
オペレーションでは、一度、レシーバーは、新しいストリーム（例えば、新しいチャネルを聴き始めるなど）にアクセスし、そのＦＥＣデコーダを使用してストリームの処理を開始し、レシーバーは、レシーバー又はレシーバーの一部とつながれたメディア・クライアントにストリームを再生、転送することによるような、メディア・ストリームの消費量を考慮する前に、最初のソース・パケットを受信した後、少なくとも最小バッファ時間、待機する必要がある。従って、メディア・ストリームは、その上にメディア・デコーダによって処理される必要があるので、最初のメディア、例えば、ビデオ・フレームやオーディオ・サンプル、がユーザーに提示されるまでの時間は、少なくとも最小バッファ時間である。これは、ユーザーの意識にマイナスの影響を及ぼし、多くの場合に許容できないと、特に、良い多様性を与えるために最小バッファ時間が大きくされるシステムでは、考えられるかもしれない。
【００２６】
デコーダは、最小バッファ時間未満で最初のパケットをバッファに移すことを決定しうる、その場合には、チャネル・スイッチング・時間遅延は、縮小することができるが、デコーダは、将来の滑らかな表示のためには、この決定の帰結を、考えていないかもしれない。デコーダは送信されたＦＥＣパケットを使用することができないか、又は、厳格なタイミングを保証するのに遅れずに、ソース・パケットがＦＥＣデコーダから開放できないかもしれない。
【００２７】
パフォーマンスを改善するためのいくつかの解決法を以下に述べる。これらの解決法のうちのいくつかは、上記の信号方式の構造でも可能であるが、エンコーダまたはデコーダでの実行を必要とする。他の解決法は、デコーダでの必要な動作に適した規定を伴う新しい信号方式を加える。いくつかの見地では、初期のバッファリングで上記命令に従ういくつかのレシーバー（従来のレシーバーと呼ばれるもの）の場合、それらのレシーバーの共存としても扱うが、他の複数のレシーバーは、従来のレシーバーで無視されるストリームを伴ういくつかの追加のメタデータにより、受信したソース＋ＦＥＣストリームを別々に処理しうる。与えられたエンコード／デコードは、これらの解決法又は解決法の組合せを使用しうる。
【００２８】
解決法１：より少ない初期のバッファリング及びプレイアウトの減速
例えば、早期デコーディング時間及びそれ以上のある時間後に最小バッファ時間を満たすことのできる手段の適用によって、デコーダは、早めに最初のメディア・パケットを放出するためのいくつかの動作を適用するための決定をしうる。
【００２９】
初めのうちは１つのソース・ブロック中のすべてのデータをリカバリに使用することができるとは限らないかもしれない。しかしながら、例えば、ある比率だけメディア・ペイロードを減速することによって、この減速、一定のプレイアウト、及び継続によって、ある時間後最小バッファ時間早期デコーディング時間の残り時間が得られることを保証することができ、ソース・ブロックに対応する全てのデータは、この時間中から存在する。
【００３０】
しかしながら、あるコンテンツについてはデコーダがこれらの動作をとるエンコーダは望まないかもしれない。例えば、音楽のようなあるメディア・コンテンツについては、減速は受け入れ難い印象があるかもしれないし、また、トランスミッターは、デコーダにこれをさせないようにしてもよいし、又は、最大減速の比率を設定してもよい。
【００３１】
これについては、トランスミッターは、次に規定するセットアップ中のいくつかの追加のメタデータを追加しうる：
−  減速が使用されるのであれば最小初期バッファ遅延、最小バッファ時間減速
−  コンテンツの最大減速、最大減速比率
２つの値のうちの１つだけが使用されうる。それから、早期のプレイアウト及び減速をサポートするレシーバーは、それから少なくとも最小バッファ時間減速待機し、規定されていれば、多く最大減速比率だけメディア・プレイアウトを減速しうる。
【００３２】
解決法２：ランダム・アクセス・ポイントの異なる最小バッファ時間
一般に、ストリームのプレイアウトを始めるためのメディア・デコーダは、ストリームのランダム・アクセス・ポイントを要求する。ランダム・アクセス・ポイントは、Ｈ．２６４／ＡＶＣのインスタント・デコーダ・リフレッシュ(Instantaneous Decoder Refresh)・ポイント及びストリームをデコーディングし始めるために必要な他の情報に含まれうる。全てのランダム・アクセス・ポイント（ＲＡＰ）のための最小バッファ時間は、セットアップで設定されるような全てのパケットのための一般の最小バッファ時間よりも少なくてもよい。
【００３３】
したがって、どのランダム・アクセス・ポイントがアクセスされた場合でも、最小のバッファ時間最小バッファ時間ラップを設定する追加のシグナリングが加えられうる。これで追加されうるシグナリングとレシーバー認識メッセージは、最小バッファ時間の代わりにこのバッファ時間最小バッファ時間ラップを使用することができる。ともかく、エンコーダは、送信されたソース＋ＦＥＣストリームがこのプロパティを満たすことを確認しなければならない。
【００３４】
更なる方法では、最小バッファ時間は、ＲＡＰアクセス・ポイントのために適用する一般的な値でなくてもよいが、メタデータは、ＲＡＰについては初期バッファ時間がより低くなるように、個別の最小バッファ時間ラップＸで、各ＲＡＰと共に送られうる。
【００３５】
両方の方法ともに、送信側のデータの再オーダリング(reordering)によって、サポートされうる。例えば、ソース・データは、送信器で遅れ、ＦＥＣデータは、以前に送られるかこのソース・ブロックにあるソース・データと共にインタリーブされる。
【００３６】
解決法３：異なる初期クオリティのための異なる最小バッファ時間
更に、最も重要なデータが非常に遅れて送られる方法で、ソース・データは、送られうる。そして、このソース・ブロックの中のより重要でないデータが早く送られる。この場合、いつかの最小バッファ時間の値は、スイッチングの後に、異なるクオリティと共におのおの設定されうる。従って、シングル・ソース＋ＦＥＣストリーム、又は、各ランダム・アクセス・ポイントでさえ、デコーダで別々に処理されうる。そして、初期バッファ時間とスイッチング後の初期クオリティは、レシーバーにより決定されうる。
【００３７】
例えば、トランスミッターは同時に信号を送信しうる。
【００３８】
−  低スイッチング・クオリティを示す最小バッファ時間低クオリティ、例えば、暫くの間オーディオを再生するのみや暫くの間低クオリティ・フレームを見せる場合。
【００３９】
−  ある中間のクオリティを示す最小バッファ時間中クオリティ、例えば、最初にある低減されたプレイアウト・フレーム・レートの状態
−  ＦＥＣが初期に必要とされない場合の初期バッファ時間を示す最小バッファ時間ｎｏＦＥＣ、例えば、ＦＥＣは、ソース・データの前に送られているからである。
【００４０】
−  上述に示されるような従来の時間  最小バッファ時間
レシーバーは、何人かのユーザーの好み、ある受信状態、又は他のレシーバー内部情報により適切な値を選択したものでもよい。
【００４１】
これらの値は、ストリーム全体のために再び一般的でもよいし、ランダム・アクセス・ポイントごとに特定されたものでもよい。
【００４２】
どんな場合も、エンコーダは、ストリームが指示された値に適合することを確かめるべきである。
【００４３】
使い方
上記の技術はジッタ・フリーのプレイバックを提供するためにＤＶＢ−Ｈ又はＤＶＢ−ＳＨで使用されうる。従来のレシーバーの場合は、トランスミッターが、時間分割された基本ストリームが最大のＭＤＢバッファ・サイズを超えないようにすることを適正に保証するべきである。しかしながら、レシーバーは、最小バッファ時間が知らされたことを解釈することができる場合、それは経験を最適化するために使用されうる。トランスミッターは、１つのストリームの間でさえ時々変化しうる最大バッファ・サイズと、変化しうる最小バッファ時間を信号で送る。これらの最適化信号は、仮想ＦＥＣデコーダで決定されうる。ある最適化選択について効果があるかもしれない時間の前に、レシーバーのデコーダは、伝えうるため、各仮想ＦＥＣデコーダは、異なる最適化を使用して実行されうる。事実上、トランスミッターは、“もし、こちらからそちらに送信するストリームを最適化手法Ａを使用してデコードするのであれば、そちらはサイズＳのバッファに備え、バッファ時間Ｔによって消費を遅らせれば、そちらは満足行くであろう”と、レシーバーに言うことができ、トランスミッターは、１以上の手法のために、その仮想ＦＥＣデコーダを使用しているため、トランスミッターは、手法Ａ用のＳ及びＴの値を知るであろう。
【００４４】
この情報は、セッション記述プロトコル（ＳＤＰ）ブロックのレシーバーに伝達しうる。従来のＳＤＰの一例は次のとおりである:
v=0
o=ghost 2890844526 2890842807 IN IP6 2001:210:1:2:240:96FF:FE25:8EC9
s=3GPP MBMS Streaming FEC SDP Example
i=Example of MBMS streaming SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419
b=AS:15
a=FEC-declaration:0 encoding-id=1
a=FEC-OTI-extension:0 ACAEAA==
a=mbms-repair: 0 min-buffer-time=2600
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
m=application 4006 UDP/MBMS-REPAIR *
b=AS:15
a=FEC:0
a=mbms-flowid: 1=FF1E:03AD::7F2E:172A:1E24/4002, 2=FF1E:03AD::7F2E:172A:1E24/4003, 3=FF1E:03AD::7F2E:172A:1E24/4004, 4=FF1E:03AD::7F2E:172A:1E24/4005, 5=FF1E:03AD::7F2E:172A:1E24/2269
デコーダ最適化シグナリングを扱うＳＤＰはこのように見えるかもしれない:
解決法１のためのＳＤＰの例:メディア・プレイアウトの減速
v=0
o=ghost 2890844526 2890842807 IN IP6 2001:210:1:2:240:96FF:FE25:8EC9
s=3GPP MBMS Streaming FEC SDP Example
i=Example of MBMS streaming SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419
b=AS:15
a=FEC-declaration:0 encoding-id=1
a=FEC-OTI-extension:0 ACAEAA==
a=mbms-repair: 0 min-buffer-time=2600
a=mbms-repair: 0 min-buffer-time-slowdown=1300 max-slowdown-percentage=10
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
m=application 4006 UDP/MBMS-REPAIR *
b=AS:15
a=FEC:0 
a=mbms-flowid: 1=FF1E:03AD::7F2E:172A:1E24/4002, 2=FF1E:03AD::7F2E:172A:1E24/4003, 3=FF1E:03AD::7F2E:172A:1E24/4004, 4=FF1E:03AD::7F2E:172A:1E24/4005, 5=FF1E:03AD::7F2E:172A:1E24/2269
解決法２のためのＳＤＰの例：全てのランダム・アクセス・ポイントのためのバッファ時間の低減
v=0
o=ghost 2890844526 2890842807 IN IP6 2001:210:1:2:240:96FF:FE25:8EC9
s=3GPP MBMS Streaming FEC SDP Example
i=Example of MBMS streaming SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419
b=AS:15
a=FEC-declaration:0 encoding-id=1
a=FEC-OTI-extension:0 ACAEAA==
a=mbms-repair: 0 min-buffer-time=2600
a=mbms-repair: 0 min-buffer-time-rap=2000
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
m=application 4006 UDP/MBMS-REPAIR *
b=AS:15
a=FEC:0 
a=mbms-flowid: 1=FF1E:03AD::7F2E:172A:1E24/4002, 2=FF1E:03AD::7F2E:172A:1E24/4003, 3=FF1E:03AD::7F2E:172A:1E24/4004, 4=FF1E:03AD::7F2E:172A:1E24/4005, 5=FF1E:03AD::7F2E:172A:1E24/2269
解決法３のためのＳＤＰの例：リバース送信オーダーのためのバッファ時間
v=0
o=ghost 2890844526 2890842807 IN IP6 2001:210:1:2:240:96FF:FE25:8EC9
s=3GPP MBMS Streaming FEC SDP Example
i=Example of MBMS streaming SDP file
u=http://www.infoserver.example.com/ae600
e=ghost@mailserver.example.com
c=IN IP6 FF1E:03AD::7F2E:172A:1E24
t=3034423619 3042462419
b=AS:15
a=FEC-declaration:0 encoding-id=1
a=FEC-OTI-extension:0 ACAEAA==
a=mbms-repair: 0 min--buffer-time=4000
a=mbms-repair: 0 min-buffer-time-low-quality=1000
a=mbms-repair: 0 min-buffer-time-medium-quality=2000
a=mbms-repair: 0 min-buffer-time-no-fec=3000
a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
m=application 4006 UDP/MBMS-REPAIR *
b=AS:15
a=FEC:0 
a=mbms-flowid: 1=FF1E:03AD::7F2E:172A:1E24/4002, 2=FF1E:03AD::7F2E:172A:1E24/4003, 3=FF1E:03AD::7F2E:172A:1E24/4004, 4=FF1E:03AD::7F2E:172A:1E24/4005, 5=FF1E:03AD::7F2E:172A:1E24/2269
解釈されていないＳＤＰ属性が無視されるので、３つの解決法がすべて下位互換性をサポートすることを注記する。これらの示された最適化パラメータが仮想ＦＥＣデコーダかその他のものを使用して生成されることかもしれない。
【００４５】
いくつかの実施例では、ＦＥＣをスイッチング直後に利用できないだろうが、ＦＥＣデータは、（最小のバッファ時間を減少することができる）ソース・データの前に送信される。
【００４６】
早期のプレイアウトが許可される信号を送るトランスミッターであれば、スイッチング後により速いディスプレイを可能にするために、ある程度小さなバッファ時間は使用されうる（例えば、最小バッファ時間ｎｏＦＥＣ  ＜  最小バッファ時間）。最小バッファ時間ｎｏＦＥＣのための値は、レシーバーに送信されるかもしれないし、又はレシーバー実行専用かもしれない。
【００４７】
十分なＦＥＣ能力を引き出すために、レシーバーはある程度のバッファ時間を得るべきである、即ち最小バッファ時間―最小バッファ時間無-ｎｏＦＥＣ 時間、また、道理にかなったアプローチは、最小バッファ時間に達するまで、データ・パケットのバッファ時間を徐々に増加するかもしれない。
【００４８】
消費量の遅延無しにバッファ時間を得る１つの方法は、なんらかの要因によって、プレイアウト速度を抑制することであり、そして、ＦＥＣデータについての残り時間を使用する。例えば、下記のスロー・ダウン時間に適用される減速要因があってもよい。
【００４９】
スロー・ダウン時間＝（最小バッファ時間−最小バッファ時間ｎｏＦＥＣ）／（１−減速要因）
これらの要因は、ＳＤＰに含ませることができる。そのため、１つ、２または３つ全ての最適化信号は、単に従来の処理を解釈するだけの従来のレシーバーのプロシージャーを（必ず）替えることなくチャネル・スイッチングを改善することが付加されうる。いくつかの変化では、下位互換性はない。
【００５０】
解決法１は、早いデコーディングの開始とそれから適用する動作、例えば、最終的により遅れる実行をするメディア・プレイアウト減速のために余裕を取っておく。この信号方式は、これを、直接的に、又は従来の解決法と互換性のある方法又は従来のメディア・プレイアウト減速を使用する方法で可能にする。
【００５１】
解決法２は、特定箇所がストリームの他の箇所よりも初期バッファリングが得られない場合に、ストリームの特定箇所についての信号方式を付加的に加える解決法を扱う。もしストリームがランダム・アクセス・ポイントの場合、その後チャネル・スイッチング・時間は減少されうる。その信号方式は、全ての特定箇所について一度で又は各箇所について個別にでも、行われるかもしれない（初期バッファリングをさらにその上抑制しうる）。
【００５２】
解決法３は、高度のレシーバーが初期バッファリングが短いことにより利益が得られるように、送信オーダーが交換される場合に、バッファリング要求をする信号を送信する。
【００５３】
さらなる実施例は、この開示を読んだ後に当業者のうちの一人に思い描かせうる。他の実施例では、上記の示された発明のコンビネーション又はサブ・コンビネーションが有利になるように作られる。コンポーネントの配置例は、実例の目的ために示され、本発明の実施形態の代替の中で、組合せ、付加、再配置などが意図されると理解されるべきである。従って、本発明は、典型的な実施形態について説明したが、多数の改良がされる可能性があることを、当業者は認識するだろう。
【００５４】
例えば、ここで説明された処理は、ハードウェア構成要素、ソフトウェア・コンポーネント及び／又はそれの任意の組合せを使用して実施されるかもしれない。従って、本明細書及び図面は、制限的な意味よりもむしろ実例において、留意される。しかしながら、変形形態や変更がされることに加えて、請求項で説明されるものとしての本発明の広い趣旨や視野から外れることなしに、また、以下の請求項の視野の範囲内で全ての変形及び同等のものをカバーするために、発明が意図されたものであることは、明らかであろう。
【図１】
2011524698.tif 000003
【図２】
2011524698.tif 000004
【図３】
2011524698.tif 000005
【図４】
2011524698.tif 000006
【図５】
2011524698.tif 000007
【国際調査報告】
2011524698.tif 000008
2011524698.tif 000009
2011524698.tif 000010