JP6300114B2 - 送信方法、受信方法、送信装置及び受信装置 - Google Patents

送信方法、受信方法、送信装置及び受信装置 Download PDF

Info

Publication number
JP6300114B2
JP6300114B2 JP2015141708A JP2015141708A JP6300114B2 JP 6300114 B2 JP6300114 B2 JP 6300114B2 JP 2015141708 A JP2015141708 A JP 2015141708A JP 2015141708 A JP2015141708 A JP 2015141708A JP 6300114 B2 JP6300114 B2 JP 6300114B2
Authority
JP
Japan
Prior art keywords
data
unit
divided
information
mpu
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015141708A
Other languages
English (en)
Other versions
JP2016039629A (ja
Inventor
賀敬 井口
賀敬 井口
遠間　正真
正真 遠間
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Priority to EP15830286.9A priority Critical patent/EP3179730B1/en
Priority to PCT/JP2015/003812 priority patent/WO2016021153A1/ja
Priority to CN201580040893.5A priority patent/CN106576188B/zh
Publication of JP2016039629A publication Critical patent/JP2016039629A/ja
Priority to US15/419,389 priority patent/US10327000B2/en
Application granted granted Critical
Publication of JP6300114B2 publication Critical patent/JP6300114B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/174—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a slice, e.g. a line of blocks or a group of blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/166—IP fragmentation; TCP segmentation

Description

本発明は、送信方法、受信方法、送信装置及び受信装置に関する。
放送及び通信サービスの高度化に伴い、８Ｋ（７６８０×４３２０ピクセル：以下では８Ｋ４Ｋとも呼ぶ）及び４Ｋ（３８４０×２１６０ピクセル：以下では４Ｋ２Ｋとも呼ぶ）などの超高精細な動画像コンテンツの導入が検討されている。受信装置は、受信した超高精細な動画像の符号化データを実時間で復号して表示する必要があるが、特に８Ｋなどの解像度の動画像は復号時の処理負荷が大きく、このような動画像を１つの復号器で、実時間で復号することは困難である。従って、複数の復号器を用いて復号処理を並列化することで、１つの復号器あたりの処理負荷を低減し、実時間処理を達成する方法が検討されている。
また、符号化データはＭＰＥＧ−２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）又はＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）などの多重化方式に基づいて多重化されたうえで送信される。例えば、非特許文献１には、ＭＭＴに従って、符号化されたメディアデータをパケット毎に送信する技術が開示されている。
Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ − Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔ − Ｐａｒｔ１：ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ ＤＩＳ ２３００８−１
ＭＭＴ方式におけるメディアデータの送信において、メディアデータを複数の分割データに分割してパケットで送信した場合、現在のＭＭＴ方式におけるシグナリング情報を用いた伝送では、受信したパケットから、メディアデータがいくつの分割データに分割されたかを示す分割データ数と、当該パケットに含まれる分割データが何番目の分割データであるのかを示す分割シーケンス番号とを一意に特定できる情報がなかった。このため、メディアデータが分割されることにより得られた複数の分割データのうち途中の分割データを受信した時点では、当該分割データの分割シーケンス番号を一意に特定できなかった。
本発明は、ＭＭＴのような方式を用いてデータ伝送する場合に、装置の処理量を削減できる送信方法及び受信方法を提供する。
上記目的を達成するために、本発明の一態様に係る送信方法は、ヘッダ情報に、データが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある分割データの数を示すフラグメントカウンタを含む複数のパケットを送信する送信方法であって、データを複数の分割データに分割する分割ステップと、前記複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、前記複数のパケットを構成する構成ステップと、構成された前記複数のパケットを送信する送信ステップと、を含み、前記送信ステップでは、（ｉ）当該分割データが前記複数の分割データのうちの何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定するための分割データ情報、および、（ｉｉ）固定値が設定され、無効化された前記フラグメントカウンタを、送信する。
また、本発明の一態様に係る受信方法は、ヘッダ情報に、データが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある分割データの数を示すフラグメントカウンタを含む複数のパケットを受信する受信方法であって、前記複数のパケットを受信する受信ステップと、受信した前記複数のパケットから、データが分割されることにより得られた複数の分割データのうち当該パケットに含まれる分割データが何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定するための分割データ情報が、取得されたか否かを判定する判定ステップと、前記判定ステップにおいて、前記分割データ情報を取得したと判定された場合、当該ヘッダ情報に含まれる固定値が設定された前記フラグメントカウンタを使用せずに、前記分割データ情報によって特定される前記分割データ番号と前記分割データ数とに基づいて、受信した前記複数のパケットから前記データを構成する構成ステップと、を含む。
なお、これらの全般的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
本発明は、ＭＭＴのような方式を用いてデータを伝送する場合に、装置の処理量を削減することができる。
図１は、ピクチャをスライスセグメントに分割する例を示す図である。 図２は、ピクチャのデータが格納されたＰＥＳパケット列の一例を示す図である。 図３は、実施の形態１に係るピクチャの分割例を示す図である。 図４は、実施の形態１の比較例に係るピクチャの分割例を示す図である。 図５は、実施の形態１に係るアクセスユニットのデータの一例を示す図である。 図６は、実施の形態１に係る送信装置のブロック図である。 図７は、実施の形態１に係る受信装置のブロック図である。 図８は、実施の形態１に係るＭＭＴパケットの一例を示す図である。 図９は、実施の形態１に係るＭＭＴパケットの別の例を示す図である。 図１０は、実施の形態１に係る各復号部に入力されるデータの一例を示す図である。 図１１は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。 図１２は、実施の形態１に係る各復号部に入力されるデータの別の例を示す図である。 図１３は、実施の形態１に係るピクチャの分割例を示す図である。 図１４は、実施の形態１に係る送信方法のフローチャートである。 図１５は、実施の形態１に係る受信装置のブロック図である。 図１６は、実施の形態１に係る受信方法のフローチャートである。 図１７は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。 図１８は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。 図１９は、ＭＰＵの構成を示す図である。 図２０は、ＭＦメタデータの構成を示す図である。 図２１は、データの送信順序を説明するための図である。 図２２は、ヘッダ情報を用いずに復号を行う方法の例を示す図である。 図２３は、実施の形態２に係る送信装置のブロック図である。 図２４は、実施の形態２に係る送信方法のフローチャートである。 図２５は、実施の形態２に係る受信装置のブロック図である。 図２６は、ＭＰＵ先頭位置及びＮＡＬユニット位置を特定するための動作のフローチャートである。 図２７は、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作のフローチャートである。 図２８は、低遅延提示モードが設けられた場合の受信装置の動作のフローチャートである。 図２９は、補助データが送信される場合のＭＭＴパケットの送信順序の一例を示す図である。 図３０は、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例を説明するための図である。 図３１は、補助データの受信を説明するための図である。 図３２は、補助データを用いた受信動作のフローチャートである。 図３３は、複数のムービーフラグメントで構成されるＭＰＵの構成を示す図である。 図３４は、図３３の構成のＭＰＵが伝送される場合のＭＭＴパケットの送信順序を説明するための図である。 図３５は、１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信装置の動作例を説明するための第１の図である。 図３６は、１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信装置の動作例を説明するための第２の図である。 図３７は、図３５及び図３６で説明した受信方法の動作のフローチャートである。 図３８は、非ＶＣＬ ＮＡＬユニットを、個別にデータユニットとし、アグリゲーションする場合を示す図である。 図３９は、非ＶＣＬ ＮＡＬユニットを、まとめてデータユニットとする場合を示す図である。 図４０は、パケットロスが発生した場合の受信装置の動作のフローチャートである。 図４１は、ＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作のフローチャートである。 図４２は、時間スケーラビリティを実現する際の各ＴｅｍｐｏｒａｌＩｄにおけるピクチャの予測構造の例を示す図である。 図４３は、図４２の各ピクチャにおける復号時刻（ＤＴＳ）と表示時刻（ＰＴＳ）との関係を示す図である。 図４４は、ピクチャの遅延処理、及び、リオーダ処理が必要となるピクチャの予測構造の一例を示す図である。 図４５は、ＭＰ４形式で構成されるＭＰＵが複数のムービーフラグメントに分割されて、ＭＭＴＰペイロード、ＭＭＴＰパケットに格納される例を示す図である。 図４６は、ＰＴＳ及びＤＴＳの算出方法と課題とを説明するための図である。 図４７は、ＤＴＳ算出用の情報を用いてＤＴＳが算出される場合の受信動作のフローチャートである。 図４８は、ＭＭＴにおけるデータユニットのペイロードへの格納方法を説明するための図である。 図４９は、実施の形態３に係る送信装置の動作フローである。 図５０は、実施の形態３に係る受信装置の動作フローである。 図５１は、実施の形態３に係る送信装置の具体的構成の例を示す図である。 図５２は、実施の形態３に係る受信装置の具体的構成の例を示す図である。 図５３は、ｎｏｎ−ｔｉｍｅｄメディアのＭＰＵへの格納方法、及び、ＭＭＴＰパケットでの伝送方法を示す図である。 図５４は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する例を示す図である。 図５５は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する他の例を示す図である。 図５６は、アセット管理テーブルにおけるファイル毎のループのシンタックスを示す図である。 図５７は、受信装置における分割データ番号を特定する動作フローである。 図５８は、受信装置における分割データ数を特定する動作フローである。 図５９は、送信装置においてフラグメントカウンタを運用するかどうかを決定するための動作フローである。 図６０は、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明するための図である。 図６１は、フラグメントカウンタを活用する場合の送信装置の動作フローである。 図６２は、フラグメントカウンタを活用する場合の受信装置の動作フローである。 図６３は、同一番組を複数のＩＰデータフローで送信する場合のサービス構成を示す図である。 図６４は、送信装置の具体的構成の例を示す図である。 図６５は、受信装置の具体的構成の例を示す図である。 図６６は、送信装置による動作フローである。 図６７は、受信装置による動作フローである。
本発明の一態様に係る送信方法は、ヘッダ情報にフラグメントカウンタを含む複数のパケットを送信する送信方法であって、データを複数の分割データに分割する分割ステップと、前記複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、前記複数のパケットを構成する構成ステップと、構成された前記複数のパケットを送信する送信ステップと、を含み、前記送信ステップでは、（ｉ）当該分割データが前記複数の分割データのうちの何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定するための分割データ情報、および、（ｉｉ）無効化された前記フラグメントカウンタの値を、送信する。
このような送信方法は、ＭＭＴのような方式を用いてデータを伝送する場合に、装置の処理量を削減することができる。
また、本発明の一態様に係る受信方法は、ヘッダ情報にフラグメントカウンタを含む複数のパケットを受信する受信方法であって、前記複数のパケットを受信する受信ステップと、受信した前記複数のパケットから、データが分割されることにより得られた複数の分割データのうち当該パケットに含まれる分割データが何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定するための分割データ情報が、取得されたか否かを判定する判定ステップと、前記判定ステップにおいて、前記分割データ情報を取得したと判定された場合、当該ヘッダ情報に含まれる前記フラグメントカウンタの値を使用せずに、受信した前記複数のパケットから前記データを構成する構成ステップと、を含む。
このような受信方法は、ＭＭＴのような方式を用いてデータを伝送する場合に、装置の処理量を削減することができる。
本発明の一態様に係る送信装置は、ヘッダ情報にフラグメントカウンタを含む複数のパケットを送信する送信装置であって、データを複数の分割データに分割する分割部と、前記複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、前記複数のパケットを構成する構成部と、構成された前記複数のパケットを送信する送信部と、を備え、前記送信部は、（ｉ）当該分割データが前記複数の分割データのうちの何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定するための分割データ情報、および、（ｉｉ）無効化された前記フラグメントカウンタの値を、送信する。
本発明の一態様に係る受信装置は、ヘッダ情報にフラグメントカウンタを含む複数のパケットを受信する受信方法であって、前記複数のパケットを受信する受信部と、受信した前記複数のパケットから、データが分割されることにより得られた複数の分割データのうち当該パケットに含まれる分割データが何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定できる分割データ情報が、取得されたか否かを判定する判定部と、前記判定部により、前記ヘッダ情報に分割データ情報を取得したと判定された場合、当該ヘッダ情報に含まれる前記フラグメントカウンタの値を使用せずに、受信した前記複数のパケットから前記データを構成する構成部と、を備える。
なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
以下、実施の形態について、図面を参照しながら具体的に説明する。
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
（本発明の基礎となった知見）
近年、ＴＶ、スマートフォン、又はタブレット端末などのディスプレイの高解像度化が進んでいる。特に日本国内の放送においては２０２０年に８Ｋ４Ｋ（解像度が８Ｋ×４Ｋ）のサービスが予定されている。８Ｋ４Ｋなどの超高解像度の動画像においては、単一の復号器では実時間での復号が困難であるため、複数の復号器を用いて並列に復号処理を行う手法が検討されている。
符号化データはＭＰＥＧ−２ ＴＳやＭＭＴなどの多重化方式に基づいて多重化して送信されるため、受信装置は、復号に先立って、多重化データから動画の符号化データを分離する必要がある。以下、多重化データから符号化データを分離する処理を逆多重化と呼ぶ。
復号処理を並列化する際には、各復号器のそれぞれに対して、復号対象となる符号化データを振り分ける必要がある。符号化データを振り分ける際には、符号化データそのものを解析する必要があり、特に８Ｋなどのコンテンツにおいてはビットレートが非常に高いことから、解析に係る処理負荷が大きい。したがって、逆多重化の部分がボトルネックとなり実時間での再生が行えないという課題があった。
ところで、ＭＰＥＧとＩＴＵにより規格化されたＨ．２６４及びＨ．２６５などの動画像符号化方式においては、送信装置は、ピクチャをスライス又はスライスセグメントと呼ばれる複数の領域に分割し、分割したそれぞれの領域を独立に復号できるように符号化することができる。従って、例えば、Ｈ．２６５の場合には、放送を受信する受信装置は、受信データからスライスセグメント毎のデータを分離し、各スライスセグメントのデータを別々の復号器に出力することで、復号処理の並列化を実現できる。
図１は、ＨＥＶＣにおいて、１つのピクチャを４つのスライスセグメントに分割する例を示す図である。例えば、受信装置は４つの復号器を備え、各復号器が４つのスライスセグメントのうちいずれかを復号する。
従来の放送においては、送信装置は、１枚のピクチャ（ＭＰＥＧシステム規格におけるアクセスユニット）を１つのＰＥＳパケットに格納し、ＰＥＳパケットをＴＳパケット列に多重化する。このため、受信装置は、ＰＥＳパケットのペイロードを分離したうえで、ペイロードに格納されたアクセスユニットのデータを解析することで、各スライスセグメントを分離し、分離された各スライスセグメントのデータを復号器に出力する必要があった。
しかしながら、アクセスユニットのデータを解析してスライスセグメントを分離する際の処理量が大きいため、この処理を実時間で行うことが困難であるという課題があることを本発明者は見出した。
図２は、スライスセグメントに分割されたピクチャのデータが、ＰＥＳパケットのペイロードに格納される例を示す図である。
図２に示すように、例えば、複数のスライスセグメント（スライスセグメント１〜４）のデータが１つのＰＥＳパケットのペイロードに格納される。また、ＰＥＳパケットはＴＳパケット列に多重化される。
（実施の形態１）
以下では、動画像の符号化方式としてＨ．２６５を用いる場合を例に説明するが、Ｈ．２６４など他の符号化方式を用いる場合にも本実施の形態を適用できる。
図３は、本実施の形態におけるアクセスユニット（ピクチャ）を分割単位に分割した例を示す図である。アクセスユニットは、Ｈ．２６５によって導入されたタイルと呼ばれる機能により、水平及び垂直方向にそれぞれ２等分され、合計４つのタイルに分割される。また、スライスセグメントとタイルは１対１に対応付けられる。
このように水平及び垂直方向に２等分する理由について説明する。まず、復号時には、一般的に水平１ラインのデータを格納するラインメモリが必要となるが、８Ｋ４Ｋなどの超高解像度になると、水平方向のサイズが大きくなるためラインメモリのサイズが増加する。受信装置の実装においては、ラインメモリのサイズを低減できることが望ましい。ラインメモリのサイズを低減するためには垂直方向の分割が必要となる。垂直方向の分割にはタイルというデータ構造が必要である。これらの理由により、タイルが用いられる。
一方で、画像は一般的に水平方向の相関が高いため、水平方向に広い範囲を参照できるほうが符号化効率は向上する。従って、符号化効率の観点ではアクセスユニットが水平方向に分割されることが望ましい。
アクセスユニットが水平及び垂直方向に２等分されることで、これら２つの特性を両立させ、実装面、及び符号化効率の両面を考慮できる。単一の復号器が４Ｋ２Ｋの動画像を実時間での復号が可能の場合には、８Ｋ４Ｋの画像が４等分され、各々のスライスセグメントが４Ｋ２Ｋとなるように分割されることで、受信装置は、８Ｋ４Ｋの画像を実時間で復号できる。
次に、アクセスユニットが水平及び垂直方向に分割されることで得られたタイルとスライスセグメントとを１対１に対応付ける理由について説明する。Ｈ．２６５においては、アクセスユニットは複数のＮＡＬ（Ｎｅｔｗｏｒｋ Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ）ユニットと呼ばれる単位から構成される。
ＮＡＬユニットのペイロードは、アクセスユニットの開始位置を示すアクセスユニットデリミタ、シーケンス単位で共通に用いられる復号時の初期化情報であるＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャ内で共通に用いられる復号時の初期化情報であるＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、復号処理自体には不要であるが復号結果の処理及び表示などにおいて必要となるＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）、並びに、スライスセグメントの符号化データなどのいずれかを格納する。ＮＡＬユニットのヘッダは、ペイロードに格納されるデータを識別するためのタイプ情報を含む。
ここで、送信装置は、符号化データをＭＰＥＧ−２ ＴＳ、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）、ＭＰＥＧ ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）、又は、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの多重化フォーマットによって多重化する際には、基本単位をＮＡＬユニットに設定できる。１つのスライスセグメントを１つのＮＡＬユニットに格納するためには、アクセスユニットを領域に分割する際に、スライスセグメント単位に分割することが望ましい。このような理由から、送信装置は、タイルとスライスセグメントとを１対１に対応付ける。
なお、図４に示すように、送信装置は、タイル１からタイル４までをまとめて１つのスライスセグメントに設定することも可能である。しかし、この場合には、１つのＮＡＬユニットに全てのタイルが格納されることになり、受信装置が、多重化レイヤにおいてタイルを分離することが困難である。
なお、スライスセグメントには独立に復号可能な独立スライスセグメントと、独立スライスセグメントを参照する参照スライスセグメントとが存在するが、ここでは独立スライスセグメントが用いられる場合を説明する。
図５は、図３に示すようにタイルとスライスセグメントとの境界が一致するように分割されたアクセスユニットのデータの例を示す図である。アクセスユニットのデータは、先頭に配置されたアクセスユニットデリミタが格納されるＮＡＬユニットと、その後に配置されるＳＰＳ、ＰＰＳ、及びＳＥＩのＮＡＬユニットと、その後に配置されるタイル１からタイル４までのデータが格納されたスライスセグメントのデータとを含む。なお、アクセスユニットのデータは、ＳＰＳ、ＰＰＳ及びＳＥＩのＮＡＬユニットの一部又は全てを含まなくてもよい。
次に、本実施の形態に係る送信装置１００の構成を説明する。図６は、本実施の形態に係る送信装置１００の構成例を示すブロック図である。この送信装置１００は、符号化部１０１と、多重化部１０２と、変調部１０３と、送信部１０４とを備える。
符号化部１０１は、入力画像を、例えば、Ｈ．２６５に従い符号化することで符号化データを生成する。また、符号化部１０１は、例えば、図３に示すように、アクセスユニットを４つのスライスセグメント（タイル）に分割し、各スライスセグメントを符号化する。
多重化部１０２は、符号化部１０１により生成された符号化データを多重化する。変調部１０３は、多重化により得られたデータを変調する。送信部１０４は、変調後のデータを放送信号として送信する。
次に、本実施の形態に係る受信装置２００の構成を説明する。図７は、本実施の形態に係る受信装置２００の構成例を示すブロック図である。この受信装置２００は、チューナー２０１と、復調部２０２と、逆多重化部２０３と、複数の復号部２０４Ａ〜２０４Ｄと、表示部２０５とを備える。
チューナー２０１は、放送信号を受信する。復調部２０２は、受信された放送信号を復調する。復調後のデータは逆多重化部２０３に入力される。
逆多重化部２０３は、復調後のデータを分割単位に分離し、分割単位毎のデータを復号部２０４Ａ〜２０４Ｄに出力する。ここで、分割単位とは、アクセスユニットが分割されることで得られた分割領域であり、例えば、Ｈ．２６５におけるスライスセグメントである。また、ここでは、８Ｋ４Ｋの画像が４つの４Ｋ２Ｋの画像に分割される。よって、４つの復号部２０４Ａ〜２０４Ｄが存在する。
複数の復号部２０４Ａ〜２０４Ｄは、所定の基準クロックに基づいて互いに同期して動作する。各復号部は、アクセスユニットのＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）に従って分割単位の符号化データを復号し、復号結果を表示部２０５に出力する。
表示部２０５は、複数の復号部２０４Ａ〜２０４Ｄから出力された複数の復号結果を統合することで８Ｋ４Ｋの出力画像を生成する。表示部２０５は、別途取得したアクセスユニットのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）に従って、生成された出力画像を表示する。なお、表示部２０５は、復号結果を統合する際に、タイルの境界など、互いに隣接する分割単位の境界領域において、当該境界が視覚的に目立たなくなるようにデブロックフィルタなどのフィルタ処理を行ってもよい。
なお、上記では、放送の送信又は受信を行う送信装置１００及び受信装置２００を例に説明したが、コンテンツは通信ネットワーク経由で送信及び受信されてもよい。受信装置２００が、通信ネットワーク経由でコンテンツを受信する場合には、受信装置２００は、イーサーネットなどのネットワークにより受信したＩＰパケットから多重化データを分離する。
放送においては、放送信号が送信されてから受信装置２００に届くまでの間の伝送路遅延は一定である。一方、インターネットなどの通信ネットワークにおいては輻輳の影響により、サーバーから送信されたデータが受信装置２００に届くまでの伝送路遅延は一定でない。従って、受信装置２００は、放送のＭＰＥＧ−２ ＴＳにおけるＰＣＲのような基準クロックに基づいた厳密な同期再生を行わないことが多い。そのため、受信装置２００は、各復号部を厳密に同期させることはせずに、表示部において８Ｋ４Ｋの出力画像をＰＴＳに従って表示してもよい。
また、通信ネットワークの輻輳などにより、全ての分割単位の復号処理がアクセスユニットのＰＴＳで示される時刻において完了していない場合がある。この場合には、受信装置２００は、アクセスユニットの表示をスキップする、又は、少なくとも４つの分割単位の復号が終了し、８Ｋ４Ｋの画像の生成が完了するまで表示を遅延させる。
なお、放送と通信とを併用してコンテンツが送信及び受信されてもよい。また、ハードディスク又はメモリなどの記録媒体に格納された多重化データを再生する際にも本手法を適用可能である。
次に、多重化方式としてＭＭＴが用いられる場合の、スライスセグメントに分割されたアクセスユニットの多重化方法にについて説明する。
図８は、ＨＥＶＣのアクセスユニットのデータを、ＭＭＴにパケット化する際の例を示す図である。ＳＰＳ、ＰＰＳ及びＳＥＩなどはアクセスユニットに必ずしも含まれる必要はないが、ここでは存在する場合について例示する。
アクセスユニットデリミタ、ＳＰＳ、ＰＰＳ、及びＳＥＩなどのアクセスユニット内で先頭のスライスセグメントよりも前に配置されるＮＡＬユニットは一纏めにしてＭＭＴパケット＃１に格納される。後続のスライスセグメントは、スライスセグメント毎に別々のＭＭＴパケットに格納される。
なお、図９に示すように、アクセスユニット内で先頭のスライスセグメントよりも前に配置されるＮＡＬユニットが、先頭のスライスセグメントと同一のＭＭＴパケットに格納されてもよい。
また、シーケンス又はストリームの終端を示す、Ｅｎｄ−ｏｆ−Ｓｅｑｕｅｎｃｅ又はＥｎｄ−ｏｆ−ＢｉｔｓｔｒｅａｍなどのＮＡＬユニットが最終スライスセグメントの後に付加される場合には、これらは、最終スライスセグメントと同一のＭＭＴパケットに格納される。ただし、Ｅｎｄ−ｏｆ−Ｓｅｑｕｅｎｃｅ又はＥｎｄ−ｏｆ−ＢｉｔｓｔｒｅａｍなどのＮＡＬユニットは、復号処理の終了ポイント、又は２本のストリームの接続ポイントなどに挿入されるため、受信装置２００が、これらのＮＡＬユニットを、多重化レイヤにおいて容易に取得できることが望ましい場合がある。この場合には、これらのＮＡＬユニットは、スライスセグメントとは別のＭＭＴパケットに格納されてもよい。これにより、受信装置２００は、多重化レイヤにおいてこれらのＮＡＬユニットを容易に分離できる。
なお、多重化方式として、ＴＳ、ＤＡＳＨ又はＲＴＰなどが用いられてもよい。これらの方式においても、送信装置１００は、異なるスライスセグメントをそれぞれ異なるパケットに格納する。これにより、受信装置２００が多重化レイヤにおいてスライスセグメントを分離できることを保証できる。
例えば、ＴＳが用いられる場合、スライスセグメント単位で符号化データがＰＥＳパケット化される。ＲＴＰが用いられる場合、スライスセグメント単位で符号化データがＲＴＰパケット化される。これらの場合においても、図８に示すＭＭＴパケット＃１のように、スライスセグメントよりも前に配置されるＮＡＬユニットとスライスセグメントとが別々にパケット化されてもよい。
ＴＳが用いられる場合、送信装置１００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を用いることなどにより、ＰＥＳパケットに格納されるデータの単位を示す。また、ＤＡＳＨはセグメントと呼ばれるＭＰ４形式のデータ単位をＨＴＴＰなどによりダウンロードする方式であるため、送信装置１００は、送信にあたって符号化データのパケット化は行わない。このため、送信装置１００は、受信装置２００がＭＰ４において多重化レイヤでスライスセグメントを検出できるように、スライスセグメント単位でサブサンプルを作成し、サブサンプルの格納位置を示す情報をＭＰ４のヘッダに格納してもよい。
以下、スライスセグメントのＭＭＴパケット化について、詳細に説明する。
図８に示すように、符号化データがパケット化されることで、ＳＰＳ及びＰＰＳなどのアクセスユニット内の全スライスセグメントの復号時に共通に参照されるデータがＭＭＴパケット＃１に格納される。この場合、受信装置２００は、ＭＭＴパケット＃１のペイロードデータと各スライスセグメントのデータとを連結し、得られたデータを復号部に出力する。このように、受信装置２００は、複数のＭＭＴパケットのペイロードを連結することで、復号部への入力データを容易に生成できる。
図１０は、図８に示すＭＭＴパケットから復号部２０４Ａ〜２０４Ｄへの入力データが生成される例を示す図である。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃２とのペイロードデータを連結させることで、復号部２０４Ａが、スライスセグメント１を復号するために必要なデータを生成する。逆多重化部２０３は、復号部２０４Ｂから復号部２０４Ｄについても、同様に入力データを生成する。つまり、逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃３とのペイロードデータを連結させることで、復号部２０４Ｂの入力データを生成する。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃４とのペイロードデータを連結させることで、復号部２０４Ｃの入力データを生成する。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃５とのペイロードデータを連結させることで、復号部２０４Ｄの入力データを生成する。
なお、逆多重化部２０３は、アクセスユニットデリミタ及びＳＥＩなど、復号処理に必要ではないＮＡＬユニットを、ＭＭＴパケット＃１のペイロードデータから除去し、復号処理に必要であるＳＰＳ及びＰＰＳのＮＡＬユニットのみを分離してスライスセグメントのデータに付加してもよい。
図９に示すように符号化データがパケット化される場合には、逆多重化部２０３は、多重化レイヤにおいてアクセスユニットの先頭データを含むＭＭＴパケット＃１を1番目の復号部２０４Ａに出力する。また、逆多重化部２０３は、多重化レイヤにおいてアクセスユニットの先頭データを含むＭＭＴパケットを解析し、ＳＰＳ及びＰＰＳのＮＡＬユニットを分離し、分離したＳＰＳ及びＰＰＳのＮＡＬユニットを２番目以降のスライスセグメントのデータの各々に付加することで２番目以降の復号部の各々に対する入力データを生成する。
さらに、受信装置２００が、ＭＭＴパケットのヘッダに含まれる情報を用いて、ＭＭＴペイロードに格納されるデータのタイプ、及び、ペイロードにスライスセグメントが格納されている場合のアクセスユニット内における当該スライスセグメントのインデックス番号を識別できることが望ましい。ここで、データのタイプとは、スライスセグメント前データ（アクセスユニット内で先頭スライスセグメントよりも前に配置されるＮＡＬユニットをまとめて、このように呼ぶことにする）、及び、スライスセグメントのデータのいずれである。ＭＭＴパケットに、スライスセグメントなどのＭＰＵをフラグメント化した単位を格納する場合には、ＭＦＵ（Ｍｅｄｉａ Ｆｒａｇｍｅｎｔ Ｕｎｉｔ）を格納するためのモードが用いられる。送信装置１００は、本モードを用いる場合には、例えば、ＭＦＵにおけるデータの基本単位であるＤａｔａ Ｕｎｉｔを、サンプル（ＭＭＴにおけるデータ単位であり、アクセスユニットに相当する）、又は、サブサンプル（サンプルを分割した単位）に設定できる。
このとき、ＭＭＴパケットのヘッダは、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒと呼ばれるフィールドと、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒと呼ばれるフィールドとを含む。
Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒは、ＭＭＴパケットのペイロードに格納されるデータが、Ｄａｔａ ｕｎｉｔをフラグメント化したものであるかどうか、フラグメント化したものである場合には、当該フラグメントがＤａｔａ ｕｎｉｔにおける先頭或いは最終のフラグメント、又は、先頭と最終とのどちらでもないフラグメントであるかを示す。言い換えると、あるパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒは、（１）基本データ単位であるＤａｔａ ｕｎｉｔに当該パケットのみが含まれる、（２）Ｄａｔａ ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ ｕｎｉｔの先頭のパケットである、（３）Ｄａｔａ ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ ｕｎｉｔの先頭及び最後以外のパケットである、及び、（４）Ｄａｔａ ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ ｕｎｉｔの最後のパケットである、のいずれであるかを示す識別情報である。
Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒは、ＭＭＴパケットに格納されるデータが、Ｄａｔａ ｕｎｉｔにおいて何番目のフラグメントに相当するかを示すインデックス番号である。
従って、送信装置１００が、ＭＭＴにおけるサンプルをＤａｔａ ｕｎｉｔに設定し、スライスセグメント前データ、及び、各スライスセグメントを、それぞれＤａｔａ ｕｎｉｔのフラグメント単位に設定することで、受信装置２００は、ＭＭＴパケットのヘッダに含まれる情報を用いて、ペイロードに格納されるデータのタイプが識別できる。つまり、逆多重化部２０３は、ＭＭＴパケットのヘッダを参照して、各復号部２０４Ａ〜２０４Ｄへの入力データを生成できる。
図１１は、サンプルがＤａｔａ ｕｎｉｔに設定され、スライスセグメント前データ、及び、スライスセグメントがＤａｔａ ｕｎｉｔのフラグメントとしてパケット化される場合の例を示す図である。
スライスセグメント前データ、及びスライスセグメントは、フラグメント＃１からフラグメント＃５までの５つのフラグメントに分割される。各フラグメントは個別のＭＭＴパケットに格納される。このとき、ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ及びＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値は図示する通りである。
例えば、Ｆｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは、２進数の２ビット値である。Ｄａｔａ ｕｎｉｔの先頭であるＭＭＴパケット＃１のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒ、最終であるＭＭＴパケット＃５のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒ、及び、その間のパケットであるＭＭＴパケット＃２からＭＭＴパケット＃４までのＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは、それぞれ別の値に設定される。具体的には、Ｄａｔａ ｕｎｉｔの先頭であるＭＭＴパケット＃１のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは０１に設定され、最終であるＭＭＴパケット＃５のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは１１に設定され、その間のパケットであるＭＭＴパケット＃２からＭＭＴパケット＃４までのＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは１０に設定される。なお、Ｄａｔａ ｕｎｉｔに一つのＭＭＴパケットのみが含まれる場合には、Ｆｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは００に設定される。
また、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒは、ＭＭＴパケット＃１においてはフラグメントの総数である５から１を減算した値である４であり、後続パケットにおいては順に１ずつ減少し、最後のＭＭＴパケット＃５においては０である。
従って、受信装置２００は、スライスセグメント前データを格納するＭＭＴパケットを、Ｆｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒ、及び、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒのいずれかを用いて識別できる。また、受信装置２００は、Ｎ番目のスライスセグメントを格納するＭＭＴパケットを、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒを参照することにより識別できる。
ＭＭＴパケットのヘッダは、別途、Ｄａｔａ ｕｎｉｔが属するＭｏｖｉｅ ＦｒａｇｍｅｎｔのＭＰＵ内でのシーケンス番号と、ＭＰＵ自体のシーケンス番号と、Ｄａｔａ ｕｎｉｔが属するサンプルのＭｏｖｉｅ Ｆｒａｇｍｅｎｔ内におけるシーケンス番号とを含む。逆多重化部２０３は、これらを参照することで、Ｄａｔａ ｕｎｉｔが属するサンプルを一意に決定できる。
更に、逆多重化部２０３は、Ｄａｔａ ｕｎｉｔ内におけるフラグメントのインデックス番号をＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒなどから決定できるため、パケットロスが発生した場合にも、フラグメントに格納されるスライスセグメントを一意に特定できる。例えば、逆多重化部２０３は、図１１に示すフラグメント＃４がパケットロスにより取得できなかった場合でも、フラグメント＃３の次に受信したフラグメントがフラグメント＃５であることが分かるため、フラグメント＃５に格納されるスライスセグメント４を、復号部２０４Ｃではなく復号部２０４Ｄに正しく出力することができる。
なお、パケットロスが発生しないことが保証される伝送路が使用される場合には、逆多重化部２０３は、ＭＭＴパケットのヘッダを参照してＭＭＴパケットに格納されるデータのタイプ、又はスライスセグメントのインデックス番号を決定せずに、到着したパケットを周期的に処理すればよい。例えば、アクセスユニットが、スライス前データ、及び、４つのスライスセグメントの計５つのＭＭＴパケットにより送信される場合には、受信装置２００は、復号を開始するアクセスユニットのスライス前データを決定した後は、受信したＭＭＴパケットを順に処理することで、スライス前データ、及び、４つのスライスセグメントのデータを順に取得できる。
以下、パケット化の変形例について説明する。
スライスセグメントは、必ずしもアクセスユニットの面内を水平方向と垂直方向との両方に分割されたものである必要はなく、図１に示すように、アクセスユニットを水平方向のみに分割されたものでもよいし、垂直方向のみに分割されたものでもよい。
また、水平方向のみにアクセスユニットが分割される場合には、タイルが用いられる必要はない。
また、アクセスユニットにおける面内の分割数は任意であり、４つに限定されるものではない。但し、スライスセグメント及びタイルの領域サイズはＨ．２６５などの符号化規格の下限以上である必要がある。
送信装置１００は、アクセスユニットにおける面内の分割方法を示す識別情報を、ＭＭＴメッセージ、又はＴＳのデスクリプタなどに格納してもよい。例えば、面内における水平方向と垂直方向との分割数とをそれぞれ示す情報が格納されてもよい。または、図３に示すように水平方向及び垂直方向にそれぞれ２等分されている、又は、図１に示すように水平方向に４等分されているなど、分割方法に対して固有の識別情報が割り当てられてもよい。例えば、図３に示すようにアクセスユニットが分割されている場合は、識別情報はモード１を示し、図１に示すようにアクセスユニットが分割されている場合には、識別情報はモード１を示す。
また、面内の分割方法に関連する符号化条件の制約を示す情報が、多重化レイヤに含まれてもよい。例えば、１つのスライスセグメントが１つのタイルから構成されること示す情報が用いられてもよい。または、スライスセグメント或いはタイルの復号時に動き補償を行う場合の参照ブロックが、画面内の同一位置のスライスセグメント或いはタイルに制限される、又は、隣接スライスセグメントにおける所定の範囲内のブロックに限定されることなどを示す情報が用いられてもよい。
また、送信装置１００は、動画像の解像度に応じて、アクセスユニットを複数のスライスセグメントに分割するかどうかを切替えてもよい。例えば、送信装置１００は、処理対象の動画像が４Ｋ２Ｋの解像度の場合には面内の分割を行わずに、処理対象の動画像が８Ｋ４Ｋの場合にはアクセスユニットを４つに分割してもよい。８Ｋ４Ｋの動画像の場合の分割方法を予め規定しておくことにより、受信装置２００は、受信する動画像の解像度を取得することで、面内の分割の有無、及び分割方法を決定し、復号動作を切替えることができる。
また、受信装置２００は、面内の分割の有無を、ＭＭＴパケットのヘッダを参照することにより検出できる。例えば、アクセスユニットが分割されない場合には、ＭＭＴのＤａｔａ ｕｎｉｔがサンプルに設定されていれば、Ｄａｔａ ｕｎｉｔのフラグメントは行われない。従って、受信装置２００は、ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値が常にゼロの場合には、アクセスユニットは分割されないと判定できる。または、受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値が常に０１であるかどうかを検出してもよい。受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値が常に０１の場合もアクセスユニットは分割されないと判定できる。
また、受信装置２００は、アクセスユニットにおける面内の分割数と復号部の数とが一致しない場合にも対応できる。例えば、受信装置２００が、８Ｋ２Ｋの符号化データを実時間で復号できる２つの復号部２０４Ａ及び２０４Ｂを備える場合には、逆多重化部２０３は、復号部２０４Ａに対して、８Ｋ４Ｋの符号化データを構成する４つのスライスセグメントのうちの２つを出力する。
図１２は、図８に示すようにＭＭＴパケット化されたデータが、２つの復号部２０４Ａ及び２０４Ｂに入力される場合の動作例を示す図である。ここで、受信装置２００は、復号部２０４Ａ及び２０４Ｂにおける復号結果を、そのまま統合して出力できることが望ましい。よって、逆多重化部２０３は、復号部２０４Ａ及び２０４Ｂの各々の復号結果が空間的に連続するように、復号部２０４Ａ及び２０４Ｂの各々に出力するスライスセグメントを選択する。
また、逆多重化部２０３は、動画像の符号化データの解像度又はフレームレートなどに応じて、使用する復号部を選択してもよい。例えば、受信装置２００が４Ｋ２Ｋの復号部を４つ備える場合には、入力画像の解像度が８Ｋ４Ｋであれば、受信装置２００は、４つ全ての復号部を用いて復号処理を行う。また、受信装置２００は、入力画像の解像度が４Ｋ２Ｋであれば１つの復号部のみを用いて復号処理を行う。または、逆多重化部２０３は、面内が４つに分割されていても、８Ｋ４Ｋを単一の復号部により実時間で復号できる場合には、全ての分割単位を統合して一つの復号部に出力する。
さらに、受信装置２００は、フレームレートを考慮して使用する復号部を決定してもよい。例えば、受信装置２００が、解像度が８Ｋ４Ｋである場合に実時間で復号可能なフレームレートの上限が６０ｆｐｓである復号部を２台備える場合に、８Ｋ４Ｋで１２０ｆｐｓの符号化データが入力されるケースがある。このとき、面内が４つの分割単位から構成されるとすると、図１２の例と同様に、スライスセグメント１とスライスセグメント２とが復号部２０４Ａに入力され、スライスセグメント３とスライスセグメント４とが復号部２０４Ｂに入力される。各々の復号部２０４Ａ及び２０４Ｂは、８Ｋ２Ｋ（解像度が８Ｋ４Ｋの半分）であれば１２０ｆｐｓまで実時間で復号できるため、これら２台の復号部２０４Ａ及び２０４Ｂにより復号処理が行われる。
また、解像度及びフレームレートが同一であっても、符号化方式におけるプロファイル、或いはレベル、又は、Ｈ．２６４或いはＨ．２６５など符号化方式自体が異なると処理量が異なる。よって、受信装置２００は、これらの情報に基づいて使用する復号部を選択してもよい。なお、受信装置２００は、放送又は通信により受信した符号化データを全て復号することができない場合、又は、ユーザーが選択した領域を構成する全てのスライスセグメント又はタイルが復号できない場合には、復号部の処理範囲内で復号可能なスライスセグメント又はタイルを自動的に決定してもよい。または、受信装置２００は、ユーザーが復号する領域を選択するためのユーザインタフェースを提供してもよい。このとき、受信装置２００は、全て領域を復号できないことを示す警告メッセージを表示してもよいし、復号可能な領域、スライスセグメント又はタイルの個数を示す情報を表示してもよい。
また、上記方法は、同一符号化データのスライスセグメントを格納するＭＭＴパケットが、放送及び通信など複数の伝送路を用いて送信及び受信される場合にも適用できる。
また、送信装置１００は、分割単位の境界を目立たなくするために、各スライスセグメントの領域がオーバーラップするように符号化を行ってもよい。図１３に示す例では、８Ｋ４Ｋのピクチャが４つのスライスセグメント１〜４に分割される。スライスセグメント１〜３の各々は、例えば、８Ｋ×１．１Ｋであり、スライスセグメント４は８Ｋ×１Ｋである。また、隣接するスライスセグメントは互いにオーバーラップする。こうすることで、点線で示す４分割した場合の境界においては、符号化時の動き補償が効率的に実行できるため、境界部分の画質が向上する。このように、境界部分の画質劣化が低減される。
この場合、表示部２０５は、８Ｋ×１．１Ｋの領域から、８Ｋ×１Ｋの領域を切り出し、得られた領域を統合する。なお、送信装置１００は、スライスセグメントがオーバーラップして符号化されているかどうか、及び、オーバーラップの範囲を示す情報を、多重化レイヤ、又は、符号化データ内に含めて、別途送信してもよい。
なお、タイルが使用される場合にも、同様の手法を適用可能である。
以下、送信装置１００の動作の流れを説明する。図１４は、送信装置１００の動作例を示すフローチャートである。
まず、符号化部１０１は、ピクチャ（アクセスユニット）を複数の領域である複数のスライスセグメント（タイル）に分割する（Ｓ１０１）。次に、符号化部１０１は、複数のスライスセグメントの各々を独立して復号が可能なように符号化することで、複数のスライスセグメントの各々に対応する符号化データを生成する（Ｓ１０２）。なお、符号化部１０１は、複数のスライスセグメントを単一の符号化部で符号化してもよし、複数の符号化部で並列処理してもよい。
次に、多重化部１０２は、符号化部１０１で生成された複数の符号化データを、複数のＭＭＴパケットに格納することで、複数の符号化データを多重化する（Ｓ１０３）。具体的には、図８及び図９に示すように、多重化部１０２は、一つのＭＭＴパケットに、異なるスライスセグメントに対応する符号化データが格納されないように、複数の符号化データを複数のＭＭＴパケットに格納する。また、多重化部１０２は、図８に示すように、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報を、複数の符号化データが格納される複数のＭＭＴパケット＃２〜＃５とは異なるＭＭＴパケット＃１に格納する。ここで制御情報は、アクセスユニットデリミタ、ＳＰＳ，ＰＰＳ及びＳＥＩのうち少なくとも一つを含む。
なお、多重化部１０２は、制御情報を、複数の符号化データが格納される複数のＭＭＴパケットのいずれかと同じＭＭＴパケットに格納してもよい。例えば、図９に示すように、多重化部１０２は、制御情報を、複数の符号化データが格納される複数のＭＭＴパケットのうちの先頭のＭＭＴパケット（図９のＭＭＴパケット＃１）に格納してもよい。
最後に、送信装置１００は、複数のＭＭＴパケットを送信する。具体的には、変調部１０３は、多重化により得られたデータを変調し、送信部１０４は、変調後のデータを送信する（Ｓ１０４）。
図１５は、受信装置２００の構成例を示すブロック図であり、図７に示す逆多重化部２０３及びその後段の構成を詳細に示す図である。図１５に示すように、受信装置２００は、さらに、復号命令部２０６を備える。また、逆多重化部２０３は、タイプ判別部２１１と、制御情報取得部２１２と、スライス情報取得部２１３と、復号データ生成部２１４とを備える。
以下、受信装置２００の動作の流れを説明する。図１６は、受信装置２００の動作例を示すフローチャートである。ここでは、１つのアクセスユニットに対する動作を示す。複数のアクセスユニットの復号処理が実行される場合には、本フローチャートの処理が繰り返される。
まず、受信装置２００は、は、例えば、送信装置１００により生成された複数のパケット（ＭＭＴパケット）を受信する（Ｓ２０１）。
次に、タイプ判別部２１１は、受信パケットのヘッダを解析することで、受信パケットに格納されている符号化データのタイプを取得する（Ｓ２０２）。
次に、タイプ判別部２１１は、取得された符号化データのタイプに基づき、受信パケットに格納されているデータがスライスセグメント前データであるか、スライスセグメントのデータであるかを判定する（Ｓ２０３）。
受信パケットに格納されているデータがスライスセグメント前データである場合（Ｓ２０３でＹｅｓ）、制御情報取得部２１２は、受信パケットのペイロードから処理対象のアクセスユニットのスライスセグメント前データを取得し、当該スライスセグメント前データをメモリに格納する（Ｓ２０４）。
一方、受信パケットに格納されているデータがスライスセグメントのデータである場合（Ｓ２０３でＮｏ）、受信装置２００は、受信パケットのヘッダ情報を用いて、当該受信パケットに格納されているデータが、複数の領域のうちいずれの領域の符号化データであるかを判定する。具体的には、スライス情報取得部２１３は、受信パケットのヘッダを解析することで、受信パケットに格納されているスライスセグメントのインデックス番号Ｉｄｘを取得する（Ｓ２０５）。具体的には、インデックス番号Ｉｄｘは、アクセスユニット（ＭＭＴにおけるサンプル）のＭｏｖｉｅ Ｆｒａｇｍｅｎｔ内におけるインデックス番号である。
なお、このステップＳ２０５の処理は、ステップＳ２０２においてまとめて行われてもよい。
次に、復号データ生成部２１４は、当該スライスセグメントを復号する復号部を決定する（Ｓ２０６）。具体的には、インデックス番号Ｉｄｘと複数の復号部とは予め対応付けられており、復号データ生成部２１４は、ステップＳ２０５で取得されたインデックス番号Ｉｄｘに対応する復号部を、当該スライスセグメントを復号する復号部を決定する。
なお、復号データ生成部２１４は、図１２の例において説明したように、アクセスユニット（ピクチャ）の解像度、アクセスユニットの複数のスライスセグメント（タイル）への分割方法、及び受信装置２００が備える複数の復号部の処理能力の少なくとも一つに基づき、当該スライスセグメントを復号する復号部を決定してもよい。例えば、復号データ生成部２１４は、アクセスユニットの分割方法を、ＭＭＴのメッセージ、又はＴＳのセクションなどのデスクリプタにおける識別情報に基づいて判別する。
次に、復号データ生成部２１４は、複数のパケットのいずれかに含まれる、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報と、複数のスライスセグメントの複数の符号化データの各々とを結合することで、複数の復号部へ入力される複数の入力データ（結合データ）を生成する。具体的には、復号データ生成部２１４は、受信パケットのペイロードからスライスセグメントのデータを取得する。復号データ生成部２１４は、ステップＳ２０４でメモリに格納されたスライスセグメント前データと、取得されたスライスセグメントのデータとを結合することで、ステップＳ２０６で決定された復号部への入力データを生成する（Ｓ２０７）。
ステップＳ２０４又はＳ２０７の後、受信パケットのデータがアクセスユニットの最終データでない場合（Ｓ２０８でＮｏ）、ステップＳ２０１以降の処理が再度行われる。つまり、アクセスユニットに含まれる全てのスライスセグメントに対応する、複数の復号部２０４Ａ〜２０４Ｄへの入力データが生成されるまで、上記処理が繰り返される。
なお、パケットが受信されるタイミングは、図１６に示すタイミングに限らず、予め又は順次複数のパケットが受信され、メモリ等に格納されてもよい。
一方、受信パケットのデータがアクセスユニットの最終データである場合（Ｓ２０８でＹｅｓ）、復号命令部２０６は、ステップＳ２０７で生成された、複数の入力データを、対応する復号部２０４Ａ〜２０４Ｄへ出力する（Ｓ２０９）。
次に、複数の復号部２０４Ａ〜２０４Ｄは、アクセスユニットのＤＴＳに従い、複数の入力データを並列に復号することで、複数の復号画像を生成する（Ｓ２１０）。
最後に、表示部２０５は、複数の復号部２０４Ａ〜２０４Ｄで生成された複数の復号画像を結合することで表示画像を生成し、アクセスユニットのＰＴＳに従い当該表示画像を表示する（Ｓ２１１）。
なお、受信装置２００は、アクセスユニットのＤＴＳ及びＰＴＳを、ＭＰＵのヘッダ情報、又は、Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔのヘッダ情報を格納するＭＭＴパケットのペイロードデータを解析することにより取得する。また、受信装置２００は、多重化方式としてＴＳが使用されている場合にはＰＥＳパケットのヘッダからアクセスユニットのＤＴＳ及びＰＴＳを取得する。受信装置２００は、多重化方式としてＲＴＰが使用されている場合にはＲＴＰパケットのヘッダからアクセスユニットのＤＴＳ及びＰＴＳを取得する。
また、表示部２０５は、複数の復号部の復号結果を統合する際に、隣接する分割単位の境界においてデブロックフィルタなどのフィルタ処理を行ってもよい。なお、単一の復号部の復号結果を表示する場合にはフィルタ処理は不要であるため、表示部２０５は、複数の復号部の復号結果の境界にフィルタ処理を行うかどうかに応じて処理を切替えてもよい。フィルタ処理が必要かどうかは、分割の有無などに応じて予め規定されていてもよい。または、フィルタ処理が必要かどうかを示す情報が、多重化レイヤに別途格納されてもよい。また、フィルタ係数などフィルタ処理に必要な情報は、ＳＰＳ、ＰＰＳ、ＳＥＩ、又はスライスセグメント内に格納される場合がある。復号部２０４Ａ〜２０４Ｄ、又は逆多重化部２０３がＳＥＩを解析することによりこれらの情報を取得し、取得された情報を表示部２０５に出力する。表示部２０５は、これらの情報を用いてフィルタ処理を行う。なお、これらの情報がスライスセグメント内に格納される場合には、復号部２０４Ａ〜２０４Ｄがこれらの情報を取得することが望ましい。
なお、上記説明では、フラグメントに格納されるデータの種類がスライスセグメント前データとスライスセグメントとの２種類である場合の例を示したが、データの種類は３種類以上であってもよい。この場合には、ステップＳ２０３においてタイプに応じた場合分けが行われる。
また、送信装置１００は、スライスセグメントのデータサイズが大きい場合にスライスセグメントをフラグメント化してＭＭＴパケットに格納してもよい。つまり、送信装置１００は、スライスセグメント前データ及びスライスセグメントをフラグメント化してもよい。この場合に、図１１に示したパケット化の例のようにアクセスユニットとＤａｔａ ｕｎｉｔとを等しく設定すると以下の問題が生じる。
例えばスライスセグメント１が３つのフラグメントに分割される場合、スライスセグメント１がＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒ値が１から３の３つのパケットに分割して送信される。また、スライスセグメント２以降では、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒ値が４以上となり、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値とペイロードに格納されるデータとの対応付けが取れなくなる。従って、受信装置２００は、ＭＭＴパケットのヘッダの情報から、スライスセグメントの先頭データを格納するパケットを特定できない。
このような場合には、受信装置２００は、ＭＭＴパケットのペイロードのデータを解析して、スライスセグメントの開始位置を特定してもよい。ここで、Ｈ．２６４又はＨ．２６５においてＮＡＬユニットを多重化レイヤに格納する形式として、ＮＡＬユニットヘッダの直前に特定のビット列からなるスタートコードが付加されるバイトストリームフォーマットと呼ばれる形式と、ＮＡＬユニットのサイズを示すフィールドが付加されるＮＡＬサイズフォーマットと呼ばれる形式との２種類がある。
バイトストリームフォーマットは、ＭＰＥＧ−２システム及びＲＴＰなどにおいて用いられる。ＮＡＬサイズフォーマットは、ＭＰ４、並びにＭＰ４を使用するＤＡＳＨ及びＭＭＴなどにおいて用いられる。
バイトストリームフォーマットが用いられる場合、受信装置２００は、パケットの先頭データがスタートコードと一致するかどうかを解析する。受信装置２００は、パケットの先頭データがスタートコードと一致していれば、その後に続くＮＡＬユニットヘッダからＮＡＬユニットのタイプを取得することで、当該パケットに含まれるデータがスライスセグメントのデータであるかどうかを検出できる。
一方、ＮＡＬサイズフォーマットの場合には、受信装置２００は、ビット列に基づいてＮＡＬユニットの開始位置を検出できない。従って、受信装置２００は、ＮＡＬユニットの開始位置を取得するために、アクセスユニットの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズ分だけデータの読出すことでポインタをシフトさせていく必要がある。
但し、ＭＭＴにおけるＭＰＵ又はＭｏｖｉｅ Ｆｒａｇｍｅｎｔのヘッダにおいて、サブサンプル単位のサイズが示され、サブサンプルがスライス前データ又はスライスセグメントに対応する場合には、受信装置２００は、サブサンプルのサイズ情報に基づいて各ＮＡＬユニットの開始位置を特定できる。そのため、送信装置１００は、サブサンプル単位の情報がＭＰＵ又はＭｏｖｉｅ Ｆｒａｇｍｅｎｔに存在するかどうかを示す情報を、ＭＭＴにおけるＭＰＴなどの、受信装置２００がデータの受信開始時に取得する情報に含めてもよい。
なお、ＭＰＵのデータはＭＰ４フォーマットをベースに拡張したものである。ＭＰ４においては、Ｈ．２６４又はＨ．２６５のＳＰＳ及びＰＰＳなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードとがある。また、このモードを特定するための情報がＳａｍｐｌｅＥｎｔｒｙのエントリ名として示される。格納可能なモードが用いられており、パラメータセットがサンプルに含まれる場合には、受信装置２００は、上述した方法によりパラメータセットを取得する。
一方、格納できないモードが用いられている場合には、パラメータセットは、ＳａｍｐｌｅＥｎｔｒｙ内のＤｅｃｏｄｅｒ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎとして格納される、又は、パラメータセット用のストリームを用いて格納される。ここで、パラメータセット用のストリームは一般的には使用されていないので、送信装置１００は、Ｄｅｃｏｄｅｒ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎにパラメータセットを格納することが望ましい。この場合には、受信装置２００は、ＭＭＴパケットにおいてＭＰＵのメタデータ、又は、Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔのメタデータとしてとして送信されるＳａｍｐｌｅＥｎｔｒｙを解析して、アクセスユニットが参照するパラメータセットを取得する。
パラメータセットがサンプルデータとして格納される場合には、受信装置２００は、ＳａｍｐｌｅＥｎｔｒｙを参照せずにサンプルデータのみを参照すれば復号に必要なパラメータセットが取得できる。このとき、送信装置１００は、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットを格納しなくてもよい。こうすることで、送信装置１００は、異なるＭＰＵにおいて同一のＳａｍｐｌｅＥｎｔｒｙを用いることができるので、ＭＰＵ生成時の送信装置１００の処理負荷を低減できる。さらに、受信装置２００がＳａｍｐｌｅＥｎｔｒｙ内のパラメータセットを参照する必要がなくなるというメリットがある。
または、送信装置１００は、ＳａｍｐｌｅＥｎｔｒｙにデフォルトのパラメータセットを１つ格納し、アクセスユニットが参照するパラメータセットをサンプルデータに格納してもよい。従来のＭＰ４においては、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットを格納するのが一般的であったため、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが存在しない場合、再生を停止する受信装置が存在する可能性がある。上記の方法を用いることで、この問題を解決できる。
または、送信装置１００は、デフォルトのパラメータセットとは異なるパラメータセットが使用される場合にのみ、サンプルデータにパラメータセットを格納してもよい。
なお、両モード共に、パラメータセットをＳａｍｐｌｅＥｎｔｒｙに格納することは可能であるため、送信装置１００は、パラメータセットを常にＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙに格納し、受信装置２００は常にＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙからパラメータセットを取得してもよい。
なお、ＭＭＴ規格においては、Ｍｏｏｖ及びＭｏｏｆなどＭＰ４のヘッダ情報は、ＭＰＵメタデータ、或いはムービーフラグメントメタデータとして伝送されるが、送信装置１００は、ＭＰＵメタデータ、および、ムービーフラグメントメタデータを必ずしも送信しなくてもよい。さらに、受信装置２００は、ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｕｓｉｎｅｓｓｅｓ）規格のサービス、アセットのタイプ、又は、ＭＰＵメタの伝送有無などに基づいて、サンプルデータ内にＳＰＳ及びＰＰＳが格納されるかどうかを判定することも可能である。
図１７は、スライスセグメント前データ及び各スライスセグメントが、それぞれ異なるＤａｔａ ｕｎｉｔに設定される場合の例を示す図である。
図１７に示す例では、スライスセグメント前データ、及びスライスセグメント１からスライスセグメント４までのデータサイズは、それぞれＬｅｎｇｔｈ＃１からＬｅｎｇｔｈ＃５である。ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒ、及び、Ｏｆｆｓｅｔの各フィールド値は図中に示す通りである。
ここで、Ｏｆｆｓｅｔは、ペイロードデータが属するサンプル（アクセスユニット又はピクチャ）の符号化データの先頭から、当該ＭＭＴパケットに含まれるペイロードデータ（符号化データ）の先頭バイトまでのビット長（オフセット）を示すオフセット情報である。なお、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値はフラグメントの総数から１を減算した値から開始するとして説明するが、他の値から開始してもよい。
図１８は、Ｄａｔａ ｕｎｉｔがフラグメント化される場合の例を示す図である。図１８に示す例では、スライスセグメント１が３つのフラグメントに分割され、それぞれＭＭＴパケット＃２からＭＭＴパケット＃４に格納される。このときも、各フラグメントのデータサイズを、それぞれＬｅｎｇｔｈ＃２＿１からＬｅｎｇｔｈ＃２＿３とすると、各フィールドの値は図中に示す通りである。
このように、スライスセグメントなどのデータ単位がＤａｔａ ｕｎｉｔに設定される場合、アクセスユニットの先頭、及びスライスセグメントの先頭は、ＭＭＴパケットヘッダのフィールド値に基づいて以下のように決定できる。
Ｏｆｆｓｅｔの値が０であるパケットにおけるペイロードの先頭は、アクセスユニットの先頭である。
Ｏｆｆｓｅｔの値が０とは異なる値であり、かつ、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｃａｔｏｒｎｏ値が００又は０１であるパケットのペイロードの先頭が、スライスセグメントの先頭である。
また、Ｄａｔａ ｕｎｉｔのフラグメント化が発生せず、パケットロスも発生しない場合には、受信装置２００は、アクセスユニットの先頭を検出した後に取得したスライスセグメントの数に基づいて、ＭＭＴパケットに格納されるスライスセグメントのインデックス番号を特定できる。
また、スライスセグメント前データのＤａｔａ ｕｎｉｔがフラグメント化される場合においても、同様に、受信装置２００は、アクセスユニット、及びスライスセグメントの先頭を検出できる。
また、パケットロスが発生した場合、又は、スライスセグメント前データに含まれるＳＰＳ、ＰＰＳ及びＳＥＩが別々のＤａｔａ ｕｎｉｔに設定された場合においても、受信装置２００は、ＭＭＴヘッダの解析結果に基づいてスライスセグメントの先頭データを格納したＭＭＴパケットを特定し、その後、スライスセグメントのヘッダを解析することで、ピクチャ（アクセスユニット）内におけるスライスセグメント又はタイルの開始位置を特定できる。スライスヘッダの解析に係る処理量は小さく、処理負荷は問題とならない。
このように、複数のスライスセグメントの複数の符号化データの各々は、１以上のパケットに格納されるデータの単位である基本データ単位（Ｄａｔａ ｕｎｉｔ）と一対一で対応付けられている。また、複数の符号化データの各々は、１以上のＭＭＴパケットに格納される。
各ＭＭＴパケットのヘッダ情報は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ（識別情報）及びＯｆｆｓｅｔ（オフセット情報）を含む。
受信装置２００は、受信装置２００は、値が００又は０１であるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。具体的には、値が０でないＯｆｆｓｅｔと、値が００又は０１であるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒとが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。
また、図１７の例では、Ｄａｔａ ｕｎｉｔの先頭は、アクセスユニットの先頭、又は、スライスセグメントの先頭のいずれかであり、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値は００又は０１である。さらに、受信装置２００は、ＮＡＬユニットのタイプを参照して、Ｄａｔａ Ｕｎｉｔの先頭がアクセスユニットデリミタ、又は、スライスセグメントのどちらであるかを判定することで、Ｏｆｆｓｅｔを参照せずに、アクセスユニットの先頭、又は、スライスセグメントの先頭を検出することも可能である。
このように、送信装置１００が、ＮＡＬユニットの先頭が必ずＭＭＴパケットのペイロードの先頭から開始されるようにパケット化を行うことで、スライスセグメント前データが複数のＤａｔａ ｕｎｉｔに分割される場合も含めて、受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ及びＮＡＬユニットヘッダを解析することにより、アクセスユニット、又は、スライスセグメントの先頭を検出できる。ＮＡＬユニットのタイプは、ＮＡＬユニットヘッダの先頭バイトに存在する。従って、受信装置２００は、ＭＭＴパケットのヘッダ部を解析する際に、追加で１バイト分のデータを解析することによりＮＡＬユニットのタイプが取得できる。 オーディオの場合には、受信装置２００は、アクセスユニットの先頭が検出できればよく、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値が００又は０１であるかどうかに基づいて判定すればよい。
また、上述したように、分割復号ができるように符号化された符号化データをＭＰＥＧ−２ ＴＳのＰＥＳパケットに格納する場合には、送信装置１００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を用いることが可能である。以下、符号化データのＰＥＳパケットへの格納方法の例について詳細に説明する。
例えば、ＨＥＶＣにおいては、送信装置１００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を用いることにより、ＰＥＳパケットに格納されるデータがアクセスユニット、スライスセグメント、及び、タイルのいずれであるかを示すことができる。ＨＥＶＣにおけるアラインメントのタイプは、次のように規定されている。
アラインメントのタイプ＝８は、ＨＥＶＣのスライスセグメントを示す。アラインメントのタイプ＝９は、ＨＥＶＣのスライスセグメント又はアクセスユニットを示す。アラインメントのタイプ＝１２は、ＨＥＶＣのスライスセグメント又はタイルを示す。
よって、送信装置１００は、例えば、タイプ９を用いることで、ＰＥＳパケットのデータがスライスセグメント又はスライスセグメント前データのいずれかであることを示すことができる。スライスセグメントではなく、スライスを示すタイプも別途規定されているため、送信装置１００は、スライスセグメントではなくスライスを示すタイプを使用してもよい。
また、ＰＥＳパケットのヘッダに含まれるＤＴＳ及びＰＴＳは、アクセスユニットの先頭データを含むＰＥＳパケットにおいてのみ設定される。従って、受信装置２００は、タイプが９であり、かつ、ＰＥＳパケットにＤＴＳ又はＰＴＳのフィールドが存在すれば、ＰＥＳパケットにはアクセスユニット全体、又は、アクセスユニットにおける先頭の分割単位が格納されると判定できる。
また、送信装置１００は、アクセスユニットの先頭データを含むＰＥＳパケットを格納するＴＳパケットの優先度を示すｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙなどのフィールドを用いて、受信装置２００がパケットに含まれるデータを区別できるようにしてもよい。また、受信装置２００は、ＰＥＳパケットのペイロードがアクセスユニットデリミタであるかどうかを解析することでパケットに含まれるデータを判定してもよい。また、ＰＥＳパケットヘッダのｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒは、これらのタイプに従ってＰＥＳパケットにデータが格納されているかどうかを示す。このフラグ（ｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒ）が１にセットされていれば、ＰＥＳパケットに格納されているデータはｄａｔａ ａｌｉｇｎｍｅｎｔ記述子に示されるタイプに従うことが保証される。
また、送信装置１００は、スライスセグメントなどの分割復号可能な単位でＰＥＳパケット化する場合にのみｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を使用してもよい。これにより、受信装置２００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が存在する場合には、符号化データが分割復号可能な単位でＰＥＳパケット化されていると判断でき、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が存在しなければ、符号化データがアクセスユニット単位でＰＥＳパケット化されていると判断できる。なお、ｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒが１にセットされており、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が存在しない場合には、ＰＥＳパケット化の単位がアクセスユニットであることはＭＰＥＧ−２ ＴＳ規格において規定されている。
受信装置２００は、ＰＭＴ内にｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が含まれていれば、分割復号可能な単位でＰＥＳパケット化されていると判定し、パケット化された単位に基づいて、各復号部への入力データを生成することができる。また、受信装置２００は、ＰＭＴ内にｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が含まれておらず、番組情報、又はその他の記述子の情報に基づいて、符号化データの並列復号が必要と判定される場合には、スライスセグメントのスライスヘッダなどを解析することにより、各復号部への入力データを生成する。また、符号化データを単一の復号部により復号可能である場合には、受信装置２００は、アクセスユニット全体のデータを当該の復号部で復号する。なお、符号化データがスライスセグメント又はタイルなどの分割復号可能な単位から構成されるかどうかを示す情報が、ＰＭＴの記述子などにより別途示されている場合、受信装置２００は、当該記述子の解析結果に基づいて符号化データを並列復号できるかどうかを判定してもよい。
また、ＰＥＳパケットのヘッダに含まれるＤＴＳ及びＰＴＳは、アクセスユニットの先頭データを含むＰＥＳパケットにおいてのみ設定されるため、アクセスユニットが分割されてＰＥＳパケット化される場合には、２番目以降のＰＥＳパケットにはアクセスユニットのＤＴＳ及びＰＴＳを示す情報は含まれない。従って、復号処理を並列に行う場合、各復号部２０４Ａ〜２０４Ｄ及び表示部２０５は、アクセスユニットの先頭データを含むＰＥＳパケットのヘッダに格納されるＤＴＳ及びＰＴＳを使用する。
（実施の形態２）
実施の形態２では、ＭＭＴにおいて、ＮＡＬサイズフォーマットのデータをＭＰ４フォーマットベースのＭＰＵに格納する方法について説明する。なお、以下では、一例として、ＭＭＴに用いられるＭＰＵへの格納方法について説明するが、このような格納方法は、同じＭＰ４フォーマットベースであるＤＡＳＨにも適用可能である。
［ＭＰＵへの格納方法］
ＭＰ４フォーマットでは、複数のアクセスユニットをまとめて、一つのＭＰ４ファイルに格納する。ＭＭＴに用いられるＭＰＵは、メディア毎のデータが一つのＭＰ４ファイルに格納され、データには任意の数のアクセスユニットを含むことができる。ＭＰＵは、単体で復号可能な単位であるため、例えば、ＭＰＵにはＧＯＰ単位のアクセスユニットが格納される。
図１９は、ＭＰＵの構成を示す図である。ＭＰＵの先頭は、ｆｔｙｐ、ｍｍｐｕ、及びｍｏｏｖであり、これらは、まとめてＭＰＵメタデータと定義される。ｍｏｏｖには、ファイルに共通の初期化情報、及びＭＭＴヒントトラックが格納される。
また、ｍｏｏｆには、サンプルやサブサンプル毎の初期化情報及びサイズ、提示時刻（ＰＴＳ）及び復号時刻（ＤＴＳ）を特定できる情報（ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎ、ｓａｍｐｌｅ＿ｓｉｚｅ、ｓａｍｐｌｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｆｆｓｅｔ）、並びにデータの位置を示すｄａｔａ＿ｏｆｆｓｅｔなどが格納される。
また、複数のアクセスユニットは、それぞれサンプルとしてｍｄａｔ（ｍｄａｔ ｂｏｘ）に格納される。ｍｏｏｆ及びｍｄａｔのうちサンプルを除くデータは、ムービーフラグメントメタデータ（以降では、ＭＦメタデータと記載する。）と定義され、ｍｄａｔのサンプルデータは、メディアデータと定義される。
図２０は、ＭＦメタデータの構成を示す図である。図２０に示されるように、ＭＦメタデータは、より詳細には、ｍｏｏｆ ｂｏｘ（ｍｏｏｆ）の、ｔｙｐｅ、ｌｅｎｇｔｈ、及びｄａｔａと、ｍｄａｔ ｂｏｘ（ｍｄａｔ）のｔｙｐｅ及びｌｅｎｇｔｈとからなる。
アクセスユニットをＭＰ４データに格納する際には、Ｈ．２６４やＨ．２６５のＳＰＳ、及び、ＰＰＳなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードがある。
ここで、上記格納できないモードにおいては、パラメータセットは、ｍｏｏｖにおけるＳａｍｐｌｅＥｎｔｒｙのＤｅｃｏｄｅｒ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎに格納される。また、上記格納できるモードにおいては、パラメータセットは、サンプル内に含められる。
ＭＰＵメタデータ、ＭＦメタデータ、及びメディアデータは、それぞれＭＭＴペイロードに格納され、これらのデータを識別可能な識別子として、ＭＭＴペイロードのヘッダには、フラグメントタイプ（ＦＴ）が格納される。ＦＴ＝０は、ＭＰＵメタデータであることを示し、ＦＴ＝１は、ＭＦメタデータであることを示し、ＦＴ＝２はメディアデータであることを示す。
なお、図１９では、ＭＰＵメタデータ単位及びＭＦメタデータ単位がデータユニットとしてＭＭＴペイロードに格納される例が図示されているが、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、及びｍｏｏｆなどの単位がデータユニットとして、データユニット単位でＭＭＴペイロードに格納されてもよい。同様に、図１９では、サンプル単位がデータユニットとしてＭＭＴペイロードに格納される例が図示されている。しかしながら、サンプル単位やＮＡＬユニット単位でデータユニットが構成され、このようなデータユニットがデータユニット単位でＭＭＴペイロードに格納されてもよい。このようなデータユニットがさらにフラグメントされた単位でＭＭＴペイロードに格納されてもよい。
［従来の送信方法と課題］
従来、複数のアクセスユニットをＭＰ４フォーマットにカプセル化する際、ＭＰ４に格納されるサンプルがすべて揃った時点でｍｏｏｖ及びｍｏｏｆが作成されていた。
ＭＰ４フォーマットを放送などを用いてリアルタイムに伝送する場合、例えば１つのＭＰ４ファイルに格納するサンプルがＧＯＰ単位であるとすると、ＧＯＰ単位の時間サンプルが蓄積された後にｍｏｏｖ及びｍｏｏｆが作成されるため、カプセル化に伴う遅延が発生する。このような送信側におけるカプセル化により、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延が常にＧＯＰ単位時間分長くなる。これにより、リアルタイムにサービスの提供を行うことが困難となり、特に、ライブコンテンツが伝送される場合には視聴者に対するサービスの劣化につながる。
図２１は、データの送信順序を説明するための図である。ＭＭＴを放送に適用する場合、図２１の（ａ）に示されるように、ＭＰＵの構成順にＭＭＴパケットに載せて送信（ＭＭＴパケット＃１、＃２、＃３、＃４、＃５、＃６の順に送信）すると、ＭＭＴパケットの送信にはカプセル化による遅延が生じる。
このカプセル化による遅延を防ぐために、図２１の（ｂ）に示されるように、ＭＰＵメタデータ及びＭＦメタデータなどのＭＰＵヘッダ情報を送らない（パケット＃１及び＃２を送信せず、パケット＃３−＃６をこの順に送信する）方法が提案されている。また、図２０の（ｃ）に示されるように、ＭＰＵヘッダ情報の作成を待たずにメディアデータを先に送信し、メディアデータの送信後にＭＰＵヘッダ情報を送信する（＃３−＃６、＃１、＃２の順で送信する）方法が考えられる。
受信装置は、ＭＰＵヘッダ情報が送信されていない場合、ＭＰＵヘッダ情報を用いずに復号する、また、受信装置は、ＭＰＵヘッダ情報がメディアデータに対して後送りされている場合には、ＭＰＵヘッダ情報の取得を待ってから復号する。
しかしながら、従来のＭＰ４準拠の受信装置では、ＭＰＵヘッダ情報を用いずに復号することが保証されていない。また、受信装置が特別な処理によりＭＰＵヘッダを用いずに復号を行う場合に従来の送信方法を用いると復号処理が煩雑となり、実時間の復号が困難となる可能性が高い。また、受信装置がＭＰＵヘッダ情報の取得を待ってから復号を行う場合には、受信装置がヘッダ情報を取得するまでの間メディアデータのバッファリングが必要であるが、バッファモデルが規定されておらず、復号が保証されていなかった。
そこで、実施の形態２に係る送信装置は、図２０の（ｄ）に示されるように、ＭＰＵメタデータに共通の情報のみを格納することで、ＭＰＵメタデータをメディアデータより先に送信する。そして、実施の形態２に係る送信装置は、生成に遅延が発生するＭＦメタデータをメディアデータより後に送信する。これにより、メディアデータの復号を保証できる送信方法或いは受信方法を提供する。
以下、図２１の（ａ）−（ｄ）の各送信方法を用いた場合の受信方法について説明する。
図２１に示される各送信方法では、まず、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順にＭＰＵデータを構成する。
ＭＰＵデータを構成した後、送信装置が図２１の（ａ）に示されるように、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータの順にデータを送信する場合、受信装置は、下記の（Ａ−１）及び（Ａ−２）のいずれかの方法で復号を行うことができる。
（Ａ−１）受信装置は、ＭＰＵヘッダ情報（ＭＰＵメタデータ及びＭＦメタデータ）を取得後、ＭＰＵヘッダ情報を用いてメディアデータを復号する。
（Ａ−２）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
このような方法はいずれも、送信側でカプセル化による遅延が発生するが、受信装置において、ＭＰＵヘッダ取得のためにメディアデータをバッファリングする必要がない利点がある。バッファリングをしない場合、バッファリングのためのメモリの搭載の必要はなく、さらにバッファリング遅延は発生しない。また、（Ａ−１）の方法は、ＭＰＵヘッダ情報を用いて復号を行うため、従来の受信装置にも適用可能ある。
送信装置が図２１の（ｂ）に示されるように、メディアデータのみを送信する場合、受信装置は下記の（Ｂ−１）の方法で復号を行うことができる。
（Ｂ−１）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
また、図示しないが、図２１の（ｂ）のメディアデータの送信よりも先にＭＰＵメタデータが送信されている場合、下記の（Ｂ−２）の方法で復号を行うことができる。
（Ｂ−２）受信装置は、ＭＰＵメタデータを用いてメディアデータを復号する。
上記（Ｂ−１）及び（Ｂ−２）の方法はいずれも、送信側でカプセル化による遅延が発生せず、かつ、ＭＰＵヘッダ取得のためにメディアデータをバッファリングする必要がない点が利点である。しかしながら、（Ｂ−１）及び（Ｂ−２）の方法はいずれも、ＭＰＵヘッダ情報を用いた復号を行わないため、復号に特別な処理が必要となる可能性がある。
送信装置が図２１の（ｃ）に示されるように、メディアデータ、ＭＰＵメタデータ、ＭＦメタデータの順にデータを送信する場合、受信装置は下記の（Ｃ−１）及び（Ｃ−２）のいずれかの方法で復号を行うことができる。
（Ｃ−１）受信装置は、ＭＰＵヘッダ情報（ＭＰＵメタデータ及びＭＦメタデータ）を取得後、メディアデータを復号する。
（Ｃ−２）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
上記（Ｃ−１）の方法が用いられる場合は、ＭＰＵヘッダ情報の取得のためにメディアデータをバッファリングする必要がある。これに対し、上記（Ｃ−２）の方法が用いられる場合は、ＭＰＵヘッダ情報の取得のためのバッファリングを行う必要はない。
また、上記（Ｃ−１）及び（Ｃ−２）のいずれの方法も、送信側においてカプセル化による遅延は発生しない。また、（Ｃ−２）の方法は、ＭＰＵヘッダ情報を用いないため、特別な処理が必要となる可能性がある。
送信装置が、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順にデータを送信する場合、受信装置は、下記の（Ｄ−１）及び（Ｄ−２）のいずれかの方法で復号を行うことができる。
（Ｄ−１）受信装置は、ＭＰＵメタデータを取得後、さらにＭＦメタデータを取得し、その後、メディアデータを復号する。
（Ｄ−２）受信装置は、ＭＰＵメタデータを取得後、ＭＦメタデータを用いずにメディアデータを復号する。
上記（Ｄ−１）の方法が用いられる場合は、ＭＦメタデータ取得のためにメディアデータをバッファリングする必要があるが、上記（Ｄ−２）の方法の場合は、ＭＦメタデータ取得のためのバッファリングを行う必要はない。
上記（Ｄ−２）の方法は、ＭＦメタデータを用いた復号を行わないため、特別な処理が必要となる可能性がある。
以上説明したように、ＭＰＵメタデータ及びＭＦメタデータを用いて復号できる場合は、従来のＭＰ４受信装置でも復号できるというメリットがある。
なお、図２１では、ＭＰＵデータは、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順に構成されており、ｍｏｏｆにおいては、この構成に基づいてサンプルやサブサンプル毎の位置情報（オフセット）が定められている。また、ＭＦメタデータには、ｍｄａｔ ｂｏｘにおけるメディアデータ以外のデータ（ｂｏｘのサイズやタイプ）も含まれている。
このため、受信装置がＭＦメタデータに基づいてメディアデータを特定する場合には、受信装置は、データが送信された順番にかかわらず、ＭＰＵデータを構成した際の順番にデータを再構成した後、ＭＰＵメタデータのｍｏｏｖ或いはＭＦメタデータのｍｏｏｆを用いて復号を行う。
なお、図２１では、ＭＰＵデータは、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順に構成されるが、図２１とは異なる順番でＭＰＵデータが構成され、位置情報（オフセット）が定められてもよい。
例えば、ＭＰＵデータがＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順に構成され、ＭＦメタデータにおいて負の位置情報（オフセット）が示されてもよい。この場合も、データが送信される順番にかかわらず、受信装置は、送信側においてＭＰＵデータが構成された際の順番にデータを再構成した後、ｍｏｏｖ或いはｍｏｏｆを用いて復号を行う。
なお、送信装置は、ＭＰＵデータを構成する際の順番を示す情報をシグナリングし、受信装置は、シグナリングされた情報に基づいてデータを再構成してもよい。
以上説明したように、受信装置は、図２１の（ｄ）に示されるように、パケット化されたＭＰＵメタデータ、パケット化されたメディアデータ（サンプルデータ）、パケット化されたＭＦメタデータをこの順に受信する。ここで、ＭＰＵメタデータは、第１のメタデータの一例であり、ＭＦメタデータは、第２のメタデータの一例である。
次に、受信装置は、受信されたＭＰＵメタデータ、受信されたＭＦメタデータ、及び受信されたサンプルデータを含むＭＰＵデータ（ＭＰ４フォーマットのファイル）を再構成する。そして、再構成されたＭＰＵデータに含まれるサンプルデータを、ＭＰＵメタデータ及びＭＦメタデータを用いて復号する。ＭＦメタデータは、送信側においてサンプルデータの生成後にのみ生成可能なデータ（例えば、ｍｂｏｘに格納されるｌｅｎｇｔｈ）を含むメタデータである。
なお、上記受信装置の動作は、より詳細には、受信装置を構成する各構成要素によって行われる。例えば、受信装置は、上記データの受信を行う受信部と、上記ＭＰＵデータの再構成を行う再構成部と、上記ＭＰＵデータの復号を行う復号部とを備える。なお、受信部、生成部、及び復号部のそれぞれは、マイクロコンピュータ、プロセッサ、専用回路などによって実現される。
［ヘッダ情報を用いずに復号を行う方法］
次に、ヘッダ情報を用いずに復号を行う方法について説明する。ここでは、送信側でヘッダ情報を送るか送らないかにかかわらず、受信装置においてヘッダ情報を用いずに復号する方法を説明する。すなわち、この方法は、図２１を用いて説明したいずれの送信方法を用いた場合においても適用可能である。ただし、一部の復号方法は、特定の送信方法の場合にのみ適用可能な復号方法である。
図２２は、ヘッダ情報を用いずに復号を行う方法の例を示す図である。図２２では、メディアデータのみが含まれるＭＭＴペイロード及びＭＭＴパケットのみが図示されており、ＭＰＵメタデータやＭＦメタデータが含まれるＭＭＴペイロード及びＭＭＴパケットは図示されていない。また、以下の図２２の説明においては、同じＭＰＵに属するメディアデータは連続して伝送されるものとする。また、メディアデータとしてペイロードにサンプルが格納されている場合を例に説明するが、以下の図２２の説明においては、当然ＮＡＬユニットが格納されていてもよいし、フラグメントされたＮＡＬユニットが格納されていてもよい。
メディアデータを復号するためには、受信装置は、まず、復号に必要な初期化情報を取得しなければならない。また、メディアがビデオであれば、受信装置は、サンプル毎の初期化情報を取得したり、ランダムアクセス単位であるＭＰＵの開始位置を特定し、サンプル及びＮＡＬユニットの開始位置を取得しなければならない。また、受信装置は、それぞれサンプルの復号時刻（ＤＴＳ）や提示時刻（ＰＴＳ）を特定する必要がある。
そこで、受信装置は、例えば、下記の方法を用いてヘッダ情報を用いずに復号を行うことができる。なお、ペイロードにＮＡＬユニット単位またはＮＡＬユニットをフラグメントした単位が格納される場合は、下記説明において「サンプル」を、「サンプルにおけるＮＡＬユニット」に読み替えればよい。
＜ランダムアクセス（＝ＭＰＵの先頭サンプルを特定）＞
ヘッダ情報が送信されない場合に、受信装置がＭＰＵの先頭サンプルを特定するには、下記方法１と方法２がある。なお、ヘッダ情報が送信される場合には、方法３を用いることができる。
［方法１］受信装置は、ＭＭＴパケットヘッダにおいて、’ＲＡＰ＿ｆｌａｇ＝１’であるＭＭＴパケットに含まれるサンプルを取得する。
［方法２］受信装置は、ＭＭＴペイロードヘッダにおいて、’ｓａｍｐｌｅ ｎｕｍｂｅｒ＝０’であるサンプルを取得する。
［方法３］受信装置は、メディアデータの前及び後ろの少なくともどちらか一方に、ＭＰＵメタデータ及びＭＦメタデータの少なくともどちらか一方が送信されている場合、受信装置は、ＭＭＴペイロードヘッダにおけるフラグメントタイプ（ＦＴ）がメディアデータへ切り替わったＭＭＴペイロードに含まれるサンプルを取得する。
なお、方法１及び方法２において、１つのペイロードに異なるＭＰＵに属する複数のサンプルが混在する場合、どのＮＡＬユニットがランダムアクセスポイント（ＲＡＰ＿ｆｌａｇ＝１或いはｓａｍｐｌｅ ｎｕｍｂｅｒ＝０）であるか判定不能である。このため、１つのペイロードに異なるＭＰＵのサンプルを混在させないといった制約、または、１つのペイロードに異なるＭＰＵのサンプルが混在する場合は、最後（或いは最初）のサンプルがランダムアクセスポイントである場合に、ＲＡＰ＿ｆｌａｇを１とするといった制約などが必要である。
また、受信装置がＮＡＬユニットの開始位置を取得するためには、サンプルの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズ分だけデータの読出しポインタをシフトさせていく必要がある。
データがフラグメントされている場合は、受信装置は、ｆｒａｇｍｅｎｔ＿ｉｎｄｉｃａｔｏｒやｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒを参照することで、データユニットを特定できる。
＜サンプルのＤＴＳの決定＞
サンプルのＤＴＳの決定方法には、下記方法１と方法２がある。
［方法１］受信装置は、予測構造に基づいて先頭サンプルのＤＴＳを決定する。ただし、この方法には符号化データの解析が必要であり、実時間での復号が困難である可能性があるため、次の方法２が望ましい。
［方法２］受信装置は、先頭サンプルのＤＴＳを別途送信し、送信された先頭サンプルのＤＴＳを取得する。先頭サンプルのＤＴＳの送信方法は、例えば、ＭＰＵ先頭サンプルのＤＴＳを、ＭＭＴ−ＳＩを用いて送信する方法や、サンプル毎のＤＴＳをＭＭＴパケットヘッダ拡張領域を用いて送信する方法などがある。なお、ＤＴＳは、絶対値でもよいし、ＰＴＳに対する相対値であってもよい。また、送信側において先頭サンプルのＤＴＳが含まれているかどうかをシグナリングしてもよい。
なお、方法１、方法２ともに、以降のサンプルのＤＴＳは、固定フレームレートであるとして算出する。
サンプル毎のＤＴＳをパケットヘッダに格納する方法として、拡張領域を用いる以外に、ＭＭＴパケットヘッダにおける３２ｂｉｔのＮＴＰタイムスタンプフィールドに、当該ＭＭＴパケットに含まれるサンプルのＤＴＳを格納する方法がある。１つのパケットヘッダのビット数（３２ｂｉｔ）でＤＴＳを表現できない場合は、ＤＴＳは、複数のパケットヘッダを用いて表現されてもよい。また、ＤＴＳは、パケットヘッダのＮＴＰタイムスタンプフィールドと拡張領域とを組み合わせて表現されてもよい。ＤＴＳ情報が含まれない場合は既知の値（例えばＡＬＬ０）とされる。
＜サンプルのＰＴＳの決定＞
受信装置は、先頭サンプルのＰＴＳを、ＭＰＵに含まれるアセット毎のＭＰＵタイムスタンプ記述子から取得する。受信装置は、以降のサンプルＰＴＳについては、固定フレームレートであるものとして、ＰＯＣ等のサンプルの表示順を示すパラメータなどから算出する。このように、ヘッダ情報を用いずにＤＴＳ、及びＰＴＳを算出するためには、固定フレームレートによる送信が必須となる。
また、ＭＦメタデータが送信されている場合、受信装置は、ＭＦメタデータに示される先頭サンプルからのＤＴＳやＰＴＳの相対時刻情報と、ＭＰＵタイムスタンプ記述子に示されるＭＰＵ先頭サンプルのタイムスタンプの絶対値とからＤＴＳ及びＰＴＳの絶対値を算出できる。
なお、符号化データ解析してＤＴＳ及びＰＴＳを算出する際には、受信装置は、アクセスユニットに含まれるＳＥＩ情報を用いて算出してもよい。
＜初期化情報（パラメータセット）＞
［ビデオの場合］
ビデオの場合、パラメータセットは、サンプルデータに格納される。また、ＭＰＵメタデータ及びＭＦメタデータが送信されない場合は、サンプルデータのみを参照することにより復号に必要なパラメータセットを取得できることを保証する。
また、図２１の（ａ）及び（ｄ）のように、ＭＰＵメタデータがメディアデータよりも先に送信される場合、ＳａｍｐｌｅＥｎｔｒｙにはパラメータセットは格納しないと規定されてもよい。この場合、受信装置は、ＳａｍｐｌｅＥｎｔｒｙのパラメータセットは参照せずにサンプル内のパラメータセットのみを参照する。
また、ＭＰＵメタデータがメディアデータよりも先に送信される場合、ＳａｍｐｌｅＥｎｔｒｙにはＭＰＵに共通のパラメータセットやデフォルトのパラメータセットが格納され、受信装置は、ＳａｍｐｌｅＥｎｔｒｙのパラメータセット及びサンプル内のパラメータセットを参照してもよい。ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが格納されることにより、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが存在しないと再生できない従来の受信装置でも復号を行うことが可能となる。
［オーディオの場合］
オーディオの場合、復号にはＬＡＴＭヘッダが必要であり、ＭＰ４では、ＬＡＴＭヘッダがサンプルエントリに含められることが必須である。しかし、ヘッダ情報が送信されない場合は、受信装置がＬＡＴＭヘッダを取得することは困難であるため、別途ＳＩなどの制御情報にＬＡＴＭヘッダが含められる。なお、ＬＡＴＭヘッダは、メッセージ、テーブル、または記述子に含められてもよい。なお、ＬＡＴＭヘッダはサンプル内に含められることもある。
受信装置は、復号開始前にＳＩなどからＬＡＴＭヘッダを取得し、オーディオの復号を開始する。或いは、図２１の（ａ）及び図２１の（ｄ）に示されるように、ＭＰＵメタデータがメディアデータよりも先に送信される場合は、受信装置は、ＬＡＴＭヘッダをメディアデータより先に受信可能である。したがって、ＭＰＵメタデータがメディアデータよりも先に送信される場合は、従来の受信装置を用いても復号を行うことが可能となる。
＜その他＞
送信順序や送信順序のタイプは、ＭＭＴパケットヘッダやペイロードヘッダ、或いは、ＭＰＴやその他のテーブル、メッセージ、記述子などの制御情報として通知されてもよい。なお、ここでの送信順序のタイプとは、例えば、図２１の（ａ）〜（ｄ）の４つのタイプの送信順序であり、それぞれのタイプを識別するための識別子が復号開始前に取得できる場所に格納されればよい。
また、送信順序のタイプは、オーディオとビデオとで異なるタイプが用いられてもよいし、オーディオとビデオとで共通のタイプが用いられてもよい。具体的には、例えば、オーディオは、図２１の（ａ）に示されるように、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータの順番で送信され、ビデオは、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順番で送信されてもよい。
以上説明したような方法により、受信装置は、ヘッダ情報を用いずに復号を行うことが可能である。また、ＭＰＵメタデータがメディアデータよりも先に送信されている場合（図２１の（ａ）及び図２１の（ｄ））は、従来の受信装置でも復号を行うことが可能になる。
特に、ＭＦメタデータがメディアデータより後に送信されること（図２１の（ｄ））により、カプセル化による遅延を発生させず、かつ従来の受信装置でも復号を行うことが可能となる。
［送信装置の構成及び動作］
次に、送信装置の構成及び動作について説明する。図２３は、実施の形態２に係る送信装置のブロック図であり、図２４は、実施の形態２に係る送信方法のフローチャートである。
図２３に示されるように、送信装置１５は、符号化部１６と、多重化部１７と、送信部１８とを備える。
符号化部１６は、符号化対象のビデオまたはオーディオを、例えば、Ｈ．２６５に従い符号化することで符号化データを生成する（Ｓ１０）。
多重化部１７は、符号化部１６により生成された符号化データを多重化（パケット化）する（Ｓ１１）。具体的には、多重化部１７は、ＭＰ４フォーマットのファイルを構成する、サンプルデータ、ＭＰＵメタデータ、及び、ＭＦメタデータ、のそれぞれをパケット化する。サンプルデータは、映像信号または音声信号が符号化されたデータであり、ＭＰＵメタデータは、第１のメタデータの一例であり、ＭＦメタデータは、第２のメタデータの一例である。第１のメタデータと第２のメタデータとは、いずれもサンプルデータの復号に用いられるメタデータであるが、これらの違いは、第２のメタデータがサンプルデータの生成後にのみ生成可能なデータを含むことである。
ここで、サンプルデータの生成後にのみ生成可能なデータは、例えば、ＭＰ４フォーマットにおけるｍｄａｔに格納されるサンプルデータ以外のデータ（ｍｄａｔのヘッダ内のデータ。つまり、図２０に図示されるｔｙｐｅ及びｌｅｎｇｔｈ。）である。ここで、第２のメタデータには、このデータのうち少なくとも一部であるｌｅｎｇｔｈが含まれればよい。
送信部１８は、パケット化したＭＰ４フォーマットのファイルを送信する（Ｓ１２）。送信部１８は、例えば、図２１の（ｄ）に示される方法でＭＰ４フォーマットのファイルを送信する。つまり、パケット化されたＭＰＵメタデータ、パケット化されたサンプルデータ、パケット化されたＭＦメタデータをこの順に送信する。
なお、符号化部１６、多重化部１７、及び送信部１８のそれぞれは、マイクロコンピュータ、プロセッサ、または専用回路などによって実現される。
［受信装置の構成］
次に、受信装置の構成及び動作について説明する。図２５は、実施の形態２に係る受信装置のブロック図である。
図２５に示されるように、受信装置２０は、パケットフィルタリング部２１と、送信順序タイプ判別部２２と、ランダムアクセス部２３と、制御情報取得部２４と、データ取得部２５と、ＰＴＳ、ＤＴＳ算出部２６と、初期化情報取得部２７と、復号命令部２８と、復号部２９と、提示部３０とを備える。
［受信装置の動作１］
まず、メディアがビデオである場合に、受信装置２０が、ＭＰＵ先頭位置及びＮＡＬユニット位置を特定するための動作について説明する。図２６は、受信装置２０のこのような動作のフローチャートである。なお、ここでは、ＭＰＵデータの送信順序タイプは、送信装置１５（多重化部１７）によってＳＩ情報に格納されているとする。
まず、パケットフィルタリング部２１は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部２２は、パケットフィルタリングによって得られるＳＩ情報を解析して、ＭＰＵデータの送信順序タイプを取得する（Ｓ２１）。
次に、送信順序タイプ判別部２２は、パケットフィルタリング後のデータにＭＰＵヘッダ情報（ＭＰＵメタデータ或いはＭＦメタデータの少なくとも一方）が含まれているか否かを判定（判別）する（Ｓ２２）。ＭＰＵヘッダ情報（が含まれている場合（Ｓ２２でＹｅｓ）には、ランダムアクセス部２３は、ＭＭＴペイロードヘッダのフラグメントタイプがメディアデータへ切り替わることを検出することで、ＭＰＵ先頭サンプルを特定する（Ｓ２３）。
一方、ＭＰＵヘッダ情報が含まれていない場合（Ｓ２２でＮｏ）には、ランダムアクセス部２３は、ＭＭＴパケットヘッダのＲＡＰ＿ｆｌａｇ或いはＭＭＴペイロードヘッダのｓａｍｐｌｅ ｎｕｍｂｅｒに基づいてＭＰＵ先頭サンプルを特定する（Ｓ２４）。
また、送信順序タイプ判別部２２は、パケットフィルタリングされたデータに、ＭＦメタデータが含まれているか否かを判定する（Ｓ２５）。ＭＦメタデータが含まれていると判定された場合（Ｓ２５でＹｅｓ）には、データ取得部２５は、ＭＦメタデータに含まれるサンプル、サブサンプルのオフセット、及びサイズ情報に基づいてＮＡＬユニットを読み出すことによりＮＡＬユニットを取得する（Ｓ２６）。一方、ＭＦメタデータが含まれていないと判定された場合（Ｓ２５でＮｏ）には、データ取得部２５は、サンプルの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズのデータを読み出すことでＮＡＬユニットを取得する（Ｓ２７）。
なお、受信装置２０は、ステップＳ２２において、ＭＰＵヘッダ情報が含まれていると判別された場合でも、ステップＳ２３ではなくステップＳ２４の処理を用いてＭＰＵ先頭サンプルを特定してもよい。また、ＭＰＵヘッダ情報が含まれていると判別された場合に、ステップＳ２３の処理とステップＳ２４の処理とが併用されてもよい。
また、受信装置２０は、ステップＳ２５において、ＭＦメタデータが含まれていると判定された場合でも、ステップＳ２６の処理を用いずにステップＳ２７の処理を用いてＮＡＬユニットを取得してもよい。また、ＭＦメタデータが含まれていると判定された場合に、ステップＳ２３の処理とステップＳ２４の処理とが併用されてもよい。
また、ステップＳ２５においてＭＦメタデータが含まれていると判定された場合であって、ＭＦデータがメディアデータより後に送信されている場合が想定される。この場合、受信装置２０は、メディアデータをバッファリングし、ＭＦメタデータを取得するまで待ってからステップＳ２６の処理を行ってもよいし、受信装置２０は、ＭＦメタデータの取得を待たずにステップＳ２７の処理を行うか否かを判定してもよい。
例えば、受信装置２０は、メディアデータをバッファリングすることが可能なバッファサイズのバッファを保有しているかどうかに基づいてＭＦメタデータの取得を待つか否かを判定してもよい。また、受信装置２０は、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延が小さくなるかどうかに基づいて、ＭＦメタデータの取得を待つか否かを判定してもよい。また、受信装置２０は、主としてステップＳ２６の処理を用いて復号処理を実施し、パケットロスなどが発生したときの処理モードの場合にステップＳ２７の処理を用いてもよい。
なお、送信順序タイプがあらかじめ定められている場合は、ステップＳ２２及びステップＳ２６は省略されてもよいし、この場合、受信装置２０は、バッファサイズやＥｎｄ−ｔｏ−Ｅｎｄ遅延を考慮して、ＭＰＵ先頭サンプルの特定方法、及び、ＮＡＬユニットの特定方法を決定してもよい。
なお、あらかじめ送信順序タイプが既知である場合は、受信装置２０において送信順序タイプ判別部２２は、不要である。
また、上記図２６においては説明されないが、復号命令部２８は、ＰＴＳ、ＤＴＳ算出部２６において算出されたＰＴＳ及びＤＴＳ、初期化情報取得部２７において取得された初期化情報に基づいて、データ取得部において取得されたデータを復号部２９に出力する。復号部２９は、データを復号し、提示部３０は、復号後のデータを提示する。
［受信装置の動作２］
次に、受信装置２０が、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作について説明する。図２７は、このような動作のフローチャートである。
まず、パケットフィルタリング部２１は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部２２は、パケットフィルタリングによって得られるＳＩ情報を解析し、送信順序タイプを取得する（Ｓ３０１）。
次に、送信順序タイプ判別部２２は、ＭＰＵメタデータが送信されているか否かを判定する（Ｓ３０２）。ＭＰＵメタデータが送信されていると判定された場合（Ｓ３０２でＹｅｓ）、送信順序タイプ判別部２２は、ステップＳ３０１の解析の結果、ＭＰＵメタデータがメディアデータより先に送信されているかどうかを判定する（Ｓ３０３）。ＭＰＵメタデータがメディアデータより先に送信されている場合（Ｓ３０３でＹｅｓ）、初期化情報取得部２７は、ＭＰＵメタデータに含まれる共通な初期化情報、及び、サンプルデータの初期化情報に基づいてメディアデータを復号する（Ｓ３０４）。
一方、ＭＰＵメタデータがメディアデータより後に送信されていると判定された場合（Ｓ３０３でＮｏ）には、データ取得部２５は、ＭＰＵメタデータが取得されるまでメディアデータをバッファリングし（Ｓ３０５）、ＭＰＵメタデータが取得された後にステップＳ３０４の処理を実施する。
また、ステップＳ３０２において、ＭＰＵメタデータが送信されていないと判定された場合（Ｓ３０２でＮｏ）には、初期化情報取得部２７は、サンプルデータの初期化情報のみに基づいてメディアデータを復号する（Ｓ３０６）。
なお、送信側においてサンプルデータの初期化情報に基づく場合のみメディアデータの復号が保証されている場合は、ステップＳ３０２、及びステップＳ３０３の判定に基づく処理を行わず、ステップＳ３０６の処理が用いられる。
また、受信装置２０は、ステップＳ３０５の前に、メディアデータをバッファリングするか否かの判定を行ってもよい。この場合、受信装置２０は、メディアデータをバッファリングすると判定した場合にはステップＳ３０５の処理へ移行し、メディアデータをバッファリングしないと判定した場合には、ステップＳ３０６の処理へ移行する。メディアデータをバッファリングするか否かの判定は、受信装置２０のバッファサイズ、占有量に基づいて行われてもよいし、例えば、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延の小さい方が選択されるなど、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を考慮して判定が行われてもよい。
［受信装置の動作３］
ここでは、ＭＦメタデータがメディアデータよりも後に送信される場合（図２１の（ｃ）、及び図２１の（ｄ））における送信方法や受信方法の詳細について説明する。以下では、図２１の（ｄ）の場合を例に説明する。なお、送信においては、図２１の（ｄ）の方法のみが用いられ、送信順序タイプのシグナリングは行われないものとする。
先述のとおり、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順でデータを送信する場合、
（Ｄ−１）受信装置２０は、ＭＰＵメタデータを取得した後、さらにＭＦメタデータを取得した後にメディアデータを復号する。
（Ｄ−２）受信装置２０は、ＭＰＵメタデータを取得した後、ＭＦメタデータを用いずにメディアデータを復号する。
の２通りの復号方法が可能である。
ここで、Ｄ−１は、ＭＦメタデータ取得のためのメディアデータのバッファリングが必要となるが、ＭＰＵヘッダ情報を用いて復号を行うことができるため、従来のＭＰ４準拠の受信装置で復号可能となる。また、Ｄ−２は、ＭＦメタデータ取得のためのメディアデータのバッファリングを必要としないが、ＭＦメタデータを用いて復号できないため、復号に特別な処理が必要となる。
また、図２１の（ｄ）の方法は、ＭＦメタデータは、メディアデータより後で送信されるため、カプセル化による遅延は発生せず、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を低減できるという利点を有する。
受信装置２０は、受信装置２０の能力や、受信装置２０が提供するサービス品質に応じて、上記２通りの復号方法を選択することができる。
送信装置１５は、受信装置２０における復号動作において、バッファのオーバーフローやアンダーフローの発生を低減して復号できることを保証しなければならない。Ｄ−１の方法を用いて復号する場合のデコーダモデルを規定するための要素としては、例えば下記のパラメータを用いることができる。
・ＭＰＵを再構成するためのバッファサイズ（ＭＰＵバッファ）
例えば、バッファサイズ＝最大レート×最大ＭＰＵ時間×αであり、最大レートとは、符号化データのプロファイル、レベルの上限レート＋ＭＰＵヘッダのオーバーヘッドである。また、最大ＭＰＵ時間は、１ＭＰＵ＝１ＧＯＰ（ビデオ）とした場合のＧＯＰの最大時間長である。
ここで、オーディオは、上記ビデオに共通のＧＯＰ単位としてもよいし、別の単位でもよい。αは、オーバーフローを起こさないためのマージンであり、最大レート×最大ＭＰＵ時間に対して、乗算されてもよいし、加算されてもよい。乗算される場合は、α≧１であり、加算される場合は、α≧０である。
・ＭＰＵバッファへデータが入力されてから復号されるまでの復号遅延時間の上限。（ＭＰＥＧ−ＴＳのＳＴＤにおけるＴＳＴＤ＿ｄｅｌａｙ）
例えば、送信時には、最大ＭＰＵ時間、及び、復号遅延時間の上限値を考慮して、受信機におけるＭＰＵデータの取得完了時刻＜＝ＤＴＳとなるようにＤＴＳが設定される。
また、送信装置１５は、Ｄ−１の方法を用いて復号する場合のデコーダモデルに従い、ＤＴＳ及びＰＴＳを付与してもよい。これにより、送信装置１５は、Ｄ−１の方法を用いて復号を行う受信装置の当該復号を保証すると同時に、Ｄ−２の方法を用いて復号が行われる場合に必要な補助情報を送信してもよい。
例えば、送信装置１５は、Ｄ−２の方法を用いて復号する場合のデコーダバッファにおけるプリバッファリング時間をシグナリングすることにより、Ｄ−２の方法を用いて復号する受信装置の動作を保証できる。
プリバッファリング時間は、メッセージ、テーブル、記述子などのＳＩ制御情報に含められてもよいし、ＭＭＴパケット、ＭＭＴペイロードのヘッダに含められてもよい。また、符号化データ内のＳＥＩが上書きされてもよい。Ｄ−１の方法を用いて復号するためのＤＴＳ及びＰＴＳは、ＭＰＵタイムスタンプ記述子、ＳａｍｐｌｌｅＥｎｔｒｙに格納され、Ｄ−２の方法を用いて復号するためのＤＴＳ及びＰＴＳ、またはプリバッファリング時間がＳＥＩにおいて記述されてもよい。
受信装置２０は、当該受信装置２０がＭＰＵヘッダを用いたＭＰ４準拠の復号動作のみに対応している場合は、復号方法Ｄ−１を選択し、Ｄ−１およびＤ−２の両方に対応している場合は、どちらか一方を選択してもよい。
送信装置１５は、一方（本説明では、Ｄ−１）の復号動作を保証できるようにＤＴＳ、及びＰＴＳを付与し、さらに一方の復号動作を補助するための補助情報を送信してもよい。
また、Ｄ−２の方法が用いられる場合、Ｄ−１の方法が用いられる場合と比較して、ＭＦメタデータのプリバッファリングに起因する遅延により、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延が大きくなる可能性が高い。したがって、受信装置２０は、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を小さくしたいときは、Ｄ−２の方法を選択して復号してもよい。例えば、受信装置２０は、常にＥｎｄ−ｔｏ−Ｅｎｄ遅延を削減したい場合に、常にＤ−２の方法を用いてもよい。また、受信装置２０は、ライブコンテンツや、選局、ザッピング動作など、低遅延で提示したい、低遅延提示モードで動作している場合のみＤ−２の方法を用いてもよい。
図２８は、このような受信方法のフローチャートである。
まず、受信装置２０は、ＭＭＴパケットを受信し、ＭＰＵデータを取得する（Ｓ４０１）。そして、受信装置２０（送信順序タイプ判別部２２）は、当該プログラムを低遅延提示モードで提示するかどうかの判定を行う（Ｓ４０２）。
プログラムを低遅延提示モードで提示しない場合（Ｓ４０２でＮｏ）、受信装置２０（ランダムアクセス部２３及び初期化情報取得部２７）は、ヘッダ情報を用いてランダムアクセス、初期化情報を取得する（Ｓ４０５）。また、受信装置２０（ＰＴＳ、ＤＴＳ算出部２６、復号命令部２８、復号部２９、提示部３０）は、送信側で付与されたＰＴＳ、ＤＴＳに基づいてデコード及び提示処理を行う（Ｓ４０６）。
一方、プログラムを低遅延提示モードで提示する場合（Ｓ４０２でＹｅｓ）、受信装置２０（ランダムアクセス部２３及び初期化情報取得部２７）は、ヘッダ情報を用いない復号方法を用いて、ランダムアクセス、初期化情報を取得する（Ｓ４０３）。また、受信装置２０は、送信側で付与されたＰＴＳ、ＤＴＳ及びヘッダ情報を用いずに復号するための補助情報に基づいてデコード及び提示処理を行う（Ｓ４０４）。なお、ステップＳ４０３、及びステップＳ４０４において、ＭＰＵメタデータを用いて処理が行われてもよい。
［補助データを用いた送受信方法］
以上、ＭＦメタデータがメディアデータより後に送信される場合（図２１の（ｃ）、及び図２１の（ｄ）の場合）における送受信動作について説明した。次に、送信装置１５がＭＦメタデータの一部の機能を有する補助データを送信することにより、より早く復号を開始でき、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を削減できる方法について説明する。ここでは、図２１の（ｄ）に示される送信方法に基づいて補助データがさらに送信される例について説明されるが、補助データを用いる方法は、図２１の（ａ）〜（ｃ）に示される送信方法においても適用可能である。
図２９の（ａ）は、図２１の（ｄ）に示される方法を用いて送信されたＭＭＴパケットを示す図である。つまり、データは、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順で送信される。
ここで、サンプル＃１、サンプル＃２、サンプル＃３、サンプル＃４はメディアデータに含まれるサンプルである。なお、ここではメディアデータは、サンプル単位でＭＭＴパケットに格納される例について説明されるが、メディアデータは、ＮＡＬユニット単位でＭＭＴパケットに格納されてもよいし、ＮＡＬユニットを分割した単位で格納されてもよい。なお、複数のＮＡＬユニットがアグリゲーションされてＭＭＴパケットに格納される場合もある。
先述のＤ−１で説明したように、図２１の（ｄ）に示される方法の場合、つまり、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順でデータが送信される場合、ＭＰＵメタデータを取得後、さらにＭＦメタデータを取得し、その後、メディアデータを復号する方法がある。このようなＤ−１の方法では、ＭＦメタデータ取得のためのメディアデータのバッファリングが必要となるが、ＭＰＵヘッダ情報を用いて復号が行われるため、従来のＭＰ４準拠の受信装置にもＤ−１の方法は適用可能である利点がある。一方で、受信装置２０は、ＭＦメタデータ取得まで、復号開始を待たなければならない欠点がある。
これに対し、図２９の（ｂ）に示されるように、補助データを用いる手法においては、ＭＦメタデータより先に、補助データが送信される。
ＭＦメタデータには、ムービーフラグメントに含まれる全てのサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれている。これに対し、補助データには、ムービーフラグメントに含まれるサンプルのうち、一部のサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれる。
例えば、ＭＦメタデータには、すべてのサンプル（サンプル＃１−サンプル＃４）の情報が含まれるのに対し、補助データには一部のサンプル（サンプル＃１−＃２）の情報が含まれる。
図２９の（ｂ）に示される場合は、補助データが用いられることでサンプル＃１、及びサンプル＃２の復号が可能となるため、Ｄ−１の送信方法に対して、Ｅｎｄ−ｔｏ−Ｅｎｔ遅延が小さくなる。なお、補助データには、どのようにサンプルの情報が組み合わされて含められてもよいし、補助データは、繰り返し送信されてもよい。
例えば、図２９の（ｃ）において、Ａのタイミングで補助情報を送信する場合は、送信装置１５は、補助情報にサンプル＃１の情報を含め、Ｂのタイミングで補助情報を送信する場合は、補助情報にサンプル＃１及びサンプル＃２の情報を含める。送信装置１５は、Ｃのタイミングで補助情報を送信する場合は、補助情報にはサンプル＃１、サンプル＃２、及びサンプル＃３の情報を含める。
なお、ＭＦメタデータには、サンプル＃１、サンプル＃２、サンプル＃３、及び、サンプル＃４の情報（ムービーフラグメントの中の全サンプルの情報）が含まれる。
補助データは、必ずしも生成後、ただちに送信される必要はない。
なお、ＭＭＴパケットやＭＭＴペイロードのヘッダにおいては、補助データが格納されていることを示すタイプが指定される。
例えば、補助データがＭＭＴペイロードにＭＰＵモードを用いて格納される場合は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅフィールド値（例えば、ＦＴ＝３）として、補助データであることを示すデータタイプが指定される。補助データは、ｍｏｏｆの構成に基づくデータであってもよいし、その他の構成であってもよい。
補助データが、ＭＭＴペイロードに制御信号（記述子、テーブル、メッセージ）として格納される場合は、補助データであることを示す記述子タグ、テーブルＩＤ、及びメッセージＩＤなどが指定される。
また、ＭＭＴパケットやＭＭＴペイロードのヘッダにＰＴＳまたはＤＴＳが格納されてもよい。
［補助データの生成例］
以下、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例について説明する。図３０は、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例を説明するための図である。
通常のＭＰ４では、図２０に示されるように、ムービーフラグメントに対してｍｏｏｆが作成される。ｍｏｏｆには、ムービーフラグメントに含まれるサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれている。
ここでは、送信装置１５は、ＭＰＵを構成するサンプルデータの中で、一部のサンプルデータのみを用いてＭＰ４（ＭＰ４ファイル）を構成し、補助データを生成する。
例えば、図３０の（ａ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、サンプル＃１のみを用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを補助データとする。
次に、図３０の（ｂ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、サンプル＃１及びサンプル＃２を用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを次の補助データとする。
次に、図３０の（ｃ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、サンプル＃１、サンプル＃２、及びサンプル＃３を用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを次の補助データとする。
次に、図３０の（ｄ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１−＃４のうち、すべてのＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダがムービーフラグメントメタデータとなる。
なお、ここでは、送信装置１５は、１サンプル毎に補助データを生成したが、Ｎサンプル毎に補助データを生成してもよい。Ｎの値は任意の数字であり、例えば、一つのＭＰＵを送信するときに補助データをＭ回送信する場合、Ｎ＝全サンプル／Ｍとされてもよい。
なお、ｍｏｏｆにおけるサンプルのオフセットを示す情報は、後続のサンプル数のサンプルエントリ領域がＮＵＬＬ領域として確保された後のオフセット値であってもよい。
なお、ＭＦメタデータをフラグメントする構成となるように補助データが生成されてもよい。
［補助データを用いた受信動作例］
図３０で説明したように生成された補助データの受信について説明する。図３１は、補助データの受信を説明するための図である。なお、図３１の（ａ）では、ＭＰＵを構成するサンプル数は３０であり、１０サンプル毎に補助データが生成され、送信されるものとする。
図３０の（ａ）において、補助データ＃１には、サンプル＃１−＃１０、補助データ＃２には、サンプル＃１−＃２０、ＭＦメタデータには、サンプル＃１−＃３０のサンプル情報がそれぞれ含まれる。
なお、サンプル＃１−＃１０、サンプル＃１１−＃２０、及びサンプル＃２１−＃３０は、一つのＭＭＴペイロードに格納されているが、サンプル単位やＮＡＬ単位で格納されてもよいし、フラグメントやアグリゲーションした単位で格納されてもよい。
受信装置２０は、ＭＰＵメタ、サンプル、ＭＦメタ、及び補助データのパケットをそれぞれ受信する。
受信装置２０は、サンプルデータを受信順に（後ろに）連結し、最新の補助データを受信した後に、これまでの補助データを更新する。また、受信装置２０は、最後に補助データをＭＦメタデータに置き換えることにより、完全なＭＰＵを構成できる。
受信装置２０は、補助データ＃１を受信した時点では、図３１の（ｂ）の上段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及び補助データ＃１の情報を用いてサンプル＃１−＃１０をパースすることができ、補助データに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
また、受信装置２０は、補助データ＃２を受信した時点では、図３１の（ｂ）の中段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及び補助データ＃２の情報を用いてサンプル＃１−＃２０をパースすることができ、補助データに含まれるＰＴＳ、ＤＴＳ、オフセット、サイズの情報に基づいて復号を行うことができる。
また、受信装置２０は、ＭＦメタデータを受信した時点では、図３１の（ｂ）の下段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタデータを用いてサンプル＃１−＃３０をパースすることができ、ＭＦメタデータに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
補助データが無い場合は、受信装置２０は、ＭＦメタデータの受信後にはじめてサンプルの情報を取得できるため、ＭＦメタデータの受信後に復号を開始する必要があった。しかしながら、送信装置１５が補助データを生成し、送信することにより、受信装置２０は、ＭＦメタデータの受信を待たずに、補助データを用いてサンプルの情報を取得できるため、復号開始時間を早めることができる。さらに、送信装置１５が図３０を用いて説明したｍｏｏｆに基づく補助データを生成することにより、受信装置２０は、従来のＭＰ４のパーサーをそのまま利用し、パースすることが可能である。
また、新たに生成する補助データやＭＦメタデータは、過去に送信した補助データと重複するサンプルの情報を含む。このため、パケットロスなどにより過去の補助データを取得できなかった場合でも、新たに取得する補助データやＭＦメタデータを用いることで、ＭＰ４を再構成し、サンプルの情報（ＰＴＳ、ＤＴＳ、サイズ、及びオフセット）を取得することが可能である。
なお、補助データは、必ずしも過去のサンプルデータの情報を含む必要はない。たとえば、補助データ＃１は、サンプルデータ＃１−＃１０に対応し、補助データ＃２は、サンプルデータ＃１１−＃２０に対応してもよい。例えば、図３１の（ｃ）に示されるように、送信装置１５は、完全なＭＦメタデータをデータユニットとして、データユニットをフラグメントした単位を補助データとして順次送出してもよい。
また、送信装置１５は、パケットロス対策のために、補助データを繰り返し伝送してもよいし、ＭＦメタデータを繰り返し伝送してもよい。
なお、補助データが格納されるＭＭＴパケット及びＭＭＴペイロードには、ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータと同様に、ＭＰＵシーケンス番号、及びアセットＩＤが含まれる。
以上のような補助データを用いた受信動作について図３２のフローチャートを用いて説明する。図３２は、補助データを用いた受信動作のフローチャートである。
まず、受信装置２０は、ＭＭＴパケットを受信し、パケットヘッダやペイロードヘッダを解析する（Ｓ５０１）。次に、受信装置２０は、フラグメントタイプが補助データか、ＭＦメタデータかを解析し（Ｓ５０２）、フラグメントタイプが補助データである場合には、過去の補助データを上書きして更新する（Ｓ５０３）。このとき、同一ＭＰＵの過去の補助データがない場合には、受信装置２０は、受信した補助データをそのまま新規の補助データとする。そして、受信装置２０は、ＭＰＵメタデータ、補助データ、及びサンプルデータに基づき、サンプルを取得し、復号を行う（Ｓ５０７）。
一方、フラグメントタイプがＭＦメタデータである場合には、受信装置２０は、ステップＳ５０５において、過去の補助データをＭＦメタデータで上書きする（Ｓ５０５）。そして、受信装置２０は、ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータに基づきサンプルを完全なＭＰＵの形で取得し、復号を行う（Ｓ５０６）。
なお、図３２において図示されないが、ステップＳ５０２において、受信装置２０は、フラグメントタイプがＭＰＵメタデータである場合には、データをバッファに格納し、サンプルデータである場合には、サンプル毎に後ろに連結したデータをバッファに格納する。
パケットロスにより補助データが取得できなかった場合は、受信装置２０は、最新の補助データにより上書きを行うか、あるいは過去の補助データを用いることによりサンプルを復号することができる。
なお、補助データの送出周期及び送出回数はあらかじめ定められた値であってもよい。送出周期や回数（カウント、カウンドダウン）の情報は、データと一緒に送信されてもよい。例えば、データユニットヘッダに、送出周期、送出回数、及びｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙなどのタイムスタンプが格納されてもよい。
ＭＰＵの初めのサンプルの情報を含む補助データをｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙより先に１回以上送信することにより、ＣＰＢバッファモデルに従うことが可能となる。このとき、ＭＰＵタイムスタンプ記述子には、ｐｉｃｔｕｒｅ ｔｉｍｉｎｇ ＳＥＩに基づいた値を格納される。
なお、このような補助データが使用される受信動作における伝送方式は、ＭＭＴ方式に限定されず、ＭＰＥＧ−ＤＡＳＨなど、ＩＳＯＢＭＦＦファイルフォーマットで構成されるパケットをストリーミング伝送する場合などに適用可能である。
［１つのＭＰＵが複数のムービーフラグメントで構成される場合の送信方法］
上記図１９以降の説明においては、１つのＭＰＵが、１つのムービーフラグメントで構成されたが、ここでは、１つのＭＰＵが複数のムービーフラグメントで構成される場合について説明する。図３３は、複数のムービーフラグメントで構成されるＭＰＵの構成を示す図である。
図３３では、１つのＭＰＵに格納されるサンプル（＃１−＃６）は、２つのムービーフラグメントに分けて格納される。第１のムービーフラグメントは、サンプル＃１−＃３に基づいて生成され、対応するｍｏｏｆボックスが生成される。第２のムービーフラグメントは、サンプル＃４−＃６に基づいて生成され、対応するｍｏｏｆボックスが生成される。
第１のムービーフラグメントにおけるｍｏｏｆボックス及びｍｄａｔボックスのヘッダは、ムービーフラグメントメタデータ＃１としてＭＭＴペイロード及びＭＭＴパケットに格納される。一方、第２のムービーフラグメントにおけるｍｏｏｆボックス及びｍｄａｔボックスのヘッダは、ムービーフラグメントメタデータ＃２としてＭＭＴペイロード及びＭＭＴパケットに格納される。なお、図３３において、ムービーフラグメントメタデータが格納されたＭＭＴペイロードは、ハッチングされている。
なお、ＭＰＵを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、ＭＰＵを構成するサンプル数をＧＯＰ単位のサンプル数とし、ＧＯＰ単位の２分の１のサンプル数をムービーフラグメントとして、２つのムービーフラグメントが構成されてもよい。
なお、ここでは、一つのＭＰＵに２つのムービーフラグメント（ｍｏｏｆボックス及びｍｄａｔボックス）を含む例を示すが、１つのＭＰＵに含むムービーフラグメントは２つでなくとも、３つ以上であってもよい。また、ムービーフラグメントに格納するサンプルは等分したサンプル数でなく、任意のサンプル数に分割してもよい。
なお、図３３では、ＭＰＵメタデータ単位及びＭＦメタデータ単位がそれぞれデータユニットとしてＭＭＴペイロードに格納されている。しかしながら、送信装置１５は、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、及びｍｏｏｆなどの単位をデータユニットとして、データユニット単位でＭＭＴペイロードに格納してもよいし、データユニットをフラグメントした単位でＭＭＴペイロードに格納してもよい。また、送信装置１５は、データユニットをアグリゲーションした単位でＭＭＴペイロードに格納してもよい。
また、図３３では、サンプルは、サンプル単位でＭＭＴペイロードに格納されている。しかしながら、送信装置１５は、サンプル単位でなくともＮＡＬユニット単位または複数のＮＡＬユニットをまとめた単位でデータユニットを構成し、データユニット単位でＭＭＴペイロードに格納してもよい。また、送信装置１５は、データユニットをフラグメントした単位でＭＭＴペイロードに格納してもよいし、データユニットをアグリゲーションした単位でＭＭＴペイロードに格納してもよい。
なお、図３３では、ｍｏｏｆ＃１、ｍｄａｔ＃１、ｍｏｏｆ＃２、ｍｄａｔ＃２の順にＭＰＵが構成され、ｍｏｏｆ＃１には、対応するｍｄａｔ＃１が後ろについているものとしてｏｆｆｓｅｔが付与されている。しかしながら、ｍｄａｔ＃１がｍｏｏｆ＃１より前についているものしてｏｆｆｓｅｔが付与されてもよい。ただし、この場合、ｍｏｏｆ＋ｍｄａｔの形でムービーフラグメントメタデータを生成することはできず、ｍｏｏｆ及びｍｄａｔのヘッダはそれぞれ別々に伝送される。
次に、図３３で説明した構成のＭＰＵが伝送される場合のＭＭＴパケットの送信順序について説明する。図３４は、ＭＭＴパケットの送信順序を説明するための図である。
図３４の（ａ）は、図３３に示されるＭＰＵの構成順序でＭＭＴパケットを送信する場合の送信順序を示している。図３４の（ａ）は、具体的には、ＭＰＵメタ、ＭＦメタ＃１、メディアデータ＃１（サンプル＃１−＃３）、ＭＦメタ＃２、メディアデータ＃２（サンプル＃４−＃６）の順に送信する例を示す。
図３４の（ｂ）は、ＭＰＵメタ、メディアデータ＃１（サンプル＃１−＃３）、ＭＦメタ＃１、メディアデータ＃２（サンプル＃４−＃６）、ＭＦメタ＃２の順に送信する例を示す。
図３４の（ｃ）は、メディアデータ＃１（サンプル＃１−＃３）、ＭＰＵメタ、ＭＦメタ＃１、メディアデータ＃２（サンプル＃４−＃６）、ＭＦメタ＃２の順に送信する例を示す。
ＭＦメタ＃１は、サンプル＃１−＃３を用いて生成され、ＭＦメタ＃２はサンプル＃４−＃６を用いて生成される。このため、図３４の（ａ）の送信方法が用いられる場合には、サンプルデータの送信にはカプセル化による遅延が発生する。
これに対し、図３４の（ｂ）及び図３４の（ｃ）の送信方法が用いられる場合には、ＭＦメタを生成するのを待たずにサンプルを送信可能であるため、カプセル化による遅延は発生せず、Ｅｎｄ−ｔｏ−Ｅｎｄ遅延を低減できる。
また、図３４の（ａ）送信順序においても、１つのＭＰＵが複数のムービーフラグメントに分割され、ＭＦメタに格納されるサンプル数が図１９の場合に対して小さくなっているため、図１９の場合よりもカプセル化による遅延量を小さくすることができる。
なお、ここで示した方法以外に、例えば、送信装置１５は、ＭＦメタ＃１及びＭＦメタ＃２を連結し、ＭＰＵの最後にまとめて送信してもよい。この場合、異なるムービーフラグメントのＭＦメタがアグリゲーションされて、一つのＭＭＴペイロードに格納されてもよい。また、異なるＭＰＵのＭＦメタがまとめてアグリゲーションされてＭＭＴペイロードに格納されてもよい。
［１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信方法］
ここでは、図３４の（ｂ）で説明した送信順序で送信されたＭＭＴパケットを受信して復号する受信装置２０の動作例について説明する。図３５及び図３６は、このような動作例を説明するための図である。
受信装置２０は、図３５に示されるような送信順序で送信された、ＭＰＵメタ、サンプル、及びＭＦメタを含むＭＭＴパケットをそれぞれ受信する。サンプルデータは、受信順に連結される。
受信装置２０は、ＭＦメタ＃１を受信した時刻であるＴ１に、図３６の（１）に示されるようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタ＃１の情報に基づいてサンプル＃１−＃３を取得することができ、ＭＦメタに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
また、受信装置２０は、ＭＦメタ＃２を受信した時刻であるＴ２に、図３６の（２）に示されるようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタ＃２の情報を基づいてサンプル＃４−＃６を取得することができ、ＭＦメタのＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。また、受信装置２０は、図３６の（３）に示されるようにデータを連結し、ＭＰ４を構成することでＭＦメタ＃１及びＭＦメタ＃２の情報に基づいてサンプル＃１−＃６を取得してもよい。
１つのＭＰＵが複数のムービーフラグメントに分割することで、ＭＰＵの中で初めのＭＦメタを取得するまでの時間が短縮されるため、復号開始時間を早めることができる。また、復号前のサンプルを蓄積するためのバッファサイズを小さくすることができる。
なお、送信装置１５は、ムービーフラグメントにおける初めのサンプルを送信（或いは受信）してからムービーフラグメントに対応するＭＦメタを送信（或いは受信）するまでの時間が、エンコーダで指定されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙより短い時間となるようにムービーフラグメントの分割単位を設定してもよい。このように設定することにより、受信バッファはｃｐｂバッファに従うことができ、低遅延の復号を実現できる。この場合、ＰＴＳ及びＤＴＳにはｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいた絶対時刻を用いることができる。
また、送信装置１５は、ムービーフラグメントの分割を等間隔、或いは、後続のムービーフラグメントを前のムービーフラグメントより短い間隔で分割してもよい。これにより、受信装置２０は、サンプルの復号前に必ず当該サンプルの情報を含むＭＦメタを受信することができ、連続した復号が可能となる。
ＰＴＳ、及びＤＴＳの絶対時刻の算出方法は、下記の２通りの方法を用いることができる。
（１）ＰＴＳ及びＤＴＳの絶対時刻は、ＭＦメタ＃１やＭＦメタ＃２の受信時刻（Ｔ１或いはＴ２）、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定される。
（２）ＰＴＳ及びＤＴＳの絶対時刻は、ＭＰＵタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定される。
また、（２−Ａ）送信装置１５がシグナリングする絶対時刻は、エンコーダから指定されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいて算出された絶対時刻であってもよい。
また、（２−Ｂ）送信装置１５がシグナリングする絶対時刻は、ＭＦメタの受信時刻の予測値に基づいて算出された絶対時刻であってもよい。
なお、ＭＦメタ＃１及びＭＦメタ＃２は、繰り返し伝送されてもよい。ＭＦメタ＃１及びＭＦメタ＃２が繰り返し伝送されることにより、受信装置２０は、ＭＦメタをパケットロス等により取得できなかった場合でも、もう一度取得することができる。
ムービーフラグメントを構成するサンプルを含むＭＦＵのペイロードヘッダには、ムービーフラグメントの順番を示す識別子を格納することができる。一方、ムービーフラグメントを構成するＭＦメタの順番を示す識別子はＭＭＴペイロードには含まれない。このため、受信装置２０は、ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒでＭＦメタの順番を識別する。或いは、送信装置１５は、ＭＦメタが何番目のムービーフラグメントに属するかを示す識別子を、制御情報（メッセージ、テーブル、記述子）、ＭＭＴヘッダ、ＭＭＴペイロードヘッダ、またはデータユニットヘッダに格納してシグナリングしてもよい。
なお、送信装置１５は、ＭＰＵメタ、ＭＦメタ、及びサンプルを、あらかじめ定められた所定の送信順序で送信し、受信装置２０は、あらかじめ定められた所定の送信順序に基づいて受信処理を実施してもよい。また、送信装置１５は、送信順序をシグナリングし、シグナリング情報に基づいて受信装置２０が受信処理を選択（判断）してもよい。
上記のような受信方法について、図３７を用いて説明する。図３７は、図３５及び図３６で説明した受信方法の動作のフローチャートである。
まず、受信装置２０は、ＭＭＴペイロードに示されるフラグメントタイプにより、ペイロードに含まれるデータが、ＭＰＵメタデータ、ＭＦメタデータであるか、サンプルデータ（ＭＦＵ）であるかを判別（識別）する（Ｓ６０１、Ｓ６０２）。データがサンプルデータである場合には、受信装置２０は、サンプルをバッファリングし、当該サンプルに対応するＭＦメタデータの受信、及び復号開始を待つ（Ｓ６０３）。
一方、ステップＳ６０２において、データがＭＦメタデータである場合には、受信装置２０は、ＭＦメタデータよりサンプルの情報（ＰＴＳ、ＤＴＳ、位置情報、及びサイズ）を取得し、取得したサンプルの情報に基づいてサンプルを取得し、ＰＴＳ及びＤＴＳに基づいてサンプルを復号、提示する（Ｓ６０４）。
なお、図示されないが、データがＭＰＵメタデータである場合、ＭＰＵメタデータには、復号に必要な初期化情報が含まれている。このため、受信装置２０はこれを蓄積し、ステップＳ６０４においてサンプルデータの復号に用いる。
なお、受信装置２０は、受信したＭＰＵのデータ（ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータ）を蓄積装置に蓄積する場合には、図１９または図３３で説明した、ＭＰＵの構成に並び替えた後に、蓄積する。
なお、送信側においては、ＭＭＴパケットには、同一のパケットＩＤを持つパケットに対して、パケットシーケンス番号を付与する。このとき、ＭＰＵメタデータ、ＭＦメタデータ、サンプルデータを含むＭＭＴパケットが送信順序に並び替えられた後にパケットシーケンス番号が付与されてもよいし、並び替える前の順序でパケットシーケンス番号が付与されてもよい。
並び替える前の順序でパケットシーケンス番号が付与される場合には、受信装置２０において、パケットシーケンス番号に基づいて、データをＭＰＵの構成順序に並び替えることができ、蓄積が容易となる。
［アクセスユニットの先頭及びスライスセグメントの先頭を検出する方法］
ＭＭＴパケットヘッダ、及びＭＭＴペイロードヘッダの情報に基づき、アクセスユニットの先頭やスライスセグメントの先頭を検出する方法について説明する。
ここでは、非ＶＣＬ ＮＡＬユニット（アクセスユニットデリミタ、ＶＰＳ、ＳＰＳ、ＰＰＳ、及びＳＥＩなど）を、まとめてデータユニットとしてＭＭＴペイロードに格納する場合、及び、非ＶＣＬ ＮＡＬユニットをそれぞれデータユニットとし、データユニットをアグリゲーションして１つのＭＭＴペイロードに格納する場合の２つの例を示す。
図３８は、非ＶＣＬ ＮＡＬユニットを、個別にデータユニットとし、アグリゲーションする場合を示す図である。
図３８の場合、アクセスユニットの先頭は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅ値がＭＦＵであるＭＭＴパケットであり、かつ、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が１であり、かつｏｆｆｓｅｔ値が０であるデータユニットを含むＭＭＴペイロードの先頭データである。このとき、Ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値は０である。
また、図３８の場合、スライスセグメントの先頭は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅ値がＭＦＵであるＭＭＴパケットであり、かつａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が０、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるＭＭＴペイロードの先頭データである。
図３９は、非ＶＣＬ ＮＡＬユニットを、まとめてデータユニットとする場合を示す図である。なお、パケットヘッダのフィールド値は、図１７（または図１８）で示した通りである。
図３９の場合、アクセスユニットの先頭は、Ｏｆｆｓｅｔ値が０であるパケットにおけるペイロードの先頭データが、アクセスユニットの先頭となる。
また、図３９の場合、スライスセグメントの先頭は、Ｏｆｆｓｅｔ値が０とは異なる値であり、ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ値が００或いは０１であるパケットのペイロードの先頭データが、スライスセグメントの先頭となる。
［パケットロスが発生した場合の受信処理］
通常、パケットロスが発生する環境において、ＭＰ４形式のデータを伝送する場合、受信装置２０は、ＡＬＦＥＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＦＥＣ）や、パケット再送制御等によりパケットを復元する。
しかし、放送のようなストリーミングにおいてＡＬ−ＦＥＣを用いられない場合にパケットロスが発生した場合には、パケットを復元できない。
受信装置２０は、パケットロスによりデータが失われた後、再び映像や音声の復号を再開させる必要がある。そのためには、受信装置２０は、アクセスユニットやＮＡＬユニットの先頭を検出し、アクセスユニットやＮＡＬユニットの先頭から復号を開始する必要がある。
しかし、ＭＰ４形式のＮＡＬユニットの先頭には、スタートコードがついていないため、受信装置２０は、ストリームを解析しても、アクセスユニットやＮＡＬユニットの先頭を検出できない。
図４０は、パケットロスが発生した場合の受信装置２０の動作のフローチャートである。
受信装置２０は、ＭＭＴパケットやＭＭＴペイロードのヘッダにおけるＰａｃｋｅｔｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒや、ｐａｃｋｅｔ ｃｏｕｎｔｅｒ、ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒなどによりパケットロスを検出し（Ｓ７０１）、前後の関係から、どのパケットが消失したかを判定する（Ｓ７０２）。
受信装置２０は、パケットロスが発生していないと判定された場合（Ｓ７０２でＮｏ）には、ＭＰ４ファイルを構成し、アクセスユニット或いはＮＡＬユニットを復号する（Ｓ７０３）。
受信装置２０は、パケットロスが発生したと判定された場合（Ｓ７０２でＹｅｓ）には、パケットロスしたＮＡＬユニットに相当するＮＡＬユニットをダミーデータにより生成し、ＭＰ４ファイルを構成する（Ｓ７０４）。受信装置２０は、ＮＡＬユニットにダミーデータを入れる場合には、ＮＡＬユニットのタイプにダミーデータであることを示す。
また、受信装置２０は、図１７、図１８、図３８、及び図３９で説明した方法に基づいて、次のアクセスユニットやＮＡＬユニットの先頭を検出し、先頭データからデコーダに入力することで、復号を再開することができる（Ｓ７０５）。
なお、パケットロスが発生した場合には、受信装置２０は、パケットヘッダに基づいて検出された情報に基づいてアクセスユニット及びＮＡＬユニットの先頭から復号を再開してもよいし、ダミーデータのＮＡＬユニットを含む、再構成されたＭＰ４ファイルのヘッダ情報に基づいてアクセスユニット及びＮＡＬユニットの先頭から復号を再開してもよい。
受信装置２０は、ＭＰ４ファイル（ＭＰＵ）を蓄積する際には、パケットロスにより消失したパケットデータ（ＮＡＬユニットなど）は、放送や通信から別途取得して蓄積（置き換え）してもよい。
このとき、受信装置２０は、消失したパケットを通信から取得する場合には、消失したパケットの情報（パケットＩＤや、ＭＰＵシーケンス番号、パケットシーケンス番号、ＩＰデータフロー番号、及びＩＰアドレスなど）をサーバーに通知し、当該パケットを取得する。受信装置２０は、消失したパケットのみに限らず、消失したパケット前後のパケット群を同時に取得してもよい。
［ムービーフラグメントの構成方法］
ここでは、ムービーフラグメントの構成方法について詳細に説明する。
図３３で説明されたように、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数は、任意である。例えば、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数は、固定的に定められた所定の数であってもよいし、動的に決定されてもよい。
ここで、送信側（送信装置１５）において下記の条件を満たすようにムービーフラグメントが構成されることで、受信装置２０における低遅延の復号を保証することができる。
その条件とは、以下の通りである。
送信装置１５は、受信装置２０が、任意のサンプル（Ｓａｍｐｌｅ（ｉ））の復号時刻（ＤＴＳ（ｉ））より前には必ず当該サンプルの情報を含むＭＦメタを受信できるように、サンプルデータを分割した単位をムービーフラグメントとしてＭＦメタを生成・送信する。
具体的には、送信装置１５は、ＤＴＳ（ｉ）より前に符号化済のサンプル（ｉ番目のサンプルを含む）を用いてムービーフラグメントを構成する。
低遅延の復号を保証するように、ムービーフラグメントを構成するサンプル数や１つのＭＰＵを構成するムービーフラグメント数を動的に決定する方法としては、例えば、下記の方法が用いられる。
（１）復号開始時、ＧＯＰ先頭のサンプルＳａｍｐｌｅ（０）の復号時刻ＤＴＳ（０）は、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいた時刻である。送信装置は、ＤＴＳ（０）より前の時刻に、符号化完了済のサンプルを用いて第１のムービーフラグメントを構成する。また、送信装置１５は、第１のムービーフラグメントに対応するＭＦメタデータを生成し、ＤＴＳ（０）より前の時刻に送信する。
（２）送信装置１５は、以降のサンプルにおいても、上記の条件を満たすようにムービーフラグメントを構成する。
例えば、ムービーフラグメントの先頭のサンプルがｋ番目のサンプルであるとしたとき、ｋ番目のサンプルを含むムービーフラグメントのＭＦメタは、ｋ番目のサンプルの復号時刻ＤＴＳ（ｋ）までに送信される。送信装置１５は、ｌ番目のサンプルの符号化完了時刻がＤＴＳ（ｋ）より前であり、（ｌ＋１）番目のサンプルの符号化完了時刻がＤＴＳ（ｋ）より後である場合には、ｋ番目のサンプルからｌ番目のサンプルを用いてムービーフラグメントを構成する。
なお、送信装置１５は、ｋ番目のサンプルから、ｌ番目に満たないサンプルまでを用いてムービーフラグメントを構成してもよい。
（３）送信装置１５は、ＭＰＵ最後のサンプルの符号化完了後、残りのサンプルを用いてムービーフラグメントを構成し、当該ムービーフラグメントに対応するＭＦメタデータを生成し、送信する。
なお、送信装置１５は、符号化完了済のすべてのサンプルを用いてムービーフラグメントを構成せずに、符号化完了済の一部のサンプルを用いてムービーフラグメントを構成してもよい。
なお、上記では、低遅延の復号を保証するように、上記条件に基づいて動的に、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数が決定される例を示した。しかしながら、サンプル数及びムービーフラグメント数の決定方法は、このような方法に限定されるものではない。例えば、１つのＭＰＵを構成するムービーフラグメント数が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。また、１つのＭＰＵを構成するムービーフラグメント数、及びムービーフラグメントを分割する時刻（或いはムービーフラグメントの符号量）が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。
また、ＭＰＵが複数のムービーフラグメントに分割されている場合、ＭＰＵが複数のムービーフラグメントに分割されているかどうかを示す情報、分割されたムービーフラグメントの属性、または分割されたムービーフラグメントに対するＭＦメタの属性が送信されてもよい。
ここで、ムービーフラグメントの属性とは、ムービーフラグメントが、ＭＰＵの先頭のムービーフラグメントであるか、ＭＰＵの最後のムービーフラグメントであるか、それ以外のムービーフラグメントであるか等を示す情報である。
また、ＭＦメタの属性とは、ＭＦメタが、ＭＰＵの先頭のムービーフラグメントに対応するＭＦメタであるか、ＭＰＵの最後のムービーフラグメントに対応するＭＦメタであるか、それ以外のムービーフラグメントに対応するＭＦメタであるか等を示す情報である。
なお、送信装置１５は、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数を制御情報として格納し、送信してもよい。
［受信装置の動作］
上記のように構成されたムービーフラグメントに基づく受信装置２０の動作について説明する。
受信装置２０は、ＰＴＳ及びＤＴＳのそれぞれの絶対時刻を、ＭＰＵタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定する。
受信装置２０は、ＭＰＵが複数のムービーフラグメントに分割されているかどうかの情報に基づいて、ＭＰＵが分割されている場合は、分割されたムービーフラグメントの属性に基づいて、下記のように処理をする。
（１）受信装置２０は、ムービーフラグメントがＭＰＵの先頭のムービーフラグメントである場合、ＭＰＵタイムスタンプ記述子に含まれる先頭サンプルのＰＴＳの絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻を用いて、ＰＴＳ及びＤＴＳの絶対時刻を生成する。
（２）受信装置２０は、ムービーフラグメントがＭＰＵの先頭のムービーフラグメントでない場合、ＭＰＵタイムスタンプ記述子の情報を用いずに、ＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻を用いて、ＰＴＳ及びＤＴＳの絶対時刻を生成する。
（３）受信装置２０は、ムービーフラグメントがＭＰＵの最後のムービーフラグメントである場合、すべてのサンプルのＰＴＳ及びＤＴＳの絶対時刻を算出後、ＰＴＳ及びＤＴＳの計算処理（相対時刻の加算処理）をリセットする。なお、リセット処理は、ＭＰＵ先頭のムービーフラグメントにおいて実施してもよい。
受信装置２０は、下記のようにムービーフラグメントが分割されているかどうかの判定を行ってもよい。また、受信装置２０は、下記のようにムービーフラグメントの属性情報を取得してもよい。
例えば、受信装置２０は、ＭＭＴＰ（ＭＭＴ Ｐｒｏｔｏｃｏｌ）ペイロードヘッダに示されるムービーフラグメントの順番を示す識別子ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値に基づいて分割されているかどうかを判定してもよい。
具体的には、受信装置２０は、１つのＭＰＵに含まれるムービーフラグメントの数が１であり、かつ、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値が１であり、かつ、当該フィールド値が２以上の値が存在する場合に、当該ＭＰＵは複数のムービーフラグメントに分割されていると判定してもよい。
また、受信装置２０は、１つのＭＰＵに含まれるムービーフラグメントの数が１であり、かつ、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値が０であり、かつ、当該フィールド値が０以外の値が存在する場合に、当該ＭＰＵは複数のムービーフラグメントに分割されていると判定してもよい。
ムービーフラグメントの属性情報も同様に、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒに基づいて判定されてもよい。
なお、ｍｏｖｉｅ＿ｆｒｅａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒを用いずとも、一つＭＰＵに含まれるムービーフラグメントやＭＦメタの送信をカウントすることにより、ムービーフラグメントが分割されているかどうかや、ムービーフラグメントの属性情報を判定されてもよい。
以上説明したような送信装置１５および受信装置２０の構成により、受信装置２０は、ＭＰＵよりも短い間隔でムービーフラグメントメタデータを受信でき、低遅延での復号開始が可能となる。また、ＭＰ４パースの方法に基づいた復号処理を用いて、低遅延での復号を行うことが可能となる。
以上説明したようにＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作について、フローチャートを用いて説明する。図４１は、ＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作のフローチャートである。なお、このフローチャートは、図３７のステップＳ６０４の動作をより詳細に図示するものである。
まず、受信装置２０は、ＭＭＴＰペイロードヘッダに示されるデータ種別に基づいて、データ種別がＭＦメタである場合に、ＭＦメタデータを取得する（Ｓ８０１）。
次に、受信装置２０は、ＭＰＵが複数のムービーフラグメントに分割されているかどうかを判定し（Ｓ８０２）、ＭＰＵが複数のムービーフラグメントに分割されている場合（Ｓ８０２でＹｅｓ）には、受信したＭＦメタデータがＭＰＵ先頭のメタデータであるかどうかを判定する（Ｓ８０３）。受信装置２０は、受信したＭＦメタデータがＭＰＵ先頭のＭＦメタデータである場合（Ｓ８０３でＹｅｓ）には、ＭＰＵタイムスタンプ記述子に示されるＰＴＳの絶対時刻、並びにＭＦメタデータに示されるＰＴＳ及びＤＴＳの相対時刻よりＰＴＳ及びＤＴＳの絶対時刻を算出し（Ｓ８０４）、ＭＰＵの最後のメタデータであるかどうかの判定を行う（Ｓ８０５）。
一方、受信装置２０は、受信したＭＦメタデータがＭＰＵ先頭のＭＦメタデータでない場合（Ｓ８０３でＮｏ）には、ＭＰＵタイムスタンプ記述子の情報は用いずＭＦメタデータに示されるＰＴＳ及びＤＴＳの相対時刻を用いてＰＴＳ及びＤＴＳの絶対時刻を算出し（Ｓ８０８）、ステップＳ８０５の処理に移行する。
ステップＳ８０５において、ＭＰＵ最後のＭＦメタデータであると判定された場合（Ｓ８０５でＹｅｓ）、受信装置２０は、すべてのサンプルのＰＴＳ及びＤＴＳの絶対時刻を算出後、ＰＴＳ及びＤＴＳの計算処理をリセットする。ステップＳ８０５においてＭＰＵ最後のＭＦメタデータでないと判定された場合（Ｓ８０５でＮｏ）、受信装置２０は処理を終了する。
また、ステップＳ８０２においてＭＰＵが複数のムービーフラグメントに分割されていないと判定された場合（Ｓ８０２でＮｏ）には、受信装置２０は、ＭＰＵの後に送信されるＭＦメタデータに基づき、サンプルデータを取得し、ＰＴＳ及びＤＴＳを決定する（Ｓ８０７）。
そして、図示されないが、受信装置２０は、最後に、決定したＰＴＳ及びＤＴＳに基づいて復号処理、提示処理を実施する。
［ムービーフラグメントを分割したときに発生する課題、及び、その解決策］
これまで、ムービーフラグメントを分割することによりＥｎｄ−ｔｏ−Ｅｎｄ遅延を短縮する方法について説明してきた。ここからは、ムービーフラグメントを分割したときに新たに発生する課題、及び、その解決策について説明する。
まず、背景として、符号化データにおけるピクチャ構造について説明する。図４２は、時間スケーラビリティを実現する際の各ＴｅｍｐｏｒａｌＩｄにおけるピクチャの予測構造の例を示す図である。
ＭＰＥＧ−４ ＡＶＣやＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）などの符号化方式においては、他のピクチャから参照可能なＢピクチャ（双方向参照予測ピクチャ）を用いることにより時間方向のスケーラビリティ（時間スケーラビリティ）が実現できる。
図４２の（ａ）に示されるＴｅｍｐｏｒａｌＩｄとは、符号化構造の階層の識別子であり、ＴｅｍｐｏｒａｌＩｄは、値が大きくなるほど深い階層であることを示す。四角のブロックはピクチャを示し、ブロック内のＩｘは、Ｉピクチャ（画面内予測ピクチャ）、Ｐｘは、Ｐピクチャ（前方参照予測ピクチャ）、Ｂｘ及びｂｘは、Ｂピクチャ（双方向参照予測ピクチャ）を示す。Ｉｘ／Ｐｘ／Ｂｘのｘは表示オーダーを示し、ピクチャを表示する順番を表わす。ピクチャ間の矢印は参照関係を示し、例えば、Ｂ４のピクチャはＩ０、Ｂ８を参照画像として予測画像を生成することを示す。ここで、一のピクチャが、自らのＴｅｍｐｏｒａｌＩｄより大きいＴｅｍｐｏｒａｌＩｄを持つ他のピクチャを参照画像として使うことは禁止されている。階層が規定されているのは時間スケーラビリティを持たせるためであり、例えば、図４２において全てのピクチャを復号すると１２０ｆｐｓ（ｆｒａｍｅ ｐｅｒ ｓｅｃｏｎｄ）の映像が得られるが、ＴｅｍｐｏｒａｌＩｄが０から３までの階層のみを復号すると６０ｆｐｓの映像が得られる。
図４３は、図４２の各ピクチャにおける復号時刻（ＤＴＳ）と表示時刻（ＰＴＳ）との関係を示す図である。例えば、図４３に示されるピクチャＩ０は、復号及び表示においてギャップが発生しないように、Ｂ４の復号完了後に表示される。
図４３に示されるように、予測構造にＢピクチャが含まれる場合などには、復号順と表示順とが異なるため、受信装置２０においてピクチャを復号後にピクチャの遅延処理、及び、ピクチャの並び替え（リオーダ）処理が必要となる。
以上、時間方向のスケーラビリティにおけるピクチャの予測構造の例について説明したが、時間方向のスケーラビリティが用いられない場合においても、予測構造によっては、ピクチャの遅延処理、及び、リオーダ処理が必要となる場合がある。図４４は、ピクチャの遅延処理、及び、リオーダ処理が必要となるピクチャの予測構造の一例を示す図である。なお、図４４における数字は、復号順を示す。
図４４に示されるように、予測構造によっては、復号順において先頭となるサンプルと、提示順において先頭となるサンプルが異なる場合があり、図４４では、提示順で先頭となるサンプルは、復号順で４番目のサンプルとなる。なお、図４４は、予測構造の一例を示すものであり、予測構造はこのような構造に限定されるものではない。他の予測構造においても、復号順において先頭となるサンプルと、提示順において先頭となるサンプルとが異なる場合がある。
図４５は、図３３と同様に、ＭＰ４形式で構成されるＭＰＵが複数のムービーフラグメントに分割されて、ＭＭＴＰペイロード、ＭＭＴＰパケットに格納される例を示す図である。なお、ＭＰＵを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、ＭＰＵを構成するサンプル数をＧＯＰ単位のサンプル数とし、ＧＯＰ単位の２分の１のサンプル数をムービーフラグメントとして、２つのムービーフラグメントが構成されてもよい。１サンプルが１つのムービーフラグメントとされてもよいし、ＭＰＵを構成するサンプルが分割されなくてもよい。
図４５では、１つのＭＰＵに２つのムービーフラグメント（ｍｏｏｆボックス及びｍｄａｔボックス）が含まれる例が示されているが、１つのＭＰＵに含まれるムービーフラグメントは２つでなくてもよい。１つのＭＰＵに含まれるムービーフラグメントは、３つ以上であってもよいし、ＭＰＵに含まれるサンプル数であってもよい。また、ムービーフラグメントに格納されるサンプルは等分したサンプル数でなく、任意のサンプル数に分割されてもよい。
ムービーフラグメントメタデータ（ＭＦメタデータ）には、ムービーフラグメントに含まれるサンプルのＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報が含まれており、受信装置２０は、サンプルを復号する際には、当該サンプルの情報を含むＭＦメタからＰＴＳ及びＤＴＳを抽出し、復号タイミングや提示タイミングを決定する。
ここからは、詳細説明のために、ｉサンプルの復号時刻の絶対値をＤＴＳ（ｉ）と記載し、提示時刻の絶対値をＰＴＳ（ｉ）と記載する。
ＭＦメタにおけるｍｏｏｆ内に格納されているタイムスタンプ情報のうちｉ番目のサンプルの情報は、具体的には、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値、及び、ｉ番目のサンプルの復号時刻と提示時刻の相対値であり、これらを以降ＤＴ（ｉ）及びＣＴ（ｉ）と記載する。
ムービーフラグメントメタデータ＃１には、サンプル＃１−＃３のＤＴ（ｉ）及びＣＴ（ｉ）が含まれており、ムービーフラグメントメタデータ＃２には、サンプル＃４−＃６のＤＴ（ｉ）及びＣＴ（ｉ）が含まれている。
また、ＭＰＵ先頭のアクセスユニットのＰＴＳ絶対値は、ＭＰＵタイムスタンプ記述子などに格納されており、受信装置２０は、ＭＰＵ先頭のアクセスユニットのＰＴＳ＿ＭＰＵと、ＣＴ及びＤＴとに基づいてＰＴＳ及びＤＴＳを算出する。
図４６は、＃１−＃１０のサンプルによりＭＰＵが構成される場合のＰＴＳ及びＤＴＳの算出方法と課題とを説明するための図である。
図４６の（ａ）は、ＭＰＵがムービーフラグメントに分割されない例を示し、図４６の（ｂ）は、ＭＰＵが５サンプル単位の２つのムービーフラグメントに分割される例を示し、図４６の（ｃ）は、ＭＰＵがサンプル単位に１０のムービーフラグメントに分割される例を示す。
図４５で説明したように、ＭＰＵタイムスタンプ記述子と、ＭＰ４内のタイムスタンプ情報（ＣＴ及びＤＴ）とを用いてＰＴＳ及びＤＴＳが算出される場合において、図４４における提示順で先頭となるサンプルは、復号順で４番目である。このため、ＭＰＵタイムスタンプ記述子に格納されているＰＴＳは、復号順で４番目のサンプルのＰＴＳ（絶対値）となる。なお、以降では、このサンプルをＡサンプルと呼ぶ。また、復号順で先頭のサンプルをＢサンプルと呼ぶ。
タイムスタンプに係る絶対時刻情報は、ＭＰＵタイムスタンプ記述子の情報のみであるため、受信装置２０は、Ａサンプルが到着するまで、その他のサンプルのＰＴＳ（絶対時刻）及びＤＴＳ（絶対時刻）を算出できない。受信装置２０は、ＢサンプルのＰＴＳ及びＤＴＳも算出できない。
図４６の（ａ）の例では、Ａサンプルは、Ｂサンプルと同じムービーフラグメントに含まれ、一つのＭＦメタに格納される。このため、受信装置２０は、当該ＭＦメタを受信後、すぐにＢサンプルのＤＴＳを決定できる。
図４６の（ｂ）の例では、Ａサンプルは、Ｂサンプルと同じムービーフラグメントに含まれ、一つのＭＦメタに格納される。このため、受信装置２０は、当該ＭＦメタを受信後、すぐにＢサンプルのＤＴＳを決定できる。
図４６の（ｃ）の例では、Ａサンプルは、Ｂサンプルと異なるムービーフラグメントに含まれる。このため、受信装置２０は、Ａサンプルを含むムービーフラグメントのＣＴ及びＤＴを含むＭＦメタを受信後でなければ、ＢサンプルのＤＴＳを決定できない。
したがって、図４６の（ｃ）の例の場合には、受信装置２０は、Ｂサンプルの到着後、すぐに復号を開始できない。
このように、Ｂサンプルを含むムービーフラグメントに、Ａサンプルが含まれない場合には、受信装置２０は、Ａサンプルを含むムービーフラグメントに係るＭＦメタを受信した後でなければ、Ｂサンプルの復号を開始できない。
提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、ＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されなくなるまでにムービーフラグメントが分割されることにより、この課題は発生する。また、ＭＦメタが後送りであるか先送りであるかにかかわらず、この課題は発生する。
このように、提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、Ａサンプルと、Ｂサンプルとが同一ムービーフラグメントに格納されない場合には、Ｂサンプルの受信後、すぐにＤＴＳを決定できない。そこで、送信装置１５は、別途、ＢサンプルのＤＴＳ（絶対値）、或いはＢサンプルのＤＴＳ（絶対値）を受信側において算出可能な情報を送信する。このような情報は、制御情報やパケットヘッダ等を用いて送信されてもよい。
受信装置２０は、このような情報を用いてＢサンプルのＤＴＳ（絶対値）を算出する。図４７は、このような情報を用いてＤＴＳが算出される場合の受信動作のフローチャートである。
受信装置２０は、ＭＰＵ先頭のムービーフラグメントを受信し（Ｓ９０１）、ＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されているかどうかを判定する（Ｓ９０２）。同一ムービーフラグメントに格納されている場合（Ｓ９０２でＹｅｓ）は、受信装置２０は、ＢサンプルのＤＴＳ（絶対時刻）を用いず、ＭＦメタの情報のみを用いてＤＴＳを算出し、復号を開始する（Ｓ９０４）。なお、ステップＳ９０４において、受信装置２０は、ＢサンプルのＤＴＳを用いてＤＴＳを決定してもよい。
一方、ステップＳ９０２においてＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されていない場合（Ｓ９０２でＮｏ）、受信装置２０は、ＢサンプルのＤＴＳ（絶対時刻）を取得し、ＤＴＳを決定し、復号を開始する（Ｓ９０３）。
なお、以上の説明では、ＭＭＴ規格におけるＭＦメタ（ＭＰ４形式のｍｏｏｆ内に格納されているタイムスタンプ情報）を用いて、各サンプルの復号時刻の絶対値と、提示時刻の絶対値とを算出する例について説明したが、ＭＦメタを、各サンプルの復号時刻の絶対値と、提示時刻の絶対値を算出に用いることができる任意の制御情報に置き換えて実施しても良いことは言うまでもない。このような制御情報の例としては、上述したｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値ＣＴ（ｉ）を、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの提示時刻の相対値に置き換えた制御情報や、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値ＣＴ（ｉ）とｉ番目のサンプルと（ｉ＋１）番目のサンプルの提示時刻の相対値との両方を含む制御情報などがある。
（実施の形態３）
［概要］
実施の形態３では、映像、音声、字幕、及びデータ放送などのコンテンツを放送で伝送する場合のコンテンツの送信方法及びデータ構造について説明する。つまり、放送ストリームの再生に特化したコンテンツの送信方法及びデータ構造について説明する。
なお、実施の形態３では、多重化方式としてＭＭＴ方式（以下、単にＭＭＴとも記載する）が用いられる例について説明するが、ＭＰＥＧ−ＤＡＳＨまたはＲＴＰなど、その他の多重化方式が用いられてもよい。
まず、ＭＭＴにおけるデータユニット（ＤＵ：Ｄａｔａ Ｕｎｉｔ）のペイロードへの格納方法の詳細について説明する。図４８は、ＭＭＴにおけるデータユニットのペイロードへの格納方法を説明するための図である。
ＭＭＴでは、送信装置は、ＭＰＵを構成するデータの一部を、データユニットとしてＭＭＴＰペイロードに格納し、ヘッダをつけて伝送する。ヘッダにはＭＭＴＰペイロードヘッダ、及び、ＭＭＴＰパケットヘッダが含まれる。なお、データユニットの単位は、ＮＡＬユニット単位でもよいし、サンプル単位でもよい。
図４８の（ａ）は、送信装置が複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す。図４８の（ａ）の例では、複数のデータユニットそれぞれの先頭に、データユニットヘッダ（ＤＵＨ：Ｄａｔａ Ｕｎｉｔ Ｈｅａｄｅｒ）、及び、データユニット長（ＤＵＬ：Ｄａｔａ Ｕｎｉｔ Ｌｅｎｇｔｈ）が付与され、データユニットヘッダ及びデータユニット長が付与されたデータユニットが複数まとめてペイロードに格納される。
図４８の（ｂ）は、一つのデータユニットを一つのペイロードに格納する例を示す。図４８の（ｂ）の例では、データユニットの先頭に、データユニットヘッダが付与されてペイロードに格納される。図４８の（ｃ）は、一つのデータユニットを分割し、分割されたデータユニットに、データユニットヘッダが付与されてペイロードに格納される例を示す。
データユニットには、映像、音声、または字幕などの同期に関する情報を含むメディアであるｔｉｍｅｄ−ＭＦＵ、ファイルなど同期に関する情報を含まないメディアであるｎｏｎ−ｔｉｍｅｄ−ＭＦＵ、ＭＰＵメタデータ、ＭＦメタデータなどの種類があり、データユニットの種類に応じてデータユニットヘッダが定められる。なお、ＭＰＵメタデータ、及び、ＭＦメタデータにはデータユニットヘッダは存在しない。
また、送信装置は、異なる種類のデータユニットをアグリゲーションすることは原則としてできないが、異なる種類のデータユニットをアグリゲーションできるように規定されてもよい。例えば、サンプル毎にムービーフラグメントに分割されている場合などのＭＦメタデータのサイズが小さい場合、ＭＦメタデータとメディアデータとをアグリゲーションすることにより、パケット数を削減でき、さらに、伝送容量を削減することもできる。
データユニットがＭＦＵの場合は、ＭＰＵ（ＭＰ４）を構成するための情報など、ＭＰＵの一部の情報がヘッダとして格納される。
例えば、ｔｉｍｅｄ−ＭＦＵのヘッダには、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ｓａｍｐｌｅ＿ｎｕｍｂｅｒ、ｏｆｆｓｅｔ、ｐｒｉｏｒｉｔｙ、及び、ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒなどが含まれ、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵのヘッダにはｉｔｅｍ＿ｉＤが含まれる。各フィールドの意味はＩＳＯ／ＩＥＣ２３００８−１あるいはＡＲＩＢ ＳＴＤ−Ｂ６０などの規格に示される。以下、このような規格において規定される各フィールドの意味について説明する。
ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、ＭＦＵが属するムービーフラグメントのシーケンス番号を示し、ＩＳＯ／ＩＥＣ１４４９６−１２にも示される。
ｓａｍｐｌｅ＿ｎｕｍｂｅｒは、当該ＭＦＵが属するサンプル番号を示し、ＩＳＯ／ＩＥＣ１４４９６−１２にも示される。
ｏｆｆｓｅｔは、当該ＭＦＵが属するサンプルにおける、ＭＦＵのオフセット量をバイト単位で示す。
ｐｒｉｏｒｉｔｙは、当該ＭＦＵが属するＭＰＵにおける、ＭＦＵの相対的な重要度を示し、ｐｒｉｏｒｉｔｙの数字が大きいＭＦＵは、ｐｒｉｏｒｉｔｙの数字が小さいＭＦＵよりも重要であることを示す。
ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒは、復号処理が当該ＭＦＵに依存しているＭＦＵ数（すなわち、このＭＦＵを復号処理しなければ、その復号処理を行うことができないＭＦＵの数）を示す。例えば、ＭＦＵがＨＥＶＣである場合においてＢピクチャまたはＰピクチャがＩピクチャを参照する場合、当該ＢピクチャまたはＰピクチャは、Ｉピクチャを復号処理しなければ復号処理を行うことができない。
したがって、ＭＦＵがサンプル単位である場合は、ＩピクチャのＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、当該Ｉピクチャを参照するピクチャ数が示される。ＭＦＵがＮＡＬユニット単位の場合は、Ｉピクチャに属するＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、当該Ｉピクチャを参照するピクチャに属するＮＡＬユニット数が示される。さらに、時間方向階層符号化された映像信号の場合、拡張レイヤのＭＦＵは、ベースレイヤのＭＦＵに依存するため、ベースレイヤのＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、拡張レイヤのＭＦＵの数が示される。本フィールドは、依存するＭＦＵ数が決定した後でなければ生成できない。
ｉｔｅｍ＿ｉＤは、アイテムを一意に特定する識別子を示す。
［ＭＰ４非サポートモード］
図１９、及び、図２１で説明したように、送信装置がＭＭＴにおけるＭＰＵを伝送する方法としては、ＭＰＵメタデータまたはＭＦメタデータをメディアデータの前または後に送信する方法、及び、メディアデータのみを送信する方法がある。また、受信装置では、ＭＰ４に準拠した受信装置や受信方法を用いて復号を行う方法や、ヘッダを用いずに復号する方法がある。
放送ストリーム再生に特化したデータの送信方法として、例えば、受信装置におけるＭＰ４再構成をサポートしない送信方法がある。
受信装置におけるＭＰ４再構成をサポートしない送信方法とは、例えば、図２１の（ｂ）に示されるようにメタデータ（ＭＰＵメタデータ及びＭＦメタデータ）を送信しない方法がある。この場合、ＭＭＴＰパケットに含まれるフラグメントタイプ（データユニットの種類を示す情報）のフィールド値は、２（＝ＭＦＵ）固定である。
メタデータが送信されない場合は、これまで説明したように、ＭＰ４準拠の受信装置などでは、受信したデータをＭＰ４として復号することはできないが、メタデータ（ヘッダ）を用いずに復号することが可能である。
そのため、メタデータは放送ストリーム復号及び再生に必ずしも必須の情報ではない。同様に、図４８で説明した、ｔｉｍｅｄ−ＭＦＵにおけるデータユニットヘッダの情報は、受信装置においてＭＰ４を再構成するための情報である。放送ストリーム再生においてＭＰ４を再構成する必要はないため、ｔｉｍｅｄ−ＭＦＵにおけるデータユニットヘッダ（以下、ｔｉｍｅｄ−ＭＦＵヘッダとも記載する）の情報は、放送ストリーム再生に必ずしも必要な情報ではない。
受信装置は、メタデータ、および、データユニットヘッダにおけるＭＰ４を再構成するための情報（以下、ＭＰ４構成情報とも記載する）を用いることにより、容易にＭＰ４を再構成することができる。しかし、受信装置は、メタデータ、および、データユニットヘッダにおけるＭＰ４構成情報のどちらか一方のみが伝送されていたとしても、ＭＰ４を再構成することはできない。メタデータ及びＭＰ４を再構成するための情報のどちらか一方のみが伝送されることによるメリットは少なく、必要でない情報を生成及び伝送することは、処理の増大や伝送効率の低下を招く。
そこで、送信装置は、下記の方法を用いてＭＰ４構成情報のデータ構造や伝送を制御する。送信装置は、メタデータが伝送されるかどうかに基づいて、データユニットヘッダにおいてＭＰ４構成情報を示すか否かを決定する。具体的には、送信装置は、メタデータが伝送される場合には、データユニットヘッダにおいてＭＰ４構成情報を示し、メタデータが伝送されない場合には、データユニットヘッダにおいてＭＰ４構成情報を示さない。
データユニットヘッダにおいてＭＰ４構成情報を示さない方法としては、例えば下記の方法を用いることができる。
１．送信装置は、ＭＰ４構成情報をｒｅｓｅｒｖｅｄとし、運用しない。これにより、ＭＰ４構成情報を生成する送出側の処理量（送信装置の処理量）を削減することができる。
２．送信装置は、ＭＰ４構成情報を削除し、ヘッダ圧縮する。これにより、ＭＰ４構成情報を生成する送出側の処理量を削減することができるとともに、伝送容量を削減することができる。
なお、送信装置は、ＭＰ４構成情報を削除し、ヘッダ圧縮する場合には、ＭＰ４構成情報を削除（圧縮）したことを示すフラグを示してもよい。フラグは、ヘッダ（ＭＭＴＰパケットヘッダ、ＭＭＴＰペイロードヘッダ、データユニットヘッダ）または制御情報などに示される。
また、メタデータが伝送されるかどうかの情報は、あらかじめ定めていてもよいし、別途ヘッダや制御情報にシグナリングし、受信装置に伝送されてもよい。
例えば、ＭＦＵヘッダに当該ＭＦＵに対応するメタデータが伝送されているかの情報が格納されてもよい。
一方、受信装置は、メタデータが伝送されているかどうかに基づいて、ＭＰ４構成情報が示されているかどうかを判定することができる。
ここで、データの送信順序（例えば、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータのような順序）が決まっている場合は、受信装置は、メディアデータの前にメタデータが受信されたかどうかに基づいて判定してもよい。
ＭＰ４構成情報が示されている場合には、受信装置は、ＭＰ４構成情報をＭＰ４の再構成に用いることができる。或いは、受信装置は、その他のアクセスユニットやＮＡＬユニットの先頭の検出などにＭＰ４構成情報を用いることができる。
なお、ＭＰ４構成情報は、ｔｉｍｅｄ−ＭＦＵヘッダの全部であってもよいし一部であってもよい。
また、送信装置は、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵヘッダにおいても同様に、メタデータが伝送されるかどうかに基づいて、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵヘッダにおいてｉｔｅｍ ｉｄを示すかどうかを決定してもよい。
送信装置は、ｔｉｍｅｄ−ＭＦＵと、ｎｏｎ−ｔｉｍｅｄ−ＭＦＵとのどちらか一方においてのみＭＰ４構成情報を示すとしてもよい。どちらか一方にのみＭＰ４構成情報を示す場合、送信装置は、メタデータが伝送されるかどうかに加え、ｔｉｍｅｄ−ＭＦＵかｎｏｎ−ｔｉｍｅｄ−ＭＦＵかどうかに基づいてＭＰ４構成情報を示すかどうかを決定する。受信装置では、メタデータが伝送されるかどうか、および、ｔｉｍｅｄ／ｎｏｎ−ｔｉｍｅｄフラグに基づいてＭＰ４構成情報が示されるかどうかを判定することができる。
なお、以上の説明においては、送信装置は、メタデータ（ＭＰＵメタデータ及びＭＦメタデータの両方）が伝送されるかどうかに基づいてＭＰ４構成情報を示すかどうかを決定した。しかしながら、送信装置は、メタデータの一部（ＭＰＵメタデータ、ＭＦメタデータのどちらか一方）が伝送されない場合に、ＭＰ４構成情報を示さないとしてもよい。
また、送信装置は、メタデータ以外の他の情報に基づいてＭＰ４構成情報を示すかどうかを決定してもよい。
例えば、ＭＰ４サポートモード／ＭＰ４非サポートモードのようなモードが定義され、送信装置は、ＭＰ４サポートモードの場合には、データユニットヘッダにおいてＭＰ４構成情報を示し、ＭＰ４非サポートモードの場合には、データユニットヘッダにおいてＭＰ４構成情報を示さないとしてもよい。また、送信装置は、ＭＰ４サポートモードの場合には、メタデータを伝送し、かつデータユニットヘッダにおいてＭＰ４構成情報を示し、ＭＰ４非サポートモードの場合には、メタデータを伝送せずにデータユニットヘッダにおいてもＭＰ４構成情報を示さないとしてもよい。
［送信装置の動作フロー］
次に、送信装置の動作フローについて説明する。図４９は、送信装置の動作フローである。
送信装置は、まず、メタデータを伝送するかどうかを判定する（Ｓ１００１）。送信装置は、メタデータを伝送すると判定した場合（Ｓ１００２でＹｅｓ）、ステップＳ１００３へ移行し、ＭＰ４構成情報を生成し、かつ、ヘッダに格納して伝送する（Ｓ１００３）。この場合、送信装置は、メタデータも生成し、かつ、伝送する。
一方、送信装置は、メタデータを伝送しないと判定した場合（Ｓ１００２でＮｏ）、ＭＰ４構成情報を生成せず、かつ、ヘッダにも格納せずに伝送する（Ｓ１００４）。この場合、送信装置は、メタデータを生成せず、伝送しない。
なお、ステップＳ１００１においてメタデータを伝送するかどうかは、あらかじめ定められていてもよいし、送信装置の内部でメタデータが生成されたかどうか、送信装置の内部でメタデータが伝送されているかどうかに基づいて判定されてもよい。
［受信装置の動作フロー］
次に、受信装置の動作フローについて説明する。図５０は、受信装置の動作フローである。
受信装置は、まず、メタデータが伝送されているかどうかを判定する（Ｓ１１０１）。メタデータが伝送されているかどうかは、ＭＭＴＰパケットペイロードにおけるフラグメントタイプを監視することにより判定できる。また、伝送されているかどうかがあらかじめ定められていてもよい。
受信装置は、メタデータが伝送されていると判定した場合（Ｓ１１０２でＹｅｓ）、ＭＰ４を再構成し、かつ、ＭＰ４構成情報を用いた復号処理を実行する（Ｓ１１０３）。一方、メタデータが伝送されていないと判定した場合（Ｓ１１０２でＮｏ）、ＭＰ４の再構成処理をせず、かつ、ＭＰ４構成情報を用いずに復号処理を実行する（Ｓ１１０４）。
なお、受信装置は、これまで説明した方法を用いて、ＭＰ４構成情報を用いずにランダムアクセスポイントの検出、アクセスユニット先頭の検出、ＮＡＬユニット先頭の検出などをすることが可能であり、復号処理、パケットロスの検出、及びパケットロスからの復帰の処理をすることができる。
例えば、アクセスユニット先頭は、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が１であるＭＭＴペイロードの先頭データである。このとき、Ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値は０である。
また、スライスセグメントの先頭は、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が０、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるＭＭＴペイロードの先頭データである。
受信装置は、以上のような情報に基づき、アクセスユニット先頭の検出、及び、スライスセグメントの検出を行うことができる。
なお、受信装置は、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるデータユニットの先頭を含むパケットにおいて、ＮＡＬユニットヘッダを解析し、ＮＡＬユニットの種類がＡＵデリミタであること、及び、ＮＡＬユニットの種類がスライスセグメントであることを検出してもよい。
［放送シンプルモード］
これまでは、放送ストリーム再生に特化したデータの送信方法として、受信装置におけるＭＰ４構成情報をサポートしない方法を説明したが、放送ストリーム再生に特化したデータの送信方法は、これに限るものではない。
放送ストリーム再生に特化したデータの送信方法として、例えば下記の方法が用いられてもよい。
・送信装置は、放送の固定受信環境では、ＡＬ−ＦＥＣを用いなくてもよい。ＡＬ−ＦＥＣが用いられない場合は、ＭＭＴＰパケットヘッダにおけるＦＥＣ＿ｔｙｐｅは常に０固定とされる。
・送信装置は、放送の移動受信環境、及び、通信ＵＤＰ伝送モードにおいては、常にＡＬ−ＦＥＣを用いてもよい。ＡＬ−ＦＥＣが用いられる場合は、ＭＭＴＰパケットヘッダにおけるＦＥＣ＿ｔｙｐｅは、常に０或いは１である。
・送信装置は、アセットのバルク伝送をしなくてもよい。アセットのバルク伝送がされない場合には、ＭＰＴ内部のアセットの伝送ローケーション数を示すｌｏｃａｔｉｏｎ＿ｉｎｆｏｌｏｃａｔｉｏｎは、１に固定されてよい。
・送信装置は、アセット、プログラム、及びメッセージのハイブリッド伝送をしなくてもよい。
また、例えば、放送シンプルモードが規定され、送信装置は、放送シンプルモードである場合には、ＭＰ４非サポートモードとする、或いは、上記に示した放送ストリーム再生に特化したデータの送信方法を用いるとしてもよい。放送シンプルモードかどうかはあらかじめ定められていてもよいし、送信装置は、放送シンプルモードであることを示すフラグを制御情報として格納し、受信装置に伝送してもよい。
また、送信装置は、図４９で説明した、ＭＰ４非サポートモードであるかどうか（メタデータが伝送されているかどうか）に基づいて、ＭＰ４非サポートモードである場合には、放送シンプルモードとして、上記に示した放送ストリーム再生に特化したデータの送信方法を用いてもよい。
受信装置は、放送シンプルモードである場合には、ＭＰ４非サポートモードであるとして、ＭＰ４を再構成せず復号処理をすることができる。
また、受信装置は、放送シンプルモードである場合には、放送に特化した機能であることを判定し、放送に特化して受信処理をすることができる。
これにより、放送シンプルモードである場合には、放送に特化した機能のみを用いることにより、送信装置及び受信装置にとって不要な処理を削減できるばかりでなく、不要な情報を圧縮して伝送しないことにより、伝送オーバーヘッドを削減することができる。
なお、ＭＰ４非サポートモードが用いられる場合には、ＭＰ４構成以外の蓄積方法をサポートするヒント情報が示されてもよい。
ＭＰ４構成以外の蓄積方法としては、例えば、ＭＭＴパケットやＩＰパケットをダイレクトに蓄積する方法や、ＭＭＴパケットをＭＰＥＧ−２ ＴＳパケットに変換する方法などがある。
なお、ＭＰ４非サポートモードの場合には、ＭＰ４構成にしたがわないフォーマットが用いられてもよい。
例えば、ＭＦＵに格納されるデータは、ＭＰ４非サポートモードの場合には、ＭＰ４形式であるＮＡＬユニットの先頭にＮＡＬユニットのサイズがついた形式でなく、バイトスタートコードがついた形式にされてもよい。
ＭＭＴでは、アセットのタイプを示すアセットタイプは、ＭＰ４ＲＥＧ（ｈｔｔｐ：／／ｗｗｗ．ｍｐ４ｒａ．ｏｒｇ）に登録される４ＣＣで記載され、映像信号としてＨＥＶＣを用いる場合、’ＨＥＶ１’または’ＨＶＣ１’が用いられる。’ＨＶＣ１’は、サンプルの中にパラメータセットを含んでもよい形式であり、’ＨＥＶ１’はサンプルの中にパラメータセットを含まず、ＭＰＵメタデータにおけるサンプルエントリにパラメータセットを含む形式である。
放送シンプルモードまたはＭＰ４非サポートモードの場合において、ＭＰＵメタデータ及びＭＦメタデータが伝送されない場合には、必ずサンプルの中にパラメータセットを含めると規定されてもよい。また、アセットタイプに’ＨＥＶ１’と’ＨＶＣ１’のどちらが示されている場合にも、必ず’ＨＶＣ１’の形式をとると規定されてもよい。
［補足１：送信装置］
以上のように、メタデータが送信されていない場合に、ＭＰ４構成情報をｒｅｓｅｒｖｅｄとし、運用しない送信装置は、図５１のように構成することも可能である。図５１は、送信装置の具体的構成の例を示す図である。
送信装置３００は、符号化部３０１と、付与部３０２と、送信部３０３とを備える。符号化部３０１、付与部３０２、及び送信部３０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
符号化部３０１は、映像信号または音声信号を符号化してサンプルデータを生成する。サンプルデータは、具体的には、データユニットである。
付与部３０２は、映像信号または音声信号が符号化されたデータであるサンプルデータに、ＭＰ４構成情報を含むヘッダ情報を付与する。ＭＰ４構成情報は、受信側において当該サンプルデータをＭＰ４フォーマットのファイルとして再構成するための情報であって、サンプルデータの提示時刻が定められているか否かに応じて内容が異なる情報である。
上述のように、付与部３０２は、提示時刻が定められているサンプルデータ（同期に関する情報を含むサンプルデータ）の一例であるｔｉｍｅｄ−ＭＦＵのヘッダ（ヘッダ情報）に、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ｓａｍｐｌｅ＿ｎｕｍｂｅｒ、ｏｆｆｓｅｔ、ｐｒｉｏｒｉｔｙ、及び、ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒなどのＭＰ４構成情報を含める。
一方で、付与部３０２は、提示時刻が定められていないサンプルデータ（同期に関する情報を含まないサンプルデータ）の一例である、ｔｉｍｅｄ−ＭＦＵのヘッダ（ヘッダ情報）には、ｉｔｅｍ＿ｉｄなどのＭＰ４構成情報を含める。
そして、付与部３０２は、送信部３０３によってサンプルデータに対応するメタデータが送信されない場合（例えば、図２１の（ｂ）のような場合）には、サンプルデータの提示時刻が定められているか否かに応じて、ＭＰ４構成情報を含まないヘッダ情報をサンプルデータに付与する。
付与部３０２は、具体的には、サンプルデータの提示時刻が定められている場合には、第一のＭＰ４構成情報を含まないヘッダ情報をサンプルデータに付与し、サンプルデータの提示時刻が定められていない場合には、第二のＭＰ４構成情報を含むヘッダ情報を前記サンプルデータに付与する。
例えば、付与部３０２は、図４９のステップＳ１００４に示されるように、送信部３０３によってサンプルデータに対応するメタデータが送信されない場合には、ＭＰ４構成情報をｒｅｓｅｒｖｅｄ（固定値）とすることにより、ＭＰ４構成情報を実質的に生成せず、かつ、実質的にヘッダ（ヘッダ情報）に格納しない。なお、メタデータには、ＭＰＵメタデータ、及び、ムービーフラグメントメタデータが含まれる。
送信部３０３は、ヘッダ情報が付与されたサンプルデータを送信する。送信部３０３は、より具体的には、ヘッダ情報が付与されたサンプルデータをＭＭＴ方式でパケット化して送信する。
上述のように、放送ストリームの再生に特化した送信方法及び受信方法では、受信装置でデータユニットをＭＰ４に再構成する必要はない。受信装置がＭＰ４に再構成する必要がない場合、ＭＰ４構成情報などの不要な情報を生成しないことで送信装置の処理は軽減される。
一方で、送信装置は、必要な情報は送らなくてはならないが、余計な追加情報などを別途送信しなくて済むように、規格との整合性は保つ必要がある。
送信装置３００のような構成によれば、ＭＰ４構成情報が格納される領域を固定値にすることなどにより、ＭＰ４構成情報を送信せず、必要な情報のみを規格に基づいて送信し、余計な追加情報を送信しなくて済む効果が得られる。つまり、送信装置の構成及び送信装置の処理量を削減することができる。また、不要なデータが送信されないことにより、伝送効率を向上させることができる。
［補足２：受信装置］
また、送信装置３００に対応する受信装置は、例えば、図５２のように構成されてもよい。図５２は、受信装置の構成の別の例を示す図である。
受信装置４００は、受信部４０１と、復号部４０２とを備える。受信部４０１、及び、復号部４０２は、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信部４０１は、映像信号または音声信号が符号化されたデータであるサンプルデータであって、当該サンプルデータをＭＰ４フォーマットのファイルとして再構成するためのＭＰ４構成情報を含むヘッダ情報が付与されたサンプルデータを受信する。
復号部４０２は、受信部によってサンプルデータに対応するメタデータが受信されなかった場合であって、サンプルデータの提示時刻が定められている場合に、ＭＰ４構成情報を使用せずにサンプルデータを復号する。
例えば、復号部４０２は、図５０のステップＳ１１０４に示されるように、受信部４０１によってサンプルデータに対応するメタデータが受信されない場合には、ＭＰ４構成情報を用いずに復号処理を実行する。
これにより、受信装置４００の構成及び受信装置４００における処理量を削減することができる。
（実施の形態４）
［概要］
実施の形態４では、ファイルなど同期に関する情報を含まない非同期（ｎｏｎ−ｔｉｍｅｄ）メディアのＭＰＵへの格納方法と、ＭＭＴＰパケットでの伝送方法について説明する。なお、実施の形態４では、ＭＭＴにおけるＭＰＵを例に説明するが、同じＭＰ４ベースであるＤＡＳＨでも適用可能である。
まず、ｎｏｎ−ｔｉｍｅｄメディア（以下、「非同期メディアデータ」とも言う）のＭＰＵへの格納方法の詳細について図５３を用いて説明する。図５３は、ｎｏｎ−ｔｉｍｅｄメディアのＭＰＵへの格納方法、及び、ＭＭＴＰパケットでの伝送方法を示す図である。
ｎｏｎ−ｔｉｍｅｄメディアを格納するＭＰＵは、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、ｍｅｔａなどのボックスで構成され、ＭＰＵに格納するファイルに関する情報が格納される。ｍｅｔａボックス内には複数のｉｄａｔボックスを格納することができ、ｉｄａｔボックスには１つのファイルがｉｔｅｍとして格納される。
ｆｔｙｐ，ｍｍｐｕ，ｍｏｏｖ，ｍｅｔａボックスの一部はＭＰＵメタデータとして一つのデータユニットを構成し、ｉｔｅｍ或いはｉｄａｔボックスはＭＦＵとしてデータユニットを構成する。
データユニットはアグリゲーションやフラグメントされた後、データユニットヘッダ、ＭＭＴＰペイロードヘッダ、及びＭＭＴＰパケットヘッダが付与されてＭＭＴＰパケットとして伝送される。
なお、図５３では、Ｆｉｌｅ＃１とＦｉｌｅ＃２とが１つのＭＰＵに格納される例を示している。ＭＰＵメタデータは分割されておらず、また、ＭＦＵは分割されてＭＭＴＰパケットに格納されているが、これに限るものではなく、データユニットのサイズに応じてアグリゲーションやフラグメントされてもよい。また、ＭＰＵメタデータは伝送されなくてもよく、その場合は、ＭＦＵのみが伝送される。
データユニットヘッダなどのヘッダ情報には、ｉｔｅｍＩＤ（アイテムを一意に特定する識別子）が示され、ＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダには、パケットシーケンス番号（パケット毎のシーケンス番号）、及び、ＭＰＵシーケンス番号（ＭＰＵのシーケンス番号、アセット内で一意の番号。）が含まれる。
なお、データユニットヘッダ以外のＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダのデータ構造はこれまで説明したｔｉｍｅｄメディア（以下、「同期メディアデータ」とも言う。）と同様であり、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ，ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ，ｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒなどが含まれる。
次に、ファイル（＝Ｉｔｅｍ＝ＭＦＵ）を分割してパケット化する場合のヘッダ情報の具体例をについて、図５４及び図５５を用いて説明する。
図５４及び図５５は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する例を示す図である。図５４及び図５５は、具体的には、分割されたＭＭＴＰパケット毎のヘッダ情報であるデータユニットヘッダ、ＭＭＴＰペイロードヘッダ、ＭＭＴＰパケットヘッダのいずれかに含まれる情報（パケットシーケンス番号、フラグメントカウンタ、フラグメンテーションインジケータ、ＭＰＵシーケンス番号、アイテムＩＤ）を示す。なお、図５４は、Ｆｉｌｅ＃１がＭ個（Ｍ＜＝２５６）に分割される例を示す図であり、図５５は、Ｆｉｌｅ＃２がＮ個（２５６＜Ｎ）に分割される例を示す図である。
分割データ番号は、ファイル先頭からの分割データのインデックスを示しており、この情報は伝送されない。つまり、分割データ番号は、ヘッダ情報には含まれない。また、分割データ番号は、ファイルを分割することにより得られた複数の分割データのそれぞれに対応するパケットに付与される番号であり、先頭のパケットから昇順に１ずつ加算されて付与される番号である。
パケットシーケンス番号は、同じパケットＩＤを持つパケットのシーケンス番号であり、図５４及び図５５では、ファイル先頭の分割データをＡとして、ファイル最後の分割データまで連続した番号が付与される。パケットシーケンス番号は、ファイル先頭の分割データから昇順に１ずつ加算されて付与される番号であり、分割データ番号に対応する番号である。
フラグメントカウンタは、１つのファイルが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある複数の分割データの数を示す。また、フラグメントカウンタは、１つのファイルを分割することにより得られた複数の分割データの数である分割データ数が２５６を超える場合、分割データ数を２５６で除した余りを示す。図５４の例では、分割データ数が２５６以下であるため、フラグメントカウンタのフィールド値は（Ｍ−分割データ番号）となる。一方、図５５の例では、分割データ数が２５６を超えるため、（Ｎ−分割データ番号）を２５６で除した値（（Ｎ−分割データ番号）％２５６）となる。
なお、フラグメンテーションインジケータは、ＭＭＴＰパケットに格納するデータの分割の状態を示し、分割されたデータユニットにおける先頭の分割データであるか、最後の分割データであるか、それ以外の分割データであるか、或いは、分割されていない１つ以上のデータユニットであるかを示す値である。具体的には、フラグメンテーションインジケータは、先頭の分割データでは「０１」であり、最後の分割データでは「１１」であり、残りの分割データでは「１０」であり、分割されていないデータユニットでは「００」である。
本実施の形態では、分割データ数が２５６を超える場合、分割データ数を２５６で除した余りを示すとして説明するが、分割データ数は２５６に限らず、他の数（所定の数）であってもよい。
図５４及び図５５に示すようにファイルを分割し、ファイルを分割することにより得られた複数の分割データのそれぞれに従来のヘッダ情報を付与して伝送する場合、受信装置において、受信したＭＭＴＰパケットに格納されるデータが、元のファイルにおいて何番目の分割データであるか（分割データ番号）、及び、ファイルの分割データ数、または、分割データ番号及び分割データ数を導出できる情報がない。このため、従来の伝送方法では、ＭＭＴＰパケットを受信しても、受信したＭＭＴＰパケットに格納されるデータの分割データ番号や分割データ数を一意に検出することができない。
例えば、図５４のように分割データ数が２５６以下であり、分割データ数があらかじめ２５６以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。しかし、分割データ数が２５６以上である場合には、分割データ番号や分割データ数を特定できない。
なお、ファイルの分割データ数を２５６以下に制限する場合、１つのパケットで伝送可能なデータサイズをｘ［ｂｙｔｅｓ］とした場合、伝送可能なファイルの最大サイズは ｘ ＊ ２５６［ｂｙｔｅｓ］に制限される。例えば、放送ではｘ＝４ｋ［ｂｙｔｅｓ］が想定されており、この場合、伝送可能なファイルの最大サイズは４ｋ＊２５６＝１Ｍ［ｂｙｔｅｓ］に制限される。従って、１［Ｍｂｙｔｅｓ］を越えるファイルを伝送したい場合にはファイルの分割データ数を２５６以下に制限することはできない。
また、例えば、フラグメンテーションインジケータを参照することでファイルの先頭の分割データや最後の分割データを検出することができるため、ファイルの最後の分割データを含むＭＭＴＰパケットが受信されるまでＭＭＴＰパケット数をカウントしたり、ファイルの最後の分割データを含むＭＭＴＰパケットを受信したりした後に、パケットシーケンス番号と組み合わせることにより、分割データ番号や分割データ数を算出することは可能であるため、フラグメンテーションインジケータとパケットシーケンス番号とを組み合わせることにより分割データ番号及び分割データ数をシグナリングするとしてもよい。しかし、ファイルの途中の分割データ（つまり、ファイルの先頭の分割データでもファイルの最後の分割データでもない分割データ）を含むＭＭＴＰパケットから受信を開始した場合、当該分割データの分割データ番号や分割データ数を特定できない。当該分割データの分割データ番号や分割データ数は、ファイル最後の分割データを含むＭＭＴＰパケットを受信後に初めて特定できる。
図５４及び図５５で説明した課題、つまり、ファイルの分割データを含むパケットを途中から受信した時点で、ファイルの分割データの分割データ番号および分割データ数を一意に決定するために、次の方法を用いる。
まず、分割データ番号について説明する。
分割データ番号については、ファイル（ｉｔｅｍ）の先頭の分割データにおけるパケットシーケンス番号をシグナリングする。
シグナリングする方法として、ファイルを管理する制御情報に格納する。具体的には、図５４及び図５５においてファイルの先頭の分割データのパケットシーケンス番号Ａを、制御情報に格納する。受信装置では、制御情報よりＡの値を取得し、パケットヘッダに示されるパケットシーケンス番号より分割データ番号を算出する。
分割データの分割データ番号は、当該分割データのパケットシーケンス番号から先頭の分割データのパケットシーケンス番号Ａを減ずることにより求められる。
ファイルを管理する制御情報としては、例えば、ＡＲＩＢ ＳＴＤ−Ｂ６０に規定されるアセット管理テーブルがある。アセット管理テーブルには、ファイル毎に、ファイルサイズやバージョン情報などが示され、データ伝送メッセージに格納されて伝送される。図５６は、アセット管理テーブルにおけるファイル毎のループのシンタックスを示す図である。
既存のアセット管理テーブルの領域が拡張できない場合には、アイテムの情報を示すｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅフィールドの一部の３２ｂｉｔの領域を用いてシグナリングしてもよい。ｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅの一部領域に、ファイル（ｉｔｅｍ）の先頭の分割データにおけるパケットシーケンス番号が示されているかどうかを示すフラグを制御情報の例えばｒｅｓｅｒｖｅｄ＿ｆｕｔｕｒｅ＿ｕｓｅフィールドに示してもよい。
データカルーセルなどファイルを繰り返し伝送する場合には、複数のパケットシーケンス番号を示してもよいし、直後に伝送するファイルの先頭のパケットシーケンス番号を示してもよい。
ファイル先頭の分割データのパケットシーケンス番号に限らず、ファイルの分割データ番号とパケットシーケンス番号を紐づける情報であればよい。
次に、分割データ数について説明する。
アセット管理テーブルに含まれるファイル毎のループの順番を、ファイルの伝送順と規定してもよい。これにより、伝送順で連続する２つのファイルの先頭のパケットシーケンス番号がわかるため、後に伝送されるファイルの先頭パケットシーケンス番号から前に伝送されるファイルの先頭パケットシーケンス番号を減ずることにより、前に伝送されるファイルの分割データ数を特定することができる。つまり、例えば、図５４に示すＦｉｌｅ＃１と図５５に示すＦｉｌｅ＃２とがこの順に連続したファイルである場合には、Ｆｉｌｅ＃１の最後のパケットシーケンス番号とＦｉｌｅ＃２の先頭のパケットシーケンス番号とは連続した番号が付与されている。
また、ファイルの分割方法を規定することにより、ファイルの分割データ数を特定できるように規定してもよい。例えば、分割データ数がＮの場合、１〜（Ｎ−１）番目の分割データのそれぞれのサイズはＬとし、Ｎ番目の分割データのサイズは端数（ｉｔｅｍ＿ｓｉｚｅ−Ｌ＊（Ｎ−１））と規定することにより、アセット管理テーブルに示されるｉｔｅｍ＿ｓｉｚｅから分割データ数を逆算できる。この場合、（ｉｔｅｍ＿ｓｉｚｅ ／ Ｌ）を切り上げた整数値が分割データ数となる。なお、ファイルの分割方法は、これに限るものではない。
また、分割データ数を直接アセット管理テーブルに格納してもよい。
受信装置では、上記の方法を用いることにより、制御情報を受信し、制御情報に基づいて分割データ数を算出する。また、制御情報に基づいてファイルの分割データ番号に対応するパケットシーケンス番号を算出できる。なお、制御情報の受信のタイミングより、分割データのパケットの受信のタイミングが早い場合は、制御情報を受信したタイミングで分割データ番号や分割データ数を算出してもよい。
なお、上記方法を用いて分割データ番号、或いは分割データ数をシグナリングする場合、フラグメントカウンタに基づいて分割データ番号や分割データ数を特定することはなく、フラグメントカウンタは不要なデータとなる。そこで、非同期メディアの伝送において、上記方法等を用いて分割データ番号、および、分割データ数を特定できる情報がシグナリングされている場合には、フラグメントカウンタは運用しない、或いは、ヘッダ圧縮してもよい。これにより、送信装置や受信装置の処理量を削減することができ、伝送効率を向上させることもできる。つまり、非同期メディアを送信する場合には、フラグメントカウンタをｒｅｓｅｒｖｅｄ（無効化）としてもよい。具体的には、フラグメントカウンタの値を例えば「０」の固定値としてもよい。また、非同期メディアを受信する場合には、フラグメントカウンタを無視してもよい。
映像や音声などの同期メディアを格納する場合においては、送出装置におけるＭＭＴＰパケットの送信順と受信装置におけるＭＭＴＰパケットの到着順が一致しており、かつ、パケットが再送されない。このような場合において、パケットロスを検出して再構成する必要がない場合には、フラグメントカウンタを運用しないとしてもよい。言い換えると、この場合では、フラグメントカウンタをｒｅｓｅｒｖｅｄ（無効化）としてもよい。
また、フラグメントカウンタを用いなくても、ランダムアクセスポイントの検出、アクセスユニット先頭の検出、ＮＡＬユニット先頭の検出などをすることが可能であり、復号処理や、パケットロスの検出、パケットロスからの復帰の処理をすることができる。
また、ライブ放送などのリアルタイムなコンテンツの伝送では、より低遅延な伝送が求められ、符号化が完了したデータから順次パケット化して送出することが求められる。しかし、リアルタイムなコンテンツの伝送において、従来のフラグメントカウンタでは、先頭の分割データの送出時に分割データ数は決定できないため、先頭の分割データの送出は、データユニットの符号化がすべて完了し、分割データ数が決定した後となり、遅延が発生する。このような場合であっても、上記の方法を用いて、フラグメントカウンタを運用しないことにより、この遅延を削減できる。
図５７は、受信装置における分割データ番号を特定する動作フローである。
受信装置は、ファイルの情報が記載された制御情報を取得する（Ｓ１２０１）。受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されているかどうかを判定し（Ｓ１２０２）、制御情報にファイル先頭のパケットシーケンス番号が示されている場合には（Ｓ１２０２でＹｅｓ）、ファイルの分割データの分割データ番号に対応するパケットシーケンス番号を算出する（Ｓ１２０３）。そして、受信装置は、分割データが格納されたＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるパケットシーケンス番号からファイルの分割データ番号を特定する（Ｓ１２０４）。一方、受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されていない場合には（Ｓ１２０２でＮｏ）、ファイル最後の分割データが含まれるＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ番号を特定する（Ｓ１２０５）。
図５８は、受信装置における分割データ数を特定する動作フローである。
受信装置は、ファイルの情報が記載された制御情報を取得する（Ｓ１３０１）。受信装置は、制御情報にファイルの分割データ数を算出可能な情報が含まれているかどうかを判定し（Ｓ１３０２）、分割データ数を算出可能な情報が含まれていると判定した場合には、（Ｓ１３０２でＹｅｓ）、制御情報に含まれる情報に基づいて分割データ数を算出する（Ｓ１３０３）。一方、受信装置は、分割データ数を算出不可能であると判定した場合には（Ｓ１３０２でＮｏ）、ファイル最後の分割データが含まれるＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ数を特定する（Ｓ１３０４）。
図５９は、送信装置においてフラグメントカウンタを運用するかどうかを決定するための動作フローである。
まず、送信装置は、伝送するメディア（以下、「メディアデータ」とも言う。）が同期メディアか、非同期メディアかを判定する（Ｓ１４０１）。
ステップＳ１４０１での判定の結果が同期メディアである場合（Ｓ１４０２で同期メディア）、送信装置は、同期メディアを伝送する環境において送受信のＭＭＴＰパケット順が一致し、かつパケットロス時にパケット再構成が不要かどうかを判定する（Ｓ１４０３）。送信装置は、不要であると判定した場合（Ｓ１４０３でＹｅｓ）、フラグメントカウンタを運用しない（Ｓ１４０４）。一方、送信装置は、不要でないと判定した場合（Ｓ１４０３でＮｏ）、フラグメントカウンタを運用する（Ｓ１４０５）。
ステップＳ１４０１での判定の結果が非同期メディアである場合（Ｓ１４０２で非同期メディア）、送信装置は、上述で説明した方法を用いて分割データ番号や分割データ数がシグナリングされるかどうかに基づいて、フラグメントカウンタを運用するか否かを決定する。具体的には、送信装置は、分割データ番号や分割データ数がシグナリングされる場合（Ｓ１４０６でＹｅｓ）、フラグメントカウンタを運用しない（Ｓ１４０４）。一方、送信装置は、分割データ番号や分割データ数がシグナリングされない場合（Ｓ１４０６でＮｏ）、フラグメントカウンタを運用する（Ｓ１４０５）。
なお、送信装置は、フラグメントカウンタを運用しない場合、フラグメントカウンタの値をｒｅｓｅｒｖｅｄとしてもよいし、ヘッダ圧縮をしてもよい。
なお、送信装置は、フラグメントカウンタを運用するかどうかに基づいて、上述した分割データ番号や分割データ数をシグナリングするかどうかを決定してもよい。
なお、送信装置は、同期メディアがフラグメントカウンタを運用しない場合には、非同期メディアにおいて上述した方法を用いて分割データ番号や分割データ数をシグナリングしてもよい。逆に、非同期メディアがフラグメントカウンタを運用するかどうかに基づいて、同期メディアの運用を決定してもよい。この場合、同期メディアと非同期メディアとにおいて、フラグメントを運用するかどうかを同じ運用とすることができる。
次に、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明する。図６０は、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明するための図である。
図５４を用いて説明したように、分割データ数が２５６以下であり、分割データ数があらかじめ２５６以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。
ファイルの分割データ数を２５６以下に制限する場合、１つのパケットで伝送可能なデータサイズをｘ［ｂｙｔｅｓ］とした場合、伝送可能なファイルの最大サイズはｘ＊２５６［ｂｙｔｅｓ］に制限される。例えば、放送ではｘ＝４ｋ［ｂｙｔｅｓ］が想定されており、この場合、伝送可能なファイルの最大サイズは４ｋ＊２５６＝１Ｍ［ｂｙｔｅｓ］に制限される。
ファイルサイズが、伝送可能なファイルの最大サイズを超える場合、分割ファイルのサイズがｘ＊２５６［ｂｙｔｅｓ］以下となるように予めファイルを分割する。ファイルが分割することにより得られた複数の分割ファイルのそれぞれは、一つのファイル（ｉｔｅｍ）として扱われ、さらに２５６以内に分割され、さらに分割されることにより得られた分割データがそれぞれＭＭＴＰパケットに格納されて伝送される。
なお、アイテムが分割ファイルであることを示す情報や、分割ファイル数、分割ファイルのシーケンス番号を制御情報に格納し、受信装置に送信してもよい。また、これらの情報をアセット管理テーブルに格納してもよいし、既存のフィールドｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅの一部を用いて示してもよい。
受信装置は、アイテムが１つのファイルを分割することにより得られた複数の分割ファイルのうちの１つの分割ファイルである場合には、他の分割ファイルを特定し、元のファイルを再構成することができる。また、受信装置では、制御情報における分割ファイルの分割ファイル数、分割ファイルのインデックス、および、フラグメントカウンタを用いることにより、分割データ数や、分割データ番号を一意に特定することができる。また、パケットシーケンス番号などを用いることなく分割データ数や分割データ番号を一意に特定できる。
ここで、１つのファイルを分割することにより得られた複数の分割ファイルそれぞれのｉｔｅｍ＿ｉｄは、互いに同じであることが望ましい。なお、別のｉｔｅｍ＿ｉｄを付与する場合は、他の制御情報などからファイルを一意に参照するために、先頭の分割ファイルのｉｔｅｍ＿ｉｄを示すとしてもよい。
また、複数の分割ファイルは、必ず同じＭＰＵに属するとしてもよい。ＭＰＵに複数のファイルを格納する場合には、異なる種類のファイルは格納せず、必ず１つのファイルを分割したファイルが格納されているとしてもよい。受信装置はｉｔｅｍ毎のバージョン情報を確認せずとも、ＭＰＵ毎のバージョン情報を確認することで、ファイルの更新を検知できる。
図６１は、フラグメントカウンタを活用する場合の送信装置の動作フローである。
まず、送信装置は、伝送するファイルのサイズを確認する（Ｓ１５０１）。次に送信装置は、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］（ｘは、１つのパケットで伝送できるデータサイズ。例えば、ＭＴＵサイズ。）を超えるか否かを判定し（Ｓ１５０２）、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］を超える場合には（Ｓ１５０２でＹｅｓ）、分割ファイルのサイズがｘ＊２５６［ｂｙｔｅｓ］未満となるようにファイルを分割する（Ｓ１５０３）。そして、分割ファイルをアイテムとして伝送し、分割ファイルに関する情報（例えば、分割ファイルであること、分割ファイルにおけるシーケンス番号など）を制御情報に格納して伝送する（Ｓ１５０４）。一方、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］未満である場合には（Ｓ１５０２でＮｏ）、通常通りファイルをアイテムとして伝送する（Ｓ１５０５）。
図６２は、フラグメントカウンタを活用する場合の受信装置の動作フローである。
まず、受信装置は、アセット管理テーブルなどのファイルの伝送に関する制御情報を取得、解析する（Ｓ１６０１）。次に、受信装置は、所望のアイテムが分割ファイルであるかどうかを判定する（Ｓ１６０２）。受信装置は、所望のファイルが分割ファイルであると判定した場合には（Ｓ１６０２でＹｅｓ）、分割ファイルや分割ファイルのインデックスなど、ファイルを再構成するための情報を制御情報から取得する（Ｓ１６０３）。そして、受信装置は、分割ファイルを構成するアイテムを取得し、元のファイルを再構成する（Ｓ１６０４）。一方、受信装置は、所望のファイルが分割ファイルでないと判定した場合（Ｓ１６０２でＮｏ）、通常通りファイルを取得する（Ｓ１６０５）。
要するに、送信装置は、ファイル先頭の分割データのパケットシーケンス番号をシグナリングする。また、送信装置は、分割データ数を特定できる情報をシグナリングする。或いは、送信装置は、分割データ数を特定できる分割ルールを規定する。また、送信装置は、フラグメントカウンタを運用せずに、ｒｅｓｅｒｖｅｄ或いはヘッダ圧縮する。
受信装置は、ファイル先頭のデータのパケットシーケンス番号がシグナリングされている場合には、ファイル先頭の分割データのパケットシーケンス番号と、ＭＭＴＰパケットのパケットシーケンス番号から、分割データ番号や分割データ数を特定する。
別の観点では、送信装置は、ファイルを分割し、分割ファイル毎にデータを分割して送信する。分割ファイルを紐づける情報（シーケンス番号、分割数など）をシグナリングする。
受信装置は、フラグメントカウンタ、及び分割ファイルのシーケンス番号により、分割データ番号や分割データ数を特定する。
これにより、分割データ番号や分割データを一意に特定できる。また、途中の分割データを受信した時点で当該分割データの分割データ番号を特定できるため、待機時間を削減し、メモリも削減できる。
また、フラグメントカウンタを運用しないことにより、送受信装置の構成は処理量を削減することができる、また、伝送効率を向上させることができる。
図６３は、同一番組を複数のＩＰデータフローで送信する場合のサービス構成を示す図である。ここでは、サービスＩＤ＝２の番組の一部（映像・音声）のデータがＭＭＴ方式を用いたＩＰデータフローで送信され、同じサービスＩＤであり、当該一部のデータとは異なるデータが高度ＢＳデータ伝送方式を用いたＩＰデータフロー（この例ではファイル伝送プロトコルも異なるが同じプロトコルであってもよい。）で送信される例を示している。
送信装置は、受信装置において、複数のＩＰデータフローから構成されるデータが、復号時刻までに揃うことを保証できるように、ＩＰデータの多重化を行う。
受信装置は、複数のＩＰデータフローから構成されるデータを用いて、復号時刻に基づいて処理することにより、保証された受信機動作を実現することができる。
［補足：送信装置及び受信装置］
以上のように、フラグメントカウンタを運用せずにデータの送信を行う送信装置は、図６４のように構成することも可能である。また、フラグメントカウンタを運用せずにデータの受信を行う受信装置は、図６５のように構成することも可能である。図６４は、送信装置の具体的構成の例を示す図である。図６５は、受信装置の具体的構成の例を示す図である。
送信装置５００は、分割部５０１と、構成部５０２と、送信部５０３とを備える。分割部５０１、構成部５０２、及び送信部５０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置６００は、受信部６０１と、判定部６０２と、構成部６０３とを備える。受信部６０１、判定部６０２、及び構成部６０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置５００及び受信装置６００の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法について、図６６を用いて説明する。図６６は、送信装置による動作フロー（送信方法）である。
まず、送信装置５００の分割部５０１は、データを複数の分割データに分割する（Ｓ１７０１）。
次に、送信装置５００の構成部５０２は、複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、複数のパケットを構成する（Ｓ１７０２）。
そして、送信装置５００の送信部５０３は、構成された前記複数のパケットを送信する（Ｓ１７０３）。送信部５０３は、分割データ情報、および、無効化されたフラグメントカウンタの値を、送信する。なお、分割データ情報は、分割データ番号と、分割データ数とを特定するための情報である。また、分割データ番号は、当該分割データが複数の分割データのうちの何番目の分割データであるかを示す番号である。分割データ数は、複数の分割データの数である。
これにより、送信装置５００の処理量を削減することができる。
次に、受信方法について、図６７を用いて説明する。図６７は、受信装置による動作フロー（受信方法）である。
まず、受信装置６００の受信部６０１は、複数のパケットを受信する（Ｓ１８０１）。
次に、受信装置６００の判定部６０２は、受信した複数のパケットから、分割データ情報が、当取得されたか否かを判定する（Ｓ１８０２）。
そして、受信装置６００の構成部６０３は、判定部６０２により、分割データ情報を取得したと判定された場合（Ｓ１８０２でＹｅｓ）、当該ヘッダ情報に含まれるフラグメントカウンタの値を使用せずに、受信した複数のパケットからデータを構成する（Ｓ１８０３）。
一方で、構成部６０３は、判定部６０２により、分割データ情報を取得していないと判定された場合（Ｓ１８０２でＮｏ）、当該ヘッダ情報に含まれるフラグメントカウンタの値を用いて、受信した複数のパケットからデータを構成してもよい（Ｓ１８０４）。
これにより、受信装置６００の処理量を削減することができる。
（その他の実施の形態）
以上、実施の形態に係る送信装置、受信装置、送信方法及び受信方法ついて説明したが、本発明は、この実施の形態に限定されるものではない。
また、上記実施の形態に係る送信装置及び受信装置に含まれる各処理部は典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。
また、集積回路化はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ又はプロセッサなどのプログラム実行部が、ハードディスク又は半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
言い換えると、送信装置及び受信装置は、処理回路（ｐｒｏｃｅｓｓｉｎｇ ｃｉｒｃｕｉｔｒｙ）と、当該処理回路に電気的に接続された（当該制御回路からアクセス可能な）記憶装置（ｓｔｏｒａｇｅ）とを備える。処理回路は、専用のハードウェア及びプログラム実行部の少なくとも一方を含む。また、記憶装置は、処理回路がプログラム実行部を含む場合には、当該プログラム実行部により実行されるソフトウェアプログラムを記憶する。処理回路は、記憶装置を用いて、上記実施の形態に係る送信方法又は受信方法を実行する。
さらに、本発明は上記ソフトウェアプログラムであってもよいし、上記プログラムが記録された非一時的なコンピュータ読み取り可能な記録媒体であってもよい。また、上記プログラムは、インターネット等の伝送媒体を介して流通させることができるのは言うまでもない。
また、上記で用いた数字は、全て本発明を具体的に説明するために例示するものであり、本発明は例示された数字に制限されない。
また、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェア又はソフトウェアが並列又は時分割に処理してもよい。
また、上記の送信方法又は受信方法に含まれるステップが実行される順序は、本発明を具体的に説明するために例示するためのものであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時（並列）に実行されてもよい。
以上、本発明の一つ又は複数の態様に係る送信装置、受信装置、送信方法及び受信方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つ又は複数の態様の範囲内に含まれてもよい。
本発明は、ビデオデータ及びオーディオデータなどのメディアトランスポートを行う装置又は機器に適用できる。
１５、１００、３００、５００ 送信装置
１６、１０１、３０１ 符号化部
１７、１０２ 多重化部
１８、１０４ 送信部
２０、２００、４００、６００ 受信装置
２１ パケットフィルタリング部
２２ 送信順序タイプ判別部
２３ ランダムアクセス部
２４、２１２ 制御情報取得部
２５ データ取得部
２６ 算出部
２７ 初期化情報取得部
２８、２０６ 復号命令部
２９、２０４Ａ、２０４Ｂ、２０４Ｃ、２０４Ｄ、４０２ 復号部
３０ 提示部
２０１ チューナー
２０２ 復調部
２０３ 逆多重化部
２０５ 表示部
２１１ タイプ判別部
２１３ スライス情報取得部
２１４ 復号データ生成部
３０２ 付与部
３０３、５０３ 送信部
４０１、６０１ 受信部
５０１ 分割部
５０２、６０３ 構成部
６０２ 判定部

Claims (4)

  1. ヘッダ情報に、データが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある分割データの数を示すフラグメントカウンタを含む複数のパケットを送信する送信方法であって、
    データを複数の分割データに分割する分割ステップと、
    前記複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、前記複数のパケットを構成する構成ステップと、
    構成された前記複数のパケットを送信する送信ステップと、を含み、
    前記送信ステップでは、（ｉ）当該分割データが前記複数の分割データのうちの何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定するための分割データ情報、および、（ｉｉ）固定値が設定され、無効化された前記フラグメントカウンタを、送信する
    送信方法。
  2. ヘッダ情報に、データが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある分割データの数を示すフラグメントカウンタを含む複数のパケットを受信する受信方法であって、
    前記複数のパケットを受信する受信ステップと、
    受信した前記複数のパケットから、データが分割されることにより得られた複数の分割データのうち当該パケットに含まれる分割データが何番目の分割データであるかを示す分割データ番号と前記複数の分割データの数である分割データ数とを特定するための分割データ情報が、取得されたか否かを判定する判定ステップと、
    前記判定ステップにおいて、前記分割データ情報を取得したと判定された場合、当該ヘッダ情報に含まれる固定値が設定された前記フラグメントカウンタを使用せずに、前記分割データ情報によって特定される前記分割データ番号と前記分割データ数とに基づいて、受信した前記複数のパケットから前記データを構成する構成ステップと、を含む
    受信方法。
  3. ヘッダ情報に、データが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある分割データの数を示すフラグメントカウンタを含む複数のパケットを送信する送信装置であって、
    データを複数の分割データに分割する分割部と、
    前記複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、前記複数のパケットを構成する構成部と、
    構成された前記複数のパケットを送信する送信部と、を備え、
    前記送信部は、（ｉ）当該分割データが前記複数の分割データのうちの何番目の分割データであるかを示す分割データ番号と、前記複数の分割データの数である分割データ数とを特定するための分割データ情報、および、（ｉｉ）固定値が設定され、無効化された前記フラグメントカウンタを、送信する
    送信装置。
  4. ヘッダ情報に、データが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある分割データの数を示すフラグメントカウンタを含む複数のパケットを受信する受信装置であって、
    前記複数のパケットを受信する受信部と、
    受信した前記複数のパケットから、データが分割されることにより得られた複数の分割データのうち当該パケットに含まれる分割データが何番目の分割データであるかを示す分割データ番号と前記複数の分割データの数である分割データ数とを特定するための分割データ情報が、取得されたか否かを判定する判定部と、
    前記判定部により、前記分割データ情報を取得したと判定された場合、当該ヘッダ情報に含まれる固定値が設定された前記フラグメントカウンタを使用せずに、前記分割データ情報によって特定される前記分割データ番号と前記分割データ数とに基づいて、受信した前記複数のパケットから前記データを構成する構成部と、を備える
    受信装置。
JP2015141708A 2014-08-06 2015-07-15 送信方法、受信方法、送信装置及び受信装置 Active JP6300114B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP15830286.9A EP3179730B1 (en) 2014-08-06 2015-07-29 Transmission method, reception method, transmission device, and reception device
PCT/JP2015/003812 WO2016021153A1 (ja) 2014-08-06 2015-07-29 送信方法、受信方法、送信装置及び受信装置
CN201580040893.5A CN106576188B (zh) 2014-08-06 2015-07-29 发送方法、接收方法、发送装置以及接收装置
US15/419,389 US10327000B2 (en) 2014-08-06 2017-01-30 Transmitting method for transmitting a plurality of packets including header information including divided data information and a value of an invalidated fragment counter

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201462033716P 2014-08-06 2014-08-06
US62/033,716 2014-08-06

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018024703A Division JP6440083B2 (ja) 2014-08-06 2018-02-15 送信方法、受信方法、送信装置及び受信装置

Publications (2)

Publication Number Publication Date
JP2016039629A JP2016039629A (ja) 2016-03-22
JP6300114B2 true JP6300114B2 (ja) 2018-03-28

Family

ID=55530348

Family Applications (6)

Application Number Title Priority Date Filing Date
JP2015141708A Active JP6300114B2 (ja) 2014-08-06 2015-07-15 送信方法、受信方法、送信装置及び受信装置
JP2018024703A Active JP6440083B2 (ja) 2014-08-06 2018-02-15 送信方法、受信方法、送信装置及び受信装置
JP2018057298A Active JP6369773B1 (ja) 2014-08-06 2018-03-23 送信方法、受信方法、送信装置及び受信装置
JP2018123738A Active JP6512500B2 (ja) 2014-08-06 2018-06-28 送信方法、受信方法、送信装置及び受信装置
JP2019063468A Active JP6655803B2 (ja) 2014-08-06 2019-03-28 送信方法、受信方法、送信装置及び受信装置
JP2020005386A Active JP6846653B2 (ja) 2014-08-06 2020-01-16 送信方法、受信方法、送信装置及び受信装置

Family Applications After (5)

Application Number Title Priority Date Filing Date
JP2018024703A Active JP6440083B2 (ja) 2014-08-06 2018-02-15 送信方法、受信方法、送信装置及び受信装置
JP2018057298A Active JP6369773B1 (ja) 2014-08-06 2018-03-23 送信方法、受信方法、送信装置及び受信装置
JP2018123738A Active JP6512500B2 (ja) 2014-08-06 2018-06-28 送信方法、受信方法、送信装置及び受信装置
JP2019063468A Active JP6655803B2 (ja) 2014-08-06 2019-03-28 送信方法、受信方法、送信装置及び受信装置
JP2020005386A Active JP6846653B2 (ja) 2014-08-06 2020-01-16 送信方法、受信方法、送信装置及び受信装置

Country Status (4)

Country Link
US (1) US10327000B2 (ja)
EP (1) EP3179730B1 (ja)
JP (6) JP6300114B2 (ja)
CN (1) CN106576188B (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102446181B1 (ko) * 2016-02-17 2022-09-22 삼성전자주식회사 멀티미디어 시스템에서 미디어 데이터를 송수신하는 방법 및 장치
US11122331B2 (en) 2016-06-30 2021-09-14 Sony Semiconductor Solutions Corporation Receiving device, transmitting device, and data processing method
CN109600795B (zh) * 2017-09-30 2021-09-28 智邦科技股份有限公司 A-msdu子帧的处理方法及无线网络存取装置
TWI725240B (zh) * 2017-09-30 2021-04-21 智邦科技股份有限公司 聚合媒體存取服務數據單元( a - m s d u ) 子訊框的處理方法及無線網路存取裝置
CN116228472A (zh) * 2019-05-21 2023-06-06 沃豪侍株式会社 信息处理系统
CN110955257B (zh) * 2019-12-17 2024-02-09 深圳市道通智能航空技术股份有限公司 一种多目标传输方法、系统及遥控设备、无人机
WO2021251886A1 (en) * 2020-06-09 2021-12-16 Telefonaktiebolaget Lm Ericsson (Publ) Providing semantic information with encoded image data
CN114040445B (zh) * 2021-11-08 2023-08-15 聚好看科技股份有限公司 一种数据传输方法及装置

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2001293783A1 (en) * 2000-09-29 2002-04-08 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for transmitting data
US7583664B2 (en) * 2004-12-28 2009-09-01 Michael Ho Techniques for transmitting and receiving traffic over advanced switching compatible switch fabrics
US7519054B2 (en) * 2005-01-27 2009-04-14 Intel Corporation Replication of multicast data packets in a multi-stage switching system
US20080056295A1 (en) * 2006-09-01 2008-03-06 Dne Technologies, Inc. Internet protocol quality of service apparatus and method
WO2012099427A2 (ko) * 2011-01-19 2012-07-26 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
BR112014007494B1 (pt) * 2011-09-29 2022-05-31 Sharp Kabushiki Kaisha Dispositivo de decodificação de imagem, método de decodificação de imagem, e dispositivo de codificação de imagem
US9319721B2 (en) * 2011-10-13 2016-04-19 Electronics And Telecommunications Research Institute Method of configuring and transmitting an MMT transport packet
KR20130040090A (ko) * 2011-10-13 2013-04-23 삼성전자주식회사 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법
TWI523497B (zh) * 2011-11-10 2016-02-21 Sony Corp Image processing apparatus and method
KR20130090824A (ko) * 2012-02-06 2013-08-14 한국전자통신연구원 이종망 네트워크에서 부호화된 미디어 데이터를 전송하는 시스템에 랜덤 액세스를 지원하는 엠엠티 애셋의 구조, 생성 방법 및 생성 장치
JP6222576B2 (ja) * 2012-03-21 2017-11-01 サン パテント トラスト 画像符号化方法、画像復号方法、画像符号化装置、画像復号装置、および画像符号化復号装置
US8942258B2 (en) * 2012-09-14 2015-01-27 International Business Machines Corporation Segmentation and reassembly of network packets for switched fabric networks
US9554146B2 (en) * 2012-09-21 2017-01-24 Qualcomm Incorporated Indication and activation of parameter sets for video coding
KR101484843B1 (ko) * 2013-04-19 2015-01-20 삼성전자주식회사 멀티미디어 전송 시스템에서 미디어 전송 패킷 전송 방법 및 장치
JP6571314B2 (ja) * 2013-06-18 2019-09-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法
JP2015015706A (ja) * 2013-07-03 2015-01-22 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ データ送信方法、データ再生方法、データ送信装置およびデータ再生装置
US9231993B2 (en) * 2013-09-06 2016-01-05 Lg Display Co., Ltd. Apparatus for transmitting encoded video stream and method for transmitting the same
US10264272B2 (en) * 2013-10-15 2019-04-16 Qualcomm Incorporated Device and method for scalable coding of video information
JP6652320B2 (ja) * 2013-12-16 2020-02-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置及び受信装置
JP6478153B2 (ja) * 2014-02-27 2019-03-06 日本放送協会 データ送出システム、受信装置、およびプログラム
JP5725235B1 (ja) * 2014-04-22 2015-05-27 ソニー株式会社 受信装置及び受信方法、並びに、送信装置及び送信方法
JP6558366B2 (ja) * 2014-06-10 2019-08-14 ソニー株式会社 送信装置、送信方法および受信装置
KR101875667B1 (ko) * 2014-06-30 2018-07-06 엘지전자 주식회사 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
JP6868802B2 (ja) * 2015-08-03 2021-05-12 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置

Also Published As

Publication number Publication date
JP2020074576A (ja) 2020-05-14
JP6512500B2 (ja) 2019-05-15
EP3179730A1 (en) 2017-06-14
US10327000B2 (en) 2019-06-18
JP6369773B1 (ja) 2018-08-08
JP2018129845A (ja) 2018-08-16
EP3179730A4 (en) 2017-08-09
JP2018110429A (ja) 2018-07-12
EP3179730B1 (en) 2021-10-06
JP2016039629A (ja) 2016-03-22
JP2019149804A (ja) 2019-09-05
JP6440083B2 (ja) 2018-12-19
CN106576188A (zh) 2017-04-19
CN106576188B (zh) 2020-08-04
US20170142425A1 (en) 2017-05-18
JP2018174577A (ja) 2018-11-08
JP6846653B2 (ja) 2021-03-24
JP6655803B2 (ja) 2020-02-26

Similar Documents

Publication Publication Date Title
JP6868802B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP6868838B2 (ja) 送信装置、受信装置、送信方法及び受信方法
JP6369773B1 (ja) 送信方法、受信方法、送信装置及び受信装置
JP2015119477A (ja) 送信方法、受信方法、送信装置及び受信装置
JP7359819B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP7361287B2 (ja) 送信方法及び送信装置
JP2020102866A (ja) 送信方法、受信方法、送信装置及び受信装置
WO2015093011A1 (ja) 送信方法、受信方法、送信装置及び受信装置
JP2023164690A (ja) 送信装置、受信装置、送信方法及び受信方法
JP2016152620A (ja) 送信方法、受信方法、送信装置及び受信装置
JP2016195380A (ja) 受信方法、受信装置及び送受信システム
WO2016021153A1 (ja) 送信方法、受信方法、送信装置及び受信装置
JP7257646B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP2016100892A (ja) 送信方法、受信方法、送信装置及び受信装置
JP2016111690A (ja) 送信方法、受信方法、送信装置及び受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171117

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20171117

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20171129

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171205

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171228

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180116

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180215

R151 Written notification of patent or utility model registration

Ref document number: 6300114

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151