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

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

Info

Publication number
JP2020074599A
JP2020074599A JP2020009501A JP2020009501A JP2020074599A JP 2020074599 A JP2020074599 A JP 2020074599A JP 2020009501 A JP2020009501 A JP 2020009501A JP 2020009501 A JP2020009501 A JP 2020009501A JP 2020074599 A JP2020074599 A JP 2020074599A
Authority
JP
Japan
Prior art keywords
data
unit
information
packet
decoding
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.)
Granted
Application number
JP2020009501A
Other languages
English (en)
Other versions
JP6966581B2 (ja
Inventor
賀敬 井口
Yoshitaka Iguchi
賀敬 井口
遠間　正真
Tadamasa Toma
正真 遠間
加藤　久也
Hisaya Kato
久也 加藤
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
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JP2020074599A publication Critical patent/JP2020074599A/ja
Priority to JP2021172691A priority Critical patent/JP7200329B2/ja
Application granted granted Critical
Publication of JP6966581B2 publication Critical patent/JP6966581B2/ja
Priority to JP2022204630A priority patent/JP7457098B2/ja
Priority to JP2024039924A priority patent/JP2024069470A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • 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/23614—Multiplexing of additional data and video streams
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L19/00—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis
    • G10L19/04—Speech or audio signals analysis-synthesis techniques for redundancy reduction, e.g. in vocoders; Coding or decoding of speech or audio signals, using source filter models or psychoacoustic analysis using predictive techniques
    • G10L19/16—Vocoder architecture
    • G10L19/167—Audio streaming, i.e. formatting and decoding of an encoded audio signal representation into a data stream for transmission or storage purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/188—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a video data packet, e.g. a network abstraction layer [NAL] unit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/38—Transmitter circuitry for the transmission of television signals according to analogue transmission standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/44—Receiver circuitry for the reception of television signals according to analogue transmission standards

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computational Linguistics (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】ＭＰ４フォーマットのファイルの送信における遅延を低減することができる送信方法を提供する。【解決手段】送信方法は、ＭＰ４フォーマットのファイルを構成する、（１）映像信号または音声信号が符号化されたデータであるサンプルデータ、（２）サンプルデータを復号するための第１のメタデータ、及び、（３）サンプルデータの生成後にのみ生成可能なデータを含む、サンプルデータを復号するための第２のメタデータ、のそれぞれをパケット化するパケット化ステップＳ１１と、パケット化された第１のメタデータ、パケット化されたサンプルデータ、及びパケット化された第２のメタデータをこの順に送信する送信ステップＳ１２とを含む。【選択図】図２４

Description

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

Claims (4)

  1. 映像信号を符号化して複数のアクセスユニットを含む符号化データを生成し、
    前記複数のアクセスユニットを、アクセスユニット単位、またはアクセスユニットを分割した単位でパケットに格納してパケット群を生成し、
    前記映像信号を符号化する際の複数のパラメータを前記映像信号が格納されたパケットとは異なる１つのパケットのペイロードに格納し、当該パケットのヘッダには当該ペイロードに格納されるデータを識別するタイプ情報が含まれ、
    生成された前記パケット群をデータとして送信し、
    前記複数のアクセスユニットのうち最初に提示されるアクセスユニットの提示時刻を示す第１の情報と、前記複数のアクセスユニットの復号時刻の算出に用いられる第２の情報と、アクセスユニットの提示順における１つ前に提示されるアクセスユニットとの提示時刻の相対値である第３の情報とを生成し、
    生成された前記第１の情報、前記第２の情報、及び前記第３の情報を送信する
    送信方法。
  2. 複数のアクセスユニットを含む符号化データがアクセスユニット単位またはアクセスユニットを分割した単位でパケット化されたパケット群を受信し、
    前記複数のアクセスユニットのうち最初に提示されるアクセスユニットの提示時刻を示す第１の情報と、前記複数のアクセスユニットの復号時刻の算出に用いられる第２の情報と、アクセスユニットの提示順における１つ前に提示されるアクセスユニットとの提示時刻の相対値である第３の情報とを受信し、
    受信されたパケット群に含まれる前記アクセスユニットを、複数のパラメータを用い、前記第１の情報及び前記第２の情報に基づいて復号し、
    前記パケット群において、前記複数のパラメータは、映像信号が格納されたパケットとは異なる１つのパケットのペイロードに格納され、当該パケットのヘッダには当該ペイロードに格納されるデータを識別するタイプ情報が含まれる
    受信方法。
  3. 映像信号を符号化して複数のアクセスユニットを含む符号化データを生成する符号化部と、
    前記複数のアクセスユニットを、アクセスユニット単位、またはアクセスユニットを分割した単位でパケットに格納してパケット群を生成し、かつ、前記映像信号を符号化する際の複数のパラメータを前記映像信号が格納されたパケットとは異なる１つのパケットのペイロードに格納するパケット生成部と、
    生成された前記パケット群をデータとして送信する第１送信部と、
    前記複数のアクセスユニットのうち最初に提示されるアクセスユニットの提示時刻を示す第１の情報と、前記複数のアクセスユニットの復号時刻の算出に用いられる第２の情報と、アクセスユニットの提示順における１つ前に提示されるアクセスユニットとの提示時刻の相対値である第３の情報とを生成する情報生成部と、
    生成された前記第１の情報及び前記第２の情報を送信する第２送信部とを備え、
    前記１つのパケットのヘッダには前記ペイロードに格納されるデータを識別するタイプ情報が含まれる
    送信装置。
  4. 複数のアクセスユニットを含む符号化データがアクセスユニット単位またはアクセスユニットを分割した単位でパケット化されたパケット群を受信する第１受信部と、
    前記複数のアクセスユニットのうち最初に提示されるアクセスユニットの提示時刻を示す第１の情報と、前記複数のアクセスユニットの復号時刻の算出に用いられる第２の情報と、アクセスユニットの提示順における１つ前に提示されるアクセスユニットとの提示時刻の相対値である第３の情報とを受信する第２受信部と、
    受信されたパケット群に含まれる前記アクセスユニットを、複数のパラメータを用い、前記第１の情報及び前記第２の情報に基づいて復号する復号部とを備え、
    前記パケット群において、前記複数のパラメータは、映像信号が格納されたパケットとは異なる１つのパケットのペイロードに格納され、当該パケットのヘッダには当該ペイロードに格納されるデータを識別するタイプ情報が含まれる
    受信装置。
JP2020009501A 2013-12-16 2020-01-23 送信方法、受信方法、送信装置及び受信装置 Active JP6966581B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2021172691A JP7200329B2 (ja) 2013-12-16 2021-10-21 送信方法、受信方法、送信装置及び受信装置
JP2022204630A JP7457098B2 (ja) 2013-12-16 2022-12-21 送信方法、受信方法、送信装置及び受信装置
JP2024039924A JP2024069470A (ja) 2013-12-16 2024-03-14 送信方法、受信方法、送信装置及び受信装置

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201361916400P 2013-12-16 2013-12-16
US61/916,400 2013-12-16
US201461954871P 2014-03-18 2014-03-18
US61/954,871 2014-03-18
US201461969857P 2014-03-25 2014-03-25
US61/969,857 2014-03-25
US201461979558P 2014-04-15 2014-04-15
US61/979,558 2014-04-15
US201461982938P 2014-04-23 2014-04-23
US61/982,938 2014-04-23
JP2014244503A JP6652320B2 (ja) 2013-12-16 2014-12-02 送信方法、受信方法、送信装置及び受信装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2014244503A Division JP6652320B2 (ja) 2013-12-16 2014-12-02 送信方法、受信方法、送信装置及び受信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2021172691A Division JP7200329B2 (ja) 2013-12-16 2021-10-21 送信方法、受信方法、送信装置及び受信装置

Publications (2)

Publication Number Publication Date
JP2020074599A true JP2020074599A (ja) 2020-05-14
JP6966581B2 JP6966581B2 (ja) 2021-11-17

Family

ID=53531788

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2014244503A Active JP6652320B2 (ja) 2013-12-16 2014-12-02 送信方法、受信方法、送信装置及び受信装置
JP2020009501A Active JP6966581B2 (ja) 2013-12-16 2020-01-23 送信方法、受信方法、送信装置及び受信装置

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2014244503A Active JP6652320B2 (ja) 2013-12-16 2014-12-02 送信方法、受信方法、送信装置及び受信装置

Country Status (4)

Country Link
US (1) US10827208B2 (ja)
EP (1) EP3086558B1 (ja)
JP (2) JP6652320B2 (ja)
CN (1) CN105830450B (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9330101B2 (en) * 2013-12-18 2016-05-03 Microsoft Technology Licensing, Llc Using constraints on media file formats to improve performance
JP2015136058A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
JP2015136059A (ja) 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
JP5886341B2 (ja) 2014-03-07 2016-03-16 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US10887651B2 (en) * 2014-03-31 2021-01-05 Samsung Electronics Co., Ltd. Signaling and operation of an MMTP de-capsulation buffer
US10530828B2 (en) * 2014-03-31 2020-01-07 Samsung Electronics Co., Ltd. Method and apparatus for signaling and operation of low delay consumption of media data in MMT
JP5708866B1 (ja) 2014-04-10 2015-04-30 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
KR20160004858A (ko) * 2014-07-04 2016-01-13 삼성전자주식회사 멀티미디어 통신 시스템에서 패킷 송/수신 장치 및 방법
JP6681580B2 (ja) 2014-08-04 2020-04-15 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
JP6300114B2 (ja) * 2014-08-06 2018-03-28 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
CN104537976B (zh) * 2015-01-16 2018-09-04 北京智谷睿拓技术服务有限公司 时分显示控制方法和装置、显示设备
JP6684433B2 (ja) * 2015-06-26 2020-04-22 ソニー株式会社 送信装置、送信方法、並びに、プログラム
JP2017028463A (ja) * 2015-07-21 2017-02-02 ソニー株式会社 送信装置、および送信方法、受信装置、および受信方法、並びにプログラム
CN108702533B (zh) * 2016-03-09 2021-07-09 索尼公司 发送装置、发送方法、接收装置和接收方法
US10136146B1 (en) * 2016-03-23 2018-11-20 Amazon Technologies, Inc. Metadata optimizations for encoding of media content
GB2558236B (en) 2016-12-22 2021-03-31 Apical Ltd Image data comprising encoded image data and additional data for modification of image
WO2019069710A1 (ja) * 2017-10-05 2019-04-11 ソニー株式会社 符号化装置および方法、復号装置および方法、並びにプログラム
CN114666597A (zh) 2019-03-11 2022-06-24 杜比实验室特许公司 帧速率可伸缩视频编码
EP3939317B1 (en) 2019-03-11 2024-10-23 Dolby Laboratories Licensing Corporation Video coding using reference picture resampling supporting region of interest
JP2022543627A (ja) 2019-08-06 2022-10-13 ドルビー ラボラトリーズ ライセンシング コーポレイション 描画面サイズ拡張可能ビデオコーディング
JP6879344B2 (ja) * 2019-08-22 2021-06-02 三菱電機株式会社 復号装置
CN110798731A (zh) * 2019-11-15 2020-02-14 北京字节跳动网络技术有限公司 视频数据的处理方法、装置、电子设备及计算机可读介质
JP6825075B2 (ja) * 2019-12-27 2021-02-03 三菱電機株式会社 復号装置
EP4162695A4 (en) * 2020-06-09 2023-08-02 Telefonaktiebolaget LM ERICSSON (PUBL) PROVISION OF SEMANTIC INFORMATION WITH ENCODED IMAGE DATA
CN111901694B (zh) * 2020-08-06 2022-08-26 海信电子科技（深圳）有限公司 一种mmtp节目的播放方法及装置
JP7003308B2 (ja) * 2021-01-13 2022-01-20 三菱電機株式会社 復号装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10200854A (ja) * 1997-01-13 1998-07-31 Sony Corp 記録装置、再生装置及び記録再生装置
US20050254526A1 (en) * 2004-05-12 2005-11-17 Nokia Corporation Parameter sets update in streaming applications
WO2012153450A1 (ja) * 2011-05-11 2012-11-15 パナソニック株式会社 動画像送信装置および動画像送信方法

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001144775A (ja) * 1999-11-12 2001-05-25 Matsushita Electric Ind Co Ltd 送信装置およびプログラム記録媒体
US7096481B1 (en) * 2000-01-04 2006-08-22 Emc Corporation Preparation of metadata for splicing of encoded MPEG video and audio
US7039116B1 (en) * 2000-11-07 2006-05-02 Cisco Technology, Inc. Methods and apparatus for embedding and format conversion of compressed video data
US7298741B2 (en) * 2003-02-27 2007-11-20 Sharp Laboratories Of America, Inc. Robust MPEG-2 multiplexing system and method using an adjustable time stamp
JP4182437B2 (ja) * 2004-10-04 2008-11-19 ソニー株式会社 オーディオビデオ同期システム及びモニター装置
US7720096B2 (en) * 2005-10-13 2010-05-18 Microsoft Corporation RTP payload format for VC-1
WO2009003685A1 (en) * 2007-07-02 2009-01-08 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for storing and reading a file having a media data container and a metadata container
US8527663B2 (en) * 2007-12-21 2013-09-03 At&T Intellectual Property I, L.P. Methods and apparatus for performing non-intrusive network layer performance measurement in communication networks
US8966103B2 (en) * 2007-12-21 2015-02-24 General Instrument Corporation Methods and system for processing time-based content
JP5258885B2 (ja) * 2008-07-04 2013-08-07 パナソニック株式会社 符号化ストリーム再生装置及び符号化ストリーム再生方法
JPWO2010044146A1 (ja) * 2008-10-15 2012-03-08 三菱電機株式会社 暗号装置及び復号装置及び暗号方法及び復号方法
US8743906B2 (en) * 2009-01-23 2014-06-03 Akamai Technologies, Inc. Scalable seamless digital video stream splicing
US20110096775A1 (en) * 2009-10-22 2011-04-28 Electronic And Telecommunications Research Institute System and method for multiplexing and streaming contents
US8918533B2 (en) * 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
CN102479530A (zh) * 2010-11-19 2012-05-30 日立民用电子株式会社 拷贝控制方法
US20120219069A1 (en) * 2011-02-28 2012-08-30 Chong Soon Lim Methods and apparatuses for encoding and decoding images of a plurality of views using multiview video coding standard and mpeg-2 video standard
KR101803970B1 (ko) * 2011-03-16 2017-12-28 삼성전자주식회사 컨텐트를 구성하는 장치 및 방법
JP2012244411A (ja) * 2011-05-19 2012-12-10 Sony Corp 画像データ送信装置、画像データ送信方法および画像データ受信装置
US20130195172A1 (en) * 2012-01-30 2013-08-01 Qualcomm Incorporated Method of coding video and storing video content
WO2013140722A1 (ja) * 2012-03-21 2013-09-26 パナソニック株式会社 画像符号化方法、画像復号方法、画像符号化装置、画像復号装置、および画像符号化復号装置
US9813705B2 (en) * 2012-04-26 2017-11-07 Qualcomm Incorporated Parameter set coding
CA3214600A1 (en) * 2012-06-29 2014-01-03 Ge Video Compression, Llc Video data stream concept
KR20150035667A (ko) * 2012-09-28 2015-04-07 삼성전자주식회사 랜덤 액세스를 위한 비디오 부호화 방법 및 장치, 비디오 복호화 방법 및 장치
JP5641090B2 (ja) 2013-03-14 2014-12-17 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
KR101484843B1 (ko) * 2013-04-19 2015-01-20 삼성전자주식회사 멀티미디어 전송 시스템에서 미디어 전송 패킷 전송 방법 및 장치
US20160057494A1 (en) * 2013-06-19 2016-02-25 Lg Electronics Inc. Signal transmitting and receiving device and method of controlling said device
US10070125B2 (en) * 2013-07-31 2018-09-04 Nokia Technologies Oy Method and apparatus for video coding and decoding
WO2015053330A1 (ja) * 2013-10-10 2015-04-16 シャープ株式会社 画像復号装置
KR102246546B1 (ko) * 2013-10-12 2021-04-30 삼성전자주식회사 멀티 레이어 비디오 부호화 방법 및 장치, 멀티 레이어 비디오 복호화 방법 및 장치
EP3080995A4 (en) * 2013-12-15 2017-09-27 LG Electronics Inc. Broadcast transmission device and operating method thereof, and broadcast reception device and operating method thereof
JP6706784B2 (ja) * 2014-09-12 2020-06-10 パナソニックＩｐマネジメント株式会社 送信装置、受信装置、送信方法及び受信方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10200854A (ja) * 1997-01-13 1998-07-31 Sony Corp 記録装置、再生装置及び記録再生装置
US20050254526A1 (en) * 2004-05-12 2005-11-17 Nokia Corporation Parameter sets update in streaming applications
WO2012153450A1 (ja) * 2011-05-11 2012-11-15 パナソニック株式会社 動画像送信装置および動画像送信方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
KWANG-DEOK SEO ET AL.: "A new timing model design for MPEG Media Transport (MMT)", IEEE INTERNATIONAL SYMPOSIUM ON BROADBAND MULTIMEDIA SYSTEMS AND BROADCASTING, JPN6021004343, 27 June 2012 (2012-06-27), pages 1 - 5, XP032222353, ISSN: 0004442817, DOI: 10.1109/BMSB.2012.6264310 *
THOMAS SCHIERL ET AL.: "System Layer Integration of High Efficiency Video Coding", IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, vol. Volume: 22, Issue: 12, Dec. 2012, JPN6021004345, 5 October 2012 (2012-10-05), pages 1871 - 1884, ISSN: 0004442818 *
一般社団法人電波産業会 デジタル放送システム開発部会, 資料UHD作4−2−5 超高精細度テレビジョン放送システムに関する中間報告（多重化方式）, [ONLINE], JPN6015009856, 1 December 2013 (2013-12-01), JP, pages 1 - 60, ISSN: 0004442815 *
青木秀一: "次世代放送システムのメディアトランスポート技術", ＮＨＫ技研Ｒ＆Ｄ, JPN6015009855, 15 July 2013 (2013-07-15), JP, pages 22 - 31, ISSN: 0004442816 *

Also Published As

Publication number Publication date
JP6966581B2 (ja) 2021-11-17
CN105830450A (zh) 2016-08-03
US20160295257A1 (en) 2016-10-06
EP3086558B1 (en) 2020-03-18
CN105830450B (zh) 2020-03-03
JP2015119477A (ja) 2015-06-25
EP3086558A4 (en) 2016-11-23
JP6652320B2 (ja) 2020-02-19
US10827208B2 (en) 2020-11-03
EP3086558A1 (en) 2016-10-26

Similar Documents

Publication Publication Date Title
JP6966581B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP6868838B2 (ja) 送信装置、受信装置、送信方法及び受信方法
JP6846653B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP7200329B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP6846629B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP2023168403A (ja) 送信方法、受信方法、送信装置及び受信装置
JP2023164690A (ja) 送信装置、受信装置、送信方法及び受信方法
JP7012257B2 (ja) 送信方法、受信方法、送信装置及び受信装置
WO2016021153A1 (ja) 送信方法、受信方法、送信装置及び受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200123

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210201

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210209

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210430

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211021

R150 Certificate of patent or registration of utility model

Ref document number: 6966581

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150