JP7525705B2 - 送信方法、受信方法、送信装置及び受信装置 - Google Patents
送信方法、受信方法、送信装置及び受信装置 Download PDFInfo
- Publication number
- JP7525705B2 JP7525705B2 JP2023122229A JP2023122229A JP7525705B2 JP 7525705 B2 JP7525705 B2 JP 7525705B2 JP 2023122229 A JP2023122229 A JP 2023122229A JP 2023122229 A JP2023122229 A JP 2023122229A JP 7525705 B2 JP7525705 B2 JP 7525705B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- unit
- information
- receiving device
- mpu
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 434
- 230000005540 biological transmission Effects 0.000 title claims description 198
- 239000012634 fragment Substances 0.000 description 276
- 238000012937 correction Methods 0.000 description 141
- 238000010586 diagram Methods 0.000 description 124
- 238000012545 processing Methods 0.000 description 112
- 239000000872 buffer Substances 0.000 description 107
- 230000008569 process Effects 0.000 description 104
- 238000003780 insertion Methods 0.000 description 30
- 230000037431 insertion Effects 0.000 description 30
- 230000001360 synchronised effect Effects 0.000 description 29
- 238000012217 deletion Methods 0.000 description 23
- 230000037430 deletion Effects 0.000 description 23
- AWSBQWZZLBPUQH-UHFFFAOYSA-N mdat Chemical compound C1=C2CC(N)CCC2=CC2=C1OCO2 AWSBQWZZLBPUQH-UHFFFAOYSA-N 0.000 description 23
- 238000013467 fragmentation Methods 0.000 description 22
- 238000006062 fragmentation reaction Methods 0.000 description 22
- 230000011664 signaling Effects 0.000 description 19
- 238000004364 calculation method Methods 0.000 description 15
- 238000004891 communication Methods 0.000 description 13
- 102100037812 Medium-wave-sensitive opsin 1 Human genes 0.000 description 12
- 238000005538 encapsulation Methods 0.000 description 12
- 230000003139 buffering effect Effects 0.000 description 11
- 238000001914 filtration Methods 0.000 description 11
- 230000002123 temporal effect Effects 0.000 description 11
- 238000007726 management method Methods 0.000 description 10
- 230000001934 delay Effects 0.000 description 9
- 238000003860 storage Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 8
- 239000002609 medium Substances 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 238000006243 chemical reaction Methods 0.000 description 7
- 238000004458 analytical method Methods 0.000 description 6
- 238000000605 extraction Methods 0.000 description 5
- 230000004931 aggregating effect Effects 0.000 description 4
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 4
- 230000007257 malfunction Effects 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 101100070543 Hevea brasiliensis HEV1 gene Proteins 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000001172 regenerating effect Effects 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000033001 locomotion Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000008707 rearrangement Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 239000013589 supplement Substances 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 101710095156 E3 ubiquitin-protein ligase RBX1 Proteins 0.000 description 1
- 102100023877 E3 ubiquitin-protein ligase RBX1 Human genes 0.000 description 1
- 101710178916 RING-box protein 1 Proteins 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 230000000052 comparative effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000012010 growth Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000009131 signaling function Effects 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 239000006163 transport media Substances 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
本発明は、送信方法、受信方法、送信装置及び受信装置に関する。
放送及び通信サービスの高度化に伴い、8K(7680×4320ピクセル:以下では8K4Kとも呼ぶ)及び4K(3840×2160ピクセル:以下では4K2Kとも呼ぶ)などの超高精細な動画像コンテンツの導入が検討されている。受信装置は、受信した超高精細な動画像の符号化データを実時間で復号して表示する必要があるが、特に8Kなどの解像度の動画像は復号時の処理負荷が大きく、このような動画像を1つの復号器で、実時間で復号することは困難である。従って、複数の復号器を用いて復号処理を並列化することで、1つの復号器あたりの処理負荷を低減し、実時間処理を達成する方法が検討されている。
また、符号化データはMPEG-2 TS(Transport Stream)又はMMT(MPEG Media Transport)などの多重化方式に基づいて多重化されたうえで送信される。例えば、非特許文献1には、MMTに従って、符号化されたメディアデータをパケット毎に送信する技術が開示されている。
Information technology - High efficiency coding and media delivery in heterogeneous environment - Part1:MPEG media transport(MMT)、ISO/IEC DIS 23008-1
ところで、放送や通信サービスの高度化に伴い、8Kや4K(3840x2160ピクセル)などの超高精細な動画コンテンツの導入が検討されている。MMT/TLV方式では、送信側の基準クロックをRFC 5905に規定される64ビットのロングフォーマットNTPに同期させ、基準クロックを基に、PTS(Presentation Time Stamp)や、DTS(Decode Time Stamp)などのタイムスタンプを同期メディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置におけるシステムクロックを生成する。
しかしながら、このようなMMTの伝送方式では、NTPなどの基準時刻情報にうるう秒調整が行なわれる場合、受信装置が受信した第1のデータユニットであるMPUに格納される複数の第2のデータユニットである複数のアクセスユニットを、当該複数のアクセスユニットに対応づけられたDTS又はPTSに従っても復号又は提示を意図された時刻に行うことができないという課題がある。
本発明は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、所定のデータユニットを意図された時刻に受信装置が再生できる送信方法などを提供する。
上記目的を達成するために、本発明の一態様に係る送信方法は、符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記時刻情報に基づいて生成されたか否かを示す識別情報とを送信し、前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報であり、前記時刻情報は、NTP(Network Time Protocol)である。
また、本発明の一態様に係る受信方法は、符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信方法であって、前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信し、受信した前記提示時刻情報及び前記識別情報に基づいて、受信した前記所定のデータユニットを再生し、前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報であり、前記時刻情報は、NTP(Network Time Protocol)である。
上記目的を達成するために、本発明の一態様に係る送信方法は、符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記時刻情報に基づいて生成されたか否かを示す識別情報とを送信し、前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報である。
また、本発明の一態様に係る受信方法は、符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信方法であって、前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信し、受信した前記提示時刻情報及び前記識別情報に基づいて、受信した前記所定のデータユニットを再生し、前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報である。
上記目的を達成するために、本発明の一態様に係る送信方法は、符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、外部から受信した基準時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記基準時刻情報に基づいて生成されたか否かを示す識別情報とを送信し、前記識別情報は、制御情報である制御メッセージに格納される。
また、本発明の一態様に係る受信方法は、符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信方法であって、前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信し、受信した前記提示時刻情報及び前記識別情報に基づいて、受信した前記所定のデータユニットを再生し、前記識別情報は、制御情報である制御メッセージに格納される。
また、本発明の一態様に係る送信装置は、符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信装置であって、外部から受信した時刻情報に基づいて、当該所定のデータユニットの提示時刻を示す提示時刻情報を生成する生成部と、前記所定のデータユニットと、前記生成部により生成された前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記時刻情報に基づいて生成されたか否かを示す識別情報とを送信する送信部と、を備え、前記識別情報は、制御情報である制御メッセージに格納される。
また、本発明の一態様に係る送信方法は、符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信装置であって、前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信する受信部と、前記受信部により受信された前記提示時刻情報及び前記識別情報に基づいて、前記受信部により受信された前記所定のデータユニットを再生する再生部と、を備え、前記識別情報は、制御情報である制御メッセージに格納される。
上記目的を達成するために、本発明の一態様に係る受信方法は、符号化ストリームを構成するデータが格納された第1のデータユニットを受信する受信装置による受信方法であって、前記第1のデータユニットは、複数の第2のデータユニットを格納し、前記受信方法では、(i)前記第1のデータユニットと、(ii)前記第1のデータユニットの提示時刻を示す第1時刻情報と、(iii)補正が必要な提示時刻で提示される、または、補正が必要な復号時刻で復号される第2のデータユニットであって、前記複数の第2のデータユニットのうちの提示順で先頭の第2のデータユニット以外の他の第2のデータユニットが前記第1のデータユニットに含まれる可能性があることを示す識別情報と、(iv)前記第1時刻情報とで前記複数の第2のデータユニットそれぞれの提示時刻または復号時刻を算出するための相対的な時刻情報である第2時刻情報と、を受信し、前記他の第2のデータユニットが含まれる可能性があることを、受信した前記識別情報が示している前記第1のデータユニットに対して、前記他の第2のデータユニットが含まれるか否かを判断する。
また、本発明の一態様に係る受信装置は、符号化ストリームを構成するデータが格納された第1のデータユニットを受信する受信装置であって、前記第1のデータユニットは、複数の第2のデータユニットを格納し、前記受信装置は、(i)前記第1のデータユニットと、(ii)前記第1のデータユニットの提示時刻を示す第1時刻情報と、(iii)補正が必要な提示時刻で提示される、または、補正が必要な復号時刻で復号される第2のデータユニットであって、前記複数の第2のデータユニットのうちの提示順で先頭の第2のデータユニット以外の他の第2のデータユニットが前記第1のデータユニットに含まれる可能性があることを示す識別情報と、(iv)前記第1時刻情報とで前記複数の第2のデータユニットそれぞれの提示時刻または復号時刻を算出するための相対的な時刻情報である第2時刻情報と、を受信する受信部と、前記他の第2のデータユニットが含まれる可能性があることを、前記受信部により受信された前記識別情報が示している前記第1のデータユニットに対して、前記他の第2のデータユニットが含まれるか否かを判断する判断部と、を備える。
上記目的を達成するために、本発明の一態様に係る送信方法は、符号化ストリームを構成するデータが格納された第1のデータユニットを送信する送信方法であって、前記第1のデータユニットは、複数の第2のデータユニットを格納し、前記送信方法では、外部から受信した基準時刻情報に基づいて、前記第1のデータユニットの提示時刻を示す第1時刻情報を生成し、(i)前記第1のデータユニットと、(ii)生成した前記第1時刻情報と、(iii)補正が必要な提示時刻で提示される、または、補正が必要な復号時刻で復号される第2のデータユニットであって、前記複数の第2のデータユニットのうちの提示順で先頭の第2のデータユニット以外の他の第2のデータユニットが前記第1のデータユニットに含まれる可能性があることを示す識別情報とを送信する。
なお、これらの全般的または具体的な態様は、システム、装置、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD-ROMなどの記録媒体で実現されてもよく、システム、装置、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
本発明は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、第1のデータユニットに格納されている複数の第2のデータユニットを意図された時刻に再生できる。
本発明の一態様に係る送信方法は、符号化ストリームを構成するデータが格納された第1のデータユニットを送信する送信方法であって、前記第1のデータユニットは、複数の第2のデータユニットを格納し、前記送信方法では、外部から受信した基準時刻情報に基づいて、前記第1のデータユニットの提示時刻を示す第1時刻情報を生成し、(i)前記第1のデータユニットと、(ii)生成した前記第1時刻情報と、(iii)補正が必要な提示時刻で提示される、または、補正が必要な復号時刻で復号される第2のデータユニットであって、前記複数の第2のデータユニットのうちの提示順で先頭の第2のデータユニット以外の他の第2のデータユニットが前記第1のデータユニットに含まれる可能性があることを示す識別情報とを送信する。
このような送信方法は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、意図された時刻に第1のデータユニットで構成される符号化ストリームを受信装置が再生できる。
また、前記送信では、さらに、前記第1時刻情報とで前記複数の第2のデータユニットそれぞれの提示時刻または復号時刻を算出するための相対的な時刻情報である第2時刻情報を送信してもよい。
また、前記第1時刻情報は、うるう秒調整時に補正の対象となる時刻情報であってもよい。
また、さらに、前記第1時刻情報が補正条件を満たす場合に、前記第1時刻情報を補正し、前記送信では、前記第1時刻情報が、前記生成においてうるう秒調整前の前記基準時刻情報に基づいて生成され、かつ、前記補正において補正されていない情報であるか否かを示す情報を、前記識別情報として送信し、前記識別情報は、前記第1時刻情報が、前記生成においてうるう秒調整前の前記基準時刻情報に基づいて生成され、かつ、前記補正において補正されていない情報であることを示す場合、前記他の第2のデータユニットが前記第1のデータユニットに含まれる可能性があることを示してもよい。
また、前記補正条件は、前記第1時刻情報が、うるう秒調整前の前記基準時刻情報に基づいて生成されており、かつ、所定の時刻以降であることであってもよい。
また、前記識別情報は、前記第1時刻情報がうるう秒調整前の前記基準時刻情報に基づいて生成されたか否かを示す第1識別情報と、前記第1時刻情報を補正したことを示す第2識別情報とを含んでもよい。
また、前記第1識別情報は、前記第1時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記基準時刻情報に基づいて生成されたか否かを示す情報であってもよい。
また、前記第1時刻情報は、前記複数の第2のデータユニットのうちの提示順で先頭の第2のデータユニットの提示時刻を示す絶対的な時刻情報であってもよい。
また、前記送信では、前記第1のデータユニットに対応する前記第1時刻情報が格納された制御情報と、複数の前記第1のデータユニットと、が格納された所定のパケットを送信してもよい。
また、前記送信では、複数の前記第1のデータユニットとしてのMPU(Media Presentation Unit)が格納された、前記所定のパケットとしてのMMTP(MPEG Media Transport Protocol)パケットを送信し、前記MMTPパケットは、制御情報として、前記第1時刻情報を含むMPUタイムスタンプ記述子と、前記第2時刻情報を含むMPU拡張タイムスタンプ記述子と、を含み、前記MPUは、前記複数の第2のデータユニットとしての複数のアクセスユニットを格納していてもよい。
また、前記基準時刻情報は、NTP(Network Time Protocol)であってもよい。
また、本発明の一態様に係る受信方法は、符号化ストリームを構成するデータが格納された第1のデータユニットを受信する受信装置による受信方法であって、前記第1のデータユニットは、複数の第2のデータユニットを格納し、前記受信方法では、(i)前記第1のデータユニットと、(ii)前記第1のデータユニットの提示時刻を示す第1時刻情報と、(iii)補正が必要な提示時刻で提示される、または、補正が必要な復号時刻で復号される第2のデータユニットであって、前記複数の第2のデータユニットのうちの提示順で先頭の第2のデータユニット以外の他の第2のデータユニットが前記第1のデータユニットに含まれる可能性があることを示す識別情報と、を受信し、前記他の第2のデータユニットが含まれる可能性があることを、受信した前記識別情報が示している前記第1のデータユニットに対して、前記他の第2のデータユニットが含まれるか否かを判断する。
このような受信方法は、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、意図された時刻に第1のデータユニットで構成される符号化ストリームを再生できる。
なお、これらの包括的または具体的な態様は、装置、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD-ROMなどの記録媒体記録媒体で実現されてもよく、装置、システム、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
以下、実施の形態について、図面を参照しながら具体的に説明する。
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
(本発明の基礎となった知見)
近年、TV、スマートフォン、又はタブレット端末などのディスプレイの高解像度化が進んでいる。特に日本国内の放送においては2020年に8K4K(解像度が8K×4K)のサービスが予定されている。8K4Kなどの超高解像度の動画像においては、単一の復号器では実時間での復号が困難であるため、複数の復号器を用いて並列に復号処理を行う手法が検討されている。
近年、TV、スマートフォン、又はタブレット端末などのディスプレイの高解像度化が進んでいる。特に日本国内の放送においては2020年に8K4K(解像度が8K×4K)のサービスが予定されている。8K4Kなどの超高解像度の動画像においては、単一の復号器では実時間での復号が困難であるため、複数の復号器を用いて並列に復号処理を行う手法が検討されている。
符号化データはMPEG-2 TSやMMTなどの多重化方式に基づいて多重化して送信されるため、受信装置は、復号に先立って、多重化データから動画の符号化データを分離する必要がある。以下、多重化データから符号化データを分離する処理を逆多重化と呼ぶ。
復号処理を並列化する際には、各復号器のそれぞれに対して、復号対象となる符号化データを振り分ける必要がある。符号化データを振り分ける際には、符号化データそのものを解析する必要があり、特に8Kなどのコンテンツにおいてはビットレートが非常に高いことから、解析に係る処理負荷が大きい。したがって、逆多重化の部分がボトルネックとなり実時間での再生が行えないという課題があった。
ところで、MPEGとITUにより規格化されたH.264及びH.265などの動画像符号化方式においては、送信装置は、ピクチャをスライス又はスライスセグメントと呼ばれる複数の領域に分割し、分割したそれぞれの領域を独立に復号できるように符号化することができる。従って、例えば、H.265の場合には、放送を受信する受信装置は、受信データからスライスセグメント毎のデータを分離し、各スライスセグメントのデータを別々の復号器に出力することで、復号処理の並列化を実現できる。
図1は、HEVCにおいて、1つのピクチャを4つのスライスセグメントに分割する例を示す図である。例えば、受信装置は4つの復号器を備え、各復号器が4つのスライスセグメントのうちいずれかを復号する。
従来の放送においては、送信装置は、1枚のピクチャ(MPEGシステム規格におけるアクセスユニット)を1つのPESパケットに格納し、PESパケットをTSパケット列に多重化する。このため、受信装置は、PESパケットのペイロードを分離したうえで、ペイロードに格納されたアクセスユニットのデータを解析することで、各スライスセグメントを分離し、分離された各スライスセグメントのデータを復号器に出力する必要があった。
しかしながら、アクセスユニットのデータを解析してスライスセグメントを分離する際の処理量が大きいため、この処理を実時間で行うことが困難であるという課題があることを本発明者は見出した。
図2は、スライスセグメントに分割されたピクチャのデータが、PESパケットのペイロードに格納される例を示す図である。
図2に示すように、例えば、複数のスライスセグメント(スライスセグメント1~4)のデータが1つのPESパケットのペイロードに格納される。また、PESパケットはTSパケット列に多重化される。
(実施の形態1)
以下では、動画像の符号化方式としてH.265を用いる場合を例に説明するが、H.264など他の符号化方式を用いる場合にも本実施の形態を適用できる。
以下では、動画像の符号化方式としてH.265を用いる場合を例に説明するが、H.264など他の符号化方式を用いる場合にも本実施の形態を適用できる。
図3は、本実施の形態におけるアクセスユニット(ピクチャ)を分割単位に分割した例を示す図である。アクセスユニットは、H.265によって導入されたタイルと呼ばれる機能により、水平及び垂直方向にそれぞれ2等分され、合計4つのタイルに分割される。また、スライスセグメントとタイルは1対1に対応付けられる。
このように水平及び垂直方向に2等分する理由について説明する。まず、復号時には、一般的に水平1ラインのデータを格納するラインメモリが必要となるが、8K4Kなどの超高解像度になると、水平方向のサイズが大きくなるためラインメモリのサイズが増加する。受信装置の実装においては、ラインメモリのサイズを低減できることが望ましい。ラインメモリのサイズを低減するためには垂直方向の分割が必要となる。垂直方向の分割にはタイルというデータ構造が必要である。これらの理由により、タイルが用いられる。
一方で、画像は一般的に水平方向の相関が高いため、水平方向に広い範囲を参照できるほうが符号化効率は向上する。従って、符号化効率の観点ではアクセスユニットが水平方向に分割されることが望ましい。
アクセスユニットが水平及び垂直方向に2等分されることで、これら2つの特性を両立させ、実装面、及び符号化効率の両面を考慮できる。単一の復号器が4K2Kの動画像を実時間での復号が可能の場合には、8K4Kの画像が4等分され、各々のスライスセグメントが4K2Kとなるように分割されることで、受信装置は、8K4Kの画像を実時間で復号できる。
次に、アクセスユニットが水平及び垂直方向に分割されることで得られたタイルとスライスセグメントとを1対1に対応付ける理由について説明する。H.265においては、アクセスユニットは複数のNAL(Network Adaptation Layer)ユニットと呼ばれる単位から構成される。
NALユニットのペイロードは、アクセスユニットの開始位置を示すアクセスユニットデリミタ、シーケンス単位で共通に用いられる復号時の初期化情報であるSPS(Sequence Parameter Set)、ピクチャ内で共通に用いられる復号時の初期化情報であるPPS(Picture Parameter Set)、復号処理自体には不要であるが復号結果の処理及び表示などにおいて必要となるSEI(Supplemental Enhancement Information)、並びに、スライスセグメントの符号化データなどのいずれかを格納する。NALユニットのヘッダは、ペイロードに格納されるデータを識別するためのタイプ情報を含む。
ここで、送信装置は、符号化データをMPEG-2 TS、MMT(MPEG Media Transport)、MPEG DASH(Dynamic Adaptive
Streaming over HTTP)、又は、RTP(Real-time Transport Protocol)などの多重化フォーマットによって多重化する際には、基本単位をNALユニットに設定できる。1つのスライスセグメントを1つのNALユニットに格納するためには、アクセスユニットを領域に分割する際に、スライスセグメント単位に分割することが望ましい。このような理由から、送信装置は、タイルとスライスセグメントとを1対1に対応付ける。
Streaming over HTTP)、又は、RTP(Real-time Transport Protocol)などの多重化フォーマットによって多重化する際には、基本単位をNALユニットに設定できる。1つのスライスセグメントを1つのNALユニットに格納するためには、アクセスユニットを領域に分割する際に、スライスセグメント単位に分割することが望ましい。このような理由から、送信装置は、タイルとスライスセグメントとを1対1に対応付ける。
なお、図4に示すように、送信装置は、タイル1からタイル4までをまとめて1つのスライスセグメントに設定することも可能である。しかし、この場合には、1つのNALユニットに全てのタイルが格納されることになり、受信装置が、多重化レイヤにおいてタイルを分離することが困難である。
なお、スライスセグメントには独立に復号可能な独立スライスセグメントと、独立スライスセグメントを参照する参照スライスセグメントとが存在するが、ここでは独立スライスセグメントが用いられる場合を説明する。
図5は、図3に示すようにタイルとスライスセグメントとの境界が一致するように分割されたアクセスユニットのデータの例を示す図である。アクセスユニットのデータは、先頭に配置されたアクセスユニットデリミタが格納されるNALユニットと、その後に配置されるSPS、PPS、及びSEIのNALユニットと、その後に配置されるタイル1からタイル4までのデータが格納されたスライスセグメントのデータとを含む。なお、アクセスユニットのデータは、SPS、PPS及びSEIのNALユニットの一部又は全てを含まなくてもよい。
次に、本実施の形態に係る送信装置100の構成を説明する。図6は、本実施の形態に係る送信装置100の構成例を示すブロック図である。この送信装置100は、符号化部101と、多重化部102と、変調部103と、送信部104とを備える。
符号化部101は、入力画像を、例えば、H.265に従い符号化することで符号化データを生成する。また、符号化部101は、例えば、図3に示すように、アクセスユニットを4つのスライスセグメント(タイル)に分割し、各スライスセグメントを符号化する。
多重化部102は、符号化部101により生成された符号化データを多重化する。変調部103は、多重化により得られたデータを変調する。送信部104は、変調後のデータを放送信号として送信する。
次に、本実施の形態に係る受信装置200の構成を説明する。図7は、本実施の形態に係る受信装置200の構成例を示すブロック図である。この受信装置200は、チューナー201と、復調部202と、逆多重化部203と、複数の復号部204A~204Dと、表示部205とを備える。
チューナー201は、放送信号を受信する。復調部202は、受信された放送信号を復調する。復調後のデータは逆多重化部203に入力される。
逆多重化部203は、復調後のデータを分割単位に分離し、分割単位毎のデータを復号部204A~204Dに出力する。ここで、分割単位とは、アクセスユニットが分割されることで得られた分割領域であり、例えば、H.265におけるスライスセグメントである。また、ここでは、8K4Kの画像が4つの4K2Kの画像に分割される。よって、4つの復号部204A~204Dが存在する。
複数の復号部204A~204Dは、所定の基準クロックに基づいて互いに同期して動作する。各復号部は、アクセスユニットのDTS(Decoding Time Stamp)に従って分割単位の符号化データを復号し、復号結果を表示部205に出力する。
表示部205は、複数の復号部204A~204Dから出力された複数の復号結果を統合することで8K4Kの出力画像を生成する。表示部205は、別途取得したアクセスユニットのPTS(Presentation Time Stamp)に従って、生成された出力画像を表示する。なお、表示部205は、復号結果を統合する際に、タイルの境界など、互いに隣接する分割単位の境界領域において、当該境界が視覚的に目立たなくなるようにデブロックフィルタなどのフィルタ処理を行ってもよい。
なお、上記では、放送の送信又は受信を行う送信装置100及び受信装置200を例に説明したが、コンテンツは通信ネットワーク経由で送信及び受信されてもよい。受信装置200が、通信ネットワーク経由でコンテンツを受信する場合には、受信装置200は、イーサーネットなどのネットワークにより受信したIPパケットから多重化データを分離する。
放送においては、放送信号が送信されてから受信装置200に届くまでの間の伝送路遅延は一定である。一方、インターネットなどの通信ネットワークにおいては輻輳の影響により、サーバーから送信されたデータが受信装置200に届くまでの伝送路遅延は一定でない。従って、受信装置200は、放送のMPEG-2 TSにおけるPCRのような基準クロックに基づいた厳密な同期再生を行わないことが多い。そのため、受信装置200は、各復号部を厳密に同期させることはせずに、表示部において8K4Kの出力画像をPTSに従って表示してもよい。
また、通信ネットワークの輻輳などにより、全ての分割単位の復号処理がアクセスユニットのPTSで示される時刻において完了していない場合がある。この場合には、受信装置200は、アクセスユニットの表示をスキップする、又は、少なくとも4つの分割単位の復号が終了し、8K4Kの画像の生成が完了するまで表示を遅延させる。
なお、放送と通信とを併用してコンテンツが送信及び受信されてもよい。また、ハードディスク又はメモリなどの記録媒体に格納された多重化データを再生する際にも本手法を適用可能である。
次に、多重化方式としてMMTが用いられる場合の、スライスセグメントに分割されたアクセスユニットの多重化方法にについて説明する。
図8は、HEVCのアクセスユニットのデータを、MMTにパケット化する際の例を示す図である。SPS、PPS及びSEIなどはアクセスユニットに必ずしも含まれる必要はないが、ここでは存在する場合について例示する。
アクセスユニットデリミタ、SPS、PPS、及びSEIなどのアクセスユニット内で先頭のスライスセグメントよりも前に配置されるNALユニットは一纏めにしてMMTパケット#1に格納される。後続のスライスセグメントは、スライスセグメント毎に別々のMMTパケットに格納される。
なお、図9に示すように、アクセスユニット内で先頭のスライスセグメントよりも前に配置されるNALユニットが、先頭のスライスセグメントと同一のMMTパケットに格納されてもよい。
また、シーケンス又はストリームの終端を示す、End-of-Sequence又はEnd-of-BitstreamなどのNALユニットが最終スライスセグメントの後に付加される場合には、これらは、最終スライスセグメントと同一のMMTパケットに格納される。ただし、End-of-Sequence又はEnd-of-BitstreamなどのNALユニットは、復号処理の終了ポイント、又は2本のストリームの接続ポイントなどに挿入されるため、受信装置200が、これらのNALユニットを、多重化レイヤにおいて容易に取得できることが望ましい場合がある。この場合には、これらのNALユニットは、スライスセグメントとは別のMMTパケットに格納されてもよい。これにより、受信装置200は、多重化レイヤにおいてこれらのNALユニットを容易に分離できる。
なお、多重化方式として、TS、DASH又はRTPなどが用いられてもよい。これらの方式においても、送信装置100は、異なるスライスセグメントをそれぞれ異なるパケットに格納する。これにより、受信装置200が多重化レイヤにおいてスライスセグメントを分離できることを保証できる。
例えば、TSが用いられる場合、スライスセグメント単位で符号化データがPESパケット化される。RTPが用いられる場合、スライスセグメント単位で符号化データがRTPパケット化される。これらの場合においても、図8に示すMMTパケット#1のように、スライスセグメントよりも前に配置されるNALユニットとスライスセグメントとが別々にパケット化されてもよい。
TSが用いられる場合、送信装置100は、data alignment記述子を用いることなどにより、PESパケットに格納されるデータの単位を示す。また、DASHはセグメントと呼ばれるMP4形式のデータ単位をHTTPなどによりダウンロードする方式であるため、送信装置100は、送信にあたって符号化データのパケット化は行わない。このため、送信装置100は、受信装置200がMP4において多重化レイヤでスライスセグメントを検出できるように、スライスセグメント単位でサブサンプルを作成し、サブサンプルの格納位置を示す情報をMP4のヘッダに格納してもよい。
以下、スライスセグメントのMMTパケット化について、詳細に説明する。
図8に示すように、符号化データがパケット化されることで、SPS及びPPSなどのアクセスユニット内の全スライスセグメントの復号時に共通に参照されるデータがMMTパケット#1に格納される。この場合、受信装置200は、MMTパケット#1のペイロードデータと各スライスセグメントのデータとを連結し、得られたデータを復号部に出力する。このように、受信装置200は、複数のMMTパケットのペイロードを連結することで、復号部への入力データを容易に生成できる。
図10は、図8に示すMMTパケットから復号部204A~204Dへの入力データが生成される例を示す図である。逆多重化部203は、MMTパケット#1とMMTパケット#2とのペイロードデータを連結させることで、復号部204Aが、スライスセグメント1を復号するために必要なデータを生成する。逆多重化部203は、復号部204Bから復号部204Dについても、同様に入力データを生成する。つまり、逆多重化部203は、MMTパケット#1とMMTパケット#3とのペイロードデータを連結させることで、復号部204Bの入力データを生成する。逆多重化部203は、MMTパケット#1とMMTパケット#4とのペイロードデータを連結させることで、復号部204Cの入力データを生成する。逆多重化部203は、MMTパケット#1とMMTパケット#5とのペイロードデータを連結させることで、復号部204Dの入力データを生成する。
なお、逆多重化部203は、アクセスユニットデリミタ及びSEIなど、復号処理に必要ではないNALユニットを、MMTパケット#1のペイロードデータから除去し、復号処理に必要であるSPS及びPPSのNALユニットのみを分離してスライスセグメントのデータに付加してもよい。
図9に示すように符号化データがパケット化される場合には、逆多重化部203は、多重化レイヤにおいてアクセスユニットの先頭データを含むMMTパケット#1を1番目の復号部204Aに出力する。また、逆多重化部203は、多重化レイヤにおいてアクセスユニットの先頭データを含むMMTパケットを解析し、SPS及びPPSのNALユニットを分離し、分離したSPS及びPPSのNALユニットを2番目以降のスライスセグメントのデータの各々に付加することで2番目以降の復号部の各々に対する入力データを生成する。
さらに、受信装置200が、MMTパケットのヘッダに含まれる情報を用いて、MMTペイロードに格納されるデータのタイプ、及び、ペイロードにスライスセグメントが格納されている場合のアクセスユニット内における当該スライスセグメントのインデックス番号を識別できることが望ましい。ここで、データのタイプとは、スライスセグメント前データ(アクセスユニット内で先頭スライスセグメントよりも前に配置されるNALユニットをまとめて、このように呼ぶことにする)、及び、スライスセグメントのデータのいずれである。MMTパケットに、スライスセグメントなどのMPUをフラグメント化した単位を格納する場合には、MFU(Media Fragment Unit)を格納するためのモードが用いられる。送信装置100は、本モードを用いる場合には、例えば、MFUにおけるデータの基本単位であるData Unitを、サンプル(MMTにおけるデータ単位であり、アクセスユニットに相当する)、又は、サブサンプル(サンプルを分割した単位)に設定できる。
このとき、MMTパケットのヘッダは、Fragmentation indicatorと呼ばれるフィールドと、Fragment counterと呼ばれるフィールドとを含む。
Fragmentation indicatorは、MMTパケットのペイロードに格納されるデータが、Data unitをフラグメント化したものであるかどうか、フラグメント化したものである場合には、当該フラグメントがData unitにおける先頭或いは最終のフラグメント、又は、先頭と最終とのどちらでもないフラグメントであるかを示す。言い換えると、あるパケットのヘッダに含まれるFragmentation indicatorは、(1)基本データ単位であるData unitに当該パケットのみが含まれる、(2)Data unitが複数のパケットに分割して格納され、かつ、当該パケットがData unitの先頭のパケットである、(3)Data unitが複数のパケットに分割して格納され、かつ、当該パケットがData unitの先頭及び最後以外のパケットである、及び、(4)Data unitが複数のパケットに分割して格納され、かつ、当該パケットがData unitの最後のパケットである、のいずれであるかを示す識別情報である。
Fragment counterは、MMTパケットに格納されるデータが、Data unitにおいて何番目のフラグメントに相当するかを示すインデックス番号である。
従って、送信装置100が、MMTにおけるサンプルをData unitに設定し、スライスセグメント前データ、及び、各スライスセグメントを、それぞれData unitのフラグメント単位に設定することで、受信装置200は、MMTパケットのヘッダに含まれる情報を用いて、ペイロードに格納されるデータのタイプが識別できる。つまり、逆多重化部203は、MMTパケットのヘッダを参照して、各復号部204A~204Dへの入力データを生成できる。
図11は、サンプルがData unitに設定され、スライスセグメント前データ、及び、スライスセグメントがData unitのフラグメントとしてパケット化される場合の例を示す図である。
スライスセグメント前データ、及びスライスセグメントは、フラグメント#1からフラグメント#5までの5つのフラグメントに分割される。各フラグメントは個別のMMTパケットに格納される。このとき、MMTパケットのヘッダに含まれるFragmentation indicator及びFragment counterの値は図示する通りである。
例えば、Fragment indicatorは、2進数の2ビット値である。Data unitの先頭であるMMTパケット#1のFragment indicator、最終であるMMTパケット#5のFragment indicator、及び、その間のパケットであるMMTパケット#2からMMTパケット#4までのFragment indicatorは、それぞれ別の値に設定される。具体的には、Data unitの先頭であるMMTパケット#1のFragment indicatorは01に設定され、最終であるMMTパケット#5のFragment indicatorは11に設定され、その間のパケットであるMMTパケット#2からMMTパケット#4までのFragment indicatorは10に設定される。なお、Data unitに一つのMMTパケットのみが含まれる場合には、Fragment indicatorは00に設定される。
また、Fragment counterは、MMTパケット#1においてはフラグメントの総数である5から1を減算した値である4であり、後続パケットにおいては順に1ずつ減少し、最後のMMTパケット#5においては0である。
従って、受信装置200は、スライスセグメント前データを格納するMMTパケットを、Fragment indicator、及び、Fragment counterのいずれかを用いて識別できる。また、受信装置200は、N番目のスライスセグメントを格納するMMTパケットを、Fragment counterを参照することにより識別できる。
MMTパケットのヘッダは、別途、Data unitが属するMovie FragmentのMPU内でのシーケンス番号と、MPU自体のシーケンス番号と、Data unitが属するサンプルのMovie Fragment内におけるシーケンス番号とを含む。逆多重化部203は、これらを参照することで、Data unitが属するサンプルを一意に決定できる。
更に、逆多重化部203は、Data unit内におけるフラグメントのインデックス番号をFragment counterなどから決定できるため、パケットロスが発生した場合にも、フラグメントに格納されるスライスセグメントを一意に特定できる。例えば、逆多重化部203は、図11に示すフラグメント#4がパケットロスにより取得できなかった場合でも、フラグメント#3の次に受信したフラグメントがフラグメント#5であることが分かるため、フラグメント#5に格納されるスライスセグメント4を、復号部204Cではなく復号部204Dに正しく出力することができる。
なお、パケットロスが発生しないことが保証される伝送路が使用される場合には、逆多重化部203は、MMTパケットのヘッダを参照してMMTパケットに格納されるデータのタイプ、又はスライスセグメントのインデックス番号を決定せずに、到着したパケットを周期的に処理すればよい。例えば、アクセスユニットが、スライス前データ、及び、4つのスライスセグメントの計5つのMMTパケットにより送信される場合には、受信装置200は、復号を開始するアクセスユニットのスライス前データを決定した後は、受信したMMTパケットを順に処理することで、スライス前データ、及び、4つのスライスセグメントのデータを順に取得できる。
以下、パケット化の変形例について説明する。
スライスセグメントは、必ずしもアクセスユニットの面内を水平方向と垂直方向との両方に分割されたものである必要はなく、図1に示すように、アクセスユニットを水平方向のみに分割されたものでもよいし、垂直方向のみに分割されたものでもよい。
また、水平方向のみにアクセスユニットが分割される場合には、タイルが用いられる必要はない。
また、アクセスユニットにおける面内の分割数は任意であり、4つに限定されるものではない。但し、スライスセグメント及びタイルの領域サイズはH.265などの符号化規格の下限以上である必要がある。
送信装置100は、アクセスユニットにおける面内の分割方法を示す識別情報を、MMTメッセージ、又はTSのデスクリプタなどに格納してもよい。例えば、面内における水平方向と垂直方向との分割数とをそれぞれ示す情報が格納されてもよい。または、図3に示すように水平方向及び垂直方向にそれぞれ2等分されている、又は、図1に示すように水平方向に4等分されているなど、分割方法に対して固有の識別情報が割り当てられてもよい。例えば、図3に示すようにアクセスユニットが分割されている場合は、識別情報はモード1を示し、図1に示すようにアクセスユニットが分割されている場合には、識別情報はモード1を示す。
また、面内の分割方法に関連する符号化条件の制約を示す情報が、多重化レイヤに含まれてもよい。例えば、1つのスライスセグメントが1つのタイルから構成されること示す情報が用いられてもよい。または、スライスセグメント或いはタイルの復号時に動き補償を行う場合の参照ブロックが、画面内の同一位置のスライスセグメント或いはタイルに制限される、又は、隣接スライスセグメントにおける所定の範囲内のブロックに限定されることなどを示す情報が用いられてもよい。
また、送信装置100は、動画像の解像度に応じて、アクセスユニットを複数のスライスセグメントに分割するかどうかを切替えてもよい。例えば、送信装置100は、処理対象の動画像が4K2Kの解像度の場合には面内の分割を行わずに、処理対象の動画像が8K4Kの場合にはアクセスユニットを4つに分割してもよい。8K4Kの動画像の場合の分割方法を予め規定しておくことにより、受信装置200は、受信する動画像の解像度を取得することで、面内の分割の有無、及び分割方法を決定し、復号動作を切替えることができる。
また、受信装置200は、面内の分割の有無を、MMTパケットのヘッダを参照することにより検出できる。例えば、アクセスユニットが分割されない場合には、MMTのData unitがサンプルに設定されていれば、Data unitのフラグメントは行われない。従って、受信装置200は、MMTパケットのヘッダに含まれるFragment counterの値が常にゼロの場合には、アクセスユニットは分割されないと判定できる。または、受信装置200は、Fragmentation indicatorの値が常に01であるかどうかを検出してもよい。受信装置200は、Fragmentation indicatorの値が常に01の場合もアクセスユニットは分割されないと判定できる。
また、受信装置200は、アクセスユニットにおける面内の分割数と復号部の数とが一致しない場合にも対応できる。例えば、受信装置200が、8K2Kの符号化データを実時間で復号できる2つの復号部204A及び204Bを備える場合には、逆多重化部203は、復号部204Aに対して、8K4Kの符号化データを構成する4つのスライスセグメントのうちの2つを出力する。
図12は、図8に示すようにMMTパケット化されたデータが、2つの復号部204A及び204Bに入力される場合の動作例を示す図である。ここで、受信装置200は、復号部204A及び204Bにおける復号結果を、そのまま統合して出力できることが望ましい。よって、逆多重化部203は、復号部204A及び204Bの各々の復号結果が空間的に連続するように、復号部204A及び204Bの各々に出力するスライスセグメントを選択する。
また、逆多重化部203は、動画像の符号化データの解像度又はフレームレートなどに応じて、使用する復号部を選択してもよい。例えば、受信装置200が4K2Kの復号部を4つ備える場合には、入力画像の解像度が8K4Kであれば、受信装置200は、4つ全ての復号部を用いて復号処理を行う。また、受信装置200は、入力画像の解像度が4K2Kであれば1つの復号部のみを用いて復号処理を行う。または、逆多重化部203は、面内が4つに分割されていても、8K4Kを単一の復号部により実時間で復号できる場合には、全ての分割単位を統合して一つの復号部に出力する。
さらに、受信装置200は、フレームレートを考慮して使用する復号部を決定してもよい。例えば、受信装置200が、解像度が8K4Kである場合に実時間で復号可能なフレームレートの上限が60fpsである復号部を2台備える場合に、8K4Kで120fpsの符号化データが入力されるケースがある。このとき、面内が4つの分割単位から構成されるとすると、図12の例と同様に、スライスセグメント1とスライスセグメント2とが復号部204Aに入力され、スライスセグメント3とスライスセグメント4とが復号部204Bに入力される。各々の復号部204A及び204Bは、8K2K(解像度が8K4Kの半分)であれば120fpsまで実時間で復号できるため、これら2台の復号部204A及び204Bにより復号処理が行われる。
また、解像度及びフレームレートが同一であっても、符号化方式におけるプロファイル、或いはレベル、又は、H.264或いはH.265など符号化方式自体が異なると処理量が異なる。よって、受信装置200は、これらの情報に基づいて使用する復号部を選択してもよい。なお、受信装置200は、放送又は通信により受信した符号化データを全て復号することができない場合、又は、ユーザーが選択した領域を構成する全てのスライスセグメント又はタイルが復号できない場合には、復号部の処理範囲内で復号可能なスライスセグメント又はタイルを自動的に決定してもよい。または、受信装置200は、ユーザーが復号する領域を選択するためのユーザインタフェースを提供してもよい。このとき、受信装置200は、全て領域を復号できないことを示す警告メッセージを表示してもよいし、復号可能な領域、スライスセグメント又はタイルの個数を示す情報を表示してもよい。
また、上記方法は、同一符号化データのスライスセグメントを格納するMMTパケットが、放送及び通信など複数の伝送路を用いて送信及び受信される場合にも適用できる。
また、送信装置100は、分割単位の境界を目立たなくするために、各スライスセグメントの領域がオーバーラップするように符号化を行ってもよい。図13に示す例では、8K4Kのピクチャが4つのスライスセグメント1~4に分割される。スライスセグメント1~3の各々は、例えば、8K×1.1Kであり、スライスセグメント4は8K×1Kである。また、隣接するスライスセグメントは互いにオーバーラップする。こうすることで、点線で示す4分割した場合の境界においては、符号化時の動き補償が効率的に実行できるため、境界部分の画質が向上する。このように、境界部分の画質劣化が低減される。
この場合、表示部205は、8K×1.1Kの領域から、8K×1Kの領域を切り出し、得られた領域を統合する。なお、送信装置100は、スライスセグメントがオーバーラップして符号化されているかどうか、及び、オーバーラップの範囲を示す情報を、多重化レイヤ、又は、符号化データ内に含めて、別途送信してもよい。
なお、タイルが使用される場合にも、同様の手法を適用可能である。
以下、送信装置100の動作の流れを説明する。図14は、送信装置100の動作例を示すフローチャートである。
まず、符号化部101は、ピクチャ(アクセスユニット)を複数の領域である複数のスライスセグメント(タイル)に分割する(S101)。次に、符号化部101は、複数のスライスセグメントの各々を独立して復号が可能なように符号化することで、複数のスライスセグメントの各々に対応する符号化データを生成する(S102)。なお、符号化部101は、複数のスライスセグメントを単一の符号化部で符号化してもよし、複数の符号化部で並列処理してもよい。
次に、多重化部102は、符号化部101で生成された複数の符号化データを、複数のMMTパケットに格納することで、複数の符号化データを多重化する(S103)。具体的には、図8及び図9に示すように、多重化部102は、一つのMMTパケットに、異なるスライスセグメントに対応する符号化データが格納されないように、複数の符号化データを複数のMMTパケットに格納する。また、多重化部102は、図8に示すように、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報を、複数の符号化データが格納される複数のMMTパケット#2~#5とは異なるMMTパケット#1に格納する。ここで制御情報は、アクセスユニットデリミタ、SPS,PPS及びSEIのうち少なくとも一つを含む。
なお、多重化部102は、制御情報を、複数の符号化データが格納される複数のMMTパケットのいずれかと同じMMTパケットに格納してもよい。例えば、図9に示すように、多重化部102は、制御情報を、複数の符号化データが格納される複数のMMTパケットのうちの先頭のMMTパケット(図9のMMTパケット#1)に格納してもよい。
最後に、送信装置100は、複数のMMTパケットを送信する。具体的には、変調部103は、多重化により得られたデータを変調し、送信部104は、変調後のデータを送信する(S104)。
図15は、受信装置200の構成例を示すブロック図であり、図7に示す逆多重化部203及びその後段の構成を詳細に示す図である。図15に示すように、受信装置200は、さらに、復号命令部206を備える。また、逆多重化部203は、タイプ判別部211と、制御情報取得部212と、スライス情報取得部213と、復号データ生成部214とを備える。
以下、受信装置200の動作の流れを説明する。図16は、受信装置200の動作例を示すフローチャートである。ここでは、1つのアクセスユニットに対する動作を示す。複数のアクセスユニットの復号処理が実行される場合には、本フローチャートの処理が繰り返される。
まず、受信装置200は、は、例えば、送信装置100により生成された複数のパケット(MMTパケット)を受信する(S201)。
次に、タイプ判別部211は、受信パケットのヘッダを解析することで、受信パケットに格納されている符号化データのタイプを取得する(S202)。
次に、タイプ判別部211は、取得された符号化データのタイプに基づき、受信パケットに格納されているデータがスライスセグメント前データであるか、スライスセグメントのデータであるかを判定する(S203)。
受信パケットに格納されているデータがスライスセグメント前データである場合(S203でYes)、制御情報取得部212は、受信パケットのペイロードから処理対象のアクセスユニットのスライスセグメント前データを取得し、当該スライスセグメント前データをメモリに格納する(S204)。
一方、受信パケットに格納されているデータがスライスセグメントのデータである場合(S203でNo)、受信装置200は、受信パケットのヘッダ情報を用いて、当該受信パケットに格納されているデータが、複数の領域のうちいずれの領域の符号化データであるかを判定する。具体的には、スライス情報取得部213は、受信パケットのヘッダを解析することで、受信パケットに格納されているスライスセグメントのインデックス番号Idxを取得する(S205)。具体的には、インデックス番号Idxは、アクセスユニット(MMTにおけるサンプル)のMovie Fragment内におけるインデックス番号である。
なお、このステップS205の処理は、ステップS202においてまとめて行われてもよい。
次に、復号データ生成部214は、当該スライスセグメントを復号する復号部を決定する(S206)。具体的には、インデックス番号Idxと複数の復号部とは予め対応付けられており、復号データ生成部214は、ステップS205で取得されたインデックス番号Idxに対応する復号部を、当該スライスセグメントを復号する復号部を決定する。
なお、復号データ生成部214は、図12の例において説明したように、アクセスユニット(ピクチャ)の解像度、アクセスユニットの複数のスライスセグメント(タイル)への分割方法、及び受信装置200が備える複数の復号部の処理能力の少なくとも一つに基づき、当該スライスセグメントを復号する復号部を決定してもよい。例えば、復号データ生成部214は、アクセスユニットの分割方法を、MMTのメッセージ、又はTSのセクションなどのデスクリプタにおける識別情報に基づいて判別する。
次に、復号データ生成部214は、複数のパケットのいずれかに含まれる、ピクチャ内の全ての復号単位に対して共通に用いられる制御情報と、複数のスライスセグメントの複数の符号化データの各々とを結合することで、複数の復号部へ入力される複数の入力データ(結合データ)を生成する。具体的には、復号データ生成部214は、受信パケットのペイロードからスライスセグメントのデータを取得する。復号データ生成部214は、ステップS204でメモリに格納されたスライスセグメント前データと、取得されたスライスセグメントのデータとを結合することで、ステップS206で決定された復号部への入力データを生成する(S207)。
ステップS204又はS207の後、受信パケットのデータがアクセスユニットの最終データでない場合(S208でNo)、ステップS201以降の処理が再度行われる。つまり、アクセスユニットに含まれる全てのスライスセグメントに対応する、複数の復号部204A~204Dへの入力データが生成されるまで、上記処理が繰り返される。
なお、パケットが受信されるタイミングは、図16に示すタイミングに限らず、予め又は順次複数のパケットが受信され、メモリ等に格納されてもよい。
一方、受信パケットのデータがアクセスユニットの最終データである場合(S208でYes)、復号命令部206は、ステップS207で生成された、複数の入力データを、対応する復号部204A~204Dへ出力する(S209)。
次に、複数の復号部204A~204Dは、アクセスユニットのDTSに従い、複数の入力データを並列に復号することで、複数の復号画像を生成する(S210)。
最後に、表示部205は、複数の復号部204A~204Dで生成された複数の復号画像を結合することで表示画像を生成し、アクセスユニットのPTSに従い当該表示画像を表示する(S211)。
なお、受信装置200は、アクセスユニットのDTS及びPTSを、MPUのヘッダ情報、又は、Movie Fragmentのヘッダ情報を格納するMMTパケットのペイロードデータを解析することにより取得する。また、受信装置200は、多重化方式としてTSが使用されている場合にはPESパケットのヘッダからアクセスユニットのDTS及びPTSを取得する。受信装置200は、多重化方式としてRTPが使用されている場合にはRTPパケットのヘッダからアクセスユニットのDTS及びPTSを取得する。
また、表示部205は、複数の復号部の復号結果を統合する際に、隣接する分割単位の境界においてデブロックフィルタなどのフィルタ処理を行ってもよい。なお、単一の復号部の復号結果を表示する場合にはフィルタ処理は不要であるため、表示部205は、複数の復号部の復号結果の境界にフィルタ処理を行うかどうかに応じて処理を切替えてもよい。フィルタ処理が必要かどうかは、分割の有無などに応じて予め規定されていてもよい。または、フィルタ処理が必要かどうかを示す情報が、多重化レイヤに別途格納されてもよい。また、フィルタ係数などフィルタ処理に必要な情報は、SPS、PPS、SEI、又はスライスセグメント内に格納される場合がある。復号部204A~204D、又は逆多重化部203がSEIを解析することによりこれらの情報を取得し、取得された情報を表示部205に出力する。表示部205は、これらの情報を用いてフィルタ処理を行う。なお、これらの情報がスライスセグメント内に格納される場合には、復号部204A~204Dがこれらの情報を取得することが望ましい。
なお、上記説明では、フラグメントに格納されるデータの種類がスライスセグメント前データとスライスセグメントとの2種類である場合の例を示したが、データの種類は3種類以上であってもよい。この場合には、ステップS203においてタイプに応じた場合分けが行われる。
また、送信装置100は、スライスセグメントのデータサイズが大きい場合にスライスセグメントをフラグメント化してMMTパケットに格納してもよい。つまり、送信装置100は、スライスセグメント前データ及びスライスセグメントをフラグメント化してもよい。この場合に、図11に示したパケット化の例のようにアクセスユニットとData unitとを等しく設定すると以下の問題が生じる。
例えばスライスセグメント1が3つのフラグメントに分割される場合、スライスセグメント1がFragment counter値が1から3の3つのパケットに分割して送信される。また、スライスセグメント2以降では、Fragment counter値が4以上となり、Fragment counterの値とペイロードに格納されるデータとの対応付けが取れなくなる。従って、受信装置200は、MMTパケットのヘッダの情報から、スライスセグメントの先頭データを格納するパケットを特定できない。
このような場合には、受信装置200は、MMTパケットのペイロードのデータを解析して、スライスセグメントの開始位置を特定してもよい。ここで、H.264又はH.265においてNALユニットを多重化レイヤに格納する形式として、NALユニットヘッダの直前に特定のビット列からなるスタートコードが付加されるバイトストリームフォーマットと呼ばれる形式と、NALユニットのサイズを示すフィールドが付加されるNALサイズフォーマットと呼ばれる形式との2種類がある。
バイトストリームフォーマットは、MPEG-2システム及びRTPなどにおいて用いられる。NALサイズフォーマットは、MP4、並びにMP4を使用するDASH及びMMTなどにおいて用いられる。
バイトストリームフォーマットが用いられる場合、受信装置200は、パケットの先頭データがスタートコードと一致するかどうかを解析する。受信装置200は、パケットの先頭データがスタートコードと一致していれば、その後に続くNALユニットヘッダからNALユニットのタイプを取得することで、当該パケットに含まれるデータがスライスセグメントのデータであるかどうかを検出できる。
一方、NALサイズフォーマットの場合には、受信装置200は、ビット列に基づいてNALユニットの開始位置を検出できない。従って、受信装置200は、NALユニットの開始位置を取得するために、アクセスユニットの先頭NALユニットから順に、NALユニットのサイズ分だけデータの読出すことでポインタをシフトさせていく必要がある。
但し、MMTにおけるMPU又はMovie Fragmentのヘッダにおいて、サブサンプル単位のサイズが示され、サブサンプルがスライス前データ又はスライスセグメントに対応する場合には、受信装置200は、サブサンプルのサイズ情報に基づいて各NALユニットの開始位置を特定できる。そのため、送信装置100は、サブサンプル単位の情報がMPU又はMovie Fragmentに存在するかどうかを示す情報を、MMTにおけるMPTなどの、受信装置200がデータの受信開始時に取得する情報に含めてもよい。
なお、MPUのデータはMP4フォーマットをベースに拡張したものである。MP4においては、H.264又はH.265のSPS及びPPSなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードとがある。また、このモードを特定するための情報がSampleEntryのエントリ名として示される。格納可能なモードが用いられており、パラメータセットがサンプルに含まれる場合には、受信装置200は、上述した方法によりパラメータセットを取得する。
一方、格納できないモードが用いられている場合には、パラメータセットは、SampleEntry内のDecoder Specific Informationとして格納される、又は、パラメータセット用のストリームを用いて格納される。ここで、パラメータセット用のストリームは一般的には使用されていないので、送信装置100は、Decoder Specific Informationにパラメータセットを格納することが望ましい。この場合には、受信装置200は、MMTパケットにおいてMPUのメタデータ、又は、Movie Fragmentのメタデータとしてとして送信されるSampleEntryを解析して、アクセスユニットが参照するパラメータセットを取得する。
パラメータセットがサンプルデータとして格納される場合には、受信装置200は、SampleEntryを参照せずにサンプルデータのみを参照すれば復号に必要なパラメータセットが取得できる。このとき、送信装置100は、SampleEntryにパラメータセットを格納しなくてもよい。こうすることで、送信装置100は、異なるMPUにおいて同一のSampleEntryを用いることができるので、MPU生成時の送信装置100の処理負荷を低減できる。さらに、受信装置200がSampleEntry内のパラメータセットを参照する必要がなくなるというメリットがある。
または、送信装置100は、SampleEntryにデフォルトのパラメータセットを1つ格納し、アクセスユニットが参照するパラメータセットをサンプルデータに格納してもよい。従来のMP4においては、SampleEntryにパラメータセットを格納するのが一般的であったため、SampleEntryにパラメータセットが存在しない場合、再生を停止する受信装置が存在する可能性がある。上記の方法を用いることで、この問題を解決できる。
または、送信装置100は、デフォルトのパラメータセットとは異なるパラメータセットが使用される場合にのみ、サンプルデータにパラメータセットを格納してもよい。
なお、両モード共に、パラメータセットをSampleEntryに格納することは可能であるため、送信装置100は、パラメータセットを常にVisualSampleEntryに格納し、受信装置200は常にVisualSampleEntryからパラメータセットを取得してもよい。
なお、MMT規格においては、Moov及びMoofなどMP4のヘッダ情報は、MPUメタデータ、或いはムービーフラグメントメタデータとして伝送されるが、送信装置100は、MPUメタデータ、および、ムービーフラグメントメタデータを必ずしも送信しなくてもよい。さらに、受信装置200は、ARIB(Association of Radio Industries and Businesses)規格のサービス、アセットのタイプ、又は、MPUメタの伝送有無などに基づいて、サンプルデータ内にSPS及びPPSが格納されるかどうかを判定することも可能である。
図17は、スライスセグメント前データ及び各スライスセグメントが、それぞれ異なるData unitに設定される場合の例を示す図である。
図17に示す例では、スライスセグメント前データ、及びスライスセグメント1からスライスセグメント4までのデータサイズは、それぞれLength#1からLength#5である。MMTパケットのヘッダに含まれるFragmentation indicator、Fragment counter、及び、Offsetの各フィールド値は図中に示す通りである。
ここで、Offsetは、ペイロードデータが属するサンプル(アクセスユニット又はピクチャ)の符号化データの先頭から、当該MMTパケットに含まれるペイロードデータ(符号化データ)の先頭バイトまでのビット長(オフセット)を示すオフセット情報である。なお、Fragment counterの値はフラグメントの総数から1を減算した値から開始するとして説明するが、他の値から開始してもよい。
図18は、Data unitがフラグメント化される場合の例を示す図である。図18に示す例では、スライスセグメント1が3つのフラグメントに分割され、それぞれMMTパケット#2からMMTパケット#4に格納される。このときも、各フラグメントのデータサイズを、それぞれLength#2_1からLength#2_3とすると、各フィールドの値は図中に示す通りである。
このように、スライスセグメントなどのデータ単位がData unitに設定される場合、アクセスユニットの先頭、及びスライスセグメントの先頭は、MMTパケットヘッダのフィールド値に基づいて以下のように決定できる。
Offsetの値が0であるパケットにおけるペイロードの先頭は、アクセスユニットの先頭である。
Offsetの値が0とは異なる値であり、かつ、Fragmentation indcatorno値が00又は01であるパケットのペイロードの先頭が、スライスセグメントの先頭である。
また、Data unitのフラグメント化が発生せず、パケットロスも発生しない場合には、受信装置200は、アクセスユニットの先頭を検出した後に取得したスライスセグメントの数に基づいて、MMTパケットに格納されるスライスセグメントのインデックス番号を特定できる。
また、スライスセグメント前データのData unitがフラグメント化される場合においても、同様に、受信装置200は、アクセスユニット、及びスライスセグメントの先頭を検出できる。
また、パケットロスが発生した場合、又は、スライスセグメント前データに含まれるSPS、PPS及びSEIが別々のData unitに設定された場合においても、受信装置200は、MMTヘッダの解析結果に基づいてスライスセグメントの先頭データを格納したMMTパケットを特定し、その後、スライスセグメントのヘッダを解析することで、ピクチャ(アクセスユニット)内におけるスライスセグメント又はタイルの開始位置を特定できる。スライスヘッダの解析に係る処理量は小さく、処理負荷は問題とならない。
このように、複数のスライスセグメントの複数の符号化データの各々は、1以上のパケットに格納されるデータの単位である基本データ単位(Data unit)と一対一で対応付けられている。また、複数の符号化データの各々は、1以上のMMTパケットに格納される。
各MMTパケットのヘッダ情報は、Fragmentation indicator(識別情報)及びOffset(オフセット情報)を含む。
受信装置200は、受信装置200は、値が00又は01であるFragmentation indicatorが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。具体的には、値が0でないOffsetと、値が00又は01であるFragmentation indicatorとが含まれるヘッダ情報を有するパケットに含まれるペイロードデータの先頭を、各スライスセグメントの符号化データの先頭であると判定する。
また、図17の例では、Data unitの先頭は、アクセスユニットの先頭、又は、スライスセグメントの先頭のいずれかであり、Fragmentation indicatorの値は00又は01である。さらに、受信装置200は、NALユニットのタイプを参照して、Data Unitの先頭がアクセスユニットデリミタ、又は、スライスセグメントのどちらであるかを判定することで、Offsetを参照せずに、アクセスユニットの先頭、又は、スライスセグメントの先頭を検出することも可能である。
このように、送信装置100が、NALユニットの先頭が必ずMMTパケットのペイロードの先頭から開始されるようにパケット化を行うことで、スライスセグメント前データが複数のData unitに分割される場合も含めて、受信装置200は、Fragmentation indicator及びNALユニットヘッダを解析することにより、アクセスユニット、又は、スライスセグメントの先頭を検出できる。NALユニットのタイプは、NALユニットヘッダの先頭バイトに存在する。従って、受信装置200は、MMTパケットのヘッダ部を解析する際に、追加で1バイト分のデータを解析することによりNALユニットのタイプが取得できる。
オーディオの場合には、受信装置200は、アクセスユニットの先頭が検出できればよく、Fragmentation indicatorの値が00又は01であるかどうかに基づいて判定すればよい。
また、上述したように、分割復号ができるように符号化された符号化データをMPEG-2 TSのPESパケットに格納する場合には、送信装置100は、data alignment記述子を用いることが可能である。以下、符号化データのPESパケットへの格納方法の例について詳細に説明する。
例えば、HEVCにおいては、送信装置100は、data alignment記述子を用いることにより、PESパケットに格納されるデータがアクセスユニット、スライスセグメント、及び、タイルのいずれであるかを示すことができる。HEVCにおけるアラインメントのタイプは、次のように規定されている。
アラインメントのタイプ=8は、HEVCのスライスセグメントを示す。アラインメントのタイプ=9は、HEVCのスライスセグメント又はアクセスユニットを示す。アラインメントのタイプ=12は、HEVCのスライスセグメント又はタイルを示す。
よって、送信装置100は、例えば、タイプ9を用いることで、PESパケットのデータがスライスセグメント又はスライスセグメント前データのいずれかであることを示すことができる。スライスセグメントではなく、スライスを示すタイプも別途規定されているため、送信装置100は、スライスセグメントではなくスライスを示すタイプを使用してもよい。
また、PESパケットのヘッダに含まれるDTS及びPTSは、アクセスユニットの先頭データを含むPESパケットにおいてのみ設定される。従って、受信装置200は、タイプが9であり、かつ、PESパケットにDTS又はPTSのフィールドが存在すれば、PESパケットにはアクセスユニット全体、又は、アクセスユニットにおける先頭の分割単位が格納されると判定できる。
また、送信装置100は、アクセスユニットの先頭データを含むPESパケットを格納するTSパケットの優先度を示すtransport_priorityなどのフィールドを用いて、受信装置200がパケットに含まれるデータを区別できるようにしてもよい。また、受信装置200は、PESパケットのペイロードがアクセスユニットデリミタであるかどうかを解析することでパケットに含まれるデータを判定してもよい。また、PESパケットヘッダのdata_alignment_indicatorは、これらのタイプに従ってPESパケットにデータが格納されているかどうかを示す。このフラグ(data_alignment_indicator)が1にセットされていれば、PESパケットに格納されているデータはdata alignment記述子に示されるタイプに従うことが保証される。
また、送信装置100は、スライスセグメントなどの分割復号可能な単位でPESパケット化する場合にのみdata alignment記述子を使用してもよい。これにより、受信装置200は、data alignment記述子が存在する場合には、符号化データが分割復号可能な単位でPESパケット化されていると判断でき、data alignment記述子が存在しなければ、符号化データがアクセスユニット単位でPESパケット化されていると判断できる。なお、data_alignment_indicatorが1にセットされており、data alignment記述子が存在しない場合には、PESパケット化の単位がアクセスユニットであることはMPEG-2 TS規格において規定されている。
受信装置200は、PMT内にdata alignment記述子が含まれていれば、分割復号可能な単位でPESパケット化されていると判定し、パケット化された単位に基づいて、各復号部への入力データを生成することができる。また、受信装置200は、PMT内にdata alignment記述子が含まれておらず、番組情報、又はその他の記述子の情報に基づいて、符号化データの並列復号が必要と判定される場合には、スライスセグメントのスライスヘッダなどを解析することにより、各復号部への入力データを生成する。また、符号化データを単一の復号部により復号可能である場合には、受信装置200は、アクセスユニット全体のデータを当該の復号部で復号する。なお、符号化データがスライスセグメント又はタイルなどの分割復号可能な単位から構成されるかどうかを示す情報が、PMTの記述子などにより別途示されている場合、受信装置200は、当該記述子の解析結果に基づいて符号化データを並列復号できるかどうかを判定してもよい。
また、PESパケットのヘッダに含まれるDTS及びPTSは、アクセスユニットの先頭データを含むPESパケットにおいてのみ設定されるため、アクセスユニットが分割されてPESパケット化される場合には、2番目以降のPESパケットにはアクセスユニットのDTS及びPTSを示す情報は含まれない。従って、復号処理を並列に行う場合、各復号部204A~204D及び表示部205は、アクセスユニットの先頭データを含むPESパケットのヘッダに格納されるDTS及びPTSを使用する。
(実施の形態2)
実施の形態2では、MMTにおいて、NALサイズフォーマットのデータをMP4フォーマットベースのMPUに格納する方法について説明する。なお、以下では、一例として、MMTに用いられるMPUへの格納方法について説明するが、このような格納方法は、同じMP4フォーマットベースであるDASHにも適用可能である。
実施の形態2では、MMTにおいて、NALサイズフォーマットのデータをMP4フォーマットベースのMPUに格納する方法について説明する。なお、以下では、一例として、MMTに用いられるMPUへの格納方法について説明するが、このような格納方法は、同じMP4フォーマットベースであるDASHにも適用可能である。
[MPUへの格納方法]
MP4フォーマットでは、複数のアクセスユニットをまとめて、一つのMP4ファイルに格納する。MMTに用いられるMPUは、メディア毎のデータが一つのMP4ファイルに格納され、データには任意の数のアクセスユニットを含むことができる。MPUは、単体で復号可能な単位であるため、例えば、MPUにはGOP単位のアクセスユニットが格納される。
MP4フォーマットでは、複数のアクセスユニットをまとめて、一つのMP4ファイルに格納する。MMTに用いられるMPUは、メディア毎のデータが一つのMP4ファイルに格納され、データには任意の数のアクセスユニットを含むことができる。MPUは、単体で復号可能な単位であるため、例えば、MPUにはGOP単位のアクセスユニットが格納される。
図19は、MPUの構成を示す図である。MPUの先頭は、ftyp、mmpu、及びmoovであり、これらは、まとめてMPUメタデータと定義される。moovには、ファイルに共通の初期化情報、及びMMTヒントトラックが格納される。
また、moofには、サンプルやサブサンプル毎の初期化情報及びサイズ、提示時刻(PTS)及び復号時刻(DTS)を特定できる情報(sample_duration、sample_size、sample_composition_time_offset)、並びにデータの位置を示すdata_offsetなどが格納される。
また、複数のアクセスユニットは、それぞれサンプルとしてmdat(mdat box)に格納される。moof及びmdatのうちサンプルを除くデータは、ムービーフラグメントメタデータ(以降では、MFメタデータと記載する。)と定義され、mdatのサンプルデータは、メディアデータと定義される。
図20は、MFメタデータの構成を示す図である。図20に示されるように、MFメタデータは、より詳細には、moof box(moof)の、type、length、及びdataと、mdat box(mdat)のtype及びlengthとからなる。
アクセスユニットをMP4データに格納する際には、H.264やH.265のSPS、及び、PPSなどのパラメータセットをサンプルデータとして格納可能なモードと、格納できないモードがある。
ここで、上記格納できないモードにおいては、パラメータセットは、moovにおけるSampleEntryのDecoder Specific Informationに格納される。また、上記格納できるモードにおいては、パラメータセットは、サンプル内に含められる。
MPUメタデータ、MFメタデータ、及びメディアデータは、それぞれMMTペイロードに格納され、これらのデータを識別可能な識別子として、MMTペイロードのヘッダには、フラグメントタイプ(FT)が格納される。FT=0は、MPUメタデータであることを示し、FT=1は、MFメタデータであることを示し、FT=2はメディアデータであることを示す。
なお、図19では、MPUメタデータ単位及びMFメタデータ単位がデータユニットとしてMMTペイロードに格納される例が図示されているが、ftyp、mmpu、moov、及びmoofなどの単位がデータユニットとして、データユニット単位でMMTペイロードに格納されてもよい。同様に、図19では、サンプル単位がデータユニットとしてMMTペイロードに格納される例が図示されている。しかしながら、サンプル単位やNALユニット単位でデータユニットが構成され、このようなデータユニットがデータユニット単位でMMTペイロードに格納されてもよい。このようなデータユニットがさらにフラグメントされた単位でMMTペイロードに格納されてもよい。
[従来の送信方法と課題]
従来、複数のアクセスユニットをMP4フォーマットにカプセル化する際、MP4に格納されるサンプルがすべて揃った時点でmoov及びmoofが作成されていた。
従来、複数のアクセスユニットをMP4フォーマットにカプセル化する際、MP4に格納されるサンプルがすべて揃った時点でmoov及びmoofが作成されていた。
MP4フォーマットを放送などを用いてリアルタイムに伝送する場合、例えば1つのMP4ファイルに格納するサンプルがGOP単位であるとすると、GOP単位の時間サンプルが蓄積された後にmoov及びmoofが作成されるため、カプセル化に伴う遅延が発生する。このような送信側におけるカプセル化により、End-to-End遅延が常にGOP単位時間分長くなる。これにより、リアルタイムにサービスの提供を行うことが困難となり、特に、ライブコンテンツが伝送される場合には視聴者に対するサービスの劣化につながる。
図21は、データの送信順序を説明するための図である。MMTを放送に適用する場合、図21の(a)に示されるように、MPUの構成順にMMTパケットに載せて送信(MMTパケット#1、#2、#3、#4、#5、#6の順に送信)すると、MMTパケットの送信にはカプセル化による遅延が生じる。
このカプセル化による遅延を防ぐために、図21の(b)に示されるように、MPUメタデータ及びMFメタデータなどのMPUヘッダ情報を送らない(パケット#1及び#2を送信せず、パケット#3-#6をこの順に送信する)方法が提案されている。また、図20の(c)に示されるように、MPUヘッダ情報の作成を待たずにメディアデータを先に送信し、メディアデータの送信後にMPUヘッダ情報を送信する(#3-#6、#1、#2の順で送信する)方法が考えられる。
受信装置は、MPUヘッダ情報が送信されていない場合、MPUヘッダ情報を用いずに復号する、また、受信装置は、MPUヘッダ情報がメディアデータに対して後送りされている場合には、MPUヘッダ情報の取得を待ってから復号する。
しかしながら、従来のMP4準拠の受信装置では、MPUヘッダ情報を用いずに復号することが保証されていない。また、受信装置が特別な処理によりMPUヘッダを用いずに復号を行う場合に従来の送信方法を用いると復号処理が煩雑となり、実時間の復号が困難となる可能性が高い。また、受信装置がMPUヘッダ情報の取得を待ってから復号を行う場合には、受信装置がヘッダ情報を取得するまでの間メディアデータのバッファリングが必要であるが、バッファモデルが規定されておらず、復号が保証されていなかった。
そこで、実施の形態2に係る送信装置は、図20の(d)に示されるように、MPUメタデータに共通の情報のみを格納することで、MPUメタデータをメディアデータより先に送信する。そして、実施の形態2に係る送信装置は、生成に遅延が発生するMFメタデータをメディアデータより後に送信する。これにより、メディアデータの復号を保証できる送信方法或いは受信方法を提供する。
以下、図21の(a)-(d)の各送信方法を用いた場合の受信方法について説明する。
図21に示される各送信方法では、まず、MPUメタデータ、MFUメタデータ、メディアデータの順にMPUデータを構成する。
MPUデータを構成した後、送信装置が図21の(a)に示されるように、MPUメタデータ、MFメタデータ、メディアデータの順にデータを送信する場合、受信装置は、下記の(A-1)及び(A-2)のいずれかの方法で復号を行うことができる。
(A-1)受信装置は、MPUヘッダ情報(MPUメタデータ及びMFメタデータ)を取得後、MPUヘッダ情報を用いてメディアデータを復号する。
(A-2)受信装置は、MPUヘッダ情報を用いずに、メディアデータを復号する。
このような方法はいずれも、送信側でカプセル化による遅延が発生するが、受信装置において、MPUヘッダ取得のためにメディアデータをバッファリングする必要がない利点がある。バッファリングをしない場合、バッファリングのためのメモリの搭載の必要はなく、さらにバッファリング遅延は発生しない。また、(A-1)の方法は、MPUヘッダ情報を用いて復号を行うため、従来の受信装置にも適用可能ある。
送信装置が図21の(b)に示されるように、メディアデータのみを送信する場合、受信装置は下記の(B-1)の方法で復号を行うことができる。
(B-1)受信装置は、MPUヘッダ情報を用いずに、メディアデータを復号する。
また、図示しないが、図21の(b)のメディアデータの送信よりも先にMPUメタデータが送信されている場合、下記の(B-2)の方法で復号を行うことができる。
(B-2)受信装置は、MPUメタデータを用いてメディアデータを復号する。
上記(B-1)及び(B-2)の方法はいずれも、送信側でカプセル化による遅延が発生せず、かつ、MPUヘッダ取得のためにメディアデータをバッファリングする必要がない点が利点である。しかしながら、(B-1)及び(B-2)の方法はいずれも、MPUヘッダ情報を用いた復号を行わないため、復号に特別な処理が必要となる可能性がある。
送信装置が図21の(c)に示されるように、メディアデータ、MPUメタデータ、MFメタデータの順にデータを送信する場合、受信装置は下記の(C-1)及び(C-2)のいずれかの方法で復号を行うことができる。
(C-1)受信装置は、MPUヘッダ情報(MPUメタデータ及びMFメタデータ)を取得後、メディアデータを復号する。
(C-2)受信装置は、MPUヘッダ情報を用いずに、メディアデータを復号する。
上記(C-1)の方法が用いられる場合は、MPUヘッダ情報の取得のためにメディアデータをバッファリングする必要がある。これに対し、上記(C-2)の方法が用いられる場合は、MPUヘッダ情報の取得のためのバッファリングを行う必要はない。
また、上記(C-1)及び(C-2)のいずれの方法も、送信側においてカプセル化による遅延は発生しない。また、(C-2)の方法は、MPUヘッダ情報を用いないため、特別な処理が必要となる可能性がある。
送信装置が、図21の(d)に示されるように、MPUメタデータ、メディアデータ、MFメタデータの順にデータを送信する場合、受信装置は、下記の(D-1)及び(D-2)のいずれかの方法で復号を行うことができる。
(D-1)受信装置は、MPUメタデータを取得後、さらにMFメタデータを取得し、その後、メディアデータを復号する。
(D-2)受信装置は、MPUメタデータを取得後、MFメタデータを用いずにメディアデータを復号する。
上記(D-1)の方法が用いられる場合は、MFメタデータ取得のためにメディアデータをバッファリングする必要があるが、上記(D-2)の方法の場合は、MFメタデータ取得のためのバッファリングを行う必要はない。
上記(D-2)の方法は、MFメタデータを用いた復号を行わないため、特別な処理が必要となる可能性がある。
以上説明したように、MPUメタデータ及びMFメタデータを用いて復号できる場合は、従来のMP4受信装置でも復号できるというメリットがある。
なお、図21では、MPUデータは、MPUメタデータ、MFUメタデータ、メディアデータの順に構成されており、moofにおいては、この構成に基づいてサンプルやサブサンプル毎の位置情報(オフセット)が定められている。また、MFメタデータには、mdat boxにおけるメディアデータ以外のデータ(boxのサイズやタイプ)も含まれている。
このため、受信装置がMFメタデータに基づいてメディアデータを特定する場合には、受信装置は、データが送信された順番にかかわらず、MPUデータを構成した際の順番にデータを再構成した後、MPUメタデータのmoov或いはMFメタデータのmoofを用いて復号を行う。
なお、図21では、MPUデータは、MPUメタデータ、MFUメタデータ、メディアデータの順に構成されるが、図21とは異なる順番でMPUデータが構成され、位置情報(オフセット)が定められてもよい。
例えば、MPUデータがMPUメタデータ、メディアデータ、MFメタデータの順に構成され、MFメタデータにおいて負の位置情報(オフセット)が示されてもよい。この場合も、データが送信される順番にかかわらず、受信装置は、送信側においてMPUデータが構成された際の順番にデータを再構成した後、moov或いはmoofを用いて復号を行う。
なお、送信装置は、MPUデータを構成する際の順番を示す情報をシグナリングし、受信装置は、シグナリングされた情報に基づいてデータを再構成してもよい。
以上説明したように、受信装置は、図21の(d)に示されるように、パケット化されたMPUメタデータ、パケット化されたメディアデータ(サンプルデータ)、パケット化されたMFメタデータをこの順に受信する。ここで、MPUメタデータは、第1のメタデータの一例であり、MFメタデータは、第2のメタデータの一例である。
次に、受信装置は、受信されたMPUメタデータ、受信されたMFメタデータ、及び受信されたサンプルデータを含むMPUデータ(MP4フォーマットのファイル)を再構成する。そして、再構成されたMPUデータに含まれるサンプルデータを、MPUメタデータ及びMFメタデータを用いて復号する。MFメタデータは、送信側においてサンプルデータの生成後にのみ生成可能なデータ(例えば、mboxに格納されるlength)を含むメタデータである。
なお、上記受信装置の動作は、より詳細には、受信装置を構成する各構成要素によって行われる。例えば、受信装置は、上記データの受信を行う受信部と、上記MPUデータの再構成を行う再構成部と、上記MPUデータの復号を行う復号部とを備える。なお、受信部、生成部、及び復号部のそれぞれは、マイクロコンピュータ、プロセッサ、専用回路などによって実現される。
[ヘッダ情報を用いずに復号を行う方法]
次に、ヘッダ情報を用いずに復号を行う方法について説明する。ここでは、送信側でヘッダ情報を送るか送らないかにかかわらず、受信装置においてヘッダ情報を用いずに復号する方法を説明する。すなわち、この方法は、図21を用いて説明したいずれの送信方法を用いた場合においても適用可能である。ただし、一部の復号方法は、特定の送信方法の場合にのみ適用可能な復号方法である。
次に、ヘッダ情報を用いずに復号を行う方法について説明する。ここでは、送信側でヘッダ情報を送るか送らないかにかかわらず、受信装置においてヘッダ情報を用いずに復号する方法を説明する。すなわち、この方法は、図21を用いて説明したいずれの送信方法を用いた場合においても適用可能である。ただし、一部の復号方法は、特定の送信方法の場合にのみ適用可能な復号方法である。
図22は、ヘッダ情報を用いずに復号を行う方法の例を示す図である。図22では、メディアデータのみが含まれるMMTペイロード及びMMTパケットのみが図示されており、MPUメタデータやMFメタデータが含まれるMMTペイロード及びMMTパケットは図示されていない。また、以下の図22の説明においては、同じMPUに属するメディアデータは連続して伝送されるものとする。また、メディアデータとしてペイロードにサンプルが格納されている場合を例に説明するが、以下の図22の説明においては、当然NALユニットが格納されていてもよいし、フラグメントされたNALユニットが格納されていてもよい。
メディアデータを復号するためには、受信装置は、まず、復号に必要な初期化情報を取得しなければならない。また、メディアがビデオであれば、受信装置は、サンプル毎の初期化情報を取得したり、ランダムアクセス単位であるMPUの開始位置を特定し、サンプル及びNALユニットの開始位置を取得しなければならない。また、受信装置は、それぞれサンプルの復号時刻(DTS)や提示時刻(PTS)を特定する必要がある。
そこで、受信装置は、例えば、下記の方法を用いてヘッダ情報を用いずに復号を行うことができる。なお、ペイロードにNALユニット単位またはNALユニットをフラグメントした単位が格納される場合は、下記説明において「サンプル」を、「サンプルにおけるNALユニット」に読み替えればよい。
<ランダムアクセス(=MPUの先頭サンプルを特定)>
ヘッダ情報が送信されない場合に、受信装置がMPUの先頭サンプルを特定するには、下記方法1と方法2がある。なお、ヘッダ情報が送信される場合には、方法3を用いることができる。
ヘッダ情報が送信されない場合に、受信装置がMPUの先頭サンプルを特定するには、下記方法1と方法2がある。なお、ヘッダ情報が送信される場合には、方法3を用いることができる。
[方法1]受信装置は、MMTパケットヘッダにおいて、‘RAP_flag=1’であるMMTパケットに含まれるサンプルを取得する。
[方法2]受信装置は、MMTペイロードヘッダにおいて、‘sample number=0’であるサンプルを取得する。
[方法3]受信装置は、メディアデータの前及び後ろの少なくともどちらか一方に、MPUメタデータ及びMFメタデータの少なくともどちらか一方が送信されている場合、受信装置は、MMTペイロードヘッダにおけるフラグメントタイプ(FT)がメディアデータへ切り替わったMMTペイロードに含まれるサンプルを取得する。
なお、方法1及び方法2において、1つのペイロードに異なるMPUに属する複数のサンプルが混在する場合、どのNALユニットがランダムアクセスポイント(RAP_flag=1或いはsample number=0)であるか判定不能である。このため、1つのペイロードに異なるMPUのサンプルを混在させないといった制約、または、1つのペイロードに異なるMPUのサンプルが混在する場合は、最後(或いは最初)のサンプルがランダムアクセスポイントである場合に、RAP_flagを1とするといった制約などが必要である。
また、受信装置がNALユニットの開始位置を取得するためには、サンプルの先頭NALユニットから順に、NALユニットのサイズ分だけデータの読出しポインタをシフトさせていく必要がある。
データがフラグメントされている場合は、受信装置は、fragment_indicatorやfragment_numberを参照することで、データユニットを特定できる。
<サンプルのDTSの決定>
サンプルのDTSの決定方法には、下記方法1と方法2がある。
サンプルのDTSの決定方法には、下記方法1と方法2がある。
[方法1]受信装置は、予測構造に基づいて先頭サンプルのDTSを決定する。ただし、この方法には符号化データの解析が必要であり、実時間での復号が困難である可能性があるため、次の方法2が望ましい。
[方法2]受信装置は、先頭サンプルのDTSを別途送信し、送信された先頭サンプルのDTSを取得する。先頭サンプルのDTSの送信方法は、例えば、MPU先頭サンプルのDTSを、MMT-SIを用いて送信する方法や、サンプル毎のDTSをMMTパケットヘッダ拡張領域を用いて送信する方法などがある。なお、DTSは、絶対値でもよいし、PTSに対する相対値であってもよい。また、送信側において先頭サンプルのDTSが含まれているかどうかをシグナリングしてもよい。
なお、方法1、方法2ともに、以降のサンプルのDTSは、固定フレームレートであるとして算出する。
サンプル毎のDTSをパケットヘッダに格納する方法として、拡張領域を用いる以外に、MMTパケットヘッダにおける32bitのNTPタイムスタンプフィールドに、当該MMTパケットに含まれるサンプルのDTSを格納する方法がある。1つのパケットヘッダのビット数(32bit)でDTSを表現できない場合は、DTSは、複数のパケットヘッダを用いて表現されてもよい。また、DTSは、パケットヘッダのNTPタイムスタンプフィールドと拡張領域とを組み合わせて表現されてもよい。DTS情報が含まれない場合は既知の値(例えばALL0)とされる。
<サンプルのPTSの決定>
受信装置は、先頭サンプルのPTSを、MPUに含まれるアセット毎のMPUタイムスタンプ記述子から取得する。受信装置は、以降のサンプルPTSについては、固定フレームレートであるものとして、POC等のサンプルの表示順を示すパラメータなどから算出する。このように、ヘッダ情報を用いずにDTS、及びPTSを算出するためには、固定フレームレートによる送信が必須となる。
受信装置は、先頭サンプルのPTSを、MPUに含まれるアセット毎のMPUタイムスタンプ記述子から取得する。受信装置は、以降のサンプルPTSについては、固定フレームレートであるものとして、POC等のサンプルの表示順を示すパラメータなどから算出する。このように、ヘッダ情報を用いずにDTS、及びPTSを算出するためには、固定フレームレートによる送信が必須となる。
また、MFメタデータが送信されている場合、受信装置は、MFメタデータに示される先頭サンプルからのDTSやPTSの相対時刻情報と、MPUタイムスタンプ記述子に示されるMPU先頭サンプルのタイムスタンプの絶対値とからDTS及びPTSの絶対値を算出できる。
なお、符号化データ解析してDTS及びPTSを算出する際には、受信装置は、アクセスユニットに含まれるSEI情報を用いて算出してもよい。
<初期化情報(パラメータセット)>
[ビデオの場合]
ビデオの場合、パラメータセットは、サンプルデータに格納される。また、MPUメタデータ及びMFメタデータが送信されない場合は、サンプルデータのみを参照することにより復号に必要なパラメータセットを取得できることを保証する。
[ビデオの場合]
ビデオの場合、パラメータセットは、サンプルデータに格納される。また、MPUメタデータ及びMFメタデータが送信されない場合は、サンプルデータのみを参照することにより復号に必要なパラメータセットを取得できることを保証する。
また、図21の(a)及び(d)のように、MPUメタデータがメディアデータよりも先に送信される場合、SampleEntryにはパラメータセットは格納しないと規定されてもよい。この場合、受信装置は、SampleEntryのパラメータセットは参照せずにサンプル内のパラメータセットのみを参照する。
また、MPUメタデータがメディアデータよりも先に送信される場合、SampleEntryにはMPUに共通のパラメータセットやデフォルトのパラメータセットが格納され、受信装置は、SampleEntryのパラメータセット及びサンプル内のパラメータセットを参照してもよい。SampleEntryにパラメータセットが格納されることにより、SampleEntryにパラメータセットが存在しないと再生できない従来の受信装置でも復号を行うことが可能となる。
[オーディオの場合]
オーディオの場合、復号にはLATMヘッダが必要であり、MP4では、LATMヘッダがサンプルエントリに含められることが必須である。しかし、ヘッダ情報が送信されない場合は、受信装置がLATMヘッダを取得することは困難であるため、別途SIなどの制御情報にLATMヘッダが含められる。なお、LATMヘッダは、メッセージ、テーブル、または記述子に含められてもよい。なお、LATMヘッダはサンプル内に含められることもある。
オーディオの場合、復号にはLATMヘッダが必要であり、MP4では、LATMヘッダがサンプルエントリに含められることが必須である。しかし、ヘッダ情報が送信されない場合は、受信装置がLATMヘッダを取得することは困難であるため、別途SIなどの制御情報にLATMヘッダが含められる。なお、LATMヘッダは、メッセージ、テーブル、または記述子に含められてもよい。なお、LATMヘッダはサンプル内に含められることもある。
受信装置は、復号開始前にSIなどからLATMヘッダを取得し、オーディオの復号を開始する。或いは、図21の(a)及び図21の(d)に示されるように、MPUメタデータがメディアデータよりも先に送信される場合は、受信装置は、LATMヘッダをメディアデータより先に受信可能である。したがって、MPUメタデータがメディアデータよりも先に送信される場合は、従来の受信装置を用いても復号を行うことが可能となる。
<その他>
送信順序や送信順序のタイプは、MMTパケットヘッダやペイロードヘッダ、或いは、MPTやその他のテーブル、メッセージ、記述子などの制御情報として通知されてもよい。なお、ここでの送信順序のタイプとは、例えば、図21の(a)~(d)の4つのタイプの送信順序であり、それぞれのタイプを識別するための識別子が復号開始前に取得できる場所に格納されればよい。
送信順序や送信順序のタイプは、MMTパケットヘッダやペイロードヘッダ、或いは、MPTやその他のテーブル、メッセージ、記述子などの制御情報として通知されてもよい。なお、ここでの送信順序のタイプとは、例えば、図21の(a)~(d)の4つのタイプの送信順序であり、それぞれのタイプを識別するための識別子が復号開始前に取得できる場所に格納されればよい。
また、送信順序のタイプは、オーディオとビデオとで異なるタイプが用いられてもよいし、オーディオとビデオとで共通のタイプが用いられてもよい。具体的には、例えば、オーディオは、図21の(a)に示されるように、MPUメタデータ、MFメタデータ、メディアデータの順番で送信され、ビデオは、図21の(d)に示されるように、MPUメタデータ、メディアデータ、MFメタデータの順番で送信されてもよい。
以上説明したような方法により、受信装置は、ヘッダ情報を用いずに復号を行うことが可能である。また、MPUメタデータがメディアデータよりも先に送信されている場合(図21の(a)及び図21の(d))は、従来の受信装置でも復号を行うことが可能になる。
特に、MFメタデータがメディアデータより後に送信されること(図21の(d))により、カプセル化による遅延を発生させず、かつ従来の受信装置でも復号を行うことが可能となる。
[送信装置の構成及び動作]
次に、送信装置の構成及び動作について説明する。図23は、実施の形態2に係る送信装置のブロック図であり、図24は、実施の形態2に係る送信方法のフローチャートである。
次に、送信装置の構成及び動作について説明する。図23は、実施の形態2に係る送信装置のブロック図であり、図24は、実施の形態2に係る送信方法のフローチャートである。
図23に示されるように、送信装置15は、符号化部16と、多重化部17と、送信部18とを備える。
符号化部16は、符号化対象のビデオまたはオーディオを、例えば、H.265に従い符号化することで符号化データを生成する(S10)。
多重化部17は、符号化部16により生成された符号化データを多重化(パケット化)する(S11)。具体的には、多重化部17は、MP4フォーマットのファイルを構成する、サンプルデータ、MPUメタデータ、及び、MFメタデータ、のそれぞれをパケット化する。サンプルデータは、映像信号または音声信号が符号化されたデータであり、MPUメタデータは、第1のメタデータの一例であり、MFメタデータは、第2のメタデータの一例である。第1のメタデータと第2のメタデータとは、いずれもサンプルデータの復号に用いられるメタデータであるが、これらの違いは、第2のメタデータがサンプルデータの生成後にのみ生成可能なデータを含むことである。
ここで、サンプルデータの生成後にのみ生成可能なデータは、例えば、MP4フォーマットにおけるmdatに格納されるサンプルデータ以外のデータ(mdatのヘッダ内のデータ。つまり、図20に図示されるtype及びlength。)である。ここで、第2のメタデータには、このデータのうち少なくとも一部であるlengthが含まれればよい。
送信部18は、パケット化したMP4フォーマットのファイルを送信する(S12)。送信部18は、例えば、図21の(d)に示される方法でMP4フォーマットのファイルを送信する。つまり、パケット化されたMPUメタデータ、パケット化されたサンプルデータ、パケット化されたMFメタデータをこの順に送信する。
なお、符号化部16、多重化部17、及び送信部18のそれぞれは、マイクロコンピュータ、プロセッサ、または専用回路などによって実現される。
[受信装置の構成]
次に、受信装置の構成及び動作について説明する。図25は、実施の形態2に係る受信装置のブロック図である。
次に、受信装置の構成及び動作について説明する。図25は、実施の形態2に係る受信装置のブロック図である。
図25に示されるように、受信装置20は、パケットフィルタリング部21と、送信順序タイプ判別部22と、ランダムアクセス部23と、制御情報取得部24と、データ取得部25と、PTS、DTS算出部26と、初期化情報取得部27と、復号命令部28と、復号部29と、提示部30とを備える。
[受信装置の動作1]
まず、メディアがビデオである場合に、受信装置20が、MPU先頭位置及びNALユニット位置を特定するための動作について説明する。図26は、受信装置20のこのような動作のフローチャートである。なお、ここでは、MPUデータの送信順序タイプは、送信装置15(多重化部17)によってSI情報に格納されているとする。
まず、メディアがビデオである場合に、受信装置20が、MPU先頭位置及びNALユニット位置を特定するための動作について説明する。図26は、受信装置20のこのような動作のフローチャートである。なお、ここでは、MPUデータの送信順序タイプは、送信装置15(多重化部17)によってSI情報に格納されているとする。
まず、パケットフィルタリング部21は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部22は、パケットフィルタリングによって得られるSI情報を解析して、MPUデータの送信順序タイプを取得する(S21)。
次に、送信順序タイプ判別部22は、パケットフィルタリング後のデータにMPUヘッダ情報(MPUメタデータ或いはMFメタデータの少なくとも一方)が含まれているか否かを判定(判別)する(S22)。MPUヘッダ情報(が含まれている場合(S22でYes)には、ランダムアクセス部23は、MMTペイロードヘッダのフラグメントタイプがメディアデータへ切り替わることを検出することで、MPU先頭サンプルを特定する(S23)。
一方、MPUヘッダ情報が含まれていない場合(S22でNo)には、ランダムアクセス部23は、MMTパケットヘッダのRAP_flag或いはMMTペイロードヘッダのsample numberに基づいてMPU先頭サンプルを特定する(S24)。
また、送信順序タイプ判別部22は、パケットフィルタリングされたデータに、MFメタデータが含まれているか否かを判定する(S25)。MFメタデータが含まれていると判定された場合(S25でYes)には、データ取得部25は、MFメタデータに含まれるサンプル、サブサンプルのオフセット、及びサイズ情報に基づいてNALユニットを読み出すことによりNALユニットを取得する(S26)。一方、MFメタデータが含まれていないと判定された場合(S25でNo)には、データ取得部25は、サンプルの先頭NALユニットから順に、NALユニットのサイズのデータを読み出すことでNALユニットを取得する(S27)。
なお、受信装置20は、ステップS22において、MPUヘッダ情報が含まれていると判別された場合でも、ステップS23ではなくステップS24の処理を用いてMPU先頭サンプルを特定してもよい。また、MPUヘッダ情報が含まれていると判別された場合に、ステップS23の処理とステップS24の処理とが併用されてもよい。
また、受信装置20は、ステップS25において、MFメタデータが含まれていると判定された場合でも、ステップS26の処理を用いずにステップS27の処理を用いてNALユニットを取得してもよい。また、MFメタデータが含まれていると判定された場合に、ステップS23の処理とステップS24の処理とが併用されてもよい。
また、ステップS25においてMFメタデータが含まれていると判定された場合であって、MFデータがメディアデータより後に送信されている場合が想定される。この場合、受信装置20は、メディアデータをバッファリングし、MFメタデータを取得するまで待ってからステップS26の処理を行ってもよいし、受信装置20は、MFメタデータの取得を待たずにステップS27の処理を行うか否かを判定してもよい。
例えば、受信装置20は、メディアデータをバッファリングすることが可能なバッファサイズのバッファを保有しているかどうかに基づいてMFメタデータの取得を待つか否かを判定してもよい。また、受信装置20は、End-to-End遅延が小さくなるかどうかに基づいて、MFメタデータの取得を待つか否かを判定してもよい。また、受信装置20は、主としてステップS26の処理を用いて復号処理を実施し、パケットロスなどが発生したときの処理モードの場合にステップS27の処理を用いてもよい。
なお、送信順序タイプがあらかじめ定められている場合は、ステップS22及びステップS26は省略されてもよいし、この場合、受信装置20は、バッファサイズやEnd-to-End遅延を考慮して、MPU先頭サンプルの特定方法、及び、NALユニットの特定方法を決定してもよい。
なお、あらかじめ送信順序タイプが既知である場合は、受信装置20において送信順序タイプ判別部22は、不要である。
また、上記図26においては説明されないが、復号命令部28は、PTS、DTS算出部26において算出されたPTS及びDTS、初期化情報取得部27において取得された初期化情報に基づいて、データ取得部において取得されたデータを復号部29に出力する。復号部29は、データを復号し、提示部30は、復号後のデータを提示する。
[受信装置の動作2]
次に、受信装置20が、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作について説明する。図27は、このような動作のフローチャートである。
次に、受信装置20が、送信順序タイプに基づいて初期化情報を取得し、初期化情報に基づいてメディアデータを復号する動作について説明する。図27は、このような動作のフローチャートである。
まず、パケットフィルタリング部21は、受信したファイルに対してパケットフィルタリングを行う。送信順序タイプ判別部22は、パケットフィルタリングによって得られるSI情報を解析し、送信順序タイプを取得する(S301)。
次に、送信順序タイプ判別部22は、MPUメタデータが送信されているか否かを判定する(S302)。MPUメタデータが送信されていると判定された場合(S302でYes)、送信順序タイプ判別部22は、ステップS301の解析の結果、MPUメタデータがメディアデータより先に送信されているかどうかを判定する(S303)。MPUメタデータがメディアデータより先に送信されている場合(S303でYes)、初期化情報取得部27は、MPUメタデータに含まれる共通な初期化情報、及び、サンプルデータの初期化情報に基づいてメディアデータを復号する(S304)。
一方、MPUメタデータがメディアデータより後に送信されていると判定された場合(S303でNo)には、データ取得部25は、MPUメタデータが取得されるまでメディアデータをバッファリングし(S305)、MPUメタデータが取得された後にステップS304の処理を実施する。
また、ステップS302において、MPUメタデータが送信されていないと判定された場合(S302でNo)には、初期化情報取得部27は、サンプルデータの初期化情報のみに基づいてメディアデータを復号する(S306)。
なお、送信側においてサンプルデータの初期化情報に基づく場合のみメディアデータの復号が保証されている場合は、ステップS302、及びステップS303の判定に基づく処理を行わず、ステップS306の処理が用いられる。
また、受信装置20は、ステップS305の前に、メディアデータをバッファリングするか否かの判定を行ってもよい。この場合、受信装置20は、メディアデータをバッファリングすると判定した場合にはステップS305の処理へ移行し、メディアデータをバッファリングしないと判定した場合には、ステップS306の処理へ移行する。メディアデータをバッファリングするか否かの判定は、受信装置20のバッファサイズ、占有量に基づいて行われてもよいし、例えば、End-to-End遅延の小さい方が選択されるなど、End-to-End遅延を考慮して判定が行われてもよい。
[受信装置の動作3]
ここでは、MFメタデータがメディアデータよりも後に送信される場合(図21の(c)、及び図21の(d))における送信方法や受信方法の詳細について説明する。以下では、図21の(d)の場合を例に説明する。なお、送信においては、図21の(d)の方法のみが用いられ、送信順序タイプのシグナリングは行われないものとする。
ここでは、MFメタデータがメディアデータよりも後に送信される場合(図21の(c)、及び図21の(d))における送信方法や受信方法の詳細について説明する。以下では、図21の(d)の場合を例に説明する。なお、送信においては、図21の(d)の方法のみが用いられ、送信順序タイプのシグナリングは行われないものとする。
先述のとおり、図21の(d)に示されるように、MPUメタデータ、メディアデータ、MFメタデータの順でデータを送信する場合、
(D-1)受信装置20は、MPUメタデータを取得した後、さらにMFメタデータを取得した後にメディアデータを復号する。
(D-1)受信装置20は、MPUメタデータを取得した後、さらにMFメタデータを取得した後にメディアデータを復号する。
(D-2)受信装置20は、MPUメタデータを取得した後、MFメタデータを用いずにメディアデータを復号する。
の2通りの復号方法が可能である。
の2通りの復号方法が可能である。
ここで、D-1は、MFメタデータ取得のためのメディアデータのバッファリングが必要となるが、MPUヘッダ情報を用いて復号を行うことができるため、従来のMP4準拠の受信装置で復号可能となる。また、D-2は、MFメタデータ取得のためのメディアデータのバッファリングを必要としないが、MFメタデータを用いて復号できないため、復号に特別な処理が必要となる。
また、図21の(d)の方法は、MFメタデータは、メディアデータより後で送信されるため、カプセル化による遅延は発生せず、End-to-End遅延を低減できるという利点を有する。
受信装置20は、受信装置20の能力や、受信装置20が提供するサービス品質に応じて、上記2通りの復号方法を選択することができる。
送信装置15は、受信装置20における復号動作において、バッファのオーバーフローやアンダーフローの発生を低減して復号できることを保証しなければならない。D-1の方法を用いて復号する場合のデコーダモデルを規定するための要素としては、例えば下記のパラメータを用いることができる。
・MPUを再構成するためのバッファサイズ(MPUバッファ)
例えば、バッファサイズ=最大レート×最大MPU時間×αであり、最大レートとは、符号化データのプロファイル、レベルの上限レート+MPUヘッダのオーバーヘッドである。また、最大MPU時間は、1MPU=1GOP(ビデオ)とした場合のGOPの最大時間長である。
例えば、バッファサイズ=最大レート×最大MPU時間×αであり、最大レートとは、符号化データのプロファイル、レベルの上限レート+MPUヘッダのオーバーヘッドである。また、最大MPU時間は、1MPU=1GOP(ビデオ)とした場合のGOPの最大時間長である。
ここで、オーディオは、上記ビデオに共通のGOP単位としてもよいし、別の単位でもよい。αは、オーバーフローを起こさないためのマージンであり、最大レート×最大MPU時間に対して、乗算されてもよいし、加算されてもよい。乗算される場合は、α≧1であり、加算される場合は、α≧0である。
・MPUバッファへデータが入力されてから復号されるまでの復号遅延時間の上限(MPEG-TSのSTDにおけるTSTD_delay)
例えば、送信時には、最大MPU時間、及び、復号遅延時間の上限値を考慮して、受信機におけるMPUデータの取得完了時刻<=DTSとなるようにDTSが設定される。
例えば、送信時には、最大MPU時間、及び、復号遅延時間の上限値を考慮して、受信機におけるMPUデータの取得完了時刻<=DTSとなるようにDTSが設定される。
また、送信装置15は、D-1の方法を用いて復号する場合のデコーダモデルに従い、DTS及びPTSを付与してもよい。これにより、送信装置15は、D-1の方法を用いて復号を行う受信装置の当該復号を保証すると同時に、D-2の方法を用いて復号が行われる場合に必要な補助情報を送信してもよい。
例えば、送信装置15は、D-2の方法を用いて復号する場合のデコーダバッファにおけるプリバッファリング時間をシグナリングすることにより、D-2の方法を用いて復号する受信装置の動作を保証できる。
プリバッファリング時間は、メッセージ、テーブル、記述子などのSI制御情報に含められてもよいし、MMTパケット、MMTペイロードのヘッダに含められてもよい。また、符号化データ内のSEIが上書きされてもよい。D-1の方法を用いて復号するためのDTS及びPTSは、MPUタイムスタンプ記述子、SampleEntryに格納され、D-2の方法を用いて復号するためのDTS及びPTS、またはプリバッファリング時間がSEIにおいて記述されてもよい。
受信装置20は、当該受信装置20がMPUヘッダを用いたMP4準拠の復号動作のみに対応している場合は、復号方法D-1を選択し、D-1およびD-2の両方に対応している場合は、どちらか一方を選択してもよい。
送信装置15は、一方(本説明では、D-1)の復号動作を保証できるようにDTS、及びPTSを付与し、さらに一方の復号動作を補助するための補助情報を送信してもよい。
また、D-2の方法が用いられる場合、D-1の方法が用いられる場合と比較して、MFメタデータのプリバッファリングに起因する遅延により、End-to-End遅延が大きくなる可能性が高い。したがって、受信装置20は、End-to-End遅延を小さくしたいときは、D-2の方法を選択して復号してもよい。例えば、受信装置20は、常にEnd-to-End遅延を削減したい場合に、常にD-2の方法を用いてもよい。また、受信装置20は、ライブコンテンツや、選局、ザッピング動作など、低遅延で提示したい、低遅延提示モードで動作している場合のみD-2の方法を用いてもよい。
図28は、このような受信方法のフローチャートである。
まず、受信装置20は、MMTパケットを受信し、MPUデータを取得する(S401)。そして、受信装置20(送信順序タイプ判別部22)は、当該プログラムを低遅延提示モードで提示するかどうかの判定を行う(S402)。
プログラムを低遅延提示モードで提示しない場合(S402でNo)、受信装置20(ランダムアクセス部23及び初期化情報取得部27)は、ヘッダ情報を用いてランダムアクセス、初期化情報を取得する(S405)。また、受信装置20(PTS、DTS算出部26、復号命令部28、復号部29、提示部30)は、送信側で付与されたPTS、DTSに基づいてデコード及び提示処理を行う(S406)。
一方、プログラムを低遅延提示モードで提示する場合(S402でYes)、受信装置20(ランダムアクセス部23及び初期化情報取得部27)は、ヘッダ情報を用いない復号方法を用いて、ランダムアクセス、初期化情報を取得する(S403)。また、受信装置20は、送信側で付与されたPTS、DTS及びヘッダ情報を用いずに復号するための補助情報に基づいてデコード及び提示処理を行う(S404)。なお、ステップS403、及びステップS404において、MPUメタデータを用いて処理が行われてもよい。
[補助データを用いた送受信方法]
以上、MFメタデータがメディアデータより後に送信される場合(図21の(c)、及び図21の(d)の場合)における送受信動作について説明した。次に、送信装置15がMFメタデータの一部の機能を有する補助データを送信することにより、より早く復号を開始でき、End-to-End遅延を削減できる方法について説明する。ここでは、図21の(d)に示される送信方法に基づいて補助データがさらに送信される例について説明されるが、補助データを用いる方法は、図21の(a)~(c)に示される送信方法においても適用可能である。
以上、MFメタデータがメディアデータより後に送信される場合(図21の(c)、及び図21の(d)の場合)における送受信動作について説明した。次に、送信装置15がMFメタデータの一部の機能を有する補助データを送信することにより、より早く復号を開始でき、End-to-End遅延を削減できる方法について説明する。ここでは、図21の(d)に示される送信方法に基づいて補助データがさらに送信される例について説明されるが、補助データを用いる方法は、図21の(a)~(c)に示される送信方法においても適用可能である。
図29の(a)は、図21の(d)に示される方法を用いて送信されたMMTパケットを示す図である。つまり、データは、MPUメタデータ、メディアデータ、MFメタデータの順で送信される。
ここで、サンプル#1、サンプル#2、サンプル#3、サンプル#4はメディアデータに含まれるサンプルである。なお、ここではメディアデータは、サンプル単位でMMTパケットに格納される例について説明されるが、メディアデータは、NALユニット単位でMMTパケットに格納されてもよいし、NALユニットを分割した単位で格納されてもよい。なお、複数のNALユニットがアグリゲーションされてMMTパケットに格納される場合もある。
先述のD-1で説明したように、図21の(d)に示される方法の場合、つまり、MPUメタデータ、メディアデータ、MFメタデータの順でデータが送信される場合、MPUメタデータを取得後、さらにMFメタデータを取得し、その後、メディアデータを復号する方法がある。このようなD-1の方法では、MFメタデータ取得のためのメディアデータのバッファリングが必要となるが、MPUヘッダ情報を用いて復号が行われるため、従来のMP4準拠の受信装置にもD-1の方法は適用可能である利点がある。一方で、受信装置20は、MFメタデータ取得まで、復号開始を待たなければならない欠点がある。
これに対し、図29の(b)に示されるように、補助データを用いる手法においては、MFメタデータより先に、補助データが送信される。
MFメタデータには、ムービーフラグメントに含まれる全てのサンプルのDTSやPTS、オフセットやサイズを示す情報が含まれている。これに対し、補助データには、ムービーフラグメントに含まれるサンプルのうち、一部のサンプルのDTSやPTS、オフセットやサイズを示す情報が含まれる。
例えば、MFメタデータには、すべてのサンプル(サンプル#1-サンプル#4)の情報が含まれるのに対し、補助データには一部のサンプル(サンプル#1-#2)の情報が含まれる。
図29の(b)に示される場合は、補助データが用いられることでサンプル#1、及びサンプル#2の復号が可能となるため、D-1の送信方法に対して、End-to-End遅延が小さくなる。なお、補助データには、どのようにサンプルの情報が組み合わされて含められてもよいし、補助データは、繰り返し送信されてもよい。
例えば、図29の(c)において、Aのタイミングで補助情報を送信する場合は、送信装置15は、補助情報にサンプル#1の情報を含め、Bのタイミングで補助情報を送信する場合は、補助情報にサンプル#1及びサンプル#2の情報を含める。送信装置15は、Cのタイミングで補助情報を送信する場合は、補助情報にはサンプル#1、サンプル#2、及びサンプル#3の情報を含める。
なお、MFメタデータには、サンプル#1、サンプル#2、サンプル#3、及び、サンプル#4の情報(ムービーフラグメントの中の全サンプルの情報)が含まれる。
補助データは、必ずしも生成後、ただちに送信される必要はない。
なお、MMTパケットやMMTペイロードのヘッダにおいては、補助データが格納されていることを示すタイプが指定される。
例えば、補助データがMMTペイロードにMPUモードを用いて格納される場合は、fragment_typeフィールド値(例えば、FT=3)として、補助データであることを示すデータタイプが指定される。補助データは、moofの構成に基づくデータであってもよいし、その他の構成であってもよい。
補助データが、MMTペイロードに制御信号(記述子、テーブル、メッセージ)として格納される場合は、補助データであることを示す記述子タグ、テーブルID、及びメッセージIDなどが指定される。
また、MMTパケットやMMTペイロードのヘッダにPTSまたはDTSが格納されてもよい。
[補助データの生成例]
以下、送信装置がmoofの構成に基づいて補助データを生成する例について説明する。図30は、送信装置がmoofの構成に基づいて補助データを生成する例を説明するための図である。
以下、送信装置がmoofの構成に基づいて補助データを生成する例について説明する。図30は、送信装置がmoofの構成に基づいて補助データを生成する例を説明するための図である。
通常のMP4では、図20に示されるように、ムービーフラグメントに対してmoofが作成される。moofには、ムービーフラグメントに含まれるサンプルのDTSやPTS、オフセットやサイズを示す情報が含まれている。
ここでは、送信装置15は、MPUを構成するサンプルデータの中で、一部のサンプルデータのみを用いてMP4(MP4ファイル)を構成し、補助データを生成する。
例えば、図30の(a)に示されるように、送信装置15は、MPUを構成するサンプル#1-#4のうち、サンプル#1のみを用いてMP4を生成し、そのうち、moof+mdatのヘッダを補助データとする。
次に、図30の(b)に示されるように、送信装置15は、MPUを構成するサンプル#1-#4のうち、サンプル#1及びサンプル#2を用いてMP4を生成し、そのうち、moof+mdatのヘッダを次の補助データとする。
次に、図30の(c)に示されるように、送信装置15は、MPUを構成するサンプル#1-#4のうち、サンプル#1、サンプル#2、及びサンプル#3を用いてMP4を生成し、そのうち、moof+mdatのヘッダを次の補助データとする。
次に、図30の(d)に示されるように、送信装置15は、MPUを構成するサンプル#1-#4のうち、すべてのMP4を生成し、そのうち、moof+mdatのヘッダがムービーフラグメントメタデータとなる。
なお、ここでは、送信装置15は、1サンプル毎に補助データを生成したが、Nサンプル毎に補助データを生成してもよい。Nの値は任意の数字であり、例えば、一つのMPUを送信するときに補助データをM回送信する場合、N=全サンプル/Mとされてもよい。
なお、moofにおけるサンプルのオフセットを示す情報は、後続のサンプル数のサンプルエントリ領域がNULL領域として確保された後のオフセット値であってもよい。
なお、MFメタデータをフラグメントする構成となるように補助データが生成されてもよい。
[補助データを用いた受信動作例]
図30で説明したように生成された補助データの受信について説明する。図31は、補助データの受信を説明するための図である。なお、図31の(a)では、MPUを構成するサンプル数は30であり、10サンプル毎に補助データが生成され、送信されるものとする。
図30で説明したように生成された補助データの受信について説明する。図31は、補助データの受信を説明するための図である。なお、図31の(a)では、MPUを構成するサンプル数は30であり、10サンプル毎に補助データが生成され、送信されるものとする。
図30の(a)において、補助データ#1には、サンプル#1-#10、補助データ#2には、サンプル#1-#20、MFメタデータには、サンプル#1-#30のサンプル情報がそれぞれ含まれる。
なお、サンプル#1-#10、サンプル#11-#20、及びサンプル#21-#30は、一つのMMTペイロードに格納されているが、サンプル単位やNAL単位で格納されてもよいし、フラグメントやアグリゲーションした単位で格納されてもよい。
受信装置20は、MPUメタ、サンプル、MFメタ、及び補助データのパケットをそれぞれ受信する。
受信装置20は、サンプルデータを受信順に(後ろに)連結し、最新の補助データを受信した後に、これまでの補助データを更新する。また、受信装置20は、最後に補助データをMFメタデータに置き換えることにより、完全なMPUを構成できる。
受信装置20は、補助データ#1を受信した時点では、図31の(b)の上段のようにデータを連結し、MP4を構成する。これにより、受信装置20は、MPUメタデータ、及び補助データ#1の情報を用いてサンプル#1-#10をパースすることができ、補助データに含まれるPTS、DTS、オフセット、及びサイズの情報に基づいて復号を行うことができる。
また、受信装置20は、補助データ#2を受信した時点では、図31の(b)の中段のようにデータを連結し、MP4を構成する。これにより、受信装置20は、MPUメタデータ、及び補助データ#2の情報を用いてサンプル#1-#20をパースすることができ、補助データに含まれるPTS、DTS、オフセット、サイズの情報に基づいて復号を行うことができる。
また、受信装置20は、MFメタデータを受信した時点では、図31の(b)の下段のようにデータを連結し、MP4を構成する。これにより、受信装置20は、MPUメタデータ、及びMFメタデータを用いてサンプル#1-#30をパースすることができ、MFメタデータに含まれるPTS、DTS、オフセット、及びサイズの情報に基づいて復号を行うことができる。
補助データが無い場合は、受信装置20は、MFメタデータの受信後にはじめてサンプルの情報を取得できるため、MFメタデータの受信後に復号を開始する必要があった。しかしながら、送信装置15が補助データを生成し、送信することにより、受信装置20は、MFメタデータの受信を待たずに、補助データを用いてサンプルの情報を取得できるため、復号開始時間を早めることができる。さらに、送信装置15が図30を用いて説明したmoofに基づく補助データを生成することにより、受信装置20は、従来のMP4のパーサーをそのまま利用し、パースすることが可能である。
また、新たに生成する補助データやMFメタデータは、過去に送信した補助データと重複するサンプルの情報を含む。このため、パケットロスなどにより過去の補助データを取得できなかった場合でも、新たに取得する補助データやMFメタデータを用いることで、MP4を再構成し、サンプルの情報(PTS、DTS、サイズ、及びオフセット)を取得することが可能である。
なお、補助データは、必ずしも過去のサンプルデータの情報を含む必要はない。たとえば、補助データ#1は、サンプルデータ#1-#10に対応し、補助データ#2は、サンプルデータ#11-#20に対応してもよい。例えば、図31の(c)に示されるように、送信装置15は、完全なMFメタデータをデータユニットとして、データユニットをフラグメントした単位を補助データとして順次送出してもよい。
また、送信装置15は、パケットロス対策のために、補助データを繰り返し伝送してもよいし、MFメタデータを繰り返し伝送してもよい。
なお、補助データが格納されるMMTパケット及びMMTペイロードには、MPUメタデータ、MFメタデータ、及びサンプルデータと同様に、MPUシーケンス番号、及びアセットIDが含まれる。
以上のような補助データを用いた受信動作について図32のフローチャートを用いて説明する。図32は、補助データを用いた受信動作のフローチャートである。
まず、受信装置20は、MMTパケットを受信し、パケットヘッダやペイロードヘッダを解析する(S501)。次に、受信装置20は、フラグメントタイプが補助データか、MFメタデータかを解析し(S502)、フラグメントタイプが補助データである場合には、過去の補助データを上書きして更新する(S503)。このとき、同一MPUの過去の補助データがない場合には、受信装置20は、受信した補助データをそのまま新規の補助データとする。そして、受信装置20は、MPUメタデータ、補助データ、及びサンプルデータに基づき、サンプルを取得し、復号を行う(S507)。
一方、フラグメントタイプがMFメタデータである場合には、受信装置20は、ステップS505において、過去の補助データをMFメタデータで上書きする(S505)。そして、受信装置20は、MPUメタデータ、MFメタデータ、及びサンプルデータに基づきサンプルを完全なMPUの形で取得し、復号を行う(S506)。
なお、図32において図示されないが、ステップS502において、受信装置20は、フラグメントタイプがMPUメタデータである場合には、データをバッファに格納し、サンプルデータである場合には、サンプル毎に後ろに連結したデータをバッファに格納する。
パケットロスにより補助データが取得できなかった場合は、受信装置20は、最新の補助データにより上書きを行うか、あるいは過去の補助データを用いることによりサンプルを復号することができる。
なお、補助データの送出周期及び送出回数はあらかじめ定められた値であってもよい。送出周期や回数(カウント、カウンドダウン)の情報は、データと一緒に送信されてもよい。例えば、データユニットヘッダに、送出周期、送出回数、及びinitial_cpb_removal_delayなどのタイムスタンプが格納されてもよい。
MPUの初めのサンプルの情報を含む補助データをinitial_cpb_removal_delayより先に1回以上送信することにより、CPBバッファモデルに従うことが可能となる。このとき、MPUタイムスタンプ記述子には、picture timing SEIに基づいた値を格納される。
なお、このような補助データが使用される受信動作における伝送方式は、MMT方式に限定されず、MPEG-DASHなど、ISOBMFFファイルフォーマットで構成されるパケットをストリーミング伝送する場合などに適用可能である。
[1つのMPUが複数のムービーフラグメントで構成される場合の送信方法]
上記図19以降の説明においては、1つのMPUが、1つのムービーフラグメントで構成されたが、ここでは、1つのMPUが複数のムービーフラグメントで構成される場合について説明する。図33は、複数のムービーフラグメントで構成されるMPUの構成を示す図である。
上記図19以降の説明においては、1つのMPUが、1つのムービーフラグメントで構成されたが、ここでは、1つのMPUが複数のムービーフラグメントで構成される場合について説明する。図33は、複数のムービーフラグメントで構成されるMPUの構成を示す図である。
図33では、1つのMPUに格納されるサンプル(#1-#6)は、2つのムービーフラグメントに分けて格納される。第1のムービーフラグメントは、サンプル#1-#3に基づいて生成され、対応するmoofボックスが生成される。第2のムービーフラグメントは、サンプル#4-#6に基づいて生成され、対応するmoofボックスが生成される。
第1のムービーフラグメントにおけるmoofボックス及びmdatボックスのヘッダは、ムービーフラグメントメタデータ#1としてMMTペイロード及びMMTパケットに格納される。一方、第2のムービーフラグメントにおけるmoofボックス及びmdatボックスのヘッダは、ムービーフラグメントメタデータ#2としてMMTペイロード及びMMTパケットに格納される。なお、図33において、ムービーフラグメントメタデータが格納されたMMTペイロードは、ハッチングされている。
なお、MPUを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、MPUを構成するサンプル数をGOP単位のサンプル数とし、GOP単位の2分の1のサンプル数をムービーフラグメントとして、2つのムービーフラグメントが構成されてもよい。
なお、ここでは、一つのMPUに2つのムービーフラグメント(moofボックス及びmdatボックス)を含む例を示すが、1つのMPUに含むムービーフラグメントは2つでなくとも、3つ以上であってもよい。また、ムービーフラグメントに格納するサンプルは等分したサンプル数でなく、任意のサンプル数に分割してもよい。
なお、図33では、MPUメタデータ単位及びMFメタデータ単位がそれぞれデータユニットとしてMMTペイロードに格納されている。しかしながら、送信装置15は、ftyp、mmpu、moov、及びmoofなどの単位をデータユニットとして、データユニット単位でMMTペイロードに格納してもよいし、データユニットをフラグメントした単位でMMTペイロードに格納してもよい。また、送信装置15は、データユニットをアグリゲーションした単位でMMTペイロードに格納してもよい。
また、図33では、サンプルは、サンプル単位でMMTペイロードに格納されている。しかしながら、送信装置15は、サンプル単位でなくともNALユニット単位または複数のNALユニットをまとめた単位でデータユニットを構成し、データユニット単位でMMTペイロードに格納してもよい。また、送信装置15は、データユニットをフラグメントした単位でMMTペイロードに格納してもよいし、データユニットをアグリゲーションした単位でMMTペイロードに格納してもよい。
なお、図33では、moof#1、mdat#1、moof#2、mdat#2の順にMPUが構成され、moof#1には、対応するmdat#1が後ろについているものとしてoffsetが付与されている。しかしながら、mdat#1がmoof#1より前についているものしてoffsetが付与されてもよい。ただし、この場合、moof+mdatの形でムービーフラグメントメタデータを生成することはできず、moof及びmdatのヘッダはそれぞれ別々に伝送される。
次に、図33で説明した構成のMPUが伝送される場合のMMTパケットの送信順序について説明する。図34は、MMTパケットの送信順序を説明するための図である。
図34の(a)は、図33に示されるMPUの構成順序でMMTパケットを送信する場合の送信順序を示している。図34の(a)は、具体的には、MPUメタ、MFメタ#1、メディアデータ#1(サンプル#1-#3)、MFメタ#2、メディアデータ#2(サンプル#4-#6)の順に送信する例を示す。
図34の(b)は、MPUメタ、メディアデータ#1(サンプル#1-#3)、MFメタ#1、メディアデータ#2(サンプル#4-#6)、MFメタ#2の順に送信する例を示す。
図34の(c)は、メディアデータ#1(サンプル#1-#3)、MPUメタ、MFメタ#1、メディアデータ#2(サンプル#4-#6)、MFメタ#2の順に送信する例を示す。
MFメタ#1は、サンプル#1-#3を用いて生成され、MFメタ#2はサンプル#4-#6を用いて生成される。このため、図34の(a)の送信方法が用いられる場合には、サンプルデータの送信にはカプセル化による遅延が発生する。
これに対し、図34の(b)及び図34の(c)の送信方法が用いられる場合には、MFメタを生成するのを待たずにサンプルを送信可能であるため、カプセル化による遅延は発生せず、End-to-End遅延を低減できる。
また、図34の(a)送信順序においても、1つのMPUが複数のムービーフラグメントに分割され、MFメタに格納されるサンプル数が図19の場合に対して小さくなっているため、図19の場合よりもカプセル化による遅延量を小さくすることができる。
なお、ここで示した方法以外に、例えば、送信装置15は、MFメタ#1及びMFメタ#2を連結し、MPUの最後にまとめて送信してもよい。この場合、異なるムービーフラグメントのMFメタがアグリゲーションされて、一つのMMTペイロードに格納されてもよい。また、異なるMPUのMFメタがまとめてアグリゲーションされてMMTペイロードに格納されてもよい。
[1つのMPUが複数のムービーフラグメントで構成される場合の受信方法]
ここでは、図34の(b)で説明した送信順序で送信されたMMTパケットを受信して復号する受信装置20の動作例について説明する。図35及び図36は、このような動作例を説明するための図である。
ここでは、図34の(b)で説明した送信順序で送信されたMMTパケットを受信して復号する受信装置20の動作例について説明する。図35及び図36は、このような動作例を説明するための図である。
受信装置20は、図35に示されるような送信順序で送信された、MPUメタ、サンプル、及びMFメタを含むMMTパケットをそれぞれ受信する。サンプルデータは、受信順に連結される。
受信装置20は、MFメタ#1を受信した時刻であるT1に、図36の(1)に示されるようにデータを連結し、MP4を構成する。これにより、受信装置20は、MPUメタデータ、及びMFメタ#1の情報に基づいてサンプル#1-#3を取得することができ、MFメタに含まれるPTS、DTS、オフセット、及びサイズの情報に基づいて復号を行うことができる。
また、受信装置20は、MFメタ#2を受信した時刻であるT2に、図36の(2)に示されるようにデータを連結し、MP4を構成する。これにより、受信装置20は、MPUメタデータ、及びMFメタ#2の情報を基づいてサンプル#4-#6を取得することができ、MFメタのPTS、DTS、オフセット、及びサイズの情報に基づいて復号を行うことができる。また、受信装置20は、図36の(3)に示されるようにデータを連結し、MP4を構成することでMFメタ#1及びMFメタ#2の情報に基づいてサンプル#1-#6を取得してもよい。
1つのMPUが複数のムービーフラグメントに分割することで、MPUの中で初めのMFメタを取得するまでの時間が短縮されるため、復号開始時間を早めることができる。また、復号前のサンプルを蓄積するためのバッファサイズを小さくすることができる。
なお、送信装置15は、ムービーフラグメントにおける初めのサンプルを送信(或いは受信)してからムービーフラグメントに対応するMFメタを送信(或いは受信)するまでの時間が、エンコーダで指定されるinitial_cpb_removal_delayより短い時間となるようにムービーフラグメントの分割単位を設定してもよい。このように設定することにより、受信バッファはcpbバッファに従うことができ、低遅延の復号を実現できる。この場合、PTS及びDTSにはinitial_cpb_removal_delayに基づいた絶対時刻を用いることができる。
また、送信装置15は、ムービーフラグメントの分割を等間隔、或いは、後続のムービーフラグメントを前のムービーフラグメントより短い間隔で分割してもよい。これにより、受信装置20は、サンプルの復号前に必ず当該サンプルの情報を含むMFメタを受信することができ、連続した復号が可能となる。
PTS、及びDTSの絶対時刻の算出方法は、下記の2通りの方法を用いることができる。
(1)PTS及びDTSの絶対時刻は、MFメタ#1やMFメタ#2の受信時刻(T1或いはT2)、及びMFメタに含まれるPTS及びDTSの相対時刻に基づいて決定される。
(2)PTS及びDTSの絶対時刻は、MPUタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びMFメタに含まれるPTS及びDTSの相対時刻に基づいて決定される。
また、(2-A)送信装置15がシグナリングする絶対時刻は、エンコーダから指定されるinitial_cpb_removal_delayに基づいて算出された絶対時刻であってもよい。
また、(2-B)送信装置15がシグナリングする絶対時刻は、MFメタの受信時刻の予測値に基づいて算出された絶対時刻であってもよい。
なお、MFメタ#1及びMFメタ#2は、繰り返し伝送されてもよい。MFメタ#1及びMFメタ#2が繰り返し伝送されることにより、受信装置20は、MFメタをパケットロス等により取得できなかった場合でも、もう一度取得することができる。
ムービーフラグメントを構成するサンプルを含むMFUのペイロードヘッダには、ムービーフラグメントの順番を示す識別子を格納することができる。一方、ムービーフラグメントを構成するMFメタの順番を示す識別子はMMTペイロードには含まれない。このため、受信装置20は、packet_sequence_numberでMFメタの順番を識別する。或いは、送信装置15は、MFメタが何番目のムービーフラグメントに属するかを示す識別子を、制御情報(メッセージ、テーブル、記述子)、MMTヘッダ、MMTペイロードヘッダ、またはデータユニットヘッダに格納してシグナリングしてもよい。
なお、送信装置15は、MPUメタ、MFメタ、及びサンプルを、あらかじめ定められた所定の送信順序で送信し、受信装置20は、あらかじめ定められた所定の送信順序に基づいて受信処理を実施してもよい。また、送信装置15は、送信順序をシグナリングし、シグナリング情報に基づいて受信装置20が受信処理を選択(判断)してもよい。
上記のような受信方法について、図37を用いて説明する。図37は、図35及び図36で説明した受信方法の動作のフローチャートである。
まず、受信装置20は、MMTペイロードに示されるフラグメントタイプにより、ペイロードに含まれるデータが、MPUメタデータ、MFメタデータであるか、サンプルデータ(MFU)であるかを判別(識別)する(S601、S602)。データがサンプルデータである場合には、受信装置20は、サンプルをバッファリングし、当該サンプルに対応するMFメタデータの受信、及び復号開始を待つ(S603)。
一方、ステップS602において、データがMFメタデータである場合には、受信装置20は、MFメタデータよりサンプルの情報(PTS、DTS、位置情報、及びサイズ)を取得し、取得したサンプルの情報に基づいてサンプルを取得し、PTS及びDTSに基づいてサンプルを復号、提示する(S604)。
なお、図示されないが、データがMPUメタデータである場合、MPUメタデータには、復号に必要な初期化情報が含まれている。このため、受信装置20はこれを蓄積し、ステップS604においてサンプルデータの復号に用いる。
なお、受信装置20は、受信したMPUのデータ(MPUメタデータ、MFメタデータ、及びサンプルデータ)を蓄積装置に蓄積する場合には、図19または図33で説明した、MPUの構成に並び替えた後に、蓄積する。
なお、送信側においては、MMTパケットには、同一のパケットIDを持つパケットに対して、パケットシーケンス番号を付与する。このとき、MPUメタデータ、MFメタデータ、サンプルデータを含むMMTパケットが送信順序に並び替えられた後にパケットシーケンス番号が付与されてもよいし、並び替える前の順序でパケットシーケンス番号が付与されてもよい。
並び替える前の順序でパケットシーケンス番号が付与される場合には、受信装置20において、パケットシーケンス番号に基づいて、データをMPUの構成順序に並び替えることができ、蓄積が容易となる。
[アクセスユニットの先頭及びスライスセグメントの先頭を検出する方法]
MMTパケットヘッダ、及びMMTペイロードヘッダの情報に基づき、アクセスユニットの先頭やスライスセグメントの先頭を検出する方法について説明する。
MMTパケットヘッダ、及びMMTペイロードヘッダの情報に基づき、アクセスユニットの先頭やスライスセグメントの先頭を検出する方法について説明する。
ここでは、非VCL NALユニット(アクセスユニットデリミタ、VPS、SPS、PPS、及びSEIなど)を、まとめてデータユニットとしてMMTペイロードに格納する場合、及び、非VCL NALユニットをそれぞれデータユニットとし、データユニットをアグリゲーションして1つのMMTペイロードに格納する場合の2つの例を示す。
図38は、非VCL NALユニットを、個別にデータユニットとし、アグリゲーションする場合を示す図である。
図38の場合、アクセスユニットの先頭は、fragment_type値がMFUであるMMTパケットであり、かつ、aggregation_flag値が1であり、かつoffset値が0であるデータユニットを含むMMTペイロードの先頭データである。このとき、Fragmentation_indicator値は0である。
また、図38の場合、スライスセグメントの先頭は、fragment_type値がMFUであるMMTパケットであり、かつaggregation_flag値が0、fragmentation_indicator値が00或いは01であるMMTペイロードの先頭データである。
図39は、非VCL NALユニットを、まとめてデータユニットとする場合を示す図である。なお、パケットヘッダのフィールド値は、図17(または図18)で示した通りである。
図39の場合、アクセスユニットの先頭は、Offset値が0であるパケットにおけるペイロードの先頭データが、アクセスユニットの先頭となる。
また、図39の場合、スライスセグメントの先頭は、Offset値が0とは異なる値であり、fragmentation indicator値が00或いは01であるパケットのペイロードの先頭データが、スライスセグメントの先頭となる。
[パケットロスが発生した場合の受信処理]
通常、パケットロスが発生する環境において、MP4形式のデータを伝送する場合、受信装置20は、ALFEC(Application Layer FEC)や、パケット再送制御等によりパケットを復元する。
通常、パケットロスが発生する環境において、MP4形式のデータを伝送する場合、受信装置20は、ALFEC(Application Layer FEC)や、パケット再送制御等によりパケットを復元する。
しかし、放送のようなストリーミングにおいてAL-FECを用いられない場合にパケットロスが発生した場合には、パケットを復元できない。
受信装置20は、パケットロスによりデータが失われた後、再び映像や音声の復号を再開させる必要がある。そのためには、受信装置20は、アクセスユニットやNALユニットの先頭を検出し、アクセスユニットやNALユニットの先頭から復号を開始する必要がある。
しかし、MP4形式のNALユニットの先頭には、スタートコードがついていないため、受信装置20は、ストリームを解析しても、アクセスユニットやNALユニットの先頭を検出できない。
図40は、パケットロスが発生した場合の受信装置20の動作のフローチャートである。
受信装置20は、MMTパケットやMMTペイロードのヘッダにおけるPacketsequence numberや、packet counter、fragment counterなどによりパケットロスを検出し(S701)、前後の関係から、どのパケットが消失したかを判定する(S702)。
受信装置20は、パケットロスが発生していないと判定された場合(S702でNo)には、MP4ファイルを構成し、アクセスユニット或いはNALユニットを復号する(S703)。
受信装置20は、パケットロスが発生したと判定された場合(S702でYes)には、パケットロスしたNALユニットに相当するNALユニットをダミーデータにより生成し、MP4ファイルを構成する(S704)。受信装置20は、NALユニットにダミーデータを入れる場合には、NALユニットのタイプにダミーデータであることを示す。
また、受信装置20は、図17、図18、図38、及び図39で説明した方法に基づいて、次のアクセスユニットやNALユニットの先頭を検出し、先頭データからデコーダに入力することで、復号を再開することができる(S705)。
なお、パケットロスが発生した場合には、受信装置20は、パケットヘッダに基づいて検出された情報に基づいてアクセスユニット及びNALユニットの先頭から復号を再開してもよいし、ダミーデータのNALユニットを含む、再構成されたMP4ファイルのヘッダ情報に基づいてアクセスユニット及びNALユニットの先頭から復号を再開してもよい。
受信装置20は、MP4ファイル(MPU)を蓄積する際には、パケットロスにより消失したパケットデータ(NALユニットなど)は、放送や通信から別途取得して蓄積(置き換え)してもよい。
このとき、受信装置20は、消失したパケットを通信から取得する場合には、消失したパケットの情報(パケットIDや、MPUシーケンス番号、パケットシーケンス番号、IPデータフロー番号、及びIPアドレスなど)をサーバーに通知し、当該パケットを取得する。受信装置20は、消失したパケットのみに限らず、消失したパケット前後のパケット群を同時に取得してもよい。
[ムービーフラグメントの構成方法]
ここでは、ムービーフラグメントの構成方法について詳細に説明する。
ここでは、ムービーフラグメントの構成方法について詳細に説明する。
図33で説明されたように、ムービーフラグメントを構成するサンプル数、及び、1つのMPUを構成するムービーフラグメント数は、任意である。例えば、ムービーフラグメントを構成するサンプル数、及び、1つのMPUを構成するムービーフラグメント数は、固定的に定められた所定の数であってもよいし、動的に決定されてもよい。
ここで、送信側(送信装置15)において下記の条件を満たすようにムービーフラグメントが構成されることで、受信装置20における低遅延の復号を保証することができる。
その条件とは、以下の通りである。
送信装置15は、受信装置20が、任意のサンプル(Sample(i))の復号時刻(DTS(i))より前には必ず当該サンプルの情報を含むMFメタを受信できるように、サンプルデータを分割した単位をムービーフラグメントとしてMFメタを生成・送信する。
具体的には、送信装置15は、DTS(i)より前に符号化済のサンプル(i番目のサンプルを含む)を用いてムービーフラグメントを構成する。
低遅延の復号を保証するように、ムービーフラグメントを構成するサンプル数や1つのMPUを構成するムービーフラグメント数を動的に決定する方法としては、例えば、下記の方法が用いられる。
(1)復号開始時、GOP先頭のサンプルSample(0)の復号時刻DTS(0)は、initial_cpb_removal_delayに基づいた時刻である。送信装置は、DTS(0)より前の時刻に、符号化完了済のサンプルを用いて第1のムービーフラグメントを構成する。また、送信装置15は、第1のムービーフラグメントに対応するMFメタデータを生成し、DTS(0)より前の時刻に送信する。
(2)送信装置15は、以降のサンプルにおいても、上記の条件を満たすようにムービーフラグメントを構成する。
例えば、ムービーフラグメントの先頭のサンプルがk番目のサンプルであるとしたとき、k番目のサンプルを含むムービーフラグメントのMFメタは、k番目のサンプルの復号時刻DTS(k)までに送信される。送信装置15は、l番目のサンプルの符号化完了時刻がDTS(k)より前であり、(l+1)番目のサンプルの符号化完了時刻がDTS(k)より後である場合には、k番目のサンプルからl番目のサンプルを用いてムービーフラグメントを構成する。
なお、送信装置15は、k番目のサンプルから、l番目に満たないサンプルまでを用いてムービーフラグメントを構成してもよい。
(3)送信装置15は、MPU最後のサンプルの符号化完了後、残りのサンプルを用いてムービーフラグメントを構成し、当該ムービーフラグメントに対応するMFメタデータを生成し、送信する。
なお、送信装置15は、符号化完了済のすべてのサンプルを用いてムービーフラグメントを構成せずに、符号化完了済の一部のサンプルを用いてムービーフラグメントを構成してもよい。
なお、上記では、低遅延の復号を保証するように、上記条件に基づいて動的に、ムービーフラグメントを構成するサンプル数、及び、1つのMPUを構成するムービーフラグメント数が決定される例を示した。しかしながら、サンプル数及びムービーフラグメント数の決定方法は、このような方法に限定されるものではない。例えば、1つのMPUを構成するムービーフラグメント数が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。また、1つのMPUを構成するムービーフラグメント数、及びムービーフラグメントを分割する時刻(或いはムービーフラグメントの符号量)が所定の値に固定され、上記条件を満たすようにサンプル数が決定されてもよい。
また、MPUが複数のムービーフラグメントに分割されている場合、MPUが複数のムービーフラグメントに分割されているかどうかを示す情報、分割されたムービーフラグメントの属性、または分割されたムービーフラグメントに対するMFメタの属性が送信されてもよい。
ここで、ムービーフラグメントの属性とは、ムービーフラグメントが、MPUの先頭のムービーフラグメントであるか、MPUの最後のムービーフラグメントであるか、それ以外のムービーフラグメントであるか等を示す情報である。
また、MFメタの属性とは、MFメタが、MPUの先頭のムービーフラグメントに対応するMFメタであるか、MPUの最後のムービーフラグメントに対応するMFメタであるか、それ以外のムービーフラグメントに対応するMFメタであるか等を示す情報である。
なお、送信装置15は、ムービーフラグメントを構成するサンプル数、及び、1つのMPUを構成するムービーフラグメント数を制御情報として格納し、送信してもよい。
[受信装置の動作]
上記のように構成されたムービーフラグメントに基づく受信装置20の動作について説明する。
上記のように構成されたムービーフラグメントに基づく受信装置20の動作について説明する。
受信装置20は、PTS及びDTSのそれぞれの絶対時刻を、MPUタイムスタンプ記述子等、送信側からシグナリングされる絶対時刻、及びMFメタに含まれるPTS及びDTSの相対時刻に基づいて決定する。
受信装置20は、MPUが複数のムービーフラグメントに分割されているかどうかの情報に基づいて、MPUが分割されている場合は、分割されたムービーフラグメントの属性に基づいて、下記のように処理をする。
(1)受信装置20は、ムービーフラグメントがMPUの先頭のムービーフラグメントである場合、MPUタイムスタンプ記述子に含まれる先頭サンプルのPTSの絶対時刻、及びMFメタに含まれるPTS及びDTSの相対時刻を用いて、PTS及びDTSの絶対時刻を生成する。
(2)受信装置20は、ムービーフラグメントがMPUの先頭のムービーフラグメントでない場合、MPUタイムスタンプ記述子の情報を用いずに、MFメタに含まれるPTS及びDTSの相対時刻を用いて、PTS及びDTSの絶対時刻を生成する。
(3)受信装置20は、ムービーフラグメントがMPUの最後のムービーフラグメントである場合、すべてのサンプルのPTS及びDTSの絶対時刻を算出後、PTS及びDTSの計算処理(相対時刻の加算処理)をリセットする。なお、リセット処理は、MPU先頭のムービーフラグメントにおいて実施してもよい。
受信装置20は、下記のようにムービーフラグメントが分割されているかどうかの判定を行ってもよい。また、受信装置20は、下記のようにムービーフラグメントの属性情報を取得してもよい。
例えば、受信装置20は、MMTP(MMT Protocol)ペイロードヘッダに示されるムービーフラグメントの順番を示す識別子movie_fragment_sequence_numberフィールド値に基づいて分割されているかどうかを判定してもよい。
具体的には、受信装置20は、1つのMPUに含まれるムービーフラグメントの数が1であり、かつ、movie_fragment_sequence_numberフィールド値が1であり、かつ、当該フィールド値が2以上の値が存在する場合に、当該MPUは複数のムービーフラグメントに分割されていると判定してもよい。
また、受信装置20は、1つのMPUに含まれるムービーフラグメントの数が1であり、かつ、movie_fragment_sequence_numberフィールド値が0であり、かつ、当該フィールド値が0以外の値が存在する場合に、当該MPUは複数のムービーフラグメントに分割されていると判定してもよい。
ムービーフラグメントの属性情報も同様に、movie_fragment_sequence_numberに基づいて判定されてもよい。
なお、movie_fragment_sequence_numberを用いずとも、一つMPUに含まれるムービーフラグメントやMFメタの送信をカウントすることにより、ムービーフラグメントが分割されているかどうかや、ムービーフラグメントの属性情報を判定されてもよい。
以上説明したような送信装置15および受信装置20の構成により、受信装置20は、MPUよりも短い間隔でムービーフラグメントメタデータを受信でき、低遅延での復号開始が可能となる。また、MP4パースの方法に基づいた復号処理を用いて、低遅延での復号を行うことが可能となる。
以上説明したようにMPUが複数のムービーフラグメントに分割されている場合の受信動作について、フローチャートを用いて説明する。図41は、MPUが複数のムービーフラグメントに分割されている場合の受信動作のフローチャートである。なお、このフローチャートは、図37のステップS604の動作をより詳細に図示するものである。
まず、受信装置20は、MMTPペイロードヘッダに示されるデータ種別に基づいて、データ種別がMFメタである場合に、MFメタデータを取得する(S801)。
次に、受信装置20は、MPUが複数のムービーフラグメントに分割されているかどうかを判定し(S802)、MPUが複数のムービーフラグメントに分割されている場合(S802でYes)には、受信したMFメタデータがMPU先頭のメタデータであるかどうかを判定する(S803)。受信装置20は、受信したMFメタデータがMPU先頭のMFメタデータである場合(S803でYes)には、MPUタイムスタンプ記述子に示されるPTSの絶対時刻、並びにMFメタデータに示されるPTS及びDTSの相対時刻よりPTS及びDTSの絶対時刻を算出し(S804)、MPUの最後のメタデータであるかどうかの判定を行う(S805)。
一方、受信装置20は、受信したMFメタデータがMPU先頭のMFメタデータでない場合(S803でNo)には、MPUタイムスタンプ記述子の情報は用いずMFメタデータに示されるPTS及びDTSの相対時刻を用いてPTS及びDTSの絶対時刻を算出し(S808)、ステップS805の処理に移行する。
ステップS805において、MPU最後のMFメタデータであると判定された場合(S805でYes)、受信装置20は、すべてのサンプルのPTS及びDTSの絶対時刻を算出後、PTS及びDTSの計算処理をリセットする。ステップS805においてMPU最後のMFメタデータでないと判定された場合(S805でNo)、受信装置20は処理を終了する。
また、ステップS802においてMPUが複数のムービーフラグメントに分割されていないと判定された場合(S802でNo)には、受信装置20は、MPUの後に送信されるMFメタデータに基づき、サンプルデータを取得し、PTS及びDTSを決定する(S807)。
そして、図示されないが、受信装置20は、最後に、決定したPTS及びDTSに基づいて復号処理、提示処理を実施する。
[ムービーフラグメントを分割したときに発生する課題、及び、その解決策]
これまで、ムービーフラグメントを分割することによりEnd-to-End遅延を短縮する方法について説明してきた。ここからは、ムービーフラグメントを分割したときに新たに発生する課題、及び、その解決策について説明する。
これまで、ムービーフラグメントを分割することによりEnd-to-End遅延を短縮する方法について説明してきた。ここからは、ムービーフラグメントを分割したときに新たに発生する課題、及び、その解決策について説明する。
まず、背景として、符号化データにおけるピクチャ構造について説明する。図42は、時間スケーラビリティを実現する際の各TemporalIdにおけるピクチャの予測構造の例を示す図である。
MPEG-4 AVCやHEVC(High Efficiency Video Coding)などの符号化方式においては、他のピクチャから参照可能なBピクチャ(双方向参照予測ピクチャ)を用いることにより時間方向のスケーラビリティ(時間スケーラビリティ)が実現できる。
図42の(a)に示されるTemporalIdとは、符号化構造の階層の識別子であり、TemporalIdは、値が大きくなるほど深い階層であることを示す。四角のブロックはピクチャを示し、ブロック内のIxは、Iピクチャ(画面内予測ピクチャ)、Pxは、Pピクチャ(前方参照予測ピクチャ)、Bx及びbxは、Bピクチャ(双方向参照予測ピクチャ)を示す。Ix/Px/Bxのxは表示オーダーを示し、ピクチャを表示する順番を表わす。ピクチャ間の矢印は参照関係を示し、例えば、B4のピクチャはI0、B8を参照画像として予測画像を生成することを示す。ここで、一のピクチャが、自らのTemporalIdより大きいTemporalIdを持つ他のピクチャを参照画像として使うことは禁止されている。階層が規定されているのは時間スケーラビリティを持たせるためであり、例えば、図42において全てのピクチャを復号すると120fps(frame per second)の映像が得られるが、TemporalIdが0から3までの階層のみを復号すると60fpsの映像が得られる。
図43は、図42の各ピクチャにおける復号時刻(DTS)と表示時刻(PTS)との関係を示す図である。例えば、図43に示されるピクチャI0は、復号及び表示においてギャップが発生しないように、B4の復号完了後に表示される。
図43に示されるように、予測構造にBピクチャが含まれる場合などには、復号順と表示順とが異なるため、受信装置20においてピクチャを復号後にピクチャの遅延処理、及び、ピクチャの並び替え(リオーダ)処理が必要となる。
以上、時間方向のスケーラビリティにおけるピクチャの予測構造の例について説明したが、時間方向のスケーラビリティが用いられない場合においても、予測構造によっては、ピクチャの遅延処理、及び、リオーダ処理が必要となる場合がある。図44は、ピクチャの遅延処理、及び、リオーダ処理が必要となるピクチャの予測構造の一例を示す図である。なお、図44における数字は、復号順を示す。
図44に示されるように、予測構造によっては、復号順において先頭となるサンプルと、提示順において先頭となるサンプルが異なる場合があり、図44では、提示順で先頭となるサンプルは、復号順で4番目のサンプルとなる。なお、図44は、予測構造の一例を示すものであり、予測構造はこのような構造に限定されるものではない。他の予測構造においても、復号順において先頭となるサンプルと、提示順において先頭となるサンプルとが異なる場合がある。
図45は、図33と同様に、MP4形式で構成されるMPUが複数のムービーフラグメントに分割されて、MMTPペイロード、MMTPパケットに格納される例を示す図である。なお、MPUを構成するサンプル数や、ムービーフラグメントを構成するサンプル数は任意である。例えば、MPUを構成するサンプル数をGOP単位のサンプル数とし、GOP単位の2分の1のサンプル数をムービーフラグメントとして、2つのムービーフラグメントが構成されてもよい。1サンプルが1つのムービーフラグメントとされてもよいし、MPUを構成するサンプルが分割されなくてもよい。
図45では、1つのMPUに2つのムービーフラグメント(moofボックス及びmdatボックス)が含まれる例が示されているが、1つのMPUに含まれるムービーフラグメントは2つでなくてもよい。1つのMPUに含まれるムービーフラグメントは、3つ以上であってもよいし、MPUに含まれるサンプル数であってもよい。また、ムービーフラグメントに格納されるサンプルは等分したサンプル数でなく、任意のサンプル数に分割されてもよい。
ムービーフラグメントメタデータ(MFメタデータ)には、ムービーフラグメントに含まれるサンプルのPTS、DTS、オフセット、及びサイズの情報が含まれており、受信装置20は、サンプルを復号する際には、当該サンプルの情報を含むMFメタからPTS及びDTSを抽出し、復号タイミングや提示タイミングを決定する。
ここからは、詳細説明のために、iサンプルの復号時刻の絶対値をDTS(i)と記載し、提示時刻の絶対値をPTS(i)と記載する。
MFメタにおけるmoof内に格納されているタイムスタンプ情報のうちi番目のサンプルの情報は、具体的には、i番目のサンプルと(i+1)番目のサンプルの復号時刻の相対値、及び、i番目のサンプルの復号時刻と提示時刻の相対値であり、これらを以降DT(i)及びCT(i)と記載する。
ムービーフラグメントメタデータ#1には、サンプル#1-#3のDT(i)及びCT(i)が含まれており、ムービーフラグメントメタデータ#2には、サンプル#4-#6のDT(i)及びCT(i)が含まれている。
また、MPU先頭のアクセスユニットのPTS絶対値は、MPUタイムスタンプ記述子などに格納されており、受信装置20は、MPU先頭のアクセスユニットのPTS_MPUと、CT及びDTとに基づいてPTS及びDTSを算出する。
図46は、#1-#10のサンプルによりMPUが構成される場合のPTS及びDTSの算出方法と課題とを説明するための図である。
図46の(a)は、MPUがムービーフラグメントに分割されない例を示し、図46の(b)は、MPUが5サンプル単位の2つのムービーフラグメントに分割される例を示し、図46の(c)は、MPUがサンプル単位に10のムービーフラグメントに分割される例を示す。
図45で説明したように、MPUタイムスタンプ記述子と、MP4内のタイムスタンプ情報(CT及びDT)とを用いてPTS及びDTSが算出される場合において、図44における提示順で先頭となるサンプルは、復号順で4番目である。このため、MPUタイムスタンプ記述子に格納されているPTSは、復号順で4番目のサンプルのPTS(絶対値)となる。なお、以降では、このサンプルをAサンプルと呼ぶ。また、復号順で先頭のサンプルをBサンプルと呼ぶ。
タイムスタンプに係る絶対時刻情報は、MPUタイムスタンプ記述子の情報のみであるため、受信装置20は、Aサンプルが到着するまで、その他のサンプルのPTS(絶対時刻)及びDTS(絶対時刻)を算出できない。受信装置20は、BサンプルのPTS及びDTSも算出できない。
図46の(a)の例では、Aサンプルは、Bサンプルと同じムービーフラグメントに含まれ、一つのMFメタに格納される。このため、受信装置20は、当該MFメタを受信後、すぐにBサンプルのDTSを決定できる。
図46の(b)の例では、Aサンプルは、Bサンプルと同じムービーフラグメントに含まれ、一つのMFメタに格納される。このため、受信装置20は、当該MFメタを受信後、すぐにBサンプルのDTSを決定できる。
図46の(c)の例では、Aサンプルは、Bサンプルと異なるムービーフラグメントに含まれる。このため、受信装置20は、Aサンプルを含むムービーフラグメントのCT及びDTを含むMFメタを受信後でなければ、BサンプルのDTSを決定できない。
したがって、図46の(c)の例の場合には、受信装置20は、Bサンプルの到着後、すぐに復号を開始できない。
このように、Bサンプルを含むムービーフラグメントに、Aサンプルが含まれない場合には、受信装置20は、Aサンプルを含むムービーフラグメントに係るMFメタを受信した後でなければ、Bサンプルの復号を開始できない。
提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、AサンプルとBサンプルとが同一ムービーフラグメントに格納されなくなるまでにムービーフラグメントが分割されることにより、この課題は発生する。また、MFメタが後送りであるか先送りであるかにかかわらず、この課題は発生する。
このように、提示順で先頭のサンプルと、デコード順で先頭のサンプルとが一致しない場合において、Aサンプルと、Bサンプルとが同一ムービーフラグメントに格納されない場合には、Bサンプルの受信後、すぐにDTSを決定できない。そこで、送信装置15は、別途、BサンプルのDTS(絶対値)、或いはBサンプルのDTS(絶対値)を受信側において算出可能な情報を送信する。このような情報は、制御情報やパケットヘッダ等を用いて送信されてもよい。
受信装置20は、このような情報を用いてBサンプルのDTS(絶対値)を算出する。図47は、このような情報を用いてDTSが算出される場合の受信動作のフローチャートである。
受信装置20は、MPU先頭のムービーフラグメントを受信し(S901)、AサンプルとBサンプルとが同一ムービーフラグメントに格納されているかどうかを判定する(S902)。同一ムービーフラグメントに格納されている場合(S902でYes)は、受信装置20は、BサンプルのDTS(絶対時刻)を用いず、MFメタの情報のみを用いてDTSを算出し、復号を開始する(S904)。なお、ステップS904において、受信装置20は、BサンプルのDTSを用いてDTSを決定してもよい。
一方、ステップS902においてAサンプルとBサンプルとが同一ムービーフラグメントに格納されていない場合(S902でNo)、受信装置20は、BサンプルのDTS(絶対時刻)を取得し、DTSを決定し、復号を開始する(S903)。
なお、以上の説明では、MMT規格におけるMFメタ(MP4形式のmoof内に格納されているタイムスタンプ情報)を用いて、各サンプルの復号時刻の絶対値と、提示時刻の絶対値とを算出する例について説明したが、MFメタを、各サンプルの復号時刻の絶対値と、提示時刻の絶対値を算出に用いることができる任意の制御情報に置き換えて実施しても良いことは言うまでもない。このような制御情報の例としては、上述したi番目のサンプルと(i+1)番目のサンプルの復号時刻の相対値CT(i)を、i番目のサンプルと(i+1)番目のサンプルの提示時刻の相対値に置き換えた制御情報や、i番目のサンプルと(i+1)番目のサンプルの復号時刻の相対値CT(i)とi番目のサンプルと(i+1)番目のサンプルの提示時刻の相対値との両方を含む制御情報などがある。
(実施の形態3)
[概要]
実施の形態3では、映像、音声、字幕、及びデータ放送などのコンテンツを放送で伝送する場合のコンテンツの送信方法及びデータ構造について説明する。つまり、放送ストリームの再生に特化したコンテンツの送信方法及びデータ構造について説明する。
[概要]
実施の形態3では、映像、音声、字幕、及びデータ放送などのコンテンツを放送で伝送する場合のコンテンツの送信方法及びデータ構造について説明する。つまり、放送ストリームの再生に特化したコンテンツの送信方法及びデータ構造について説明する。
なお、実施の形態3では、多重化方式としてMMT方式(以下、単にMMTとも記載する)が用いられる例について説明するが、MPEG-DASHまたはRTPなど、その他の多重化方式が用いられてもよい。
まず、MMTにおけるデータユニット(DU:Data Unit)のペイロードへの格納方法の詳細について説明する。図48は、MMTにおけるデータユニットのペイロードへの格納方法を説明するための図である。
MMTでは、送信装置は、MPUを構成するデータの一部を、データユニットとしてMMTPペイロードに格納し、ヘッダをつけて伝送する。ヘッダにはMMTPペイロードヘッダ、及び、MMTPパケットヘッダが含まれる。なお、データユニットの単位は、NALユニット単位でもよいし、サンプル単位でもよい。
図48の(a)は、送信装置が複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す。図48の(a)の例では、複数のデータユニットそれぞれの先頭に、データユニットヘッダ(DUH:Data Unit Header)、及び、データユニット長(DUL:Data Unit Length)が付与され、データユニットヘッダ及びデータユニット長が付与されたデータユニットが複数まとめてペイロードに格納される。
図48の(b)は、一つのデータユニットを一つのペイロードに格納する例を示す。図48の(b)の例では、データユニットの先頭に、データユニットヘッダが付与されてペイロードに格納される。図48の(c)は、一つのデータユニットを分割し、分割されたデータユニットに、データユニットヘッダが付与されてペイロードに格納される例を示す。
データユニットには、映像、音声、または字幕などの同期に関する情報を含むメディアであるtimed-MFU、ファイルなど同期に関する情報を含まないメディアであるnon-timed-MFU、MPUメタデータ、MFメタデータなどの種類があり、データユニットの種類に応じてデータユニットヘッダが定められる。なお、MPUメタデータ、及び、MFメタデータにはデータユニットヘッダは存在しない。
また、送信装置は、異なる種類のデータユニットをアグリゲーションすることは原則としてできないが、異なる種類のデータユニットをアグリゲーションできるように規定されてもよい。例えば、サンプル毎にムービーフラグメントに分割されている場合などのMFメタデータのサイズが小さい場合、MFメタデータとメディアデータとをアグリゲーションすることにより、パケット数を削減でき、さらに、伝送容量を削減することもできる。
データユニットがMFUの場合は、MPU(MP4)を構成するための情報など、MPUの一部の情報がヘッダとして格納される。
例えば、timed-MFUのヘッダには、movie_fragment_sequence_number、sample_number、offset、priority、及び、dependency_counterなどが含まれ、non-timed-MFUのヘッダにはitem_iDが含まれる。各フィールドの意味はISO/IEC23008-1あるいはARIB STD-B60などの規格に示される。以下、このような規格において規定される各フィールドの意味について説明する。
movie_fragment_sequence_numberは、MFUが属するムービーフラグメントのシーケンス番号を示し、ISO/IEC14496-12にも示される。
sample_numberは、当該MFUが属するサンプル番号を示し、ISO/IEC14496-12にも示される。
offsetは、当該MFUが属するサンプルにおける、MFUのオフセット量をバイト単位で示す。
priorityは、当該MFUが属するMPUにおける、MFUの相対的な重要度を示し、priorityの数字が大きいMFUは、priorityの数字が小さいMFUよりも重要であることを示す。
dependency_counterは、復号処理が当該MFUに依存しているMFU数(すなわち、このMFUを復号処理しなければ、その復号処理を行うことができないMFUの数)を示す。例えば、MFUがHEVCである場合においてBピクチャまたはPピクチャがIピクチャを参照する場合、当該BピクチャまたはPピクチャは、Iピクチャを復号処理しなければ復号処理を行うことができない。
したがって、MFUがサンプル単位である場合は、IピクチャのMFUにおけるdependency_counterには、当該Iピクチャを参照するピクチャ数が示される。MFUがNALユニット単位の場合は、Iピクチャに属するMFUにおけるdependency_counterには、当該Iピクチャを参照するピクチャに属するNALユニット数が示される。さらに、時間方向階層符号化された映像信号の場合、拡張レイヤのMFUは、ベースレイヤのMFUに依存するため、ベースレイヤのMFUにおけるdependency_counterには、拡張レイヤのMFUの数が示される。本フィールドは、依存するMFU数が決定した後でなければ生成できない。
item_iDは、アイテムを一意に特定する識別子を示す。
[MP4非サポートモード]
図19、及び、図21で説明したように、送信装置がMMTにおけるMPUを伝送する方法としては、MPUメタデータまたはMFメタデータをメディアデータの前または後に送信する方法、及び、メディアデータのみを送信する方法がある。また、受信装置では、MP4に準拠した受信装置や受信方法を用いて復号を行う方法や、ヘッダを用いずに復号する方法がある。
図19、及び、図21で説明したように、送信装置がMMTにおけるMPUを伝送する方法としては、MPUメタデータまたはMFメタデータをメディアデータの前または後に送信する方法、及び、メディアデータのみを送信する方法がある。また、受信装置では、MP4に準拠した受信装置や受信方法を用いて復号を行う方法や、ヘッダを用いずに復号する方法がある。
放送ストリーム再生に特化したデータの送信方法として、例えば、受信装置におけるMP4再構成をサポートしない送信方法がある。
受信装置におけるMP4再構成をサポートしない送信方法とは、例えば、図21の(b)に示されるようにメタデータ(MPUメタデータ及びMFメタデータ)を送信しない方法がある。この場合、MMTPパケットに含まれるフラグメントタイプ(データユニットの種類を示す情報)のフィールド値は、2(=MFU)固定である。
メタデータが送信されない場合は、これまで説明したように、MP4準拠の受信装置などでは、受信したデータをMP4として復号することはできないが、メタデータ(ヘッダ)を用いずに復号することが可能である。
そのため、メタデータは放送ストリーム復号及び再生に必ずしも必須の情報ではない。同様に、図48で説明した、timed-MFUにおけるデータユニットヘッダの情報は、受信装置においてMP4を再構成するための情報である。放送ストリーム再生においてMP4を再構成する必要はないため、timed-MFUにおけるデータユニットヘッダ(以下、timed-MFUヘッダとも記載する)の情報は、放送ストリーム再生に必ずしも必要な情報ではない。
受信装置は、メタデータ、および、データユニットヘッダにおけるMP4を再構成するための情報(以下、MP4構成情報とも記載する)を用いることにより、容易にMP4を再構成することができる。しかし、受信装置は、メタデータ、および、データユニットヘッダにおけるMP4構成情報のどちらか一方のみが伝送されていたとしても、MP4を再構成することはできない。メタデータ及びMP4を再構成するための情報のどちらか一方のみが伝送されることによるメリットは少なく、必要でない情報を生成及び伝送することは、処理の増大や伝送効率の低下を招く。
そこで、送信装置は、下記の方法を用いてMP4構成情報のデータ構造や伝送を制御する。送信装置は、メタデータが伝送されるかどうかに基づいて、データユニットヘッダにおいてMP4構成情報を示すか否かを決定する。具体的には、送信装置は、メタデータが伝送される場合には、データユニットヘッダにおいてMP4構成情報を示し、メタデータが伝送されない場合には、データユニットヘッダにおいてMP4構成情報を示さない。
データユニットヘッダにおいてMP4構成情報を示さない方法としては、例えば下記の方法を用いることができる。
1.送信装置は、MP4構成情報をreservedとし、運用しない。これにより、MP4構成情報を生成する送出側の処理量(送信装置の処理量)を削減することができる。
2.送信装置は、MP4構成情報を削除し、ヘッダ圧縮する。これにより、MP4構成情報を生成する送出側の処理量を削減することができるとともに、伝送容量を削減することができる。
なお、送信装置は、MP4構成情報を削除し、ヘッダ圧縮する場合には、MP4構成情報を削除(圧縮)したことを示すフラグを示してもよい。フラグは、ヘッダ(MMTPパケットヘッダ、MMTPペイロードヘッダ、データユニットヘッダ)または制御情報などに示される。
また、メタデータが伝送されるかどうかの情報は、あらかじめ定めていてもよいし、別途ヘッダや制御情報にシグナリングし、受信装置に伝送されてもよい。
例えば、MFUヘッダに当該MFUに対応するメタデータが伝送されているかの情報が格納されてもよい。
一方、受信装置は、メタデータが伝送されているかどうかに基づいて、MP4構成情報が示されているかどうかを判定することができる。
ここで、データの送信順序(例えば、MPUメタデータ、MFメタデータ、メディアデータのような順序)が決まっている場合は、受信装置は、メディアデータの前にメタデータが受信されたかどうかに基づいて判定してもよい。
MP4構成情報が示されている場合には、受信装置は、MP4構成情報をMP4の再構成に用いることができる。或いは、受信装置は、その他のアクセスユニットやNALユニットの先頭の検出などにMP4構成情報を用いることができる。
なお、MP4構成情報は、timed-MFUヘッダの全部であってもよいし一部であってもよい。
また、送信装置は、non-timed-MFUヘッダにおいても同様に、メタデータが伝送されるかどうかに基づいて、non-timed-MFUヘッダにおいてitem
idを示すかどうかを決定してもよい。
idを示すかどうかを決定してもよい。
送信装置は、timed-MFUと、non-timed-MFUとのどちらか一方においてのみMP4構成情報を示すとしてもよい。どちらか一方にのみMP4構成情報を示す場合、送信装置は、メタデータが伝送されるかどうかに加え、timed-MFUかnon-timed-MFUかどうかに基づいてMP4構成情報を示すかどうかを決定する。受信装置では、メタデータが伝送されるかどうか、および、timed/non-timedフラグに基づいてMP4構成情報が示されるかどうかを判定することができる。
なお、以上の説明においては、送信装置は、メタデータ(MPUメタデータ及びMFメタデータの両方)が伝送されるかどうかに基づいてMP4構成情報を示すかどうかを決定した。しかしながら、送信装置は、メタデータの一部(MPUメタデータ、MFメタデータのどちらか一方)が伝送されない場合に、MP4構成情報を示さないとしてもよい。
また、送信装置は、メタデータ以外の他の情報に基づいてMP4構成情報を示すかどうかを決定してもよい。
例えば、MP4サポートモード/MP4非サポートモードのようなモードが定義され、送信装置は、MP4サポートモードの場合には、データユニットヘッダにおいてMP4構成情報を示し、MP4非サポートモードの場合には、データユニットヘッダにおいてMP4構成情報を示さないとしてもよい。また、送信装置は、MP4サポートモードの場合には、メタデータを伝送し、かつデータユニットヘッダにおいてMP4構成情報を示し、MP4非サポートモードの場合には、メタデータを伝送せずにデータユニットヘッダにおいてもMP4構成情報を示さないとしてもよい。
[送信装置の動作フロー]
次に、送信装置の動作フローについて説明する。図49は、送信装置の動作フローである。
次に、送信装置の動作フローについて説明する。図49は、送信装置の動作フローである。
送信装置は、まず、メタデータを伝送するかどうかを判定する(S1001)。送信装置は、メタデータを伝送すると判定した場合(S1002でYes)、ステップS1003へ移行し、MP4構成情報を生成し、かつ、ヘッダに格納して伝送する(S1003)。この場合、送信装置は、メタデータも生成し、かつ、伝送する。
一方、送信装置は、メタデータを伝送しないと判定した場合(S1002でNo)、MP4構成情報を生成せず、かつ、ヘッダにも格納せずに伝送する(S1004)。この場合、送信装置は、メタデータを生成せず、伝送しない。
なお、ステップS1001においてメタデータを伝送するかどうかは、あらかじめ定められていてもよいし、送信装置の内部でメタデータが生成されたかどうか、送信装置の内部でメタデータが伝送されているかどうかに基づいて判定されてもよい。
[受信装置の動作フロー]
次に、受信装置の動作フローについて説明する。図50は、受信装置の動作フローである。
次に、受信装置の動作フローについて説明する。図50は、受信装置の動作フローである。
受信装置は、まず、メタデータが伝送されているかどうかを判定する(S1101)。メタデータが伝送されているかどうかは、MMTPパケットペイロードにおけるフラグメントタイプを監視することにより判定できる。また、伝送されているかどうかがあらかじめ定められていてもよい。
受信装置は、メタデータが伝送されていると判定した場合(S1102でYes)、MP4を再構成し、かつ、MP4構成情報を用いた復号処理を実行する(S1103)。一方、メタデータが伝送されていないと判定した場合(S1102でNo)、MP4の再構成処理をせず、かつ、MP4構成情報を用いずに復号処理を実行する(S1104)。
なお、受信装置は、これまで説明した方法を用いて、MP4構成情報を用いずにランダムアクセスポイントの検出、アクセスユニット先頭の検出、NALユニット先頭の検出などをすることが可能であり、復号処理、パケットロスの検出、及びパケットロスからの復帰の処理をすることができる。
例えば、アクセスユニット先頭は、aggregation_flag値が1であるMMTペイロードの先頭データである。このとき、Fragmentation_indicator値は0である。
また、スライスセグメントの先頭は、aggregation_flag値が0、fragmentation_indicator値が00或いは01であるMMTペイロードの先頭データである。
受信装置は、以上のような情報に基づき、アクセスユニット先頭の検出、及び、スライスセグメントの検出を行うことができる。
なお、受信装置は、fragmentation_indicator値が00或いは01であるデータユニットの先頭を含むパケットにおいて、NALユニットヘッダを解析し、NALユニットの種類がAUデリミタであること、及び、NALユニットの種類がスライスセグメントであることを検出してもよい。
[放送シンプルモード]
これまでは、放送ストリーム再生に特化したデータの送信方法として、受信装置におけるMP4構成情報をサポートしない方法を説明したが、放送ストリーム再生に特化したデータの送信方法は、これに限るものではない。
これまでは、放送ストリーム再生に特化したデータの送信方法として、受信装置におけるMP4構成情報をサポートしない方法を説明したが、放送ストリーム再生に特化したデータの送信方法は、これに限るものではない。
放送ストリーム再生に特化したデータの送信方法として、例えば下記の方法が用いられてもよい。
・送信装置は、放送の固定受信環境では、AL-FECを用いなくてもよい。AL-FECが用いられない場合は、MMTPパケットヘッダにおけるFEC_typeは常に0固定とされる。
・送信装置は、放送の移動受信環境、及び、通信UDP伝送モードにおいては、常にAL-FECを用いてもよい。AL-FECが用いられる場合は、MMTPパケットヘッダにおけるFEC_typeは、常に0或いは1である。
・送信装置は、アセットのバルク伝送をしなくてもよい。アセットのバルク伝送がされない場合には、MPT内部のアセットの伝送ローケーション数を示すlocation_infolocationは、1に固定されてよい。
・送信装置は、アセット、プログラム、及びメッセージのハイブリッド伝送をしなくてもよい。
また、例えば、放送シンプルモードが規定され、送信装置は、放送シンプルモードである場合には、MP4非サポートモードとする、或いは、上記に示した放送ストリーム再生に特化したデータの送信方法を用いるとしてもよい。放送シンプルモードかどうかはあらかじめ定められていてもよいし、送信装置は、放送シンプルモードであることを示すフラグを制御情報として格納し、受信装置に伝送してもよい。
また、送信装置は、図49で説明した、MP4非サポートモードであるかどうか(メタデータが伝送されているかどうか)に基づいて、MP4非サポートモードである場合には、放送シンプルモードとして、上記に示した放送ストリーム再生に特化したデータの送信方法を用いてもよい。
受信装置は、放送シンプルモードである場合には、MP4非サポートモードであるとして、MP4を再構成せず復号処理をすることができる。
また、受信装置は、放送シンプルモードである場合には、放送に特化した機能であることを判定し、放送に特化して受信処理をすることができる。
これにより、放送シンプルモードである場合には、放送に特化した機能のみを用いることにより、送信装置及び受信装置にとって不要な処理を削減できるばかりでなく、不要な情報を圧縮して伝送しないことにより、伝送オーバーヘッドを削減することができる。
なお、MP4非サポートモードが用いられる場合には、MP4構成以外の蓄積方法をサポートするヒント情報が示されてもよい。
MP4構成以外の蓄積方法としては、例えば、MMTパケットやIPパケットをダイレクトに蓄積する方法や、MMTパケットをMPEG-2 TSパケットに変換する方法などがある。
なお、MP4非サポートモードの場合には、MP4構成にしたがわないフォーマットが用いられてもよい。
例えば、MFUに格納されるデータは、MP4非サポートモードの場合には、MP4形式であるNALユニットの先頭にNALユニットのサイズがついた形式でなく、バイトスタートコードがついた形式にされてもよい。
MMTでは、アセットのタイプを示すアセットタイプは、MP4REG(http://www.mp4ra.org)に登録される4CCで記載され、映像信号としてHEVCを用いる場合、‘HEV1’または‘HVC1’が用いられる。‘HVC1’は、サンプルの中にパラメータセットを含んでもよい形式であり、‘HEV1’はサンプルの中にパラメータセットを含まず、MPUメタデータにおけるサンプルエントリにパラメータセットを含む形式である。
放送シンプルモードまたはMP4非サポートモードの場合において、MPUメタデータ及びMFメタデータが伝送されない場合には、必ずサンプルの中にパラメータセットを含めると規定されてもよい。また、アセットタイプに‘HEV1’と‘HVC1’のどちらが示されている場合にも、必ず‘HVC1’の形式をとると規定されてもよい。
[補足1:送信装置]
以上のように、メタデータが送信されていない場合に、MP4構成情報をreservedとし、運用しない送信装置は、図51のように構成することも可能である。図51は、送信装置の具体的構成の例を示す図である。
以上のように、メタデータが送信されていない場合に、MP4構成情報をreservedとし、運用しない送信装置は、図51のように構成することも可能である。図51は、送信装置の具体的構成の例を示す図である。
送信装置300は、符号化部301と、付与部302と、送信部303とを備える。符号化部301、付与部302、及び送信部303のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
符号化部301は、映像信号または音声信号を符号化してサンプルデータを生成する。サンプルデータは、具体的には、データユニットである。
付与部302は、映像信号または音声信号が符号化されたデータであるサンプルデータに、MP4構成情報を含むヘッダ情報を付与する。MP4構成情報は、受信側において当該サンプルデータをMP4フォーマットのファイルとして再構成するための情報であって、サンプルデータの提示時刻が定められているか否かに応じて内容が異なる情報である。
上述のように、付与部302は、提示時刻が定められているサンプルデータ(同期に関する情報を含むサンプルデータ)の一例であるtimed-MFUのヘッダ(ヘッダ情報)に、movie_fragment_sequence_number、sample_number、offset、priority、及び、dependency_counterなどのMP4構成情報を含める。
一方で、付与部302は、提示時刻が定められていないサンプルデータ(同期に関する情報を含まないサンプルデータ)の一例である、timed-MFUのヘッダ(ヘッダ情報)には、item_idなどのMP4構成情報を含める。
そして、付与部302は、送信部303によってサンプルデータに対応するメタデータが送信されない場合(例えば、図21の(b)のような場合)には、サンプルデータの提示時刻が定められているか否かに応じて、MP4構成情報を含まないヘッダ情報をサンプルデータに付与する。
付与部302は、具体的には、サンプルデータの提示時刻が定められている場合には、第一のMP4構成情報を含まないヘッダ情報をサンプルデータに付与し、サンプルデータの提示時刻が定められていない場合には、第二のMP4構成情報を含むヘッダ情報を前記サンプルデータに付与する。
例えば、付与部302は、図49のステップS1004に示されるように、送信部303によってサンプルデータに対応するメタデータが送信されない場合には、MP4構成情報をreserved(固定値)とすることにより、MP4構成情報を実質的に生成せず、かつ、実質的にヘッダ(ヘッダ情報)に格納しない。なお、メタデータには、MPUメタデータ、及び、ムービーフラグメントメタデータが含まれる。
送信部303は、ヘッダ情報が付与されたサンプルデータを送信する。送信部303は、より具体的には、ヘッダ情報が付与されたサンプルデータをMMT方式でパケット化して送信する。
上述のように、放送ストリームの再生に特化した送信方法及び受信方法では、受信装置でデータユニットをMP4に再構成する必要はない。受信装置がMP4に再構成する必要がない場合、MP4構成情報などの不要な情報を生成しないことで送信装置の処理は軽減される。
一方で、送信装置は、必要な情報は送らなくてはならないが、余計な追加情報などを別途送信しなくて済むように、規格との整合性は保つ必要がある。
送信装置300のような構成によれば、MP4構成情報が格納される領域を固定値にすることなどにより、MP4構成情報を送信せず、必要な情報のみを規格に基づいて送信し、余計な追加情報を送信しなくて済む効果が得られる。つまり、送信装置の構成及び送信装置の処理量を削減することができる。また、不要なデータが送信されないことにより、伝送効率を向上させることができる。
[補足2:受信装置]
また、送信装置300に対応する受信装置は、例えば、図52のように構成されてもよい。図52は、受信装置の構成の別の例を示す図である。
また、送信装置300に対応する受信装置は、例えば、図52のように構成されてもよい。図52は、受信装置の構成の別の例を示す図である。
受信装置400は、受信部401と、復号部402とを備える。受信部401、及び、復号部402は、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信部401は、映像信号または音声信号が符号化されたデータであるサンプルデータであって、当該サンプルデータをMP4フォーマットのファイルとして再構成するためのMP4構成情報を含むヘッダ情報が付与されたサンプルデータを受信する。
復号部402は、受信部によってサンプルデータに対応するメタデータが受信されなかった場合であって、サンプルデータの提示時刻が定められている場合に、MP4構成情報を使用せずにサンプルデータを復号する。
例えば、復号部402は、図50のステップS1104に示されるように、受信部401によってサンプルデータに対応するメタデータが受信されない場合には、MP4構成情報を用いずに復号処理を実行する。
これにより、受信装置400の構成及び受信装置400における処理量を削減することができる。
(実施の形態4)
[概要]
実施の形態4では、ファイルなど同期に関する情報を含まない非同期(non-timed)メディアのMPUへの格納方法と、MMTPパケットでの伝送方法について説明する。なお、実施の形態4では、MMTにおけるMPUを例に説明するが、同じMP4ベースであるDASHでも適用可能である。
[概要]
実施の形態4では、ファイルなど同期に関する情報を含まない非同期(non-timed)メディアのMPUへの格納方法と、MMTPパケットでの伝送方法について説明する。なお、実施の形態4では、MMTにおけるMPUを例に説明するが、同じMP4ベースであるDASHでも適用可能である。
まず、non-timedメディア(以下、「非同期メディアデータ」とも言う)のMPUへの格納方法の詳細について図53を用いて説明する。図53は、non-timedメディアのMPUへの格納方法、及び、MMTPパケットでの伝送方法を示す図である。
non-timedメディアを格納するMPUは、ftyp、mmpu、moov、metaなどのボックスで構成され、MPUに格納するファイルに関する情報が格納される。metaボックス内には複数のidatボックスを格納することができ、idatボックスには1つのファイルがitemとして格納される。
ftyp,mmpu,moov,metaボックスの一部はMPUメタデータとして一つのデータユニットを構成し、item或いはidatボックスはMFUとしてデータユニットを構成する。
データユニットはアグリゲーションやフラグメントされた後、データユニットヘッダ、MMTPペイロードヘッダ、及びMMTPパケットヘッダが付与されてMMTPパケットとして伝送される。
なお、図53では、File#1とFile#2とが1つのMPUに格納される例を示している。MPUメタデータは分割されておらず、また、MFUは分割されてMMTPパケットに格納されているが、これに限るものではなく、データユニットのサイズに応じてアグリゲーションやフラグメントされてもよい。また、MPUメタデータは伝送されなくてもよく、その場合は、MFUのみが伝送される。
データユニットヘッダなどのヘッダ情報には、itemID(アイテムを一意に特定する識別子)が示され、MMTPペイロードヘッダやMMTPパケットヘッダには、パケットシーケンス番号(パケット毎のシーケンス番号)、及び、MPUシーケンス番号(MPUのシーケンス番号、アセット内で一意の番号。)が含まれる。
なお、データユニットヘッダ以外のMMTPペイロードヘッダやMMTPパケットヘッダのデータ構造はこれまで説明したtimedメディア(以下、「同期メディアデータ」とも言う。)と同様であり、aggregation_flag,fragmentation_indicator,fragment_counterなどが含まれる。
次に、ファイル(=Item=MFU)を分割してパケット化する場合のヘッダ情報の具体例をについて、図54及び図55を用いて説明する。
図54及び図55は、ファイルが分割されることにより得られた複数の分割データ毎にパケット化して伝送する例を示す図である。図54及び図55は、具体的には、分割されたMMTPパケット毎のヘッダ情報であるデータユニットヘッダ、MMTPペイロードヘッダ、MMTPパケットヘッダのいずれかに含まれる情報(パケットシーケンス番号、フラグメントカウンタ、フラグメンテーションインジケータ、MPUシーケンス番号、アイテムID)を示す。なお、図54は、File#1がM個(M<=256)に分割される例を示す図であり、図55は、File#2がN個(256<N)に分割される例を示す図である。
分割データ番号は、ファイル先頭からの分割データのインデックスを示しており、この情報は伝送されない。つまり、分割データ番号は、ヘッダ情報には含まれない。また、分割データ番号は、ファイルを分割することにより得られた複数の分割データのそれぞれに対応するパケットに付与される番号であり、先頭のパケットから昇順に1ずつ加算されて付与される番号である。
パケットシーケンス番号は、同じパケットIDを持つパケットのシーケンス番号であり、図54及び図55では、ファイル先頭の分割データをAとして、ファイル最後の分割データまで連続した番号が付与される。パケットシーケンス番号は、ファイル先頭の分割データから昇順に1ずつ加算されて付与される番号であり、分割データ番号に対応する番号である。
フラグメントカウンタは、1つのファイルが分割されることにより得られた複数の分割データのうち当該分割データよりも後にある複数の分割データの数を示す。また、フラグメントカウンタは、1つのファイルを分割することにより得られた複数の分割データの数である分割データ数が256を超える場合、分割データ数を256で除した余りを示す。図54の例では、分割データ数が256以下であるため、フラグメントカウンタのフィールド値は(M-分割データ番号)となる。一方、図55の例では、分割データ数が256を超えるため、(N-分割データ番号)を256で除した値((N-分割データ番号)%256)となる。
なお、フラグメンテーションインジケータは、MMTPパケットに格納するデータの分割の状態を示し、分割されたデータユニットにおける先頭の分割データであるか、最後の分割データであるか、それ以外の分割データであるか、或いは、分割されていない1つ以上のデータユニットであるかを示す値である。具体的には、フラグメンテーションインジケータは、先頭の分割データでは「01」であり、最後の分割データでは「11」であり、残りの分割データでは「10」であり、分割されていないデータユニットでは「00」である。
本実施の形態では、分割データ数が256を超える場合、分割データ数を256で除した余りを示すとして説明するが、分割データ数は256に限らず、他の数(所定の数)であってもよい。
図54及び図55に示すようにファイルを分割し、ファイルを分割することにより得られた複数の分割データのそれぞれに従来のヘッダ情報を付与して伝送する場合、受信装置において、受信したMMTPパケットに格納されるデータが、元のファイルにおいて何番目の分割データであるか(分割データ番号)、及び、ファイルの分割データ数、または、分割データ番号及び分割データ数を導出できる情報がない。このため、従来の伝送方法では、MMTPパケットを受信しても、受信したMMTPパケットに格納されるデータの分割データ番号や分割データ数を一意に検出することができない。
例えば、図54のように分割データ数が256以下であり、分割データ数があらかじめ256以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。しかし、分割データ数が256以上である場合には、分割データ番号や分割データ数を特定できない。
なお、ファイルの分割データ数を256以下に制限する場合、1つのパケットで伝送可能なデータサイズをx[bytes]とした場合、伝送可能なファイルの最大サイズは x * 256[bytes]に制限される。例えば、放送ではx=4k[bytes]が想定されており、この場合、伝送可能なファイルの最大サイズは4k*256=1M[bytes]に制限される。従って、1[Mbytes]を越えるファイルを伝送したい場合にはファイルの分割データ数を256以下に制限することはできない。
また、例えば、フラグメンテーションインジケータを参照することでファイルの先頭の分割データや最後の分割データを検出することができるため、ファイルの最後の分割データを含むMMTPパケットが受信されるまでMMTPパケット数をカウントしたり、ファイルの最後の分割データを含むMMTPパケットを受信したりした後に、パケットシーケンス番号と組み合わせることにより、分割データ番号や分割データ数を算出することは可能であるため、フラグメンテーションインジケータとパケットシーケンス番号とを組み合わせることにより分割データ番号及び分割データ数をシグナリングするとしてもよい。しかし、ファイルの途中の分割データ(つまり、ファイルの先頭の分割データでもファイルの最後の分割データでもない分割データ)を含むMMTPパケットから受信を開始した場合、当該分割データの分割データ番号や分割データ数を特定できない。当該分割データの分割データ番号や分割データ数は、ファイル最後の分割データを含むMMTPパケットを受信後に初めて特定できる。
図54及び図55で説明した課題、つまり、ファイルの分割データを含むパケットを途中から受信した時点で、ファイルの分割データの分割データ番号および分割データ数を一意に決定するために、次の方法を用いる。
まず、分割データ番号について説明する。
分割データ番号については、ファイル(item)の先頭の分割データにおけるパケットシーケンス番号をシグナリングする。
シグナリングする方法として、ファイルを管理する制御情報に格納する。具体的には、図54及び図55においてファイルの先頭の分割データのパケットシーケンス番号Aを、制御情報に格納する。受信装置では、制御情報よりAの値を取得し、パケットヘッダに示されるパケットシーケンス番号より分割データ番号を算出する。
分割データの分割データ番号は、当該分割データのパケットシーケンス番号から先頭の分割データのパケットシーケンス番号Aを減ずることにより求められる。
ファイルを管理する制御情報としては、例えば、ARIB STD-B60に規定されるアセット管理テーブルがある。アセット管理テーブルには、ファイル毎に、ファイルサイズやバージョン情報などが示され、データ伝送メッセージに格納されて伝送される。図56は、アセット管理テーブルにおけるファイル毎のループのシンタックスを示す図である。
既存のアセット管理テーブルの領域が拡張できない場合には、アイテムの情報を示すitem_info_byteフィールドの一部の32bitの領域を用いてシグナリングしてもよい。item_info_byteの一部領域に、ファイル(item)の先頭の分割データにおけるパケットシーケンス番号が示されているかどうかを示すフラグを制御情報の例えばreserved_future_useフィールドに示してもよい。
データカルーセルなどファイルを繰り返し伝送する場合には、複数のパケットシーケンス番号を示してもよいし、直後に伝送するファイルの先頭のパケットシーケンス番号を示してもよい。
ファイル先頭の分割データのパケットシーケンス番号に限らず、ファイルの分割データ番号とパケットシーケンス番号を紐づける情報であればよい。
次に、分割データ数について説明する。
アセット管理テーブルに含まれるファイル毎のループの順番を、ファイルの伝送順と規定してもよい。これにより、伝送順で連続する2つのファイルの先頭のパケットシーケンス番号がわかるため、後に伝送されるファイルの先頭パケットシーケンス番号から前に伝送されるファイルの先頭パケットシーケンス番号を減ずることにより、前に伝送されるファイルの分割データ数を特定することができる。つまり、例えば、図54に示すFile#1と図55に示すFile#2とがこの順に連続したファイルである場合には、File#1の最後のパケットシーケンス番号とFile#2の先頭のパケットシーケンス番号とは連続した番号が付与されている。
また、ファイルの分割方法を規定することにより、ファイルの分割データ数を特定できるように規定してもよい。例えば、分割データ数がNの場合、1~(N-1)番目の分割データのそれぞれのサイズはLとし、N番目の分割データのサイズは端数(item_size-L*(N-1))と規定することにより、アセット管理テーブルに示されるitem_sizeから分割データ数を逆算できる。この場合、(item_size / L)を切り上げた整数値が分割データ数となる。なお、ファイルの分割方法は、これに限るものではない。
また、分割データ数を直接アセット管理テーブルに格納してもよい。
受信装置では、上記の方法を用いることにより、制御情報を受信し、制御情報に基づいて分割データ数を算出する。また、制御情報に基づいてファイルの分割データ番号に対応するパケットシーケンス番号を算出できる。なお、制御情報の受信のタイミングより、分割データのパケットの受信のタイミングが早い場合は、制御情報を受信したタイミングで分割データ番号や分割データ数を算出してもよい。
なお、上記方法を用いて分割データ番号、或いは分割データ数をシグナリングする場合、フラグメントカウンタに基づいて分割データ番号や分割データ数を特定することはなく、フラグメントカウンタは不要なデータとなる。そこで、非同期メディアの伝送において、上記方法等を用いて分割データ番号、および、分割データ数を特定できる情報がシグナリングされている場合には、フラグメントカウンタは運用しない、或いは、ヘッダ圧縮してもよい。これにより、送信装置や受信装置の処理量を削減することができ、伝送効率を向上させることもできる。つまり、非同期メディアを送信する場合には、フラグメントカウンタをreserved(無効化)としてもよい。具体的には、フラグメントカウンタの値を例えば「0」の固定値としてもよい。また、非同期メディアを受信する場合には、フラグメントカウンタを無視してもよい。
映像や音声などの同期メディアを格納する場合においては、送出装置におけるMMTPパケットの送信順と受信装置におけるMMTPパケットの到着順が一致しており、かつ、パケットが再送されない。このような場合において、パケットロスを検出して再構成する必要がない場合には、フラグメントカウンタを運用しないとしてもよい。言い換えると、この場合では、フラグメントカウンタをreserved(無効化)としてもよい。
また、フラグメントカウンタを用いなくても、ランダムアクセスポイントの検出、アクセスユニット先頭の検出、NALユニット先頭の検出などをすることが可能であり、復号処理や、パケットロスの検出、パケットロスからの復帰の処理をすることができる。
また、ライブ放送などのリアルタイムなコンテンツの伝送では、より低遅延な伝送が求められ、符号化が完了したデータから順次パケット化して送出することが求められる。しかし、リアルタイムなコンテンツの伝送において、従来のフラグメントカウンタでは、先頭の分割データの送出時に分割データ数は決定できないため、先頭の分割データの送出は、データユニットの符号化がすべて完了し、分割データ数が決定した後となり、遅延が発生する。このような場合であっても、上記の方法を用いて、フラグメントカウンタを運用しないことにより、この遅延を削減できる。
図57は、受信装置における分割データ番号を特定する動作フローである。
受信装置は、ファイルの情報が記載された制御情報を取得する(S1201)。受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されているかどうかを判定し(S1202)、制御情報にファイル先頭のパケットシーケンス番号が示されている場合には(S1202でYes)、ファイルの分割データの分割データ番号に対応するパケットシーケンス番号を算出する(S1203)。そして、受信装置は、分割データが格納されたMMTPパケットを取得後、取得したMMTPパケットのパケットヘッダに格納されるパケットシーケンス番号からファイルの分割データ番号を特定する(S1204)。一方、受信装置は、制御情報にファイル先頭のパケットシーケンス番号が示されていない場合には(S1202でNo)、ファイル最後の分割データが含まれるMMTPパケットを取得後、取得したMMTPパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ番号を特定する(S1205)。
図58は、受信装置における分割データ数を特定する動作フローである。
受信装置は、ファイルの情報が記載された制御情報を取得する(S1301)。受信装置は、制御情報にファイルの分割データ数を算出可能な情報が含まれているかどうかを判定し(S1302)、分割データ数を算出可能な情報が含まれていると判定した場合には、(S1302でYes)、制御情報に含まれる情報に基づいて分割データ数を算出する(S1303)。一方、受信装置は、分割データ数を算出不可能であると判定した場合には(S1302でNo)、ファイル最後の分割データが含まれるMMTPパケットを取得後、取得したMMTPパケットのパケットヘッダに格納されるフラグメントインジケータ、および、パケットシーケンス番号を用いて分割データ数を特定する(S1304)。
図59は、送信装置においてフラグメントカウンタを運用するかどうかを決定するための動作フローである。
まず、送信装置は、伝送するメディア(以下、「メディアデータ」とも言う。)が同期メディアか、非同期メディアかを判定する(S1401)。
ステップS1401での判定の結果が同期メディアである場合(S1402で同期メディア)、送信装置は、同期メディアを伝送する環境において送受信のMMTPパケット順が一致し、かつパケットロス時にパケット再構成が不要かどうかを判定する(S1403)。送信装置は、不要であると判定した場合(S1403でYes)、フラグメントカウンタを運用しない(S1404)。一方、送信装置は、不要でないと判定した場合(S1403でNo)、フラグメントカウンタを運用する(S1405)。
ステップS1401での判定の結果が非同期メディアである場合(S1402で非同期メディア)、送信装置は、上述で説明した方法を用いて分割データ番号や分割データ数がシグナリングされるかどうかに基づいて、フラグメントカウンタを運用するか否かを決定する。具体的には、送信装置は、分割データ番号や分割データ数がシグナリングされる場合(S1406でYes)、フラグメントカウンタを運用しない(S1404)。一方、送信装置は、分割データ番号や分割データ数がシグナリングされない場合(S1406でNo)、フラグメントカウンタを運用する(S1405)。
なお、送信装置は、フラグメントカウンタを運用しない場合、フラグメントカウンタの値をreservedとしてもよいし、ヘッダ圧縮をしてもよい。
なお、送信装置は、フラグメントカウンタを運用するかどうかに基づいて、上述した分割データ番号や分割データ数をシグナリングするかどうかを決定してもよい。
なお、送信装置は、同期メディアがフラグメントカウンタを運用しない場合には、非同期メディアにおいて上述した方法を用いて分割データ番号や分割データ数をシグナリングしてもよい。逆に、非同期メディアがフラグメントカウンタを運用するかどうかに基づいて、同期メディアの運用を決定してもよい。この場合、同期メディアと非同期メディアとにおいて、フラグメントを運用するかどうかを同じ運用とすることができる。
次に、分割データ数、分割データ番号を特定する方法(フラグメントカウンタを活用する場合)について説明する。図60は、分割データ数、分割データ番号を特定する方法(フラグメントカウンタを活用する場合)について説明するための図である。
図54を用いて説明したように、分割データ数が256以下であり、分割データ数があらかじめ256以下であることが既知である場合には、フラグメントカウンタを参照することにより、分割データ番号や分割データ数を特定することが可能である。
ファイルの分割データ数を256以下に制限する場合、1つのパケットで伝送可能なデータサイズをx[bytes]とした場合、伝送可能なファイルの最大サイズはx*256[bytes]に制限される。例えば、放送ではx=4k[bytes]が想定されており、この場合、伝送可能なファイルの最大サイズは4k*256=1M[bytes]に制限される。
ファイルサイズが、伝送可能なファイルの最大サイズを超える場合、分割ファイルのサイズがx*256[bytes]以下となるように予めファイルを分割する。ファイルが分割することにより得られた複数の分割ファイルのそれぞれは、一つのファイル(item)として扱われ、さらに256以内に分割され、さらに分割されることにより得られた分割データがそれぞれMMTPパケットに格納されて伝送される。
なお、アイテムが分割ファイルであることを示す情報や、分割ファイル数、分割ファイルのシーケンス番号を制御情報に格納し、受信装置に送信してもよい。また、これらの情報をアセット管理テーブルに格納してもよいし、既存のフィールドitem_info_byteの一部を用いて示してもよい。
受信装置は、アイテムが1つのファイルを分割することにより得られた複数の分割ファイルのうちの1つの分割ファイルである場合には、他の分割ファイルを特定し、元のファイルを再構成することができる。また、受信装置では、制御情報における分割ファイルの分割ファイル数、分割ファイルのインデックス、および、フラグメントカウンタを用いることにより、分割データ数や、分割データ番号を一意に特定することができる。また、パケットシーケンス番号などを用いることなく分割データ数や分割データ番号を一意に特定できる。
ここで、1つのファイルを分割することにより得られた複数の分割ファイルそれぞれのitem_idは、互いに同じであることが望ましい。なお、別のitem_idを付与する場合は、他の制御情報などからファイルを一意に参照するために、先頭の分割ファイルのitem_idを示すとしてもよい。
また、複数の分割ファイルは、必ず同じMPUに属するとしてもよい。MPUに複数のファイルを格納する場合には、異なる種類のファイルは格納せず、必ず1つのファイルを分割したファイルが格納されているとしてもよい。受信装置はitem毎のバージョン情報を確認せずとも、MPU毎のバージョン情報を確認することで、ファイルの更新を検知できる。
図61は、フラグメントカウンタを活用する場合の送信装置の動作フローである。
まず、送信装置は、伝送するファイルのサイズを確認する(S1501)。次に送信装置は、ファイルサイズがx*256[bytes](xは、1つのパケットで伝送できるデータサイズ。例えば、MTUサイズ。)を超えるか否かを判定し(S1502)、ファイルサイズがx*256[bytes]を超える場合には(S1502でYes)、分割ファイルのサイズがx*256[bytes]未満となるようにファイルを分割する(S1503)。そして、分割ファイルをアイテムとして伝送し、分割ファイルに関する情報(例えば、分割ファイルであること、分割ファイルにおけるシーケンス番号など)を制御情報に格納して伝送する(S1504)。一方、ファイルサイズがx*256[bytes]未満である場合には(S1502でNo)、通常通りファイルをアイテムとして伝送する(S1505)。
図62は、フラグメントカウンタを活用する場合の受信装置の動作フローである。
まず、受信装置は、アセット管理テーブルなどのファイルの伝送に関する制御情報を取得、解析する(S1601)。次に、受信装置は、所望のアイテムが分割ファイルであるかどうかを判定する(S1602)。受信装置は、所望のファイルが分割ファイルであると判定した場合には(S1602でYes)、分割ファイルや分割ファイルのインデックスなど、ファイルを再構成するための情報を制御情報から取得する(S1603)。そして、受信装置は、分割ファイルを構成するアイテムを取得し、元のファイルを再構成する(S1604)。一方、受信装置は、所望のファイルが分割ファイルでないと判定した場合(S1602でNo)、通常通りファイルを取得する(S1605)。
要するに、送信装置は、ファイル先頭の分割データのパケットシーケンス番号をシグナリングする。また、送信装置は、分割データ数を特定できる情報をシグナリングする。或いは、送信装置は、分割データ数を特定できる分割ルールを規定する。また、送信装置は、フラグメントカウンタを運用せずに、reserved或いはヘッダ圧縮する。
受信装置は、ファイル先頭のデータのパケットシーケンス番号がシグナリングされている場合には、ファイル先頭の分割データのパケットシーケンス番号と、MMTPパケットのパケットシーケンス番号から、分割データ番号や分割データ数を特定する。
別の観点では、送信装置は、ファイルを分割し、分割ファイル毎にデータを分割して送信する。分割ファイルを紐づける情報(シーケンス番号、分割数など)をシグナリングする。
受信装置は、フラグメントカウンタ、及び分割ファイルのシーケンス番号により、分割データ番号や分割データ数を特定する。
これにより、分割データ番号や分割データを一意に特定できる。また、途中の分割データを受信した時点で当該分割データの分割データ番号を特定できるため、待機時間を削減し、メモリも削減できる。
また、フラグメントカウンタを運用しないことにより、送受信装置の構成は処理量を削減することができる、また、伝送効率を向上させることができる。
図63は、同一番組を複数のIPデータフローで送信する場合のサービス構成を示す図である。ここでは、サービスID=2の番組の一部(映像・音声)のデータがMMT方式を用いたIPデータフローで送信され、同じサービスIDであり、当該一部のデータとは異なるデータが高度BSデータ伝送方式を用いたIPデータフロー(この例ではファイル伝送プロトコルも異なるが同じプロトコルであってもよい。)で送信される例を示している。
送信装置は、受信装置において、複数のIPデータフローから構成されるデータが、復号時刻までに揃うことを保証できるように、IPデータの多重化を行う。
受信装置は、複数のIPデータフローから構成されるデータを用いて、復号時刻に基づいて処理することにより、保証された受信機動作を実現することができる。
[補足:送信装置及び受信装置]
以上のように、フラグメントカウンタを運用せずにデータの送信を行う送信装置は、図64のように構成することも可能である。また、フラグメントカウンタを運用せずにデータの受信を行う受信装置は、図65のように構成することも可能である。図64は、送信装置の具体的構成の例を示す図である。図65は、受信装置の具体的構成の例を示す図である。
以上のように、フラグメントカウンタを運用せずにデータの送信を行う送信装置は、図64のように構成することも可能である。また、フラグメントカウンタを運用せずにデータの受信を行う受信装置は、図65のように構成することも可能である。図64は、送信装置の具体的構成の例を示す図である。図65は、受信装置の具体的構成の例を示す図である。
送信装置500は、分割部501と、構成部502と、送信部503とを備える。分割部501、構成部502、及び送信部503のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置600は、受信部601と、判定部602と、構成部603とを備える。受信部601、判定部602、及び構成部603のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置500及び受信装置600の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法について、図66を用いて説明する。図66は、送信装置による動作フロー(送信方法)である。
まず、送信装置500の分割部501は、データを複数の分割データに分割する(S1701)。
次に、送信装置500の構成部502は、複数の分割データのそれぞれにヘッダ情報を付与してパケット化することで、複数のパケットを構成する(S1702)。
そして、送信装置500の送信部503は、構成された前記複数のパケットを送信する(S1703)。送信部503は、分割データ情報、および、無効化されたフラグメントカウンタの値を、送信する。なお、分割データ情報は、分割データ番号と、分割データ数とを特定するための情報である。また、分割データ番号は、当該分割データが複数の分割データのうちの何番目の分割データであるかを示す番号である。分割データ数は、複数の分割データの数である。
これにより、送信装置500の処理量を削減することができる。
次に、受信方法について、図67を用いて説明する。図67は、受信装置による動作フロー(受信方法)である。
まず、受信装置600の受信部601は、複数のパケットを受信する(S1801)。
次に、受信装置600の判定部602は、受信した複数のパケットから、分割データ情報が、当取得されたか否かを判定する(S1802)。
そして、受信装置600の構成部603は、判定部602により、分割データ情報を取得したと判定された場合(S1802でYes)、当該ヘッダ情報に含まれるフラグメントカウンタの値を使用せずに、受信した複数のパケットからデータを構成する(S1803)。
一方で、構成部603は、判定部602により、分割データ情報を取得していないと判定された場合(S1802でNo)、当該ヘッダ情報に含まれるフラグメントカウンタの値を用いて、受信した複数のパケットからデータを構成してもよい(S1804)。
これにより、受信装置600の処理量を削減することができる。
(実施の形態5)
[概要]
実施の形態5では、NALサイズフォーマットでNALユニットを多重化レイヤに格納した場合の伝送パケット(TLVパケット)の送信方法について説明する。
[概要]
実施の形態5では、NALサイズフォーマットでNALユニットを多重化レイヤに格納した場合の伝送パケット(TLVパケット)の送信方法について説明する。
実施の形態1で説明したように、H.264やH.265のNALユニットを多重化レイヤに格納する際には、次の2種類の形式がある。1つは、NALユニットヘッダの直前に特定のビット列からなるスタートコードを付加するバイトストリームフォーマットと呼ばれる形式である。もう1つは、NALユニットのサイズを示すフィールドを付加するNALサイズフォーマットと呼ばれる形式である。バイトストリームフォーマットは、MPEG-2システムやRTPなどにおいて用いられ、NALサイズフォーマットはMP4、あるいは、MP4を使用するDASHやMMTなどにおいて用いられる。
バイトストリームフォーマットにおいて、スタートコードは3バイトで構成され、さらに任意のバイト(値は0であるバイト)を付加することもできる。
一方で、一般的なMP4におけるNALサイズフォーマットでは、サイズ情報は、1バイト、2バイト、および4バイトのいずれかで示される。このサイズ情報は、HEVCサンプルエントリにおけるlengthSizeMinusOneフィールドで示される。当該フィールドの値が「0」の場合は1バイト、「1」の場合は2バイト、「3」の場合は4バイトであることを示す。
ここで、2014年7月に規格化された、ARIB STD-B60「デジタル放送におけるMMTによるメディアトランスポート方式」では、NALユニットを多重化レイヤに格納する際、HEVCエンコーダの出力がバイトストリームである場合、バイトスタートコードを除去し、32ビット(符号なし整数)で示したバイト単位のNALユニットのサイズを長さ情報としてNALユニットの直前に付加する。なお、HEVCサンプルエントリを含むMPUメタデータを伝送せず、サイズ情報は32ビット(4バイト)固定である。
また、ARIB STD-B60「デジタル放送におけるMMTによるメディアトランスポート方式」では、送信装置が受信装置におけるバッファ動作を保証するために送信の際に考慮する受信バッファモデルにおいては、映像信号の復号前バッファは、CPBであると規定されている。
しかし、次のような課題がある。MPEG-2システムにおけるCPBや、HEVCにおけるHRDでは、映像信号がバイトストリームフォーマットであることを前提に規定されている。このため、例えば、3バイトのスタートコードが付いたバイトストリームフォーマットであることを前提に伝送パケットのレート制御を行った場合、4バイトのサイズ領域が付加されたNALサイズフォーマットの伝送パケットを受信した受信装置は、ARIB STD-B60における受信バッファモデルを満たすことができない可能性がある。また、ARIB STD-B60における受信バッファモデルには、具体的なバッファサイズ、および、引き抜きレートが示されていないため、受信装置におけるバッファ動作を保証することは難しい。
したがって、上記の課題を解決するために、受信機におけるバッファ動作を保証するための受信バッファモデルを下記のように規定する。
図68は、ARIB STD-B60に規定されている受信バッファモデルに基づいて、特に放送伝送路のみを用いた場合の受信バッファモデルを示す。
受信バッファモデルは、TLVパケットバッファ(第1のバッファ)と、IPパケットバッファ(第2のバッファ)と、MMTPバッファ(第3のバッファ)と、復号前バッファ(第4のバッファ)とを備える。なお、放送伝送路では、デジッタバッファやFECのためのバッファは必要ないため、省略している。
TLVパケットバッファは、TLVパケット(伝送パケット)を放送伝送路から受信し、受信したTLVパケットに格納されている可変長のパケットヘッダ(IPパケットヘッダ、IPパケット圧縮時のフルヘッダ、IPパケット圧縮時の圧縮ヘッダ)、および可変長のペイロードで構成されるIPパケットを、ヘッダ伸張された固定長のIPパケットヘッダを有するIPパケット(第1のパケット)に変換し、変換することにより得られたIPパケットを一定のビットレートで出力する。
IPパケットバッファは、IPパケットをパケットヘッダおよび可変長のペイロードを有するMMTPパケット(第2のパケット)に変換し、変換することにより得られたMMTPパケットを一定のビットレートで出力する。なお、IPパケットバッファは、MMTPバッファにマージされていても良い。
MMTPバッファは、出力されたMMTPパケットをNALユニットに変換し、変換することにより得られたNALユニットを一定のビットレートで出力する。
復号前バッファは、出力されたNALユニットを順次蓄積し、蓄積した複数のNALユニットからアクセスユニットを生成し、生成したアクセスユニットを当該アクセスユニットに対応した復号時刻のタイミングでデコーダに出力する。
図68に示す受信バッファモデルでは、前段のTLVパケットバッファおよびIPパケットバッファ以外のバッファであるMMTPバッファおよび復号前バッファは、MPEG-2 TSにおける受信バッファモデルを踏襲することが特徴的である。
例えば、映像におけるMMTPバッファ(MMTP B1)は、MPEG-2 TSにおけるトランスポートバッファ(TB)、及び、多重化バッファ(MB)に相当するバッファで構成される。また、音声におけるMMTPバッファ(MMTP Bn)は、MPEG-2 TSにおけるトランスポートバッファ(TB)に相当するバッファで構成される。
トランスポートバッファのバッファサイズは、MPEG-2 TS同様であり固定値とする。例えば、MTUサイズのn倍(nは、小数であっても整数であってもよく、1以上とする。)とする。
また、MMTPパケットヘッダのオーバーヘッド率がPESパケットヘッダのオーバーヘッド率よりも小さくなるように、MMTPパケットサイズを規定する。これにより、トランスポートバッファからの引き抜きレートは、MPEG-2 TSにおけるトランスポートバッファの引き抜きレートRX1、RXn、RXsをそのまま適用することができる。
また、多重化バッファのサイズ、および、引き抜きレートは、それぞれ、MPEG-2 TSにおけるMBサイズ、および、RBX1とする。
以上の受信バッファモデルに加え、課題を解決するために、下記の制約を設ける。
HEVCのHRD規定は、バイトストリーム形式が前提であり、MMTはNALユニットの先頭に4バイトのサイズ領域を付加するNALサイズ形式である。したがって、符号化時にはNALサイズ形式において、HRDを満たすようにレート制御を行う。
つまり、送信装置では、上記の受信バッファモデルおよび制約に基づいて、伝送パケットのレート制御を行う。
受信装置では、上記の信号を用いて受信処理をすることにより、アンダーフローやオーバーフローすることなる復号動作をすることができる。
なお、NALユニットの先頭のサイズ領域は4バイトでなくても、NALユニットの先頭のサイズ領域を考慮して、HRDを満たすようにレート制御を行う。
なお、TLVパケットバッファの引き抜きレート(TLVパケットバッファがIPパケットを出力する際のビットレート)は、IPヘッダ伸張後の伝送レートを考慮して設定する。
つまり、データサイズが可変長であるTLVパケットを入力し、TLVヘッダの除去およびIPヘッダの伸張(復元)を実施した後、出力されるIPパケットの伝送レートを考慮する。言い換えれば、入力される伝送レートに対してヘッダの増減量を考慮する。
具体的には、データサイズが可変長であること、IPヘッダ圧縮されるパケットとIPヘッダ圧縮されていないパケットとが混在すること、IPv4,IPv6などのパケット種別によりIPヘッダのサイズが異なることから、出力されるIPパケットの伝送レートは一意ではない。このため、可変長のデータサイズの平均パケット長を定め、TLVパケットから出力されるIPパケットの伝送レートを定める。
ここでは、IPヘッダ伸張後の最大伝送速度を規定するために、IPヘッダは常に圧縮されている場合を想定して伝送レートを定める。
また、IPv4、IPv6のパケット種別が混在する場合、或いは、パケット種別を区別することなく規定する場合は、ヘッダサイズが大きく、ヘッダ伸張後の増加率の大きいIPv6パケットを想定して伝送レートを定める。
例えば、TLVパケットバッファに入力されるTLVパケットの平均パケット長がSであり、TLVパケットに格納されるIPパケットはすべてIPv6パケットであり、ヘッダ圧縮されているとした場合の、TLVヘッダの除去及びIPヘッダの伸張後の最大出力伝送レートは、
入力レート×{S/(S+IPv6ヘッダ圧縮量)}
となる。
入力レート×{S/(S+IPv6ヘッダ圧縮量)}
となる。
より具体的には、TLVパケットの平均パケット長Sを、
S=0.75×1500(1500は最大MTUサイズを想定)
を基準として設定し、
IPv6ヘッダ圧縮量=TLVヘッダ長-IPv6ヘッダ長-UDPヘッダ長
=3-40-8とした場合、TLVヘッダの除去及びIPヘッダの伸張後の最大出力伝送レートは、
入力レート×1.0417≒入力レート×1.05
となる。
S=0.75×1500(1500は最大MTUサイズを想定)
を基準として設定し、
IPv6ヘッダ圧縮量=TLVヘッダ長-IPv6ヘッダ長-UDPヘッダ長
=3-40-8とした場合、TLVヘッダの除去及びIPヘッダの伸張後の最大出力伝送レートは、
入力レート×1.0417≒入力レート×1.05
となる。
図69は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例を示す図である。
MMT方式では、データユニットをアグリゲーションする際、図69に示すように、データユニットの前に、データユニット長、及び、データユニットヘッダが付加される。
しかし、例えば、NALサイズフォーマットの映像信号を一つのデータユニットとして格納する場合、図70に示すように、一つのデータユニットに対して、サイズを示すフィールドが2つあり、情報として重複している。図70は、複数のデータユニットをアグリゲーションして一つのペイロードに格納する例であって、NALサイズフォーマットの映像信号を一つのデータユニットとした場合の例を示す図である。具体的には、NALサイズフォーマットにおける先頭のサイズ領域(以降の説明では、「size領域」と呼ぶ。)と、MMTPペイロードヘッダにおけるデータユニットヘッダの前に位置するデータユニット長フィールドとのいずれもサイズを示すフィールドであり、情報として重複している。例えば、NALユニットの長さがLバイトである場合、size領域にはLバイトが示されており、データユニット長フィールドには、Lバイト+「size領域の長さ」(byte)が示される。size領域と、データユニット長フィールドとで示される値は完全に一致はしていないが、一方の値から他方の値を容易に算出できるため、重複していると言える。
このように、データのサイズ情報を内部に含むデータをデータユニットとして格納し、かつ、複数の当該データユニットをアグリゲーションして一つのペイロードに格納する場合、サイズ情報が重複するため、オーバーヘッドが大きく、伝送効率が悪いと言う課題がある。
そこで、送出装置では、データのサイズ情報を内部に含むデータをデータユニットとして格納し、かつ、複数の当該データユニットをアグリゲーションして一つのペイロードに格納する場合、図71や図72に示すように格納することが考えられる。
図71に示すように、size領域を含むNALユニットをデータユニットとして格納し、MMTPペイロードヘッダに従来含まれるデータユニット長は示さないことが考えられる。図71は、データユニット長が示されないMMTPパケットのペイロードの構成を示す図である。
また、図72に示すように、データユニット長が示されているかどうかを示すフラグや、size領域の長さを示す情報を新たにヘッダに格納してもよい。フラグやsize領域の長さを示す情報を格納する場所は、データユニットヘッダなど、データユニット単位で示してもよいし、複数のデータユニットをアグリゲーションした単位で(パケット単位)で示してもよい。図72は、パケット単位に付与されるextend領域に示す例である。なお、上記の新規に示す情報の格納場所はこれに限るものではなく、MMTPペイロードヘッダやMMTPパケットヘッダ、制御情報であってもよい。
受信側では、データユニット長が圧縮されているかどうかを示すフラグが、データユニット長が圧縮されていることを示している場合は、データユニット内部のsize領域の長さ情報を取得し、size領域の長さ情報に基づいて、size領域を取得することにより、取得したsize領域の長さ情報およびsize領域を用いてデータユニット長を算出できる。
以上の方法により、送出側でデータ量を削減することができ、伝送効率を向上できる。
なお、データユニット長を削減するのではなく、size領域を削減することによりオーバーヘッド削減してもよい。size領域を削減する場合には、size領域が削減されているかどうかを示す情報や、データユニット長フィールドの長さを示す情報を格納してもよい。
なお、MMTPペイロードヘッダにも、長さ情報が含まれる。
size領域を含むNALユニットをデータユニットとして格納する場合は、アグリゲーションする/しないにかかわらず、MMTPペイロードヘッダにおけるペイロードサイズ領域を削減してもよい。
また、size領域を含まないデータをデータユニットとして格納する場合でも、アグリゲーションされており、データユニット長が示されている場合には、MMTPペイロードヘッダにおけるペイロードサイズ領域を削減してもよい。
ペイロードサイズ領域を削減する場合には、上記と同様に、削減したかどうかを示すフラグや、削減したサイズフィールドの長さ情報、或いは削減しなかったサイズフィールドの長さ情報を示してもよい。
図73は、受信装置の動作フローを示す。
送出装置では、上述したように、size領域を含むNALユニットをデータユニットとして格納し、MMTPペイロードヘッダに含まれるデータユニット長はMMTPパケットにおいて示さないとする。
以下では、データユニット長が示されているかどうかをフラグや、size領域の長さ情報がMMTPパケットにおいて示されている場合を例に説明する。
受信装置は、データユニットがサイズ領域を含み、データユニット長が削減されているかどうかを、送出側から送信される情報に基づいて判定する(S1901)。
データユニット長が削減されていると判定した場合(S1902でYes)、データユニット内部のサイズ領域の長さ情報を取得し、その後、データユニット内部のサイズ領域を解析し、データユニット長を算出することにより取得する(S1903)。
一方、データユニット長が削減されていないと判定した場合(S1902でNo)、通常どおり、データユニット長、および、データユニット内部のサイズ領域のいずれか一方からデータユニット長を算出する(S1904)。
なお、データユニット長が削減されているかどうかを示すフラグや、size領域の長さ情報は、予め受信装置が分かっている場合、送信しなくてもよい。この場合受信装置は予め定められた情報に基づいて図73で示した処理を行う。
[補足:送信装置及び受信装置]
以上のように、符号化時に受信バッファモデルの規定を満たすようにレート制御を行う送信装置は、図74のように構成することも可能である。また、送信装置から送信された伝送パケットを受信し、復号する受信装置は、図75のように構成することも可能である。図74は、送信装置の具体的構成の例を示す図である。図75は、受信装置の具体的構成の例を示す図である。
以上のように、符号化時に受信バッファモデルの規定を満たすようにレート制御を行う送信装置は、図74のように構成することも可能である。また、送信装置から送信された伝送パケットを受信し、復号する受信装置は、図75のように構成することも可能である。図74は、送信装置の具体的構成の例を示す図である。図75は、受信装置の具体的構成の例を示す図である。
送信装置700は、生成部701と、送信部702とを備える。生成部701及び送信部702のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置800は、受信部801と、第1のバッファ802と、第2のバッファ803と、第3のバッファ804と、第4のバッファ805と、復号部806とを備える。受信部801、第1のバッファ802、第2のバッファ803、第3のバッファ804、第4のバッファ805及び復号部(デコーダ)806のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置700及び受信装置800の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法について、図76を用いて説明する。図76は、送信装置による動作フロー(送信方法)である。
まず、送信装置700の生成部701は、受信装置のバッファ動作を保証するために予め定められた受信バッファモデルによる規定を満たすようにレート制御を行うことで符号化ストリームを生成する(S2001)。
次に、送信装置700の送信部702は、生成された符号化ストリームをパケット化し、パケット化することで得られた伝送パケットを送信する(S2002)。
なお、送信装置700において用いられる受信バッファモデルは、受信装置800の構成の第1~第4のバッファ802~805を備える構成であるため、説明を省略する。
これにより、送信装置700は、MMTのような方式を用いてデータ伝送する場合に、受信装置800のバッファ動作を保証できる。
次に、受信方法について、図77を用いて説明する。図77は、受信装置による動作フロー(受信方法)である。
まず、受信装置800の受信部801は、固定長のパケットヘッダおよび可変長のペイロードで構成された伝送パケットを受信する(S2101)。
次に、受信装置800の第1のバッファ802は、受信した伝送パケットに格納されている可変長のパケットヘッダおよび可変長のペイロードで構成されるパケットを、ヘッダ伸張された固定長のパケットヘッダを有する第1のパケットに変換し、変換することにより得られた前記第1のパケットを一定のビットレートで出力する(S2102)。
次に、受信装置800の第2のバッファ803は、変換することにより得られた第1のパケットをパケットヘッダおよび可変長のペイロードで構成される第2のパケットに変換し、変換することにより得られた第2のパケットを一定のビットレートで出力する(S2103)。
次に、受信装置800の第3のバッファ804は、出力された第2のパケットをNALユニットに変換し、変換することにより得られたNALユニットを一定のビットレートで出力する(S2104)。
次に、受信装置800の第4のバッファ805は、出力されたNALユニットを順次蓄積し、蓄積した複数のNALユニットからアクセスユニットを生成し、生成したアクセスユニットを当該アクセスユニットに対応した復号時刻のタイミングでデコーダに出力する(S2105)。
そして、受信装置800の復号部806は、第4のバッファにより出力されたアクセスユニットを復号する(S2106)。
これにより、受信装置800は、アンダーフローやオーバーフローすることなる復号動作を行うことができる。
(実施の形態6)
[概要]
実施の形態6では、MMT/TLVの伝送方式における基準クロックの基準となる時刻情報にうるう秒調整が行なわれる場合の送信方法及び受信方法について説明する。
[概要]
実施の形態6では、MMT/TLVの伝送方式における基準クロックの基準となる時刻情報にうるう秒調整が行なわれる場合の送信方法及び受信方法について説明する。
図78は、ARIB STD-B60に規定されるMMT/TLV方式のプロトコルスタックを示す図である。
MMT方式では、パケットには、映像や音声などのデータを複数のMPU(Media
Presentation Unit)やMFU(Media Fragment Unit)などの第1のデータユニットごとに格納し、MMTPパケットヘッダを付与することで所定のパケットとしてのMMTPパケットを生成する(MMTPパケット化する)。また、MMTPにおける制御メッセージなどの制御情報に対しても、MMTPパケットヘッダを付与することで、所定のパケットとしてのMMTPパケットを生成する。MMTPパケットヘッダには、32ビットのショートフォーマットのNTP(Network Time Protocol:IETF RFC 5905に規定)を格納するフィールドが設けられており、通信回線のQoS制御等に用いることができる。
Presentation Unit)やMFU(Media Fragment Unit)などの第1のデータユニットごとに格納し、MMTPパケットヘッダを付与することで所定のパケットとしてのMMTPパケットを生成する(MMTPパケット化する)。また、MMTPにおける制御メッセージなどの制御情報に対しても、MMTPパケットヘッダを付与することで、所定のパケットとしてのMMTPパケットを生成する。MMTPパケットヘッダには、32ビットのショートフォーマットのNTP(Network Time Protocol:IETF RFC 5905に規定)を格納するフィールドが設けられており、通信回線のQoS制御等に用いることができる。
また、送信側(送信装置)の基準クロックをRFC 5905に規定される64ビットのロングフォーマットNTPに同期させ、同期させた当該基準クロックを基に、PTS(Presentation Time Stamp)や、DTS(Decode Time Stamp)などのタイムスタンプを同期メディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では送信側から受信した基準クロック情報を基に受信装置におけるシステムクロックを生成する。
PTSやDTSは、具体的には、MMTPの制御情報であるMPUタイムスタンプ記述子や、MPU拡張タイムスタンプ記述子に格納されて、アセット毎にMPテーブルに格納され、制御メッセージとしてMMTPパケット化された後、伝送される。
MMTPパケット化されたデータは、UDPヘッダやIPヘッダが付与されIPパケットにカプセル化される。このとき、IPヘッダやUDPヘッダにおいて、送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、プロトコル種別が同じもののパケットの集合をIPデータフローとする。なお、同じIPデータフローのIPパケットは、ヘッダが冗長であるため、一部のIPパケットではヘッダ圧縮される。
また、基準クロック情報として、64ビットのNTPタイムスタンプは、NTPパケットに格納され、IPパケットに格納される。このとき、NTPパケットを格納するIPパケットでは、送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別は固定値であり、IPパケットのヘッダは圧縮されない。
図79は、TLVパケットの構成を示す図である。
TLVパケットには、図79に示すように、IPパケット、圧縮IPパケット、AMT(Address Map Table)やNIT(Network Information Table)などの伝送制御情報をデータとして含むことができ、これらのデータは、8ビットのデータタイプを用いて識別される。また、TLVパケットでは、16ビットのフィールドを用いてデータ長(バイト単位)が示され、そのあとにデータの値を格納する。また、TLVパケットは、データタイプの前に1バイトのヘッダ情報を有し、当該ヘッダ情報は、合計4バイトのヘッダ領域に格納される。また、TLVパケットは、高度BS伝送方式における伝送スロットにマッピングされ、TMCC(Transmission and Multiplexing Configuration Control)制御情報にマッピング情報が格納される。
図80は、受信装置のブロック図の一例を示す図である。
受信装置では、まずチューナーで受信した放送信号に対し、復調手段において伝送路符号化データを復号、誤り訂正などを施し、TLVパケットを抽出する。そして、TLV/IP DEMUX手段では、TLVのDEMUX処理やIPのDEMUX処理を行う。TLVのDEMUX処理は、TLVパケットのデータタイプに応じた処理を行う。例えば、TLVパケットが圧縮IPパケットを有する場合は、当該圧縮IPパケットの圧縮されたヘッダを復元する。IP DEMUXでは、IPパケットやUDPパケットのヘッダ解析などの処理を行い、MMTPパケット及びNTPパケットを抽出する。
NTPクロック生成手段では、抽出したNTPパケットからNTPクロックを再生する。MMTP DEMUXでは、抽出したMMTPパケットヘッダに格納されているパケットIDを基に映像や音声などのコンポーネントや制御情報のフィルタリング処理を行う。制御情報取得手段からは、MPテーブルの中に格納されるタイムスタンプ記述子を取得し、PTS/DTS算出手段においてアクセスユニット毎のPTS及びDTSを算出する。なお、タイムスタンプ記述子は、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子の両記述子を含む。
アクセスユニット再生手段では、MMTPパケットからフィルタリングされた映像や音声などを、提示する単位のデータに変換する。提示する単位のデータとは、具体的には、映像信号のNALユニットやアクセスユニット、音声フレーム、字幕の提示単位などである。復号提示手段では、NTPクロックの基準時刻情報をベースに、アクセスユニットのPTS/DTSが一致した時刻に、アクセスユニットを復号、提示する。
なお、受信装置の構成は、これに限るものではない。
次にタイムスタンプ記述子について説明する。
図81は、タイムスタンプ記述子について説明するための図である。
PTSやDTSは、MMTの制御情報である、第1制御情報としてのMPUタイムスタンプ記述子や第2制御情報としてのMPU拡張タイムスタンプ記述子に格納され、アセット毎にMPテーブルに格納され、制御メッセージとしてMMTPパケット化された後、伝送される。
図81の(a)はARIB STD-B60に規定されるMPUタイムスタンプ記述子の構成を示す図である。MPUタイムスタンプ記述子には、複数のMPUのそれぞれについて、当該MPUに格納されている第2のデータユニットとしての複数のアクセスユニット(AU)のうちの提示順で先頭(最初)のAU(以下、「先頭AU」という。)のPTS(64bitのNTPで示される絶対値)を示す提示時刻情報(第1時刻情報)が格納される。つまり、MPUに付与された当該MPUの提示時刻情報は、MMTPパケットの制御情報に格納されて送信される。
図81の(b)は、MPU拡張タイムスタンプ記述子の構成を示すである。MPU拡張タイムスタンプ記述子には、複数のMPUのそれぞれのMPU内に含まれるAUのPTS及びDTSを算出するための情報が格納される。MPU拡張タイムスタンプ記述子は、MPUタイムスタンプ記述子に格納されるMPUの先頭AUのPTSからの相対情報(第2時刻情報)を含んでおり、MPU内に含まれる複数のAUそれぞれのPTS及びDTSは、MPUタイムスタンプ記述子とMPU拡張タイムスタンプ記述子との両方に基づいて算出できる。つまり、MPU内に含まれる先頭AU以外のAUのPTS及びDTSは、MPUタイムスタンプ記述子に格納される当該先頭AUのPTSと、MPU拡張タイムスタンプ記述子に格納されている相対情報とに基づいて算出できる。
言い換えると、第2時刻情報は、第1時刻情報とで複数のAUそれぞれのPTSまたはDTSを算出するための相対的な時刻情報である。つまり、第2時刻情報は、第1時刻情報とで複数のAUそれぞれのPTSまたはDTSを示す情報である。
NTPは、協定世界時(Coordinated Universal Time(UTC))に基づいた基準時刻情報である。UTCは、地球の自転速度に基づく天文時との差を調整するため、うるう秒の調整(以下、「うるう秒調整」という。)を実施する。うるう秒調整は、具体的には、日本時間の午前9時に実施され、1秒の挿入または削除を行う調整である。
図82は、うるう秒調整を説明するための図である。
図82の(a)は、日本時間における、うるう秒挿入の一例を示す図である。図82の(a)に示すように、うるう秒挿入では、日本時間8:59:59の後、本来9:00:00になるタイミングで8:59:59となり、8:59:59台が2回繰り返される。
図82の(b)は、日本時間における、うるう秒削除の一例を示す図である。図82の(b)に示すように、うるう秒削除では、日本時間8:59:58の後、本来8:59:59になるタイミングで9:00:00となり、8:59:59台の1秒間が削除される。
NTPパケットには、64bitのタイムスタンプの他に、2bitのleap_indicatorが格納されている。leap_indicatorは、うるう秒調整が行なわれることを事前に通知するためのフラグであり、leap_indicator=1の場合にうるう秒挿入を示し、leap_indicator=2の場合にうるう秒削除を示す。事前通知は、うるう秒調整を実施する月の初めから通知する方法や、24時間前に通知する方法、その他、任意の時間に通知を開始する方法がある。また、leap_indicatorは、うるう秒調整が終わった時間(9:00:00)に0となる。例えば、24時間前から事前通知する場合には、日本時間でうるう秒調整が行われる前日の9:00からうるう秒調整が行われる当日におけるうるう秒調整が行われる直前の時刻(つまり、うるう秒挿入の場合は1回目の8:59:59台の時刻であり、うるう秒削除の場合は8:59:58台の時刻)までの間にleap_indicatorが「1」または「2」であることが示される。
次に、うるう秒調整時の課題について説明する。
図83は、NTP時刻、MPUタイムスタンプ及びMPU提示タイミングの関係を示す図である。なお、NTP時刻は、NTPにより示される時刻である。また、MPUタイムスタンプは、MPU内の先頭AUのPTSを示すタイムスタンプである。また、MPU提示タイミングとは、受信装置がMPUタイムスタンプに従ってMPUを提示すべきタイミングである。具体的には、図83の(a)~(c)は、それぞれ、うるう秒調整が発生しない場合、うるう秒が挿入される場合、うるう秒が削除される場合におけるNTP時刻、MPUタイムスタンプ及びMPU提示時刻の関係を示す図である。
ここでは、送出側のNTP時刻(基準クロック)は、NTPサーバと同期しており、また、受信側のNTP時刻(システムクロック)は、送出側のNTP時刻と同期している場合を例に説明する。この場合、受信装置では、送出側から伝送されるNTPパケットに格納されているタイムスタンプに基づいて再生する。また、この場合、送出側のNTP時刻及び受信側のNTP時刻共に、NTPサーバと同期しているため、うるう秒の調整時に±1秒の調整がなされる。また、図83におけるNTP時刻は、送出側のNTP時刻及び受信側のNTP時刻で共通であるとする。なお、伝送遅延はないものとして説明する。
図83におけるMPUタイムスタンプは、複数のMPUのそれぞれに含まれる複数のAUのうちの提示順における先頭AUのタイムスタンプを示しており、矢印の元で示されるNTP時刻に基づいて生成(設定)される。具体的には、MPUの提示時刻情報を生成するタイミングにおける基準時刻情報としてのNTP時刻に、予め定められた時間(図83では、例えば、1.5秒)を加算することで、MPUの提示時刻情報を生成する。生成されたMPUタイムスタンプは、MPUタイムスタンプ記述子に格納される。
受信装置では、MPUタイムスタンプ記述子に格納されるタイムスタンプに基づくMPU提示時刻においてMPUを提示する。
なお、図83では、1つのMPUの再生時間は1秒であるとして説明するが、1つのMPUの再生時間は、それ以外の再生時間であってもよく、例えば、0.5秒でもよいし、0.1秒でもよい。
図83の(a)の例では、受信装置は、MPUタイムスタンプ記述子に格納されるタイムスタンプに基づいてMPU#1-#5を順番に提示することができる。
しかし、図83の(b)では、うるう秒挿入によりMPU#2とMPU#3との提示時刻が重複する。このため、受信装置は、MPUタイムスタンプ記述子に格納されるタイムスタンプに基づいてMPUを提示してしまうと、同じ9:00:00台の時間帯に提示するMPUが2つ存在することになり、2つのMPUのどれを提示すべきかの判断ができない。また、受信装置は、MPU#1のタイムスタンプで示されるMPU提示時刻(8:59:59)が2回存在することになるため、2つのMPU提示時刻のうちどのMPU提示時刻で提示すべきかの判断ができない。
また、図83の(c)では、受信装置は、うるう秒の削除により、MPU#3のMPUタイムスタンプで示されるMPU提示時刻(8:59:59)がNTP時刻に存在しないため、MPU#3を提示することができない。
受信装置は、タイムスタンプに基づかないMPUの復号処理及び提示処理を行う場合には、上記のような課題を解決できる。しかし、タイムスタンプに基づく処理を行う受信装置は、うるう秒の発生時のみに、異なる処理(タイムスタンプに基づかない処理)を行うことは困難である。
次に、送信側においてタイムスタンプを補正することでうるう秒調整時の課題を解決する方法について説明する。
図84は、送信側においてタイムスタンプを補正する補正方法について説明するための図である。具体的には、図84の(a)は、うるう秒挿入の例を示し、図84の(b)は、うるう秒削除の例を示す図である。
まず、うるう秒挿入の場合について説明する。
図84の(a)に示すように、うるう秒挿入時には、うるう秒挿入の直前までの時刻(つまり、NTP時刻における1回目の8:59:59台まで)をA領域とし、うるう秒挿入以後の時刻(つまり、NTP時刻における2回目の8:59:59以降)をB領域とする。なお、A領域及びB領域は、時間的な領域であり、時間帯または期間である。図84の(a)におけるMPUタイムスタンプは、図83で説明したタイムスタンプと同様であり、MPUタイムスタンプを付与するタイミングにおけるNTPの時刻に基づいて生成(設定)したタイムスタンプである。
うるう秒挿入の場合に、送信側でのタイムスタンプの補正方法について具体的に説明する。
送信側(送信装置)では、以下の処理を行う。
1.MPUタイムスタンプを付与するタイミング(図84の(a)の矢印の元が示すタイミング)がA領域に含まれ、かつ、MPUタイムスタンプ(補正前のMPUタイムスタンプの値)が9:00:00以降を示す場合は、MPUタイムスタンプを1秒減ずる-1秒補正して、補正後のMPUタイムスタンプをMPUタイムスタンプ記述子に格納する。つまり、A領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプであり、かつ、当該MPUタイムスタンプが9:00:00以降を示す場合は、当該MPUタイムスタンプを-1秒補正する。なお、ここでの「9:00:00」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻(つまり、UTC時刻に9時間を加算することにより算出される時刻)である。また、別途補正したことを示す情報である補正情報を受信装置に送信する。
2.MPUタイムスタンプを付与するタイミング(図84の(a)の矢印の元が示すタイミング)がB領域の場合、MPUタイムスタンプを補正しない。つまり、B領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプである場合は、当該MPUタイムスタンプを補正しない。
受信装置においては、MPUタイムスタンプと、当該MPUタイムスタンプが補正されたか否か(つまり、補正したことを示す情報が含まれるか否か)を示す補正情報に基づいて、MPUを提示する。
受信装置は、MPUタイムスタンプが補正されていないと判定した場合(つまり、補正したことを示す情報が含まれていないと判定した場合)、MPUタイムスタンプ記述子に格納されるタイムスタンプが受信装置のNTP時刻(補正前、補正後両方含む)に一致した時刻にMPUを提示する。つまり、MPUタイムスタンプが補正されるMPUより前に送信されるMPUのMPUタイムスタンプ記述子に格納されたMPUタイムスタンプの場合、当該MPUタイムスタンプが、うるう秒挿入前(つまり、1回目の8:59:59台以前)のNTP時刻に一致したタイミングに当該MPUを提示する。また、受信したMPUのMPUタイムスタンプ記述子に格納されるMPUタイムスタンプが、補正されるMPUタイムスタンプより後に送信されるタイムスタンプの場合、うるう秒挿入後(つまり、2回目の8:59:59台以降)のNTP時刻に一致したタイミングに当該MPUを提示する。
また、受信装置は、受信したMPUのMPUタイムスタンプ記述子に格納されるMPUタイムスタンプが補正されている場合、MPUタイムスタンプ記述子に格納されるタイムスタンプが、受信装置においてうるう秒挿入後(つまり、2回目の8:59:59台以降)のNTP時刻に基づいてMPUを提示する。
なお、MPUタイムスタンプ値を補正したことを示す情報は、制御メッセージや記述子、テーブル、MPUメタデータ、MFメタデータ、MMTPパケットヘッダなどに格納して伝送する。
次に、うるう秒削除の場合について説明する。
図84の(b)に示すように、うるう秒削除時には、うるう秒削除の直前までの時刻(つまり、NTP時刻における9:00:00直前)をC領域とし、うるう秒削除以後の時刻(つまり、NTP時刻における9:00:00以降)をD領域とする。なお、C領域及びD領域は、時間的な領域であり、時間帯または期間である。図84の(b)におけるMPUタイムスタンプは、図83で説明したタイムスタンプと同様であり、MPUタイムスタンプを付与するタイミングにおけるNTP時刻に基づいて生成(設定)したタイムスタンプである。
うるう秒削除の場合に、送信側でのタイムスタンプの補正方法について具体的に説明する。
送信側(送信装置)では、以下の処理を行う。
1.MPUタイムスタンプを付与するタイミング(図84の(b)の矢印の元が示すタイミング)がC領域に含まれ、かつ、MPUタイムスタンプ(補正前のMPUタイムスタンプの値)が8:59:59以降を示す場合は、MPUタイムスタンプを1秒加える+1秒補正して、補正後のMPUタイムスタンプをMPUタイムスタンプ記述子に格納する。つまり、C領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプであり、かつ、当該MPUタイムスタンプが8:59:59以降を示す場合は、当該MPUタイムスタンプを+1秒補正する。なお、ここでの「8:59:59」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻(つまり、UTC時刻に9時間を加算することにより算出される時刻)から-1秒減算することで得られた時刻である。また、別途補正したことを示す情報である補正情報を受信装置に送信する。なお、この場合、補正情報は、必ずしも送信しなくてもよい。
2.MPUタイムスタンプを付与するタイミング(図84の(b)の矢印の元が示すタイミング)がD領域の場合、MPUタイムスタンプを補正しない。つまり、D領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプである場合は、当該MPUタイムスタンプを補正しない。
受信装置においては、MPUタイムスタンプに基づいて、MPUを提示する。なお、当該MPUタイムスタンプが補正されたか否かを示す補正情報があれば、MPUタイムスタンプと当該補正情報とに基づいてMPUを提示してもよい。
以上の処理により、NTP時刻にうるう秒調整が行われた場合であっても、受信装置において、MPUタイムスタンプ記述子に格納されているMPUタイムスタンプを用いて正常なMPUの提示が可能となる。
なお、MPUタイムスタンプの付与タイミングがA領域であるか、B領域であるか、C領域であるか、D領域であるかをシグナリングし、受信側に通知してもよい。つまり、当該MPUタイムスタンプが、A領域に含まれるNTP時刻に基づいて生成されたか、B領域に含まれるNTP時刻に基づいて生成されたか、または、C領域に含まれるNTP時刻に基づいて生成されたか、D領域に含まれるNTP時刻に基づいて生成されたかをシグナリングし、受信側に通知してもよい。言い換えると、MPUタイムスタンプ(提示時刻)がうるう秒調整前の基準時刻情報(NTP時刻)に基づいて生成されたか否かを示す識別情報を送信してもよい。この識別情報は、NTPパケットに含まれるleap_indicatorに基づいて付与されるため、日本時間でうるう秒調整が行われる前日の9:00からうるう秒調整が行われる当日におけるうるう秒調整が行われる直前の時刻(つまり、うるう秒挿入の場合は1回目の8:59:59台の時刻であり、うるう秒削除の場合は8:59:58台の時刻)までの間の時刻に基づいて設定されるMPUタイムスタンプか否かを示す情報である。つまり、識別情報は、MPUタイムスタンプが、うるう秒調整が行われる直前の時刻よりも予め定められた期間(例えば24時間)前の時刻から当該直前の時刻までにおけるNTP時刻に基づいて生成されたか否かを示す情報である。
次に、受信装置においてタイムスタンプを補正することでうるう秒調整時の課題を解決する方法について説明する。
図85は、受信装置においてタイムスタンプを補正する補正方法について説明するための図である。具体的には、図85の(a)は、うるう秒挿入の例を示し図85の(b)は、うるう秒削除の例を示す図である。
まず、うるう秒挿入の場合について説明する。
図85の(a)に示すように、図84の(a)と同様にうるう秒挿入時には、うるう秒挿入の直前までの時刻(つまり、NTP時刻における1回目の8:59:59台まで)をA領域とし、うるう秒挿入以後の時刻(つまり、NTP時刻における2回目の8:59:59以降)をB領域とする。なお、A領域及びB領域は、時間的な領域であり、時間帯または期間である。図85の(a)におけるMPUタイムスタンプは、図83で説明したタイムスタンプと同様であり、MPUタイムスタンプを付与するタイミングにおけるNTPの時刻に基づいて生成(設定)したタイムスタンプである。
うるう秒挿入の場合に、受信装置でのタイムスタンプの補正方法について具体的に説明する。
送信側(送信装置)では、以下の処理を行う。
・生成したMPUタイムスタンプを補正せずに、当該MPUタイムスタンプをMPUタイムスタンプ記述子に格納して受信装置に送信する。
・MPUのタイムスタンプを付与したタイミングが、A領域であるか、B領域であるかを示す情報を識別情報として受信装置に送信する。つまり、当該MPUタイムスタンプが、A領域に含まれているNTP時刻に基づいて生成されたか、B領域に含まれるNTP時刻に基づいて生成されたか、を示す識別情報を受信装置に送信する。
受信装置では、以下の処理を行う。
受信装置においては、MPUタイムスタンプと、MPUタイムスタンプを付与したタイミングがA領域であるか、B領域であるかを示す識別情報に基づいて、MPUタイムスタンプを補正する。
具体的には、以下の処理を行う。
1.MPUタイムスタンプを付与するタイミング(図85の(a)の矢印の元が示すタイミング)がA領域に含まれ、かつ、MPUタイムスタンプ(補正前のMPUタイムスタンプの値)が9:00:00以降を示す場合は、MPUタイムスタンプを1秒減ずる-1秒補正する。つまり、A領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプであり、かつ、当該MPUタイムスタンプが9:00:00以降を示す場合は、当該MPUタイムスタンプを-1秒補正する。なお、ここでの「9:00:00」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻(つまり、UTC時刻に9時間を加算することにより算出される時刻)である。
2.MPUタイムスタンプを付与するタイミング(図85の(a)の矢印の元が示すタイミング)がB領域の場合、MPUタイムスタンプを補正しない。つまり、B領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプである場合は、当該MPUタイムスタンプを補正しない。
MPUタイムスタンプを補正しない場合、MPUタイムスタンプ記述子に格納されているMPUタイムスタンプが受信装置のNTP時刻(補正前及び補正後含む)に一致した時刻にMPUを提示する。
つまり、補正するMPUタイムスタンプより前に受信されるMPUタイムスタンプの場合、うるう秒挿入前(つまり、1回目の8:59:59台以前)のNTP時刻に一致した時刻にMPUを提示する。また、補正するMPUタイムスタンプより後に受信されるMPUタイムスタンプの場合、うるう秒挿入後(2回目の8:59:59台以降)のNTP時刻に一致した時刻にMPUを提示する。
MPUタイムスタンプを補正する場合、補正したMPUタイムスタンプが、受信装置においてうるう秒挿入後(つまり、2回目の8:59:59台以降)のNTP時刻に基づいてMPUを提示する。
なお、送信側は、MPUタイムスタンプを付与したタイミングがA領域であるか、B領域であるかを示す識別情報は、制御メッセージや記述子、テーブル、MPUメタデータ、MFメタデータ、MMTPパケットヘッダなどに格納して伝送する。
次に、うるう秒削除の場合について説明する。
図85の(b)に示すように、うるう秒削除時には、図84の(a)と同様に、うるう秒削除の直前までの時刻(つまり、NTP時刻における9:00:00直前まで)をC領域とし、うるう秒削除以後の時刻(つまり、NTP時刻における9:00:00:以降)をD領域とする。なお、C領域及びD領域は、時間的な領域であり、時間帯または期間である。図85の(b)におけるMPUタイムスタンプは、図83で説明したタイムスタンプと同様であり、MPUタイムスタンプを付与するタイミングにおけるNTP時刻に基づいて生成(設定)したタイムスタンプである。
うるう秒削除の場合に、受信装置でのタイムスタンプの補正方法について具体的に説明する。
送信側(送信装置)では、以下の処理を行う。
・生成したMPUタイムスタンプを補正せずに、当該MPUタイムスタンプをMPUタイムスタンプ記述子に格納して受信装置に送信する。
・MPUのタイムスタンプを付与したタイミングが、C領域であるか、D領域であるかを示す情報を識別情報として受信装置に送信する。つまり、当該MPUタイムスタンプが、C領域に含まれているNTP時刻に基づいて生成されたか、B領域に含まれるNTP時刻に基づいて生成されたか、を示す識別情報を受信装置に送信する。
受信装置では、以下の処理を行う。
受信装置においては、MPUタイムスタンプと、MPUタイムスタンプを付与したタイミングがC領域であるか、D領域であるかを示す識別情報に基づいて、MPUタイムスタンプを補正する。
具体的には、以下の処理を行う。
1.MPUタイムスタンプを付与するタイミング(図85の(b)の矢印の元が示すタイミング)がC領域に含まれ、かつ、MPUタイムスタンプ(補正前のMPUタイムスタンプの値)が8:59:59以降を示す場合は、MPUタイムスタンプ値を1秒加える+1秒補正する。つまり、C領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプであり、かつ、当該MPUタイムスタンプが8:59:59以降を示す場合は、当該MPUタイムスタンプを+1秒補正する。なお、ここでの「8:59:59」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻(つまり、UTC時刻に9時間を加算することにより算出される時刻)から-1秒減算することで得られた時刻である。
2.MPUタイムスタンプを付与するタイミング(図85の(b)の矢印の元が示すタイミング)がD領域の場合、MPUタイムスタンプを補正しない。つまり、D領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプである場合は、当該MPUタイムスタンプを補正しない。
受信装置においては、MPUタイムスタンプ、及び、補正したMPUタイムスタンプに基づいて、MPUを提示する。
以上の処理により、NTP時刻にうるう秒調整が行われた場合であっても、受信装置において、MPUタイムスタンプ記述子に格納されているMPUタイムスタンプを用いて正常なMPUの提示が可能となる。
なお、この場合であっても、図84で説明した送信側においてMPUタイムスタンプを補正する場合と同様に、MPUタイムスタンプの付与タイミングがA領域であるか、B領域であるか、C領域であるか、D領域であるかをシグナリングし、受信側に通知してもよい。通知の詳細については、同様であるので説明を省略する。
なお、図84及び図85で説明した、MPUタイムスタンプを補正したか否かを示す情報や、MPUタイムスタンプを付与したタイミングがA領域であるか、B領域であるか、C領域であるか、D領域であるかを示す情報などの付加情報(識別情報)は、NTPパケットのleap_indicatorがうるう秒の削除(leap_indicator=2)や挿入(leap_indicator=1)を示す場合に有効にしてもよい。予め定められた任意の時刻(例えば、うるう秒調整の3秒前)から有効となるとしてもよいし、動的に有効にしてもよい。
また、付加情報の有効期間が終わるタイミングや付加情報のシグナリングを終了するタイミングも、NTPパケットのleap_indicatorに合わせてもよいし、予め定められた任意の時刻(例えば、うるう秒調整の3秒前)から有効となるとしてもよいし、動的に有効にしてもよい。
なお、MMTPパケットに格納される32bitのタイムスタンプや、TMCCに格納されるタイムスタンプ情報なども、NTP時刻に基づいて生成され付与されるため、同様の課題が発生する。このため、32bitのタイムスタンプや、TMCCに格納されるタイムスタンプ情報などの場合も図84及び図85と同様の方法を用いてタイムスタンプを補正し、受信装置においてタイムスタンプに基づいた処理を実施することができる。例えば、MMTPパケットに格納される32bitのタイムスタンプに対する上記付加情報を格納する場合は、MMTPパケットヘッダの拡張領域を用いて示してもよい。この場合、マルチヘッダータイプの拡張タイプに付加情報であることを示す。また、leap_indicatorが立っている時間は、32bitや64bitのタイムスタンプのうち、一部のビットを用いて付加情報を示してもよい。
なお、図84の例では、補正したMPUタイムスタンプをMPUタイムスタンプ記述子に格納するとしたが、補正前及び補正後のMPUタイムスタンプ(つまり、補正していないMPUタイムスタンプ及び補正したMPUタイムスタンプ)を両方受信装置に送信してもよい。例えば、補正前のMPUタイムスタンプ記述子と、補正後のMPUタイムスタンプ記述子とを同一のMPUタイムスタンプ記述子に格納してもよいし、2つのMPUタイムスタンプ記述子にそれぞれ格納してもよい。この場合、2つのMPUタイムスタンプ記述子の配置順や、MPUタイムスタンプ記述子内の記載順などにより、補正前のMPUタイムスタンプであるか、補正後のMPUタイムスタンプであるかを識別してもよい。また、MPUタイムスタンプ記述子には常に補正前のMPUタイムスタンプを格納するとし、補正をする場合には、補正後のタイムスタンプをMPU拡張タイムスタンプ記述子に格納するとしてもよい。
なお、本実施の形態では、NTP時刻として日本時間での時刻(午前9時)を例に説明したが、日本時間での時刻に限らない。うるう秒調整は、UTC時刻に基づくものであり、世界同時に補正される。日本時刻は、UTC時刻を基準として9時間進んだ時刻であり、UTC時刻に対する時刻(+9)という値で表される。このように、場所に応じた時差により異なる時間に調整された時刻を採用してもよい。
以上のように、タイムスタンプを付与したタイミングを示す情報に基づいて、送信側、或いは受信装置においてタイムスタンプを補正することにより、タイムスタンプを用いた正常な受信処理が可能となる。
なお、うるう秒調整時刻より十分前から復号処理を継続する受信装置は、タイムスタンプを用いない復号処理及び提示処理が可能となる場合もあるが、うるう秒調整時刻直前で選局した受信装置は、タイムスタンプを決定できず、うるう秒調整が終了した後でなければ、提示できない場合がある。その場合であっても、本実施の形態における補正方法を用いることによりタイムスタンプを用いた受信処理が可能となり、うるう秒調整時刻の直前でも選局が可能となる。
図84で説明した、送信側(送信装置)においてMPUタイムスタンプを補正する場合の、送信側(送信装置)の動作フローを図86に、受信装置の動作フローを図87に示す。
まず、送信側(送信装置)の動作フローについて、図86を用いて説明する。
うるう秒の挿入や削除が行われる場合、MPUタイムスタンプの付与のタイミングがA領域であるか、B領域であるか、C領域であるか、D領域であるかを判定する(S2201)。なお、うるう秒の挿入や削除が行われない場合については、図示しない。
ここで、A領域~D領域は、以下のように定義される。
A領域:うるう秒挿入の直前までの時刻(1回目の8:59:59台まで)
B領域:うるう秒挿入以後の時刻(2回目の8:59:59以降)
C領域:うるう秒削除の直前までの時刻(9:00:00まで)
D領域:うるう秒削除以後の時刻(9:00:00以降)
B領域:うるう秒挿入以後の時刻(2回目の8:59:59以降)
C領域:うるう秒削除の直前までの時刻(9:00:00まで)
D領域:うるう秒削除以後の時刻(9:00:00以降)
ステップS2201において、A領域であると判定された場合であって、MPUタイムスタンプが9:00:00以降を示す場合は、MPUタイムスタンプを-1秒補正し、補正したMPUタイムスタンプをMPUタイムスタンプ記述子に格納する(S2202)。
そして、MPUタイムスタンプを補正したことを示す補正情報をシグナリングし、受信装置に送信する(S2203)。
また、ステップS2201において、C領域であると判定された場合であって、MPUタイムスタンプが8:59:59以降を示す場合は、MPUタイムスタンプを+1秒補正し、補正したMPUタイムスタンプをMPUタイムスタンプ記述子に格納する(S2205)。
また、ステップS2201において、B領域またはD領域であると判定された場合、MPUタイムスタンプを補正せずにMPUタイムスタンプ記述子に格納する(S2204)。
次に、受信装置の動作フローについて、図87を用いて説明する。
送信側からシグナリングされた情報に基づいて、MPUタイムスタンプが補正されているか否かを判定する(S2301)。
MPUタイムスタンプが補正されていると判定された場合(S2301でYes)は、受信装置においてうるう秒調整が実施された後のNTP時刻における当該MPUタイムスタンプに基づいてMPUを提示する(S2302)。
MPUタイムスタンプが補正されていないと判定された場合(S2301でNo)は、NTP時刻における当該MPUタイムスタンプに基づいてMPUを提示する。
なお、MPUタイムスタンプを補正する場合は、当該MPUタイムスタンプに対応するMPUをうるう秒が挿入される区間に提示する。
反対に、MPUタイムスタンプを補正しない場合は、当該MPUタイムスタンプに対応するMPUを、うるう秒が挿入される区間に提示することはなく、うるう秒が挿入されない区間に提示する。
図85で説明した、受信装置においてMPUタイムスタンプを補正する場合の、送信側の動作フローを図88に、受信装置の動作フローを図89に示す。
まず、送信側(送信装置)の動作フローについて、図88を用いて説明する。
NTPパケットのleap_indicatorに基づいて、うるう秒の調整(挿入や削除)が行われかを判定する(S2401)。
うるう秒の調整が行われると判定された場合(S2401でYes)、MPUタイムスタンプの付与のタイミングを判定し、識別情報をシグナリングし、受信装置に送信する(S2402)。
一方、うるう秒の調整が行われないと判定された場合(S2041でNo)、通常動作のまま処理を終了する。
次に、受信装置の動作フローについて、図89を用いて説明する。
送信側(送信装置)によりシグナリングされた識別情報に基づいて、MPUタイムスタンプの付与のタイミングがA領域であるか、B領域であるか、C領域であるか、D領域であるかを判定する(S2501)。ここで、A領域~D領域は、上記で定義したものと同じであるため説明を省略する。なお、図87と同様に、うるう秒の挿入や削除が行われない場合については、図示しない。
ステップS2501において、A領域であると判定された場合であって、MPUタイムスタンプが9:00:00以降を示す場合は、MPUタイムスタンプを-1秒補正する(S2502)。
ステップS2501において、C領域であると判定された場合であって、MPUタイムスタンプが8:59:59以降を示す場合は、MPUタイムスタンプを+1秒補正する(S2504)。
ステップS2501において、B領域またはD領域であると判定された場合、MPUタイムスタンプを補正しない(S2503)。
受信装置は、さらに、図示しない処理において、補正されたMPUタイムスタンプに基づいてMPUを提示する。
なお、MPUタイムスタンプを補正する場合は、うるう秒調整が実施された後のNTP時刻におけるMPUタイムスタンプに基づいて、当該MPUタイムスタンプに対応するMPUを提示する。
反対に、MPUタイムスタンプを補正しない場合は、当該MPUタイムスタンプに対応するMPUを、うるう秒が挿入される区間に提示することはなく、うるう秒が挿入されない区間に提示する。
要するに、送信側(送信装置)は、複数のMPUのそれぞれについて、当該MPUに対応するMPUタイムスタンプを付与するタイミングを判定する。そして、判定の結果、当該タイミングがうるう秒挿入の直前までの時刻の場合であって、当該MPUタイムスタンプが9:00:00以降を示す場合は、当該MPUタイムスタンプを-1秒補正する。また、MPUタイムスタンプを補正したことを示す補正情報をシグナリングし、受信装置に送信する。また、判定の結果、当該タイミングがうるう秒削除の直前までの時刻の場合であって、当該MPUタイムスタンプが8:59:59以降を示す場合は、当該MPUタイムスタンプを+1秒補正する。
また、受信装置は、送信側(送信装置)によりシグナリングされた補正情報により示されるMPUタイムスタンプが補正されているか否かに基づいて、MPUタイムスタンプが補正されていることが示される場合には、うるう秒調整が実施された後のNTP時刻における当該MPUタイムスタンプに基づいてMPUを提示する。MPUタイムスタンプが補正されていない場合は、うるう秒調整前のNTP時刻における当該MPUタイムスタンプに基づいてMPUを提示する。
また、送信側(送信装置)は、複数のMPUのそれぞれについて、当該MPUに対応するMPUタイムスタンプを付与するタイミングを判定し、判定した結果をシグナリングする。受信装置はl、送信側によりシグナリングされた、MPUタイムスタンプを付与するタイミングを示す情報に基づき、以下の処理を行う。具体的には、当該タイミングを示す情報がうるう秒挿入の直前までの時刻であることを示す場合であって、MPUタイムスタンプが9:00:00以降を示す場合は、当該MPUタイムスタンプを-1秒補正する。また、当該タイミングを示す情報がうるう秒削除の直前までの時刻の場合であって、当該MPUタイムスタンプが8:59:59以降を示す場合は、当該MPUタイムスタンプを+1秒補正する。
受信装置は、MPUタイムスタンプが補正されている場合には、うるう秒調整が実施された後のNTP時刻における当該MPUタイムスタンプに基づいてMPUを提示する。MPUタイムスタンプが補正されていない場合は、うるう秒調整前のNTP時刻における当該MPUタイムスタンプに基づいてMPUを提示する。
このように、うるう秒調整における、MPUタイムスタンプの付与のタイミングを判定することにより、MPUタイムスタンプの補正が可能となり、受信装置は、どのMPUを提示すべきかの判断ができ、MPUタイムスタンプ記述子やMPU拡張タイムスタンプ記述子を用いた適切な受信処理が可能となる。つまり、NTP時刻にうるう秒調整が行われた場合であっても、受信装置において、MPUタイムスタンプ記述子に格納されているMPUタイムスタンプを用いて正常なMPUの提示が可能となる。
[補足:送信装置及び受信装置]
以上のように、符号化ストリームを構成するデータをMPUに格納して送信する送信装置は、図90のように構成することも可能である。また、符号化ストリームを構成するデータが格納されたMPUを受信する受信装置は、図91のように構成することも可能である。図90は、送信装置の具体的構成の例を示す図である。図91は、受信装置の具体的構成の例を示す図である。
以上のように、符号化ストリームを構成するデータをMPUに格納して送信する送信装置は、図90のように構成することも可能である。また、符号化ストリームを構成するデータが格納されたMPUを受信する受信装置は、図91のように構成することも可能である。図90は、送信装置の具体的構成の例を示す図である。図91は、受信装置の具体的構成の例を示す図である。
送信装置900は、生成部901と、送信部902とを備える。生成部901及び送信部902のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置1000は、受信部1001と、再生部1002とを備える。受信部1001及び再生部1002のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置900及び受信装置1000の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法については、図92を用いて説明する。図92は、送信装置による動作フロー(送信方法)である。
まず、送信装置900の生成部901は、外部から受信した基準時刻情報としてのNTP時刻に基づいて、第1のデータユニットとしてのMPUの提示時刻を示す提示時刻情報(MPUタイムスタンプ)を生成する(S2601)。
次に、送信装置900の送信部902は、MPUと、生成部901により生成された提示時刻情報と、当該提示時刻情報(MPUタイムスタンプ)がうるう秒調整前のNTP時刻に基づいて生成されたか否かを示す識別情報とを送信する(S2602)。
これにより、送信装置900から送信された情報を受信した受信装置は、うるう秒調整が行われた場合であっても、識別情報に基づいてMPUを再生できるので、MPUを意図された時刻に再生できる。
次に、受信方法について図93を用いて説明する。図93は、受信装置による動作フロー(受信方法)である。
まず、受信装置1000の受信部1001は、MPUと、MPUの提示時刻を示す提示時刻情報と、当該提示時刻情報(MPUタイムスタンプ)がうるう秒調整前のNTP時刻に基づいて生成されたか否かを示す識別情報とを、受信する(S2701)。
次に、受信装置1000の再生部1002は、受信部1001により受信された提示時刻情報(MPUタイムスタンプ)及び識別情報に基づいて、受信部1001により受信されたMPUを再生する(S2702)。
これにより、受信装置1000は、うるう秒調整が行われた場合であっても、MPUを意図された時刻に再生できる。
なお、実施の形態6において、再生とは、復号及び提示の少なくとも一方の処理を含む処理を示す。
(実施の形態6の変形例)
次に、図84及び図85で説明した、付加情報(識別情報)の具体的なシグナリング方法の具体例について説明する。
次に、図84及び図85で説明した、付加情報(識別情報)の具体的なシグナリング方法の具体例について説明する。
ここでは、図81の(a)に示すMPUタイムスタンプ記述子と、図81の(b)に示すMPU拡張タイムスタンプ記述子との組み合わせでシグナリングする方法について説明する。
図94は、MPU拡張タイムスタンプ記述子の拡張例を示す図である。図94の下線で示したフィールドは、図81の(b)で示したMPU拡張タイムスタンプ記述子に対して新規に追加するフィールドである。
図94におけるNTP_leap_indicatorは、第2制御情報としてのMPU拡張タイムスタンプ記述子に、NTPのうるう秒調整に係る付加情報(識別情報)を示すか否かのフラグを示す。このフラグが立っている場合、複数のMPU毎のループ内におけるmpu_presentation_time_typeが有効となる。
図94におけるmpu_presentation_time_typeは、図84で説明したようなMPUタイムスタンプの補正を送信側(送信装置)において行う場合、MPUタイムスタンプスタンプ記述子に記載される同一シーケンス番号のmpu_presentation_timeが、補正されているかどうかを示す。また、mpu_presentation_time_typeは、図85で説明したようなMPUタイムスタンプの補正を受信装置において行う場合、MPUタイムスタンプスタンプ記述子に記載される同一シーケンス番号のmpu_presentation_timeが付与されるタイミングが、A領域であるか、B領域であるか、C領域であるか、D領域であるかを示す。
つまり、MPU拡張タイムスタンプ記述子は、MPUタイムスタンプがうるう秒調整前の時刻情報(NTP時刻)に基づいて生成されたか否かを示す識別情報が格納されている。また、MPU拡張タイムスタンプ記述子は、複数のMPUのそれぞれのループにおいて、当該MPUに対応する識別情報を格納している。
送信装置900の送信部902は、上記ステップS2602において、MPUと、生成部901により生成された提示時刻情報(MPUタイムスタンプ)が格納された第1制御情報としてのMPUタイムスタンプ記述子と、当該提示時刻情報がうるう秒調整前の時刻情報(NTP時刻)に基づいて生成されたか否かを示す識別情報が格納された第2制御情報としてのMPU拡張タイムスタンプ記述子と、を送信する。
受信装置1000の受信部1001は、ステップS2701において、MPUと、MPUタイムスタンプ記述子と、MPU拡張タイムスタンプ記述子とを受信する。そして、受信装置1000の再生部1002は、受信部1001により受信されたMPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づいて、受信部1001により受信されたMPUを再生する。このように、受信装置1000は、MPUタイムスタンプ記述子とMPU拡張タイムスタンプ記述子との両方を解析することで、うるう秒調整時、MPUタイムスタンプを用いた復号処理が可能となる。よって、受信装置1000は、うるう秒調整が行われた場合であっても、MPUを意図された時刻に再生できる。また、MPU拡張タイムスタンプ記述子に識別情報を格納しているため、MPUタイムスタンプ記述子を既存規格(MPEG)に対応した構成のまま、MPUタイムスタンプがうるう秒調整前の時刻情報(NTP時刻)に基づいて生成されたか否かをシグナリングする機能を拡張できる。このように、従来の構成を利用できるため、シグナリングする機能を拡張した場合であっても、設計変更を最小限にでき、送信側(送信装置)および受信装置の製造コストを低減することができる。
なお、NTP_leap_indicatorを立てるタイミングは、NTPパケットにおけるleap_indicatorと同じでもよいし、leap_indicatorが立っている間における任意の時間としてもよい。つまり、NTP_leap_indicatorは、MPUタイムスタンプが生成された基準となるNTP時刻に対応するNTPパケットにおけるleap_indicatorの値に応じた値に決定される。
(実施の形態6の変形例2)
本実施の形態において説明した、うるう秒調整に係る課題は、NTP時刻に基づいた時刻を用いる場合に限らずに、UTC時刻に基づいた時刻を用いる場合であっても、同様に発生する課題である。
本実施の形態において説明した、うるう秒調整に係る課題は、NTP時刻に基づいた時刻を用いる場合に限らずに、UTC時刻に基づいた時刻を用いる場合であっても、同様に発生する課題である。
時刻系が、UTCに基づいた時刻系であり、その時刻系に基づいて提示時刻情報(MPUタイムスタンプ)を生成し、付与する場合には、これまでに示した方法と同様の方法を用いることにより、うるう秒調整時にも、受信装置側で提示時刻情報及びシグナリング情報(付加情報、識別情報)を用いて、提示時刻情報を補正し、処理することが可能である。
例えば、ARIB STD-B60において、受信機で動作しているアプリケーションに対して、放送局から動作を指定する時刻(時刻指定情報)を通知する目的として、イベントメッセージを伝送する際、イベントメッセージ記述子をMMTPパケットに格納し、イベントメッセージ記述子においてイベントメッセージの発生する時刻が示されている。この場合、アプリケーションを構成するデータは、第1のデータユニットとしてのMPUに格納して送信される。イベントメッセージの発生する時刻については、複数の時刻の指定方法があり、time_modeで示される。time_modeにおいて、イベントメッセージの発生する時刻をUTCで表現する場合、そのUTC時刻が、うるう秒調整前の時刻情報に基づいて付与された時刻情報か、うるう秒調整後の時刻情報に基づいて付与された時刻情報かを示す識別情報をシグナリングする。つまり、識別情報は、本実施の形態で説明した識別情報と同様に、提示時刻情報がうるう秒調整前の時刻情報(NTP時刻)に基づいて生成されたか否かを示す情報である。このような識別情報(シグナリング情報)は、イベントメッセージ記述子内に示すことが望ましい。例えば、イベントメッセージ記述子のreserved_future_useフィールドを用いてシグナリングすることができる。
つまり、送信装置900の生成部901は、上記ステップS2601において、外部から受信した基準時刻情報としてのNTP時刻に基づいて、アプリケーションの動作時刻を示す時刻指定情報を生成する。そして、送信装置900の送信部902は、上記ステップS2602において、MPUと、生成部901により生成された、アプリケーションの動作時刻(イベントメッセージの発生する時刻)を示す時刻指定情報と、当該時刻情報がうるう秒調整前の時刻情報であるか否かを示す識別情報とが格納された制御情報としてのイベントメッセージ記述子と、を送信する。
なお、送信側(送信装置)において、うるう秒調整の必要な時間帯や番組を判定し、うるう秒調整が必要な時間帯や番組では、UTCで表現するtime_modeの使用を禁止し、UTCに係らないtime_modeを使用すると規定してもよい。
或いは、送信側(送信装置)において、イベントメッセージの発生するUTC時刻を算出し、イベントメッセージを発生させる時刻がうるう秒調整後であるかどうかを判定し、うるう秒調整後の場合には、うるう秒調整後のUTC時刻を算出してイベントメッセージ記述子に格納してもよい。また、提示時刻情報がうるう秒調整されたかどうかを別途シグナリングしてもよい。
同様に、UTC(Universal Time Coordinated)-NPT(Normal Play Time)参照記述子は、UTCとNPTとの関係を、UTC_Referenceフィールド及びNPT_Referenceフィールドを用いて示す。UTC_ReferenceフィールドまたはNPT_Referenceフィールドに示す時刻情報が、うるう秒調整前の基準時刻情報(NTP時刻)に基づいて付与された時刻情報か、うるう秒調整後の基準時刻情報に基づいて付与された時刻情報かをシグナリングする。つまり、UTC-NPT参照記述子は、送信装置900の生成部901により生成された提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報(NTP時刻)か否かを示す識別情報とを格納している制御情報である。識別情報は、UTC-NPT参照記述子内のreservedフィールド等を用いてシグナリングすることができる。
また、ARIB STD-B60或いはARIB STD-B62に記載される字幕或いは文字スーパーの提示時刻の指定方法は、付加識別情報(Additional_Arib_Subtitle_Info)におけるTMD(時刻制御モード)で示される。付加識別情報は、MPTのアセットループに格納される。
TMD(時刻制御モード)がMPUタイムスタンプやNPT(Normal Play
Time)を起点とした時刻であるモードの場合には、字幕或いは文字スーパーの提示時刻は、MPU拡張タイムスタンプ記述子或いはUTC-NPT参照記述子に示される。上記シグナリング情報により、うるう秒調整時にも、受信装置側で時刻情報及びシグナリング情報を用いて、時刻情報を補正し、処理することが可能である。
Time)を起点とした時刻であるモードの場合には、字幕或いは文字スーパーの提示時刻は、MPU拡張タイムスタンプ記述子或いはUTC-NPT参照記述子に示される。上記シグナリング情報により、うるう秒調整時にも、受信装置側で時刻情報及びシグナリング情報を用いて、時刻情報を補正し、処理することが可能である。
時刻制御モード=’0000’(UTC_TTML記述)である場合は、ARIB-TTML字幕内のタイムコードをUTCに対応した提示時刻を示す。この場合は、当該タイムコードに示されるUTC時刻が、うるう秒調整前の時刻情報に基づいて付与された時刻情報か、うるう秒調整後の時刻情報に基づいて付与された時刻情報かをシグナリングする。このとき送信されるシグナリング情報は、ARIB-TTML字幕内に示すことが望ましい。
時刻制御モード=’0010’(UTC_TTML記述)である場合は、付加識別情報におけるreference_start_timeフィールドに示されるUTC時刻を起点とした時刻である。この場合は、付加識別情報内において、時刻制御モード=’0000’(UTC_TTML記述)である場合と同様にシグナリングする。この場合、送信側(送信装置)では、reference_start_timeフィールドに示されるUTC時刻が、うるう秒調整が行われる直前の時刻(例えば、9:00:00までの時刻)よりも予め定められた期間(例えば24時間)前の時刻(つまり、うるう秒調整が行われる前日の9:00:00)から当該直前の時刻までにおける時刻であるか否かを示す情報を識別情報として送信する。
なお、送信側(送信装置)において、うるう秒調整の必要な時間帯や番組を判定し、UTCで表現する時刻制御モードの使用を禁止し、UTCに係らない時刻制御モードを使用すると規定してもよい。
その他、MH-Expire記述子についても同様である。
(実施の形態7)
一般的な放送局設備は、複数の送出系統を有しており、1系統を通常設備として実際の放送サービスに、それ以外を冗長系設備としてバックアップ用に運用している。これにより、送出設備等の原因により、視聴者に提供するサービスにエラーが起こった場合などに、冗長系設備に切り替えることができる。ここで、MMT/TLV方式では、冗長系設備の切り替え時に、下記の現象が生じる。
一般的な放送局設備は、複数の送出系統を有しており、1系統を通常設備として実際の放送サービスに、それ以外を冗長系設備としてバックアップ用に運用している。これにより、送出設備等の原因により、視聴者に提供するサービスにエラーが起こった場合などに、冗長系設備に切り替えることができる。ここで、MMT/TLV方式では、冗長系設備の切り替え時に、下記の現象が生じる。
1.MPUシーケンス番号の調整
冗長系設備を切り替える前処理として、MPUシーケンス番号の調整が実施される。図95に示すように、MPUシーケンス番号の調整が実施された場合、調整前と調整後とで、MPUシーケンス番号に不連続が生じる場合がある。図95では、MPUシーケンス番号が重複する例を示す。
冗長系設備を切り替える前処理として、MPUシーケンス番号の調整が実施される。図95に示すように、MPUシーケンス番号の調整が実施された場合、調整前と調整後とで、MPUシーケンス番号に不連続が生じる場合がある。図95では、MPUシーケンス番号が重複する例を示す。
アクセスユニットや、アクセスユニットに対するMPUタイムスタンプは、MPUシーケンス番号の調整前及び調整後で、同じであるが、異なるMPUに対して同一のMPUシーケンス番号が付与されていることにより、2つのMPUに渡って、同一のMPUシーケンス番号が付与される。
これにより、MMTPパケットヘッダに格納されるMPUシーケンス番号と、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に格納されるMPUシーケンス番号とが、異なるMPUで重複する。また、同様に、MPUシーケンス番号がスキップしたり、戻ったりする場合もある。
2.パケットシーケンス番号の不連続
通常設備と冗長系設備との間で、パケットシーケンス番号やパケットカウンタが異なっているために、通常設備から冗長系設備に切り替える際、パケットシーケンス番号やパケットカウンタが不連続になる場合がある。図96に示すように、通常動作ではパケットシーケンス番号は連続しているのに対して、スキップ、重複、戻る場合がある。なお、図96は、通常設備から冗長系設備に切り替えるタイミングで、パケットシーケンス番号が不連続になる場合について説明するための図である。
通常設備と冗長系設備との間で、パケットシーケンス番号やパケットカウンタが異なっているために、通常設備から冗長系設備に切り替える際、パケットシーケンス番号やパケットカウンタが不連続になる場合がある。図96に示すように、通常動作ではパケットシーケンス番号は連続しているのに対して、スキップ、重複、戻る場合がある。なお、図96は、通常設備から冗長系設備に切り替えるタイミングで、パケットシーケンス番号が不連続になる場合について説明するための図である。
上記、1または2のようにMPUシーケンス番号やパケットシーケンス番号が不連続になる場合、これらのシーケンス番号の連続性を信じて動作する受信装置は誤動作するおそれがあるという課題がある。
なお、アクセスユニット、及び、アクセスユニットに対するMPUタイムスタンプは、MPUシーケンス番号やパケットシーケンス番号の不連続が生じる場合においても、連続性は保たれており、連続なデータが受信装置に送出される。
図95及び図96を用いて説明したようなMPUシーケンス番号やパケットシーケンス番号の不連続が起こった場合の受信処理について説明する。
MPUシーケンス番号やパケットシーケンス番号の不連続が生じる場合、下記に示すようなMPUシーケンス番号やパケットシーケンス番号を用いる処理を行う受信装置は誤動作する可能性がある。
MPUシーケンス番号を用いる処理としては、例えば、MMTPパケットヘッダにおけるMPUシーケンス番号の切り替わりによってMPU境界を検出する処理がある。
また、MPUシーケンス番号を用いる処理としては、例えば、MPUタイムスタンプ記述子やMPU拡張タイムスタンプ記述子には、MPUシーケンス番号に対するタイムスタンプが記載されており、当該タイムスタンプを用いて復号及び/又は提示する。
パケットシーケンス番号を用いる処理としては、例えば、パケットシーケンス番号をパケットロスの検出に用い、パケットシーケンス番号がスキップした場合にパケットロスと判定し、パケットシーケンス番号が戻った場合にパケットの入れ替わりと判定する処理がある。
これらのMPUシーケンス番号やパケットシーケンス番号を用いる処理を行うことによる誤動作を防ぐために、受信装置は、MPUシーケンス番号やパケットシーケンス番号の不連続を判定し、不連続と判定した場合には、MPUシーケンス番号やパケットシーケンス番号を用いない処理を実施する。
ここで、MPUシーケンス番号やパケットシーケンス番号の不連続の判定方法として、例えば、下記の方法を用いることができる。
まず、上記判定方法の1つは、冗長系設備に切り替えることを示す付加情報をシグナリングすることが考えられる。これにより、受信装置は、付加情報に基づいてMPUシーケンス番号やパケットシーケンス番号を用いない受信処理を行うことができる。
付加情報をシグナリングする方法としては、制御メッセージや記述子、テーブル、MPUメタデータ、MFメタデータ、MMTPパケットヘッダ、MMTPパケットの拡張ヘッダなどに当該付加情報を格納して伝送する方法がある。
次に、受信装置において、他の情報を用いて不連続を検出する方法について説明する。
例えば、MPU境界を示す情報として、MMTPペイロードヘッダにおけるMPUシーケンス番号の切り替わりを検出する方法と、MMTPパケットヘッダにおいてランダムアクセスポイントであるか否かを示すフラグであるRAP_flagを用いる方法とがある。他にも、Sample_numberが0となるパケットの切り替わりや、フラグメントタイプの切り替わりなどでもMPU境界を検出することが可能である。また、アクセスユニットの数を数えてMPU境界を検出することもできる。
ここで、冗長系設備の切り替えが実施される可能性がある場合には、MPUシーケンス番号の切り替わりを用いたMPU境界を判定せず、その他の方法を用いてMPU境界を判定する。例えば、RAP_flagが1であるパケットは、MPUにおける先頭のパケットと判定する。ここで、MPU境界の後のパケットのMPUシーケンス番号が前のパケットのMPUシーケンス番号と変わらない場合、MMTPパケットにおいてMPUシーケンス番号の重複が生じたと判定する。
或いは、RAP_flagが1であるパケットは、MPUにおける先頭のパケットと判定する。ここで、先頭のパケットと判定されたパケットのMPUシーケンス番号がその前のパケットのMPUシーケンス番号からスキップ或いは戻った場合、MMTPパケットにおいてMPUシーケンス番号の不連続が生じたと判定する。
なお、MMTPペイロードヘッダにおけるMPUシーケンス番号の不連続が、MPUタイムスタンプ記述子やMPU拡張タイムスタンプ記述子におけるMPUシーケンス番号やパケットシーケンス番号の不連続より必ず前に生じる場合は、当該判定結果に基づいて、タイムスタンプを用いない受信処理やパケットシーケンス番号を用いない処理を実施してもよい。
また、映像パケットのMMTPペイロードヘッダにおけるMPUシーケンス番号の不連続が、音声パケットのMMTPペイロードヘッダにおけるMPUシーケンス番号の不連続や、音声のMPUタイムスタンプ記述子やMPU拡張タイムスタンプ記述子におけるMPUシーケンス番号やパケットシーケンス番号の不連続より、必ず前に生じる場合には、映像パケットのMPUシーケンス番号の不連続の検出結果に基づいて、音声のタイムスタンプを用いない受信処理やパケットシーケンス番号を用いない処理を実施してもよい。当該判定結果を、冗長系設備への切り替えが開始するタイミングと判定してもよい。
なお、受信装置は、冗長系設備に切り替えることを示す付加情報をシグナリングする方法を用いて、冗長系設備に切り替えることを示す付加情報が示される場合のみ、MPUシーケンス番号やパケットシーケンス番号を用いない処理をしてもよい。
なお、受信装置は、冗長系設備に切り替えることを示す付加情報をシグナリングする方法を用いて冗長系設備に切り替えることを示す付加情報が示される場合のみ、RAP_flagなどとMPUシーケンス番号の不連続の検出処理を実施してもよい。
ここで、受信装置におけるタイムスタンプ記述子を用いた判定について説明する。通常、MPUシーケンス番号に対するタイムスタンプが記載され、複数回伝送されることが多いが、MPUシーケンス番号が同じであるにも関わらず、タイムスタンプ値が更新された場合、受信装置は、MPUシーケンス番号が重複したと判定する。
また、タイムスタンプ値が1つのMPUのプレゼンテーション時間分更新されたにもかかわらず、MPUシーケンス番号が2以上更新されるなど、タイムスタンプ値とMPUシーケンス番号との関係が対応していない場合、受信装置は、MPUシーケンス番号の不連続が生じたと判定する。
なお、MPUタイムスタンプやMPU拡張タイムスタンプの更新時には、MPテーブルにおけるversionを更新しないとしてもよい。また、別途version情報を定義し、タイムスタンプ情報のversionと、タイムスタンプ情報以外の情報のversionとを分けて送信してもよい。これにより、タイムスタンプ情報以外の情報のversion頻度を低減でき、受信処理を軽減できる。
なお、MPUシーケンス番号の不連続が生じる場合には、MPUタイムスタンプとタイムスタンプ情報との関係が信用できない。そのため、タイムスタンプ情報が信用できない情報であることを記述子にシグナリングしてもよい。例えば、図94で説明したNTP_leap_indicatorやmpu_presentation_time_typeと同様のフィールドを用いて、MPUタイムスタンプを付与するタイミングが冗長系切り替え前後のタイミングであり、タイムスタンプが信用できないことを示してもよい。また、MPUタイムスタンプ記述子と併用して使用することを前提として、MPU拡張タイムスタンプ記述子に示してもよい。
以上の方法を用いて、受信装置において、MPUシーケンス番号や、パケットシーケンス番号の不連続が生じると判定することにより、MPUシーケンス番号やパケットシーケンス番号を用いない処理が可能となり、同期再生における誤動作を防ぐことが可能となる。以上のように説明したようなMPUシーケンス番号やパケットシーケンス番号の不連続が起こった場合の受信装置の動作フローについて説明する。図97は、MPUシーケンス番号やパケットシーケンス番号の不連続が起こった場合の受信装置による動作フローである。
受信装置では、MMTPパケットにおけるパケットヘッダ或いはペイロードヘッダなどから、MPU境界を判定する。具体的には、RAP_flagが1となるパケットをMPU先頭のパケットであると判定することで、MPU境界を判定する。さらに、MPUシーケンス番号を判定し、前のパケットのMPUシーケンス番号から1増加しているか否かを判定する(S2801)。
RAP_flagが1であり、かつ、MPUシーケンス番号が1増加したと判定した場合(S2801でYes)は、MPUシーケンス番号の不連続は発生していないものとし、MPUシーケンス番号を用いる受信処理を実施する(S2803)。
一方、RAP_flagが0であるか、RAP_flagが1であっても前のパケットのMPUシーケンス番号から1増加していないと判定した場合(S2801でNo)は、MPUシーケンス番号の不連続が発生しているものとし、MPUシーケンス番号を用いない受信処理を実施する(S2802)。
(実施の形態8)
実施の形態6では、主に、MPUタイムスタンプの補正に関して説明してきたが、MPU内に含まれるAU毎のPTSまたはDTSを受信装置において補正する方法について説明する。つまり、MPU内に含まれる複数のAUのうちの先頭AUを除く複数の他のAUそれぞれのPTSまたはDTSを示すタイムスタンプを受信装置において補正する補正方法について説明する。
実施の形態6では、主に、MPUタイムスタンプの補正に関して説明してきたが、MPU内に含まれるAU毎のPTSまたはDTSを受信装置において補正する方法について説明する。つまり、MPU内に含まれる複数のAUのうちの先頭AUを除く複数の他のAUそれぞれのPTSまたはDTSを示すタイムスタンプを受信装置において補正する補正方法について説明する。
図98は、うるう秒挿入時に受信装置においてタイムスタンプを補正する補正方法について説明するための図である。図98は、図85の(a)と同じケースである。
ここで、送信側のNTP時刻は、NTPサーバと同期しており、また、受信側のNTP時刻は、送信側から伝送されるNTPパケットに格納されるタイムスタンプに基づいて再生されることで、送信側のNTP時刻と同期している場合を例に説明する。この場合、送信側のNTP時刻及び受信側のNTP時刻共に、うるう秒の挿入時は+1秒の調整がなされる。
図98におけるNTP時刻は、送信側のNTP時刻及び受信側のNTP時刻で共通であるとする。なお、以下では、伝送遅延はないものとして説明する。また、以下ではMPU内のAUのPTSの補正方法のみ説明するが、MPU内のAUのDTSについても同様の方法を用いることにより補正することができる。なお、図98では、一つのMPUに含まれるAU数は5であるとして説明するが、MPUに含まれるAU数はこれに限るものではない。
図85の(a)で説明した送信方法と同様に、うるう秒挿入の直前までのNTP時刻(1回目の8:59:59台まで)をA領域、うるう秒挿入以後のNTP時刻(2回目の8:59:59以降)をB領域とする。
送信側(送信装置)では、以下の処理を行う。
・実施の形態6において図83を用いて説明したように、MPUの提示時刻情報(第1時刻情報)であるMPUタイムスタンプを生成する。
・生成したMPUタイムスタンプを補正せずに、当該MPUタイムスタンプをMPUタイムスタンプ記述子に格納して受信装置に送信する。つまり、第1時刻情報は、うるう秒調整時にMPUの送信側において補正されない時刻情報である。また、MPUタイムスタンプを付与したタイミングが、A領域であるか、B領域であるかを示す識別情報を受信装置に送信する。具体的には、複数のMPUが格納されたMMTPパケットを送信する。このMMTPパケットは、制御情報として、第1時刻情報としてのMPUタイムスタンプを含むMPUタイムスタンプ記述子と、第2時刻情報としての相対情報を含むMPU拡張タイムスタンプ記述子と、識別情報とを含む。
なお、図98では、MPUのタイムスタンプを付与したタイミングは矢印の元で示される。
受信装置では、以下の処理を行う。
実施の形態6で説明したように、MPU拡張タイムスタンプ記述子には、AU毎のPTSまたはDTSを算出するための第2時刻情報が、MPUタイムスタンプ記述子に格納されるMPUの先頭AUのPTSからの相対情報として格納されている。このとき、MPU拡張タイムスタンプ記述子に格納される相対情報は、うるう秒の挿入を考慮した値ではない。
受信装置は、まず、送信側(送信装置)により送信された、MPUと、第1時刻情報と、第2時刻情報と、識別情報とを含むMMTPパケットを受信し、図98の「AU毎のPTS」に示すように、MPUタイムスタンプ記述子に格納されている第1時刻情報及びMPU拡張タイムスタンプ記述子に格納されている第2時刻情報の両方に基づいてMPU内に含まれるすべてのAU毎のPTS(DTS)を算出する。
次に、受信装置は、AU毎のPTSを補正する。補正対象となるAUは、AUが属するMPUのMPUタイムスタンプの付与のタイミング(図98の矢印の元が示すタイミング)がA領域であり、かつ、補正前のAU毎のPTSが9:00:00以降を示すAUである。補正対象となるAUは、図98では、下線で示されるAUであり、MPU#1におけるAU#5、及び、MPU#2におけるAU#1-AU#5である。受信装置は、PTSの補正対象のAUに該当すると判断した場合には、当該AUのPTSを-1秒補正する。
つまり、補正では、複数のAUそれぞれについて、当該AUを格納しているMPUのMPUタイムスタンプがうるう秒調整前の基準時刻情報に基づいて生成されており、かつ、算出された当該AUのPTSまたはDTSが所定の時刻(うるう秒挿入の場合には9:00:00)以降である補正条件を満たすか否かを判定する。そして、補正では、判定において、上記の補正条件を満たすと判定されたAUのPTSまたはDTSを補正する。
AUが属するMPUのMPUタイムスタンプの付与のタイミングがA領域であり、かつ、PTSが補正されていないAU(図98ではMPU#1におけるAU#4までのAU)は、うるう秒挿入前(1回目の8:59:59:台以前)のNTP時刻に一致した時刻にAUを提示する。また、PTSが補正されたAU或いはそれ以降のAU(図98ではMPU#1におけるAU#5以降のAU)は、うるう秒挿入後(2回目の8:59:59台以降)のNTP時刻に一致した時刻にAUを提示する。
なお、MPUタイムスタンプの付与のタイミングを示す識別情報は、少なくとも、補正対象のAUを含むMPUに対して提示する必要がある。つまり、補正対象のAUを含まないMPUに対して識別情報を提示する必要は必ずしもない。
図99は、うるう秒削除時に受信装置においてタイムスタンプを補正する補正方法について説明するための図である。図99は、図85の(b)と同じケースである。
送信側のNTP時刻は、NTPサーバと同期しており、また、受信側のNTP時刻は、送信側から伝送されるNTPパケットに格納されるタイムスタンプに基づいて再生されることで、送信側のNTP時刻と同期している場合を例に説明する。この場合、送信側のNTP時刻及び受信側のNTP時刻共に、うるう秒の削除時は-1秒の調整がなされる。
図99におけるNTP時刻は、送信側のNTP時刻及び受信側のNTP時刻で共通であるとする。なお、以下では、伝送遅延はないものとして説明する。また、以下ではMPU内のAUのPTSの補正方法のみ説明するが、MPU内のすべてのAUのDTSについても同様の方法を用いることにより補正することができる。なお、図99では、一つのMPUに含まれるAU数は5であるとして説明するが、MPUに含まれるAU数はこれに限るものではない。
図85で説明した送信方法と同様に、うるう秒削除の直前までのNTP時刻(8:59:58台まで)をC領域、うるう秒削除以後のNTP時刻(9:00:00以降)をD領域とする。
送信側(送信装置)では、以下の処理を行う。
・実施の形態6において図83を用いて説明したように、MPUの提示時刻情報(第1時刻情報)であるMPUタイムスタンプを生成する。
・生成したMPUタイムスタンプを補正せずに、当該MPUタイムスタンプをMPUタイムスタンプ記述子に格納して受信装置に送信する。つまり、第1時刻情報は、うるう秒調整時にMPUの送信側において補正されない時刻情報である。また、MPUタイムスタンプを付与したタイミングが、C領域であるか、D領域であるかを示す識別情報を受信装置に送信する。具体的には、複数のMPUが格納されたMMTPパケットを送信する。MMTPパケットは、図98で説明したMMTPパケットと同様の構成である。
なお、図99では、MPUのタイムスタンプを付与したタイミングは矢印の元で示される。
受信装置では、以下の処理を行う。
実施の形態6で説明したように、MPU拡張タイムスタンプ記述子には、AU毎のPTSまたはDTSを算出するための第2時刻情報が、MPUタイムスタンプ記述子に格納されるMPUの先頭AUのPTSからの相対情報として格納されている。このとき、MPU拡張タイムスタンプ記述子に格納される相対情報は、うるう秒の挿入を考慮した値ではない。
受信装置は、まず、送信側(送信装置)により送信された、MPUと、第1時刻情報と、第2時刻情報と、識別情報とを含むMMTPパケットを受信し、図99の「AU毎のPTS」に示すように、MPUタイムスタンプ記述子に格納されている第1時刻情報及びMPU拡張タイムスタンプ記述子に格納されている第2時刻情報の両方に基づいてMPU内に含まれるすべてのAU毎のPTS(DTS)を算出する。
次に、受信装置は、AU毎のPTSを補正する。補正対象となるAUは、AUが属するMPUのMPUタイムスタンプの付与のタイミング(図99の矢印の元が示すタイミング)がC領域であり、かつ、補正前のAU毎のPTSが8:59:59以降を示すAUである。補正対象となるAUは、図99では、下線で示されるAUであり、MPU#2におけるAU#5、及び、MPU#3におけるAU#1-AU#5である。受信装置は、PTSの補正対象のAUに該当すると判断した場合には、当該AUのPTSを+1秒補正する。
つまり、補正では、複数のAUそれぞれについて、当該AUを格納しているMPUのMPUタイムスタンプがうるう秒調整前の基準時刻情報に基づいて生成されており、かつ、算出された当該AUのPTSまたはDTSが所定の時刻(うるう秒削除の場合には8:59:59)以降である補正条件を満たすか否かを判定する。そして、補正では、判定において、上記の補正条件を満たすと判定されたAUのPTSまたはDTSを補正する。
受信装置では、うるう秒削除を実施したNTP時刻、及び、補正したPTSに基づいて、すべてのAUの同期再生を実施できる。
なお、MPUタイムスタンプの付与のタイミングを示す識別情報は、少なくとも、補正対象のAUを含むMPUに対して提示する必要がある。つまり、補正対象のAUを含まないMPUに対して識別情報を提示する必要は必ずしもない。
図100は、図98及び図99で説明した受信装置の動作フローを示す図である。
なお、送信側の動作フローは、図88に示す動作フローと同じであるため説明を省略する。
受信装置では、まず、MPUタイムスタンプ記述子、及び、MPU拡張タイムスタンプ記述子を用いて、すべてのAU毎のタイムスタンプ(PTS及びDTS)を算出する(S2901)。
次に、送信側によりシグナリングされた識別情報に基づいて、AU毎に、当該AUの属するMPUのMPUタイムスタンプの付与のタイミングがA領域であるか、B領域であるか、C領域であるか、D領域であるかを判定する(S2902)。ここで、A領域~D領域は、上記で定義したものと同じであるため説明を省略する。なお、図89と同様に、うるう秒の挿入や削除が行われない場合については、図示しない。
ステップS2902において、AUの属するMPUのMPUタイムスタンプがA領域のNTP時刻に基づいて付与されたものと判定された場合、ステップS2901において算出されたAUのタイムスタンプが9:00:0:以降か否かを判定する(S2903)。
AUのタイムスタンプが9:00:00以降であると判定された場合(ステップS2903でYes)、AUのタイムスタンプ値を-1秒補正する(S2904)。
ステップS2902においてAUの属するMPUのMPUタイムスタンプがC領域のNTP時刻に基づいて付与されたものと判定された場合、ステップS2901において算出されたAUのタイムスタンプが8:59:59以降か否かを判定する(S2905)。
AUのタイムスタンプが8:59:59以降であると判定された場合(ステップS2905でYes)、AUのタイムスタンプ値を+1秒補正する(S2906)。
一方、ステップS2902においてAUの属するMPUのMPUタイムスタンプがB領域もしくはD領域のNTP時刻に基づいて付与されたものと判定された場合、または、ステップS2903においてAUのタイムスタンプ値が90000以降でないと判定された場合(ステップS2903でNo)、または、ステップS2905においてAUのタイムスタンプ値が8:59:59以降でないと判定された場合(ステップS2905でNo)、AUのタイムスタンプを補正せず(ステップS2907)、受信装置の動作を終了する。
以上のように、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に代表されるように、MPUのタイムスタンプの絶対値を示す第1時刻情報と、当該絶対値に対する相対値を示す第2時刻情報とがそれぞれ伝送される場合、送信側は、タイムスタンプの絶対値と共に、タイムスタンプの絶対値が付与される基となるNTP時刻の領域を示す識別情報を伝送する。
受信装置では、MPUのタイムスタンプの絶対値を示す第1時刻情報及び相対値を示す第2時刻情報に基づきすべてのAUのタイムスタンプ(PTSおよびDTS)を算出した後に、それぞれのタイムスタンプ、及び、タイムスタンプの基となるMPUタイムスタンプの絶対値が付与される基となるNTP時刻の領域を示す識別情報に基づき、タイムスタンプを補正するか否かを判定することで、タイムスタンプを補正する。
受信装置において各AUについてタイムスタンプを補正したか否かを示す情報や、各AUが属するMPUのMPUタイムスタンプを付与したタイミングがA領域であるか、B領域であるか、C領域であるか、D領域であるかを示す情報などの付加情報は、全てのMPUで示す必要はなく、最低限補正対象のAUを含むMPUを含む区間において示せばよい。
例えば、任意のAUにおけるタイムスタンプ(PTSまたはDTS)、及び当該AUが属するMPUのMPUタイムスタンプを付与する基となるNTP時刻との時間差をN秒とした場合、うるう秒挿入時、または、うるう秒削除時に、補正対象のAUが存在する期間は、うるう秒調整前の少なくともN秒間である。そのため、うるう秒挿入時のA領域、または、うるう秒削除時におけるC領域は、少なくともうるう秒調整前のN秒間以上の期間を示す領域である必要がある。
逆に、うるう秒挿入時におけるA領域、うるう秒削除時におけるC領域を示す時間をM秒と規定し、必ずN<Mとなるようにタイムスタンプを付与するよう制約を与えてもよい。
また、うるう秒挿入時におけるB領域、または、うるう秒削除時におけるD領域は、必ずしもシグナリングする必要はなく、うるう秒挿入時においてはA領域からB領域へ移行したことを示す情報を、うるう秒削除時においてはC領域からD領域へ移行したことを示す情報を最低限示せばよい。
要するに、受信装置は、まず、第1時刻情報(絶対的な時刻情報)及び第2時刻情報(相対的な時刻情報)に基づいて、すべてのアクセスユニットのタイムスタンプを算出し、すべてのアクセスユニットのそれぞれについて、当該アクセスユニットが属するMPUのMPUタイムスタンプの算出の基となるNTP時刻がうるう秒調整前であるか否かを示す識別情報に基づき、当該アクセスユニットのタイムスタンプを補正する。具体的には、識別情報がうるう秒挿入の直前までの時刻を示す場合、かつ、当該アクセスユニットのタイムスタンプが9:00:00以降を示す場合は、タイムスタンプを-1秒補正する。また、識別情報がうるう秒削除の直前までの時刻を示す場合、かつ、アクセスユニットのタイムスタンプが8:59:59以降を示す場合は、タイムスタンプを+1秒補正する。また、受信装置は、タイムスタンプが補正されているアクセスユニットの場合には、うるう秒調整が実施された後の基準時刻情報に基づいて当該アクセスユニットを提示する。
このように、うるう秒調整時に、アクセスユニットが属するMPUのMPUタイムスタンプの付与のタイミングを判定することにより、すべてのアクセスユニットのタイムスタンプの補正が可能となり、MPUタイムスタンプ記述子やMPU拡張タイムスタンプ記述子を用いた適切な受信処理が可能となる。つまり、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、MPUに格納されている複数のアクセスユニットを意図された時刻に再生できる。
[補足:送受信システム及び受信装置]
以上のように、符号化ストリームを構成するデータをMPUに格納して送信する送信装置と、送信されたMPUを受信する受信装置とを備える送受信システムは、図101のように構成することも可能である。また、当該受信装置は、図102のように構成することも可能である。図101は、送受信システムの具体的構成の例を示す図である。図102は、受信装置の具体的構成の例を示す図である。
以上のように、符号化ストリームを構成するデータをMPUに格納して送信する送信装置と、送信されたMPUを受信する受信装置とを備える送受信システムは、図101のように構成することも可能である。また、当該受信装置は、図102のように構成することも可能である。図101は、送受信システムの具体的構成の例を示す図である。図102は、受信装置の具体的構成の例を示す図である。
送受信システム1100は、送信装置1200と、受信装置1300とを備える。
送信装置1200は、生成部1201と、送信部1202とを備える。生成部1201及び送信部1202のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
生成部1201は、外部から受信した基準時刻情報(NTP時刻)に基づいて、第1のデータユニット(MPU)の提示時刻を示す第1時刻情報(MPUタイムスタンプ)を生成する。
送信部1202は、第1のデータユニット(MPU)と、生成部1201により生成された第1時刻情報(MPUタイムスタンプ)と、第1時刻情報(MPUタイムスタンプ)とで複数の第2のデータユニット(AU)それぞれの提示時刻(PTS)または復号時刻(DTS)を示す第2時刻情報(相対情報)と、識別情報とを送信する。
受信装置1300は、受信部1301と、算出部1302と、補正部1303とを備える。受信部1301、算出部1302及び算出部1303のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置1300の各構成要素についての詳細な説明は、受信方法の説明において行う。
受信方法については、図103を用いて説明する。図103は、受信装置による動作フロー(受信方法)である。
まず、受信装置1300の受信部1301は、第1のデータユニット(MPU)と、第1時刻情報(MPUタイムスタンプ)と、第2時刻情報(相対情報)と、識別情報とを受信する(S3001)。
次に、受信装置1300の算出部1302は、受信部1301により受信された第1時刻情報(MPUタイムスタンプ)と第2時刻情報(相対情報)とを用いて、受信部1302により受信された複数の第2のデータユニット(AU)それぞれの提示時刻(PTS)または復号時刻(DTS)を産出する(S3002)。
次に、受信装置1300の補正部1303は、受信部1301により受信された識別情報に基づいて、算出部1302により算出された複数の第2のデータユニット(AU)それぞれの提示時刻(PTS)または復号時刻(DTS)を補正する(S3003)。
これにより、受信装置1300は、うるう秒調整が行われた場合であっても、第1のデータユニットに格納されている複数の第2のデータユニットを正常に再生できる。
なお、実施の形態8において、再生とは、復号及び提示の少なくとも一方の処理を含む処理を示す。
(実施の形態9)
実施の形態8では、MPU内に含まれるAU毎のPTSまたはDTSを受信装置において補正する方法について説明したが、実施の形態9では、当該PTSまたはDTSを送信装置においても補正する方法について説明する。つまり、MPU内に含まれる複数のAUのうちの先頭AUを除く複数の他のAUそれぞれのPTSまたはDTSを示すタイムスタンプを送信装置においても補正する補正方法について説明する。
実施の形態8では、MPU内に含まれるAU毎のPTSまたはDTSを受信装置において補正する方法について説明したが、実施の形態9では、当該PTSまたはDTSを送信装置においても補正する方法について説明する。つまり、MPU内に含まれる複数のAUのうちの先頭AUを除く複数の他のAUそれぞれのPTSまたはDTSを示すタイムスタンプを送信装置においても補正する補正方法について説明する。
図104は、うるう秒挿入時に送信側(送信装置)においてタイムスタンプを補正する補正方法について説明するための図である。図104は、図84の(a)と同じケースである。
ここで、送信側のNTP時刻は、NTPサーバと同期しており、また、受信側のNTP時刻は、送信側から伝送されるNTPパケットに格納されるタイムスタンプに基づいて再生されることで、送信側のNTP時刻と同期している場合を例に説明する。この場合、送信側のNTP時刻及び受信側のNTP時刻共に、うるう秒の挿入時は+1秒の調整がなされる。
図104におけるNTP時刻は、送信側のNTP時刻及び受信側のNTP時刻で共通であるとする。なお、以下では、伝送遅延はないものとして説明する。また、以下ではMPU内のAUのPTSの補正方法のみ説明するが、MPU内のAUのDTSについても同様の方法を用いることにより補正することができる。なお、図104では、一つのMPUに含まれるAU数は5であるとして説明するが、MPUに含まれるAU数はこれに限るものではない。
送信側(送信装置)では、以下の処理を行う。
1.実施の形態6において図83を用いて説明したように、MPUの提示時刻情報(第1時刻情報)であるMPUタイムスタンプを生成する生成処理を行う。
2.MPUタイムスタンプの付与のタイミング(図104の矢印の元が示すタイミング)がA領域に含まれ、かつ、MPUタイムスタンプ(補正前のMPUタイムスタンプ値)が9:00:00以降を示す場合は、MPUタイムスタンプ値を-1秒補正して、補正後のMPUタイムスタンプをMPUタイムスタンプ記述子に格納する補正処理を行う。つまり、A領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプであり、かつ、当該MPUタイムスタンプが9:00:00以降を示す場合は、当該MPUタイムスタンプを-1秒補正する。なお、ここでの「9:00:00」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻(つまり、UTC時刻に9時間を加算することにより算出される時刻)である。
また、MPUタイムスタンプを付与するタイミング(図104の矢印の元が示すタイミング)がB領域の場合、MPUタイムスタンプを補正しない。つまり、B領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプである場合は、当該MPUタイムスタンプを補正しない。
なお、MPU拡張タイムスタンプ記述子には、AU毎のPTSまたはDTSを算出するための第2時刻情報が、MPUタイムスタンプ記述子に格納されるMPUの先頭AUのPTSからの相対情報として格納されている。このとき、MPU拡張タイムスタンプ記述子に格納される相対情報は、うるう秒の挿入を考慮した値ではない。
したがって、上記1の生成処理では、第1時刻情報としてのMPUタイムスタンプが補正条件を満たす場合に、MPUタイムスタンプを補正する。このため、第1時刻情報は、うるう秒調整時に補正の対象となる時刻情報である。そして、補正条件とは、MPUタイムスタンプが、うるう秒調整前のNTP時刻に基づいて生成されており、かつ、9:00:00以降であることである。
3.複数のMPUが格納されたMMTPパケットを受信装置に送信する送信処理を行う。MMTPパケットは、制御情報として、第1時刻情報としてのMPUタイムスタンプを含むMPUタイムスタンプ記述子と、第2時刻情報としての相対情報を含むMPU拡張タイムスタンプ記述子と、識別情報とを含む。
ここで識別情報は、MPUタイムスタンプが、上記1の生成処理におけるMPUタイムスタンプの補正条件に該当せず、送信側でMPUタイムスタンプを補正しない場合において、当該MPUタイムスタンプ及び相対情報を用いてMPU内のAU毎のPTSまたはDTSを受信装置が算出する際に、当該PTSまたは当該DTSに対してうるう秒挿入による補正が必要となるAUを含むMPUを受信装置が識別するための情報である。
つまり、識別情報は、基準時刻情報に対してうるう秒調整が行われることにより、補正が必要となったPTSで提示される、または、補正が必要となったDTSで提示されるAUであって、先頭AU以外の他のAU(以下、「補正要AU」と言う。)がMPUに含まれる可能性があることを示す情報である。なお、識別情報は、言い換えると、補正要AUがMPUに含まれるか否かの判断を受信装置に行わせるか否かを示す情報とも言える。
識別情報は、例えば、MPUタイムスタンプが、上記1の生成処理においてうるう秒調整前のNTP時刻に基づいて生成され、かつ、上記2の補正処理において補正されていない情報であるか否かを示す情報である。つまり、識別情報は、MPUタイムスタンプがうるう秒調整前のNTP時刻に基づいて生成されたか否かを示す第1識別情報と、MPUタイムスタンプを補正したことを示す第2識別情報とを含む。
このように、識別情報は、MPUタイムスタンプが、生成処理においてうるう秒調整前のNTP時刻に基づいて生成され、かつ、補正処理において補正されていない情報であることを示す場合、補正要AUがMPUに含まれる可能性があることを示す。反対に、識別情報は、MPUタイムスタンプが、生成処理においてうるう秒調整前のNTP時刻に基づいて生成されていない、または、補正処理において補正されている情報であることを示す場合、補正要AUがMPUに含まれる可能性がない(つまり、補正要AUがMPUに含まれるか否かの判断を受信装置に行わせない)ことを示す。
送信側(送信装置)の処理について図104を用いて具体的に説明する。
図104で示した例では、上記2の補正処理における補正条件に該当するのはMPU#2であり、下線で示すように、送信側でMPU#2のMPUタイムスタンプを-1秒補正し、それ以外のMPUのMPUタイムスタンプは補正しない。以上のように算出したMPUタイムスタンプをMPUタイムスタンプ記述子に示し、一方、図示しないMPU拡張タイムスタンプ記述子には、従来どおり、当該MPUにおけるAU毎のPTS(DTS)をMPUタイムスタンプからの相対情報により示す。
また、図104におけるMPU#1は、補正要AUを含むMPUである。ここで、図104に、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づいて算出したAU毎のPTSを示す。MPU#1におけるAU#5のPTSは、9:00:00.1と算出されるものの、実際にはうるう秒挿入後の2回目の8:59:59台に提示すべきAUであり、-1秒の補正が必要である。つまり、MPU#1におけるAU#5は、補正要AUである。
以上のように、送信装置においては、MPUタイムスタンプの付与のタイミング(図104の矢印の元が示すタイミング)がA領域であり、かつ、補正条件を満たさない(つまり、補正前のMPUタイムスタンプが所定の時刻としての9:00:00より前であり、かつ、補正前のMPUタイムスタンプ及び相対情報を用いて算出されるMPU内のすべてのAUのPTS(DTS)のうち、少なくとも1つ以上の値が9:00:00以降となる)条件に該当するMPUを、補正要AUを含むMPUであると判定でき、補正要AUを含むMPUであることを示す情報を送信装置から受信装置にシグナリングする。当該MPUは、言い換えれば、MPUタイムスタンプを補正しない場合において、MPU内に1回目の8:59:59台に提示すべきAU、及び、2回目の8:59:59台に提示すべきAUの両方が存在するMPUということもできる。
受信装置では、以下の処理を行う。
1.送信側(送信装置)により送信されたMMTPパケットを受信する受信処理を行う。
2.MMTPパケットの制御情報に含まれるMPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づいて、すべてのAUのPTS(DTS)を算出する算出処理を行う。
3.送信側(送信装置)によりシグナリングされた、補正要AUを含む可能性があるMPUであるか否かを示す識別情報に基づき、補正要AUを含む可能性があることが識別情報により示されているMPUについて、補正要AUが含まれるか否かを判断する判断処理を行う。具体的には、当該MPUに含まれるすべてのAUのPTS(DTS)が9:00:00以降であるか否かを判断し、PTS(DTS)が9:00:00以降であるAUを補正要AUであると判断することで、MPUに補正要AUが含まれるか否かを判断する。そして、補正要AUのPTS(DTS)に対して、-1秒補正を実施する。
受信装置の処理について図104を用いて具体的に説明する。
図104においては、MPU#1が補正要AUを含む可能性があるMPUであると送信側からシグナリングされるため、MPU#1においてタイムスタンプ記述子に基づいて算出されるPTSが9:00:00以降を示すAU#5が補正の対象となり、-1秒補正を実施する。これにより、補正後において、MPU#1におけるAU#5のPTSは、8:59:59.1となる。
なお、補正要AUを含む可能性がないMPUであると送信側からシグナリングされる場合、受信装置において、上記の判断処理を行わない。このため、当該MPUに格納されている複数のAUについては、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づいて算出される当該複数のAUのPTS(DTS)を補正しない。以上のようにすることで、すべてのAUのPTS(DTS)を算出できる。
なお、受信装置は、送信側においてMPUタイムスタンプが補正されたか否か、または、受信装置においてPTS(DTS)を補正したか否かを示す情報に基づき、送信装置及び受信装置のいずれかで補正されたタイムスタンプを用いて提示または復号を行う場合は、必ずうるう秒挿入が実施された後(2回目の8:59:59台以降)のNTP時刻に基づいて提示または復号を行う。一方で、補正される前のタイムスタンプを用いて提示または復号を行う場合は、うるう秒挿入が実施される前(1回目の8:59:59台以前)のNTP時刻に基づいて、提示または復号を行う。図104の例では、MPU#1におけるAU#4までのAUを、うるう秒挿入が実施される前(1回目の8:59:59台以前)のNTP時刻に基づいて提示し、MPU#1におけるAU#5以降のAUはうるう秒挿入が実施された後(2回目の8:59:59台以降)のNTP時刻に基づいて提示する。
なお、本実施の形態では、送信側において、MPU拡張タイムスタンプ記述子には、従来どおりうるう秒挿入を考慮せず、MPUタイムスタンプからの相対値を格納すると説明したが、うるう秒挿入による補正も考慮し、MPU#1におけるAU#5のタイムスタンプを-1秒補正した後の相対値を格納してもよい。このとき、当該AUが補正されており、うるう秒挿入後(2回目の8:59:59秒以降)のNTP時刻に基づいて提示または復号するAUであることを別途シグナリングする。
受信装置は、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づきすべてのAUのPTSまたはDTSを算出する。このとき、相対値がすでに補正されているため、受信装置でAUのタイムスタンプを補正する必要はなく、MPUタイムスタンプが補正されたか否かを示す情報、及び、MPU内のAUのPTSまたはDTSが補正されたか否かを示す情報に基づき、すべてのAUを提示または復号できる。
図105は、うるう秒削除時に送信側(送信装置)においてタイムスタンプを補正する補正方法について説明するための図である。図105は、図84の(b)と同じケースである。
ここで、送信側のNTP時刻は、NTPサーバと同期しており、また、受信側のNTP時刻は、送信側から伝送されるNTPパケットに格納されるタイムスタンプに基づいて再生されることで、送信側のNTP時刻と同期している場合を例に説明する。この場合、送信側のNTP時刻及び受信側のNTP時刻共に、うるう秒の挿入時は-1秒の調整がなされる。
図105におけるNTP時刻は、送信側のNTP時刻及び受信側のNTP時刻で共通であるとする。なお、以下では、伝送遅延はないものとして説明する。また、以下ではMPU内のAUのPTSの補正方法のみ説明するが、MPU内のAUのDTSについても同様の方法を用いることにより補正することができる。なお、図104では、一つのMPUに含まれるAU数は5であるとして説明するが、MPUに含まれるAU数はこれに限るものではない。
送信側(送信装置)では、以下の処理を行う。
1.実施の形態6において図83を用いて説明したように、MPUの提示時刻情報(第1時刻情報)であるMPUタイムスタンプを生成する生成処理を行う。
2.MPUタイムスタンプの付与のタイミング(図105の矢印の元が示すタイミング)がC領域に含まれ、かつ、MPUタイムスタンプ(補正前のMPUタイムスタンプ値)が8:59:59以降を示す場合は、MPUタイムスタンプ値を+1秒補正して、補正後のMPUタイムスタンプをMPUタイムスタンプ記述子に格納する補正処理を行う。つまり、C領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプであり、かつ、当該MPUタイムスタンプが8:59:59以降を示す場合は、当該MPUタイムスタンプを+1秒補正する。なお、ここでの「8:59:59」とはうるう秒調整が行われる基準となる時刻を日本時間に対応させた時刻(つまり、UTC時刻に9時間を加算することにより算出される時刻)から-1秒減算することで得られた時刻である。
また、MPUタイムスタンプを付与するタイミング(図105の矢印の元が示すタイミング)がD領域の場合、MPUタイムスタンプを補正しない。つまり、D領域に含まれるNTP時刻に基づいて生成されたMPUタイムスタンプである場合は、当該MPUタイムスタンプを補正しない。
なお、MPU拡張タイムスタンプ記述子には、AU毎のPTSまたはDTSを算出するための第2時刻情報が、MPUタイムスタンプ記述子に格納されるMPUの先頭AUのPTSからの相対情報として格納されている。このとき、MPU拡張タイムスタンプ記述子に格納される相対情報は、うるう秒の削除を考慮した値ではない。
したがって、上記1の生成処理では、第1時刻情報としてのMPUタイムスタンプが補正条件を満たす場合に、MPUタイムスタンプを補正する。このため、第1時刻情報は、うるう秒調整時に補正の対象となる時刻情報である。そして、補正条件とは、MPUタイムスタンプが、うるう秒調整前のNTP時刻に基づいて生成されており、かつ、8:59:59以降であることである。
3.複数のMPUが格納されたMMTPパケットを受信装置に送信する送信処理を行う。MMTPパケットは、制御情報として、第1時刻情報としてのMPUタイムスタンプを含むMPUタイムスタンプ記述子と、第2時刻情報としての相対情報を含むMPU拡張タイムスタンプ記述子と、識別情報とを含む。
ここで識別情報は、MPUタイムスタンプが、上記1の生成処理におけるMPUタイムスタンプの補正条件に該当せず、送信側でMPUタイムスタンプを補正しない場合において、当該MPUタイムスタンプ及び相対情報を用いてMPU内のAU毎のPTSまたはDTSを受信装置が算出する際に、当該PTSまたは当該DTSに対してうるう秒削除による補正が必要となるAUを含むMPUを受信装置が識別するための情報である。
ここで、識別情報は、うるう秒挿入で説明した識別情報と同様であるため、説明を省略する。
送信側(送信装置)の処理について図105を用いて具体的に説明する。
図105で示した例では、上記2の補正処理におけるMPUタイムスタンプを補正する条件に該当するのはMPU#3であり、下線で示すように、送信側でMPU#3のMPUタイムスタンプを+1秒補正し、それ以外のMPUのMPUタイムスタンプは補正しない。以上のように算出したMPUタイムスタンプをMPUタイムスタンプ記述子に示し、一方、図示しないMPU拡張タイムスタンプ記述子には、従来どおり、当該MPUにおけるAU毎のPTS(DTS)をMPUタイムスタンプからの相対情報で示す。
また、図105におけるMPU#2は、補正要AUを含むMPUである。
ここで、105に、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づいて算出したAU毎のPTSを示す。MPU#2におけるAU#5のPTSは、8:59:59.1と算出されるものの、実際にはうるう秒削除後の9:00:00台に提示すべきAUであり、+1秒の補正が必要である。つまり、MPU#2におけるAU#5は、補正要AUである。
以上のように、送信装置においては、MPUタイムスタンプの付与のタイミング(図105の矢印の元が示すタイミング)がC領域であり、かつ、補正条件を満たさない(つまり、補正前のMPUタイムスタンプが所定の時刻としての8:59:59より前であり、かつ、補正前のMPUタイムスタンプ及び相対情報を用いて算出されるMPU内のすべてのAUのPTS(DTS)のうち、少なくとも1つ以上の値が8:59:59以降となる)条件に該当するMPUを、補正要AUを含むMPUであると判定でき、補正要AUを含むMPUであることを示す情報を送信装置から受信装置にシグナリングする。当該MPUは、言い換えれば、MPUタイムスタンプを補正しない場合において、MPU内にうるう秒削除前の8:59:58台に提示すべきAU、及び、うるう秒削除後の9:00:00台に提示すべきAUの両方が存在するMPUということもできる。
受信装置では、以下の処理を行う。
1.送信側(送信装置)により送信されたMMTPパケットを受信する受信処理を行う。
2.MMTPパケットの制御情報に含まれるMPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づいて、すべてのAUのPTS(DTS)を算出する算出処理を行う。
3.送信側(送信装置)によりシグナリングされた、補正要AUを含む可能性があるMPUであるか否かを示す識別情報に基づき、補正要AUを含む可能性があることが識別情報により示されているMPUについて、補正要AUが含まれるか否かを判断する判断処理を行う。具体的には、当該MPUに含まれるすべてのAUのPTS(DTS)が8:59:59以降であるか否かを判断し、PTS(DTS)が8:59:59以降であるAUを補正要AUであると判断することで、MPUに補正要AUが含まれるか否かを判断する。そして、補正要AUのPTS(DTS)に対して、+1秒補正を実施する。
図105においては、MPU#2が補正要AUを含む可能性があるMPUであると送信側からシグナリングされるため、MPU#2においてタイムスタンプ記述子に基づいて算出されるPTSが8:59:59以降を示すAU#5が補正の対象となり、+1秒補正を実施する。これにより、補正後において、MPU#2におけるAU#5のPTSは、9:00:00.1となる。
なお、補正要AUを含む可能性がないMPUであると送信側からシグナリングされる場合、受信装置において、上記の判断処理を行わない。このため、当該MPUに格納されている複数のAUについては、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づいて算出される当該複数のAUのPTS(DTS)を補正しない。以上のようにすることで、すべてのAUのPTS(DTS)を算出できる。
なお、受信装置は、補正されたPTS(DTS)を用いてAUを提示または復号できる。
なお、本実施の形態では、送信側において、MPU拡張タイムスタンプ記述子には、従来どおりうるう秒削除を考慮せず、MPUタイムスタンプからの相対値を格納すると説明したが、うるう秒削除による補正も考慮し、MPU#1におけるAU#5のタイムスタンプを+1秒補正した後の相対値を格納してもよい。
受信装置は、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子に基づきすべてのAUのPTSまたはDTSを算出する。このとき、相対値がすでに補正されているため、受信装置でAUのタイムスタンプを補正する必要はなく、すべてのAUを提示または復号できる。
なお、これまで説明した、うるう秒挿入またはうるう秒削除における補正方法の中で、送信側(送信装置)は、どの補正方法を用いるかを選択できてもよい。送信側(送信装置)が補正方法を選択する場合には、送信側がどの方法を用いて補正したかを、受信装置にシグナリングする。受信装置はシグナリングされた情報に基づいて、受信装置における補正或いは、提示動作または復号動作を切り替えることができる。
図106は、図104で説明した送信装置の動作フローを示す図である。図107は、図104で説明した受信装置の動作フローを示す図である。
図106において、送信装置は、MPUのタイムスタンプの付与のタイミングがA領域であるか、B領域であるかを判定する(S3101)。ここで、A領域およびB領域は、上記で定義したものと同じであるため説明を省略する。なお、図89と同様に、うるう秒の挿入が行われない場合については、図示しない。
ステップS3101においてB領域であると判定された場合、MPUタイムスタンプを補正せず(S3102)、処理を終了する。
一方、ステップS3101においてA領域であると判定された場合、当該MPUタイムスタンプが9:00:00秒以降であるか否かを判定する(S3103)。
MPUタイムスタンプが9:00:00以降であると判定された場合(ステップS3103でYes)、MPUタイムスタンプを-1秒補正し、MPUタイムスタンプを補正したことを受信装置へシグナリングし(S3104)、処理を終了する。
一方、MPUタイムスタンプが9:00:00以降でないと判定された場合(ステップS3103でNo)、MPUタイムスタンプ記述子、及び、MPU拡張タイムスタプ記述子を用いてMPU内に含まれるすべてのAUのタイムスタンプ(PTS及びDTS)を算出する(S3105)。
次に、算出されたタイムスタンプが9:00:00以降であるAUがMPUに含まれるか否かを判定する(S3106)。
算出されたタイムスタンプが9:00:00以降であるAUが含まれると判定された場合(S3106でYes)、受信装置でMPU内のAUのタイムスタンプの補正が必要であることを受信装置にシグナリングする(S3107)。
一方、算出されたタイムスタンプが9:00:00以降であるAUがMPUに含まれないと判定された場合(S3106でNo)、処理を終了する。
図107において、受信装置は、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子を用いてすべてのAUのタイムスタンプを算出する(S3201)。
次に、シグナリングされた識別情報に基づいて、MPU内のAUのタイムスタンプの補正が必要か否かを判定する(S3202)。
MPU内のAUのタイムスタンプの補正が必要であると判定された場合(ステップS3202でYes)、タイムスタンプが9:00:00以降を示すAUのタイムスタンプを-1秒補正する(S3205)。
一方、MPU内のAUのタイムスタンプの補正が必要ないと判定された場合(ステップS3202でNo)、シグナリングされた識別情報に基づいて、MPUタイムスタンプが補正されているか否かを判定する(S3203)。
MPUタイムスタンプが補正されていないと判定された場合(ステップS3203でNo)、補正されるタイムスタンプ以前のタイムスタンプについてはうるう秒挿入以前のNTP時刻に基づいてAUを提示し、補正されるタイムスタンプ以降のタイムスタンプについてはうるう秒挿入以降のNTP時刻に基づいてAUを提示する(S3204)。
ステップS3205の後、または、ステップS3203においてタイムスタンプが補正されたと判定された場合(ステップS3203でYes)、うるう秒挿入が実施された後のNTP時刻に基づいてAUを提示する(S3206)。
図108は、図105で説明した送信装置の動作フローを示す図である。図109は、図105で説明した受信装置の動作フローをに示す図である。
図108において、送信装置は、MPUのタイムスタンプの付与のタイミングがC領域であるか、D領域であるかを判定する(S3301)。ここで、C領域およびD領域は、上記で定義したものと同じであるため説明を省略する。なお、図89と同様に、うるう秒の削除が行われない場合については、図示しない。
ステップS3301において、D領域であると判定された場合、MPUタイムスタンプを補正せず(S3302)、処理を終了する。
一方、ステップS3301においてC領域であると判定された場合、当該MPUタイムスタンプが8:59:59以降であるか否かを判定する(S3303)。
MPUタイムスタンプが8:59:59以降であると判定された場合(ステップS3303でYes)、MPUタイムスタンプを+1秒補正し(S3304)、処理を終了する。
一方、MPUタイムスタンプが8:59:59以降でないと判定された場合(ステップS3303でNo)、MPUタイムスタンプ記述子、及び、MPU拡張タイムスタプ記述子を用いてMPU内に含まれるすべてのAUのタイムスタンプ(PTS及びDTS)を算出する(S3305)。
次に、算出されたタイムスタンプが8:59:59以降であるAUが含まれるか否かを判定する(S3306)。
算出されたタイムスタンプが8:59:59以降であるがAUが含まれると判定された場合(S3306でYes)、受信装置でMPU内のAUのタイムスタンプの補正が必要であることを受信装置にシグナリングする(S3307)。
一方、算出されたタイムスタンプが8:59:59以降であるAUがMPUに含まれないと判定された場合(S3306でNo)、処理を終了する。
図109において、受信装置は、MPUタイムスタンプ記述子及びMPU拡張タイムスタンプ記述子を用いてすべてのAUのタイムスタンプを算出する(S3401)。
次に、シグナリングされた識別情報に基づいて、MPU内のAUのタイムスタンプの補正が必要か否かを判定する(S3402)。
MPU内のAUのタイムスタンプの補正が必要であると判定された場合(ステップS3402でYes)、タイムスタンプが8:59:59以降を示すAUのタイムスタンプを+1秒補正する(S3403)。
ステップS3403の後、または、ステップS3402においてMPU内のAUのタイムスタンプの補正が必要ないと判定された場合(ステップS3402でNo)、NTP時刻に基づいてAUを提示する。
これによれば、(i)MPUと、(ii)MPUタイムスタンプと、(iii)補正が必要な提示時刻で提示される、または、補正が必要な復号時刻で復号される第2のデータユニットであって、複数の第2のデータユニットのうちの提示順で先頭の第2のデータユニット以外の他の第2のデータユニットが第1のデータユニットに含まれる可能性があることを示す識別情報とを送信する。このため、送信側及び受信装置の基準クロックの基準となる基準時刻情報に対してうるう秒調整が行なわれる場合であっても、受信装置は、第1のデータユニットに格納されている複数の第2のデータユニットを意図された時刻に再生できる。
[補足:送信装置及び受信装置]
以上のように、符号化ストリームを構成するデータをMPUに格納して送信する送信装置は、図110のように構成することも可能である。また、符号化ストリームを構成するデータが格納されたMPUを受信する受信装置は、図111のように構成することも可能である。図110は、送信装置の具体的構成の例を示す図である。図111は、受信装置の具体的構成の例を示す図である。
以上のように、符号化ストリームを構成するデータをMPUに格納して送信する送信装置は、図110のように構成することも可能である。また、符号化ストリームを構成するデータが格納されたMPUを受信する受信装置は、図111のように構成することも可能である。図110は、送信装置の具体的構成の例を示す図である。図111は、受信装置の具体的構成の例を示す図である。
送信装置1400は、生成部1401と、送信部1402とを備える。生成部1401及び送信部1402のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
受信装置1500は、受信部1501と、判断部1502とを備える。受信部1501及び判断部1502のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。
送信装置1400及び受信装置1500の各構成要素についての詳細な説明は、それぞれ、送信方法及び受信方法の説明において行う。
まず、送信方法については、図112を用いて説明する。図112は、送信装置による動作フロー(送信方法)である。
まず、送信装置1400の生成部1401は、外部から受信した基準時刻情報に基づいて、第1のデータユニットとしてのMPU]の提示時刻を示す第1時刻情報を生成する(S3501)。
次に、送信装置1400の送信部1402は、第1のデータユニット(MPU)と、第1時刻情報(MPUタイムスタンプ)と、識別情報とを送信する(S3502)。ここで、第1時刻情報(MPUタイムスタンプ)は、生成部1401により生成された情報である。また、識別情報は、補正が必要な提示時刻(PTS)で提示される、または、補正が必要な復号時刻(DTS)で復号される第2のデータユニット(アクセスユニット)であって、複数の第2のデータユニット(アクセスユニット)のうちの提示順で先頭の第2のデータユニット(アクセスユニット)以外の他の第2のデータユニット(アクセスユニット)が第1のデータユニット(MPU)に含まれる可能性があることを示す情報である。
これにより、送信装置1400から送信された情報を受信した受信装置は、うるう秒調整が行われた場合であっても、識別情報に基づいてMPU内のAUを再生できるので、MPU内のAUを意図された時刻に再生できる。
次に受信方法について図113を用いて説明する。図113は、受信装置による動作フロー(受信方法)である。
まず、受信装置1500の受信部1501は、第1のデータユニット(MPU)と、第1時刻情報(MPUタイムスタンプ)と、識別情報とを受信する(S3601)。第1時刻情報及び識別情報は、送信装置1400で説明した第1時刻情報及び識別情報と同様である。
次に、受信装置1500の判断部1502は、他の第2のデータユニット(アクセスユニット)が含まれる可能性があることを、受信部1501により受信された識別情報が示している第1のデータユニット(MPU)に対して、他の第2のデータユニット(アクセスユニット)が含まれるか否かを判断する(S3602)。
これにより、受信装置1500は、うるう秒調整が行われた場合であっても、MPU内のAUを意図された時刻に再生できる。
(その他の実施の形態)
以上、実施の形態に係る送信装置、受信装置、送信方法及び受信方法ついて説明したが、本発明は、この実施の形態に限定されるものではない。
以上、実施の形態に係る送信装置、受信装置、送信方法及び受信方法ついて説明したが、本発明は、この実施の形態に限定されるものではない。
また、上記実施の形態に係る送信装置及び受信装置に含まれる各処理部は典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部又は全てを含むように1チップ化されてもよい。
また、集積回路化はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後にプログラムすることが可能なFPGA(Field Programmable Gate Array)、又はLSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPU又はプロセッサなどのプログラム実行部が、ハードディスク又は半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
言い換えると、送信装置及び受信装置は、処理回路(processing circuitry)と、当該処理回路に電気的に接続された(当該制御回路からアクセス可能な)記憶装置(storage)とを備える。処理回路は、専用のハードウェア及びプログラム実行部の少なくとも一方を含む。また、記憶装置は、処理回路がプログラム実行部を含む場合には、当該プログラム実行部により実行されるソフトウェアプログラムを記憶する。処理回路は、記憶装置を用いて、上記実施の形態に係る送信方法又は受信方法を実行する。
さらに、本発明は上記ソフトウェアプログラムであってもよいし、上記プログラムが記録された非一時的なコンピュータ読み取り可能な記録媒体であってもよい。また、上記プログラムは、インターネット等の伝送媒体を介して流通させることができるのは言うまでもない。
また、上記で用いた数字は、全て本発明を具体的に説明するために例示するものであり、本発明は例示された数字に制限されない。
また、ブロック図における機能ブロックの分割は一例であり、複数の機能ブロックを一つの機能ブロックとして実現したり、一つの機能ブロックを複数に分割したり、一部の機能を他の機能ブロックに移してもよい。また、類似する機能を有する複数の機能ブロックの機能を単一のハードウェア又はソフトウェアが並列又は時分割に処理してもよい。
また、上記の送信方法又は受信方法に含まれるステップが実行される順序は、本発明を具体的に説明するために例示するためのものであり、上記以外の順序であってもよい。また、上記ステップの一部が、他のステップと同時(並列)に実行されてもよい。
以上、本発明の一つ又は複数の態様に係る送信装置、受信装置、送信方法及び受信方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つ又は複数の態様の範囲内に含まれてもよい。
本発明は、ビデオデータ及びオーディオデータなどのメディアトランスポートを行う装置又は機器に適用できる。
15、100、300、500、700、900、1200、1400 送信装置
16、101、301 符号化部
17、102 多重化部
18、104 送信部
20、200、400、600、800、1000、1300、1500 受信装置
21 パケットフィルタリング部
22 送信順序タイプ判別部
23 ランダムアクセス部
24、212 制御情報取得部
25 データ取得部
26 算出部
27 初期化情報取得部
28、206 復号命令部
29、204A、204B、204C、204D、402 復号部
30 提示部
201 チューナー
202 復調部
203 逆多重化部
205 表示部
211 タイプ判別部
213 スライス情報取得部
214 復号データ生成部
302 付与部
303、503、702、902、1202、1402 送信部
401、601、801、1001、1301、1501 受信部
501 分割部
502、603 構成部
602 判定部
701、901、1201、1401 生成部
802 第1のバッファ
803 第2のバッファ
804 第3のバッファ
805 第4のバッファ
806 復号部
1002 再生部
1302 算出部
1303 補正部
1502 判断部
16、101、301 符号化部
17、102 多重化部
18、104 送信部
20、200、400、600、800、1000、1300、1500 受信装置
21 パケットフィルタリング部
22 送信順序タイプ判別部
23 ランダムアクセス部
24、212 制御情報取得部
25 データ取得部
26 算出部
27 初期化情報取得部
28、206 復号命令部
29、204A、204B、204C、204D、402 復号部
30 提示部
201 チューナー
202 復調部
203 逆多重化部
205 表示部
211 タイプ判別部
213 スライス情報取得部
214 復号データ生成部
302 付与部
303、503、702、902、1202、1402 送信部
401、601、801、1001、1301、1501 受信部
501 分割部
502、603 構成部
602 判定部
701、901、1201、1401 生成部
802 第1のバッファ
803 第2のバッファ
804 第3のバッファ
805 第4のバッファ
806 復号部
1002 再生部
1302 算出部
1303 補正部
1502 判断部
Claims (4)
- 符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信方法であって、
外部から受信した時刻情報に基づいて、前記所定のデータユニットの提示時刻を示す提示時刻情報を生成し、
前記所定のデータユニットと、生成した前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記時刻情報に基づいて生成されたか否かを示す識別情報とを送信し、
前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、
前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報であり、
前記時刻情報は、NTP(Network Time Protocol)である
送信方法。 - 符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信方法であって、
前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信し、
受信した前記提示時刻情報及び前記識別情報に基づいて、受信した前記所定のデータユニットを再生し、
前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、
前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報であり、
前記時刻情報は、NTP(Network Time Protocol)である
受信方法。 - 符号化ストリームを構成するデータを所定のデータユニットに格納して送信する送信装置であって、
外部から受信した時刻情報に基づいて、当該所定のデータユニットの提示時刻を示す提示時刻情報を生成する生成部と、
前記所定のデータユニットと、前記生成部により生成された前記提示時刻情報と、当該提示時刻情報がうるう秒調整前の前記時刻情報に基づいて生成されたか否かを示す識別情報とを送信する送信部と、を備え、
前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、
前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報であり、
前記時刻情報は、NTP(Network Time Protocol)である
送信装置。 - 符号化ストリームを構成するデータが格納された所定のデータユニットを受信する受信装置であって、
前記所定のデータユニットと、前記所定のデータユニットの提示時刻を示す提示時刻情報と、当該提示時刻情報がうるう秒調整前の時刻情報に基づいて生成されたか否かを示す識別情報とを、受信する受信部と、
前記受信部により受信された前記提示時刻情報及び前記識別情報に基づいて、前記受信部により受信された前記所定のデータユニットを再生する再生部と、を備え、
前記識別情報は、(i)制御情報である制御メッセージに格納され、(ii)前記提示時刻情報が、うるう秒調整が行われる直前の時刻よりも予め定められた期間前の時刻から当該直前の時刻までにおける前記時刻情報に基づいて生成されたかを示し、
前記提示時刻情報は、前記時刻情報から予め定められた時間を加算することで生成された時刻情報であり、
前記時刻情報は、NTP(Network Time Protocol)である
受信装置。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562142010P | 2015-04-02 | 2015-04-02 | |
US62/142,010 | 2015-04-02 | ||
JP2020185412A JP7116137B2 (ja) | 2015-04-02 | 2020-11-05 | 送信方法、受信方法、送信装置及び受信装置 |
JP2022120564A JP7323684B2 (ja) | 2015-04-02 | 2022-07-28 | 送信方法、受信方法、送信装置及び受信装置 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022120564A Division JP7323684B2 (ja) | 2015-04-02 | 2022-07-28 | 送信方法、受信方法、送信装置及び受信装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2023138586A JP2023138586A (ja) | 2023-10-02 |
JP7525705B2 true JP7525705B2 (ja) | 2024-07-30 |
Family
ID=57358571
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016000732A Active JP6585508B2 (ja) | 2015-03-31 | 2016-01-05 | 送信方法、受信方法、送信装置及び受信装置 |
JP2019162380A Active JP6792038B2 (ja) | 2015-04-02 | 2019-09-05 | 受信方法及び受信装置 |
JP2020185412A Active JP7116137B2 (ja) | 2015-04-02 | 2020-11-05 | 送信方法、受信方法、送信装置及び受信装置 |
JP2022120564A Active JP7323684B2 (ja) | 2015-04-02 | 2022-07-28 | 送信方法、受信方法、送信装置及び受信装置 |
JP2023122229A Active JP7525705B2 (ja) | 2015-04-02 | 2023-07-27 | 送信方法、受信方法、送信装置及び受信装置 |
Family Applications Before (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016000732A Active JP6585508B2 (ja) | 2015-03-31 | 2016-01-05 | 送信方法、受信方法、送信装置及び受信装置 |
JP2019162380A Active JP6792038B2 (ja) | 2015-04-02 | 2019-09-05 | 受信方法及び受信装置 |
JP2020185412A Active JP7116137B2 (ja) | 2015-04-02 | 2020-11-05 | 送信方法、受信方法、送信装置及び受信装置 |
JP2022120564A Active JP7323684B2 (ja) | 2015-04-02 | 2022-07-28 | 送信方法、受信方法、送信装置及び受信装置 |
Country Status (1)
Country | Link |
---|---|
JP (5) | JP6585508B2 (ja) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010272071A (ja) | 2009-05-25 | 2010-12-02 | Hitachi Kokusai Electric Inc | 端末装置 |
US20140282791A1 (en) | 2013-03-13 | 2014-09-18 | Johannes P. Schmidt | Leap second support in content timestamps |
JP2015005977A (ja) | 2013-06-18 | 2015-01-08 | パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカPanasonic Intellectual Property Corporation of America | 送信方法および受信方法 |
WO2016129413A1 (ja) | 2015-02-10 | 2016-08-18 | ソニー株式会社 | 送信装置、送信方法、受信装置および受信方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5641090B2 (ja) * | 2013-03-14 | 2014-12-17 | ソニー株式会社 | 送信装置、送信方法、受信装置および受信方法 |
EP3007454A4 (en) * | 2013-06-05 | 2016-06-01 | Panasonic Ip Corp America | DATA DECODING METHOD, DATA DECODING DEVICE AND DATA TRANSMISSION METHOD |
US10194196B2 (en) * | 2015-03-02 | 2019-01-29 | Nec Corporation | Decoding device, reception device, transmission device, transmission/reception system, decoding method, and storage medium having decoding program stored therein |
JP6219330B2 (ja) * | 2015-03-11 | 2017-10-25 | 株式会社東芝 | 送信システム、多重化装置及びうるう秒補正対応方法 |
-
2016
- 2016-01-05 JP JP2016000732A patent/JP6585508B2/ja active Active
-
2019
- 2019-09-05 JP JP2019162380A patent/JP6792038B2/ja active Active
-
2020
- 2020-11-05 JP JP2020185412A patent/JP7116137B2/ja active Active
-
2022
- 2022-07-28 JP JP2022120564A patent/JP7323684B2/ja active Active
-
2023
- 2023-07-27 JP JP2023122229A patent/JP7525705B2/ja active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010272071A (ja) | 2009-05-25 | 2010-12-02 | Hitachi Kokusai Electric Inc | 端末装置 |
US20140282791A1 (en) | 2013-03-13 | 2014-09-18 | Johannes P. Schmidt | Leap second support in content timestamps |
JP2015005977A (ja) | 2013-06-18 | 2015-01-08 | パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカPanasonic Intellectual Property Corporation of America | 送信方法および受信方法 |
WO2016129413A1 (ja) | 2015-02-10 | 2016-08-18 | ソニー株式会社 | 送信装置、送信方法、受信装置および受信方法 |
Also Published As
Publication number | Publication date |
---|---|
JP2023138586A (ja) | 2023-10-02 |
JP7323684B2 (ja) | 2023-08-08 |
JP2022145755A (ja) | 2022-10-04 |
JP6792038B2 (ja) | 2020-11-25 |
JP2021040322A (ja) | 2021-03-11 |
JP2016197852A (ja) | 2016-11-24 |
JP6585508B2 (ja) | 2019-10-02 |
JP7116137B2 (ja) | 2022-08-09 |
JP2019213223A (ja) | 2019-12-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107431845B (zh) | 发送方法、接收方法、发送装置以及接收装置 | |
CN108141636B (zh) | 接收装置以及接收方法 | |
JP7209234B2 (ja) | 受信装置及び受信方法 | |
JP7500833B2 (ja) | 送信方法、受信方法、送信装置及び受信装置 | |
JP7361287B2 (ja) | 送信方法及び送信装置 | |
JP7036956B2 (ja) | 送信方法、受信方法、送信装置及び受信装置 | |
JP7307237B2 (ja) | 受信方法、送信方法、受信装置及び送信装置 | |
WO2016157817A1 (ja) | 送信方法、受信方法、送信装置及び受信装置 | |
JP2021073791A (ja) | 送信方法、受信方法、送信装置及び受信装置 | |
JP2020205633A (ja) | 送信方法、受信方法、送信装置及び受信装置 | |
JP7525705B2 (ja) | 送信方法、受信方法、送信装置及び受信装置 | |
JP2024107125A (ja) | 送信方法、受信方法、送信装置及び受信装置 | |
CN113038188B (zh) | 发送方法、接收方法、发送装置以及接收装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230727 |
|
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: 20240618 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20240718 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7525705 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |