(57)【要約】  本発明は、モバイル動画受信機にデジタル動画データを放送する改良型ザッピングサービスに関し、特に、そのための動画エンコーダおよびデコーダに関する。ザッピングサービスは静止画像（フレーム内符号化フレーム）を、対応するメイン動画サービスのＰフレームと同期した形で含む。個々の同期データは動画エンコーダが生成してモバイル受信機に伝送する。同期データにより、モバイル受信機の動画デコーダは、ザッピングサービスＩフレームをランダムアクセスポイントとして用いた、符号化メインサービス画像シーケンスの復号を行うことができる。よって、新たなメイン動画サービス（ザッピング）の選択後、メイン動画サービスの表示準備ができるまでの待ち時間は短くなる。また、メインサービスチャンネルで伝送する際に帯域幅を消費するＩフレームの数も少なくなる。よって、帯域幅必要量が小さくなる。【選択図】  図５
2009528709.tif 000002
【特許請求の範囲】
【請求項１】
モバイル受信機への伝送のために入力動画画像のシーケンス（１０５）を符号化する動画エンコーダであって、
予測符号化手順を用いて入力画像シーケンス（１０５）を符号化して、符号化画像データのシーケンス（１１１）に変える符号化手段（１１０）と、
モバイル受信機に別個に伝送される個別の画像の前記入力画像シーケンス（１０５）における位置を示す同期データを生成する同期手段（１３０）と、
を有することを特徴とする動画エンコーダ。
【請求項２】
モバイル受信機に別個に伝送される前記個別の画像を符号化する、静止画像符号化手段（１２０）を更に有すること、
を特徴とする請求項１に記載の動画エンコーダ。
【請求項３】
前記静止画像符号化手段（１２０）は、個別の画像をフレーム内符号化フレーム（Ｉ）として符号化すること、
を特徴とする請求項２に記載の動画エンコーダ。
【請求項４】
前記静止画像符号化手段（１２０）は、個別の画像をＩＤＲ（Instantaneous Decoding Refresh）アクセスユニットとして符号化すること、
を特徴とする請求項３に記載の動画エンコーダ。
【請求項５】
前記同期手段（１３０）は、前記入力画像シーケンス（１０５）のうちモバイル受信機に別個に伝送される個別の画像の複数について、位置を示す同期データを生成すること、
を特徴とする請求項１乃至４のいずれかに記載の動画エンコーダ。
【請求項６】
前記入力画像シーケンス（１０５）のうちの所定の画像を、前記受信機に別個に伝送される個別の画像として選択する選択手段（５０５）を更に有すること、
を特徴とする請求項１乃至５のいずれかに記載の動画エンコーダ。
【請求項７】
前記符号化手段（１１０）は、前記符号化画像データのシーケンス（１１１）のうちの前記の選択された所定の画像を、Ｐフレーム（Ｐ）として符号化すること、
を特徴とする請求項６に記載の動画エンコーダ。
【請求項８】
前記選択手段（５０５）は、前記符号化手段（１１０）によってＰフレームとして符号化されることになる入力画像シーケンス（１０５）のＮ枚毎の画像を、前記受信機に別個に伝送される個別の画像として選択し、Ｎは自然数であること、
を特徴とする請求項７に記載の動画エンコーダ。
【請求項９】
所定のタイムアウト時間を繰り返しカウントするタイマを更に有し、
前記選択手段（５０５）は、前記所定のタイムアウト時間が経過するたびに、その時点での入力画像シーケンス（１０５）の画像を、前記受信機に別個に伝送する個別の画像として選択すること、
を特徴とする請求項６または７に記載の動画エンコーダ。
【請求項１０】
前記入力画像シーケンス（１０５）の画像を保存する静止画像バッファを更に有し、
前記静止画像バッファに保存された画像は、別個にモバイル受信機に伝送される前記個別の画像として使用されること、
を特徴とする請求項１乃至９のいずれかに記載の動画エンコーダ。
【請求項１１】
伝送される全てのデータをインターネットプロトコル（ＩＰ）パケット（１４１）にカプセル化するネットワークパケタイザ（１４０）を更に有すること、
を特徴とする請求項１乃至１０のいずれかに記載の動画エンコーダ。
【請求項１２】
前記パケット（１４１）が、前記同期データ内に含まれる形でタイムスタンプを有すること、
を特徴とする請求項１１に記載の動画エンコーダ。
【請求項１３】
前記ネットワークパケタイザ（１４０）は、データを、ユーザデータグラムプロトコル（ＵＤＰ）およびリアルタイムプロトコル（ＲＴＰ）と共に、インターネットプロトコル（ＩＰ）のパケットにカプセル化すること、
を特徴とする請求項１１または１２に記載の動画エンコーダ。
【請求項１４】
前記同期手段（１３０）は、リアルタイムプロトコル（ＲＴＰ）パケットのヘッダに前記タイムスタンプを挿入して、入力画像シーケンス（１０５）の同じ画像から生じたデータを有するリアルタイムプロトコル（ＲＴＰ）パケットが同じタイムスタンプを有する、という形にすること、
を特徴とする請求項１２または１３に記載の動画エンコーダ。
【請求項１５】
符号化画像データのシーケンス（１１１）をモバイル受信機に伝送する送信機であって、
請求項１乃至１４のいずれかに記載の動画エンコーダと、符号化画像データの前記シーケンス（１１１）と前記個別の画像（１１２）と前記同期データ（１１１，１１２）とを伝送する伝送手段と、を有すること、
を特徴とする送信機。
【請求項１６】
前記伝送手段は、符号化画像データの前記シーケンス（１１１）をバースト（１０）の形式で伝送し、前記バースト（１０）は、第１の伝送チャンネル上で、間隔（２０）をおいて伝送されること、
を特徴とする請求項１５に記載の送信機。
【請求項１７】
前記伝送手段は個別の画像（１２１）を、別の伝送チャンネル上で、間隔（６０）をおいてバースト（５０）の形式で伝送すること、
を特徴とする請求項１６に記載の送信機。
【請求項１８】
前記個別の画像を伝送するための前記バースト（５０）は、各々が個別の画像を１つだけ含むこと、
を特徴とする請求項１７に記載の送信機。
【請求項１９】
符号化画像データの前記シーケンス（１１１）を伝送するための前記バースト（１０）の間の間隔（２０）は、個別の画像（１２１）を伝送するための前記バースト（５０）の間の間隔（６０）よりも長いこと、
を特徴とする請求項１７または１８に記載の送信機。
【請求項２０】
符号化画像データの前記シーケンス（１１１）は、ＤＶＢ−ＨまたはＤＭＢ標準に従って伝送されること、
を特徴とする請求項１５乃至１９のいずれかに記載の送信機。
【請求項２１】
モバイル受信機において符号化画像データを復号する動画デコーダであって、前記モバイル受信機は、符号化画像データのシーケンス（２２１）および個別の画像の画像データ（２２２）を、画像シーケンスに対する前記個別の画像の位置を示す同期データと共に受信するものであり、前記動画デコーダは、
予測復号手順を用いて符号化画像データの画像シーケンス（２２１）を復号する復号手段（２２０）と、
前記個別の画像の位置に基づいて前記復号手段（２２０）の復号処理を開始させる同期手段（２６０）であって、示された位置の後に続く符号化画像データの予測復号において個別の画像が参照画像として参照される、という形で開始させる同期手段（２６０）と、を有すること、
を特徴とする動画デコーダ。
【請求項２２】
個別の画像の前記受信された画像データ（２２２）は、符号化画像データであり、そして、
前記動画デコーダは、前記個別の画像の前記符号化画像データを復号する静止画像復号手段（２２０）を更に有すること、
を特徴とする請求項２１に記載の動画デコーダ。
【請求項２３】
前記個別の画像は、フレーム内符号化フレーム（Ｉ）として符号化されること、
を特徴とする請求項２２に記載の動画デコーダ。
【請求項２４】
前記個別の画像は、ＩＤＲ（Instantaneous Decoding Refresh）アクセスユニットとして符号化され、前記同期手段（２６０）は、前記ＩＤＲアクセスユニットを、前記シーケンスの前記符号化画像データの復号のためのランダムアクセスポイントとして用いること、
を特徴とする請求項２３に記載の動画デコーダ。
【請求項２５】
個別の画像の位置は、符号化画像データの前記シーケンス（２２１）の内部でのＰフレーム（Ｐ）の位置と同じ、または近くにあること、
を特徴とする請求項２１乃至２４のいずれかに記載の動画デコーダ。
【請求項２６】
符号化画像データの前記シーケンス（２２１）は、間隔（２０）をおいて伝送されるバースト（１０）の形式で受信されること、
を特徴とする請求項２１乃至２５のいずれかに記載の動画デコーダ。
【請求項２７】
前記個別の画像は、シーケンスのうち前記同期データが示す画像位置を含む符号化画像データを含んだバースト（１０）に先立って受信されること、
を特徴とする請求項２６に記載の動画デコーダ。
【請求項２８】
データは、インターネットプロトコル（ＩＰ）パケット（１３１）の形式にカプセル化された形で受信されること、
を特徴とする請求項２１乃至２７のいずれかに記載の動画デコーダ。
【請求項２９】
前記同期データは、前記インターネットプロトコル（ＩＰ）パケットに含まれた形で、タイムスタンプを有していること、
を特徴とする請求項２８に記載の動画デコーダ。
【請求項３０】
データは、ユーザデータグラムプロトコル（ＵＤＰ）およびリアルタイムプロトコル（ＲＴＰ）と共にインターネットプロトコル（ＩＰ）のパケットにカプセル化されること、
を特徴とする請求項２８または２９に記載の動画デコーダ。
【請求項３１】
前記タイムスタンプは、リアルタイムプロトコル（ＲＴＰ）パケットのヘッダに含まれていること、
を特徴とする請求項２９または３０に記載の動画デコーダ。
【請求項３２】
リアルタイムプロトコル（ＲＴＰ）パケットは、シーケンスのうち前記同期データが示す画像位置を含む符号化画像データを含み、そして、リアルタイムプロトコル（ＲＴＰ）パケットは、同じタイムスタンプを有する前記個別の画像のデータを含むこと、
を特徴とする請求項３１に記載の動画デコーダ。
【請求項３３】
リアルタイムプロトコル（ＲＴＰ）パケットは、シーケンスのうち前記同期データが示す画像位置を含む符号化画像データを含み、そして、リアルタイムプロトコル（ＲＴＰ）パケットは、お互いに近いタイムスタンプを有する前記個別の画像のデータを含むこと、
を特徴とする請求項３１に記載の動画デコーダ。
【請求項３４】
符号化画像データの前記シーケンス（２２１）は、ＤＶＢ−ＨまたはＤＭＢ標準に従って受信されること、
を特徴とする請求項２１乃至３３のいずれかに記載の動画デコーダ。
【請求項３５】
モバイル受信機への伝送のために入力動画画像のシーケンスを符号化する符号化方法であって、
予測符号化手順を用いて入力画像シーケンス（１０５）を符号化して符号化画像データのシーケンス（１１１）に変える、入力画像シーケンス符号化ステップと、
前記入力画像シーケンス（１０５）のうちモバイル受信機に別個に伝送される個別の画像の位置を示す同期データを生成する同期データ生成ステップと、
を有することを特徴とする方法。
【請求項３６】
モバイル受信機に別個に伝送される前記個別の画像を符号化する符号化ステップを更に有すること、
を特徴とする請求項３５に記載の方法。
【請求項３７】
前記個別の画像を符号化する符号化ステップでは、個別の画像がフレーム内符号化フレーム（Ｉ）として符号化されること、
を特徴とする請求項３６に記載の方法。
【請求項３８】
前記個別の画像を符号化する符号化ステップでは、個別の画像がＩＤＲ（Instantaneous Decoding Refresh）アクセスユニットとして符号化されること、
を特徴とする請求項３７に記載の方法。
【請求項３９】
前記同期データ生成ステップでは、前記入力画像シーケンスのうちモバイル受信機に別個に伝送される個別の画像の複数について、位置を示す同期データが生成されること、
を特徴とする請求項３５乃至３８のいずれかに記載の方法。
【請求項４０】
前記入力画像シーケンスのうちの所定の画像を、前記受信機に別個に伝送される個別の画像として選択する選択ステップを更に有すること、
を特徴とする請求項３５乃至３９のいずれかに記載の方法。
【請求項４１】
前記の入力画像シーケンス符号化ステップでは、前記符号化画像データのシーケンス（１１１）のうちの選択された所定の画像が、Ｐフレーム（Ｐ）として符号化されること、
を特徴とする請求項４０に記載の方法。
【請求項４２】
前記選択ステップでは、Ｐフレームとして符号化されることになる入力画像シーケンスのＮ枚毎の画像が、前記受信機に別個に伝送される個別の画像として選択され、Ｎは自然数であること、
を特徴とする請求項４１に記載の方法。
【請求項４３】
所定のタイムアウト時間を繰り返しカウントするステップを更に有し、
前記選択ステップでは、前記所定のタイムアウト時間が経過するたびに、その時点での入力画像シーケンス（１０５）の画像が、前記受信機に別個に伝送される個別の画像として選択されること、
を特徴とする請求項４０または４１に記載の方法。
【請求項４４】
符号化画像データの前記シーケンス（１１１）と前記個別の画像（１１２）と前記同期データ（１１１，１１２）とを伝送する伝送ステップを更に有すること、
を特徴とする請求項３５乃至４３のいずれかに記載の方法。
【請求項４５】
前記伝送ステップでは、符号化画像データの前記シーケンスをバースト（１０）の形式で伝送し、前記バースト（１０）は、第１の伝送チャンネル上で、間隔（２０）をおいて伝送されること、
を特徴とする請求項４４に記載の方法。
【請求項４６】
個別の画像は、別の伝送チャンネル上で、間隔（６０）をおいてバースト（５０）の形式で伝送されること、
を特徴とする請求項４５に記載の方法。
【請求項４７】
前記個別の画像を伝送するための前記バースト（５０）は、各々が個別の画像を１つだけ含むこと、
を特徴とする請求項４６に記載の方法。
【請求項４８】
符号化画像データの前記シーケンス（１１１）を伝送するための前記バースト（１０）の間の間隔（２０）は、個別の画像（１２１）を伝送するための前記バースト（５０）の間の間隔（６０）よりも長いこと、
を特徴とする請求項４６または４７に記載の方法。
【請求項４９】
バースト（１０，５０）で伝送される全てのデータをインターネットプロトコル（ＩＰ）パケット（１４１）にカプセル化するカプセル化ステップを更に有すること、
を特徴とする請求項４５乃至４８のいずれかに記載の方法。
【請求項５０】
前記パケット（１４１）が、前記同期データ内に含まれる形でタイムスタンプを有すること、
を特徴とする請求項４９に記載の方法。
【請求項５１】
前記カプセル化ステップでは、データを、ユーザデータグラムプロトコル（ＵＤＰ）およびリアルタイムプロトコル（ＲＴＰ）と共に、インターネットプロトコル（ＩＰ）のパケットにカプセル化すること、
を特徴とする請求項４９または５０に記載の方法。
【請求項５２】
前記同期ステップでは、リアルタイムプロトコル（ＲＴＰ）パケットのヘッダに前記タイムスタンプを挿入して、入力画像シーケンス（１０５）の同じ画像から生じたデータを有するリアルタイムプロトコル（ＲＴＰ）パケットが同じタイムスタンプを有する、という形にすること、
を特徴とする請求項４９または５０に記載の方法。
【請求項５３】
符号化画像データの前記シーケンス（１１１）は、ＤＶＢ−Ｈに従って伝送されること、
を特徴とする請求項４３乃至５１のいずれかに記載の方法。
【請求項５４】
モバイル受信機（２００）において符号化画像データを復号する方法であって、前記モバイル受信機は、符号化画像データのシーケンス（２２１）および個別の画像の画像データ（２２２）を、画像シーケンスに対する前記個別の画像の位置を示す同期データと共に受信するものであり、前記方法は、
予測復号手順を用いて符号化画像データの画像シーケンス（２２１）を復号する復号ステップ（Ｓ３６０）と、
前記同期データを用いて前記個別の画像の位置に基づいた復号ステップ（Ｓ３６０）を開始させるステップ（Ｓ２２０，Ｓ２３０，Ｓ２４０）であって、示された位置の後に続く符号化画像データの予測復号において個別の画像が参照画像として参照される、という形で開始させるステップと、を有すること、
を特徴とする方法。
【請求項５５】
個別の画像の前記受信された画像データは符号化画像データであり、そして、
前記個別の画像の前記符号化画像データ（２２２）を復号する復号ステップ（Ｓ１７０）を更に有すること、
を特徴とする請求項５４に記載の方法。
【請求項５６】
前記個別の画像は、フレーム内符号化フレーム（Ｉ）として符号化されること、
を特徴とする請求項５５に記載の方法。
【請求項５７】
前記個別の画像は、ＩＤＲ（Instantaneous Decoding Refresh）アクセスユニットとして符号化され、前記シーケンスの符号化画像データを復号する復号ステップ（Ｓ３６０）では、前記ＩＤＲアクセスユニットが、前記シーケンスの前記符号化画像データの復号のためのランダムアクセスポイントとして用いられること、
を特徴とする請求項５６に記載の方法。
【請求項５８】
個別の画像の位置は、符号化画像データの前記シーケンスの内部でのＰフレーム（Ｐ）の位置と同じ、または近くにあること、
を特徴とする請求項５４乃至５７のいずれかに記載の方法。
【請求項５９】
符号化画像データの前記シーケンスは、間隔（２０）をおいて伝送されるバースト（１０）の形式で受信されること、
を特徴とする請求項５４乃至５８のいずれかに記載の方法。
【請求項６０】
前記個別の画像は、シーケンス（２２１）のうち前記同期データが示す画像位置を含む符号化画像データを含んだバースト（１０）に先立って受信されること、
を特徴とする請求項５９に記載の方法。
【請求項６１】
データは、インターネットプロトコル（ＩＰ）パケットの形式にカプセル化された形で受信されること、
を特徴とする請求項５４乃至６０のいずれかに記載の方法。
【請求項６２】
前記同期データは、前記インターネットプロトコル（ＩＰ）パケットに含まれた形で、タイムスタンプを有していること、
を特徴とする請求項６１に記載の方法。
【請求項６３】
データは、ユーザデータグラムプロトコル（ＵＤＰ）およびリアルタイムプロトコル（ＲＴＰ）と共にインターネットプロトコル（ＩＰ）のパケットにカプセル化されること、
を特徴とする請求項６１または６２に記載の方法。
【請求項６４】
前記タイムスタンプは、リアルタイムプロトコル（ＲＴＰ）パケットのヘッダに含まれていること、
を特徴とする請求項６２または６３に記載の方法。
【請求項６５】
リアルタイムプロトコル（ＲＴＰ）パケットは、シーケンスのうち前記同期データが示す画像位置を含む符号化画像データを含み、そして、リアルタイムプロトコル（ＲＴＰ）パケットは、同じタイムスタンプを有する前記個別の画像のデータを含むこと、
を特徴とする請求項６４に記載の方法。
【請求項６６】
リアルタイムプロトコル（ＲＴＰ）パケットは、シーケンスのうち前記同期データが示す画像位置を含む符号化画像データを含み、そして、リアルタイムプロトコル（ＲＴＰ）パケットは、お互いに近いタイムスタンプを有する前記個別の画像のデータを含むこと、
を特徴とする請求項６４に記載の方法。
【請求項６７】
符号化画像データの前記シーケンス（２２１）は、ＤＶＢ−Ｈに従って受信されること、
を特徴とする請求項５４乃至６６のいずれかに記載の方法。
【請求項６８】
符号化画像データのシーケンス（２２１）を受信して表示するモバイル受信機であって、
符号化画像データの前記シーケンス（２２１）および個別の画像の画像データ（２２２）を、前記画像シーケンスに対する前記個別の画像の位置を示す同期データと共に受信する受信セクション（２１０）と、
請求項２１乃至３４のいずれかに記載の動画デコーダ（２２０）と、
前記受信セクション（２１０）によって受信されて、前記動画デコーダ（２２０）によって復号された画像データを表示するディスプレイ（２５０）と、を有すること
を特徴とするモバイル受信機。
【請求項６９】
前記受信セクション（２１０）は、符号化画像データの前記シーケンスをバースト（１０）の形で受信し、前記バースト（１０）は、所定の時間間隔（２０）で隔てられて、モバイル受信機は更に、前記シーケンスのうち前記同期データが示す符号化画像データの位置を含んだバースト（１０）が受信されるまでの間、個別の画像の画像データを格納する静止画像バッファ（２３０ａ）を有すること、
を特徴とする請求項６８に記載のモバイル受信機。
【請求項７０】
前記受信セクション（２１０）は更に、複数の伝送チャンネルから符号化画像データのシーケンスを受信するように作られており、
モバイル受信機は更に、受信のために特定の伝送ルートを選択する選択手段を有し、そして、
前記受信セクション（２１０）は特定の個別の画像を受信し、同期データは、前記選択された伝送チャンネルで受信される符号化画像データのシーケンスに対する特定の個別の画像の受信画像データの位置を示すこと、
を特徴とする請求項６９に記載のモバイル受信機。
【請求項７１】
前記ディスプレイ（２５０）は、受信のための前記特定の伝送ルートが選択された後、前記特定の個別の画像を静止画像として表示するように作られており、その表示は、選択された伝送チャンネルで受信された符号化画像データのシーケンス（２２１）の前記データが、表示のために復号されるまでの間であること、
を特徴とする請求項７０に記載のモバイル受信機。
【請求項７２】
符号化画像データの表示を開始するにあたって、初期のフレームレートを下げるように作られていること、
を特徴とする請求項６８乃至７１のいずれかに記載のモバイル受信機。
【請求項７３】
前記の下げられた初期フレームレートの結果として生じる追加の表示時間に応じて、表示の開始は、遅らせる形にシフトされること、
を特徴とする請求項７２に記載のモバイル受信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、表示のためにモバイル端末に伝送される動画の符号化および復号に関する。具体的には、本発明は、別個に伝送される静止画像を符号化された画像シーケンスと同期させるエンコーダに関し、そして、受信した符号化画像データのシーケンスと同期した静止画像を用いて復号を行うデコーダに関する。
【背景技術】
【０００２】
デジタル動画データ放送のための伝送システムは、いくつかの異なる伝送パスに関して標準化されてきた。ＤＶＢ−Ｓは衛星利用放送を対象としており、ＤＶＢ−Ｃはケーブル伝送を、ＤＶＢ−Ｔは地上放送を対象としている。地上放送伝送システムＤＶＢ−Ｔは、家庭、オフィス、車などにある受信機を目標とした放送システムを意図したものである。そしてまた、ＤＶＢ−Ｔシステムは、運転速度が高速の場合でも、モバイル受信機による受信に適している。しかし、モバイル携帯デバイスについては、限られたバッテリ能力のために、そして、小型化環境での極端にレベルの高い放熱のために、更なる制限を強いられる。そこで、更なるＤＶＢ標準規格であるＤＶＢ−Ｈが開発された。これは、主に携帯端末（すなわち、バッテリで動作しポケットにも入る小型端末）を対象にしたものである。これらの端末は、携帯電話のような小型装置とすることができ、建物や車両の内部での受信を実現できる。
【０００３】
ＤＶＢ−Ｈは、地上放送伝送システムＤＶＢ−Ｔを基礎としている。ＤＶＢ−Ｔ伝送システムが通常１０Ｍｂｐｓ以上の帯域幅を提供するのに対し、モバイル携帯端末で利用されるサービスは、比較的低い帯域幅しか必要としない。ＭＰＥＧ-４のような高度動画圧縮を使用したストリーミング動画の場合の推定最大ビットレートは、２、３００Ｋｂｐｓの周辺である。伝送データの平均量を下げるという観点から、ＤＶＢ−Ｈは、時分割多重（ＴＤＭ：Time Division Multiplexing）の伝送スキームを採用している。ＤＶＢ−Ｈデータは、タイムスライスまたはバーストで伝送される。各々のバーストが用いるビットレートは、固定帯域幅によるデータ伝送の際に必要とされるビットレートよりも高い。
【０００４】
特定のサービスのバーストデータの間、同じサービスのデータは伝送されない。その間隔は、バーストとバーストとの間のオフタイムなので、他のサービスが残りの帯域幅を使用することができる。従って、受信機は、時間のごく一部にわたってのみ（すなわちバースト受信中のみ）活動していればよい、ということにできる。オフタイムの間、受信機は、隣接する他のサービス用の伝送チャンネルをモニタすることもできるだろう。
【０００５】
こうしたバーストベースの伝送のコンセプトが有する、受信側での電力消費の削減を可能にする能力は、オフ期間が長いほど向上する。オフタイムの幅は、通常１秒から１５秒である。例えば、オフタイムが約５秒で、オンタイムが０.５秒未満であれば、約９０%の省電力を達成できる。
また、モバイル受信端末は、他の情報（電子サービスガイド（ＥＳＧ）用データなど）を受信することができる。ＤＶＢ−Ｈサービスにおいて２つの隣接したバーストの間に他のデータの受信がない場合は、端末の受信部のスイッチを切り、それによってバッテリ電力を節約することができる。そうして、次のバーストが伝送される際には、受信のために受信部を再起動する。再起動時間は、予め決められており、先のデータバーストと共に受信されたデータによって既に知らされている。
【０００６】
モバイル受信機への動画放送の伝送スキームの一般的な例が図１に示してある。以下、これについて説明する。以下の説明は、一例としてＤＶＢ−Ｈに基づいているが、当業者であれば分かるように、同じ目的のために他の伝送スキームを用いることもできる。例えば、別の例として、ＤＭＢ（Digital Multimedia Broadcasting）がある。
ＤＶＢ−Ｈデータは、時分割多重（ＴＤＭ）スキームでのタイムスライスまたはバーストで伝送される。各バーストは一般的に、およそ２Ｍｂｉｔ（２５６キロバイト）のデータを含む。バーストデータの伝送に必要なバースト時間は、通常、約１４０ミリ秒である。各バーストには、サービスのバーストデータが伝送されないオフタイムを埋めるための、動画、音声、その他のデータが含まれている。内部帯域幅と１バースト内で伝送されるデータの量とに従って、バースト時間（すなわち、バーストの開始から終わりまでの時間）は大幅に変化する。バースト時間は、バーストサイズ（単位：ビット）をバースト帯域幅（単位：ビット／秒）で除算して算出するのが望ましい。オーバーヘッドコストを補償するために、ＤＶＢ伝送スキームのトランスポートパッケージヘッダで補正要因を考慮することもある。
【０００７】
図１の例では、参照番号１０は、特定のサービス（図では「メインサービス１」という名称）のデータを伝送するためのバーストを指している。後続のバーストでは、他のサービスのデータが伝送される。ここに示す例では、メインサービス１の第１バースト１０と同じサービスの後続の第２バースト１０´との間のオフタイム２０は８秒に等しい。このオフタイム間隔の間、メインサービス１のデータは利用できない。
【０００８】
１つの伝送チャンネルで伝送される異なる複数のストリームの間では、バーストパラメータ（バーストサイズ、バースト飽和（saturation）、バースト帯域幅、オフタイムなど）がしばしば変化する。
５秒程度のオフタイムの時間の結果として、対応する形で、伝送チャンネル間の切換時間が長くなる。ユーザが、あるメインサービス（通常１つのメイン動画サービスと、いくつかのメイン音声サービスとを含み、オプションで字幕サービスを１つ含む場合もあるもの）から新しいメインサービスへ、図１に矢印で示すように切替えると、当該新しいメインサービスの２つのバーストの間、データは利用できない。また、別の伝送チャンネルへの切替えを行うと、新しいサービスの最初のバーストを受信した後でしか、画像は再生されないであろう。別のテレビチャンネルへの切替えを行うユーザは、新しいチャンネル上で最初のバーストが伝送されるのを待たねばならず、それは約５秒間も続く場合がある。よって、異なるテレビチャンネルのプログラム放送の間での速やかなスキャンは不可能である。
【０００９】
例えば、図１に示す状況では、ユーザは１.５秒の時点でメインサービス１の受信を開始する。こうした状況が起こるのは、例えば、モバイル受信端末の電源をオンにした後、または、別のメインサービスからの切替えの場合である。受信開始後、所望のメインサービス１の次のバーストが８秒の時点で受信されるまで、ユーザは６.５秒待たなければならない。
【００１０】
長い待ち時間の問題を解消できるのが、ザッピングサービスの特徴である。ザッピングサービスが運ぶのは、種類の異なるデータ（例：静止画、テキスト、音声、または低解像度動画まで）である。あらゆるメインサービスは、固有のザッピングサービスを持つことができ、それもやはりバーストで伝送されるのだが、オフタイムは相当に短くなる。従って、チャンネル切替え後、端末がザッピングデータを受信し、処理し、提示するタイミングは、相当に早くすることができ、ユーザは、対応するメインサービスを待つかどうかの判断を直ちに下すことができる。
【００１１】
ザッピングサービスが消費する帯域幅はメインサービスより小さく、その内容と伝送レートとに左右される。例えば、１ピクチャ／秒または低データ転送速度の音声の場合、通常、関連するメインサービスの帯域幅の最大１０％が必要となる。従って、複数のメインサービスに属する複数のザッピングサービスが、共通の１つのザッピングサービスバーストで伝送される、とするのが好ましい。ただし、別の形として、異なる複数のザッピングサービスを、いくつかのバーストで伝送することも可能である。
【００１２】
図２が示す例では、図１のメインサービス伝送状況に加えて、端末が追加で送受信するザッピングサービスデータを示してある。ここに挙げる例では、ザッピングデータバースト５０の伝送間隔６０は１秒の長さである。受信端末のユーザが、ザッピングサービスを利用可能な別のメインサービスへの切替えを行うと、受信端末はザッピングサービス受信のために自動的に調整される。ザッピングサービスは、そのオフタイムが短いので、先に受信される可能性がかなり高い。メインサービスデータバーストを待つ間に、ザッピングサービスは受信され、処理される。ザッピングサービス内で伝送されるデータが静止画であれば、ユーザがメインサービスを別のメインサービスに切替えた後、メインサービスの内容についての視覚的な印象を得るタイミングは相当に早まる。メインサービスに関するデータが受信されると、それを処理してユーザに表示することができるので、ザッピングサービスの受信は終了する。例えば、図２に示すように、ユーザが、１．５秒の時点でメインサービス１への切替えを行えば、次のザッピングデータバーストは２秒の時点（すなわち、切替え後わずか０．５秒）で受信される。一方、次のメインサービスバーストは切替え後６．５秒で受信される。
【００１３】
しかし、モバイル受信端末では、切替え後に新しいメインサービスの動画画像を表示できるようになるまでに、更なる遅延が生じ、それは、受信される符号化画像データの特有の構造に起因する。すなわち、限られたチャンネル帯域幅で伝送するためには動画データの圧縮が不可避であるため、メインサービスの動画データは、Ｈ．２６４／ＡＶＣまたはＭＰＥＧ．４などの動画符号化標準に従って符号化されている。伝送用の帯域幅を最小にするために、標準動画符号化スキームは予測符号化を採用している。従って、伝送された動画データは、受信端末で復号する必要があり、少なくともＰフレームとＩフレームとを含む。Ｐフレームは予測フレームである。これらフレームは先行のＩフレームまたはＰフレームから予測される。Ｐフレームは、データサイズの点では、Ｉフレームと比較して非常に小さい。従って、効率の良い動画伝送を実現するためには、ストリーム中のＩフレームの数は可能な限り少なくするのが望ましい。
【００１４】
Ｉフレームはフレーム内符号化されたフレームであって、他のフレームを参照せず、動画デコーダの初期化後直ちに動画内容を復号、表示するのに必要なデータが含まれている。動画デコーダの初期化には、シーケンスパラメータセットとピクチャパラメータセットとが必要である。シーケンスパラメータセットは、受信されたフレームを復号する順番を定義している。予測符号化スキームでは、復号する順番が表示する順番と異なる場合がある。ピクチャパラメータセットには、ピクチャの特徴（例：水平解像度および垂直解像度、ピクセルビット幅）を定義するパラメータが含まれる。これらパラメータセットは、動画データと同じ形で送られる。
【００１５】
動画符号化標準Ｈ．２６４／ＡＶＣによると、ＩフレームはＩＤＲ（Instantaneous Decoder Refresh）ピクチャとして符号化することができ、当該ピクチャは必要なパラメータセットを含んでいる。従って、切替え後の新しいメインサービスのＩＤＲを受信して初めて、デコーダの初期化に必要なパラメータセットが利用可能となる。従って、デコーダが新しいメインサービスの動画シーケンスの復号を開始できるのは、符号化動画データシーケンス内のＩフレームの位置しかない。
【００１６】
一方、ＤＶＢ−Ｈ放送環境では、動画エンコーダからの送られる動画データは、ネットワークプロトコルであるリアルタイムプロトコル（ＲＴＰ：Real Time Protocol）、ユーザデータグラムプロトコル（ＵＤＰ：User Datagram Protocol）とインターネットプロトコル（ＩＰ：Internet Protocol）にカプセル化される。しかし、伝送のために動画データをパケタイズするＩＰエンカプスレータと動画エンコーダとの間には関連付けがない。従って、Ｉフレーム（ＩＤＲ）は、メインサービスの受信データバーストのどんな位置にでも現れうる。具体的に言うと、ＤＶＢ−Ｈ放送環境で、受信されたデータバーストにおいて最初の動画フレームがＩＤＲである可能性は極めて低い。サービス切替え手順に関する最悪のケースは、受信されたデータバーストの末尾に最初のＩＤＲがある、という場合である。これは、内容がＰフレームの形で伝送されているため、受信されたデータのほぼ全てが表示できない、ということを意味する。データバーストの最初のＩＤＲピクチャまで、Ｐフレームを動画の復号に使用することはできないため、これらのＰフレームは廃棄せざるを得ない。データバーストの先頭にあるＰフレームは、確実に動画内容を含んでいるので、これらを廃棄することで、新しいサービスへの切替え後にモバイル受信機の画面で実際の動画の提示が始まるまでの遅延は、更に大きくなる。図８（ａ）（一番上と３番目の図）に示す例では、バーストの最初のＩフレームが受信バーストの終わり近くに位置している。この例については、後で、更に詳細に説明する。
【００１７】
図３は、静止画像を含むザッピングサービスの生成スキームの先行技術を示す。図３のザッピングサービス生成スキームは、対応するメイン動画サービスから、静止画タイプのザッピングサービスを生成する。メイン動画サービスが動画エンコーダによってすでに符号化され、ネットワークパケタイザでＩＰデータグラムに埋め込まれた後で、ザッピングサービスデータは生成される。それに続いて、図３によるザッピングサービス生成器は、全てのＩＰデータグラムから、関連するメインサービスのものを抽出し、それらを処理してザッピングサービスのＩＰデータグラムを出力する。それは、メイン動画サービスに関係しており、そこに由来するものである。しかし、従来のやり方では、ザッピングサービスの生成は、メイン動画サービスデータがすでに符号化され伝送のためにカプセル化された後に、別個のステップにおいて実行されるため、ザッピングサービスとメイン動画サービスとの間で正確な時間的相関を持たせることは不可能である。
【００１８】
つまり、従来技術のモバイル動画受信端末用の動画のエンコーダおよびデコーダに関する問題は、ザッピングサービスバーストの送受信の間隔が、メインサービスのバーストとバーストとの間の間隔よりもはるかに短いにも関わらず、ザッピングサービスのデータと共に提供される静止画を、切替え後に新しいメインサービスの提示を開始するまでの待ち時間を最小限に抑える目的に使用できない、という点である。従来のザッピングサービス生成器は、動画エンコーダとの共同で作業を行わず、それどころか、動画エンコーダとは無関係にザッピングストリームの符号化を行う。
【００１９】
その一方で、伝送される動画ストリームは、ばらばらの動画シーケンスのセットから成る。最も単純な場合、全ての動画シーケンスは、ＩＤＲピクチャで始まり、多数のＰフレームがその後に続く。しかし、より高度な予測符号化スキーム（例：双方向符号化）も同様に可能である。動画ストリームは、ＩＰエンカスプレータにより、バースト内で分割される。ＩＰエンカプスレータは、動画シーケンスの境界に関わりのない形で、しかし一定のバーストサイズに、バーストを編集する。ＩＰカプスレータは、バースト内部でのＩＤＲピクチャの存在や位置について考慮しない。受信端末の動画デコーダは、受信した動画ストリームの復号を、動画シーケンス（先頭がＩＤＲピクチャのもの）の先頭でのみ開始することができる。従って、サービス切替え後、バーストがたまたまＩＤＲで始まらなかった場合、動画デコーダは、切替え後に最初に受信したバーストのうち、次のＩＤＲピクチャを受信するまでのＰフレームをドロップする必要がある。そのため、数秒分の動画データは、端末で利用可能であるにも関わらず、ユーザに表示できない。
【００２０】
従来技術のザッピングサービス生成器に関する更なる問題は、ザッピング生成器における動画ストリーム復号と繰返しの符号化とにより、ザッピングストリームにピクセルエラーが加わることである。
【発明の開示】
【発明が解決しようとする課題】
【００２１】
本発明が提供しようとするのは、新たな動画サービスの受信への切り替えの後、新たな動画サービスの動画データをモバイル端末に表示できるまでの待ち時間を短縮することができる、という符号化方法、エンコーダ、復号方法、そしてデコーダである。
【課題を解決するための手段】
【００２２】
これは、独立請求項の特徴によって達成される。本発明の第１の様態は、モバイル受信機への伝送のために入力動画画像のシーケンスを符号化する動画エンコーダを提供する。本動画エンコーダは、予測符号化手順を用いて入力画像シーケンスを符号化して、符号化画像データのシーケンスに変える符号化手段を有する。更に、本動画エンコーダは、モバイル受信機に別個に伝送される個別の画像の入力画像シーケンスに対する位置関係を示す同期データを生成する同期手段を有する。
【００２３】
第２の様態では、モバイル受信機において符号化画像データを復号する動画デコーダであって、前記モバイル受信機は、符号化画像データのシーケンスおよび個別の画像の画像データを、画像シーケンスに対する個別の画像の位置を示す同期データと共に受信する、というものを提供する。本動画デコーダは、予測復号手順を用いて符号化画像データの画像シーケンスを復号する復号手段を有する。また、本動画デコーダは、前記個別の画像の位置に基づいて前記復号手段の復号処理を開始させる同期手段であって、示された位置の後に続く符号化画像データの予測復号において個別の画像が参照画像として参照される、という形で開始させる同期手段を有する。
【００２４】
また、本発明の第３の様態では、モバイル受信機への伝送のために入力動画画像のシーケンスを符号化する符号化方法を提供する。本方法は、予測符号化手順を用いて入力画像シーケンスを符号化して符号化画像データのシーケンスに変える、入力画像シーケンス符号化ステップを有する。更に、本方法は、モバイル受信機に別個に伝送される個別の画像の前記入力画像シーケンスにおける位置を示す同期データを生成する同期データ生成ステップを有する。
【００２５】
また、本発明の第４の様態では、モバイル受信機において符号化画像データを復号する方法であって、前記モバイル受信機は、符号化画像データのシーケンスおよび個別の画像の画像データを、画像シーケンスに対する前記個別の画像の位置を示す同期データと共に受信するものである、という方法を提供する。本方法は、予測復号手順を用いて画像シーケンスの符号化画像を復号する復号ステップを有する。更に本方法は、同期データを用いて前記個別の画像の位置に基づいた復号ステップを開始させるステップであって、示された位置の後に続く符号化画像データの予測復号において個別の画像が参照画像として参照される、という形で開始させるステップ、を有する。
【発明の効果】
【００２６】
本発明の特別なアプローチは、メインサービスからの個別の画像を、そこから分離した形で、同期情報と組み合わせて伝送することである。同期情報と共に分けて伝送される画像は、モバイル受信機において、メインサービスの予測符号化画像データの復号処理の開始に使われる。同期情報によって提供される位置情報に基づいて、メインサービス画像シーケンスの予測符号化画像は、上記個別の画像と置き換えられ、参照画像として以降の画像の復号を可能にする。
【００２７】
好ましい形として、分けてモバイル受信機に伝送される個別の画像もまた、エンコーダ側で符号化される。そして更に、フレーム内符号化フレームとして符号化されるのが好ましい。また、個別の画像データに対して動画符号化を用いることで、ザッピングサービスの帯域幅要求を小さくすることができる。フレーム内符号化されたフレームは他のフレームを参照していない。そのため、フレーム内符号化フレームで復号処理を開始すれば、以降の全ての符号化ピクチャの復号にあたって、シーケンス中の当該フレーム内符号化フレーム以前のピクチャを参照しなくてよい。
【００２８】
また、更に好ましい点として、個別の画像は、ＩＤＲ（Instantaneous Decoding Refresh）アクセスユニットとして符号化される。Ｉフレームの他に追加パラメータ（シーケンスパラメータセットやピクチャパラメータセットなど）を含んだＩＤＲデータを用いることで、本発明は、より洗練された予測符号化スキーム（双方向符号化など）にも適用することができる。
【００２９】
好ましい形としては、個別の画像を数多く、分けて（すなわち、ザッピングサービスに含めて）モバイル受信機に伝送する。そして、エンコーダ側では、これらの個別の画像全てについて、入力画像シーケンス内での位置を示すための同期データを生成する。これにより、デコーダ側では、メインサービスの符号化動画シーケンスの復号を開始するにあたって、多数の参照画像が利用可能となる。
【００３０】
好適な実施の形態によれば、本発明による動画エンコーダは、個別の画像としてザッピングサービスに含めて伝送するべき画像を入力画像シーケンスの中から選択する、という選択手段を更に有する。また、より好ましい構成として、符号化画像データのシーケンスのうちの選択された所定の画像が、Ｐフレームとして符号化される（一方、個別の画像はＩフレームとして分けて伝送される）。そのため、受信機側での動画シーケンスの復号は、所定の画像の位置から開始することができ、これは、ザッピングサービスの中の個別の画像が参照画像として利用できるからである。その一方で、メインサービスでは所定の画像をＩフレームとして伝送する必要はなく、従って、メインサービスの帯域幅を節約できる。
【００３１】
また、より好ましい構成として、Ｐフレームとして符号化されることになる入力画像シーケンスのＮ枚毎の画像が、個別の画像として選択される（Ｎは自然数である）。また、別の形として、一定の時間間隔で、入力画像シーケンス中のその時点での画像を選択し、その画像を、ザッピングストリームに入れて伝送すべき個別の画像とする、ということもできる。その一定の時間間隔については、動画エンコーダ内のタイマで計測するのが好ましい。
【００３２】
また、本発明による動画エンコーダが、符号化されていない状態の入力画像シーケンスの画像を格納する静止画像バッファを有し、ザッピングサービスの個別の画像は、静止画像バッファに格納された画像から選択する、という構成が好ましい。この構成では、メイン動画サービスの符号化動画データのフレームの符号化ベースである処理前の動画データが、ザッピングサービスＩフレームとしてもう一度使用される。
【００３３】
好ましい構成として、モバイル受信機に伝送されるデータは、ＩＰパケットの形にカプセル化される。ＩＰパケットは、好ましい構成として、同期のためのタイムスタンプを、同期データに含まれた形で有する。更に好ましい構成として、データは、ＵＤＰおよびＲＴＰと共にＩＰパケットにカプセル化される。更にまた好ましい構成として、タイムスタンプはＲＴＰパケットヘッダに挿入されるが、その際、入力画像シーケンスの同じ画像が元になったデータを含む複数のＲＴＰパケットには、同じタイムスタンプを持たせることとする。それにより、ザッピングサービスに収容された特定の個別の画像の、メインサービスデータシーケンスに対する位置は、特に単純な方法で、すなわち、各々のＲＴＰパケットヘッダのタイムスタンプを比較することで知ることができる。
【００３４】
本発明の更なる好適な様態では、符号化画像データのシーケンスを伝送するための送信機が設けられている。送信機は、本発明の第１の様態による動画エンコーダを有している。送信機は更に、符号化画像データのシーケンス、個別の画像、そして同期データを伝送するための伝送手段を有する。
好ましい構成として、伝送手段は、第１の伝送チャンネル上で符号化画像データのシーケンスを、間隔をおいたバーストの形式で伝送する。上で概説したように、動画データをバーストで伝送すると、低電力受信装置でのバッテリ消費電力を相当に下げることができる。より好ましい構成として、ザッピングサービスの個別の画像は、別の伝送チャンネル上で、間隔をおいたバーストの形式で伝送される。また、より好ましい構成として、ザッピングサービスの各バーストでは、ザッピングサービスの個別の画像が１つだけ伝送される。従って、チャンネル切替え後に受信されるザッピングサービスのバーストは全て、対応するメインサービス動画シーケンスの復号の開始に必要なデータを含んでいる。
【００３５】
好ましい構成として、メインサービスの伝送の場合のバーストの間隔は、ザッピングサービスの伝送の場合のバーストの間隔よりも長い。従って、バッテリ電力消費は改善される。メインサービスの受信中、新たなチャンネル（ザッピング）への切替えの比較的短い間隔の間、データは短い間隔の中で受信され、各メインサービスの復号を開始するために、ならびに、待ち時間を埋めるために、参照として使用される。
【００３６】
さらに、より好ましい構成として、符号化されたデータのシーケンスは、ＤＶＢ−ＨまたはＤＭＢ標準に従って伝送される。
また、好ましい構成として、２つのメインサービスバーストの間の時間間隔において送受信されるザッピングサービスバーストは、後続のバーストと共に伝送されるメインサービスの画像データに対応する静止画像データを含む。エンコーダ側では、伝送のためにバーストが完成するまでに、所定量の符号化圧縮データが蓄積されることになるので、個々の画像のデータは前もって利用可能となる。一方のデコーダ側では、参照画像として使用されることになる個別の画像を、メインサービスの符号化シーケンスのうちの対応部分に先立って受信することができる。従って、切替え後に最初に受信されるザッピングバーストの静止画像は、対応するメインサービスデータが受信された時点で、参照画像として利用できる。
【００３７】
本発明の更に好ましい様態として、符号化画像データのシーケンスを受信して表示するモバイル受信機を提供する。このモバイル受信機は受信セクションを有し、当該セクションは、符号化画像データのシーケンスおよび個別の画像の画像データと共に、画像シーケンスに対する個別の画像の位置を示す同期データを受信する。さらに、本モバイル受信機は、本発明の第２の様態による動画デコーダを有する。加えて、本モバイル受信機は、受信セクションによって受信され、動画デコーダで復号された画像データを表示するディスプレイを有する。
【００３８】
好ましい構成として、モバイル受信機は、符号化画像データのシーケンスをバーストで受信し、受信にあたって、バーストは所定の時間間隔で隔てられている。モバイル受信機は静止画像バッファを更に有し、当該バッファは、符号化画像データのシーケンスにおいて同期データが示す位置を有するバーストが受信されるまで、個別の画像（ザッピングサービスデータ）の画像データを格納しておく。すなわち、符号化画像シーケンスにおける対応データを含んだメインサービスバーストよりも先に送受信されたザッピングサービス画像を、メイン動画画像シーケンスを復号するための参照画像として必要になるまで、保存しておくことができる。
【００３９】
更に好ましい構成として、モバイル受信機は、異なる伝送チャンネル上で送られる複数のメイン動画サービスを受信するように作られており、これらチャンネルは選択して受信できる。異なる複数のメインサービスは、好ましい構成として、それぞれが、受信セクションで受信可能なザッピングサービスと関連付けられており、そのため、同期データは、選択されたメイン動画サービスに対するザッピング画像の位置を示すものとして利用可能である。
【００４０】
更にまた好ましい構成として、モバイル受信機は、特定のメインサービスに対応する静止画像をザッピングデータに入った形で受信し、対応するメイン動画サービスの、そして新しく選択された伝送チャンネルのデータが表示のために復号されるまでの間、この静止画像を表示することができる。従って、新たなメイン動画サービスの選択後の待ち時間は、ザッピングデータの静止画像で埋めることができる。ユーザは、表示されたデータに基づいて、選択したチャンネルのメイン動画サービスを待つか、次の切替えを実行するか、決定することができる。
【００４１】
また、好ましい構成として、本モバイル受信機は、符号化画像データの表示を、初期フレームレートを下げた形で開始することができる。また、更に好ましい構成として、表示の開始は、前記の下げた初期フレームレートの結果として生じる追加の表示時間に対応して、遅らせる形にシフトされる。それにより、メインサービスとしても、ザッピング用参照フレームとしてもデコード（復号）することはできないが、新しく受信されるメインチャンネルの、最初に受信されるバーストの先頭の、表示されるべき数フレームの時間を埋めることができる。さらに、それによって、メインサービス画像データ受信における短い中断は、歪みを最小限に抑えた形で埋めることができる。
【００４２】
本発明の更なる好適な実施の形態は従属する請求項の主題となる。
【発明を実施するための最良の形態】
【００４３】
本発明に関わる他の実施の形態および効果については、添付図面と共に示す好適な実施の形態に関する以下の説明を読むことで、より明らかになるであろう。
以下、本発明の例示的な実施の形態について、図面を参照しながら説明する。
本発明は、静止画タイプのザッピングサービス（第２サービス）の生成に関するものであり、当該ザッピングサービスには、対応するメイン動画サービス（第１サービス）との間の、内容の正確なマッチング処理が含まれる。本発明による動画エンコーダにおいて、マッチングは、所定の動画フレームを２回符号化する、というやり方で実現される。すなわち、１回目はメイン動画ストリームの一部としてＰフレームに、２回目はザッピングストリームの一部としてＩフレームに符号化する。
【００４４】
本発明は更に、モバイル受信端末による静止画タイプのザッピングサービス（第２サービス）の使用に関する。それは、関連するメイン動画サービス（第１サービス）の復号を開始するタイミングを、従来技術の場合に比べて大幅に早めることを可能にする。それにより、動画復号能力は向上する。
静止画タイプのザッピングサービスはスライドショーから成り、それはメイン動画サービスデータから分離されて送られてくる。同期データは、時間および内容に関して、ザッピングデータとメイン動画サービスとの間を直接的に関連付けるものである。また、メイン動画シーケンスの復号の迅速な開始が実現されるが、それは、ザッピングサービスの静止画が、メイン動画データシーケンス内のＰフレームの位置に対応するＩＤＲ（Instantaneous Decoder Refresh）ピクチャとして符号化され、メイン動画画像シーケンスのうち当該Ｐフレームの後に続く画像を復号する際の参照画像として採用されるからである。言い換えると、ザッピングサービスのＩＤＲ画像は、メイン動画ストリームにおけるランダムアクセスポイント（ＲＡＰ：Random Access Point）として機能するのであり、従って、初期状態では不完全なメイン動画シーケンスを完全な形にすることができる。ザッピングサービスを補助として用いれば、メイン動画ストリームの中で伝送されるＲＡＰ（Ｉフレーム）（データ転送速度の点で「高くつく」もの）の量を相当に小さくすることができる。よって、その分のデータ転送速度をメイン動画サービスにまわすことができる。
【００４５】
動画サービスに付随する関連音声トラックの処理は影響を受けないので、それに関する説明は省略する。
以下、本発明によるザッピングサービスを生成するように作られた動画エンコーダの例示的な実施の形態について、図４を参照しながら説明する。ここでの本発明の説明は、ＤＶＢ−Ｈに関連付けてあるが、それは一例であり、本発明は当該標準の範囲内の実施には限定されない。例えば、本発明は、標準デジタルマルチメディア放送（ＤＭＢ：Digital Multimedia Broadcasting）に基づいた形でも、同様に実施することができる。
【００４６】
ここで説明する実施の形態による動画エンコーダは、ＤＶＢ−Ｈ放送環境において用いられるものであり、この環境において伝送される動画データは、動画符号化標準（例えば、Ｈ２６４／ＡＶＣ、ＭＰＥＧ４、または、現在使用されているか、将来使用されることになる別の符号化スキーム）に従って符号化されたフレームおよびピクチャであり、ネットワークプロトコルＲＴＰ、ＵＤＰ、ＩＰにカプセル化される。これは、エンコーダ１００のＩＰパケタイザブロック１４０において、ネットワーク抽象化レイヤ（ＮＡＬ：Network Abstraction Layer）で行われる。メインサービス用符号化手段１１０とザッピングサービス用符号化手段１２０とが、ＩＰパケタイザ１４０にメインおよびザッピングのストリームを送る。ＩＰパケタイザ１４０のＮＡＬレイヤは、動画データをバンドルしてＮＡＬユニットとする。ＮＡＬユニットは、符号化された動画データの他に、トランスポート固有の機能のための全てのデータを含む。
【００４７】
動画入力からの処理前メイン動画ストリームを、メインサービス符号化手段１１０において符号化する際、符号化は適用される標準に従って行われるので、それを復号できるのも、当該適用される標準に従ったデコーダとなる。
本発明によるメインサービス符号化手段１１０として用いることのできる動画符号化手段の一例について、以下、図５を参照しながら詳細に説明する。符号化手段は減算器５１０を有し、当該減算器は、入力画像シーケンス１０５からの現在の動画画像と以前に符号化された画像に基づく現在の画像の予測信号との差分を求める。結果として得られた予測誤差を、変換・量子化ユニット５２０は、空間領域から周波数領域に変換し、得られた変換係数を量子化する。エントロピー符号化ユニット５９０は、量子化後の変換係数をエントロピー符号化する。
【００４８】
図５の動画エンコーダの動作は以下の通りである。本エンコーダは、差分パルス符号変調（ＤＰＣＭ）アプローチを採用しており、入力動画シーケンスの後続画像の差分だけを伝送する。これらの差分は減算器５１０で求められる。減算器は、符号化対象の動画画像を受信し、そこから現在の画像の予測値を減算する。
予測値は、エンコーダ側で以前に符号化された画像の復号処理結果（「局部的復号画像」）に基づいている。これは、動画符号化手段１１０に組み込まれた復号ユニットによって達成される。復号ユニットは、符号化ステップを逆方向に実行する。逆量子化・逆変換ユニット５３０は、量子化係数を逆量子化し、逆量子化後の係数に対して逆変換を実施する。加算器５３５において、復号後の差分は予測信号に加算される。
【００４９】
図５の動画符号化手段によって実行される動き補償ＤＰＣＭでは、現在のフィールドまたはフレームを、前のフィールドまたはフレームのうち対応するもののデータから予測する。この予測は、現在のフィールドまたはフレームと前のそれとの間の動き探索に基づく。動き探索は、２次元の動きベクトルで求められ、これは、現在のフレームと前のフレームとの間でのピクセルの変位を表す。通常、動き探索はブロック単位で実行され、現在のフレームのブロックを前のフレームのブロックと比較する処理を、最も一致するブロックが求められるまで行う。そして、比較結果に基づき、現在のフレームの各ブロックに関して変位ベクトルが求められる。これは、現在の入力信号と局部的復号画像とを受信する動き探索ユニット５７０によって達成される。
【００５０】
動き探索の結果に基づいて、動き補償予測ユニット５６０が動き補償を実行することで、求められた動きベクトルを利用した予測値が提供される。そうして、現在のブロックと予測ブロックとの差分を表す予測誤差ブロックに含まれる情報が、変換ユニット５２０によって変換係数に変換される。通常は、２次元の離散コサイン変換（ＤＣＴ：Discrete Cosine Transform）が使用される。
【００５１】
Ｈ．２６４／ＡＶＣでは、入力画像はマクロブロックに分割される。マクロブロックは、「フレーム内」または「フレーム間」の符号化モードが適用されて、符号化される。フレーム間符号化モードでは、前述した動き補償を用いてマクロブロックを予測する。フレーム内符号化モードでは、予測信号は０にセットされるが、動画符号化標準Ｈ．２６４／ＡＶＣは、加えて、同じ画像のすでに符号化されたマクロブロックに基づく予測スキームを用いて、後続のマクロブロックを予測する。
【００５２】
フレーム内符号化された画像（Ｉタイプ画像）だけは、先に復号された画像を全く参照することなく、符号化することができる。Ｉタイプ画像は、符号化動画シーケンスにエラー耐性をもたらす。更に、Ｉタイプ画像は、符号化データのビットストリームへのエントリポイントを提供し、ランダムアクセス（すなわち、符号化動画画像のシーケンス内部でのＩタイプ画像へのアクセス）を可能にする。フレーム内符号化モード（フレーム内予測ユニット５５０による処理）とフレーム間符号化モード（動き補償予測ユニット５６０による処理）との間の切り替えは、フレーム内／フレーム間スイッチ５８０によって制御される。
【００５３】
さらに、局部的符号化画像におけるブロッキング現象の発生を減らすために、デブロッキングフィルタ５３７を設けることにしてもよい。
結果は、以降の予測処理のために参照メモリ５４０に格納される。
図５の変換量子化ユニット５２０とエントロピー符号化ユニット５９０とを、ザッピングサービス符号化手段１２０として用いることもでき、その場合、ザッピングサービスの静止画像は、やはり動き補償なしで符号化される。説明を簡単にするために明示はしていないが、フレーム内予測は、同様に、ザッピングサービス用の処理パスの中に含ませることもできる。あるいは、別個の符号化手段１２０を、ザッピングサービスデータの符号化用に設けることもできる。
【００５４】
内容の正確なマッチングを達成するには、入力画像シーケンスの中の所定の動画フレームを２回周波数符号化する（すなわち、１回目はメイン動画ストリーム１１１の一部としてＰフレームに、２回目はザッピングストリーム１２１の一部としてＩＤＲにする）。そこで、符号化手段の入口にセレクタ５０５を設け、当該セレクタは、受信した入力画像の特定のものを選択して、２回目に別途符号化されて伝送されるようにする。更に、セレクタ５０５の前に入力バッファ（図示せず）を設けて、入力画像を保存することにしてもよい。
【００５５】
図６に見られる通り、ザッピングストリームはＩＤＲだけから成り、これらＩＤＲは、柔軟に選択可能な一定の時間間隔（例：１秒につき１つのＩＤＲ）で、符号化手段１２０において符号化される。よって、両ストリーム（１１１，１２１）は、Ｐフレームの量（ザッピングストリームは「０」）、１秒あたりの全体フレーム量、そして、Ｉフレームの時間位置において異なったものとなる。
【００５６】
ＩＤＲアクセスユニットは、Ｉフレームに加えて、追加パラメータ（シーケンスパラメータセットなど）を含む。これら追加パラメータによって、いずれの高度予測符号化アルゴリズム（双方向符号化など）の場合でも、ＩＤＲフレームをランダムアクセスポイントとして用いることが可能となる（上記アルゴリズムでは、デコーダにおける復号のシーケンスが表示のシーケンスとは異なる）。ＩＤＲピクチャの前に復号されたあらゆるピクチャからの相互依存を断つ目的で、ＩＤＲピクチャは、デコーダのマルチフレームバッファをリセットする。
【００５７】
ザッピングＩＤＲの中に含まれるパラメータセットは、端末におけるメインサービス復号にも有効である。１秒あたりのザッピングサービスＩＤＲの量については、完全に柔軟なものである。メインサービスＰフレームとして符号化された入力動画ピクチャには全て、対応するザッピングサービスＩＤＲを持たせることができる。また、メインサービスＰフレームのうち、対応するザッピングサービスＩＤＲを有するフレームの数は、定義可能である。よって、コンテンツプロバイダが、対応するザッピングＩフレーム（ＩＤＲ）を有するＰフレームの総フレーム数を定義することができる。
【００５８】
図６に示す例では、ザッピングＩフレームは、７番目および２２番目のメインサービスＰフレームを補足する。従って、セレクタ５０５の設定は、メインサービスのうち、７番目および２２番目のＰフレームに対応する入力画像を、ザッピングサービスＩフレームとして再度符号化する、という形にしなければならない。７番目および２２番目のＰフレームの符号化ベースである入力動画データが、ザッピングＩフレーム符号化の符号化ベースとして再び用いられるのは、この目的のためである。
【００５９】
また、別の形として、７番目および２２番目のＰフレームから復号されたピクチャを、ザッピングＩフレームの符号化ベースとして用いることができる。これらの復号後のピクチャは、エンコーダ参照バッファ５４０から入手することができ、本来は、エンコーダ１１０において次の（図示した例では、８番目と２３番目）Ｐフレームの予測ベースとして使用されるものである。
【００６０】
また、別の形として、Ｐフレームのシーケンス番号を予め決めておくのではなく、タイムアウトタイマを用いることもできる。タイムアウトタイマは、Ｐフレーム番号に関わりなく、予め選択されたタイムアウト期間が終わる度に、１つのザッピングＩフレームを生成させる。このやり方では、メインサービス符号化のフレームシーケンスに関わりのない一定のレートで、ザッピングサービスＩＤＲを生成することができる。
【００６１】
本発明において、ザッピングサービス生成のための追加の作業は、ユーザが選択したＰフレームの内容をＩフレームとして再度符号化すること、そして、これらＩフレーム（ＩＤＲ）を、より低いフレームレートの付加的動画ストリーム１２１として出力すること、それだけである。
メインサービスデータ１１１およびザッピングサービスデータ１２１の符号化が終わると、全てのデータはネットワークパケタイザ１４０に送られる。ネットワークパケタイザは、符号化後の動画データ１１１、１２１を、図７に示すように、ユーザデータグラムプロトコル（ＵＤＰ）およびリアルタイムプロトコル（ＲＴＰ）と共に、インターネットプロトコル（ＩＰ）のパケットにもカプセル化する。
【００６２】
ＩＰ／ＵＤＰ／ＲＴＰカプセル化は、ＩＰネットワーク上にデータを提供するのに用いられる。しかしながら、本発明は、ここに述べた特定のカプセル化に限定はされない。当業者であれば、他のカプセル化プロトコルも同様に、本発明と共に用いてよいことが分かるはずである。上で概説したように、受信端末において、ザッピングを用いてメインサービス復号プロセスを開始するためには、ザッピングサービスデータとメインサービスデータとの間の正確なタイミング情報が必要とされる。そこで、本発明による動画エンコーダ１００は、同期データ発生器１３０を有する。同期データ発生器１３０が生成する同期データは、メインサービス符号化手段１１０で符号化された画像シーケンスに対する、符号化手段１２０で符号化されたザッピングサービス用特定画像の位置を示すものである。同期データは、同期データ発生器１３０からネットワークパケタイザ１４０へと送られると、さらに、カプセル化されたＩＰ／ＵＤＰ／ＲＴＰ出力データ１４１の内に入れられて、符号化後の動画データと共に伝送される。
【００６３】
特定の好適な実施の形態では、ＲＴＰパケットヘッダ（図７参照）に含まれるタイムスタンプを、２つの対応するフレームの間で同期をとるための同期データとして用いることができる。メインサービスＰフレームとザッピングサービスＩフレーム（ＩＤＲ）とは、その両方が、別々にＲＴＰパケットにカプセル化される。同期データ発生器１３０は、正確に同じＲＴＰタイムスタンプを、２つの対応する（すなわち、入力画像シーケンスの同じフレームから生じる）フレームに属する全てのＲＴＰパケットに確実に保持させる。従って、受信端末は、ＲＴＰタイムスタンプを検討することで、受信したザッピングサービスＩフレームに対応するメインサービスＰフレームを容易に判定することができる。
【００６４】
あるいは、ザッピングサービスＩフレームと対応するメインサービスＰフレームとの間の時間同期は、別に、音声ストリームと対応する動画ストリームとの同期をとる方法（ＥＴＳＩ標準ＴＳ １０２００５「ＩＰ上を直接送られるＤＶＢサービスにおける動画および音声符号化の使用に関するＤＶＢ仕様」， Ａｎｎｅｘに準拠したもの）と同じやり方で達成することができる。メインストリームＲＴＰパケットとザッピングストリームＲＴＰパケットとの両方に、ＲＴＣＰ（Real time Transport Control Protocol）センダレポートパケットが付属する。ＲＴＣＰセンダレポートパケットは、ＲＴＰタイムスタンプを、ネットワークタイムプロトコル（ＮＴＰ：Network Time Protocol）タイムスタンプと共に含む。両タイムスタンプは、時間内の同じ瞬間に対応している。しかし、ＲＴＰタイムスタンプが、データパケット内のＲＴＰタイムスタンプと同じ単位で表されるのに対し、ＮＴＰタイムスタンプは、ＩＥＴＦ標準ＲＦＣ ３５５０に従ったウォールクロックタイムで表されている。２本のデータストリーム（例えば、メインサービスとザッピングサービス）を同期させるためには、メインサービスのＲＴＣＰセンダレポートパケットとザッピングサービスのＲＴＣＰセンダレポートパケットとを受信しなければならない。ある瞬間のウォールクロックタイムは両方のＲＴＣＰパケットに関して正確に同じものであるため、それぞれのＲＴＰタイムスタンプのオフセットは、ＲＴＣＰパケット内のＮＴＰウォールクロックを手がかりに求めることができ、従って、これら有するＲＴＰタイムスタンプが正確に同じではない場合ですら、それぞれのサービスのＲＴＰパケット内での対応を確立することができる。このアプローチの問題点は、メインサービスＰフレームとザッピングサービスＩＤＲとの間で確実に同期をとるために、全てのザッピングＩＤＲにＲＴＣＰパケットを付属させなければならないことである。そうすると、必要な帯域幅の量が大きくなる。
【００６５】
以下、ザッピングサービスＩＤＲ画像を、メインサービスシーケンスからの符号化画像を復号するための参照フレームとして用いる手順について、図８（ａ）、図８（ｂ）を参照しながら説明する。図８（ａ）の一番上のタイムライン「メインストリームの受信バースト」は、符号化されたメインサービス動画データのシーケンスを示しており、それは、新たなメインサービスへの切り替えの後に最初に受信されたメインサービスバーストから引き出されたものである。図から分かるように、バーストの先頭３３フレームはＰフレームであり、それに対し、対応するＩＤＲピクチャは先のバーストに含まれていたが、まだ受信されていなかった。ＩＤＲフレームは、受信されたバーストの中で、バースト終端近くにある（バースト内の後ろから３番目のフレーム位置）。さらに、図８（ａ）の第２のタイムライン「受信ザッピングストリーム」で分かるように、ザッピングストリーム静止画が受信されている。この静止画は、ＩＤＲピクチャとして符号化されており、Ｐフレームのうちの１つ（“ｘ”の印が付いたもの）と同じオリジナル入力ピクチャに由来している。
【００６６】
従来は、ザッピングサービスＩフレームと対応するメインサービスＰフレームとの間の同期データは利用できなかった。よって、従来技術の受信端末では、第３のタイムライン「動画デコーダへのストリーム（ザッピングＩＤＲピクチャを含まないもの）」で分かるように、受信されたバーストのＰフレームの当初のシーケンスは完全に捨てられることになり、動画の提示は、メインサービスバーストで受信された最初のＩフレームと共に始まる。図８（ａ）に示した例では、２．２秒分の動画が、端末で利用可能でありながら、画面に表示されない。しかし、ザッピングサービスからの静止画をユーザに表示することで、廃棄された動画の内容分の遅延を埋めることもできる。
【００６７】
一番下のタイムライン「動画デコーダへのストリーム（ザッピングＩＤＲピクチャを含むもの）」が示すのは、本発明によるデコーダの側の処理である。同期データがエンコーダによって生成され、メインサービスおよびザッピングサービスの動画データと共に受信されるため、メインサービスのＰフレームに対するザッピングサービスＩフレームの位置を知ることができる。端末は、同期データ（例：ＲＴＰタイムスタンプ）を検証する同期手段を有し、従って、受信したメインサービスバーストに対するザッピングサービスＩフレームの位置を求めることができる。つまり、受信したザッピングストリームＩフレームを、符号化メインサービス画像データシーケンス内の対応する位置（図８（ａ）で“ｘ”の印を付けた位置）にあるＰフレームと置き換えて、以降のＰフレームを予測復号するための参照フレームとして使用することができる。図８（ｂ）に示すように、異なるタイムスタンプを有した複数のザッピングＩＤＲ画像が受信され、端末に保存された場合は、端末は最も早いものを選択し、それをメインサービスのＰフレームと置き換えることができる。
【００６８】
本発明による端末の処理に関する効果は明白である。本発明およびサービスによれば、受信当初の相当数のＰフレーム（図８（ａ）の例では３３）が廃棄されずにすみ、復号の開始は相当に早くなる。例えば、図８（ａ）の例では、廃棄する必要のあるＰフレームは「６」に過ぎず、メイン動画サービスの復号とその内容の提示を「２.２秒−０.４秒＝１.８秒」も早く開始することができる。さらに、静止画型のザッピングサービスがＤＶＢ−Ｈ放送環境に導入されている場合、メインサービスデータにおけるＩフレーム間の距離をより大きくすることができ、その結果、メイン動画サービスのＩＤＲピクチャの量をより小さくできると共に、メイン動画サービスに割り当てるデータ信号速度を下げることができる。極端なケースでは、メイン動画ストリームにおけるＩＤＲピクチャは、シーンの切り替えのたびに１つだけで充分となるだろう。加えて、本発明を用いることで、更に、新たなメインサービスが表示されるまでの待ち時間を短縮できる。上で図８（ａ）を参照しながら説明したように、対応するザッピングＩフレームが利用できないと、切り替え後に受信された最初のメインサービスバーストの先頭にあるフレームが多数、復号できなくなる、という可能性がある。しかし、新しいメインサービスの表示は、それにも関わらず、少なくとも最初のバーストの復号画像の受信当初の一部について再生速度を下げる、という手法をとることで、受信した全フレームが復号できる場合と同じタイミングで開始することができる。
【００６９】
再生速度を当初の値から（表示用フレームレートを下げるのに対応して）下げた場合、下げた速度は、利用可能な復号後データの量が通常の再生速度で連続的に表示が行えるのに充分なものになるまで、一定に保つことができる。そして、充分な量になった後、通常の再生速度に切り替える。
また、別のやり方として、いったん下げた再生速度を、通常の再生速度に達するまで継続的に上げていく、という形も可能である。例えば、ザッピング静止画像から始めて通常の再生速度に達するまで、速度を上げながら連続的に表示することができる。
【００７０】
上述の本発明の特定の様態の一例を、以下、図８（ａ）を参照しながら示す。しかし、留意すべき点として、時間長やフレームレート低下について表示し記述する値は、単に例として示すものであり、本発明がそれらの値に限定されるわけではない。
図８（ａ）の例では、先頭の６つのＰフレームが廃棄されるため、動画の表示開始まで０．４秒の遅延が生じる。開始時のこうした遅延は避けることが望ましい。しかし、本発明によるザッピングサービスが利用できる場合ですら、デコーダはこれら先頭の６つのＰフレームを復号することはできない。その代わりに、再生は組立処理（assembling）の直後に開始することができる。ただし、速度を下げ、それぞれにフレームレートを下げて、復号されない動画データを埋め合わせる形となる。図８（ａ）の例では、時間軸の最初の０．８秒は、表示に利用できる（すなわち、受信データシーケンスにおいて“ｘ”の位置から始まる）最初の６フレームを再生することで、埋めることができる。ただし、それらは元々０．４秒だけ埋めるはずであったものを、フレームレートを半分にして再生するのである。その後、動画デコーダにおいて、フレームレートはその公称値に変えられ、そして、公称フレームレートでの動画再生が続けられる。最初の０．８秒の間のサウンドについては、時間的に動画に一致しないので、消音とする。
【００７１】
受信端末の中にある、本発明による動画デコーダのブロック図を図９に示す。
入力データは、ＩＰ／ＵＤＰ／ＲＴＰ入力パケット２０５の形式で受信される。デパケタイザ２１０は、メインサービスの符号化動画画像データシーケンス２２１とザッピングサービスの符号化静止画データ２２２とを生成し、これらは復号手段２２０に提供される。さらに、ザッピングのフレームおよびメインのフレームは、必要であれば、メモリ２３０に格納される。同期手段２６０は、パケット化された入力ストリーム２０５で動画データと共に受信された同期データを検証する。よって、ザッピングＩＤＲフレームが復号手段２２０に送られるのは、正確に、対応するメインサービスＰフレームが受信されて、後続のメインサービス画像の復号のための参照画像としてＩＤＲピクチャが必要とされる、そのタイミングとなる。復号されたメインストリーム画像は続いて、出力フォーマッタ２４０を経由してディスプレイ２５０へと進む。
【００７２】
復号手段２２０の構造について、以下、図１０を参照しながら更に詳細に説明する。 
一般的に言えば、符号化画像をデコーダ側で再構成するためには、符号化プロセスを逆の形に適用する。先ず、エントロピー復号ユニット３１０において、エントロピー符号化が逆に実行される。エントロピー復号後の係数は逆量子化器・逆変換器３２０に送られ、動きデータは動き補償予測ユニット３７０に送られる。ここで、量子化係数データは逆量子化・逆変換ユニット３２０の元にある。予測誤差を含んだ再構成画像ブロックは、加算器３３０により、フレーム内予測ユニット３６０から出力される予測信号（フレーム内符号化モードの場合）、または、動き補償予測ユニット３７０から出力される予測信号（フレーム間符号化モードの場合）に加算される。結果として生じる画像はデブロッキングフィルタ３４０に入力され、復号された信号は、予測ユニット３６０、３７０への入力のためにメモリ３５０に格納される。新たなメインサービスチャンネルの最初のメインサービスバーストの頭では、受信したメインサービスからの復号Ｉフレームが利用できないため、最初は、ザッピングフレーム記憶２３０ａからのザッピングサービス画像が、復号のための参照画像として入力される。従って、ザッピングフレームメモリ２３０ａからのザッピングフレームは、同期手段２６０からの信号に従ってデコーダメモリ３５０に提供されるが、それは、ザッピングフレームメモリ２３０ａに格納された画像に対応するメインサービスＰフレームが受信された、と同期手段が判断した場合である。
【００７３】
以下、受信機端末における本発明の典型的な実施の形について、図１１乃至１３のフローチャートを参照しながら、更に詳細に説明する。
以下の説明は、ザッピングサービスへの対応、および、受信されるメインサービスの全てが利用できること、が前提となっている。従って、送信機側は、各々のメインサービスに対して、関連するザッピングサービスを提供する。ユーザが、受信機端末の使用を開始する、または、現在受信しているメインサービスから別のメインサービスへの切り替えを行うと、端末は初期化され、メインサービスと対応するザッピングサービスとを平行して受信する。どのサービスを最初に受信するかについての決定は、放送タイミングにのみ依存する。ユーザが、２つの連続するメインサービスバーストの間でメインサービスの切り替え（図２に点線で示すもの）を実施した場合、直ちに利用できるメインサービスデータはない。一般に、ザッピングサービスデータは、バースト間隔がより短い分、メインサービスデータよりも早く利用可能となることが期待される。従って、端末では、バースト間隔がより短いため、先にザッピングデータバーストを受信する可能性が高い。
【００７４】
受信後、端末は、全ての必要な前処理（例：ＩＰパケットの組立（assembling）、誤り訂正（必要な場合）、ＩＰおよびＵＴＰヘッダの除去）を実行する。対応する前処理は、図１１のＳ１１０（ザッピングサービス用）、図１２のＳ３１０（メインサービス用）にまとめてある。前処理は、両方が平行して行われる。
以下、受信されたザッピングサービスデータの、その後の処理について、図１１を見ながら説明する。後続のステップＳ１２０では、受信されたＲＴＰパケットのＲＴＰタイムスタンプの値が保存される。タイムスタンプは、伝送されたザッピングサービスＩＤＲに属するあらゆるＲＴＰパケットについて同一である。次のステップＳ１３０では、ＩＤＲに含まれるシーケンスパラメータ（ＩＳＯ／ＩＥＣ１４４９６−１０「情報技術−音声映像オブジェクトの符号化−（第１０部：高度動画符号化）」で定められたもの）を端末が読み込む。好ましい構成として、ザッピングサービスＩＤＲは、表示に関するピクチャ特性を定義するピクチャパラメータを更に有する（例えば、水平解像度および垂直解像度、ピクセルビット幅など）。ザッピングＩＤＲに含まれるシーケンスおよびピクチャのパラメータは、メインサービスにも適用できる。
【００７５】
従って、ＩＤＲ内部のシーケンスおよびピクチャのパラメータセットは、メインサービスおよびザッピングサービスの両方で、動画デコーダの初期化に用いることができる。よって、ステップＳ１４０で動画デコーダを一度初期化しておけば、途中で再初期化を行うことなく、両方のサービスの復号に用いることができる。
続くステップＳ１５０では、ザッピングＩフレームが、ＲＴＰパケットペイロードから組み立てられる。ステップＳ１６０において完全なＩフレームが利用できるのであれば、それは、ステップＳ１２０で保存された適正なＲＴＰタイムスタンプの参照値と共に保存される。さらに、ステップ１７０で動画デコーダがＩフレームを復号し、その結果生じたピクチャは、ステップＳ１８０において、内容の表示のためにピクチャバッファ２３０ａに送られる。
【００７６】
後続のステップＳ１９０では、メインサービスバーストの受信が、ザッピングサービス処理時間中か否かの判定が行われる（図１２のステップＳ３２０、Ｓ３３０も参照）。ステップＳ１９０において、ザッピングサービス処理時間中でメインサービスが全く受信できないと判断された場合、受信機は、開始点にループし（Ｓ１９０：Ｎｏ）、次のザッピングデータバーストを待つ。
【００７７】
メインサービスデータバーストの受信がザッピングサービスデータの前処理中の場合（Ｓ１９０：Ｙｅｓ）、「ザッピングサービスハンドラ」（Ｓ２００）が開始される。サブステップＳ２１０〜Ｓ２４０については、図１１の下側部分を参照しながら更に詳細に説明する。ステップＳ２００では、受信されたメインサービスデータをフレーム種類によって解析する。受信データは少なくともＩフレームおよびＰフレームを相当量含んでおり、先に受信され保存されていたＩフレームに一致するＩフレームまたはＰフレームが見つかるまで、データは１フレームずつ送られる（Ｓ２１０）。図１１のフローチャートは、簡潔にするために、受信されたメインサービス内ではＩフレームおよびＰフレームのみが利用できる、という前提になっているが、本発明はこうしたケースに限定されない。例えば、双方向性の動画符号化が用いられている場合、メインサービスは更にＢフレームを含むが、ザッピングサービスハンドラはこれを無視する。
【００７８】
Ｐフレームが見つかると（Ｓ２１０：Ｎｏ）、保存されたザッピングサービスＩフレームと当該メインサービスＰフレームとからのＲＴＰタイムスタンプが、ステップＳ２２０において比較される。それらタイムスタンプが等しい場合（Ｓ２３０：Ｙｅｓ）、復号手段２２０に対しては、メインサービスＰフレームに関するデータを削除し、次のメインサービスＰフレームの復号時にはザッピングサービスＩフレームを参照用に用いる、という指示が与えられる（Ｓ２４０）。タイムスタンプが等しくなかった場合（Ｓ２３０：Ｎｏ）、現在のメインサービスＰフレームはドロップされ（Ｓ２３５）、フローはステップＳ２１０に戻る。
【００７９】
ステップＳ２４０を抜けると、ザッピングサービスハンドラの処理は終わり、メインサービス動画データに関するその先の処理は、図１２においてＳ２００からＳ３００への矢印で示される「メインサービス処理ループ」が行う。
メインサービス処理ループＳ３００のサブステップについては、図１２のフローチャートの右側部分を参照しながら、更に詳細に説明する。
【００８０】
ステップＳ３４０において、動画デコーダは、受信されたＩＰペイロードデータからのメインサービスのフレームの組立を始める。ここで説明する例では、動画デコーダは先のステップＳ１４０で、ザッピングＩＤＲパラメータセットの助けですでに初期化されているため、後続のステップＳ３５０の判定の結果は「Ｙｅｓ」となり、フローは直接ステップＳ３６０へと変わる。別の形では、例えば、ザッピングサービスデータが、メインサービスバーストに先立って受信されていなかった場合、フローチャートの右側の分岐で、ステップＳ３５２およびＳ３５４によって初期化が実施される。
【００８１】
ステップＳ３６０の処理は、ザッピングサービスＩフレームが以降の復号のために用いられるのか、あるいは、受信データの中にあったメインサービスＩフレームが以降の復号のための参照として用いられるのか、に応じて異なってくる。ザッピングサービスＩフレームが用いられる場合、ステップＳ３６０は、次のメインサービスＰフレームにおけるヘッダ情報の一部を変えて、標準ＩＳＯ／ＩＥＣ１４４９６−１０「情報技術−音声映像オブジェクトの符号化（第１０部：高度動画符号化）」に準拠した形にする。
【００８２】
図１３は、ステップＳ３６０の詳細を示す簡略フローチャートである。ザッピングサービスＩフレームが隣接Ｐフレーム用の参照として用いられる場合（Ｓ３６２：Ｎｏ，Ｓ３６４：Ｙｅｓ）、ピクチャヘッダ内にあるフレーム番号と、スライスヘッダにおけるピクチャ順番カウント（ＰＯＣ：Picture Order Count）の番号とが、ＩＳＯ／ＩＥＣ１４４９６−１０標準に従って置き換えられることになる（定数オフセットの減算、Ｓ３６５、Ｓ３６６）。ザッピングサービスＩフレームを参照として用いる最初のメインサービスＰフレームに挿入される値は、ＩＤＲの直後のＰフレームに一致しなければならない。以降のＰフレームでは、シームレスな動画ストリームのために、番号は、ＩＳＯ／ＩＥＣ１４４９６−１０に従って置き換えられる。従って、これらのＰフレームの復号中、動画デコーダがエラーを報告することはない。こうしたヘッダ情報の交換は、メインサービスＩフレームが見つかるまで行われる（Ｓ３６２：Ｙｅｓ）。
【００８３】
ここで図１２に戻る。後続のステップＳ３７０では、復号された動画データは動画バッファに送られ、要求された時点で表示のために出力される。デコーダは、ユーザサービスの次の変更、端末のスイッチオフや、その他中断（信号損失など）が生じて、連続的なメインサービスバーストが受信できない事態が生じるまでは、メインサービス処理ループＳ３００にとどまる。そして、こうした事態が生じた場合、端末は最初から処理を始め、メインサービスバーストまたは対応するザッピングサービスを受信しようとする。
【００８４】
これまでの詳細な説明は、一例として行ったものであり、本発明の範囲をこれに限定する意図はない。当業者であれば、本発明を実施するにあたって様々な変形を施す余地のあることが分かるはずである。
例えば、本発明は、ＤＶＢ−Ｈ放送環境やＨ．２６４／ＡＶＣ動画コーデックに限定されない。他の動画コーデック（例：ＶＣ−１）を使用する場合、ザッピングピクチャはランダムアクセスポイント（ＲＡＰ）として符号化するべきでる。ＲＡＰは、動画フレームのうち、即座に動画復号を開始するために用いることのできるものに関する共通宣言（common declaration）である。Ｈ．２６４／ＡＶＣの特定のケースでは、ＲＡＰはＩＤＲである。従って、当業者ならば気づく通り、ザッピングサービスのランダムアクセスポイント（ＲＡＰ）は、メイン動画サービスが異なる動画コーデックで符号化されている場合でも、同様のやり方で復号エントリポイントとして使用することができる。
【００８５】
更に別の変更例として、ザッピングサービス画像のフォーマットに関するものがある。伝送されるザッピングサービスに、受信終端において復号される、何らかのフォーマット（ＪＰＥＧ、ｐｎｇ、ＧＩＦ）のピクチャを含ませて、本発明によるメインサービスＰフレームの代替として用いることができる。
要約すると、本発明は、モバイル受信端末にデジタル動画データを放送する改良型ザッピングサービスに関し、具体的には、動画エンコーダおよび動画デコーダに関する。ザッピングサービスには、メイン動画サービスにおいて対応するＰフレームと同期する静止画（フレーム内符号化フレーム）が含まれる。各同期データは、動画エンコーダによって生成され、モバイル受信端末に伝送される。
モバイル受信端末の動画デコーダは、同期データを用いることで、符号化されたメインサービス画像シーケンスの復号にあたってザッピングサービスＩフレームをランダムアクセスポイントとして使用することができる。従って、新たなメイン動画サービス（ザッピング）の選択の後、メイン動画サービスの表示準備ができるまでの待ち時間は短縮され、メインサービスチャンネルで伝送しなければならないＩフレームで消費される帯域幅の数字も小さくなる。その結果、必要な帯域幅は小さくなる。
【図面の簡単な説明】
【００８６】
【図１】ＤＶＢ−Ｈメインサービスのバーストによる伝送を示す図である。
【図２】ＤＶＢ−Ｈメインサービスおよびザッピングサービスのバーストによる伝送を示す図である。
【図３】従来のザッピングサービス生成器のスキームを示す図である。
【図４】本発明によるザッピングサービス生成を伴う動画エンコーダのブロック図である。
【図５】本発明による動画エンコーダの例示的な実施の形態で使用される、予測符号化を行う符号化手段のブロック図である。
【図６】本発明による動画エンコーダからの動画データ出力の例を概略的に示す図である。
【図７】ＵＤＰおよびＲＴＰに準拠したインターネットプロトコルパケットに基づいた、本発明の実施の形態による動画エンコーダからのデータ出力を示す図である。
【図８】（ａ）ザッピングサービスＩＤＲ画像を、対応するメイン動画サービスシーケンスの復号開始のための開始参照画像として用いる用法を示す図である。（ｂ）ザッピング動画サービスＩフレームを、対応するメイン動画ストリームの復号開始のために用いる場合の詳細な例を示す図である。
【図９】本発明による受信端末の中の動画デコーダの全体的な構造を示す図である。
【図１０】本発明の例示的な実施の形態で使用される動画デコーダのスキームを示すブロック図である。
【図１１】受信されたザッピングサービスの処理の、本発明による例示的な実行の形を示すフローチャートである。
【図１２】本発明による受信端末でのメインサービス処理の例示的な実行の形を示すフローチャートである。
【図１３】図１２の例示的な実行の形における動画データ復号ステップＳ３６０の詳細を示すフローチャートである。
【図１】
2009528709.tif 000003
【図２】
2009528709.tif 000004
【図３】
2009528709.tif 000005
【図４】
2009528709.tif 000006
【図５】
2009528709.tif 000007
【図６】
2009528709.tif 000008
【図７】
2009528709.tif 000009
【図８】
2009528709.tif 000010
【図９】
2009528709.tif 000011
【図１０】
2009528709.tif 000012
【図１１】
2009528709.tif 000013
【図１２】
2009528709.tif 000014
【図１３】
2009528709.tif 000015
【国際調査報告】
2009528709.tif 000016
2009528709.tif 000017
2009528709.tif 000018