JP2009515391A

JP2009515391A - データ・ソースからデータ・シンクへのデータ・フローの転送のための方法、データ・シンク装置、データ・ソース装置、およびこれを実行するための装置

Info

Publication number: JP2009515391A
Application number: JP2008538329A
Authority: JP
Inventors: ヒユツター，インゴ; ベーバー，ミヒヤエル
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2005-11-02
Filing date: 2006-10-24
Publication date: 2009-04-09
Anticipated expiration: 2026-10-24
Also published as: EP1943804B1; KR101390880B1; CN101288286B; WO2007051729A8; EP1943804A1; US7984205B2; JP5085553B2; TWI415432B; US20090240848A1; DE102005052207A1; TW200719641A; CN101288286A; KR20080063359A; WO2007051729A1

Abstract

【課題】
ＡＶデータ・フローの転送において、特に、ネットワーク環境において、動作モードを例えば、通常再生から順方向の早送りサーチに変更する際、一方の動作モードから他方の動作モードへの移行が遅延することがある。
【解決手段】
上述した問題を解決するために、本発明によれば、動作モードの変更を求めるリクエストの後、所望のデータが高速に復号化されるように、バッファ・メモリ内の所望しないデータを適切な手段を通じて速やかに除去することが提案される。これを行うために、新たな動作モードのための識別子（ＩＤ）がデータ・ソース装置（１０）の側のデータ・フローに挿入される。データ・シンク装置（２０）における復号器（２１）の復号化ドライバは、データ・フローに挿入された識別子（ＩＤ）をサーチし、この識別子と組み合わせられない全てのデータ・パケットを拒絶する。
【選択図】図３

Description

本発明は、マルチメディア・コンテンツ、特に、ビデオ・コンテンツやオーディオ・コンテンツのトリック・モード再生の技術分野に関し、特に、例えばホーム・ネットワークなどのネットワーク環境におけるトリック・モードの発生について参照する。

データ・ソース（ｄａｔａｓｏｕｒｃｅ：データ源、データ送信装置）とデータ・シンク（ｄａｔａｓｉｎｋ：データ受信装置）との間のＡＶデータの転送は、業界における多数の調査および標準化の対象となっている。上記を具体的に記載した例示的なネットワークは、略語ＨＡＶｉ（ＨｏｍｅＡｕｄｉｏ／Ｖｉｄｅｏｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）およびＵＰｎＰ（ＵｎｉｖｅｒｓａｌＰｌｕｇａｎｄＰｌａｙ）によって知られている。ＡＶデータ・フローの転送は、これらのネットワーク・システムにおいて特に考慮されている。なぜならば、ＨＡＶｉシステムは、主に、この用途のために開発され、ＵＰｎＰシステムについては、ＵＰｎＰの作業グループは、一般的なＵＰｎＰ仕様に基づくＵＰｎＰＡＶ仕様をまとめあげ、これを拡張しているからである。この仕様の指定は、２００２年６月１２日付のＵＰｎＰＡＶアーキテクチャ０．８３である。

上記仕様は、ＡＶ装置の検出、ＡＶコネクションのセットアップ、ＡＶコンテンツの検出、データ・ソースおよびデータ・シンク装置を動作させること、通常再生およびトリック・モード再生における選択されたＡＶコンテンツの再生などをサポートしている。

トリック・モードの再生動作にはいくつかの問題が付随するため、ネットワーク内の２つの装置ＡおよびＢの間のデータ転送が詳細に考慮される。装置Ａは、例えば、ハード・ディスクに基づき、ＡＶコンテンツが保存されるディジタル・ビデオ・レコーダのようなデータ・ソースであると仮定する。装置Ｂは、例えば、表示装置などのデータ・シンクとして機能する。両方の装置は、データ交換や制御コマンドの交換をするための通信インタフェースを備えている。データ転送（これは、例えば、ＴＣＰ／ＩＰに基づいたネットワークにおいてＨＴＴＰまたはＲＴＰを介して、行うことができる）において、データは、一般に、複数の異なるバッファ・メモリを通過しなくてはならない。この意味において、転送ネットワーク自体がメモリとしてみなされる。なぜならば、この転送がネット上で遅延さえも生じさせることがあるからである。

ＡＶコンテンツの再生は、通常再生の場合は比較的簡単である（従って、単純な再生速度を有する）。通信インタフェースを介して、各装置には、どのコンテンツがどこに存在し、何を受信するかが通知され、その後、再生が開始する。しかしながら、いわゆる各トリック・モード（順方向早送り、逆方向早戻し、スロー・モーション、静止画）には問題が伴う。例えば、ＡＶシステムが通常の再生モードにあり、次に、一時停止せずにより高速な順方向速度、例えば、３倍速サーチ機能に切り替えられる場合を考える。

ここで、装置Ａは、いわゆる「サーバーサイド」トリック・モード、すなわち、表示されない画像が除去された有効なデータを受信機が受信するように、ソースがデータ・フローを変更することをサポートしている。このため、対応するトリック・モード・モジュールが装置Ａ内のデータ・パス内にループされる。

このモジュールによって発生されたデータは、今度は、転送パス、例えば、送信機メモリ、受信機メモリ、さらに、データ復号器のためのバッファ・メモリ上の各メモリを通らなければならない。すなわち、切り替えの際にこれらのメモリに依然として存在するデータを、トリック・モードのための特定のデータを復号化することができるようになる前に、装置Ｂ内の復号器によって、実際に、依然として復号化しなければならない。

このような特徴は問題であり、ユーザは、これがシステムの慣性であると気付く。即ち、ユーザがシステムに順方向機能の変更を求めることを通知した後にも依然として再生が継続され、実際には、一定の時間経過した後、ようやく順方向の早送りに変更される。この時間遅延は、本質的に利用可能なメモリのサイズに依存する。

本発明の目的は、上述した時間遅延を最小限にして、ユーザがシステムを遅いと感じにくいようにする方法および対応する装置を提供することにある。

本発明の解決法は、ユーザによるトリック・モードに変更するリクエストがあった際にメモリ内に依然として存在したデータを削除することに基づくものである。これを行うために、受信機装置内で実行される手段が提案される。この装置は、実際には無関係なデータを受信するが、これを復号化せずに無視する。さらに、この実現のために、受信機装置は、（新たに設定されたトリック・モードの例において、）関連するデータの開始がいつであるかを知らなければならない。この問題は、ＡＶデータ・フローに追加の制御データを埋め込むことによって解決される。追加の制御データは、後続するＡＶデータがユニークに特定のアクションに属していることを識別する。

アクション・フローに関して以下のシナリオが想定される。
装置Ａにおいて、ユーザは、動作モードの変更に関するリクエストを発する。装置Ａは、後でデータ・フローに挿入される識別子を生成し、これを、ＡＶデータ・フローとは非同期に通信インタフェースを介して装置Ｂに送信する。従って、装置Ｂは、将来、この識別子でマークされたＡＶデータの再生のみをすべきであることを把握する。ソース装置Ａはここで、トリック・モードのデータ・パスを切り替え、前記識別子を新たなデータに挿入する。

ユーザは、装置Ｂにおける動作リクエストを発する。通信インタフェースを介して、動作リクエストが装置Ａに転送される。このメッセージは、既に動作リクエストのための識別子を含んでいる。動作リクエストの転送と同時に、装置Ｂ自体の中で制御コマンドが送信され、これは、復号器に対し、将来的に、通知された識別子が与えられたＡＶデータまたはこの識別子が前に存在するＡＶデータのみを復号化すべきであることを知らせる。装置Ｂは、従って、トリック・モードに変更した後、動作リクエストの対象とならないデータを「破棄（ｓｃｒａｐ）」し、装置Ａは、データ・フローに識別子を挿入する。

従属請求項に記載した手段は、本発明に係る方法の有益な発展および改良を実現するものである。

例えば、追加的な制御データは、データ・フローに一回組み込まれるだけでなく、規則的な間隔で繰り返されることが望ましい。これにより、セキュアでない転送方法を介した転送の場合（例えば、ＲＴＰプロトコルに従った転送の場合）、（例えば、無線データ接続の介在によって生じる）転送パス上のデータで想定される損失によってイライラさせるような障害が発生するようなことはなくなり、さらに、既にデータを送信しているデータ・ソースに対して時間的に後に接続される追加のデータ・シンクが、データ・ソース装置の、送信側、または、現在の動作モードをトリガーするコマンドについての情報を受信するであろう。

動作モードの識別子は、データ通信のＯＳＩ／ＩＳＯレイヤー・モデルの範囲内で、トランスポート・レイヤー上のデータ・フローの中に組み込まれることが望ましい。なぜならば、これは、有用なロード・データ・フローの操作を必要としないからである。

例えば、ＡＶデータ・フローの転送のためにＨＴＴＰプロトコルが使用される場合、動作モードは、それ自体を、特にトリック・モード再生において、ＨＴＴＰ１．１仕様に従ったいわゆるかたまり転送符号化（ｃｈｕｎｋｅｄｔｒａｎｓｆｅｒｅｎｃｏｄｉｎｇ）の動作モードであると示唆するものである。この転送方法においては、有用なデータは様々な長さのブロックで転送され、ブロック長は実際のブロックの前に１６進数の数として転送される。ブロック長の表示の後に、セミコロンによって分けられたコメント文字列を挿入することが可能であり、このコメント文字列こそが、本発明の範囲の中で、前記識別子の転送のために使用される。

ＲＴＰプロトコルによるＡＶデータ・フロー転送において、ＲＴＰパケットのヘッダ内にいわゆるＸビットが設定される。このビットが設定されたとき、追加のヘッダをいわゆる「ＲＴＰヘッダの拡張」として標準のヘッダに追加することができる。本発明に係る識別子をこの追加のヘッダに挿入してもよい。

通常の再生から、より高速な順方向早送りか逆方向早戻しに切り替える場合、ある再生モードから別の再生モードに変更する際、バッファ・メモリの消去、または、「破棄（ｓｃｒａｐｐｉｎｇ）」によるスキップ（飛び）が存在する。通常の動作モードからより高速のトリック・モードに変更する際には問題は生じない。なぜならば、概して、順方向または逆方向への変更が、実際には、所望の再生ポイントに到達するために行われるものであるため、再生中に想定されるスキップがイライラさせるようなものではなく、スキップは、トリック・モード自体の間にも発生するからである。これは、ビデオ・フィルムが再生される際、スロー・モーションまたは静止画像モードのトリック・モードである場合には当てはまらない。通常再生からトリック・モード再生へのスムーズな移行を達成するために、データ・シンク装置が追加的に、最後に復号化されたマルチメディア・コンテンツが何であったかについてデータ・ソース装置に知らせる。この情報が有用なデータ・フローの中に存在しない場合には、データ・ソース装置がＡＶデータ・フローの中に追加的な情報を挿入して装置Ｂが正確な位置情報を判定できるようにするとよい。本発明の別の手段によれば、さらに、データ・シンク装置は、復号化の処理がどのポイントまで進行したかをデータ・ソース装置に知らせる。そこで、データ・ソース装置は、トリック・モード再生をこのポイントに正確に合わせ、前に再生が中断されたポイントでトリック・モード・データ・フローの生成を開始する。

データ・フロー内の正確なデータ位置をデータ・ソース装置からデータ・シンク装置に規則的に転送することが特に有用である。これに基づいて、データ・シンク装置は、再生が中断されたポイントを特定することができる。代替的には、データ位置の代わりに時間コードを転送するか、または、これらの両方を一緒に転送することも可能である。時間コード情報は、例えば、再生カウンタを表示するためのソース情報と同時に、データ・シンク装置内でも使用することができる。

請求項８および９は、本発明に係るデータ・シンク装置のための対応する有益な手段を列挙している。請求項１０〜１５は、本発明に係るデータ・ソース装置のための対応する有益な手段を列挙している。

本発明は、データ・ソースおよびデータ・シンクがネットワークによって接続された別個の装置内に位置しているものではなく、代わりに、単一の装置に位置している場合にも有益に使用することができる。請求項１６は、本発明に係る方法を実行するためのこのような装置のための本発明に係る各手段を列挙している。

本発明の例示的な実施の形態は、各図面に示されており、以下により詳細に説明する。
図１において、参照符号１０によってディジタル・ビデオ・レコーダＤＶＲを示す。ディジタル・ビデオ・レコーダ１０には、大容量記憶装置が設けられ、ビデオおよびオーディオ・コンテンツを保存する。今日の標準的なディジタル・ビデオ・レコーダは、このためのハード・ディスクを有する。参照符号２０は、ディジタルＴＶ装置ＤＴＶを示している。これには、ディジタル・オーディオおよびビデオ信号のための復号器が組み込まれたＬＣＤやプラズマＴＶのようなフラット画面装置を用いることができる。参照符号３０は、ＤＶＤプレーヤを示している。全ての装置１０〜３０は、ネットワークに接続されている。図１に示す例示的な実施の形態においては、このためにネットワーク接続スイッチ・ユニット４０が設けられ、ネットワーク接続スイッチ・ユニット４０は、「ネットワーク・スイッチ」または「ルータ」としても知られている。ネットワークにおけるデータは、イーサーネット・プロトコルに従って転送される。ネットワーク・ケーブルとしては、市販で入手可能なイーサーネット・ネットワーク・ケーブルが使用される。データは圧縮された状態で転送されるため、ＡＶデータ・フローの転送のために、１００Ｍｂｉｔのイーサーネット用のネットワーク・ケーブルの使用が既に適したものとされている。

参照符号５０は、パーソナル・コンピュータＰＣを示し、参照符号６０は、プリンタＰＲＴを示している。これらの２つの装置は、各々のネットワーク接続スイッチ・ユニット８０を介してネットワークのその他の機器に接続されている。さらに、ネットワークは、ネットワーク・ユーザ・ステーションとしてのパーソナル・データ・アシスタントＰＤＡ７０を含む。しかしながら、この装置は、無線でネットワークに対し、ネットワーク接続スイッチ・ユニット８０によってサポートされる対応する無線接続経路を介して接続される。

図２は、互いに結合された２つの装置、データ・ソース装置（データ送信装置）１０およびデータ・シンク装置（データ受信装置）２０、さらに、これらの構造を関連する概略的なブロック図によって示している。ディジタル・ビデオ・レコーダ１０において、ハード・ディスク１１が大容量記憶装置として設けられている。ハード・ディスク１１からデータを読み出す際、読み出されたデータは、まず読み出しメモリ１２に行く。大容量記憶装置１１内のデータは、既に、符号化された形態で、圧縮されて保存されていると想定される。通常の再生においては、データは記録されずに、データ・パスは、読み出しメモリ１２を介してハード・ディスク１１から直接送信側のメモリ１４に至るようになっており、ここから、データは、通信インタフェース１５、ネットワークを介してデータ・シンク装置２０に転送される。送信側のメモリ１４を満たすための現状の技術において公知なアルゴリズムをデータ・ソース装置１０において使用することができる。

トリック・モードに切り替える際、データ・ソース装置１０内のデータ・パスもまた切り替えられる。トリック・モードとして考慮されるものは、高速順方向再生（早送り）、高速逆方向再生（早戻し）、スロー・モーション、さらに、静止画再生がある。上述したように、データは、圧縮した状態で保存され、大容量記憶装置１１内で符号化される。例えば、ＭＰＥＧ２符号化方法がビデオ符号化に使用されている場合には、何らかの速度のトリック・モードへの切り替えには、データが記録されることを必要とする。ＭＰＥＧ２ビデオ符合化方法に従って、３つの異なるタイプの画像が使用されることが知られている。これらは、イントラ符号化画像Ｉ、片方向予測画像Ｐ、双方向予測画像Ｂである。

一定の、または、任意のシーケンスに従ったデータ・フロー内に複数の異なるタイプの画像が現れる場合がある。Ｉ画像およびＰ画像は、先行する、または、後続する画像に依存するため、これらは、単純に、単独に転送することができず、関連する基本となる画像と一緒にしか転送されない。これは、トリック・モードを実現する際の１つの困難である。このため、現在の技術では、大容量記憶装置に存在するＭＰＥＧ２のデータ・フローを実際に復号化してトリック・モード再生を生じさせ、次にこれらを再符号化して転送される画像の選択に新たな自由を生み出すことが提案されている。このため、データ・ソース装置１０にトリック・モード発生器１３が設けられる。この発生器は、トリック・モード再生に切り替えられると、データ・パス内でループされる。読み出しメモリ１２に存在するＭＰＥＧ２データは、次に、記録されて、新たなＭＰＥＧ２データ・フローが発生し、送信側メモリ１４に受け渡される。図２にスイッチング・ユニット１６による切り替えを示す。

図示しているように、転送されたデータは、ネットワークを介してデータ・シンク装置２０に入る。上述したように、データ・シンク装置２０は、主なコンポーネントとして、復号器２１およびディスプレイ・ユニット２６を含むディジタルＴＶ装置である。ディスプレイ・ユニットとして、プラズマ・パネルまたはＬＣＤパネルが使用されると仮定する。復号器２１は、例えば、ＭＰＥＧ２復号器である。これに対し、バッファ・メモリ２２が復号メモリとして割り当てられる。しかしながら、データは、まず、通信インタフェース２５を介して装置内に受け渡され、次に、受信側バッファ・メモリ２４内に提供される。デマルチプレクサ・ユニット２３は、データを複数の異なる復号器ユニットに分配し、このうち、ビデオ復号器ユニット２１のみがブロック図に示されている。ディジタルＴＶ装置２０は、ユーザが遠隔制御によってこの装置を操作できるように標準的な方法で設けられている。

次に、図２に従った構成の動作モードを図３に基づいて説明する。ディジタルＴＶ装置２０がデータ・ソース装置１０からビデオ・データ・フローを受信し、関連するコンテンツを通常再生モードで表示することを想定する。時間ｔ１において、データ・ソース装置１０は、通常再生のためのデータ・フローの送信を開始する。バッファ・メモリ、受信側バッファ・メモリ２４および復号器用バッファ・メモリ２２が満たされるまでに幾らかの時間が経過する。時間ｔ２において、データ・シンク装置２０において受信したデータ・フローの再生が開始する。従って、受信されたコンテンツは、特定の時間遅延を有して復号化される。時間ｔ３において、操作者は、通常再生を中断し、この代わりに、トリック・モード再生、例えば、順方向の３倍速サーチの実行への変更を求めるリクエストを行う。データ・シンク装置２０内の通信インタフェース２５は、このリクエストをデータ・ソース装置１０に送信する。この後、データのさらなる送信が停止される。図３の上部は、データのどの部分がそれぞれ送信されたかを示している。図示するように、時間ｔ４において、斜線で示されたデータ部分がデータ・シンク装置２０に転送されている。図３の下部は、データ・シンク装置内で既に復号化されたデータのパーセンテージを示している。上述したように、データの受信と復号化の開始との間には遅延が存在する。時間ｔ４では、上部のハッチングされたデータの復号化はまだ行われていない。通常再生が時間ｔ４で中断されているので、バッファ・メモリ２４および２２内には時間ｔ３と時間ｔ４との間に転送されたデータが依然として存在する。

リクエストされたトリック・モードにおける高速な変更を実現するために、これらのデータは、バッファ・メモリ２４および２２から本発明に従って除去される。これは、データ・シンク装置２０の側よりトリック・モードのリクエストが転送される際に、識別子がデータ・ソース装置１０に通知されるように行われる。データ・ソース装置１０内のデータ・パスが切り替えられた後、トリック・モード発生器１３は、通知された識別子を新たに発生したデータ・フロー内に挿入する。データ・シンク装置２０内の復号器ドライバは、次に、データ・パケットの復号化の前に、このデータ・パケットが転送された識別子を含むかどうかをチェックする。転送された識別子を含む場合に該当しない限り、データ・パケットは、拒絶され、復号化されない。従って、復号化メモリ２２のデータは高速に放出され、再び、受信側メモリ２４からの、新たな、フレッシュなデータによって満たされる。時間ｔ３と時間ｔ４との間の図３におけるデータ・フローのハッチングされた部分全体が拒絶される。さらに、トリック・モードに変更される前に既にデータ・ソース装置１０の送信側バッファ１４に存在するデータ部分もまた、拒絶される。データ・フローにおいて最初に通知された識別子が見つかった際、後続するデータ・パケットの復号化が開始される。これは、図３に示す時間ｔ５の場合に該当する。

図４は、データ・シンク装置２０の側でデータ・ソース装置１０に対して、通常の再生から順方向の３倍速サーチ・モードに変更するために行われるＨＴＴＰＧｅｔリクエストを示している。示されている例においては、リクエストされたファイル名は、キーワードＧｅｔの後に続く。これは、パラメータ名ＩＴＥＭによって通知されるものである。例として、ファイル名“ＭｅｎＩｎＢｌａｃｋ．ｍｐｇ”が示されている。同じ行のＨＴＴＰのバージョン情報の後、次の行における情報は、どこでこのファイルが見つけられるかに関する情報に続く。このパラメータを指定するために、第２行のサーバ名の前に‘ｈｏｓｔ’の語が置かれる。

最後のもう一行は、サーチ速度および再生方向のパラメータを有する。パラメータ名は、従って、ＡＶ＿ＳＰＥＥＤである。図示された例においては、パラメータ情報は、ｆｏｒｗａｒｄ＿３の語であり、これは、高速サーチが順方向の３倍速で行われるべきであることを示している。

ＨＴＴＰＧｅｔの範囲内で、転送モード「かたまり転送符号化（ｃｈｕｎｋｅｄｔｒａｎｓｆｅｒｅｎｃｏｄｉｎｇ）」は、それ自体が、トリック・モード・データの転送のためのものであることを示唆している。この点に関しては、出願人の先願の欧州特許公報（ＥＰ−Ａ−１５３１６０１）を参照する。本発明の開示内容の範囲内で、この文献を明確に参照する。図５は、ＨＴＴＰＧｅｔリクエストに対するソース装置１０の側のレスポンス（応答）を示している。第１行は、受信が成功したＨＴＴＰＧｅｔリクエストのためのステータス・レポートを提供する。さらに、第１行は、ＨＴＴＰプロセスに関するバージョン情報を含んでいる。第２行は、日付および時刻を示している。第３行は、どのタイプのデータが続いて転送されるかをキーワードＣｏｎｔｅｎｔＴｙｐｅによって知らせるものである。上述した例は、ＭＰＥＧ２フォーマットで符号化されたビデオ・データに関する。次に、第４行は、後続する転送が「かたまり転送符号化（ｃｈｕｎｋｅｄｔｒａｎｓｆｅｒｅｎｃｏｄｉｎｇ）」モードで行われることを知らせるものである。続いて、第１のデータ部分が送信されるが、この前に、１６進数の数として対応するデータ部分の長さ表示が置かれる。セミコロンによって長さ表示と分けられて、コメント文字列をＨＴＴＰ仕様の後に設けることができる。これは、本発明のために、データ・シンク装置２０における復号化ユニットが注意を払わなくてはならない識別子を転送するために使用される。この例は、データ・フローが３倍速での順方向早送りの動作モードと同じであるという情報として単純にＦＦ３を示している。図５は、この情報が「かたまり転送符号化（ｃｈｕｎｋｅｄｔｒａｎｓｆｅｒｅｎｃｏｄｉｎｇ）」モードで転送される各データ部分と共に転送されることを示している。これは、本発明では必須ではないが、初めに記載したように有益である。

図６は、通常再生動作モードからスロー・モーション動作モードに変更する特別な場合における時間条件を示している。再び、通常動作モードは、時間ｔ４で停止する。この場合、しかしながら、スロー・モーション動作モードへの変更が行われるべきであり、通常再生モードとスロー・モーションとの間のスムーズな移行が重要である。これは、本発明に従って実現されるようになり、データ・ソース装置１０に対して行われるデータ・シンク装置２０側でのＨＴＴＰＧｅｔリクエストにおいても最後に復号化された画像の時間が示される。図７に関連するＨＴＴＰＧｅｔリクエストを示す。パラメータＡＶ＿ＳＰＥＥＤは、スロー・モーション（ＳＭ：ＳｌｏｗＭｏｔｉｏｎ）のためのエントリＳＭを有する。下部には、復号器の時間（ＤＥＣＯＤＥＲＴＩＭＥ）として、時刻０１：０２：０３：０３が示されている。従って、データ・ソース装置１０には、データ・シンク装置２０において最後に復号化された画像についての情報が与えられる。通常再生からスロー・モーションへのスムーズな移行のために、データ・ソース装置１０は、新たに符号化されたデータの流れを０１：０２：０３：０４の時間コードを有する、後続して表示される画像の時点から開始される新たに符号化されたデータ・フローを送信する。時間情報は、セミコロンによって分けられて、「かたまり転送符号化（ｃｈｕｎｋｅｄｔｒａｎｓｆｅｒｅｎｃｏｄｉｎｇ）」内のデータ・ブロックの長さ表示の後に提供される。また、コンマによって時間情報と分けられて、新たに開始された動作モードＳＭの識別子が続いている。この識別子に基づいて、データ・ソース装置２０は、再び、データの復号化を再度開始しなければならないことを決定する。識別子ＳＭを含む新たなデータ・フローが到着するまで、復号器メモリ２２から読み出された全てのデータが全て拒絶される。図６によれば、時間ｔ６において、新たなデータ・フローの復号化が開始される。斜線は、時間ｔ６において復号化されたデータが正確には時間ｔ３および時間ｔ４との間に転送されるデータに対応しないことを強調している。なぜならば、図８に示されているように、スロー・モーション再生のためのデータ・フローは、具体的に記録されているからである。このような記録されたデータは、データ・シンク装置２０においてｔ５の時点で受信されたものである。しかしながら、これらは、開始時間コードに関し、時間ｔ３の時点で転送されたデータには対応している。従って、通常再生からスロー・モーション再生へのスムーズな移行が可能となる。

代替的に、時間コード情報の代わりに対応するブロックの開始の絶対バイト位置をパラメータとして転送してもよい。この位置は、受信されたデータ・バイトをカウントすることによって受信機自体によって理論的に判定できるという反論が想定されるが、これは、間違っている。なぜならば、このようなことは、通常速度での再生の場合にのみ可能だからである。通常再生およびトリック・モードとの間の切り替えがなされるとすぐに、データ・ソース装置において、トリック・モード記録がなされるため、受信されたバイト数は、オリジナルのドキュメント内の位置には対応しなくなる。

ＨＴＴＰプロトコルの代わりにＲＴＰ（ＲｅａｌＴｉｍｅＰｒｏｔｏｃｏｌ：リアルタイム・プロトコル）がデータの転送に使用される場合、追加の情報がＲＴＰパケットの標準ヘッダに対して追加ヘッダの形態で付加される。この場合、いわゆるＸビットがＲＴＰパケットの標準的なヘッダにセットされる。

図２に示すように、トランスポート・パケット（ＨＴＴＰパケットまたはＲＴＰパケット）は、まず、データ・シンク装置２０内の通信インタフェース２５に送られる。これらのデータ・パケットは、しかしながら、ここでは処理されず、次に、有用なデータ・コンテンツのみが受信メモリ２４内に転送される。これは、受信側メモリ２４内のパケットの有用なデータを保存するためのフォーマットが判定されることを必要とし、識別子、時間コード情報、または、バイト位置情報、データ長および有用なデータが連続的に続くようにする。対応する記憶装置フォーマットを図９に示す。参照符号９１は、識別子ＩＤを示す。参照符号９２は、バイト位置情報のためのフィールド、または、時間コードのためのフィールドを示す。参照符号９３は、データ・ブロックの長さが示されるフィールドを示す。さらに、参照符号９４は、パケットの有用なデータを示す。このフォーマットは、さらに、データ・シンク装置２０内のさらなるデータ・パス内でも維持され、データは、復号器メモリ２２内でこのフォーマットで受信される。復号器２１のための復号器ドライバは、次に、各エントリを分析し、所望の識別子９１が最初に発生するデータ・ブロックの新しいコンテンツの復号化を開始する。

本発明のホーム・ネットワーク内のアプリケーションに関する例示的な実施の形態について説明した。基本的には、データ・ソース装置およびデータ・ターゲット装置の各装置は、ネットワークにおいて別個の装置として動作するが、単一の装置内ではモジュールとして動作する。例えば、ＤＶＤプレーヤでは、モジュールとして動作する。

図１は、ホーム・ネットワークの例を示す図である。図２は、ネットワークを介して接続されたデータ・ソース装置とデータ・シンク装置の概略ブロック図である。図３は、本発明に係る動作モードを変更する際の再生機能、または、復号化機能のタイム・フローを示す図である、図４は、通常再生モードからサーチ・モードに変更するＨＴＴＰＧｅｔリクエストを示す図である。図５は、図４に従ったＨＴＴＰＧｅｔリクエストに対するレスポンスを示す図である。図６は、通常再生モードからスロー・モーション再生に変更する際の再生機能または復号化機能のタイム・フローを示す図である。図７は、データ・シンク装置からデータ・ソース装置に送信される関連するＨＴＴＰＧｅｔリクエストのフォーマットを示す図である。図８は、関連するＨＴＴＰＧｅｔレスポンスのフォーマットを示す図である。図９は、データ・シンク装置の復号器メモリにおいて使用されるデータ・パケットのフォーマットを示す図である。

Claims

データ・ソース（１０）からデータ・シンク（２０）にデータ・フローを転送する方法であって、
前記データ・フローが複数のデータ・セットからなり、
前記方法は、
ａ）前記データ・ソース（１０）の側でデータ・パケットを送信するステップと、
ｂ）前記データ・シンク（２０）の側で前記データ・パケットを受信するステップと、
ｃ）バッファ・メモリ（２２）内に前記データ・パケットを一時的に保存するステップと、
ｄ）前記バッファ・メモリ（２２）内の前記データ・パケットのデータを復号化するステップと、
を含み、さらに、
ｅ）データ識別のための識別子（ＩＤ）と結合された、別の動作モードへの変更を求めるリクエストを受信するステップと、
ｆ）前記識別子（ＩＤ）と結合されていないデータ・パケットを前記バッファ・メモリ（２２）から除去するステップと、
ｇ）前記データ・ソース（１０）の側で、前記識別子（ＩＤ）を送信して後続するデータ・パケットが新たな動作モードに従って送信されることを指定するステップと、
ｈ）前記データ・シンク（２０）の側で、前記識別子（ＩＤ）およびデータ・パケットを受信するステップと、
ｉ）前記データ・パケットを前記バッファ・メモリ（２２）内に一時的に保存するステップと、
ｊ）前記識別子（ＩＤ）が前記データ・パケットより前または一緒に受信されたかどうかをチェックし、前記識別子（ＩＤ）が前記データ・パケットより前または一緒に受信された場合には、前記バッファ・メモリ（２２）内の前記データ・パケットのデータを復号化するステップと、
を含むことを特徴とする、前記方法。
前記識別子（ＩＤ）が、規則的な間隔で前記データ・フローに挿入される請求項１に記載の方法。
前記識別子（ＩＤ）が、データ通信のＯＳＩ／ＩＳＯレイヤーのモデルに従ってトランスポート・レイヤー上のデータ・フローに挿入される請求項１または２に記載の方法。
前記識別子（ＩＤ）が、トランスポート・パケットの部分である請求項３に記載の方法。
前記データ・フローは、「かたまり転送符号化（ｃｈｕｎｋｅｄｔｒａｎｓｆｅｒｅｎｃｏｄｉｎｇ）」モードでＨＴＴＰプロトコル、アナログ・ハイパー・テキスト転送プロトコルに従って転送され、前記識別子（ＩＤ）は、ＨＴＴＰデータ・パケットにおけるコメント文字列としてブロック長の表示の後に挿入される請求項１〜４のいずれか１項に記載の方法。
前記データ・フローは、ＲＴＰプロトコル、アナログ・リアル・タイム・プロトコルに従って転送され、前記識別子は、ＲＴＰデータ・パケットの追加のヘッダ内に挿入される請求項１〜５のいずれか１項に記載の方法。
絶対的なデータ位置および／または再生時間位置が追加的にデータ・パケット内で示される請求項１〜６のいずれか１項に記載の方法。
請求項１〜７のいずれか１項に記載の方法を実行するデータ・シンク装置であって、送受信用インタフェース（２５）と、復号化ユニット（２１）と、別の動作モードへの変更を求めるリクエストを生成する手段とを備え、
データ・ソース装置（１０）に対して、前記送受信用インタフェース（２５）を介して、前記リクエストが識別子（ＩＤ）と組み合わされて送信され、
記憶装置管理手段が設けられ、当該記憶装置管理手段は、前記リクエストが生成された後、１つまたは複数のデータ・パケットを前記バッファ・メモリ（２２）から除去し、前記識別子（ＩＤ）と組み合わされたデータ・パケットの時点で前記データ・パケットの復号化を行うことを特徴とする、前記データ・シンク装置。
前記記憶装置管理手段が、前記識別子（ＩＤ）と共にデータ・パケットを前記バッファ・メモリ（２２）内に保存するように設計されていることを特徴とする請求項８に記載のデータ・シンク装置。
請求項１〜７のいずれか１項に記載の方法を実行するためのデータ・ソース装置であって、送受信用インタフェース（１５）と、大容量記憶装置ユニット（１１）と、第１および第２の動作モードに従ってデータ・フローを提供する手段とを備え、
別の動作モードへの変更を求めるリクエストを受信した後、前記データ・フローを提供する手段が前記リクエストに従ったリクエストされた動作モードの識別子（ＩＤ）を含むデータ・フローを発生させることを特徴とする、前記データ・ソース装置。
前記提供手段が規則的な間隔で前記データ・フロー内に前記識別子（ＩＤ）を挿入する請求項１０に記載のデータ・ソース装置。
前記提供手段が前記識別子（ＩＤ）をトランスポート・パケット内に挿入する請求項１０または１１のいずれかに記載のデータ・ソース装置。
前記提供手段が、前記識別子（ＩＤ）を前記各トランスポート・パケットの部分として前記データ・フローに挿入する請求項１２に記載のデータ・ソース装置。
前記提供手段が、「かたまり転送符号化（ｃｈｕｎｋｅｄｔｒａｎｓｆｅｒｅｎｃｏｄｉｎｇ）」モードでＨＴＴＰプロトコルに従ってデータ・フローを発生させ、ＨＴＴＰパケットにおけるコメント文字列としてブロック長の表示の後に識別子（ＩＤ）を挿入する請求項１０〜１３のいずれか１項に記載のデータ・ソース装置。
前記提供手段は、ＲＴＰプロトコル、アナログ・リアル・タイム・プロトコルに従ってデータ・フローを発生させ、前記識別子（ＩＤ）をＲＴＰトランスポート・パケットの追加のヘッダ内に挿入する、請求項１０〜１３のいずれか１項に記載のデータ・ソース装置。
請求項１〜７のいずれか１項に記載の方法を実行する装置であって、データ・ソース（１０）およびデータ・シンク（２０）と、第１および第２の動作モードに従ってデータ・フローを提供する手段と、復号化ユニット（２１）および当該復号化ユニット（２１）のためのバッファ・メモリ（２２）と、識別子（ＩＤ）と組み合わされる別の動作モードへの変更を求めるリクエストを生成する手段とを備え、
前記動作モードの変更を求めるリクエストを受信した後、前記データ・フローを提供する手段は、前記リクエストに従った前記リクエストされた動作モードの識別子（ＩＤ）を含むデータ・フローを発生させ、前記バッファ・メモリ（２２）のために記憶装置管理手段が設けられ、当該記憶装置管理手段は、前記リクエストが生成された後、前記バッファ・メモリ（２２）から１つ以上のデータ・パケットを除去し、前記識別子（ＩＤ）に組み合わされたデータ・パケットの時点で前記データ・パケットを復号化することを特徴とする、前記装置。