JP2013219513A - 画像データ送信装置、画像データ送信方法および画像データ送信プログラム - Google Patents

Abstract

【課題】パケットを送信する構成において、再生するためのタイミング情報を送れず、かつ受信側の装置におけるパケットの復元処理による待機時間が発生する場合でも、番組の情報を適切に再生させる。
【解決手段】配信装置２０は、送信すべき、基本画像を示す基本画像データ、および前記基本画像データを参照することにより作成される関連画像データが分割された、複数の分割パケットをソースブロックとしてまとめ、基本画像データおよび関連画像データの受信側の装置においてソースブロックを復元するための復元用パケットを、ソースブロックに基づいて作成するためのＦＥＣパケット作成部２５を備える。ＦＥＣパケット作成部２５は、基本画像データを選択的に送信する場合には、１つのソースブロックに含める基本画像データの分割パケットを、１つの基本画像データに対応する分割パケットに制限する。
【選択図】図６

Description

本発明は、画像データ送信装置、画像データ送信方法および画像データ送信プログラムに関し、特に、番組の情報に含まれる画像データ、および上記画像データの復元に用いる復元用データを送信するための画像データ送信装置、画像データ送信方法および画像データ送信プログラムに関する。

ＩＰＴＶ（Internet Protocol Television）規定（非特許文献１および非特許文献２）には、ＩＰ（Internet Protocol）ネットワークを用いたＶＯＤ（Video On Demand）サービスによる番組の配信について記載されている。番組の情報を配信する映像コンテンツサーバは、受信側の装置から要求された番組の情報をパケットに含めて受信側の装置へ配信する。この際、映像コンテンツサーバは、ＩＰネットワークにおいてパケットロスが発生すると、ＦＥＣ（Forward Error Correction）を用いてパケットロスに対処できるようにする。

また、映像コンテンツサーバは、通常の再生速度に対応する番組の情報の他に、たとえば受信側の装置により指定された倍速値の早送り再生または巻き戻し再生等の、トリック再生に対応する番組の情報を当該受信側の装置へ送信する。映像コンテンツサーバは、ＩフレームＴＳ方式によりトリック再生に対応する番組の情報を送信する際、以下の処理を行う。すなわち、映像コンテンツサーバは、ストリームにおいてＩフレーム以外のＰフレームおよびＢフレームを破棄し、Ｉフレームのみ送信する。また、映像コンテンツサーバは、指定された倍速値での再生が受信側の装置において可能となるような時間間隔で、Ｉフレームの画像データを受信側の装置へ送信する。

ＩＰＴＶ規定 ＶＯＤ仕様、ＩＰＴＶＦＪ ＳＴＤ−０００２ １．１版、ＩＰＴＶフォーラム、２０１０年７月３０日 ＩＰＴＶ規定 ＣＤＮスコープ サービスアプローチ仕様、ＩＰＴＶＦＪ ＳＴＤ−０００６ １．３版、ＩＰＴＶフォーラム、２０１０年７月３０日

非特許文献１および非特許文献２に記載の技術では、受信側の装置は、受信したパケットをある一定量蓄積した後、蓄積したパケットのＦＥＣを用いた復元処理を行う。このため、受信側の装置は、当該復元処理が完了するまで、受信したパケットをデコードすることができない。

映像コンテンツサーバは、通常再生に対応する番組の情報を送信する場合、当該番組の情報を適切なタイミングでデコードするためのタイミング情報をストリームに含めて送信する。これにより、受信側の装置は、受信したパケットの復元処理が完了すると、当該タイミング情報に基づくことにより、番組の情報を適切なタイミングでデコードすることができる。

一方、映像コンテンツサーバは、ＩフレームＴＳ方式によりトリック再生に対応する番組の情報を送信する場合、具体的には、基本画像を示すＩフレームならびに当該Ｉフレームを参照することにより作成される関連画像を示すＰフレームおよびＢフレームの中から、Ｉフレームを選択的に送信する場合、以下の処理を行う。すなわち、当該映像コンテンツサーバは、当該番組の情報を適切なタイミングでデコードするためのタイミング情報を送信せずに、指定された倍速値でのトリック再生が受信側の装置において可能となるような時間間隔で、番組の情報を受信側の装置へ送信する。受信側の装置は、映像コンテンツサーバから番組の情報を受信したタイミングで、当該番組の情報をデコードすることにより、当該倍速値でのトリック再生を実現する。

しかしながら、トリック再生時において、受信側の装置が受信したパケットのＦＥＣを用いた復元処理を行うと、以下の問題が発生する場合がある。すなわち、受信側の装置は、復元処理が完了するまで受信したパケットをデコードすることができないので、映像コンテンツサーバから受信したパケットに含まれる番組の情報をデコードするタイミングは、復元処理のタイミングにより遅れてしまう場合がある。

すなわち、受信側の装置は、受信したパケットに含まれる番組の情報を、当該パケットを受信したタイミングでデコードすることができない。このため、映像コンテンツサーバが、指定された倍速値でのトリック再生が受信側の装置において可能となるような時間間隔で番組の情報を送信しても、受信側の装置では、番組の情報を当該時間間隔で再生することができなくなってしまう。

この発明は、上述の課題を解決するためになされたもので、その目的は、パケットを送信する構成において、再生するためのタイミング情報を送れず、かつ受信側の装置におけるパケットの復元処理による待機時間が発生する場合でも、番組の情報を適切に再生させることが可能な画像データ送信装置、画像データ送信方法および画像データ送信プログラムを提供することである。

（１）上記課題を解決するために、この発明のある局面に係わる画像データ送信装置は、基本画像を示す基本画像データ、および前記基本画像データを参照することにより作成される関連画像データを送信するための画像データ送信装置であって、送信すべき上記基本画像データおよび上記関連画像データが分割された、複数の分割パケットをソースブロックとしてまとめるためのソースブロック作成部と、上記基本画像データおよび上記関連画像データの受信側の装置において上記ソースブロックを復元するための復元用パケットを、上記ソースブロックに基づいて作成するための復元用パケット作成部とを備え、上記ソースブロック作成部は、上記基本画像データを選択的に送信する場合には、１つの上記ソースブロックに含める上記基本画像データの上記分割パケットを、１つの上記基本画像データに対応する上記分割パケットに制限する。

このような構成により、１つのソースブロックに含められる基本画像データの分割パケットが１つの基本画像データに対応するので、１つのソースブロックにおいて２つ以上の基本画像データが含まれることによる処理の遅延を防ぐことができる。

これにより、再生するためのタイミング情報が画像データ送信装置により送信されない場合においても、指定された倍速値でのトリック再生が可能となるような時間間隔で基本画像データを送信することにより、受信側の装置では、上記基本画像データを当該時間間隔で再生することができる。

（２）好ましくは、上記ソースブロック作成部は、上記基本画像データを選択的に送信する場合には、１つの上記ソースブロックとなる上記分割パケットが、１つの上記基本画像データに対応する上記分割パケットになるように、上記ソースブロックのデータサイズを調整する。

このような構成により、１つの基本画像の基本画像データに対して、１つのソースブロックを対応させることができる。これにより、１つのソースブロックにおいて、たとえばヌルパケットのような余分なデータが含まれないので、余分なデータの処理による負担の増加、およびネットワークにおける分割パケットの送信に必要な帯域の増大を防ぐことができる。

また、受信側の装置は、上記基本画像を作成する際に、前に受信したソースブロックまたは次に受信するソースブロックを参照する必要がないので、基本画像の作成処理を簡素化することができる。

（３）好ましくは、上記ソースブロックのデータサイズが固定値に設定され、上記ソースブロック作成部は、上記基本画像データを選択的に送信する場合であって、１つの上記基本画像データに対応する上記分割パケットの総データ量が上記固定値に満たないときには、上記分割パケット、およびヌルデータを含むパケットを上記ソースブロックとしてまとめる。

このような構成により、基本画像データに対応する分割パケットの総データ量毎にソースブロックのデータサイズを変更する必要がないので、画像データ送信装置におけるソースブロックの作成処理を簡素化することができる。

また、受信側の装置は、一定のデータサイズのソースブロックを取り扱う。これにより、受信側の装置は、受信する度に上記ソースブロックのデータサイズを取得し、取得したデータサイズに応じて処理のアルゴリズムを変更する必要がない。すなわち、受信側の装置は、一定のデータサイズに対応した一定の処理を用意するだけでよいので、処理のアルゴリズムを簡素化することができる。

（４）より好ましくは、上記ソースブロック作成部は、１つの上記基本画像データに対応する上記分割パケットの総データ量が上記ソースブロックの最大データサイズを超える場合には、１つの上記基本画像データに対応する上記分割パケットを１または複数の上記ソースブロックに含め、余った上記分割パケットを含める上記ソースブロックのデータサイズを、余った上記分割パケットの総データ量に応じて調整する。

このような構成により、ソースブロックにデータサイズの上限がある場合においても、１つの基本画像の基本画像データを１または複数のソースブロックに収容することができる。

また、余った分割パケットを含めるソースブロックのデータサイズを、余った分割パケットの総データ量に応じて調整するので、たとえばヌルパケットのような余分なパケットを含める必要がない。これにより、たとえばネットワークにおいて画像データの送信に使用される帯域が、余分なパケットを送信することにより増加してしまうことを防ぐことができる。

また、たとえばヌルパケットのような余分なパケットがソースブロックに含まれないので、受信側の装置は、たとえば復元処理において、余分なパケットを処理することによる負担の増加を防ぐことができる。

（５）好ましくは、上記基本画像データはＩフレーム（Intra-coded Frame）の画像データであり、上記関連画像データはＰフレーム（Predicted Frame）またはＢフレーム（Bi-directional Predicted Frame）の画像データであり、上記画像データ送信装置は、上記基本画像データを選択的に送信することにより、上記基本画像データの受信側の装置においてトリック再生を可能とする。

このような構成により、受信側の装置は、画像データ送信装置から受信した基本画像データに基づいてトリック再生に用いる基本画像を作成する際、作成した基本画像の表示時間が長くなったり、短くなったりすることなく、トリック再生を行うことができる。すなわち、受信側の装置は、ＩフレームＴＳ方式に従ったトリック再生を、指定した倍速値で行うことができる。

（６）また、この発明のある局面に係わる画像データ送信方法は、基本画像を示す基本画像データ、および上記基本画像データを参照することにより作成される関連画像データを送信するための画像データ送信装置における画像データ送信方法であって、送信すべき上記基本画像データおよび上記関連画像データが分割された、複数の分割パケットをソースブロックとしてまとめるステップと、上記基本画像データおよび上記関連画像データの受信側の装置において上記ソースブロックを復元するための復元用パケットを、上記ソースブロックに基づいて作成するステップとを含み、上記ソースブロックとしてまとめるステップにおいては、上記基本画像データを選択的に送信する場合には、１つの上記ソースブロックに含める上記基本画像データの上記分割パケットを、１つの上記基本画像データに対応する上記分割パケットに制限する。

このような構成により、１つのソースブロックに含められる基本画像データの分割パケットが１つの基本画像データに対応するので、１つのソースブロックにおいて２つ以上の基本画像データが含まれることによる処理の遅延を防ぐことができる。

これにより、再生するためのタイミング情報が画像データ送信装置により送信されない場合においても、指定された倍速値でのトリック再生が可能となるような時間間隔で基本画像データを送信することにより、受信側の装置では、上記基本画像データを当該時間間隔で再生することができる。

（７）また、この発明のある局面に係わる画像データ送信プログラムは、基本画像を示す基本画像データ、および上記基本画像データを参照することにより作成される関連画像データを送信するための画像データ送信装置において用いられる画像データ送信プログラムであって、コンピュータに、送信すべき上記基本画像データおよび上記関連画像データが分割された、複数の分割パケットをソースブロックとしてまとめるステップと、上記基本画像データおよび上記関連画像データの受信側の装置において上記ソースブロックを復元するための復元用パケットを、上記ソースブロックに基づいて作成するステップとを実行させるためのプログラムであり、上記ソースブロックとしてまとめるステップにおいては、上記基本画像データを選択的に送信する場合には、１つの上記ソースブロックに含める上記基本画像データの上記分割パケットを、１つの上記基本画像データに対応する上記分割パケットに制限する。

このような構成により、１つのソースブロックに含められる基本画像データの分割パケットが１つの基本画像データに対応するので、１つのソースブロックにおいて２つ以上の基本画像データが含まれることによる処理の遅延を防ぐことができる。

これにより、再生するためのタイミング情報が画像データ送信装置により送信されない場合においても、指定された倍速値でのトリック再生が可能となるような時間間隔で基本画像データを送信することにより、受信側の装置では、上記基本画像データを当該時間間隔で再生することができる。

本発明によれば、パケットを送信する構成において、再生するためのタイミング情報を送れず、かつ受信側の装置におけるパケットの復元処理による待機時間が発生する場合でも、番組の情報を適切に再生させることが可能な画像データ送信装置、画像データ送信方法および画像データ送信プログラムを提供することである。

本発明の実施の形態に係る番組配信システムの構成を示す図である。 本発明の実施の形態に係る配信される画像データの一例を示す図である。 本発明の実施の形態に係る通常再生時およびトリック再生時において送信されるフレームの一例を示す図である。 本発明の実施の形態に係るパケットの欠損補償の一例を示す図である。 本発明の実施の形態に係るＩフレームの画像データおよびソースブロックの対応関係の一例を示す図である。 本発明の実施の形態に係る配信装置の構成を示す図である。 本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを動的に変化させる場合におけるソースブロックおよびＦＥＣ符号化ブロックの一例を示す図である。 本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズに上限がある場合におけるソースブロックおよびＦＥＣ符号化ブロックの一例を示す図である。 本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを変更できない場合におけるソースブロックおよびＦＥＣ符号化ブロックの一例を示す図である。 本発明の実施の形態に係る配信装置におけるトリック再生処理を行う際の動作手順の一例を定めたフローチャートである。 本発明の実施の形態に係る配信装置におけるＩフレームの検出処理を行う際の動作手順の一例を定めたフローチャートである。 本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを動的に変化させる場合におけるＦＥＣ符号化ブロックおよびソースブロックを作成する際の動作手順の一例を定めたフローチャートである。 発明の実施の形態に係るＦＥＣ符号化ブロックのサイズに上限がある場合におけるＦＥＣ符号化ブロックおよびソースブロックを作成する際の動作手順の一例を定めたフローチャートである。 発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを変更できない場合におけるＦＥＣ符号化ブロックおよびソースブロックを作成する際の動作手順の一例を定めたフローチャートである。

以下、本発明の実施の形態について図面を用いて説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。

［番組配信システムの概要］
図１は、本発明の実施の形態に係る番組配信システムの構成を示す図である。

図１を参照して、番組配信システム１０は、配信装置２０と、番組受信装置４０とを備える。番組受信装置４０は、ネットワーク１１を介して配信装置２０と接続されている。

配信装置２０は、基本画像を示す基本画像データ、および基本画像データを参照することにより作成される関連画像データを送信する。言い換えると、配信装置２０は、基本画像を示す基本画像データ、および基本画像データを参照することにより再生可能な画像を示す関連画像データを送信する。基本画像、基本画像データおよび関連画像データについては、後述する。

配信装置２０は、たとえばＩＰＴＶに対応するサーバであり、番組受信装置４０を使用するユーザによりある番組の情報を要求されると、当該番組の情報を含むストリームを配信するＶＯＤサービスを行う。

配信装置２０は、たとえばＩＰを利用することにより、当該番組の情報を含むストリームを、インターネット等のネットワーク１１経由で番組受信装置４０へ配信する。

番組受信装置４０は、ユーザが要求した番組の情報を含むストリームを、たとえばＩＰによりネットワーク１１経由で配信装置２０から受信し、受信した上記ストリームを処理することにより、当該番組の情報を取得する。そして、番組受信装置４０は、取得した番組の情報を表示装置１２において再生する。なお、番組受信装置４０および表示装置１２は、一体であってもよい。

配信装置２０が配信する番組の情報は、ＭＰＥＧ２（Moving Picture Experts Group 2）またはＨ．２６４／ＡＶＣ（Advanced Video Coding）に従った方式により符号化される。符号化された番組の情報は、ＭＰＥＧ２−ＴＳ（Transport Stream）形式における、複数のＴＳ（Transport Stream）パケットに格納される。

ＴＳパケットは、１８８バイトの大きさを持ち、ＴＳヘッダおよびＴＳペイロードを含む。番組の情報は、たとえば複数のＴＳパケットにおけるペイロードに分割して含められる。また、ＴＳヘッダは、当該ＴＳヘッダを含むＴＳパケットの識別情報であるＰＩＤ（Packet Identifier）を含み、ＰＩＤは、当該ＴＳパケットのペイロードに含まれる情報に対応した値が割り当てられる。

ＴＳパケットには、番組の画像データを格納するビデオＴＳパケット、番組の音声データを格納するオーディオＴＳパケット、およびＰＳＩ（Program Specific Information）を示すパケット等がある。配信装置２０は、上記ＴＳパケットを多重化した１つのデータ列であるストリームにより、番組の情報をたとえば番組受信装置４０へ配信する。なお、ストリームには、複数の番組の情報を含めてもよい。

ＰＳＩを示すパケットには、ＰＡＴ（Program Association Table）パケットおよびＰＭＴ（Program Map Table）パケットが含まれる。ＰＡＴパケットは、ストリームに含まれる１または複数の番組すなわち現在放送中である１または複数の番組の識別子であるチャンネルＩＤ、および各放送チャンネルの情報を含むＰＭＴパケットのＰＩＤを含む。また、ＰＡＴパケットのＰＩＤは、１６進数表記における０ｘ００００である。

ＰＭＴパケットは、対応の番組の内容を含むビデオＴＳパケットおよびオーディオＴＳパケットのＰＩＤを含む。ＰＡＴパケットおよびＰＭＴパケットは、当該ＰＡＴパケットおよび当該ＰＭＴパケットの内容が切替わるまで、配信装置２０から繰り返し再送される場合がある。

そして、配信装置２０は、番組の情報を含むＴＳパケットにより構成されるストリームをＩＰにより送信する際に、上記ストリームに対して以下の処理を行う。すなわち、配信装置２０は、送信するストリームに含まれるＴＳパケットにおいて、当該ＴＳパケットがデコードタイミング調整用のヌルパケットである場合、当該ＴＳパケットを削除する。

また、配信装置２０がパケットを送信するタイミングを調節しながらパケットをＩＰにより番組受信装置４０へ送信しても、ＩＰではパケット毎に伝送時間のばらつきが生じるので、番組受信装置４０がパケットを受信するタイミングは、配信装置２０により調節されたタイミングと異なってしまう。

すなわち、ＩＰによるパケットの配信では、配信装置２０におけるパケットを送信するタイミングを、番組受信装置４０において再現することができない。これに対処するために、配信装置２０は、送信するストリームに含まれるＴＳパケットを、受信側の装置においてデコーダへ投入すべきタイミングを示すタイムスタンプ情報を含めたＴＴＳ（Timestamped TS）パケットへ変換する。

番組受信装置４０は、ＴＴＳパケットを受信すると、受信したＴＴＳパケットのタイムスタンプ情報を参照することにより、当該ＴＴＳパケットを適切なタイミングでデコーダへ投入することができる。

配信装置２０は、複数のＴＴＳパケットを、所定個数のＴＴＳパケットにより構成される複数のグループに分割し、各グループをＲＴＰ（Realtime Transport Protocol）パケットのペイロードに含める。なお、上記所定個数は、たとえば非特許文献１において７個が推奨されている。配信装置２０は、上記ＲＴＰパケットをたとえばネットワーク１１経由で番組受信装置４０へ送信することにより、番組の情報を番組受信装置４０へ配信する。

［配信装置により配信される画像データの一例］
図２は、本発明の実施の形態に係る配信される画像データの一例を示す図である。

図２を参照して、配信装置２０が配信する番組は、複数の静止画により構成される動画であり、図２の（Ａ）に示すように複数の静止画により構成される。なお、上記静止画１つ分の画像を、フレームと称する。すなわち、配信装置２０が配信する番組は、複数のフレームにより構成される。

１フレームを描画するために必要な画像データは、ピクチャである。また、１フレームの一部を描画するために必要な画像データは、スライスである。すなわち、ピクチャは、複数のスライスにより構成される。

たとえば、ＭＰＥＧ２の方式では、ピクチャは、Ｉピクチャ（Intra Picture）、Ｐピクチャ（Predictive Picture）およびＢピクチャ（Bi-directionally Predictive-Picture）の３種類のピクチャがある。また、Ｈ．２６４／ＡＶＣの方式では、スライスは、Ｉスライス（Intra Slice）、Ｐスライス（Predictive Slice）またはＢスライス（Bi-predictive Slice）の３種類のスライスがある。なお、Ｈ．２６４／ＡＶＣの方式では、１ピクチャにおいて、Ｉスライス、ＰスライスまたはＢスライスが混在してもよい。

Ｉピクチャは、１フレームにおけるフレーム内符号化によって得られるピクチャである。従って、Ｉピクチャ単独で１フレームを作成することができる。ＰピクチャまたはＢピクチャは、複数のフレームにおけるフレーム間予測符号化によって得られるピクチャである。従って、ＰピクチャまたはＢピクチャは、他のピクチャを参照することにより１フレームを作成することができる。

Ｉスライスは、当該スライスが含まれるフレーム内の予測のみで符号化することにより得られるスライスである。Ｐスライスは、当該スライスが含まれるフレーム内の予測符号化および１つの参照ピクチャを使用したフレーム間予測符号化により得られるスライスである。また、Ｂスライスは、当該スライスが含まれるフレーム内の予測符号化および１つ〜２つの参照ピクチャを使用したフレーム間予測符号化により得られるスライスである。

従って、Ｉスライスは、自己が含まれるフレームの画像データに基づいて作成される。一方、ＰスライスまたはＢスライスは、自己が含まれるフレームおよび当該フレーム以外のフレームの画像データに基づいて作成される。

また、Ｉピクチャは、Ｉスライスのみによって構成される。以下、Ｉピクチャにより作成されるフレームを、Ｉフレーム（Intra-coded Frame）と称する。Ｉフレームは、基本画像を示し、Ｉフレームの画像データであるＩピクチャは、基本画像データに相当する。

ＭＰＥＧ２の方式において、Ｐピクチャにより作成されるフレームを、Ｐフレーム（Predicted Frame）と称し、Ｂピクチャにより作成されるフレームを、Ｂフレーム（Bi-directional Predicted Frame）と称する。

また、Ｈ．２６４／ＡＶＣの方式において、Ｐスライスを含むフレームを、Ｐフレーム（Predicted Frame）と称し、Ｂスライスを含むフレームを、Ｂフレーム（Bi-directional Predicted Frame）と称する。ＰフレームまたはＢフレームの画像データは、関連画像データに相当する。

Ｉフレームを作成する際には、他のフレームの画像データを参照しなくてもよいので、Ｉフレームは、ＩフレームＴＳ方式における早送り再生または巻き戻し再生といった可変速再生等のトリック再生を行う場合に利用される。具体的には、以下の処理を行うことによりＩフレームＴＳ方式におけるトリック再生が実現される。

図３は、本発明の実施の形態に係る通常再生時およびトリック再生時において送信されるフレームの一例を示す図である。

図３を参照して、図３の（Ａ）に示すように通常再生時においては、Ｉフレーム、ＰフレームおよびＢフレームが所定の時間間隔で再生されるように配信される。一方、たとえばＩフレームＴＳ方式における２倍速の早送り再生時においては、図３の（Ｂ）に示すように、Ｉフレームのみを、通常再生時においてＩフレームが再生される時間間隔の半分の時間間隔で当該Ｉフレームを再生させることにより、２倍速の早送り再生を実現する。

トリック再生時においては、隣接するＩフレーム間においてフレームは伝送されない。また、ＰＣＲ（Program Clock Reference）またはＴＴＳパケットにおけるタイムスタンプ情報等の通常再生時において利用されるタイミング情報を利用できない。このため、配信装置２０は、トリック再生時においては、受信側で指定された倍速値に対応した時間間隔でＩフレームを受信側の装置で再生できるように、Ｉフレームを選択的に送信する。

すなわち、配信装置２０は、通常再生時におけるＩフレーム間の時間間隔に、受信側で指定された倍速値の逆数を乗じた時間間隔で、当該Ｉフレームが再生されるように、Ｉフレームの画像データを選択的に送信する。

また、巻き戻し再生を行う場合、早送り再生の方向と逆方向に再生させること以外は、同様の処理により巻き戻し再生が実現される。

再び図２を参照して、配信装置２０は、たとえば番組受信装置４０を使用するユーザによりある倍速値での早送り再生の要求を受けた場合、上記倍速値に対応する時間間隔で、図２の（Ａ）に示すＩフレームであるＩ−１の画像データおよびＩ−２の画像データを番組受信装置４０へ送信する。

この際、配信装置２０は、たとえばＩ−１の画像データを、図２の（Ｂ）に示すＴＴＳ−１からＴＴＳ−２１までの２１個のＴＴＳパケットに含める。また、配信装置２０は、たとえばＩ−１の次のＩフレームであるＩ−２の画像データを、図２の（Ｂ）に示すＴＴＳ−５１からＴＴＳ−６７までの１７個のＴＴＳパケットに含める。

そして、配信装置２０は、たとえばＩ−１の画像データを含むＴＴＳ−１からＴＴＳ−２１までのＴＴＳパケットを、図２の（Ｃ）に示すＲＴＰパケット１からＲＴＰパケット３までのＲＴＰパケットのペイロードに含める。また、配信装置２０は、たとえばＩ−２の画像データを含むＴＴＳ−５１からＴＴＳ−６７までのＴＴＳパケットを、図２の（Ｃ）に示すＲＴＰパケット４からＲＴＰパケット６までのＲＴＰパケットのペイロードに含める。

ＲＴＰパケットのヘッダは、シーケンス番号を保持するフィールドを有する。配信装置２０は、たとえばＲＴＰパケット１からＲＴＰパケット６までのシーケンス番号のフィールドに連続した番号を付与した後、番組受信装置４０へ送信する。

番組受信装置４０は、配信装置２０からＲＴＰパケットを受信すると、受信したＲＴＰパケットのシーケンス番号を確認することにより、当該ＲＴＰパケットを受信した順序が逆転している場合における当該順序の回復、および当該ＲＴＰパケットの伝送経路での消失の検出を行うことができる。

［ＲＴＰパケットの欠損補償］
番組受信装置４０は、配信装置２０から受信したＲＴＰパケットの順序が逆転している場合には、ＲＴＰパケットの順序を並べ替えることにより、ＲＴＰパケットの順序を容易に回復することができる。

一方、番組受信装置４０は、配信装置２０から受信したＲＴＰパケットに欠損がある場合には、欠損したＲＴＰパケットを容易に復元することができない。このため、配信装置２０は、たとえばＰｒｏ−ＭＰＥＧ（the Professional-MPEG） １Ｄ ＦＥＣ方式に準拠した処理を行うことにより、伝送経路の途中で欠損したＲＴＰパケットを番組受信装置４０において復元できるようにする。

図４は、本発明の実施の形態に係るパケットの欠損補償の一例を示す図である。

図４を参照して、配信装置２０は、たとえばＲＴＰ０１からＲＴＰ２５までの２５個のＲＴＰパケットを送信する場合、シーケンス番号順に並べた当該２５個のＲＴＰパケットを構成要素とする、図４の（Ａ）に示すソースブロックを作成する。

そして、配信装置２０は、作成したソースブロックに基づいて、上記ソースブロックに含まれるＲＴＰパケットを復元するための復元用パケットであるＦＥＣパケットを作成する。

具体的には、配信装置２０は、ソースブロックの各列のＲＴＰパケットにおけるビットストリングに対して排他的論理和を計算し、計算した排他的論理和、すなわち各ビットストリングの冗長データをペイロードに含むＦＥＣパケットを作成する。ソースブロックに対応する複数のＦＥＣパケットを、以下ＦＥＣ符号化ブロックと称する。

具体的には、配信装置２０は、図４の（Ａ）に示すソースブロックの１列目を構成するＲＴＰ０１、ＲＴＰ０６、ＲＴＰ１１、ＲＴＰ１６およびＲＴＰ２１の各ビットストリングに対して排他的論理和を計算することにより、冗長データを得る。そして、配信装置２０は、上記冗長データにＦＥＣヘッダおよびＲＴＰヘッダを付加することにより、ＦＥＣパケットである図４の（Ｂ）に示すＦＥＣ０１を作成する。

ＦＥＣヘッダには、たとえばＰｒｏ−ＭＰＥＧ １Ｄ ＦＥＣといったＦＥＣ方式、ソースブロックのサイズおよびＦＥＣ符号化ブロックのサイズが含められる。

なお、上記サイズは、ソースブロックまたはＦＥＣ符号化ブロックの行数および列数の積を示す。従って、ソースブロックのサイズは、当該ソースブロックに収容されるＲＴＰパケットの個数を示し、ＲＴＰパケットのビット数に対して上記個数を乗じた結果が、当該ソースブロックのデータサイズとなる。

また、ＦＥＣ符号化ブロックのサイズは、当該ＦＥＣ符号化ブロックに収容されるＦＥＣパケットの個数を示し、ＦＥＣパケットのビット数に対して上記サイズを乗じた結果が、当該ＦＥＣ符号化ブロックのデータサイズとなる。

配信装置２０は、図４の（Ａ）に示すソースブロックの２列目から５列目について同様の処理を行い、図４の（Ｂ）に示すＦＥＣ０２からＦＥＣ０５を作成する。図４の（Ｂ）に示すＦＥＣ０１からＦＥＣ０５までのＦＥＣパケットは、図４の（Ａ）に示すソースブロックに対応するＦＥＣ符号化ブロックを形成する。

配信装置２０は、たとえば図４の（Ａ）に示すソースブロックを構成するＲＴＰパケット、および図４の（Ｂ）に示すＦＥＣ符号化ブロックを構成するＦＥＣパケットを、それぞれ異なるポート番号を付与した別々のストリームに含めて番組受信装置４０へ送信する。

番組受信装置４０は、上記ＲＴＰパケットおよび上記ＦＥＣパケットを受信すると、まず、ＦＥＣパケットのヘッダを参照することにより、ＦＥＣ方式、ソースブロックのサイズおよびＦＥＣ符号化ブロックのサイズを取得する。そして、番組受信装置４０は、取得したブロックの大きさに基づいて、図４の（Ｃ）に示すソースブロック、および図４の（Ｄ）に示すＦＥＣ符号化ブロックを再生する。

番組受信装置４０は、図４の（Ｃ）に示すソースブロックを再生する際に、ＲＴＰ１１およびＲＴＰ１３の間のＲＴＰパケットが欠損していることを検出する。このような場合においても、番組受信装置４０は、図４の（Ｃ）に示すソースブロックにおいて「欠損１」により示される位置に対応する列に属するＲＴＰパケット、および当該列に対応するＦＥＣパケットに基づいて、欠損したＲＴＰパケットを復元する。

具体的には、番組受信装置４０は、図４の（Ｅ）に示すように、ＲＴＰパケットが欠損した列に属するＲＴＰ０２、ＲＴＰ０７、ＲＴＰ１７およびＲＴＰ２２の各ビットストリングおよび当該列に対応するＦＥＣパケットであるＦＥＣ０２のビットストリングに対して排他的論理和を計算する。計算した排他的論理和は、欠損したＲＴＰ１２のビットストリングと同じであるので、番組受信装置４０は、計算した排他的論理和に基づいて、欠損したＲＴＰパケットであるＲＴＰ１２を復元する。

上記のようなソースブロックおよび当該ソースブロックに対応するＦＥＣ符号化ブロックに基づいて、ＲＴＰパケットの欠損の検出処理および欠損したＲＴＰパケットの復元処理を、以下、ＦＥＣデコードと称する。

番組受信装置４０は、ＦＥＣデコードを行った、ＲＴＰ０１からＲＴＰ２５までのＲＴＰパケットから取得したＴＴＳパケットに基づいて、番組の画像を再生する。

なお、番組受信装置４０は、ＦＥＣデコードを完了するより以前に、ＲＴＰパケットを次の処理へ移すことは好ましくない。番組受信装置４０は、ソースブロックにおいて、たとえば１行目に属するＲＴＰパケットを復元するためには、当該ＲＴＰパケットと同一列に属するＲＴＰパケット全てが到着するまで待たなければならない。

従って、番組受信装置４０は、最終行に属するＲＴＰパケットが到着するより以前に到着したＲＴＰパケットを次の処理へ移すことはできない。

また、番組受信装置４０は、ソースブロックにおいて、たとえば最終行に属するＲＴＰパケットを復元するためには、当該ＲＴＰパケットと同一列のＲＴＰパケット全てが必要となるので、最終行に属するＲＴＰパケットが到着するより以前に、当該ＲＴＰパケットと同一列のＲＴＰパケットを次の処理へ移すことはできない。

従って、番組受信装置４０は、ＲＴＰパケットの欠損の有無に関わらず、ＦＥＣデコードが完了するまでは、ＲＴＰパケットを次の処理へ移すことができない。また、番組受信装置４０は、ＲＴＰパケットの複製を作成することにより、ＦＥＣデコード処理を行いながらＲＴＰパケットを次の処理へ移すことも考えられるが、ＲＴＰパケットを複製するために余分なメモリが必要となるので、好ましくない。

［トリック再生時においてＲＴＰパケットの欠損補償を行う際に生ずる問題点］
図５は、本発明の実施の形態に係るＩフレームの画像データおよびソースブロックの対応関係の一例を示す図である。

非特許文献１によれば、ＶＯＤにおいてトリック再生を行う方式として、通常ＴＳ方式およびＩフレームＴＳ方式が定められている。通常ＴＳ方式は、配信装置において予め早送り再生用または巻き戻し再生用に符号化処理したストリームを準備しておき、番組受信装置の要求に応じて、早送り再生用または巻き戻し再生用に準備したストリームをＭＰＥＧ２-ＴＳのフォーマットを用いて配信処理する方式である。

また、ＩフレームＴＳ方式は、上述したように、番組受信装置からの要求毎にＭＰＥＧ２-ＴＳのフォーマットからＩフレームに対応するＴＳパケットを抽出し、抽出したＴＳパケットを番組受信装置へ送信する。この際、配信装置は、番組受信装置が要求する倍速値で番組受信装置においてＩフレームを再生できるように、Ｉフレームの画像データを送信する時間間隔を調節する。

しかしながら、配信装置が、Ｉフレームの画像データを送信する時間間隔を調節した場合においても、ある１つのＩフレームの画像データが複数のソースブロックに分散されたり、また、複数のＩフレームの画像データがある１つのソースブロックに含まれてしまったりすると、番組受信装置においてＩフレームを適切な倍速値で再生させることができなくなる場合がある。

具体的には、配信装置が、たとえば図５の（Ａ）示すようにＩフレーム１からＩフレーム５までの５つのＩフレームを番組受信装置へ送信する場合を想定する。Ｉフレームの画像データのデータサイズは、当該Ｉフレームに含まれる画像に応じて変化するので、上記５つのＩフレームの画像データのデータサイズはそれぞれ異なる。また、非特許文献１により定められるＦＥＣ方式では、ソースブロックのサイズおよびＦＥＣ符号化ブロックのサイズは、少なくとも同一ストリーム内では固定されている。

従って、配信装置は、たとえば図５の（Ｂ）に示すソースブロック１からソースブロック３までの３個のソースブロックに、上記５つのＩフレームの画像データを含める。また、配信装置は、上記３個のソースブロックにそれぞれ対応する、図５の（Ｃ）に示すＦＥＣ符号化ブロック１からＦＥＣ符号化ブロック３までの３個のＦＥＣ符号化ブロックを作成する。

図５の（Ｂ）に示すように、Ｉフレーム２の画像データは、ソースブロック１およびソースブロック２に分散する。また、Ｉフレーム４およびＩフレーム５の画像データは、ソースブロック３に含まれる。

配信装置は、Ｉフレーム１からＩフレーム５までを、適切な時間間隔で順番に番組受信装置へ送信する。また、配信装置は、あるソースブロック１に含まれるデータを全て送信した後、概ねソースブロック２に含まれるデータを全て送信し終えるまでに、ＦＥＣ符号化ブロック１を番組受信装置へ送信する。配信装置は、ＦＥＣ符号化ブロック２およびＦＥＣ符号化ブロック３についても、同様のタイミングで番組受信装置へ送信する。

番組受信装置は、ソースブロック１に含まれるパケットおよびＦＥＣ符号化ブロック１に含まれるパケットを全て受信したタイミングにおいて、パケットの消失の検出を行い、必要に応じて欠損補償を行う。そして、番組受信装置は、ソースブロック１に含まれるＩフレーム１をデコードし、表示装置において再生させる。一方、Ｉフレーム２は、Ｉフレーム２の画像データの一部がソースブロック２に分散しているので、上記タイミングではデコードできない。

Ｉフレーム１は、番組受信装置がＩフレーム２の一部を受信し終えた後にデコードされるので、Ｉフレーム１が表示装置において再生されるタイミングは、適切なタイミングより遅れることになる。

次に、番組受信装置は、ソースブロック２に含まれるパケットおよびＦＥＣ符号化ブロック２に含まれるパケットを全て受信したタイミングにおいて、パケットの消失の検出を行い、必要に応じて欠損補償を行う。そして、番組受信装置は、Ｉフレーム２の画像データを全て取得したので、上記タイミングにおいてＩフレーム２をデコードし、表示装置において再生させる。また、番組受信装置は、Ｉフレーム３の画像データも全て取得したので、Ｉフレーム２に続いてＩフレーム３をデコードし、表示装置において再生させる。

Ｉフレーム２は、番組受信装置がＩフレーム３を受信し終えた後にデコードされるので、Ｉフレーム２が表示装置において再生されるタイミングは、適切なタイミングより遅れることになる。また、Ｉフレーム３は、Ｉフレーム２に続いて再生されるので、Ｉフレーム２を再生してからＩフレーム３を再生するまでの時間間隔は、適切な時間間隔より短い時間間隔となってしまう。

次に、番組受信装置は、ソースブロック３に含まれるパケットおよびＦＥＣ符号化ブロック３に含まれるパケットを全て受信したタイミングにおいて、パケットの消失の検出を行い、必要に応じて欠損補償を行う。そして、番組受信装置は、上記タイミングにおいてソースブロック３に含まれるＩフレーム４をデコードし、表示装置において再生させる。また、番組受信装置は、Ｉフレーム５の画像データも全て取得したので、Ｉフレーム４に続いてＩフレーム５をデコードし、表示装置において再生させる。

Ｉフレーム４は、番組受信装置がＩフレーム５を受信し終えた後にデコードされるので、Ｉフレーム４が表示装置において再生されるタイミングは、適切なタイミングより遅れることになる。また、Ｉフレーム５は、Ｉフレーム４に続いて再生されるので、Ｉフレーム４を再生してからＩフレーム５を再生するまでの時間間隔は、適切な時間間隔より短い時間間隔となってしまう。

上記のように、番組受信装置は、配信装置から受信した画像データを、受信したタイミングまたは受信したタイミングより遅れたタイミングで表示装置において再生してしまうので、表示装置においてフレームが再生される時間間隔が長くなったり短くなったりする問題が発生してしまう。

これにより、番組受信装置を操作するユーザは、たとえば番組受信装置に２倍速の早送り再生させても、２倍速より早くなったり遅くなったりする、再生速度の不安定な早送り再生を視聴する。

本発明の実施の形態における配信装置２０では、図５の（Ｄ）に示す５つのＩフレームを、図５の（Ｅ）および（Ｆ）に示すように、各Ｉフレームに１個のソースブロックおよび１個のＦＥＣ符号化ブロックを対応させる構成により、上記問題を解決する。

［配信装置の構成］
図６は、本発明の実施の形態に係る配信装置の構成を示す図である。

図６を参照して、配信装置（画像データ送信装置）２０は、番組配信制御部２１と、ストリーム作成部２２と、記憶部２３と、ＲＴＰパケット作成部２４と、ＦＥＣパケット作成部（ソースブロック作成部および復元用パケット作成部）２５と、通信部２６とを備える。なお、記憶部２３は、配信装置２０の外部に設けられていてもよい。

通信部２８は、インターネット等のネットワーク１１を介して番組受信装置４０とパケットの送受信を行う。

記憶部２３は、ＨＤＤ（Hard Disk Drive）等の記憶装置であり、番組の情報を含むストリームを保持する。

番組配信制御部２１は、番組の情報の配信の制御を行う。具体的には、番組配信制御部２１は、たとえばある番組の再生要求を通信部２８経由で番組受信装置４０から受信すると、当該番組の再生命令をストリーム作成部２２へ出力する。

また、番組配信制御部２１は、ある倍速値での早送り再生または巻き戻し再生等のトリック再生の要求を通信部２８経由で番組受信装置４０から受信すると、当該倍速値でのトリック再生命令をストリーム作成部２２へ出力する。

ストリーム作成部２２は、番組配信制御部２１から再生命令を受けると、受けた再生命令に対応する番組を含む、ＭＰＥＧ２−ＴＳ形式のストリームを記憶部２３から読み出す。そして、ストリーム作成部２２は、読み出したストリームに基づいて、ＩＰによる配信に適した配信用ストリームを作成する。

より詳細には、ストリーム作成部２２は、読み出したストリームからＴＳパケットを取得する。そして、ストリーム作成部２２は、取得したＴＳパケットがデコードタイミング調整用のヌルパケットである場合、当該ヌルパケットを削除する。また、ストリーム作成部２２は、取得したＴＳパケットがヌルパケットでない場合、当該ＴＳパケットにタイムスタンプ情報を付加することによりＴＴＳパケットへ変換する。そして、ストリーム作成部２２は、上記ＴＴＳパケットをＲＴＰパケット作成部２４へ出力する。

また、ストリーム作成部２２は、番組配信制御部２１からある倍速値でのトリック再生命令を受けると、受けたトリック再生命令の示す倍速値で画像データを送信するために、以下の処理を行う。すなわち、ストリーム作成部２２は、トリック再生に対応する番組のストリームにおいて、たとえば早送り再生を行う場合、トリック再生を開始する位置より時間的に後方におけるＩフレームの画像データの開始位置および終了位置を特定する。当該Ｉフレームの画像データの開始位置および終了位置の検出処理については、後述する。

ストリーム作成部２２は、当該Ｉフレームの画像データの開始位置および終了位置に基づいて、当該Ｉフレームの画像データを含むＴＳパケットを記憶部２３から取得する。そして、ストリーム作成部２２は、取得したＴＳパケットおよび取得したＴＳパケットに対応するＰＳＩ情報をＲＴＰパケット作成部２４へ出力する。

この際、ストリーム作成部２２は、取得したＴＳパケットおよび当該Ｉフレームの対応関係を明確にするために、以下の処理を行ってもよい。すなわち、ストリーム作成部２２は、たとえば取得したＴＳパケットにおける先頭および最後のＴＳパケットの位置を示すバイトオフセット情報を含む対応用テーブルを作成し、作成した対応用テーブルと当該取得したＴＳパケットとをＲＴＰパケット作成部２４へ出力してもよい。また、ストリーム作成部２２は、取得したＴＳパケットをＴＴＳパケットへ変換しなくてもよい。

そして、ストリーム作成部２２は、当該Ｉフレームの次のＩフレームについても同様の処理を行うことにより、次のＩフレームに対応するＴＳパケットを記憶部２３から取得し、取得したＴＳパケットを、上記倍速値に適したタイミングでＲＴＰパケット作成部２４へ出力する。ストリーム作成部２２は、上記処理を後続のＩフレームに対して順次行い、Ｉフレームの画像データを含むＴＳパケットを上記倍速値に適したタイミングでＲＴＰパケット作成部２４へ出力する。

ＲＴＰパケット作成部２４は、分割された基本画像データまたは関連画像データを、複数の分割パケットである複数のＲＴＰパケットに含める。具体的には、ＲＴＰパケット作成部２４は、ストリーム作成部２２から通常再生用のＩフレーム、ＰフレームまたはＢフレームのいずれかの画像データを含むＴＴＳパケットを受けると、受けたＴＴＳパケットをＲＴＰパケットのペイロードに含めることによりＲＴＰパケットを作成する。この際、ＲＴＰパケット作成部２４は、たとえばＲＴＰパケットのペイロードに７個ずつＴＴＳパケットを含め、ＲＴＰパケットヘッダにシーケンス番号をパケット作成順に付与する。そして、ＲＴＰパケット作成部２４は、作成したＲＴＰパケットをＦＥＣパケット作成部２５へ出力する。

また、ＲＴＰパケット作成部２４は、ストリーム作成部２２からトリック再生用のＴＳパケットおよび対応用テーブルを受けると、受けた対応用テーブルに含まれるバイトオフセット情報に基づいて、当該ＴＳパケットおよびＩフレームの対応関係を把握にする。そして、ＲＴＰパケット作成部２４は、当該ＴＳパケットをＩフレーム毎にまとめる。

次に、ＲＴＰパケット作成部２４は、Ｉフレーム毎にまとめられたＴＳパケットをＲＴＰパケットのペイロードに含めることにより、Ｉフレームとの対応関係が明確なＲＴＰパケットを作成する。この際、ＲＴＰパケット作成部２４は、たとえばＲＴＰパケットのペイロードに７個ずつＴＳパケットを含め、ＲＴＰパケットヘッダにシーケンス番号をパケット作成順に付与する。そして、ＲＴＰパケット作成部２４は、作成した複数のＲＴＰパケットすなわち複数の分割パケットをＩフレーム毎にＦＥＣパケット作成部２５へ出力する。

ＦＥＣパケット作成部２５は、ＲＴＰパケット作成部から通常再生用のＲＴＰパケットを受けると、受けたＲＴＰパケットを用いて、たとえば非特許文献１に記載されている技術によりソースブロックを作成する。そして、ＦＥＣパケット作成部２５は、作成したソースブロックの各列に属するＲＴＰパケットに基づいて、所定のＦＥＣパケットを作成する。ＦＥＣパケット作成部２５は、作成したＦＥＣパケットをまとめることにより、ＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、トリック再生用のＲＴＰパケットをＩフレーム毎に受けると、受けたＲＴＰパケットを用いて１または複数のソースブロックをＩフレーム毎に作成する。そして、ＦＥＣパケット作成部２５は、作成した１または複数のソースブロックの各列に属するＲＴＰパケットに基づいて、所定のＦＥＣパケットを作成する。ＦＥＣパケット作成部２５は、作成したＦＥＣパケットをまとめることにより、ＦＥＣ符号化ブロックを作成する。

より詳細には、ＦＥＣパケット作成部２５は、Ｉフレーム毎にまとめられたＲＴＰパケットを受けると、受けたＲＴＰパケットの個数に応じて、たとえばＰｒｏ−ＭＰＥＧ １Ｄ ＦＥＣ方式に用いるＦＥＣ符号化ブロックのサイズを動的に変化させることにより、１つのＩフレームに対して１個のソースブロックおよび１個のＦＥＣ符号化ブロックを作成する。これにより、ＦＥＣパケット作成部２５は、ソースブロックのデータサイズがＩフレーム毎にまとめられたＲＴＰパケットの総データ量となるように調整する。

図７は、本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを動的に変化させる場合におけるソースブロックおよびＦＥＣ符号化ブロックの一例を示す図である。

図７を参照して、具体的には、ＦＥＣパケット作成部２５は、１つのＩフレームの画像データを含むＲＴＰパケットとして、たとえば図７の（Ａ）に示すＲＴＰ０１からＲＴＰ２５までの２５個のＲＴＰパケットをＲＴＰパケット作成部２４から受けると、図７の（Ｂ）に示す５行５列のソースブロックを作成する。

次に、ＦＥＣパケット作成部２５は、たとえば１列目に属するＲＴＰ０１からＲＴＰ２１までの５個のＲＴＰパケットに基づいて、図７の（Ｃ）に示すＦＥＣパケットであるＦＥＣ０１を作成する。そして、ＦＥＣパケット作成部２５は、２列目以降も順次計算を行い、ＦＥＣ０１からＦＥＣ０５までのＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、次の１つのＩフレームの画像データを含むＲＴＰパケットとして、たとえば図７の（Ｄ）に示すＲＴＰ５１からＲＴＰ８６までの３６個のＲＴＰパケットをＲＴＰパケット作成部２４から受けると、図７の（Ｅ）に示す６行６列のソースブロックを作成する。

次に、ＦＥＣパケット作成部２５は、たとえば１列目に属するＲＴＰ５１からＲＴＰ８１までの６個のＲＴＰパケットに基づいて、図７の（Ｆ）に示すＦＥＣパケットであるＦＥＣ５１を作成する。そして、ＦＥＣパケット作成部２５は、２列目以降も順次計算を行い、ＦＥＣ５１からＦＥＣ５６までのＦＥＣ符号化ブロックを作成する。

これにより、ＦＥＣパケット作成部２５は、１つのＩフレームに対して１個のソースブロックおよび１個のＦＥＣ符号化ブロックを作成する。

なお、ＦＥＣパケット作成部２５は、Ｐｒｏ−ＭＰＥＧ １Ｄ ＦＥＣ方式に用いるＦＥＣ符号化ブロックのサイズに上限があり、上限サイズのＦＥＣ符号化ブロックに対応するソースブロックにおいても１つのＩフレームに対応するＲＴＰパケットを収容できない場合、以下の処理を行ってもよい。

すなわち、ＦＥＣパケット作成部２５は、ＦＥＣ符号化ブロックを複数の同じサイズのＦＥＣ符号化ブロックに分割し、分割したＦＥＣ符号化ブロックに対応する複数のソースブロックを作成することにより当該ＲＴＰパケットを収容する。

この際、ＦＥＣパケット作成部２５は、上記複数のソースブロックに収容できない余剰のＲＴＰパケットが生じた場合、余剰のＲＴＰパケットの総データ量に応じて、ソースブロックのデータサイズを調整する。換言すると、ＦＥＣパケット作成部２５は、余剰のＲＴＰパケットが生じた場合、サイズの大きさを調整したＦＥＣ符号化ブロックに対応するソースブロックを作成することにより当該余剰のＲＴＰパケットを収容する。

図８は、本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズに上限がある場合におけるソースブロックおよびＦＥＣ符号化ブロックの一例を示す図である。

図８を参照して、たとえばＦＥＣ符号化ブロックのサイズの上限が４であり、かつ当該ＦＥＣ符号化ブロックに対応するソースブロックのサイズが４行４列である場合を想定する。

ＦＥＣパケット作成部２５は、１つのＩフレームの画像データを含むＲＴＰパケットとして、たとえば図８の（Ａ）に示すＲＴＰ０１からＲＴＰ２５までの２５個のＲＴＰパケットをＲＴＰパケット作成部２４から受けると、図８の（Ｂ）に示す４行４列のソースブロックを作成し、当該ソースブロックにおいてＲＴＰ０１からＲＴＰ１６までの１６個のＲＴＰパケットを収容する。

次に、ＦＥＣパケット作成部２５は、図８の（Ｂ）に示すソースブロックの１列目に属するＲＴＰ０１からＲＴＰ１３までの４個のＲＴＰパケットに基づいて、図８の（Ｄ）に示すＦＥＣパケットであるＦＥＣ１１を作成する。そして、ＦＥＣパケット作成部２５は、２列目以降も順次計算を行い、ＦＥＣ１１からＦＥＣ１４までのＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、図８の（Ｂ）に示すソースブロックに収容できなかったＲＴＰ１７からＲＴＰ２５までの９個のＲＴＰパケットを収容するために、ＦＥＣ符号化ブロックのサイズを３に変更することにより、上記９個のＲＴＰパケットを収容する。

すなわち、ＦＥＣパケット作成部２５は、図８の（Ｃ）に示す３行３列のソースブロックを作成し、当該ソースブロックにおいてＲＴＰ１７からＲＴＰ２５までの９個のＲＴＰパケットを収容する。

次に、ＦＥＣパケット作成部２５は、図８の（Ｃ）に示すソースブロックの１列目に属するＲＴＰ１７からＲＴＰ２３までの３個のＲＴＰパケットに基づいて、図８の（Ｅ）に示すＦＥＣパケットであるＦＥＣ１５を作成する。そして、ＦＥＣパケット作成部２５は、２列目以降も順次計算を行い、ＦＥＣ１５からＦＥＣ１７までのＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、次の１つのＩフレームの画像データを含むＲＴＰパケットとして、たとえば図８の（Ｆ）に示すＲＴＰ５１からＲＴＰ８６までの３６個のＲＴＰパケットをＲＴＰパケット作成部２４から受けると、図８の（Ｇ）および（Ｈ）に示す４行４列のソースブロックを２個作成し、当該２個のソースブロックにおいてＲＴＰ５１からＲＴＰ８２までの３２個のＲＴＰパケットを収容する。

次に、ＦＥＣパケット作成部２５は、図８の（Ｇ）に示すソースブロックの１列目に属するＲＴＰ５１からＲＴＰ６３までの４個のＲＴＰパケットに基づいて、図８の（Ｊ）に示すＦＥＣパケットであるＦＥＣ６１を作成する。そして、ＦＥＣパケット作成部２５は、２列目以降も順次計算を行い、ＦＥＣ６１からＦＥＣ６４までのＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、たとえば図８の（Ｈ）に示すソースブロックについても同様の処理を行い、図８の（Ｋ）に示すＦＥＣ６５からＦＥＣ６８までのＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、図８の（Ｇ）および（Ｈ）に示すソースブロックに収容できなかったＲＴＰ８３からＲＴＰ８６までの４個のＲＴＰパケットを収容するために、ＦＥＣ符号化ブロックのサイズを２に変更することにより、上記４個のＲＴＰパケットを収容する。

すなわち、ＦＥＣパケット作成部２５は、図８の（Ｉ）に示す２行２列のソースブロックを作成し、当該ソースブロックにおいてＲＴＰ８３からＲＴＰ８６までの４個のＲＴＰパケットを収容する。

次に、ＦＥＣパケット作成部２５は、図８の（Ｉ）に示すソースブロックの１列目に属するＲＴＰ８３およびＲＴＰ８５の２個のＲＴＰパケットに基づいて、図８の（Ｌ）に示すＦＥＣパケットであるＦＥＣ６９を作成する。そして、ＦＥＣパケット作成部２５は、２列目も同様に計算を行い、ＦＥＣ６９およびＦＥＣ７０のＦＥＣ符号化ブロックを作成する。

これにより、ＦＥＣパケット作成部２５は、ＦＥＣ符号化ブロックのサイズに上限がある場合における、１つのＩフレームに対応するソースブロックおよびＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、Ｐｒｏ−ＭＰＥＧ １Ｄ ＦＥＣ方式に用いるＦＥＣ符号化ブロックのサイズが固定され、また、上記ＦＥＣ符号化ブロックに対応してソースブロックのサイズも固定されている場合において、以下の処理を行ってもよい。すなわち、ＦＥＣパケット作成部２５は、１つのＩフレームに対応するＲＴＰパケットを受けると、受けたＲＴＰパケットの総データ量が上記ソースブロックのデータサイズに満たないときには、受けたＲＴＰパケットに加えて、ヌルデータを含むヌルパケットをパディングしたＲＴＰパケットを当該ソースブロックに含める。

換言すると、ＦＥＣパケット作成部２５は、１つのＩフレームに対応するＲＴＰパケットを受けると、受けたＲＴＰパケットの個数が上記ソースブロックのサイズに満たないときには、受けたＲＴＰパケットに加えて、ヌルパケットをパディングしたＲＴＰパケットを当該ソースブロックに含める。

図９は、本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを変更できない場合におけるソースブロックおよびＦＥＣ符号化ブロックの一例を示す図である。

図９を参照して、非特許文献１に記載されているように、ＦＥＣ符号化ブロックのサイズが１０に固定され、かつ当該ＦＥＣ符号化ブロックに対応するソースブロックのサイズが１０行１０列に固定されている場合を想定する。

ＦＥＣパケット作成部２５は、１つのＩフレームの画像データを含むＲＴＰパケットとして、たとえば図９の（Ａ）に示すＲＴＰ０１からＲＴＰ２５までの２５個のＲＴＰパケットをＲＴＰパケット作成部２４から受けると、図９の（Ｂ）に示す１０行１０列のソースブロックを作成し、当該ソースブロックにおいてＲＴＰ０１からＲＴＰ２５までの２５個のＲＴＰパケットを収容する。

この際、上記２５個のＲＴＰパケットをソースブロックに収容しても、当該ソースブロックに収容できる個数である１００には満たない。このため、ＦＥＣパケット作成部２５は、図９の（Ｂ）においてＮＵＬＬで示す、ヌルパケットをパディングしたＲＴＰパケットを７５個作成し、作成した７５個のＲＴＰパケットを当該ソースブロックに含める。

次に、ＦＥＣパケット作成部２５は、図９の（Ｂ）に示すソースブロックの１列目に属するＲＴＰ０１からＲＴＰ２１までの３個のＲＴＰパケットおよびヌルパケットをパディングした７個のＲＴＰパケットに基づいて、図９の（Ｃ）に示すＦＥＣパケットであるＦＥＣ２１を作成する。そして、ＦＥＣパケット作成部２５は、２列目以降も順次計算を行い、ＦＥＣ２１からＦＥＣ３０までのＦＥＣ符号化ブロックを作成する。

また、ＦＥＣパケット作成部２５は、次の１つのＩフレームの画像データを含むＲＴＰパケットとして、たとえば図９の（Ｄ）に示すＲＴＰ５１からＲＴＰ８６までの３６個のＲＴＰパケットをＲＴＰパケット作成部２４から受けると、図９の（Ｅ）に示す１０行１０列のソースブロックを作成し、当該ソースブロックにおいてＲＴＰ５１からＲＴＰ８６までの３６個のＲＴＰパケットを収容する。

この際、上記３６個のＲＴＰパケットをソースブロックに収容しても、当該ソースブロックに収容できる個数である１００には満たない。このため、ＦＥＣパケット作成部２５は、図９の（Ｅ）においてＮＵＬＬで示す、ヌルパケットをパディングしたＲＴＰパケットを６４個作成し、作成した６４個のＲＴＰパケットを当該ソースブロックに含める。

次に、ＦＥＣパケット作成部２５は、図９の（Ｅ）に示すソースブロックの１列目に属するＲＴＰ５１からＲＴＰ８１までの４個のＲＴＰパケットおよびヌルパケットをパディングした６個のＲＴＰパケットに基づいて、図９の（Ｆ）に示すＦＥＣパケットであるＦＥＣ７１を作成する。そして、ＦＥＣパケット作成部２５は、２列目以降も順次計算を行い、ＦＥＣ７１からＦＥＣ８０までのＦＥＣ符号化ブロックを作成する。

これにより、ＦＥＣパケット作成部２５は、ＦＥＣ符号化ブロックのサイズが固定されている場合における、１つのＩフレームに対応するソースブロックおよびＦＥＣ符号化ブロックを作成する。

そして、ＦＥＣパケット作成部２５は、作成したＦＥＣ符号化ブロックに含まれるＦＥＣパケットおよびソースブロックに含まれるＲＴＰパケットを、通信部２６を介してたとえば番組受信装置４０へ送信する。

［配信装置におけるトリック再生処理動作］
配信装置２０は、以下に示す各フローチャートの各ステップを図示しないメモリから読み出して実行する。このプログラムは、外部からインストールすることができる。このインストールされるプログラムは、たとえば記録媒体に格納された状態で流通する。

図１０は、本発明の実施の形態に係る配信装置におけるトリック再生処理を行う際の動作手順の一例を定めたフローチャートである。

図１０を参照して、まず、配信装置２０は、選択された番組の、ある倍速値での早送り再生または巻き戻し再生等のトリック再生の要求を番組受信装置４０から受信する。

次に、配信装置２０は、たとえば早送り再生を行う場合、選択された番組のストリームに含まれるＴＳパケットにおいて、トリック再生を開始する位置から後方へ直近のＩフレームを探索する。次に、配信装置２０は、Ｉフレームの画像データの開始位置を含むＴＳパケットおよび当該画像データの終了位置を含むＴＳパケットを特定する（ステップＳ１０２）。上記開始位置および上記終了位置の検出処理については後述する。

次に、配信装置２０は、上記開始位置を含むＴＳパケットから上記終了位置を含むＴＳパケットまでのＴＳパケットを複数のＲＴＰパケットに収容する（ステップＳ１０４）。

次に、配信装置２０は、上記複数のＲＴＰパケットに基づいて、Ｉフレーム毎にソースブロックを作成する（ステップＳ１０６）。ソースブロックの作成処理については後述する。

次に、配信装置２０は、上記ソースブロックに対応するＦＥＣ符号化ブロックを作成する（ステップＳ１０８）。ソースブロックに対応するＦＥＣ符号化ブロックの作成処理については後述する。

次に、配信装置２０は、上記ソースブロックに含まれる複数のＲＴＰパケット、および上記ＦＥＣ符号化ブロックに含まれる複数のＦＥＣパケットを、たとえば異なるポート番号を用いることにより、別々のストリームで番組受信装置４０へ送信する（ステップＳ１１０）。

次に、配信装置２０は、トリック再生を継続する場合（ステップＳ１１２でＹＥＳ）、ステップＳ１０２において特定したＩフレームの、次のＩフレームを探索する。

また、配信装置２０は、トリック再生を継続しない場合（ステップＳ１１２でＮＯ）、トリック再生処理動作を終了する。

以上の動作により、配信装置２０における、ＩフレームＴＳ方式によるトリック再生処理が行われる。

なお、配信装置２０は、上記処理において早送り再生を行ったが、巻き戻し再生を行ってもよい。巻き戻し再生の場合、ストリーム作成部２２は、上記ステップＳ１０２において、トリック再生を開始する位置から前方へ直近のＩフレームを探索する。

そして、配信装置２０は、上記ステップＳ１１２においてトリック再生を継続する場合、ステップＳ１０２において特定したＩフレームの、前のＩフレームを探索する。これにより、配信装置２０は、選択された番組の巻き戻し再生を行うことができる。

［Ｉフレームの画像データの開始位置および終了位置の検出動作］
図１１は、本発明の実施の形態に係る配信装置におけるＩフレームの検出処理を行う際の動作手順の一例を定めたフローチャートである。

図１１を参照して、まず、ストリーム作成部２２は、たとえば早送り再生を行う場合、選択された番組のストリームに含まれるＴＳパケットにおいて、トリック再生を開始する位置から後方へ直近のＩフレームを探索する。また、ストリーム作成部２２は、たとえば巻き戻し再生を行う場合、選択された番組のストリームに含まれるＴＳパケットにおいて、トリック再生を開始する位置から前方へ直近のＩフレームを探索する。

次に、ストリーム作成部２２は、ＰＩＤが０ｘ００００であるＰＡＴパケットを探索し、探索したＰＡＴパケットにおいて選択された番組のＰＭＴパケットのＰＩＤを取得する。次に、ストリーム作成部２２は、取得したＰＩＤに基づいてＰＭＴパケットを特定し、特定したＰＭＴパケットを解析する（ステップＳ１５２）。

次に、ストリーム作成部２２は、ＰＭＴパケットを解析することにより、選択された番組の画像を含むビデオＴＳパケットのＰＩＤを取得する（ステップＳ１５４）。

次に、ストリーム作成部２２は、たとえばＰＭＴパケットにおけるstream_typeに基づいて、ストリームに含まれる番組の画像のエンコード種別を取得する（ステップＳ１５６）。

次に、ストリーム作成部２２は、上記エンコード種別がＭＰＥＧ２である場合（ステップＳ１５８でＹＥＳ）、スタートコードプレフィックスである０ｘ０００００１に、picture_start_codeを示す０ｘ００を付加したスタートコードのビット列を、ストリームにおいて探索することによりフレームの開始位置を取得する（ステップＳ１６０）。

次に、ストリーム作成部２２は、上記フレームに対応するスタートコードの最上位ビットから４２ビット目から４４ビット目までの３ビットに含まれるpicture_coding_typeを参照する。picture_coding_typeのビット列が００１の場合、上記フレームに含まれる画像はＩピクチャとなるので、上記フレームはＩフレームとなる。次に、ストリーム作成部２２は、参照したpicture_coding_typeのビット列が００１の場合、上記フレームの開始位置を記録する（ステップＳ１６２）。

次に、ストリーム作成部２２は、上記開始位置から更に後方へスタートコードのビット列を探索することにより、上記フレームの次のフレームの開始位置を取得し、当該次のフレームの開始位置の直前を、上記フレームの終端位置として記録する（ステップＳ１６４）。

一方、ストリーム作成部２２は、上記エンコード種別がＨ．２６４／ＡＶＣである場合（ステップＳ１５８でＮＯ）、スタートコードプレフィックスである０ｘ０００００１のビット列をストリームにおいて探索する（ステップＳ１６６）。

次に、ストリーム作成部２２は、スタートコードプレフィックスに続くＮＡＬ（Network Abstraction Layer）ユニットがＡＵ（Access Unit）デリミタであるＮＡＬユニットを探索する（ステップＳ１６８）。

次に、ストリーム作成部２２は、ＡＵデリミタを検出すると、検出したＡＵデリミタに含まれるprimary_pic_typeを参照し、参照したprimary_pic_typeが００ｂである場合、当該ＡＵデリミタに続くＮＡＬユニットに含まれる画像はＩスライスであるので、当該ＡＵデリミタの位置をＩフレームの開始位置として記録する（ステップＳ１７０）。

次に、ストリーム作成部２２は、上記Ｉフレームの開始位置から更に後方へスタートコードプレフィックスおよびＡＵデリミタを探索することにより、上記Ｉフレームの次のフレームの開始位置を取得し、当該次のフレームの開始位置の直前を、上記Ｉフレームの終端位置として記録する（ステップＳ１７２）。

以上の動作により、ストリーム作成部２２は、Ｉフレームの開始位置および終端位置に基づいて、当該Ｉフレームを含むＴＳパケットを特定する。

［ＦＥＣ符号化ブロックのサイズを動的に変化させる場合］
図１２は、本発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを動的に変化させる場合におけるＦＥＣ符号化ブロックおよびソースブロックを作成する際の動作手順の一例を定めたフローチャートである。

図１２を参照して、まず、ＦＥＣパケット作成部２５は、ＲＴＰパケット作成部２４から１つのＩフレームに対応する複数のＲＴＰパケットを受ける。

次に、ＦＥＣパケット作成部２５は、ＲＴＰパケット作成部２４から受けたＲＴＰパケットの個数をカウントする（ステップＳ２０２）。

次に、ＦＥＣパケット作成部２５は、カウントしたＲＴＰパケットの個数に応じて、ＦＥＣ符号化ブロックのサイズを決定する（ステップＳ２０４）。

次に、ＦＥＣパケット作成部２５は、決定したＦＥＣ符号化ブロックのサイズに応じたソースブロックを作成し、作成したソースブロックに上記ＲＴＰパケットを収容する（ステップＳ２０６）。

次に、ＦＥＣパケット作成部２５は、作成したソースブロックの各列に含まれるＲＴＰパケットに基づいて、ＦＥＣパケットを作成する（ステップＳ２０８）。

次に、ＦＥＣパケット作成部２５は、作成したＦＥＣパケットに基づいてＦＥＣ符号化ブロックを作成する（ステップＳ２１０）。

以上の動作により、１つのＩフレームに対応する複数のＲＴＰパケットを１個のソースブロックに含め、当該ソースブロックに対応する１個のＦＥＣ符号化ブロックを作成する処理が行われる。

［ＦＥＣ符号化ブロックのサイズに上限がある場合］
図１３は、発明の実施の形態に係るＦＥＣ符号化ブロックのサイズに上限がある場合におけるＦＥＣ符号化ブロックおよびソースブロックを作成する際の動作手順の一例を定めたフローチャートである。

図１３を参照して、まず、ＦＥＣパケット作成部２５は、ＲＴＰパケット作成部２４から１つのＩフレームに対応する複数のＲＴＰパケットを受ける。

次に、ＦＥＣパケット作成部２５は、ＲＴＰパケット作成部２４から受けたＲＴＰパケットの個数をカウントする（ステップＳ３０２）。

次に、ＦＥＣパケット作成部２５は、カウントしたＲＴＰパケットの個数がＦＥＣ符号化ブロックの上限サイズに対応するソースブロックにおいても収容できない場合（ステップＳ３０４でＹＥＳ）、複数の等サイズのＦＥＣ符号化ブロックに対応するソースブロックにおいて、上記ＲＴＰパケットを収容するために必要なＦＥＣ符号化ブロックのサイズおよび個数を決定する（ステップＳ３０６）。

この際、上記ＦＥＣ符号化ブロックのサイズおよび個数が限定されることはないが、以下のように設定される場合が好ましい。すなわち、カウントしたＲＴＰパケットの個数から、上記サイズのＦＥＣ符号化ブロックに対応するソースブロックに収容できるＲＴＰパケットの個数に、ＦＥＣ符号化ブロックの上記個数を乗じた値を差し引いた値が、上記ソースブロックに収容できるＲＴＰパケットの個数を超えない。

次に、ＦＥＣパケット作成部２５は、上記サイズおよび上記個数のＦＥＣ符号化ブロックに対応するソースブロックにおいて、ＲＴＰパケットが完全に収容されない場合、上記サイズを余剰のＲＴＰパケットに対応できるサイズへ変更する（ステップＳ３０８）。

一方、ＦＥＣパケット作成部２５は、カウントしたＲＴＰパケットの個数がＦＥＣ符号化ブロックの上限サイズに対応するソースブロックにおいて収容できる場合（ステップＳ３０４でＮＯ）、カウントしたＲＴＰパケットの個数に応じてＦＥＣ符号化ブロックのサイズを決定する（ステップＳ３１０）。

次に、ＦＥＣパケット作成部２５は、決定したＦＥＣ符号化ブロックのサイズおよび個数に応じたソースブロックを作成し、作成したソースブロックにＲＴＰパケットを収容する（ステップＳ３１２）。

次に、ＦＥＣパケット作成部２５は、作成したソースブロックの各列に含まれるＲＴＰパケットに基づいて、ＦＥＣパケットを作成する（ステップＳ３１４）。

次に、ＦＥＣパケット作成部２５は、作成したＦＥＣパケットに基づいてＦＥＣ符号化ブロックを作成する（ステップＳ３１６）。

以上の動作により、１つのＩフレームに対応する複数のＲＴＰパケットを等サイズのソースブロックおよび変更したサイズのソースブロックに含め、当該ソースブロックに対応するＦＥＣ符号化ブロックを作成する処理が行われる。

［ＦＥＣ符号化ブロックのサイズが固定されている場合］
図１４は、発明の実施の形態に係るＦＥＣ符号化ブロックのサイズを変更できない場合におけるＦＥＣ符号化ブロックおよびソースブロックを作成する際の動作手順の一例を定めたフローチャートである。

図１４を参照して、まず、ＦＥＣパケット作成部２５は、ＲＴＰパケット作成部２４から１つのＩフレームに対応する複数のＲＴＰパケットを受ける。

次に、ＦＥＣパケット作成部２５は、ＦＥＣ符号化ブロックのサイズに応じたソースブロックを作成し、作成したソースブロックにＲＴＰパケットを収容する（ステップＳ４０２）。

次に、ＦＥＣパケット作成部２５は、ＲＴＰパケット作成部２４から受けたＲＴＰパケットの個数が上記ソースブロックに収容できる個数に満たない場合、ヌルパケットをパディングしたＲＴＰパケットを当該ソースブロックに含めることにより、上記ソースブロックを完全に埋める（ステップＳ４０４）。

次に、ＦＥＣパケット作成部２５は、作成したソースブロックの各列に含まれるＲＴＰパケットに基づいて、ＦＥＣパケットを作成する（ステップＳ４０６）。

次に、ＦＥＣパケット作成部２５は、作成したＦＥＣパケットに基づいてＦＥＣ符号化ブロックを作成する（ステップＳ４０８）。

以上の動作により、必要に応じてヌルパケットをパディングしたＲＴＰパケットと共に、１つのＩフレームに対応する複数のＲＴＰパケットを固定されたサイズのソースブロックに含め、当該ソースブロックに対応するＦＥＣ符号化ブロックを作成する処理が行われる。

このような構成により、非特許文献１に記載されている仕様に適応させた上で、１個のソースブロックにおいて、２つ以上のＩフレームの画像データが含まれることを防ぐことができる。これにより、番組受信装置４０は、非特許文献１に記載されている仕様通りに運用することにより、上記ソースブロックに含まれるＲＴＰパケットおよび上記ソースブロックに対応するＦＥＣ符号化ブロックに含まれるＦＥＣパケットに基づいて、上記ＲＴＰパケットの復元処理を行った後、１つのＩフレームを作成することができる。

ところで、配信装置２０は、ＩフレームＴＳ方式によりトリック再生に対応する番組の情報を送信する場合、当該番組の情報を適切なタイミングでデコードするためのタイミング情報を送信せずに、指定された倍速値でのトリック再生が受信側の装置において可能となるような時間間隔で、番組の情報を受信側の装置へ送信する。受信側の装置は、配信装置２０から番組の情報を受信したタイミングで、当該番組の情報をデコードすることにより、当該倍速値でのトリック再生を実現する。

しかしながら、トリック再生時において、受信側の装置が受信したパケットのＦＥＣを用いた復元処理を行うと、以下の問題が発生する場合がある。すなわち、受信側の装置は、復元処理が完了するまで受信したパケットをデコードすることができないので、配信装置２０から受信したパケットに含まれる番組の情報をデコードするタイミングは、復元処理のタイミングにより遅れてしまう場合がある。

すなわち、受信側の装置は、受信したパケットに含まれる番組の情報を、当該パケットを受信したタイミングでデコードすることができない。このため、配信装置２０が、指定された倍速値でのトリック再生が受信側の装置において可能となるような時間間隔で番組の情報を送信しても、受信側の装置では、番組の情報を当該時間間隔で再生することができなくなってしまう。

これに対して、本発明の実施の形態に係る画像データ送信装置では、ＦＥＣパケット作成部２５は、送信すべきＩフレームの画像データと、ＰフレームまたはＢフレームの画像データとが分割された、複数のＲＴＰパケットをソースブロックとしてまとめる。そして、ＦＥＣパケット作成部２５は、番組受信装置４０において上記ソースブロックを復元するためのＦＥＣパケットを、上記ソースブロックに基づいて作成する。ＦＥＣパケット作成部２５は、Ｉフレームの画像データを選択的に送信する場合には、１つのソースブロックに含めるＩフレームの画像データのＲＴＰパケットを、１つのＩフレームの画像データに対応するＲＴＰパケットに制限する。

このような構成により、１つのソースブロックに含められるＩフレームの画像データのＲＴＰパケットが１つのＩフレームの画像データに対応するので、１つのソースブロックにおいて２つ以上のＩフレームの画像データが含まれることによる処理の遅延を防ぐことができる。

これにより、再生するためのタイミング情報が配信装置２０により送信されない場合においても、指定された倍速値でのトリック再生が可能となるような時間間隔でＩフレームの画像データを送信することにより、番組受信装置４０では、上記Ｉフレームの画像データを当該時間間隔で再生することができる。

また、本発明の実施の形態に係る画像データ送信装置では、ＦＥＣパケット作成部２５は、Ｉフレームの画像データを選択的に送信する場合には、１つのソースブロックとなる複数のＲＴＰパケットが、１つのＩフレームの画像データに対応する複数のＲＴＰパケットになるように、ソースブロックのデータサイズを調整する。

このような構成により、１つのＩフレームの画像データに対して、１つのソースブロックを対応させることができる。これにより、１つのソースブロックにおいて、たとえばヌルパケットのような余分なデータが含まれないので、余分なデータの処理による負担の増加、およびネットワーク１１におけるＲＴＰパケットの送信に必要な帯域の増大を防ぐことができる。

また、番組受信装置４０は、上記Ｉフレームを作成する際に、前に受信したソースブロックまたは次に受信するソースブロックを参照する必要がないので、Ｉフレームの作成処理を簡素化することができる。

また、本発明の実施の形態に係る画像データ送信装置では、ソースブロックのデータサイズが固定値に設定され、ＦＥＣパケット作成部２５は、Ｉフレームの画像データを選択的に送信する場合であって、１つの前記Ｉフレームの画像データに対応するＲＴＰパケットの総データ量が上記固定値に満たないときには、ＲＴＰパケット、およびヌルデータを含むパケットをソースブロックとしてまとめる。

このような構成により、Ｉフレームの画像データに対応するＲＴＰパケットの総データ量毎にソースブロックのデータサイズを変更する必要がないので、配信装置２０におけるソースブロックの作成処理を簡素化することができる。

また、番組受信装置４０は、一定のデータサイズのソースブロックを取り扱う。これにより、番組受信装置４０は、受信する度に上記ソースブロックのデータサイズを取得し、取得したデータサイズに応じて処理のアルゴリズムを変更する必要がない。すなわち、番組受信装置４０は、所定のデータサイズに対応した所定の処理を用意するだけでよいので、処理のアルゴリズムを簡素化することができる。

また、本発明の実施の形態に係る画像データ送信装置では、ＦＥＣパケット作成部２５は、１つのＩフレームの画像データに対応するＲＴＰパケットの総データ量がソースブロックの最大データサイズを超える場合には、１つのＩフレームの画像データに対応するＲＴＰパケットを１または複数のソースブロックに含め、余ったＲＴＰパケットを含めるソースブロックのデータサイズを、余ったＲＴＰパケットの総データ量に応じて調整する。

このような構成により、ソースブロックにデータサイズの上限がある場合においても、１つのＩフレームの画像データを１または複数のソースブロックに収容することができる。

また、余ったＲＴＰパケットを含めるソースブロックのデータサイズを、余ったＲＴＰパケットの総データ量に応じて調整するので、たとえばヌルパケットのような余分なパケットを含める必要がない。これにより、たとえばネットワーク１１において画像データの送信に使用される帯域が、余分なパケットを送信することにより増加してしまうことを防ぐことができる。

また、たとえばヌルパケットのような余分なパケットがソースブロックに含まれないので、番組受信装置４０は、たとえば復元処理において、余分なパケットを処理することによる負担の増加を防ぐことができる。

また、本発明の実施の形態に係る画像データ送信装置では、基本画像データはＩフレーム（Intra-coded Frame）の画像データであり、前記関連画像データはＰフレーム（Predicted Frame）またはＢフレーム（Bi-directional Predicted Frame）の画像データであり、配信装置２０は、Ｉフレームの画像データを選択的に送信することにより、Ｉフレームの画像データの受信側の装置においてトリック再生を可能とする。

このような構成により、番組受信装置４０は、配信装置２０から受信したＩフレームの画像データに基づいてトリック再生に用いるＩフレームを作成する際、作成したＩフレームの表示時間が長くなったり、短くなったりすることなく、トリック再生を行うことができる。すなわち、番組受信装置４０は、ＩフレームＴＳ方式に従ったトリック再生を、指定した倍速値で行うことができる。

なお、本発明の実施の形態に係る画像データ送信装置は、ＭＰＥＧ２−ＴＳ規格に従うストリームの処理を行なう構成であるとしたが、これに限定するものではない。他の規格に従うストリームの処理を行なう構成であってもよい。

上記実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記説明ではなく特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１０ 番組配信システム
１１ ネットワーク
１２ 表示装置
２０ 配信装置（画像データ送信装置）
２１ 番組配信制御部
２２ ストリーム作成部
２３ 記憶部
２４ ＲＴＰパケット作成部
２５ ＦＥＣパケット作成部（ソースブロック作成部および復元用パケット作成部）
２６ 通信部
４０ 番組受信装置

Claims (7)

1. 基本画像を示す基本画像データ、および前記基本画像データを参照することにより作成される関連画像データを送信するための画像データ送信装置であって、
   送信すべき前記基本画像データおよび前記関連画像データが分割された、複数の分割パケットをソースブロックとしてまとめるためのソースブロック作成部と、
   前記基本画像データおよび前記関連画像データの受信側の装置において前記ソースブロックを復元するための復元用パケットを、前記ソースブロックに基づいて作成するための復元用パケット作成部とを備え、
   前記ソースブロック作成部は、前記基本画像データを選択的に送信する場合には、１つの前記ソースブロックに含める前記基本画像データの前記分割パケットを、１つの前記基本画像データに対応する前記分割パケットに制限する、画像データ送信装置。
2. 前記ソースブロック作成部は、前記基本画像データを選択的に送信する場合には、１つの前記ソースブロックとなる前記分割パケットが、１つの前記基本画像データに対応する前記分割パケットになるように、前記ソースブロックのデータサイズを調整する、請求項１に記載の画像データ送信装置。
3. 前記ソースブロックのデータサイズが固定値に設定され、
   前記ソースブロック作成部は、前記基本画像データを選択的に送信する場合であって、１つの前記基本画像データに対応する前記分割パケットの総データ量が前記固定値に満たないときには、前記分割パケット、およびヌルデータを含むパケットを前記ソースブロックとしてまとめる、請求項１に記載の画像データ送信装置。
4. 前記ソースブロック作成部は、１つの前記基本画像データに対応する前記分割パケットの総データ量が前記ソースブロックの最大データサイズを超える場合には、１つの前記基本画像データに対応する前記分割パケットを１または複数の前記ソースブロックに含め、余った前記分割パケットを含める前記ソースブロックのデータサイズを、余った前記分割パケットの総データ量に応じて調整する、請求項２または請求項３に記載の画像データ送信装置。
5. 前記基本画像データはＩフレーム（Intra-coded Frame）の画像データであり、前記関連画像データはＰフレーム（Predicted Frame）またはＢフレーム（Bi-directional Predicted Frame）の画像データであり、
   前記画像データ送信装置は、前記基本画像データを選択的に送信することにより、前記基本画像データの受信側の装置においてトリック再生を可能とする、請求項１から請求項４のいずれか１項に記載の画像データ送信装置。
6. 基本画像を示す基本画像データ、および前記基本画像データを参照することにより作成される関連画像データを送信するための画像データ送信装置における画像データ送信方法であって、
   送信すべき前記基本画像データおよび前記関連画像データが分割された、複数の分割パケットをソースブロックとしてまとめるステップと、
   前記基本画像データおよび前記関連画像データの受信側の装置において前記ソースブロックを復元するための復元用パケットを、前記ソースブロックに基づいて作成するステップとを含み、
   前記ソースブロックとしてまとめるステップにおいては、前記基本画像データを選択的に送信する場合には、１つの前記ソースブロックに含める前記基本画像データの前記分割パケットを、１つの前記基本画像データに対応する前記分割パケットに制限する、画像データ送信方法。
7. 基本画像を示す基本画像データ、および前記基本画像データを参照することにより作成される関連画像データを送信するための画像データ送信装置において用いられる画像データ送信プログラムであって、
   コンピュータに、
   送信すべき前記基本画像データおよび前記関連画像データが分割された、複数の分割パケットをソースブロックとしてまとめるステップと、
   前記基本画像データおよび前記関連画像データの受信側の装置において前記ソースブロックを復元するための復元用パケットを、前記ソースブロックに基づいて作成するステップとを実行させるためのプログラムであり、
   前記ソースブロックとしてまとめるステップにおいては、前記基本画像データを選択的に送信する場合には、１つの前記ソースブロックに含める前記基本画像データの前記分割パケットを、１つの前記基本画像データに対応する前記分割パケットに制限する、画像データ送信プログラム。
   
   
   
   

Images