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

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

Info

Publication number
JP7293433B2
JP7293433B2 JP2022032421A JP2022032421A JP7293433B2 JP 7293433 B2 JP7293433 B2 JP 7293433B2 JP 2022032421 A JP2022032421 A JP 2022032421A JP 2022032421 A JP2022032421 A JP 2022032421A JP 7293433 B2 JP7293433 B2 JP 7293433B2
Authority
JP
Japan
Prior art keywords
data
information
time
unit
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
JP2022032421A
Other languages
English (en)
Other versions
JP2022075737A (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 Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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
Priority claimed from JP2015212363A external-priority patent/JP6828991B2/ja
Priority claimed from JP2015212359A external-priority patent/JP6765802B2/ja
Priority claimed from JP2015212367A external-priority patent/JP6828992B2/ja
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2022075737A publication Critical patent/JP2022075737A/ja
Priority to JP2023094389A priority Critical patent/JP7500833B2/ja
Application granted granted Critical
Publication of JP7293433B2 publication Critical patent/JP7293433B2/ja
Priority to JP2024091487A priority patent/JP2024107125A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/38—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space
    • H04H60/40—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space for identifying broadcast time
    • 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/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/2365—Multiplexing of several video streams
    • 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/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • 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
    • 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/43072—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 multiple content streams on the same device
    • 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/4347—Demultiplexing of several video streams
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
    • 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/8547—Content authoring involving timestamps for synchronizing content

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Electric Clocks (AREA)

Description

本発明は、送信方法、受信方法、送信装置及び受信装置に関する。
放送及び通信サービスの高度化に伴い、８Ｋ（７６８０×４３２０ピクセル：以下では８Ｋ４Ｋとも呼ぶ）及び４Ｋ（３８４０×２１６０ピクセル：以下では４Ｋ２Ｋとも呼ぶ）などの超高精細な動画像コンテンツの導入が検討されている。受信装置は、受信した超高精細な動画像の符号化データを実時間で復号して表示する必要があるが、特に８Ｋなどの解像度の動画像は復号時の処理負荷が大きく、このような動画像を１つの復号器で、実時間で復号することは困難である。従って、複数の復号器を用いて復号処理を並列化することで、１つの復号器あたりの処理負荷を低減し、実時間処理を達成する方法が検討されている。
また、符号化データはＭＰＥＧ－２ ＴＳ（Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）又はＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）などの多重化方式に基づいて多重化されたうえで送信される。例えば、非特許文献１には、ＭＭＴに従って、符号化されたメディアデータをパケット毎に送信する技術が開示されている。
Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ － Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔ － Ｐａｒｔ１：ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ ＤＩＳ ２３００８－１
ところで、放送や通信サービスの高度化に伴い、８Ｋや４Ｋ（３８４０ｘ２１６０ピクセル）などの超高精細な動画コンテンツの導入が検討されている。ＭＭＴ／ＴＬＶ方式では、送信側の基準クロックをＲＦＣ ５９０５に規定される６４ビットのロングフォーマットＮＴＰに同期させ、基準クロックを基に、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）や、ＤＴＳ（Ｄｅｃｏｄｅ Ｔｉｍｅ Ｓｔａｍｐ）などのタイムスタンプを同期メディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置におけるシステムクロックを生成する。
しかしながら、このようなＭＭＴの伝送方式では、ＮＴＰなどの基準時刻情報にうるう秒調整が行なわれる場合、受信装置が受信したパケットに含まれる所定のデータユニットであるＭＰＵを、当該ＭＰＵに対応づけられたＤＴＳ又はＰＴＳに従っても復号又は提示を意図された時刻に行うことができないという課題がある。
本発明は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、受信装置が意図された時刻に所定のデータユニットを再生できる送信方法などを提供する。
上記目的を達成するために、本発明の一態様に係る送信方法は、アプリケーションを構成するデータを所定のデータユニットに格納して送信する送信方法であって、基準時刻情報に基づいて、前記アプリケーションの動作時刻を示す時刻指定情報を生成し、（ｉ）前記所定のデータユニットと、（ｉｉ）生成した前記時刻指定情報を示す制御情報とを送信し、前記制御情報は、生成した前記時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納しており、前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）である。
また、本発明の一態様に係る受信方法は、アプリケーションを構成するデータが格納された所定のデータユニットを受信する受信方法であって、（ｉ）前記所定のデータユニットと、（ｉｉ）前記アプリケーションの動作時刻を示す時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納している制御情報と、を受信し、受信した前記制御情報に基づいて、受信した前記所定のデータユニットに格納されている前記アプリケーションを実行し、前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、前記時刻指定情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づいて生成される。
上記目的を達成するために、本発明の一態様に係る送信方法は、アプリケーションを構成するデータを所定のデータユニットに格納して送信する送信方法であって、基準時刻情報に基づいて、前記アプリケーションの動作時刻を示す時刻指定情報を生成し、（ｉ）前記所定のデータユニットと、（ｉｉ）生成した前記時刻指定情報を示す制御情報とを送信し、前記制御情報は、生成した前記時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納しており、前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、前記所定のデータユニットの前記時刻指定情報は、前記時刻情報に予め定められた時間が加算された時刻情報である。
また、本発明の一態様に係る受信方法は、アプリケーションを構成するデータが格納された所定のデータユニットを受信する受信方法であって、（ｉ）前記所定のデータユニットと、（ｉｉ）前記アプリケーションの動作時刻を示す時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納している制御情報と、を受信し、受信した前記制御情報に基づいて、受信した前記所定のデータユニットに格納されている前記アプリケーションを実行し、前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、前記所定のデータユニットの前記時刻指定情報は、前記時刻情報に予め定められた時間を加算することで生成された時刻情報である。
上記目的を達成するために、本発明の一態様に係る送信方法は、アプリケーションを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した基準時刻情報に基づいて、前記アプリケーションの動作時刻を示す時刻指定情報を生成し、（ｉ）前記所定のデータユニットと、（ｉｉ）生成した前記時刻指定情報を示す制御情報とを送信し、前記制御情報は、生成した前記時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納している。
なお、これらの全般的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
本発明は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、受信装置が意図された時刻に所定のデータユニットで構成されるアプリケーションを実行できる。
図１は、ピクチャをスライスセグメントに分割する例を示す図である。 図２は、ピクチャのデータが格納されたＰＥＳパケット列の一例を示す図である。 図３は、実施の形態１に係るピクチャの分割例を示す図である。 図４は、実施の形態１の比較例に係るピクチャの分割例を示す図である。 図５は、実施の形態１に係るアクセスユニットのデータの一例を示す図である。 図６は、実施の形態１に係る送信装置のブロック図である。 図７は、実施の形態１に係る受信装置のブロック図である。 図８は、実施の形態１に係るＭＭＴパケットの一例を示す図である。 図９は、実施の形態１に係るＭＭＴパケットの別の例を示す図である。 図１０は、実施の形態１に係る各復号部に入力されるデータの一例を示す図である。 図１１は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。 図１２は、実施の形態１に係る各復号部に入力されるデータの別の例を示す図である。 図１３は、実施の形態１に係るピクチャの分割例を示す図である。 図１４は、実施の形態１に係る送信方法のフローチャートである。 図１５は、実施の形態１に係る受信装置のブロック図である。 図１６は、実施の形態１に係る受信方法のフローチャートである。 図１７は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。 図１８は、実施の形態１に係るＭＭＴパケット及びヘッダ情報の一例を示す図である。 図１９は、ＭＰＵの構成を示す図である。 図２０は、ＭＦメタデータの構成を示す図である。 図２１は、データの送信順序を説明するための図である。 図２２は、ヘッダ情報を用いずに復号を行う方法の例を示す図である。 図２３は、実施の形態２に係る送信装置のブロック図である。 図２４は、実施の形態２に係る送信方法のフローチャートである。 図２５は、実施の形態２に係る受信装置のブロック図である。 図２６は、ＭＰＵ先頭位置及びＮＡＬユニット位置を特定するための動作のフローチャートである。 図２７は、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作のフローチャートである。 図２８は、低遅延提示モードが設けられた場合の受信装置の動作のフローチャートである。 図２９は、補助データが送信される場合のＭＭＴパケットの送信順序の一例を示す図である。 図３０は、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例を説明するための図である。 図３１は、補助データの受信を説明するための図である。 図３２は、補助データを用いた受信動作のフローチャートである。 図３３は、複数のムービーフラグメントで構成されるＭＰＵの構成を示す図である。 図３４は、図３３の構成のＭＰＵが伝送される場合のＭＭＴパケットの送信順序を説明するための図である。 図３５は、１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信装置の動作例を説明するための第１の図である。 図３６は、１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信装置の動作例を説明するための第２の図である。 図３７は、図３５及び図３６で説明した受信方法の動作のフローチャートである。 図３８は、非ＶＣＬ ＮＡＬユニットを、個別にデータユニットとし、アグリゲーションする場合を示す図である。 図３９は、非ＶＣＬ ＮＡＬユニットを、まとめてデータユニットとする場合を示す図である。 図４０は、パケットロスが発生した場合の受信装置の動作のフローチャートである。 図４１は、ＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作のフローチャートである。 図４２は、時間スケーラビリティを実現する際の各ＴｅｍｐｏｒａｌＩｄにおけるピクチャの予測構造の例を示す図である。 図４３は、図４２の各ピクチャにおける復号時刻（ＤＴＳ）と表示時刻（ＰＴＳ）との関係を示す図である。 図４４は、ピクチャの遅延処理、及び、リオーダ処理が必要となるピクチャの予測構造の一例を示す図である。 図４５は、ＭＰ４形式で構成されるＭＰＵが複数のムービーフラグメントに分割されて、ＭＭＴＰペイロード、ＭＭＴＰパケットに格納される例を示す図である。 図４６は、ＰＴＳ及びＤＴＳの算出方法と課題とを説明するための図である。 図４７は、ＤＴＳ算出用の情報を用いてＤＴＳが算出される場合の受信動作のフローチャートである。 図４８は、ＭＭＴにおけるデータユニットのペイロードへの格納方法を説明するための図である。 図４９は、実施の形態３に係る送信装置の動作フローである。 図５０は、実施の形態３に係る受信装置の動作フローである。 図５１は、実施の形態３に係る送信装置の具体的構成の例を示す図である。 図５２は、実施の形態３に係る受信装置の具体的構成の例を示す図である。 図５３は、ｎｏｎ－ｔｉｍｅｄメディアのＭＰＵへの格納方法、及び、ＭＭＴＰパケットでの伝送方法を示す図である。 図５４は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する例を示す図である。 図５５は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する他の例を示す図である。 図５６は、アセット管理テーブルにおけるファイル毎のループのシンタックスを示す図である。 図５７は、受信装置における分割データ番号を特定する動作フローである。 図５８は、受信装置における分割データ数を特定する動作フローである。 図５９は、送信装置においてフラグメントカウンタを運用するかどうかを決定するための動作フローである。 図６０は、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明するための図である。 図６１は、フラグメントカウンタを活用する場合の送信装置の動作フローである。 図６２は、フラグメントカウンタを活用する場合の受信装置の動作フローである。 図６３は、同一番組を複数のＩＰデータフローで送信する場合のサービス構成を示す図である。 図６４は、送信装置の具体的構成の例を示す図である。 図６５は、受信装置の具体的構成の例を示す図である。 図６６は、送信装置による動作フローである。 図６７は、受信装置による動作フローである。 図６８は、ＡＲＩＢ ＳＴＤ－Ｂ６０に規定されている受信バッファモデルに基づいて、特に放送伝送路のみを用いた場合の受信バッファモデルを示す。 図６９は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す図である。 図７０は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例であって、ＮＡＬサイズフォーマットの映像信号を一つのデータユニットとした場合の例を示す図である。 図７１は、データユニット長が示されないＭＭＴＰパケットのペイロードの構成を示す図である。 図７２は、パケット単位に付与されるｅｘｔｅｎｄ領域に示す例である。 図７３は、受信装置の動作フローを示す。 図７４は、送信装置の具体的構成の例を示す図である。 図７５は、受信装置の具体的構成の例を示す図である。 図７６は、送信装置による動作フローである。 図７７は、受信装置による動作フローである。 図７８は、ＡＲＩＢ ＳＴＤ－Ｂ６０に規定されるＭＭＴ／ＴＬＶ方式のプロトコルスタックを示す図である。 図７９は、ＴＬＶパケットの構成を示す図である。 図８０は、受信装置のブロック図の一例を示す図である。 図８１は、タイムスタンプ記述子について説明するための図である。 図８２は、うるう秒調整を説明するための図である。 図８３は、ＮＴＰ時刻、ＭＰＵタイムスタンプ及びＭＰＵ提示タイミングの関係を示す図である。 図８４は、送信側においてタイムスタンプを補正する補正方法について説明するための図である。 図８５は、受信装置においてタイムスタンプを補正する補正方法について説明するための図である。 図８６は、送信側（送信装置）においてＭＰＵタイムスタンプを補正する場合の、送信側（送信装置）による動作フローである。 図８７は、送信側（送信装置）においてＭＰＵタイムスタンプを補正する場合の、受信装置による動作フローである。 図８８は、受信装置においてＭＰＵタイムスタンプを補正する場合の、送信側（送信装置）による動作フローである。 図８９は、受信装置においてＭＰＵタイムスタンプを補正する場合の、受信装置による動作フローである。 図９０は、送信装置の具体的構成の例を示す図である。 図９１は、受信装置の具体的構成の例を示す図である。 図９２は、送信装置による動作フローである。 図９３は、受信装置による動作フローである。 図９４は、ＭＰＵ拡張タイムスタンプ記述子の拡張例を示す図である。 図９５は、ＭＰＵシーケンス番号の調整が実施されることでＭＰＵシーケンス番号に不連続が生じた場合について説明するための図である。 図９６は、通常設備から冗長系設備に切り替えるタイミングで、パケットシーケンス番号が不連続になる場合について説明するための図である。 図９７は、ＭＰＵシーケンス番号やパケットシーケンス番号の不連続が起こった場合の受信装置による動作フローである。
本発明の一態様に係る送信方法は、アプリケーションを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した基準時刻情報に基づいて、前記アプリケーションの動作時刻を示す時刻指定情報を生成し、（ｉ）前記所定のデータユニットと、（ｉｉ）生成した前記時刻指定情報を示す制御情報とを送信し、前記制御情報は、生成した前記時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納している。
このような送信方法は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、意図された時刻に所定のデータユニットで構成されるアプリケーションを実行できる。
また、前記生成では、前記時刻情報に予め定められた時間を加算することで、前記ＭＰＵの前記提示時刻情報を生成してもよい。
また、前記識別情報は、前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示してもよい。
また、前記時刻指定情報は、ＵＴＣ（Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ Ｃｏｏｒｄｉｎａｔｅｄ）時刻およびＮＰＴ（Ｎｏｒｍａｌ Ｐｌａｙ Ｔｉｍｅ）であり、前記制御情報は、ＵＴＣ時刻とＮＰＴ時刻の関係を示すＵＴＣ－ＮＰＴ参照記述子であってもよい。
また、前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）であってもよい。
また、本発明の一態様に係る受信方法は、アプリケーションを構成するデータが格納された所定のデータユニットを受信する受信方法であって、（ｉ）前記所定のデータユニットと、（ｉｉ）前記アプリケーションの動作時刻を示す時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納している制御情報と、を受信し、受信した前記制御情報に基づいて、受信した前記所定のデータユニットに格納されている前記アプリケーションを実行する。
このような受信方法は、基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、意図された時刻に所定のデータユニットで構成されるアプリケーションを実行できる。
なお、これらの包括的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
以下、実施の形態について、図面を参照しながら具体的に説明する。
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
（本発明の基礎となった知見）
近年、ＴＶ、スマートフォン、又はタブレット端末などのディスプレイの高解像度化が進んでいる。特に日本国内の放送においては２０２０年に８Ｋ４Ｋ（解像度が８Ｋ×４Ｋ）のサービスが予定されている。８Ｋ４Ｋなどの超高解像度の動画像においては、単一の復号器では実時間での復号が困難であるため、複数の復号器を用いて並列に復号処理を行う手法が検討されている。
符号化データはＭＰＥＧ－２ ＴＳやＭＭＴなどの多重化方式に基づいて多重化して送信されるため、受信装置は、復号に先立って、多重化データから動画の符号化データを分離する必要がある。以下、多重化データから符号化データを分離する処理を逆多重化と呼ぶ。
復号処理を並列化する際には、各復号器のそれぞれに対して、復号対象となる符号化データを振り分ける必要がある。符号化データを振り分ける際には、符号化データそのものを解析する必要があり、特に８Ｋなどのコンテンツにおいてはビットレートが非常に高いことから、解析に係る処理負荷が大きい。したがって、逆多重化の部分がボトルネックとなり実時間での再生が行えないという課題があった。
ところで、ＭＰＥＧとＩＴＵにより規格化されたＨ．２６４及びＨ．２６５などの動画像符号化方式においては、送信装置は、ピクチャをスライス又はスライスセグメントと呼ばれる複数の領域に分割し、分割したそれぞれの領域を独立に復号できるように符号化することができる。従って、例えば、Ｈ．２６５の場合には、放送を受信する受信装置は、受信データからスライスセグメント毎のデータを分離し、各スライスセグメントのデータを別々の復号器に出力することで、復号処理の並列化を実現できる。
図１は、ＨＥＶＣにおいて、１つのピクチャを４つのスライスセグメントに分割する例を示す図である。例えば、受信装置は４つの復号器を備え、各復号器が４つのスライスセグメントのうちいずれかを復号する。
従来の放送においては、送信装置は、１枚のピクチャ（ＭＰＥＧシステム規格におけるアクセスユニット）を１つのＰＥＳパケットに格納し、ＰＥＳパケットをＴＳパケット列に多重化する。このため、受信装置は、ＰＥＳパケットのペイロードを分離したうえで、ペイロードに格納されたアクセスユニットのデータを解析することで、各スライスセグメントを分離し、分離された各スライスセグメントのデータを復号器に出力する必要があった。
しかしながら、アクセスユニットのデータを解析してスライスセグメントを分離する際の処理量が大きいため、この処理を実時間で行うことが困難であるという課題があることを本発明者は見出した。
図２は、スライスセグメントに分割されたピクチャのデータが、ＰＥＳパケットのペイロードに格納される例を示す図である。
図２に示すように、例えば、複数のスライスセグメント（スライスセグメント１～４）のデータが１つのＰＥＳパケットのペイロードに格納される。また、ＰＥＳパケットはＴＳパケット列に多重化される。
（実施の形態１）
以下では、動画像の符号化方式としてＨ．２６５を用いる場合を例に説明するが、Ｈ．２６４など他の符号化方式を用いる場合にも本実施の形態を適用できる。
図３は、本実施の形態におけるアクセスユニット（ピクチャ）を分割単位に分割した例を示す図である。アクセスユニットは、Ｈ．２６５によって導入されたタイルと呼ばれる機能により、水平及び垂直方向にそれぞれ２等分され、合計４つのタイルに分割される。また、スライスセグメントとタイルは１対１に対応付けられる。
このように水平及び垂直方向に２等分する理由について説明する。まず、復号時には、一般的に水平１ラインのデータを格納するラインメモリが必要となるが、８Ｋ４Ｋなどの超高解像度になると、水平方向のサイズが大きくなるためラインメモリのサイズが増加する。受信装置の実装においては、ラインメモリのサイズを低減できることが望ましい。ラインメモリのサイズを低減するためには垂直方向の分割が必要となる。垂直方向の分割にはタイルというデータ構造が必要である。これらの理由により、タイルが用いられる。
一方で、画像は一般的に水平方向の相関が高いため、水平方向に広い範囲を参照できるほうが符号化効率は向上する。従って、符号化効率の観点ではアクセスユニットが水平方向に分割されることが望ましい。
アクセスユニットが水平及び垂直方向に２等分されることで、これら２つの特性を両立させ、実装面、及び符号化効率の両面を考慮できる。単一の復号器が４Ｋ２Ｋの動画像を実時間での復号が可能の場合には、８Ｋ４Ｋの画像が４等分され、各々のスライスセグメントが４Ｋ２Ｋとなるように分割されることで、受信装置は、８Ｋ４Ｋの画像を実時間で復号できる。
次に、アクセスユニットが水平及び垂直方向に分割されることで得られたタイルとスライスセグメントとを１対１に対応付ける理由について説明する。Ｈ．２６５においては、アクセスユニットは複数のＮＡＬ（Ｎｅｔｗｏｒｋ Ａｄａｐｔａｔｉｏｎ Ｌａｙｅｒ）ユニットと呼ばれる単位から構成される。
ＮＡＬユニットのペイロードは、アクセスユニットの開始位置を示すアクセスユニットデリミタ、シーケンス単位で共通に用いられる復号時の初期化情報であるＳＰＳ（Ｓｅｑｕｅｎｃｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、ピクチャ内で共通に用いられる復号時の初期化情報であるＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）、復号処理自体には不要であるが復号結果の処理及び表示などにおいて必要となるＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）、並びに、スライスセグメントの符号化データなどのいずれかを格納する。ＮＡＬユニットのヘッダは、ペイロードに格納されるデータを識別するためのタイプ情報を含む。
ここで、送信装置は、符号化データをＭＰＥＧ－２ ＴＳ、ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）、ＭＰＥＧ ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ
Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）、又は、ＲＴＰ（Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの多重化フォーマットによって多重化する際には、基本単位をＮＡＬユニットに設定できる。１つのスライスセグメントを１つのＮＡＬユニットに格納するためには、アクセスユニットを領域に分割する際に、スライスセグメント単位に分割することが望ましい。このような理由から、送信装置は、タイルとスライスセグメントとを１対１に対応付ける。
なお、図４に示すように、送信装置は、タイル１からタイル４までをまとめて１つのスライスセグメントに設定することも可能である。しかし、この場合には、１つのＮＡＬユニットに全てのタイルが格納されることになり、受信装置が、多重化レイヤにおいてタイルを分離することが困難である。
なお、スライスセグメントには独立に復号可能な独立スライスセグメントと、独立スライスセグメントを参照する参照スライスセグメントとが存在するが、ここでは独立スライスセグメントが用いられる場合を説明する。
図５は、図３に示すようにタイルとスライスセグメントとの境界が一致するように分割されたアクセスユニットのデータの例を示す図である。アクセスユニットのデータは、先頭に配置されたアクセスユニットデリミタが格納されるＮＡＬユニットと、その後に配置されるＳＰＳ、ＰＰＳ、及びＳＥＩのＮＡＬユニットと、その後に配置されるタイル１からタイル４までのデータが格納されたスライスセグメントのデータとを含む。なお、アクセスユニットのデータは、ＳＰＳ、ＰＰＳ及びＳＥＩのＮＡＬユニットの一部又は全てを含まなくてもよい。
次に、本実施の形態に係る送信装置１００の構成を説明する。図６は、本実施の形態に係る送信装置１００の構成例を示すブロック図である。この送信装置１００は、符号化部１０１と、多重化部１０２と、変調部１０３と、送信部１０４とを備える。
符号化部１０１は、入力画像を、例えば、Ｈ．２６５に従い符号化することで符号化データを生成する。また、符号化部１０１は、例えば、図３に示すように、アクセスユニットを４つのスライスセグメント（タイル）に分割し、各スライスセグメントを符号化する。
多重化部１０２は、符号化部１０１により生成された符号化データを多重化する。変調部１０３は、多重化により得られたデータを変調する。送信部１０４は、変調後のデータを放送信号として送信する。
次に、本実施の形態に係る受信装置２００の構成を説明する。図７は、本実施の形態に係る受信装置２００の構成例を示すブロック図である。この受信装置２００は、チューナー２０１と、復調部２０２と、逆多重化部２０３と、複数の復号部２０４Ａ～２０４Ｄと、表示部２０５とを備える。
チューナー２０１は、放送信号を受信する。復調部２０２は、受信された放送信号を復調する。復調後のデータは逆多重化部２０３に入力される。
逆多重化部２０３は、復調後のデータを分割単位に分離し、分割単位毎のデータを復号部２０４Ａ～２０４Ｄに出力する。ここで、分割単位とは、アクセスユニットが分割されることで得られた分割領域であり、例えば、Ｈ．２６５におけるスライスセグメントである。また、ここでは、８Ｋ４Ｋの画像が４つの４Ｋ２Ｋの画像に分割される。よって、４つの復号部２０４Ａ～２０４Ｄが存在する。
複数の復号部２０４Ａ～２０４Ｄは、所定の基準クロックに基づいて互いに同期して動作する。各復号部は、アクセスユニットのＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）に従って分割単位の符号化データを復号し、復号結果を表示部２０５に出力する。
表示部２０５は、複数の復号部２０４Ａ～２０４Ｄから出力された複数の復号結果を統合することで８Ｋ４Ｋの出力画像を生成する。表示部２０５は、別途取得したアクセスユニットのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）に従って、生成された出力画像を表示する。なお、表示部２０５は、復号結果を統合する際に、タイルの境界など、互いに隣接する分割単位の境界領域において、当該境界が視覚的に目立たなくなるようにデブロックフィルタなどのフィルタ処理を行ってもよい。
なお、上記では、放送の送信又は受信を行う送信装置１００及び受信装置２００を例に説明したが、コンテンツは通信ネットワーク経由で送信及び受信されてもよい。受信装置２００が、通信ネットワーク経由でコンテンツを受信する場合には、受信装置２００は、イーサーネットなどのネットワークにより受信したＩＰパケットから多重化データを分離する。
放送においては、放送信号が送信されてから受信装置２００に届くまでの間の伝送路遅延は一定である。一方、インターネットなどの通信ネットワークにおいては輻輳の影響により、サーバーから送信されたデータが受信装置２００に届くまでの伝送路遅延は一定でない。従って、受信装置２００は、放送のＭＰＥＧ－２ ＴＳにおけるＰＣＲのような基準クロックに基づいた厳密な同期再生を行わないことが多い。そのため、受信装置２００は、各復号部を厳密に同期させることはせずに、表示部において８Ｋ４Ｋの出力画像をＰＴＳに従って表示してもよい。
また、通信ネットワークの輻輳などにより、全ての分割単位の復号処理がアクセスユニットのＰＴＳで示される時刻において完了していない場合がある。この場合には、受信装置２００は、アクセスユニットの表示をスキップする、又は、少なくとも４つの分割単位の復号が終了し、８Ｋ４Ｋの画像の生成が完了するまで表示を遅延させる。
なお、放送と通信とを併用してコンテンツが送信及び受信されてもよい。また、ハードディスク又はメモリなどの記録媒体に格納された多重化データを再生する際にも本手法を適用可能である。
次に、多重化方式としてＭＭＴが用いられる場合の、スライスセグメントに分割されたアクセスユニットの多重化方法にについて説明する。
図８は、ＨＥＶＣのアクセスユニットのデータを、ＭＭＴにパケット化する際の例を示す図である。ＳＰＳ、ＰＰＳ及びＳＥＩなどはアクセスユニットに必ずしも含まれる必要はないが、ここでは存在する場合について例示する。
アクセスユニットデリミタ、ＳＰＳ、ＰＰＳ、及びＳＥＩなどのアクセスユニット内で先頭のスライスセグメントよりも前に配置されるＮＡＬユニットは一纏めにしてＭＭＴパケット＃１に格納される。後続のスライスセグメントは、スライスセグメント毎に別々のＭＭＴパケットに格納される。
なお、図９に示すように、アクセスユニット内で先頭のスライスセグメントよりも前に配置されるＮＡＬユニットが、先頭のスライスセグメントと同一のＭＭＴパケットに格納されてもよい。
また、シーケンス又はストリームの終端を示す、Ｅｎｄ－ｏｆ－Ｓｅｑｕｅｎｃｅ又はＥｎｄ－ｏｆ－ＢｉｔｓｔｒｅａｍなどのＮＡＬユニットが最終スライスセグメントの後に付加される場合には、これらは、最終スライスセグメントと同一のＭＭＴパケットに格納される。ただし、Ｅｎｄ－ｏｆ－Ｓｅｑｕｅｎｃｅ又はＥｎｄ－ｏｆ－ＢｉｔｓｔｒｅａｍなどのＮＡＬユニットは、復号処理の終了ポイント、又は２本のストリームの接続ポイントなどに挿入されるため、受信装置２００が、これらのＮＡＬユニットを、多重化レイヤにおいて容易に取得できることが望ましい場合がある。この場合には、これらのＮＡＬユニットは、スライスセグメントとは別のＭＭＴパケットに格納されてもよい。これにより、受信装置２００は、多重化レイヤにおいてこれらのＮＡＬユニットを容易に分離できる。
なお、多重化方式として、ＴＳ、ＤＡＳＨ又はＲＴＰなどが用いられてもよい。これらの方式においても、送信装置１００は、異なるスライスセグメントをそれぞれ異なるパケットに格納する。これにより、受信装置２００が多重化レイヤにおいてスライスセグメントを分離できることを保証できる。
例えば、ＴＳが用いられる場合、スライスセグメント単位で符号化データがＰＥＳパケット化される。ＲＴＰが用いられる場合、スライスセグメント単位で符号化データがＲＴＰパケット化される。これらの場合においても、図８に示すＭＭＴパケット＃１のように、スライスセグメントよりも前に配置されるＮＡＬユニットとスライスセグメントとが別々にパケット化されてもよい。
ＴＳが用いられる場合、送信装置１００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を用いることなどにより、ＰＥＳパケットに格納されるデータの単位を示す。また、ＤＡＳＨはセグメントと呼ばれるＭＰ４形式のデータ単位をＨＴＴＰなどによりダウンロードする方式であるため、送信装置１００は、送信にあたって符号化データのパケット化は行わない。このため、送信装置１００は、受信装置２００がＭＰ４において多重化レイヤでスライスセグメントを検出できるように、スライスセグメント単位でサブサンプルを作成し、サブサンプルの格納位置を示す情報をＭＰ４のヘッダに格納してもよい。
以下、スライスセグメントのＭＭＴパケット化について、詳細に説明する。
図８に示すように、符号化データがパケット化されることで、ＳＰＳ及びＰＰＳなどのアクセスユニット内の全スライスセグメントの復号時に共通に参照されるデータがＭＭＴパケット＃１に格納される。この場合、受信装置２００は、ＭＭＴパケット＃１のペイロードデータと各スライスセグメントのデータとを連結し、得られたデータを復号部に出力する。このように、受信装置２００は、複数のＭＭＴパケットのペイロードを連結することで、復号部への入力データを容易に生成できる。
図１０は、図８に示すＭＭＴパケットから復号部２０４Ａ～２０４Ｄへの入力データが生成される例を示す図である。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃２とのペイロードデータを連結させることで、復号部２０４Ａが、スライスセグメント１を復号するために必要なデータを生成する。逆多重化部２０３は、復号部２０４Ｂから復号部２０４Ｄについても、同様に入力データを生成する。つまり、逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃３とのペイロードデータを連結させることで、復号部２０４Ｂの入力データを生成する。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃４とのペイロードデータを連結させることで、復号部２０４Ｃの入力データを生成する。逆多重化部２０３は、ＭＭＴパケット＃１とＭＭＴパケット＃５とのペイロードデータを連結させることで、復号部２０４Ｄの入力データを生成する。
なお、逆多重化部２０３は、アクセスユニットデリミタ及びＳＥＩなど、復号処理に必要ではないＮＡＬユニットを、ＭＭＴパケット＃１のペイロードデータから除去し、復号処理に必要であるＳＰＳ及びＰＰＳのＮＡＬユニットのみを分離してスライスセグメントのデータに付加してもよい。
図９に示すように符号化データがパケット化される場合には、逆多重化部２０３は、多重化レイヤにおいてアクセスユニットの先頭データを含むＭＭＴパケット＃１を１番目の復号部２０４Ａに出力する。また、逆多重化部２０３は、多重化レイヤにおいてアクセスユニットの先頭データを含むＭＭＴパケットを解析し、ＳＰＳ及びＰＰＳのＮＡＬユニットを分離し、分離したＳＰＳ及びＰＰＳのＮＡＬユニットを２番目以降のスライスセグメントのデータの各々に付加することで２番目以降の復号部の各々に対する入力データを生成する。
さらに、受信装置２００が、ＭＭＴパケットのヘッダに含まれる情報を用いて、ＭＭＴペイロードに格納されるデータのタイプ、及び、ペイロードにスライスセグメントが格納されている場合のアクセスユニット内における当該スライスセグメントのインデックス番号を識別できることが望ましい。ここで、データのタイプとは、スライスセグメント前データ（アクセスユニット内で先頭スライスセグメントよりも前に配置されるＮＡＬユニットをまとめて、このように呼ぶことにする）、及び、スライスセグメントのデータのいずれである。ＭＭＴパケットに、スライスセグメントなどのＭＰＵをフラグメント化した単位を格納する場合には、ＭＦＵ（Ｍｅｄｉａ Ｆｒａｇｍｅｎｔ Ｕｎｉｔ）を格納するためのモードが用いられる。送信装置１００は、本モードを用いる場合には、例えば、ＭＦＵにおけるデータの基本単位であるＤａｔａ Ｕｎｉｔを、サンプル（ＭＭＴにおけるデータ単位であり、アクセスユニットに相当する）、又は、サブサンプル（サンプルを分割した単位）に設定できる。
このとき、ＭＭＴパケットのヘッダは、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒと呼ばれるフィールドと、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒと呼ばれるフィールドとを含む。
Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒは、ＭＭＴパケットのペイロードに格納されるデータが、Ｄａｔａ ｕｎｉｔをフラグメント化したものであるかどうか、フラグメント化したものである場合には、当該フラグメントがＤａｔａ ｕｎｉｔにおける先頭或いは最終のフラグメント、又は、先頭と最終とのどちらでもないフラグメントであるかを示す。言い換えると、あるパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒは、（１）基本データ単位であるＤａｔａ ｕｎｉｔに当該パケットのみが含まれる、（２）Ｄａｔａ ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ ｕｎｉｔの先頭のパケットである、（３）Ｄａｔａ ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ ｕｎｉｔの先頭及び最後以外のパケットである、及び、（４）Ｄａｔａ ｕｎｉｔが複数のパケットに分割して格納され、かつ、当該パケットがＤａｔａ ｕｎｉｔの最後のパケットである、のいずれであるかを示す識別情報である。
Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒは、ＭＭＴパケットに格納されるデータが、Ｄａｔａ ｕｎｉｔにおいて何番目のフラグメントに相当するかを示すインデックス番号である。
従って、送信装置１００が、ＭＭＴにおけるサンプルをＤａｔａ ｕｎｉｔに設定し、スライスセグメント前データ、及び、各スライスセグメントを、それぞれＤａｔａ ｕｎｉｔのフラグメント単位に設定することで、受信装置２００は、ＭＭＴパケットのヘッダに含まれる情報を用いて、ペイロードに格納されるデータのタイプが識別できる。つまり、逆多重化部２０３は、ＭＭＴパケットのヘッダを参照して、各復号部２０４Ａ～２０４Ｄへの入力データを生成できる。
図１１は、サンプルがＤａｔａ ｕｎｉｔに設定され、スライスセグメント前データ、及び、スライスセグメントがＤａｔａ ｕｎｉｔのフラグメントとしてパケット化される場合の例を示す図である。
スライスセグメント前データ、及びスライスセグメントは、フラグメント＃１からフラグメント＃５までの５つのフラグメントに分割される。各フラグメントは個別のＭＭＴパケットに格納される。このとき、ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ及びＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値は図示する通りである。
例えば、Ｆｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは、２進数の２ビット値である。Ｄａｔａ ｕｎｉｔの先頭であるＭＭＴパケット＃１のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒ、最終であるＭＭＴパケット＃５のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒ、及び、その間のパケットであるＭＭＴパケット＃２からＭＭＴパケット＃４までのＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは、それぞれ別の値に設定される。具体的には、Ｄａｔａ ｕｎｉｔの先頭であるＭＭＴパケット＃１のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは０１に設定され、最終であるＭＭＴパケット＃５のＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは１１に設定され、その間のパケットであるＭＭＴパケット＃２からＭＭＴパケット＃４までのＦｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは１０に設定される。なお、Ｄａｔａ ｕｎｉｔに一つのＭＭＴパケットのみが含まれる場合には、Ｆｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒは００に設定される。
また、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒは、ＭＭＴパケット＃１においてはフラグメントの総数である５から１を減算した値である４であり、後続パケットにおいては順に１ずつ減少し、最後のＭＭＴパケット＃５においては０である。
従って、受信装置２００は、スライスセグメント前データを格納するＭＭＴパケットを、Ｆｒａｇｍｅｎｔ ｉｎｄｉｃａｔｏｒ、及び、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒのいずれかを用いて識別できる。また、受信装置２００は、Ｎ番目のスライスセグメントを格納するＭＭＴパケットを、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒを参照することにより識別できる。
ＭＭＴパケットのヘッダは、別途、Ｄａｔａ ｕｎｉｔが属するＭｏｖｉｅ ＦｒａｇｍｅｎｔのＭＰＵ内でのシーケンス番号と、ＭＰＵ自体のシーケンス番号と、Ｄａｔａ ｕｎｉｔが属するサンプルのＭｏｖｉｅ Ｆｒａｇｍｅｎｔ内におけるシーケンス番号とを含む。逆多重化部２０３は、これらを参照することで、Ｄａｔａ ｕｎｉｔが属するサンプルを一意に決定できる。
更に、逆多重化部２０３は、Ｄａｔａ ｕｎｉｔ内におけるフラグメントのインデックス番号をＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒなどから決定できるため、パケットロスが発生した場合にも、フラグメントに格納されるスライスセグメントを一意に特定できる。例えば、逆多重化部２０３は、図１１に示すフラグメント＃４がパケットロスにより取得できなかった場合でも、フラグメント＃３の次に受信したフラグメントがフラグメント＃５であることが分かるため、フラグメント＃５に格納されるスライスセグメント４を、復号部２０４Ｃではなく復号部２０４Ｄに正しく出力することができる。
なお、パケットロスが発生しないことが保証される伝送路が使用される場合には、逆多重化部２０３は、ＭＭＴパケットのヘッダを参照してＭＭＴパケットに格納されるデータのタイプ、又はスライスセグメントのインデックス番号を決定せずに、到着したパケットを周期的に処理すればよい。例えば、アクセスユニットが、スライス前データ、及び、４つのスライスセグメントの計５つのＭＭＴパケットにより送信される場合には、受信装置２００は、復号を開始するアクセスユニットのスライス前データを決定した後は、受信したＭＭＴパケットを順に処理することで、スライス前データ、及び、４つのスライスセグメントのデータを順に取得できる。
以下、パケット化の変形例について説明する。
スライスセグメントは、必ずしもアクセスユニットの面内を水平方向と垂直方向との両方に分割されたものである必要はなく、図１に示すように、アクセスユニットを水平方向のみに分割されたものでもよいし、垂直方向のみに分割されたものでもよい。
また、水平方向のみにアクセスユニットが分割される場合には、タイルが用いられる必要はない。
また、アクセスユニットにおける面内の分割数は任意であり、４つに限定されるものではない。但し、スライスセグメント及びタイルの領域サイズはＨ．２６５などの符号化規格の下限以上である必要がある。
送信装置１００は、アクセスユニットにおける面内の分割方法を示す識別情報を、ＭＭＴメッセージ、又はＴＳのデスクリプタなどに格納してもよい。例えば、面内における水平方向と垂直方向との分割数とをそれぞれ示す情報が格納されてもよい。または、図３に示すように水平方向及び垂直方向にそれぞれ２等分されている、又は、図１に示すように水平方向に４等分されているなど、分割方法に対して固有の識別情報が割り当てられてもよい。例えば、図３に示すようにアクセスユニットが分割されている場合は、識別情報はモード１を示し、図１に示すようにアクセスユニットが分割されている場合には、識別情報はモード１を示す。
また、面内の分割方法に関連する符号化条件の制約を示す情報が、多重化レイヤに含まれてもよい。例えば、１つのスライスセグメントが１つのタイルから構成されること示す情報が用いられてもよい。または、スライスセグメント或いはタイルの復号時に動き補償を行う場合の参照ブロックが、画面内の同一位置のスライスセグメント或いはタイルに制限される、又は、隣接スライスセグメントにおける所定の範囲内のブロックに限定されることなどを示す情報が用いられてもよい。
また、送信装置１００は、動画像の解像度に応じて、アクセスユニットを複数のスライスセグメントに分割するかどうかを切替えてもよい。例えば、送信装置１００は、処理対象の動画像が４Ｋ２Ｋの解像度の場合には面内の分割を行わずに、処理対象の動画像が８Ｋ４Ｋの場合にはアクセスユニットを４つに分割してもよい。８Ｋ４Ｋの動画像の場合の分割方法を予め規定しておくことにより、受信装置２００は、受信する動画像の解像度を取得することで、面内の分割の有無、及び分割方法を決定し、復号動作を切替えることができる。
また、受信装置２００は、面内の分割の有無を、ＭＭＴパケットのヘッダを参照することにより検出できる。例えば、アクセスユニットが分割されない場合には、ＭＭＴのＤａｔａ ｕｎｉｔがサンプルに設定されていれば、Ｄａｔａ ｕｎｉｔのフラグメントは行われない。従って、受信装置２００は、ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値が常にゼロの場合には、アクセスユニットは分割されないと判定できる。または、受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値が常に０１であるかどうかを検出してもよい。受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値が常に０１の場合もアクセスユニットは分割されないと判定できる。
また、受信装置２００は、アクセスユニットにおける面内の分割数と復号部の数とが一致しない場合にも対応できる。例えば、受信装置２００が、８Ｋ２Ｋの符号化データを実時間で復号できる２つの復号部２０４Ａ及び２０４Ｂを備える場合には、逆多重化部２０３は、復号部２０４Ａに対して、８Ｋ４Ｋの符号化データを構成する４つのスライスセグメントのうちの２つを出力する。
図１２は、図８に示すようにＭＭＴパケット化されたデータが、２つの復号部２０４Ａ及び２０４Ｂに入力される場合の動作例を示す図である。ここで、受信装置２００は、復号部２０４Ａ及び２０４Ｂにおける復号結果を、そのまま統合して出力できることが望ましい。よって、逆多重化部２０３は、復号部２０４Ａ及び２０４Ｂの各々の復号結果が空間的に連続するように、復号部２０４Ａ及び２０４Ｂの各々に出力するスライスセグメントを選択する。
また、逆多重化部２０３は、動画像の符号化データの解像度又はフレームレートなどに応じて、使用する復号部を選択してもよい。例えば、受信装置２００が４Ｋ２Ｋの復号部を４つ備える場合には、入力画像の解像度が８Ｋ４Ｋであれば、受信装置２００は、４つ全ての復号部を用いて復号処理を行う。また、受信装置２００は、入力画像の解像度が４Ｋ２Ｋであれば１つの復号部のみを用いて復号処理を行う。または、逆多重化部２０３は、面内が４つに分割されていても、８Ｋ４Ｋを単一の復号部により実時間で復号できる場合には、全ての分割単位を統合して一つの復号部に出力する。
さらに、受信装置２００は、フレームレートを考慮して使用する復号部を決定してもよい。例えば、受信装置２００が、解像度が８Ｋ４Ｋである場合に実時間で復号可能なフレームレートの上限が６０ｆｐｓである復号部を２台備える場合に、８Ｋ４Ｋで１２０ｆｐｓの符号化データが入力されるケースがある。このとき、面内が４つの分割単位から構成されるとすると、図１２の例と同様に、スライスセグメント１とスライスセグメント２とが復号部２０４Ａに入力され、スライスセグメント３とスライスセグメント４とが復号部２０４Ｂに入力される。各々の復号部２０４Ａ及び２０４Ｂは、８Ｋ２Ｋ（解像度が８Ｋ４Ｋの半分）であれば１２０ｆｐｓまで実時間で復号できるため、これら２台の復号部２０４Ａ及び２０４Ｂにより復号処理が行われる。
また、解像度及びフレームレートが同一であっても、符号化方式におけるプロファイル、或いはレベル、又は、Ｈ．２６４或いはＨ．２６５など符号化方式自体が異なると処理量が異なる。よって、受信装置２００は、これらの情報に基づいて使用する復号部を選択してもよい。なお、受信装置２００は、放送又は通信により受信した符号化データを全て復号することができない場合、又は、ユーザーが選択した領域を構成する全てのスライスセグメント又はタイルが復号できない場合には、復号部の処理範囲内で復号可能なスライスセグメント又はタイルを自動的に決定してもよい。または、受信装置２００は、ユーザーが復号する領域を選択するためのユーザインタフェースを提供してもよい。このとき、受信装置２００は、全て領域を復号できないことを示す警告メッセージを表示してもよいし、復号可能な領域、スライスセグメント又はタイルの個数を示す情報を表示してもよい。
また、上記方法は、同一符号化データのスライスセグメントを格納するＭＭＴパケットが、放送及び通信など複数の伝送路を用いて送信及び受信される場合にも適用できる。
また、送信装置１００は、分割単位の境界を目立たなくするために、各スライスセグメントの領域がオーバーラップするように符号化を行ってもよい。図１３に示す例では、８Ｋ４Ｋのピクチャが４つのスライスセグメント１～４に分割される。スライスセグメント１～３の各々は、例えば、８Ｋ×１．１Ｋであり、スライスセグメント４は８Ｋ×１Ｋである。また、隣接するスライスセグメントは互いにオーバーラップする。こうすることで、点線で示す４分割した場合の境界においては、符号化時の動き補償が効率的に実行できるため、境界部分の画質が向上する。このように、境界部分の画質劣化が低減される。
この場合、表示部２０５は、８Ｋ×１．１Ｋの領域から、８Ｋ×１Ｋの領域を切り出し、得られた領域を統合する。なお、送信装置１００は、スライスセグメントがオーバーラップして符号化されているかどうか、及び、オーバーラップの範囲を示す情報を、多重化レイヤ、又は、符号化データ内に含めて、別途送信してもよい。
なお、タイルが使用される場合にも、同様の手法を適用可能である。
以下、送信装置１００の動作の流れを説明する。図１４は、送信装置１００の動作例を示すフローチャートである。
まず、符号化部１０１は、ピクチャ（アクセスユニット）を複数の領域である複数のスライスセグメント（タイル）に分割する（Ｓ１０１）。次に、符号化部１０１は、複数のスライスセグメントの各々を独立して復号が可能なように符号化することで、複数のスライスセグメントの各々に対応する符号化データを生成する（Ｓ１０２）。なお、符号化部１０１は、複数のスライスセグメントを単一の符号化部で符号化してもよし、複数の符号化部で並列処理してもよい。
次に、多重化部１０２は、符号化部１０１で生成された複数の符号化データを、複数のＭＭＴパケットに格納することで、複数の符号化データを多重化する（Ｓ１０３）。具体的には、図８及び図９に示すように、多重化部１０２は、一つのＭＭＴパケットに、異なるスライスセグメントに対応する符号化データが格納されないように、複数の符号化データを複数のＭＭＴパケットに格納する。また、多重化部１０２は、図８に示すように、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報を、複数の符号化データが格納される複数のＭＭＴパケット＃２～＃５とは異なるＭＭＴパケット＃１に格納する。ここで制御情報は、アクセスユニットデリミタ、ＳＰＳ，ＰＰＳ及びＳＥＩのうち少なくとも一つを含む。
なお、多重化部１０２は、制御情報を、複数の符号化データが格納される複数のＭＭＴパケットのいずれかと同じＭＭＴパケットに格納してもよい。例えば、図９に示すように、多重化部１０２は、制御情報を、複数の符号化データが格納される複数のＭＭＴパケットのうちの先頭のＭＭＴパケット（図９のＭＭＴパケット＃１）に格納してもよい。
最後に、送信装置１００は、複数のＭＭＴパケットを送信する。具体的には、変調部１０３は、多重化により得られたデータを変調し、送信部１０４は、変調後のデータを送信する（Ｓ１０４）。
図１５は、受信装置２００の構成例を示すブロック図であり、図７に示す逆多重化部２０３及びその後段の構成を詳細に示す図である。図１５に示すように、受信装置２００は、さらに、復号命令部２０６を備える。また、逆多重化部２０３は、タイプ判別部２１１と、制御情報取得部２１２と、スライス情報取得部２１３と、復号データ生成部２１４とを備える。
以下、受信装置２００の動作の流れを説明する。図１６は、受信装置２００の動作例を示すフローチャートである。ここでは、１つのアクセスユニットに対する動作を示す。複数のアクセスユニットの復号処理が実行される場合には、本フローチャートの処理が繰り返される。
まず、受信装置２００は、は、例えば、送信装置１００により生成された複数のパケット（ＭＭＴパケット）を受信する（Ｓ２０１）。
次に、タイプ判別部２１１は、受信パケットのヘッダを解析することで、受信パケットに格納されている符号化データのタイプを取得する（Ｓ２０２）。
次に、タイプ判別部２１１は、取得された符号化データのタイプに基づき、受信パケットに格納されているデータがスライスセグメント前データであるか、スライスセグメントのデータであるかを判定する（Ｓ２０３）。
受信パケットに格納されているデータがスライスセグメント前データである場合（Ｓ２０３でＹｅｓ）、制御情報取得部２１２は、受信パケットのペイロードから処理対象のアクセスユニットのスライスセグメント前データを取得し、当該スライスセグメント前データをメモリに格納する（Ｓ２０４）。
一方、受信パケットに格納されているデータがスライスセグメントのデータである場合（Ｓ２０３でＮｏ）、受信装置２００は、受信パケットのヘッダ情報を用いて、当該受信パケットに格納されているデータが、複数の領域のうちいずれの領域の符号化データであるかを判定する。具体的には、スライス情報取得部２１３は、受信パケットのヘッダを解析することで、受信パケットに格納されているスライスセグメントのインデックス番号Ｉｄｘを取得する（Ｓ２０５）。具体的には、インデックス番号Ｉｄｘは、アクセスユニット（ＭＭＴにおけるサンプル）のＭｏｖｉｅ Ｆｒａｇｍｅｎｔ内におけるインデックス番号である。
なお、このステップＳ２０５の処理は、ステップＳ２０２においてまとめて行われてもよい。
次に、復号データ生成部２１４は、当該スライスセグメントを復号する復号部を決定する（Ｓ２０６）。具体的には、インデックス番号Ｉｄｘと複数の復号部とは予め対応付けられており、復号データ生成部２１４は、ステップＳ２０５で取得されたインデックス番号Ｉｄｘに対応する復号部を、当該スライスセグメントを復号する復号部を決定する。
なお、復号データ生成部２１４は、図１２の例において説明したように、アクセスユニット（ピクチャ）の解像度、アクセスユニットの複数のスライスセグメント（タイル）への分割方法、及び受信装置２００が備える複数の復号部の処理能力の少なくとも一つに基づき、当該スライスセグメントを復号する復号部を決定してもよい。例えば、復号データ生成部２１４は、アクセスユニットの分割方法を、ＭＭＴのメッセージ、又はＴＳのセクションなどのデスクリプタにおける識別情報に基づいて判別する。
次に、復号データ生成部２１４は、複数のパケットのいずれかに含まれる、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報と、複数のスライスセグメントの複数の符号化データの各々とを結合することで、複数の復号部へ入力される複数の入力データ（結合データ）を生成する。具体的には、復号データ生成部２１４は、受信パケットのペイロードからスライスセグメントのデータを取得する。復号データ生成部２１４は、ステップＳ２０４でメモリに格納されたスライスセグメント前データと、取得されたスライスセグメントのデータとを結合することで、ステップＳ２０６で決定された復号部への入力データを生成する（Ｓ２０７）。
ステップＳ２０４又はＳ２０７の後、受信パケットのデータがアクセスユニットの最終データでない場合（Ｓ２０８でＮｏ）、ステップＳ２０１以降の処理が再度行われる。つまり、アクセスユニットに含まれる全てのスライスセグメントに対応する、複数の復号部２０４Ａ～２０４Ｄへの入力データが生成されるまで、上記処理が繰り返される。
なお、パケットが受信されるタイミングは、図１６に示すタイミングに限らず、予め又は順次複数のパケットが受信され、メモリ等に格納されてもよい。
一方、受信パケットのデータがアクセスユニットの最終データである場合（Ｓ２０８でＹｅｓ）、復号命令部２０６は、ステップＳ２０７で生成された、複数の入力データを、対応する復号部２０４Ａ～２０４Ｄへ出力する（Ｓ２０９）。
次に、複数の復号部２０４Ａ～２０４Ｄは、アクセスユニットのＤＴＳに従い、複数の入力データを並列に復号することで、複数の復号画像を生成する（Ｓ２１０）。
最後に、表示部２０５は、複数の復号部２０４Ａ～２０４Ｄで生成された複数の復号画像を結合することで表示画像を生成し、アクセスユニットのＰＴＳに従い当該表示画像を表示する（Ｓ２１１）。
なお、受信装置２００は、アクセスユニットのＤＴＳ及びＰＴＳを、ＭＰＵのヘッダ情報、又は、Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔのヘッダ情報を格納するＭＭＴパケットのペイロードデータを解析することにより取得する。また、受信装置２００は、多重化方式としてＴＳが使用されている場合にはＰＥＳパケットのヘッダからアクセスユニットのＤＴＳ及びＰＴＳを取得する。受信装置２００は、多重化方式としてＲＴＰが使用されている場合にはＲＴＰパケットのヘッダからアクセスユニットのＤＴＳ及びＰＴＳを取得する。
また、表示部２０５は、複数の復号部の復号結果を統合する際に、隣接する分割単位の境界においてデブロックフィルタなどのフィルタ処理を行ってもよい。なお、単一の復号部の復号結果を表示する場合にはフィルタ処理は不要であるため、表示部２０５は、複数の復号部の復号結果の境界にフィルタ処理を行うかどうかに応じて処理を切替えてもよい。フィルタ処理が必要かどうかは、分割の有無などに応じて予め規定されていてもよい。または、フィルタ処理が必要かどうかを示す情報が、多重化レイヤに別途格納されてもよい。また、フィルタ係数などフィルタ処理に必要な情報は、ＳＰＳ、ＰＰＳ、ＳＥＩ、又はスライスセグメント内に格納される場合がある。復号部２０４Ａ～２０４Ｄ、又は逆多重化部２０３がＳＥＩを解析することによりこれらの情報を取得し、取得された情報を表示部２０５に出力する。表示部２０５は、これらの情報を用いてフィルタ処理を行う。なお、これらの情報がスライスセグメント内に格納される場合には、復号部２０４Ａ～２０４Ｄがこれらの情報を取得することが望ましい。
なお、上記説明では、フラグメントに格納されるデータの種類がスライスセグメント前データとスライスセグメントとの２種類である場合の例を示したが、データの種類は３種類以上であってもよい。この場合には、ステップＳ２０３においてタイプに応じた場合分けが行われる。
また、送信装置１００は、スライスセグメントのデータサイズが大きい場合にスライスセグメントをフラグメント化してＭＭＴパケットに格納してもよい。つまり、送信装置１００は、スライスセグメント前データ及びスライスセグメントをフラグメント化してもよい。この場合に、図１１に示したパケット化の例のようにアクセスユニットとＤａｔａ ｕｎｉｔとを等しく設定すると以下の問題が生じる。
例えばスライスセグメント１が３つのフラグメントに分割される場合、スライスセグメント１がＦｒａｇｍｅｎｔ ｃｏｕｎｔｅｒ値が１から３の３つのパケットに分割して送信される。また、スライスセグメント２以降では、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒ値が４以上となり、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値とペイロードに格納されるデータとの対応付けが取れなくなる。従って、受信装置２００は、ＭＭＴパケットのヘッダの情報から、スライスセグメントの先頭データを格納するパケットを特定できない。
このような場合には、受信装置２００は、ＭＭＴパケットのペイロードのデータを解析して、スライスセグメントの開始位置を特定してもよい。ここで、Ｈ．２６４又はＨ．２６５においてＮＡＬユニットを多重化レイヤに格納する形式として、ＮＡＬユニットヘッダの直前に特定のビット列からなるスタートコードが付加されるバイトストリームフォーマットと呼ばれる形式と、ＮＡＬユニットのサイズを示すフィールドが付加されるＮＡＬサイズフォーマットと呼ばれる形式との２種類がある。
バイトストリームフォーマットは、ＭＰＥＧ－２システム及びＲＴＰなどにおいて用いられる。ＮＡＬサイズフォーマットは、ＭＰ４、並びにＭＰ４を使用するＤＡＳＨ及びＭＭＴなどにおいて用いられる。
バイトストリームフォーマットが用いられる場合、受信装置２００は、パケットの先頭データがスタートコードと一致するかどうかを解析する。受信装置２００は、パケットの先頭データがスタートコードと一致していれば、その後に続くＮＡＬユニットヘッダからＮＡＬユニットのタイプを取得することで、当該パケットに含まれるデータがスライスセグメントのデータであるかどうかを検出できる。
一方、ＮＡＬサイズフォーマットの場合には、受信装置２００は、ビット列に基づいてＮＡＬユニットの開始位置を検出できない。従って、受信装置２００は、ＮＡＬユニットの開始位置を取得するために、アクセスユニットの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズ分だけデータの読出すことでポインタをシフトさせていく必要がある。
但し、ＭＭＴにおけるＭＰＵ又はＭｏｖｉｅ Ｆｒａｇｍｅｎｔのヘッダにおいて、サブサンプル単位のサイズが示され、サブサンプルがスライス前データ又はスライスセグメントに対応する場合には、受信装置２００は、サブサンプルのサイズ情報に基づいて各ＮＡＬユニットの開始位置を特定できる。そのため、送信装置１００は、サブサンプル単位の情報がＭＰＵ又はＭｏｖｉｅ Ｆｒａｇｍｅｎｔに存在するかどうかを示す情報を、ＭＭＴにおけるＭＰＴなどの、受信装置２００がデータの受信開始時に取得する情報に含めてもよい。
なお、ＭＰＵのデータはＭＰ４フォーマットをベースに拡張したものである。ＭＰ４においては、Ｈ．２６４又はＨ．２６５のＳＰＳ及びＰＰＳなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードとがある。また、このモードを特定するための情報がＳａｍｐｌｅＥｎｔｒｙのエントリ名として示される。格納可能なモードが用いられており、パラメータセットがサンプルに含まれる場合には、受信装置２００は、上述した方法によりパラメータセットを取得する。
一方、格納できないモードが用いられている場合には、パラメータセットは、ＳａｍｐｌｅＥｎｔｒｙ内のＤｅｃｏｄｅｒ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎとして格納される、又は、パラメータセット用のストリームを用いて格納される。ここで、パラメータセット用のストリームは一般的には使用されていないので、送信装置１００は、Ｄｅｃｏｄｅｒ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎにパラメータセットを格納することが望ましい。この場合には、受信装置２００は、ＭＭＴパケットにおいてＭＰＵのメタデータ、又は、Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔのメタデータとしてとして送信されるＳａｍｐｌｅＥｎｔｒｙを解析して、アクセスユニットが参照するパラメータセットを取得する。
パラメータセットがサンプルデータとして格納される場合には、受信装置２００は、ＳａｍｐｌｅＥｎｔｒｙを参照せずにサンプルデータのみを参照すれば復号に必要なパラメータセットが取得できる。このとき、送信装置１００は、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットを格納しなくてもよい。こうすることで、送信装置１００は、異なるＭＰＵにおいて同一のＳａｍｐｌｅＥｎｔｒｙを用いることができるので、ＭＰＵ生成時の送信装置１００の処理負荷を低減できる。さらに、受信装置２００がＳａｍｐｌｅＥｎｔｒｙ内のパラメータセットを参照する必要がなくなるというメリットがある。
または、送信装置１００は、ＳａｍｐｌｅＥｎｔｒｙにデフォルトのパラメータセットを１つ格納し、アクセスユニットが参照するパラメータセットをサンプルデータに格納してもよい。従来のＭＰ４においては、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットを格納するのが一般的であったため、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが存在しない場合、再生を停止する受信装置が存在する可能性がある。上記の方法を用いることで、この問題を解決できる。
または、送信装置１００は、デフォルトのパラメータセットとは異なるパラメータセットが使用される場合にのみ、サンプルデータにパラメータセットを格納してもよい。
なお、両モード共に、パラメータセットをＳａｍｐｌｅＥｎｔｒｙに格納することは可能であるため、送信装置１００は、パラメータセットを常にＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙに格納し、受信装置２００は常にＶｉｓｕａｌＳａｍｐｌｅＥｎｔｒｙからパラメータセットを取得してもよい。
なお、ＭＭＴ規格においては、Ｍｏｏｖ及びＭｏｏｆなどＭＰ４のヘッダ情報は、ＭＰＵメタデータ、或いはムービーフラグメントメタデータとして伝送されるが、送信装置１００は、ＭＰＵメタデータ、および、ムービーフラグメントメタデータを必ずしも送信しなくてもよい。さらに、受信装置２００は、ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｕｓｉｎｅｓｓｅｓ）規格のサービス、アセットのタイプ、又は、ＭＰＵメタの伝送有無などに基づいて、サンプルデータ内にＳＰＳ及びＰＰＳが格納されるかどうかを判定することも可能である。
図１７は、スライスセグメント前データ及び各スライスセグメントが、それぞれ異なるＤａｔａ ｕｎｉｔに設定される場合の例を示す図である。
図１７に示す例では、スライスセグメント前データ、及びスライスセグメント１からスライスセグメント４までのデータサイズは、それぞれＬｅｎｇｔｈ＃１からＬｅｎｇｔｈ＃５である。ＭＭＴパケットのヘッダに含まれるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒ、及び、Ｏｆｆｓｅｔの各フィールド値は図中に示す通りである。
ここで、Ｏｆｆｓｅｔは、ペイロードデータが属するサンプル（アクセスユニット又はピクチャ）の符号化データの先頭から、当該ＭＭＴパケットに含まれるペイロードデータ（符号化データ）の先頭バイトまでのビット長（オフセット）を示すオフセット情報である。なお、Ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒの値はフラグメントの総数から１を減算した値から開始するとして説明するが、他の値から開始してもよい。
図１８は、Ｄａｔａ ｕｎｉｔがフラグメント化される場合の例を示す図である。図１８に示す例では、スライスセグメント１が３つのフラグメントに分割され、それぞれＭＭＴパケット＃２からＭＭＴパケット＃４に格納される。このときも、各フラグメントのデータサイズを、それぞれＬｅｎｇｔｈ＃２＿１からＬｅｎｇｔｈ＃２＿３とすると、各フィールドの値は図中に示す通りである。
このように、スライスセグメントなどのデータ単位がＤａｔａ ｕｎｉｔに設定される場合、アクセスユニットの先頭、及びスライスセグメントの先頭は、ＭＭＴパケットヘッダのフィールド値に基づいて以下のように決定できる。
Ｏｆｆｓｅｔの値が０であるパケットにおけるペイロードの先頭は、アクセスユニットの先頭である。
Ｏｆｆｓｅｔの値が０とは異なる値であり、かつ、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｃａｔｏｒｎｏ値が００又は０１であるパケットのペイロードの先頭が、スライスセグメントの先頭である。
また、Ｄａｔａ ｕｎｉｔのフラグメント化が発生せず、パケットロスも発生しない場合には、受信装置２００は、アクセスユニットの先頭を検出した後に取得したスライスセグメントの数に基づいて、ＭＭＴパケットに格納されるスライスセグメントのインデックス番号を特定できる。
また、スライスセグメント前データのＤａｔａ ｕｎｉｔがフラグメント化される場合においても、同様に、受信装置２００は、アクセスユニット、及びスライスセグメントの先頭を検出できる。
また、パケットロスが発生した場合、又は、スライスセグメント前データに含まれるＳＰＳ、ＰＰＳ及びＳＥＩが別々のＤａｔａ ｕｎｉｔに設定された場合においても、受信装置２００は、ＭＭＴヘッダの解析結果に基づいてスライスセグメントの先頭データを格納したＭＭＴパケットを特定し、その後、スライスセグメントのヘッダを解析することで、ピクチャ（アクセスユニット）内におけるスライスセグメント又はタイルの開始位置を特定できる。スライスヘッダの解析に係る処理量は小さく、処理負荷は問題とならない。
このように、複数のスライスセグメントの複数の符号化データの各々は、１以上のパケットに格納されるデータの単位である基本データ単位（Ｄａｔａ ｕｎｉｔ）と一対一で対応付けられている。また、複数の符号化データの各々は、１以上のＭＭＴパケットに格納される。
各ＭＭＴパケットのヘッダ情報は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ（識別情報）及びＯｆｆｓｅｔ（オフセット情報）を含む。
受信装置２００は、受信装置２００は、値が００又は０１であるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。具体的には、値が０でないＯｆｆｓｅｔと、値が００又は０１であるＦｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒとが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。
また、図１７の例では、Ｄａｔａ ｕｎｉｔの先頭は、アクセスユニットの先頭、又は、スライスセグメントの先頭のいずれかであり、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値は００又は０１である。さらに、受信装置２００は、ＮＡＬユニットのタイプを参照して、Ｄａｔａ Ｕｎｉｔの先頭がアクセスユニットデリミタ、又は、スライスセグメントのどちらであるかを判定することで、Ｏｆｆｓｅｔを参照せずに、アクセスユニットの先頭、又は、スライスセグメントの先頭を検出することも可能である。
このように、送信装置１００が、ＮＡＬユニットの先頭が必ずＭＭＴパケットのペイロードの先頭から開始されるようにパケット化を行うことで、スライスセグメント前データが複数のＤａｔａ ｕｎｉｔに分割される場合も含めて、受信装置２００は、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ及びＮＡＬユニットヘッダを解析することにより、アクセスユニット、又は、スライスセグメントの先頭を検出できる。ＮＡＬユニットのタイプは、ＮＡＬユニットヘッダの先頭バイトに存在する。従って、受信装置２００は、ＭＭＴパケットのヘッダ部を解析する際に、追加で１バイト分のデータを解析することによりＮＡＬユニットのタイプが取得できる。
オーディオの場合には、受信装置２００は、アクセスユニットの先頭が検出できればよく、Ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒの値が００又は０１であるかどうかに基づいて判定すればよい。
また、上述したように、分割復号ができるように符号化された符号化データをＭＰＥＧ－２ ＴＳのＰＥＳパケットに格納する場合には、送信装置１００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を用いることが可能である。以下、符号化データのＰＥＳパケットへの格納方法の例について詳細に説明する。
例えば、ＨＥＶＣにおいては、送信装置１００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を用いることにより、ＰＥＳパケットに格納されるデータがアクセスユニット、スライスセグメント、及び、タイルのいずれであるかを示すことができる。ＨＥＶＣにおけるアラインメントのタイプは、次のように規定されている。
アラインメントのタイプ＝８は、ＨＥＶＣのスライスセグメントを示す。アラインメントのタイプ＝９は、ＨＥＶＣのスライスセグメント又はアクセスユニットを示す。アラインメントのタイプ＝１２は、ＨＥＶＣのスライスセグメント又はタイルを示す。
よって、送信装置１００は、例えば、タイプ９を用いることで、ＰＥＳパケットのデータがスライスセグメント又はスライスセグメント前データのいずれかであることを示すことができる。スライスセグメントではなく、スライスを示すタイプも別途規定されているため、送信装置１００は、スライスセグメントではなくスライスを示すタイプを使用してもよい。
また、ＰＥＳパケットのヘッダに含まれるＤＴＳ及びＰＴＳは、アクセスユニットの先頭データを含むＰＥＳパケットにおいてのみ設定される。従って、受信装置２００は、タイプが９であり、かつ、ＰＥＳパケットにＤＴＳ又はＰＴＳのフィールドが存在すれば、ＰＥＳパケットにはアクセスユニット全体、又は、アクセスユニットにおける先頭の分割単位が格納されると判定できる。
また、送信装置１００は、アクセスユニットの先頭データを含むＰＥＳパケットを格納するＴＳパケットの優先度を示すｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｉｔｙなどのフィールドを用いて、受信装置２００がパケットに含まれるデータを区別できるようにしてもよい。また、受信装置２００は、ＰＥＳパケットのペイロードがアクセスユニットデリミタであるかどうかを解析することでパケットに含まれるデータを判定してもよい。また、ＰＥＳパケットヘッダのｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒは、これらのタイプに従ってＰＥＳパケットにデータが格納されているかどうかを示す。このフラグ（ｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒ）が１にセットされていれば、ＰＥＳパケットに格納されているデータはｄａｔａ ａｌｉｇｎｍｅｎｔ記述子に示されるタイプに従うことが保証される。
また、送信装置１００は、スライスセグメントなどの分割復号可能な単位でＰＥＳパケット化する場合にのみｄａｔａ ａｌｉｇｎｍｅｎｔ記述子を使用してもよい。これにより、受信装置２００は、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が存在する場合には、符号化データが分割復号可能な単位でＰＥＳパケット化されていると判断でき、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が存在しなければ、符号化データがアクセスユニット単位でＰＥＳパケット化されていると判断できる。なお、ｄａｔａ＿ａｌｉｇｎｍｅｎｔ＿ｉｎｄｉｃａｔｏｒが１にセットされており、ｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が存在しない場合には、ＰＥＳパケット化の単位がアクセスユニットであることはＭＰＥＧ－２ ＴＳ規格において規定されている。
受信装置２００は、ＰＭＴ内にｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が含まれていれば、分割復号可能な単位でＰＥＳパケット化されていると判定し、パケット化された単位に基づいて、各復号部への入力データを生成することができる。また、受信装置２００は、ＰＭＴ内にｄａｔａ ａｌｉｇｎｍｅｎｔ記述子が含まれておらず、番組情報、又はその他の記述子の情報に基づいて、符号化データの並列復号が必要と判定される場合には、スライスセグメントのスライスヘッダなどを解析することにより、各復号部への入力データを生成する。また、符号化データを単一の復号部により復号可能である場合には、受信装置２００は、アクセスユニット全体のデータを当該の復号部で復号する。なお、符号化データがスライスセグメント又はタイルなどの分割復号可能な単位から構成されるかどうかを示す情報が、ＰＭＴの記述子などにより別途示されている場合、受信装置２００は、当該記述子の解析結果に基づいて符号化データを並列復号できるかどうかを判定してもよい。
また、ＰＥＳパケットのヘッダに含まれるＤＴＳ及びＰＴＳは、アクセスユニットの先頭データを含むＰＥＳパケットにおいてのみ設定されるため、アクセスユニットが分割されてＰＥＳパケット化される場合には、２番目以降のＰＥＳパケットにはアクセスユニットのＤＴＳ及びＰＴＳを示す情報は含まれない。従って、復号処理を並列に行う場合、各復号部２０４Ａ～２０４Ｄ及び表示部２０５は、アクセスユニットの先頭データを含むＰＥＳパケットのヘッダに格納されるＤＴＳ及びＰＴＳを使用する。
（実施の形態２）
実施の形態２では、ＭＭＴにおいて、ＮＡＬサイズフォーマットのデータをＭＰ４フォーマットベースのＭＰＵに格納する方法について説明する。なお、以下では、一例として、ＭＭＴに用いられるＭＰＵへの格納方法について説明するが、このような格納方法は、同じＭＰ４フォーマットベースであるＤＡＳＨにも適用可能である。
［ＭＰＵへの格納方法］
ＭＰ４フォーマットでは、複数のアクセスユニットをまとめて、一つのＭＰ４ファイルに格納する。ＭＭＴに用いられるＭＰＵは、メディア毎のデータが一つのＭＰ４ファイルに格納され、データには任意の数のアクセスユニットを含むことができる。ＭＰＵは、単体で復号可能な単位であるため、例えば、ＭＰＵにはＧＯＰ単位のアクセスユニットが格納される。
図１９は、ＭＰＵの構成を示す図である。ＭＰＵの先頭は、ｆｔｙｐ、ｍｍｐｕ、及びｍｏｏｖであり、これらは、まとめてＭＰＵメタデータと定義される。ｍｏｏｖには、ファイルに共通の初期化情報、及びＭＭＴヒントトラックが格納される。
また、ｍｏｏｆには、サンプルやサブサンプル毎の初期化情報及びサイズ、提示時刻（ＰＴＳ）及び復号時刻（ＤＴＳ）を特定できる情報（ｓａｍｐｌｅ＿ｄｕｒａｔｉｏｎ、ｓａｍｐｌｅ＿ｓｉｚｅ、ｓａｍｐｌｅ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｔｉｍｅ＿ｏｆｆｓｅｔ）、並びにデータの位置を示すｄａｔａ＿ｏｆｆｓｅｔなどが格納される。
また、複数のアクセスユニットは、それぞれサンプルとしてｍｄａｔ（ｍｄａｔ ｂｏｘ）に格納される。ｍｏｏｆ及びｍｄａｔのうちサンプルを除くデータは、ムービーフラグメントメタデータ（以降では、ＭＦメタデータと記載する。）と定義され、ｍｄａｔのサンプルデータは、メディアデータと定義される。
図２０は、ＭＦメタデータの構成を示す図である。図２０に示されるように、ＭＦメタデータは、より詳細には、ｍｏｏｆ ｂｏｘ（ｍｏｏｆ）の、ｔｙｐｅ、ｌｅｎｇｔｈ、及びｄａｔａと、ｍｄａｔ ｂｏｘ（ｍｄａｔ）のｔｙｐｅ及びｌｅｎｇｔｈとからなる。
アクセスユニットをＭＰ４データに格納する際には、Ｈ．２６４やＨ．２６５のＳＰＳ、及び、ＰＰＳなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードがある。
ここで、上記格納できないモードにおいては、パラメータセットは、ｍｏｏｖにおけるＳａｍｐｌｅＥｎｔｒｙのＤｅｃｏｄｅｒ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎに格納される。また、上記格納できるモードにおいては、パラメータセットは、サンプル内に含められる。
ＭＰＵメタデータ、ＭＦメタデータ、及びメディアデータは、それぞれＭＭＴペイロードに格納され、これらのデータを識別可能な識別子として、ＭＭＴペイロードのヘッダには、フラグメントタイプ（ＦＴ）が格納される。ＦＴ＝０は、ＭＰＵメタデータであることを示し、ＦＴ＝１は、ＭＦメタデータであることを示し、ＦＴ＝２はメディアデータであることを示す。
なお、図１９では、ＭＰＵメタデータ単位及びＭＦメタデータ単位がデータユニットとしてＭＭＴペイロードに格納される例が図示されているが、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、及びｍｏｏｆなどの単位がデータユニットとして、データユニット単位でＭＭＴペイロードに格納されてもよい。同様に、図１９では、サンプル単位がデータユニットとしてＭＭＴペイロードに格納される例が図示されている。しかしながら、サンプル単位やＮＡＬユニット単位でデータユニットが構成され、このようなデータユニットがデータユニット単位でＭＭＴペイロードに格納されてもよい。このようなデータユニットがさらにフラグメントされた単位でＭＭＴペイロードに格納されてもよい。
［従来の送信方法と課題］
従来、複数のアクセスユニットをＭＰ４フォーマットにカプセル化する際、ＭＰ４に格納されるサンプルがすべて揃った時点でｍｏｏｖ及びｍｏｏｆが作成されていた。
ＭＰ４フォーマットを放送などを用いてリアルタイムに伝送する場合、例えば１つのＭＰ４ファイルに格納するサンプルがＧＯＰ単位であるとすると、ＧＯＰ単位の時間サンプルが蓄積された後にｍｏｏｖ及びｍｏｏｆが作成されるため、カプセル化に伴う遅延が発生する。このような送信側におけるカプセル化により、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延が常にＧＯＰ単位時間分長くなる。これにより、リアルタイムにサービスの提供を行うことが困難となり、特に、ライブコンテンツが伝送される場合には視聴者に対するサービスの劣化につながる。
図２１は、データの送信順序を説明するための図である。ＭＭＴを放送に適用する場合、図２１の（ａ）に示されるように、ＭＰＵの構成順にＭＭＴパケットに載せて送信（ＭＭＴパケット＃１、＃２、＃３、＃４、＃５、＃６の順に送信）すると、ＭＭＴパケットの送信にはカプセル化による遅延が生じる。
このカプセル化による遅延を防ぐために、図２１の（ｂ）に示されるように、ＭＰＵメタデータ及びＭＦメタデータなどのＭＰＵヘッダ情報を送らない（パケット＃１及び＃２を送信せず、パケット＃３－＃６をこの順に送信する）方法が提案されている。また、図２０の（ｃ）に示されるように、ＭＰＵヘッダ情報の作成を待たずにメディアデータを先に送信し、メディアデータの送信後にＭＰＵヘッダ情報を送信する（＃３－＃６、＃１、＃２の順で送信する）方法が考えられる。
受信装置は、ＭＰＵヘッダ情報が送信されていない場合、ＭＰＵヘッダ情報を用いずに復号する、また、受信装置は、ＭＰＵヘッダ情報がメディアデータに対して後送りされている場合には、ＭＰＵヘッダ情報の取得を待ってから復号する。
しかしながら、従来のＭＰ４準拠の受信装置では、ＭＰＵヘッダ情報を用いずに復号することが保証されていない。また、受信装置が特別な処理によりＭＰＵヘッダを用いずに復号を行う場合に従来の送信方法を用いると復号処理が煩雑となり、実時間の復号が困難となる可能性が高い。また、受信装置がＭＰＵヘッダ情報の取得を待ってから復号を行う場合には、受信装置がヘッダ情報を取得するまでの間メディアデータのバッファリングが必要であるが、バッファモデルが規定されておらず、復号が保証されていなかった。
そこで、実施の形態２に係る送信装置は、図２０の（ｄ）に示されるように、ＭＰＵメタデータに共通の情報のみを格納することで、ＭＰＵメタデータをメディアデータより先に送信する。そして、実施の形態２に係る送信装置は、生成に遅延が発生するＭＦメタデータをメディアデータより後に送信する。これにより、メディアデータの復号を保証できる送信方法或いは受信方法を提供する。
以下、図２１の（ａ）－（ｄ）の各送信方法を用いた場合の受信方法について説明する。
図２１に示される各送信方法では、まず、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順にＭＰＵデータを構成する。
ＭＰＵデータを構成した後、送信装置が図２１の（ａ）に示されるように、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータの順にデータを送信する場合、受信装置は、下記の（Ａ－１）及び（Ａ－２）のいずれかの方法で復号を行うことができる。
（Ａ－１）受信装置は、ＭＰＵヘッダ情報（ＭＰＵメタデータ及びＭＦメタデータ）を取得後、ＭＰＵヘッダ情報を用いてメディアデータを復号する。
（Ａ－２）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
このような方法はいずれも、送信側でカプセル化による遅延が発生するが、受信装置において、ＭＰＵヘッダ取得のためにメディアデータをバッファリングする必要がない利点がある。バッファリングをしない場合、バッファリングのためのメモリの搭載の必要はなく、さらにバッファリング遅延は発生しない。また、（Ａ－１）の方法は、ＭＰＵヘッダ情報を用いて復号を行うため、従来の受信装置にも適用可能ある。
送信装置が図２１の（ｂ）に示されるように、メディアデータのみを送信する場合、受信装置は下記の（Ｂ－１）の方法で復号を行うことができる。
（Ｂ－１）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
また、図示しないが、図２１の（ｂ）のメディアデータの送信よりも先にＭＰＵメタデータが送信されている場合、下記の（Ｂ－２）の方法で復号を行うことができる。
（Ｂ－２）受信装置は、ＭＰＵメタデータを用いてメディアデータを復号する。
上記（Ｂ－１）及び（Ｂ－２）の方法はいずれも、送信側でカプセル化による遅延が発生せず、かつ、ＭＰＵヘッダ取得のためにメディアデータをバッファリングする必要がない点が利点である。しかしながら、（Ｂ－１）及び（Ｂ－２）の方法はいずれも、ＭＰＵヘッダ情報を用いた復号を行わないため、復号に特別な処理が必要となる可能性がある。
送信装置が図２１の（ｃ）に示されるように、メディアデータ、ＭＰＵメタデータ、ＭＦメタデータの順にデータを送信する場合、受信装置は下記の（Ｃ－１）及び（Ｃ－２）のいずれかの方法で復号を行うことができる。
（Ｃ－１）受信装置は、ＭＰＵヘッダ情報（ＭＰＵメタデータ及びＭＦメタデータ）を取得後、メディアデータを復号する。
（Ｃ－２）受信装置は、ＭＰＵヘッダ情報を用いずに、メディアデータを復号する。
上記（Ｃ－１）の方法が用いられる場合は、ＭＰＵヘッダ情報の取得のためにメディアデータをバッファリングする必要がある。これに対し、上記（Ｃ－２）の方法が用いられる場合は、ＭＰＵヘッダ情報の取得のためのバッファリングを行う必要はない。
また、上記（Ｃ－１）及び（Ｃ－２）のいずれの方法も、送信側においてカプセル化による遅延は発生しない。また、（Ｃ－２）の方法は、ＭＰＵヘッダ情報を用いないため、特別な処理が必要となる可能性がある。
送信装置が、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順にデータを送信する場合、受信装置は、下記の（Ｄ－１）及び（Ｄ－２）のいずれかの方法で復号を行うことができる。
（Ｄ－１）受信装置は、ＭＰＵメタデータを取得後、さらにＭＦメタデータを取得し、その後、メディアデータを復号する。
（Ｄ－２）受信装置は、ＭＰＵメタデータを取得後、ＭＦメタデータを用いずにメディアデータを復号する。
上記（Ｄ－１）の方法が用いられる場合は、ＭＦメタデータ取得のためにメディアデータをバッファリングする必要があるが、上記（Ｄ－２）の方法の場合は、ＭＦメタデータ取得のためのバッファリングを行う必要はない。
上記（Ｄ－２）の方法は、ＭＦメタデータを用いた復号を行わないため、特別な処理が必要となる可能性がある。
以上説明したように、ＭＰＵメタデータ及びＭＦメタデータを用いて復号できる場合は、従来のＭＰ４受信装置でも復号できるというメリットがある。
なお、図２１では、ＭＰＵデータは、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順に構成されており、ｍｏｏｆにおいては、この構成に基づいてサンプルやサブサンプル毎の位置情報（オフセット）が定められている。また、ＭＦメタデータには、ｍｄａｔ ｂｏｘにおけるメディアデータ以外のデータ（ｂｏｘのサイズやタイプ）も含まれている。
このため、受信装置がＭＦメタデータに基づいてメディアデータを特定する場合には、受信装置は、データが送信された順番にかかわらず、ＭＰＵデータを構成した際の順番にデータを再構成した後、ＭＰＵメタデータのｍｏｏｖ或いはＭＦメタデータのｍｏｏｆを用いて復号を行う。
なお、図２１では、ＭＰＵデータは、ＭＰＵメタデータ、ＭＦＵメタデータ、メディアデータの順に構成されるが、図２１とは異なる順番でＭＰＵデータが構成され、位置情報（オフセット）が定められてもよい。
例えば、ＭＰＵデータがＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順に構成され、ＭＦメタデータにおいて負の位置情報（オフセット）が示されてもよい。この場合も、データが送信される順番にかかわらず、受信装置は、送信側においてＭＰＵデータが構成された際の順番にデータを再構成した後、ｍｏｏｖ或いはｍｏｏｆを用いて復号を行う。
なお、送信装置は、ＭＰＵデータを構成する際の順番を示す情報をシグナリングし、受信装置は、シグナリングされた情報に基づいてデータを再構成してもよい。
以上説明したように、受信装置は、図２１の（ｄ）に示されるように、パケット化されたＭＰＵメタデータ、パケット化されたメディアデータ（サンプルデータ）、パケット化されたＭＦメタデータをこの順に受信する。ここで、ＭＰＵメタデータは、第１のメタデータの一例であり、ＭＦメタデータは、第２のメタデータの一例である。
次に、受信装置は、受信されたＭＰＵメタデータ、受信されたＭＦメタデータ、及び受信されたサンプルデータを含むＭＰＵデータ（ＭＰ４フォーマットのファイル）を再構成する。そして、再構成されたＭＰＵデータに含まれるサンプルデータを、ＭＰＵメタデータ及びＭＦメタデータを用いて復号する。ＭＦメタデータは、送信側においてサンプルデータの生成後にのみ生成可能なデータ（例えば、ｍｂｏｘに格納されるｌｅｎｇｔｈ）を含むメタデータである。
なお、上記受信装置の動作は、より詳細には、受信装置を構成する各構成要素によって行われる。例えば、受信装置は、上記データの受信を行う受信部と、上記ＭＰＵデータの再構成を行う再構成部と、上記ＭＰＵデータの復号を行う復号部とを備える。なお、受信部、生成部、及び復号部のそれぞれは、マイクロコンピュータ、プロセッサ、専用回路などによって実現される。
［ヘッダ情報を用いずに復号を行う方法］
次に、ヘッダ情報を用いずに復号を行う方法について説明する。ここでは、送信側でヘッダ情報を送るか送らないかにかかわらず、受信装置においてヘッダ情報を用いずに復号する方法を説明する。すなわち、この方法は、図２１を用いて説明したいずれの送信方法を用いた場合においても適用可能である。ただし、一部の復号方法は、特定の送信方法の場合にのみ適用可能な復号方法である。
図２２は、ヘッダ情報を用いずに復号を行う方法の例を示す図である。図２２では、メディアデータのみが含まれるＭＭＴペイロード及びＭＭＴパケットのみが図示されており、ＭＰＵメタデータやＭＦメタデータが含まれるＭＭＴペイロード及びＭＭＴパケットは図示されていない。また、以下の図２２の説明においては、同じＭＰＵに属するメディアデータは連続して伝送されるものとする。また、メディアデータとしてペイロードにサンプルが格納されている場合を例に説明するが、以下の図２２の説明においては、当然ＮＡＬユニットが格納されていてもよいし、フラグメントされたＮＡＬユニットが格納されていてもよい。
メディアデータを復号するためには、受信装置は、まず、復号に必要な初期化情報を取得しなければならない。また、メディアがビデオであれば、受信装置は、サンプル毎の初期化情報を取得したり、ランダムアクセス単位であるＭＰＵの開始位置を特定し、サンプル及びＮＡＬユニットの開始位置を取得しなければならない。また、受信装置は、それぞれサンプルの復号時刻（ＤＴＳ）や提示時刻（ＰＴＳ）を特定する必要がある。
そこで、受信装置は、例えば、下記の方法を用いてヘッダ情報を用いずに復号を行うことができる。なお、ペイロードにＮＡＬユニット単位またはＮＡＬユニットをフラグメントした単位が格納される場合は、下記説明において「サンプル」を、「サンプルにおけるＮＡＬユニット」に読み替えればよい。
＜ランダムアクセス（＝ＭＰＵの先頭サンプルを特定）＞
ヘッダ情報が送信されない場合に、受信装置がＭＰＵの先頭サンプルを特定するには、下記方法１と方法２がある。なお、ヘッダ情報が送信される場合には、方法３を用いることができる。
［方法１］受信装置は、ＭＭＴパケットヘッダにおいて、‘ＲＡＰ＿ｆｌａｇ＝１’であるＭＭＴパケットに含まれるサンプルを取得する。
［方法２］受信装置は、ＭＭＴペイロードヘッダにおいて、‘ｓａｍｐｌｅ ｎｕｍｂｅｒ＝０’であるサンプルを取得する。
［方法３］受信装置は、メディアデータの前及び後ろの少なくともどちらか一方に、ＭＰＵメタデータ及びＭＦメタデータの少なくともどちらか一方が送信されている場合、受信装置は、ＭＭＴペイロードヘッダにおけるフラグメントタイプ（ＦＴ）がメディアデータへ切り替わったＭＭＴペイロードに含まれるサンプルを取得する。
なお、方法１及び方法２において、１つのペイロードに異なるＭＰＵに属する複数のサンプルが混在する場合、どのＮＡＬユニットがランダムアクセスポイント（ＲＡＰ＿ｆｌａｇ＝１或いはｓａｍｐｌｅ ｎｕｍｂｅｒ＝０）であるか判定不能である。このため、１つのペイロードに異なるＭＰＵのサンプルを混在させないといった制約、または、１つのペイロードに異なるＭＰＵのサンプルが混在する場合は、最後（或いは最初）のサンプルがランダムアクセスポイントである場合に、ＲＡＰ＿ｆｌａｇを１とするといった制約などが必要である。
また、受信装置がＮＡＬユニットの開始位置を取得するためには、サンプルの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズ分だけデータの読出しポインタをシフトさせていく必要がある。
データがフラグメントされている場合は、受信装置は、ｆｒａｇｍｅｎｔ＿ｉｎｄｉｃａｔｏｒやｆｒａｇｍｅｎｔ＿ｎｕｍｂｅｒを参照することで、データユニットを特定できる。
＜サンプルのＤＴＳの決定＞
サンプルのＤＴＳの決定方法には、下記方法１と方法２がある。
［方法１］受信装置は、予測構造に基づいて先頭サンプルのＤＴＳを決定する。ただし、この方法には符号化データの解析が必要であり、実時間での復号が困難である可能性があるため、次の方法２が望ましい。
［方法２］受信装置は、先頭サンプルのＤＴＳを別途送信し、送信された先頭サンプルのＤＴＳを取得する。先頭サンプルのＤＴＳの送信方法は、例えば、ＭＰＵ先頭サンプルのＤＴＳを、ＭＭＴ－ＳＩを用いて送信する方法や、サンプル毎のＤＴＳをＭＭＴパケットヘッダ拡張領域を用いて送信する方法などがある。なお、ＤＴＳは、絶対値でもよいし、ＰＴＳに対する相対値であってもよい。また、送信側において先頭サンプルのＤＴＳが含まれているかどうかをシグナリングしてもよい。
なお、方法１、方法２ともに、以降のサンプルのＤＴＳは、固定フレームレートであるとして算出する。
サンプル毎のＤＴＳをパケットヘッダに格納する方法として、拡張領域を用いる以外に、ＭＭＴパケットヘッダにおける３２ｂｉｔのＮＴＰタイムスタンプフィールドに、当該ＭＭＴパケットに含まれるサンプルのＤＴＳを格納する方法がある。１つのパケットヘッダのビット数（３２ｂｉｔ）でＤＴＳを表現できない場合は、ＤＴＳは、複数のパケットヘッダを用いて表現されてもよい。また、ＤＴＳは、パケットヘッダのＮＴＰタイムスタンプフィールドと拡張領域とを組み合わせて表現されてもよい。ＤＴＳ情報が含まれない場合は既知の値（例えばＡＬＬ０）とされる。
＜サンプルのＰＴＳの決定＞
受信装置は、先頭サンプルのＰＴＳを、ＭＰＵに含まれるアセット毎のＭＰＵタイムスタンプ記述子から取得する。受信装置は、以降のサンプルＰＴＳについては、固定フレームレートであるものとして、ＰＯＣ等のサンプルの表示順を示すパラメータなどから算出する。このように、ヘッダ情報を用いずにＤＴＳ、及びＰＴＳを算出するためには、固定フレームレートによる送信が必須となる。
また、ＭＦメタデータが送信されている場合、受信装置は、ＭＦメタデータに示される先頭サンプルからのＤＴＳやＰＴＳの相対時刻情報と、ＭＰＵタイムスタンプ記述子に示されるＭＰＵ先頭サンプルのタイムスタンプの絶対値とからＤＴＳ及びＰＴＳの絶対値を算出できる。
なお、符号化データ解析してＤＴＳ及びＰＴＳを算出する際には、受信装置は、アクセスユニットに含まれるＳＥＩ情報を用いて算出してもよい。
＜初期化情報（パラメータセット）＞
［ビデオの場合］
ビデオの場合、パラメータセットは、サンプルデータに格納される。また、ＭＰＵメタデータ及びＭＦメタデータが送信されない場合は、サンプルデータのみを参照することにより復号に必要なパラメータセットを取得できることを保証する。
また、図２１の（ａ）及び（ｄ）のように、ＭＰＵメタデータがメディアデータよりも先に送信される場合、ＳａｍｐｌｅＥｎｔｒｙにはパラメータセットは格納しないと規定されてもよい。この場合、受信装置は、ＳａｍｐｌｅＥｎｔｒｙのパラメータセットは参照せずにサンプル内のパラメータセットのみを参照する。
また、ＭＰＵメタデータがメディアデータよりも先に送信される場合、ＳａｍｐｌｅＥｎｔｒｙにはＭＰＵに共通のパラメータセットやデフォルトのパラメータセットが格納され、受信装置は、ＳａｍｐｌｅＥｎｔｒｙのパラメータセット及びサンプル内のパラメータセットを参照してもよい。ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが格納されることにより、ＳａｍｐｌｅＥｎｔｒｙにパラメータセットが存在しないと再生できない従来の受信装置でも復号を行うことが可能となる。
［オーディオの場合］
オーディオの場合、復号にはＬＡＴＭヘッダが必要であり、ＭＰ４では、ＬＡＴＭヘッダがサンプルエントリに含められることが必須である。しかし、ヘッダ情報が送信されない場合は、受信装置がＬＡＴＭヘッダを取得することは困難であるため、別途ＳＩなどの制御情報にＬＡＴＭヘッダが含められる。なお、ＬＡＴＭヘッダは、メッセージ、テーブル、または記述子に含められてもよい。なお、ＬＡＴＭヘッダはサンプル内に含められることもある。
受信装置は、復号開始前にＳＩなどからＬＡＴＭヘッダを取得し、オーディオの復号を開始する。或いは、図２１の（ａ）及び図２１の（ｄ）に示されるように、ＭＰＵメタデータがメディアデータよりも先に送信される場合は、受信装置は、ＬＡＴＭヘッダをメディアデータより先に受信可能である。したがって、ＭＰＵメタデータがメディアデータよりも先に送信される場合は、従来の受信装置を用いても復号を行うことが可能となる。
＜その他＞
送信順序や送信順序のタイプは、ＭＭＴパケットヘッダやペイロードヘッダ、或いは、ＭＰＴやその他のテーブル、メッセージ、記述子などの制御情報として通知されてもよい。なお、ここでの送信順序のタイプとは、例えば、図２１の（ａ）～（ｄ）の４つのタイプの送信順序であり、それぞれのタイプを識別するための識別子が復号開始前に取得できる場所に格納されればよい。
また、送信順序のタイプは、オーディオとビデオとで異なるタイプが用いられてもよいし、オーディオとビデオとで共通のタイプが用いられてもよい。具体的には、例えば、オーディオは、図２１の（ａ）に示されるように、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータの順番で送信され、ビデオは、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順番で送信されてもよい。
以上説明したような方法により、受信装置は、ヘッダ情報を用いずに復号を行うことが可能である。また、ＭＰＵメタデータがメディアデータよりも先に送信されている場合（図２１の（ａ）及び図２１の（ｄ））は、従来の受信装置でも復号を行うことが可能になる。
特に、ＭＦメタデータがメディアデータより後に送信されること（図２１の（ｄ））により、カプセル化による遅延を発生させず、かつ従来の受信装置でも復号を行うことが可能となる。
［送信装置の構成及び動作］
次に、送信装置の構成及び動作について説明する。図２３は、実施の形態２に係る送信装置のブロック図であり、図２４は、実施の形態２に係る送信方法のフローチャートである。
図２３に示されるように、送信装置１５は、符号化部１６と、多重化部１７と、送信部１８とを備える。
符号化部１６は、符号化対象のビデオまたはオーディオを、例えば、Ｈ．２６５に従い符号化することで符号化データを生成する（Ｓ１０）。
多重化部１７は、符号化部１６により生成された符号化データを多重化（パケット化）する（Ｓ１１）。具体的には、多重化部１７は、ＭＰ４フォーマットのファイルを構成する、サンプルデータ、ＭＰＵメタデータ、及び、ＭＦメタデータ、のそれぞれをパケット化する。サンプルデータは、映像信号または音声信号が符号化されたデータであり、ＭＰＵメタデータは、第１のメタデータの一例であり、ＭＦメタデータは、第２のメタデータの一例である。第１のメタデータと第２のメタデータとは、いずれもサンプルデータの復号に用いられるメタデータであるが、これらの違いは、第２のメタデータがサンプルデータの生成後にのみ生成可能なデータを含むことである。
ここで、サンプルデータの生成後にのみ生成可能なデータは、例えば、ＭＰ４フォーマットにおけるｍｄａｔに格納されるサンプルデータ以外のデータ（ｍｄａｔのヘッダ内のデータ。つまり、図２０に図示されるｔｙｐｅ及びｌｅｎｇｔｈ。）である。ここで、第２のメタデータには、このデータのうち少なくとも一部であるｌｅｎｇｔｈが含まれればよい。
送信部１８は、パケット化したＭＰ４フォーマットのファイルを送信する（Ｓ１２）。送信部１８は、例えば、図２１の（ｄ）に示される方法でＭＰ４フォーマットのファイルを送信する。つまり、パケット化されたＭＰＵメタデータ、パケット化されたサンプルデータ、パケット化されたＭＦメタデータをこの順に送信する。
なお、符号化部１６、多重化部１７、及び送信部１８のそれぞれは、マイクロコンピュータ、プロセッサ、または専用回路などによって実現される。
［受信装置の構成］
次に、受信装置の構成及び動作について説明する。図２５は、実施の形態２に係る受信装置のブロック図である。
図２５に示されるように、受信装置２０は、パケットフィルタリング部２１と、送信順序タイプ判別部２２と、ランダムアクセス部２３と、制御情報取得部２４と、データ取得部２５と、ＰＴＳ、ＤＴＳ算出部２６と、初期化情報取得部２７と、復号命令部２８と、復号部２９と、提示部３０とを備える。
［受信装置の動作１］
まず、メディアがビデオである場合に、受信装置２０が、ＭＰＵ先頭位置及びＮＡＬユニット位置を特定するための動作について説明する。図２６は、受信装置２０のこのような動作のフローチャートである。なお、ここでは、ＭＰＵデータの送信順序タイプは、送信装置１５（多重化部１７）によってＳＩ情報に格納されているとする。
まず、パケットフィルタリング部２１は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部２２は、パケットフィルタリングによって得られるＳＩ情報を解析して、ＭＰＵデータの送信順序タイプを取得する（Ｓ２１）。
次に、送信順序タイプ判別部２２は、パケットフィルタリング後のデータにＭＰＵヘッダ情報（ＭＰＵメタデータ或いはＭＦメタデータの少なくとも一方）が含まれているか否かを判定（判別）する（Ｓ２２）。ＭＰＵヘッダ情報（が含まれている場合（Ｓ２２でＹｅｓ）には、ランダムアクセス部２３は、ＭＭＴペイロードヘッダのフラグメントタイプがメディアデータへ切り替わることを検出することで、ＭＰＵ先頭サンプルを特定する（Ｓ２３）。
一方、ＭＰＵヘッダ情報が含まれていない場合（Ｓ２２でＮｏ）には、ランダムアクセス部２３は、ＭＭＴパケットヘッダのＲＡＰ＿ｆｌａｇ或いはＭＭＴペイロードヘッダのｓａｍｐｌｅ ｎｕｍｂｅｒに基づいてＭＰＵ先頭サンプルを特定する（Ｓ２４）。
また、送信順序タイプ判別部２２は、パケットフィルタリングされたデータに、ＭＦメタデータが含まれているか否かを判定する（Ｓ２５）。ＭＦメタデータが含まれていると判定された場合（Ｓ２５でＹｅｓ）には、データ取得部２５は、ＭＦメタデータに含まれるサンプル、サブサンプルのオフセット、及びサイズ情報に基づいてＮＡＬユニットを読み出すことによりＮＡＬユニットを取得する（Ｓ２６）。一方、ＭＦメタデータが含まれていないと判定された場合（Ｓ２５でＮｏ）には、データ取得部２５は、サンプルの先頭ＮＡＬユニットから順に、ＮＡＬユニットのサイズのデータを読み出すことでＮＡＬユニットを取得する（Ｓ２７）。
なお、受信装置２０は、ステップＳ２２において、ＭＰＵヘッダ情報が含まれていると判別された場合でも、ステップＳ２３ではなくステップＳ２４の処理を用いてＭＰＵ先頭サンプルを特定してもよい。また、ＭＰＵヘッダ情報が含まれていると判別された場合に、ステップＳ２３の処理とステップＳ２４の処理とが併用されてもよい。
また、受信装置２０は、ステップＳ２５において、ＭＦメタデータが含まれていると判定された場合でも、ステップＳ２６の処理を用いずにステップＳ２７の処理を用いてＮＡＬユニットを取得してもよい。また、ＭＦメタデータが含まれていると判定された場合に、ステップＳ２３の処理とステップＳ２４の処理とが併用されてもよい。
また、ステップＳ２５においてＭＦメタデータが含まれていると判定された場合であって、ＭＦデータがメディアデータより後に送信されている場合が想定される。この場合、受信装置２０は、メディアデータをバッファリングし、ＭＦメタデータを取得するまで待ってからステップＳ２６の処理を行ってもよいし、受信装置２０は、ＭＦメタデータの取得を待たずにステップＳ２７の処理を行うか否かを判定してもよい。
例えば、受信装置２０は、メディアデータをバッファリングすることが可能なバッファサイズのバッファを保有しているかどうかに基づいてＭＦメタデータの取得を待つか否かを判定してもよい。また、受信装置２０は、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延が小さくなるかどうかに基づいて、ＭＦメタデータの取得を待つか否かを判定してもよい。また、受信装置２０は、主としてステップＳ２６の処理を用いて復号処理を実施し、パケットロスなどが発生したときの処理モードの場合にステップＳ２７の処理を用いてもよい。
なお、送信順序タイプがあらかじめ定められている場合は、ステップＳ２２及びステップＳ２６は省略されてもよいし、この場合、受信装置２０は、バッファサイズやＥｎｄ－ｔｏ－Ｅｎｄ遅延を考慮して、ＭＰＵ先頭サンプルの特定方法、及び、ＮＡＬユニットの特定方法を決定してもよい。
なお、あらかじめ送信順序タイプが既知である場合は、受信装置２０において送信順序タイプ判別部２２は、不要である。
また、上記図２６においては説明されないが、復号命令部２８は、ＰＴＳ、ＤＴＳ算出部２６において算出されたＰＴＳ及びＤＴＳ、初期化情報取得部２７において取得された初期化情報に基づいて、データ取得部において取得されたデータを復号部２９に出力する。復号部２９は、データを復号し、提示部３０は、復号後のデータを提示する。
［受信装置の動作２］
次に、受信装置２０が、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作について説明する。図２７は、このような動作のフローチャートである。
まず、パケットフィルタリング部２１は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部２２は、パケットフィルタリングによって得られるＳＩ情報を解析し、送信順序タイプを取得する（Ｓ３０１）。
次に、送信順序タイプ判別部２２は、ＭＰＵメタデータが送信されているか否かを判定する（Ｓ３０２）。ＭＰＵメタデータが送信されていると判定された場合（Ｓ３０２でＹｅｓ）、送信順序タイプ判別部２２は、ステップＳ３０１の解析の結果、ＭＰＵメタデータがメディアデータより先に送信されているかどうかを判定する（Ｓ３０３）。ＭＰＵメタデータがメディアデータより先に送信されている場合（Ｓ３０３でＹｅｓ）、初期化情報取得部２７は、ＭＰＵメタデータに含まれる共通な初期化情報、及び、サンプルデータの初期化情報に基づいてメディアデータを復号する（Ｓ３０４）。
一方、ＭＰＵメタデータがメディアデータより後に送信されていると判定された場合（Ｓ３０３でＮｏ）には、データ取得部２５は、ＭＰＵメタデータが取得されるまでメディアデータをバッファリングし（Ｓ３０５）、ＭＰＵメタデータが取得された後にステップＳ３０４の処理を実施する。
また、ステップＳ３０２において、ＭＰＵメタデータが送信されていないと判定された場合（Ｓ３０２でＮｏ）には、初期化情報取得部２７は、サンプルデータの初期化情報のみに基づいてメディアデータを復号する（Ｓ３０６）。
なお、送信側においてサンプルデータの初期化情報に基づく場合のみメディアデータの復号が保証されている場合は、ステップＳ３０２、及びステップＳ３０３の判定に基づく処理を行わず、ステップＳ３０６の処理が用いられる。
また、受信装置２０は、ステップＳ３０５の前に、メディアデータをバッファリングするか否かの判定を行ってもよい。この場合、受信装置２０は、メディアデータをバッファリングすると判定した場合にはステップＳ３０５の処理へ移行し、メディアデータをバッファリングしないと判定した場合には、ステップＳ３０６の処理へ移行する。メディアデータをバッファリングするか否かの判定は、受信装置２０のバッファサイズ、占有量に基づいて行われてもよいし、例えば、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延の小さい方が選択されるなど、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延を考慮して判定が行われてもよい。
［受信装置の動作３］
ここでは、ＭＦメタデータがメディアデータよりも後に送信される場合（図２１の（ｃ）、及び図２１の（ｄ））における送信方法や受信方法の詳細について説明する。以下では、図２１の（ｄ）の場合を例に説明する。なお、送信においては、図２１の（ｄ）の方法のみが用いられ、送信順序タイプのシグナリングは行われないものとする。
先述のとおり、図２１の（ｄ）に示されるように、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順でデータを送信する場合、
（Ｄ－１）受信装置２０は、ＭＰＵメタデータを取得した後、さらにＭＦメタデータを取得した後にメディアデータを復号する。
（Ｄ－２）受信装置２０は、ＭＰＵメタデータを取得した後、ＭＦメタデータを用いずにメディアデータを復号する。
の２通りの復号方法が可能である。
ここで、Ｄ－１は、ＭＦメタデータ取得のためのメディアデータのバッファリングが必要となるが、ＭＰＵヘッダ情報を用いて復号を行うことができるため、従来のＭＰ４準拠の受信装置で復号可能となる。また、Ｄ－２は、ＭＦメタデータ取得のためのメディアデータのバッファリングを必要としないが、ＭＦメタデータを用いて復号できないため、復号に特別な処理が必要となる。
また、図２１の（ｄ）の方法は、ＭＦメタデータは、メディアデータより後で送信されるため、カプセル化による遅延は発生せず、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延を低減できるという利点を有する。
受信装置２０は、受信装置２０の能力や、受信装置２０が提供するサービス品質に応じて、上記２通りの復号方法を選択することができる。
送信装置１５は、受信装置２０における復号動作において、バッファのオーバーフローやアンダーフローの発生を低減して復号できることを保証しなければならない。Ｄ－１の方法を用いて復号する場合のデコーダモデルを規定するための要素としては、例えば下記のパラメータを用いることができる。
・ＭＰＵを再構成するためのバッファサイズ（ＭＰＵバッファ）
例えば、バッファサイズ＝最大レート×最大ＭＰＵ時間×αであり、最大レートとは、符号化データのプロファイル、レベルの上限レート＋ＭＰＵヘッダのオーバーヘッドである。また、最大ＭＰＵ時間は、１ＭＰＵ＝１ＧＯＰ（ビデオ）とした場合のＧＯＰの最大時間長である。
ここで、オーディオは、上記ビデオに共通のＧＯＰ単位としてもよいし、別の単位でもよい。αは、オーバーフローを起こさないためのマージンであり、最大レート×最大ＭＰＵ時間に対して、乗算されてもよいし、加算されてもよい。乗算される場合は、α≧１であり、加算される場合は、α≧０である。
・ＭＰＵバッファへデータが入力されてから復号されるまでの復号遅延時間の上限（ＭＰＥＧ－ＴＳのＳＴＤにおけるＴＳＴＤ＿ｄｅｌａｙ）
例えば、送信時には、最大ＭＰＵ時間、及び、復号遅延時間の上限値を考慮して、受信機におけるＭＰＵデータの取得完了時刻＜＝ＤＴＳとなるようにＤＴＳが設定される。
また、送信装置１５は、Ｄ－１の方法を用いて復号する場合のデコーダモデルに従い、ＤＴＳ及びＰＴＳを付与してもよい。これにより、送信装置１５は、Ｄ－１の方法を用いて復号を行う受信装置の当該復号を保証すると同時に、Ｄ－２の方法を用いて復号が行われる場合に必要な補助情報を送信してもよい。
例えば、送信装置１５は、Ｄ－２の方法を用いて復号する場合のデコーダバッファにおけるプリバッファリング時間をシグナリングすることにより、Ｄ－２の方法を用いて復号する受信装置の動作を保証できる。
プリバッファリング時間は、メッセージ、テーブル、記述子などのＳＩ制御情報に含められてもよいし、ＭＭＴパケット、ＭＭＴペイロードのヘッダに含められてもよい。また、符号化データ内のＳＥＩが上書きされてもよい。Ｄ－１の方法を用いて復号するためのＤＴＳ及びＰＴＳは、ＭＰＵタイムスタンプ記述子、ＳａｍｐｌｅＥｎｔｒｙに格納され、Ｄ－２の方法を用いて復号するためのＤＴＳ及びＰＴＳ、またはプリバッファリング時間がＳＥＩにおいて記述されてもよい。
受信装置２０は、当該受信装置２０がＭＰＵヘッダを用いたＭＰ４準拠の復号動作のみに対応している場合は、復号方法Ｄ－１を選択し、Ｄ－１およびＤ－２の両方に対応している場合は、どちらか一方を選択してもよい。
送信装置１５は、一方（本説明では、Ｄ－１）の復号動作を保証できるようにＤＴＳ、及びＰＴＳを付与し、さらに一方の復号動作を補助するための補助情報を送信してもよい。
また、Ｄ－２の方法が用いられる場合、Ｄ－１の方法が用いられる場合と比較して、ＭＦメタデータのプリバッファリングに起因する遅延により、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延が大きくなる可能性が高い。したがって、受信装置２０は、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延を小さくしたいときは、Ｄ－２の方法を選択して復号してもよい。例えば、受信装置２０は、常にＥｎｄ－ｔｏ－Ｅｎｄ遅延を削減したい場合に、常にＤ－２の方法を用いてもよい。また、受信装置２０は、ライブコンテンツや、選局、ザッピング動作など、低遅延で提示したい、低遅延提示モードで動作している場合のみＤ－２の方法を用いてもよい。
図２８は、このような受信方法のフローチャートである。
まず、受信装置２０は、ＭＭＴパケットを受信し、ＭＰＵデータを取得する（Ｓ４０１）。そして、受信装置２０（送信順序タイプ判別部２２）は、当該プログラムを低遅延提示モードで提示するかどうかの判定を行う（Ｓ４０２）。
プログラムを低遅延提示モードで提示しない場合（Ｓ４０２でＮｏ）、受信装置２０（ランダムアクセス部２３及び初期化情報取得部２７）は、ヘッダ情報を用いてランダムアクセス、初期化情報を取得する（Ｓ４０５）。また、受信装置２０（ＰＴＳ、ＤＴＳ算出部２６、復号命令部２８、復号部２９、提示部３０）は、送信側で付与されたＰＴＳ、ＤＴＳに基づいてデコード及び提示処理を行う（Ｓ４０６）。
一方、プログラムを低遅延提示モードで提示する場合（Ｓ４０２でＹｅｓ）、受信装置２０（ランダムアクセス部２３及び初期化情報取得部２７）は、ヘッダ情報を用いない復号方法を用いて、ランダムアクセス、初期化情報を取得する（Ｓ４０３）。また、受信装置２０は、送信側で付与されたＰＴＳ、ＤＴＳ及びヘッダ情報を用いずに復号するための補助情報に基づいてデコード及び提示処理を行う（Ｓ４０４）。なお、ステップＳ４０３、及びステップＳ４０４において、ＭＰＵメタデータを用いて処理が行われてもよい。
［補助データを用いた送受信方法］
以上、ＭＦメタデータがメディアデータより後に送信される場合（図２１の（ｃ）、及び図２１の（ｄ）の場合）における送受信動作について説明した。次に、送信装置１５がＭＦメタデータの一部の機能を有する補助データを送信することにより、より早く復号を開始でき、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延を削減できる方法について説明する。ここでは、図２１の（ｄ）に示される送信方法に基づいて補助データがさらに送信される例について説明されるが、補助データを用いる方法は、図２１の（ａ）～（ｃ）に示される送信方法においても適用可能である。
図２９の（ａ）は、図２１の（ｄ）に示される方法を用いて送信されたＭＭＴパケットを示す図である。つまり、データは、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順で送信される。
ここで、サンプル＃１、サンプル＃２、サンプル＃３、サンプル＃４はメディアデータに含まれるサンプルである。なお、ここではメディアデータは、サンプル単位でＭＭＴパケットに格納される例について説明されるが、メディアデータは、ＮＡＬユニット単位でＭＭＴパケットに格納されてもよいし、ＮＡＬユニットを分割した単位で格納されてもよい。なお、複数のＮＡＬユニットがアグリゲーションされてＭＭＴパケットに格納される場合もある。
先述のＤ－１で説明したように、図２１の（ｄ）に示される方法の場合、つまり、ＭＰＵメタデータ、メディアデータ、ＭＦメタデータの順でデータが送信される場合、ＭＰＵメタデータを取得後、さらにＭＦメタデータを取得し、その後、メディアデータを復号する方法がある。このようなＤ－１の方法では、ＭＦメタデータ取得のためのメディアデータのバッファリングが必要となるが、ＭＰＵヘッダ情報を用いて復号が行われるため、従来のＭＰ４準拠の受信装置にもＤ－１の方法は適用可能である利点がある。一方で、受信装置２０は、ＭＦメタデータ取得まで、復号開始を待たなければならない欠点がある。
これに対し、図２９の（ｂ）に示されるように、補助データを用いる手法においては、ＭＦメタデータより先に、補助データが送信される。
ＭＦメタデータには、ムービーフラグメントに含まれる全てのサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれている。これに対し、補助データには、ムービーフラグメントに含まれるサンプルのうち、一部のサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれる。
例えば、ＭＦメタデータには、すべてのサンプル（サンプル＃１－サンプル＃４）の情報が含まれるのに対し、補助データには一部のサンプル（サンプル＃１－＃２）の情報が含まれる。
図２９の（ｂ）に示される場合は、補助データが用いられることでサンプル＃１、及びサンプル＃２の復号が可能となるため、Ｄ－１の送信方法に対して、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延が小さくなる。なお、補助データには、どのようにサンプルの情報が組み合わされて含められてもよいし、補助データは、繰り返し送信されてもよい。
例えば、図２９の（ｃ）において、Ａのタイミングで補助情報を送信する場合は、送信装置１５は、補助情報にサンプル＃１の情報を含め、Ｂのタイミングで補助情報を送信する場合は、補助情報にサンプル＃１及びサンプル＃２の情報を含める。送信装置１５は、Ｃのタイミングで補助情報を送信する場合は、補助情報にはサンプル＃１、サンプル＃２、及びサンプル＃３の情報を含める。
なお、ＭＦメタデータには、サンプル＃１、サンプル＃２、サンプル＃３、及び、サンプル＃４の情報（ムービーフラグメントの中の全サンプルの情報）が含まれる。
補助データは、必ずしも生成後、ただちに送信される必要はない。
なお、ＭＭＴパケットやＭＭＴペイロードのヘッダにおいては、補助データが格納されていることを示すタイプが指定される。
例えば、補助データがＭＭＴペイロードにＭＰＵモードを用いて格納される場合は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅフィールド値（例えば、ＦＴ＝３）として、補助データであることを示すデータタイプが指定される。補助データは、ｍｏｏｆの構成に基づくデータであってもよいし、その他の構成であってもよい。
補助データが、ＭＭＴペイロードに制御信号（記述子、テーブル、メッセージ）として格納される場合は、補助データであることを示す記述子タグ、テーブルＩＤ、及びメッセージＩＤなどが指定される。
また、ＭＭＴパケットやＭＭＴペイロードのヘッダにＰＴＳまたはＤＴＳが格納されてもよい。
［補助データの生成例］
以下、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例について説明する。図３０は、送信装置がｍｏｏｆの構成に基づいて補助データを生成する例を説明するための図である。
通常のＭＰ４では、図２０に示されるように、ムービーフラグメントに対してｍｏｏｆが作成される。ｍｏｏｆには、ムービーフラグメントに含まれるサンプルのＤＴＳやＰＴＳ、オフセットやサイズを示す情報が含まれている。
ここでは、送信装置１５は、ＭＰＵを構成するサンプルデータの中で、一部のサンプルデータのみを用いてＭＰ４（ＭＰ４ファイル）を構成し、補助データを生成する。
例えば、図３０の（ａ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１－＃４のうち、サンプル＃１のみを用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを補助データとする。
次に、図３０の（ｂ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１－＃４のうち、サンプル＃１及びサンプル＃２を用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを次の補助データとする。
次に、図３０の（ｃ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１－＃４のうち、サンプル＃１、サンプル＃２、及びサンプル＃３を用いてＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダを次の補助データとする。
次に、図３０の（ｄ）に示されるように、送信装置１５は、ＭＰＵを構成するサンプル＃１－＃４のうち、すべてのＭＰ４を生成し、そのうち、ｍｏｏｆ＋ｍｄａｔのヘッダがムービーフラグメントメタデータとなる。
なお、ここでは、送信装置１５は、１サンプル毎に補助データを生成したが、Ｎサンプル毎に補助データを生成してもよい。Ｎの値は任意の数字であり、例えば、一つのＭＰＵを送信するときに補助データをＭ回送信する場合、Ｎ＝全サンプル／Ｍとされてもよい。
なお、ｍｏｏｆにおけるサンプルのオフセットを示す情報は、後続のサンプル数のサンプルエントリ領域がＮＵＬＬ領域として確保された後のオフセット値であってもよい。
なお、ＭＦメタデータをフラグメントする構成となるように補助データが生成されてもよい。
［補助データを用いた受信動作例］
図３０で説明したように生成された補助データの受信について説明する。図３１は、補助データの受信を説明するための図である。なお、図３１の（ａ）では、ＭＰＵを構成するサンプル数は３０であり、１０サンプル毎に補助データが生成され、送信されるものとする。
図３０の（ａ）において、補助データ＃１には、サンプル＃１－＃１０、補助データ＃２には、サンプル＃１－＃２０、ＭＦメタデータには、サンプル＃１－＃３０のサンプル情報がそれぞれ含まれる。
なお、サンプル＃１－＃１０、サンプル＃１１－＃２０、及びサンプル＃２１－＃３０は、一つのＭＭＴペイロードに格納されているが、サンプル単位やＮＡＬ単位で格納されてもよいし、フラグメントやアグリゲーションした単位で格納されてもよい。
受信装置２０は、ＭＰＵメタ、サンプル、ＭＦメタ、及び補助データのパケットをそれぞれ受信する。
受信装置２０は、サンプルデータを受信順に（後ろに）連結し、最新の補助データを受信した後に、これまでの補助データを更新する。また、受信装置２０は、最後に補助データをＭＦメタデータに置き換えることにより、完全なＭＰＵを構成できる。
受信装置２０は、補助データ＃１を受信した時点では、図３１の（ｂ）の上段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及び補助データ＃１の情報を用いてサンプル＃１－＃１０をパースすることができ、補助データに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
また、受信装置２０は、補助データ＃２を受信した時点では、図３１の（ｂ）の中段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及び補助データ＃２の情報を用いてサンプル＃１－＃２０をパースすることができ、補助データに含まれるＰＴＳ、ＤＴＳ、オフセット、サイズの情報に基づいて復号を行うことができる。
また、受信装置２０は、ＭＦメタデータを受信した時点では、図３１の（ｂ）の下段のようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタデータを用いてサンプル＃１－＃３０をパースすることができ、ＭＦメタデータに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
補助データが無い場合は、受信装置２０は、ＭＦメタデータの受信後にはじめてサンプルの情報を取得できるため、ＭＦメタデータの受信後に復号を開始する必要があった。しかしながら、送信装置１５が補助データを生成し、送信することにより、受信装置２０は、ＭＦメタデータの受信を待たずに、補助データを用いてサンプルの情報を取得できるため、復号開始時間を早めることができる。さらに、送信装置１５が図３０を用いて説明したｍｏｏｆに基づく補助データを生成することにより、受信装置２０は、従来のＭＰ４のパーサーをそのまま利用し、パースすることが可能である。
また、新たに生成する補助データやＭＦメタデータは、過去に送信した補助データと重複するサンプルの情報を含む。このため、パケットロスなどにより過去の補助データを取得できなかった場合でも、新たに取得する補助データやＭＦメタデータを用いることで、ＭＰ４を再構成し、サンプルの情報（ＰＴＳ、ＤＴＳ、サイズ、及びオフセット）を取得することが可能である。
なお、補助データは、必ずしも過去のサンプルデータの情報を含む必要はない。たとえば、補助データ＃１は、サンプルデータ＃１－＃１０に対応し、補助データ＃２は、サンプルデータ＃１１－＃２０に対応してもよい。例えば、図３１の（ｃ）に示されるように、送信装置１５は、完全なＭＦメタデータをデータユニットとして、データユニットをフラグメントした単位を補助データとして順次送出してもよい。
また、送信装置１５は、パケットロス対策のために、補助データを繰り返し伝送してもよいし、ＭＦメタデータを繰り返し伝送してもよい。
なお、補助データが格納されるＭＭＴパケット及びＭＭＴペイロードには、ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータと同様に、ＭＰＵシーケンス番号、及びアセットＩＤが含まれる。
以上のような補助データを用いた受信動作について図３２のフローチャートを用いて説明する。図３２は、補助データを用いた受信動作のフローチャートである。
まず、受信装置２０は、ＭＭＴパケットを受信し、パケットヘッダやペイロードヘッダを解析する（Ｓ５０１）。次に、受信装置２０は、フラグメントタイプが補助データか、ＭＦメタデータかを解析し（Ｓ５０２）、フラグメントタイプが補助データである場合には、過去の補助データを上書きして更新する（Ｓ５０３）。このとき、同一ＭＰＵの過去の補助データがない場合には、受信装置２０は、受信した補助データをそのまま新規の補助データとする。そして、受信装置２０は、ＭＰＵメタデータ、補助データ、及びサンプルデータに基づき、サンプルを取得し、復号を行う（Ｓ５０７）。
一方、フラグメントタイプがＭＦメタデータである場合には、受信装置２０は、ステップＳ５０５において、過去の補助データをＭＦメタデータで上書きする（Ｓ５０５）。そして、受信装置２０は、ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータに基づきサンプルを完全なＭＰＵの形で取得し、復号を行う（Ｓ５０６）。
なお、図３２において図示されないが、ステップＳ５０２において、受信装置２０は、フラグメントタイプがＭＰＵメタデータである場合には、データをバッファに格納し、サンプルデータである場合には、サンプル毎に後ろに連結したデータをバッファに格納する。
パケットロスにより補助データが取得できなかった場合は、受信装置２０は、最新の補助データにより上書きを行うか、あるいは過去の補助データを用いることによりサンプルを復号することができる。
なお、補助データの送出周期及び送出回数はあらかじめ定められた値であってもよい。送出周期や回数（カウント、カウンドダウン）の情報は、データと一緒に送信されてもよい。例えば、データユニットヘッダに、送出周期、送出回数、及びｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙなどのタイムスタンプが格納されてもよい。
ＭＰＵの初めのサンプルの情報を含む補助データをｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙより先に１回以上送信することにより、ＣＰＢバッファモデルに従うことが可能となる。このとき、ＭＰＵタイムスタンプ記述子には、ｐｉｃｔｕｒｅ ｔｉｍｉｎｇ ＳＥＩに基づいた値を格納される。
なお、このような補助データが使用される受信動作における伝送方式は、ＭＭＴ方式に限定されず、ＭＰＥＧ－ＤＡＳＨなど、ＩＳＯＢＭＦＦファイルフォーマットで構成されるパケットをストリーミング伝送する場合などに適用可能である。
［１つのＭＰＵが複数のムービーフラグメントで構成される場合の送信方法］
上記図１９以降の説明においては、１つのＭＰＵが、１つのムービーフラグメントで構成されたが、ここでは、１つのＭＰＵが複数のムービーフラグメントで構成される場合について説明する。図３３は、複数のムービーフラグメントで構成されるＭＰＵの構成を示す図である。
図３３では、１つのＭＰＵに格納されるサンプル（＃１－＃６）は、２つのムービーフラグメントに分けて格納される。第１のムービーフラグメントは、サンプル＃１－＃３に基づいて生成され、対応するｍｏｏｆボックスが生成される。第２のムービーフラグメントは、サンプル＃４－＃６に基づいて生成され、対応するｍｏｏｆボックスが生成される。
第１のムービーフラグメントにおけるｍｏｏｆボックス及びｍｄａｔボックスのヘッダは、ムービーフラグメントメタデータ＃１としてＭＭＴペイロード及びＭＭＴパケットに格納される。一方、第２のムービーフラグメントにおけるｍｏｏｆボックス及びｍｄａｔボックスのヘッダは、ムービーフラグメントメタデータ＃２としてＭＭＴペイロード及びＭＭＴパケットに格納される。なお、図３３において、ムービーフラグメントメタデータが格納されたＭＭＴペイロードは、ハッチングされている。
なお、ＭＰＵを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、ＭＰＵを構成するサンプル数をＧＯＰ単位のサンプル数とし、ＧＯＰ単位の２分の１のサンプル数をムービーフラグメントとして、２つのムービーフラグメントが構成されてもよい。
なお、ここでは、一つのＭＰＵに２つのムービーフラグメント（ｍｏｏｆボックス及びｍｄａｔボックス）を含む例を示すが、１つのＭＰＵに含むムービーフラグメントは２つでなくとも、３つ以上であってもよい。また、ムービーフラグメントに格納するサンプルは等分したサンプル数でなく、任意のサンプル数に分割してもよい。
なお、図３３では、ＭＰＵメタデータ単位及びＭＦメタデータ単位がそれぞれデータユニットとしてＭＭＴペイロードに格納されている。しかしながら、送信装置１５は、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、及びｍｏｏｆなどの単位をデータユニットとして、データユニット単位でＭＭＴペイロードに格納してもよいし、データユニットをフラグメントした単位でＭＭＴペイロードに格納してもよい。また、送信装置１５は、データユニットをアグリゲーションした単位でＭＭＴペイロードに格納してもよい。
また、図３３では、サンプルは、サンプル単位でＭＭＴペイロードに格納されている。しかしながら、送信装置１５は、サンプル単位でなくともＮＡＬユニット単位または複数のＮＡＬユニットをまとめた単位でデータユニットを構成し、データユニット単位でＭＭＴペイロードに格納してもよい。また、送信装置１５は、データユニットをフラグメントした単位でＭＭＴペイロードに格納してもよいし、データユニットをアグリゲーションした単位でＭＭＴペイロードに格納してもよい。
なお、図３３では、ｍｏｏｆ＃１、ｍｄａｔ＃１、ｍｏｏｆ＃２、ｍｄａｔ＃２の順にＭＰＵが構成され、ｍｏｏｆ＃１には、対応するｍｄａｔ＃１が後ろについているものとしてｏｆｆｓｅｔが付与されている。しかしながら、ｍｄａｔ＃１がｍｏｏｆ＃１より前についているものしてｏｆｆｓｅｔが付与されてもよい。ただし、この場合、ｍｏｏｆ＋ｍｄａｔの形でムービーフラグメントメタデータを生成することはできず、ｍｏｏｆ及びｍｄａｔのヘッダはそれぞれ別々に伝送される。
次に、図３３で説明した構成のＭＰＵが伝送される場合のＭＭＴパケットの送信順序について説明する。図３４は、ＭＭＴパケットの送信順序を説明するための図である。
図３４の（ａ）は、図３３に示されるＭＰＵの構成順序でＭＭＴパケットを送信する場合の送信順序を示している。図３４の（ａ）は、具体的には、ＭＰＵメタ、ＭＦメタ＃１、メディアデータ＃１（サンプル＃１－＃３）、ＭＦメタ＃２、メディアデータ＃２（サンプル＃４－＃６）の順に送信する例を示す。
図３４の（ｂ）は、ＭＰＵメタ、メディアデータ＃１（サンプル＃１－＃３）、ＭＦメタ＃１、メディアデータ＃２（サンプル＃４－＃６）、ＭＦメタ＃２の順に送信する例を示す。
図３４の（ｃ）は、メディアデータ＃１（サンプル＃１－＃３）、ＭＰＵメタ、ＭＦメタ＃１、メディアデータ＃２（サンプル＃４－＃６）、ＭＦメタ＃２の順に送信する例を示す。
ＭＦメタ＃１は、サンプル＃１－＃３を用いて生成され、ＭＦメタ＃２はサンプル＃４－＃６を用いて生成される。このため、図３４の（ａ）の送信方法が用いられる場合には、サンプルデータの送信にはカプセル化による遅延が発生する。
これに対し、図３４の（ｂ）及び図３４の（ｃ）の送信方法が用いられる場合には、ＭＦメタを生成するのを待たずにサンプルを送信可能であるため、カプセル化による遅延は発生せず、Ｅｎｄ－ｔｏ－Ｅｎｄ遅延を低減できる。
また、図３４の（ａ）送信順序においても、１つのＭＰＵが複数のムービーフラグメントに分割され、ＭＦメタに格納されるサンプル数が図１９の場合に対して小さくなっているため、図１９の場合よりもカプセル化による遅延量を小さくすることができる。
なお、ここで示した方法以外に、例えば、送信装置１５は、ＭＦメタ＃１及びＭＦメタ＃２を連結し、ＭＰＵの最後にまとめて送信してもよい。この場合、異なるムービーフラグメントのＭＦメタがアグリゲーションされて、一つのＭＭＴペイロードに格納されてもよい。また、異なるＭＰＵのＭＦメタがまとめてアグリゲーションされてＭＭＴペイロードに格納されてもよい。
［１つのＭＰＵが複数のムービーフラグメントで構成される場合の受信方法］
ここでは、図３４の（ｂ）で説明した送信順序で送信されたＭＭＴパケットを受信して復号する受信装置２０の動作例について説明する。図３５及び図３６は、このような動作例を説明するための図である。
受信装置２０は、図３５に示されるような送信順序で送信された、ＭＰＵメタ、サンプル、及びＭＦメタを含むＭＭＴパケットをそれぞれ受信する。サンプルデータは、受信順に連結される。
受信装置２０は、ＭＦメタ＃１を受信した時刻であるＴ１に、図３６の（１）に示されるようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタ＃１の情報に基づいてサンプル＃１－＃３を取得することができ、ＭＦメタに含まれるＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。
また、受信装置２０は、ＭＦメタ＃２を受信した時刻であるＴ２に、図３６の（２）に示されるようにデータを連結し、ＭＰ４を構成する。これにより、受信装置２０は、ＭＰＵメタデータ、及びＭＦメタ＃２の情報を基づいてサンプル＃４－＃６を取得することができ、ＭＦメタのＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報に基づいて復号を行うことができる。また、受信装置２０は、図３６の（３）に示されるようにデータを連結し、ＭＰ４を構成することでＭＦメタ＃１及びＭＦメタ＃２の情報に基づいてサンプル＃１－＃６を取得してもよい。
１つのＭＰＵが複数のムービーフラグメントに分割することで、ＭＰＵの中で初めのＭＦメタを取得するまでの時間が短縮されるため、復号開始時間を早めることができる。また、復号前のサンプルを蓄積するためのバッファサイズを小さくすることができる。
なお、送信装置１５は、ムービーフラグメントにおける初めのサンプルを送信（或いは受信）してからムービーフラグメントに対応するＭＦメタを送信（或いは受信）するまでの時間が、エンコーダで指定されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙより短い時間となるようにムービーフラグメントの分割単位を設定してもよい。このように設定することにより、受信バッファはｃｐｂバッファに従うことができ、低遅延の復号を実現できる。この場合、ＰＴＳ及びＤＴＳにはｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいた絶対時刻を用いることができる。
また、送信装置１５は、ムービーフラグメントの分割を等間隔、或いは、後続のムービーフラグメントを前のムービーフラグメントより短い間隔で分割してもよい。これにより、受信装置２０は、サンプルの復号前に必ず当該サンプルの情報を含むＭＦメタを受信することができ、連続した復号が可能となる。
ＰＴＳ、及びＤＴＳの絶対時刻の算出方法は、下記の２通りの方法を用いることができる。
（１）ＰＴＳ及びＤＴＳの絶対時刻は、ＭＦメタ＃１やＭＦメタ＃２の受信時刻（Ｔ１或いはＴ２）、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定される。
（２）ＰＴＳ及びＤＴＳの絶対時刻は、ＭＰＵタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定される。
また、（２－Ａ）送信装置１５がシグナリングする絶対時刻は、エンコーダから指定されるｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいて算出された絶対時刻であってもよい。
また、（２－Ｂ）送信装置１５がシグナリングする絶対時刻は、ＭＦメタの受信時刻の予測値に基づいて算出された絶対時刻であってもよい。
なお、ＭＦメタ＃１及びＭＦメタ＃２は、繰り返し伝送されてもよい。ＭＦメタ＃１及びＭＦメタ＃２が繰り返し伝送されることにより、受信装置２０は、ＭＦメタをパケットロス等により取得できなかった場合でも、もう一度取得することができる。
ムービーフラグメントを構成するサンプルを含むＭＦＵのペイロードヘッダには、ムービーフラグメントの順番を示す識別子を格納することができる。一方、ムービーフラグメントを構成するＭＦメタの順番を示す識別子はＭＭＴペイロードには含まれない。このため、受信装置２０は、ｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒでＭＦメタの順番を識別する。或いは、送信装置１５は、ＭＦメタが何番目のムービーフラグメントに属するかを示す識別子を、制御情報（メッセージ、テーブル、記述子）、ＭＭＴヘッダ、ＭＭＴペイロードヘッダ、またはデータユニットヘッダに格納してシグナリングしてもよい。
なお、送信装置１５は、ＭＰＵメタ、ＭＦメタ、及びサンプルを、あらかじめ定められた所定の送信順序で送信し、受信装置２０は、あらかじめ定められた所定の送信順序に基づいて受信処理を実施してもよい。また、送信装置１５は、送信順序をシグナリングし、シグナリング情報に基づいて受信装置２０が受信処理を選択（判断）してもよい。
上記のような受信方法について、図３７を用いて説明する。図３７は、図３５及び図３６で説明した受信方法の動作のフローチャートである。
まず、受信装置２０は、ＭＭＴペイロードに示されるフラグメントタイプにより、ペイロードに含まれるデータが、ＭＰＵメタデータ、ＭＦメタデータであるか、サンプルデータ（ＭＦＵ）であるかを判別（識別）する（Ｓ６０１、Ｓ６０２）。データがサンプルデータである場合には、受信装置２０は、サンプルをバッファリングし、当該サンプルに対応するＭＦメタデータの受信、及び復号開始を待つ（Ｓ６０３）。
一方、ステップＳ６０２において、データがＭＦメタデータである場合には、受信装置２０は、ＭＦメタデータよりサンプルの情報（ＰＴＳ、ＤＴＳ、位置情報、及びサイズ）を取得し、取得したサンプルの情報に基づいてサンプルを取得し、ＰＴＳ及びＤＴＳに基づいてサンプルを復号、提示する（Ｓ６０４）。
なお、図示されないが、データがＭＰＵメタデータである場合、ＭＰＵメタデータには、復号に必要な初期化情報が含まれている。このため、受信装置２０はこれを蓄積し、ステップＳ６０４においてサンプルデータの復号に用いる。
なお、受信装置２０は、受信したＭＰＵのデータ（ＭＰＵメタデータ、ＭＦメタデータ、及びサンプルデータ）を蓄積装置に蓄積する場合には、図１９または図３３で説明した、ＭＰＵの構成に並び替えた後に、蓄積する。
なお、送信側においては、ＭＭＴパケットには、同一のパケットＩＤを持つパケットに対して、パケットシーケンス番号を付与する。このとき、ＭＰＵメタデータ、ＭＦメタデータ、サンプルデータを含むＭＭＴパケットが送信順序に並び替えられた後にパケットシーケンス番号が付与されてもよいし、並び替える前の順序でパケットシーケンス番号が付与されてもよい。
並び替える前の順序でパケットシーケンス番号が付与される場合には、受信装置２０において、パケットシーケンス番号に基づいて、データをＭＰＵの構成順序に並び替えることができ、蓄積が容易となる。
［アクセスユニットの先頭及びスライスセグメントの先頭を検出する方法］
ＭＭＴパケットヘッダ、及びＭＭＴペイロードヘッダの情報に基づき、アクセスユニットの先頭やスライスセグメントの先頭を検出する方法について説明する。
ここでは、非ＶＣＬ ＮＡＬユニット（アクセスユニットデリミタ、ＶＰＳ、ＳＰＳ、ＰＰＳ、及びＳＥＩなど）を、まとめてデータユニットとしてＭＭＴペイロードに格納する場合、及び、非ＶＣＬ ＮＡＬユニットをそれぞれデータユニットとし、データユニットをアグリゲーションして１つのＭＭＴペイロードに格納する場合の２つの例を示す。
図３８は、非ＶＣＬ ＮＡＬユニットを、個別にデータユニットとし、アグリゲーションする場合を示す図である。
図３８の場合、アクセスユニットの先頭は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅ値がＭＦＵであるＭＭＴパケットであり、かつ、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が１であり、かつｏｆｆｓｅｔ値が０であるデータユニットを含むＭＭＴペイロードの先頭データである。このとき、Ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値は０である。
また、図３８の場合、スライスセグメントの先頭は、ｆｒａｇｍｅｎｔ＿ｔｙｐｅ値がＭＦＵであるＭＭＴパケットであり、かつａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が０、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるＭＭＴペイロードの先頭データである。
図３９は、非ＶＣＬ ＮＡＬユニットを、まとめてデータユニットとする場合を示す図である。なお、パケットヘッダのフィールド値は、図１７（または図１８）で示した通りである。
図３９の場合、アクセスユニットの先頭は、Ｏｆｆｓｅｔ値が０であるパケットにおけるペイロードの先頭データが、アクセスユニットの先頭となる。
また、図３９の場合、スライスセグメントの先頭は、Ｏｆｆｓｅｔ値が０とは異なる値であり、ｆｒａｇｍｅｎｔａｔｉｏｎ ｉｎｄｉｃａｔｏｒ値が００或いは０１であるパケットのペイロードの先頭データが、スライスセグメントの先頭となる。
［パケットロスが発生した場合の受信処理］
通常、パケットロスが発生する環境において、ＭＰ４形式のデータを伝送する場合、受信装置２０は、ＡＬＦＥＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ ＦＥＣ）や、パケット再送制御等によりパケットを復元する。
しかし、放送のようなストリーミングにおいてＡＬ－ＦＥＣを用いられない場合にパケットロスが発生した場合には、パケットを復元できない。
受信装置２０は、パケットロスによりデータが失われた後、再び映像や音声の復号を再開させる必要がある。そのためには、受信装置２０は、アクセスユニットやＮＡＬユニットの先頭を検出し、アクセスユニットやＮＡＬユニットの先頭から復号を開始する必要がある。
しかし、ＭＰ４形式のＮＡＬユニットの先頭には、スタートコードがついていないため、受信装置２０は、ストリームを解析しても、アクセスユニットやＮＡＬユニットの先頭を検出できない。
図４０は、パケットロスが発生した場合の受信装置２０の動作のフローチャートである。
受信装置２０は、ＭＭＴパケットやＭＭＴペイロードのヘッダにおけるＰａｃｋｅｔｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒや、ｐａｃｋｅｔ ｃｏｕｎｔｅｒ、ｆｒａｇｍｅｎｔ ｃｏｕｎｔｅｒなどによりパケットロスを検出し（Ｓ７０１）、前後の関係から、どのパケットが消失したかを判定する（Ｓ７０２）。
受信装置２０は、パケットロスが発生していないと判定された場合（Ｓ７０２でＮｏ）には、ＭＰ４ファイルを構成し、アクセスユニット或いはＮＡＬユニットを復号する（Ｓ７０３）。
受信装置２０は、パケットロスが発生したと判定された場合（Ｓ７０２でＹｅｓ）には、パケットロスしたＮＡＬユニットに相当するＮＡＬユニットをダミーデータにより生成し、ＭＰ４ファイルを構成する（Ｓ７０４）。受信装置２０は、ＮＡＬユニットにダミーデータを入れる場合には、ＮＡＬユニットのタイプにダミーデータであることを示す。
また、受信装置２０は、図１７、図１８、図３８、及び図３９で説明した方法に基づいて、次のアクセスユニットやＮＡＬユニットの先頭を検出し、先頭データからデコーダに入力することで、復号を再開することができる（Ｓ７０５）。
なお、パケットロスが発生した場合には、受信装置２０は、パケットヘッダに基づいて検出された情報に基づいてアクセスユニット及びＮＡＬユニットの先頭から復号を再開してもよいし、ダミーデータのＮＡＬユニットを含む、再構成されたＭＰ４ファイルのヘッダ情報に基づいてアクセスユニット及びＮＡＬユニットの先頭から復号を再開してもよい。
受信装置２０は、ＭＰ４ファイル（ＭＰＵ）を蓄積する際には、パケットロスにより消失したパケットデータ（ＮＡＬユニットなど）は、放送や通信から別途取得して蓄積（置き換え）してもよい。
このとき、受信装置２０は、消失したパケットを通信から取得する場合には、消失したパケットの情報（パケットＩＤや、ＭＰＵシーケンス番号、パケットシーケンス番号、ＩＰデータフロー番号、及びＩＰアドレスなど）をサーバーに通知し、当該パケットを取得する。受信装置２０は、消失したパケットのみに限らず、消失したパケット前後のパケット群を同時に取得してもよい。
［ムービーフラグメントの構成方法］
ここでは、ムービーフラグメントの構成方法について詳細に説明する。
図３３で説明されたように、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数は、任意である。例えば、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数は、固定的に定められた所定の数であってもよいし、動的に決定されてもよい。
ここで、送信側（送信装置１５）において下記の条件を満たすようにムービーフラグメントが構成されることで、受信装置２０における低遅延の復号を保証することができる。
その条件とは、以下の通りである。
送信装置１５は、受信装置２０が、任意のサンプル（Ｓａｍｐｌｅ（ｉ））の復号時刻（ＤＴＳ（ｉ））より前には必ず当該サンプルの情報を含むＭＦメタを受信できるように、サンプルデータを分割した単位をムービーフラグメントとしてＭＦメタを生成・送信する。
具体的には、送信装置１５は、ＤＴＳ（ｉ）より前に符号化済のサンプル（ｉ番目のサンプルを含む）を用いてムービーフラグメントを構成する。
低遅延の復号を保証するように、ムービーフラグメントを構成するサンプル数や１つのＭＰＵを構成するムービーフラグメント数を動的に決定する方法としては、例えば、下記の方法が用いられる。
（１）復号開始時、ＧＯＰ先頭のサンプルＳａｍｐｌｅ（０）の復号時刻ＤＴＳ（０）は、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに基づいた時刻である。送信装置は、ＤＴＳ（０）より前の時刻に、符号化完了済のサンプルを用いて第１のムービーフラグメントを構成する。また、送信装置１５は、第１のムービーフラグメントに対応するＭＦメタデータを生成し、ＤＴＳ（０）より前の時刻に送信する。
（２）送信装置１５は、以降のサンプルにおいても、上記の条件を満たすようにムービーフラグメントを構成する。
例えば、ムービーフラグメントの先頭のサンプルがｋ番目のサンプルであるとしたとき、ｋ番目のサンプルを含むムービーフラグメントのＭＦメタは、ｋ番目のサンプルの復号時刻ＤＴＳ（ｋ）までに送信される。送信装置１５は、ｌ番目のサンプルの符号化完了時刻がＤＴＳ（ｋ）より前であり、（ｌ＋１）番目のサンプルの符号化完了時刻がＤＴＳ（ｋ）より後である場合には、ｋ番目のサンプルからｌ番目のサンプルを用いてムービーフラグメントを構成する。
なお、送信装置１５は、ｋ番目のサンプルから、ｌ番目に満たないサンプルまでを用いてムービーフラグメントを構成してもよい。
（３）送信装置１５は、ＭＰＵ最後のサンプルの符号化完了後、残りのサンプルを用いてムービーフラグメントを構成し、当該ムービーフラグメントに対応するＭＦメタデータを生成し、送信する。
なお、送信装置１５は、符号化完了済のすべてのサンプルを用いてムービーフラグメントを構成せずに、符号化完了済の一部のサンプルを用いてムービーフラグメントを構成してもよい。
なお、上記では、低遅延の復号を保証するように、上記条件に基づいて動的に、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数が決定される例を示した。しかしながら、サンプル数及びムービーフラグメント数の決定方法は、このような方法に限定されるものではない。例えば、１つのＭＰＵを構成するムービーフラグメント数が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。また、１つのＭＰＵを構成するムービーフラグメント数、及びムービーフラグメントを分割する時刻（或いはムービーフラグメントの符号量）が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。
また、ＭＰＵが複数のムービーフラグメントに分割されている場合、ＭＰＵが複数のムービーフラグメントに分割されているかどうかを示す情報、分割されたムービーフラグメントの属性、または分割されたムービーフラグメントに対するＭＦメタの属性が送信されてもよい。
ここで、ムービーフラグメントの属性とは、ムービーフラグメントが、ＭＰＵの先頭のムービーフラグメントであるか、ＭＰＵの最後のムービーフラグメントであるか、それ以外のムービーフラグメントであるか等を示す情報である。
また、ＭＦメタの属性とは、ＭＦメタが、ＭＰＵの先頭のムービーフラグメントに対応するＭＦメタであるか、ＭＰＵの最後のムービーフラグメントに対応するＭＦメタであるか、それ以外のムービーフラグメントに対応するＭＦメタであるか等を示す情報である。
なお、送信装置１５は、ムービーフラグメントを構成するサンプル数、及び、１つのＭＰＵを構成するムービーフラグメント数を制御情報として格納し、送信してもよい。
［受信装置の動作］
上記のように構成されたムービーフラグメントに基づく受信装置２０の動作について説明する。
受信装置２０は、ＰＴＳ及びＤＴＳのそれぞれの絶対時刻を、ＭＰＵタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻に基づいて決定する。
受信装置２０は、ＭＰＵが複数のムービーフラグメントに分割されているかどうかの情報に基づいて、ＭＰＵが分割されている場合は、分割されたムービーフラグメントの属性に基づいて、下記のように処理をする。
（１）受信装置２０は、ムービーフラグメントがＭＰＵの先頭のムービーフラグメントである場合、ＭＰＵタイムスタンプ記述子に含まれる先頭サンプルのＰＴＳの絶対時刻、及びＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻を用いて、ＰＴＳ及びＤＴＳの絶対時刻を生成する。
（２）受信装置２０は、ムービーフラグメントがＭＰＵの先頭のムービーフラグメントでない場合、ＭＰＵタイムスタンプ記述子の情報を用いずに、ＭＦメタに含まれるＰＴＳ及びＤＴＳの相対時刻を用いて、ＰＴＳ及びＤＴＳの絶対時刻を生成する。
（３）受信装置２０は、ムービーフラグメントがＭＰＵの最後のムービーフラグメントである場合、すべてのサンプルのＰＴＳ及びＤＴＳの絶対時刻を算出後、ＰＴＳ及びＤＴＳの計算処理（相対時刻の加算処理）をリセットする。なお、リセット処理は、ＭＰＵ先頭のムービーフラグメントにおいて実施してもよい。
受信装置２０は、下記のようにムービーフラグメントが分割されているかどうかの判定を行ってもよい。また、受信装置２０は、下記のようにムービーフラグメントの属性情報を取得してもよい。
例えば、受信装置２０は、ＭＭＴＰ（ＭＭＴ Ｐｒｏｔｏｃｏｌ）ペイロードヘッダに示されるムービーフラグメントの順番を示す識別子ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値に基づいて分割されているかどうかを判定してもよい。
具体的には、受信装置２０は、１つのＭＰＵに含まれるムービーフラグメントの数が１であり、かつ、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値が１であり、かつ、当該フィールド値が２以上の値が存在する場合に、当該ＭＰＵは複数のムービーフラグメントに分割されていると判定してもよい。
また、受信装置２０は、１つのＭＰＵに含まれるムービーフラグメントの数が１であり、かつ、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールド値が０であり、かつ、当該フィールド値が０以外の値が存在する場合に、当該ＭＰＵは複数のムービーフラグメントに分割されていると判定してもよい。
ムービーフラグメントの属性情報も同様に、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒに基づいて判定されてもよい。
なお、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒを用いずとも、一つＭＰＵに含まれるムービーフラグメントやＭＦメタの送信をカウントすることにより、ムービーフラグメントが分割されているかどうかや、ムービーフラグメントの属性情報を判定されてもよい。
以上説明したような送信装置１５および受信装置２０の構成により、受信装置２０は、ＭＰＵよりも短い間隔でムービーフラグメントメタデータを受信でき、低遅延での復号開始が可能となる。また、ＭＰ４パースの方法に基づいた復号処理を用いて、低遅延での復号を行うことが可能となる。
以上説明したようにＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作について、フローチャートを用いて説明する。図４１は、ＭＰＵが複数のムービーフラグメントに分割されている場合の受信動作のフローチャートである。なお、このフローチャートは、図３７のステップＳ６０４の動作をより詳細に図示するものである。
まず、受信装置２０は、ＭＭＴＰペイロードヘッダに示されるデータ種別に基づいて、データ種別がＭＦメタである場合に、ＭＦメタデータを取得する（Ｓ８０１）。
次に、受信装置２０は、ＭＰＵが複数のムービーフラグメントに分割されているかどうかを判定し（Ｓ８０２）、ＭＰＵが複数のムービーフラグメントに分割されている場合（Ｓ８０２でＹｅｓ）には、受信したＭＦメタデータがＭＰＵ先頭のメタデータであるかどうかを判定する（Ｓ８０３）。受信装置２０は、受信したＭＦメタデータがＭＰＵ先頭のＭＦメタデータである場合（Ｓ８０３でＹｅｓ）には、ＭＰＵタイムスタンプ記述子に示されるＰＴＳの絶対時刻、並びにＭＦメタデータに示されるＰＴＳ及びＤＴＳの相対時刻よりＰＴＳ及びＤＴＳの絶対時刻を算出し（Ｓ８０４）、ＭＰＵの最後のメタデータであるかどうかの判定を行う（Ｓ８０５）。
一方、受信装置２０は、受信したＭＦメタデータがＭＰＵ先頭のＭＦメタデータでない場合（Ｓ８０３でＮｏ）には、ＭＰＵタイムスタンプ記述子の情報は用いずＭＦメタデータに示されるＰＴＳ及びＤＴＳの相対時刻を用いてＰＴＳ及びＤＴＳの絶対時刻を算出し（Ｓ８０８）、ステップＳ８０５の処理に移行する。
ステップＳ８０５において、ＭＰＵ最後のＭＦメタデータであると判定された場合（Ｓ８０５でＹｅｓ）、受信装置２０は、すべてのサンプルのＰＴＳ及びＤＴＳの絶対時刻を算出後、ＰＴＳ及びＤＴＳの計算処理をリセットする。ステップＳ８０５においてＭＰＵ最後のＭＦメタデータでないと判定された場合（Ｓ８０５でＮｏ）、受信装置２０は処理を終了する。
また、ステップＳ８０２においてＭＰＵが複数のムービーフラグメントに分割されていないと判定された場合（Ｓ８０２でＮｏ）には、受信装置２０は、ＭＰＵの後に送信されるＭＦメタデータに基づき、サンプルデータを取得し、ＰＴＳ及びＤＴＳを決定する（Ｓ８０７）。
そして、図示されないが、受信装置２０は、最後に、決定したＰＴＳ及びＤＴＳに基づいて復号処理、提示処理を実施する。
［ムービーフラグメントを分割したときに発生する課題、及び、その解決策］
これまで、ムービーフラグメントを分割することによりＥｎｄ－ｔｏ－Ｅｎｄ遅延を短縮する方法について説明してきた。ここからは、ムービーフラグメントを分割したときに新たに発生する課題、及び、その解決策について説明する。
まず、背景として、符号化データにおけるピクチャ構造について説明する。図４２は、時間スケーラビリティを実現する際の各ＴｅｍｐｏｒａｌＩｄにおけるピクチャの予測構造の例を示す図である。
ＭＰＥＧ－４ ＡＶＣやＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）などの符号化方式においては、他のピクチャから参照可能なＢピクチャ（双方向参照予測ピクチャ）を用いることにより時間方向のスケーラビリティ（時間スケーラビリティ）が実現できる。
図４２の（ａ）に示されるＴｅｍｐｏｒａｌＩｄとは、符号化構造の階層の識別子であり、ＴｅｍｐｏｒａｌＩｄは、値が大きくなるほど深い階層であることを示す。四角のブロックはピクチャを示し、ブロック内のＩｘは、Ｉピクチャ（画面内予測ピクチャ）、Ｐｘは、Ｐピクチャ（前方参照予測ピクチャ）、Ｂｘ及びｂｘは、Ｂピクチャ（双方向参照予測ピクチャ）を示す。Ｉｘ／Ｐｘ／Ｂｘのｘは表示オーダーを示し、ピクチャを表示する順番を表わす。ピクチャ間の矢印は参照関係を示し、例えば、Ｂ４のピクチャはＩ０、Ｂ８を参照画像として予測画像を生成することを示す。ここで、一のピクチャが、自らのＴｅｍｐｏｒａｌＩｄより大きいＴｅｍｐｏｒａｌＩｄを持つ他のピクチャを参照画像として使うことは禁止されている。階層が規定されているのは時間スケーラビリティを持たせるためであり、例えば、図４２において全てのピクチャを復号すると１２０ｆｐｓ（ｆｒａｍｅ ｐｅｒ ｓｅｃｏｎｄ）の映像が得られるが、ＴｅｍｐｏｒａｌＩｄが０から３までの階層のみを復号すると６０ｆｐｓの映像が得られる。
図４３は、図４２の各ピクチャにおける復号時刻（ＤＴＳ）と表示時刻（ＰＴＳ）との関係を示す図である。例えば、図４３に示されるピクチャＩ０は、復号及び表示においてギャップが発生しないように、Ｂ４の復号完了後に表示される。
図４３に示されるように、予測構造にＢピクチャが含まれる場合などには、復号順と表示順とが異なるため、受信装置２０においてピクチャを復号後にピクチャの遅延処理、及び、ピクチャの並び替え（リオーダ）処理が必要となる。
以上、時間方向のスケーラビリティにおけるピクチャの予測構造の例について説明したが、時間方向のスケーラビリティが用いられない場合においても、予測構造によっては、ピクチャの遅延処理、及び、リオーダ処理が必要となる場合がある。図４４は、ピクチャの遅延処理、及び、リオーダ処理が必要となるピクチャの予測構造の一例を示す図である。なお、図４４における数字は、復号順を示す。
図４４に示されるように、予測構造によっては、復号順において先頭となるサンプルと、提示順において先頭となるサンプルが異なる場合があり、図４４では、提示順で先頭となるサンプルは、復号順で４番目のサンプルとなる。なお、図４４は、予測構造の一例を示すものであり、予測構造はこのような構造に限定されるものではない。他の予測構造においても、復号順において先頭となるサンプルと、提示順において先頭となるサンプルとが異なる場合がある。
図４５は、図３３と同様に、ＭＰ４形式で構成されるＭＰＵが複数のムービーフラグメントに分割されて、ＭＭＴＰペイロード、ＭＭＴＰパケットに格納される例を示す図である。なお、ＭＰＵを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、ＭＰＵを構成するサンプル数をＧＯＰ単位のサンプル数とし、ＧＯＰ単位の２分の１のサンプル数をムービーフラグメントとして、２つのムービーフラグメントが構成されてもよい。１サンプルが１つのムービーフラグメントとされてもよいし、ＭＰＵを構成するサンプルが分割されなくてもよい。
図４５では、１つのＭＰＵに２つのムービーフラグメント（ｍｏｏｆボックス及びｍｄａｔボックス）が含まれる例が示されているが、１つのＭＰＵに含まれるムービーフラグメントは２つでなくてもよい。１つのＭＰＵに含まれるムービーフラグメントは、３つ以上であってもよいし、ＭＰＵに含まれるサンプル数であってもよい。また、ムービーフラグメントに格納されるサンプルは等分したサンプル数でなく、任意のサンプル数に分割されてもよい。
ムービーフラグメントメタデータ（ＭＦメタデータ）には、ムービーフラグメントに含まれるサンプルのＰＴＳ、ＤＴＳ、オフセット、及びサイズの情報が含まれており、受信装置２０は、サンプルを復号する際には、当該サンプルの情報を含むＭＦメタからＰＴＳ及びＤＴＳを抽出し、復号タイミングや提示タイミングを決定する。
ここからは、詳細説明のために、ｉサンプルの復号時刻の絶対値をＤＴＳ（ｉ）と記載し、提示時刻の絶対値をＰＴＳ（ｉ）と記載する。
ＭＦメタにおけるｍｏｏｆ内に格納されているタイムスタンプ情報のうちｉ番目のサンプルの情報は、具体的には、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値、及び、ｉ番目のサンプルの復号時刻と提示時刻の相対値であり、これらを以降ＤＴ（ｉ）及びＣＴ（ｉ）と記載する。
ムービーフラグメントメタデータ＃１には、サンプル＃１－＃３のＤＴ（ｉ）及びＣＴ（ｉ）が含まれており、ムービーフラグメントメタデータ＃２には、サンプル＃４－＃６のＤＴ（ｉ）及びＣＴ（ｉ）が含まれている。
また、ＭＰＵ先頭のアクセスユニットのＰＴＳ絶対値は、ＭＰＵタイムスタンプ記述子などに格納されており、受信装置２０は、ＭＰＵ先頭のアクセスユニットのＰＴＳ＿ＭＰＵと、ＣＴ及びＤＴとに基づいてＰＴＳ及びＤＴＳを算出する。
図４６は、＃１－＃１０のサンプルによりＭＰＵが構成される場合のＰＴＳ及びＤＴＳの算出方法と課題とを説明するための図である。
図４６の（ａ）は、ＭＰＵがムービーフラグメントに分割されない例を示し、図４６の（ｂ）は、ＭＰＵが５サンプル単位の２つのムービーフラグメントに分割される例を示し、図４６の（ｃ）は、ＭＰＵがサンプル単位に１０のムービーフラグメントに分割される例を示す。
図４５で説明したように、ＭＰＵタイムスタンプ記述子と、ＭＰ４内のタイムスタンプ情報（ＣＴ及びＤＴ）とを用いてＰＴＳ及びＤＴＳが算出される場合において、図４４における提示順で先頭となるサンプルは、復号順で４番目である。このため、ＭＰＵタイムスタンプ記述子に格納されているＰＴＳは、復号順で４番目のサンプルのＰＴＳ（絶対値）となる。なお、以降では、このサンプルをＡサンプルと呼ぶ。また、復号順で先頭のサンプルをＢサンプルと呼ぶ。
タイムスタンプに係る絶対時刻情報は、ＭＰＵタイムスタンプ記述子の情報のみであるため、受信装置２０は、Ａサンプルが到着するまで、その他のサンプルのＰＴＳ（絶対時刻）及びＤＴＳ（絶対時刻）を算出できない。受信装置２０は、ＢサンプルのＰＴＳ及びＤＴＳも算出できない。
図４６の（ａ）の例では、Ａサンプルは、Ｂサンプルと同じムービーフラグメントに含まれ、一つのＭＦメタに格納される。このため、受信装置２０は、当該ＭＦメタを受信後、すぐにＢサンプルのＤＴＳを決定できる。
図４６の（ｂ）の例では、Ａサンプルは、Ｂサンプルと同じムービーフラグメントに含まれ、一つのＭＦメタに格納される。このため、受信装置２０は、当該ＭＦメタを受信後、すぐにＢサンプルのＤＴＳを決定できる。
図４６の（ｃ）の例では、Ａサンプルは、Ｂサンプルと異なるムービーフラグメントに含まれる。このため、受信装置２０は、Ａサンプルを含むムービーフラグメントのＣＴ及びＤＴを含むＭＦメタを受信後でなければ、ＢサンプルのＤＴＳを決定できない。
したがって、図４６の（ｃ）の例の場合には、受信装置２０は、Ｂサンプルの到着後、すぐに復号を開始できない。
このように、Ｂサンプルを含むムービーフラグメントに、Ａサンプルが含まれない場合には、受信装置２０は、Ａサンプルを含むムービーフラグメントに係るＭＦメタを受信した後でなければ、Ｂサンプルの復号を開始できない。
提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、ＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されなくなるまでにムービーフラグメントが分割されることにより、この課題は発生する。また、ＭＦメタが後送りであるか先送りであるかにかかわらず、この課題は発生する。
このように、提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、Ａサンプルと、Ｂサンプルとが同一ムービーフラグメントに格納されない場合には、Ｂサンプルの受信後、すぐにＤＴＳを決定できない。そこで、送信装置１５は、別途、ＢサンプルのＤＴＳ（絶対値）、或いはＢサンプルのＤＴＳ（絶対値）を受信側において算出可能な情報を送信する。このような情報は、制御情報やパケットヘッダ等を用いて送信されてもよい。
受信装置２０は、このような情報を用いてＢサンプルのＤＴＳ（絶対値）を算出する。図４７は、このような情報を用いてＤＴＳが算出される場合の受信動作のフローチャートである。
受信装置２０は、ＭＰＵ先頭のムービーフラグメントを受信し（Ｓ９０１）、ＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されているかどうかを判定する（Ｓ９０２）。同一ムービーフラグメントに格納されている場合（Ｓ９０２でＹｅｓ）は、受信装置２０は、ＢサンプルのＤＴＳ（絶対時刻）を用いず、ＭＦメタの情報のみを用いてＤＴＳを算出し、復号を開始する（Ｓ９０４）。なお、ステップＳ９０４において、受信装置２０は、ＢサンプルのＤＴＳを用いてＤＴＳを決定してもよい。
一方、ステップＳ９０２においてＡサンプルとＢサンプルとが同一ムービーフラグメントに格納されていない場合（Ｓ９０２でＮｏ）、受信装置２０は、ＢサンプルのＤＴＳ（絶対時刻）を取得し、ＤＴＳを決定し、復号を開始する（Ｓ９０３）。
なお、以上の説明では、ＭＭＴ規格におけるＭＦメタ（ＭＰ４形式のｍｏｏｆ内に格納されているタイムスタンプ情報）を用いて、各サンプルの復号時刻の絶対値と、提示時刻の絶対値とを算出する例について説明したが、ＭＦメタを、各サンプルの復号時刻の絶対値と、提示時刻の絶対値を算出に用いることができる任意の制御情報に置き換えて実施しても良いことは言うまでもない。このような制御情報の例としては、上述したｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値ＣＴ（ｉ）を、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの提示時刻の相対値に置き換えた制御情報や、ｉ番目のサンプルと（ｉ＋１）番目のサンプルの復号時刻の相対値ＣＴ（ｉ）とｉ番目のサンプルと（ｉ＋１）番目のサンプルの提示時刻の相対値との両方を含む制御情報などがある。
（実施の形態３）
［概要］
実施の形態３では、映像、音声、字幕、及びデータ放送などのコンテンツを放送で伝送する場合のコンテンツの送信方法及びデータ構造について説明する。つまり、放送ストリームの再生に特化したコンテンツの送信方法及びデータ構造について説明する。
なお、実施の形態３では、多重化方式としてＭＭＴ方式（以下、単にＭＭＴとも記載する）が用いられる例について説明するが、ＭＰＥＧ－ＤＡＳＨまたはＲＴＰなど、その他の多重化方式が用いられてもよい。
まず、ＭＭＴにおけるデータユニット（ＤＵ：Ｄａｔａ Ｕｎｉｔ）のペイロードへの格納方法の詳細について説明する。図４８は、ＭＭＴにおけるデータユニットのペイロードへの格納方法を説明するための図である。
ＭＭＴでは、送信装置は、ＭＰＵを構成するデータの一部を、データユニットとしてＭＭＴＰペイロードに格納し、ヘッダをつけて伝送する。ヘッダにはＭＭＴＰペイロードヘッダ、及び、ＭＭＴＰパケットヘッダが含まれる。なお、データユニットの単位は、ＮＡＬユニット単位でもよいし、サンプル単位でもよい。
図４８の（ａ）は、送信装置が複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す。図４８の（ａ）の例では、複数のデータユニットそれぞれの先頭に、データユニットヘッダ（ＤＵＨ：Ｄａｔａ Ｕｎｉｔ Ｈｅａｄｅｒ）、及び、データユニット長（ＤＵＬ：Ｄａｔａ Ｕｎｉｔ Ｌｅｎｇｔｈ）が付与され、データユニットヘッダ及びデータユニット長が付与されたデータユニットが複数まとめてペイロードに格納される。
図４８の（ｂ）は、一つのデータユニットを一つのペイロードに格納する例を示す。図４８の（ｂ）の例では、データユニットの先頭に、データユニットヘッダが付与されてペイロードに格納される。図４８の（ｃ）は、一つのデータユニットを分割し、分割されたデータユニットに、データユニットヘッダが付与されてペイロードに格納される例を示す。
データユニットには、映像、音声、または字幕などの同期に関する情報を含むメディアであるｔｉｍｅｄ－ＭＦＵ、ファイルなど同期に関する情報を含まないメディアであるｎｏｎ－ｔｉｍｅｄ－ＭＦＵ、ＭＰＵメタデータ、ＭＦメタデータなどの種類があり、データユニットの種類に応じてデータユニットヘッダが定められる。なお、ＭＰＵメタデータ、及び、ＭＦメタデータにはデータユニットヘッダは存在しない。
また、送信装置は、異なる種類のデータユニットをアグリゲーションすることは原則としてできないが、異なる種類のデータユニットをアグリゲーションできるように規定されてもよい。例えば、サンプル毎にムービーフラグメントに分割されている場合などのＭＦメタデータのサイズが小さい場合、ＭＦメタデータとメディアデータとをアグリゲーションすることにより、パケット数を削減でき、さらに、伝送容量を削減することもできる。
データユニットがＭＦＵの場合は、ＭＰＵ（ＭＰ４）を構成するための情報など、ＭＰＵの一部の情報がヘッダとして格納される。
例えば、ｔｉｍｅｄ－ＭＦＵのヘッダには、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ｓａｍｐｌｅ＿ｎｕｍｂｅｒ、ｏｆｆｓｅｔ、ｐｒｉｏｒｉｔｙ、及び、ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒなどが含まれ、ｎｏｎ－ｔｉｍｅｄ－ＭＦＵのヘッダにはｉｔｅｍ＿ｉＤが含まれる。各フィールドの意味はＩＳＯ／ＩＥＣ２３００８－１あるいはＡＲＩＢ ＳＴＤ－Ｂ６０などの規格に示される。以下、このような規格において規定される各フィールドの意味について説明する。
ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、ＭＦＵが属するムービーフラグメントのシーケンス番号を示し、ＩＳＯ／ＩＥＣ１４４９６－１２にも示される。
ｓａｍｐｌｅ＿ｎｕｍｂｅｒは、当該ＭＦＵが属するサンプル番号を示し、ＩＳＯ／ＩＥＣ１４４９６－１２にも示される。
ｏｆｆｓｅｔは、当該ＭＦＵが属するサンプルにおける、ＭＦＵのオフセット量をバイト単位で示す。
ｐｒｉｏｒｉｔｙは、当該ＭＦＵが属するＭＰＵにおける、ＭＦＵの相対的な重要度を示し、ｐｒｉｏｒｉｔｙの数字が大きいＭＦＵは、ｐｒｉｏｒｉｔｙの数字が小さいＭＦＵよりも重要であることを示す。
ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒは、復号処理が当該ＭＦＵに依存しているＭＦＵ数（すなわち、このＭＦＵを復号処理しなければ、その復号処理を行うことができないＭＦＵの数）を示す。例えば、ＭＦＵがＨＥＶＣである場合においてＢピクチャまたはＰピクチャがＩピクチャを参照する場合、当該ＢピクチャまたはＰピクチャは、Ｉピクチャを復号処理しなければ復号処理を行うことができない。
したがって、ＭＦＵがサンプル単位である場合は、ＩピクチャのＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、当該Ｉピクチャを参照するピクチャ数が示される。ＭＦＵがＮＡＬユニット単位の場合は、Ｉピクチャに属するＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、当該Ｉピクチャを参照するピクチャに属するＮＡＬユニット数が示される。さらに、時間方向階層符号化された映像信号の場合、拡張レイヤのＭＦＵは、ベースレイヤのＭＦＵに依存するため、ベースレイヤのＭＦＵにおけるｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒには、拡張レイヤのＭＦＵの数が示される。本フィールドは、依存するＭＦＵ数が決定した後でなければ生成できない。
ｉｔｅｍ＿ｉＤは、アイテムを一意に特定する識別子を示す。
［ＭＰ４非サポートモード］
図１９、及び、図２１で説明したように、送信装置がＭＭＴにおけるＭＰＵを伝送する方法としては、ＭＰＵメタデータまたはＭＦメタデータをメディアデータの前または後に送信する方法、及び、メディアデータのみを送信する方法がある。また、受信装置では、ＭＰ４に準拠した受信装置や受信方法を用いて復号を行う方法や、ヘッダを用いずに復号する方法がある。
放送ストリーム再生に特化したデータの送信方法として、例えば、受信装置におけるＭＰ４再構成をサポートしない送信方法がある。
受信装置におけるＭＰ４再構成をサポートしない送信方法とは、例えば、図２１の（ｂ）に示されるようにメタデータ（ＭＰＵメタデータ及びＭＦメタデータ）を送信しない方法がある。この場合、ＭＭＴＰパケットに含まれるフラグメントタイプ（データユニットの種類を示す情報）のフィールド値は、２（＝ＭＦＵ）固定である。
メタデータが送信されない場合は、これまで説明したように、ＭＰ４準拠の受信装置などでは、受信したデータをＭＰ４として復号することはできないが、メタデータ（ヘッダ）を用いずに復号することが可能である。
そのため、メタデータは放送ストリーム復号及び再生に必ずしも必須の情報ではない。同様に、図４８で説明した、ｔｉｍｅｄ－ＭＦＵにおけるデータユニットヘッダの情報は、受信装置においてＭＰ４を再構成するための情報である。放送ストリーム再生においてＭＰ４を再構成する必要はないため、ｔｉｍｅｄ－ＭＦＵにおけるデータユニットヘッダ（以下、ｔｉｍｅｄ－ＭＦＵヘッダとも記載する）の情報は、放送ストリーム再生に必ずしも必要な情報ではない。
受信装置は、メタデータ、および、データユニットヘッダにおけるＭＰ４を再構成するための情報（以下、ＭＰ４構成情報とも記載する）を用いることにより、容易にＭＰ４を再構成することができる。しかし、受信装置は、メタデータ、および、データユニットヘッダにおけるＭＰ４構成情報のどちらか一方のみが伝送されていたとしても、ＭＰ４を再構成することはできない。メタデータ及びＭＰ４を再構成するための情報のどちらか一方のみが伝送されることによるメリットは少なく、必要でない情報を生成及び伝送することは、処理の増大や伝送効率の低下を招く。
そこで、送信装置は、下記の方法を用いてＭＰ４構成情報のデータ構造や伝送を制御する。送信装置は、メタデータが伝送されるかどうかに基づいて、データユニットヘッダにおいてＭＰ４構成情報を示すか否かを決定する。具体的には、送信装置は、メタデータが伝送される場合には、データユニットヘッダにおいてＭＰ４構成情報を示し、メタデータが伝送されない場合には、データユニットヘッダにおいてＭＰ４構成情報を示さない。
データユニットヘッダにおいてＭＰ４構成情報を示さない方法としては、例えば下記の方法を用いることができる。
１．送信装置は、ＭＰ４構成情報をｒｅｓｅｒｖｅｄとし、運用しない。これにより、ＭＰ４構成情報を生成する送出側の処理量（送信装置の処理量）を削減することができる。
２．送信装置は、ＭＰ４構成情報を削除し、ヘッダ圧縮する。これにより、ＭＰ４構成情報を生成する送出側の処理量を削減することができるとともに、伝送容量を削減することができる。
なお、送信装置は、ＭＰ４構成情報を削除し、ヘッダ圧縮する場合には、ＭＰ４構成情報を削除（圧縮）したことを示すフラグを示してもよい。フラグは、ヘッダ（ＭＭＴＰパケットヘッダ、ＭＭＴＰペイロードヘッダ、データユニットヘッダ）または制御情報などに示される。
また、メタデータが伝送されるかどうかの情報は、あらかじめ定めていてもよいし、別途ヘッダや制御情報にシグナリングし、受信装置に伝送されてもよい。
例えば、ＭＦＵヘッダに当該ＭＦＵに対応するメタデータが伝送されているかの情報が格納されてもよい。
一方、受信装置は、メタデータが伝送されているかどうかに基づいて、ＭＰ４構成情報が示されているかどうかを判定することができる。
ここで、データの送信順序（例えば、ＭＰＵメタデータ、ＭＦメタデータ、メディアデータのような順序）が決まっている場合は、受信装置は、メディアデータの前にメタデータが受信されたかどうかに基づいて判定してもよい。
ＭＰ４構成情報が示されている場合には、受信装置は、ＭＰ４構成情報をＭＰ４の再構成に用いることができる。或いは、受信装置は、その他のアクセスユニットやＮＡＬユニットの先頭の検出などにＭＰ４構成情報を用いることができる。
なお、ＭＰ４構成情報は、ｔｉｍｅｄ－ＭＦＵヘッダの全部であってもよいし一部であってもよい。
また、送信装置は、ｎｏｎ－ｔｉｍｅｄ－ＭＦＵヘッダにおいても同様に、メタデータが伝送されるかどうかに基づいて、ｎｏｎ－ｔｉｍｅｄ－ＭＦＵヘッダにおいてｉｔｅｍ
ｉｄを示すかどうかを決定してもよい。
送信装置は、ｔｉｍｅｄ－ＭＦＵと、ｎｏｎ－ｔｉｍｅｄ－ＭＦＵとのどちらか一方においてのみＭＰ４構成情報を示すとしてもよい。どちらか一方にのみＭＰ４構成情報を示す場合、送信装置は、メタデータが伝送されるかどうかに加え、ｔｉｍｅｄ－ＭＦＵかｎｏｎ－ｔｉｍｅｄ－ＭＦＵかどうかに基づいてＭＰ４構成情報を示すかどうかを決定する。受信装置では、メタデータが伝送されるかどうか、および、ｔｉｍｅｄ／ｎｏｎ－ｔｉｍｅｄフラグに基づいてＭＰ４構成情報が示されるかどうかを判定することができる。
なお、以上の説明においては、送信装置は、メタデータ（ＭＰＵメタデータ及びＭＦメタデータの両方）が伝送されるかどうかに基づいてＭＰ４構成情報を示すかどうかを決定した。しかしながら、送信装置は、メタデータの一部（ＭＰＵメタデータ、ＭＦメタデータのどちらか一方）が伝送されない場合に、ＭＰ４構成情報を示さないとしてもよい。
また、送信装置は、メタデータ以外の他の情報に基づいてＭＰ４構成情報を示すかどうかを決定してもよい。
例えば、ＭＰ４サポートモード／ＭＰ４非サポートモードのようなモードが定義され、送信装置は、ＭＰ４サポートモードの場合には、データユニットヘッダにおいてＭＰ４構成情報を示し、ＭＰ４非サポートモードの場合には、データユニットヘッダにおいてＭＰ４構成情報を示さないとしてもよい。また、送信装置は、ＭＰ４サポートモードの場合には、メタデータを伝送し、かつデータユニットヘッダにおいてＭＰ４構成情報を示し、ＭＰ４非サポートモードの場合には、メタデータを伝送せずにデータユニットヘッダにおいてもＭＰ４構成情報を示さないとしてもよい。
［送信装置の動作フロー］
次に、送信装置の動作フローについて説明する。図４９は、送信装置の動作フローである。
送信装置は、まず、メタデータを伝送するかどうかを判定する（Ｓ１００１）。送信装置は、メタデータを伝送すると判定した場合（Ｓ１００２でＹｅｓ）、ステップＳ１００３へ移行し、ＭＰ４構成情報を生成し、かつ、ヘッダに格納して伝送する（Ｓ１００３）。この場合、送信装置は、メタデータも生成し、かつ、伝送する。
一方、送信装置は、メタデータを伝送しないと判定した場合（Ｓ１００２でＮｏ）、ＭＰ４構成情報を生成せず、かつ、ヘッダにも格納せずに伝送する（Ｓ１００４）。この場合、送信装置は、メタデータを生成せず、伝送しない。
なお、ステップＳ１００１においてメタデータを伝送するかどうかは、あらかじめ定められていてもよいし、送信装置の内部でメタデータが生成されたかどうか、送信装置の内部でメタデータが伝送されているかどうかに基づいて判定されてもよい。
［受信装置の動作フロー］
次に、受信装置の動作フローについて説明する。図５０は、受信装置の動作フローである。
受信装置は、まず、メタデータが伝送されているかどうかを判定する（Ｓ１１０１）。メタデータが伝送されているかどうかは、ＭＭＴＰパケットペイロードにおけるフラグメントタイプを監視することにより判定できる。また、伝送されているかどうかがあらかじめ定められていてもよい。
受信装置は、メタデータが伝送されていると判定した場合（Ｓ１１０２でＹｅｓ）、ＭＰ４を再構成し、かつ、ＭＰ４構成情報を用いた復号処理を実行する（Ｓ１１０３）。一方、メタデータが伝送されていないと判定した場合（Ｓ１１０２でＮｏ）、ＭＰ４の再構成処理をせず、かつ、ＭＰ４構成情報を用いずに復号処理を実行する（Ｓ１１０４）。
なお、受信装置は、これまで説明した方法を用いて、ＭＰ４構成情報を用いずにランダムアクセスポイントの検出、アクセスユニット先頭の検出、ＮＡＬユニット先頭の検出などをすることが可能であり、復号処理、パケットロスの検出、及びパケットロスからの復帰の処理をすることができる。
例えば、アクセスユニット先頭は、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が１であるＭＭＴペイロードの先頭データである。このとき、Ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値は０である。
また、スライスセグメントの先頭は、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ値が０、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるＭＭＴペイロードの先頭データである。
受信装置は、以上のような情報に基づき、アクセスユニット先頭の検出、及び、スライスセグメントの検出を行うことができる。
なお、受信装置は、ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ値が００或いは０１であるデータユニットの先頭を含むパケットにおいて、ＮＡＬユニットヘッダを解析し、ＮＡＬユニットの種類がＡＵデリミタであること、及び、ＮＡＬユニットの種類がスライスセグメントであることを検出してもよい。
［放送シンプルモード］
これまでは、放送ストリーム再生に特化したデータの送信方法として、受信装置におけるＭＰ４構成情報をサポートしない方法を説明したが、放送ストリーム再生に特化したデータの送信方法は、これに限るものではない。
放送ストリーム再生に特化したデータの送信方法として、例えば下記の方法が用いられてもよい。
・送信装置は、放送の固定受信環境では、ＡＬ－ＦＥＣを用いなくてもよい。ＡＬ－ＦＥＣが用いられない場合は、ＭＭＴＰパケットヘッダにおけるＦＥＣ＿ｔｙｐｅは常に０固定とされる。
・送信装置は、放送の移動受信環境、及び、通信ＵＤＰ伝送モードにおいては、常にＡＬ－ＦＥＣを用いてもよい。ＡＬ－ＦＥＣが用いられる場合は、ＭＭＴＰパケットヘッダにおけるＦＥＣ＿ｔｙｐｅは、常に０或いは１である。
・送信装置は、アセットのバルク伝送をしなくてもよい。アセットのバルク伝送がされない場合には、ＭＰＴ内部のアセットの伝送ローケーション数を示すｌｏｃａｔｉｏｎ＿ｉｎｆｏｌｏｃａｔｉｏｎは、１に固定されてよい。
・送信装置は、アセット、プログラム、及びメッセージのハイブリッド伝送をしなくてもよい。
また、例えば、放送シンプルモードが規定され、送信装置は、放送シンプルモードである場合には、ＭＰ４非サポートモードとする、或いは、上記に示した放送ストリーム再生に特化したデータの送信方法を用いるとしてもよい。放送シンプルモードかどうかはあらかじめ定められていてもよいし、送信装置は、放送シンプルモードであることを示すフラグを制御情報として格納し、受信装置に伝送してもよい。
また、送信装置は、図４９で説明した、ＭＰ４非サポートモードであるかどうか（メタデータが伝送されているかどうか）に基づいて、ＭＰ４非サポートモードである場合には、放送シンプルモードとして、上記に示した放送ストリーム再生に特化したデータの送信方法を用いてもよい。
受信装置は、放送シンプルモードである場合には、ＭＰ４非サポートモードであるとして、ＭＰ４を再構成せず復号処理をすることができる。
また、受信装置は、放送シンプルモードである場合には、放送に特化した機能であることを判定し、放送に特化して受信処理をすることができる。
これにより、放送シンプルモードである場合には、放送に特化した機能のみを用いることにより、送信装置及び受信装置にとって不要な処理を削減できるばかりでなく、不要な情報を圧縮して伝送しないことにより、伝送オーバーヘッドを削減することができる。
なお、ＭＰ４非サポートモードが用いられる場合には、ＭＰ４構成以外の蓄積方法をサポートするヒント情報が示されてもよい。
ＭＰ４構成以外の蓄積方法としては、例えば、ＭＭＴパケットやＩＰパケットをダイレクトに蓄積する方法や、ＭＭＴパケットをＭＰＥＧ－２ ＴＳパケットに変換する方法などがある。
なお、ＭＰ４非サポートモードの場合には、ＭＰ４構成にしたがわないフォーマットが用いられてもよい。
例えば、ＭＦＵに格納されるデータは、ＭＰ４非サポートモードの場合には、ＭＰ４形式であるＮＡＬユニットの先頭にＮＡＬユニットのサイズがついた形式でなく、バイトスタートコードがついた形式にされてもよい。
ＭＭＴでは、アセットのタイプを示すアセットタイプは、ＭＰ４ＲＥＧ（ｈｔｔｐ：／／ｗｗｗ．ｍｐ４ｒａ．ｏｒｇ）に登録される４ＣＣで記載され、映像信号としてＨＥＶＣを用いる場合、‘ＨＥＶ１’または‘ＨＶＣ１’が用いられる。‘ＨＶＣ１’は、サンプルの中にパラメータセットを含んでもよい形式であり、‘ＨＥＶ１’はサンプルの中にパラメータセットを含まず、ＭＰＵメタデータにおけるサンプルエントリにパラメータセットを含む形式である。
放送シンプルモードまたはＭＰ４非サポートモードの場合において、ＭＰＵメタデータ及びＭＦメタデータが伝送されない場合には、必ずサンプルの中にパラメータセットを含めると規定されてもよい。また、アセットタイプに‘ＨＥＶ１’と‘ＨＶＣ１’のどちらが示されている場合にも、必ず‘ＨＶＣ１’の形式をとると規定されてもよい。
［補足１：送信装置］
以上のように、メタデータが送信されていない場合に、ＭＰ４構成情報をｒｅｓｅｒｖｅｄとし、運用しない送信装置は、図５１のように構成することも可能である。図５１は、送信装置の具体的構成の例を示す図である。
送信装置３００は、符号化部３０１と、付与部３０２と、送信部３０３とを備える。符号化部３０１、付与部３０２、及び送信部３０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
符号化部３０１は、映像信号または音声信号を符号化してサンプルデータを生成する。サンプルデータは、具体的には、データユニットである。
付与部３０２は、映像信号または音声信号が符号化されたデータであるサンプルデータに、ＭＰ４構成情報を含むヘッダ情報を付与する。ＭＰ４構成情報は、受信側において当該サンプルデータをＭＰ４フォーマットのファイルとして再構成するための情報であって、サンプルデータの提示時刻が定められているか否かに応じて内容が異なる情報である。
上述のように、付与部３０２は、提示時刻が定められているサンプルデータ（同期に関する情報を含むサンプルデータ）の一例であるｔｉｍｅｄ－ＭＦＵのヘッダ（ヘッダ情報）に、ｍｏｖｉｅ＿ｆｒａｇｍｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ、ｓａｍｐｌｅ＿ｎｕｍｂｅｒ、ｏｆｆｓｅｔ、ｐｒｉｏｒｉｔｙ、及び、ｄｅｐｅｎｄｅｎｃｙ＿ｃｏｕｎｔｅｒなどのＭＰ４構成情報を含める。
一方で、付与部３０２は、提示時刻が定められていないサンプルデータ（同期に関する情報を含まないサンプルデータ）の一例である、ｔｉｍｅｄ－ＭＦＵのヘッダ（ヘッダ情報）には、ｉｔｅｍ＿ｉｄなどのＭＰ４構成情報を含める。
そして、付与部３０２は、送信部３０３によってサンプルデータに対応するメタデータが送信されない場合（例えば、図２１の（ｂ）のような場合）には、サンプルデータの提示時刻が定められているか否かに応じて、ＭＰ４構成情報を含まないヘッダ情報をサンプルデータに付与する。
付与部３０２は、具体的には、サンプルデータの提示時刻が定められている場合には、第一のＭＰ４構成情報を含まないヘッダ情報をサンプルデータに付与し、サンプルデータの提示時刻が定められていない場合には、第二のＭＰ４構成情報を含むヘッダ情報を前記サンプルデータに付与する。
例えば、付与部３０２は、図４９のステップＳ１００４に示されるように、送信部３０３によってサンプルデータに対応するメタデータが送信されない場合には、ＭＰ４構成情報をｒｅｓｅｒｖｅｄ（固定値）とすることにより、ＭＰ４構成情報を実質的に生成せず、かつ、実質的にヘッダ（ヘッダ情報）に格納しない。なお、メタデータには、ＭＰＵメタデータ、及び、ムービーフラグメントメタデータが含まれる。
送信部３０３は、ヘッダ情報が付与されたサンプルデータを送信する。送信部３０３は、より具体的には、ヘッダ情報が付与されたサンプルデータをＭＭＴ方式でパケット化して送信する。
上述のように、放送ストリームの再生に特化した送信方法及び受信方法では、受信装置でデータユニットをＭＰ４に再構成する必要はない。受信装置がＭＰ４に再構成する必要がない場合、ＭＰ４構成情報などの不要な情報を生成しないことで送信装置の処理は軽減される。
一方で、送信装置は、必要な情報は送らなくてはならないが、余計な追加情報などを別途送信しなくて済むように、規格との整合性は保つ必要がある。
送信装置３００のような構成によれば、ＭＰ４構成情報が格納される領域を固定値にすることなどにより、ＭＰ４構成情報を送信せず、必要な情報のみを規格に基づいて送信し、余計な追加情報を送信しなくて済む効果が得られる。つまり、送信装置の構成及び送信装置の処理量を削減することができる。また、不要なデータが送信されないことにより、伝送効率を向上させることができる。
［補足２：受信装置］
また、送信装置３００に対応する受信装置は、例えば、図５２のように構成されてもよい。図５２は、受信装置の構成の別の例を示す図である。
受信装置４００は、受信部４０１と、復号部４０２とを備える。受信部４０１、及び、復号部４０２は、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信部４０１は、映像信号または音声信号が符号化されたデータであるサンプルデータであって、当該サンプルデータをＭＰ４フォーマットのファイルとして再構成するためのＭＰ４構成情報を含むヘッダ情報が付与されたサンプルデータを受信する。
復号部４０２は、受信部によってサンプルデータに対応するメタデータが受信されなかった場合であって、サンプルデータの提示時刻が定められている場合に、ＭＰ４構成情報を使用せずにサンプルデータを復号する。
例えば、復号部４０２は、図５０のステップＳ１１０４に示されるように、受信部４０１によってサンプルデータに対応するメタデータが受信されない場合には、ＭＰ４構成情報を用いずに復号処理を実行する。
これにより、受信装置４００の構成及び受信装置４００における処理量を削減することができる。
（実施の形態４）
［概要］
実施の形態４では、ファイルなど同期に関する情報を含まない非同期（ｎｏｎ－ｔｉｍｅｄ）メディアのＭＰＵへの格納方法と、ＭＭＴＰパケットでの伝送方法について説明する。なお、実施の形態４では、ＭＭＴにおけるＭＰＵを例に説明するが、同じＭＰ４ベースであるＤＡＳＨでも適用可能である。
まず、ｎｏｎ－ｔｉｍｅｄメディア（以下、「非同期メディアデータ」とも言う）のＭＰＵへの格納方法の詳細について図５３を用いて説明する。図５３は、ｎｏｎ－ｔｉｍｅｄメディアのＭＰＵへの格納方法、及び、ＭＭＴＰパケットでの伝送方法を示す図である。
ｎｏｎ－ｔｉｍｅｄメディアを格納するＭＰＵは、ｆｔｙｐ、ｍｍｐｕ、ｍｏｏｖ、ｍｅｔａなどのボックスで構成され、ＭＰＵに格納するファイルに関する情報が格納される。ｍｅｔａボックス内には複数のｉｄａｔボックスを格納することができ、ｉｄａｔボックスには１つのファイルがｉｔｅｍとして格納される。
ｆｔｙｐ，ｍｍｐｕ，ｍｏｏｖ，ｍｅｔａボックスの一部はＭＰＵメタデータとして一つのデータユニットを構成し、ｉｔｅｍ或いはｉｄａｔボックスはＭＦＵとしてデータユニットを構成する。
データユニットはアグリゲーションやフラグメントされた後、データユニットヘッダ、ＭＭＴＰペイロードヘッダ、及びＭＭＴＰパケットヘッダが付与されてＭＭＴＰパケットとして伝送される。
なお、図５３では、Ｆｉｌｅ＃１とＦｉｌｅ＃２とが１つのＭＰＵに格納される例を示している。ＭＰＵメタデータは分割されておらず、また、ＭＦＵは分割されてＭＭＴＰパケットに格納されているが、これに限るものではなく、データユニットのサイズに応じてアグリゲーションやフラグメントされてもよい。また、ＭＰＵメタデータは伝送されなくてもよく、その場合は、ＭＦＵのみが伝送される。
データユニットヘッダなどのヘッダ情報には、ｉｔｅｍＩＤ（アイテムを一意に特定する識別子）が示され、ＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダには、パケットシーケンス番号（パケット毎のシーケンス番号）、及び、ＭＰＵシーケンス番号（ＭＰＵのシーケンス番号、アセット内で一意の番号。）が含まれる。
なお、データユニットヘッダ以外のＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダのデータ構造はこれまで説明したｔｉｍｅｄメディア（以下、「同期メディアデータ」とも言う。）と同様であり、ａｇｇｒｅｇａｔｉｏｎ＿ｆｌａｇ，ｆｒａｇｍｅｎｔａｔｉｏｎ＿ｉｎｄｉｃａｔｏｒ，ｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒなどが含まれる。
次に、ファイル（＝Ｉｔｅｍ＝ＭＦＵ）を分割してパケット化する場合のヘッダ情報の具体例をについて、図５４及び図５５を用いて説明する。
図５４及び図５５は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する例を示す図である。図５４及び図５５は、具体的には、分割されたＭＭＴＰパケット毎のヘッダ情報であるデータユニットヘッダ、ＭＭＴＰペイロードヘッダ、ＭＭＴＰパケットヘッダのいずれかに含まれる情報（パケットシーケンス番号、フラグメントカウンタ、フラグメンテーションインジケータ、ＭＰＵシーケンス番号、アイテムＩＤ）を示す。なお、図５４は、Ｆｉｌｅ＃１がＭ個（Ｍ＜＝２５６）に分割される例を示す図であり、図５５は、Ｆｉｌｅ＃２がＮ個（２５６＜Ｎ）に分割される例を示す図である。
分割データ番号は、ファイル先頭からの分割データのインデックスを示しており、この情報は伝送されない。つまり、分割データ番号は、ヘッダ情報には含まれない。また、分割データ番号は、ファイルを分割することにより得られた複数の分割データのそれぞれに対応するパケットに付与される番号であり、先頭のパケットから昇順に１ずつ加算されて付与される番号である。
パケットシーケンス番号は、同じパケットＩＤを持つパケットのシーケンス番号であり、図５４及び図５５では、ファイル先頭の分割データをＡとして、ファイル最後の分割データまで連続した番号が付与される。パケットシーケンス番号は、ファイル先頭の分割データから昇順に１ずつ加算されて付与される番号であり、分割データ番号に対応する番号である。
フラグメントカウンタは、１つのファイルが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある複数の分割データの数を示す。また、フラグメントカウンタは、１つのファイルを分割することにより得られた複数の分割データの数である分割データ数が２５６を超える場合、分割データ数を２５６で除した余りを示す。図５４の例では、分割データ数が２５６以下であるため、フラグメントカウンタのフィールド値は（Ｍ－分割データ番号）となる。一方、図５５の例では、分割データ数が２５６を超えるため、（Ｎ－分割データ番号）を２５６で除した値（（Ｎ－分割データ番号）％２５６）となる。
なお、フラグメンテーションインジケータは、ＭＭＴＰパケットに格納するデータの分割の状態を示し、分割されたデータユニットにおける先頭の分割データであるか、最後の分割データであるか、それ以外の分割データであるか、或いは、分割されていない１つ以上のデータユニットであるかを示す値である。具体的には、フラグメンテーションインジケータは、先頭の分割データでは「０１」であり、最後の分割データでは「１１」であり、残りの分割データでは「１０」であり、分割されていないデータユニットでは「００」である。
本実施の形態では、分割データ数が２５６を超える場合、分割データ数を２５６で除した余りを示すとして説明するが、分割データ数は２５６に限らず、他の数（所定の数）であってもよい。
図５４及び図５５に示すようにファイルを分割し、ファイルを分割することにより得られた複数の分割データのそれぞれに従来のヘッダ情報を付与して伝送する場合、受信装置において、受信したＭＭＴＰパケットに格納されるデータが、元のファイルにおいて何番目の分割データであるか（分割データ番号）、及び、ファイルの分割データ数、または、分割データ番号及び分割データ数を導出できる情報がない。このため、従来の伝送方法では、ＭＭＴＰパケットを受信しても、受信したＭＭＴＰパケットに格納されるデータの分割データ番号や分割データ数を一意に検出することができない。
例えば、図５４のように分割データ数が２５６以下であり、分割データ数があらかじめ２５６以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。しかし、分割データ数が２５６以上である場合には、分割データ番号や分割データ数を特定できない。
なお、ファイルの分割データ数を２５６以下に制限する場合、１つのパケットで伝送可能なデータサイズをｘ［ｂｙｔｅｓ］とした場合、伝送可能なファイルの最大サイズは ｘ ＊ ２５６［ｂｙｔｅｓ］に制限される。例えば、放送ではｘ＝４ｋ［ｂｙｔｅｓ］が想定されており、この場合、伝送可能なファイルの最大サイズは４ｋ＊２５６＝１Ｍ［ｂｙｔｅｓ］に制限される。従って、１［Ｍｂｙｔｅｓ］を越えるファイルを伝送したい場合にはファイルの分割データ数を２５６以下に制限することはできない。
また、例えば、フラグメンテーションインジケータを参照することでファイルの先頭の分割データや最後の分割データを検出することができるため、ファイルの最後の分割データを含むＭＭＴＰパケットが受信されるまでＭＭＴＰパケット数をカウントしたり、ファイルの最後の分割データを含むＭＭＴＰパケットを受信したりした後に、パケットシーケンス番号と組み合わせることにより、分割データ番号や分割データ数を算出することは可能であるため、フラグメンテーションインジケータとパケットシーケンス番号とを組み合わせることにより分割データ番号及び分割データ数をシグナリングするとしてもよい。しかし、ファイルの途中の分割データ（つまり、ファイルの先頭の分割データでもファイルの最後の分割データでもない分割データ）を含むＭＭＴＰパケットから受信を開始した場合、当該分割データの分割データ番号や分割データ数を特定できない。当該分割データの分割データ番号や分割データ数は、ファイル最後の分割データを含むＭＭＴＰパケットを受信後に初めて特定できる。
図５４及び図５５で説明した課題、つまり、ファイルの分割データを含むパケットを途中から受信した時点で、ファイルの分割データの分割データ番号および分割データ数を一意に決定するために、次の方法を用いる。
まず、分割データ番号について説明する。
分割データ番号については、ファイル（ｉｔｅｍ）の先頭の分割データにおけるパケットシーケンス番号をシグナリングする。
シグナリングする方法として、ファイルを管理する制御情報に格納する。具体的には、図５４及び図５５においてファイルの先頭の分割データのパケットシーケンス番号Ａを、制御情報に格納する。受信装置では、制御情報よりＡの値を取得し、パケットヘッダに示されるパケットシーケンス番号より分割データ番号を算出する。
分割データの分割データ番号は、当該分割データのパケットシーケンス番号から先頭の分割データのパケットシーケンス番号Ａを減ずることにより求められる。
ファイルを管理する制御情報としては、例えば、ＡＲＩＢ ＳＴＤ－Ｂ６０に規定されるアセット管理テーブルがある。アセット管理テーブルには、ファイル毎に、ファイルサイズやバージョン情報などが示され、データ伝送メッセージに格納されて伝送される。図５６は、アセット管理テーブルにおけるファイル毎のループのシンタックスを示す図である。
既存のアセット管理テーブルの領域が拡張できない場合には、アイテムの情報を示すｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅフィールドの一部の３２ｂｉｔの領域を用いてシグナリングしてもよい。ｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅの一部領域に、ファイル（ｉｔｅｍ）の先頭の分割データにおけるパケットシーケンス番号が示されているかどうかを示すフラグを制御情報の例えばｒｅｓｅｒｖｅｄ＿ｆｕｔｕｒｅ＿ｕｓｅフィールドに示してもよい。
データカルーセルなどファイルを繰り返し伝送する場合には、複数のパケットシーケンス番号を示してもよいし、直後に伝送するファイルの先頭のパケットシーケンス番号を示してもよい。
ファイル先頭の分割データのパケットシーケンス番号に限らず、ファイルの分割データ番号とパケットシーケンス番号を紐づける情報であればよい。
次に、分割データ数について説明する。
アセット管理テーブルに含まれるファイル毎のループの順番を、ファイルの伝送順と規定してもよい。これにより、伝送順で連続する２つのファイルの先頭のパケットシーケンス番号がわかるため、後に伝送されるファイルの先頭パケットシーケンス番号から前に伝送されるファイルの先頭パケットシーケンス番号を減ずることにより、前に伝送されるファイルの分割データ数を特定することができる。つまり、例えば、図５４に示すＦｉｌｅ＃１と図５５に示すＦｉｌｅ＃２とがこの順に連続したファイルである場合には、Ｆｉｌｅ＃１の最後のパケットシーケンス番号とＦｉｌｅ＃２の先頭のパケットシーケンス番号とは連続した番号が付与されている。
また、ファイルの分割方法を規定することにより、ファイルの分割データ数を特定できるように規定してもよい。例えば、分割データ数がＮの場合、１～（Ｎ－１）番目の分割データのそれぞれのサイズはＬとし、Ｎ番目の分割データのサイズは端数（ｉｔｅｍ＿ｓｉｚｅ－Ｌ＊（Ｎ－１））と規定することにより、アセット管理テーブルに示されるｉｔｅｍ＿ｓｉｚｅから分割データ数を逆算できる。この場合、（ｉｔｅｍ＿ｓｉｚｅ ／ Ｌ）を切り上げた整数値が分割データ数となる。なお、ファイルの分割方法は、これに限るものではない。
また、分割データ数を直接アセット管理テーブルに格納してもよい。
受信装置では、上記の方法を用いることにより、制御情報を受信し、制御情報に基づいて分割データ数を算出する。また、制御情報に基づいてファイルの分割データ番号に対応するパケットシーケンス番号を算出できる。なお、制御情報の受信のタイミングより、分割データのパケットの受信のタイミングが早い場合は、制御情報を受信したタイミングで分割データ番号や分割データ数を算出してもよい。
なお、上記方法を用いて分割データ番号、或いは分割データ数をシグナリングする場合、フラグメントカウンタに基づいて分割データ番号や分割データ数を特定することはなく、フラグメントカウンタは不要なデータとなる。そこで、非同期メディアの伝送において、上記方法等を用いて分割データ番号、および、分割データ数を特定できる情報がシグナリングされている場合には、フラグメントカウンタは運用しない、或いは、ヘッダ圧縮してもよい。これにより、送信装置や受信装置の処理量を削減することができ、伝送効率を向上させることもできる。つまり、非同期メディアを送信する場合には、フラグメントカウンタをｒｅｓｅｒｖｅｄ（無効化）としてもよい。具体的には、フラグメントカウンタの値を例えば「０」の固定値としてもよい。また、非同期メディアを受信する場合には、フラグメントカウンタを無視してもよい。
映像や音声などの同期メディアを格納する場合においては、送出装置におけるＭＭＴＰパケットの送信順と受信装置におけるＭＭＴＰパケットの到着順が一致しており、かつ、パケットが再送されない。このような場合において、パケットロスを検出して再構成する必要がない場合には、フラグメントカウンタを運用しないとしてもよい。言い換えると、この場合では、フラグメントカウンタをｒｅｓｅｒｖｅｄ（無効化）としてもよい。
また、フラグメントカウンタを用いなくても、ランダムアクセスポイントの検出、アクセスユニット先頭の検出、ＮＡＬユニット先頭の検出などをすることが可能であり、復号処理や、パケットロスの検出、パケットロスからの復帰の処理をすることができる。
また、ライブ放送などのリアルタイムなコンテンツの伝送では、より低遅延な伝送が求められ、符号化が完了したデータから順次パケット化して送出することが求められる。しかし、リアルタイムなコンテンツの伝送において、従来のフラグメントカウンタでは、先頭の分割データの送出時に分割データ数は決定できないため、先頭の分割データの送出は、データユニットの符号化がすべて完了し、分割データ数が決定した後となり、遅延が発生する。このような場合であっても、上記の方法を用いて、フラグメントカウンタを運用しないことにより、この遅延を削減できる。
図５７は、受信装置における分割データ番号を特定する動作フローである。
受信装置は、ファイルの情報が記載された制御情報を取得する（Ｓ１２０１）。受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されているかどうかを判定し（Ｓ１２０２）、制御情報にファイル先頭のパケットシーケンス番号が示されている場合には（Ｓ１２０２でＹｅｓ）、ファイルの分割データの分割データ番号に対応するパケットシーケンス番号を算出する（Ｓ１２０３）。そして、受信装置は、分割データが格納されたＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるパケットシーケンス番号からファイルの分割データ番号を特定する（Ｓ１２０４）。一方、受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されていない場合には（Ｓ１２０２でＮｏ）、ファイル最後の分割データが含まれるＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ番号を特定する（Ｓ１２０５）。
図５８は、受信装置における分割データ数を特定する動作フローである。
受信装置は、ファイルの情報が記載された制御情報を取得する（Ｓ１３０１）。受信装置は、制御情報にファイルの分割データ数を算出可能な情報が含まれているかどうかを判定し（Ｓ１３０２）、分割データ数を算出可能な情報が含まれていると判定した場合には、（Ｓ１３０２でＹｅｓ）、制御情報に含まれる情報に基づいて分割データ数を算出する（Ｓ１３０３）。一方、受信装置は、分割データ数を算出不可能であると判定した場合には（Ｓ１３０２でＮｏ）、ファイル最後の分割データが含まれるＭＭＴＰパケットを取得後、取得したＭＭＴＰパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ数を特定する（Ｓ１３０４）。
図５９は、送信装置においてフラグメントカウンタを運用するかどうかを決定するための動作フローである。
まず、送信装置は、伝送するメディア（以下、「メディアデータ」とも言う。）が同期メディアか、非同期メディアかを判定する（Ｓ１４０１）。
ステップＳ１４０１での判定の結果が同期メディアである場合（Ｓ１４０２で同期メディア）、送信装置は、同期メディアを伝送する環境において送受信のＭＭＴＰパケット順が一致し、かつパケットロス時にパケット再構成が不要かどうかを判定する（Ｓ１４０３）。送信装置は、不要であると判定した場合（Ｓ１４０３でＹｅｓ）、フラグメントカウンタを運用しない（Ｓ１４０４）。一方、送信装置は、不要でないと判定した場合（Ｓ１４０３でＮｏ）、フラグメントカウンタを運用する（Ｓ１４０５）。
ステップＳ１４０１での判定の結果が非同期メディアである場合（Ｓ１４０２で非同期メディア）、送信装置は、上述で説明した方法を用いて分割データ番号や分割データ数がシグナリングされるかどうかに基づいて、フラグメントカウンタを運用するか否かを決定する。具体的には、送信装置は、分割データ番号や分割データ数がシグナリングされる場合（Ｓ１４０６でＹｅｓ）、フラグメントカウンタを運用しない（Ｓ１４０４）。一方、送信装置は、分割データ番号や分割データ数がシグナリングされない場合（Ｓ１４０６でＮｏ）、フラグメントカウンタを運用する（Ｓ１４０５）。
なお、送信装置は、フラグメントカウンタを運用しない場合、フラグメントカウンタの値をｒｅｓｅｒｖｅｄとしてもよいし、ヘッダ圧縮をしてもよい。
なお、送信装置は、フラグメントカウンタを運用するかどうかに基づいて、上述した分割データ番号や分割データ数をシグナリングするかどうかを決定してもよい。
なお、送信装置は、同期メディアがフラグメントカウンタを運用しない場合には、非同期メディアにおいて上述した方法を用いて分割データ番号や分割データ数をシグナリングしてもよい。逆に、非同期メディアがフラグメントカウンタを運用するかどうかに基づいて、同期メディアの運用を決定してもよい。この場合、同期メディアと非同期メディアとにおいて、フラグメントを運用するかどうかを同じ運用とすることができる。
次に、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明する。図６０は、分割データ数、分割データ番号を特定する方法（フラグメントカウンタを活用する場合）について説明するための図である。
図５４を用いて説明したように、分割データ数が２５６以下であり、分割データ数があらかじめ２５６以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。
ファイルの分割データ数を２５６以下に制限する場合、１つのパケットで伝送可能なデータサイズをｘ［ｂｙｔｅｓ］とした場合、伝送可能なファイルの最大サイズはｘ＊２５６［ｂｙｔｅｓ］に制限される。例えば、放送ではｘ＝４ｋ［ｂｙｔｅｓ］が想定されており、この場合、伝送可能なファイルの最大サイズは４ｋ＊２５６＝１Ｍ［ｂｙｔｅｓ］に制限される。
ファイルサイズが、伝送可能なファイルの最大サイズを超える場合、分割ファイルのサイズがｘ＊２５６［ｂｙｔｅｓ］以下となるように予めファイルを分割する。ファイルが分割することにより得られた複数の分割ファイルのそれぞれは、一つのファイル（ｉｔｅｍ）として扱われ、さらに２５６以内に分割され、さらに分割されることにより得られた分割データがそれぞれＭＭＴＰパケットに格納されて伝送される。
なお、アイテムが分割ファイルであることを示す情報や、分割ファイル数、分割ファイルのシーケンス番号を制御情報に格納し、受信装置に送信してもよい。また、これらの情報をアセット管理テーブルに格納してもよいし、既存のフィールドｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅの一部を用いて示してもよい。
受信装置は、アイテムが１つのファイルを分割することにより得られた複数の分割ファイルのうちの１つの分割ファイルである場合には、他の分割ファイルを特定し、元のファイルを再構成することができる。また、受信装置では、制御情報における分割ファイルの分割ファイル数、分割ファイルのインデックス、および、フラグメントカウンタを用いることにより、分割データ数や、分割データ番号を一意に特定することができる。また、パケットシーケンス番号などを用いることなく分割データ数や分割データ番号を一意に特定できる。
ここで、１つのファイルを分割することにより得られた複数の分割ファイルそれぞれのｉｔｅｍ＿ｉｄは、互いに同じであることが望ましい。なお、別のｉｔｅｍ＿ｉｄを付与する場合は、他の制御情報などからファイルを一意に参照するために、先頭の分割ファイルのｉｔｅｍ＿ｉｄを示すとしてもよい。
また、複数の分割ファイルは、必ず同じＭＰＵに属するとしてもよい。ＭＰＵに複数のファイルを格納する場合には、異なる種類のファイルは格納せず、必ず１つのファイルを分割したファイルが格納されているとしてもよい。受信装置はｉｔｅｍ毎のバージョン情報を確認せずとも、ＭＰＵ毎のバージョン情報を確認することで、ファイルの更新を検知できる。
図６１は、フラグメントカウンタを活用する場合の送信装置の動作フローである。
まず、送信装置は、伝送するファイルのサイズを確認する（Ｓ１５０１）。次に送信装置は、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］（ｘは、１つのパケットで伝送できるデータサイズ。例えば、ＭＴＵサイズ。）を超えるか否かを判定し（Ｓ１５０２）、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］を超える場合には（Ｓ１５０２でＹｅｓ）、分割ファイルのサイズがｘ＊２５６［ｂｙｔｅｓ］未満となるようにファイルを分割する（Ｓ１５０３）。そして、分割ファイルをアイテムとして伝送し、分割ファイルに関する情報（例えば、分割ファイルであること、分割ファイルにおけるシーケンス番号など）を制御情報に格納して伝送する（Ｓ１５０４）。一方、ファイルサイズがｘ＊２５６［ｂｙｔｅｓ］未満である場合には（Ｓ１５０２でＮｏ）、通常通りファイルをアイテムとして伝送する（Ｓ１５０５）。
図６２は、フラグメントカウンタを活用する場合の受信装置の動作フローである。
まず、受信装置は、アセット管理テーブルなどのファイルの伝送に関する制御情報を取得、解析する（Ｓ１６０１）。次に、受信装置は、所望のアイテムが分割ファイルであるかどうかを判定する（Ｓ１６０２）。受信装置は、所望のファイルが分割ファイルであると判定した場合には（Ｓ１６０２でＹｅｓ）、分割ファイルや分割ファイルのインデックスなど、ファイルを再構成するための情報を制御情報から取得する（Ｓ１６０３）。そして、受信装置は、分割ファイルを構成するアイテムを取得し、元のファイルを再構成する（Ｓ１６０４）。一方、受信装置は、所望のファイルが分割ファイルでないと判定した場合（Ｓ１６０２でＮｏ）、通常通りファイルを取得する（Ｓ１６０５）。
要するに、送信装置は、ファイル先頭の分割データのパケットシーケンス番号をシグナリングする。また、送信装置は、分割データ数を特定できる情報をシグナリングする。或いは、送信装置は、分割データ数を特定できる分割ルールを規定する。また、送信装置は、フラグメントカウンタを運用せずに、ｒｅｓｅｒｖｅｄ或いはヘッダ圧縮する。
受信装置は、ファイル先頭のデータのパケットシーケンス番号がシグナリングされている場合には、ファイル先頭の分割データのパケットシーケンス番号と、ＭＭＴＰパケットのパケットシーケンス番号から、分割データ番号や分割データ数を特定する。
別の観点では、送信装置は、ファイルを分割し、分割ファイル毎にデータを分割して送信する。分割ファイルを紐づける情報（シーケンス番号、分割数など）をシグナリングする。
受信装置は、フラグメントカウンタ、及び分割ファイルのシーケンス番号により、分割データ番号や分割データ数を特定する。
これにより、分割データ番号や分割データを一意に特定できる。また、途中の分割データを受信した時点で当該分割データの分割データ番号を特定できるため、待機時間を削減し、メモリも削減できる。
また、フラグメントカウンタを運用しないことにより、送受信装置の構成は処理量を削減することができる、また、伝送効率を向上させることができる。
図６３は、同一番組を複数のＩＰデータフローで送信する場合のサービス構成を示す図である。ここでは、サービスＩＤ＝２の番組の一部（映像・音声）のデータがＭＭＴ方式を用いたＩＰデータフローで送信され、同じサービスＩＤであり、当該一部のデータとは異なるデータが高度ＢＳデータ伝送方式を用いたＩＰデータフロー（この例ではファイル伝送プロトコルも異なるが同じプロトコルであってもよい。）で送信される例を示している。
送信装置は、受信装置において、複数のＩＰデータフローから構成されるデータが、復号時刻までに揃うことを保証できるように、ＩＰデータの多重化を行う。
受信装置は、複数のＩＰデータフローから構成されるデータを用いて、復号時刻に基づいて処理することにより、保証された受信機動作を実現することができる。
［補足：送信装置及び受信装置］
以上のように、フラグメントカウンタを運用せずにデータの送信を行う送信装置は、図６４のように構成することも可能である。また、フラグメントカウンタを運用せずにデータの受信を行う受信装置は、図６５のように構成することも可能である。図６４は、送信装置の具体的構成の例を示す図である。図６５は、受信装置の具体的構成の例を示す図である。
送信装置５００は、分割部５０１と、構成部５０２と、送信部５０３とを備える。分割部５０１、構成部５０２、及び送信部５０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置６００は、受信部６０１と、判定部６０２と、構成部６０３とを備える。受信部６０１、判定部６０２、及び構成部６０３のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置５００及び受信装置６００の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法について、図６６を用いて説明する。図６６は、送信装置による動作フロー（送信方法）である。
まず、送信装置５００の分割部５０１は、データを複数の分割データに分割する（Ｓ１７０１）。
次に、送信装置５００の構成部５０２は、複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、複数のパケットを構成する（Ｓ１７０２）。
そして、送信装置５００の送信部５０３は、構成された前記複数のパケットを送信する（Ｓ１７０３）。送信部５０３は、分割データ情報、および、無効化されたフラグメントカウンタの値を、送信する。なお、分割データ情報は、分割データ番号と、分割データ数とを特定するための情報である。また、分割データ番号は、当該分割データが複数の分割データのうちの何番目の分割データであるかを示す番号である。分割データ数は、複数の分割データの数である。
これにより、送信装置５００の処理量を削減することができる。
次に、受信方法について、図６７を用いて説明する。図６７は、受信装置による動作フロー（受信方法）である。
まず、受信装置６００の受信部６０１は、複数のパケットを受信する（Ｓ１８０１）。
次に、受信装置６００の判定部６０２は、受信した複数のパケットから、分割データ情報が、当取得されたか否かを判定する（Ｓ１８０２）。
そして、受信装置６００の構成部６０３は、判定部６０２により、分割データ情報を取得したと判定された場合（Ｓ１８０２でＹｅｓ）、当該ヘッダ情報に含まれるフラグメントカウンタの値を使用せずに、受信した複数のパケットからデータを構成する（Ｓ１８０３）。
一方で、構成部６０３は、判定部６０２により、分割データ情報を取得していないと判定された場合（Ｓ１８０２でＮｏ）、当該ヘッダ情報に含まれるフラグメントカウンタの値を用いて、受信した複数のパケットからデータを構成してもよい（Ｓ１８０４）。
これにより、受信装置６００の処理量を削減することができる。
（実施の形態５）
［概要］
実施の形態５では、ＮＡＬサイズフォーマットでＮＡＬユニットを多重化レイヤに格納した場合の伝送パケット（ＴＬＶパケット）の送信方法について説明する。
実施の形態１で説明したように、Ｈ．２６４やＨ．２６５のＮＡＬユニットを多重化レイヤに格納する際には、次の２種類の形式がある。１つは、ＮＡＬユニットヘッダの直前に特定のビット列からなるスタートコードを付加するバイトストリームフォーマットと呼ばれる形式である。もう１つは、ＮＡＬユニットのサイズを示すフィールドを付加するＮＡＬサイズフォーマットと呼ばれる形式である。バイトストリームフォーマットは、ＭＰＥＧ－２システムやＲＴＰなどにおいて用いられ、ＮＡＬサイズフォーマットはＭＰ４、あるいは、ＭＰ４を使用するＤＡＳＨやＭＭＴなどにおいて用いられる。
バイトストリームフォーマットにおいて、スタートコードは３バイトで構成され、さらに任意のバイト（値は０であるバイト）を付加することもできる。
一方で、一般的なＭＰ４におけるＮＡＬサイズフォーマットでは、サイズ情報は、１バイト、２バイト、および４バイトのいずれかで示される。このサイズ情報は、ＨＥＶＣサンプルエントリにおけるｌｅｎｇｔｈＳｉｚｅＭｉｎｕｓＯｎｅフィールドで示される。当該フィールドの値が「０」の場合は１バイト、「１」の場合は２バイト、「３」の場合は４バイトであることを示す。
ここで、２０１４年７月に規格化された、ＡＲＩＢ ＳＴＤ－Ｂ６０「デジタル放送におけるＭＭＴによるメディアトランスポート方式」では、ＮＡＬユニットを多重化レイヤに格納する際、ＨＥＶＣエンコーダの出力がバイトストリームである場合、バイトスタートコードを除去し、３２ビット（符号なし整数）で示したバイト単位のＮＡＬユニットのサイズを長さ情報としてＮＡＬユニットの直前に付加する。なお、ＨＥＶＣサンプルエントリを含むＭＰＵメタデータを伝送せず、サイズ情報は３２ビット（４バイト）固定である。
また、ＡＲＩＢ ＳＴＤ－Ｂ６０「デジタル放送におけるＭＭＴによるメディアトランスポート方式」では、送信装置が受信装置におけるバッファ動作を保証するために送信の際に考慮する受信バッファモデルにおいては、映像信号の復号前バッファは、ＣＰＢであると規定されている。
しかし、次のような課題がある。ＭＰＥＧ－２システムにおけるＣＰＢや、ＨＥＶＣにおけるＨＲＤでは、映像信号がバイトストリームフォーマットであることを前提に規定されている。このため、例えば、３バイトのスタートコードが付いたバイトストリームフォーマットであることを前提に伝送パケットのレート制御を行った場合、４バイトのサイズ領域が付加されたＮＡＬサイズフォーマットの伝送パケットを受信した受信装置は、ＡＲＩＢ ＳＴＤ－Ｂ６０における受信バッファモデルを満たすことができない可能性がある。また、ＡＲＩＢ ＳＴＤ－Ｂ６０における受信バッファモデルには、具体的なバッファサイズ、および、引き抜きレートが示されていないため、受信装置におけるバッファ動作を保証することは難しい。
したがって、上記の課題を解決するために、受信機におけるバッファ動作を保証するための受信バッファモデルを下記のように規定する。
図６８は、ＡＲＩＢ ＳＴＤ－Ｂ６０に規定されている受信バッファモデルに基づいて、特に放送伝送路のみを用いた場合の受信バッファモデルを示す。
受信バッファモデルは、ＴＬＶパケットバッファ（第１のバッファ）と、ＩＰパケットバッファ（第２のバッファ）と、ＭＭＴＰバッファ（第３のバッファ）と、復号前バッファ（第４のバッファ）とを備える。なお、放送伝送路では、デジッタバッファやＦＥＣのためのバッファは必要ないため、省略している。
ＴＬＶパケットバッファは、ＴＬＶパケット（伝送パケット）を放送伝送路から受信し、受信したＴＬＶパケットに格納されている可変長のパケットヘッダ（ＩＰパケットヘッダ、ＩＰパケット圧縮時のフルヘッダ、ＩＰパケット圧縮時の圧縮ヘッダ）、および可変長のペイロードで構成されるＩＰパケットを、ヘッダ伸張された固定長のＩＰパケットヘッダを有するＩＰパケット（第１のパケット）に変換し、変換することにより得られたＩＰパケットを一定のビットレートで出力する。
ＩＰパケットバッファは、ＩＰパケットをパケットヘッダおよび可変長のペイロードを有するＭＭＴＰパケット（第２のパケット）に変換し、変換することにより得られたＭＭＴＰパケットを一定のビットレートで出力する。なお、ＩＰパケットバッファは、ＭＭＴＰバッファにマージされていても良い。
ＭＭＴＰバッファは、出力されたＭＭＴＰパケットをＮＡＬユニットに変換し、変換することにより得られたＮＡＬユニットを一定のビットレートで出力する。
復号前バッファは、出力されたＮＡＬユニットを順次蓄積し、蓄積した複数のＮＡＬユニットからアクセスユニットを生成し、生成したアクセスユニットを当該アクセスユニットに対応した復号時刻のタイミングでデコーダに出力する。
図６８に示す受信バッファモデルでは、前段のＴＬＶパケットバッファおよびＩＰパケットバッファ以外のバッファであるＭＭＴＰバッファおよび復号前バッファは、ＭＰＥＧ－２ ＴＳにおける受信バッファモデルを踏襲することが特徴的である。
例えば、映像におけるＭＭＴＰバッファ（ＭＭＴＰ Ｂ１）は、ＭＰＥＧ－２ ＴＳにおけるトランスポートバッファ（ＴＢ）、及び、多重化バッファ（ＭＢ）に相当するバッファで構成される。また、音声におけるＭＭＴＰバッファ（ＭＭＴＰ Ｂｎ）は、ＭＰＥＧ－２ ＴＳにおけるトランスポートバッファ（ＴＢ）に相当するバッファで構成される。
トランスポートバッファのバッファサイズは、ＭＰＥＧ－２ ＴＳ同様であり固定値とする。例えば、ＭＴＵサイズのｎ倍（ｎは、小数であっても整数であってもよく、１以上とする。）とする。
また、ＭＭＴＰパケットヘッダのオーバーヘッド率がＰＥＳパケットヘッダのオーバーヘッド率よりも小さくなるように、ＭＭＴＰパケットサイズを規定する。これにより、トランスポートバッファからの引き抜きレートは、ＭＰＥＧ－２ ＴＳにおけるトランスポートバッファの引き抜きレートＲＸ１、ＲＸｎ、ＲＸｓをそのまま適用することができる。
また、多重化バッファのサイズ、および、引き抜きレートは、それぞれ、ＭＰＥＧ－２
ＴＳにおけるＭＢサイズ、および、ＲＢＸ１とする。
以上の受信バッファモデルに加え、課題を解決するために、下記の制約を設ける。
ＨＥＶＣのＨＲＤ規定は、バイトストリーム形式が前提であり、ＭＭＴはＮＡＬユニットの先頭に４バイトのサイズ領域を付加するＮＡＬサイズ形式である。したがって、符号化時にはＮＡＬサイズ形式において、ＨＲＤを満たすようにレート制御を行う。
つまり、送信装置では、上記の受信バッファモデルおよび制約に基づいて、伝送パケットのレート制御を行う。
受信装置では、上記の信号を用いて受信処理をすることにより、アンダーフローやオーバーフローすることなる復号動作をすることができる。
なお、ＮＡＬユニットの先頭のサイズ領域は４バイトでなくても、ＮＡＬユニットの先頭のサイズ領域を考慮して、ＨＲＤを満たすようにレート制御を行う。
なお、ＴＬＶパケットバッファの引き抜きレート（ＴＬＶパケットバッファがＩＰパケットを出力する際のビットレート）は、ＩＰヘッダ伸張後の伝送レートを考慮して設定する。
つまり、データサイズが可変長であるＴＬＶパケットを入力し、ＴＬＶヘッダの除去およびＩＰヘッダの伸張（復元）を実施した後、出力されるＩＰパケットの伝送レートを考慮する。言い換えれば、入力される伝送レートに対してヘッダの増減量を考慮する。
具体的には、データサイズが可変長であること、ＩＰヘッダ圧縮されるパケットとＩＰヘッダ圧縮されていないパケットとが混在すること、ＩＰｖ４，ＩＰｖ６などのパケット種別によりＩＰヘッダのサイズが異なることから、出力されるＩＰパケットの伝送レートは一意ではない。このため、可変長のデータサイズの平均パケット長を定め、ＴＬＶパケットから出力されるＩＰパケットの伝送レートを定める。
ここでは、ＩＰヘッダ伸張後の最大伝送速度を規定するために、ＩＰヘッダは常に圧縮されている場合を想定して伝送レートを定める。
また、ＩＰｖ４、ＩＰｖ６のパケット種別が混在する場合、或いは、パケット種別を区別することなく規定する場合は、ヘッダサイズが大きく、ヘッダ伸張後の増加率の大きいＩＰｖ６パケットを想定して伝送レートを定める。
例えば、ＴＬＶパケットバッファに入力されるＴＬＶパケットの平均パケット長がＳであり、ＴＬＶパケットに格納されるＩＰパケットはすべてＩＰｖ６パケットであり、ヘッダ圧縮されているとした場合の、ＴＬＶヘッダの除去及びＩＰヘッダの伸張後の最大出力伝送レートは、
入力レート×｛Ｓ／（Ｓ＋ＩＰｖ６ヘッダ圧縮量）｝
となる。
より具体的には、ＴＬＶパケットの平均パケット長Ｓを、
Ｓ＝０．７５×１５００（１５００は最大ＭＴＵサイズを想定）
を基準として設定し、
ＩＰｖ６ヘッダ圧縮量＝ＴＬＶヘッダ長－ＩＰｖ６ヘッダ長－ＵＤＰヘッダ長
＝３－４０－８
とした場合、ＴＬＶヘッダの除去及びＩＰヘッダの伸張後の最大出力伝送レートは、
入力レート×１．０４１７≒入力レート×１．０５
となる。
図６９は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す図である。
ＭＭＴ方式では、データユニットをアグリゲーションする際、図６９に示すように、データユニットの前に、データユニット長、及び、データユニットヘッダが付加される。
しかし、例えば、ＮＡＬサイズフォーマットの映像信号を一つのデータユニットとして格納する場合、図７０に示すように、一つのデータユニットに対して、サイズを示すフィールドが２つあり、情報として重複している。図７０は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例であって、ＮＡＬサイズフォーマットの映像信号を一つのデータユニットとした場合の例を示す図である。具体的には、ＮＡＬサイズフォーマットにおける先頭のサイズ領域（以降の説明では、「ｓｉｚｅ領域」と呼ぶ。）と、ＭＭＴＰペイロードヘッダにおけるデータユニットヘッダの前に位置するデータユニット長フィールドとのいずれもサイズを示すフィールドであり、情報として重複している。例えば、ＮＡＬユニットの長さがＬバイトである場合、ｓｉｚｅ領域にはＬバイトが示されており、データユニット長フィールドには、Ｌバイト＋「ｓｉｚｅ領域の長さ」（ｂｙｔｅ）が示される。ｓｉｚｅ領域と、データユニット長フィールドとで示される値は完全に一致はしていないが、一方の値から他方の値を容易に算出できるため、重複していると言える。
このように、データのサイズ情報を内部に含むデータをデータユニットとして格納し、かつ、複数の当該データユニットをアグリゲーションして一つのペイロードに格納する場合、サイズ情報が重複するため、オーバーヘッドが大きく、伝送効率が悪いと言う課題がある。
そこで、送出装置では、データのサイズ情報を内部に含むデータをデータユニットとして格納し、かつ、複数の当該データユニットをアグリゲーションして一つのペイロードに格納する場合、図７１や図７２に示すように格納することが考えられる。
図７１に示すように、ｓｉｚｅ領域を含むＮＡＬユニットをデータユニットとして格納し、ＭＭＴＰペイロードヘッダに従来含まれるデータユニット長は示さないことが考えられる。図７１は、データユニット長が示されないＭＭＴＰパケットのペイロードの構成を示す図である。
また、図７２に示すように、データユニット長が示されているかどうかを示すフラグや、ｓｉｚｅ領域の長さを示す情報を新たにヘッダに格納してもよい。フラグやｓｉｚｅ領域の長さを示す情報を格納する場所は、データユニットヘッダなど、データユニット単位で示してもよいし、複数のデータユニットをアグリゲーションした単位で（パケット単位）で示してもよい。図７２は、パケット単位に付与されるｅｘｔｅｎｄ領域に示す例である。なお、上記の新規に示す情報の格納場所はこれに限るものではなく、ＭＭＴＰペイロードヘッダやＭＭＴＰパケットヘッダ、制御情報であってもよい。
受信側では、データユニット長が圧縮されているかどうかを示すフラグが、データユニット長が圧縮されていることを示している場合は、データユニット内部のｓｉｚｅ領域の長さ情報を取得し、ｓｉｚｅ領域の長さ情報に基づいて、ｓｉｚｅ領域を取得することにより、取得したｓｉｚｅ領域の長さ情報およびｓｉｚｅ領域を用いてデータユニット長を算出できる。
以上の方法により、送出側でデータ量を削減することができ、伝送効率を向上できる。
なお、データユニット長を削減するのではなく、ｓｉｚｅ領域を削減することによりオーバーヘッド削減してもよい。ｓｉｚｅ領域を削減する場合には、ｓｉｚｅ領域が削減されているかどうかを示す情報や、データユニット長フィールドの長さを示す情報を格納してもよい。
なお、ＭＭＴＰペイロードヘッダにも、長さ情報が含まれる。
ｓｉｚｅ領域を含むＮＡＬユニットをデータユニットとして格納する場合は、アグリゲーションする／しないにかかわらず、ＭＭＴＰペイロードヘッダにおけるペイロードサイズ領域を削減してもよい。
また、ｓｉｚｅ領域を含まないデータをデータユニットとして格納する場合でも、アグリゲーションされており、データユニット長が示されている場合には、ＭＭＴＰペイロードヘッダにおけるペイロードサイズ領域を削減してもよい。
ペイロードサイズ領域を削減する場合には、上記と同様に、削減したかどうかを示すフラグや、削減したサイズフィールドの長さ情報、或いは削減しなかったサイズフィールドの長さ情報を示してもよい。
図７３は、受信装置の動作フローを示す。
送出装置では、上述したように、ｓｉｚｅ領域を含むＮＡＬユニットをデータユニットとして格納し、ＭＭＴＰペイロードヘッダに含まれるデータユニット長はＭＭＴＰパケットにおいて示さないとする。
以下では、データユニット長が示されているかどうかをフラグや、ｓｉｚｅ領域の長さ情報がＭＭＴＰパケットにおいて示されている場合を例に説明する。
受信装置は、データユニットがサイズ領域を含み、データユニット長が削減されているかどうかを、送出側から送信される情報に基づいて判定する（Ｓ１９０１）。
データユニット長が削減されていると判定した場合（Ｓ１９０２でＹｅｓ）、データユニット内部のサイズ領域の長さ情報を取得し、その後、データユニット内部のサイズ領域を解析し、データユニット長を算出することにより取得する（Ｓ１９０３）。
一方、データユニット長が削減されていないと判定した場合（Ｓ１９０２でＮｏ）、通常どおり、データユニット長、および、データユニット内部のサイズ領域のいずれか一方からデータユニット長を算出する（Ｓ１９０４）。
なお、データユニット長が削減されているかどうかを示すフラグや、ｓｉｚｅ領域の長さ情報は、予め受信装置が分かっている場合、送信しなくてもよい。この場合受信装置は予め定められた情報に基づいて図７３で示した処理を行う。
［補足：送信装置及び受信装置］
以上のように、符号化時に受信バッファモデルの規定を満たすようにレート制御を行う送信装置は、図７４のように構成することも可能である。また、送信装置から送信された伝送パケットを受信し、復号する受信装置は、図７５のように構成することも可能である。図７４は、送信装置の具体的構成の例を示す図である。図７５は、受信装置の具体的構成の例を示す図である。
送信装置７００は、生成部７０１と、送信部７０２とを備える。生成部７０１及び送信部７０２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置８００は、受信部８０１と、第１のバッファ８０２と、第２のバッファ８０３と、第３のバッファ８０４と、第４のバッファ８０５と、復号部８０６とを備える。受信部８０１、第１のバッファ８０２、第２のバッファ８０３、第３のバッファ８０４、第４のバッファ８０５及び復号部（デコーダ）８０６のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置７００及び受信装置８００の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法について、図７６を用いて説明する。図７６は、送信装置による動作フロー（送信方法）である。
まず、送信装置７００の生成部７０１は、受信装置のバッファ動作を保証するために予め定められた受信バッファモデルによる規定を満たすようにレート制御を行うことで符号化ストリームを生成する（Ｓ２００１）。
次に、送信装置７００の送信部７０２は、生成された符号化ストリームをパケット化し、パケット化することで得られた伝送パケットを送信する（Ｓ２００２）。
なお、送信装置７００において用いられる受信バッファモデルは、受信装置８００の構成の第１～第４のバッファ８０２～８０５を備える構成であるため、説明を省略する。
これにより、送信装置７００は、ＭＭＴのような方式を用いてデータ伝送する場合に、受信装置８００のバッファ動作を保証できる。
次に、受信方法について、図７７を用いて説明する。図７７は、受信装置による動作フロー（受信方法）である。
まず、受信装置８００の受信部８０１は、固定長のパケットヘッダおよび可変長のペイロードで構成された伝送パケットを受信する（Ｓ２１０１）。
次に、受信装置８００の第１のバッファ８０２は、受信した伝送パケットに格納されている可変長のパケットヘッダおよび可変長のペイロードで構成されるパケットを、ヘッダ伸張された固定長のパケットヘッダを有する第１のパケットに変換し、変換することにより得られた前記第１のパケットを一定のビットレートで出力する（Ｓ２１０２）。
次に、受信装置８００の第２のバッファ８０３は、変換することにより得られた第１のパケットをパケットヘッダおよび可変長のペイロードで構成される第２のパケットに変換し、変換することにより得られた第２のパケットを一定のビットレートで出力する（Ｓ２１０３）。
次に、受信装置８００の第３のバッファ８０４は、出力された第２のパケットをＮＡＬユニットに変換し、変換することにより得られたＮＡＬユニットを一定のビットレートで出力する（Ｓ２１０４）。
次に、受信装置８００の第４のバッファ８０５は、出力されたＮＡＬユニットを順次蓄積し、蓄積した複数のＮＡＬユニットからアクセスユニットを生成し、生成したアクセスユニットを当該アクセスユニットに対応した復号時刻のタイミングでデコーダに出力する（Ｓ２１０５）。
そして、受信装置８００の復号部８０６は、第４のバッファにより出力されたアクセスユニットを復号する（Ｓ２１０６）。
これにより、受信装置８００は、アンダーフローやオーバーフローすることなる復号動作を行うことができる。
（実施の形態６）
［概要］
実施の形態６では、ＭＭＴ／ＴＬＶの伝送方式における基準クロックの基準となる時刻情報にうるう秒調整が行なわれる場合の送信方法及び受信方法について説明する。
図７８は、ＡＲＩＢ ＳＴＤ－Ｂ６０に規定されるＭＭＴ／ＴＬＶ方式のプロトコルスタックを示す図である。
ＭＭＴ方式では、パケットには、映像や音声などのデータを複数のＭＰＵ（Ｍｅｄｉａ
Ｐｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ）やＭＦＵ（Ｍｅｄｉａ Ｆｒａｇｍｅｎｔ Ｕｎｉｔ）などの所定のデータユニットごとに格納し、ＭＭＴＰパケットヘッダを付与することで所定のパケットとしてのＭＭＴＰパケットを生成する（ＭＭＴＰパケット化する）。また、ＭＭＴＰにおける制御メッセージなどの制御情報に対しても、ＭＭＴＰパケットヘッダを付与することで、所定のパケットとしてのＭＭＴＰパケットを生成する。ＭＭＴＰパケットヘッダには、３２ビットのショートフォーマットのＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ：ＩＥＴＦ ＲＦＣ ５９０５に規定）を格納するフィールドが設けられており、通信回線のＱｏＳ制御等に用いることができる。
また、送信側（送信装置）の基準クロックをＲＦＣ ５９０５に規定される６４ビットのロングフォーマットＮＴＰに同期させ、同期させた当該基準クロックを基に、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）や、ＤＴＳ（Ｄｅｃｏｄｅ Ｔｉｍｅ Ｓｔａｍｐ）などのタイムスタンプを同期メディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では送信側から受信した基準クロック情報を基に受信装置におけるシステムクロックを生成する。
ＰＴＳやＤＴＳは、具体的には、ＭＭＴＰの制御情報であるＭＰＵタイムスタンプ記述子や、ＭＰＵ拡張タイムスタンプ記述子に格納されて、アセット毎にＭＰテーブルに格納され、制御メッセージとしてＭＭＴＰパケット化された後、伝送される。
ＭＭＴＰパケット化されたデータは、ＵＤＰヘッダやＩＰヘッダが付与されＩＰパケットにカプセル化される。このとき、ＩＰヘッダやＵＤＰヘッダにおいて、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、プロトコル種別が同じもののパケットの集合をＩＰデータフローとする。なお、同じＩＰデータフローのＩＰパケットは、ヘッダが冗長であるため、一部のＩＰパケットではヘッダ圧縮される。
また、基準クロック情報として、６４ビットのＮＴＰタイムスタンプは、ＮＴＰパケットに格納され、ＩＰパケットに格納される。このとき、ＮＴＰパケットを格納するＩＰパケットでは、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別は固定値であり、ＩＰパケットのヘッダは圧縮されない。
図７９は、ＴＬＶパケットの構成を示す図である。
ＴＬＶパケットには、図７９に示すように、ＩＰパケット、圧縮ＩＰパケット、ＡＭＴ（Ａｄｄｒｅｓｓ Ｍａｐ Ｔａｂｌｅ）やＮＩＴ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）などの伝送制御情報をデータとして含むことができ、これらのデータは、８ビットのデータタイプを用いて識別される。また、ＴＬＶパケットでは、１６ビットのフィールドを用いてデータ長（バイト単位）が示され、そのあとにデータの値を格納する。また、ＴＬＶパケットは、データタイプの前に１バイトのヘッダ情報を有し、当該ヘッダ情報は、合計４バイトのヘッダ領域に格納される。また、ＴＬＶパケットは、高度ＢＳ伝送方式における伝送スロットにマッピングされ、ＴＭＣＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｍｕｌｔｉｐｌｅｘｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｎｔｒｏｌ）制御情報にマッピング情報が格納される。
図８０は、受信装置のブロック図の一例を示す図である。
受信装置では、まずチューナーで受信した放送信号に対し、復調手段において伝送路符号化データを復号、誤り訂正などを施し、ＴＬＶパケットを抽出する。そして、ＴＬＶ／ＩＰ ＤＥＭＵＸ手段では、ＴＬＶのＤＥＭＵＸ処理やＩＰのＤＥＭＵＸ処理を行う。ＴＬＶのＤＥＭＵＸ処理は、ＴＬＶパケットのデータタイプに応じた処理を行う。例えば、ＴＬＶパケットが圧縮ＩＰパケットを有する場合は、当該圧縮ＩＰパケットの圧縮されたヘッダを復元する。ＩＰ ＤＥＭＵＸでは、ＩＰパケットやＵＤＰパケットのヘッダ解析などの処理を行い、ＭＭＴＰパケット及びＮＴＰパケットを抽出する。
ＮＴＰクロック生成手段では、抽出したＮＴＰパケットからＮＴＰクロックを再生する。ＭＭＴＰ ＤＥＭＵＸでは、抽出したＭＭＴＰパケットヘッダに格納されているパケットＩＤを基に映像や音声などのコンポーネントや制御情報のフィルタリング処理を行う。制御情報取得手段からは、ＭＰテーブルの中に格納されるタイムスタンプ記述子を取得し、ＰＴＳ／ＤＴＳ算出手段においてアクセスユニット毎のＰＴＳ及びＤＴＳを算出する。なお、タイムスタンプ記述子は、ＭＰＵタイムスタンプ記述子及びＭＰＵ拡張タイムスタンプ記述子の両記述子を含む。
アクセスユニット再生手段では、ＭＭＴＰパケットからフィルタリングされた映像や音声などを、提示する単位のデータに変換する。提示する単位のデータとは、具体的には、映像信号のＮＡＬユニットやアクセスユニット、音声フレーム、字幕の提示単位などである。復号提示手段では、ＮＴＰクロックの基準時刻情報をベースに、アクセスユニットのＰＴＳ／ＤＴＳが一致した時刻に、アクセスユニットを復号、提示する。
なお、受信装置の構成は、これに限るものではない。
次にタイムスタンプ記述子について説明する。
図８１は、タイムスタンプ記述子について説明するための図である。
ＰＴＳやＤＴＳは、ＭＭＴの制御情報である、第１制御情報としてのＭＰＵタイムスタンプ記述子や第２制御情報としてのＭＰＵ拡張タイムスタンプ記述子に格納され、アセット毎にＭＰテーブルに格納され、制御メッセージとしてＭＭＴＰパケット化された後、伝送される。
図８１の（ａ）はＡＲＩＢ ＳＴＤ－Ｂ６０に規定されるＭＰＵタイムスタンプ記述子の構成を示す図である。ＭＰＵタイムスタンプ記述子には、複数のＭＰＵのそれぞれについて、当該ＭＰＵに含まれる複数のＡＵのうちの提示順で先頭（最初）のＡＵ（以下、「先頭ＡＵ」という。）のＰＴＳ（６４ｂｉｔのＮＴＰで示される絶対値）が格納される。つまり、ＭＰＵに付与された当該ＭＰＵの提示時刻情報は、ＭＭＴＰパケットの制御情報に格納されて送信される。
図８１の（ｂ）は、ＭＰＵ拡張タイムスタンプ記述子の構成を示すである。ＭＰＵ拡張タイムスタンプ記述子には、複数のＭＰＵのそれぞれのＭＰＵ内に含まれるＡＵのＰＴＳ及びＤＴＳを算出するための情報が格納される。ＭＰＵ拡張タイムスタンプ記述子には、ＭＰＵタイムスタンプ記述子に格納されるＭＰＵの先頭ＡＵのＰＴＳからの相対情報を含んでおり、ＭＰＵ内に含まれるＡＵのＰＴＳ及びＤＴＳは、ＭＰＵタイムスタンプ記述子とＭＰＵ拡張タイムスタンプ記述子との両方に基づいて算出できる。つまり、ＭＰＵ内に含まれる先頭ＡＵ以外のＡＵのＰＴＳ及びＤＴＳは、ＭＰＵタイムスタンプ記述子に格納される当該先頭ＡＵのＰＴＳと、ＭＰＵ拡張タイムスタンプ記述子に格納されている相対情報とに基づいて算出できる。
ＮＴＰは、協定世界時（Ｃｏｏｒｄｉｎａｔｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ（ＵＴＣ））に基づいた基準時刻情報である。ＵＴＣは、地球の自転速度に基づく天文時との差を調整するため、うるう秒の調整（以下、「うるう秒調整」という。）を実施する。うるう秒調整は、具体的には、日本時間の午前９時に実施され、１秒の挿入または削除を行う調整である。
図８２は、うるう秒調整を説明するための図である。
図８２の（ａ）は、日本時間における、うるう秒挿入の一例を示す図である。図８２の（ａ）に示すように、うるう秒挿入では、日本時間８：５９：５９の後、本来９：００：００になるタイミングで８：５９：５９となり、８：５９：５９台が２回繰り返される。
図８２の（ｂ）は、日本時間における、うるう秒削除の一例を示す図である。図８２の（ｂ）に示すように、うるう秒削除では、日本時間８：５９：５８の後、本来８：５９：５９になるタイミングで９：００：００となり、８：５９：５９台の１秒間が削除される。
ＮＴＰパケットには、６４ｂｉｔのタイムスタンプの他に、２ｂｉｔのｌｅａｐ＿ｉｎｄｉｃａｔｏｒが格納されている。ｌｅａｐ＿ｉｎｄｉｃａｔｏｒは、うるう秒調整が行なわれることを事前に通知するためのフラグであり、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝１の場合にうるう秒挿入を示し、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝２の場合にうるう秒削除を示す。事前通知は、うるう秒調整を実施する月の初めから通知する方法や、２４時間前に通知する方法、その他、任意の時間に通知を開始する方法がある。また、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒは、うるう秒調整が終わった時間（９：００：００）に０となる。例えば、２４時間前から事前通知する場合には、日本時間でうるう秒調整が行われる前日の９：００からうるう秒調整が行われる当日におけるうるう秒調整が行われる直前の時刻（つまり、うるう秒挿入の場合は１回目の８：５９：５９台の時刻であり、うるう秒削除の場合は８：５９：５８台の時刻）までの間にｌｅａｐ＿ｉｎｄｉｃａｔｏｒが「１」または「２」であることが示される。
次に、うるう秒調整時の課題について説明する。
図８３は、ＮＴＰ時刻、ＭＰＵタイムスタンプ及びＭＰＵ提示タイミングの関係を示す図である。なお、ＮＴＰ時刻は、ＮＴＰにより示される時刻である。また、ＭＰＵタイムスタンプは、ＭＰＵ内の先頭ＡＵのＰＴＳを示すタイムスタンプである。また、ＭＰＵ提示タイミングとは、受信装置がＭＰＵタイムスタンプに従ってＭＰＵを提示すべきタイミングである。具体的には、図８３の（ａ）～（ｃ）は、それぞれ、うるう秒調整が発生しない場合、うるう秒が挿入される場合、うるう秒が削除される場合におけるＮＴＰ時刻、ＭＰＵタイムスタンプ及びＭＰＵ提示時刻の関係を示す図である。
ここでは、送出側のＮＴＰ時刻（基準クロック）は、ＮＴＰサーバと同期しており、また、受信側のＮＴＰ時刻（システムクロック）は、送出側のＮＴＰ時刻と同期している場合を例に説明する。この場合、受信装置では、送出側から伝送されるＮＴＰパケットに格納されているタイムスタンプに基づいて再生する。また、この場合、送出側のＮＴＰ時刻及び受信側のＮＴＰ時刻共に、ＮＴＰサーバと同期しているため、うるう秒の調整時に±１秒の調整がなされる。また、図８３におけるＮＴＰ時刻は、送出側のＮＴＰ時刻及び受信側のＮＴＰ時刻で共通であるとする。なお、伝送遅延はないものとして説明する。
図８３におけるＭＰＵタイムスタンプは、複数のＭＰＵのそれぞれに含まれる複数のＡＵのうちの提示順における先頭ＡＵのタイムスタンプを示しており、矢印の元で示されるＮＴＰ時刻に基づいて生成（設定）される。具体的には、ＭＰＵの提示時刻情報を生成するタイミングにおける基準時刻情報としてのＮＴＰ時刻に、予め定められた時間（図８３では、例えば、１．５秒）を加算することで、ＭＰＵの提示時刻情報を生成する。生成されたＭＰＵタイムスタンプは、ＭＰＵタイムスタンプ記述子に格納される。
受信装置では、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプに基づくＭＰＵ提示時刻においてＭＰＵを提示する。
なお、図８３では、１つのＭＰＵの再生時間は１秒であるとして説明するが、１つのＭＰＵの再生時間は、それ以外の再生時間であってもよく、例えば、０．５秒でもよいし、０．１秒でもよい。
図８３の（ａ）の例では、受信装置は、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプに基づいてＭＰＵ＃１－＃５を順番に提示することができる。
しかし、図８３の（ｂ）では、うるう秒挿入によりＭＰＵ＃２とＭＰＵ＃３との提示時刻が重複する。このため、受信装置は、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプに基づいてＭＰＵを提示してしまうと、同じ９：００：００台の時間帯に提示するＭＰＵが２つ存在することになり、２つのＭＰＵのどれを提示すべきかの判断ができない。また、受信装置は、ＭＰＵ＃１のタイムスタンプで示されるＭＰＵ提示時刻（８：５９：５９）が２回存在することになるため、２つのＭＰＵ提示時刻のうちどのＭＰＵ提示時刻で提示すべきかの判断ができない。
また、図８３の（ｃ）では、受信装置は、うるう秒の削除により、ＭＰＵ＃３のＭＰＵタイムスタンプで示されるＭＰＵ提示時刻（８：５９：５９）がＮＴＰ時刻に存在しないため、ＭＰＵ＃３を提示することができない。
受信装置は、タイムスタンプに基づかないＭＰＵの復号処理及び提示処理を行う場合には、上記のような課題を解決できる。しかし、タイムスタンプに基づく処理を行う受信装置は、うるう秒の発生時のみに、異なる処理（タイムスタンプに基づかない処理）を行うことは困難である。
次に、送信側においてタイムスタンプを補正することでうるう秒調整時の課題を解決する方法について説明する。
図８４は、送信側においてタイムスタンプを補正する補正方法について説明するための図である。具体的には、図８４の（ａ）は、うるう秒挿入の例を示し、図８４の（ｂ）は、うるう秒削除の例を示す図である。
まず、うるう秒挿入の場合について説明する。
図８４の（ａ）に示すように、うるう秒挿入時には、うるう秒挿入の直前までの時刻（つまり、ＮＴＰ時刻における１回目の８：５９：５９台まで）をＡ領域とし、うるう秒挿入以後の時刻（つまり、ＮＴＰ時刻における２回目の８：５９：５９以降）をＢ領域とする。なお、Ａ領域及びＢ領域は、時間的な領域であり、時間帯または期間である。図８４の（ａ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰの時刻に基づいて生成（設定）したタイムスタンプである。
うるう秒挿入の場合に、送信側でのタイムスタンプの補正方法について具体的に説明する。
送信側（送信装置）では、以下の処理を行う。
１．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ａ）の矢印の元が示すタイミング）がＡ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が９：００：００以降を示す場合は、ＭＰＵタイムスタンプを１秒減ずる－１秒補正して、補正後のＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する。つまり、Ａ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを－１秒補正する。なお、ここでの「９：００：００」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）である。また、別途補正したことを示す情報である補正情報を受信装置に送信する。
２．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ａ）の矢印の元が示すタイミング）がＢ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
受信装置においては、ＭＰＵタイムスタンプと、当該ＭＰＵタイムスタンプが補正されたか否か（つまり、補正したことを示す情報が含まれるか否か）を示す補正情報に基づいて、ＭＰＵを提示する。
受信装置は、ＭＰＵタイムスタンプが補正されていないと判定した場合（つまり、補正したことを示す情報が含まれていないと判定した場合）、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプが受信装置のＮＴＰ時刻（補正前、補正後両方含む）に一致した時刻にＭＰＵを提示する。つまり、ＭＰＵタイムスタンプが補正されるＭＰＵより前に送信されるＭＰＵのＭＰＵタイムスタンプ記述子に格納されたＭＰＵタイムスタンプの場合、当該ＭＰＵタイムスタンプが、うるう秒挿入前（つまり、１回目の８：５９：５９台以前）のＮＴＰ時刻に一致したタイミングに当該ＭＰＵを提示する。また、受信したＭＰＵのＭＰＵタイムスタンプ記述子に格納されるＭＰＵタイムスタンプが、補正されるＭＰＵタイムスタンプより後に送信されるタイムスタンプの場合、うるう秒挿入後（つまり、２回目の８：５９：５９台以降）のＮＴＰ時刻に一致したタイミングに当該ＭＰＵを提示する。
また、受信装置は、受信したＭＰＵのＭＰＵタイムスタンプ記述子に格納されるＭＰＵタイムスタンプが補正されている場合、ＭＰＵタイムスタンプ記述子に格納されるタイムスタンプが、受信装置においてうるう秒挿入後（つまり、２回目の８：５９：５９台以降）のＮＴＰ時刻に基づいてＭＰＵを提示する。
なお、ＭＰＵタイムスタンプ値を補正したことを示す情報は、制御メッセージや記述子、テーブル、ＭＰＵメタデータ、ＭＦメタデータ、ＭＭＴＰパケットヘッダなどに格納して伝送する。
次に、うるう秒削除の場合について説明する。
図８４の（ｂ）に示すように、うるう秒削除時には、うるう秒削除の直前までの時刻（つまり、ＮＴＰ時刻における９：００：００直前）をＣ領域とし、うるう秒削除以後の時刻（つまり、ＮＴＰ時刻における９：００：００以降）をＤ領域とする。なお、Ｃ領域及びＤ領域は、時間的な領域であり、時間帯または期間である。図８４の（ｂ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰ時刻に基づいて生成（設定）したタイムスタンプである。
うるう秒削除の場合に、送信側でのタイムスタンプの補正方法について具体的に説明する。
送信側（送信装置）では、以下の処理を行う。
１．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ｂ）の矢印の元が示すタイミング）がＣ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプを１秒加える＋１秒補正して、補正後のＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する。つまり、Ｃ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。なお、ここでの「８：５９：５９」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）から－１秒減算することで得られた時刻である。また、別途補正したことを示す情報である補正情報を受信装置に送信する。なお、この場合、補正情報は、必ずしも送信しなくてもよい。
２．ＭＰＵタイムスタンプを付与するタイミング（図８４の（ｂ）の矢印の元が示すタイミング）がＤ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｄ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
受信装置においては、ＭＰＵタイムスタンプに基づいて、ＭＰＵを提示する。なお、当該ＭＰＵタイムスタンプが補正されたか否かを示す補正情報があれば、ＭＰＵタイムスタンプと当該補正情報とに基づいてＭＰＵを提示してもよい。
以上の処理により、ＮＴＰ時刻にうるう秒調整が行われた場合であっても、受信装置において、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプを用いて正常なＭＰＵの提示が可能となる。
なお、ＭＰＵタイムスタンプの付与タイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかをシグナリングし、受信側に通知してもよい。つまり、当該ＭＰＵタイムスタンプが、Ａ領域に含まれるＮＴＰ時刻に基づいて生成されたか、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたか、または、Ｃ領域に含まれるＮＴＰ時刻に基づいて生成されたか、Ｄ領域に含まれるＮＴＰ時刻に基づいて生成されたかをシグナリングし、受信側に通知してもよい。言い換えると、ＭＰＵタイムスタンプ（提示時刻）がうるう秒調整前の基準時刻情報（ＮＴＰ時刻）に基づいて生成されたか否かを示す識別情報を送信してもよい。この識別情報は、ＮＴＰパケットに含まれるｌｅａｐ＿ｉｎｄｉｃａｔｏｒに基づいて付与されるため、日本時間でうるう秒調整が行われる前日の９：００からうるう秒調整が行われる当日におけるうるう秒調整が行われる直前の時刻（つまり、うるう秒挿入の場合は１回目の８：５９：５９台の時刻であり、うるう秒削除の場合は８：５９：５８台の時刻）までの間の時刻に基づいて設定されるＭＰＵタイムスタンプか否かを示す情報である。つまり、識別情報は、ＭＰＵタイムスタンプが、うるう秒調整が行われる直前の時刻よりも予め定められた期間（例えば２４時間）前の時刻から当該直前の時刻までにおけるＮＴＰ時刻に基づいて生成されたか否かを示す情報である。
次に、受信装置においてタイムスタンプを補正することでうるう秒調整時の課題を解決する方法について説明する。
図８５は、受信装置においてタイムスタンプを補正する補正方法について説明するための図である。具体的には、図８５の（ａ）は、うるう秒挿入の例を示し図８５の（ｂ）は、うるう秒削除の例を示す図である。
まず、うるう秒挿入の場合について説明する。
図８５の（ａ）に示すように、図８４の（ａ）と同様にうるう秒挿入時には、うるう秒挿入の直前までの時刻（つまり、ＮＴＰ時刻における１回目の８：５９：５９台まで）をＡ領域とし、うるう秒挿入以後の時刻（つまり、ＮＴＰ時刻における２回目の８：５９：５９以降）をＢ領域とする。なお、Ａ領域及びＢ領域は、時間的な領域であり、時間帯または期間である。図８５の（ａ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰの時刻に基づいて生成（設定）したタイムスタンプである。
うるう秒挿入の場合に、受信装置でのタイムスタンプの補正方法について具体的に説明する。
送信側（送信装置）では、以下の処理を行う。
・生成したＭＰＵタイムスタンプを補正せずに、当該ＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納して受信装置に送信する。
・ＭＰＵのタイムスタンプを付与したタイミングが、Ａ領域であるか、Ｂ領域であるかを示す情報を識別情報として受信装置に送信する。つまり、当該ＭＰＵタイムスタンプが、Ａ領域に含まれているＮＴＰ時刻に基づいて生成されたか、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたか、を示す識別情報を受信装置に送信する。
受信装置では、以下の処理を行う。
受信装置においては、ＭＰＵタイムスタンプと、ＭＰＵタイムスタンプを付与したタイミングがＡ領域であるか、Ｂ領域であるかを示す識別情報に基づいて、ＭＰＵタイムスタンプを補正する。
具体的には、以下の処理を行う。
１．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ａ）の矢印の元が示すタイミング）がＡ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が９：００：００以降を示す場合は、ＭＰＵタイムスタンプを１秒減ずる－１秒補正する。つまり、Ａ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを－１秒補正する。なお、ここでの「９：００：００」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）である。
２．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ａ）の矢印の元が示すタイミング）がＢ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
ＭＰＵタイムスタンプを補正しない場合、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプが受信装置のＮＴＰ時刻（補正前及び補正後含む）に一致した時刻にＭＰＵを提示する。
つまり、補正するＭＰＵタイムスタンプより前に受信されるＭＰＵタイムスタンプの場合、うるう秒挿入前（つまり、１回目の８：５９：５９台以前）のＮＴＰ時刻に一致した時刻にＭＰＵを提示する。また、補正するＭＰＵタイムスタンプより後に受信されるＭＰＵタイムスタンプの場合、うるう秒挿入後（２回目の８：５９：５９台以降）のＮＴＰ時刻に一致した時刻にＭＰＵを提示する。
ＭＰＵタイムスタンプを補正する場合、補正したＭＰＵタイムスタンプが、受信装置においてうるう秒挿入後（つまり、２回目の８：５９：５９台以降）のＮＴＰ時刻に基づいてＭＰＵを提示する。
なお、送信側は、ＭＰＵタイムスタンプを付与したタイミングがＡ領域であるか、Ｂ領域であるかを示す識別情報は、制御メッセージや記述子、テーブル、ＭＰＵメタデータ、ＭＦメタデータ、ＭＭＴＰパケットヘッダなどに格納して伝送する。
次に、うるう秒削除の場合について説明する。
図８５の（ｂ）に示すように、うるう秒削除時には、図８４の（ａ）と同様に、うるう秒削除の直前までの時刻（つまり、ＮＴＰ時刻における９：００：００直前まで）をＣ領域とし、うるう秒削除以後の時刻（つまり、ＮＴＰ時刻における９：００：００：以降）をＤ領域とする。なお、Ｃ領域及びＤ領域は、時間的な領域であり、時間帯または期間である。図８５の（ｂ）におけるＭＰＵタイムスタンプは、図８３で説明したタイムスタンプと同様であり、ＭＰＵタイムスタンプを付与するタイミングにおけるＮＴＰ時刻に基づいて生成（設定）したタイムスタンプである。
うるう秒削除の場合に、受信装置でのタイムスタンプの補正方法について具体的に説明する。
送信側（送信装置）では、以下の処理を行う。
・生成したＭＰＵタイムスタンプを補正せずに、当該ＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納して受信装置に送信する。
・ＭＰＵのタイムスタンプを付与したタイミングが、Ｃ領域であるか、Ｄ領域であるかを示す情報を識別情報として受信装置に送信する。つまり、当該ＭＰＵタイムスタンプが、Ｃ領域に含まれているＮＴＰ時刻に基づいて生成されたか、Ｂ領域に含まれるＮＴＰ時刻に基づいて生成されたか、を示す識別情報を受信装置に送信する。
受信装置では、以下の処理を行う。
受信装置においては、ＭＰＵタイムスタンプと、ＭＰＵタイムスタンプを付与したタイミングがＣ領域であるか、Ｄ領域であるかを示す識別情報に基づいて、ＭＰＵタイムスタンプを補正する。
具体的には、以下の処理を行う。
１．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ｂ）の矢印の元が示すタイミング）がＣ領域に含まれ、かつ、ＭＰＵタイムスタンプ（補正前のＭＰＵタイムスタンプの値）が８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプ値を１秒加える＋１秒補正する。つまり、Ｃ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプであり、かつ、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。なお、ここでの「８：５９：５９」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻（つまり、ＵＴＣ時刻に９時間を加算することにより算出される時刻）から－１秒減算することで得られた時刻である。
２．ＭＰＵタイムスタンプを付与するタイミング（図８５の（ｂ）の矢印の元が示すタイミング）がＤ領域の場合、ＭＰＵタイムスタンプを補正しない。つまり、Ｄ領域に含まれるＮＴＰ時刻に基づいて生成されたＭＰＵタイムスタンプである場合は、当該ＭＰＵタイムスタンプを補正しない。
受信装置においては、ＭＰＵタイムスタンプ、及び、補正したＭＰＵタイムスタンプに基づいて、ＭＰＵを提示する。
以上の処理により、ＮＴＰ時刻にうるう秒調整が行われた場合であっても、受信装置において、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプを用いて正常なＭＰＵの提示が可能となる。
なお、この場合であっても、図８４で説明した送信側においてＭＰＵタイムスタンプを補正する場合と同様に、ＭＰＵタイムスタンプの付与タイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかをシグナリングし、受信側に通知してもよい。通知の詳細については、同様であるので説明を省略する。
なお、図８４及び図８５で説明した、ＭＰＵタイムスタンプを補正したか否かを示す情報や、ＭＰＵタイムスタンプを付与したタイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかを示す情報などの付加情報（識別情報）は、ＮＴＰパケットのｌｅａｐ＿ｉｎｄｉｃａｔｏｒがうるう秒の削除（ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝２）や挿入（ｌｅａｐ＿ｉｎｄｉｃａｔｏｒ＝１）を示す場合に有効にしてもよい。予め定められた任意の時刻（例えば、うるう秒調整の３秒前）から有効となるとしてもよいし、動的に有効にしてもよい。
また、付加情報の有効期間が終わるタイミングや付加情報のシグナリングを終了するタイミングも、ＮＴＰパケットのｌｅａｐ＿ｉｎｄｉｃａｔｏｒに合わせてもよいし、予め定められた任意の時刻（例えば、うるう秒調整の３秒前）から有効となるとしてもよいし、動的に有効にしてもよい。
なお、ＭＭＴＰパケットに格納される３２ｂｉｔのタイムスタンプや、ＴＭＣＣに格納されるタイムスタンプ情報なども、ＮＴＰ時刻に基づいて生成され付与されるため、同様の課題が発生する。このため、３２ｂｉｔのタイムスタンプや、ＴＭＣＣに格納されるタイムスタンプ情報などの場合も図８４及び図８５と同様の方法を用いてタイムスタンプを補正し、受信装置においてタイムスタンプに基づいた処理を実施することができる。例えば、ＭＭＴＰパケットに格納される３２ｂｉｔのタイムスタンプに対する上記付加情報を格納する場合は、ＭＭＴＰパケットヘッダの拡張領域を用いて示してもよい。この場合、マルチヘッダータイプの拡張タイプに付加情報であることを示す。また、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒが立っている時間は、３２ｂｉｔや６４ｂｉｔのタイムスタンプのうち、一部のビットを用いて付加情報を示してもよい。
なお、図８４の例では、補正したＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納するとしたが、補正前及び補正後のＭＰＵタイムスタンプ（つまり、補正していないＭＰＵタイムスタンプ及び補正したＭＰＵタイムスタンプ）を両方受信装置に送信してもよい。例えば、補正前のＭＰＵタイムスタンプ記述子と、補正後のＭＰＵタイムスタンプ記述子とを同一のＭＰＵタイムスタンプ記述子に格納してもよいし、２つのＭＰＵタイムスタンプ記述子にそれぞれ格納してもよい。この場合、２つのＭＰＵタイムスタンプ記述子の配置順や、ＭＰＵタイムスタンプ記述子内の記載順などにより、補正前のＭＰＵタイムスタンプであるか、補正後のＭＰＵタイムスタンプであるかを識別してもよい。また、ＭＰＵタイムスタンプ記述子には常に補正前のＭＰＵタイムスタンプを格納するとし、補正をする場合には、補正後のタイムスタンプをＭＰＵ拡張タイムスタンプ記述子に格納するとしてもよい。
なお、本実施の形態では、ＮＴＰ時刻として日本時間での時刻（午前９時）を例に説明したが、日本時間での時刻に限らない。うるう秒調整は、ＵＴＣ時刻に基づくものであり、世界同時に補正される。日本時刻は、ＵＴＣ時刻を基準として９時間進んだ時刻であり、ＵＴＣ時刻に対する時刻（＋９）という値で表される。このように、場所に応じた時差により異なる時間に調整された時刻を採用してもよい。
以上のように、タイムスタンプを付与したタイミングを示す情報に基づいて、送信側、或いは受信装置においてタイムスタンプを補正することにより、タイムスタンプを用いた正常な受信処理が可能となる。
なお、うるう秒調整時刻より十分前から復号処理を継続する受信装置は、タイムスタンプを用いない復号処理及び提示処理が可能となる場合もあるが、うるう秒調整時刻直前で選局した受信装置は、タイムスタンプを決定できず、うるう秒調整が終了した後でなければ、提示できない場合がある。その場合であっても、本実施の形態における補正方法を用いることによりタイムスタンプを用いた受信処理が可能となり、うるう秒調整時刻の直前でも選局が可能となる。
図８４で説明した、送信側（送信装置）においてＭＰＵタイムスタンプを補正する場合の、送信側（送信装置）の動作フローを図８６に、受信装置の動作フローを図８７に示す。
まず、送信側（送信装置）の動作フローについて、図８６を用いて説明する。
うるう秒の挿入や削除が行われる場合、ＭＰＵタイムスタンプの付与のタイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかを判定する（Ｓ２２０１）。なお、うるう秒の挿入や削除が行われない場合については、図示しない。
ここで、Ａ領域～Ｄ領域は、以下のように定義される。
Ａ領域：うるう秒挿入の直前までの時刻（１回目の８：５９：５９台まで）
Ｂ領域：うるう秒挿入以後の時刻（２回目の８：５９：５９以降）
Ｃ領域：うるう秒削除の直前までの時刻（９：００：００まで）
Ｄ領域：うるう秒削除以後の時刻（９：時００：００以降）
ステップＳ２２０１において、Ａ領域であると判定された場合であって、ＭＰＵタイムスタンプが９：００：００以降を示す場合は、ＭＰＵタイムスタンプを－１秒補正し、補正したＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する（Ｓ２２０２）。
そして、ＭＰＵタイムスタンプを補正したことを示す補正情報をシグナリングし、受信装置に送信する（Ｓ２２０３）。
また、ステップＳ２２０１において、Ｃ領域であると判定された場合であって、ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプを＋１秒補正し、補正したＭＰＵタイムスタンプをＭＰＵタイムスタンプ記述子に格納する（Ｓ２２０５）。
また、ステップＳ２２０１において、Ｂ領域またはＤ領域であると判定された場合、ＭＰＵタイムスタンプを補正せずにＭＰＵタイムスタンプ記述子に格納する（Ｓ２２０４）。
次に、受信装置の動作フローについて、図８７を用いて説明する。
送信側からシグナリングされた情報に基づいて、ＭＰＵタイムスタンプが補正されているか否かを判定する（Ｓ２３０１）。
ＭＰＵタイムスタンプが補正されていると判定された場合（Ｓ２３０１でＹｅｓ）は、受信装置においてうるう秒調整が実施された後のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する（Ｓ２３０２）。
ＭＰＵタイムスタンプが補正されていないと判定された場合（Ｓ２３０１でＮｏ）は、ＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
なお、ＭＰＵタイムスタンプを補正する場合は、当該ＭＰＵタイムスタンプに対応するＭＰＵをうるう秒が挿入される区間に提示する。
反対に、ＭＰＵタイムスタンプを補正しない場合は、当該ＭＰＵタイムスタンプに対応するＭＰＵを、うるう秒が挿入される区間に提示することはなく、うるう秒が挿入されない区間に提示する。
図８５で説明した、受信装置においてＭＰＵタイムスタンプを補正する場合の、送信側の動作フローを図８８に、受信装置の動作フローを図８９に示す。
まず、送信側（送信装置）の動作フローについて、図８８を用いて説明する。
ＮＴＰパケットのｌｅａｐ＿ｉｎｄｉｃａｔｏｒに基づいて、うるう秒の調整（挿入や削除）が行われかを判定する（Ｓ２４０１）。
うるう秒の調整が行われると判定された場合（Ｓ２４０１でＹｅｓ）、ＭＰＵタイムスタンプの付与のタイミングを判定し、識別情報をシグナリングし、受信装置に送信する（Ｓ２４０２）。
一方、うるう秒の調整が行われないと判定された場合（Ｓ２０４１でＮｏ）、通常動作のまま処理を終了する。
次に、受信装置の動作フローについて、図８９を用いて説明する。
送信側（送信装置）によりシグナリングされた識別情報に基づいて、ＭＰＵタイムスタンプの付与のタイミングがＡ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかを判定する（Ｓ２５０１）。ここで、Ａ領域～Ｄ領域は、上記で定義したものと同じであるため説明を省略する。なお、図８７と同様に、うるう秒の挿入や削除が行われない場合については、図示しない。
ステップＳ２５０１において、Ａ領域であると判定された場合であって、ＭＰＵタイムスタンプが９：００：００以降を示す場合は、ＭＰＵタイムスタンプを－１秒補正する（Ｓ２５０２）。
ステップＳ２５０１において、Ｃ領域であると判定された場合であって、ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、ＭＰＵタイムスタンプを＋１秒補正する（Ｓ２５０４）。
ステップＳ２５０１において、Ｂ領域またはＤ領域であると判定された場合、ＭＰＵタイムスタンプを補正しない（Ｓ２５０３）。
受信装置は、さらに、図示しない処理において、補正されたＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
なお、ＭＰＵタイムスタンプを補正する場合は、うるう秒調整が実施された後のＮＴＰ時刻におけるＭＰＵタイムスタンプに基づいて、当該ＭＰＵタイムスタンプに対応するＭＰＵを提示する。
反対に、ＭＰＵタイムスタンプを補正しない場合は、当該ＭＰＵタイムスタンプに対応するＭＰＵを、うるう秒が挿入される区間に提示することはなく、うるう秒が挿入されない区間に提示する。
要するに、送信側（送信装置）は、複数のＭＰＵのそれぞれについて、当該ＭＰＵに対応するＭＰＵタイムスタンプを付与するタイミングを判定する。そして、判定の結果、当該タイミングがうるう秒挿入の直前までの時刻の場合であって、当該ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを－１秒補正する。また、ＭＰＵタイムスタンプを補正したことを示す補正情報をシグナリングし、受信装置に送信する。また、判定の結果、当該タイミングがうるう秒削除の直前までの時刻の場合であって、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。
また、受信装置は、送信側（送信装置）によりシグナリングされた補正情報により示されるＭＰＵタイムスタンプが補正されているか否かに基づいて、ＭＰＵタイムスタンプが補正されていることが示される場合には、うるう秒調整が実施された後のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。ＭＰＵタイムスタンプが補正されていない場合は、うるう秒調整前のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
また、送信側（送信装置）は、複数のＭＰＵのそれぞれについて、当該ＭＰＵに対応するＭＰＵタイムスタンプを付与するタイミングを判定し、判定した結果をシグナリングする。受信装置はｌ、送信側によりシグナリングされた、ＭＰＵタイムスタンプを付与するタイミングを示す情報に基づき、以下の処理を行う。具体的には、当該タイミングを示す情報がうるう秒挿入の直前までの時刻であることを示す場合であって、ＭＰＵタイムスタンプが９：００：００以降を示す場合は、当該ＭＰＵタイムスタンプを－１秒補正する。また、当該タイミングを示す情報がうるう秒削除の直前までの時刻の場合であって、当該ＭＰＵタイムスタンプが８：５９：５９以降を示す場合は、当該ＭＰＵタイムスタンプを＋１秒補正する。
受信装置は、ＭＰＵタイムスタンプが補正されている場合には、うるう秒調整が実施された後のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。ＭＰＵタイムスタンプが補正されていない場合は、うるう秒調整前のＮＴＰ時刻における当該ＭＰＵタイムスタンプに基づいてＭＰＵを提示する。
このように、うるう秒調整における、ＭＰＵタイムスタンプの付与のタイミングを判定することにより、ＭＰＵタイムスタンプの補正が可能となり、受信装置は、どのＭＰＵを提示すべきかの判断ができ、ＭＰＵタイムスタンプ記述子やＭＰＵ拡張タイムスタンプ記述子を用いた適切な受信処理が可能となる。つまり、ＮＴＰ時刻にうるう秒調整が行われた場合であっても、受信装置において、ＭＰＵタイムスタンプ記述子に格納されているＭＰＵタイムスタンプを用いて正常なＭＰＵの提示が可能となる。
［補足：送信装置及び受信装置］
以上のように、符号化ストリームを構成するデータをＭＰＵに格納して送信する送信装置は、図９０のように構成することも可能である。また、符号化ストリームを構成するデータが格納されたＭＰＵを受信する受信装置は、図９１のように構成することも可能である。図９０は、送信装置の具体的構成の例を示す図である。図９１は、受信装置の具体的構成の例を示す図である。
送信装置９００は、生成部９０１と、送信部９０２とを備える。生成部９０１及び送信部９０２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置１０００は、受信部１００１と、再生部１００２とを備える。受信部１００１及び再生部１００２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置９００及び受信装置１０００の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法については、図９２を用いて説明する。図９２は、送信装置による動作フロー（送信方法）である。
まず、送信装置９００の生成部９０１は、外部から受信した基準時刻情報としてのＮＴＰ時刻に基づいて、所定のデータユニットとしてのＭＰＵの提示時刻を示す提示時刻情報（ＭＰＵタイムスタンプ）を生成する（Ｓ２６０１）。
次に、送信装置９００の送信部９０２は、ＭＰＵと、生成部９０１により生成された提示時刻情報と、当該提示時刻情報（ＭＰＵタイムスタンプ）がうるう秒調整前のＮＴＰ時刻に基づいて生成されたか否かを示す識別情報とを送信する（Ｓ２６０２）。
これにより、送信装置９００から送信された情報を受信した受信装置は、うるう秒調整が行われた場合であっても、識別情報に基づいてＭＰＵを再生できるので、ＭＰＵを意図された時刻に再生できる。
次に、受信方法について図９３を用いて説明する。図９３は、受信装置による動作フロー（受信方法）である。
まず、受信装置１０００の受信部１００１は、ＭＰＵと、ＭＰＵの提示時刻を示す提示時刻情報と、当該提示時刻情報（ＭＰＵタイムスタンプ）がうるう秒調整前のＮＴＰ時刻に基づいて生成されたか否かを示す識別情報とを、受信する（Ｓ２７０１）。
次に、受信装置１０００の再生部１００２は、受信部１００１により受信された提示時刻情報（ＭＰＵタイムスタンプ）及び識別情報に基づいて、受信部１００１により受信されたＭＰＵを再生する（Ｓ２７０２）。
これにより、受信装置１０００は、うるう秒調整が行われた場合であっても、ＭＰＵを意図された時刻に再生できる。
なお、実施の形態６において、再生とは、復号及び提示の少なくとも一方の処理を含む処理を示す。
（実施の形態６の変形例）
次に、図８４及び図８５で説明した、付加情報（識別情報）の具体的なシグナリング方法の具体例について説明する。
ここでは、図８１の（ａ）に示すＭＰＵタイムスタンプ記述子と、図８１の（ｂ）に示すＭＰＵ拡張タイムスタンプ記述子との組み合わせでシグナリングする方法について説明する。
図９４は、ＭＰＵ拡張タイムスタンプ記述子の拡張例を示す図である。図９４の下線で示したフィールドは、図８１の（ｂ）で示したＭＰＵ拡張タイムスタンプ記述子に対して新規に追加するフィールドである。
図９４におけるＮＴＰ＿ｌｅａｐ＿ｉｎｄｉｃａｔｏｒは、第２制御情報としてのＭＰＵ拡張タイムスタンプ記述子に、ＮＴＰのうるう秒調整に係る付加情報（識別情報）を示すか否かのフラグを示す。このフラグが立っている場合、複数のＭＰＵ毎のループ内におけるｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｔｙｐｅが有効となる。
図９４におけるｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｔｙｐｅは、図８４で説明したようなＭＰＵタイムスタンプの補正を送信側（送信装置）において行う場合、ＭＰＵタイムスタンプスタンプ記述子に記載される同一シーケンス番号のｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅが、補正されているかどうかを示す。また、ｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｔｙｐｅは、図８５で説明したようなＭＰＵタイムスタンプの補正を受信装置において行う場合、ＭＰＵタイムスタンプスタンプ記述子に記載される同一シーケンス番号のｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅが付与されるタイミングが、Ａ領域であるか、Ｂ領域であるか、Ｃ領域であるか、Ｄ領域であるかを示す。
つまり、ＭＰＵ拡張タイムスタンプ記述子は、ＭＰＵタイムスタンプがうるう秒調整前の時刻情報（ＮＴＰ時刻）に基づいて生成されたか否かを示す識別情報が格納されている。また、ＭＰＵ拡張タイムスタンプ記述子は、複数のＭＰＵのそれぞれのループにおいて、当該ＭＰＵに対応する識別情報を格納している。
送信装置９００の送信部９０２は、上記ステップＳ２６０２において、ＭＰＵと、生成部９０１により生成された提示時刻情報（ＭＰＵタイムスタンプ）が格納された第１制御情報としてのＭＰＵタイムスタンプ記述子と、当該提示時刻情報がうるう秒調整前の時刻情報（ＮＴＰ時刻）に基づいて生成されたか否かを示す識別情報が格納された第２制御情報としてのＭＰＵ拡張タイムスタンプ記述子と、を送信する。
受信装置１０００の受信部１００１は、ステップＳ２７０１において、ＭＰＵと、ＭＰＵタイムスタンプ記述子と、ＭＰＵ拡張タイムスタンプ記述子とを受信する。そして、受信装置１０００の再生部１００２は、受信部１００１により受信されたＭＰＵタイムスタンプ記述子及びＭＰＵ拡張タイムスタンプ記述子に基づいて、受信部１００１により受信されたＭＰＵを再生する。このように、受信装置１０００は、ＭＰＵタイムスタンプ記述子とＭＰＵ拡張タイムスタンプ記述子との両方を解析することで、うるう秒調整時、ＭＰＵタイムスタンプを用いた復号処理が可能となる。よって、受信装置１０００は、うるう秒調整が行われた場合であっても、ＭＰＵを意図された時刻に再生できる。また、ＭＰＵ拡張タイムスタンプ記述子に識別情報を格納しているため、ＭＰＵタイムスタンプ記述子を既存規格（ＭＰＥＧ）に対応した構成のまま、ＭＰＵタイムスタンプがうるう秒調整前の時刻情報（ＮＴＰ時刻）に基づいて生成されたか否かをシグナリングする機能を拡張できる。このように、従来の構成を利用できるため、シグナリングする機能を拡張した場合であっても、設計変更を最小限にでき、送信側（送信装置）および受信装置の製造コストを低減することができる。
なお、ＮＴＰ＿ｌｅａｐ＿ｉｎｄｉｃａｔｏｒを立てるタイミングは、ＮＴＰパケットにおけるｌｅａｐ＿ｉｎｄｉｃａｔｏｒと同じでもよいし、ｌｅａｐ＿ｉｎｄｉｃａｔｏｒが立っている間における任意の時間としてもよい。つまり、ＮＴＰ＿ｌｅａｐ＿ｉｎｄｉｃａｔｏｒは、ＭＰＵタイムスタンプが生成された基準となるＮＴＰ時刻に対応するＮＴＰパケットにおけるｌｅａｐ＿ｉｎｄｉｃａｔｏｒの値に応じた値に決定される。
（実施の形態６の変形例２）
本実施の形態において説明した、うるう秒調整に係る課題は、ＮＴＰ時刻に基づいた時刻を用いる場合に限らずに、ＵＴＣ時刻に基づいた時刻を用いる場合であっても、同様に発生する課題である。
時刻系が、ＵＴＣに基づいた時刻系であり、その時刻系に基づいて提示時刻情報（ＭＰＵタイムスタンプ）を生成し、付与する場合には、これまでに示した方法と同様の方法を用いることにより、うるう秒調整時にも、受信装置側で提示時刻情報及びシグナリング情報（付加情報、識別情報）を用いて、提示時刻情報を補正し、処理することが可能である。
例えば、ＡＲＩＢ ＳＴＤ－Ｂ６０において、受信機で動作しているアプリケーションに対して、放送局から動作を指定する時刻（時刻指定情報）を通知する目的として、イベントメッセージを伝送する際、イベントメッセージ記述子をＭＭＴＰパケットに格納し、イベントメッセージ記述子においてイベントメッセージの発生する時刻が示されている。この場合、アプリケーションを構成するデータは、所定のデータユニットとしてのＭＰＵに格納して送信される。イベントメッセージの発生する時刻については、複数の時刻の指定方法があり、ｔｉｍｅ＿ｍｏｄｅで示される。ｔｉｍｅ＿ｍｏｄｅにおいて、イベントメッセージの発生する時刻をＵＴＣで表現する場合、そのＵＴＣ時刻が、うるう秒調整前の時刻情報に基づいて付与された時刻情報か、うるう秒調整後の時刻情報に基づいて付与された時刻情報かを示す識別情報をシグナリングする。つまり、識別情報は、本実施の形態で説明した識別情報と同様に、提示時刻情報がうるう秒調整前の時刻情報（ＮＴＰ時刻）に基づいて生成されたか否かを示す情報である。このような識別情報（シグナリング情報）は、イベントメッセージ記述子内に示すことが望ましい。例えば、イベントメッセージ記述子のｒｅｓｅｒｖｅｄ＿ｆｕｔｕｒｅ＿ｕｓｅフィールドを用いてシグナリングすることができる。
つまり、送信装置９００の生成部９０１は、上記ステップＳ２６０１において、外部から受信した基準時刻情報としてのＮＴＰ時刻に基づいて、アプリケーションの動作時刻を示す時刻指定情報を生成する。そして、送信装置９００の送信部９０２は、上記ステップＳ２６０２において、ＭＰＵと、生成部９０１により生成された、アプリケーションの動作時刻（イベントメッセージの発生する時刻）を示す時刻指定情報と、当該時刻情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とが格納された制御情報としてのイベントメッセージ記述子と、を送信する。
なお、送信側（送信装置）において、うるう秒調整の必要な時間帯や番組を判定し、うるう秒調整が必要な時間帯や番組では、ＵＴＣで表現するｔｉｍｅ＿ｍｏｄｅの使用を禁止し、ＵＴＣに係らないｔｉｍｅ＿ｍｏｄｅを使用すると規定してもよい。
或いは、送信側（送信装置）において、イベントメッセージの発生するＵＴＣ時刻を算出し、イベントメッセージを発生させる時刻がうるう秒調整後であるかどうかを判定し、うるう秒調整後の場合には、うるう秒調整後のＵＴＣ時刻を算出してイベントメッセージ記述子に格納してもよい。また、提示時刻情報がうるう秒調整されたかどうかを別途シグナリングしてもよい。
同様に、ＵＴＣ（Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ Ｃｏｏｒｄｉｎａｔｅｄ）－ＮＰＴ（Ｎｏｒｍａｌ Ｐｌａｙ Ｔｉｍｅ）参照記述子は、ＵＴＣとＮＰＴとの関係を、ＵＴＣ＿Ｒｅｆｅｒｅｎｃｅフィールド及びＮＰＴ＿Ｒｅｆｅｒｅｎｃｅフィールドを用いて示す。ＵＴＣ＿ＲｅｆｅｒｅｎｃｅフィールドまたはＮＰＴ＿Ｒｅｆｅｒｅｎｃｅフィールドに示す時刻情報が、うるう秒調整前の基準時刻情報（ＮＴＰ時刻）に基づいて付与された時刻情報か、うるう秒調整後の基準時刻情報に基づいて付与された時刻情報かをシグナリングする。つまり、ＵＴＣ－ＮＰＴ参照記述子は、送信装置９００の生成部９０１により生成された提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報（ＮＴＰ時刻）か否かを示す識別情報とを格納している制御情報である。識別情報は、ＵＴＣ－ＮＰＴ参照記述子内のｒｅｓｅｒｖｅｄフィールド等を用いてシグナリングすることができる。
また、ＡＲＩＢ ＳＴＤ－Ｂ６０或いはＡＲＩＢ ＳＴＤ－Ｂ６２に記載される字幕或いは文字スーパーの提示時刻の指定方法は、付加識別情報（Ａｄｄｉｔｉｏｎａｌ＿Ａｒｉｂ＿Ｓｕｂｔｉｔｌｅ＿Ｉｎｆｏ）におけるＴＭＤ（時刻制御モード）で示される。付加識別情報は、ＭＰＴのアセットループに格納される。
ＴＭＤ（時刻制御モード）がＭＰＵタイムスタンプやＮＰＴ（Ｎｏｒｍａｌ Ｐｌａｙ
Ｔｉｍｅ）を起点とした時刻であるモードの場合には、字幕或いは文字スーパーの提示時刻は、ＭＰＵ拡張タイムスタンプ記述子或いはＵＴＣ－ＮＰＴ参照記述子に示される。上記シグナリング情報により、うるう秒調整時にも、受信装置側で時刻情報及びシグナリング情報を用いて、時刻情報を補正し、処理することが可能である。
時刻制御モード＝’００００’（ＵＴＣ＿ＴＴＭＬ記述）である場合は、ＡＲＩＢ－ＴＴＭＬ字幕内のタイムコードをＵＴＣに対応した提示時刻を示す。この場合は、当該タイムコードに示されるＵＴＣ時刻が、うるう秒調整前の時刻情報に基づいて付与された時刻情報か、うるう秒調整後の時刻情報に基づいて付与された時刻情報かをシグナリングする。このとき送信されるシグナリング情報は、ＡＲＩＢ－ＴＴＭＬ字幕内に示すことが望ましい。
時刻制御モード＝’００１０’（ＵＴＣ＿ＴＴＭＬ記述）である場合は、付加識別情報におけるｒｅｆｅｒｅｎｃｅ＿ｓｔａｒｔ＿ｔｉｍｅフィールドに示されるＵＴＣ時刻を起点とした時刻である。この場合は、付加識別情報内において、時刻制御モード＝’００００’（ＵＴＣ＿ＴＴＭＬ記述）である場合と同様にシグナリングする。この場合、送信側（送信装置）では、ｒｅｆｅｒｅｎｃｅ＿ｓｔａｒｔ＿ｔｉｍｅフィールドに示されるＵＴＣ時刻が、うるう秒調整が行われる直前の時刻（例えば、９：００：００までの時刻）よりも予め定められた期間（例えば２４時間）前の時刻（つまり、うるう秒調整が行われる前日の９：００：００）から当該直前の時刻までにおける時刻であるか否かを示す情報を識別情報として送信する。
なお、送信側（送信装置）において、うるう秒調整の必要な時間帯や番組を判定し、ＵＴＣで表現する時刻制御モードの使用を禁止し、ＵＴＣに係らない時刻制御モードを使用すると規定してもよい。
その他、ＭＨ－Ｅｘｐｉｒｅ記述子についても同様である。
（実施の形態７）
一般的な放送局設備は、複数の送出系統を有しており、１系統を通常設備として実際の放送サービスに、それ以外を冗長系設備としてバックアップ用に運用している。これにより、送出設備等の原因により、視聴者に提供するサービスにエラーが起こった場合などに、冗長系設備に切り替えることができる。ここで、ＭＭＴ／ＴＬＶ方式では、冗長系設備の切り替え時に、下記の現象が生じる。
１．ＭＰＵシーケンス番号の調整
冗長系設備を切り替える前処理として、ＭＰＵシーケンス番号の調整が実施される。図９５に示すように、ＭＰＵシーケンス番号の調整が実施された場合、調整前と調整後とで、ＭＰＵシーケンス番号に不連続が生じる場合がある。図９５では、ＭＰＵシーケンス番号が重複する例を示す。
アクセスユニットや、アクセスユニットに対するＭＰＵタイムスタンプは、ＭＰＵシーケンス番号の調整前及び調整後で、同じであるが、異なるＭＰＵに対して同一のＭＰＵシーケンス番号が付与されていることにより、２つのＭＰＵに渡って、同一のＭＰＵシーケンス番号が付与される。
これにより、ＭＭＴＰパケットヘッダに格納されるＭＰＵシーケンス番号と、ＭＰＵタイムスタンプ記述子及びＭＰＵ拡張タイムスタンプ記述子に格納されるＭＰＵシーケンス番号とが、異なるＭＰＵで重複する。また、同様に、ＭＰＵシーケンス番号がスキップしたり、戻ったりする場合もある。
２．パケットシーケンス番号の不連続
通常設備と冗長系設備との間で、パケットシーケンス番号やパケットカウンタが異なっているために、通常設備から冗長系設備に切り替える際、パケットシーケンス番号やパケットカウンタが不連続になる場合がある。図９６に示すように、通常動作ではパケットシーケンス番号は連続しているのに対して、スキップ、重複、戻る場合がある。なお、図９６は、通常設備から冗長系設備に切り替えるタイミングで、パケットシーケンス番号が不連続になる場合について説明するための図である。
上記、１または２のようにＭＰＵシーケンス番号やパケットシーケンス番号が不連続になる場合、これらのシーケンス番号の連続性を信じて動作する受信装置は誤動作するおそれがあるという課題がある。
なお、アクセスユニット、及び、アクセスユニットに対するＭＰＵタイムスタンプは、ＭＰＵシーケンス番号やパケットシーケンス番号の不連続が生じる場合においても、連続性は保たれており、連続なデータが受信装置に送出される。
図９５及び図９６を用いて説明したようなＭＰＵシーケンス番号やパケットシーケンス番号の不連続が起こった場合の受信処理について説明する。
ＭＰＵシーケンス番号やパケットシーケンス番号の不連続が生じる場合、下記に示すようなＭＰＵシーケンス番号やパケットシーケンス番号を用いる処理を行う受信装置は誤動作する可能性がある。
ＭＰＵシーケンス番号を用いる処理としては、例えば、ＭＭＴＰパケットヘッダにおけるＭＰＵシーケンス番号の切り替わりによってＭＰＵ境界を検出する処理がある。
また、ＭＰＵシーケンス番号を用いる処理としては、例えば、ＭＰＵタイムスタンプ記述子やＭＰＵ拡張タイムスタンプ記述子には、ＭＰＵシーケンス番号に対するタイムスタンプが記載されており、当該タイムスタンプを用いて復号及び／又は提示する。
パケットシーケンス番号を用いる処理としては、例えば、パケットシーケンス番号をパケットロスの検出に用い、パケットシーケンス番号がスキップした場合にパケットロスと判定し、パケットシーケンス番号が戻った場合にパケットの入れ替わりと判定する処理がある。
これらのＭＰＵシーケンス番号やパケットシーケンス番号を用いる処理を行うことによる誤動作を防ぐために、受信装置は、ＭＰＵシーケンス番号やパケットシーケンス番号の不連続を判定し、不連続と判定した場合には、ＭＰＵシーケンス番号やパケットシーケンス番号を用いない処理を実施する。
ここで、ＭＰＵシーケンス番号やパケットシーケンス番号の不連続の判定方法として、例えば、下記の方法を用いることができる。
まず、上記判定方法の１つは、冗長系設備に切り替えることを示す付加情報をシグナリングすることが考えられる。これにより、受信装置は、付加情報に基づいてＭＰＵシーケンス番号やパケットシーケンス番号を用いない受信処理を行うことができる。
付加情報をシグナリングする方法としては、制御メッセージや記述子、テーブル、ＭＰＵメタデータ、ＭＦメタデータ、ＭＭＴＰパケットヘッダ、ＭＭＴＰパケットの拡張ヘッダなどに当該付加情報を格納して伝送する方法がある。
次に、受信装置において、他の情報を用いて不連続を検出する方法について説明する。
例えば、ＭＰＵ境界を示す情報として、ＭＭＴＰペイロードヘッダにおけるＭＰＵシーケンス番号の切り替わりを検出する方法と、ＭＭＴＰパケットヘッダにおいてランダムアクセスポイントであるか否かを示すフラグであるＲＡＰ＿ｆｌａｇを用いる方法とがある。他にも、Ｓａｍｐｌｅ＿ｎｕｍｂｅｒが０となるパケットの切り替わりや、フラグメントタイプの切り替わりなどでもＭＰＵ境界を検出することが可能である。また、アクセスユニットの数を数えてＭＰＵ境界を検出することもできる。
ここで、冗長系設備の切り替えが実施される可能性がある場合には、ＭＰＵシーケンス番号の切り替わりを用いたＭＰＵ境界を判定せず、その他の方法を用いてＭＰＵ境界を判定する。例えば、ＲＡＰ＿ｆｌａｇが１であるパケットは、ＭＰＵにおける先頭のパケットと判定する。ここで、ＭＰＵ境界の後のパケットのＭＰＵシーケンス番号が前のパケットのＭＰＵシーケンス番号と変わらない場合、ＭＭＴＰパケットにおいてＭＰＵシーケンス番号の重複が生じたと判定する。
或いは、ＲＡＰ＿ｆｌａｇが１であるパケットは、ＭＰＵにおける先頭のパケットと判定する。ここで、先頭のパケットと判定されたパケットのＭＰＵシーケンス番号がその前のパケットのＭＰＵシーケンス番号からスキップ或いは戻った場合、ＭＭＴＰパケットにおいてＭＰＵシーケンス番号の不連続が生じたと判定する。
なお、ＭＭＴＰペイロードヘッダにおけるＭＰＵシーケンス番号の不連続が、ＭＰＵタイムスタンプ記述子やＭＰＵ拡張タイムスタンプ記述子におけるＭＰＵシーケンス番号やパケットシーケンス番号の不連続より必ず前に生じる場合は、当該判定結果に基づいて、タイムスタンプを用いない受信処理やパケットシーケンス番号を用いない処理を実施してもよい。
また、映像パケットのＭＭＴＰペイロードヘッダにおけるＭＰＵシーケンス番号の不連続が、音声パケットのＭＭＴＰペイロードヘッダにおけるＭＰＵシーケンス番号の不連続や、音声のＭＰＵタイムスタンプ記述子やＭＰＵ拡張タイムスタンプ記述子におけるＭＰＵシーケンス番号やパケットシーケンス番号の不連続より、必ず前に生じる場合には、映像パケットのＭＰＵシーケンス番号の不連続の検出結果に基づいて、音声のタイムスタンプを用いない受信処理やパケットシーケンス番号を用いない処理を実施してもよい。当該判定結果を、冗長系設備への切り替えが開始するタイミングと判定してもよい。
なお、受信装置は、冗長系設備に切り替えることを示す付加情報をシグナリングする方法を用いて、冗長系設備に切り替えることを示す付加情報が示される場合のみ、ＭＰＵシーケンス番号やパケットシーケンス番号を用いない処理をしてもよい。
なお、受信装置は、冗長系設備に切り替えることを示す付加情報をシグナリングする方法を用いて冗長系設備に切り替えることを示す付加情報が示される場合のみ、ＲＡＰ＿ｆｌａｇなどとＭＰＵシーケンス番号の不連続の検出処理を実施してもよい。
ここで、受信装置におけるタイムスタンプ記述子を用いた判定について説明する。通常、ＭＰＵシーケンス番号に対するタイムスタンプが記載され、複数回伝送されることが多いが、ＭＰＵシーケンス番号が同じであるにも関わらず、タイムスタンプ値が更新された場合、受信装置は、ＭＰＵシーケンス番号が重複したと判定する。
また、タイムスタンプ値が１つのＭＰＵのプレゼンテーション時間分更新されたにもかかわらず、ＭＰＵシーケンス番号が２以上更新されるなど、タイムスタンプ値とＭＰＵシーケンス番号との関係が対応していない場合、受信装置は、ＭＰＵシーケンス番号の不連続が生じたと判定する。
なお、ＭＰＵタイムスタンプやＭＰＵ拡張タイムスタンプの更新時には、ＭＰテーブルにおけるｖｅｒｓｉｏｎを更新しないとしてもよい。また、別途ｖｅｒｓｉｏｎ情報を定義し、タイムスタンプ情報のｖｅｒｓｉｏｎと、タイムスタンプ情報以外の情報のｖｅｒｓｉｏｎとを分けて送信してもよい。これにより、タイムスタンプ情報以外の情報のｖｅｒｓｉｏｎ頻度を低減でき、受信処理を軽減できる。
なお、ＭＰＵシーケンス番号の不連続が生じる場合には、ＭＰＵタイムスタンプとタイムスタンプ情報との関係が信用できない。そのため、タイムスタンプ情報が信用できない情報であることを記述子にシグナリングしてもよい。例えば、図９４で説明したＮＴＰ＿ｌｅａｐ＿ｉｎｄｉｃａｔｏｒやｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｔｙｐｅと同様のフィールドを用いて、ＭＰＵタイムスタンプを付与するタイミングが冗長系切り替え前後のタイミングであり、タイムスタンプが信用できないことを示してもよい。また、ＭＰＵタイムスタンプ記述子と併用して使用することを前提として、ＭＰＵ拡張タイムスタンプ記述子に示してもよい。
以上の方法を用いて、受信装置において、ＭＰＵシーケンス番号や、パケットシーケンス番号の不連続が生じると判定することにより、ＭＰＵシーケンス番号やパケットシーケンス番号を用いない処理が可能となり、同期再生における誤動作を防ぐことが可能となる。 以上のように説明したようなＭＰＵシーケンス番号やパケットシーケンス番号の不連続が起こった場合の受信装置の動作フローについて説明する。図９７は、ＭＰＵシーケンス番号やパケットシーケンス番号の不連続が起こった場合の受信装置による動作フローである。
受信装置では、ＭＭＴＰパケットにおけるパケットヘッダ或いはペイロードヘッダなどから、ＭＰＵ境界を判定する。具体的には、ＲＡＰ＿ｆｌａｇが１となるパケットをＭＰＵ先頭のパケットであると判定することで、ＭＰＵ境界を判定する。さらに、ＭＰＵシーケンス番号を判定し、前のパケットのＭＰＵシーケンス番号から１増加しているか否かを判定する（Ｓ２８０１）。
ＲＡＰ＿ｆｌａｇが１であり、かつ、ＭＰＵシーケンス番号が１増加したと判定した場合（Ｓ２８０１でＹｅｓ）は、ＭＰＵシーケンス番号の不連続は発生していないものとし、ＭＰＵシーケンス番号を用いる受信処理を実施する（Ｓ２８０３）。
一方、ＲＡＰ＿ｆｌａｇが０であるか、ＲＡＰ＿ｆｌａｇが１であっても前のパケットのＭＰＵシーケンス番号から１増加していないと判定した場合（Ｓ２８０１でＮｏ）は、ＭＰＵシーケンス番号の不連続が発生しているものとし、ＭＰＵシーケンス番号を用いない受信処理を実施する（Ｓ２８０２）。
（その他の実施の形態）
以上、実施の形態に係る送信装置、受信装置、送信方法及び受信方法ついて説明したが、本発明は、この実施の形態に限定されるものではない。
また、上記実施の形態に係る送信装置及び受信装置に含まれる各処理部は典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。
また、集積回路化はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、又はＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵ又はプロセッサなどのプログラム実行部が、ハードディスク又は半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
言い換えると、送信装置及び受信装置は、処理回路（ｐｒｏｃｅｓｓｉｎｇ ｃｉｒｃｕｉｔｒｙ）と、当該処理回路に電気的に接続された（当該制御回路からアクセス可能な）記憶装置（ｓｔｏｒａｇｅ）とを備える。処理回路は、専用のハードウェア及びプログラム実行部の少なくとも一方を含む。また、記憶装置は、処理回路がプログラム実行部を含む場合には、当該プログラム実行部により実行されるソフトウェアプログラムを記憶する。処理回路は、記憶装置を用いて、上記実施の形態に係る送信方法又は受信方法を実行する。
さらに、本発明は上記ソフトウェアプログラムであってもよいし、上記プログラムが記録された非一時的なコンピュータ読み取り可能な記録媒体であってもよい。また、上記プログラムは、インターネット等の伝送媒体を介して流通させることができるのは言うまでもない。
また、上記で用いた数字は、全て本発明を具体的に説明するために例示するものであり、本発明は例示された数字に制限されない。
また、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェア又はソフトウェアが並列又は時分割に処理してもよい。
また、上記の送信方法又は受信方法に含まれるステップが実行される順序は、本発明を具体的に説明するために例示するためのものであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時（並列）に実行されてもよい。
以上、本発明の一つ又は複数の態様に係る送信装置、受信装置、送信方法及び受信方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つ又は複数の態様の範囲内に含まれてもよい。
本発明は、ビデオデータ及びオーディオデータなどのメディアトランスポートを行う装置又は機器に適用できる。
１５、１００、３００、５００、７００、９００ 送信装置
１６、１０１、３０１ 符号化部
１７、１０２ 多重化部
１８、１０４ 送信部
２０、２００、４００、６００、８００、１０００ 受信装置
２１ パケットフィルタリング部
２２ 送信順序タイプ判別部
２３ ランダムアクセス部
２４、２１２ 制御情報取得部
２５ データ取得部
２６ 算出部
２７ 初期化情報取得部
２８、２０６ 復号命令部
２９、２０４Ａ、２０４Ｂ、２０４Ｃ、２０４Ｄ、４０２ 復号部
３０ 提示部
２０１ チューナー
２０２ 復調部
２０３ 逆多重化部
２０５ 表示部
２１１ タイプ判別部
２１３ スライス情報取得部
２１４ 復号データ生成部
３０２ 付与部
３０３、５０３、７０２、９０２ 送信部
４０１、６０１、８０１、１００１ 受信部
５０１ 分割部
５０２、６０３ 構成部
６０２ 判定部
７０１、９０１ 生成部
８０２ 第１のバッファ
８０３ 第２のバッファ
８０４ 第３のバッファ
８０５ 第４のバッファ
８０６ 復号部
１００２ 再生部

Claims (4)

  1. アプリケーションを構成するデータを所定のデータユニットに格納して送信する送信方法であって、
    基準時刻情報に基づいて、前記アプリケーションの動作時刻を示す時刻指定情報を生成し、
    （ｉ）前記所定のデータユニットと、（ｉｉ）生成した前記時刻指定情報を示す制御情報とを送信し、
    前記制御情報は、生成した前記時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納しており、
    前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、
    前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）である
    送信方法。
  2. アプリケーションを構成するデータが格納された所定のデータユニットを受信する受信方法であって、
    （ｉ）前記所定のデータユニットと、（ｉｉ）前記アプリケーションの動作時刻を示す時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納している制御情報と、を受信し、
    受信した前記制御情報に基づいて、受信した前記所定のデータユニットに格納されている前記アプリケーションを実行し、
    前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、
    前記時刻指定情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づいて生成される
    受信方法。
  3. アプリケーションを構成するデータを所定のデータユニットに格納して送信する送信装置であって、
    基準時刻情報に基づいて、前記アプリケーションの動作時刻を示す時刻指定情報を生成する生成部と、
    （ｉ）前記所定のデータユニットと、（ｉｉ）前記生成部により生成された前記時刻指定情報を示す制御情報とを送信する送信部と、
    前記制御情報は、前記生成部により生成された前記時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納しており、
    前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、
    前記基準時刻情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）である
    送信装置。
  4. アプリケーションを構成するデータが格納された所定のデータユニットを受信する受信装置であって、
    （ｉ）前記所定のデータユニットと、（ｉｉ）前記アプリケーションの動作時刻を示す時刻指定情報と、当該時刻指定情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とを格納している制御情報と、を受信する受信部と、
    前記受信部により受信された前記制御情報に基づいて、前記受信部により受信された前記所定のデータユニットに格納されている前記アプリケーションを実行し、
    前記識別情報は、前記時刻指定情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたか否かを示し、
    前記時刻指定情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に基づいて生成される
    受信装置。
JP2022032421A 2015-02-18 2022-03-03 送信方法、受信方法、送信装置及び受信装置 Active JP7293433B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2023094389A JP7500833B2 (ja) 2015-02-18 2023-06-07 送信方法、受信方法、送信装置及び受信装置
JP2024091487A JP2024107125A (ja) 2015-02-18 2024-06-05 送信方法、受信方法、送信装置及び受信装置

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201562117610P 2015-02-18 2015-02-18
US62/117,610 2015-02-18
JP2015212363A JP6828991B2 (ja) 2014-12-08 2015-10-28 送信方法、受信方法、送信装置及び受信装置
JP2015212359A JP6765802B2 (ja) 2014-11-20 2015-10-28 送信方法、受信方法、送信装置及び受信装置
JP2015212367A JP6828992B2 (ja) 2015-02-18 2015-10-28 送信方法、受信方法、送信装置及び受信装置
JP2021008216A JP7036956B2 (ja) 2015-02-18 2021-01-21 送信方法、受信方法、送信装置及び受信装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2021008216A Division JP7036956B2 (ja) 2015-02-18 2021-01-21 送信方法、受信方法、送信装置及び受信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023094389A Division JP7500833B2 (ja) 2015-02-18 2023-06-07 送信方法、受信方法、送信装置及び受信装置

Publications (2)

Publication Number Publication Date
JP2022075737A JP2022075737A (ja) 2022-05-18
JP7293433B2 true JP7293433B2 (ja) 2023-06-19

Family

ID=56013521

Family Applications (8)

Application Number Title Priority Date Filing Date
JP2021168095A Active JP7359819B2 (ja) 2014-11-20 2021-10-13 送信方法、受信方法、送信装置及び受信装置
JP2022032421A Active JP7293433B2 (ja) 2015-02-18 2022-03-03 送信方法、受信方法、送信装置及び受信装置
JP2022032362A Active JP7295293B2 (ja) 2014-12-08 2022-03-03 送信方法、受信方法、送信装置及び受信装置
JP2023094389A Active JP7500833B2 (ja) 2015-02-18 2023-06-07 送信方法、受信方法、送信装置及び受信装置
JP2023094763A Active JP7502525B2 (ja) 2014-12-08 2023-06-08 送信方法、受信方法、送信装置及び受信装置
JP2023168720A Active JP7564309B2 (ja) 2014-11-20 2023-09-28 送信方法、受信方法、送信装置及び受信装置
JP2024091487A Pending JP2024107125A (ja) 2015-02-18 2024-06-05 送信方法、受信方法、送信装置及び受信装置
JP2024092321A Pending JP2024116264A (ja) 2014-12-08 2024-06-06 送信方法、受信方法、送信装置及び受信装置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2021168095A Active JP7359819B2 (ja) 2014-11-20 2021-10-13 送信方法、受信方法、送信装置及び受信装置

Family Applications After (6)

Application Number Title Priority Date Filing Date
JP2022032362A Active JP7295293B2 (ja) 2014-12-08 2022-03-03 送信方法、受信方法、送信装置及び受信装置
JP2023094389A Active JP7500833B2 (ja) 2015-02-18 2023-06-07 送信方法、受信方法、送信装置及び受信装置
JP2023094763A Active JP7502525B2 (ja) 2014-12-08 2023-06-08 送信方法、受信方法、送信装置及び受信装置
JP2023168720A Active JP7564309B2 (ja) 2014-11-20 2023-09-28 送信方法、受信方法、送信装置及び受信装置
JP2024091487A Pending JP2024107125A (ja) 2015-02-18 2024-06-05 送信方法、受信方法、送信装置及び受信装置
JP2024092321A Pending JP2024116264A (ja) 2014-12-08 2024-06-06 送信方法、受信方法、送信装置及び受信装置

Country Status (5)

Country Link
US (3) US11323751B2 (ja)
EP (1) EP4277170A3 (ja)
JP (8) JP7359819B2 (ja)
CN (2) CN112135167B (ja)
WO (1) WO2016079946A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10305617B2 (en) * 2015-02-10 2019-05-28 Sony Corporation Transmission apparatus, transmission method, reception apparatus, and reception method
JP6219330B2 (ja) * 2015-03-11 2017-10-25 株式会社東芝 送信システム、多重化装置及びうるう秒補正対応方法
US10523467B2 (en) 2015-04-24 2019-12-31 Sony Corporation Transmission device, transmission method, reception device and reception method
JP6868802B2 (ja) 2015-08-03 2021-05-12 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001308836A (ja) 2000-04-25 2001-11-02 Ntt Communications Kk 通信装置の時計のうるう秒補正方法及び通信装置
JP2002040171A (ja) 2000-07-25 2002-02-06 Seiko Precision Inc 時刻修正機能付き時計装置および時計の時刻修正方法
JP2010272071A (ja) 2009-05-25 2010-12-02 Hitachi Kokusai Electric Inc 端末装置
CN102281114A (zh) 2010-06-10 2011-12-14 郑州威科姆科技股份有限公司 授时时间闰秒处理方法
US20140282791A1 (en) 2013-03-13 2014-09-18 Johannes P. Schmidt Leap second support in content timestamps
JP2018026778A (ja) 2015-04-24 2018-02-15 ソニー株式会社 送信装置、送信方法、受信装置および受信方法

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10303877A (ja) * 1996-09-05 1998-11-13 Matsushita Electric Ind Co Ltd 送信装置と受信装置とこれらを用いた伝送システム及び送信方法と受信方法とこれらを用いた伝送方法
JP2000171576A (ja) * 1998-12-09 2000-06-23 Citizen Watch Co Ltd 電波修正時計
CN100488196C (zh) * 2004-07-02 2009-05-13 大唐电信科技股份有限公司 时间同步网络的组网实现方法
US7447931B1 (en) * 2005-12-09 2008-11-04 Rockwell Automation Technologies, Inc. Step time change compensation in an industrial automation network
JP5114936B2 (ja) * 2006-12-11 2013-01-09 カシオ計算機株式会社 時計装置及び閏秒補正方法
JP2008170228A (ja) * 2007-01-10 2008-07-24 Seiko Epson Corp 時刻修正装置、時刻修正装置付き計時装置及び時刻修正方法
JP2008170229A (ja) * 2007-01-10 2008-07-24 Seiko Epson Corp 時刻修正装置、時刻修正装置付き計時装置及び時刻修正方法
US9112626B2 (en) * 2007-01-31 2015-08-18 International Business Machines Corporation Employing configuration information to determine the role of a server in a coordinated timing network
KR101572875B1 (ko) * 2007-09-21 2015-11-30 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
US20090310593A1 (en) * 2008-06-17 2009-12-17 Qualcomm Incorporated Self-positioning access points
US8792308B2 (en) 2010-03-26 2014-07-29 Citizen Holdings Co., Ltd. Radio-controlled watch
JP5026561B2 (ja) * 2010-06-29 2012-09-12 京楽産業．株式会社 遊技機、主制御基板、周辺基板、遊技機の認証方法及び認証プログラム
JP5582045B2 (ja) * 2011-01-20 2014-09-03 セイコーエプソン株式会社 時刻修正装置、時刻修正装置付き計時装置及び時刻修正方法
JP5578103B2 (ja) * 2011-02-09 2014-08-27 セイコーエプソン株式会社 電子時計及び電子時計の受信制御方法
JP2013055588A (ja) * 2011-09-06 2013-03-21 Japan Radio Co Ltd 時刻制御装置及び時刻制御方法
US8270465B1 (en) * 2011-11-15 2012-09-18 Xw Llc Timing and time information extraction from a phase modulated signal in a radio controlled clock receiver
DE102012206910A1 (de) * 2011-12-06 2013-06-06 Rohde & Schwarz Gmbh & Co. Kg Verfahren und Vorrichtung zur Signalisierung eines Sendezeitpunktes und/oder eines Systemtaktes
US9369976B2 (en) * 2012-06-27 2016-06-14 Qualcomm Incorporated Supporting coordinated universal time in LTE
US9645244B2 (en) * 2012-07-24 2017-05-09 Qualcomm Incorporated UTC time offset estimation at a GNSS receiver
CN102981403B (zh) * 2012-09-26 2014-05-21 广东大普通信技术有限公司 一种时钟闰秒处理方法及其系统
JPWO2015115171A1 (ja) * 2014-01-31 2017-03-23 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
JP5708866B1 (ja) * 2014-04-10 2015-04-30 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US10305617B2 (en) * 2015-02-10 2019-05-28 Sony Corporation Transmission apparatus, transmission method, reception apparatus, and reception method

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001308836A (ja) 2000-04-25 2001-11-02 Ntt Communications Kk 通信装置の時計のうるう秒補正方法及び通信装置
JP2002040171A (ja) 2000-07-25 2002-02-06 Seiko Precision Inc 時刻修正機能付き時計装置および時計の時刻修正方法
JP2010272071A (ja) 2009-05-25 2010-12-02 Hitachi Kokusai Electric Inc 端末装置
CN102281114A (zh) 2010-06-10 2011-12-14 郑州威科姆科技股份有限公司 授时时间闰秒处理方法
US20140282791A1 (en) 2013-03-13 2014-09-18 Johannes P. Schmidt Leap second support in content timestamps
JP2018026778A (ja) 2015-04-24 2018-02-15 ソニー株式会社 送信装置、送信方法、受信装置および受信方法

Also Published As

Publication number Publication date
JP7359819B2 (ja) 2023-10-11
US20240007686A1 (en) 2024-01-04
JP2023111993A (ja) 2023-08-10
CN112135167A (zh) 2020-12-25
WO2016079946A1 (ja) 2016-05-26
US20220224951A1 (en) 2022-07-14
JP2024116264A (ja) 2024-08-27
JP2022075736A (ja) 2022-05-18
CN112135168A (zh) 2020-12-25
JP7564309B2 (ja) 2024-10-08
US11758201B2 (en) 2023-09-12
US20190281328A1 (en) 2019-09-12
EP4277170A2 (en) 2023-11-15
JP7502525B2 (ja) 2024-06-18
JP2024107125A (ja) 2024-08-08
EP4277170A3 (en) 2024-01-17
US11323751B2 (en) 2022-05-03
JP2023111983A (ja) 2023-08-10
JP7295293B2 (ja) 2023-06-20
CN112135167B (zh) 2022-04-01
JP2023165959A (ja) 2023-11-17
JP7500833B2 (ja) 2024-06-17
JP2022075737A (ja) 2022-05-18
CN112135168B (zh) 2022-11-04
US12108092B2 (en) 2024-10-01
JP2022002417A (ja) 2022-01-06

Similar Documents

Publication Publication Date Title
JP6868802B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP7293433B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP7307237B2 (ja) 受信方法、送信方法、受信装置及び送信装置
JP7036956B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP7361287B2 (ja) 送信方法及び送信装置
JP7036957B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP6961772B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP2021122110A (ja) 送信装置、受信装置、送信方法及び受信方法
JP7323684B2 (ja) 送信方法、受信方法、送信装置及び受信装置
WO2016021153A1 (ja) 送信方法、受信方法、送信装置及び受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220303

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230323

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: 20230509

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230607

R150 Certificate of patent or registration of utility model

Ref document number: 7293433

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150