(57)【特許請求の範囲】
【請求項１】
ビデオ受信器が実行するザッピング方法であって、
新しいプログラムに対するザッピング命令を受信するステップと、
前記新しいプログラムを有する第１のストリームと、該第１のストリームと同じプログラムを有しかつ該ビデオ受信器によって前記第１のストリームより速く処理されるのに適した第２のストリームとを受信することを要求するステップと、
前記第２のストリームが前記第１のストリームより遅れた状態で前記第１のストリーム及び前記第２のストリームを同時に受信するステップと、
前記第２のストリームの記憶より長い期間の間の前記第１のストリームを記憶するステップであって、ストリームの記憶期間は、前記第１のストリームが表示された場合、前記第２のストリームの表示時間に一致する表示時間になるように、前記第１のストリーム及び前記第２のストリームの間の時間遅延に従って前記ビデオ受信器によって固定されている、ステップと、
前記第２のストリームを表示するステップと、
前記第２のストリームに続いて前記第１のストリームを表示するステップと
を有するザッピング方法。
【請求項２】
ビデオサーバが受信器へストリームを送信する方法であって、
第１のストリームのコンテンツを符号化するステップと、
前記受信器が前記第１のストリームより速く処理するのに適した第２のストリームにおける同じコンテンツを符号化するステップと、
前記第１のストリーム及び前記第２のストリームをバッファリングする期間の時間差を表わす前記第１のストリーム及び前記第２のストリームの間の時間オフセットと共に、２つのストリームを同時に送信するステップと、
前記時間オフセットの値を前記受信器へ通知するステップと、
を有する方法。
【請求項３】
コンピュータで実行される場合に請求項１又は２に記載の方法を実行するプログラムコード命令を有するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ザッピングのための方法に関し、より具体的に、２つのプログラムの間のザッピング時間を減らす方法に関する。
【背景技術】
【０００２】
ブロードバンド・ネットワークを介するビデオ配信は、例えばＭＰＥＧ−２又はＪＶＴ／Ｈ．２６４／ＭＰＥＧ  ＡＶＣのような標準の圧縮システムを使用する。ＭＰＥＧ標準は、ＧｏＰ（Group  of  Pictures）を定義する。ＧｏＰは、Ｉ、Ｐ、Ｂタイプのピクチャのシーケンスを定義する。これらのピクチャは、また、ＭＰＥＧ標準でも定義されている。Ｉピクチャは、いずれかの他のピクチャを参照することなく符号化される。Ｐピクチャは、先行するピクチャを参照して表される。Ｂピクチャは、先行するピクチャ及び後続のピクチャを参照して表される。受信器がプログラム（programme）を受信するとき、受信器は、復号化を開始すべくＩピクチャの受信を待つ。これにより、特にザッピング（zapping）の場合に、新しいフィルムの表示に先だって遅延が生ずる。従って、ザッピング時に、スクリーン上に新しいチャンネルを表示する前に時間が経過する。この時間は、受信メモリを満たす時間と、ストリームにおいて復号化可能なピクチャを見つける時間との間で分けられる。
【０００３】
システムは、復号化可能なピクチャがそれを表示することができるようにより速く見つけられるような構造を有する付加的なストリームを加えることによって、復号化時間を改善すべく存在する。これがどのようなものであるのかは、例えば、国際公開第２００５／１１２４６５（Ａ１）号パンフレット（特許文献１）に定義されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第２００５／１１２４６５（Ａ１）号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、この付加的なストリームは、復号される前にメモリ受信が満たされるのを待つ必要がある点で、通常のストリームと同じ問題を欠点とする。
【課題を解決するための手段】
【０００６】
本発明は、受信器でのザッピング時間を最適化するのに適するシステム及び方法に関する。
【０００７】
この目的のために、本発明の目的は、ビデオ受信器で、新しいプログラムに対するザッピング命令の受信ステップと、前記新しいプログラムを有する第１のストリームと、該第１のストリームと同じプログラムを有し、当該受信器によって前記第１のストリームより速く処理されるのに適する第２のストリームとを受信するための登録ステップと、前記第２のストリームが前記第１の受信に対して遅れて受信される、前記第１のストリーム及び前記第２のストリームの受信ステップと、前記第２のストリームの記憶より長い期間の間の前記第１のストリームの記憶ステップと、前記第２のストリームの表示ステップと、前記第２のストリームに連続する前記第１のストリームの表示ステップとを有するザッピング方法である。
【０００８】
実施例に従って、前記第１のストリームの記憶時間は、前記第１のストリームと前記第２のストリームとの間の時間遅延に従って当該受信器によって定められる。
【０００９】
一実施例に従って、前記プログラムは、前記第１のストリームより前記第２のストリームでより圧縮されて伝送される。
【００１０】
特定の実施に従って、当該受信器は、前記第１のストリーム及び前記第２のストリームの提示時間の間の差の表示を受信する。
【００１１】
本発明の他の目的は、ビデオサーバによって受信器へストリームを送信する方法であって、当該サーバで、第１のストリームにおけるコンテンツの符号化ステップと、前記受信器によって前記第１のストリームより速く処理されるのに適する第２のストリームにおける同じコンテンツの符号化ステップと、前記第１のストリームに対する前記第２のストリームの遅延を有した前記第１のストリーム及び前記第２のストリームの送信ステップとを有する方法を提案することである。
【００１２】
一実施例に従って、前記第２のストリームにおける符号化されたコンテンツは、前記第１のストリームにおける符号化されたコンテンツより圧縮されている。
【００１３】
本発明は、また、コンピュータで実行される場合に本発明に従う方法のステップの実行のためのプログラムコード命令を有するコンピュータプログラムプロダクトに適用する。「コンピュータプログラムプロダクト（computer  program  product）」は、例えばディスケット又はカセットのような、プログラムを有する記憶空間のみならず、例えば電気信号又は光信号のような信号をも有することができるコンピュータプログラム媒体を意味すると理解される。
【００１４】
本発明は、添付の図面を参照して、決して限定ではなく、以下の実施例及び実施を用いてより良く理解され、説明されうる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施例に従うシステムの図表示である。
【図２】本発明の実施例に従う受信器の図である。
【図３】本発明の実施例に従うサーバの図である。
【図４】本発明の実施例に従うストリームダイアグラムを表す。
【図５】本発明の実施例に従う高速ザッピング原理の略図である。
【発明を実施するための形態】
【００１６】
図２及び図３で、図示されるモジュールは、物理的に区別可能なユニットに対応しうる機能ユニットである。例えば、これらのモジュール又はそれらのうちの幾つは、単一のコンポーネントに集められ、又は同じソフトウェアの機能を構成することができる。一方、一部のモジュールは別々の物理エンティティから構成されてよい。
【００１７】
実施例は、ブロードバンド・ネットワークでの圧縮コンテンツ分配のモジュールにおけるザッピングに係るフレームワーク内にあるが、本発明はこの特定の実施例に限定されず、ザッピングに類似する事項が適用するところの他の状況に適用可能でありうる。
【００１８】
図１は、本発明の実施例に従うシステムを示す。図１のシステムはビデオソース１を有する。ビデオは、２つのストリーム、すなわち、高品質ストリーム及び低品質ストリームの形でエンコーダ２によって符号化される。高品質ストリームは、例えばＳＤ又はＨＤストリームのような、標準のストリームである。低品質ストリームは標準フォーマットのストリームであるが、それは高品質ストリームよりも圧縮されている。低品質ストリームは、高品質ストリームのＧｏＰよりも短いＧｏＰによって特徴付けられる。すなわち、低品質ストリームは、標準ストリームが符号化されるところのパケットの数より少ないパケット数で符号化される。サーバ６は、ビデオソース１及びエンコーダ２を有する。当然、ビデオソース１及びエンコーダ２は個別の装置に含まれてよい。エンコーダ２は２つの異なるストリームを符号化する。これは、２つの個別のエンコーダによって実行され得る。
【００１９】
次に、高品質ストリームは標準ストリームと呼ばれ、低品質ストリームは付加ストリームと呼ばれる。標準ストリームについてのＧｏＰの例はＩＢＢＰＢＢＰＢＢＰＢＢＩであり、付加ストリームについてのＧｏＰの例はＩＢＩである。それは、より少ないパケット数を有して送信される同じデータに対応する。
【００２０】
ビデオストリームは、インターネットプロトコル形式のネットワーク３を介して、例えばセットトップボックス等のビデオ受信器４へ送信される。受信器４は、受信されたストリームをビデオスクリーン５に表示する。
【００２１】
図２は、実施例に従う受信器４を表す。受信器４は、特にＩＰ形式のＷＡＮネットワークで、データを送受信する通信モジュール２１を有する。受信器４は、ＷＡＮネットワークから受信されるビデオデータを記憶するのに適するメモリ２３と、ビデオ復号化モジュール２５とを有する。具体的に、ビデオ復号化モジュール２５はＭＰＥＧデコーダである。受信器４は、様々な受信器モジュールを処理する手段を有するプロセッサ２２を有する。
【００２２】
受信器４は、また、ユーザからのザッピング要求の受信を可能にするユーザインターフェース２４を有する。このザッピング要求は、プログラムの変更をトリガする。最後に、受信器４は、それ自体知られている、スクリーンへの接続の手段（図示せず。）を有する。
【００２３】
図３に表されるサーバ６は、２つのエンコーダ、すなわち、標準ストリームのためのビデオ符号化モジュール３４と、付加ストリームのためのビデオ符号化モジュール３５とを有する。サーバ６は、また、それ自体知られている、マルチキャストモードで受信器へストリームを送信する通信手段３１を有する。必然的に、ストリームはユニキャストモードで送信されてよい。この手段３１は、後述されるように、受信器へ送信されるストリームの間で時間遅延を可能にする。サーバ６は、また、プロセッサ３２及びメモリ３３を有する。
【００２４】
図４は、ザッピングメカニズムを表すシーケンス図である。
【００２５】
ステップＳ１で、受信器２はビデオソース１からビデオストリームを受け取る。次いで、ステップＳ２で、ユーザインターフェースから、受信器２は、他のプログラムへのザッピングの要求を受け取る。接続プロシージャは、それ自体よく知られているＩＧＭＰ（Internet  Group  Management  Protocol）を介して起こる。ＩＧＭＰ要求は、対応するビデオサービスを選択するよう所望のビデオストリームのマルチキャストＩＰアドレスを有する。受信器２は、ステップＳ３で古いビデオストリームのＩＧＭＰリーブ（leave）を行い、次いで、ステップＳ４及びＳ５で標準ストリーム及び関連する付加ストリームのＩＰマルチキャストアドレスについてＩＧＭＰジョイン（join）を行う。
【００２６】
次いで、受信器２は、ステップＳ６で標準ストリームを受信し、ステップＳ８で付加ストリームを受信する。これらのストリームはステップＳ７及びＳ９で記憶される。付加ストリームは、一般に、ステップＳ１０で表示される。実際には、この付加ストリームでＩピクチャを見つける、より多くの機会がある。次いで、後述されるように、ステップＳ１１で、標準ストリームが表示される。
【００２７】
前述のＧｏＰの例に従って、ただ１つのＢタイプピクチャが付加ストリームについての各Ｉタイプピクチャの間で送信される。一方、標準ストリームについては、幾つかのＢタイプピクチャ及びＰタイプピクチャが２つのタイプＩのピクチャの間で送信される。従って、２つのタイプＩのピクチャの間の待ち時間は付加ストリームの場合におけるものよりも長い。
【００２８】
図５は、受信器での記憶及び復号化メカニズムを表す。
【００２９】
受信の際に、標準ストリーム及び付加ストリームは、復号される少し前にメモリに記憶される。この記憶は、受信されるデータが、かかるデータをデコーダへ送信する前の一定期間の間記憶されることを可能にする。次に、デコーダは、表示を開始すべくタイプＩのピクチャを検出するのを待つ。
【００３０】
標準ストリームの記憶時間１０１は極めて長い。実際に、この標準ストリームは、適切に処理されうるものである。その場合に、それは、送信に伴う問題に耐性があるものでなければならない。一方で、標準ストリームは、ストーリング（stalling）を防ぐよう受信時に起こりうるジッタ効果を補償する。他方で、標準ストリームは、定められた設定のパケットで、例えばＦＥＣ（Forward  Error  Correction）のようなエラー補正を行うのに十分なデータを有することを可能にする。この記憶は、オーディオ・ビデオデータのパケットがデコーダに送られる前に記憶される時間を要する。これは、データのパケットが使用可能である前の一定期間の間記憶されたままであることを意味する。この期間は損失時間であり、これは、特にザッピング時に新しい復号化が開始される場合に影響力を持ち、どんなものでも復号される前にメモリが満たされるまで待つ必要がある。
【００３１】
付加ストリームの記憶時間１０２はより短い。実際に、それは、ザッピングの直後ほんの数秒だけ有用である。付加ストリームの役割は、恒久的に見られることではない。それは、標準フローほど保護されず、ジッタに対してより敏感である。これは、付加ストリームがより速くデコーダへデータを送るとともに、ザッピング時間を短くすることを可能にする。
【００３２】
ストリームが十分に長い時間記憶されると、それらはデコーダへ送信され、復号化が開始される。付加ストリームについて、復号化時間はより速い。実際に、付加ストリームのＧｏＰはより短く、ピクチャＩはより速く現れる。Ｔ０で、付加ストリームはスクリーン上に現れることができる。標準ストリームの復号化時間１０４は、通常は、より長い。標準ストリームのＧｏＰはより長く、Ｉピクチャの出現はより離れて間隔を空けられ、Ｉピクチャは付加ストリームにおけるものほど頻繁には現れない。Ｔ１で、標準ストリームは復号され、スクリーン上に表示される準備ができる。
【００３３】
標準ストリームは付加ストリームに取って代わる（参照符号１０５）。標準ストリームへの付加ストリームのハンドオーバは、同じ時間ベースで２つのストリームにタイムスタンプを付すことで容易に行われ得る。従って、各ストリームに存在する同じピクチャは同じ提示時間を有する。とりわけ、それは、ＭＰＥＧ標準で定義されるように、ＰＴＳ（Presentation  Time  Stamp）である。
【００３４】
記憶時間は次のように説明され得る。標準ストリームのための記憶時間が１秒である場合に、付加ストリームのための記憶時間は１００ミリ秒である。従って、２つのストリームが受信器によって同時に受信されるとすると、付加ストリームは１００ミリ秒後にデコーダへ送信されて、表示の準備ができているＩタイプピクチャを速やかに得るよう復号される。同時に、標準ストリームは１秒後にデコーダへ送信される。次いで、標準ストリームは復号される。タイプＩのピクチャは、付加ストリームについてほど速くは得られない。タイプＩのピクチャが得られると、標準ストリームはスクリーン上で付加ストリームに取って代わる。
【００３５】
タイプＩのピクチャは付加ストリームを介して十分に速く表示されるので、標準ストリームのための記憶時間は、起こり得る伝送エラーに対して受信をよりロバストにするために増大され得る。
【００３６】
実施例に従って、標準ストリーム及び付加ストリームは、ＭＰＥＧ標準に従って、異なる提示時間、特に異なるＰＴＳを有して、同時に発せられる。すなわち、これらのストリームは時間においてオフセットされる。付加ストリームのＰＴＳ、すなわちＰＴＳ１は、標準フローのＰＴＳ、すなわち、ＰＴＳ２に先行する。付加ストリームは、標準ストリームに対して時間オフセットを有して発せられる。すなわち、それは、標準ストリームに対して遅延して発せられる。従って、受信器が標準ストリームのＰＴＳ２を受信する場合に、受信器は同時に、サーバによって既に送信されていた標準ストリームのＰＴＳ２に対応する付加ストリームのＰＴＳ１を受信する。ＰＴＳ１とＰＴＳ２との間の差は、標準ストリーム及び付加ストリームのバッファ間のサイズの差を時間で表す。従って、付加ストリームがそのメモリを満たした場合に、それは復号され始める（ＰＴＳ１）。一方、標準ストリームは依然として記憶されている。付加ストリームが復号されている間、標準ストリームは、そのメモリがいっぱいになり、標準ストリームが復号され始めるまで、メモリを満たす。このＰＴＳ２時は、付加ストリームがそのＰＴＳ２を復号する時点に対応する。従って、付加ストリームが表示される場合に、付加ストリームはＰＴＳ１の直後の時点Ｔ０で表示される。次いで、この時間の間、標準ストリームは記憶され復号される。標準ストリームが表示される場合に、ＰＴＳ２の直後の時点Ｔ１に、表示される付加ストリームは顕著に同じ時間Ｔ１に対応し、付加ストリームのハンドオーバはいつの間にかスクリーン上で起こる。ＰＴＳ１とＰＴＳ２との間の差は、実際に、スクリーンでの表示の前に、標準ストリームと付加ストリームとの間の、デコーダで必要とされる処理における差を補償することを可能にする。
【００３７】
サーバは、場合により、２つのストリームの間で行われるオフセットを受信器へ信号により伝える。これは、特に、ストリームの登録（registration）の間に行われ得る。これは、受信器が、ストリームの夫々に専用のメモリのサイズについてのパラメータを設定することを可能にする。
【００３８】
受信器は、また、それ自身このオフセットを検出することができる。それは、標準ストリームの記憶時間を必要な長さにすべくこのオフセットを使用することができる。
【００３９】
本発明は、一例として本明細書中に記載されている。当業者には明らかなように、本発明の適用範囲を逸脱しない範囲で本発明を変形することが可能である。
【図１】
0005474777.tif 000002
【図２】
0005474777.tif 000003
【図３】
0005474777.tif 000004
【図４】
0005474777.tif 000005
【図５】
0005474777.tif 000006