JP2008535298A - デジタルデータフローサーバーへコマンドを送出する方法、及び当該方法を使用する装置 - Google Patents

Abstract

本発明は、例えばクライアントにローカルなＲＴＳＰを使用しＶＯＤサーバーへのコマンドを送出する方法に関する。これらのコマンドは、相対現在位置へのリファレンスを有する。当該コマンドは相対現在位置へのリファレンスを有する。この相対現在位置は、サーバーに要求を送出することなく、又はストリームに含まれるＰＴＳ内のジャンプを処理するために使用され得るストリーム内の存在に基づくことなく、ＭＰＥＧストリームで受信したＰＴＳに基づき受信機により維持される。

Description

本発明は、コンテンツ・オンデマンド・サーバーの受信機による制御の分野に関する。より詳細には、本発明は、サーバーがサーバーのコンテンツを、ＩＰネットワークを介しデジタルデータのフローの形式で「放送」する場合に関する。

ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）は、特にＲＦＣ（リクエスト・フォー・コメント）２３２６で、デジタルデータフローサーバーの制御プロトコルを定めている。このプロトコルは、ＲＴＳＰ（実時間ストリーミングプロトコル）と称され、サーバーを制御し、セッションを開き、番組の起動を要求し、番組の一時停止、開始又は最終的な停止を要求するために使用される。

従って、ＲＴＳＰを使用して、番組の特定再生モード（「トリックモード」）を実施することが可能である。これらのモードは、ユーザーがビデオレコーダーで慣れ親しんでいる、ＩＰで放送される番組を閲覧するためのコマンドを供給するために使用される。これらのモードでは、早送り及び巻き戻し、また番組内で予め識別されたポイントでの位置決めが引用される。

殆どのＲＴＳＰコマンド、特に特定再生モードに含まれる「Ｐｌａｙ」コマンドは、開始リファレンスと終了リファレンスとの間隔により識別されることが要求される番組範囲の時刻印を与えるパラメーターを必要とする。ＲＴＳＰクライアントは従って、再生されるファイル内の現在時間位置を正確に知ることが可能でなければならない。クライアントに番組内の相対現在時間位置を瞬間毎に知らせる手法はいくつかある。いくつかのサーバー、例えばオラクルサーバーは、番組に混合された時間記述子を送出する。しかし全てのサーバーがこの機構を使用するわけではない。これを行う別の方法は、ＲＴＳＰコマンド「ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ」を使用し現在時刻印をサーバーから得るクライアントを有する。この解決法は、要求を送出し及び回答を返す時間を必要とする。しかしながら、これは最も一般に使用されている方法である。

ＭＰＥＧ規格は、「ＭＰＥＧ−２システム：ＩＳＯ／ＩＥＣ、１９９４年、ジェネリック・コーディング・オブ・ムービング・ピクチャーズ・アンド・アソシエイティッド・オーディオ：システムズ（ＭＰＥＧ−２システムズ・スペシフィケーション）、１１月、ＩＳＯ／ＩＥＣ１３８１８−１」に参照され、再生及びトランスポートを目的としてマルチメディアコンテンツを多重する方法を記載している。番組は、基本ストリームに分割される。基本ストリームはデータパケットに切断される。

コンテンツの再生を可能にするこのような方法では、基本ストリームのレベルの各エンティティ、例えばビデオストリームのための画像は、ＰＴＳ（プレゼンテーション・タイム・スタンプ、表示時刻印）と称される時刻印を割り当てられる。この時刻印は、関連付けられたエンティティ、ここでは画像がリストアされなければならない瞬間を示す。この時刻印の基礎は、システムの基準クロックであり、９０ｋＨｚクロックである。これらの時刻印は、互いの間で番組を構成している種々の基本ストリームを同期するために使用される。

番組のストリーム内のこれらの表示時刻印の連続は、一般に番組の開始から終了まで連続していない。実際に、番組は、別個に符号化されたいくつかのシーケンスを組み立てた結果であり得る。また当該番組の表示時刻印は同一の時間リファレンスシステムで計算されていない。更に、特定再生モードの使用中、現行の技術は異なるモードに対し異なる方法で符号化された版を使用する。例えば、サーバーは、サーバーが早送りコマンドを受信した場合に使用する２倍速で符号化された番組の版を有する。ここで再び、異なる版の番組は、異なる時間リファレンスシステムに対応する表示時刻印を有する。表示時刻印はストリーム内に存在し、従って一般にシーケンスの連続を形成する。これらシーケンスのそれぞれは、特定時間リファレンスシステムに対応する。

本発明は従って、ＲＴＳＰクライアントにより利用可能な番組放送内で相対時間を識別する信頼できる方法を見出すことを含む。この方法は、分散したフロー内に必ずしも存在するとは限らない記述子の使用に頼らず、サーバーへの如何なる要求も必要とせず、及び処理されるべき表示時刻印のシーケンスの時間リファレンスシステム内の変化を許容する。

本発明は、例えばＲＴＳＰに従うＶＯＤサーバーへコマンドを送出するクライアントのローカル方法を提案する。これらのコマンドは、相対現在位置へのリファレンスを有する。この相対現在位置は、サーバーに要求を求めることなく、又はストリームに含まれるＰＴＳ内のシーケンスの中断を処理可能な記述子のストリーム内の存在に基づくことなく、ＭＰＥＧフロー内で受信したＰＴＳに基づき受信機により維持される。本発明はまた、方法の実施に適したクライアントに関する。

本発明は、受信機によりデジタルデータストリームサーバーへ命令を送出する方法に関する。デジタルストリームは前記サーバーにより前記受信機へ、前記サーバーと前記受信機を接続するリンクを介し放送される。デジタルデータのフローは、所与の速度で再生されるよう設計された少なくとも１つの番組及びフローのデータと関連付けられた時刻印を有する。前記時刻印は、時間リファレンスシステム内の関連データを再生する瞬間に相対的である。前記時間リファレンスシステムは、フロー内で互いに順次続く。時間リファレンスシステムの変化は、シーケンス中断を生じ、ストリーム内に現れることが可能である。前記方法は、
−前記デジタルデータストリームを受信する段階、
−ストリームに含まれる番組内の現在相対時間位置を有するコマンドを送出する段階、を少なくとも有し、前記位置は前記受信機によりローカルに決定され、前記位置の決定に介入するストリームからの情報は、前記ストリームのデータと関連付けられた時刻印のみである。

本発明のある特定の実施例によると、方法はまた、現在相対時間位置の現在値を定期的に更新する段階を有する。

本発明の特定の実施例によると、更新する段階は、受信した新たな時刻印と最後に格納された時刻印との間の差に相当するデルタ値を決定する下位段階を有する。

本発明の特定の実施例によると、更新する段階はまた、デルタ値とストリーム再生速度に依存する閾値を比較する下位段階を有する。シーケンス中断の存在は、閾値より大きいデルタ値により決定される。

本発明のある特定の実施例によると、更新する段階はまた、如何なるシーケンス中断もない場合、デルタ値を維持されている時間位置の現在値に加算する段階を有する。

本発明のある特定の実施例によると、更新する段階はまた、如何なるシーケンス中断もない場合、再生速度で乗算されたデルタ値を維持されている時間位置の現在値に加算する段階を有する。

本発明は、デジタルデータストリーム受信機に関する。前記デジタルストリームは、前記サーバーから前記受信機へ、前記サーバーと前記受信機を接続するリンクを介し放送される。デジタルデータのフローは、所与の速度で再生されるよう設計された少なくとも１つの番組及び前記フローのデータと関連付けられた時刻印を有する。前記時刻印は、時間リファレンスシステム内の関連データを再生する瞬間で相対的である。前記時刻印は、前記フロー内で互いに順次続く。時間リファレンスシステムの変化は、シーケンス中断を生じ、ストリーム内に現れることが可能である。前記受信機は、
−前記デジタルデータストリームを受信する手段、
−前記ストリームに含まれる番組内の現在相対時間位置を有するコマンドを送出する手段、を少なくとも有し、前記受信機はまた前記位置を前記受信機によりローカルに決定する手段を有し、前記位置の決定に介入するストリームからの情報は、前記ストリームのデータと関連付けられた時刻印のみである。

本発明のある特定の実施例によると、受信機また、現在相対時間位置の現在値を定期的に更新する手段を有する。

本発明のある特定の実施例によると、更新する手段は、新たに受信した時刻印と最後に格納された時刻印との間の差に相当するデルタ値を決定する手段を有する。

本発明の特定の実施例によると、更新する手段はまた、デルタ値とストリーム再生速度に依存する閾値を比較する手段を有する。シーケンス中断の存在は、閾値より大きいデルタ値により決定される。

本発明のある特定の実施例によると、更新する手段はまた、如何なるシーケンス中断もない場合、デルタ値を維持されている時間位置の現在値に加算する手段を有する。

本発明のある特定の実施例によると、更新する手段はまた、如何なるシーケンス中断もない場合、再生速度で乗算されたデルタ値を維持されている時間位置の現在値に加算する手段を有する。

本発明は、添付の図面を参照する以下の記載を読むことにより一層理解され、及び他の特定の特徴及び利点が明らかになるだろう。

本発明の実施例を以下に記載する。

本発明のこの実施例は、ビデオオンデマンド（ＶＯＤ）サービスシステムの範囲に含まれる。図１にこのようなシステムの一般的なアーキテクチャが示される。システムは、１つ以上のサーバー１．１を有する。これらのサーバーは、放送する番組を格納し及びそれら番組をデータストリームの形式で送出し得る。システムのユーザー、標準的にサービスの個人加入者は、彼らの家にサービス表示画面１．５、標準的に受信されたデジタルデータストリームを画面へ送出されるアナログ信号に復号化可能なＭＰＥＧであるデコーダー１．４、を有する。本願明細書に記載される状況では、デコーダーはＩＰネットワーク１．２を介し番組を受信するのに適したＩＰデコーダーである。モデム１．３は、ユーザーのネットワークをＩＰ供給ネットワーク１．２と接続するために使用される。ＩＰ供給ネットワーク１．２は、インターネット又はビデオオンデマンドサービスプロバイダーのプライベートＩＰ供給ネットワークであり得る。このようなシステムでは、デコーダーは、ユーザーの要求に応じてＲＴＳＰプロトコルを介したサーバーによる番組の放送を制御するＲＴＳＰクライアントである。

ＭＰＥＧ規格は、マルチメディア番組を構成する異なる基本ストリームを符号化及び多重化する方法を定める。この番組、標準的にビデオオーディオ番組は、異なる基本ストリームを有する。一般に、１つのビデオストリーム及び１つ以上のオーディオストリームがある。各基本ストリームは、規格では表示ユニットと称されるエンティティを有する。これらエンティティのそれぞれは、ＰＴＳとして知られる表示時刻印に割り当てられる。ＰＴＳは、エンコーダーの時間リファレンスシステム内で、時間リファレンスシステムのクロックシステムに従い、このエンティティ又は表示ユニットがデコーダーにより再生されなければならない瞬間を与える。これら表示時刻印の存在は、特に、デコーダーが番組を再生する場合に異なる基本ストリームを同期させる。エンティティ又は表示ユニットは、ビデオの場合には標準的に画像であり、一方オーディオの場合にはサンプルである。

図２は、本発明の実施例のＭＰＥＧデコーダーのハードウェアアーキテクチャを示す。このデコーダー２．１は、モデム２．２と、イーサネット（登録商標）インターフェース２．７を介し接続される。デコーダー２．１は、ＴＶ２．５にプログラムの復号化からアナログ信号を供給する。デコーダーは、中央処理装置２．９の制御下で動作する。この処理装置は、フラッシュメモリー２．１０に格納されたプログラムをワーキングメモリーとしてＲＡＭ２．１１を使用して実行する。ＭＰＥＧストリームは、モデム２．２及びイーサネット（登録商標）インターフェース２．７を介し受信される。ＭＰＥＧストリームは次にオーディオ及びビデオデコーダー２．６へ送出される。このデコーダーは異なる基本ストリームを分離し、及びそれらが符号化されている場合はそれらを復号化すると共にそれらを解凍する。解凍された基本オーディオ及びビデオストリームは、次にデジタルアナログ変換器２．４へ送出される。グラフィック処理装置２．８は、ビデオ画像に重ねられるグラフィックの生成を担う。これらのグラフィックは、標準的にユーザーインターフェースグラフィック又は番組案内データ等である。デジタルアナログ変換モジュール２．４は、番組及びグラフィックを有するアナログ信号を生成する。これらの信号は、番組再生装置、標準的にはテレビジョンセット２．３へ送出される。

図３は、本発明の実施例によるこのようなデコーダーで実施されるソフトウェアアーキテクチャの図を示す。図３は、ハードウェア３．７を制御するために使用されるドライバーの層３．６を有する。実時間オペレーティングシステム（ＲＴＯＳ）は、装置の基本動作を提供する。一般に、条件付きアクセスモジュール３．４は、ユーザーが番組を閲覧可能な権利を有することを保証する。通信及び特に番組の受信を管理するため、ＩＰ通信スタック３．３はビデオオンデマンドサーバーを有するネットワークとやりとりする。ＶＯＤモジュール３．８はビデオオンデマンドサービスへのアクセス管理専用である。当該管理はＩＰの上に位置し、ＶＯサーバーとのやりとりを管理する。当該モジュール内に、記載された実施例による本発明の実施手段が位置する。最も高いレベルに、アプリケーションのセット３．２がある。アプリケーションのセット３．２は、ユーザーにサービスのセットを提供可能にする。サービスの中には、番組選択インターフェース及びしばしば番組案内がある。

図４は、本発明の実施例によるＲＴＳＰプロトコルを使用した、クライアントとＶＯＤサーバーとの間のダイアログの例を示す。ＲＴＳＰは、番組の実時間放送サーバーのコマンドを管理可能なサーバークライアントプロトコルである。このプロトコルは、コマンドを管理するだけであり、データの送出を考慮しない。データの送出は他のプロトコルにより行われる。ＲＴＳＰは、一般にＲＦＣ１８８９に記載されたＲＡＰ（実時間トランスポートプロトコル）に従うデータの送出と結合される。しかし、サーバーは、データを送出するためにサーバーが選択した如何なるプロトコルも自由に使用できる。例えば、ＲＡＰが基づくプロトコルであるＵＰ（ユーザーデータグラムプロトコル、ＲＦＣ７６８）で直接にデータを送出できる。

ＲＴＳＰは、クライアントに「ＳＥＴＵＰ」コマンドを介しサーバーにセッションを開く可能性を与える。このセッションは、要求された番組、宛先、トランスポートモード、及び種々の他のパラメーターを定める。このセッションは次に、再生速度を指定することにより、つまり「ＰＬＡＹ」コマンドによりサーバーに番組範囲のデータの送出を要求することを可能にする。またサーバーにデータの送出の一時停止を要求すること、つまり「ＰＡＵＳＥ」コマンドが可能である。セッションの終了は、「ＴＥＡＲＤＯＷＮ」コマンドで生じる。このプロトコルの完全な説明は、ＲＦＣ２３２６を参照のこと。

図４の例では、ＶＯＤクライアント、従ってデコーダーは、「ＳＥＴＵＰ」コマンドを有するＭ１メッセージを通じてセッションを開始する。このコマンドは、クライアントが、アドレスがｒｔｓｐ：／／１９２．９．２１ ０．２３３：５００４／ａｓｓｅｔ／ｖｓｃｏｎｔｓｒｖ％３ｖｏｄｓｔｒｅａｍ＿ｓｃｒ−ｆｒｅｅ−ｆである番組を望んでいることを、最良のモードでＵＰプロトコルを介しＲＴＳＰプロトコルの１．０版を使用することにより、ポート２００００のアドレス１９２．９．２１０．２３へ指定する。

サーバーはＭ２受理メッセージにより応答する。ここで、サーバーは引数「ａ＝ｒａｎｇｅ：ｐｔｓ＝７５６２１−２１４６４２１」を送出する。当該引数は、送出された番組が、値７５６２１で開始し値２１４６４２１で終了する表示時刻印を有することを指定する。この情報は、続いて一時的に番組内に置かれるためクライアントにより使用され得る。実際に、受信した表示時刻印は、関連付けられた番組エンティティを「ＰＴＳ＿ｓｔａｒｔ」及び「ＰＴＳ＿ｅｎｄ」と称されるこれらの限界に関して位置付けさせなければならない。残念ながら、全てのサーバーがこの引数を送出するわけではなく、この引数が利用可能な場合でさえ、放送される番組内の時刻印が必ずしも同一のリファレンスシステム内で「ＳＥＴＵＰ」を受領して返送される間隔として計算されるとは限らない。

クライアントは従って、「ＰＬＡＹ」コマンドを有するＭ３メッセージを送出することにより、サーバーに番組を送出し始めることを要求可能である。「ＰＬＡＹ」は受信を望まれる番組範囲の表示を有さなければならない。この範囲は番組全体であり得、この例では引数「Ｒａｎｇｅ：ｎｐｔ＝０．００−ｅｎｄ」により示される。番組範囲を示すいくつかの方法、時間を示すいくつかの方法がある。例えば、ＮＰＴ（通常再生時間）表記を使用する例は、番組の始めに対するストリーム内の時間位置を少数の形式で示す。少数の左部分は時間を秒又は時間、分及び秒で与える。一方で右部分は秒の端数である。Ｍ３メッセージは従って、番組の始め「０．００」から「ｅｎｄ（終わり）」まで番組全体の放送を要求する。

Ｍ４メッセージは、Ｍ３メッセージの受理である。

少しの後、放送中に、顧客はメッセージＭ５を介し一時停止を要求する。この一時停止は、メッセージＭ６を介し受理される。

メッセージＭ７に関し、Ｍ７は、番組の現在位置から通常の８倍の速度で早送りを要求するメッセージである。使用される範囲の引数は従って、「Ｒａｎｇｅ：ｎｐｔ＝４２．７２−ｅｎｄ」である。また再生の速度は引数「Ｓｃａｌｅ：８．０」を介し渡される。Ｍ８メッセージは、Ｍ７メッセージの受理である。

上述の通信の例は、デコーダーの場合に放送されるストリーム内の時間的位置の重要性を示す。実際に、例えばデコーダーがメッセージＭ７でのように速度８で早送りする動きを要求した場合、サーバーは要求された範囲の開始位置を与えなければならない。この開始位置は、ユーザーがモードの変化時に如何なるジャンプにも気付かないように、放送される番組の現在位置に正確に対応しなければならない。

デコーダーがストリーム内の現在時間位置を知る別の手段がある。例は、サーバーが「ＳＥＴＵＰ」コマンドを受理した場合、放送されるストリーム内で使用される表示時刻印の限界を与えることを示す。これらの限界は、ＰＴＳ＿Ｓｔａｒｔ及びＰＴＳ＿Ｅｎｄと称される。しかしながら、図５に図示されるように、放送されるＭＰＥＧストリームは、番組の画像と関連付けられた表示時刻印を有する。この図では、各矢印は、関連する表示時刻印の値と共に番組の放送中に受信した画像を表す。放送は時間ｔ０で開始し、最初の受信した画像は値ｖａｌｕｅ＿１を有するＰＴＳ＿１と関連付けられる。２番目の受信した画像は値ｖａｌｕｅ＿２を有するＰＴＳ＿２と関連付けられ、以下同様である。必然的に、値ｖａｌｕｅ＿１はＰＴＳ＿Ｓｔａｒｔに対応する。この図では、最後の受信した表示時刻印に従い番組の始めに対する時間に自身を位置付けることが可能である。番組の始めに対する現在の相対時間を知るためには、この最後のＰＴＳ値から、格納されているＰＴＳ＿Ｓｔａｒｔの値を減算すれば良い。この時間は、ＰＴＳを生成するために使用される９０ｋＨｚクロックの精度で分かる。

図６は、通常速度の２倍の速度での早送りを図示する。図６では、２つに１つの画像が、関連付けられた時刻印と共に受信される。最初の画像は従って、値ｖａｌｕｅ＿１のＰＴＳと関連付けられる。一方で２番目は、通常速度で再生される番組の３番目の画像に対応し、ストリームが通常速度で再生された場合にこの３番目の画像の表示の瞬間に対応する値ｖａｌｕｅ＿３と関連付けられる。従って図６では再び、受信された最後のＰＴＳとＰＴＳ＿Ｓｔａｒｔとの差に基づく位置決めは、依然として番組の始めに対する現在相対時間を与える。

図７は、２倍速度への経過が放送中に時間ｔ１で生じる場合を図示する。ここで再び、通常速度での放送中にｔ０とｔ１との間か、又は２倍速度での放送中にｔ１とｔ２との間かに拘わらず、同一の技術は依然として番組の始めに対する信頼できる現在相対時間を与える。

残念ながら、一方で、「ＳＥＴＵＰ」コマンドが受理された場合に全てのサーバーがＰＴＳ範囲情報を与える訳ではないことが分かる。更に、サーバーがこの範囲を与える場合でさえ、受信したフロー内に含まれる表示時刻印が、時にはサーバーにより通信されるＰＴＳ＿Ｓｔａｒｔ及びＰＴＳ＿Ｅｎｄ値を計算するために使用されるリファレンスシステムと異なる時間リファレンスシステムで計算されることが分かる。また、放送される番組は、別個に符号化されているいくつかのシーケンスを組み立てたものである。この場合、一般に、各シーケンスは当該シーケンスの時間リファレンスシステムで計算された表示時刻印を有する。リファレンスシステムの変化は、放送中に起こる。この状況は図８に記載される。図８では、ｖａｌｕｅ＿１、ｖａｌｕｅ＿２、及びｖａｌｕｅ＿３と称される値は、第１のシーケンスに対応する。シーケンスの変化は時間ｔ１で生じる。ｖａｌｕｅ＿ｘ４及びｖａｌｕｅ＿ｘ５と称される値は、第２のシーケンスに対応する。各シーケンスは当該シーケンス自身のリファレンスシステムで符号化されている。シーケンスの中断は当該２つのシーケンスの間で生じる。

同様に、サーバーは番組の異なる版を利用し、早送り又は巻き戻しのような特定再生モードを実施し得る。この場合、サーバーは、遅い又は加速された速度での再生の要求に応答するため、通常放送のための番組の版、及び異なる速度で符号化された版を有する。例えば、２つのうち１つの画像を含む異なる版は、２倍速度の放送に使用される。ここで再び、各版は、一般に異なる時間リファレンスシステムで計算された表示時刻印を有する。この状況は図９に示される。図９では、２倍速度の高速再生要求が時間ｔ１で生じ、ＰＴＳの値ｖａｌｕｅ＿ｘ４及びｖａｌｕｅ＿ｘ６は、ｔ０とｔ１との間の通常速度で放送されるストリームの値ｖａｌｕｅ＿１、ｖａｌｕｅ＿２及びｖａｌｕｅ＿３と異なる別の時間にある。

シーケンス中断を有するこれらの問題の１つの解決法は、ＤＳＭ−ＣＣ規格（ＩＳＯ／ＩＥＣ１３８１８―６）の８章に記載されたような「ＮＰＴ記述子（ｄｅｓｃｒｉｐｔｏｒ）」の挿入である。これらの記述子は、シーケンス中断の瞬間にストリームに挿入され、そして結果の表示時刻印とストリームの論理リファレンスシステムとの間の対応を示す。しかし全てのサーバーがこの機能を使用するわけではない。

これらの問題を解決する別の方法は、受信した時刻印を使用しないが、要求される度に現在相対時間の値をサーバーに尋ねることである。ＲＴＳＰには、「ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ」コマンドの形式でサーバーからパラメーターを要求する機構が存在する。この場合、「ＰＬＡＹ」コマンドのような範囲引数を使用しなければならないコマンドを送出する前に、クライアントは、「ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ」コマンドを使用して、ストリームの相対時間現在位置を尋ねる。この方法は一般に機能的であるが、コマンドの送出及び結果の返送に対応する時間、及び対応する帯域の使用を導入する。

次にストリームの現在相対時間位置のローカルな計算の信頼できる方法の例を記載する。当該方法は、サ―バーによる記述子の挿入もサーバーへの要求の送出も必要ない。この方法はまた、処理されるべき表示時刻印内のシーケンス中断を許容する。この方法は図１０に示される。当該方法は、番組の始めに相対現在値を維持し、及び当該値を受信した時刻印の値に従い更新する。この方法は図１０に示される。第１の段階Ｅ１は番組の放送の開始時に実行される。第１の段階Ｅ１の間、最初に受信したＰＴＳはＦｉｒｓｔ＿ＰＴＳ変数に記憶される。変数Ｃｕｒｒｅｎｔ＿ｔｉｍｅは０に設定される。この変数は、常に、番組内の相対現在時間位置を有する。Ｌａｓｔ＿ＰＴＳ変数も最初のＰＴＳの値に設定される。Ｌａｓｔ＿ＰＴＳ変数は最後に受信したＰＴＳの値に対応する。

次に新たなＰＴＳ値がストリーム内で受信された場合、段階Ｅ２が実行される。この段階は、この新たに受信されたＰＴＳとＬａｓｔ＿ＰＴＳに記憶された前のＰＴＳとの間の差を計算する。この情報はＤｅｌｔａ変数に格納される。

シーケンス中断を検出する目的で、Ｄｅｌｔａ値は閾値と比較される。実際に表示時刻印はストリームのエンティティ、標準的にはビデオ画像と関連付けられ、２つの連続する受信したＰＴＳの間で期待される差を決定することが可能である。この差は、標準的に９０ｋＨｚクロックに従い表現される画像周波数である。本来、現在再生速度は考慮されなければならない。従ってＴｈｒｅｓｈｏｌｄ値を例えば画像周波数の２倍、又はサーバーの最大速度により乗算された画像周波数とセキュリティ係数の和に等しく決定することが可能である。Ｄｅｌｔａ値がこの閾値より大きい場合、シーケンス中断があると見なされる。その他の場合、如何なるシーケンス中断もないと見なされる。シーケンス中断が存在しない場合、段階Ｅ４が実行され、現在時間内のＤｅｌｔａ値を累積する。全ての場合で、段階Ｅ５で、最後に受信したＰＴＳ値は新たなＰＴＳで更新される。次に、ストリーム内の新たな表示時刻印を受信すると、段階Ｅ２へループバックする。

この方法では、Ｃｕｒｒｅｎｔ＿ｔｉｍｅ変数は、常に同一のシーケンスに属する時刻印の間の差の累積を有する。如何なる時間もシーケンス中断時に累積されない。

デコーダーがコマンドをサーバーへ送出し、限界の１つが現在時間である範囲を要求する場合、デコーダーはこの値を現在時間の基礎として使用する。ＮＰＴ値の秒での計算は直接的であり、画像周波数で除算されたＣｕｒｒｅｎｔ＿ｔｉｍｅに対応する。

フローが通常速度で再生されない特定再生モード、つまり遅い動き又は加速された速度のモードでは、記載された方法は、ストリームに挿入された表示時刻印が通常速度での再生のために計算された時刻印であると仮定する。実際に、２つのＰＴＳの間の差は、通常速度の再生中に２つの対応するエンティティの間の番組内の時間差を表現すると考えられる。いくつかのサーバーは、ＭＰＥＧ規格に従うために、通常速度に対し変更された速度の再生で新たな表示時刻印を生成する。例えば、４の係数の加速された速度で、通常モードのためのストリーム内の３個の他の画像により分割された２つの連続する画像は、通常モードのための及び画像周波数を４で分割したストリーム内の計算されたＰＴＳ値の代わりに画像周波数からの別個のＰＴＳ値を割り当てられる。記載された方法の変形は、変更された速度での再生中に、２つの時刻印の間の差を画像周波数と比較する。この差が再生速度による結果でなく画像周波数と近い場合、Ｄｅｌｔａは現在時間と共に累積される前に当該速度で乗算される。

本発明の実施例はＭＰＥＧ表示時刻印及びＮＰＴ形式で定められた範囲を使用するＲＴＳＰプロトコルの使用に基づく。しかし本発明はデジタルデータのフローに含まれる他の種類の時刻印に、及び他のサーバーコマンドプロトコルに一般化され得、及びこれはこのプロトコルにより使用される時間データ符号化方法に関係ない。実施例の例は、ＩＰネットワークのストリームの放送に基づく。しかし本発明は他の種類のネットワークに拡張され得る。

ＶＯＤ（ビデオオンデマンド）サーバーの知られているアーキテクチャを示す。 ＩＰデコーダーの実施例のハードウェアアーキテクチャを示す。 ＩＰデコーダーの実施例のソフトウェアアーキテクチャを示す。 クライアントとサーバーとの間のＲＴＳＰダイアログの例を示す。 関連するＰＴＳ値を備えた通常速度の再生中に受信した画像の図を示す。 受信した画像の図及び早送りの場合の関連するＰＴＳを示す。 受信した画像の図及び通常速度の再生から早送りへの経過中の関連するＰＴＳを示す。 受信した画像の図及び通常速度の再生ための無間隔の関連するＰＴＳを示す。 受信した画像の図及び通常速度の再生から間隔に変化を有する早送りへの経過中の関連するＰＴＳを示す。 デコーダーの時間識別方法のフローチャートを示す。

Claims (12)

1. 方法であって、受信機によりデジタルデータストリームサーバーへ命令を送出し、デジタルストリームは前記サーバーにより前記受信機へ、前記サーバーと前記受信機を接続するリンクを介し放送され、デジタルデータのフローは、所与の速度で再生されるよう設計された少なくとも１つの番組及びフローのデータと関連付けられた時刻印を有し、前記時刻印は、時間リファレンスシステム内の関連データを再生する瞬間で相対的であり、前記時刻印は互いにフロー内で順次続き、時間リファレンスシステムの変化はシーケンス中断を生じ、ストリーム内に現れることが可能であり、前記方法は、
   −前記デジタルデータストリームを受信する段階、
   −前記ストリームに含まれる番組内の現在相対時間位置を有するコマンドを送出する段階、を少なくとも有し、前記位置は前記受信機によりローカルに決定され、前記位置の決定に介入するストリームからの情報は、前記ストリームのデータと関連付けられた時刻印のみである、方法。
2. 現在相対時間位置の現在値を定期的に更新する段階を有する、請求項１記載の方法。
3. 更新する段階は、新たに受信した時刻印と最後に格納した時刻印との間の差に相当するデルタ値を決定する下位段階を有する、請求項２記載の方法。
4. 更新する段階はまた、デルタ値とストリーム再生速度に依存する閾値を比較する下位段階を有し、シーケンス中断の存在は、閾値より大きいデルタ値により決定される、請求項３記載の方法。
5. 更新する段階はまた、如何なるシーケンス中断もない場合、デルタ値を維持されている時間位置の現在値に加算する段階を有する、請求項４記載の方法。
6. 更新する段階はまた、如何なるシーケンス中断もない場合、再生速度で乗算されたデルタ値を維持されている時間位置の現在値に加算する段階を有する、請求項４記載の方法。
7. デジタルデータストリーム受信機であって、デジタルストリームは、前記サーバーから前記受信機へ、前記サーバーと前記受信機を接続するリンクを介し放送され、デジタルデータのフローは、所与の速度で再生されるよう設計された少なくとも１つの番組及び前記フローのデータと関連付けられた時刻印を有し、前記時刻印は、時間リファレンスシステム内の関連データを再生する瞬間で相対的であり、前記時刻印は前記フロー内で互いに順次続き、時間リファレンスシステムの変化はシーケンス中断を生じ、ストリーム内に現れることが可能であり、前記受信機は、
   −前記デジタルデータストリームを受信する手段、
   −前記ストリームに含まれる番組内の現在相対時間位置を有するコマンドを送出する手段、を少なくとも有し、前記受信機はまた前記位置を前記受信機によりローカルに決定する手段を有し、前記位置の決定に介入するストリームからの情報は、前記ストリームのデータと関連付けられた時刻印のみである、受信機。
8. 現在相対時間位置の現在値を定期的に更新する手段を有する、請求項７記載の受信機。
9. 更新する手段は、新たに受信した時刻印と最後に格納した時刻印との間の差に相当するデルタ値を決定する手段を有する、請求項８記載の受信機。
10. 更新する手段はまた、デルタ値とストリーム再生速度に依存する閾値を比較する手段を有し、シーケンス中断の存在は、閾値より大きいデルタ値により決定される、請求項９記載の受信機。
11. 更新する手段はまた、如何なるシーケンス中断もない場合、デルタ値を維持されている時間位置の現在値に加算する手段を有する、請求項１０記載の受信機。
12. 更新する手段はまた、如何なるシーケンス中断もない場合、再生速度により乗算されたデルタ値を維持されている時間位置の現在値に加算する手段を有する、請求項１０記載の受信機。

Images