(57)【特許請求の範囲】
【請求項１】
メディアデータのビットストリームを分割するデータ分割手段と、上記データ分割手段により分割されたビットストリームを順番に各パケットのペイロードに挿入するとともに、そのメディアデータの復号パラメータを特定する識別情報を各パケットのペイロードに挿入するパケット構築手段と、上記パケット構築手段によりビットストリームと識別情報が挿入された各パケットを配信するパケット配信手段とを備えたメディア配信装置。
【請求項２】
メディア配信装置から配信された各パケットを受信するパケット受信手段と、識別情報と復号パラメータの対応関係が記録されているテーブルを格納するテーブル格納手段と、上記パケット受信手段により受信された何れかのパケットのペイロードから識別情報を抽出し、上記テーブル格納手段に格納されているテーブルを参照して、その識別情報に対応する復号パラメータを特定する復号パラメータ特定手段と、上記パケット受信手段により受信された各パケットのペイロードからビットストリームを抽出し、上記復号パラメータ特定手段により特定された復号パラメータを使用して、各ビットストリームからメディアデータを復元するメディアデータ復元手段とを備えたメディア受信装置。
【請求項３】
メディアデータのビットストリームを分割し、分割後のビットストリームを順番に各パケットのペイロードに挿入するとともに、そのメディアデータの復号パラメータを特定する識別情報を各パケットのペイロードに挿入して、各パケットを配信するメディア配信装置と、予め識別情報と復号パラメータの対応関係が記録されているテーブルを格納し、上記メディア配信装置から配信された各パケットを受信すると、何れかのパケットのペイロードから識別情報を抽出し、上記テーブルを参照して、その識別情報に対応する復号パラメータを特定する一方、各パケットのペイロードからビットストリームを抽出し、その復号パラメータを使用して、各ビットストリームからメディアデータを復元するメディア受信装置とを備えたメディア伝送システム。
【請求項４】
メディア受信装置は、メディア配信装置からテーブルの更新情報を受信すると、その更新情報にしたがってテーブルを更新することを特徴とする請求項３記載のメディア伝送システム。
【請求項５】
メディア受信装置は、メディア配信装置から特定の識別情報と復号パラメータを受信すると、テーブルを参照することなく、その復号パラメータを使用して、各ビットストリームからメディアデータを復元することを特徴とする請求項３記載のメディア伝送システム。
【請求項６】
メディア受信装置は、メディア配信装置から復号パラメータの差分情報を受信すると、テーブルに記録されている復号パラメータと当該差分情報を使用して、各ビットストリームからメディアデータを復元することを特徴とする請求項３記載のメディア伝送システム。
【請求項７】
メディア受信装置は、メディア配信装置から配信されたパケットのうち、一部のパケットの受信に失敗すると、正しく受信したパケットのペイロードからビットストリームを抽出してメディアデータを復元することを特徴とする請求項３記載のメディア伝送システム。
【請求項８】
メディア受信装置は、先頭のビットストリームから最後尾のビットストリームまでを結合する際、受信に失敗したパケットがあれば、先頭のビットストリームから、受信に失敗したパケットの直前のパケットのペイロードに挿入されているビットストリームまでを結合することを特徴とする請求項７記載のメディア伝送システム。
【請求項９】
メディア受信装置は、先頭のビットストリームから最後尾のビットストリームまでを結合する際、受信に失敗したパケットがあれば、受信に失敗したパケットに挿入されているビットストリームの代わりにヌルデータを結合することを特徴とする請求項７記載のメディア伝送システム。
【請求項１０】
メディア受信装置は、予め設定されている固定個数だけヌルデータを結合することを特徴とする請求項９記載のメディア伝送システム。
【請求項１１】
メディア受信装置は、正しく受信したパケットのペイロードの記述内容を参照して、ビットストリームの代わりに結合するヌルデータの個数を計算し、その個数だけヌルデータを結合することを特徴とする請求項９記載のメディア伝送システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、メディアデータをパケット化して配信するメディア配信装置と、メディア配信装置から配信されるメディアデータを受信するメディア受信装置と、メディア配信装置とメディア受信装置からなるメディア伝送システムとに関するものである。
【背景技術】
【０００２】
品質の悪いネットワークにおいて、ＪＰＥＧ２０００（ＩＴＵ−Ｔ  Ｔ．８００／ＩＳＯ／ＩＥＣ  １５４４４−１）のデータ伝送を出来る限り、効率良く行うことを目的とする場合、ＪＰＥＧ２０００のデータにおいて、最重要なメインヘッダを出来る限り落とさないようにする必要がある。
メインヘッダの伝送に失敗すると、他のすべてのデータを正しく受信することができても、ＪＰＥＧ２０００のデータから画像を一切復号することができなくなるからである。【０００３】
従来のメディア伝送システムは、メインヘッダの欠落を出来る限り防止するため、次のような工夫を施している。
メディア伝送システムのメディア配信装置は、メインヘッダを先頭のＲＴＰ（ＩＥＴＦ  ＲＦＣ３５５０）パケットに挿入するとともに、メディアデータのビットストリームを分割して、後続のＲＴＰパケットにそれぞれ挿入する。【０００４】
また、メディア配信装置は、すべてのＲＴＰパケットに対してメインヘッダフラグを記述する。
ただし、メインヘッダフラグのフラグ値は、“０”〜“１５”の値であり（４ビットで表現される値）、分割元が同じビットストリームのＲＴＰパケットには、同じ値のフラグ値が記述される。また、フラグ値はメインヘッダが更新される度にインクリメントされる。【０００５】
メディア伝送システムのメディア受信装置は、メディア配信装置からメインヘッダが挿入されているＲＴＰパケットを受信すると、そのＲＴＰパケットに記述されているメインヘッダフラグのフラグ値と対にしてメインヘッダを保存する。
メディア受信装置は、メディア配信装置から後続のＲＴＰパケットを受信すると、メインヘッダを参照して、後続のＲＴＰパケットに挿入されているビットストリームからメディアデータを復元する。【０００６】
ただし、メディア受信装置は、メインヘッダが挿入されているＲＴＰパケットが欠落した場合、後続のＲＴＰパケットに記述されているメインヘッダフラグのフラグ値を確認する。
そして、過去に受信して保存しているメインヘッダの中で、そのフラグ値と同じフラグ値が付加されているメインヘッダを検索する。
メディア受信装置は、同じフラグ値が付加されているメインヘッダがあれば、そのメインヘッダを参照して、後続のＲＴＰパケットに挿入されているビットストリームからメディアデータを復元する（例えば、特許文献１を参照）。【０００７】
【特許文献１】特開２００３−２０９８３９号公報（段落番号［００５１］から［００５７］、図１）
【０００８】
従来のメディア伝送システムは以上のように構成されているので、過去に受信して保存しているメインヘッダの中に、後続のＲＴＰパケットに記述されているメインヘッダフラグのフラグ値と同じフラグ値が付加されているメインヘッダがあれば、そのメインヘッダを参照して、後続のＲＴＰパケットに挿入されているビットストリームからメディアデータを復元することができる。しかし、メインヘッダフラグのフラグ値は、メインヘッダが更新される度にインクリメントされ、その更新回数が多くなると、過去に使用されたフラグ値が再度使用されるため、後続のＲＴＰパケットに記述されているメインヘッダフラグのフラグ値と同じフラグ値が付加されているメインヘッダがあっても、そのメインヘッダは欠落したＲＴＰパケットに挿入されているメインヘッダと異なり、後続のＲＴＰパケットを正しく受信できても、メディアデータを復元することができないことがある課題があった。【０００９】
この発明は上記のような課題を解決するためになされたもので、メインヘッダが挿入されているＲＴＰパケットの受信に失敗しても、後続のＲＴＰパケットに挿入されているビットストリームからメディアデータを復元することができるメディア伝送システム及びメディア受信装置を得ることを目的とする。
また、この発明は、メインヘッダを特定する識別情報をメディア受信装置に通知することができるメディア配信装置を得ることを目的とする。
【発明の開示】
【００１０】
この発明に係るメディア伝送システムは、メディア配信装置が復号パラメータを特定する識別情報を各パケットのペイロードに挿入して各パケットを配信する一方、メディア受信装置が何れかのパケットのペイロードから識別情報を抽出し、テーブルを参照して、その識別情報に対応する復号パラメータを特定し、その復号パラメータを使用して、各ビットストリームからメディアデータを復元するようにしたものである。
【００１１】
このことによって、メインヘッダが挿入されているＲＴＰパケットの受信に失敗しても、後続のＲＴＰパケットに挿入されているビットストリームからメディアデータを復元することができる効果がある。
【図面の簡単な説明】
【００１２】
【図１】この発明の実施の形態１によるメディア伝送システムを示す構成図である。
【図２】ＪＰＥＧ２０００の符号化コードストリームのフォーマット例を示す説明図である。
【図３】一般的なＲＴＰパケットの構成を示す説明図である。
【図４】一般的な静止画データをＲＴＰ伝送する場合の方式を示す説明図である。
【図５】一般的なＪＰＥＧ２０００の静止画データをＲＴＰ伝送する場合の方式を示す説明図である。
【図６】ｃｏｎｆｉｇ−ＩＤとｃｏｎｆｉｇ情報の対応関係が記録されているテーブルを示す説明図である。
【図７】メディア配信装置が配信するＲＴＰパケットの構成を示す説明図である。
【図８】ＪＰＥＧ２０００の静止画データをＲＴＰ伝送する場合の実施の形態１の方式を示す説明図である。
【図９】ＪＰＥＧ２０００の静止画データをＲＴＰ伝送する場合の実施の形態２の方式を示す説明図である。
【図１０】テーブルの更新処理を示す説明図である。
【図１１】テーブルの更新処理を示す説明図である。
【図１２】ＪＰＥＧ２０００の静止画データをＲＴＰ伝送する場合の実施の形態４の方式を示す説明図である。
【図１３】ＪＰＥＧ２０００の静止画データをＲＴＰ伝送する場合の実施の形態５の方式を示す説明図である。
【図１４】ｃｏｎｆｉｇ情報の差分情報に含まれている情報を示す説明図である。
【図１５】図１４の差分情報の記述形式を用いて、ｃｏｎｆｉｇ情報を変更する場合の具体例を示す説明図である。
【図１６】ビットストリームの分割例を示す説明図である。
【図１７】一部のＲＴＰパケットの欠落を補完する処理を示す説明図である。
【図１８】ビットストリームの分割例を示す説明図である。
【図１９】一部のＲＴＰパケットの欠落を補完する処理を示す説明図である。
【図２０】ビットストリームのパケッタイズを示す説明図である。
【図２１】一部のＲＴＰパケットの欠落を補完する処理を示す説明図である。
【発明を実施するための最良の形態】
【００１３】
以下、この発明をより詳細に説明するために、この発明を実施するための最良の形態について、添付の図面に従って説明する。
実施の形態１．
図１はこの発明の実施の形態１によるメディア伝送システムを示す構成図である。【００１４】
図において、メディア配信装置１は復号パラメータであるｃｏｎｆｉｇ情報（メインヘッダ＋タイルパートヘッダ）を特定するｃｏｎｆｉｇ−ＩＤ（識別情報）を各ＲＴＰパケットのＲＴＰペイロードヘッダに挿入して各ＲＴＰパケットを配信する。
メディア受信装置２はメディア配信装置１から配信された各ＲＴＰパケットを受信すると、何れかのＲＴＰパケットのＲＴＰペイロードヘッダからｃｏｎｆｉｇ−ＩＤを抽出し、テーブルを参照して、そのｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報を特定し、そのｃｏｎｆｉｇ情報を使用して、各ＲＴＰパケットに挿入されているビットストリームからメディアデータを復元する。【００１５】
メディア配信装置１のデータ分割部１１は配信対象のメディアデータを入力すると、そのメディアデータのビットストリームを分割する。なお、データ分割部１１はデータ分割手段を構成している。
メディア配信装置１のＲＴＰヘッダ構築部１２は表示時刻を示すタイムスタンプ（ＴＳ）、ＲＴＰパケットの順序を示すシーケンスナンバー（ＳＱ）及び画像同士の切れ目を示すＭビットなどを各ＲＴＰパケットのＲＴＰヘッダに挿入する。【００１６】
メディア配信装置１のＲＴＰペイロード構築部１３はメディアデータを復元する際に必要なｃｏｎｆｉｇ情報を先頭のＲＴＰパケットのＲＴＰペイロードに挿入するとともに、データ分割部１１により分割されたビットストリームを順番に後続のＲＴＰパケットのＲＴＰペイロードに挿入する。
メディア配信装置１のテーブル格納部１４はｃｏｎｆｉｇ−ＩＤとｃｏｎｆｉｇ情報の対応関係が記録されているテーブルを格納しているメモリである。【００１７】
メディア配信装置１のＲＴＰペイロードヘッダ構築部１５はテーブル格納部１４に格納されているテーブルを参照して、ＲＴＰペイロード構築部１３により挿入されたｃｏｎｆｉｇ情報に対応するｃｏｎｆｉｇ−ＩＤを各ＲＴＰパケットのＲＴＰペイロードヘッダに挿入する。
なお、ＲＴＰヘッダ構築部１２、ＲＴＰペイロード構築部１３、テーブル格納部１４及びＲＴＰペイロードヘッダ構築部１５からパケット構築手段が構成されている。
メディア配信装置１のパケット配信部１６は各ＲＴＰパケットを順番に配信するパケット配信手段を構成している。【００１８】
メディア受信装置２のパケット受信部２１はメディア配信装置１から配信された各ＲＴＰパケットを受信するパケット受信手段を構成している。
メディア受信装置２のテーブル格納部２２はｃｏｎｆｉｇ−ＩＤとｃｏｎｆｉｇ情報の対応関係が記録されているテーブルを格納しているメモリである。なお、テーブル格納部２２はテーブル格納手段を構成している。【００１９】
メディア受信装置２のｃｏｎｆｉｇ情報特定部２３はパケット受信部２１により受信された何れかのＲＴＰパケットのＲＴＰペイロードヘッダからｃｏｎｆｉｇ−ＩＤを抽出し、テーブル格納部２２に格納されているテーブルを参照して、そのｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報を特定する。なお、ｃｏｎｆｉｇ情報特定部２３は復号パラメータ特定手段を構成している。【００２０】
メディア受信装置２のメディアデータ復元部２４はパケット受信部２１により受信された各ＲＴＰパケットのＲＴＰペイロードからビットストリームを抽出し、ｃｏｎｆｉｇ情報特定部２３により特定されたｃｏｎｆｉｇ情報を使用して、各ビットストリームからメディアデータを復元する。なお、メディアデータ復元部２４はメディアデータ復元手段を構成している。
メディア受信装置２のデコード部２５はメディアデータ復元部２４により復元されたメディアデータを画像データに変換する。
メディア受信装置２の画像再生部２６はデコード部２５により変換された画像データにしたがって画像をディスプレイ２７に表示する。【００２１】
次に動作について説明する。
この実施の形態１では、ＪＰＥＧ２０００（ＩＴＵ−Ｔ  Ｔ．８００／ＩＳＯ／ＩＥＣ  １５４４４−１）の符号化コードストリームを用いるとともに、ＲＴＰ（ＩＥＴＦ  ＲＦＣ３５５０）のメディア配信プロトコルを用いるものを説明するが、これは一例に過ぎず、実用上、これに限定するものではない。【００２２】
図２はＪＰＥＧ２０００の符号化コードストリームのフォーマット例を示す説明図である。
図２では、タイル数が１、タイルパート数が１である場合のＪＰＥＧ２０００の符号化コードストリームを示しており、メインヘッダとタイルパートヘッダからｃｏｎｆｉｇ情報が構成され、そのｃｏｎｆｉｇ情報の後ろにビットストリームとエンドコード（ＥＯＣ）が付加されている。
なお、タイルパートヘッダは、ＪＰＥＧ２０００規格において、１画像中に複数持つことが可能であると規定されているが、この実施の形態１では、１画像中のタイルパートヘッダは、１個であるとして説明を行う。【００２３】
図３は一般的なＲＴＰパケットの構成を示す説明図であり、一般的なＲＴＰパケットは、ＲＴＰヘッダとＲＴＰペイロードから構成される。この実施の形態１におけるＲＴＰパケットの構成は後述する。
ＲＴＰヘッダには、表示時刻を示すタイムスタンプ（ＴＳ）、ＲＴＰパケットの順序を示すシーケンスナンバー（ＳＱ）や画像間の切れ目を示すＭビットなどが記述される。
また、ＲＴＰペイロードにはメディアデータのビットストリームが格納される。メディアデータが画像のデータであれば、画像データが格納される。【００２４】
図４は一般的な静止画データをＲＴＰ伝送する場合の方式を示す説明図であり、１枚の静止画データを４つのＲＴＰパケットに分割して伝送する例を示している。
図４の例では、静止画データのビットストリームが４分割され、分割後の４個のビットストリーム（１）〜（４）が順番に各ＲＴＰパケットのＲＴＰペイロード（１）〜（４）に格納されている。【００２５】
ＲＴＰヘッダ（１）〜（４）内のシーケンスナンバー（ＳＱ）は、先頭のＲＴＰヘッダ（１）内の値が最も小さく、後続のＲＴＰヘッダ（２）〜（４）内の値が１ずつインクリメントされている。
ＲＴＰヘッダ（１）〜（４）内のタイムスタンプ（ＴＳ）は、同一の静止画にあっては同一の値である。
なお、画像間の切れ目を認識できるようにするため、同一静止画において、最大のシーケンスナンバー（ＳＱ）をもつＲＴＰヘッダ（４）のＭビットには“１”が格納され、ＲＴＰヘッダ（１）〜（３）のＭビットには“０”が格納される。【００２６】
図５は一般的なＪＰＥＧ２０００の静止画データをＲＴＰ伝送する場合の方式を示す説明図であり、１枚の静止画データを４つのＲＴＰパケットに分割して伝送する例を示している。この実施の形態１におけるＲＴＰの伝送方式は後述する。
ＪＰＥＧ２０００の静止画データを伝送する場合、符号化コードストリームのメインヘッダやタイルパートヘッダは重要な情報であるため、先頭のＲＴＰパケットのＲＴＰペイロード、即ち、ＲＴＰペイロード（１）にｃｏｎｆｉｇ情報（メインヘッダ＋タイルパートヘッダ）が格納されている。
また、符号化コードストリームのビットストリームは３分割され、分割後の３個のビットストリーム（１）〜（３）が順番にＲＴＰパケットのＲＴＰペイロード（２）〜（４）に格納されている。【００２７】
ＲＴＰヘッダ（１）〜（４）内のシーケンスナンバー（ＳＱ）は、先頭のＲＴＰヘッダ（１）内の値が最も小さく、後続のＲＴＰヘッダ（２）〜（４）内の値が１ずつインクリメントされている。
ＲＴＰヘッダ（１）〜（４）内のタイムスタンプ（ＴＳ）は、同一の静止画にあっては同一の値である。
なお、画像間の切れ目を認識できるようにするため、同一静止画において、最大のシーケンスナンバー（ＳＱ）をもつＲＴＰヘッダ（４）のＭビットには“１”が格納され、ＲＴＰヘッダ（１）〜（３）のＭビットには“０”が格納される。【００２８】
ＪＰＥＧ２０００の静止画データを伝送する場合、上記のようにして、メディア配信装置が符号化コードストリームをＲＴＰパケット化して、複数のＲＴＰパケットを配信するが、メディア受信装置が先頭のＲＴＰパケットのＲＴＰペイロード（１）を正しく受信できない場合、後続のＲＴＰパケットを正しく受信することができても、ｃｏｎｆｉｇ情報（メインヘッダ＋タイルパートヘッダ）がないため、静止画を再生することができない。
この実施の形態１では、先頭のＲＴＰパケットのＲＴＰペイロード（１）を正しく受信できない場合でも、次のようにして、静止画を再生することができるようにしている。【００２９】
予め、ｃｏｎｆｉｇ−ＩＤとｃｏｎｆｉｇ情報（メインヘッダ＋タイルパートヘッダ）の対応関係が記録されているテーブルが用意され、そのテーブルがメディア配信装置１のテーブル格納部１４とメディア受信装置２のテーブル格納部２２に格納される。
具体的には、メディア配信装置１側で上記テーブルを作成し、例えば、ＴＣＰなどの送達確認のあるプロトコルを用いて、メディア配信装置１が上記テーブルをメディア受信装置２に伝送することにより、メディア配信装置１とメディア受信装置２が上記テーブルを共有化する。【００３０】
あるいは、予めシステムの固定値として、メディア配信装置１とメディア受信装置２が同一のテーブルを記憶しておくことにより、メディア配信装置１とメディア受信装置２が上記テーブルを共有化する。
図６はｃｏｎｆｉｇ−ＩＤとｃｏｎｆｉｇ情報の対応関係が記録されているテーブルを示す説明図であり、特に下側のテーブルは、ｃｏｎｆｉｇ情報が３種類である場合の例である。【００３１】
メディア配信装置１のデータ分割部１１は、配信対象のメディアデータを入力すると、例えば、そのメディアデータのビットストリームを３分割する。
メディア配信装置１のＲＴＰヘッダ構築部１２は、表示時刻を示すタイムスタンプ（ＴＳ）、ＲＴＰパケットの順序を示すシーケンスナンバー（ＳＱ）及び画像同士の切れ目を示すＭビットなどを各ＲＴＰパケットのＲＴＰヘッダに挿入する。【００３２】
図８はＪＰＥＧ２０００の静止画データをＲＴＰ伝送する場合の実施の形態１の方式を示す説明図であり、ＲＴＰヘッダに挿入するタイムスタンプ（ＴＳ）、シーケンスナンバー（ＳＱ）やＭビットなどは、図５の場合と同様である。
なお、図７はメディア配信装置１が配信するＲＴＰパケットの構成を示す説明図である。【００３３】
メディア配信装置１のＲＴＰペイロード構築部１３は、データ分割部１１がメディアデータのビットストリームを３分割すると、図８に示すように、先頭のＲＴＰパケットのＲＴＰペイロード、即ち、ＲＴＰペイロード（１）にｃｏｎｆｉｇ情報（メインヘッダ＋タイルパートヘッダ）を挿入する。
また、ＲＴＰペイロード構築部１３は、データ分割部１１により分割されたビットストリーム（１）〜（３）を順番に後続のＲＴＰパケットのＲＴＰペイロード（２）〜（４）に挿入する。【００３４】
メディア配信装置１のＲＴＰペイロードヘッダ構築部１５は、ＲＴＰペイロード構築部１３がｃｏｎｆｉｇ情報をＲＴＰペイロード（１）に挿入すると、テーブル格納部１４に格納されているテーブルを参照して、そのｃｏｎｆｉｇ情報に対応するｃｏｎｆｉｇ−ＩＤを特定する。
例えば、ｃｏｎｆｉｇ情報がデータ（１）であれば、ｃｏｎｆｉｇ−ＩＤが“０”であると特定し、ｃｏｎｆｉｇ情報がデータ（２）であれば、ｃｏｎｆｉｇ−ＩＤが“１”であると特定する。【００３５】
ＲＴＰペイロードヘッダ構築部１５は、そのｃｏｎｆｉｇ情報に対応するｃｏｎｆｉｇ−ＩＤを特定すると、そのｃｏｎｆｉｇ−ＩＤをＲＴＰパケットのＲＴＰペイロードヘッダ（１）〜（４）に挿入する。ＲＴＰペイロードヘッダ（１）〜（４）に挿入するｃｏｎｆｉｇ−ＩＤは、言うまでもないが、すべて同じ値である。
ここでは、すべてのＲＴＰペイロードヘッダ（１）〜（４）にｃｏｎｆｉｇ−ＩＤを挿入しているが、一部のＲＴＰペイロードヘッダ（例えば、ＲＴＰペイロードヘッダ（１）（２））だけに挿入するようにしてもよい。【００３６】
メディア配信装置１のパケット配信部１６は、ＲＴＰヘッダ構築部１２、ＲＴＰペイロード構築部１３及びＲＴＰペイロードヘッダ構築部１５によって４個のＲＴＰパケットが構築されると、４個のＲＴＰパケットを順番にメディア受信装置２に配信する。【００３７】
メディア受信装置２のパケット受信部２１は、メディア配信装置１から配信された４個のＲＴＰパケットを受信する。
メディア受信装置２のｃｏｎｆｉｇ情報特定部２３は、パケット受信部２１が４個のＲＴＰパケットを受信すると、何れかのＲＴＰパケットのＲＴＰペイロードヘッダからｃｏｎｆｉｇ−ＩＤを抽出する。
ｃｏｎｆｉｇ−ＩＤの抽出対象のＲＴＰペイロードヘッダは、正しく受信できているＲＴＰペイロードヘッダであれば、何れのＲＴＰペイロードヘッダでもよいが、例えば、予め設定されている優先順位が最も高いＲＴＰペイロードヘッダを抽出対象に設定し、そのＲＴＰペイロードヘッダが正しく受信できていなければ、次に優先順位が高いＲＴＰペイロードヘッダを抽出対象に設定するようにすればよい。【００３８】
ｃｏｎｆｉｇ情報特定部２３は、何れかのＲＴＰパケットのＲＴＰペイロードヘッダからｃｏｎｆｉｇ−ＩＤを抽出すると、テーブル格納部２２に格納されているテーブルを参照して、そのｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報を特定する。
例えば、ｃｏｎｆｉｇ−ＩＤが“０”であれば、ｃｏｎｆｉｇ情報がデータ（１）であると特定し、ｃｏｎｆｉｇ−ＩＤが“１”であれば、ｃｏｎｆｉｇ情報がデータ（２）であると特定する。
したがって、仮に、ｃｏｎｆｉｇ情報が挿入されているＲＴＰパケットのＲＴＰペイロード（１）を正しく受信できていない場合でも、他のＲＴＰパケットを正しく受信できていていれば、そのＲＴＰパケットのＲＴＰペイロードヘッダに挿入されているｃｏｎｆｉｇ−ＩＤからｃｏｎｆｉｇ情報を取得することができる。【００３９】
メディア受信装置２のメディアデータ復元部２４は、パケット受信部２１が先頭のＲＴＰパケットを正しく受信すると、そのＲＴＰパケットのＲＴＰペイロード（１）からｃｏｎｆｉｇ情報を抽出する。
一方、パケット受信部２１が先頭のＲＴＰパケットを正しく受信できていない場合には、ｃｏｎｆｉｇ情報特定部２３により特定されたｃｏｎｆｉｇ情報を取得する。
ここでは、パケット受信部２１が先頭のＲＴＰパケットを正しく受信できていないとき、ｃｏｎｆｉｇ情報特定部２３からｃｏｎｆｉｇ情報を取得するようにしているが、パケット受信部２１が先頭のＲＴＰパケットを正しく受信できている場合でも、ｃｏｎｆｉｇ情報特定部２３からｃｏｎｆｉｇ情報を取得するようにしてもよい。【００４０】
メディアデータ復元部２４は、パケット受信部２１により受信された後続のＲＴＰパケットのＲＴＰペイロード（２）〜（４）からビットストリーム（１）〜（３）を抽出し、上記のｃｏｎｆｉｇ情報を使用して、ビットストリーム（１）〜（３）からメディアデータを復元する。
メディア受信装置２のデコード部２５は、メディアデータ復元部２４がメディアデータを復元すると、そのメディアデータを画像データに変換する。
メディア受信装置２の画像再生部２６は、デコード部２５がメディアデータを画像データに変換すると、その画像データにしたがって画像をディスプレイ２７に表示する。【００４１】
以上で明らかなように、この実施の形態１によれば、メディア配信装置１がメディアデータを復元する際に必要なｃｏｎｆｉｇ情報を特定するｃｏｎｆｉｇ−ＩＤをＲＴＰパケットのＲＴＰペイロードヘッダ（１）〜（４）に挿入して各ＲＴＰパケットを配信する一方、メディア受信装置２が何れかのＲＴＰパケットのＲＴＰペイロードヘッダからｃｏｎｆｉｇ−ＩＤを抽出し、テーブルを参照して、そのｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報を特定し、そのｃｏｎｆｉｇ情報を使用して、各ビットストリームからメディアデータを復元するように構成したので、ｃｏｎｆｉｇ情報が挿入されているＲＴＰパケットの受信に失敗しても、後続のＲＴＰパケットに挿入されているビットストリームからメディアデータを復元することができる効果を奏する。【００４２】
実施の形態２．
上記実施の形態１では、メディア配信装置１のＲＴＰペイロード構築部１３がＲＴＰパケットのＲＴＰペイロード（１）にｃｏｎｆｉｇ情報を挿入するものについて示したが、メディア受信装置２のメディアデータ復元部２４が常にｃｏｎｆｉｇ情報特定部２３からｃｏｎｆｉｇ情報を取得するようにすれば、図９に示すように、メディア配信装置１のＲＴＰペイロード構築部１３がＲＴＰパケットのＲＴＰペイロード（１）にｃｏｎｆｉｇ情報を挿入しないようにしてもよい。
これにより、ｃｏｎｆｉｇ情報を配信しない分、伝送量を削減することができる効果を奏する。【００４３】
実施の形態３．
上記実施の形態１では、メディア配信装置１のテーブル格納部１４とメディア受信装置２のテーブル格納部２２が共通のテーブルを格納するものについて示したが、メディア配信装置１のテーブル格納部１４とメディア受信装置２のテーブル格納部２２が格納している共通のテーブルを更新するようにしてもよい。【００４４】
具体的には、図１０に示すように、３種類のｃｏｎｆｉｇ−ＩＤとｃｏｎｆｉｇ情報の対応関係がテーブルに記録されているとき、その対応関係を１種類追加する場合、メディア配信装置１が例えばアウトバンドで送達確認のあるＴＣＰのようなプロトコルを用いて、ｃｏｎｆｉｇ−ＩＤ“３”とｃｏｎｆｉｇ情報“データ（４）”の組を更新情報としてメディア受信装置２に送信する。
メディア受信装置２は、メディア配信装置１からｃｏｎｆｉｇ−ＩＤ“３”とｃｏｎｆｉｇ情報“データ（４）”の組を更新情報として受信すると、ｃｏｎｆｉｇ−ＩＤ“３”とｃｏｎｆｉｇ情報“データ（４）”の組をテーブルに追加する。【００４５】
また、図１１に示すように、３種類のｃｏｎｆｉｇ−ＩＤとｃｏｎｆｉｇ情報の対応関係がテーブルに記録されているとき、ｃｏｎｆｉｇ−ＩＤ“２”に対応するｃｏｎｆｉｇ情報“データ（３）”を変更する場合、メディア配信装置１が例えばアウトバンドで送達確認のあるＴＣＰのようなプロトコルを用いて、ｃｏｎｆｉｇ−ＩＤ“２”とｃｏｎｆｉｇ情報“データ（４）”の組を更新情報としてメディア受信装置２に送信する。
メディア受信装置２は、メディア配信装置１からｃｏｎｆｉｇ−ＩＤ“２”とｃｏｎｆｉｇ情報“データ（４）”の組を更新情報として受信すると、ｃｏｎｆｉｇ−ＩＤ“２”は既に格納しているので、ｃｏｎｆｉｇ−ＩＤ“２”に対応するｃｏｎｆｉｇ情報をデータ（３）からデータ（４）に変更する。【００４６】
以上で明らかなように、この実施の形態３によれば、メディア受信装置２がメディア配信装置１からテーブルの更新情報を受信すると、その更新情報にしたがってテーブルを更新するように構成したので、配信対象のメディアデータに応じて適宜ｃｏｎｆｉｇ情報を更新することができる効果を奏する。【００４７】
実施の形態４．
上記実施の形態１では、メディア受信装置２のｃｏｎｆｉｇ情報特定部２３が何れかのＲＴＰパケットのＲＴＰペイロードヘッダからｃｏｎｆｉｇ−ＩＤを抽出し、テーブル格納部２２に格納されているテーブルを参照して、そのｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報を特定するものについて示したが、図１２に示すように、メディア受信装置２のパケット受信部２１がメディア配信装置１からｃｏｎｆｉｇ−ＩＤ“ＦＦ”（特定の識別情報）を受信すると、テーブル格納部２２に格納されているテーブルを参照することなく、ＲＴＰパケットのＲＴＰペイロード（１）に挿入されているｃｏｎｆｉｇ情報を使用して、ビットストリーム（１）〜（３）からメディアデータを復元するようにしてもよい。【００４８】
具体的には次の通りである。
メディア受信装置２のｃｏｎｆｉｇ情報特定部２３は、何れかのＲＴＰパケットのＲＴＰペイロードヘッダに挿入されているｃｏｎｆｉｇ−ＩＤが特定値であるか否かを判定する。即ち、ｃｏｎｆｉｇ−ＩＤが“ＦＦ”である否かを判定する。【００４９】
ｃｏｎｆｉｇ情報特定部２３は、ｃｏｎｆｉｇ−ＩＤが“ＦＦ”でなければ、上記実施の形態１と同様に、ｃｏｎｆｉｇ情報を特定する。
しかし、ｃｏｎｆｉｇ−ＩＤが“ＦＦ”であれば、テーブル格納部２２に格納されているテーブルを参照することなく、ＲＴＰパケットのＲＴＰペイロード（１）に挿入されているｃｏｎｆｉｇ情報を取得するようにする。【００５０】
メディア受信装置２のメディアデータ復元部２４は、パケット受信部２１により受信された後続のＲＴＰパケットのＲＴＰペイロード（２）〜（４）からビットストリーム（１）〜（３）を抽出し、ｃｏｎｆｉｇ情報特定部２３により取得されたｃｏｎｆｉｇ情報を使用して、ビットストリーム（１）〜（３）からメディアデータを復元する。【００５１】
以上で明らかなように、この実施の形態４によれば、メディア受信装置２のパケット受信部２１がメディア配信装置１からｃｏｎｆｉｇ−ＩＤ“ＦＦ”（特定の識別情報）を受信すると、テーブル格納部２２に格納されているテーブルを参照することなく、ＲＴＰパケットのＲＴＰペイロード（１）に挿入されているｃｏｎｆｉｇ情報を使用して、ビットストリーム（１）〜（３）からメディアデータを復元するように構成したので、テーブル格納部２２に格納されているテーブルを更新することなく、そのテーブルに記録されていないｃｏｎｆｉｇ情報を使用して、メディアデータを復元することができる効果を奏する。【００５２】
実施の形態５．
上記実施の形態１では、メディア受信装置２のｃｏｎｆｉｇ情報特定部２３が何れかのＲＴＰパケットのＲＴＰペイロードヘッダからｃｏｎｆｉｇ−ＩＤを抽出し、テーブル格納部２２に格納されているテーブルを参照して、そのｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報を特定するものについて示したが、図１３に示すように、メディア受信装置２のパケット受信部２１がメディア配信装置１からｃｏｎｆｉｇ情報の差分情報を受信すると、テーブル格納部２２に格納されているテーブル内のｃｏｎｆｉｇ情報と当該差分情報を使用して、ビットストリーム（１）〜（３）からメディアデータを復元するようにしてもよい。【００５３】
具体的には次の通りである。
ｃｏｎｆｉｇ情報の差分情報は、ｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報（テーブル内のｃｏｎｆｉｇ情報）に対する差分情報であり、図１４はｃｏｎｆｉｇ情報の差分情報に含まれている情報を示している。【００５４】
ｃｏｎｆｉｇ情報の差分情報には、１個のｃｏｎｆｉｇ−ＩＤと、そのｃｏｎｆｉｇ−ＩＤに対応するｃｏｎｆｉｇ情報（テーブル内のｃｏｎｆｉｇ情報）を変更する箇所の個数を示すｃｈａｎｇｅとを含んでいる。
また、ｃｏｎｆｉｇ情報の差分情報には、ｃｈａｎｇｅの個数分だけ、変更箇所を示すｏｆｆｓｅｔ、消去するデータの長さを示すｅｒａｃｅ＿ｌｅｎｇｔｈ、変更後のデータの長さを示すｉｎｓｅｒｔ＿ｌｅｎｇｔｈ、変更後のデータを示すｄａｔａを含んでいる。【００５５】
図１５は図１４の差分情報の記述形式を用いて、ｃｏｎｆｉｇ情報を変更する場合の具体例を示している。
例（１）はｃｏｎｆｉｇ−ＩＤ＝０ｘ０のｃｏｎｆｉｇ情報を２箇所変更するものを示しており、例（２）はｃｏｎｆｉｇ情報の値を変更すると同時にバイト長を変更するものを示している。【００５６】
以上で明らかなように、この実施の形態５によれば、メディア受信装置２のパケット受信部２１がメディア配信装置１からｃｏｎｆｉｇ情報の差分情報を受信すると、テーブル格納部２２に格納されているテーブル内のｃｏｎｆｉｇ情報と当該差分情報を使用して、ビットストリーム（１）〜（３）からメディアデータを復元するように構成したので、上記実施の形態１と同様に、ｃｏｎｆｉｇ情報が挿入されているＲＴＰパケットの受信に失敗しても、後続のＲＴＰパケットに挿入されているビットストリームからメディアデータを復元することができる効果を奏する。【００５７】
また、差分情報の中にｃｏｎｆｉｇ−ＩＤが含まれているので、テーブルに記録されているｃｏｎｆｉｇ情報の中で、最も類似しているｃｏｎｆｉｇ情報との差分を伝送することができるようになり、メディア配信装置１の伝送量を削減することができる効果を奏する。【００５８】
実施の形態６．
上記実施の形態１では、特に言及していないが、ＲＴＰのような送達確認のないプロトコルを用いる伝送方式の場合、分割後のビットストリームが挿入されているＲＴＰパケットのいずれかの受信に失敗すると、正しく受信できたビットストリームを使用してデコードを行う際に、デコードエラーの発生を招いたり、不自然な画像が表示されたりすることがある。
この実施の形態６では、メディア配信装置１から配信されたＲＴＰパケットのうち、一部のＲＴＰパケットの受信に失敗しても、デコードエラーの発生等を次のようにして防止している。【００５９】
図１６はビットストリームの分割例を示す説明図であり、ＪＰ２Ｋパケットは符号化ストリームを構成する単位である。図１６の例では、ＪＰ２Ｋパケットを１個、もしくは、複数個含む形で、ビットストリームを分割している。
図１７は一部のＲＴＰパケットの欠落を補完する処理を示す説明図であり、図１６のようにＪＰ２Ｋパケット単位で分割されたビットストリームを伝送する際、即ち、メディア配信装置１が１枚のＪＰＥＧ２０００の静止画データであるビットストリームを５つに分割して配信する際、伝送中にビットストリーム（４）を含むＲＴＰパケットが欠落している例を示している。【００６０】
メディア受信装置２のメディアデータ復元部２４は、図１７に示すように、パケット受信部２１がビットストリーム（１）〜（３）を含むＲＴＰパケットを正しく受信できたが、ビットストリーム（４）を含むＲＴＰパケットを正しく受信できない場合、即ち、ＲＴＰヘッダのシーケンスナンバー（ＳＱ）からビットストリーム（４）を含むＲＴＰパケットが欠落したことを認識すると、ｃｏｎｆｉｇ情報特定部２３により特定されたｃｏｎｆｉｇ情報の後ろにビットストリーム（１）〜（３）を結合し、その後ろにエンドコード（ＥＯＣ）を結合する。
メディアデータ復元部２４は、上記の結合結果を解析してメディアデータを復元する。【００６１】
この実施の形態６によれば、ビットストリーム（５）が失われるため、若干の画質劣化を伴うが、ＪＰＥＧ２０００の性質から、多くの場合、実用上十分な画質の画像が復号される効果を奏する。【００６２】
実施の形態７．
図１８はビットストリームの分割例として、ビットストリームが固定個数のＪＰ２Ｋパケットを含むものを示している。図１８の例では、各ビットストリーム（１）〜（３）は３個のＪＰ２Ｋパケットを含んでいる。
図１９は一部のＲＴＰパケットの欠落を補完する処理を示す説明図であり、図１８のように各ビットストリームが固定個数のＪＰ２Ｋパケットを含む分割方法でビットストリームを伝送する際、伝送中にビットストリーム（４）を含むＲＴＰパケットが欠落している例を示している。【００６３】
メディア受信装置２のメディアデータ復元部２４は、図１９に示すように、パケット受信部２１がビットストリーム（１）〜（３）を含むＲＴＰパケットを正しく受信できたが、ビットストリーム（４）を含むＲＴＰパケットを正しく受信できない場合、即ち、ＲＴＰヘッダのシーケンスナンバー（ＳＱ）からビットストリーム（４）を含むＲＴＰパケットが欠落したことを認識すると、ｃｏｎｆｉｇ情報特定部２３により特定されたｃｏｎｆｉｇ情報の後ろにビットストリーム（１）〜（３）を結合する。【００６４】
次に、メディアデータ復元部２４は、ビットストリーム（３）の後ろに、ビットストリーム（４）に含まれているＪＰ２Ｋパケットの個数だけヌルデータ（１バイトの“０”のデータ（０ｘ００））を結合する。
次に、メディアデータ復元部２４は、ヌルデータの後ろにビットストリーム（５）とエンドコード（ＥＯＣ）を結合する。
メディアデータ復元部２４は、上記の結合結果を解析してメディアデータを復元する。【００６５】
この実施の形態７によれば、欠落した後ろのビットストリーム（５）も使用されるため、上記実施の形態６よりも、画質劣化を抑制することができる効果を奏する。
なお、ＪＰＥＧ２０００の規定によれば、ＪＰ２Ｋパケットをヌルパケットで補完することは、ビットストリームとして矛盾をなくすようなエラー補完方法となる。【００６６】
ここで、図２０はビットストリームのパケッタイズを示す説明図である。
図２０の例では、ＲＴＰペイロードヘッダにｏｆｆｓｅｔとｉｎｃｌｕｄｅを含んでいる。
ｏｆｆｓｅｔとｉｎｃｌｕｄｅはＪＰ２Ｋパケットに関する数値であり、特にｏｆｆｓｅｔは先頭からのＪＰ２Ｋパケット数の累積個数を示し、ｉｎｃｌｕｄｅはＲＴＰペイロードのビットストリームに含まれるＪＰ２Ｋパケットの個数を示している。【００６７】
ビットストリーム（１）は３個のＪＰ２Ｋパケットを含み、ビットストリーム（２）は１個のＪＰ２Ｋパケットを含み、ビットストリーム（３）は４個のＪＰ２Ｋパケットを含み、ビットストリーム（４）は５個のＪＰ２Ｋパケットを含み、ビットストリーム（５）は３個のＪＰ２Ｋパケットを含んでいる。
図２１は図２０の伝送において、ビットストリーム（４）を含むＲＴＰパケットが欠落したものを示している。
正しく受信したＲＴＰペイロードヘッダに記述されているｏｆｆｓｅｔとｉｎｃｌｕｄｅの値から、ビットストリーム（４）に含まれているＪＰ２Ｋパケットの個数を算出する。【００６８】
図２１の例では、ビットストリーム（４）が欠落しているので、正しく受信できた前後のＲＴＰペイロードヘッダに記述されているｏｆｆｓｅｔとｉｎｃｌｕｄｅの値を用いて、ビットストリーム（４）に含まれているＪＰ２Ｋパケットの数Ｘを計算する。
Ｘ＝ｏｆｆｓｅｔ５−ｏｆｆｓｅｔ３−ｉｎｃｌｕｄｅ３
そして、ＪＰ２Ｋパケットの数Ｘだけヌルパケットで補完する。ヌルパケットは、１バイトの０ｘ００である。このとき、１つのＪＰ２Ｋパケットを１つのヌルパケットで補完する。
【産業上の利用可能性】
【００６９】
以上のように、この発明に係るメディア伝送システムは、復号パラメータを正しく受信できない場合でも、正しく受信できたビットストリームを廃棄することなく、メディアデータを復元できるようにして、伝送効率を高める必要があるものに適している。
【図１】
0004361564.tif 000002
【図２】
0004361564.tif 000003
【図３】
0004361564.tif 000004
【図４】
0004361564.tif 000005
【図５】
0004361564.tif 000006
【図６】
0004361564.tif 000007
【図７】
0004361564.tif 000008
【図８】
0004361564.tif 000009
【図９】
0004361564.tif 000010
【図１０】
0004361564.tif 000011
【図１１】
0004361564.tif 000012
【図１２】
0004361564.tif 000013
【図１３】
0004361564.tif 000014
【図１４】
0004361564.tif 000015
【図１５】
0004361564.tif 000016
【図１６】
0004361564.tif 000017
【図１７】
0004361564.tif 000018
【図１８】
0004361564.tif 000019
【図１９】
0004361564.tif 000020
【図２０】
0004361564.tif 000021
【図２１】
0004361564.tif 000022