JP4980913B2 - トリック・プレイ用メタデータのビデオ伝送ストリームへの挿入 - Google Patents

Description

関連出願への相互参照

本出願は、西暦２００４年９月２３日付け出願の米国仮出願番号６０／６１２，６２４号の利益を主張する。

本発明は一般にディジタル伝送システムに関し、特にトリック・プレイ機能をサポートするビデオ伝送システムに関する。

ディジタル配信システム（ケーブル、衛星、エアウェーブ経由、インターネット経由や同様なものなど）を介してビデオ番組を伝送する場合、ビデオ番組は、最終的にはビデオ受信器によって復号化される一連のデータ・パケットとして配信される。現在、衛星伝送又はエアウェーブ伝送を利用するビデオ配信システムは通常、「一方向」の伝送（大半のビデオ情報は、番組放送事業者からビデオ受信器（セットトップ・ボックスやテレビジョン受像機などの装置の形態）に伝送される）として知られている。しかし、受信装置が実際にバック・チャンネルをサポートする場合、放送事業者にもう一度伝送することができる（アップストリーム）情報の量は、放送事業者から受信装置に伝送される（ダウンストリーム）情報の量よりも少ない。

しかし、衛星伝送又はエアウェーブ伝送を介してビデオ・コンテンツを配信する場合、前述の配信システムは、トリック・プレイ機能（高速順送り、逆送り、中断、特定された時間量だけ順方向／逆方向にスキップなど）をサポートしない。多数のビデオ受信器にビデオを放送する際に前述の機能を放送事業者がサポートするやり方は何ら存在していないからである。特に、ビデオ受信器を操作している各ユーザが同時に別々のトリック・プレイ機能を望む場合、放送事業者に利用可能な放送帯域幅に対する制約が理由で、前述の機能全てを放送事業者が効率的にサポートするやり方は何ら存在しない。

本発明の一局面によれば、ビデオ受信器におけるトリック・プレイ機能のサポートに関する情報を含むデータ・パケットを放送する装置及び方法が提供される。

本発明の更に別の実施例によれば、放送事業者からの伝送の一部として伝送される情報を利用して、ビデオ受信器におけるビデオ・トリック機能をサポートする装置及び方法が提供される。

本発明の前述並びにその他の局面、特徴及び利点は、添付図面とともに検討するものとする、好ましい実施例の以下の詳細な説明から明らかになるであろう。

本発明は、ソース（衛星プロバイダ（ＤＩＲＥＣＴＶなど）、エアウェーブ・テレビジョン放送、ケーブル会社、ストリーミング・メディア・プロバイダ、ビデオ・オーバ・インターネット・プロトコル伝送や同様なものなど）からのパケット化データ信号の一部として伝送される情報を用いてビデオ再生装置（コンピュータ、セットトップ・ボックス、テレビジョン受像機や同様なものなど）におけるビデオ・トリック・プレイ機能をサポートする方法に関する。本発明の例示的な実施例は、衛星プロバイダ（ＤＩＲＥＣＴＶなど）などのプロバイダによって用いられるデータ伝送構造、又は、ＡＴＳＣ高品位標準（西暦１９９５年１０月４日付け発行のＡＴＳＣ ５３／Ａ標準を参照のこと）に準拠したデータ伝送構造を用いることに関して記載している。前述のモーダリティは限定的でなく、他の伝送の方法論、及び伝送構造に本発明の原理を当業者が適用することができる。

本発明は、ハードウェア、ソフトウェア、ファームウェア、特定用途向プロセッサ、又はこれらの組み合わせの種々の形態で実施することもできる。好ましくは、本発明は、ハードウェア及びソフトウェアの組み合わせとして実施される。更に、ソフトウェアは好ましくは、プログラム記憶装置上に有形的に実施されたアプリケーション・プログラムとして実現される。アプリケーション・プログラムは、何れかの適切なアーキテクチャを備えるマシンにアップロードし得るものであり、かつ、前述のマシンによって実行し得る。好ましくは、マシンは、ハードウェア（１つ又は複数の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）や入出力（Ｉ／Ｏ）インタフェースなど）を有するコンピュータ・プラットフォーム上に実現される。コンピュータ・プラットフォームは、オペレーティング・システム及びマイクロ命令コードも含む。本明細書及び特許請求の範囲記載の種々の処理及び機能は、オペレーティング・システムによって実行される、マイクロ命令コードの一部若しくはアプリケーション・プログラムの一部（又はそれらの組み合わせ）であり得る。更に、種々の他の周辺装置（更なるデータ記憶装置や印刷装置など）をコンピュータ・プラットフォームに接続することができる。

更に、添付図面に表した構成システム部分及び構成工程の一部は好ましくはソフトウェアで実現されるので、システム構成部分間（又は処理工程間）の実際の接続は、本発明がプログラムされるやり方によって変わり得る。本明細書及び特許請求の範囲に記載の教示を前提とすれば、当業者は、本発明の前述及び同様の実現形態又は構成を考え出すことができるであろう。

図１は、本発明の実施例によって用いる対象のビデオ放送及びビデオ受信器システム１００の概要レベルの図を示している。ビデオ放送システム１０は、ビデオ放送システムによって伝送される対象のビデオを供給するビデオ・コンテンツ１０５を提示する。好ましくは、ビデオ・コンテンツ１０５は、大容量記憶装置（ＤＶＤ、ビデオテープ、ハード・ドライブなど）上に記憶されるビデオ（及び、任意的には、オーディオ情報）が、リアルタイム性放送源（ビデオ・カメラなど）から、又は、ビデオ情報を伝送することができるデータ・ネットワークから供給される。

ビデオ・コンテンツ１０５からのビデオ情報は、好ましくは、ビデオ圧縮標準（ＭＰＥＧ−２、Ｈ．２６１、Ｈ．２６４や、同様なものなど）を用いて、ビデオ符号器１１０によってディジタル情報として符号化される。ＡＴＳＣの場合、ＭＰＥＧ−２を用いてビデオ情報を独立フレーム（Ｉフレーム）、双方向フレーム（Ｂフレーム）及び予測フレーム（Ｐフレーム）に圧縮する。他のタイプのビデオ圧縮を用いて、ビデオ符号器１１０からのビデオ・データを圧縮ビデオ・データ信号に圧縮することができる。ビデオ符号器１１０によってビデオを圧縮する動作は任意的であり、特定の放送に用いられないことがあり得る。例えば、放送事業者は、一連の非圧縮Ｉフレーム、又は他のタイプの非圧縮ビデオ情報としてビデオ信号を伝送することにし得る。

ビデオ符号器１１０からの符号化ビデオ信号が、ビデオ伝送符号器１１５に供給され、ビデオ伝送符号器は、いくつかのデータ伝送パケット（伝送ストリーム）から構成されるパケット化データ信号にビデオ信号を符号化する。本発明の実施例では、ビデオ符号器１１０からのビデオ符号化信号が、ＡＴＳＣ ５３／Ａ標準に記載されており、図２に示しているような伝送パケットから構成される伝送ストリームに符号化される。通常、伝送ストリームを用いてビデオ、オーディオ又は補助情報を伝送する。各伝送ストリームは、特定のパケット識別番号すなわちＰＩＤと関連付けられる。他のタイプの伝送パケット・スキーマ（伝送制御プロトコル（ＴＣＰ）、ユーザ・データ・プロトコル（ＵＤＰ）や同様なもの）を用いることができる。

特に、図２の伝送パケットは、４バイトのヘッダを有する１８８バイトのデータ・パケットを表す。ヘッダの最初の８ビットは同期バイトを表す。データ・パケットの第２の部分は、伝送パケット・エラー・フラグである単一ビット値である。伝送パケットの次の部分は、単一ビット値であるペイロード・ユニット開始インディケータ・フラグを表す。伝送優先度フラグは、伝送パケットに高優先度が割り当てられるか、又は低優先度が割り当てられるかを示す１ビット値から成る伝送の次のセグメントである。この伝送優先度フラグは通常、ＡＴＳＣベースのビデオ伝送のビデオ番組放送に用いられない。

次の１３ビットは、特定の伝送パケットが属する伝送ストリームを識別するＰＩＤ情報に予約される。伝送ヘッダの次の２ビットは、伝送スクランブル制御（パケット・ペイロードがスクランブルされるか否かを示す）を表す。後続する２ビットは、適合フィールド制御（適合ヘッダは、存在しているか否か、及び、同じ伝送パケットにおいてペイロードが付随しているかを開示している）を示している。ヘッダの最後の４ビットは、通常、単調に増加させられる連続性カウンタを表す。連続性カウンタを用いて、受信伝送データ・パケットの順序、及び、伝送データ・パケットが欠落しているか否かを示し得る。

伝送パケットの他の１８４ビットは、オーディオ・データ、ビデオ・データ、補助データ、又は３つのタイプのデータの混合物を表すパケットのペイロードである。ペイロードのコンテンツは通常、放送事業者の要件によって規定される。

図１に示すビデオ放送システム１０をもう一度参照すれば、処理済伝送ストリームが、ビデオ伝送符号器１１５からビデオ変調器／送信器１２０に供給される。ビデオ変調器／送信器１２０は、送信することができる信号にビデオ伝送ストリームを変調する。変調信号は、直交振幅変調（ＱＡＭ）、直交位相シフト・キーイング（ＱＰＳＫ）、残留側波帯（ＶＳＢ）及び同様なものなどの手法（特定のモーダリティ（衛星、エアウェーブ、ケーブル、モデムや同様なものなど）を介してビデオ信号を伝送するのに用いられる）を用いて変調することができる。任意的には、ビデオ伝送ストリームは、形式（トレリス符号化、リード・ソロモン符号化や同様なものなど）を用いた伝送のために符号化される。

ビデオ受信器システム２０（以下、受信器システム２０）は、ビデオ放送システム１０によって伝送されるデータ信号を表示装置上で再生し、表示することができるビデオ信号に処理することができるビデオ復調／復号器システムを表す。ビデオ受信器／復調器１５０は、ビデオ放送システム１０から送信されるデータ信号を（アンテナ、衛星アンテナ、ネットワーク・インタフェース接続や、同様なものを介して）受信し、更なる動作のためにデータ伝送ストリームにデ―タ信号を処理する。好ましくは、ビデオ受信器／復調器１５０は、データ信号を伝送するために変調器／送信器１２０によって行われたことの逆の動作を行う。例えば、トレリス符号化データ信号がＱＡＭを用いて変調されている場合、ビデオ受信器／復調器１５０は、ＱＡＭベースの復調及びトレリス復号化手法を用いて、リンク層サブシステムからの伝送ストリームに受信データ信号を復調する。別々の復調手法及び復号化手法を、受信器システム２０の要件に基づいて選択するものとする。

伝送復号器１６０は、ビデオ受信器復調器１５０から復号化伝送ストリームを受信し、符号化ビデオ情報、及びトリック・プレイ・データを表す情報に受信伝送パケットを処理する。本明細書の本文において以下に説明するように、伝送復号器１６０は、伝送パケットのヘッダ内又はペイロード内に埋め込まれた情報を読み取って、受信器システム２０のトリック・プレイ機能を支援する。伝送復号器１６０によって抽出される情報の例は、本明細書の本文で以下に説明する通りである。

ビデオ復号器１６５は、伝送復号器１６０から処理済データを受信する。好ましくは、ビデオ復号器１６５は、処理済データを取得し、前述のデータを、表示装置１７３（テレビジョン、モニタ、及び同様なものを表す）上に表示することができるビデオ情報に復号化する。ビデオ復号器１６５によって行われるビデオ復号化動作は、ビデオ符号器１１０によって行われる逆動作である。例えば、処理済データがＭＰＥＧ−２ビデオとして符号化された場合、ビデオ復号器１６５は、表示装置１７３上に表示することができるビデオ信号にＭＰＥＧ−２ビデオを復号化する。ビデオ復号器１６５によって行われる復号化動作は、ビデオ・データの符号化に用いられる符号化手法によって変わってくる。任意的には、ビデオ復号器１６５は、伝送復号器１６０から受信される処理済データからのオーディオ情報も復号化する。この復号化オーディオ情報は、ビデオ復号器１６５によって音としてスピーカ１７４に出力することができる。

伝送復号器１６０に結合された局所メモリ１７５は、受信器システム２０によるトリック・プレイ機能をサポートするために受信伝送パケットから抽出される情報を記憶するのに用いられる。この情報は、本明細書中で以下に説明するように、伝送復号器１６０によって伝送パケットから抽出される情報から構成されるメタデータのテーブルであり得る。

記憶装置１８０は、伝送復号器１６０から受信される伝送ストリーム、伝送復号器１６０から受信される復号化伝送ストリーム、及びビデオ復号器１６５から受信される復号化ビデオ・データを記憶するよう調節される。好ましくは、記憶装置１８０は、記憶装置（ハード・ドライブ、ランダム・アクセス・メモリ、フラッシュ・カード、ディジタル多用途ディスク、テープ・システムや同様なものなど）である。ビデオ・データ及び伝送ストリームを記憶する以外に、記憶装置１８０は、トリック・プレイ機能（高速順送り、巻き戻し、中断、順方向スキップ、逆方向スキップや同様なものなど）をサポートするよう調節される。

システム・プロセッサ１５５は、前述の受信器システム２０の構成部分を制御するために受信器システム２０によって用いられるマイクロプロセッサである。本発明の任意的な実施例では、システム・プロセッサ１６５は、伝送復号器１６０と組み合わされる。

一連のデータ伝送パケットとしてディジタル信号を送信する場合、送信システム１０及び受信器システム２０は、前述のデータ伝送パケットの特定部分を用いて、前述のデータ伝送パケットにおいて配信されるビデオ・データについての情報を示すことによってトリック・プレイ機能をサポートすることができる。トリック・プレイ・メタデータを表すこのデータは、伝送パケット（ヘッダ、ペイロード又は両方）に伝送符号器１１５によって挿入される。同様に、ディジタル・データが受信器システム２０によって処理される場合、伝送復号器１６０は、前述のトリック・プレイ・メタデータを、前述のメタデータが存在し得る伝送パケットから抽出するよう構成される。

この抽出メタデータを次いで受信器システム２０によって用いて、トリック・プレイ・メタデータと、受信器システム２０に配信され、受信器システム２０によって処理されるビデオ情報とを関係付けるメタデータ表を構成する。例えば、表１は、トリック機能をサポートするのに用いるトリック・プレイ・メタデータ表の例示的な実施例を表す。この例では、表１は、パケット化されたデータ伝送ストリーム内で受信されるＩフレームの時間位置情報を示す。時間位置は表のエントリとして格納される。他のトリック・プレイ関連の情報を上記表内に格納することができる。

トリック・プレイ・メタデータの作成に用いる値は好ましくは、伝送復号器１６０によって局所メモリ１７５に記憶される。更に、記憶装置１８０は任意的には、伝送ストリームを表すデータ、符号化ビデオ情報、又は、トリック・プレイ機能を起動させるためにシステム・プロセッサ１５５によってアクセスされる復号化ビデオ情報を記憶するのに用いることができる。

本発明の実施例によれば、伝送ストリームは、受信器システム２０によって受信されると、（局所メモリ１７５に記憶されるように）表１内のコンテンツを作成するよう処理され、伝送ストリームのビデオ・データのコンテンツは、前述の通り、符号化ビデオとして記憶装置１８０に記憶される。受信器システム２０がトリック・プレイ・モード（高速順送りなど）において動作する場合、システム・プロセッサ１５５は、局所メモリ１７５内のトリック・プレイ・メタデータをアクセスして、記憶装置１８０に記憶されたＩフレームの時間位置を判定する。記憶装置１８０に記憶されたＩフレームのみ（１．２７秒、２．５４秒、３．７１秒、及び同様なものの順序で）をアクセスし、復号化することによって、システム・プロセッサ１５５は、やはり、記憶された符号化ビデオ・データの一部として存在しており、高速順送りのトリック・プレイ動作の場合、不必要なＢフレーム及びＰフレームを復号化することなく、ビデオ復号器１６５に提示する対象のビデオ・データが分かる。更に、システム・プロセッサ１５５は、表内に格納された他のメタデータを用いて、入り口点及び対応するバイト・カウントの時間コードを照会することによって「５分間順方向に飛び越し」などの機能をサポートすることが可能である。更に、メタデータ表を照会することによって、システム・プロセッサ１５５は、番組の開始及び終了全てを位置特定し、番組コンテンツについてのテキスト詳細（番組の開始、終了及び持続時間のリストなど）を提示することが可能である。他のトリック・プレイの機能及びアプリケーションを当業者は本発明の原理によって実現することができる。

送信システム１０から受信システム２０に伝送ストリームの一部としてトリック・プレイ・メタデータを送信する場合、本発明の一実施例は、（ＡＴＳＣベースの伝送パケットの）その伝送優先度ビットを交換させ、（このビットは、ＡＴＳＣにおいて（又はＤＩＲＥＣＴＶストリームにおいて）通常用いられないので）トリック・プレイ・メタデータを代わりに挿入する。伝送パケット・ヘッダ（、及び、よって、伝送優先度ビット）が通常、伝送中に暗号化されていないので、伝送パケットの伝送ヘッダが、トリック・プレイ・メタデータの挿入のための理想的な場所としての役目を担うことを本発明の発明者は認識している。よって、復号器は、セキュリティ・サブシステムのサポートを必要とすることなく、トリック・プレイ・メタデータを利用することができる。

トリック・プレイ・メタデータの場所としての伝送優先度ビットの利用をもう一度参照すれば、伝送優先度ビットとして送信されるビットはバイトに組み立てることが可能であり、前述のバイトは、完全なメッセージに組み立てることが可能である。複数のメッセージはその場合、特定のＰＩＤのメタデータ、及び、ＰＩＤが対応する要素ストリームを備える。

意義有るトリック・プレイ・メタデータを生成するために単一のビット群では十分でないことがあり得るように思われ得るが、４Ｍｂｐｓのビデオ・ストリームの場合、４千個を超えるパケットが、毎秒送信される（ＡＴＳＣベースの配信システムの場合の２６５０個のデータ・パケットと比較して）。よって、伝送優先度ビットのみを用いることによって、数百バイトのトリック・プレイ・メタデータは、受信器システム２０が受信し、用いることができる。他の伝送パケット部分（他のヘッダ部分、ペイロード、ヘッダ及びペイロードをはじめとする）、及び、他のタイプの伝送パケット自体を、本発明の原理によって、トリック・プレイ関連のメタデータを送信するのに用いることができる。

表２は、一連のデータ伝送パケットから抽出される優先度ビット・データから組み立てられるトリック・プレイ・メタデータを提示するメッセージの例示的な実施例を表す。

表３は、一連のデータ伝送パケットから抽出される優先度ビット・データから組み立てられるトリック・プレイ・メタデータを提示する別のメッセージの例示的な実施例を表す。

受信伝送パケットが無くなったか、又は受信中にエラー状態にある場合、その点より後の現在のメタデータ・メッセージは疑わしく、新たな開始コードが検出されるまで、メッセージの更なる獲得は停止する。本発明の任意的な実施例では、「ペイロード」の構文は、開始コード・エミュレーションを行わなくてよいように構成される。特に、このことは、メッセージを構成する構文要素間のマーカ・ビット（値「１」の）を挿入することによって達成される。データの最後に、「１」の値が、次の開始コードまで繰り返される。

トリック・プレイ・メタデータを伝送に合わせることが可能な場合、伝送ヘッダ・フラグ（バウンダリ・バンドル・ビット又はペイロード・ユニット開始インディケータ（ＡＴＳＣベースの伝送パケットに用いられているような）はその場合、メタデータ・メッセージ（トリック・プレイ機能をサポートするためのメタデータとしての役目を担うことが可能である）の存在を示す開始インディケータとしての役目を担うことが可能である。前述の条件下では、メタデータ伝送は任意的には、表４に示す形式に変わる。開始コードの、意図されていないトリガを回避するためにデータを束縛しなくてよい。同様に、伝送パケットのヘッダ内のインディケータ・フラグは、伝送パケットのペイロード内の、トリック・プレイ関連のメタデータの存在を示すよう設定することが可能である。

表４に示したような特定のアラインメント形式の下では、伝送ペイロード内に含まれる特定ビデオ・フレーム・データに関する新たなセマンティックが推定される。例えば、特定のフレームの「番組時間コード」を示すデータ・タイプは、前述のフレームを含む同じ伝送パケットから組み立てることが可能である。このタイプの対応関係は、トランスポート・マルチプレックスにおいて送信される、全部ではないが大半のフレームについて達成することが可能である。

表２乃至表４に示す伝送構造に用いるような、トリック・プレイ・メタデータの伝送に用いることができるＣＯＭＭＡＮＤフィールド及びＤＡＴＡフィールドの一般的な構造を以下に提示する。一般化されたＣＯＭＭＡＮＤコマンド及びＤＡＴＡコマンドは、併せて連結し、複数のコマンド及びデータの列として送信することができる（ＢｙｔｅＣｏｕｎｔ変数のサイズが検出されるまで、「フィル」ビットが検出されるまで、又は、次の開始コードが検出されるまで）。データ伝送パケットにおいてビデオ情報の属性を記述するのに用いることができるＣＯＭＭＡＮＤタイプ及びＤＡＴＡタイプを表５に示す。

他のＣＯＭＭＡＮＤ値は全て、予約済であり、コマンドに対するオペランドとして、後続する対象の更なるデータ・バイトの数を記述した１バイトのデータがこれに続く。

表５に示すような、ＣＯＭＭＡＮＤコマンド及びＤＡＴＡコマンドの使用は任意的である。例えば、Ｉフレームの示標がないことは、現在のフレームがＩフレームでないことをアサートするものでない。しかし、伝送パケットにおいて明示的にアサートされたＣＯＭＭＡＮＤ及びＤＡＴＡの場合、前述のＣＯＭＭＡＮＤ及びＤＡＴＡの意味は真である。

前述の方法論を用いれば、ビデオ・フレームが受信器システム２０によって受信されるレートと（同じではないが）ほぼ同じレートで構成される。例えば、５分間のみのビデオが捕捉され、記憶装置１８０上に記憶される場合、前述の同じ５分間のトリック・プレイ・メタデータも記憶装置１８０上に記憶される。

任意的には、記憶装置１８０を用いるために、部分的な伝送ストリームを記憶することができる（所望の番組に寄与しないデータ・パケットが受信システム２０によって廃棄される）。前述の方法論を用いることによって、伝送復号器１６０による一定の度合いの伝送ストリーム復号化が必要になる。この任意的な復号化処理中に、トリック・プレイ・メタデータを抽出し、部分的な伝送ストリームとは別の場所に記憶することが可能である。このようにして、伝送ストリームの記憶を、記憶装置１８０及び関連した記憶システム構成部分によって扱い、ビデオ・データの最適な取り出し及び再生を容易にするための更なる暗号化又はデータ再編成を可能にすることができる。よって、トリック・プレイ・メタデータは、更なるサーチ処理のために、オープン状態、及び受信器システム２０に対して局所の状態に留まることが可能である（メタデータは、伝送ストリーム自体ではなくビデオ・パラメータを求めてサーチされる）。適切なメタデータが見つかると、単純なファイル索引コマンドを、記憶装置１８０などの記憶サブシステムに対して生成することが可能である。

本発明の更なる任意的な実施例として、トリック・プレイ・メタデータに関する情報を、一意のＰＩＤの１つ又は複数の伝送パケットのペイロードに挿入されるパケット化要素ストリーム（ＰＥＳ）構造に入れることができる。前述の場合には、提示タイム・スタンプ（ＰＴＳ）フィールドを追加することを用いて、特定のＰＥＳパケットがあてはまる単一のフレームを識別する。本発明のこの任意的な実施例は、チャンネル・ガイド情報に関連したトリック・プレイ・メタデータの送信、又は、トリック・プレイ・メタデータがあてはまる番組を識別する番組特有情報（ＰＳＩ）の送信をサポートする。

図３は、本発明の実施例による、受信伝送ストリームからのトリック・プレイ・メタデータを抽出し、用いる方法３００を示す。工程３０５は、トリック・プレイ・メタデータとして用いることが可能なデータが伝送パケット内に存在しているか否かを識別する任意的な工程である。前述の通り、トリック・プレイ・メタデータとして用いることができる情報は、伝送パケット・ヘッダ、伝送パケットのペイロード、複数のスパン・パケット・ヘッダ、又は前述の可能性全ての組み合わせにおいて存在し得る。更に、メタデータの識別は、種々のコマンド及びデータ形式（前述のような）を用いることにより、又は、本発明の原理による他の手順により、トリック・プレイ・メタデータの存在を示す特定のフラグを取っておくことによって行うことができる。

工程３１０は、受信された伝送パケットからの、トリック・プレイ・メタデータとして用いることができる情報の抽出である。通常、伝送復号器１６０がこの工程を行うが、受信器システム２０の他の構成部分によって実現することができる、工程３１０の別の実施例が存在する。例えば、受信伝送ストリームは、トリック・プレイ・メタデータとして用いることができる情報の存在を求めて前述のデータ・ストリームを伝送復号器１８０が後の時点で解析するまで記憶装置１８０にアーカイビングすることができる。工程３１５では、トリック・プレイ・メタデータを表す抽出情報は、メモリ（局所メモリ１７５や記憶装置１８０など）に記憶される。好ましくは、前述のメタデータ情報は、前述の通り、表内に格納される。

工程３２０は、トリック・プレイ機能をビデオ再生中に起動させる場合、ビデオ再生装置（受信器装置２０など）は、トリック・プレイ・メタデータを表す記憶データにアクセスし、前述の情報を用いて、所望のトリック・プレイ機能を実現する。前述の通り、ユーザが、高速順送りのトリック・プレイ機能を望んでいる場合、ビデオ再生装置（２０）は、記憶装置１８０に記憶されたＩフレームの時間位置を位置特定し、高速順送り動作中にのみ前述のフレームを出力する。他のトリック・プレイ機能は、本発明の原理によって、記憶されたトリック・プレイ・メタデータを用いることによって実現される。

本発明は、高度テレビジョン方式委員会（ＡＴＳＣ）ベースの通信システムに関して説明しているが、本発明は、何れかのパケット・ベースのディジタル通信システムに用いることができる。

添付図面を参照して例証的な実施例を本明細書及び特許請求の範囲において説明したが、本発明は前述のまさにその実施例に限定されるものでなく、本発明の範囲から逸脱することなく、当業者によって種々の他の変更及び修正をそれにおいて行うことができる。前述の変更及び修正は全て、特許請求の範囲記載の本発明の範囲内に含まれることが意図されている。

ビデオ信号送信器システム及びビデオ信号送信器・受信器システムの例示的な実施例を示す図である。 伝送パケットの例示的な実施例を示す図である。 トリック・プレイ機能のイネーブルをサポートするよう伝送パケットからトリック・プレイ・メタデータを抽出する方法の例示的な実施例を示す概略図である。

Claims (10)

1. パケット化データ・ストリームの形式でビデオ情報を送信する方法であって、前記方法は、
   ビデオ情報を複数の伝送パケットにフォーマッティングする工程と、
   トリック・プレイ機能をサポートするためにトリック・プレイ・メタデータを前記伝送パケットの伝送ヘッダに挿入する工程と、
   前記伝送パケットを送信する工程と
   を含み、
   前記トリック・プレイ・メタデータは前記ビデオ情報の属性を記述し、
   前記トリック・プレイ・メタデータは、前記トリック・プレイ機能をサポートするために使用される少なくとも１つのメッセージを表すバイトに組立て、前記伝送パケットの前記送信前に前記伝送ヘッダの伝送優先度ビットに挿入される方法。
2. 請求項１記載の方法であって、前記伝送パケットの少なくとも１つの伝送パケットのペイロード内に前記トリック・プレイ・メタデータが存在している旨を示すよう、前記伝送パケットの少なくとも１つの伝送パケットの伝送ヘッダにおいてインディケータ・フラグが起動される方法。
3. 請求項１記載の方法であって、前記伝送パケットの少なくとも１つの伝送パケットは、少なくとも１つのコマンドを表すデータを有しており、
   前記少なくとも１つのコマンドは、現在フレームの時間コード、番組開始の時間コード、最後の不連続の時間コード、番組終了の時間コード、現行フレーム・サイズに関する情報、現在番組サイズに関する情報、前記少なくとも１つの伝送パケット内のビデオ・フレームを示す情報、トリック・モード・キー・フレーム、復号化参照フレーム、不連続フレーム、及び、静止フレームと、該フレームを表示する秒数とを表す情報、のうちの少なくとも１つから選択される方法。
4. パケット化データ・ストリームの形式でビデオ情報を受信する方法であって、前記方法は、
   前記パケット化データ・ストリームから複数の伝送パケットを、前記伝送パケット内の前記ビデオ情報に対応するトリック・プレイ・メタデータを抽出するよう処理する工程であって、前記トリック・プレイ・メタデータは、前記伝送パケットの伝送優先度ビットから抽出され、トリック・プレイ機能を実現するために使用される少なくとも１つのメッセージを表すバイトに組立てられる工程と、
   前記トリック・プレイ機能をサポートするよう前記トリック・プレイ・メタデータを示す情報を記憶する工程と
   を備える方法。
5. 請求項４記載の方法であって、
   前記トリック・プレイ・メタデータを示す情報をアクセスする更なる工程と、
   前記トリック・プレイ・メタデータを示す情報を用いて前記トリック・プレイ機能を実現する更なる工程とを備える方法。
6. 請求項４記載の方法であって、前記記憶された情報は、表内に格納される方法。
7. 請求項４記載の方法であって、
   前記伝送パケットからのデータを記憶装置に記憶する更なる工程を備えており、前記記憶されたデータは、前記伝送パケット、前記伝送パケットから復号化されるビデオ情報、前記伝送パケットから復号化され、前記伝送パケットから抽出される前記トリック・プレイ・メタデータに鑑みて選択されるビデオ情報のうちの少なくとも１つである方法。
8. 請求項４記載の方法であって、前記トリック・プレイ・メタデータの抽出は、前記伝送パケットにおける前記トリック・プレイ・メタデータの存在を示すインディケータ・フラグに鑑みて行われる方法。
9. 請求項４記載の方法であって、前記抽出は、メタデータの表内の少なくとも１つのエントリを満たすように複数の伝送パケットについて繰り返される方法。
10. 請求項１記載の方法であって、前記トリック・プレイ・メタデータは、前記伝送パケットの前記伝送優先度ビットから抽出され、受信装置において前記トリック・プレイ機能を実現するために使用される少なくとも１つのメッセージを表すバイトに再び組立てられる方法。

Images