(57)【要約】【課題】送信側及び受信装置の基準クロックの基準となる基準時刻情報にうるう秒調整が行なわれる場合であっても、受信装置が意図された時刻に所定のデータ単位を再生できる送信方法などを提供する。【解決手段】符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した基準時刻情報に基づいて、所定のデータユニットの提示時刻を示す提示時刻情報を生成し、所定のデータユニットと、生成した提示時刻情報と、提示時刻情報がうるう秒調整前の基準時刻情報に基づいて生成されたか否かを示す識別情報とを送信し、所定のデータユニットの提示時刻は、所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻である。【選択図】図９２
2020205633.tif 000002
【特許請求の範囲】
【請求項１】
符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、
外部から受信した基準時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、
前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記基準時刻情報に基づいて生成されたか否かを示す識別情報とを送信し、
前記所定のデータユニットの提示時刻は、前記所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻である
送信方法。
【請求項２】
符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信方法であって、
前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信し、
受信した前記提示時刻情報及び前記識別情報に基づいて、受信した前記所定のデータユニットを再生し、
前記所定のデータユニットの提示時刻は、前記所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻である
受信方法。
【請求項３】
符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信装置であって、
外部から受信した時刻情報に基づいて、当該所定のデータユニットの提示時刻を示す提示時刻情報を生成する生成部と、
前記所定のデータユニットと、前記生成部により生成された前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記時刻情報に基づいて生成されたか否かを示す識別情報とを送信する送信部と、を備え、
前記所定のデータユニットの提示時刻は、前記所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻である
送信装置。
【請求項４】
符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信装置であって、
前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信する受信部と、
前記受信部により受信された前記提示時刻情報及び前記識別情報に基づいて、前記受信部により受信された前記所定のデータユニットを再生する再生部と、を備え、
前記所定のデータユニットの提示時刻は、前記所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻である
受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信方法、受信方法、送信装置及び受信装置に関する。
【背景技術】
【０００２】
放送及び通信サービスの高度化に伴い、８Ｋ（７６８０×４３２０ピクセル：以下では８Ｋ４Ｋとも呼ぶ）及び４Ｋ（３８４０×２１６０ピクセル：以下では４Ｋ２Ｋとも呼ぶ）などの超高精細な動画像コンテンツの導入が検討されている。受信装置は、受信した超高精細な動画像の符号化データを実時間で復号して表示する必要があるが、特に８Ｋなどの解像度の動画像は復号時の処理負荷が大きく、このような動画像を１つの復号器で、実時間で復号することは困難である。従って、複数の復号器を用いて復号処理を並列化することで、１つの復号器あたりの処理負荷を低減し、実時間処理を達成する方法が検討されている。
【０００３】
また、符号化データはＭＰＥＧ−２  ＴＳ（Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ）又はＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）などの多重化方式に基づいて多重化されたうえで送信される。例えば、非特許文献１には、ＭＭＴに従って、符号化されたメディアデータをパケット毎に送信する技術が開示されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ  −  Ｈｉｇｈ  ｅｆｆｉｃｉｅｎｃｙ  ｃｏｄｉｎｇ  ａｎｄ  ｍｅｄｉａ  ｄｅｌｉｖｅｒｙ  ｉｎ  ｈｅｔｅｒｏｇｅｎｅｏｕｓ  ｅｎｖｉｒｏｎｍｅｎｔ  −  Ｐａｒｔ１：ＭＰＥＧ  ｍｅｄｉａ  ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ  ＤＩＳ  ２３００８−１
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、放送や通信サービスの高度化に伴い、８Ｋや４Ｋ（３８４０ｘ２１６０ピクセル）などの超高精細な動画コンテンツの導入が検討されている。ＭＭＴ／ＴＬＶ方式では、送信側の基準クロックをＲＦＣ  ５９０５に規定される６４ビットのロングフォーマットＮＴＰに同期させ、基準クロックを基に、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ  Ｓｔａｍｐ）や、ＤＴＳ（Ｄｅｃｏｄｅ  Ｔｉｍｅ  Ｓｔａｍｐ）などのタイムスタンプを同期メディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置におけるシステムクロックを生成する。
【０００６】
しかしながら、このようなＭＭＴの伝送方式では、ＮＴＰなどの基準時刻情報にうるう秒調整が行なわれる場合、受信装置が受信したパケットに含まれる所定のデータユニットであるＭＰＵを、当該ＭＰＵに対応づけられたＤＴＳ又はＰＴＳに従っても復号又は提示を意図された時刻に行うことができないという課題がある。
【０００７】
本発明は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、受信装置が意図された時刻に所定のデータユニットを再生できる送信方法などを提供する。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明の一態様に係る送信方法は、符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した基準時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記基準時刻情報に基づいて生成されたか否かを示す識別情報とを送信し、前記所定のデータユニットの提示時刻は、前記所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻である。
【０００９】
また、上記目的を達成するために、本発明の一態様に係る受信方法は、符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信方法であって、前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信し、受信した前記提示時刻情報及び前記識別情報に基づいて、受信した前記所定のデータユニットを再生し、前記所定のデータユニットの提示時刻は、前記所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻である。
【００１０】
上記目的を達成するために、本発明の一態様に係る送信方法は、符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した基準時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記基準時刻情報に基づいて生成されたか否かを示す識別情報とを送信する。
【００１１】
なお、これらの全般的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【００１２】
本発明は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、受信装置が意図された時刻にＭＰＵを復号及び提示できる。
【図面の簡単な説明】
【００１３】
【図１】図１は、ピクチャをスライスセグメントに分割する例を示す図である。
【図２】図２は、ピクチャのデータが格納されたＰＥＳパケット列の一例を示す図である。
【図３】図３は、実施の形態１に係るピクチャの分割例を示す図である。
【図４】図４は、実施の形態１の比較例に係るピクチャの分割例を示す図である。
【図５】図５は、実施の形態１に係るアクセスユニットのデータの一例を示す図である。
【図６】図６は、実施の形態１に係る送信装置のブロック図である。
【図７】図７は、実施の形態１に係る受信装置のブロック図である。
【図８】図８は、実施の形態１に係るＭＭＴパケットの一例を示す図である。
【図９】図９は、実施の形態１に係るＭＭＴパケットの別の例を示す図である。
【図１０】図１０は、実施の形態１に係る各復号部に入力されるデータの一例を示す図である。
【図１１】図１１は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。
【図１２】図１２は、実施の形態１に係る各復号部に入力されるデータの別の例を示す図である。
【図１３】図１３は、実施の形態１に係るピクチャの分割例を示す図である。
【図１４】図１４は、実施の形態１に係る送信方法のフローチャートである。
【図１５】図１５は、実施の形態１に係る受信装置のブロック図である。
【図１６】図１６は、実施の形態１に係る受信方法のフローチャートである。
【図１７】図１７は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。
【図１８】図１８は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。
【図１９】図１９は、ＭＰＵの構成を示す図である。
【図２０】図２０は、ＭＦメタデータの構成を示す図である。
【図２１】図２１は、データの送信順序を説明するための図である。
【図２２】図２２は、ヘッダ情報を用いずに復号を行う方法の例を示す図である。
【図２３】図２３は、実施の形態２に係る送信装置のブロック図である。
【図２４】図２４は、実施の形態２に係る送信方法のフローチャートである。
【図２５】図２５は、実施の形態２に係る受信装置のブロック図である。
【図２６】図２６は、ＭＰＵ先頭位置及びＮＡＬユニット位置を特定するための動作のフローチャートである。
【図２７】図２７は、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作のフローチャートである。
【図２８】図２８は、低遅延提示モードが設けられた場合の受信装置の動作のフローチャートである。
【図２９】図２９は、補助データが送信される場合のＭＭＴパケットの送信順序の一例を示す図である。
【図３０】図３０は、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例を説明するための図である。
【図３１】図３１は、補助データの受信を説明するための図である。
【図３２】図３２は、補助データを用いた受信動作のフローチャートである。
【図３３】図３３は、複数のムービーフラグメントで構成されるＭＰＵの構成を示す図である。
【図３４】図３４は、図３３の構成のＭＰＵが伝送される場合のＭＭＴパケットの送信順序を説明するための図である。
【図３５】図３５は、１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信装置の動作例を説明するための第１の図である。
【図３６】図３６は、１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信装置の動作例を説明するための第２の図である。
【図３７】図３７は、図３５及び図３６で説明した受信方法の動作のフローチャートである。
【図３８】図３８は、非ＶＣＬ  ＮＡＬユニットを、個別にデータユニットとし、アグリゲーションする場合を示す図である。
【図３９】図３９は、非ＶＣＬ  ＮＡＬユニットを、まとめてデータユニットとする場合を示す図である。
【図４０】図４０は、パケットロスが発生した場合の受信装置の動作のフローチャートである。
【図４１】図４１は、ＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作のフローチャートである。
【図４２】図４２は、時間スケーラビリティを実現する際の各ＴｅｍｐｏｒａｌＩｄにおけるピクチャの予測構造の例を示す図である。
【図４３】図４３は、図４２の各ピクチャにおける復号時刻（ＤＴＳ）と表示時刻（ＰＴＳ）との関係を示す図である。
【図４４】図４４は、ピクチャの遅延処理、及び、リオーダ処理が必要となるピクチャの予測構造の一例を示す図である。
【図４５】図４５は、ＭＰ４形式で構成されるＭＰＵが複数のムービーフラグメントに分割されて、ＭＭＴＰペイロード、ＭＭＴＰパケットに格納される例を示す図である。
【図４６】図４６は、ＰＴＳ及びＤＴＳの算出方法と課題とを説明するための図である。
【図４７】図４７は、ＤＴＳ算出用の情報を用いてＤＴＳが算出される場合の受信動作のフローチャートである。
【図４８】図４８は、ＭＭＴにおけるデータユニットのペイロードへの格納方法を説明するための図である。
【図４９】図４９は、実施の形態３に係る送信装置の動作フローである。
【図５０】図５０は、実施の形態３に係る受信装置の動作フローである。
【図５１】図５１は、実施の形態３に係る送信装置の具体的構成の例を示す図である。
【図５２】図５２は、実施の形態３に係る受信装置の具体的構成の例を示す図である。
【図５３】図５３は、ｎｏｎ−ｔｉｍｅｄメディアのＭＰＵへの格納方法、及び、ＭＭＴＰパケットでの伝送方法を示す図である。
【図５４】図５４は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する例を示す図である。
【図５５】図５５は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する他の例を示す図である。
【図５６】図５６は、アセット管理テーブルにおけるファイル毎のループのシンタックスを示す図である。
【図５７】図５７は、受信装置における分割データ番号を特定する動作フローである。
【図５８】図５８は、受信装置における分割データ数を特定する動作フローである。
【図５９】図５９は、送信装置においてフラグメントカウンタを運用するかどうかを決定するための動作フローである。
【図６０】図６０は、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明するための図である。
【図６１】図６１は、フラグメントカウンタを活用する場合の送信装置の動作フローである。
【図６２】図６２は、フラグメントカウンタを活用する場合の受信装置の動作フローである。
【図６３】図６３は、同一番組を複数のＩＰデータフローで送信する場合のサービス構成を示す図である。
【図６４】図６４は、送信装置の具体的構成の例を示す図である。
【図６５】図６５は、受信装置の具体的構成の例を示す図である。
【図６６】図６６は、送信装置による動作フローである。
【図６７】図６７は、受信装置による動作フローである。
【図６８】図６８は、ＡＲＩＢ  ＳＴＤ−Ｂ６０に規定されている受信バッファモデルに基づいて、特に放送伝送路のみを用いた場合の受信バッファモデルを示す。
【図６９】図６９は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す図である。
【図７０】図７０は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例であって、ＮＡＬサイズフォーマットの映像信号を一つのデータユニットとした場合の例を示す図である。
【図７１】図７１は、データユニット長が示されないＭＭＴＰパケットのペイロードの構成を示す図である。
【図７２】図７２は、パケット単位に付与されるｅｘｔｅｎｄ領域に示す例である。
【図７３】図７３は、受信装置の動作フローを示す。
【図７４】図７４は、送信装置の具体的構成の例を示す図である。
【図７５】図７５は、受信装置の具体的構成の例を示す図である。
【図７６】図７６は、送信装置による動作フローである。
【図７７】図７７は、受信装置による動作フローである。
【図７８】図７８は、ＡＲＩＢ  ＳＴＤ−Ｂ６０に規定されるＭＭＴ／ＴＬＶ方式のプロトコルスタックを示す図である。
【図７９】図７９は、ＴＬＶパケットの構成を示す図である。
【図８０】図８０は、受信装置のブロック図の一例を示す図である。
【図８１】図８１は、タイムスタンプ記述子について説明するための図である。
【図８２】図８２は、うるう秒調整を説明するための図である。
【図８３】図８３は、ＮＴＰ時刻、ＭＰＵタイムスタンプ及びＭＰＵ提示タイミングの関係を示す図である。
【図８４】図８４は、送信側においてタイムスタンプを補正する補正方法について説明するための図である。
【図８５】図８５は、受信装置においてタイムスタンプを補正する補正方法について説明するための図である。
【図８６】図８６は、送信側（送信装置）においてＭＰＵタイムスタンプを補正する場合の、送信側（送信装置）による動作フローである。
【図８７】図８７は、送信側（送信装置）においてＭＰＵタイムスタンプを補正する場合の、受信装置による動作フローである。
【図８８】図８８は、受信装置においてＭＰＵタイムスタンプを補正する場合の、送信側（送信装置）による動作フローである。
【図８９】図８９は、受信装置においてＭＰＵタイムスタンプを補正する場合の、受信装置による動作フローである。
【図９０】図９０は、送信装置の具体的構成の例を示す図である。
【図９１】図９１は、受信装置の具体的構成の例を示す図である。
【図９２】図９２は、送信装置による動作フローである。
【図９３】図９３は、受信装置による動作フローである。
【発明を実施するための形態】
【００１４】
本発明の一態様に係る送信方法は、符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した基準時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記基準時刻情報に基づいて生成されたか否かを示す識別情報とを送信する。
【００１５】
このような送信方法は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、意図された時刻に所定のデータユニットを再生できる。
【００１６】
また、前記所定のデータユニットの提示時刻は、前記所定のデータユニットに含まれる複数のアクセスユニットのうちの提示順で先頭のアクセスユニットの提示時刻であってもよい。
【００１７】
また、前記生成では、前記基準時刻情報に予め定められた時間を加算することで、前記所定のデータユニットの提示時刻を生成してもよい。
【００１８】
また、前記識別情報は、前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記基準時刻情報に基づいて生成されたか否かを示してもよい。
【００１９】
また、前記送信では、複数の前記所定のデータユニットを所定のパケットに格納して送信し、前記生成において生成した、前記所定のデータユニットに対応する前記提示時刻情報を、前記所定のパケットの制御情報に格納して送信してもよい。
【００２０】
また、前記送信では、複数の前記所定のデータユニットとしてのＭＰＵ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ）を、前記所定のパケットとしてのＭＭＴＰ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）パケットに格納して送信し、前記生成において生成した、前記ＭＰＵに対応する前記提示時刻情報を、前記ＭＭＴＰパケットの制御情報に含まれるＭＰＵタイムスタンプ記述子に格納して送信してもよい。
【００２１】
また、前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）であってもよい。
【００２２】
また、本発明の一態様に係る受信方法は、符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信方法であって、前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信し、受信した前記提示時刻情報及び前記識別情報に基づいて、受信した前記所定のデータユニットを再生する。
【００２３】
このような受信方法は、基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、意図された時刻に所定のデータユニットを再生できる。
【００２４】
なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
【００２５】
以下、実施の形態について、図面を参照しながら具体的に説明する。
【００２６】
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
【００２７】
（本発明の基礎となった知見）
近年、ＴＶ、スマートフォン、又はタブレット端末などのディスプレイの高解像度化が進んでいる。特に日本国内の放送においては２０２０年に８Ｋ４Ｋ（解像度が８Ｋ×４Ｋ）のサービスが予定されている。８Ｋ４Ｋなどの超高解像度の動画像においては、単一の復号器では実時間での復号が困難であるため、複数の復号器を用いて並列に復号処理を行う手法が検討されている。
【００２８】
符号化データはＭＰＥＧ−２  ＴＳやＭＭＴなどの多重化方式に基づいて多重化して送信されるため、受信装置は、復号に先立って、多重化データから動画の符号化データを分離する必要がある。以下、多重化データから符号化データを分離する処理を逆多重化と呼ぶ。
【００２９】
復号処理を並列化する際には、各復号器のそれぞれに対して、復号対象となる符号化データを振り分ける必要がある。符号化データを振り分ける際には、符号化データそのものを解析する必要があり、特に８Ｋなどのコンテンツにおいてはビットレートが非常に高いことから、解析に係る処理負荷が大きい。したがって、逆多重化の部分がボトルネックとなり実時間での再生が行えないという課題があった。
【００３０】
ところで、ＭＰＥＧとＩＴＵにより規格化されたＨ．２６４及びＨ．２６５などの動画像符号化方式においては、送信装置は、ピクチャをスライス又はスライスセグメントと呼ばれる複数の領域に分割し、分割したそれぞれの領域を独立に復号できるように符号化することができる。従って、例えば、Ｈ．２６５の場合には、放送を受信する受信装置は、受信データからスライスセグメント毎のデータを分離し、各スライスセグメントのデータを別々の復号器に出力することで、復号処理の並列化を実現できる。
【００３１】
図１は、ＨＥＶＣにおいて、１つのピクチャを４つのスライスセグメントに分割する例を示す図である。例えば、受信装置は４つの復号器を備え、各復号器が４つのスライスセグメントのうちいずれかを復号する。
【００３２】
従来の放送においては、送信装置は、１枚のピクチャ（ＭＰＥＧシステム規格におけるアクセスユニット）を１つのＰＥＳパケットに格納し、ＰＥＳパケットをＴＳパケット列に多重化する。このため、受信装置は、ＰＥＳパケットのペイロードを分離したうえで、ペイロードに格納されたアクセスユニットのデータを解析することで、各スライスセグメントを分離し、分離された各スライスセグメントのデータを復号器に出力する必要があった。
【００３３】
しかしながら、アクセスユニットのデータを解析してスライスセグメントを分離する際の処理量が大きいため、この処理を実時間で行うことが困難であるという課題があることを本発明者は見出した。
【００３４】
図２は、スライスセグメントに分割されたピクチャのデータが、ＰＥＳパケットのペイロードに格納される例を示す図である。
【００３５】
図２に示すように、例えば、複数のスライスセグメント（スライスセグメント１〜４）のデータが１つのＰＥＳパケットのペイロードに格納される。また、ＰＥＳパケットはＴＳパケット列に多重化される。
【００３６】
（実施の形態１）
以下では、動画像の符号化方式としてＨ．２６５を用いる場合を例に説明するが、Ｈ．２６４など他の符号化方式を用いる場合にも本実施の形態を適用できる。
【００３７】
図３は、本実施の形態におけるアクセスユニット（ピクチャ）を分割単位に分割した例を示す図である。アクセスユニットは、Ｈ．２６５によって導入されたタイルと呼ばれる機能により、水平及び垂直方向にそれぞれ２等分され、合計４つのタイルに分割される。また、スライスセグメントとタイルは１対１に対応付けられる。
【００３８】
このように水平及び垂直方向に２等分する理由について説明する。まず、復号時には、一般的に水平１ラインのデータを格納するラインメモリが必要となるが、８Ｋ４Ｋなどの超高解像度になると、水平方向のサイズが大きくなるためラインメモリのサイズが増加する。受信装置の実装においては、ラインメモリのサイズを低減できることが望ましい。ラインメモリのサイズを低減するためには垂直方向の分割が必要となる。垂直方向の分割にはタイルというデータ構造が必要である。これらの理由により、タイルが用いられる。
【００３９】
一方で、画像は一般的に水平方向の相関が高いため、水平方向に広い範囲を参照できるほうが符号化効率は向上する。従って、符号化効率の観点ではアクセスユニットが水平方向に分割されることが望ましい。
【００４０】
アクセスユニットが水平及び垂直方向に２等分されることで、これら２つの特性を両立させ、実装面、及び符号化効率の両面を考慮できる。単一の復号器が４Ｋ２Ｋの動画像を実時間での復号が可能の場合には、８Ｋ４Ｋの画像が４等分され、各々のスライスセグメントが４Ｋ２Ｋとなるように分割されることで、受信装置は、８Ｋ４Ｋの画像を実時間で復号できる。
【００４１】
次に、アクセスユニットが水平及び垂直方向に分割されることで得られたタイルとスライスセグメントとを１対１に対応付ける理由について説明する。Ｈ．２６５においては、アクセスユニットは複数のＮＡＬ（Ｎｅｔｗｏｒｋ  Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ）ユニットと呼ばれる単位から構成される。
【００４２】
ＮＡＬユニットのペイロードは、アクセスユニットの開始位置を示すアクセスユニットデリミタ、シーケンス単位で共通に用いられる復号時の初期化情報であるＳＰＳ（Ｓｅｑｕｅｎｃｅ  Ｐａｒａｍｅｔｅｒ  Ｓｅｔ）、ピクチャ内で共通に用いられる復号時の初期化情報であるＰＰＳ（Ｐｉｃｔｕｒｅ  Ｐａｒａｍｅｔｅｒ  Ｓｅｔ）、復号処理自体には不要であるが復号結果の処理及び表示などにおいて必要となるＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ  Ｅｎｈａｎｃｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）、並びに、スライスセグメントの符号化データなどのいずれかを格納する。ＮＡＬユニットのヘッダは、ペイロードに格納されるデータを識別するためのタイプ情報を含む。
【００４３】
ここで、送信装置は、符号化データをＭＰＥＧ−２  ＴＳ、ＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）、ＭＰＥＧ  ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ
Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）、又は、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）などの多重化フォーマットによって多重化する際には、基本単位をＮＡＬユニットに設定できる。１つのスライスセグメントを１つのＮＡＬユニットに格納するためには、アクセスユニットを領域に分割する際に、スライスセグメント単位に分割することが望ましい。このような理由から、送信装置は、タイルとスライスセグメントとを１対１に対応付ける。
【００４４】
なお、図４に示すように、送信装置は、タイル１からタイル４までをまとめて１つのスライスセグメントに設定することも可能である。しかし、この場合には、１つのＮＡＬユニットに全てのタイルが格納されることになり、受信装置が、多重化レイヤにおいてタイルを分離することが困難である。
【００４５】
なお、スライスセグメントには独立に復号可能な独立スライスセグメントと、独立スライスセグメントを参照する参照スライスセグメントとが存在するが、ここでは独立スライスセグメントが用いられる場合を説明する。
【００４６】
図５は、図３に示すようにタイルとスライスセグメントとの境界が一致するように分割されたアクセスユニットのデータの例を示す図である。アクセスユニットのデータは、先頭に配置されたアクセスユニットデリミタが格納されるＮＡＬユニットと、その後に配置されるＳＰＳ、ＰＰＳ、及びＳＥＩのＮＡＬユニットと、その後に配置されるタイル１からタイル４までのデータが格納されたスライスセグメントのデータとを含む。なお、アクセスユニットのデータは、ＳＰＳ、ＰＰＳ及びＳＥＩのＮＡＬユニットの一部又は全てを含まなくてもよい。
【００４７】
次に、本実施の形態に係る送信装置１００の構成を説明する。図６は、本実施の形態に係る送信装置１００の構成例を示すブロック図である。この送信装置１００は、符号化部１０１と、多重化部１０２と、変調部１０３と、送信部１０４とを備える。
【００４８】
符号化部１０１は、入力画像を、例えば、Ｈ．２６５に従い符号化することで符号化データを生成する。また、符号化部１０１は、例えば、図３に示すように、アクセスユニットを４つのスライスセグメント（タイル）に分割し、各スライスセグメントを符号化する。
【００４９】
多重化部１０２は、符号化部１０１により生成された符号化データを多重化する。変調部１０３は、多重化により得られたデータを変調する。送信部１０４は、変調後のデータを放送信号として送信する。
【００５０】
次に、本実施の形態に係る受信装置２００の構成を説明する。図７は、本実施の形態に係る受信装置２００の構成例を示すブロック図である。この受信装置２００は、チューナー２０１と、復調部２０２と、逆多重化部２０３と、複数の復号部２０４Ａ〜２０４Ｄと、表示部２０５とを備える。
【００５１】
チューナー２０１は、放送信号を受信する。復調部２０２は、受信された放送信号を復調する。復調後のデータは逆多重化部２０３に入力される。
【００５２】
逆多重化部２０３は、復調後のデータを分割単位に分離し、分割単位毎のデータを復号部２０４Ａ〜２０４Ｄに出力する。ここで、分割単位とは、アクセスユニットが分割されることで得られた分割領域であり、例えば、Ｈ．２６５におけるスライスセグメントである。また、ここでは、８Ｋ４Ｋの画像が４つの４Ｋ２Ｋの画像に分割される。よって、４つの復号部２０４Ａ〜２０４Ｄが存在する。
【００５３】
複数の復号部２０４Ａ〜２０４Ｄは、所定の基準クロックに基づいて互いに同期して動作する。各復号部は、アクセスユニットのＤＴＳ（Ｄｅｃｏｄｉｎｇ  Ｔｉｍｅ  Ｓｔａｍｐ）に従って分割単位の符号化データを復号し、復号結果を表示部２０５に出力する。
【００５４】
表示部２０５は、複数の復号部２０４Ａ〜２０４Ｄから出力された複数の復号結果を統合することで８Ｋ４Ｋの出力画像を生成する。表示部２０５は、別途取得したアクセスユニットのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ  Ｓｔａｍｐ）に従って、生成された出力画像を表示する。なお、表示部２０５は、復号結果を統合する際に、タイルの境界など、互いに隣接する分割単位の境界領域において、当該境界が視覚的に目立たなくなるようにデブロックフィルタなどのフィルタ処理を行ってもよい。
【００５５】
なお、上記では、放送の送信又は受信を行う送信装置１００及び受信装置２００を例に説明したが、コンテンツは通信ネットワーク経由で送信及び受信されてもよい。受信装置２００が、通信ネットワーク経由でコンテンツを受信する場合には、受信装置２００は、イーサーネットなどのネットワークにより受信したＩＰパケットから多重化データを分離する。
【００５６】
放送においては、放送信号が送信されてから受信装置２００に届くまでの間の伝送路遅延は一定である。一方、インターネットなどの通信ネットワークにおいては輻輳の影響により、サーバーから送信されたデータが受信装置２００に届くまでの伝送路遅延は一定でない。従って、受信装置２００は、放送のＭＰＥＧ−２  ＴＳにおけるＰＣＲのような基準クロックに基づいた厳密な同期再生を行わないことが多い。そのため、受信装置２００は、各復号部を厳密に同期させることはせずに、表示部において８Ｋ４Ｋの出力画像をＰＴＳに従って表示してもよい。
【００５７】
また、通信ネットワークの輻輳などにより、全ての分割単位の復号処理がアクセスユニットのＰＴＳで示される時刻において完了していない場合がある。この場合には、受信装置２００は、アクセスユニットの表示をスキップする、又は、少なくとも４つの分割単位の復号が終了し、８Ｋ４Ｋの画像の生成が完了するまで表示を遅延させる。
【００５８】
なお、放送と通信とを併用してコンテンツが送信及び受信されてもよい。また、ハードディスク又はメモリなどの記録媒体に格納された多重化データを再生する際にも本手法を適用可能である。
【００５９】
次に、多重化方式としてＭＭＴが用いられる場合の、スライスセグメントに分割されたアクセスユニットの多重化方法にについて説明する。
【００６０】
図８は、ＨＥＶＣのアクセスユニットのデータを、ＭＭＴにパケット化する際の例を示す図である。ＳＰＳ、ＰＰＳ及びＳＥＩなどはアクセスユニットに必ずしも含まれる必要はないが、ここでは存在する場合について例示する。
【００６１】
アクセスユニットデリミタ、ＳＰＳ、ＰＰＳ、及びＳＥＩなどのアクセスユニット内で先頭のスライスセグメントよりも前に配置されるＮＡＬユニットは一纏めにしてＭＭＴパケット＃１に格納される。後続のスライスセグメントは、スライスセグメント毎に別々のＭＭＴパケットに格納される。
【００６２】
なお、図９に示すように、アクセスユニット内で先頭のスライスセグメントよりも前に配置されるＮＡＬユニットが、先頭のスライスセグメントと同一のＭＭＴパケットに格納されてもよい。
【００６３】
また、シーケンス又はストリームの終端を示す、Ｅｎｄ−ｏｆ−Ｓｅｑｕｅｎｃｅ又はＥｎｄ−ｏｆ−ＢｉｔｓｔｒｅａｍなどのＮＡＬユニットが最終スライスセグメントの後に付加される場合には、これらは、最終スライスセグメントと同一のＭＭＴパケットに格納される。ただし、Ｅｎｄ−ｏｆ−Ｓｅｑｕｅｎｃｅ又はＥｎｄ−ｏｆ−ＢｉｔｓｔｒｅａｍなどのＮＡＬユニットは、復号処理の終了ポイント、又は２本のストリームの接続ポイントなどに挿入されるため、受信装置２００が、これらのＮＡＬユニットを、多重化レイヤにおいて容易に取得できることが望ましい場合がある。この場合には、これらのＮＡＬユニットは、スライスセグメントとは別のＭＭＴパケットに格納されてもよい。これにより、受信装置２００は、多重化レイヤにおいてこれらのＮＡＬユニットを容易に分離できる。
【００６４】
なお、多重化方式として、ＴＳ、ＤＡＳＨ又はＲＴＰなどが用いられてもよい。これらの方式においても、送信装置１００は、異なるスライスセグメントをそれぞれ異なるパケットに格納する。これにより、受信装置２００が多重化レイヤにおいてスライスセグメントを分離できることを保証できる。
【００６５】
例えば、ＴＳが用いられる場合、スライスセグメント単位で符号化データがＰＥＳパケット化される。ＲＴＰが用いられる場合、スライスセグメント単位で符号化データがＲＴＰパケット化される。これらの場合においても、図８に示すＭＭＴパケット＃１のように、スライスセグメントよりも前に配置されるＮＡＬユニットとスライスセグメントとが別々にパケット化されてもよい。
【００６６】
ＴＳが用いられる場合、送信装置１００は、ｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子を用いることなどにより、ＰＥＳパケットに格納されるデータの単位を示す。また、ＤＡＳＨはセグメントと呼ばれるＭＰ４形式のデータ単位をＨＴＴＰなどによりダウンロードする方式であるため、送信装置１００は、送信にあたって符号化データのパケット化は行わない。このため、送信装置１００は、受信装置２００がＭＰ４において多重化レイヤでスライスセグメントを検出できるように、スライスセグメント単位でサブサンプルを作成し、サブサンプルの格納位置を示す情報をＭＰ４のヘッダに格納してもよい。
【００６７】
以下、スライスセグメントのＭＭＴパケット化について、詳細に説明する。
【００６８】
図８に示すように、符号化データがパケット化されることで、ＳＰＳ及びＰＰＳなどのアクセスユニット内の全スライスセグメントの復号時に共通に参照されるデータがＭＭＴパケット＃１に格納される。この場合、受信装置２００は、ＭＭＴパケット＃１のペイロードデータと各スライスセグメントのデータとを連結し、得られたデータを復号部に出力する。このように、受信装置２００は、複数のＭＭＴパケットのペイロードを連結することで、復号部への入力データを容易に生成できる。
【００６９】
図１０は、図８に示すＭＭＴパケットから復号部２０４Ａ〜２０４Ｄへの入力データが生成される例を示す図である。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃２とのペイロードデータを連結させることで、復号部２０４Ａが、スライスセグメント１を復号するために必要なデータを生成する。逆多重化部２０３は、復号部２０４Ｂから復号部２０４Ｄについても、同様に入力データを生成する。つまり、逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃３とのペイロードデータを連結させることで、復号部２０４Ｂの入力データを生成する。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃４とのペイロードデータを連結させることで、復号部２０４Ｃの入力データを生成する。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃５とのペイロードデータを連結させることで、復号部２０４Ｄの入力データを生成する。
【００７０】
なお、逆多重化部２０３は、アクセスユニットデリミタ及びＳＥＩなど、復号処理に必要ではないＮＡＬユニットを、ＭＭＴパケット＃１のペイロードデータから除去し、復号処理に必要であるＳＰＳ及びＰＰＳのＮＡＬユニットのみを分離してスライスセグメントのデータに付加してもよい。
【００７１】
図９に示すように符号化データがパケット化される場合には、逆多重化部２０３は、多重化レイヤにおいてアクセスユニットの先頭データを含むＭＭＴパケット＃１を１番目の復号部２０４Ａに出力する。また、逆多重化部２０３は、多重化レイヤにおいてアクセスユニットの先頭データを含むＭＭＴパケットを解析し、ＳＰＳ及びＰＰＳのＮＡＬユニットを分離し、分離したＳＰＳ及びＰＰＳのＮＡＬユニットを２番目以降のスライスセグメントのデータの各々に付加することで２番目以降の復号部の各々に対する入力データを生成する。
【００７２】
さらに、受信装置２００が、ＭＭＴパケットのヘッダに含まれる情報を用いて、ＭＭＴペイロードに格納されるデータのタイプ、及び、ペイロードにスライスセグメントが格納されている場合のアクセスユニット内における当該スライスセグメントのインデックス番号を識別できることが望ましい。ここで、データのタイプとは、スライスセグメント前データ（アクセスユニット内で先頭スライスセグメントよりも前に配置されるＮＡＬユニットをまとめて、このように呼ぶことにする）、及び、スライスセグメントのデータのいずれである。ＭＭＴパケットに、スライスセグメントなどのＭＰＵをフラグメント化した単位を格納する場合には、ＭＦＵ（Ｍｅｄｉａ  Ｆｒａｇｍｅｎｔ  Ｕｎｉｔ）を格納するためのモードが用いられる。送信装置１００は、本モードを用いる場合には、例えば、ＭＦＵにおけるデータの基本単位であるＤａｔａ  Ｕｎｉｔを、サンプル（ＭＭＴにおけるデータ単位であり、アクセスユニットに相当する）、又は、サブサンプル（サンプルを分割した単位）に設定できる。
【００７３】
このとき、ＭＭＴパケットのヘッダは、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒと呼ばれるフィールドと、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒと呼ばれるフィールドとを含む。
【００７４】
Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒは、ＭＭＴパケットのペイロードに格納されるデータが、Ｄａｔａ  ｕｎｉｔをフラグメント化したものであるかどうか、フラグメント化したものである場合には、当該フラグメントがＤａｔａ  ｕｎｉｔにおける先頭或いは最終のフラグメント、又は、先頭と最終とのどちらでもないフラグメントであるかを示す。言い換えると、あるパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒは、（１）基本データ単位であるＤａｔａ  ｕｎｉｔに当該パケットのみが含まれる、（２）Ｄａｔａ  ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ  ｕｎｉｔの先頭のパケットである、（３）Ｄａｔａ  ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ  ｕｎｉｔの先頭及び最後以外のパケットである、及び、（４）Ｄａｔａ  ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ  ｕｎｉｔの最後のパケットである、のいずれであるかを示す識別情報である。
【００７５】
Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒは、ＭＭＴパケットに格納されるデータが、Ｄａｔａ  ｕｎｉｔにおいて何番目のフラグメントに相当するかを示すインデックス番号である。
【００７６】
従って、送信装置１００が、ＭＭＴにおけるサンプルをＤａｔａ  ｕｎｉｔに設定し、スライスセグメント前データ、及び、各スライスセグメントを、それぞれＤａｔａ  ｕｎｉｔのフラグメント単位に設定することで、受信装置２００は、ＭＭＴパケットのヘッダに含まれる情報を用いて、ペイロードに格納されるデータのタイプが識別できる。つまり、逆多重化部２０３は、ＭＭＴパケットのヘッダを参照して、各復号部２０４Ａ〜２０４Ｄへの入力データを生成できる。
【００７７】
図１１は、サンプルがＤａｔａ  ｕｎｉｔに設定され、スライスセグメント前データ、及び、スライスセグメントがＤａｔａ  ｕｎｉｔのフラグメントとしてパケット化される場合の例を示す図である。
【００７８】
スライスセグメント前データ、及びスライスセグメントは、フラグメント＃１からフラグメント＃５までの５つのフラグメントに分割される。各フラグメントは個別のＭＭＴパケットに格納される。このとき、ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒ及びＦｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒの値は図示する通りである。
【００７９】
例えば、Ｆｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒは、２進数の２ビット値である。Ｄａｔａ  ｕｎｉｔの先頭であるＭＭＴパケット＃１のＦｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒ、最終であるＭＭＴパケット＃５のＦｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒ、及び、その間のパケットであるＭＭＴパケット＃２からＭＭＴパケット＃４までのＦｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒは、それぞれ別の値に設定される。具体的には、Ｄａｔａ  ｕｎｉｔの先頭であるＭＭＴパケット＃１のＦｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒは０１に設定され、最終であるＭＭＴパケット＃５のＦｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒは１１に設定され、その間のパケットであるＭＭＴパケット＃２からＭＭＴパケット＃４までのＦｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒは１０に設定される。なお、Ｄａｔａ  ｕｎｉｔに一つのＭＭＴパケットのみが含まれる場合には、Ｆｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒは００に設定される。
【００８０】
また、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒは、ＭＭＴパケット＃１においてはフラグメントの総数である５から１を減算した値である４であり、後続パケットにおいては順に１ずつ減少し、最後のＭＭＴパケット＃５においては０である。
【００８１】
従って、受信装置２００は、スライスセグメント前データを格納するＭＭＴパケットを、Ｆｒａｇｍｅｎｔ  ｉｎｄｉｃａｔｏｒ、及び、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒのいずれかを用いて識別できる。また、受信装置２００は、Ｎ番目のスライスセグメントを格納するＭＭＴパケットを、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒを参照することにより識別できる。
【００８２】
ＭＭＴパケットのヘッダは、別途、Ｄａｔａ  ｕｎｉｔが属するＭｏｖｉｅ  ＦｒａｇｍｅｎｔのＭＰＵ内でのシーケンス番号と、ＭＰＵ自体のシーケンス番号と、Ｄａｔａ  ｕｎｉｔが属するサンプルのＭｏｖｉｅ  Ｆｒａｇｍｅｎｔ内におけるシーケンス番号とを含む。逆多重化部２０３は、これらを参照することで、Ｄａｔａ  ｕｎｉｔが属するサンプルを一意に決定できる。
【００８３】
更に、逆多重化部２０３は、Ｄａｔａ  ｕｎｉｔ内におけるフラグメントのインデックス番号をＦｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒなどから決定できるため、パケットロスが発生した場合にも、フラグメントに格納されるスライスセグメントを一意に特定できる。例えば、逆多重化部２０３は、図１１に示すフラグメント＃４がパケットロスにより取得できなかった場合でも、フラグメント＃３の次に受信したフラグメントがフラグメント＃５であることが分かるため、フラグメント＃５に格納されるスライスセグメント４を、復号部２０４Ｃではなく復号部２０４Ｄに正しく出力することができる。
【００８４】
なお、パケットロスが発生しないことが保証される伝送路が使用される場合には、逆多重化部２０３は、ＭＭＴパケットのヘッダを参照してＭＭＴパケットに格納されるデータのタイプ、又はスライスセグメントのインデックス番号を決定せずに、到着したパケットを周期的に処理すればよい。例えば、アクセスユニットが、スライス前データ、及び、４つのスライスセグメントの計５つのＭＭＴパケットにより送信される場合には、受信装置２００は、復号を開始するアクセスユニットのスライス前データを決定した後は、受信したＭＭＴパケットを順に処理することで、スライス前データ、及び、４つのスライスセグメントのデータを順に取得できる。
【００８５】
以下、パケット化の変形例について説明する。
【００８６】
スライスセグメントは、必ずしもアクセスユニットの面内を水平方向と垂直方向との両方に分割されたものである必要はなく、図１に示すように、アクセスユニットを水平方向のみに分割されたものでもよいし、垂直方向のみに分割されたものでもよい。
【００８７】
また、水平方向のみにアクセスユニットが分割される場合には、タイルが用いられる必要はない。
【００８８】
また、アクセスユニットにおける面内の分割数は任意であり、４つに限定されるものではない。但し、スライスセグメント及びタイルの領域サイズはＨ．２６５などの符号化規格の下限以上である必要がある。
【００８９】
送信装置１００は、アクセスユニットにおける面内の分割方法を示す識別情報を、ＭＭＴメッセージ、又はＴＳのデスクリプタなどに格納してもよい。例えば、面内における水平方向と垂直方向との分割数とをそれぞれ示す情報が格納されてもよい。または、図３に示すように水平方向及び垂直方向にそれぞれ２等分されている、又は、図１に示すように水平方向に４等分されているなど、分割方法に対して固有の識別情報が割り当てられてもよい。例えば、図３に示すようにアクセスユニットが分割されている場合は、識別情報はモード１を示し、図１に示すようにアクセスユニットが分割されている場合には、識別情報はモード１を示す。
【００９０】
また、面内の分割方法に関連する符号化条件の制約を示す情報が、多重化レイヤに含まれてもよい。例えば、１つのスライスセグメントが１つのタイルから構成されること示す情報が用いられてもよい。または、スライスセグメント或いはタイルの復号時に動き補償を行う場合の参照ブロックが、画面内の同一位置のスライスセグメント或いはタイルに制限される、又は、隣接スライスセグメントにおける所定の範囲内のブロックに限定されることなどを示す情報が用いられてもよい。
【００９１】
また、送信装置１００は、動画像の解像度に応じて、アクセスユニットを複数のスライスセグメントに分割するかどうかを切替えてもよい。例えば、送信装置１００は、処理対象の動画像が４Ｋ２Ｋの解像度の場合には面内の分割を行わずに、処理対象の動画像が８Ｋ４Ｋの場合にはアクセスユニットを４つに分割してもよい。８Ｋ４Ｋの動画像の場合の分割方法を予め規定しておくことにより、受信装置２００は、受信する動画像の解像度を取得することで、面内の分割の有無、及び分割方法を決定し、復号動作を切替えることができる。
【００９２】
また、受信装置２００は、面内の分割の有無を、ＭＭＴパケットのヘッダを参照することにより検出できる。例えば、アクセスユニットが分割されない場合には、ＭＭＴのＤａｔａ  ｕｎｉｔがサンプルに設定されていれば、Ｄａｔａ  ｕｎｉｔのフラグメントは行われない。従って、受信装置２００は、ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒの値が常にゼロの場合には、アクセスユニットは分割されないと判定できる。または、受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒの値が常に０１であるかどうかを検出してもよい。受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒの値が常に０１の場合もアクセスユニットは分割されないと判定できる。
【００９３】
また、受信装置２００は、アクセスユニットにおける面内の分割数と復号部の数とが一致しない場合にも対応できる。例えば、受信装置２００が、８Ｋ２Ｋの符号化データを実時間で復号できる２つの復号部２０４Ａ及び２０４Ｂを備える場合には、逆多重化部２０３は、復号部２０４Ａに対して、８Ｋ４Ｋの符号化データを構成する４つのスライスセグメントのうちの２つを出力する。
【００９４】
図１２は、図８に示すようにＭＭＴパケット化されたデータが、２つの復号部２０４Ａ及び２０４Ｂに入力される場合の動作例を示す図である。ここで、受信装置２００は、復号部２０４Ａ及び２０４Ｂにおける復号結果を、そのまま統合して出力できることが望ましい。よって、逆多重化部２０３は、復号部２０４Ａ及び２０４Ｂの各々の復号結果が空間的に連続するように、復号部２０４Ａ及び２０４Ｂの各々に出力するスライスセグメントを選択する。
【００９５】
また、逆多重化部２０３は、動画像の符号化データの解像度又はフレームレートなどに応じて、使用する復号部を選択してもよい。例えば、受信装置２００が４Ｋ２Ｋの復号部を４つ備える場合には、入力画像の解像度が８Ｋ４Ｋであれば、受信装置２００は、４つ全ての復号部を用いて復号処理を行う。また、受信装置２００は、入力画像の解像度が４Ｋ２Ｋであれば１つの復号部のみを用いて復号処理を行う。または、逆多重化部２０３は、面内が４つに分割されていても、８Ｋ４Ｋを単一の復号部により実時間で復号できる場合には、全ての分割単位を統合して一つの復号部に出力する。
【００９６】
さらに、受信装置２００は、フレームレートを考慮して使用する復号部を決定してもよい。例えば、受信装置２００が、解像度が８Ｋ４Ｋである場合に実時間で復号可能なフレームレートの上限が６０ｆｐｓである復号部を２台備える場合に、８Ｋ４Ｋで１２０ｆｐｓの符号化データが入力されるケースがある。このとき、面内が４つの分割単位から構成されるとすると、図１２の例と同様に、スライスセグメント１とスライスセグメント２とが復号部２０４Ａに入力され、スライスセグメント３とスライスセグメント４とが復号部２０４Ｂに入力される。各々の復号部２０４Ａ及び２０４Ｂは、８Ｋ２Ｋ（解像度が８Ｋ４Ｋの半分）であれば１２０ｆｐｓまで実時間で復号できるため、これら２台の復号部２０４Ａ及び２０４Ｂにより復号処理が行われる。
【００９７】
また、解像度及びフレームレートが同一であっても、符号化方式におけるプロファイル、或いはレベル、又は、Ｈ．２６４或いはＨ．２６５など符号化方式自体が異なると処理量が異なる。よって、受信装置２００は、これらの情報に基づいて使用する復号部を選択してもよい。なお、受信装置２００は、放送又は通信により受信した符号化データを全て復号することができない場合、又は、ユーザーが選択した領域を構成する全てのスライスセグメント又はタイルが復号できない場合には、復号部の処理範囲内で復号可能なスライスセグメント又はタイルを自動的に決定してもよい。または、受信装置２００は、ユーザーが復号する領域を選択するためのユーザインタフェースを提供してもよい。このとき、受信装置２００は、全て領域を復号できないことを示す警告メッセージを表示してもよいし、復号可能な領域、スライスセグメント又はタイルの個数を示す情報を表示してもよい。
【００９８】
また、上記方法は、同一符号化データのスライスセグメントを格納するＭＭＴパケットが、放送及び通信など複数の伝送路を用いて送信及び受信される場合にも適用できる。
【００９９】
また、送信装置１００は、分割単位の境界を目立たなくするために、各スライスセグメントの領域がオーバーラップするように符号化を行ってもよい。図１３に示す例では、８Ｋ４Ｋのピクチャが４つのスライスセグメント１〜４に分割される。スライスセグメント１〜３の各々は、例えば、８Ｋ×１．１Ｋであり、スライスセグメント４は８Ｋ×１Ｋである。また、隣接するスライスセグメントは互いにオーバーラップする。こうすることで、点線で示す４分割した場合の境界においては、符号化時の動き補償が効率的に実行できるため、境界部分の画質が向上する。このように、境界部分の画質劣化が低減される。
【０１００】
この場合、表示部２０５は、８Ｋ×１．１Ｋの領域から、８Ｋ×１Ｋの領域を切り出し、得られた領域を統合する。なお、送信装置１００は、スライスセグメントがオーバーラップして符号化されているかどうか、及び、オーバーラップの範囲を示す情報を、多重化レイヤ、又は、符号化データ内に含めて、別途送信してもよい。
【０１０１】
なお、タイルが使用される場合にも、同様の手法を適用可能である。
【０１０２】
以下、送信装置１００の動作の流れを説明する。図１４は、送信装置１００の動作例を示すフローチャートである。
【０１０３】
まず、符号化部１０１は、ピクチャ（アクセスユニット）を複数の領域である複数のスライスセグメント（タイル）に分割する（Ｓ１０１）。次に、符号化部１０１は、複数のスライスセグメントの各々を独立して復号が可能なように符号化することで、複数のスライスセグメントの各々に対応する符号化データを生成する（Ｓ１０２）。なお、符号化部１０１は、複数のスライスセグメントを単一の符号化部で符号化してもよし、複数の符号化部で並列処理してもよい。
【０１０４】
次に、多重化部１０２は、符号化部１０１で生成された複数の符号化データを、複数のＭＭＴパケットに格納することで、複数の符号化データを多重化する（Ｓ１０３）。具体的には、図８及び図９に示すように、多重化部１０２は、一つのＭＭＴパケットに、異なるスライスセグメントに対応する符号化データが格納されないように、複数の符号化データを複数のＭＭＴパケットに格納する。また、多重化部１０２は、図８に示すように、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報を、複数の符号化データが格納される複数のＭＭＴパケット＃２〜＃５とは異なるＭＭＴパケット＃１に格納する。ここで制御情報は、アクセスユニットデリミタ、ＳＰＳ，ＰＰＳ及びＳＥＩのうち少なくとも一つを含む。
【０１０５】
なお、多重化部１０２は、制御情報を、複数の符号化データが格納される複数のＭＭＴパケットのいずれかと同じＭＭＴパケットに格納してもよい。例えば、図９に示すように、多重化部１０２は、制御情報を、複数の符号化データが格納される複数のＭＭＴパケットのうちの先頭のＭＭＴパケット（図９のＭＭＴパケット＃１）に格納してもよい。
【０１０６】
最後に、送信装置１００は、複数のＭＭＴパケットを送信する。具体的には、変調部１０３は、多重化により得られたデータを変調し、送信部１０４は、変調後のデータを送信する（Ｓ１０４）。
【０１０７】
図１５は、受信装置２００の構成例を示すブロック図であり、図７に示す逆多重化部２０３及びその後段の構成を詳細に示す図である。図１５に示すように、受信装置２００は、さらに、復号命令部２０６を備える。また、逆多重化部２０３は、タイプ判別部２１１と、制御情報取得部２１２と、スライス情報取得部２１３と、復号データ生成部２１４とを備える。
【０１０８】
以下、受信装置２００の動作の流れを説明する。図１６は、受信装置２００の動作例を示すフローチャートである。ここでは、１つのアクセスユニットに対する動作を示す。複数のアクセスユニットの復号処理が実行される場合には、本フローチャートの処理が繰り返される。
【０１０９】
まず、受信装置２００は、は、例えば、送信装置１００により生成された複数のパケット（ＭＭＴパケット）を受信する（Ｓ２０１）。
【０１１０】
次に、タイプ判別部２１１は、受信パケットのヘッダを解析することで、受信パケットに格納されている符号化データのタイプを取得する（Ｓ２０２）。
【０１１１】
次に、タイプ判別部２１１は、取得された符号化データのタイプに基づき、受信パケットに格納されているデータがスライスセグメント前データであるか、スライスセグメントのデータであるかを判定する（Ｓ２０３）。
【０１１２】
受信パケットに格納されているデータがスライスセグメント前データである場合（Ｓ２０３でＹｅｓ）、制御情報取得部２１２は、受信パケットのペイロードから処理対象のアクセスユニットのスライスセグメント前データを取得し、当該スライスセグメント前データをメモリに格納する（Ｓ２０４）。
【０１１３】
一方、受信パケットに格納されているデータがスライスセグメントのデータである場合（Ｓ２０３でＮｏ）、受信装置２００は、受信パケットのヘッダ情報を用いて、当該受信パケットに格納されているデータが、複数の領域のうちいずれの領域の符号化データであるかを判定する。具体的には、スライス情報取得部２１３は、受信パケットのヘッダを解析することで、受信パケットに格納されているスライスセグメントのインデックス番号Ｉｄｘを取得する（Ｓ２０５）。具体的には、インデックス番号Ｉｄｘは、アクセスユニット（ＭＭＴにおけるサンプル）のＭｏｖｉｅ  Ｆｒａｇｍｅｎｔ内におけるインデックス番号である。
【０１１４】
なお、このステップＳ２０５の処理は、ステップＳ２０２においてまとめて行われてもよい。
【０１１５】
次に、復号データ生成部２１４は、当該スライスセグメントを復号する復号部を決定する（Ｓ２０６）。具体的には、インデックス番号Ｉｄｘと複数の復号部とは予め対応付けられており、復号データ生成部２１４は、ステップＳ２０５で取得されたインデックス番号Ｉｄｘに対応する復号部を、当該スライスセグメントを復号する復号部を決定する。
【０１１６】
なお、復号データ生成部２１４は、図１２の例において説明したように、アクセスユニット（ピクチャ）の解像度、アクセスユニットの複数のスライスセグメント（タイル）への分割方法、及び受信装置２００が備える複数の復号部の処理能力の少なくとも一つに基づき、当該スライスセグメントを復号する復号部を決定してもよい。例えば、復号データ生成部２１４は、アクセスユニットの分割方法を、ＭＭＴのメッセージ、又はＴＳのセクションなどのデスクリプタにおける識別情報に基づいて判別する。
【０１１７】
次に、復号データ生成部２１４は、複数のパケットのいずれかに含まれる、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報と、複数のスライスセグメントの複数の符号化データの各々とを結合することで、複数の復号部へ入力される複数の入力データ（結合データ）を生成する。具体的には、復号データ生成部２１４は、受信パケットのペイロードからスライスセグメントのデータを取得する。復号データ生成部２１４は、ステップＳ２０４でメモリに格納されたスライスセグメント前データと、取得されたスライスセグメントのデータとを結合することで、ステップＳ２０６で決定された復号部への入力データを生成する（Ｓ２０７）。
【０１１８】
ステップＳ２０４又はＳ２０７の後、受信パケットのデータがアクセスユニットの最終データでない場合（Ｓ２０８でＮｏ）、ステップＳ２０１以降の処理が再度行われる。つまり、アクセスユニットに含まれる全てのスライスセグメントに対応する、複数の復号部２０４Ａ〜２０４Ｄへの入力データが生成されるまで、上記処理が繰り返される。
【０１１９】
なお、パケットが受信されるタイミングは、図１６に示すタイミングに限らず、予め又は順次複数のパケットが受信され、メモリ等に格納されてもよい。
【０１２０】
一方、受信パケットのデータがアクセスユニットの最終データである場合（Ｓ２０８でＹｅｓ）、復号命令部２０６は、ステップＳ２０７で生成された、複数の入力データを、対応する復号部２０４Ａ〜２０４Ｄへ出力する（Ｓ２０９）。
【０１２１】
次に、複数の復号部２０４Ａ〜２０４Ｄは、アクセスユニットのＤＴＳに従い、複数の入力データを並列に復号することで、複数の復号画像を生成する（Ｓ２１０）。
【０１２２】
最後に、表示部２０５は、複数の復号部２０４Ａ〜２０４Ｄで生成された複数の復号画像を結合することで表示画像を生成し、アクセスユニットのＰＴＳに従い当該表示画像を表示する（Ｓ２１１）。
【０１２３】
なお、受信装置２００は、アクセスユニットのＤＴＳ及びＰＴＳを、ＭＰＵのヘッダ情報、又は、Ｍｏｖｉｅ  Ｆｒａｇｍｅｎｔのヘッダ情報を格納するＭＭＴパケットのペイロードデータを解析することにより取得する。また、受信装置２００は、多重化方式としてＴＳが使用されている場合にはＰＥＳパケットのヘッダからアクセスユニットのＤＴＳ及びＰＴＳを取得する。受信装置２００は、多重化方式としてＲＴＰが使用されている場合にはＲＴＰパケットのヘッダからアクセスユニットのＤＴＳ及びＰＴＳを取得する。
【０１２４】
また、表示部２０５は、複数の復号部の復号結果を統合する際に、隣接する分割単位の境界においてデブロックフィルタなどのフィルタ処理を行ってもよい。なお、単一の復号部の復号結果を表示する場合にはフィルタ処理は不要であるため、表示部２０５は、複数の復号部の復号結果の境界にフィルタ処理を行うかどうかに応じて処理を切替えてもよい。フィルタ処理が必要かどうかは、分割の有無などに応じて予め規定されていてもよい。または、フィルタ処理が必要かどうかを示す情報が、多重化レイヤに別途格納されてもよい。また、フィルタ係数などフィルタ処理に必要な情報は、ＳＰＳ、ＰＰＳ、ＳＥＩ、又はスライスセグメント内に格納される場合がある。復号部２０４Ａ〜２０４Ｄ、又は逆多重化部２０３がＳＥＩを解析することによりこれらの情報を取得し、取得された情報を表示部２０５に出力する。表示部２０５は、これらの情報を用いてフィルタ処理を行う。なお、これらの情報がスライスセグメント内に格納される場合には、復号部２０４Ａ〜２０４Ｄがこれらの情報を取得することが望ましい。
【０１２５】
なお、上記説明では、フラグメントに格納されるデータの種類がスライスセグメント前データとスライスセグメントとの２種類である場合の例を示したが、データの種類は３種類以上であってもよい。この場合には、ステップＳ２０３においてタイプに応じた場合分けが行われる。
【０１２６】
また、送信装置１００は、スライスセグメントのデータサイズが大きい場合にスライスセグメントをフラグメント化してＭＭＴパケットに格納してもよい。つまり、送信装置１００は、スライスセグメント前データ及びスライスセグメントをフラグメント化してもよい。この場合に、図１１に示したパケット化の例のようにアクセスユニットとＤａｔａ  ｕｎｉｔとを等しく設定すると以下の問題が生じる。
【０１２７】
例えばスライスセグメント１が３つのフラグメントに分割される場合、スライスセグメント１がＦｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒ値が１から３の３つのパケットに分割して送信される。また、スライスセグメント２以降では、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒ値が４以上となり、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒの値とペイロードに格納されるデータとの対応付けが取れなくなる。従って、受信装置２００は、ＭＭＴパケットのヘッダの情報から、スライスセグメントの先頭データを格納するパケットを特定できない。
【０１２８】
このような場合には、受信装置２００は、ＭＭＴパケットのペイロードのデータを解析して、スライスセグメントの開始位置を特定してもよい。ここで、Ｈ．２６４又はＨ．２６５においてＮＡＬユニットを多重化レイヤに格納する形式として、ＮＡＬユニットヘッダの直前に特定のビット列からなるスタートコードが付加されるバイトストリームフォーマットと呼ばれる形式と、ＮＡＬユニットのサイズを示すフィールドが付加されるＮＡＬサイズフォーマットと呼ばれる形式との２種類がある。
【０１２９】
バイトストリームフォーマットは、ＭＰＥＧ−２システム及びＲＴＰなどにおいて用いられる。ＮＡＬサイズフォーマットは、ＭＰ４、並びにＭＰ４を使用するＤＡＳＨ及びＭＭＴなどにおいて用いられる。
【０１３０】
バイトストリームフォーマットが用いられる場合、受信装置２００は、パケットの先頭データがスタートコードと一致するかどうかを解析する。受信装置２００は、パケットの先頭データがスタートコードと一致していれば、その後に続くＮＡＬユニットヘッダからＮＡＬユニットのタイプを取得することで、当該パケットに含まれるデータがスライスセグメントのデータであるかどうかを検出できる。
【０１３１】
一方、ＮＡＬサイズフォーマットの場合には、受信装置２００は、ビット列に基づいてＮＡＬユニットの開始位置を検出できない。従って、受信装置２００は、ＮＡＬユニットの開始位置を取得するために、アクセスユニットの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズ分だけデータの読出すことでポインタをシフトさせていく必要がある。
【０１３２】
但し、ＭＭＴにおけるＭＰＵ又はＭｏｖｉｅ  Ｆｒａｇｍｅｎｔのヘッダにおいて、サブサンプル単位のサイズが示され、サブサンプルがスライス前データ又はスライスセグメントに対応する場合には、受信装置２００は、サブサンプルのサイズ情報に基づいて各ＮＡＬユニットの開始位置を特定できる。そのため、送信装置１００は、サブサンプル単位の情報がＭＰＵ又はＭｏｖｉｅ  Ｆｒａｇｍｅｎｔに存在するかどうかを示す情報を、ＭＭＴにおけるＭＰＴなどの、受信装置２００がデータの受信開始時に取得する情報に含めてもよい。
【０１３３】
なお、ＭＰＵのデータはＭＰ４フォーマットをベースに拡張したものである。ＭＰ４においては、Ｈ．２６４又はＨ．２６５のＳＰＳ及びＰＰＳなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードとがある。また、このモードを特定するための情報がＳａｍｐｌｅＥｎｔｒｙのエントリ名として示される。格納可能なモードが用いられており、パラメータセットがサンプルに含まれる場合には、受信装置２００は、上述した方法によりパラメータセットを取得する。
【０１３４】
一方、格納できないモードが用いられている場合には、パラメータセットは、ＳａｍｐｌｅＥｎｔｒｙ内のＤｅｃｏｄｅｒ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎとして格納される、又は、パラメータセット用のストリームを用いて格納される。ここで、パラメータセット用のストリームは一般的には使用されていないので、送信装置１００は、Ｄｅｃｏｄｅｒ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎにパラメータセットを格納することが望ましい。この場合には、受信装置２００は、ＭＭＴパケットにおいてＭＰＵのメタデータ、又は、Ｍｏｖｉｅ  Ｆｒａｇｍｅｎｔのメタデータとしてとして送信されるＳａｍｐｌｅＥｎｔｒｙを解析して、アクセスユニットが参照するパラメータセットを取得する。
【０１３５】
パラメータセットがサンプルデータとして格納される場合には、受信装置２００は、ＳａｍｐｌｅＥｎｔｒｙを参照せずにサンプルデータのみを参照すれば復号に必要なパラメータセットが取得できる。このとき、送信装置１００は、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットを格納しなくてもよい。こうすることで、送信装置１００は、異なるＭＰＵにおいて同一のＳａｍｐｌｅＥｎｔｒｙを用いることができるので、ＭＰＵ生成時の送信装置１００の処理負荷を低減できる。さらに、受信装置２００がＳａｍｐｌｅＥｎｔｒｙ内のパラメータセットを参照する必要がなくなるというメリットがある。
【０１３６】
または、送信装置１００は、ＳａｍｐｌｅＥｎｔｒｙにデフォルトのパラメータセットを１つ格納し、アクセスユニットが参照するパラメータセットをサンプルデータに格納してもよい。従来のＭＰ４においては、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットを格納するのが一般的であったため、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが存在しない場合、再生を停止する受信装置が存在する可能性がある。上記の方法を用いることで、この問題を解決できる。
【０１３７】
または、送信装置１００は、デフォルトのパラメータセットとは異なるパラメータセットが使用される場合にのみ、サンプルデータにパラメータセットを格納してもよい。
【０１３８】
なお、両モード共に、パラメータセットをＳａｍｐｌｅＥｎｔｒｙに格納することは可能であるため、送信装置１００は、パラメータセットを常にＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙに格納し、受信装置２００は常にＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙからパラメータセットを取得してもよい。
【０１３９】
なお、ＭＭＴ規格においては、Ｍｏｏｖ及びＭｏｏｆなどＭＰ４のヘッダ情報は、ＭＰＵメタデータ、或いはムービーフラグメントメタデータとして伝送されるが、送信装置１００は、ＭＰＵメタデータ、および、ムービーフラグメントメタデータを必ずしも送信しなくてもよい。さらに、受信装置２００は、ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ  ｏｆ  Ｒａｄｉｏ  Ｉｎｄｕｓｔｒｉｅｓ  ａｎｄ  Ｂｕｓｉｎｅｓｓｅｓ）規格のサービス、アセットのタイプ、又は、ＭＰＵメタの伝送有無などに基づいて、サンプルデータ内にＳＰＳ及びＰＰＳが格納されるかどうかを判定することも可能である。
【０１４０】
図１７は、スライスセグメント前データ及び各スライスセグメントが、それぞれ異なるＤａｔａ  ｕｎｉｔに設定される場合の例を示す図である。
【０１４１】
図１７に示す例では、スライスセグメント前データ、及びスライスセグメント１からスライスセグメント４までのデータサイズは、それぞれＬｅｎｇｔｈ＃１からＬｅｎｇｔｈ＃５である。ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒ、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒ、及び、Ｏｆｆｓｅｔの各フィールド値は図中に示す通りである。
【０１４２】
ここで、Ｏｆｆｓｅｔは、ペイロードデータが属するサンプル（アクセスユニット又はピクチャ）の符号化データの先頭から、当該ＭＭＴパケットに含まれるペイロードデータ（符号化データ）の先頭バイトまでのビット長（オフセット）を示すオフセット情報である。なお、Ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒの値はフラグメントの総数から１を減算した値から開始するとして説明するが、他の値から開始してもよい。
【０１４３】
図１８は、Ｄａｔａ  ｕｎｉｔがフラグメント化される場合の例を示す図である。図１８に示す例では、スライスセグメント１が３つのフラグメントに分割され、それぞれＭＭＴパケット＃２からＭＭＴパケット＃４に格納される。このときも、各フラグメントのデータサイズを、それぞれＬｅｎｇｔｈ＃２＿１からＬｅｎｇｔｈ＃２＿３とすると、各フィールドの値は図中に示す通りである。
【０１４４】
このように、スライスセグメントなどのデータ単位がＤａｔａ  ｕｎｉｔに設定される場合、アクセスユニットの先頭、及びスライスセグメントの先頭は、ＭＭＴパケットヘッダのフィールド値に基づいて以下のように決定できる。
【０１４５】
Ｏｆｆｓｅｔの値が０であるパケットにおけるペイロードの先頭は、アクセスユニットの先頭である。
【０１４６】
Ｏｆｆｓｅｔの値が０とは異なる値であり、かつ、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｃａｔｏｒｎｏ値が００又は０１であるパケットのペイロードの先頭が、スライスセグメントの先頭である。
【０１４７】
また、Ｄａｔａ  ｕｎｉｔのフラグメント化が発生せず、パケットロスも発生しない場合には、受信装置２００は、アクセスユニットの先頭を検出した後に取得したスライスセグメントの数に基づいて、ＭＭＴパケットに格納されるスライスセグメントのインデックス番号を特定できる。
【０１４８】
また、スライスセグメント前データのＤａｔａ  ｕｎｉｔがフラグメント化される場合においても、同様に、受信装置２００は、アクセスユニット、及びスライスセグメントの先頭を検出できる。
【０１４９】
また、パケットロスが発生した場合、又は、スライスセグメント前データに含まれるＳＰＳ、ＰＰＳ及びＳＥＩが別々のＤａｔａ  ｕｎｉｔに設定された場合においても、受信装置２００は、ＭＭＴヘッダの解析結果に基づいてスライスセグメントの先頭データを格納したＭＭＴパケットを特定し、その後、スライスセグメントのヘッダを解析することで、ピクチャ（アクセスユニット）内におけるスライスセグメント又はタイルの開始位置を特定できる。スライスヘッダの解析に係る処理量は小さく、処理負荷は問題とならない。
【０１５０】
このように、複数のスライスセグメントの複数の符号化データの各々は、１以上のパケットに格納されるデータの単位である基本データ単位（Ｄａｔａ  ｕｎｉｔ）と一対一で対応付けられている。また、複数の符号化データの各々は、１以上のＭＭＴパケットに格納される。
【０１５１】
各ＭＭＴパケットのヘッダ情報は、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒ（識別情報）及びＯｆｆｓｅｔ（オフセット情報）を含む。
【０１５２】
受信装置２００は、受信装置２００は、値が００又は０１であるＦｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。具体的には、値が０でないＯｆｆｓｅｔと、値が００又は０１であるＦｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒとが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。
【０１５３】
また、図１７の例では、Ｄａｔａ  ｕｎｉｔの先頭は、アクセスユニットの先頭、又は、スライスセグメントの先頭のいずれかであり、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒの値は００又は０１である。さらに、受信装置２００は、ＮＡＬユニットのタイプを参照して、Ｄａｔａ  Ｕｎｉｔの先頭がアクセスユニットデリミタ、又は、スライスセグメントのどちらであるかを判定することで、Ｏｆｆｓｅｔを参照せずに、アクセスユニットの先頭、又は、スライスセグメントの先頭を検出することも可能である。
【０１５４】
このように、送信装置１００が、ＮＡＬユニットの先頭が必ずＭＭＴパケットのペイロードの先頭から開始されるようにパケット化を行うことで、スライスセグメント前データが複数のＤａｔａ  ｕｎｉｔに分割される場合も含めて、受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒ及びＮＡＬユニットヘッダを解析することにより、アクセスユニット、又は、スライスセグメントの先頭を検出できる。ＮＡＬユニットのタイプは、ＮＡＬユニットヘッダの先頭バイトに存在する。従って、受信装置２００は、ＭＭＴパケットのヘッダ部を解析する際に、追加で１バイト分のデータを解析することによりＮＡＬユニットのタイプが取得できる。
【０１５５】
オーディオの場合には、受信装置２００は、アクセスユニットの先頭が検出できればよく、Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒの値が００又は０１であるかどうかに基づいて判定すればよい。
【０１５６】
また、上述したように、分割復号ができるように符号化された符号化データをＭＰＥＧ−２  ＴＳのＰＥＳパケットに格納する場合には、送信装置１００は、ｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子を用いることが可能である。以下、符号化データのＰＥＳパケットへの格納方法の例について詳細に説明する。
【０１５７】
例えば、ＨＥＶＣにおいては、送信装置１００は、ｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子を用いることにより、ＰＥＳパケットに格納されるデータがアクセスユニット、スライスセグメント、及び、タイルのいずれであるかを示すことができる。ＨＥＶＣにおけるアラインメントのタイプは、次のように規定されている。
【０１５８】
アラインメントのタイプ＝８は、ＨＥＶＣのスライスセグメントを示す。アラインメントのタイプ＝９は、ＨＥＶＣのスライスセグメント又はアクセスユニットを示す。アラインメントのタイプ＝１２は、ＨＥＶＣのスライスセグメント又はタイルを示す。
【０１５９】
よって、送信装置１００は、例えば、タイプ９を用いることで、ＰＥＳパケットのデータがスライスセグメント又はスライスセグメント前データのいずれかであることを示すことができる。スライスセグメントではなく、スライスを示すタイプも別途規定されているため、送信装置１００は、スライスセグメントではなくスライスを示すタイプを使用してもよい。
【０１６０】
また、ＰＥＳパケットのヘッダに含まれるＤＴＳ及びＰＴＳは、アクセスユニットの先頭データを含むＰＥＳパケットにおいてのみ設定される。従って、受信装置２００は、タイプが９であり、かつ、ＰＥＳパケットにＤＴＳ又はＰＴＳのフィールドが存在すれば、ＰＥＳパケットにはアクセスユニット全体、又は、アクセスユニットにおける先頭の分割単位が格納されると判定できる。
【０１６１】
また、送信装置１００は、アクセスユニットの先頭データを含むＰＥＳパケットを格納するＴＳパケットの優先度を示すｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙなどのフィールドを用いて、受信装置２００がパケットに含まれるデータを区別できるようにしてもよい。また、受信装置２００は、ＰＥＳパケットのペイロードがアクセスユニットデリミタであるかどうかを解析することでパケットに含まれるデータを判定してもよい。また、ＰＥＳパケットヘッダのｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒは、これらのタイプに従ってＰＥＳパケットにデータが格納されているかどうかを示す。このフラグ（ｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒ）が１にセットされていれば、ＰＥＳパケットに格納されているデータはｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子に示されるタイプに従うことが保証される。
【０１６２】
また、送信装置１００は、スライスセグメントなどの分割復号可能な単位でＰＥＳパケット化する場合にのみｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子を使用してもよい。これにより、受信装置２００は、ｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子が存在する場合には、符号化データが分割復号可能な単位でＰＥＳパケット化されていると判断でき、ｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子が存在しなければ、符号化データがアクセスユニット単位でＰＥＳパケット化されていると判断できる。なお、ｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒが１にセットされており、ｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子が存在しない場合には、ＰＥＳパケット化の単位がアクセスユニットであることはＭＰＥＧ−２  ＴＳ規格において規定されている。
【０１６３】
受信装置２００は、ＰＭＴ内にｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子が含まれていれば、分割復号可能な単位でＰＥＳパケット化されていると判定し、パケット化された単位に基づいて、各復号部への入力データを生成することができる。また、受信装置２００は、ＰＭＴ内にｄａｔａ  ａｌｉｇｎｍｅｎｔ記述子が含まれておらず、番組情報、又はその他の記述子の情報に基づいて、符号化データの並列復号が必要と判定される場合には、スライスセグメントのスライスヘッダなどを解析することにより、各復号部への入力データを生成する。また、符号化データを単一の復号部により復号可能である場合には、受信装置２００は、アクセスユニット全体のデータを当該の復号部で復号する。なお、符号化データがスライスセグメント又はタイルなどの分割復号可能な単位から構成されるかどうかを示す情報が、ＰＭＴの記述子などにより別途示されている場合、受信装置２００は、当該記述子の解析結果に基づいて符号化データを並列復号できるかどうかを判定してもよい。
【０１６４】
また、ＰＥＳパケットのヘッダに含まれるＤＴＳ及びＰＴＳは、アクセスユニットの先頭データを含むＰＥＳパケットにおいてのみ設定されるため、アクセスユニットが分割されてＰＥＳパケット化される場合には、２番目以降のＰＥＳパケットにはアクセスユニットのＤＴＳ及びＰＴＳを示す情報は含まれない。従って、復号処理を並列に行う場合、各復号部２０４Ａ〜２０４Ｄ及び表示部２０５は、アクセスユニットの先頭データを含むＰＥＳパケットのヘッダに格納されるＤＴＳ及びＰＴＳを使用する。
【０１６５】
（実施の形態２）
実施の形態２では、ＭＭＴにおいて、ＮＡＬサイズフォーマットのデータをＭＰ４フォーマットベースのＭＰＵに格納する方法について説明する。なお、以下では、一例として、ＭＭＴに用いられるＭＰＵへの格納方法について説明するが、このような格納方法は、同じＭＰ４フォーマットベースであるＤＡＳＨにも適用可能である。
【０１６６】
［ＭＰＵへの格納方法］
ＭＰ４フォーマットでは、複数のアクセスユニットをまとめて、一つのＭＰ４ファイルに格納する。ＭＭＴに用いられるＭＰＵは、メディア毎のデータが一つのＭＰ４ファイルに格納され、データには任意の数のアクセスユニットを含むことができる。ＭＰＵは、単体で復号可能な単位であるため、例えば、ＭＰＵにはＧＯＰ単位のアクセスユニットが格納される。
【０１６７】
図１９は、ＭＰＵの構成を示す図である。ＭＰＵの先頭は、ｆｔｙｐ、ｍｍｐｕ、及びｍｏｏｖであり、これらは、まとめてＭＰＵメタデータと定義される。ｍｏｏｖには、ファイルに共通の初期化情報、及びＭＭＴヒントトラックが格納される。
【０１６８】
また、ｍｏｏｆには、サンプルやサブサンプル毎の初期化情報及びサイズ、提示時刻（ＰＴＳ）及び復号時刻（ＤＴＳ）を特定できる情報（ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎ、ｓａｍｐｌｅ＿ｓｉｚｅ、ｓａｍｐｌｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｆｆｓｅｔ）、並びにデータの位置を示すｄａｔａ＿ｏｆｆｓｅｔなどが格納される。
【０１６９】
また、複数のアクセスユニットは、それぞれサンプルとしてｍｄａｔ（ｍｄａｔ  ｂｏｘ）に格納される。ｍｏｏｆ及びｍｄａｔのうちサンプルを除くデータは、ムービーフラグメントメタデータ（以降では、ＭＦメタデータと記載する。）と定義され、ｍｄａｔのサンプルデータは、メディアデータと定義される。
【０１７０】
図２０は、ＭＦメタデータの構成を示す図である。図２０に示されるように、ＭＦメタデータは、より詳細には、ｍｏｏｆ  ｂｏｘ（ｍｏｏｆ）の、ｔｙｐｅ、ｌｅｎｇｔｈ、及びｄａｔａと、ｍｄａｔ  ｂｏｘ（ｍｄａｔ）のｔｙｐｅ及びｌｅｎｇｔｈとからなる。
【０１７１】
アクセスユニットをＭＰ４データに格納する際には、Ｈ．２６４やＨ．２６５のＳＰＳ、及び、ＰＰＳなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードがある。
【０１７２】
ここで、上記格納できないモードにおいては、パラメータセットは、ｍｏｏｖにおけるＳａｍｐｌｅＥｎｔｒｙのＤｅｃｏｄｅｒ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎに格納される。また、上記格納できるモードにおいては、パラメータセットは、サンプル内に含められる。
【０１７３】
ＭＰＵメタデータ、ＭＦメタデータ、及びメディアデータは、それぞれＭＭＴペイロードに格納され、これらのデータを識別可能な識別子として、ＭＭＴペイロードのヘッダには、フラグメントタイプ（ＦＴ）が格納される。ＦＴ＝０は、ＭＰＵメタデータであることを示し、ＦＴ＝１は、ＭＦメタデータであることを示し、ＦＴ＝２はメディアデータであることを示す。
【０１７４】
なお、図１９では、ＭＰＵメタデータ単位及びＭＦメタデータ単位がデータユニットとしてＭＭＴペイロードに格納される例が図示されているが、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、及びｍｏｏｆなどの単位がデータユニットとして、データユニット単位でＭＭＴペイロードに格納されてもよい。同様に、図１９では、サンプル単位がデータユニットとしてＭＭＴペイロードに格納される例が図示されている。しかしながら、サンプル単位やＮＡＬユニット単位でデータユニットが構成され、このようなデータユニットがデータユニット単位でＭＭＴペイロードに格納されてもよい。このようなデータユニットがさらにフラグメントされた単位でＭＭＴペイロードに格納されてもよい。
【０１７５】
［従来の送信方法と課題］
従来、複数のアクセスユニットをＭＰ４フォーマットにカプセル化する際、ＭＰ４に格納されるサンプルがすべて揃った時点でｍｏｏｖ及びｍｏｏｆが作成されていた。
【０１７６】
ＭＰ４フォーマットを放送などを用いてリアルタイムに伝送する場合、例えば１つのＭＰ４ファイルに格納するサンプルがＧＯＰ単位であるとすると、ＧＯＰ単位の時間サンプルが蓄積された後にｍｏｏｖ及びｍｏｏｆが作成されるため、カプセル化に伴う遅延が発生する。このような送信側におけるカプセル化により、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延が常にＧＯＰ単位時間分長くなる。これにより、リアルタイムにサービスの提供を行うことが困難となり、特に、ライブコンテンツが伝送される場合には視聴者に対するサービスの劣化につながる。
【０１７７】
図２１は、データの送信順序を説明するための図である。ＭＭＴを放送に適用する場合、図２１の（ａ）に示されるように、ＭＰＵの構成順にＭＭＴパケットに載せて送信（ＭＭＴパケット＃１、＃２、＃３、＃４、＃５、＃６の順に送信）すると、ＭＭＴパケットの送信にはカプセル化による遅延が生じる。
【０１７８】
このカプセル化による遅延を防ぐために、図２１の（ｂ）に示されるように、ＭＰＵメタデータ及びＭＦメタデータなどのＭＰＵヘッダ情報を送らない（パケット＃１及び＃２を送信せず、パケット＃３−＃６をこの順に送信する）方法が提案されている。また、図２０の（ｃ）に示されるように、ＭＰＵヘッダ情報の作成を待たずにメディアデータを先に送信し、メディアデータの送信後にＭＰＵヘッダ情報を送信する（＃３−＃６、＃１、＃２の順で送信する）方法が考えられる。
【０１７９】
受信装置は、ＭＰＵヘッダ情報が送信されていない場合、ＭＰＵヘッダ情報を用いずに復号する、また、受信装置は、ＭＰＵヘッダ情報がメディアデータに対して後送りされている場合には、ＭＰＵヘッダ情報の取得を待ってから復号する。
【０１８０】
しかしながら、従来のＭＰ４準拠の受信装置では、ＭＰＵヘッダ情報を用いずに復号することが保証されていない。また、受信装置が特別な処理によりＭＰＵヘッダを用いずに復号を行う場合に従来の送信方法を用いると復号処理が煩雑となり、実時間の復号が困難となる可能性が高い。また、受信装置がＭＰＵヘッダ情報の取得を待ってから復号を行う場合には、受信装置がヘッダ情報を取得するまでの間メディアデータのバッファリングが必要であるが、バッファモデルが規定されておらず、復号が保証されていなかった。
【０１８１】
そこで、実施の形態２に係る送信装置は、図２０の（ｄ）に示されるように、ＭＰＵメタデータに共通の情報のみを格納することで、ＭＰＵメタデータをメディアデータより先に送信する。そして、実施の形態２に係る送信装置は、生成に遅延が発生するＭＦメタデータをメディアデータより後に送信する。これにより、メディアデータの復号を保証できる送信方法或いは受信方法を提供する。
【０１８２】
以下、図２１の（ａ）−（ｄ）の各送信方法を用いた場合の受信方法について説明する。
【０１８３】
図２１に示される各送信方法では、まず、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順にＭＰＵデータを構成する。
【０１８４】
ＭＰＵデータを構成した後、送信装置が図２１の（ａ）に示されるように、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータの順にデータを送信する場合、受信装置は、下記の（Ａ−１）及び（Ａ−２）のいずれかの方法で復号を行うことができる。
【０１８５】
（Ａ−１）受信装置は、ＭＰＵヘッダ情報（ＭＰＵメタデータ及びＭＦメタデータ）を取得後、ＭＰＵヘッダ情報を用いてメディアデータを復号する。
【０１８６】
（Ａ−２）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
【０１８７】
このような方法はいずれも、送信側でカプセル化による遅延が発生するが、受信装置において、ＭＰＵヘッダ取得のためにメディアデータをバッファリングする必要がない利点がある。バッファリングをしない場合、バッファリングのためのメモリの搭載の必要はなく、さらにバッファリング遅延は発生しない。また、（Ａ−１）の方法は、ＭＰＵヘッダ情報を用いて復号を行うため、従来の受信装置にも適用可能ある。
【０１８８】
送信装置が図２１の（ｂ）に示されるように、メディアデータのみを送信する場合、受信装置は下記の（Ｂ−１）の方法で復号を行うことができる。
【０１８９】
（Ｂ−１）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
【０１９０】
また、図示しないが、図２１の（ｂ）のメディアデータの送信よりも先にＭＰＵメタデータが送信されている場合、下記の（Ｂ−２）の方法で復号を行うことができる。
【０１９１】
（Ｂ−２）受信装置は、ＭＰＵメタデータを用いてメディアデータを復号する。
【０１９２】
上記（Ｂ−１）及び（Ｂ−２）の方法はいずれも、送信側でカプセル化による遅延が発生せず、かつ、ＭＰＵヘッダ取得のためにメディアデータをバッファリングする必要がない点が利点である。しかしながら、（Ｂ−１）及び（Ｂ−２）の方法はいずれも、ＭＰＵヘッダ情報を用いた復号を行わないため、復号に特別な処理が必要となる可能性がある。
【０１９３】
送信装置が図２１の（ｃ）に示されるように、メディアデータ、ＭＰＵメタデータ、ＭＦメタデータの順にデータを送信する場合、受信装置は下記の（Ｃ−１）及び（Ｃ−２）のいずれかの方法で復号を行うことができる。
【０１９４】
（Ｃ−１）受信装置は、ＭＰＵヘッダ情報（ＭＰＵメタデータ及びＭＦメタデータ）を取得後、メディアデータを復号する。
【０１９５】
（Ｃ−２）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
【０１９６】
上記（Ｃ−１）の方法が用いられる場合は、ＭＰＵヘッダ情報の取得のためにメディアデータをバッファリングする必要がある。これに対し、上記（Ｃ−２）の方法が用いられる場合は、ＭＰＵヘッダ情報の取得のためのバッファリングを行う必要はない。
【０１９７】
また、上記（Ｃ−１）及び（Ｃ−２）のいずれの方法も、送信側においてカプセル化による遅延は発生しない。また、（Ｃ−２）の方法は、ＭＰＵヘッダ情報を用いないため、特別な処理が必要となる可能性がある。
【０１９８】
送信装置が、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順にデータを送信する場合、受信装置は、下記の（Ｄ−１）及び（Ｄ−２）のいずれかの方法で復号を行うことができる。
【０１９９】
（Ｄ−１）受信装置は、ＭＰＵメタデータを取得後、さらにＭＦメタデータを取得し、その後、メディアデータを復号する。
【０２００】
（Ｄ−２）受信装置は、ＭＰＵメタデータを取得後、ＭＦメタデータを用いずにメディアデータを復号する。
【０２０１】
上記（Ｄ−１）の方法が用いられる場合は、ＭＦメタデータ取得のためにメディアデータをバッファリングする必要があるが、上記（Ｄ−２）の方法の場合は、ＭＦメタデータ取得のためのバッファリングを行う必要はない。
【０２０２】
上記（Ｄ−２）の方法は、ＭＦメタデータを用いた復号を行わないため、特別な処理が必要となる可能性がある。
【０２０３】
以上説明したように、ＭＰＵメタデータ及びＭＦメタデータを用いて復号できる場合は、従来のＭＰ４受信装置でも復号できるというメリットがある。
【０２０４】
なお、図２１では、ＭＰＵデータは、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順に構成されており、ｍｏｏｆにおいては、この構成に基づいてサンプルやサブサンプル毎の位置情報（オフセット）が定められている。また、ＭＦメタデータには、ｍｄａｔ  ｂｏｘにおけるメディアデータ以外のデータ（ｂｏｘのサイズやタイプ）も含まれている。
【０２０５】
このため、受信装置がＭＦメタデータに基づいてメディアデータを特定する場合には、受信装置は、データが送信された順番にかかわらず、ＭＰＵデータを構成した際の順番にデータを再構成した後、ＭＰＵメタデータのｍｏｏｖ或いはＭＦメタデータのｍｏｏｆを用いて復号を行う。
【０２０６】
なお、図２１では、ＭＰＵデータは、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順に構成されるが、図２１とは異なる順番でＭＰＵデータが構成され、位置情報（オフセット）が定められてもよい。
【０２０７】
例えば、ＭＰＵデータがＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順に構成され、ＭＦメタデータにおいて負の位置情報（オフセット）が示されてもよい。この場合も、データが送信される順番にかかわらず、受信装置は、送信側においてＭＰＵデータが構成された際の順番にデータを再構成した後、ｍｏｏｖ或いはｍｏｏｆを用いて復号を行う。
【０２０８】
なお、送信装置は、ＭＰＵデータを構成する際の順番を示す情報をシグナリングし、受信装置は、シグナリングされた情報に基づいてデータを再構成してもよい。
【０２０９】
以上説明したように、受信装置は、図２１の（ｄ）に示されるように、パケット化されたＭＰＵメタデータ、パケット化されたメディアデータ（サンプルデータ）、パケット化されたＭＦメタデータをこの順に受信する。ここで、ＭＰＵメタデータは、第１のメタデータの一例であり、ＭＦメタデータは、第２のメタデータの一例である。
【０２１０】
次に、受信装置は、受信されたＭＰＵメタデータ、受信されたＭＦメタデータ、及び受信されたサンプルデータを含むＭＰＵデータ（ＭＰ４フォーマットのファイル）を再構成する。そして、再構成されたＭＰＵデータに含まれるサンプルデータを、ＭＰＵメタデータ及びＭＦメタデータを用いて復号する。ＭＦメタデータは、送信側においてサンプルデータの生成後にのみ生成可能なデータ（例えば、ｍｂｏｘに格納されるｌｅｎｇｔｈ）を含むメタデータである。
【０２１１】
なお、上記受信装置の動作は、より詳細には、受信装置を構成する各構成要素によって行われる。例えば、受信装置は、上記データの受信を行う受信部と、上記ＭＰＵデータの再構成を行う再構成部と、上記ＭＰＵデータの復号を行う復号部とを備える。なお、受信部、生成部、及び復号部のそれぞれは、マイクロコンピュータ、プロセッサ、専用回路などによって実現される。
【０２１２】
［ヘッダ情報を用いずに復号を行う方法］
次に、ヘッダ情報を用いずに復号を行う方法について説明する。ここでは、送信側でヘッダ情報を送るか送らないかにかかわらず、受信装置においてヘッダ情報を用いずに復号する方法を説明する。すなわち、この方法は、図２１を用いて説明したいずれの送信方法を用いた場合においても適用可能である。ただし、一部の復号方法は、特定の送信方法の場合にのみ適用可能な復号方法である。
【０２１３】
図２２は、ヘッダ情報を用いずに復号を行う方法の例を示す図である。図２２では、メディアデータのみが含まれるＭＭＴペイロード及びＭＭＴパケットのみが図示されており、ＭＰＵメタデータやＭＦメタデータが含まれるＭＭＴペイロード及びＭＭＴパケットは図示されていない。また、以下の図２２の説明においては、同じＭＰＵに属するメディアデータは連続して伝送されるものとする。また、メディアデータとしてペイロードにサンプルが格納されている場合を例に説明するが、以下の図２２の説明においては、当然ＮＡＬユニットが格納されていてもよいし、フラグメントされたＮＡＬユニットが格納されていてもよい。
【０２１４】
メディアデータを復号するためには、受信装置は、まず、復号に必要な初期化情報を取得しなければならない。また、メディアがビデオであれば、受信装置は、サンプル毎の初期化情報を取得したり、ランダムアクセス単位であるＭＰＵの開始位置を特定し、サンプル及びＮＡＬユニットの開始位置を取得しなければならない。また、受信装置は、それぞれサンプルの復号時刻（ＤＴＳ）や提示時刻（ＰＴＳ）を特定する必要がある。
【０２１５】
そこで、受信装置は、例えば、下記の方法を用いてヘッダ情報を用いずに復号を行うことができる。なお、ペイロードにＮＡＬユニット単位またはＮＡＬユニットをフラグメントした単位が格納される場合は、下記説明において「サンプル」を、「サンプルにおけるＮＡＬユニット」に読み替えればよい。
【０２１６】
＜ランダムアクセス（＝ＭＰＵの先頭サンプルを特定）＞
ヘッダ情報が送信されない場合に、受信装置がＭＰＵの先頭サンプルを特定するには、下記方法１と方法２がある。なお、ヘッダ情報が送信される場合には、方法３を用いることができる。
【０２１７】
［方法１］受信装置は、ＭＭＴパケットヘッダにおいて、‘ＲＡＰ＿ｆｌａｇ＝１’であるＭＭＴパケットに含まれるサンプルを取得する。
【０２１８】
［方法２］受信装置は、ＭＭＴペイロードヘッダにおいて、‘ｓａｍｐｌｅ  ｎｕｍｂｅｒ＝０’であるサンプルを取得する。
【０２１９】
［方法３］受信装置は、メディアデータの前及び後ろの少なくともどちらか一方に、ＭＰＵメタデータ及びＭＦメタデータの少なくともどちらか一方が送信されている場合、受信装置は、ＭＭＴペイロードヘッダにおけるフラグメントタイプ（ＦＴ）がメディアデータへ切り替わったＭＭＴペイロードに含まれるサンプルを取得する。
【０２２０】
なお、方法１及び方法２において、１つのペイロードに異なるＭＰＵに属する複数のサンプルが混在する場合、どのＮＡＬユニットがランダムアクセスポイント（ＲＡＰ＿ｆｌａｇ＝１或いはｓａｍｐｌｅ  ｎｕｍｂｅｒ＝０）であるか判定不能である。このため、１つのペイロードに異なるＭＰＵのサンプルを混在させないといった制約、または、１つのペイロードに異なるＭＰＵのサンプルが混在する場合は、最後（或いは最初）のサンプルがランダムアクセスポイントである場合に、ＲＡＰ＿ｆｌａｇを１とするといった制約などが必要である。
【０２２１】
また、受信装置がＮＡＬユニットの開始位置を取得するためには、サンプルの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズ分だけデータの読出しポインタをシフトさせていく必要がある。
【０２２２】
データがフラグメントされている場合は、受信装置は、ｆｒａｇｍｅｎｔ＿ｉｎｄｉｃａｔｏｒやｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒを参照することで、データユニットを特定できる。
【０２２３】
＜サンプルのＤＴＳの決定＞
サンプルのＤＴＳの決定方法には、下記方法１と方法２がある。
【０２２４】
［方法１］受信装置は、予測構造に基づいて先頭サンプルのＤＴＳを決定する。ただし、この方法には符号化データの解析が必要であり、実時間での復号が困難である可能性があるため、次の方法２が望ましい。
【０２２５】
［方法２］受信装置は、先頭サンプルのＤＴＳを別途送信し、送信された先頭サンプルのＤＴＳを取得する。先頭サンプルのＤＴＳの送信方法は、例えば、ＭＰＵ先頭サンプルのＤＴＳを、ＭＭＴ−ＳＩを用いて送信する方法や、サンプル毎のＤＴＳをＭＭＴパケットヘッダ拡張領域を用いて送信する方法などがある。なお、ＤＴＳは、絶対値でもよいし、ＰＴＳに対する相対値であってもよい。また、送信側において先頭サンプルのＤＴＳが含まれているかどうかをシグナリングしてもよい。
【０２２６】
なお、方法１、方法２ともに、以降のサンプルのＤＴＳは、固定フレームレートであるとして算出する。
【０２２７】
サンプル毎のＤＴＳをパケットヘッダに格納する方法として、拡張領域を用いる以外に、ＭＭＴパケットヘッダにおける３２ｂｉｔのＮＴＰタイムスタンプフィールドに、当該ＭＭＴパケットに含まれるサンプルのＤＴＳを格納する方法がある。１つのパケットヘッダのビット数（３２ｂｉｔ）でＤＴＳを表現できない場合は、ＤＴＳは、複数のパケットヘッダを用いて表現されてもよい。また、ＤＴＳは、パケットヘッダのＮＴＰタイムスタンプフィールドと拡張領域とを組み合わせて表現されてもよい。ＤＴＳ情報が含まれない場合は既知の値（例えばＡＬＬ０）とされる。
【０２２８】
＜サンプルのＰＴＳの決定＞
受信装置は、先頭サンプルのＰＴＳを、ＭＰＵに含まれるアセット毎のＭＰＵタイムスタンプ記述子から取得する。受信装置は、以降のサンプルＰＴＳについては、固定フレームレートであるものとして、ＰＯＣ等のサンプルの表示順を示すパラメータなどから算出する。このように、ヘッダ情報を用いずにＤＴＳ、及びＰＴＳを算出するためには、固定フレームレートによる送信が必須となる。
【０２２９】
また、ＭＦメタデータが送信されている場合、受信装置は、ＭＦメタデータに示される先頭サンプルからのＤＴＳやＰＴＳの相対時刻情報と、ＭＰＵタイムスタンプ記述子に示されるＭＰＵ先頭サンプルのタイムスタンプの絶対値とからＤＴＳ及びＰＴＳの絶対値を算出できる。
【０２３０】
なお、符号化データ解析してＤＴＳ及びＰＴＳを算出する際には、受信装置は、アクセスユニットに含まれるＳＥＩ情報を用いて算出してもよい。
【０２３１】
＜初期化情報（パラメータセット）＞
［ビデオの場合］
ビデオの場合、パラメータセットは、サンプルデータに格納される。また、ＭＰＵメタデータ及びＭＦメタデータが送信されない場合は、サンプルデータのみを参照することにより復号に必要なパラメータセットを取得できることを保証する。
【０２３２】
また、図２１の（ａ）及び（ｄ）のように、ＭＰＵメタデータがメディアデータよりも先に送信される場合、ＳａｍｐｌｅＥｎｔｒｙにはパラメータセットは格納しないと規定されてもよい。この場合、受信装置は、ＳａｍｐｌｅＥｎｔｒｙのパラメータセットは参照せずにサンプル内のパラメータセットのみを参照する。
【０２３３】
また、ＭＰＵメタデータがメディアデータよりも先に送信される場合、ＳａｍｐｌｅＥｎｔｒｙにはＭＰＵに共通のパラメータセットやデフォルトのパラメータセットが格納され、受信装置は、ＳａｍｐｌｅＥｎｔｒｙのパラメータセット及びサンプル内のパラメータセットを参照してもよい。ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが格納されることにより、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが存在しないと再生できない従来の受信装置でも復号を行うことが可能となる。
【０２３４】
［オーディオの場合］
オーディオの場合、復号にはＬＡＴＭヘッダが必要であり、ＭＰ４では、ＬＡＴＭヘッダがサンプルエントリに含められることが必須である。しかし、ヘッダ情報が送信されない場合は、受信装置がＬＡＴＭヘッダを取得することは困難であるため、別途ＳＩなどの制御情報にＬＡＴＭヘッダが含められる。なお、ＬＡＴＭヘッダは、メッセージ、テーブル、または記述子に含められてもよい。なお、ＬＡＴＭヘッダはサンプル内に含められることもある。
【０２３５】
受信装置は、復号開始前にＳＩなどからＬＡＴＭヘッダを取得し、オーディオの復号を開始する。或いは、図２１の（ａ）及び図２１の（ｄ）に示されるように、ＭＰＵメタデータがメディアデータよりも先に送信される場合は、受信装置は、ＬＡＴＭヘッダをメディアデータより先に受信可能である。したがって、ＭＰＵメタデータがメディアデータよりも先に送信される場合は、従来の受信装置を用いても復号を行うことが可能となる。
【０２３６】
＜その他＞
送信順序や送信順序のタイプは、ＭＭＴパケットヘッダやペイロードヘッダ、或いは、ＭＰＴやその他のテーブル、メッセージ、記述子などの制御情報として通知されてもよい。なお、ここでの送信順序のタイプとは、例えば、図２１の（ａ）〜（ｄ）の４つのタイプの送信順序であり、それぞれのタイプを識別するための識別子が復号開始前に取得できる場所に格納されればよい。
【０２３７】
また、送信順序のタイプは、オーディオとビデオとで異なるタイプが用いられてもよいし、オーディオとビデオとで共通のタイプが用いられてもよい。具体的には、例えば、オーディオは、図２１の（ａ）に示されるように、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータの順番で送信され、ビデオは、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順番で送信されてもよい。
【０２３８】
以上説明したような方法により、受信装置は、ヘッダ情報を用いずに復号を行うことが可能である。また、ＭＰＵメタデータがメディアデータよりも先に送信されている場合（図２１の（ａ）及び図２１の（ｄ））は、従来の受信装置でも復号を行うことが可能になる。
【０２３９】
特に、ＭＦメタデータがメディアデータより後に送信されること（図２１の（ｄ））により、カプセル化による遅延を発生させず、かつ従来の受信装置でも復号を行うことが可能となる。
【０２４０】
［送信装置の構成及び動作］
次に、送信装置の構成及び動作について説明する。図２３は、実施の形態２に係る送信装置のブロック図であり、図２４は、実施の形態２に係る送信方法のフローチャートである。
【０２４１】
図２３に示されるように、送信装置１５は、符号化部１６と、多重化部１７と、送信部１８とを備える。
【０２４２】
符号化部１６は、符号化対象のビデオまたはオーディオを、例えば、Ｈ．２６５に従い符号化することで符号化データを生成する（Ｓ１０）。
【０２４３】
多重化部１７は、符号化部１６により生成された符号化データを多重化（パケット化）する（Ｓ１１）。具体的には、多重化部１７は、ＭＰ４フォーマットのファイルを構成する、サンプルデータ、ＭＰＵメタデータ、及び、ＭＦメタデータ、のそれぞれをパケット化する。サンプルデータは、映像信号または音声信号が符号化されたデータであり、ＭＰＵメタデータは、第１のメタデータの一例であり、ＭＦメタデータは、第２のメタデータの一例である。第１のメタデータと第２のメタデータとは、いずれもサンプルデータの復号に用いられるメタデータであるが、これらの違いは、第２のメタデータがサンプルデータの生成後にのみ生成可能なデータを含むことである。
【０２４４】
ここで、サンプルデータの生成後にのみ生成可能なデータは、例えば、ＭＰ４フォーマットにおけるｍｄａｔに格納されるサンプルデータ以外のデータ（ｍｄａｔのヘッダ内のデータ。つまり、図２０に図示されるｔｙｐｅ及びｌｅｎｇｔｈ。）である。ここで、第２のメタデータには、このデータのうち少なくとも一部であるｌｅｎｇｔｈが含まれればよい。
【０２４５】
送信部１８は、パケット化したＭＰ４フォーマットのファイルを送信する（Ｓ１２）。送信部１８は、例えば、図２１の（ｄ）に示される方法でＭＰ４フォーマットのファイルを送信する。つまり、パケット化されたＭＰＵメタデータ、パケット化されたサンプルデータ、パケット化されたＭＦメタデータをこの順に送信する。
【０２４６】
なお、符号化部１６、多重化部１７、及び送信部１８のそれぞれは、マイクロコンピュータ、プロセッサ、または専用回路などによって実現される。
【０２４７】
［受信装置の構成］
次に、受信装置の構成及び動作について説明する。図２５は、実施の形態２に係る受信装置のブロック図である。
【０２４８】
図２５に示されるように、受信装置２０は、パケットフィルタリング部２１と、送信順序タイプ判別部２２と、ランダムアクセス部２３と、制御情報取得部２４と、データ取得部２５と、ＰＴＳ、ＤＴＳ算出部２６と、初期化情報取得部２７と、復号命令部２８と、復号部２９と、提示部３０とを備える。
【０２４９】
［受信装置の動作１］
まず、メディアがビデオである場合に、受信装置２０が、ＭＰＵ先頭位置及びＮＡＬユニット位置を特定するための動作について説明する。図２６は、受信装置２０のこのような動作のフローチャートである。なお、ここでは、ＭＰＵデータの送信順序タイプは、送信装置１５（多重化部１７）によってＳＩ情報に格納されているとする。
【０２５０】
まず、パケットフィルタリング部２１は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部２２は、パケットフィルタリングによって得られるＳＩ情報を解析して、ＭＰＵデータの送信順序タイプを取得する（Ｓ２１）。
【０２５１】
次に、送信順序タイプ判別部２２は、パケットフィルタリング後のデータにＭＰＵヘッダ情報（ＭＰＵメタデータ或いはＭＦメタデータの少なくとも一方）が含まれているか否かを判定（判別）する（Ｓ２２）。ＭＰＵヘッダ情報（が含まれている場合（Ｓ２２でＹｅｓ）には、ランダムアクセス部２３は、ＭＭＴペイロードヘッダのフラグメントタイプがメディアデータへ切り替わることを検出することで、ＭＰＵ先頭サンプルを特定する（Ｓ２３）。
【０２５２】
一方、ＭＰＵヘッダ情報が含まれていない場合（Ｓ２２でＮｏ）には、ランダムアクセス部２３は、ＭＭＴパケットヘッダのＲＡＰ＿ｆｌａｇ或いはＭＭＴペイロードヘッダのｓａｍｐｌｅ  ｎｕｍｂｅｒに基づいてＭＰＵ先頭サンプルを特定する（Ｓ２４）。
【０２５３】
また、送信順序タイプ判別部２２は、パケットフィルタリングされたデータに、ＭＦメタデータが含まれているか否かを判定する（Ｓ２５）。ＭＦメタデータが含まれていると判定された場合（Ｓ２５でＹｅｓ）には、データ取得部２５は、ＭＦメタデータに含まれるサンプル、サブサンプルのオフセット、及びサイズ情報に基づいてＮＡＬユニットを読み出すことによりＮＡＬユニットを取得する（Ｓ２６）。一方、ＭＦメタデータが含まれていないと判定された場合（Ｓ２５でＮｏ）には、データ取得部２５は、サンプルの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズのデータを読み出すことでＮＡＬユニットを取得する（Ｓ２７）。
【０２５４】
なお、受信装置２０は、ステップＳ２２において、ＭＰＵヘッダ情報が含まれていると判別された場合でも、ステップＳ２３ではなくステップＳ２４の処理を用いてＭＰＵ先頭サンプルを特定してもよい。また、ＭＰＵヘッダ情報が含まれていると判別された場合に、ステップＳ２３の処理とステップＳ２４の処理とが併用されてもよい。
【０２５５】
また、受信装置２０は、ステップＳ２５において、ＭＦメタデータが含まれていると判定された場合でも、ステップＳ２６の処理を用いずにステップＳ２７の処理を用いてＮＡＬユニットを取得してもよい。また、ＭＦメタデータが含まれていると判定された場合に、ステップＳ２３の処理とステップＳ２４の処理とが併用されてもよい。
【０２５６】
また、ステップＳ２５においてＭＦメタデータが含まれていると判定された場合であって、ＭＦデータがメディアデータより後に送信されている場合が想定される。この場合、受信装置２０は、メディアデータをバッファリングし、ＭＦメタデータを取得するまで待ってからステップＳ２６の処理を行ってもよいし、受信装置２０は、ＭＦメタデータの取得を待たずにステップＳ２７の処理を行うか否かを判定してもよい。
【０２５７】
例えば、受信装置２０は、メディアデータをバッファリングすることが可能なバッファサイズのバッファを保有しているかどうかに基づいてＭＦメタデータの取得を待つか否かを判定してもよい。また、受信装置２０は、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延が小さくなるかどうかに基づいて、ＭＦメタデータの取得を待つか否かを判定してもよい。また、受信装置２０は、主としてステップＳ２６の処理を用いて復号処理を実施し、パケットロスなどが発生したときの処理モードの場合にステップＳ２７の処理を用いてもよい。
【０２５８】
なお、送信順序タイプがあらかじめ定められている場合は、ステップＳ２２及びステップＳ２６は省略されてもよいし、この場合、受信装置２０は、バッファサイズやＥｎｄ−ｔｏ−Ｅｎｄ遅延を考慮して、ＭＰＵ先頭サンプルの特定方法、及び、ＮＡＬユニットの特定方法を決定してもよい。
【０２５９】
なお、あらかじめ送信順序タイプが既知である場合は、受信装置２０において送信順序タイプ判別部２２は、不要である。
【０２６０】
また、上記図２６においては説明されないが、復号命令部２８は、ＰＴＳ、ＤＴＳ算出部２６において算出されたＰＴＳ及びＤＴＳ、初期化情報取得部２７において取得された初期化情報に基づいて、データ取得部において取得されたデータを復号部２９に出力する。復号部２９は、データを復号し、提示部３０は、復号後のデータを提示する。
【０２６１】
［受信装置の動作２］
次に、受信装置２０が、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作について説明する。図２７は、このような動作のフローチャートである。
【０２６２】
まず、パケットフィルタリング部２１は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部２２は、パケットフィルタリングによって得られるＳＩ情報を解析し、送信順序タイプを取得する（Ｓ３０１）。
【０２６３】
次に、送信順序タイプ判別部２２は、ＭＰＵメタデータが送信されているか否かを判定する（Ｓ３０２）。ＭＰＵメタデータが送信されていると判定された場合（Ｓ３０２でＹｅｓ）、送信順序タイプ判別部２２は、ステップＳ３０１の解析の結果、ＭＰＵメタデータがメディアデータより先に送信されているかどうかを判定する（Ｓ３０３）。ＭＰＵメタデータがメディアデータより先に送信されている場合（Ｓ３０３でＹｅｓ）、初期化情報取得部２７は、ＭＰＵメタデータに含まれる共通な初期化情報、及び、サンプルデータの初期化情報に基づいてメディアデータを復号する（Ｓ３０４）。
【０２６４】
一方、ＭＰＵメタデータがメディアデータより後に送信されていると判定された場合（Ｓ３０３でＮｏ）には、データ取得部２５は、ＭＰＵメタデータが取得されるまでメディアデータをバッファリングし（Ｓ３０５）、ＭＰＵメタデータが取得された後にステップＳ３０４の処理を実施する。
【０２６５】
また、ステップＳ３０２において、ＭＰＵメタデータが送信されていないと判定された場合（Ｓ３０２でＮｏ）には、初期化情報取得部２７は、サンプルデータの初期化情報のみに基づいてメディアデータを復号する（Ｓ３０６）。
【０２６６】
なお、送信側においてサンプルデータの初期化情報に基づく場合のみメディアデータの復号が保証されている場合は、ステップＳ３０２、及びステップＳ３０３の判定に基づく処理を行わず、ステップＳ３０６の処理が用いられる。
【０２６７】
また、受信装置２０は、ステップＳ３０５の前に、メディアデータをバッファリングするか否かの判定を行ってもよい。この場合、受信装置２０は、メディアデータをバッファリングすると判定した場合にはステップＳ３０５の処理へ移行し、メディアデータをバッファリングしないと判定した場合には、ステップＳ３０６の処理へ移行する。メディアデータをバッファリングするか否かの判定は、受信装置２０のバッファサイズ、占有量に基づいて行われてもよいし、例えば、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延の小さい方が選択されるなど、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を考慮して判定が行われてもよい。
【０２６８】
［受信装置の動作３］
ここでは、ＭＦメタデータがメディアデータよりも後に送信される場合（図２１の（ｃ）、及び図２１の（ｄ））における送信方法や受信方法の詳細について説明する。以下では、図２１の（ｄ）の場合を例に説明する。なお、送信においては、図２１の（ｄ）の方法のみが用いられ、送信順序タイプのシグナリングは行われないものとする。
【０２６９】
先述のとおり、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順でデータを送信する場合、
（Ｄ−１）受信装置２０は、ＭＰＵメタデータを取得した後、さらにＭＦメタデータを取得した後にメディアデータを復号する。
（Ｄ−２）受信装置２０は、ＭＰＵメタデータを取得した後、ＭＦメタデータを用いずにメディアデータを復号する。
の２通りの復号方法が可能である。
【０２７０】
ここで、Ｄ−１は、ＭＦメタデータ取得のためのメディアデータのバッファリングが必要となるが、ＭＰＵヘッダ情報を用いて復号を行うことができるため、従来のＭＰ４準拠の受信装置で復号可能となる。また、Ｄ−２は、ＭＦメタデータ取得のためのメディアデータのバッファリングを必要としないが、ＭＦメタデータを用いて復号できないため、復号に特別な処理が必要となる。
【０２７１】
また、図２１の（ｄ）の方法は、ＭＦメタデータは、メディアデータより後で送信されるため、カプセル化による遅延は発生せず、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を低減できるという利点を有する。
【０２７２】
受信装置２０は、受信装置２０の能力や、受信装置２０が提供するサービス品質に応じて、上記２通りの復号方法を選択することができる。
【０２７３】
送信装置１５は、受信装置２０における復号動作において、バッファのオーバーフローやアンダーフローの発生を低減して復号できることを保証しなければならない。Ｄ−１の方法を用いて復号する場合のデコーダモデルを規定するための要素としては、例えば下記のパラメータを用いることができる。
【０２７４】
・ＭＰＵを再構成するためのバッファサイズ（ＭＰＵバッファ）
例えば、バッファサイズ＝最大レート×最大ＭＰＵ時間×αであり、最大レートとは、符号化データのプロファイル、レベルの上限レート＋ＭＰＵヘッダのオーバーヘッドである。また、最大ＭＰＵ時間は、１ＭＰＵ＝１ＧＯＰ（ビデオ）とした場合のＧＯＰの最大時間長である。
【０２７５】
ここで、オーディオは、上記ビデオに共通のＧＯＰ単位としてもよいし、別の単位でもよい。αは、オーバーフローを起こさないためのマージンであり、最大レート×最大ＭＰＵ時間に対して、乗算されてもよいし、加算されてもよい。乗算される場合は、α≧１であり、加算される場合は、α≧０である。
【０２７６】
・ＭＰＵバッファへデータが入力されてから復号されるまでの復号遅延時間の上限。（ＭＰＥＧ−ＴＳのＳＴＤにおけるＴＳＴＤ＿ｄｅｌａｙ）
例えば、送信時には、最大ＭＰＵ時間、及び、復号遅延時間の上限値を考慮して、受信機におけるＭＰＵデータの取得完了時刻＜＝ＤＴＳとなるようにＤＴＳが設定される。
【０２７７】
また、送信装置１５は、Ｄ−１の方法を用いて復号する場合のデコーダモデルに従い、ＤＴＳ及びＰＴＳを付与してもよい。これにより、送信装置１５は、Ｄ−１の方法を用いて復号を行う受信装置の当該復号を保証すると同時に、Ｄ−２の方法を用いて復号が行われる場合に必要な補助情報を送信してもよい。
【０２７８】
例えば、送信装置１５は、Ｄ−２の方法を用いて復号する場合のデコーダバッファにおけるプリバッファリング時間をシグナリングすることにより、Ｄ−２の方法を用いて復号する受信装置の動作を保証できる。
【０２７９】
プリバッファリング時間は、メッセージ、テーブル、記述子などのＳＩ制御情報に含められてもよいし、ＭＭＴパケット、ＭＭＴペイロードのヘッダに含められてもよい。また、符号化データ内のＳＥＩが上書きされてもよい。Ｄ−１の方法を用いて復号するためのＤＴＳ及びＰＴＳは、ＭＰＵタイムスタンプ記述子、ＳａｍｐｌｅＥｎｔｒｙに格納され、Ｄ−２の方法を用いて復号するためのＤＴＳ及びＰＴＳ、またはプリバッファリング時間がＳＥＩにおいて記述されてもよい。
【０２８０】
受信装置２０は、当該受信装置２０がＭＰＵヘッダを用いたＭＰ４準拠の復号動作のみに対応している場合は、復号方法Ｄ−１を選択し、Ｄ−１およびＤ−２の両方に対応している場合は、どちらか一方を選択してもよい。
【０２８１】
送信装置１５は、一方（本説明では、Ｄ−１）の復号動作を保証できるようにＤＴＳ、及びＰＴＳを付与し、さらに一方の復号動作を補助するための補助情報を送信してもよい。
【０２８２】
また、Ｄ−２の方法が用いられる場合、Ｄ−１の方法が用いられる場合と比較して、ＭＦメタデータのプリバッファリングに起因する遅延により、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延が大きくなる可能性が高い。したがって、受信装置２０は、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を小さくしたいときは、Ｄ−２の方法を選択して復号してもよい。例えば、受信装置２０は、常にＥｎｄ−ｔｏ−Ｅｎｄ遅延を削減したい場合に、常にＤ−２の方法を用いてもよい。また、受信装置２０は、ライブコンテンツや、選局、ザッピング動作など、低遅延で提示したい、低遅延提示モードで動作している場合のみＤ−２の方法を用いてもよい。
【０２８３】
図２８は、このような受信方法のフローチャートである。
【０２８４】
まず、受信装置２０は、ＭＭＴパケットを受信し、ＭＰＵデータを取得する（Ｓ４０１）。そして、受信装置２０（送信順序タイプ判別部２２）は、当該プログラムを低遅延提示モードで提示するかどうかの判定を行う（Ｓ４０２）。
【０２８５】
プログラムを低遅延提示モードで提示しない場合（Ｓ４０２でＮｏ）、受信装置２０（ランダムアクセス部２３及び初期化情報取得部２７）は、ヘッダ情報を用いてランダムアクセス、初期化情報を取得する（Ｓ４０５）。また、受信装置２０（ＰＴＳ、ＤＴＳ算出部２６、復号命令部２８、復号部２９、提示部３０）は、送信側で付与されたＰＴＳ、ＤＴＳに基づいてデコード及び提示処理を行う（Ｓ４０６）。
【０２８６】
一方、プログラムを低遅延提示モードで提示する場合（Ｓ４０２でＹｅｓ）、受信装置２０（ランダムアクセス部２３及び初期化情報取得部２７）は、ヘッダ情報を用いない復号方法を用いて、ランダムアクセス、初期化情報を取得する（Ｓ４０３）。また、受信装置２０は、送信側で付与されたＰＴＳ、ＤＴＳ及びヘッダ情報を用いずに復号するための補助情報に基づいてデコード及び提示処理を行う（Ｓ４０４）。なお、ステップＳ４０３、及びステップＳ４０４において、ＭＰＵメタデータを用いて処理が行われてもよい。
【０２８７】
［補助データを用いた送受信方法］
以上、ＭＦメタデータがメディアデータより後に送信される場合（図２１の（ｃ）、及び図２１の（ｄ）の場合）における送受信動作について説明した。次に、送信装置１５がＭＦメタデータの一部の機能を有する補助データを送信することにより、より早く復号を開始でき、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を削減できる方法について説明する。ここでは、図２１の（ｄ）に示される送信方法に基づいて補助データがさらに送信される例について説明されるが、補助データを用いる方法は、図２１の（ａ）〜（ｃ）に示される送信方法においても適用可能である。
【０２８８】
図２９の（ａ）は、図２１の（ｄ）に示される方法を用いて送信されたＭＭＴパケットを示す図である。つまり、データは、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順で送信される。
【０２８９】
ここで、サンプル＃１、サンプル＃２、サンプル＃３、サンプル＃４はメディアデータに含まれるサンプルである。なお、ここではメディアデータは、サンプル単位でＭＭＴパケットに格納される例について説明されるが、メディアデータは、ＮＡＬユニット単位でＭＭＴパケットに格納されてもよいし、ＮＡＬユニットを分割した単位で格納されてもよい。なお、複数のＮＡＬユニットがアグリゲーションされてＭＭＴパケットに格納される場合もある。
【０２９０】
先述のＤ−１で説明したように、図２１の（ｄ）に示される方法の場合、つまり、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順でデータが送信される場合、ＭＰＵメタデータを取得後、さらにＭＦメタデータを取得し、その後、メディアデータを復号する方法がある。このようなＤ−１の方法では、ＭＦメタデータ取得のためのメディアデータのバッファリングが必要となるが、ＭＰＵヘッダ情報を用いて復号が行われるため、従来のＭＰ４準拠の受信装置にもＤ−１の方法は適用可能である利点がある。一方で、受信装置２０は、ＭＦメタデータ取得まで、復号開始を待たなければならない欠点がある。
【０２９１】
これに対し、図２９の（ｂ）に示されるように、補助データを用いる手法においては、ＭＦメタデータより先に、補助データが送信される。
【０２９２】
ＭＦメタデータには、ムービーフラグメントに含まれる全てのサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれている。これに対し、補助データには、ムービーフラグメントに含まれるサンプルのうち、一部のサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれる。
【０２９３】
例えば、ＭＦメタデータには、すべてのサンプル（サンプル＃１−サンプル＃４）の情報が含まれるのに対し、補助データには一部のサンプル（サンプル＃１−＃２）の情報が含まれる。
【０２９４】
図２９の（ｂ）に示される場合は、補助データが用いられることでサンプル＃１、及びサンプル＃２の復号が可能となるため、Ｄ−１の送信方法に対して、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延が小さくなる。なお、補助データには、どのようにサンプルの情報が組み合わされて含められてもよいし、補助データは、繰り返し送信されてもよい。
【０２９５】
例えば、図２９の（ｃ）において、Ａのタイミングで補助情報を送信する場合は、送信装置１５は、補助情報にサンプル＃１の情報を含め、Ｂのタイミングで補助情報を送信する場合は、補助情報にサンプル＃１及びサンプル＃２の情報を含める。送信装置１５は、Ｃのタイミングで補助情報を送信する場合は、補助情報にはサンプル＃１、サンプル＃２、及びサンプル＃３の情報を含める。
【０２９６】
なお、ＭＦメタデータには、サンプル＃１、サンプル＃２、サンプル＃３、及び、サンプル＃４の情報（ムービーフラグメントの中の全サンプルの情報）が含まれる。
【０２９７】
補助データは、必ずしも生成後、ただちに送信される必要はない。
【０２９８】
なお、ＭＭＴパケットやＭＭＴペイロードのヘッダにおいては、補助データが格納されていることを示すタイプが指定される。
【０２９９】
例えば、補助データがＭＭＴペイロードにＭＰＵモードを用いて格納される場合は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅフィールド値（例えば、ＦＴ＝３）として、補助データであることを示すデータタイプが指定される。補助データは、ｍｏｏｆの構成に基づくデータであってもよいし、その他の構成であってもよい。
【０３００】
補助データが、ＭＭＴペイロードに制御信号（記述子、テーブル、メッセージ）として格納される場合は、補助データであることを示す記述子タグ、テーブルＩＤ、及びメッセージＩＤなどが指定される。
【０３０１】
また、ＭＭＴパケットやＭＭＴペイロードのヘッダにＰＴＳまたはＤＴＳが格納されてもよい。
【０３０２】
［補助データの生成例］
以下、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例について説明する。図３０は、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例を説明するための図である。
【０３０３】
通常のＭＰ４では、図２０に示されるように、ムービーフラグメントに対してｍｏｏｆが作成される。ｍｏｏｆには、ムービーフラグメントに含まれるサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれている。
【０３０４】
ここでは、送信装置１５は、ＭＰＵを構成するサンプルデータの中で、一部のサンプルデータのみを用いてＭＰ４（ＭＰ４ファイル）を構成し、補助データを生成する。
【０３０５】
例えば、図３０の（ａ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、サンプル＃１のみを用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを補助データとする。
【０３０６】
次に、図３０の（ｂ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、サンプル＃１及びサンプル＃２を用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを次の補助データとする。
【０３０７】
次に、図３０の（ｃ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、サンプル＃１、サンプル＃２、及びサンプル＃３を用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを次の補助データとする。
【０３０８】
次に、図３０の（ｄ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、すべてのＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダがムービーフラグメントメタデータとなる。
【０３０９】
なお、ここでは、送信装置１５は、１サンプル毎に補助データを生成したが、Ｎサンプル毎に補助データを生成してもよい。Ｎの値は任意の数字であり、例えば、一つのＭＰＵを送信するときに補助データをＭ回送信する場合、Ｎ＝全サンプル／Ｍとされてもよい。
【０３１０】
なお、ｍｏｏｆにおけるサンプルのオフセットを示す情報は、後続のサンプル数のサンプルエントリ領域がＮＵＬＬ領域として確保された後のオフセット値であってもよい。
【０３１１】
なお、ＭＦメタデータをフラグメントする構成となるように補助データが生成されてもよい。
【０３１２】
［補助データを用いた受信動作例］
図３０で説明したように生成された補助データの受信について説明する。図３１は、補助データの受信を説明するための図である。なお、図３１の（ａ）では、ＭＰＵを構成するサンプル数は３０であり、１０サンプル毎に補助データが生成され、送信されるものとする。
【０３１３】
図３０の（ａ）において、補助データ＃１には、サンプル＃１−＃１０、補助データ＃２には、サンプル＃１−＃２０、ＭＦメタデータには、サンプル＃１−＃３０のサンプル情報がそれぞれ含まれる。
【０３１４】
なお、サンプル＃１−＃１０、サンプル＃１１−＃２０、及びサンプル＃２１−＃３０は、一つのＭＭＴペイロードに格納されているが、サンプル単位やＮＡＬ単位で格納されてもよいし、フラグメントやアグリゲーションした単位で格納されてもよい。
【０３１５】
受信装置２０は、ＭＰＵメタ、サンプル、ＭＦメタ、及び補助データのパケットをそれぞれ受信する。
【０３１６】
受信装置２０は、サンプルデータを受信順に（後ろに）連結し、最新の補助データを受信した後に、これまでの補助データを更新する。また、受信装置２０は、最後に補助データをＭＦメタデータに置き換えることにより、完全なＭＰＵを構成できる。
【０３１７】
受信装置２０は、補助データ＃１を受信した時点では、図３１の（ｂ）の上段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及び補助データ＃１の情報を用いてサンプル＃１−＃１０をパースすることができ、補助データに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
【０３１８】
また、受信装置２０は、補助データ＃２を受信した時点では、図３１の（ｂ）の中段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及び補助データ＃２の情報を用いてサンプル＃１−＃２０をパースすることができ、補助データに含まれるＰＴＳ、ＤＴＳ、オフセット、サイズの情報に基づいて復号を行うことができる。
【０３１９】
また、受信装置２０は、ＭＦメタデータを受信した時点では、図３１の（ｂ）の下段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタデータを用いてサンプル＃１−＃３０をパースすることができ、ＭＦメタデータに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
【０３２０】
補助データが無い場合は、受信装置２０は、ＭＦメタデータの受信後にはじめてサンプルの情報を取得できるため、ＭＦメタデータの受信後に復号を開始する必要があった。しかしながら、送信装置１５が補助データを生成し、送信することにより、受信装置２０は、ＭＦメタデータの受信を待たずに、補助データを用いてサンプルの情報を取得できるため、復号開始時間を早めることができる。さらに、送信装置１５が図３０を用いて説明したｍｏｏｆに基づく補助データを生成することにより、受信装置２０は、従来のＭＰ４のパーサーをそのまま利用し、パースすることが可能である。
【０３２１】
また、新たに生成する補助データやＭＦメタデータは、過去に送信した補助データと重複するサンプルの情報を含む。このため、パケットロスなどにより過去の補助データを取得できなかった場合でも、新たに取得する補助データやＭＦメタデータを用いることで、ＭＰ４を再構成し、サンプルの情報（ＰＴＳ、ＤＴＳ、サイズ、及びオフセット）を取得することが可能である。
【０３２２】
なお、補助データは、必ずしも過去のサンプルデータの情報を含む必要はない。たとえば、補助データ＃１は、サンプルデータ＃１−＃１０に対応し、補助データ＃２は、サンプルデータ＃１１−＃２０に対応してもよい。例えば、図３１の（ｃ）に示されるように、送信装置１５は、完全なＭＦメタデータをデータユニットとして、データユニットをフラグメントした単位を補助データとして順次送出してもよい。
【０３２３】
また、送信装置１５は、パケットロス対策のために、補助データを繰り返し伝送してもよいし、ＭＦメタデータを繰り返し伝送してもよい。
【０３２４】
なお、補助データが格納されるＭＭＴパケット及びＭＭＴペイロードには、ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータと同様に、ＭＰＵシーケンス番号、及びアセットＩＤが含まれる。
【０３２５】
以上のような補助データを用いた受信動作について図３２のフローチャートを用いて説明する。図３２は、補助データを用いた受信動作のフローチャートである。
【０３２６】
まず、受信装置２０は、ＭＭＴパケットを受信し、パケットヘッダやペイロードヘッダを解析する（Ｓ５０１）。次に、受信装置２０は、フラグメントタイプが補助データか、ＭＦメタデータかを解析し（Ｓ５０２）、フラグメントタイプが補助データである場合には、過去の補助データを上書きして更新する（Ｓ５０３）。このとき、同一ＭＰＵの過去の補助データがない場合には、受信装置２０は、受信した補助データをそのまま新規の補助データとする。そして、受信装置２０は、ＭＰＵメタデータ、補助データ、及びサンプルデータに基づき、サンプルを取得し、復号を行う（Ｓ５０７）。
【０３２７】
一方、フラグメントタイプがＭＦメタデータである場合には、受信装置２０は、ステップＳ５０５において、過去の補助データをＭＦメタデータで上書きする（Ｓ５０５）。そして、受信装置２０は、ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータに基づきサンプルを完全なＭＰＵの形で取得し、復号を行う（Ｓ５０６）。
【０３２８】
なお、図３２において図示されないが、ステップＳ５０２において、受信装置２０は、フラグメントタイプがＭＰＵメタデータである場合には、データをバッファに格納し、サンプルデータである場合には、サンプル毎に後ろに連結したデータをバッファに格納する。
【０３２９】
パケットロスにより補助データが取得できなかった場合は、受信装置２０は、最新の補助データにより上書きを行うか、あるいは過去の補助データを用いることによりサンプルを復号することができる。
【０３３０】
なお、補助データの送出周期及び送出回数はあらかじめ定められた値であってもよい。送出周期や回数（カウント、カウンドダウン）の情報は、データと一緒に送信されてもよい。例えば、データユニットヘッダに、送出周期、送出回数、及びｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙなどのタイムスタンプが格納されてもよい。
【０３３１】
ＭＰＵの初めのサンプルの情報を含む補助データをｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙより先に１回以上送信することにより、ＣＰＢバッファモデルに従うことが可能となる。このとき、ＭＰＵタイムスタンプ記述子には、ｐｉｃｔｕｒｅ  ｔｉｍｉｎｇ  ＳＥＩに基づいた値を格納される。
【０３３２】
なお、このような補助データが使用される受信動作における伝送方式は、ＭＭＴ方式に限定されず、ＭＰＥＧ−ＤＡＳＨなど、ＩＳＯＢＭＦＦファイルフォーマットで構成されるパケットをストリーミング伝送する場合などに適用可能である。
【０３３３】
［１つのＭＰＵが複数のムービーフラグメントで構成される場合の送信方法］
上記図１９以降の説明においては、１つのＭＰＵが、１つのムービーフラグメントで構成されたが、ここでは、１つのＭＰＵが複数のムービーフラグメントで構成される場合について説明する。図３３は、複数のムービーフラグメントで構成されるＭＰＵの構成を示す図である。
【０３３４】
図３３では、１つのＭＰＵに格納されるサンプル（＃１−＃６）は、２つのムービーフラグメントに分けて格納される。第１のムービーフラグメントは、サンプル＃１−＃３に基づいて生成され、対応するｍｏｏｆボックスが生成される。第２のムービーフラグメントは、サンプル＃４−＃６に基づいて生成され、対応するｍｏｏｆボックスが生成される。
【０３３５】
第１のムービーフラグメントにおけるｍｏｏｆボックス及びｍｄａｔボックスのヘッダは、ムービーフラグメントメタデータ＃１としてＭＭＴペイロード及びＭＭＴパケットに格納される。一方、第２のムービーフラグメントにおけるｍｏｏｆボックス及びｍｄａｔボックスのヘッダは、ムービーフラグメントメタデータ＃２としてＭＭＴペイロード及びＭＭＴパケットに格納される。なお、図３３において、ムービーフラグメントメタデータが格納されたＭＭＴペイロードは、ハッチングされている。
【０３３６】
なお、ＭＰＵを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、ＭＰＵを構成するサンプル数をＧＯＰ単位のサンプル数とし、ＧＯＰ単位の２分の１のサンプル数をムービーフラグメントとして、２つのムービーフラグメントが構成されてもよい。
【０３３７】
なお、ここでは、一つのＭＰＵに２つのムービーフラグメント（ｍｏｏｆボックス及びｍｄａｔボックス）を含む例を示すが、１つのＭＰＵに含むムービーフラグメントは２つでなくとも、３つ以上であってもよい。また、ムービーフラグメントに格納するサンプルは等分したサンプル数でなく、任意のサンプル数に分割してもよい。
【０３３８】
なお、図３３では、ＭＰＵメタデータ単位及びＭＦメタデータ単位がそれぞれデータユニットとしてＭＭＴペイロードに格納されている。しかしながら、送信装置１５は、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、及びｍｏｏｆなどの単位をデータユニットとして、データユニット単位でＭＭＴペイロードに格納してもよいし、データユニットをフラグメントした単位でＭＭＴペイロードに格納してもよい。また、送信装置１５は、データユニットをアグリゲーションした単位でＭＭＴペイロードに格納してもよい。
【０３３９】
また、図３３では、サンプルは、サンプル単位でＭＭＴペイロードに格納されている。しかしながら、送信装置１５は、サンプル単位でなくともＮＡＬユニット単位または複数のＮＡＬユニットをまとめた単位でデータユニットを構成し、データユニット単位でＭＭＴペイロードに格納してもよい。また、送信装置１５は、データユニットをフラグメントした単位でＭＭＴペイロードに格納してもよいし、データユニットをアグリゲーションした単位でＭＭＴペイロードに格納してもよい。
【０３４０】
なお、図３３では、ｍｏｏｆ＃１、ｍｄａｔ＃１、ｍｏｏｆ＃２、ｍｄａｔ＃２の順にＭＰＵが構成され、ｍｏｏｆ＃１には、対応するｍｄａｔ＃１が後ろについているものとしてｏｆｆｓｅｔが付与されている。しかしながら、ｍｄａｔ＃１がｍｏｏｆ＃１より前についているものしてｏｆｆｓｅｔが付与されてもよい。ただし、この場合、ｍｏｏｆ＋ｍｄａｔの形でムービーフラグメントメタデータを生成することはできず、ｍｏｏｆ及びｍｄａｔのヘッダはそれぞれ別々に伝送される。
【０３４１】
次に、図３３で説明した構成のＭＰＵが伝送される場合のＭＭＴパケットの送信順序について説明する。図３４は、ＭＭＴパケットの送信順序を説明するための図である。
【０３４２】
図３４の（ａ）は、図３３に示されるＭＰＵの構成順序でＭＭＴパケットを送信する場合の送信順序を示している。図３４の（ａ）は、具体的には、ＭＰＵメタ、ＭＦメタ＃１、メディアデータ＃１（サンプル＃１−＃３）、ＭＦメタ＃２、メディアデータ＃２（サンプル＃４−＃６）の順に送信する例を示す。
【０３４３】
図３４の（ｂ）は、ＭＰＵメタ、メディアデータ＃１（サンプル＃１−＃３）、ＭＦメタ＃１、メディアデータ＃２（サンプル＃４−＃６）、ＭＦメタ＃２の順に送信する例を示す。
【０３４４】
図３４の（ｃ）は、メディアデータ＃１（サンプル＃１−＃３）、ＭＰＵメタ、ＭＦメタ＃１、メディアデータ＃２（サンプル＃４−＃６）、ＭＦメタ＃２の順に送信する例を示す。
【０３４５】
ＭＦメタ＃１は、サンプル＃１−＃３を用いて生成され、ＭＦメタ＃２はサンプル＃４−＃６を用いて生成される。このため、図３４の（ａ）の送信方法が用いられる場合には、サンプルデータの送信にはカプセル化による遅延が発生する。
【０３４６】
これに対し、図３４の（ｂ）及び図３４の（ｃ）の送信方法が用いられる場合には、ＭＦメタを生成するのを待たずにサンプルを送信可能であるため、カプセル化による遅延は発生せず、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を低減できる。
【０３４７】
また、図３４の（ａ）送信順序においても、１つのＭＰＵが複数のムービーフラグメントに分割され、ＭＦメタに格納されるサンプル数が図１９の場合に対して小さくなっているため、図１９の場合よりもカプセル化による遅延量を小さくすることができる。
【０３４８】
なお、ここで示した方法以外に、例えば、送信装置１５は、ＭＦメタ＃１及びＭＦメタ＃２を連結し、ＭＰＵの最後にまとめて送信してもよい。この場合、異なるムービーフラグメントのＭＦメタがアグリゲーションされて、一つのＭＭＴペイロードに格納されてもよい。また、異なるＭＰＵのＭＦメタがまとめてアグリゲーションされてＭＭＴペイロードに格納されてもよい。
【０３４９】
［１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信方法］
ここでは、図３４の（ｂ）で説明した送信順序で送信されたＭＭＴパケットを受信して復号する受信装置２０の動作例について説明する。図３５及び図３６は、このような動作例を説明するための図である。
【０３５０】
受信装置２０は、図３５に示されるような送信順序で送信された、ＭＰＵメタ、サンプル、及びＭＦメタを含むＭＭＴパケットをそれぞれ受信する。サンプルデータは、受信順に連結される。
【０３５１】
受信装置２０は、ＭＦメタ＃１を受信した時刻であるＴ１に、図３６の（１）に示されるようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタ＃１の情報に基づいてサンプル＃１−＃３を取得することができ、ＭＦメタに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
【０３５２】
また、受信装置２０は、ＭＦメタ＃２を受信した時刻であるＴ２に、図３６の（２）に示されるようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタ＃２の情報を基づいてサンプル＃４−＃６を取得することができ、ＭＦメタのＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。また、受信装置２０は、図３６の（３）に示されるようにデータを連結し、ＭＰ４を構成することでＭＦメタ＃１及びＭＦメタ＃２の情報に基づいてサンプル＃１−＃６を取得してもよい。
【０３５３】
１つのＭＰＵが複数のムービーフラグメントに分割することで、ＭＰＵの中で初めのＭＦメタを取得するまでの時間が短縮されるため、復号開始時間を早めることができる。また、復号前のサンプルを蓄積するためのバッファサイズを小さくすることができる。
【０３５４】
なお、送信装置１５は、ムービーフラグメントにおける初めのサンプルを送信（或いは受信）してからムービーフラグメントに対応するＭＦメタを送信（或いは受信）するまでの時間が、エンコーダで指定されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙより短い時間となるようにムービーフラグメントの分割単位を設定してもよい。このように設定することにより、受信バッファはｃｐｂバッファに従うことができ、低遅延の復号を実現できる。この場合、ＰＴＳ及びＤＴＳにはｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいた絶対時刻を用いることができる。
【０３５５】
また、送信装置１５は、ムービーフラグメントの分割を等間隔、或いは、後続のムービーフラグメントを前のムービーフラグメントより短い間隔で分割してもよい。これにより、受信装置２０は、サンプルの復号前に必ず当該サンプルの情報を含むＭＦメタを受信することができ、連続した復号が可能となる。
【０３５６】
ＰＴＳ、及びＤＴＳの絶対時刻の算出方法は、下記の２通りの方法を用いることができる。
【０３５７】
（１）ＰＴＳ及びＤＴＳの絶対時刻は、ＭＦメタ＃１やＭＦメタ＃２の受信時刻（Ｔ１或いはＴ２）、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定される。
【０３５８】
（２）ＰＴＳ及びＤＴＳの絶対時刻は、ＭＰＵタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定される。
【０３５９】
また、（２−Ａ）送信装置１５がシグナリングする絶対時刻は、エンコーダから指定されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいて算出された絶対時刻であってもよい。
【０３６０】
また、（２−Ｂ）送信装置１５がシグナリングする絶対時刻は、ＭＦメタの受信時刻の予測値に基づいて算出された絶対時刻であってもよい。
【０３６１】
なお、ＭＦメタ＃１及びＭＦメタ＃２は、繰り返し伝送されてもよい。ＭＦメタ＃１及びＭＦメタ＃２が繰り返し伝送されることにより、受信装置２０は、ＭＦメタをパケットロス等により取得できなかった場合でも、もう一度取得することができる。
【０３６２】
ムービーフラグメントを構成するサンプルを含むＭＦＵのペイロードヘッダには、ムービーフラグメントの順番を示す識別子を格納することができる。一方、ムービーフラグメントを構成するＭＦメタの順番を示す識別子はＭＭＴペイロードには含まれない。このため、受信装置２０は、ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒでＭＦメタの順番を識別する。或いは、送信装置１５は、ＭＦメタが何番目のムービーフラグメントに属するかを示す識別子を、制御情報（メッセージ、テーブル、記述子）、ＭＭＴヘッダ、ＭＭＴペイロードヘッダ、またはデータユニットヘッダに格納してシグナリングしてもよい。
【０３６３】
なお、送信装置１５は、ＭＰＵメタ、ＭＦメタ、及びサンプルを、あらかじめ定められた所定の送信順序で送信し、受信装置２０は、あらかじめ定められた所定の送信順序に基づいて受信処理を実施してもよい。また、送信装置１５は、送信順序をシグナリングし、シグナリング情報に基づいて受信装置２０が受信処理を選択（判断）してもよい。
【０３６４】
上記のような受信方法について、図３７を用いて説明する。図３７は、図３５及び図３６で説明した受信方法の動作のフローチャートである。
【０３６５】
まず、受信装置２０は、ＭＭＴペイロードに示されるフラグメントタイプにより、ペイロードに含まれるデータが、ＭＰＵメタデータ、ＭＦメタデータであるか、サンプルデータ（ＭＦＵ）であるかを判別（識別）する（Ｓ６０１、Ｓ６０２）。データがサンプルデータである場合には、受信装置２０は、サンプルをバッファリングし、当該サンプルに対応するＭＦメタデータの受信、及び復号開始を待つ（Ｓ６０３）。
【０３６６】
一方、ステップＳ６０２において、データがＭＦメタデータである場合には、受信装置２０は、ＭＦメタデータよりサンプルの情報（ＰＴＳ、ＤＴＳ、位置情報、及びサイズ）を取得し、取得したサンプルの情報に基づいてサンプルを取得し、ＰＴＳ及びＤＴＳに基づいてサンプルを復号、提示する（Ｓ６０４）。
【０３６７】
なお、図示されないが、データがＭＰＵメタデータである場合、ＭＰＵメタデータには、復号に必要な初期化情報が含まれている。このため、受信装置２０はこれを蓄積し、ステップＳ６０４においてサンプルデータの復号に用いる。
【０３６８】
なお、受信装置２０は、受信したＭＰＵのデータ（ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータ）を蓄積装置に蓄積する場合には、図１９または図３３で説明した、ＭＰＵの構成に並び替えた後に、蓄積する。
【０３６９】
なお、送信側においては、ＭＭＴパケットには、同一のパケットＩＤを持つパケットに対して、パケットシーケンス番号を付与する。このとき、ＭＰＵメタデータ、ＭＦメタデータ、サンプルデータを含むＭＭＴパケットが送信順序に並び替えられた後にパケットシーケンス番号が付与されてもよいし、並び替える前の順序でパケットシーケンス番号が付与されてもよい。
【０３７０】
並び替える前の順序でパケットシーケンス番号が付与される場合には、受信装置２０において、パケットシーケンス番号に基づいて、データをＭＰＵの構成順序に並び替えることができ、蓄積が容易となる。
【０３７１】
［アクセスユニットの先頭及びスライスセグメントの先頭を検出する方法］
ＭＭＴパケットヘッダ、及びＭＭＴペイロードヘッダの情報に基づき、アクセスユニットの先頭やスライスセグメントの先頭を検出する方法について説明する。
【０３７２】
ここでは、非ＶＣＬ  ＮＡＬユニット（アクセスユニットデリミタ、ＶＰＳ、ＳＰＳ、ＰＰＳ、及びＳＥＩなど）を、まとめてデータユニットとしてＭＭＴペイロードに格納する場合、及び、非ＶＣＬ  ＮＡＬユニットをそれぞれデータユニットとし、データユニットをアグリゲーションして１つのＭＭＴペイロードに格納する場合の２つの例を示す。
【０３７３】
図３８は、非ＶＣＬ  ＮＡＬユニットを、個別にデータユニットとし、アグリゲーションする場合を示す図である。
【０３７４】
図３８の場合、アクセスユニットの先頭は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅ値がＭＦＵであるＭＭＴパケットであり、かつ、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が１であり、かつｏｆｆｓｅｔ値が０であるデータユニットを含むＭＭＴペイロードの先頭データである。このとき、Ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値は０である。
【０３７５】
また、図３８の場合、スライスセグメントの先頭は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅ値がＭＦＵであるＭＭＴパケットであり、かつａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が０、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるＭＭＴペイロードの先頭データである。
【０３７６】
図３９は、非ＶＣＬ  ＮＡＬユニットを、まとめてデータユニットとする場合を示す図である。なお、パケットヘッダのフィールド値は、図１７（または図１８）で示した通りである。
【０３７７】
図３９の場合、アクセスユニットの先頭は、Ｏｆｆｓｅｔ値が０であるパケットにおけるペイロードの先頭データが、アクセスユニットの先頭となる。
【０３７８】
また、図３９の場合、スライスセグメントの先頭は、Ｏｆｆｓｅｔ値が０とは異なる値であり、ｆｒａｇｍｅｎｔａｔｉｏｎ  ｉｎｄｉｃａｔｏｒ値が００或いは０１であるパケットのペイロードの先頭データが、スライスセグメントの先頭となる。
【０３７９】
［パケットロスが発生した場合の受信処理］
通常、パケットロスが発生する環境において、ＭＰ４形式のデータを伝送する場合、受信装置２０は、ＡＬＦＥＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｌａｙｅｒ  ＦＥＣ）や、パケット再送制御等によりパケットを復元する。
【０３８０】
しかし、放送のようなストリーミングにおいてＡＬ−ＦＥＣを用いられない場合にパケットロスが発生した場合には、パケットを復元できない。
【０３８１】
受信装置２０は、パケットロスによりデータが失われた後、再び映像や音声の復号を再開させる必要がある。そのためには、受信装置２０は、アクセスユニットやＮＡＬユニットの先頭を検出し、アクセスユニットやＮＡＬユニットの先頭から復号を開始する必要がある。
【０３８２】
しかし、ＭＰ４形式のＮＡＬユニットの先頭には、スタートコードがついていないため、受信装置２０は、ストリームを解析しても、アクセスユニットやＮＡＬユニットの先頭を検出できない。
【０３８３】
図４０は、パケットロスが発生した場合の受信装置２０の動作のフローチャートである。
【０３８４】
受信装置２０は、ＭＭＴパケットやＭＭＴペイロードのヘッダにおけるＰａｃｋｅｔｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒや、ｐａｃｋｅｔ  ｃｏｕｎｔｅｒ、ｆｒａｇｍｅｎｔ  ｃｏｕｎｔｅｒなどによりパケットロスを検出し（Ｓ７０１）、前後の関係から、どのパケットが消失したかを判定する（Ｓ７０２）。
【０３８５】
受信装置２０は、パケットロスが発生していないと判定された場合（Ｓ７０２でＮｏ）には、ＭＰ４ファイルを構成し、アクセスユニット或いはＮＡＬユニットを復号する（Ｓ７０３）。
【０３８６】
受信装置２０は、パケットロスが発生したと判定された場合（Ｓ７０２でＹｅｓ）には、パケットロスしたＮＡＬユニットに相当するＮＡＬユニットをダミーデータにより生成し、ＭＰ４ファイルを構成する（Ｓ７０４）。受信装置２０は、ＮＡＬユニットにダミーデータを入れる場合には、ＮＡＬユニットのタイプにダミーデータであることを示す。
【０３８７】
また、受信装置２０は、図１７、図１８、図３８、及び図３９で説明した方法に基づいて、次のアクセスユニットやＮＡＬユニットの先頭を検出し、先頭データからデコーダに入力することで、復号を再開することができる（Ｓ７０５）。
【０３８８】
なお、パケットロスが発生した場合には、受信装置２０は、パケットヘッダに基づいて検出された情報に基づいてアクセスユニット及びＮＡＬユニットの先頭から復号を再開してもよいし、ダミーデータのＮＡＬユニットを含む、再構成されたＭＰ４ファイルのヘッダ情報に基づいてアクセスユニット及びＮＡＬユニットの先頭から復号を再開してもよい。
【０３８９】
受信装置２０は、ＭＰ４ファイル（ＭＰＵ）を蓄積する際には、パケットロスにより消失したパケットデータ（ＮＡＬユニットなど）は、放送や通信から別途取得して蓄積（置き換え）してもよい。
【０３９０】
このとき、受信装置２０は、消失したパケットを通信から取得する場合には、消失したパケットの情報（パケットＩＤや、ＭＰＵシーケンス番号、パケットシーケンス番号、ＩＰデータフロー番号、及びＩＰアドレスなど）をサーバーに通知し、当該パケットを取得する。受信装置２０は、消失したパケットのみに限らず、消失したパケット前後のパケット群を同時に取得してもよい。
【０３９１】
［ムービーフラグメントの構成方法］
ここでは、ムービーフラグメントの構成方法について詳細に説明する。
【０３９２】
図３３で説明されたように、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数は、任意である。例えば、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数は、固定的に定められた所定の数であってもよいし、動的に決定されてもよい。
【０３９３】
ここで、送信側（送信装置１５）において下記の条件を満たすようにムービーフラグメントが構成されることで、受信装置２０における低遅延の復号を保証することができる。
【０３９４】
その条件とは、以下の通りである。
【０３９５】
送信装置１５は、受信装置２０が、任意のサンプル（Ｓａｍｐｌｅ（ｉ））の復号時刻（ＤＴＳ（ｉ））より前には必ず当該サンプルの情報を含むＭＦメタを受信できるように、サンプルデータを分割した単位をムービーフラグメントとしてＭＦメタを生成・送信する。
【０３９６】
具体的には、送信装置１５は、ＤＴＳ（ｉ）より前に符号化済のサンプル（ｉ番目のサンプルを含む）を用いてムービーフラグメントを構成する。
【０３９７】
低遅延の復号を保証するように、ムービーフラグメントを構成するサンプル数や１つのＭＰＵを構成するムービーフラグメント数を動的に決定する方法としては、例えば、下記の方法が用いられる。
【０３９８】
（１）復号開始時、ＧＯＰ先頭のサンプルＳａｍｐｌｅ（０）の復号時刻ＤＴＳ（０）は、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいた時刻である。送信装置は、ＤＴＳ（０）より前の時刻に、符号化完了済のサンプルを用いて第１のムービーフラグメントを構成する。また、送信装置１５は、第１のムービーフラグメントに対応するＭＦメタデータを生成し、ＤＴＳ（０）より前の時刻に送信する。
【０３９９】
（２）送信装置１５は、以降のサンプルにおいても、上記の条件を満たすようにムービーフラグメントを構成する。
【０４００】
例えば、ムービーフラグメントの先頭のサンプルがｋ番目のサンプルであるとしたとき、ｋ番目のサンプルを含むムービーフラグメントのＭＦメタは、ｋ番目のサンプルの復号時刻ＤＴＳ（ｋ）までに送信される。送信装置１５は、ｌ番目のサンプルの符号化完了時刻がＤＴＳ（ｋ）より前であり、（ｌ＋１）番目のサンプルの符号化完了時刻がＤＴＳ（ｋ）より後である場合には、ｋ番目のサンプルからｌ番目のサンプルを用いてムービーフラグメントを構成する。
【０４０１】
なお、送信装置１５は、ｋ番目のサンプルから、ｌ番目に満たないサンプルまでを用いてムービーフラグメントを構成してもよい。
【０４０２】
（３）送信装置１５は、ＭＰＵ最後のサンプルの符号化完了後、残りのサンプルを用いてムービーフラグメントを構成し、当該ムービーフラグメントに対応するＭＦメタデータを生成し、送信する。
【０４０３】
なお、送信装置１５は、符号化完了済のすべてのサンプルを用いてムービーフラグメントを構成せずに、符号化完了済の一部のサンプルを用いてムービーフラグメントを構成してもよい。
【０４０４】
なお、上記では、低遅延の復号を保証するように、上記条件に基づいて動的に、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数が決定される例を示した。しかしながら、サンプル数及びムービーフラグメント数の決定方法は、このような方法に限定されるものではない。例えば、１つのＭＰＵを構成するムービーフラグメント数が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。また、１つのＭＰＵを構成するムービーフラグメント数、及びムービーフラグメントを分割する時刻（或いはムービーフラグメントの符号量）が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。
【０４０５】
また、ＭＰＵが複数のムービーフラグメントに分割されている場合、ＭＰＵが複数のムービーフラグメントに分割されているかどうかを示す情報、分割されたムービーフラグメントの属性、または分割されたムービーフラグメントに対するＭＦメタの属性が送信されてもよい。
【０４０６】
ここで、ムービーフラグメントの属性とは、ムービーフラグメントが、ＭＰＵの先頭のムービーフラグメントであるか、ＭＰＵの最後のムービーフラグメントであるか、それ以外のムービーフラグメントであるか等を示す情報である。
【０４０７】
また、ＭＦメタの属性とは、ＭＦメタが、ＭＰＵの先頭のムービーフラグメントに対応するＭＦメタであるか、ＭＰＵの最後のムービーフラグメントに対応するＭＦメタであるか、それ以外のムービーフラグメントに対応するＭＦメタであるか等を示す情報である。
【０４０８】
なお、送信装置１５は、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数を制御情報として格納し、送信してもよい。
【０４０９】
［受信装置の動作］
上記のように構成されたムービーフラグメントに基づく受信装置２０の動作について説明する。
【０４１０】
受信装置２０は、ＰＴＳ及びＤＴＳのそれぞれの絶対時刻を、ＭＰＵタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定する。
【０４１１】
受信装置２０は、ＭＰＵが複数のムービーフラグメントに分割されているかどうかの情報に基づいて、ＭＰＵが分割されている場合は、分割されたムービーフラグメントの属性に基づいて、下記のように処理をする。
【０４１２】
（１）受信装置２０は、ムービーフラグメントがＭＰＵの先頭のムービーフラグメントである場合、ＭＰＵタイムスタンプ記述子に含まれる先頭サンプルのＰＴＳの絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻を用いて、ＰＴＳ及びＤＴＳの絶対時刻を生成する。
【０４１３】
（２）受信装置２０は、ムービーフラグメントがＭＰＵの先頭のムービーフラグメントでない場合、ＭＰＵタイムスタンプ記述子の情報を用いずに、ＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻を用いて、ＰＴＳ及びＤＴＳの絶対時刻を生成する。
【０４１４】
（３）受信装置２０は、ムービーフラグメントがＭＰＵの最後のムービーフラグメントである場合、すべてのサンプルのＰＴＳ及びＤＴＳの絶対時刻を算出後、ＰＴＳ及びＤＴＳの計算処理（相対時刻の加算処理）をリセットする。なお、リセット処理は、ＭＰＵ先頭のムービーフラグメントにおいて実施してもよい。
【０４１５】
受信装置２０は、下記のようにムービーフラグメントが分割されているかどうかの判定を行ってもよい。また、受信装置２０は、下記のようにムービーフラグメントの属性情報を取得してもよい。
【０４１６】
例えば、受信装置２０は、ＭＭＴＰ（ＭＭＴ  Ｐｒｏｔｏｃｏｌ）ペイロードヘッダに示されるムービーフラグメントの順番を示す識別子ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値に基づいて分割されているかどうかを判定してもよい。
【０４１７】
具体的には、受信装置２０は、１つのＭＰＵに含まれるムービーフラグメントの数が１であり、かつ、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値が１であり、かつ、当該フィールド値が２以上の値が存在する場合に、当該ＭＰＵは複数のムービーフラグメントに分割されていると判定してもよい。
【０４１８】
また、受信装置２０は、１つのＭＰＵに含まれるムービーフラグメントの数が１であり、かつ、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値が０であり、かつ、当該フィールド値が０以外の値が存在する場合に、当該ＭＰＵは複数のムービーフラグメントに分割されていると判定してもよい。
【０４１９】
ムービーフラグメントの属性情報も同様に、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒに基づいて判定されてもよい。
【０４２０】
なお、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒを用いずとも、一つＭＰＵに含まれるムービーフラグメントやＭＦメタの送信をカウントすることにより、ムービーフラグメントが分割されているかどうかや、ムービーフラグメントの属性情報を判定されてもよい。
【０４２１】
以上説明したような送信装置１５および受信装置２０の構成により、受信装置２０は、ＭＰＵよりも短い間隔でムービーフラグメントメタデータを受信でき、低遅延での復号開始が可能となる。また、ＭＰ４パースの方法に基づいた復号処理を用いて、低遅延での復号を行うことが可能となる。
【０４２２】
以上説明したようにＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作について、フローチャートを用いて説明する。図４１は、ＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作のフローチャートである。なお、このフローチャートは、図３７のステップＳ６０４の動作をより詳細に図示するものである。
【０４２３】
まず、受信装置２０は、ＭＭＴＰペイロードヘッダに示されるデータ種別に基づいて、データ種別がＭＦメタである場合に、ＭＦメタデータを取得する（Ｓ８０１）。
【０４２４】
次に、受信装置２０は、ＭＰＵが複数のムービーフラグメントに分割されているかどうかを判定し（Ｓ８０２）、ＭＰＵが複数のムービーフラグメントに分割されている場合（Ｓ８０２でＹｅｓ）には、受信したＭＦメタデータがＭＰＵ先頭のメタデータであるかどうかを判定する（Ｓ８０３）。受信装置２０は、受信したＭＦメタデータがＭＰＵ先頭のＭＦメタデータである場合（Ｓ８０３でＹｅｓ）には、ＭＰＵタイムスタンプ記述子に示されるＰＴＳの絶対時刻、並びにＭＦメタデータに示されるＰＴＳ及びＤＴＳの相対時刻よりＰＴＳ及びＤＴＳの絶対時刻を算出し（Ｓ８０４）、ＭＰＵの最後のメタデータであるかどうかの判定を行う（Ｓ８０５）。
【０４２５】
一方、受信装置２０は、受信したＭＦメタデータがＭＰＵ先頭のＭＦメタデータでない場合（Ｓ８０３でＮｏ）には、ＭＰＵタイムスタンプ記述子の情報は用いずＭＦメタデータに示されるＰＴＳ及びＤＴＳの相対時刻を用いてＰＴＳ及びＤＴＳの絶対時刻を算出し（Ｓ８０８）、ステップＳ８０５の処理に移行する。
【０４２６】
ステップＳ８０５において、ＭＰＵ最後のＭＦメタデータであると判定された場合（Ｓ８０５でＹｅｓ）、受信装置２０は、すべてのサンプルのＰＴＳ及びＤＴＳの絶対時刻を算出後、ＰＴＳ及びＤＴＳの計算処理をリセットする。ステップＳ８０５においてＭＰＵ最後のＭＦメタデータでないと判定された場合（Ｓ８０５でＮｏ）、受信装置２０は処理を終了する。
【０４２７】
また、ステップＳ８０２においてＭＰＵが複数のムービーフラグメントに分割されていないと判定された場合（Ｓ８０２でＮｏ）には、受信装置２０は、ＭＰＵの後に送信されるＭＦメタデータに基づき、サンプルデータを取得し、ＰＴＳ及びＤＴＳを決定する（Ｓ８０７）。
【０４２８】
そして、図示されないが、受信装置２０は、最後に、決定したＰＴＳ及びＤＴＳに基づいて復号処理、提示処理を実施する。
【０４２９】
［ムービーフラグメントを分割したときに発生する課題、及び、その解決策］
これまで、ムービーフラグメントを分割することによりＥｎｄ−ｔｏ−Ｅｎｄ遅延を短縮する方法について説明してきた。ここからは、ムービーフラグメントを分割したときに新たに発生する課題、及び、その解決策について説明する。
【０４３０】
まず、背景として、符号化データにおけるピクチャ構造について説明する。図４２は、時間スケーラビリティを実現する際の各ＴｅｍｐｏｒａｌＩｄにおけるピクチャの予測構造の例を示す図である。
【０４３１】
ＭＰＥＧ−４  ＡＶＣやＨＥＶＣ（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）などの符号化方式においては、他のピクチャから参照可能なＢピクチャ（双方向参照予測ピクチャ）を用いることにより時間方向のスケーラビリティ（時間スケーラビリティ）が実現できる。
【０４３２】
図４２の（ａ）に示されるＴｅｍｐｏｒａｌＩｄとは、符号化構造の階層の識別子であり、ＴｅｍｐｏｒａｌＩｄは、値が大きくなるほど深い階層であることを示す。四角のブロックはピクチャを示し、ブロック内のＩｘは、Ｉピクチャ（画面内予測ピクチャ）、Ｐｘは、Ｐピクチャ（前方参照予測ピクチャ）、Ｂｘ及びｂｘは、Ｂピクチャ（双方向参照予測ピクチャ）を示す。Ｉｘ／Ｐｘ／Ｂｘのｘは表示オーダーを示し、ピクチャを表示する順番を表わす。ピクチャ間の矢印は参照関係を示し、例えば、Ｂ４のピクチャはＩ０、Ｂ８を参照画像として予測画像を生成することを示す。ここで、一のピクチャが、自らのＴｅｍｐｏｒａｌＩｄより大きいＴｅｍｐｏｒａｌＩｄを持つ他のピクチャを参照画像として使うことは禁止されている。階層が規定されているのは時間スケーラビリティを持たせるためであり、例えば、図４２において全てのピクチャを復号すると１２０ｆｐｓ（ｆｒａｍｅ  ｐｅｒ  ｓｅｃｏｎｄ）の映像が得られるが、ＴｅｍｐｏｒａｌＩｄが０から３までの階層のみを復号すると６０ｆｐｓの映像が得られる。
【０４３３】
図４３は、図４２の各ピクチャにおける復号時刻（ＤＴＳ）と表示時刻（ＰＴＳ）との関係を示す図である。例えば、図４３に示されるピクチャＩ０は、復号及び表示においてギャップが発生しないように、Ｂ４の復号完了後に表示される。
【０４３４】
図４３に示されるように、予測構造にＢピクチャが含まれる場合などには、復号順と表示順とが異なるため、受信装置２０においてピクチャを復号後にピクチャの遅延処理、及び、ピクチャの並び替え（リオーダ）処理が必要となる。
【０４３５】
以上、時間方向のスケーラビリティにおけるピクチャの予測構造の例について説明したが、時間方向のスケーラビリティが用いられない場合においても、予測構造によっては、ピクチャの遅延処理、及び、リオーダ処理が必要となる場合がある。図４４は、ピクチャの遅延処理、及び、リオーダ処理が必要となるピクチャの予測構造の一例を示す図である。なお、図４４における数字は、復号順を示す。
【０４３６】
図４４に示されるように、予測構造によっては、復号順において先頭となるサンプルと、提示順において先頭となるサンプルが異なる場合があり、図４４では、提示順で先頭となるサンプルは、復号順で４番目のサンプルとなる。なお、図４４は、予測構造の一例を示すものであり、予測構造はこのような構造に限定されるものではない。他の予測構造においても、復号順において先頭となるサンプルと、提示順において先頭となるサンプルとが異なる場合がある。
【０４３７】
図４５は、図３３と同様に、ＭＰ４形式で構成されるＭＰＵが複数のムービーフラグメントに分割されて、ＭＭＴＰペイロード、ＭＭＴＰパケットに格納される例を示す図である。なお、ＭＰＵを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、ＭＰＵを構成するサンプル数をＧＯＰ単位のサンプル数とし、ＧＯＰ単位の２分の１のサンプル数をムービーフラグメントとして、２つのムービーフラグメントが構成されてもよい。１サンプルが１つのムービーフラグメントとされてもよいし、ＭＰＵを構成するサンプルが分割されなくてもよい。
【０４３８】
図４５では、１つのＭＰＵに２つのムービーフラグメント（ｍｏｏｆボックス及びｍｄａｔボックス）が含まれる例が示されているが、１つのＭＰＵに含まれるムービーフラグメントは２つでなくてもよい。１つのＭＰＵに含まれるムービーフラグメントは、３つ以上であってもよいし、ＭＰＵに含まれるサンプル数であってもよい。また、ムービーフラグメントに格納されるサンプルは等分したサンプル数でなく、任意のサンプル数に分割されてもよい。
【０４３９】
ムービーフラグメントメタデータ（ＭＦメタデータ）には、ムービーフラグメントに含まれるサンプルのＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報が含まれており、受信装置２０は、サンプルを復号する際には、当該サンプルの情報を含むＭＦメタからＰＴＳ及びＤＴＳを抽出し、復号タイミングや提示タイミングを決定する。
【０４４０】
ここからは、詳細説明のために、ｉサンプルの復号時刻の絶対値をＤＴＳ（ｉ）と記載し、提示時刻の絶対値をＰＴＳ（ｉ）と記載する。
【０４４１】
ＭＦメタにおけるｍｏｏｆ内に格納されているタイムスタンプ情報のうちｉ番目のサンプルの情報は、具体的には、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値、及び、ｉ番目のサンプルの復号時刻と提示時刻の相対値であり、これらを以降ＤＴ（ｉ）及びＣＴ（ｉ）と記載する。
【０４４２】
ムービーフラグメントメタデータ＃１には、サンプル＃１−＃３のＤＴ（ｉ）及びＣＴ（ｉ）が含まれており、ムービーフラグメントメタデータ＃２には、サンプル＃４−＃６のＤＴ（ｉ）及びＣＴ（ｉ）が含まれている。
【０４４３】
また、ＭＰＵ先頭のアクセスユニットのＰＴＳ絶対値は、ＭＰＵタイムスタンプ記述子などに格納されており、受信装置２０は、ＭＰＵ先頭のアクセスユニットのＰＴＳ＿ＭＰＵと、ＣＴ及びＤＴとに基づいてＰＴＳ及びＤＴＳを算出する。
【０４４４】
図４６は、＃１−＃１０のサンプルによりＭＰＵが構成される場合のＰＴＳ及びＤＴＳの算出方法と課題とを説明するための図である。
【０４４５】
図４６の（ａ）は、ＭＰＵがムービーフラグメントに分割されない例を示し、図４６の（ｂ）は、ＭＰＵが５サンプル単位の２つのムービーフラグメントに分割される例を示し、図４６の（ｃ）は、ＭＰＵがサンプル単位に１０のムービーフラグメントに分割される例を示す。
【０４４６】
図４５で説明したように、ＭＰＵタイムスタンプ記述子と、ＭＰ４内のタイムスタンプ情報（ＣＴ及びＤＴ）とを用いてＰＴＳ及びＤＴＳが算出される場合において、図４４における提示順で先頭となるサンプルは、復号順で４番目である。このため、ＭＰＵタイムスタンプ記述子に格納されているＰＴＳは、復号順で４番目のサンプルのＰＴＳ（絶対値）となる。なお、以降では、このサンプルをＡサンプルと呼ぶ。また、復号順で先頭のサンプルをＢサンプルと呼ぶ。
【０４４７】
タイムスタンプに係る絶対時刻情報は、ＭＰＵタイムスタンプ記述子の情報のみであるため、受信装置２０は、Ａサンプルが到着するまで、その他のサンプルのＰＴＳ（絶対時刻）及びＤＴＳ（絶対時刻）を算出できない。受信装置２０は、ＢサンプルのＰＴＳ及びＤＴＳも算出できない。
【０４４８】
図４６の（ａ）の例では、Ａサンプルは、Ｂサンプルと同じムービーフラグメントに含まれ、一つのＭＦメタに格納される。このため、受信装置２０は、当該ＭＦメタを受信後、すぐにＢサンプルのＤＴＳを決定できる。
【０４４９】
図４６の（ｂ）の例では、Ａサンプルは、Ｂサンプルと同じムービーフラグメントに含まれ、一つのＭＦメタに格納される。このため、受信装置２０は、当該ＭＦメタを受信後、すぐにＢサンプルのＤＴＳを決定できる。
【０４５０】
図４６の（ｃ）の例では、Ａサンプルは、Ｂサンプルと異なるムービーフラグメントに含まれる。このため、受信装置２０は、Ａサンプルを含むムービーフラグメントのＣＴ及びＤＴを含むＭＦメタを受信後でなければ、ＢサンプルのＤＴＳを決定できない。
【０４５１】
したがって、図４６の（ｃ）の例の場合には、受信装置２０は、Ｂサンプルの到着後、すぐに復号を開始できない。
【０４５２】
このように、Ｂサンプルを含むムービーフラグメントに、Ａサンプルが含まれない場合には、受信装置２０は、Ａサンプルを含むムービーフラグメントに係るＭＦメタを受信した後でなければ、Ｂサンプルの復号を開始できない。
【０４５３】
提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、ＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されなくなるまでにムービーフラグメントが分割されることにより、この課題は発生する。また、ＭＦメタが後送りであるか先送りであるかにかかわらず、この課題は発生する。
【０４５４】
このように、提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、Ａサンプルと、Ｂサンプルとが同一ムービーフラグメントに格納されない場合には、Ｂサンプルの受信後、すぐにＤＴＳを決定できない。そこで、送信装置１５は、別途、ＢサンプルのＤＴＳ（絶対値）、或いはＢサンプルのＤＴＳ（絶対値）を受信側において算出可能な情報を送信する。このような情報は、制御情報やパケットヘッダ等を用いて送信されてもよい。
【０４５５】
受信装置２０は、このような情報を用いてＢサンプルのＤＴＳ（絶対値）を算出する。図４７は、このような情報を用いてＤＴＳが算出される場合の受信動作のフローチャートである。
【０４５６】
受信装置２０は、ＭＰＵ先頭のムービーフラグメントを受信し（Ｓ９０１）、ＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されているかどうかを判定する（Ｓ９０２）。同一ムービーフラグメントに格納されている場合（Ｓ９０２でＹｅｓ）は、受信装置２０は、ＢサンプルのＤＴＳ（絶対時刻）を用いず、ＭＦメタの情報のみを用いてＤＴＳを算出し、復号を開始する（Ｓ９０４）。なお、ステップＳ９０４において、受信装置２０は、ＢサンプルのＤＴＳを用いてＤＴＳを決定してもよい。
【０４５７】
一方、ステップＳ９０２においてＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されていない場合（Ｓ９０２でＮｏ）、受信装置２０は、ＢサンプルのＤＴＳ（絶対時刻）を取得し、ＤＴＳを決定し、復号を開始する（Ｓ９０３）。
【０４５８】
なお、以上の説明では、ＭＭＴ規格におけるＭＦメタ（ＭＰ４形式のｍｏｏｆ内に格納されているタイムスタンプ情報）を用いて、各サンプルの復号時刻の絶対値と、提示時刻の絶対値とを算出する例について説明したが、ＭＦメタを、各サンプルの復号時刻の絶対値と、提示時刻の絶対値を算出に用いることができる任意の制御情報に置き換えて実施しても良いことは言うまでもない。このような制御情報の例としては、上述したｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値ＣＴ（ｉ）を、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの提示時刻の相対値に置き換えた制御情報や、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値ＣＴ（ｉ）とｉ番目のサンプルと（ｉ＋１）番目のサンプルの提示時刻の相対値との両方を含む制御情報などがある。
【０４５９】
（実施の形態３）
［概要］
実施の形態３では、映像、音声、字幕、及びデータ放送などのコンテンツを放送で伝送する場合のコンテンツの送信方法及びデータ構造について説明する。つまり、放送ストリームの再生に特化したコンテンツの送信方法及びデータ構造について説明する。
【０４６０】
なお、実施の形態３では、多重化方式としてＭＭＴ方式（以下、単にＭＭＴとも記載する）が用いられる例について説明するが、ＭＰＥＧ−ＤＡＳＨまたはＲＴＰなど、その他の多重化方式が用いられてもよい。
【０４６１】
まず、ＭＭＴにおけるデータユニット（ＤＵ：Ｄａｔａ  Ｕｎｉｔ）のペイロードへの格納方法の詳細について説明する。図４８は、ＭＭＴにおけるデータユニットのペイロードへの格納方法を説明するための図である。
【０４６２】
ＭＭＴでは、送信装置は、ＭＰＵを構成するデータの一部を、データユニットとしてＭＭＴＰペイロードに格納し、ヘッダをつけて伝送する。ヘッダにはＭＭＴＰペイロードヘッダ、及び、ＭＭＴＰパケットヘッダが含まれる。なお、データユニットの単位は、ＮＡＬユニット単位でもよいし、サンプル単位でもよい。
【０４６３】
図４８の（ａ）は、送信装置が複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す。図４８の（ａ）の例では、複数のデータユニットそれぞれの先頭に、データユニットヘッダ（ＤＵＨ：Ｄａｔａ  Ｕｎｉｔ  Ｈｅａｄｅｒ）、及び、データユニット長（ＤＵＬ：Ｄａｔａ  Ｕｎｉｔ  Ｌｅｎｇｔｈ）が付与され、データユニットヘッダ及びデータユニット長が付与されたデータユニットが複数まとめてペイロードに格納される。
【０４６４】
図４８の（ｂ）は、一つのデータユニットを一つのペイロードに格納する例を示す。図４８の（ｂ）の例では、データユニットの先頭に、データユニットヘッダが付与されてペイロードに格納される。図４８の（ｃ）は、一つのデータユニットを分割し、分割されたデータユニットに、データユニットヘッダが付与されてペイロードに格納される例を示す。
【０４６５】
データユニットには、映像、音声、または字幕などの同期に関する情報を含むメディアであるｔｉｍｅｄ−ＭＦＵ、ファイルなど同期に関する情報を含まないメディアであるｎｏｎ−ｔｉｍｅｄ−ＭＦＵ、ＭＰＵメタデータ、ＭＦメタデータなどの種類があり、データユニットの種類に応じてデータユニットヘッダが定められる。なお、ＭＰＵメタデータ、及び、ＭＦメタデータにはデータユニットヘッダは存在しない。
【０４６６】
また、送信装置は、異なる種類のデータユニットをアグリゲーションすることは原則としてできないが、異なる種類のデータユニットをアグリゲーションできるように規定されてもよい。例えば、サンプル毎にムービーフラグメントに分割されている場合などのＭＦメタデータのサイズが小さい場合、ＭＦメタデータとメディアデータとをアグリゲーションすることにより、パケット数を削減でき、さらに、伝送容量を削減することもできる。
【０４６７】
データユニットがＭＦＵの場合は、ＭＰＵ（ＭＰ４）を構成するための情報など、ＭＰＵの一部の情報がヘッダとして格納される。
【０４６８】
例えば、ｔｉｍｅｄ−ＭＦＵのヘッダには、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ｓａｍｐｌｅ＿ｎｕｍｂｅｒ、ｏｆｆｓｅｔ、ｐｒｉｏｒｉｔｙ、及び、ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒなどが含まれ、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵのヘッダにはｉｔｅｍ＿ｉＤが含まれる。各フィールドの意味はＩＳＯ／ＩＥＣ２３００８−１あるいはＡＲＩＢ  ＳＴＤ−Ｂ６０などの規格に示される。以下、このような規格において規定される各フィールドの意味について説明する。
【０４６９】
ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、ＭＦＵが属するムービーフラグメントのシーケンス番号を示し、ＩＳＯ／ＩＥＣ１４４９６−１２にも示される。
【０４７０】
ｓａｍｐｌｅ＿ｎｕｍｂｅｒは、当該ＭＦＵが属するサンプル番号を示し、ＩＳＯ／ＩＥＣ１４４９６−１２にも示される。
【０４７１】
ｏｆｆｓｅｔは、当該ＭＦＵが属するサンプルにおける、ＭＦＵのオフセット量をバイト単位で示す。
【０４７２】
ｐｒｉｏｒｉｔｙは、当該ＭＦＵが属するＭＰＵにおける、ＭＦＵの相対的な重要度を示し、ｐｒｉｏｒｉｔｙの数字が大きいＭＦＵは、ｐｒｉｏｒｉｔｙの数字が小さいＭＦＵよりも重要であることを示す。
【０４７３】
ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒは、復号処理が当該ＭＦＵに依存しているＭＦＵ数（すなわち、このＭＦＵを復号処理しなければ、その復号処理を行うことができないＭＦＵの数）を示す。例えば、ＭＦＵがＨＥＶＣである場合においてＢピクチャまたはＰピクチャがＩピクチャを参照する場合、当該ＢピクチャまたはＰピクチャは、Ｉピクチャを復号処理しなければ復号処理を行うことができない。
【０４７４】
したがって、ＭＦＵがサンプル単位である場合は、ＩピクチャのＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、当該Ｉピクチャを参照するピクチャ数が示される。ＭＦＵがＮＡＬユニット単位の場合は、Ｉピクチャに属するＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、当該Ｉピクチャを参照するピクチャに属するＮＡＬユニット数が示される。さらに、時間方向階層符号化された映像信号の場合、拡張レイヤのＭＦＵは、ベースレイヤのＭＦＵに依存するため、ベースレイヤのＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、拡張レイヤのＭＦＵの数が示される。本フィールドは、依存するＭＦＵ数が決定した後でなければ生成できない。
【０４７５】
ｉｔｅｍ＿ｉＤは、アイテムを一意に特定する識別子を示す。
【０４７６】
［ＭＰ４非サポートモード］
図１９、及び、図２１で説明したように、送信装置がＭＭＴにおけるＭＰＵを伝送する方法としては、ＭＰＵメタデータまたはＭＦメタデータをメディアデータの前または後に送信する方法、及び、メディアデータのみを送信する方法がある。また、受信装置では、ＭＰ４に準拠した受信装置や受信方法を用いて復号を行う方法や、ヘッダを用いずに復号する方法がある。
【０４７７】
放送ストリーム再生に特化したデータの送信方法として、例えば、受信装置におけるＭＰ４再構成をサポートしない送信方法がある。
【０４７８】
受信装置におけるＭＰ４再構成をサポートしない送信方法とは、例えば、図２１の（ｂ）に示されるようにメタデータ（ＭＰＵメタデータ及びＭＦメタデータ）を送信しない方法がある。この場合、ＭＭＴＰパケットに含まれるフラグメントタイプ（データユニットの種類を示す情報）のフィールド値は、２（＝ＭＦＵ）固定である。
【０４７９】
メタデータが送信されない場合は、これまで説明したように、ＭＰ４準拠の受信装置などでは、受信したデータをＭＰ４として復号することはできないが、メタデータ（ヘッダ）を用いずに復号することが可能である。
【０４８０】
そのため、メタデータは放送ストリーム復号及び再生に必ずしも必須の情報ではない。同様に、図４８で説明した、ｔｉｍｅｄ−ＭＦＵにおけるデータユニットヘッダの情報は、受信装置においてＭＰ４を再構成するための情報である。放送ストリーム再生においてＭＰ４を再構成する必要はないため、ｔｉｍｅｄ−ＭＦＵにおけるデータユニットヘッダ（以下、ｔｉｍｅｄ−ＭＦＵヘッダとも記載する）の情報は、放送ストリーム再生に必ずしも必要な情報ではない。
【０４８１】
受信装置は、メタデータ、および、データユニットヘッダにおけるＭＰ４を再構成するための情報（以下、ＭＰ４構成情報とも記載する）を用いることにより、容易にＭＰ４を再構成することができる。しかし、受信装置は、メタデータ、および、データユニットヘッダにおけるＭＰ４構成情報のどちらか一方のみが伝送されていたとしても、ＭＰ４を再構成することはできない。メタデータ及びＭＰ４を再構成するための情報のどちらか一方のみが伝送されることによるメリットは少なく、必要でない情報を生成及び伝送することは、処理の増大や伝送効率の低下を招く。
【０４８２】
そこで、送信装置は、下記の方法を用いてＭＰ４構成情報のデータ構造や伝送を制御する。送信装置は、メタデータが伝送されるかどうかに基づいて、データユニットヘッダにおいてＭＰ４構成情報を示すか否かを決定する。具体的には、送信装置は、メタデータが伝送される場合には、データユニットヘッダにおいてＭＰ４構成情報を示し、メタデータが伝送されない場合には、データユニットヘッダにおいてＭＰ４構成情報を示さない。
【０４８３】
データユニットヘッダにおいてＭＰ４構成情報を示さない方法としては、例えば下記の方法を用いることができる。
【０４８４】
１．送信装置は、ＭＰ４構成情報をｒｅｓｅｒｖｅｄとし、運用しない。これにより、ＭＰ４構成情報を生成する送出側の処理量（送信装置の処理量）を削減することができる。
【０４８５】
２．送信装置は、ＭＰ４構成情報を削除し、ヘッダ圧縮する。これにより、ＭＰ４構成情報を生成する送出側の処理量を削減することができるとともに、伝送容量を削減することができる。
【０４８６】
なお、送信装置は、ＭＰ４構成情報を削除し、ヘッダ圧縮する場合には、ＭＰ４構成情報を削除（圧縮）したことを示すフラグを示してもよい。フラグは、ヘッダ（ＭＭＴＰパケットヘッダ、ＭＭＴＰペイロードヘッダ、データユニットヘッダ）または制御情報などに示される。
【０４８７】
また、メタデータが伝送されるかどうかの情報は、あらかじめ定めていてもよいし、別途ヘッダや制御情報にシグナリングし、受信装置に伝送されてもよい。
【０４８８】
例えば、ＭＦＵヘッダに当該ＭＦＵに対応するメタデータが伝送されているかの情報が格納されてもよい。
【０４８９】
一方、受信装置は、メタデータが伝送されているかどうかに基づいて、ＭＰ４構成情報が示されているかどうかを判定することができる。
【０４９０】
ここで、データの送信順序（例えば、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータのような順序）が決まっている場合は、受信装置は、メディアデータの前にメタデータが受信されたかどうかに基づいて判定してもよい。
【０４９１】
ＭＰ４構成情報が示されている場合には、受信装置は、ＭＰ４構成情報をＭＰ４の再構成に用いることができる。或いは、受信装置は、その他のアクセスユニットやＮＡＬユニットの先頭の検出などにＭＰ４構成情報を用いることができる。
【０４９２】
なお、ＭＰ４構成情報は、ｔｉｍｅｄ−ＭＦＵヘッダの全部であってもよいし一部であってもよい。
【０４９３】
また、送信装置は、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵヘッダにおいても同様に、メタデータが伝送されるかどうかに基づいて、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵヘッダにおいてｉｔｅｍ
ｉｄを示すかどうかを決定してもよい。
【０４９４】
送信装置は、ｔｉｍｅｄ−ＭＦＵと、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵとのどちらか一方においてのみＭＰ４構成情報を示すとしてもよい。どちらか一方にのみＭＰ４構成情報を示す場合、送信装置は、メタデータが伝送されるかどうかに加え、ｔｉｍｅｄ−ＭＦＵかｎｏｎ−ｔｉｍｅｄ−ＭＦＵかどうかに基づいてＭＰ４構成情報を示すかどうかを決定する。受信装置では、メタデータが伝送されるかどうか、および、ｔｉｍｅｄ／ｎｏｎ−ｔｉｍｅｄフラグに基づいてＭＰ４構成情報が示されるかどうかを判定することができる。
【０４９５】
なお、以上の説明においては、送信装置は、メタデータ（ＭＰＵメタデータ及びＭＦメタデータの両方）が伝送されるかどうかに基づいてＭＰ４構成情報を示すかどうかを決定した。しかしながら、送信装置は、メタデータの一部（ＭＰＵメタデータ、ＭＦメタデータのどちらか一方）が伝送されない場合に、ＭＰ４構成情報を示さないとしてもよい。
【０４９６】
また、送信装置は、メタデータ以外の他の情報に基づいてＭＰ４構成情報を示すかどうかを決定してもよい。
【０４９７】
例えば、ＭＰ４サポートモード／ＭＰ４非サポートモードのようなモードが定義され、送信装置は、ＭＰ４サポートモードの場合には、データユニットヘッダにおいてＭＰ４構成情報を示し、ＭＰ４非サポートモードの場合には、データユニットヘッダにおいてＭＰ４構成情報を示さないとしてもよい。また、送信装置は、ＭＰ４サポートモードの場合には、メタデータを伝送し、かつデータユニットヘッダにおいてＭＰ４構成情報を示し、ＭＰ４非サポートモードの場合には、メタデータを伝送せずにデータユニットヘッダにおいてもＭＰ４構成情報を示さないとしてもよい。
【０４９８】
［送信装置の動作フロー］
次に、送信装置の動作フローについて説明する。図４９は、送信装置の動作フローである。
【０４９９】
送信装置は、まず、メタデータを伝送するかどうかを判定する（Ｓ１００１）。送信装置は、メタデータを伝送すると判定した場合（Ｓ１００２でＹｅｓ）、ステップＳ１００３へ移行し、ＭＰ４構成情報を生成し、かつ、ヘッダに格納して伝送する（Ｓ１００３）。この場合、送信装置は、メタデータも生成し、かつ、伝送する。
【０５００】
一方、送信装置は、メタデータを伝送しないと判定した場合（Ｓ１００２でＮｏ）、ＭＰ４構成情報を生成せず、かつ、ヘッダにも格納せずに伝送する（Ｓ１００４）。この場合、送信装置は、メタデータを生成せず、伝送しない。
【０５０１】
なお、ステップＳ１００１においてメタデータを伝送するかどうかは、あらかじめ定められていてもよいし、送信装置の内部でメタデータが生成されたかどうか、送信装置の内部でメタデータが伝送されているかどうかに基づいて判定されてもよい。
【０５０２】
［受信装置の動作フロー］
次に、受信装置の動作フローについて説明する。図５０は、受信装置の動作フローである。
【０５０３】
受信装置は、まず、メタデータが伝送されているかどうかを判定する（Ｓ１１０１）。メタデータが伝送されているかどうかは、ＭＭＴＰパケットペイロードにおけるフラグメントタイプを監視することにより判定できる。また、伝送されているかどうかがあらかじめ定められていてもよい。
【０５０４】
受信装置は、メタデータが伝送されていると判定した場合（Ｓ１１０２でＹｅｓ）、ＭＰ４を再構成し、かつ、ＭＰ４構成情報を用いた復号処理を実行する（Ｓ１１０３）。一方、メタデータが伝送されていないと判定した場合（Ｓ１１０２でＮｏ）、ＭＰ４の再構成処理をせず、かつ、ＭＰ４構成情報を用いずに復号処理を実行する（Ｓ１１０４）。
【０５０５】
なお、受信装置は、これまで説明した方法を用いて、ＭＰ４構成情報を用いずにランダムアクセスポイントの検出、アクセスユニット先頭の検出、ＮＡＬユニット先頭の検出などをすることが可能であり、復号処理、パケットロスの検出、及びパケットロスからの復帰の処理をすることができる。
【０５０６】
例えば、アクセスユニット先頭は、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が１であるＭＭＴペイロードの先頭データである。このとき、Ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値は０である。
【０５０７】
また、スライスセグメントの先頭は、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が０、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるＭＭＴペイロードの先頭データである。
【０５０８】
受信装置は、以上のような情報に基づき、アクセスユニット先頭の検出、及び、スライスセグメントの検出を行うことができる。
【０５０９】
なお、受信装置は、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるデータユニットの先頭を含むパケットにおいて、ＮＡＬユニットヘッダを解析し、ＮＡＬユニットの種類がＡＵデリミタであること、及び、ＮＡＬユニットの種類がスライスセグメントであることを検出してもよい。
【０５１０】
［放送シンプルモード］
これまでは、放送ストリーム再生に特化したデータの送信方法として、受信装置におけるＭＰ４構成情報をサポートしない方法を説明したが、放送ストリーム再生に特化したデータの送信方法は、これに限るものではない。
【０５１１】
放送ストリーム再生に特化したデータの送信方法として、例えば下記の方法が用いられてもよい。
【０５１２】
・送信装置は、放送の固定受信環境では、ＡＬ−ＦＥＣを用いなくてもよい。ＡＬ−ＦＥＣが用いられない場合は、ＭＭＴＰパケットヘッダにおけるＦＥＣ＿ｔｙｐｅは常に０固定とされる。
【０５１３】
・送信装置は、放送の移動受信環境、及び、通信ＵＤＰ伝送モードにおいては、常にＡＬ−ＦＥＣを用いてもよい。ＡＬ−ＦＥＣが用いられる場合は、ＭＭＴＰパケットヘッダにおけるＦＥＣ＿ｔｙｐｅは、常に０或いは１である。
【０５１４】
・送信装置は、アセットのバルク伝送をしなくてもよい。アセットのバルク伝送がされない場合には、ＭＰＴ内部のアセットの伝送ローケーション数を示すｌｏｃａｔｉｏｎ＿ｉｎｆｏｌｏｃａｔｉｏｎは、１に固定されてよい。
【０５１５】
・送信装置は、アセット、プログラム、及びメッセージのハイブリッド伝送をしなくてもよい。
【０５１６】
また、例えば、放送シンプルモードが規定され、送信装置は、放送シンプルモードである場合には、ＭＰ４非サポートモードとする、或いは、上記に示した放送ストリーム再生に特化したデータの送信方法を用いるとしてもよい。放送シンプルモードかどうかはあらかじめ定められていてもよいし、送信装置は、放送シンプルモードであることを示すフラグを制御情報として格納し、受信装置に伝送してもよい。
【０５１７】
また、送信装置は、図４９で説明した、ＭＰ４非サポートモードであるかどうか（メタデータが伝送されているかどうか）に基づいて、ＭＰ４非サポートモードである場合には、放送シンプルモードとして、上記に示した放送ストリーム再生に特化したデータの送信方法を用いてもよい。
【０５１８】
受信装置は、放送シンプルモードである場合には、ＭＰ４非サポートモードであるとして、ＭＰ４を再構成せず復号処理をすることができる。
【０５１９】
また、受信装置は、放送シンプルモードである場合には、放送に特化した機能であることを判定し、放送に特化して受信処理をすることができる。
【０５２０】
これにより、放送シンプルモードである場合には、放送に特化した機能のみを用いることにより、送信装置及び受信装置にとって不要な処理を削減できるばかりでなく、不要な情報を圧縮して伝送しないことにより、伝送オーバーヘッドを削減することができる。
【０５２１】
なお、ＭＰ４非サポートモードが用いられる場合には、ＭＰ４構成以外の蓄積方法をサポートするヒント情報が示されてもよい。
【０５２２】
ＭＰ４構成以外の蓄積方法としては、例えば、ＭＭＴパケットやＩＰパケットをダイレクトに蓄積する方法や、ＭＭＴパケットをＭＰＥＧ−２  ＴＳパケットに変換する方法などがある。
【０５２３】
なお、ＭＰ４非サポートモードの場合には、ＭＰ４構成にしたがわないフォーマットが用いられてもよい。
【０５２４】
例えば、ＭＦＵに格納されるデータは、ＭＰ４非サポートモードの場合には、ＭＰ４形式であるＮＡＬユニットの先頭にＮＡＬユニットのサイズがついた形式でなく、バイトスタートコードがついた形式にされてもよい。
【０５２５】
ＭＭＴでは、アセットのタイプを示すアセットタイプは、ＭＰ４ＲＥＧ（ｈｔｔｐ：／／ｗｗｗ．ｍｐ４ｒａ．ｏｒｇ）に登録される４ＣＣで記載され、映像信号としてＨＥＶＣを用いる場合、‘ＨＥＶ１’または‘ＨＶＣ１’が用いられる。‘ＨＶＣ１’は、サンプルの中にパラメータセットを含んでもよい形式であり、‘ＨＥＶ１’はサンプルの中にパラメータセットを含まず、ＭＰＵメタデータにおけるサンプルエントリにパラメータセットを含む形式である。
【０５２６】
放送シンプルモードまたはＭＰ４非サポートモードの場合において、ＭＰＵメタデータ及びＭＦメタデータが伝送されない場合には、必ずサンプルの中にパラメータセットを含めると規定されてもよい。また、アセットタイプに‘ＨＥＶ１’と‘ＨＶＣ１’のどちらが示されている場合にも、必ず‘ＨＶＣ１’の形式をとると規定されてもよい。
【０５２７】
［補足１：送信装置］
以上のように、メタデータが送信されていない場合に、ＭＰ４構成情報をｒｅｓｅｒｖｅｄとし、運用しない送信装置は、図５１のように構成することも可能である。図５１は、送信装置の具体的構成の例を示す図である。
【０５２８】
送信装置３００は、符号化部３０１と、付与部３０２と、送信部３０３とを備える。符号化部３０１、付与部３０２、及び送信部３０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０５２９】
符号化部３０１は、映像信号または音声信号を符号化してサンプルデータを生成する。サンプルデータは、具体的には、データユニットである。
【０５３０】
付与部３０２は、映像信号または音声信号が符号化されたデータであるサンプルデータに、ＭＰ４構成情報を含むヘッダ情報を付与する。ＭＰ４構成情報は、受信側において当該サンプルデータをＭＰ４フォーマットのファイルとして再構成するための情報であって、サンプルデータの提示時刻が定められているか否かに応じて内容が異なる情報である。
【０５３１】
上述のように、付与部３０２は、提示時刻が定められているサンプルデータ（同期に関する情報を含むサンプルデータ）の一例であるｔｉｍｅｄ−ＭＦＵのヘッダ（ヘッダ情報）に、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ｓａｍｐｌｅ＿ｎｕｍｂｅｒ、ｏｆｆｓｅｔ、ｐｒｉｏｒｉｔｙ、及び、ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒなどのＭＰ４構成情報を含める。
【０５３２】
一方で、付与部３０２は、提示時刻が定められていないサンプルデータ（同期に関する情報を含まないサンプルデータ）の一例である、ｔｉｍｅｄ−ＭＦＵのヘッダ（ヘッダ情報）には、ｉｔｅｍ＿ｉｄなどのＭＰ４構成情報を含める。
【０５３３】
そして、付与部３０２は、送信部３０３によってサンプルデータに対応するメタデータが送信されない場合（例えば、図２１の（ｂ）のような場合）には、サンプルデータの提示時刻が定められているか否かに応じて、ＭＰ４構成情報を含まないヘッダ情報をサンプルデータに付与する。
【０５３４】
付与部３０２は、具体的には、サンプルデータの提示時刻が定められている場合には、第一のＭＰ４構成情報を含まないヘッダ情報をサンプルデータに付与し、サンプルデータの提示時刻が定められていない場合には、第二のＭＰ４構成情報を含むヘッダ情報を前記サンプルデータに付与する。
【０５３５】
例えば、付与部３０２は、図４９のステップＳ１００４に示されるように、送信部３０３によってサンプルデータに対応するメタデータが送信されない場合には、ＭＰ４構成情報をｒｅｓｅｒｖｅｄ（固定値）とすることにより、ＭＰ４構成情報を実質的に生成せず、かつ、実質的にヘッダ（ヘッダ情報）に格納しない。なお、メタデータには、ＭＰＵメタデータ、及び、ムービーフラグメントメタデータが含まれる。
【０５３６】
送信部３０３は、ヘッダ情報が付与されたサンプルデータを送信する。送信部３０３は、より具体的には、ヘッダ情報が付与されたサンプルデータをＭＭＴ方式でパケット化して送信する。
【０５３７】
上述のように、放送ストリームの再生に特化した送信方法及び受信方法では、受信装置でデータユニットをＭＰ４に再構成する必要はない。受信装置がＭＰ４に再構成する必要がない場合、ＭＰ４構成情報などの不要な情報を生成しないことで送信装置の処理は軽減される。
【０５３８】
一方で、送信装置は、必要な情報は送らなくてはならないが、余計な追加情報などを別途送信しなくて済むように、規格との整合性は保つ必要がある。
【０５３９】
送信装置３００のような構成によれば、ＭＰ４構成情報が格納される領域を固定値にすることなどにより、ＭＰ４構成情報を送信せず、必要な情報のみを規格に基づいて送信し、余計な追加情報を送信しなくて済む効果が得られる。つまり、送信装置の構成及び送信装置の処理量を削減することができる。また、不要なデータが送信されないことにより、伝送効率を向上させることができる。
【０５４０】
［補足２：受信装置］
また、送信装置３００に対応する受信装置は、例えば、図５２のように構成されてもよい。図５２は、受信装置の構成の別の例を示す図である。
【０５４１】
受信装置４００は、受信部４０１と、復号部４０２とを備える。受信部４０１、及び、復号部４０２は、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０５４２】
受信部４０１は、映像信号または音声信号が符号化されたデータであるサンプルデータであって、当該サンプルデータをＭＰ４フォーマットのファイルとして再構成するためのＭＰ４構成情報を含むヘッダ情報が付与されたサンプルデータを受信する。
【０５４３】
復号部４０２は、受信部によってサンプルデータに対応するメタデータが受信されなかった場合であって、サンプルデータの提示時刻が定められている場合に、ＭＰ４構成情報を使用せずにサンプルデータを復号する。
【０５４４】
例えば、復号部４０２は、図５０のステップＳ１１０４に示されるように、受信部４０１によってサンプルデータに対応するメタデータが受信されない場合には、ＭＰ４構成情報を用いずに復号処理を実行する。
【０５４５】
これにより、受信装置４００の構成及び受信装置４００における処理量を削減することができる。
【０５４６】
（実施の形態４）
［概要］
実施の形態４では、ファイルなど同期に関する情報を含まない非同期（ｎｏｎ−ｔｉｍｅｄ）メディアのＭＰＵへの格納方法と、ＭＭＴＰパケットでの伝送方法について説明する。なお、実施の形態４では、ＭＭＴにおけるＭＰＵを例に説明するが、同じＭＰ４ベースであるＤＡＳＨでも適用可能である。
【０５４７】
まず、ｎｏｎ−ｔｉｍｅｄメディア（以下、「非同期メディアデータ」とも言う）のＭＰＵへの格納方法の詳細について図５３を用いて説明する。図５３は、ｎｏｎ−ｔｉｍｅｄメディアのＭＰＵへの格納方法、及び、ＭＭＴＰパケットでの伝送方法を示す図である。
【０５４８】
ｎｏｎ−ｔｉｍｅｄメディアを格納するＭＰＵは、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、ｍｅｔａなどのボックスで構成され、ＭＰＵに格納するファイルに関する情報が格納される。ｍｅｔａボックス内には複数のｉｄａｔボックスを格納することができ、ｉｄａｔボックスには１つのファイルがｉｔｅｍとして格納される。
【０５４９】
ｆｔｙｐ，ｍｍｐｕ，ｍｏｏｖ，ｍｅｔａボックスの一部はＭＰＵメタデータとして一つのデータユニットを構成し、ｉｔｅｍ或いはｉｄａｔボックスはＭＦＵとしてデータユニットを構成する。
【０５５０】
データユニットはアグリゲーションやフラグメントされた後、データユニットヘッダ、ＭＭＴＰペイロードヘッダ、及びＭＭＴＰパケットヘッダが付与されてＭＭＴＰパケットとして伝送される。
【０５５１】
なお、図５３では、Ｆｉｌｅ＃１とＦｉｌｅ＃２とが１つのＭＰＵに格納される例を示している。ＭＰＵメタデータは分割されておらず、また、ＭＦＵは分割されてＭＭＴＰパケットに格納されているが、これに限るものではなく、データユニットのサイズに応じてアグリゲーションやフラグメントされてもよい。また、ＭＰＵメタデータは伝送されなくてもよく、その場合は、ＭＦＵのみが伝送される。
【０５５２】
データユニットヘッダなどのヘッダ情報には、ｉｔｅｍＩＤ（アイテムを一意に特定する識別子）が示され、ＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダには、パケットシーケンス番号（パケット毎のシーケンス番号）、及び、ＭＰＵシーケンス番号（ＭＰＵのシーケンス番号、アセット内で一意の番号。）が含まれる。
【０５５３】
なお、データユニットヘッダ以外のＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダのデータ構造はこれまで説明したｔｉｍｅｄメディア（以下、「同期メディアデータ」とも言う。）と同様であり、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ，ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ，ｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒなどが含まれる。
【０５５４】
次に、ファイル（＝Ｉｔｅｍ＝ＭＦＵ）を分割してパケット化する場合のヘッダ情報の具体例をについて、図５４及び図５５を用いて説明する。
【０５５５】
図５４及び図５５は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する例を示す図である。図５４及び図５５は、具体的には、分割されたＭＭＴＰパケット毎のヘッダ情報であるデータユニットヘッダ、ＭＭＴＰペイロードヘッダ、ＭＭＴＰパケットヘッダのいずれかに含まれる情報（パケットシーケンス番号、フラグメントカウンタ、フラグメンテーションインジケータ、ＭＰＵシーケンス番号、アイテムＩＤ）を示す。なお、図５４は、Ｆｉｌｅ＃１がＭ個（Ｍ＜＝２５６）に分割される例を示す図であり、図５５は、Ｆｉｌｅ＃２がＮ個（２５６＜Ｎ）に分割される例を示す図である。
【０５５６】
分割データ番号は、ファイル先頭からの分割データのインデックスを示しており、この情報は伝送されない。つまり、分割データ番号は、ヘッダ情報には含まれない。また、分割データ番号は、ファイルを分割することにより得られた複数の分割データのそれぞれに対応するパケットに付与される番号であり、先頭のパケットから昇順に１ずつ加算されて付与される番号である。
【０５５７】
パケットシーケンス番号は、同じパケットＩＤを持つパケットのシーケンス番号であり、図５４及び図５５では、ファイル先頭の分割データをＡとして、ファイル最後の分割データまで連続した番号が付与される。パケットシーケンス番号は、ファイル先頭の分割データから昇順に１ずつ加算されて付与される番号であり、分割データ番号に対応する番号である。
【０５５８】
フラグメントカウンタは、１つのファイルが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある複数の分割データの数を示す。また、フラグメントカウンタは、１つのファイルを分割することにより得られた複数の分割データの数である分割データ数が２５６を超える場合、分割データ数を２５６で除した余りを示す。図５４の例では、分割データ数が２５６以下であるため、フラグメントカウンタのフィールド値は（Ｍ−分割データ番号）となる。一方、図５５の例では、分割データ数が２５６を超えるため、（Ｎ−分割データ番号）を２５６で除した値（（Ｎ−分割データ番号）％２５６）となる。
【０５５９】
なお、フラグメンテーションインジケータは、ＭＭＴＰパケットに格納するデータの分割の状態を示し、分割されたデータユニットにおける先頭の分割データであるか、最後の分割データであるか、それ以外の分割データであるか、或いは、分割されていない１つ以上のデータユニットであるかを示す値である。具体的には、フラグメンテーションインジケータは、先頭の分割データでは「０１」であり、最後の分割データでは「１１」であり、残りの分割データでは「１０」であり、分割されていないデータユニットでは「００」である。
【０５６０】
本実施の形態では、分割データ数が２５６を超える場合、分割データ数を２５６で除した余りを示すとして説明するが、分割データ数は２５６に限らず、他の数（所定の数）であってもよい。
【０５６１】
図５４及び図５５に示すようにファイルを分割し、ファイルを分割することにより得られた複数の分割データのそれぞれに従来のヘッダ情報を付与して伝送する場合、受信装置において、受信したＭＭＴＰパケットに格納されるデータが、元のファイルにおいて何番目の分割データであるか（分割データ番号）、及び、ファイルの分割データ数、または、分割データ番号及び分割データ数を導出できる情報がない。このため、従来の伝送方法では、ＭＭＴＰパケットを受信しても、受信したＭＭＴＰパケットに格納されるデータの分割データ番号や分割データ数を一意に検出することができない。
【０５６２】
例えば、図５４のように分割データ数が２５６以下であり、分割データ数があらかじめ２５６以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。しかし、分割データ数が２５６以上である場合には、分割データ番号や分割データ数を特定できない。
【０５６３】
なお、ファイルの分割データ数を２５６以下に制限する場合、１つのパケットで伝送可能なデータサイズをｘ［ｂｙｔｅｓ］とした場合、伝送可能なファイルの最大サイズは  ｘ  ＊  ２５６［ｂｙｔｅｓ］に制限される。例えば、放送ではｘ＝４ｋ［ｂｙｔｅｓ］が想定されており、この場合、伝送可能なファイルの最大サイズは４ｋ＊２５６＝１Ｍ［ｂｙｔｅｓ］に制限される。従って、１［Ｍｂｙｔｅｓ］を越えるファイルを伝送したい場合にはファイルの分割データ数を２５６以下に制限することはできない。
【０５６４】
また、例えば、フラグメンテーションインジケータを参照することでファイルの先頭の分割データや最後の分割データを検出することができるため、ファイルの最後の分割データを含むＭＭＴＰパケットが受信されるまでＭＭＴＰパケット数をカウントしたり、ファイルの最後の分割データを含むＭＭＴＰパケットを受信したりした後に、パケットシーケンス番号と組み合わせることにより、分割データ番号や分割データ数を算出することは可能であるため、フラグメンテーションインジケータとパケットシーケンス番号とを組み合わせることにより分割データ番号及び分割データ数をシグナリングするとしてもよい。しかし、ファイルの途中の分割データ（つまり、ファイルの先頭の分割データでもファイルの最後の分割データでもない分割データ）を含むＭＭＴＰパケットから受信を開始した場合、当該分割データの分割データ番号や分割データ数を特定できない。当該分割データの分割データ番号や分割データ数は、ファイル最後の分割データを含むＭＭＴＰパケットを受信後に初めて特定できる。
【０５６５】
図５４及び図５５で説明した課題、つまり、ファイルの分割データを含むパケットを途中から受信した時点で、ファイルの分割データの分割データ番号および分割データ数を一意に決定するために、次の方法を用いる。
【０５６６】
まず、分割データ番号について説明する。
【０５６７】
分割データ番号については、ファイル（ｉｔｅｍ）の先頭の分割データにおけるパケットシーケンス番号をシグナリングする。
【０５６８】
シグナリングする方法として、ファイルを管理する制御情報に格納する。具体的には、図５４及び図５５においてファイルの先頭の分割データのパケットシーケンス番号Ａを、制御情報に格納する。受信装置では、制御情報よりＡの値を取得し、パケットヘッダに示されるパケットシーケンス番号より分割データ番号を算出する。
【０５６９】
分割データの分割データ番号は、当該分割データのパケットシーケンス番号から先頭の分割データのパケットシーケンス番号Ａを減ずることにより求められる。
【０５７０】
ファイルを管理する制御情報としては、例えば、ＡＲＩＢ  ＳＴＤ−Ｂ６０に規定されるアセット管理テーブルがある。アセット管理テーブルには、ファイル毎に、ファイルサイズやバージョン情報などが示され、データ伝送メッセージに格納されて伝送される。図５６は、アセット管理テーブルにおけるファイル毎のループのシンタックスを示す図である。
【０５７１】
既存のアセット管理テーブルの領域が拡張できない場合には、アイテムの情報を示すｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅフィールドの一部の３２ｂｉｔの領域を用いてシグナリングしてもよい。ｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅの一部領域に、ファイル（ｉｔｅｍ）の先頭の分割データにおけるパケットシーケンス番号が示されているかどうかを示すフラグを制御情報の例えばｒｅｓｅｒｖｅｄ＿ｆｕｔｕｒｅ＿ｕｓｅフィールドに示してもよい。
【０５７２】
データカルーセルなどファイルを繰り返し伝送する場合には、複数のパケットシーケンス番号を示してもよいし、直後に伝送するファイルの先頭のパケットシーケンス番号を示してもよい。
【０５７３】
ファイル先頭の分割データのパケットシーケンス番号に限らず、ファイルの分割データ番号とパケットシーケンス番号を紐づける情報であればよい。
【０５７４】
次に、分割データ数について説明する。
【０５７５】
アセット管理テーブルに含まれるファイル毎のループの順番を、ファイルの伝送順と規定してもよい。これにより、伝送順で連続する２つのファイルの先頭のパケットシーケンス番号がわかるため、後に伝送されるファイルの先頭パケットシーケンス番号から前に伝送されるファイルの先頭パケットシーケンス番号を減ずることにより、前に伝送されるファイルの分割データ数を特定することができる。つまり、例えば、図５４に示すＦｉｌｅ＃１と図５５に示すＦｉｌｅ＃２とがこの順に連続したファイルである場合には、Ｆｉｌｅ＃１の最後のパケットシーケンス番号とＦｉｌｅ＃２の先頭のパケットシーケンス番号とは連続した番号が付与されている。
【０５７６】
また、ファイルの分割方法を規定することにより、ファイルの分割データ数を特定できるように規定してもよい。例えば、分割データ数がＮの場合、１〜（Ｎ−１）番目の分割データのそれぞれのサイズはＬとし、Ｎ番目の分割データのサイズは端数（ｉｔｅｍ＿ｓｉｚｅ−Ｌ＊（Ｎ−１））と規定することにより、アセット管理テーブルに示されるｉｔｅｍ＿ｓｉｚｅから分割データ数を逆算できる。この場合、（ｉｔｅｍ＿ｓｉｚｅ  ／  Ｌ）を切り上げた整数値が分割データ数となる。なお、ファイルの分割方法は、これに限るものではない。
【０５７７】
また、分割データ数を直接アセット管理テーブルに格納してもよい。
【０５７８】
受信装置では、上記の方法を用いることにより、制御情報を受信し、制御情報に基づいて分割データ数を算出する。また、制御情報に基づいてファイルの分割データ番号に対応するパケットシーケンス番号を算出できる。なお、制御情報の受信のタイミングより、分割データのパケットの受信のタイミングが早い場合は、制御情報を受信したタイミングで分割データ番号や分割データ数を算出してもよい。
【０５７９】
なお、上記方法を用いて分割データ番号、或いは分割データ数をシグナリングする場合、フラグメントカウンタに基づいて分割データ番号や分割データ数を特定することはなく、フラグメントカウンタは不要なデータとなる。そこで、非同期メディアの伝送において、上記方法等を用いて分割データ番号、および、分割データ数を特定できる情報がシグナリングされている場合には、フラグメントカウンタは運用しない、或いは、ヘッダ圧縮してもよい。これにより、送信装置や受信装置の処理量を削減することができ、伝送効率を向上させることもできる。つまり、非同期メディアを送信する場合には、フラグメントカウンタをｒｅｓｅｒｖｅｄ（無効化）としてもよい。具体的には、フラグメントカウンタの値を例えば「０」の固定値としてもよい。また、非同期メディアを受信する場合には、フラグメントカウンタを無視してもよい。
【０５８０】
映像や音声などの同期メディアを格納する場合においては、送出装置におけるＭＭＴＰパケットの送信順と受信装置におけるＭＭＴＰパケットの到着順が一致しており、かつ、パケットが再送されない。このような場合において、パケットロスを検出して再構成する必要がない場合には、フラグメントカウンタを運用しないとしてもよい。言い換えると、この場合では、フラグメントカウンタをｒｅｓｅｒｖｅｄ（無効化）としてもよい。
【０５８１】
また、フラグメントカウンタを用いなくても、ランダムアクセスポイントの検出、アクセスユニット先頭の検出、ＮＡＬユニット先頭の検出などをすることが可能であり、復号処理や、パケットロスの検出、パケットロスからの復帰の処理をすることができる。
【０５８２】
また、ライブ放送などのリアルタイムなコンテンツの伝送では、より低遅延な伝送が求められ、符号化が完了したデータから順次パケット化して送出することが求められる。しかし、リアルタイムなコンテンツの伝送において、従来のフラグメントカウンタでは、先頭の分割データの送出時に分割データ数は決定できないため、先頭の分割データの送出は、データユニットの符号化がすべて完了し、分割データ数が決定した後となり、遅延が発生する。このような場合であっても、上記の方法を用いて、フラグメントカウンタを運用しないことにより、この遅延を削減できる。
【０５８３】
図５７は、受信装置における分割データ番号を特定する動作フローである。
【０５８４】
受信装置は、ファイルの情報が記載された制御情報を取得する（Ｓ１２０１）。受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されているかどうかを判定し（Ｓ１２０２）、制御情報にファイル先頭のパケットシーケンス番号が示されている場合には（Ｓ１２０２でＹｅｓ）、ファイルの分割データの分割データ番号に対応するパケットシーケンス番号を算出する（Ｓ１２０３）。そして、受信装置は、分割データが格納されたＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるパケットシーケンス番号からファイルの分割データ番号を特定する（Ｓ１２０４）。一方、受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されていない場合には（Ｓ１２０２でＮｏ）、ファイル最後の分割データが含まれるＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ番号を特定する（Ｓ１２０５）。
【０５８５】
図５８は、受信装置における分割データ数を特定する動作フローである。
【０５８６】
受信装置は、ファイルの情報が記載された制御情報を取得する（Ｓ１３０１）。受信装置は、制御情報にファイルの分割データ数を算出可能な情報が含まれているかどうかを判定し（Ｓ１３０２）、分割データ数を算出可能な情報が含まれていると判定した場合には、（Ｓ１３０２でＹｅｓ）、制御情報に含まれる情報に基づいて分割データ数を算出する（Ｓ１３０３）。一方、受信装置は、分割データ数を算出不可能であると判定した場合には（Ｓ１３０２でＮｏ）、ファイル最後の分割データが含まれるＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ数を特定する（Ｓ１３０４）。
【０５８７】
図５９は、送信装置においてフラグメントカウンタを運用するかどうかを決定するための動作フローである。
【０５８８】
まず、送信装置は、伝送するメディア（以下、「メディアデータ」とも言う。）が同期メディアか、非同期メディアかを判定する（Ｓ１４０１）。
【０５８９】
ステップＳ１４０１での判定の結果が同期メディアである場合（Ｓ１４０２で同期メディア）、送信装置は、同期メディアを伝送する環境において送受信のＭＭＴＰパケット順が一致し、かつパケットロス時にパケット再構成が不要かどうかを判定する（Ｓ１４０３）。送信装置は、不要であると判定した場合（Ｓ１４０３でＹｅｓ）、フラグメントカウンタを運用しない（Ｓ１４０４）。一方、送信装置は、不要でないと判定した場合（Ｓ１４０３でＮｏ）、フラグメントカウンタを運用する（Ｓ１４０５）。
【０５９０】
ステップＳ１４０１での判定の結果が非同期メディアである場合（Ｓ１４０２で非同期メディア）、送信装置は、上述で説明した方法を用いて分割データ番号や分割データ数がシグナリングされるかどうかに基づいて、フラグメントカウンタを運用するか否かを決定する。具体的には、送信装置は、分割データ番号や分割データ数がシグナリングされる場合（Ｓ１４０６でＹｅｓ）、フラグメントカウンタを運用しない（Ｓ１４０４）。一方、送信装置は、分割データ番号や分割データ数がシグナリングされない場合（Ｓ１４０６でＮｏ）、フラグメントカウンタを運用する（Ｓ１４０５）。
【０５９１】
なお、送信装置は、フラグメントカウンタを運用しない場合、フラグメントカウンタの値をｒｅｓｅｒｖｅｄとしてもよいし、ヘッダ圧縮をしてもよい。
【０５９２】
なお、送信装置は、フラグメントカウンタを運用するかどうかに基づいて、上述した分割データ番号や分割データ数をシグナリングするかどうかを決定してもよい。
【０５９３】
なお、送信装置は、同期メディアがフラグメントカウンタを運用しない場合には、非同期メディアにおいて上述した方法を用いて分割データ番号や分割データ数をシグナリングしてもよい。逆に、非同期メディアがフラグメントカウンタを運用するかどうかに基づいて、同期メディアの運用を決定してもよい。この場合、同期メディアと非同期メディアとにおいて、フラグメントを運用するかどうかを同じ運用とすることができる。
【０５９４】
次に、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明する。図６０は、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明するための図である。
【０５９５】
図５４を用いて説明したように、分割データ数が２５６以下であり、分割データ数があらかじめ２５６以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。
【０５９６】
ファイルの分割データ数を２５６以下に制限する場合、１つのパケットで伝送可能なデータサイズをｘ［ｂｙｔｅｓ］とした場合、伝送可能なファイルの最大サイズはｘ＊２５６［ｂｙｔｅｓ］に制限される。例えば、放送ではｘ＝４ｋ［ｂｙｔｅｓ］が想定されており、この場合、伝送可能なファイルの最大サイズは４ｋ＊２５６＝１Ｍ［ｂｙｔｅｓ］に制限される。
【０５９７】
ファイルサイズが、伝送可能なファイルの最大サイズを超える場合、分割ファイルのサイズがｘ＊２５６［ｂｙｔｅｓ］以下となるように予めファイルを分割する。ファイルが分割することにより得られた複数の分割ファイルのそれぞれは、一つのファイル（ｉｔｅｍ）として扱われ、さらに２５６以内に分割され、さらに分割されることにより得られた分割データがそれぞれＭＭＴＰパケットに格納されて伝送される。
【０５９８】
なお、アイテムが分割ファイルであることを示す情報や、分割ファイル数、分割ファイルのシーケンス番号を制御情報に格納し、受信装置に送信してもよい。また、これらの情報をアセット管理テーブルに格納してもよいし、既存のフィールドｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅの一部を用いて示してもよい。
【０５９９】
受信装置は、アイテムが１つのファイルを分割することにより得られた複数の分割ファイルのうちの１つの分割ファイルである場合には、他の分割ファイルを特定し、元のファイルを再構成することができる。また、受信装置では、制御情報における分割ファイルの分割ファイル数、分割ファイルのインデックス、および、フラグメントカウンタを用いることにより、分割データ数や、分割データ番号を一意に特定することができる。また、パケットシーケンス番号などを用いることなく分割データ数や分割データ番号を一意に特定できる。
【０６００】
ここで、１つのファイルを分割することにより得られた複数の分割ファイルそれぞれのｉｔｅｍ＿ｉｄは、互いに同じであることが望ましい。なお、別のｉｔｅｍ＿ｉｄを付与する場合は、他の制御情報などからファイルを一意に参照するために、先頭の分割ファイルのｉｔｅｍ＿ｉｄを示すとしてもよい。
【０６０１】
また、複数の分割ファイルは、必ず同じＭＰＵに属するとしてもよい。ＭＰＵに複数のファイルを格納する場合には、異なる種類のファイルは格納せず、必ず１つのファイルを分割したファイルが格納されているとしてもよい。受信装置はｉｔｅｍ毎のバージョン情報を確認せずとも、ＭＰＵ毎のバージョン情報を確認することで、ファイルの更新を検知できる。
【０６０２】
図６１は、フラグメントカウンタを活用する場合の送信装置の動作フローである。
【０６０３】
まず、送信装置は、伝送するファイルのサイズを確認する（Ｓ１５０１）。次に送信装置は、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］（ｘは、１つのパケットで伝送できるデータサイズ。例えば、ＭＴＵサイズ。）を超えるか否かを判定し（Ｓ１５０２）、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］を超える場合には（Ｓ１５０２でＹｅｓ）、分割ファイルのサイズがｘ＊２５６［ｂｙｔｅｓ］未満となるようにファイルを分割する（Ｓ１５０３）。そして、分割ファイルをアイテムとして伝送し、分割ファイルに関する情報（例えば、分割ファイルであること、分割ファイルにおけるシーケンス番号など）を制御情報に格納して伝送する（Ｓ１５０４）。一方、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］未満である場合には（Ｓ１５０２でＮｏ）、通常通りファイルをアイテムとして伝送する（Ｓ１５０５）。
【０６０４】
図６２は、フラグメントカウンタを活用する場合の受信装置の動作フローである。
【０６０５】
まず、受信装置は、アセット管理テーブルなどのファイルの伝送に関する制御情報を取得、解析する（Ｓ１６０１）。次に、受信装置は、所望のアイテムが分割ファイルであるかどうかを判定する（Ｓ１６０２）。受信装置は、所望のファイルが分割ファイルであると判定した場合には（Ｓ１６０２でＹｅｓ）、分割ファイルや分割ファイルのインデックスなど、ファイルを再構成するための情報を制御情報から取得する（Ｓ１６０３）。そして、受信装置は、分割ファイルを構成するアイテムを取得し、元のファイルを再構成する（Ｓ１６０４）。一方、受信装置は、所望のファイルが分割ファイルでないと判定した場合（Ｓ１６０２でＮｏ）、通常通りファイルを取得する（Ｓ１６０５）。
【０６０６】
要するに、送信装置は、ファイル先頭の分割データのパケットシーケンス番号をシグナリングする。また、送信装置は、分割データ数を特定できる情報をシグナリングする。或いは、送信装置は、分割データ数を特定できる分割ルールを規定する。また、送信装置は、フラグメントカウンタを運用せずに、ｒｅｓｅｒｖｅｄ或いはヘッダ圧縮する。
【０６０７】
受信装置は、ファイル先頭のデータのパケットシーケンス番号がシグナリングされている場合には、ファイル先頭の分割データのパケットシーケンス番号と、ＭＭＴＰパケットのパケットシーケンス番号から、分割データ番号や分割データ数を特定する。
【０６０８】
別の観点では、送信装置は、ファイルを分割し、分割ファイル毎にデータを分割して送信する。分割ファイルを紐づける情報（シーケンス番号、分割数など）をシグナリングする。
【０６０９】
受信装置は、フラグメントカウンタ、及び分割ファイルのシーケンス番号により、分割データ番号や分割データ数を特定する。
【０６１０】
これにより、分割データ番号や分割データを一意に特定できる。また、途中の分割データを受信した時点で当該分割データの分割データ番号を特定できるため、待機時間を削減し、メモリも削減できる。
【０６１１】
また、フラグメントカウンタを運用しないことにより、送受信装置の構成は処理量を削減することができる、また、伝送効率を向上させることができる。
【０６１２】
図６３は、同一番組を複数のＩＰデータフローで送信する場合のサービス構成を示す図である。ここでは、サービスＩＤ＝２の番組の一部（映像・音声）のデータがＭＭＴ方式を用いたＩＰデータフローで送信され、同じサービスＩＤであり、当該一部のデータとは異なるデータが高度ＢＳデータ伝送方式を用いたＩＰデータフロー（この例ではファイル伝送プロトコルも異なるが同じプロトコルであってもよい。）で送信される例を示している。
【０６１３】
送信装置は、受信装置において、複数のＩＰデータフローから構成されるデータが、復号時刻までに揃うことを保証できるように、ＩＰデータの多重化を行う。
【０６１４】
受信装置は、複数のＩＰデータフローから構成されるデータを用いて、復号時刻に基づいて処理することにより、保証された受信機動作を実現することができる。
【０６１５】
［補足：送信装置及び受信装置］
以上のように、フラグメントカウンタを運用せずにデータの送信を行う送信装置は、図６４のように構成することも可能である。また、フラグメントカウンタを運用せずにデータの受信を行う受信装置は、図６５のように構成することも可能である。図６４は、送信装置の具体的構成の例を示す図である。図６５は、受信装置の具体的構成の例を示す図である。
【０６１６】
送信装置５００は、分割部５０１と、構成部５０２と、送信部５０３とを備える。分割部５０１、構成部５０２、及び送信部５０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０６１７】
受信装置６００は、受信部６０１と、判定部６０２と、構成部６０３とを備える。受信部６０１、判定部６０２、及び構成部６０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０６１８】
送信装置５００及び受信装置６００の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
【０６１９】
まず、送信方法について、図６６を用いて説明する。図６６は、送信装置による動作フロー（送信方法）である。
【０６２０】
まず、送信装置５００の分割部５０１は、データを複数の分割データに分割する（Ｓ１７０１）。
【０６２１】
次に、送信装置５００の構成部５０２は、複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、複数のパケットを構成する（Ｓ１７０２）。
【０６２２】
そして、送信装置５００の送信部５０３は、構成された前記複数のパケットを送信する（Ｓ１７０３）。送信部５０３は、分割データ情報、および、無効化されたフラグメントカウンタの値を、送信する。なお、分割データ情報は、分割データ番号と、分割データ数とを特定するための情報である。また、分割データ番号は、当該分割データが複数の分割データのうちの何番目の分割データであるかを示す番号である。分割データ数は、複数の分割データの数である。
【０６２３】
これにより、送信装置５００の処理量を削減することができる。
【０６２４】
次に、受信方法について、図６７を用いて説明する。図６７は、受信装置による動作フロー（受信方法）である。
【０６２５】
まず、受信装置６００の受信部６０１は、複数のパケットを受信する（Ｓ１８０１）。
【０６２６】
次に、受信装置６００の判定部６０２は、受信した複数のパケットから、分割データ情報が、当取得されたか否かを判定する（Ｓ１８０２）。
【０６２７】
そして、受信装置６００の構成部６０３は、判定部６０２により、分割データ情報を取得したと判定された場合（Ｓ１８０２でＹｅｓ）、当該ヘッダ情報に含まれるフラグメントカウンタの値を使用せずに、受信した複数のパケットからデータを構成する（Ｓ１８０３）。
【０６２８】
一方で、構成部６０３は、判定部６０２により、分割データ情報を取得していないと判定された場合（Ｓ１８０２でＮｏ）、当該ヘッダ情報に含まれるフラグメントカウンタの値を用いて、受信した複数のパケットからデータを構成してもよい（Ｓ１８０４）。
【０６２９】
これにより、受信装置６００の処理量を削減することができる。
【０６３０】
（実施の形態５）
［概要］
実施の形態５では、ＮＡＬサイズフォーマットでＮＡＬユニットを多重化レイヤに格納した場合の伝送パケット（ＴＬＶパケット）の送信方法について説明する。
【０６３１】
実施の形態１で説明したように、Ｈ．２６４やＨ．２６５のＮＡＬユニットを多重化レイヤに格納する際には、次の２種類の形式がある。１つは、ＮＡＬユニットヘッダの直前に特定のビット列からなるスタートコードを付加するバイトストリームフォーマットと呼ばれる形式である。もう１つは、ＮＡＬユニットのサイズを示すフィールドを付加するＮＡＬサイズフォーマットと呼ばれる形式である。バイトストリームフォーマットは、ＭＰＥＧ−２システムやＲＴＰなどにおいて用いられ、ＮＡＬサイズフォーマットはＭＰ４、あるいは、ＭＰ４を使用するＤＡＳＨやＭＭＴなどにおいて用いられる。
【０６３２】
バイトストリームフォーマットにおいて、スタートコードは３バイトで構成され、さらに任意のバイト（値は０であるバイト）を付加することもできる。
【０６３３】
一方で、一般的なＭＰ４におけるＮＡＬサイズフォーマットでは、サイズ情報は、１バイト、２バイト、および４バイトのいずれかで示される。このサイズ情報は、ＨＥＶＣサンプルエントリにおけるｌｅｎｇｔｈＳｉｚｅＭｉｎｕｓＯｎｅフィールドで示される。当該フィールドの値が「０」の場合は１バイト、「１」の場合は２バイト、「３」の場合は４バイトであることを示す。
【０６３４】
ここで、２０１４年７月に規格化された、ＡＲＩＢ  ＳＴＤ−Ｂ６０「デジタル放送におけるＭＭＴによるメディアトランスポート方式」では、ＮＡＬユニットを多重化レイヤに格納する際、ＨＥＶＣエンコーダの出力がバイトストリームである場合、バイトスタートコードを除去し、３２ビット（符号なし整数）で示したバイト単位のＮＡＬユニットのサイズを長さ情報としてＮＡＬユニットの直前に付加する。なお、ＨＥＶＣサンプルエントリを含むＭＰＵメタデータを伝送せず、サイズ情報は３２ビット（４バイト）固定である。
【０６３５】
また、ＡＲＩＢ  ＳＴＤ−Ｂ６０「デジタル放送におけるＭＭＴによるメディアトランスポート方式」では、送信装置が受信装置におけるバッファ動作を保証するために送信の際に考慮する受信バッファモデルにおいては、映像信号の復号前バッファは、ＣＰＢであると規定されている。
【０６３６】
しかし、次のような課題がある。ＭＰＥＧ−２システムにおけるＣＰＢや、ＨＥＶＣにおけるＨＲＤでは、映像信号がバイトストリームフォーマットであることを前提に規定されている。このため、例えば、３バイトのスタートコードが付いたバイトストリームフォーマットであることを前提に伝送パケットのレート制御を行った場合、４バイトのサイズ領域が付加されたＮＡＬサイズフォーマットの伝送パケットを受信した受信装置は、ＡＲＩＢ  ＳＴＤ−Ｂ６０における受信バッファモデルを満たすことができない可能性がある。また、ＡＲＩＢ  ＳＴＤ−Ｂ６０における受信バッファモデルには、具体的なバッファサイズ、および、引き抜きレートが示されていないため、受信装置におけるバッファ動作を保証することは難しい。
【０６３７】
したがって、上記の課題を解決するために、受信機におけるバッファ動作を保証するための受信バッファモデルを下記のように規定する。
【０６３８】
図６８は、ＡＲＩＢ  ＳＴＤ−Ｂ６０に規定されている受信バッファモデルに基づいて、特に放送伝送路のみを用いた場合の受信バッファモデルを示す。
【０６３９】
受信バッファモデルは、ＴＬＶパケットバッファ（第１のバッファ）と、ＩＰパケットバッファ（第２のバッファ）と、ＭＭＴＰバッファ（第３のバッファ）と、復号前バッファ（第４のバッファ）とを備える。なお、放送伝送路では、デジッタバッファやＦＥＣのためのバッファは必要ないため、省略している。
【０６４０】
ＴＬＶパケットバッファは、ＴＬＶパケット（伝送パケット）を放送伝送路から受信し、受信したＴＬＶパケットに格納されている可変長のパケットヘッダ（ＩＰパケットヘッダ、ＩＰパケット圧縮時のフルヘッダ、ＩＰパケット圧縮時の圧縮ヘッダ）、および可変長のペイロードで構成されるＩＰパケットを、ヘッダ伸張された固定長のＩＰパケットヘッダを有するＩＰパケット（第１のパケット）に変換し、変換することにより得られたＩＰパケットを一定のビットレートで出力する。
【０６４１】
ＩＰパケットバッファは、ＩＰパケットをパケットヘッダおよび可変長のペイロードを有するＭＭＴＰパケット（第２のパケット）に変換し、変換することにより得られたＭＭＴＰパケットを一定のビットレートで出力する。なお、ＩＰパケットバッファは、ＭＭＴＰバッファにマージされていても良い。
【０６４２】
ＭＭＴＰバッファは、出力されたＭＭＴＰパケットをＮＡＬユニットに変換し、変換することにより得られたＮＡＬユニットを一定のビットレートで出力する。
【０６４３】
復号前バッファは、出力されたＮＡＬユニットを順次蓄積し、蓄積した複数のＮＡＬユニットからアクセスユニットを生成し、生成したアクセスユニットを当該アクセスユニットに対応した復号時刻のタイミングでデコーダに出力する。
【０６４４】
図６８に示す受信バッファモデルでは、前段のＴＬＶパケットバッファおよびＩＰパケットバッファ以外のバッファであるＭＭＴＰバッファおよび復号前バッファは、ＭＰＥＧ−２  ＴＳにおける受信バッファモデルを踏襲することが特徴的である。
【０６４５】
例えば、映像におけるＭＭＴＰバッファ（ＭＭＴＰ  Ｂ１）は、ＭＰＥＧ−２  ＴＳにおけるトランスポートバッファ（ＴＢ）、及び、多重化バッファ（ＭＢ）に相当するバッファで構成される。また、音声におけるＭＭＴＰバッファ（ＭＭＴＰ  Ｂｎ）は、ＭＰＥＧ−２  ＴＳにおけるトランスポートバッファ（ＴＢ）に相当するバッファで構成される。
【０６４６】
トランスポートバッファのバッファサイズは、ＭＰＥＧ−２  ＴＳ同様であり固定値とする。例えば、ＭＴＵサイズのｎ倍（ｎは、小数であっても整数であってもよく、１以上とする。）とする。
【０６４７】
また、ＭＭＴＰパケットヘッダのオーバーヘッド率がＰＥＳパケットヘッダのオーバーヘッド率よりも小さくなるように、ＭＭＴＰパケットサイズを規定する。これにより、トランスポートバッファからの引き抜きレートは、ＭＰＥＧ−２  ＴＳにおけるトランスポートバッファの引き抜きレートＲＸ１、ＲＸｎ、ＲＸｓをそのまま適用することができる。
【０６４８】
また、多重化バッファのサイズ、および、引き抜きレートは、それぞれ、ＭＰＥＧ−２
ＴＳにおけるＭＢサイズ、および、ＲＢＸ１とする。
【０６４９】
以上の受信バッファモデルに加え、課題を解決するために、下記の制約を設ける。
【０６５０】
ＨＥＶＣのＨＲＤ規定は、バイトストリーム形式が前提であり、ＭＭＴはＮＡＬユニットの先頭に４バイトのサイズ領域を付加するＮＡＬサイズ形式である。したがって、符号化時にはＮＡＬサイズ形式において、ＨＲＤを満たすようにレート制御を行う。
【０６５１】
つまり、送信装置では、上記の受信バッファモデルおよび制約に基づいて、伝送パケットのレート制御を行う。
【０６５２】
受信装置では、上記の信号を用いて受信処理をすることにより、アンダーフローやオーバーフローすることなる復号動作をすることができる。
【０６５３】
なお、ＮＡＬユニットの先頭のサイズ領域は４バイトでなくても、ＮＡＬユニットの先頭のサイズ領域を考慮して、ＨＲＤを満たすようにレート制御を行う。
【０６５４】
なお、ＴＬＶパケットバッファの引き抜きレート（ＴＬＶパケットバッファがＩＰパケットを出力する際のビットレート）は、ＩＰヘッダ伸張後の伝送レートを考慮して設定する。
【０６５５】
つまり、データサイズが可変長であるＴＬＶパケットを入力し、ＴＬＶヘッダの除去およびＩＰヘッダの伸張（復元）を実施した後、出力されるＩＰパケットの伝送レートを考慮する。言い換えれば、入力される伝送レートに対してヘッダの増減量を考慮する。
【０６５６】
具体的には、データサイズが可変長であること、ＩＰヘッダ圧縮されるパケットとＩＰヘッダ圧縮されていないパケットとが混在すること、ＩＰｖ４，ＩＰｖ６などのパケット種別によりＩＰヘッダのサイズが異なることから、出力されるＩＰパケットの伝送レートは一意ではない。このため、可変長のデータサイズの平均パケット長を定め、ＴＬＶパケットから出力されるＩＰパケットの伝送レートを定める。
【０６５７】
ここでは、ＩＰヘッダ伸張後の最大伝送速度を規定するために、ＩＰヘッダは常に圧縮されている場合を想定して伝送レートを定める。
【０６５８】
また、ＩＰｖ４、ＩＰｖ６のパケット種別が混在する場合、或いは、パケット種別を区別することなく規定する場合は、ヘッダサイズが大きく、ヘッダ伸張後の増加率の大きいＩＰｖ６パケットを想定して伝送レートを定める。
【０６５９】
例えば、ＴＬＶパケットバッファに入力されるＴＬＶパケットの平均パケット長がＳであり、ＴＬＶパケットに格納されるＩＰパケットはすべてＩＰｖ６パケットであり、ヘッダ圧縮されているとした場合の、ＴＬＶヘッダの除去及びＩＰヘッダの伸張後の最大出力伝送レートは、
入力レート×｛Ｓ／（Ｓ＋ＩＰｖ６ヘッダ圧縮量）｝
となる。
【０６６０】
より具体的には、ＴＬＶパケットの平均パケット長Ｓを、
Ｓ＝０．７５×１５００（１５００は最大ＭＴＵサイズを想定）
を基準として設定し、
ＩＰｖ６ヘッダ圧縮量＝ＴＬＶヘッダ長−ＩＰｖ６ヘッダ長−ＵＤＰヘッダ長
＝３−４０−８
とした場合、ＴＬＶヘッダの除去及びＩＰヘッダの伸張後の最大出力伝送レートは、
入力レート×１．０４１７≒入力レート×１．０５
となる。
【０６６１】
図６９は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す図である。
【０６６２】
ＭＭＴ方式では、データユニットをアグリゲーションする際、図６９に示すように、データユニットの前に、データユニット長、及び、データユニットヘッダが付加される。
【０６６３】
しかし、例えば、ＮＡＬサイズフォーマットの映像信号を一つのデータユニットとして格納する場合、図７０に示すように、一つのデータユニットに対して、サイズを示すフィールドが２つあり、情報として重複している。図７０は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例であって、ＮＡＬサイズフォーマットの映像信号を一つのデータユニットとした場合の例を示す図である。具体的には、ＮＡＬサイズフォーマットにおける先頭のサイズ領域（以降の説明では、「ｓｉｚｅ領域」と呼ぶ。）と、ＭＭＴＰペイロードヘッダにおけるデータユニットヘッダの前に位置するデータユニット長フィールドとのいずれもサイズを示すフィールドであり、情報として重複している。例えば、ＮＡＬユニットの長さがＬバイトである場合、ｓｉｚｅ領域にはＬバイトが示されており、データユニット長フィールドには、Ｌバイト＋「ｓｉｚｅ領域の長さ」（ｂｙｔｅ）が示される。ｓｉｚｅ領域と、データユニット長フィールドとで示される値は完全に一致はしていないが、一方の値から他方の値を容易に算出できるため、重複していると言える。
【０６６４】
このように、データのサイズ情報を内部に含むデータをデータユニットとして格納し、かつ、複数の当該データユニットをアグリゲーションして一つのペイロードに格納する場合、サイズ情報が重複するため、オーバーヘッドが大きく、伝送効率が悪いと言う課題がある。
【０６６５】
そこで、送出装置では、データのサイズ情報を内部に含むデータをデータユニットとして格納し、かつ、複数の当該データユニットをアグリゲーションして一つのペイロードに格納する場合、図７１や図７２に示すように格納することが考えられる。
【０６６６】
図７１に示すように、ｓｉｚｅ領域を含むＮＡＬユニットをデータユニットとして格納し、ＭＭＴＰペイロードヘッダに従来含まれるデータユニット長は示さないことが考えられる。図７１は、データユニット長が示されないＭＭＴＰパケットのペイロードの構成を示す図である。
【０６６７】
また、図７２に示すように、データユニット長が示されているかどうかを示すフラグや、ｓｉｚｅ領域の長さを示す情報を新たにヘッダに格納してもよい。フラグやｓｉｚｅ領域の長さを示す情報を格納する場所は、データユニットヘッダなど、データユニット単位で示してもよいし、複数のデータユニットをアグリゲーションした単位で（パケット単位）で示してもよい。図７２は、パケット単位に付与されるｅｘｔｅｎｄ領域に示す例である。なお、上記の新規に示す情報の格納場所はこれに限るものではなく、ＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダ、制御情報であってもよい。
【０６６８】
受信側では、データユニット長が圧縮されているかどうかを示すフラグが、データユニット長が圧縮されていることを示している場合は、データユニット内部のｓｉｚｅ領域の長さ情報を取得し、ｓｉｚｅ領域の長さ情報に基づいて、ｓｉｚｅ領域を取得することにより、取得したｓｉｚｅ領域の長さ情報およびｓｉｚｅ領域を用いてデータユニット長を算出できる。
【０６６９】
以上の方法により、送出側でデータ量を削減することができ、伝送効率を向上できる。
【０６７０】
なお、データユニット長を削減するのではなく、ｓｉｚｅ領域を削減することによりオーバーヘッド削減してもよい。ｓｉｚｅ領域を削減する場合には、ｓｉｚｅ領域が削減されているかどうかを示す情報や、データユニット長フィールドの長さを示す情報を格納してもよい。
【０６７１】
なお、ＭＭＴＰペイロードヘッダにも、長さ情報が含まれる。
【０６７２】
ｓｉｚｅ領域を含むＮＡＬユニットをデータユニットとして格納する場合は、アグリゲーションする／しないにかかわらず、ＭＭＴＰペイロードヘッダにおけるペイロードサイズ領域を削減してもよい。
【０６７３】
また、ｓｉｚｅ領域を含まないデータをデータユニットとして格納する場合でも、アグリゲーションされており、データユニット長が示されている場合には、ＭＭＴＰペイロードヘッダにおけるペイロードサイズ領域を削減してもよい。
【０６７４】
ペイロードサイズ領域を削減する場合には、上記と同様に、削減したかどうかを示すフラグや、削減したサイズフィールドの長さ情報、或いは削減しなかったサイズフィールドの長さ情報を示してもよい。
【０６７５】
図７３は、受信装置の動作フローを示す。
【０６７６】
送出装置では、上述したように、ｓｉｚｅ領域を含むＮＡＬユニットをデータユニットとして格納し、ＭＭＴＰペイロードヘッダに含まれるデータユニット長はＭＭＴＰパケットにおいて示さないとする。
【０６７７】
以下では、データユニット長が示されているかどうかをフラグや、ｓｉｚｅ領域の長さ情報がＭＭＴＰパケットにおいて示されている場合を例に説明する。
【０６７８】
受信装置は、データユニットがサイズ領域を含み、データユニット長が削減されているかどうかを、送出側から送信される情報に基づいて判定する（Ｓ１９０１）。
【０６７９】
データユニット長が削減されていると判定した場合（Ｓ１９０２でＹｅｓ）、データユニット内部のサイズ領域の長さ情報を取得し、その後、データユニット内部のサイズ領域を解析し、データユニット長を算出することにより取得する（Ｓ１９０３）。
【０６８０】
一方、データユニット長が削減されていないと判定した場合（Ｓ１９０２でＮｏ）、通常どおり、データユニット長、および、データユニット内部のサイズ領域のいずれか一方からデータユニット長を算出する（Ｓ１９０４）。
【０６８１】
なお、データユニット長が削減されているかどうかを示すフラグや、ｓｉｚｅ領域の長さ情報は、予め受信装置が分かっている場合、送信しなくてもよい。この場合受信装置は予め定められた情報に基づいて図７３で示した処理を行う。
【０６８２】
［補足：送信装置及び受信装置］
以上のように、符号化時に受信バッファモデルの規定を満たすようにレート制御を行う送信装置は、図７４のように構成することも可能である。また、送信装置から送信された伝送パケットを受信し、復号する受信装置は、図７５のように構成することも可能である。図７４は、送信装置の具体的構成の例を示す図である。図７５は、受信装置の具体的構成の例を示す図である。
【０６８３】
送信装置７００は、生成部７０１と、送信部７０２とを備える。生成部７０１及び送信部７０２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０６８４】
受信装置８００は、受信部８０１と、第１のバッファ８０２と、第２のバッファ８０３と、第３のバッファ８０４と、第４のバッファ８０５と、復号部８０６とを備える。受信部８０１、第１のバッファ８０２、第２のバッファ８０３、第３のバッファ８０４、第４のバッファ８０５及び復号部（デコーダ）８０６のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０６８５】
送信装置７００及び受信装置８００の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
【０６８６】
まず、送信方法について、図７６を用いて説明する。図７６は、送信装置による動作フロー（送信方法）である。
【０６８７】
まず、送信装置７００の生成部７０１は、受信装置のバッファ動作を保証するために予め定められた受信バッファモデルによる規定を満たすようにレート制御を行うことで符号化ストリームを生成する（Ｓ２００１）。
【０６８８】
次に、送信装置７００の送信部７０２は、生成された符号化ストリームをパケット化し、パケット化することで得られた伝送パケットを送信する（Ｓ２００２）。
【０６８９】
なお、送信装置７００において用いられる受信バッファモデルは、受信装置８００の構成の第１〜第４のバッファ８０２〜８０５を備える構成であるため、説明を省略する。
【０６９０】
これにより、送信装置７００は、ＭＭＴのような方式を用いてデータ伝送する場合に、受信装置８００のバッファ動作を保証できる。
【０６９１】
次に、受信方法について、図７７を用いて説明する。図７７は、受信装置による動作フロー（受信方法）である。
【０６９２】
まず、受信装置８００の受信部８０１は、固定長のパケットヘッダおよび可変長のペイロードで構成された伝送パケットを受信する（Ｓ２１０１）。
【０６９３】
次に、受信装置８００の第１のバッファ８０２は、受信した伝送パケットに格納されている可変長のパケットヘッダおよび可変長のペイロードで構成されるパケットを、ヘッダ伸張された固定長のパケットヘッダを有する第１のパケットに変換し、変換することにより得られた前記第１のパケットを一定のビットレートで出力する（Ｓ２１０２）。
【０６９４】
次に、受信装置８００の第２のバッファ８０３は、変換することにより得られた第１のパケットをパケットヘッダおよび可変長のペイロードで構成される第２のパケットに変換し、変換することにより得られた第２のパケットを一定のビットレートで出力する（Ｓ２１０３）。
【０６９５】
次に、受信装置８００の第３のバッファ８０４は、出力された第２のパケットをＮＡＬユニットに変換し、変換することにより得られたＮＡＬユニットを一定のビットレートで出力する（Ｓ２１０４）。
【０６９６】
次に、受信装置８００の第４のバッファ８０５は、出力されたＮＡＬユニットを順次蓄積し、蓄積した複数のＮＡＬユニットからアクセスユニットを生成し、生成したアクセスユニットを当該アクセスユニットに対応した復号時刻のタイミングでデコーダに出力する（Ｓ２１０５）。
【０６９７】
そして、受信装置８００の復号部８０６は、第４のバッファにより出力されたアクセスユニットを復号する（Ｓ２１０６）。
【０６９８】
これにより、受信装置８００は、アンダーフローやオーバーフローすることなる復号動作を行うことができる。
【０６９９】
（実施の形態６）
［概要］
実施の形態６では、ＭＭＴ／ＴＬＶの伝送方式における基準クロックの基準となる時刻情報にうるう秒調整が行なわれる場合の送信方法及び受信方法について説明する。
【０７００】
図７８は、ＡＲＩＢ  ＳＴＤ−Ｂ６０に規定されるＭＭＴ／ＴＬＶ方式のプロトコルスタックを示す図である。
【０７０１】
ＭＭＴ方式では、パケットには、映像や音声などのデータを複数のＭＰＵ（Ｍｅｄｉａ
Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ）やＭＦＵ（Ｍｅｄｉａ  Ｆｒａｇｍｅｎｔ  Ｕｎｉｔ）などの所定のデータユニットごとに格納し、ＭＭＴＰパケットヘッダを付与することで所定のパケットとしてのＭＭＴＰパケットを生成する（ＭＭＴＰパケット化する）。また、ＭＭＴＰにおける制御メッセージなどの制御情報に対しても、ＭＭＴＰパケットヘッダを付与することで、所定のパケットとしてのＭＭＴＰパケットを生成する。ＭＭＴＰパケットヘッダには、３２ビットのショートフォーマットのＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ：ＩＥＴＦ  ＲＦＣ  ５９０５に規定）を格納するフィールドが設けられており、通信回線のＱｏＳ制御等に用いることができる。
【０７０２】
また、送信側（送信装置）の基準クロックをＲＦＣ  ５９０５に規定される６４ビットのロングフォーマットＮＴＰに同期させ、同期させた当該基準クロックを基に、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｔｉｍｅ  Ｓｔａｍｐ）や、ＤＴＳ（Ｄｅｃｏｄｅ  Ｔｉｍｅ  Ｓｔａｍｐ）などのタイムスタンプを同期メディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では送信側から受信した基準クロック情報を基に受信装置におけるシステムクロックを生成する。
【０７０３】
ＰＴＳやＤＴＳは、具体的には、ＭＭＴＰの制御情報であるＭＰＵタイムスタンプ記述子や、ＭＰＵ拡張タイムスタンプ記述子に格納されて、アセット毎にＭＰテーブルに格納され、制御メッセージとしてＭＭＴＰパケット化された後、伝送される。
【０７０４】
ＭＭＴＰパケット化されたデータは、ＵＤＰヘッダやＩＰヘッダが付与されＩＰパケットにカプセル化される。このとき、ＩＰヘッダやＵＤＰヘッダにおいて、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコル種別が同じもののパケットの集合をＩＰデータフローとする。なお、同じＩＰデータフローのＩＰパケットは、ヘッダが冗長であるため、一部のＩＰパケットではヘッダ圧縮される。
【０７０５】
また、基準クロック情報として、６４ビットのＮＴＰタイムスタンプは、ＮＴＰパケットに格納され、ＩＰパケットに格納される。このとき、ＮＴＰパケットを格納するＩＰパケットでは、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別は固定値であり、ＩＰパケットのヘッダは圧縮されない。
【０７０６】
図７９は、ＴＬＶパケットの構成を示す図である。
【０７０７】
ＴＬＶパケットには、図７９に示すように、ＩＰパケット、圧縮ＩＰパケット、ＡＭＴ（Ａｄｄｒｅｓｓ  Ｍａｐ  Ｔａｂｌｅ）やＮＩＴ（Ｎｅｔｗｏｒｋ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）などの伝送制御情報をデータとして含むことができ、これらのデータは、８ビットのデータタイプを用いて識別される。また、ＴＬＶパケットでは、１６ビットのフィールドを用いてデータ長（バイト単位）が示され、そのあとにデータの値を格納する。また、ＴＬＶパケットは、データタイプの前に１バイトのヘッダ情報を有し、当該ヘッダ情報は、合計４バイトのヘッダ領域に格納される。また、ＴＬＶパケットは、高度ＢＳ伝送方式における伝送スロットにマッピングされ、ＴＭＣＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  Ｍｕｌｔｉｐｌｅｘｉｎｇ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｎｔｒｏｌ）制御情報にマッピング情報が格納される。
【０７０８】
図８０は、受信装置のブロック図の一例を示す図である。
【０７０９】
受信装置では、まずチューナーで受信した放送信号に対し、復調手段において伝送路符号化データを復号、誤り訂正などを施し、ＴＬＶパケットを抽出する。そして、ＴＬＶ／ＩＰ  ＤＥＭＵＸ手段では、ＴＬＶのＤＥＭＵＸ処理やＩＰのＤＥＭＵＸ処理を行う。ＴＬＶのＤＥＭＵＸ処理は、ＴＬＶパケットのデータタイプに応じた処理を行う。例えば、ＴＬＶパケットが圧縮ＩＰパケットを有する場合は、当該圧縮ＩＰパケットの圧縮されたヘッダを復元する。ＩＰ  ＤＥＭＵＸでは、ＩＰパケットやＵＤＰパケットのヘッダ解析などの処理を行い、ＭＭＴＰパケット及びＮＴＰパケットを抽出する。
【０７１０】
ＮＴＰクロック生成手段では、抽出したＮＴＰパケットからＮＴＰクロックを再生する。ＭＭＴＰ  ＤＥＭＵＸでは、抽出したＭＭＴＰパケットヘッダに格納されているパケットＩＤを基に映像や音声などのコンポーネントや制御情報のフィルタリング処理を行う。制御情報取得手段からは、ＭＰテーブルの中に格納されるタイムスタンプ記述子を取得し、ＰＴＳ／ＤＴＳ算出手段においてアクセスユニット毎のＰＴＳ及びＤＴＳを算出する。なお、タイムスタンプ記述子は、ＭＰＵタイムスタンプ記述子及びＭＰＵ拡張タイムスタンプ記述子の両記述子を含む。
【０７１１】
アクセスユニット再生手段では、ＭＭＴＰパケットからフィルタリングされた映像や音声などを、提示する単位のデータに変換する。提示する単位のデータとは、具体的には、映像信号のＮＡＬユニットやアクセスユニット、音声フレーム、字幕の提示単位などである。復号提示手段では、ＮＴＰクロックの基準時刻情報をベースに、アクセスユニットのＰＴＳ／ＤＴＳが一致した時刻に、アクセスユニットを復号、提示する。
【０７１２】
なお、受信装置の構成は、これに限るものではない。
【０７１３】
次にタイムスタンプ記述子について説明する。
【０７１４】
図８１は、タイムスタンプ記述子について説明するための図である。
【０７１５】
ＰＴＳやＤＴＳは、ＭＭＴの制御情報である、ＭＰＵタイムスタンプ記述子やＭＰＵ拡張タイムスタンプ記述子に格納され、アセット毎にＭＰテーブルに格納され、制御メッセージとしてＭＭＴＰパケット化された後、伝送される。
【０７１６】
図８１の（ａ）はＡＲＩＢ  ＳＴＤ−Ｂ６０に規定されるＭＰＵタイムスタンプ記述子の構成を示す図である。ＭＰＵタイムスタンプ記述子には、複数のＭＰＵのそれぞれについて、当該ＭＰＵに含まれる複数のＡＵのうちの提示順で先頭（最初）のＡＵ（以下、「先頭ＡＵ」という。）のＰＴＳ（６４ｂｉｔのＮＴＰで示される絶対値）が格納される。つまり、ＭＰＵに付与された当該ＭＰＵの提示時刻情報は、ＭＭＴＰパケットの制御情報に格納されて送信される。
【０７１７】
図８１の（ｂ）は、ＭＰＵ拡張タイムスタンプ記述子の構成を示すである。ＭＰＵ拡張タイムスタンプ記述子には、複数のＭＰＵのそれぞれのＭＰＵ内に含まれるＡＵのＰＴＳ及びＤＴＳを算出するための情報が格納される。ＭＰＵ拡張タイムスタンプ記述子には、ＭＰＵタイムスタンプ記述子に格納されるＭＰＵの先頭ＡＵのＰＴＳからの相対情報を含んでおり、ＭＰＵ内に含まれるＡＵのＰＴＳ及びＤＴＳは、ＭＰＵタイムスタンプ記述子とＭＰＵ拡張タイムスタンプ記述子との両方に基づいて算出できる。つまり、ＭＰＵ内に含まれる先頭ＡＵ以外のＡＵのＰＴＳ及びＤＴＳは、ＭＰＵタイムスタンプ記述子に格納される当該先頭ＡＵのＰＴＳと、ＭＰＵ拡張タイムスタンプ記述子に格納されている相対情報とに基づいて算出できる。
【０７１８】
ＮＴＰは、協定世界時（Ｃｏｏｒｄｉｎａｔｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｉｍｅ（ＵＴＣ））に基づいた基準時刻情報である。ＵＴＣは、地球の自転速度に基づく天文時との差を調整するため、うるう秒の調整（以下、「うるう秒調整」という。）を実施する。うるう秒調整は、具体的には、日本時間の午前９時に実施され、１秒の挿入または削除を行う調整である。
【０７１９】
図８２は、うるう秒調整を説明するための図である。
【０７２０】
図８２の（ａ）は、日本時間における、うるう秒挿入の一例を示す図である。図８２の（ａ）に示すように、うるう秒挿入では、日本時間８：５９：５９の後、本来９：００：００になるタイミングで８：５９：５９となり、８：５９：５９台が２回繰り返される。
【０７２１】
図８２の（ｂ）は、日本時間における、うるう秒削除の一例を示す図である。図８２の（ｂ）に示すように、うるう秒削除では、日本時間８：５９：５８の後、本来８：５９：５９になるタイミングで９：００：００となり、８：５９：５９台の１秒間が削除される。
【０７２２】
ＮＴＰパケットには、６４ｂｉｔのタイムスタンプの他に、２ｂｉｔのｌｅａｐ＿ｉｎｄｉｃａｔｏｒが格納されている。ｌｅａｐ＿ｉｎｄｉｃａｔｏｒは、うるう秒調整が行なわれることを事前に通知するためのフラグであり、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝１の場合にうるう秒挿入を示し、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝２の場合にうるう秒削除を示す。事前通知は、うるう秒調整を実施する月の初めから通知する方法や、２４時間前に通知する方法、その他、任意の時間に通知を開始する方法がある。また、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒは、うるう秒調整が終わった時間（９：００：００）に０となる。例えば、２４時間前から事前通知する場合には、日本時間でうるう秒調整が行われる前日の９：００からうるう秒調整が行われる当日におけるうるう秒調整が行われる直前の時刻（つまり、うるう秒挿入の場合は１回目の８：５９：５９台の時刻であり、うるう秒削除の場合は８：５９：５８台の時刻）までの間にｌｅａｐ＿ｉｎｄｉｃａｔｏｒが「１」または「２」であることが示される。
【０７２３】
次に、うるう秒調整時の課題について説明する。
【０７２４】
図８３は、ＮＴＰ時刻、ＭＰＵタイムスタンプ及びＭＰＵ提示タイミングの関係を示す図である。なお、ＮＴＰ時刻は、ＮＴＰにより示される時刻である。また、ＭＰＵタイムスタンプは、ＭＰＵ内の先頭ＡＵのＰＴＳを示すタイムスタンプである。また、ＭＰＵ提示タイミングとは、受信装置がＭＰＵタイムスタンプに従ってＭＰＵを提示すべきタイミングである。具体的には、図８３の（ａ）〜（ｃ）は、それぞれ、うるう秒調整が発生しない場合、うるう秒が挿入される場合、うるう秒が削除される場合におけるＮＴＰ時刻、ＭＰＵタイムスタンプ及びＭＰＵ提示時刻の関係を示す図である。
【０７２５】
ここでは、送出側のＮＴＰ時刻（基準クロック）は、ＮＴＰサーバと同期しており、また、受信側のＮＴＰ時刻（システムクロック）は、送出側のＮＴＰ時刻と同期している場合を例に説明する。この場合、受信装置では、送出側から伝送されるＮＴＰパケットに格納されているタイムスタンプに基づいて再生する。また、この場合、送出側のＮＴＰ時刻及び受信側のＮＴＰ時刻共に、ＮＴＰサーバと同期しているため、うるう秒の調整時に±１秒の調整がなされる。また、図８３におけるＮＴＰ時刻は、送出側のＮＴＰ時刻及び受信側のＮＴＰ時刻で共通であるとする。なお、伝送遅延はないものとして説明する。
【０７２６】
図８３におけるＭＰＵタイムスタンプは、複数のＭＰＵのそれぞれに含まれる複数のＡＵのうちの提示順における先頭ＡＵのタイムスタンプを示しており、矢印の元で示されるＮＴＰ時刻に基づいて生成（設定）される。具体的には、ＭＰＵの提示時刻情報を生成するタイミングにおける基準時刻情報としてのＮＴＰ時刻に、予め定められた時間（図８３では、例えば、１．５秒）を加算することで、ＭＰＵの提示時刻情報を生成する。生成されたＭＰＵタイムスタンプは、ＭＰＵタイムスタンプ記述子に格納される。
【０７２７】
受信装置では、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプに基づくＭＰＵ提示時刻においてＭＰＵを提示する。
【０７２８】
なお、図８３では、１つのＭＰＵの再生時間は１秒であるとして説明するが、１つのＭＰＵの再生時間は、それ以外の再生時間であってもよく、例えば、０．５秒でもよいし、０．１秒でもよい。
【０７２９】
図８３の（ａ）の例では、受信装置は、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプに基づいてＭＰＵ＃１−＃５を順番に提示することができる。
【０７３０】
しかし、図８３の（ｂ）では、うるう秒挿入によりＭＰＵ＃２とＭＰＵ＃３との提示時刻が重複する。このため、受信装置は、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプに基づいてＭＰＵを提示してしまうと、同じ９：００：００台の時間帯に提示するＭＰＵが２つ存在することになり、２つのＭＰＵのどれを提示すべきかの判断ができない。また、受信装置は、ＭＰＵ＃１のタイムスタンプで示されるＭＰＵ提示時刻（８：５９：５９）が２回存在することになるため、２つのＭＰＵ提示時刻のうちどのＭＰＵ提示時刻で提示すべきかの判断ができない。
【０７３１】
また、図８３の（ｃ）では、受信装置は、うるう秒の削除により、ＭＰＵ＃３のＭＰＵタイムスタンプで示されるＭＰＵ提示時刻（８：５９：５９）がＮＴＰ時刻に存在しないため、ＭＰＵ＃３を提示することができない。
【０７３２】
受信装置は、タイムスタンプに基づかないＭＰＵの復号処理及び提示処理を行う場合には、上記のような課題を解決できる。しかし、タイムスタンプに基づく処理を行う受信装置は、うるう秒の発生時のみに、異なる処理（タイムスタンプに基づかない処理）を行うことは困難である。
【０７３３】
次に、送信側においてタイムスタンプを補正することでうるう秒調整時の課題を解決する方法について説明する。
【０７３４】
図８４は、送信側においてタイムスタンプを補正する補正方法について説明するための図である。具体的には、図８４の（ａ）は、うるう秒挿入の例を示し、図８４の（ｂ）は、うるう秒削除の例を示す図である。
【０７３５】
まず、うるう秒挿入の場合について説明する。
【０７３６】
図８４の（ａ）に示すように、うるう秒挿入時には、うるう秒挿入の直前までの時刻（つまり、ＮＴＰ時刻における１回目の８：５９：５９台まで）をＡ領域とし、うるう秒挿入以後の時刻（つまり、ＮＴＰ時刻における２回目の８：５９：５９以降）をＢ領域とする。なお、Ａ領域及びＢ領域は、時間的な領域であり、時間帯または期間である。図８４の（ａ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰの時刻に基づいて生成（設定）したタイムスタンプである。
【０７３７】
うるう秒挿入の場合に、送信側でのタイムスタンプの補正方法について具体的に説明する。
【０７３８】
送信側（送信装置）では、以下の処理を行う。
【０７３９】
１．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ａ）の矢印の元が示すタイミング）がＡ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が９：００：００以降を示す場合は、ＭＰＵタイムスタンプを１秒減ずる−１秒補正して、補正後のＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する。つまり、Ａ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを−１秒補正する。なお、ここでの「９：００：００」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）である。また、別途補正したことを示す情報である補正情報を受信装置に送信する。
【０７４０】
２．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ａ）の矢印の元が示すタイミング）がＢ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
【０７４１】
受信装置においては、ＭＰＵタイムスタンプと、当該ＭＰＵタイムスタンプが補正されたか否か（つまり、補正したことを示す情報が含まれるか否か）を示す補正情報に基づいて、ＭＰＵを提示する。
【０７４２】
受信装置は、ＭＰＵタイムスタンプが補正されていないと判定した場合（つまり、補正したことを示す情報が含まれていないと判定した場合）、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプが受信装置のＮＴＰ時刻（補正前、補正後両方含む）に一致した時刻にＭＰＵを提示する。つまり、ＭＰＵタイムスタンプが補正されるＭＰＵより前に送信されるＭＰＵのＭＰＵタイムスタンプ記述子に格納されたＭＰＵタイムスタンプの場合、当該ＭＰＵタイムスタンプが、うるう秒挿入前（つまり、１回目の８：５９：５９台以前）のＮＴＰ時刻に一致したタイミングに当該ＭＰＵを提示する。また、受信したＭＰＵのＭＰＵタイムスタンプ記述子に格納されるＭＰＵタイムスタンプが、補正されるＭＰＵタイムスタンプより後に送信されるタイムスタンプの場合、うるう秒挿入後（つまり、２回目の８：５９：５９台以降）のＮＴＰ時刻に一致したタイミングに当該ＭＰＵを提示する。
【０７４３】
また、受信装置は、受信したＭＰＵのＭＰＵタイムスタンプ記述子に格納されるＭＰＵタイムスタンプが補正されている場合、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプが、受信装置においてうるう秒挿入後（つまり、２回目の８：５９：５９台以降）のＮＴＰ時刻に基づいてＭＰＵを提示する。
【０７４４】
なお、ＭＰＵタイムスタンプ値を補正したことを示す情報は、制御メッセージや記述子、テーブル、ＭＰＵメタデータ、ＭＦメタデータ、ＭＭＴＰパケットヘッダなどに格納して伝送する。
【０７４５】
次に、うるう秒削除の場合について説明する。
【０７４６】
図８４の（ｂ）に示すように、うるう秒削除時には、うるう秒削除の直前までの時刻（つまり、ＮＴＰ時刻における９：００：００直前）をＣ領域とし、うるう秒削除以後の時刻（つまり、ＮＴＰ時刻における９：００：００以降）をＤ領域とする。なお、Ｃ領域及びＤ領域は、時間的な領域であり、時間帯または期間である。図８４の（ｂ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰ時刻に基づいて生成（設定）したタイムスタンプである。
【０７４７】
うるう秒削除の場合に、送信側でのタイムスタンプの補正方法について具体的に説明する。
【０７４８】
送信側（送信装置）では、以下の処理を行う。
【０７４９】
１．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ｂ）の矢印の元が示すタイミング）がＣ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプを１秒加える＋１秒補正して、補正後のＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する。つまり、Ｃ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。なお、ここでの「８：５９：５９」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）から−１秒減算することで得られた時刻である。また、別途補正したことを示す情報である補正情報を受信装置に送信する。なお、この場合、補正情報は、必ずしも送信しなくてもよい。
【０７５０】
２．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ｂ）の矢印の元が示すタイミング）がＤ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｄ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
【０７５１】
受信装置においては、ＭＰＵタイムスタンプに基づいて、ＭＰＵを提示する。なお、当該ＭＰＵタイムスタンプが補正されたか否かを示す補正情報があれば、ＭＰＵタイムスタンプと当該補正情報とに基づいてＭＰＵを提示してもよい。
【０７５２】
以上の処理により、ＮＴＰ時刻にうるう秒調整が行われた場合であっても、受信装置において、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプを用いて正常なＭＰＵの提示が可能となる。
【０７５３】
なお、ＭＰＵタイムスタンプの付与タイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかをシグナリングし、受信側に通知してもよい。つまり、当該ＭＰＵタイムスタンプが、Ａ領域に含まれるＮＴＰ時刻に基づいて生成されたか、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたか、または、Ｃ領域に含まれるＮＴＰ時刻に基づいて生成されたか、Ｄ領域に含まれるＮＴＰ時刻に基づいて生成されたかをシグナリングし、受信側に通知してもよい。言い換えると、ＭＰＵタイムスタンプ（提示時刻）がうるう秒調整前の基準時刻情報（ＮＴＰ時刻）に基づいて生成されたか否かを示す識別情報を送信してもよい。この識別情報は、ＮＴＰパケットに含まれるｌｅａｐ＿ｉｎｄｉｃａｔｏｒに基づいて付与されるため、日本時間でうるう秒調整が行われる前日の９：００からうるう秒調整が行われる当日におけるうるう秒調整が行われる直前の時刻（つまり、うるう秒挿入の場合は１回目の８：５９：５９台の時刻であり、うるう秒削除の場合は８：５９：５８台の時刻）までの間の時刻に基づいて設定されるＭＰＵタイムスタンプか否かを示す情報である。つまり、識別情報は、ＭＰＵタイムスタンプが、うるう秒調整が行われる直前の時刻よりも予め定められた期間（例えば２４時間）前の時刻から当該直前の時刻までにおけるＮＴＰ時刻に基づいて生成されたか否かを示す情報である。
【０７５４】
次に、受信装置においてタイムスタンプを補正することでうるう秒調整時の課題を解決する方法について説明する。
【０７５５】
図８５は、受信装置においてタイムスタンプを補正する補正方法について説明するための図である。具体的には、図８５の（ａ）は、うるう秒挿入の例を示し図８５の（ｂ）は、うるう秒削除の例を示す図である。
【０７５６】
まず、うるう秒挿入の場合について説明する。
【０７５７】
図８５の（ａ）に示すように、図８４の（ａ）と同様にうるう秒挿入時には、うるう秒挿入の直前までの時刻（つまり、ＮＴＰ時刻における１回目の８：５９：５９台まで）をＡ領域とし、うるう秒挿入以後の時刻（つまり、ＮＴＰ時刻における２回目の８：５９：５９以降）をＢ領域とする。なお、Ａ領域及びＢ領域は、時間的な領域であり、時間帯または期間である。図８５の（ａ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰの時刻に基づいて生成（設定）したタイムスタンプである。
【０７５８】
うるう秒挿入の場合に、受信装置でのタイムスタンプの補正方法について具体的に説明する。
【０７５９】
送信側（送信装置）では、以下の処理を行う。
【０７６０】
・生成したＭＰＵタイムスタンプを補正せずに、当該ＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納して受信装置に送信する。
【０７６１】
・ＭＰＵのタイムスタンプを付与したタイミングが、Ａ領域であるか、Ｂ領域であるかを示す情報を識別情報として受信装置に送信する。つまり、当該ＭＰＵタイムスタンプが、Ａ領域に含まれているＮＴＰ時刻に基づいて生成されたか、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたか、を示す識別情報を受信装置に送信する。
【０７６２】
受信装置では、以下の処理を行う。
【０７６３】
受信装置においては、ＭＰＵタイムスタンプと、ＭＰＵタイムスタンプを付与したタイミングがＡ領域であるか、Ｂ領域であるかを示す識別情報に基づいて、ＭＰＵタイムスタンプを補正する。
【０７６４】
具体的には、以下の処理を行う。
【０７６５】
１．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ａ）の矢印の元が示すタイミング）がＡ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が９：００：００以降を示す場合は、ＭＰＵタイムスタンプを１秒減ずる−１秒補正する。つまり、Ａ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを−１秒補正する。なお、ここでの「９：００：００」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）である。
【０７６６】
２．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ａ）の矢印の元が示すタイミング）がＢ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
【０７６７】
ＭＰＵタイムスタンプを補正しない場合、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプが受信装置のＮＴＰ時刻（補正前及び補正後含む）に一致した時刻にＭＰＵを提示する。
【０７６８】
つまり、補正するＭＰＵタイムスタンプより前に受信されるＭＰＵタイムスタンプの場合、うるう秒挿入前（つまり、１回目の８：５９：５９台以前）のＮＴＰ時刻に一致した時刻にＭＰＵを提示する。また、補正するＭＰＵタイムスタンプより後に受信されるＭＰＵタイムスタンプの場合、うるう秒挿入後（２回目の８：５９：５９台以降）のＮＴＰ時刻に一致した時刻にＭＰＵを提示する。
【０７６９】
ＭＰＵタイムスタンプを補正する場合、補正したＭＰＵタイムスタンプが、受信装置においてうるう秒挿入後（つまり、２回目の８：５９：５９台以降）のＮＴＰ時刻に基づいてＭＰＵを提示する。
【０７７０】
なお、送信側は、ＭＰＵタイムスタンプを付与したタイミングがＡ領域であるか、Ｂ領域であるかを示す識別情報は、制御メッセージや記述子、テーブル、ＭＰＵメタデータ、ＭＦメタデータ、ＭＭＴＰパケットヘッダなどに格納して伝送する。
【０７７１】
次に、うるう秒削除の場合について説明する。
【０７７２】
図８５の（ｂ）に示すように、うるう秒削除時には、図８４の（ａ）と同様に、うるう秒削除の直前までの時刻（つまり、ＮＴＰ時刻における９：００：００直前まで）をＣ領域とし、うるう秒削除以後の時刻（つまり、ＮＴＰ時刻における９：００：００：以降）をＤ領域とする。なお、Ｃ領域及びＤ領域は、時間的な領域であり、時間帯または期間である。図８５の（ｂ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰ時刻に基づいて生成（設定）したタイムスタンプである。
【０７７３】
うるう秒削除の場合に、受信装置でのタイムスタンプの補正方法について具体的に説明する。
【０７７４】
送信側（送信装置）では、以下の処理を行う。
【０７７５】
・生成したＭＰＵタイムスタンプを補正せずに、当該ＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納して受信装置に送信する。
【０７７６】
・ＭＰＵのタイムスタンプを付与したタイミングが、Ｃ領域であるか、Ｄ領域であるかを示す情報を識別情報として受信装置に送信する。つまり、当該ＭＰＵタイムスタンプが、Ｃ領域に含まれているＮＴＰ時刻に基づいて生成されたか、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたか、を示す識別情報を受信装置に送信する。
【０７７７】
受信装置では、以下の処理を行う。
【０７７８】
受信装置においては、ＭＰＵタイムスタンプと、ＭＰＵタイムスタンプを付与したタイミングがＣ領域であるか、Ｄ領域であるかを示す識別情報に基づいて、ＭＰＵタイムスタンプを補正する。
【０７７９】
具体的には、以下の処理を行う。
【０７８０】
１．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ｂ）の矢印の元が示すタイミング）がＣ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプ値を１秒加える＋１秒補正する。つまり、Ｃ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。なお、ここでの「８：５９：５９」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）から−１秒減算することで得られた時刻である。
【０７８１】
２．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ｂ）の矢印の元が示すタイミング）がＤ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｄ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
【０７８２】
受信装置においては、ＭＰＵタイムスタンプ、及び、補正したＭＰＵタイムスタンプに基づいて、ＭＰＵを提示する。
【０７８３】
以上の処理により、ＮＴＰ時刻にうるう秒調整が行われた場合であっても、受信装置において、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプを用いて正常なＭＰＵの提示が可能となる。
【０７８４】
なお、この場合であっても、図８４で説明した送信側においてＭＰＵタイムスタンプを補正する場合と同様に、ＭＰＵタイムスタンプの付与タイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかをシグナリングし、受信側に通知してもよい。通知の詳細については、同様であるので説明を省略する。
【０７８５】
なお、図８４及び図８５で説明した、ＭＰＵタイムスタンプを補正したか否かを示す情報や、ＭＰＵタイムスタンプを付与したタイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかを示す情報などの付加情報（識別情報）は、ＮＴＰパケットのｌｅａｐ＿ｉｎｄｉｃａｔｏｒがうるう秒の削除（ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝２）や挿入（ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝１）を示す場合に有効にしてもよい。予め定められた任意の時刻（例えば、うるう秒調整の３秒前）から有効となるとしてもよいし、動的に有効にしてもよい。
【０７８６】
また、付加情報の有効期間が終わるタイミングや付加情報のシグナリングを終了するタイミングも、ＮＴＰパケットのｌｅａｐ＿ｉｎｄｉｃａｔｏｒに合わせてもよいし、予め定められた任意の時刻（例えば、うるう秒調整の３秒前）から有効となるとしてもよいし、動的に有効にしてもよい。
【０７８７】
なお、ＭＭＴＰパケットに格納される３２ｂｉｔのタイムスタンプや、ＴＭＣＣに格納されるタイムスタンプ情報なども、ＮＴＰ時刻に基づいて生成され付与されるため、同様の課題が発生する。このため、３２ｂｉｔのタイムスタンプや、ＴＭＣＣに格納されるタイムスタンプ情報などの場合も図８４及び図８５と同様の方法を用いてタイムスタンプを補正し、受信装置においてタイムスタンプに基づいた処理を実施することができる。例えば、ＭＭＴＰパケットに格納される３２ｂｉｔのタイムスタンプに対する上記付加情報を格納する場合は、ＭＭＴＰパケットヘッダの拡張領域を用いて示してもよい。この場合、マルチヘッダータイプの拡張タイプに付加情報であることを示す。また、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒが立っている時間は、３２ｂｉｔや６４ｂｉｔのタイムスタンプのうち、一部のビットを用いて付加情報を示してもよい。
【０７８８】
なお、図８４の例では、補正したＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納するとしたが、補正前及び補正後のＭＰＵタイムスタンプ（つまり、補正していないＭＰＵタイムスタンプ及び補正したＭＰＵタイムスタンプ）を両方受信装置に送信してもよい。例えば、補正前のＭＰＵタイムスタンプ記述子と、補正後のＭＰＵタイムスタンプ記述子とを同一のＭＰＵタイムスタンプ記述子に格納してもよいし、２つのＭＰＵタイムスタンプ記述子にそれぞれ格納してもよい。この場合、２つのＭＰＵタイムスタンプ記述子の配置順や、ＭＰＵタイムスタンプ記述子内の記載順などにより、補正前のＭＰＵタイムスタンプであるか、補正後のＭＰＵタイムスタンプであるかを識別してもよい。また、ＭＰＵタイムスタンプ記述子には常に補正前のＭＰＵタイムスタンプを格納するとし、補正をする場合には、補正後のタイムスタンプをＭＰＵ拡張タイムスタンプ記述子に格納するとしてもよい。
【０７８９】
なお、本実施の形態では、ＮＴＰ時刻として日本時間での時刻（午前９時）を例に説明したが、日本時間での時刻に限らない。うるう秒調整は、ＵＴＣ時刻に基づくものであり、世界同時に補正される。日本時刻は、ＵＴＣ時刻を基準として９時間進んだ時刻であり、ＵＴＣ時刻に対する時刻（＋９）という値で表される。このように、場所に応じた時差により異なる時間に調整された時刻を採用してもよい。
【０７９０】
以上のように、タイムスタンプを付与したタイミングを示す情報に基づいて、送信側、或いは受信装置においてタイムスタンプを補正することにより、タイムスタンプを用いた正常な受信処理が可能となる。
【０７９１】
なお、うるう秒調整時刻より十分前から復号処理を継続する受信装置は、タイムスタンプを用いない復号処理及び提示処理が可能となる場合もあるが、うるう秒調整時刻直前で選局した受信装置は、タイムスタンプを決定できず、うるう秒調整が終了した後でなければ、提示できない場合がある。その場合であっても、本実施の形態における補正方法を用いることによりタイムスタンプを用いた受信処理が可能となり、うるう秒調整時刻の直前でも選局が可能となる。
【０７９２】
図８４で説明した、送信側（送信装置）においてＭＰＵタイムスタンプを補正する場合の、送信側（送信装置）の動作フローを図８６に、受信装置の動作フローを図８７に示す。
【０７９３】
まず、送信側（送信装置）の動作フローについて、図８６を用いて説明する。
【０７９４】
うるう秒の挿入や削除が行われる場合、ＭＰＵタイムスタンプの付与のタイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかを判定する（Ｓ２２０１）。なお、うるう秒の挿入や削除が行われない場合については、図示しない。
【０７９５】
ここで、Ａ領域〜Ｄ領域は、以下のように定義される。
【０７９６】
Ａ領域：うるう秒挿入の直前までの時刻（１回目の８：５９：５９台まで）
Ｂ領域：うるう秒挿入以後の時刻（２回目の８：５９：５９以降）
Ｃ領域：うるう秒削除の直前までの時刻（９：００：００まで）
Ｄ領域：うるう秒削除以後の時刻（９：時００：００以降）
【０７９７】
ステップＳ２２０１において、Ａ領域であると判定された場合であって、ＭＰＵタイムスタンプが９：００：００以降を示す場合は、ＭＰＵタイムスタンプを−１秒補正し、補正したＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する（Ｓ２２０２）。
【０７９８】
そして、ＭＰＵタイムスタンプを補正したことを示す補正情報をシグナリングし、受信装置に送信する（Ｓ２２０３）。
【０７９９】
また、ステップＳ２２０１において、Ｃ領域であると判定された場合であって、ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプを＋１秒補正し、補正したＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する（Ｓ２２０５）。
【０８００】
また、ステップＳ２２０１において、Ｂ領域またはＤ領域であると判定された場合、ＭＰＵタイムスタンプを補正せずにＭＰＵタイムスタンプ記述子に格納する（Ｓ２２０４）。
【０８０１】
次に、受信装置の動作フローについて、図８７を用いて説明する。
【０８０２】
送信側からシグナリングされた情報に基づいて、ＭＰＵタイムスタンプが補正されているか否かを判定する（Ｓ２３０１）。
【０８０３】
ＭＰＵタイムスタンプが補正されていると判定された場合（Ｓ２３０１でＹｅｓ）は、受信装置においてうるう秒調整が実施された後のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する（Ｓ２３０２）。
【０８０４】
ＭＰＵタイムスタンプが補正されていないと判定された場合（Ｓ２３０１でＮｏ）は、ＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
【０８０５】
なお、ＭＰＵタイムスタンプを補正する場合は、当該ＭＰＵタイムスタンプに対応するＭＰＵをうるう秒が挿入される区間に提示する。
【０８０６】
反対に、ＭＰＵタイムスタンプを補正しない場合は、当該ＭＰＵタイムスタンプに対応するＭＰＵを、うるう秒が挿入される区間に提示することはなく、うるう秒が挿入されない区間に提示する。
【０８０７】
図８５で説明した、受信装置においてＭＰＵタイムスタンプを補正する場合の、送信側の動作フローを図８８に、受信装置の動作フローを図８９に示す。
【０８０８】
まず、送信側（送信装置）の動作フローについて、図８８を用いて説明する。
【０８０９】
ＮＴＰパケットのｌｅａｐ＿ｉｎｄｉｃａｔｏｒに基づいて、うるう秒の調整（挿入や削除）が行われかを判定する（Ｓ２４０１）。
【０８１０】
うるう秒の調整が行われると判定された場合（Ｓ２４０１でＹｅｓ）、ＭＰＵタイムスタンプの付与のタイミングを判定し、識別情報をシグナリングし、受信装置に送信する（Ｓ２４０２）。
【０８１１】
一方、うるう秒の調整が行われないと判定された場合（Ｓ２０４１でＮｏ）、通常動作のまま処理を終了する。
【０８１２】
次に、受信装置の動作フローについて、図８９を用いて説明する。
【０８１３】
送信側（送信装置）によりシグナリングされた識別情報に基づいて、ＭＰＵタイムスタンプの付与のタイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかを判定する（Ｓ２５０１）。ここで、Ａ領域〜Ｄ領域は、上記で定義したものと同じであるため説明を省略する。なお、図８７と同様に、うるう秒の挿入や削除が行われない場合については、図示しない。
【０８１４】
ステップＳ２５０１において、Ａ領域であると判定された場合であって、ＭＰＵタイムスタンプが９：００：００以降を示す場合は、ＭＰＵタイムスタンプを−１秒補正する（Ｓ２５０２）。
【０８１５】
ステップＳ２５０１において、Ｃ領域であると判定された場合であって、ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプを＋１秒補正する（Ｓ２５０４）。
【０８１６】
ステップＳ２５０１において、Ｂ領域またはＤ領域であると判定された場合、ＭＰＵタイムスタンプを補正しない（Ｓ２５０３）。
【０８１７】
受信装置は、さらに、図示しない処理において、補正されたＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
【０８１８】
なお、ＭＰＵタイムスタンプを補正する場合は、うるう秒調整が実施された後のＮＴＰ時刻におけるＭＰＵタイムスタンプに基づいて、当該ＭＰＵタイムスタンプに対応するＭＰＵを提示する。
【０８１９】
反対に、ＭＰＵタイムスタンプを補正しない場合は、当該ＭＰＵタイムスタンプに対応するＭＰＵを、うるう秒が挿入される区間に提示することはなく、うるう秒が挿入されない区間に提示する。
【０８２０】
要するに、送信側（送信装置）は、複数のＭＰＵのそれぞれについて、当該ＭＰＵに対応するＭＰＵタイムスタンプを付与するタイミングを判定する。そして、判定の結果、当該タイミングがうるう秒挿入の直前までの時刻の場合であって、当該ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを−１秒補正する。また、ＭＰＵタイムスタンプを補正したことを示す補正情報をシグナリングし、受信装置に送信する。また、判定の結果、当該タイミングがうるう秒削除の直前までの時刻の場合であって、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。
【０８２１】
また、受信装置は、送信側（送信装置）によりシグナリングされた補正情報により示されるＭＰＵタイムスタンプが補正されているか否かに基づいて、ＭＰＵタイムスタンプが補正されていることが示される場合には、うるう秒調整が実施された後のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。ＭＰＵタイムスタンプが補正されていない場合は、うるう秒調整前のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
【０８２２】
また、送信側（送信装置）は、複数のＭＰＵのそれぞれについて、当該ＭＰＵに対応するＭＰＵタイムスタンプを付与するタイミングを判定し、判定した結果をシグナリングする。受信装置はｌ、送信側によりシグナリングされた、ＭＰＵタイムスタンプを付与するタイミングを示す情報に基づき、以下の処理を行う。具体的には、当該タイミングを示す情報がうるう秒挿入の直前までの時刻であることを示す場合であって、ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを−１秒補正する。また、当該タイミングを示す情報がうるう秒削除の直前までの時刻の場合であって、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。
【０８２３】
受信装置は、ＭＰＵタイムスタンプが補正されている場合には、うるう秒調整が実施された後のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。ＭＰＵタイムスタンプが補正されていない場合は、うるう秒調整前のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
【０８２４】
このように、うるう秒調整における、ＭＰＵタイムスタンプの付与のタイミングを判定することにより、ＭＰＵタイムスタンプの補正が可能となり、受信装置は、どのＭＰＵを提示すべきかの判断ができ、ＭＰＵタイムスタンプ記述子やＭＰＵ拡張タイムスタンプ記述子を用いた適切な受信処理が可能となる。つまり、ＮＴＰ時刻にうるう秒調整が行われた場合であっても、受信装置において、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプを用いて正常なＭＰＵの提示が可能となる。
【０８２５】
［補足：送信装置及び受信装置］
以上のように、符号化ストリームを構成するデータをＭＰＵに格納して送信する送信装置は、図９０のように構成することも可能である。また、符号化ストリームを構成するデータが格納されたＭＰＵを受信する受信装置は、図９１のように構成することも可能である。図９０は、送信装置の具体的構成の例を示す図である。図９１は、受信装置の具体的構成の例を示す図である。
【０８２６】
送信装置９００は、生成部９０１と、送信部９０２とを備える。生成部９０１及び送信部９０２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０８２７】
受信装置１０００は、受信部１００１と、再生部１００２とを備える。受信部１００１及び再生部１００２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
【０８２８】
送信装置９００及び受信装置１０００の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
【０８２９】
まず、送信方法については、図９２を用いて説明する。図９２は、送信装置による動作フロー（送信方法）である。
【０８３０】
まず、送信装置９００の生成部９０１は、外部から受信した基準時刻情報としてのＮＴＰ時刻に基づいて、所定のデータユニットとしてのＭＰＵの提示時刻を示す提示時刻情報（ＭＰＵタイムスタンプ）を生成する（Ｓ２６０１）。
【０８３１】
次に、送信装置９００の送信部９０２は、ＭＰＵと、生成部９０１により生成された提示時刻情報と、当該提示時刻情報がうるう秒調整前のＮＴＰ時刻に基づいて生成されたか否かを示す識別情報とを送信する（Ｓ２６０２）。
【０８３２】
これにより、送信装置９００から送信された情報を受信した受信装置は、うるう秒調整が行われた場合であっても、識別情報に基づいてＭＰＵを再生できるので、ＭＰＵを意図された時刻に再生できる。
【０８３３】
次に、受信方法について図９３を用いて説明する。図９３は、受信装置による動作フロー（受信方法）である。
【０８３４】
まず、受信装置１０００の受信部１００１は、ＭＰＵと、ＭＰＵの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前のＮＴＰ時刻に基づいて生成されたか否かを示す識別情報とを、受信する（Ｓ２７０１）。
【０８３５】
次に、受信装置１０００の再生部１００２は、受信部１００１により受信された提示時刻情報及び識別情報に基づいて、受信部１００１により受信されたＭＰＵを再生する（Ｓ２７０２）。
【０８３６】
これにより、受信装置１０００は、うるう秒調整が行われた場合であっても、ＭＰＵを正常に再生できる。
【０８３７】
なお、実施の形態６において、再生とは、復号及び提示の少なくとも一方の処理を含む処理を示す。
【０８３８】
（その他の実施の形態）
以上、実施の形態に係る送信装置、受信装置、送信方法及び受信方法ついて説明したが、本発明は、この実施の形態に限定されるものではない。
【０８３９】
また、上記実施の形態に係る送信装置及び受信装置に含まれる各処理部は典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。
【０８４０】
また、集積回路化はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０８４１】
上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ又はプロセッサなどのプログラム実行部が、ハードディスク又は半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
【０８４２】
言い換えると、送信装置及び受信装置は、処理回路（ｐｒｏｃｅｓｓｉｎｇ  ｃｉｒｃｕｉｔｒｙ）と、当該処理回路に電気的に接続された（当該制御回路からアクセス可能な）記憶装置（ｓｔｏｒａｇｅ）とを備える。処理回路は、専用のハードウェア及びプログラム実行部の少なくとも一方を含む。また、記憶装置は、処理回路がプログラム実行部を含む場合には、当該プログラム実行部により実行されるソフトウェアプログラムを記憶する。処理回路は、記憶装置を用いて、上記実施の形態に係る送信方法又は受信方法を実行する。
【０８４３】
さらに、本発明は上記ソフトウェアプログラムであってもよいし、上記プログラムが記録された非一時的なコンピュータ読み取り可能な記録媒体であってもよい。また、上記プログラムは、インターネット等の伝送媒体を介して流通させることができるのは言うまでもない。
【０８４４】
また、上記で用いた数字は、全て本発明を具体的に説明するために例示するものであり、本発明は例示された数字に制限されない。
【０８４５】
また、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェア又はソフトウェアが並列又は時分割に処理してもよい。
【０８４６】
また、上記の送信方法又は受信方法に含まれるステップが実行される順序は、本発明を具体的に説明するために例示するためのものであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時（並列）に実行されてもよい。
【０８４７】
以上、本発明の一つ又は複数の態様に係る送信装置、受信装置、送信方法及び受信方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つ又は複数の態様の範囲内に含まれてもよい。
【産業上の利用可能性】
【０８４８】
本発明は、ビデオデータ及びオーディオデータなどのメディアトランスポートを行う装置又は機器に適用できる。
【符号の説明】
【０８４９】
１５、１００、３００、５００、７００、９００  送信装置
１６、１０１、３０１  符号化部
１７、１０２  多重化部
１８、１０４  送信部
２０、２００、４００、６００、８００、１０００  受信装置
２１  パケットフィルタリング部
２２  送信順序タイプ判別部
２３  ランダムアクセス部
２４、２１２  制御情報取得部
２５  データ取得部
２６  算出部
２７  初期化情報取得部
２８、２０６  復号命令部
２９、２０４Ａ、２０４Ｂ、２０４Ｃ、２０４Ｄ、４０２  復号部
３０  提示部
２０１  チューナー
２０２  復調部
２０３  逆多重化部
２０５  表示部
２１１  タイプ判別部
２１３  スライス情報取得部
２１４  復号データ生成部
３０２  付与部
３０３、５０３、７０２、９０２  送信部
４０１、６０１、８０１、１００１  受信部
５０１  分割部
５０２、６０３  構成部
６０２  判定部
７０１、９０１  生成部
８０２  第１のバッファ
８０３  第２のバッファ
８０４  第３のバッファ
８０５  第４のバッファ
８０６  復号部
１００２  再生部
【図１】
2020205633.tif 000003
【図２】
2020205633.tif 000004
【図３】
2020205633.tif 000005
【図４】
2020205633.tif 000006
【図５】
2020205633.tif 000007
【図６】
2020205633.tif 000008
【図７】
2020205633.tif 000009
【図８】
2020205633.tif 000010
【図９】
2020205633.tif 000011
【図１０】
2020205633.tif 000012
【図１１】
2020205633.tif 000013
【図１２】
2020205633.tif 000014
【図１３】
2020205633.tif 000015
【図１４】
2020205633.tif 000016
【図１５】
2020205633.tif 000017
【図１６】
2020205633.tif 000018
【図１７】
2020205633.tif 000019
【図１８】
2020205633.tif 000020
【図１９】
2020205633.tif 000021
【図２０】
2020205633.tif 000022
【図２１】
2020205633.tif 000023
【図２２】
2020205633.tif 000024
【図２３】
2020205633.tif 000025
【図２４】
2020205633.tif 000026
【図２５】
2020205633.tif 000027
【図２６】
2020205633.tif 000028
【図２７】
2020205633.tif 000029
【図２８】
2020205633.tif 000030
【図２９】
2020205633.tif 000031
【図３０】
2020205633.tif 000032
【図３１】
2020205633.tif 000033
【図３２】
2020205633.tif 000034
【図３３】
2020205633.tif 000035
【図３４】
2020205633.tif 000036
【図３５】
2020205633.tif 000037
【図３６】
2020205633.tif 000038
【図３７】
2020205633.tif 000039
【図３８】
2020205633.tif 000040
【図３９】
2020205633.tif 000041
【図４０】
2020205633.tif 000042
【図４１】
2020205633.tif 000043
【図４２】
2020205633.tif 000044
【図４３】
2020205633.tif 000045
【図４４】
2020205633.tif 000046
【図４５】
2020205633.tif 000047
【図４６】
2020205633.tif 000048
【図４７】
2020205633.tif 000049
【図４８】
2020205633.tif 000050
【図４９】
2020205633.tif 000051
【図５０】
2020205633.tif 000052
【図５１】
2020205633.tif 000053
【図５２】
2020205633.tif 000054
【図５３】
2020205633.tif 000055
【図５４】
2020205633.tif 000056
【図５５】
2020205633.tif 000057
【図５６】
2020205633.tif 000058
【図５７】
2020205633.tif 000059
【図５８】
2020205633.tif 000060
【図５９】
2020205633.tif 000061
【図６０】
2020205633.tif 000062
【図６１】
2020205633.tif 000063
【図６２】
2020205633.tif 000064
【図６３】
2020205633.tif 000065
【図６４】
2020205633.tif 000066
【図６５】
2020205633.tif 000067
【図６６】
2020205633.tif 000068
【図６７】
2020205633.tif 000069
【図６８】
2020205633.tif 000070
【図６９】
2020205633.tif 000071
【図７０】
2020205633.tif 000072
【図７１】
2020205633.tif 000073
【図７２】
2020205633.tif 000074
【図７３】
2020205633.tif 000075
【図７４】
2020205633.tif 000076
【図７５】
2020205633.tif 000077
【図７６】
2020205633.tif 000078
【図７７】
2020205633.tif 000079
【図７８】
2020205633.tif 000080
【図７９】
2020205633.tif 000081
【図８０】
2020205633.tif 000082
【図８１】
2020205633.tif 000083
【図８２】
2020205633.tif 000084
【図８３】
2020205633.tif 000085
【図８４】
2020205633.tif 000086
【図８５】
2020205633.tif 000087
【図８６】
2020205633.tif 000088
【図８７】
2020205633.tif 000089
【図８８】
2020205633.tif 000090
【図８９】
2020205633.tif 000091
【図９０】
2020205633.tif 000092
【図９１】
2020205633.tif 000093
【図９２】
2020205633.tif 000094
【図９３】
2020205633.tif 000095