JP6510205B2 - 送信方法、受信方法、送信装置および受信装置 - Google Patents

送信方法、受信方法、送信装置および受信装置 Download PDF

Info

Publication number
JP6510205B2
JP6510205B2 JP2014191896A JP2014191896A JP6510205B2 JP 6510205 B2 JP6510205 B2 JP 6510205B2 JP 2014191896 A JP2014191896 A JP 2014191896A JP 2014191896 A JP2014191896 A JP 2014191896A JP 6510205 B2 JP6510205 B2 JP 6510205B2
Authority
JP
Japan
Prior art keywords
stream
time
content
reference clock
descriptor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014191896A
Other languages
English (en)
Other versions
JP2015076881A (ja
Inventor
遠間 正真
正真 遠間
賀敬 井口
賀敬 井口
加藤 久也
久也 加藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to CN201480037289.2A priority Critical patent/CN105359449B/zh
Priority to PCT/JP2014/005073 priority patent/WO2015052908A1/ja
Priority to EP14853090.0A priority patent/EP3057261B1/en
Publication of JP2015076881A publication Critical patent/JP2015076881A/ja
Priority to US15/007,042 priority patent/US10368115B2/en
Application granted granted Critical
Publication of JP6510205B2 publication Critical patent/JP6510205B2/ja
Priority to US16/430,740 priority patent/US10945015B2/en
Priority to US17/167,174 priority patent/US11849166B2/en
Priority to JP2021136752A priority patent/JP7275212B2/ja
Priority to US18/386,727 priority patent/US20240064359A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26283Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for associating distribution time parameters to content, e.g. to generate electronic program guide data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/23424Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614Multiplexing of additional data and video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365Multiplexing of several video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242Synchronization processes, e.g. processing of PCR [Program Clock References]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84Generation or processing of descriptive data, e.g. content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/854Content authoring
    • H04N21/8547Content authoring involving timestamps for synchronizing content
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/858Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Description

本発明は、データの送信方法および受信方法などに関する。
現在、互いに独立に送信されるストリームにおけるアクセスユニット間のPTS(Presentation Time Stamp)の関係を示すための補助データのデータ構造に関する規格化が進行中である(例えば、非特許文献1参照)。互いに独立に送信されるストリームは、例えば、MPEG−2 TS(Moving Picture Experts Group−2 Transport Stream)において送信されるストリーム、および、MPEG−DASH(Dynamic Adaptive Streaming over HTTP)またはMMT(MPEG Media Transport)などの多重化フォーマットにより送信されるストリームなどである。なお、このようなアクセスユニット間のPTSを対応付けることを、以下、タイムライン拡張と呼ぶ。
Working Draft of ISO/IEC 13181−1:2012/AMD6 −Delivery of Timeline for External Data
しかしながら、上記非特許文献1の送信方法および受信方法におけるタイムライン拡張では、処理量が多く、効率的でないという問題がある。
そこで、本発明は、タイムライン拡張を効率的に行うことができる送信方法および受信方法などを提供する。
本発明の一態様に係る送信方法は、画像または音声のコンテンツに関する第1のストリームを送信する送信方法であって、前記第1のストリームの送受信に用いられる第1の基準クロックと、前記第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとのオフセットである対応関係が更新されたか否かを示すタイミング更新識別情報と、前記第1の基準クロックにおける第1の時刻と、更新後の前記対応関係に基づいて前記第1の時刻に対応付けられた前記第2の基準クロックにおける時刻である第2の時刻とを含む前記第1のストリームを送信する。
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD−ROMなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
本発明の送信方法および受信方法は、タイムライン拡張を効率的に行うことができる送信方法および受信方法などを提供する。
図1Aは、従来の問題を説明するためのTEMIアクセスユニットのシンタックスを示す図である。 図1Bは、受信装置がTEMIアクセスユニットを用いて参照元と参照先のそれぞれのタイムラインを同期するための処理を示すフローチャートである。 図1Cは、参照元のタイムラインと参照先のタイムラインにおける、時刻T_orgと時刻T_refとの関係を示す図である。 図2は、実施の形態におけるTEMIアクセスユニットのシンタックスの一例を示す図である。 図3は、実施の形態における送信装置の構成を示すブロック図である。 図4は、実施の形態における送信装置の処理動作の例を示すフローチャートである。 図5は、実施の形態における受信装置の構成を示すブロック図である。 図6は、実施の形態における受信装置の処理動作の例を示すフローチャートである。 図7Aは、実施の形態における変形例2に係るTEMIアクセスユニットのシンタックスを示す図である。 図7Bは、実施の形態における変形例2に係るTEMIアクセスユニットのシンタックスを示す図である。 図7Cは、実施の形態における変形例2に係るTEMIアクセスユニットのシンタックスを示す図である。 図8Aは、実施の形態における変形例2に係る受信装置により行われるランダムアクセスを説明するための図である。 図8Bは、実施の形態における変形例2に係る、タイムラグを考慮した場合の送信装置および受信装置の処理動作を説明するための図である。 図9は、実施の形態における変形例2に係る受信装置の処理動作の例を示すフローチャートである。 図10Aは、本発明の一態様に係る送信方法を示すフローチャートである。 図10Bは、本発明の一態様に係る送信装置のブロック図である。 図11Aは、本発明の一態様に係る受信方法を示すフローチャートである。 図11Bは、本発明の一態様に係る受信装置のブロック図である。
(本発明の基礎となった知見)
本発明者は、「背景技術」の欄において記載した、非特許文献1の送信方法および受信方法に関し、以下の問題が生じることを見出した。
従来のタイムライン拡張においては、補助データ用のストリームが定義されている。ここで、互いに独立に送信されるストリームを、それぞれ、参照元と参照先とする。なお、これらのストリームのそれぞれは、画像または音声を示す互いに異なるコンテンツを含む。また、参照元は、補助データ用のストリームとされる。この補助データ用のストリームに含まれるいずれかのPESパケットは、TEMI(Timeline and External Media Information)アクセスユニットを格納している。また、そのPESパケットのヘッダには、参照元のタイムラインにおける時刻T_orgが示される。さらに、TEMIアクセスユニットには、参照先のタイムラインにおいて、時刻T_orgに対応する時刻となる、時刻T_refが格納される。なお、タイムラインは、ストリームの送受信に用いられる基準クロックである。つまり、共通の時間軸において、参照元における時刻T_orgと参照先における時刻T_refとは互いに等しい時刻となる。
TEMIアクセスユニットは、参照元のストリームと共に送信される。受信装置は、TEMIアクセスユニットを解析することにより、参照元のコンテンツと参照先のコンテンツとを同期させて再生することができる。
図1Aは、従来の問題を説明するためのTEMIアクセスユニットのシンタックスを示す図である。
図1Aに示すように、TEMIアクセスユニット(TEMI_AU)は、addon_locationと、timescaleとを含む。
addon_locationは、参照先のロケーション情報(例えばURL: Uniform Resource Locatorなど)を示す。
timescaleは、time_before_activationまたはmedia_time_anchorを含む。
time_before_activationは、addon_locationが有効(つまり、参照先を取得することが可能であること)となるまでの時間を示す。
media_time_anchorは、参照先のタイムラインにおける時刻T_refを示す。
また、参照元のタイムラインにおける時刻T_orgは、TEMIアクセスユニットを格納するPESパケットのヘッダのPTSフィールドにおいて示される。
図1Bは、受信装置がTEMIアクセスユニットを用いて参照元と参照先のそれぞれのタイムラインを同期するための処理を示すフローチャートである。
まず、受信装置は、参照元のストリームに含まれるデータを受信する(ステップS1001)。次に、受信装置は、その受信されたデータがTEMIアクセスユニットか否か、つまり、TEMIアクセスユニットを受信したか否かを判定する(ステップS1002)。ここで、受信していないと判定すると(ステップS1002の「いいえ」)、受信装置は、ステップS1001からの処理を繰り返し実行する。一方、受信したと判定すると(ステップS1002の「はい」)、受信装置は、TEMIアクセスユニットを格納するPESパケットのPTSと、TEMIアクセスユニット内のmedia_time_anchorとを取得する。つまり、受信装置は、時刻T_orgと時刻T_refとを取得する(ステップS1003)。次に、受信装置は、その時刻T_orgと時刻T_refとに基づいて、参照元と参照先のタイムラインを同期する(ステップS1004)。なお、参照元と参照先のタイムラインを同期するとは、それらのタイムラインの対応関係、つまり時刻オフセット(つまりオフセット値)を特定することである。
図1Cは、参照元のタイムラインと参照先のタイムラインにおける、時刻T_orgと時刻T_refとの関係を示す図である。
受信装置は、時刻T_orgと時刻T_refの差分を時刻オフセット(offset)として特定する。この時刻オフセットは、offset=T_ref−T_org×(timescale2/timescale1)によって示される。なお、timescale1は、参照元のタイムラインのタイムスケールであり、timescale2は、参照先のタイムラインのタイムスケールである。なお、タイムスケールは、時刻が表現される頻度であって、具体的には、単位時間(例えば1秒間)あたりに表現される時刻の回数である。受信装置は、このような時刻オフセットを特定すると、参照元のタイムラインにおける任意の時刻Tに対応する、参照先のタイムラインにおける時刻を、T+offsetによって算出することができる。
しかしながら、このようなタイムライン拡張においては、TEMIアクセスユニットを受信する度に、時刻T_orgと時刻T_refを解析する必要があり、同期再生時の時刻情報の管理に係る処理量が多く、効率的でないという問題がある。
このような問題を解決するために、本発明の一態様に係る送信方法は、画像または音声のコンテンツに関する第1のストリームを送信する送信方法であって、前記第1のストリームの送受信に用いられる第1の基準クロックと、前記第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとの間の、対応関係が更新されたか否かを示すタイミング更新識別情報と、前記第1の基準クロックにおける第1の時刻と、更新後の前記対応関係に基づいて前記第1の時刻に対応付けられた前記第2の基準クロックにおける時刻である第2の時刻とを含む前記第1のストリームを送信する。
これにより、タイミング更新識別情報が受信装置に送信される。したがって、受信装置は、第1の基準クロックと前記第2の基準クロックとの間の対応関係が更新されたか否かを、第1の時刻と第2の時刻とを用いた解析によって判定することなく、そのタイミング更新識別情報のみに基づいて簡単にその判定を行うことができる。その結果、受信装置は、更新されたと判定したときにのみ、第1の時刻と第2の時刻を用いて、更新後の対応関係を特定すればいいため、受信装置の処理量を抑えることができる。したがって、タイムライン拡張を効率的に行うことができる。
例えば、前記送信方法は、さらに、前記対応関係が更新されたか否かを判定し、判定の結果を示す前記タイミング更新識別情報を生成してもよい。
また、前記対応関係が更新されたか否かの判定では、前記第1の基準クロックによって示される時刻の変化に不連続な変化があったか否かを判定し、不連続な変化があったと判定したときには、前記対応関係が更新されたと判定してもよい。
また、前記第1の基準クロックは、MPEG2−TS(Moving Picture Experts Group−2 Transport Stream)におけるPCR(Program Clock Reference)であってもよい。
また、前記送信方法は、前記対応関係が更新されたと判定したときには、前記第1の基準クロックと前記第2の基準クロックとの間の、更新後の前記対応関係に応じたオフセット値を算出し、前記第1の時刻と、算出された前記オフセット値とに基づいて特定される前記第2の時刻を、前記第1のストリームに含めてもよい。
また、前記第1のストリームにおけるTEMI(Timeline and External Media Information)アクセスユニットに、前記タイミング更新識別情報および前記第2の時刻を格納してもよい。
また、前記TEMIアクセスユニットを格納するPES(Packetized Elementary Stream)パケットのヘッダに、前記第1の時刻を格納してもよい。
また、前記TEMIアクセスユニットは、タイムラインデスクリプタと、ロケーションデスクリプタとを有し、前記タイムラインデスクリプタに、前記タイミング更新識別情報および前記第2の時刻を格納し、前記送信方法は、さらに、前記ロケーションデスクリプタに、前記第2のストリームに関するコンテンツの場所を示すロケーション情報を格納してもよい。
また、前記送信方法は、さらに、前記第2のストリームに関するコンテンツの再生を中止して、第3のストリームに関するコンテンツの再生を開始させるためのスプライシング識別情報と、前記第3のストリームに関するコンテンツの場所を示すロケーション情報とを含む他のロケーションデスクリプタを、前記ロケーションデスクリプタが送信された後に送信し、前記第3のストリームに関するコンテンツの再生区間の終了時までに、前記ロケーションデスクリプタを再び送信してもよい。
これにより、他のロケーションデスクリプタが受信装置に送信される。したがって、受信装置は、他のロケーションデスクリプタに格納されているスプライシング識別情報に基づいて、第2のストリームに関するコンテンツの再生を中止して、第3のストリームに関するコンテンツを再生することができる。さらに、その第3のストリームに関するコンテンツの再生区間(つまりスプライス区間)の終了までに、第2のストリームに関するコンテンツの場所を示すロケーション情報が格納されたロケーションデスクリプタが受信装置に再送される。したがって、受信装置は、その再生区間から第1のストリームの受信を開始した場合であっても、その再生区間の終了時には、次に再生すべきコンテンツを容易に特定して再生することができる。つまり、受信装置は、その再生区間前から第1のストリームの受信を開始していた場合と同様に、第3のストリームに関するコンテンツの前に再生されていた、元の第2のストリームに関するコンテンツの再生を再開することができる。
また、本発明の一態様に係る受信方法は、画像または音声のコンテンツに関する第1のストリームを受信する受信方法であって、前記第1のストリームの送受信に用いられる第1の基準クロックと、前記第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとの間の、対応関係が更新されたか否かを示すタイミング更新識別情報と、前記第1の基準クロックにおける第1の時刻と、更新後の前記対応関係に基づいて前記第1の時刻に対応付けられた前記第2の基準クロックにおける時刻である第2の時刻とを含む前記第1のストリームを受信する。
これにより、タイミング更新識別情報が受信装置に受信される。したがって、受信装置は、第1の基準クロックと第2の基準クロックとの間の対応関係が更新されたか否かを、わざわざ第1の時刻と第2の時刻とを用いた解析によって判定することなく、そのタイミング更新識別情報のみに基づいて簡単にその判定を行うことができる。その結果、受信装置は、更新されたと判定したときにのみ、第1の時刻と第2の時刻を用いて、更新後の対応関係を特定すればいいため、処理量を抑えることができる。したがって、タイムライン拡張を効率的に行うことができる。
なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD−ROMなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
以下、実施の形態について、図面を参照しながら具体的に説明する。
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
(実施の形態)
図2は、本実施の形態におけるTEMIアクセスユニットのシンタックスの一例を示す図である。
このTEMIアクセスユニットは、上述のaddon_locationと、timescaleと、media_time_anchorとを含むととともに、さらに、タイミング更新識別情報id1であるis_timing_updateを含んでいる。
このis_timing_update(id1)は、参照元のタイムラインと参照先のタイムラインとの対応関係(時刻オフセットなど)が更新されたことを示す。つまり、is_timing_updateは、その対応関係が更新された後の、時刻T_orgと、時刻T_refとがPESパケットに格納されていることを示す。なお、参照元のタイムラインと参照先のタイムラインとを、以下、両タイムラインという。また、media_time_anchorが時刻T_refを示し、このTEMIアクセスユニットを含むPESパケットのヘッダに、時刻T_orgがPTSとして示されている。
is_timing_updateは例えば1ビットのフラグである。したがって、is_timing_update=1の場合、そのis_timing_updateは、両タイムラインの対応関係が更新されたことを示す。また、is_timing_update=0の場合、そのis_timing_updateは、両タイムラインの対応関係は更新されていないことを示す。
両タイムラインの対応関係が更新されるのは、addon_locationが有効な期間である。したがって、is_timing_updateの値が1にセットされる場合には、is_announcementの値は0となり、media_time_anchorのフィールドが存在する。
送信装置は、両タイムラインの対応関係が更新された直後に送信されるTEMIアクセスユニットにおいてのみ、is_timing_updateを1にセットしてもよい。または、送信装置は、更新後に送信される複数のTEMIアクセスユニットにおいて、is_timing_updateを1にセットしてもよい。または、送信装置は、更新を事前に通知するために、更新前の複数のTEMIアクセスユニット、及び、更新直後のTEMIアクセスユニットにおいて、is_timing_updateを1にセットしてもよい。この場合、受信装置は、is_timing_updateの値が1から0に変化したことを判定することにより、両タイムラインの対応関係が更新されたと判定してもよい。
送信装置は、参照先のタイムラインのタイムスケールを、TEMIアクセスユニットの“timescale”に設定してもよい。これにより、送信装置は、media_time_anchorの値を、タイムスケールの変換を行うことなしに、参照先のタイムラインにおける時刻情報として用いることができる。
例えば、参照元がMPEG2−TSにより送信され、参照先がMPEG−DASHにより送信される場合、TEMIアクセスユニットはTSに多重化される。また、参照元がMPEG2−TSにより送信され、参照先がMMTのストリームとして送信されてもよく、参照元と参照先が共にMPEG2−TSによって送信されてもよく、他の組合せで送信されてもよい。
また、送信装置は、TEMIアクセスユニットを参照元のストリームに多重化せずに、別のストリームとして送信してもよい。
送信装置は、参照元のタイムラインと参照先のタイムラインとの対応関係を例えば以下のようなケース(ケース1および2)において更新する。
つまり、送信装置は、参照元の基準クロックに不連続が発生した場合に更新する(ケース1)。例えば、送信装置は、MPEG2−TSにおけるPCR(Program Clock Reference)に不連続が発生した場合に更新する。
または、送信装置は、参照先の基準クロックに不連続が発生した場合に更新する(ケース2)。例えば、送信装置は、参照先のMPEG−DASHにおいて、一部のMP4 Fragmentがスキップされる場合に更新する。または、送信装置は、参照先のMPEG2−TSにおけるPCRに不連続が発生した場合に更新する。または、送信装置は、参照先のMMTにおいて基準クロックとされるNTP(Network Time Protocol)の値に不連続が発生する場合に更新する。
なお、ケース2では、参照先の基準クロックに不連続が発生したこと、および、基準クロックの変位量は、参照元のストリームを送信する送信装置に対して通知される。
次に、media_time_anchorの設定方法について説明する。
例えば、MPEG−DASHのように、セグメント化されたコンテンツの途中のセグメントからデータが受信されることがある。このとき、各セグメント、あるいは、MPEG−DASHのピリオドなどにおける、表示(再生)順で先頭のアクセスユニットのPTSが、コンテンツの先頭をゼロとするタイムライン(ゼロタイムライン)に従う場合には、当該タイムラインを使用することができる。一方、受信が開始されるセグメントなどの先頭アクセスユニットのPTSをゼロとするタイムライン(セグメントタイムラインと呼ぶ)に従う場合には、media_time_anchorもセグメントタイムラインに従って設定される。
このとき、セグメントタイムラインの基準となるセグメントを特定するためのインデックス番号などを、TEMIアクセスユニット、あるいは、TEMIアクセスユニットのストリームのPID(パケット識別子)を格納するPMT(Program Map Table)におけるデスクリプタなどに格納してもよい。なお、セグメントタイムラインを用いる場合には、セグメントタイムラインの時刻がゼロとなる時刻に一致する、参照元のタイムラインにおける時刻を予め取得しておく必要がある。
MPEG2−TS、MMT、あるいは、RTP(Real−time Transport Protocol)など、基準クロックが規定されるフォーマットの場合には、使用される基準クロックに従ってmedia_time_anchorの値が設定される。MPEG2−TSではPCRによって基準クロックが規定され、MMTおよびRTPではNTP(Network Time Protocol))によって基準クロックが規定される。
図3は、本実施の形態における上述の送信装置の構成を示すブロック図である。
本実施の形態における上述の送信装置100は、参照元TM決定部101、不連続判定部102、識別情報設定部103、不連続設定部104、および通常設定部106を備える。
参照元TM決定部101は、参照元の時刻T_orgを決定する。不連続判定部102は、参照元のタイムラインに不連続が発生したか否かを判定する。識別情報設定部103は、上述のタイミング更新識別情報id1であるis_timing_updateを設定する。不連続設定部104は、両タイムラインの対応関係が更新された場合に、その更新後の対応関係に応じた、参照先のタイムラインの時刻T_refをTEMIアクセスユニットに設定する。通常設定部106は、両タイムラインの対応関係が更新されていない場合に、これまで使われていた対応関係に応じた、参照先のタイムラインの時刻T_refをTEMIアクセスユニットに設定する。
図4は、本実施の形態における送信装置100の処理動作の例を示すフローチャートである。
なお、図4では、参照元のストリームがMPEG2−TSによって送信される場合を例にあげて説明する。
まず、送信装置100の参照元TM決定部101は、参照元のタイムラインの時刻T_orgを決定して、TEMIアクセスユニットを格納するPESパケットのヘッダに格納する(ステップS101)。
次に、不連続判定部102は、直前のTEMIアクセスユニットが送信されたとき以降に、基準クロックであるPCRに不連続が発生したかどうかを判定する(ステップS102)。PCRに不連続が発生したと判定された場合には(ステップS102の「はい」)、識別情報設定部103は、TEMIアクセスユニットにおけるis_timing_updateのフラグを1にセットする(ステップS103)。そして、不連続設定部104は、基準クロックの切り替わり後における時刻オフセットを算出し、その時刻オフセットに基づいて、参照先のタイムラインの時刻T_ref(media_time_anchor)を設定する(ステップS104)。
一方、PCRに不連続が発生していないと判定された場合には(ステップS102の「いいえ」)、識別情報設定部103は、TEMIアクセスユニットにおけるis_timing_updateのフラグを0にセットする(ステップS105)。そして、通常設定部106は、これまで使われていた時刻オフセットに基づいて、参照先のタイムラインの時刻T_ref(media_time_anchor)を設定する(ステップS106)。
不連続判定部102は、PCRを生成する手段から、そのPCRを直接取得してもよいし、PCRを格納するTSパケットを解析してもよい。後者の場合には、TSパケットのヘッダにおいてPCRの不連続が発生したかどうかを示すフィールド(discontinuity_indicator)が1にセットされていれば、不連続判定部102は不連続が発生したと判定する。あるいは、discontinuity_indicatorが不連続の発生に先立って連続的に1に設定される場合には、その値が1である最終のTSパケットにおいて更新後のPCRの値が格納される。したがって、不連続判定部102は、その最後のTSパケットを受けた場合に不連続が発生したと判定してもよい。
送信装置100は、参照元のストリームに多重化されるオーディオまたはビデオのアクセスユニット(以下、AVアクセスユニットという)毎にTEMIアクセスユニットを送信してもよいし、送信間隔が所定値以下となるように周期的にTEMIアクセスユニットを送信してもよい。
AVアクセスユニット毎にTEMIアクセスユニットを送信する際には、送信装置100は、TEMIアクセスユニットを格納するPESパケットのヘッダのPTSが、AVアクセスユニットのPTSと等しくなるように、そのPESパケットのヘッダのPTSを設定してもよい。
このとき、送信装置100は、TEMIアクセスユニットを、そのTEMIアクセスユニットに対応するAVアクセスユニットよりも時間的に前に送信してもよい。これにより、受信装置は、AVアクセスユニットの取得に先立って、そのAVアクセスユニットのPTSに対応する参照先のタイムラインの時刻を取得することができる。
また、送信装置100は、周期的にTEMIアクセスユニットを送信する際にも、TEMIアクセスユニットを格納するPESパケットのPTSが、AVアクセスユニットのPTSと等しくなるように、そのPESパケットのPTSを設定してもよい。さらに、送信装置100は、参照元と参照先のタイムラインの対応関係が更新された場合には、次のTEMIアクセスユニットの送信のタイミングまで待たずに、更新直後のAVアクセスユニットのPTSに対応するTEMIアクセスユニットを送信してもよい。
参照元のストリームを送信する送信装置100は、図示しない手段によって、参照先のストリームを送信する送信装置から、参照先のタイムラインの情報を取得してもよい。例えば、参照元のコンテンツが本編とCM(コマーシャル)を含み、参照先のコンテンツが、参照元の本編と同期再生される本編のみを含む場合には、参照元のコンテンツのCMが再生される区間では、参照先のコンテンツの再生を停止しておくことが望まれる。このような場合には、送信装置100は、参照元のタイムラインのみを進めて、参照先のタイムラインを停止させてもよい。
つまり、送信装置100は、CMの再生区間においては、時刻T_orgを更新するが、CMの生成区間に入る直前の時刻T_refの値を、それ以降の時刻T_refに設定し続ける。CMの再生区間の終了後は、送信装置100は、通常通り、時刻T_orgと時刻T_refを共に更新する。このとき、送信装置100は、参照元のストリームにおけるAVアクセスユニット毎に、それらのPTSに対応付けられたTEMIアクセスユニットを送信するのが望ましい。さらに、送信装置100は、参照先、あるいは、参照先のタイムラインが停止していることを示す識別情報を、TEMIアクセスユニットに格納してもよい。あるいは、送信装置100は、参照先のタイムラインを停止させずに、CMの再生区間において、参照先のコンテンツに無再生区間を挿入してもよい。例えば、送信装置100は、MP4における“empty edit”の機能などを用いて無再生区間を生成することができる。本方法は、CMに限らず、参照元と参照先において、同期再生の対象とならない区間が存在する場合に適用できる。
このように、本実施の形態における送信方法は、画像または音声のコンテンツに関する第1のストリームを送信する送信方法であって、例えば上述の図2に示すis_timing_updateなどのタイミング更新識別情報id1と、第1の時刻(上述の時刻T_orgに相当)と、第2の時刻(上述の時刻T_refに相当)とを含む第1のストリームを送信する。タイミング更新識別情報id1は、第1のストリームの送受信に用いられる第1の基準クロックと、その第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとの間の、対応関係が更新されたか否かを示す。また、第1の時刻は、第1の基準クロックにおける時刻であり、第2の時刻は、更新後の対応関係に基づいて第1の時刻に対応付けられた第2の基準クロックにおける時刻である。
これにより、タイミング更新識別情報id1が受信装置に送信される。したがって、受信装置は、第1の基準クロックと第2の基準クロックとの間の対応関係が更新されたか否かを、第1の時刻と第2の時刻とを用いた解析によって判定することなく、そのタイミング更新識別情報id1のみに基づいて簡単にその判定を行うことができる。その結果、受信装置は、更新されたと判定したときにのみ、第1の時刻と第2の時刻を用いて、更新後の対応関係を特定すればいいため、受信装置の処理量を抑えることができる。したがって、タイムライン拡張を効率的に行うことができる。
また、本実施の形態における送信方法は、さらに、上述の対応関係が更新されたか否かを判定し、判定の結果を示すタイミング更新識別情報id1を生成する。また、上述の対応関係が更新されたか否かの判定では、図4のステップS102に示すように、第1の基準クロックによって示される時刻の変化に不連続な変化があったか否かを判定し、不連続な変化があったと判定したときには、対応関係が更新されたと判定する。また、第1の基準クロックは、例えば、MPEG2−TSにおけるPCRである。また、本実施の形態における送信方法は、対応関係が更新されたと判定したときには、図4のステップS104に示すように、第1の基準クロックと第2の基準クロックとの間の、更新後の対応関係に応じたオフセット値(つまり、時刻オフセット)を算出する。さらに、第1の時刻と、算出された前記オフセット値とに基づいて特定される第2の時刻を、第1のストリームに含める。具体的には、第1のストリームにおけるTEMIアクセスユニットに、タイミング更新識別情報id1および第2の時刻を格納し、TEMIアクセスユニットを格納するPESパケットのヘッダに、第1の時刻を格納する。
図5は、本実施の形態における上述の受信装置の構成を示すブロック図である。
受信装置200は、TEMI_AU取得部201、初期状態判定部202、更新判定部203、および時刻同期部204を備える。
TEMI_AU取得部201は、TEMIアクセスユニットを取得する。初期状態判定部202は、コンテンツの復号を開始する前に、両タイムラインの同期が完了しているか否かを判定する。更新判定部203は、両タイムラインの対応関係が更新されたか否かを判定する。時刻同期部204は、両タイムラインに対して後述する時刻同期処理を行う。
図6は、本実施の形態における受信装置200の処理動作の例を示すフローチャートである。
まず、受信装置200のTEMI_AU取得部201は、TEMIアクセスユニットを取得する(ステップS201)。次に、初期状態判定部202は、コンテンツの復号を開始するに先立って、参照元のタイムラインと参照先のタイムラインの同期が完了しているかどうかを判定する(ステップS202)。なお、コンテンツの復号を開始するときには、参照元と参照先のタイムラインの同期が必須である。
ステップS202において、同期が完了していると判定されたときには(ステップS202の「はい」)、更新判定部203は、TEMIアクセスユニットにおいて、参照元と参照先のタイムラインの対応関係が更新されたことを示すタイミング更新識別情報id1(is_timing_update=1)がセットされているか否かを判定する(ステップS203)。
ステップS202において、同期が完了していないと判定されたとき(ステップS202の「いいえ」)、または、ステップS203において、セットされていると判定されたときには(ステップS203の「はい」)、時刻同期部204は、参照元と参照先のタイムラインに対して時刻同期処理を行う。
時刻同期処理とは、参照元のタイムラインと参照先のタイムラインとの間の時刻を対応付けることである。例えば、参照元のタイムラインにおける時刻T_orgと、参照先のタイムラインにおける時刻T_refとが対応する場合、時刻同期部204は、以下の(式1)によって、参照元のタイムラインにおける任意の時刻t1を、参照先のタイムラインにおける時刻t2に対応付ける。
t2=t1×(timescale2/timescale1)+(T_ref−(T_org×timescale2/timescale1))・・・(式1)
受信装置200は、上記(式1)に基づいて、参照元のストリームにおけるアクセスユニットと、参照先のストリームにおけるアクセスユニットとを同期させて再生する。
受信装置200は、タイムラインの対応関係が更新された場合だけでなく、更新されていない場合にも、ステップS204における時刻同期処理を行ってもよい。例えば、周期的に時刻同期処理を行ってもよい。
また、TEMIアクセスユニットにタイミング更新識別情報id1が格納されない場合には、受信装置200は、基準クロックが更新されたかどうかを別の方法により判定し、更新されたと判定した場合には、上述の時刻同期処理を行ってもよい。
例えば、参照元のストリームがMPEG2−TSによって送信されていれば、受信装置200は、PCRを格納するTSパケットのdiscontinuity_indicatorの値に基づいて、基準クロックの更新(不連続)を判定する。そして、受信装置200は、不連続が発生したと判定した場合には、上述の時刻同期処理を行う。あるいは、受信装置200は、基準クロックの更新などを判定せずに、周期的にTEMIアクセスユニットを取得して上述の時刻同期処理を行ってもよい。
このように、本実施の形態における受信方法は、画像または音声のコンテンツに関する第1のストリームを受信する受信方法であって、例えば上述の図2に示すis_timing_updateなどのタイミング更新識別情報id1と、第1の時刻(上述の時刻T_orgに相当)と、第2の時刻(上述の時刻T_refに相当)とを含む第1のストリームを受信する。タイミング更新識別情報id1は、第1のストリームの送受信に用いられる第1の基準クロックと、その第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとの間の、対応関係が更新されたか否かを示す。また、第1の時刻は、第1の基準クロックにおける時刻であり、第2の時刻は、更新後の対応関係に基づいて第1の時刻に対応付けられた第2の基準クロックにおける時刻である。
これにより、タイミング更新識別情報id1が受信装置200に受信される。したがって、受信装置200は、第1の基準クロックと第2の基準クロックとの間の対応関係が更新されたか否かを、わざわざ第1の時刻と第2の時刻とを用いた解析によって判定することなく、そのタイミング更新識別情報id1のみに基づいて簡単にその判定を行うことができる。その結果、受信装置は、更新されたと判定したときにのみ、第1の時刻と第2の時刻を用いて、更新後の対応関係を特定すればいいため、処理量を抑えることができる。したがって、タイムライン拡張を効率的に行うことができる。
つまり、本実施の形態における受信方法は、図6のステップS203に示すように、第1のストリームに含まれるタイミング更新識別情報id1に基づいて、上述の対応関係が更新されたか否かを判定する。そして、更新されたと判定されたときには、図6のステップS204に示すように、時刻同期処理を行う。つまり、第1のストリームに含まれる第1の時刻と第2の時刻とに基づいて、更新された対応関係を特定する。そして、更新された対応関係に基づいて、第1のストリームに関するコンテンツと、第2のストリームに関するコンテンツとを同期させて再生する。また、更新された対応関係の特定では、例えば、第1および第2の基準クロックのタイムスケールをそれぞれTs1,Ts2とし、第1および第2の時刻をそれぞれT_org,T_refとし、第1の基準クロックにおける任意の時刻をtとして表す。この場合、t×(Ts2/Ts1)+(T_ref−(T_org×Ts2/Ts1))によって算出される第2の基準クロックにおける時刻に、第1の基準クロックにおける時刻tを対応付けることによって、更新された対応関係を特定する。なお、Ts1,Ts2は、上記(式1)におけるtimescale1,timescale2に相当する。
(変形例1)
以下、本実施の形態における変形例について説明する。
送信装置100は、TEMIアクセスユニットのaddon_locationに、コンテンツの管理情報を取得するためのアクセス情報(URLなど)を記述してもよい。管理情報は、例えば、MPEG−DASHにおけるMPD(Media Presentation Description)、またはMMTにおけるパッケージの構成情報(パッケージを構成するアセットや、アセットを取得するためのURLなど)などである。
例えば、参照先のストリームがMPEG−DASHにしたがって送信される場合には、受信装置200は、まず、TEMIアクセスユニットのaddon_locationから、MPEG−DASHのMPDにアクセスするためのURLを取得する。そして、受信装置200は、そのURLにアクセスしてMPDを取得した上で、MPEG−DASHのコンテンツの取得を開始する。
また、参照先のストリームがRTPにしたがって送信される際には、ビデオまたはオーディオの1つの符号化データが1つのRTPストリームによって送信されるのが一般的である。従って、送信装置100は、ビデオまたはオーディオなど複数のRTPストリームをまとめたコンテンツの管理情報にアクセスするためのURLを記述してもよい。
あるいは、参照元のストリームがMPEG2−TSにしたがって送信される場合には、送信装置100は、TEMIアクセスユニットのストリームのPIDが示されるPMTのデスクリプタなどを利用して、参照先のコンテンツの管理情報を格納してもよい。このとき、送信装置100は、has_locationのフラグを0にセットして、addon_locationを格納せずに、PMTを参照して参照先のコンテンツの管理情報を格納してもよい。
送信装置100は、PMTの第2ループにおいて、TEMIアクセスユニットに関連するデスクリプタとして管理情報を格納してもよい。あるいは、送信装置100は、PMTの第1ループのデスクリプタにおいて、参照先のコンテンツの有無を示す情報を格納し、参照先のコンテンツが存在する場合には、第2ループにおいて、参照先のコンテンツの管理情報を格納してもよい。
また、参照元のコンテンツと参照先のコンテンツに依存関係がある場合には、送信装置100は、依存関係を示す情報を、TEMIアクセスユニットの情報が示されるPMTに格納してもよい。参照元のコンテンツがMPEG2−TSにしたがって送信される場合、参照元のコンテンツとTEMIアクセスユニットのPIDなどが、同一PMTによって示される。例えば、参照先のコンテンツが参照元のコンテンツの拡張データを含む場合、拡張データを復号することで、時間(フレームレートなど)、空間(解像度など)、およびビット深度などを拡張することができる。具体的には、フレームレートを60fpsから120fpsに増加したり、解像度を1920x1080pixelから3840x2160pixelに上げることができる。このような場合には、参照先のコンテンツが拡張データであり、送信装置100は、どのようなタイプの拡張ができるかを示す情報をPMTに格納してもよい。また、送信装置100は、参照元のコンテンツと参照先のコンテンツにおける、互いの表示位置を示す情報などをPMTに格納してもよい。
あるいは、参照元のコンテンツにおける特定のデータと、参照先のコンテンツとが依存関係を持つ場合には、送信装置100は、どのデータが依存関係を持つかを示す情報をPMTに格納してもよい。例えば、参照元のコンテンツがオーディオとビデオを含み、参照先のコンテンツは参照元のコンテンツのビデオに対応する字幕データを含む。このとき、送信装置100は、参照元のコンテンツのビデオと参照先のコンテンツとが関連することを示してもよい。つまり、送信装置100は、ビデオを格納するTSパケットのPIDと、TEMIアクセスユニットを格納するTSパケットのPIDとを関連付ける。あるいは、送信装置100は、参照先のコンテンツの管理情報において、対応するデータとして、関連するビデオを格納するTSパケットのPIDを示してもよい。
上記に示すような情報は、addon_locationに従って取得される参照先のコンテンツの管理情報に格納されてもよい。
受信装置200は、上記に示す情報に基づいて、コンテンツの管理情報、あるいは、参照元と参照先のコンテンツの依存関係などを取得して、それらのコンテンツを再生する。
(変形例2)
図7A〜図7Cは、本変形例に係るTEMIアクセスユニットのシンタックスを示す図である。
TEMIアクセスユニットは、図7Aに示すように、デスクリプタ(temi_descriptor)を含む。このデスクリプタ(temi_descriptor)は、図7Bに示すタイムラインデスクリプタ(temi_timeline_descriptor)と、図7Cに示すロケーションデスクリプタ(temi_location_descriptor)とを含む。
図7Bに示すタイムラインデスクリプタは、両タイムラインの対応関係を示すためのデスクリプタであり、参照先のタイムラインに関する情報を含む。上述のタイミング更新識別情報id1であるis_timing_updateは、このタイムラインデスクリプタに格納される。
図7Cに示すロケーションデスクリプタは、参照先のコンテンツのロケーションに関する情報を示すためのデスクリプタである。
つまり、TEMIアクセスユニットには、参照元のMPEG2−TSにより送信されるコンテンツと参照先のコンテンツとのタイムラインの対応関係、および、参照先のコンテンツのロケーション情報が、それぞれ異なるデスクリプタの形式として記述されている。
以下に、ロケーションデスクリプタにおける特徴的な要素について説明する。force_reloadは、参照先のコンテンツの実体データ、またはコンテンツの管理情報を再度取得する必要があるかどうかを示すフラグである。その管理情報は、参照先とされるMPEG−DASHのMPDのような、コンテンツの管理情報である。
is_announcementは、参照先のコンテンツが取得可能であるかどうかを示すフラグである。このフラグが1にセットされると、timescaleが示されるとともに、time_before_activationにおいて、参照先のコンテンツが取得可能となるまでの時間が示される。
addon_locationは、参照先のコンテンツの場所を示すロケーション情報(例えばURL)である。
splicing_flagは、コンテンツのつなぎ合わせを指示するためのスプライシング識別情報であって、参照先のコンテンツの再生および停止を示すフラグである。つまり、このフラグが1にセットされると、このフラグがセットされていないデスクリプタにおいて示される参照先のコンテンツの再生が中断され、このフラグがセットされているデスクリプタにおいて示される参照先のコンテンツが再生される。例えば、ロケーションデスクリプタAでは、splicing_flag=0がセットされ、かつ、参照先のコンテンツAが示されている。また、ロケーションデスクリプタBでは、splicing_flag=1がセットされ、かつ、参照先のコンテンツBが示されている。ここで、受信装置200は、参照先のコンテンツAを再生している状態で、ロケーションデスクリプタBを受信すると、参照先のコンテンツAの再生を中断して、参照先のコンテンツBを再生する。受信装置200は、参照先のコンテンツBの再生が終了した後には、参照先のコンテンツAの再生を再開する。
media_timestampまたはnptなどは、上述のmedia_time_anchorに相当し、参照先のタイムラインにおける時刻T_refを示す。
次に、上述のTEMIアクセスユニットを含むストリーム(以下、TEMIストリームという)におけるランダムアクセスについて説明する。
図8Aは、受信装置200により行われるランダムアクセスを説明するための図である。受信装置200は、ロケーションデスクリプタを取得して解析し、参照先のコンテンツを取得して再生する。具体的には、受信装置200は、図8Aに示すように、時刻T0においてロケーションデスクリプタAを取得して、そのロケーションデスクリプタAに示されるコンテンツAの再生を開始する。続いて、受信装置200は、時刻T1においてロケーションデスクリプタBを取得する。ロケーションデスクリプタBには、splicing_flagが1にセットされている。したがって、受信装置200は、コンテンツAの再生を中断して、ロケーションデスクリプタBに示されるコンテンツBの再生を開始する。コンテンツBの再生区間であるスプライス区間は、時刻T2で終了する。したがって、受信装置200は、時刻T2の後、コンテンツAの再生を再開する。
なお、ロケーションデスクリプタAは時刻T0から周期的に送信され、ロケーションデスクリプタBは時刻T1から周期的に送信されている。また、スプライス区間は、splicing_flagが1にセットされているロケーションデスクリプタによって示されるコンテンツが再生される区間である。
ここで、受信装置200は、ランダムアクセスを行う。例えば、受信装置200は、ロケーションデスクリプタBが送信されている時刻Tから受信を開始する。このとき、受信装置200は、ロケーションデスクリプタBを受信する。その結果、受信装置200は、コンテンツBから再生を開始する。しかしながら、この場合には、受信装置200は、ロケーションデスクリプタAを受信していないため、コンテンツBの再生終了後に再生を再開すべきコンテンツを特定することができない。
そこで、本変形例では、送信装置100は、スプライス区間の直後に再生されるコンテンツを示すロケーションデスクリプタを、スプライス区間の終了時刻、あるいは、終了時刻以前に送信する。これにより、受信装置200は、splicing_flagが1にセットされたロケーションデスクリプタの直前に送出されたロケーションデスクリプタを取得できていない場合であっても、スプライス区間の終了後に、再生を再開すべき元のコンテンツを特定して再生することができる。
図8Aに示す例では、送信装置100は、時刻T2においてロケーションデスクリプタAを再送する。送信装置100は、スプライス区間の終了時刻よりも前にロケーションデスクリプタAを送信する場合には、is_announcementのフラグを1にセットして、コンテンツAが時刻T2から取得可能であることをそのロケーションデスクリプタAに示してもよい。is_announcementは、本来、コンテンツが取得可能となる時刻を示すフラグであるが、スプライス区間の後に再生を再開する参照先のコンテンツの再生開始時刻を示してもよい。再生が開始されるアクセスユニットは、参照先のコンテンツ内のアクセスユニット毎のDTS(Decoding Time Stamp)あるいはPTSに基づいて決定される。
ここで、参照元と参照先のタイムラインが異なる場合は、受信装置200は、temi_timeline_descriptorから取得したタイムラインの同期情報(例えば、timescaleおよびmedia_timestampなど)に基づいて、両タイムラインの時刻同期処理を行う。また、送信装置100は、再送されるロケーションデスクリプタにおいて、force_reloadのフラグを0にセットしておいてもよい。これにより、既にロケーションデスクリプタAを取得済みの受信装置200は、再送されたロケーションデスクリプタAを受信した場合には、参照先のコンテンツを再度取得する必要がないと判断することができる。
なお、送信装置100は、スプライス区間の直後に再生されるコンテンツであることを示す情報、あるいは、ロケーションデスクリプタの内容が既に送信済みの内容であることを示す情報を、再送されるロケーションデスクリプタ内に格納してもよい。また、送信装置100は、TEMIストリームの属性を示すデスクリプタなどに、より有意義な情報を示してもよい。この有意義な情報は、任意のTEMIアクセスユニットから受信が開始された場合であっても、受信が開始されたTEMIアクセスユニットにより示される参照先のコンテンツと、時間的に後続となる参照先のコンテンツとが、ロケーションデスクリプタが再送さることによって一意に決定できることを示す情報である。
図8Aに示す例は、ロケーションデスクリプタの取得直後から参照先のコンテンツの再生が開始できる理想的な例である。しかし、実際には、ロケーションデスクリプタの取得後にコンテンツを取得して再生を開始するまでには、通信ネットワークの帯域や輻輳状況などに依存してタイムラグが発生する。
図8Bは、タイムラグを考慮した場合の送信装置100および受信装置200の処理動作を説明するための図である。
例えば、受信装置200は、時刻T0においてロケーションデスクリプタAを取得した場合に、コンテンツAの再生を時刻S0から開始する。また、送信装置100は、ロケーションデスクリプタが取得されてから参照先のコンテンツの再生が開始されるまでにかかるタイムラグを考慮して、ロケーションデスクリプタを送信してもよい。つまり、送信装置100は、参照先のコンテンツにおける先頭アクセスユニットのDTSあるいはPTSに相当する時刻に先立って、temi_location_descriptorの送信を開始する。例えば、参照先のコンテンツの先頭アクセスユニットのDTSが、参照元のMPEG2−TSにおけるPCRの値に換算した場合に、1000000であり、タイムラグが600000であったとする。この場合、送信装置100は、PCRの値が400000に相当する時刻、あるいは、それ以前に、temi_location_descriptorを送信する。これにより、受信装置200において時刻1000000から参照先のコンテンツを再生することが保証できる。
次に、上述のTEMIアクセスユニットを含むTEMIストリームにおけるランダムアクセスポイントについて説明する。
受信装置200では、参照先のコンテンツに関する情報を取得することが可能である必要があり、具体的には、放送における選局、または、通信における受信開始動作の直後にその必要がある。例えば、放送の場合には、受信装置200は、受信される番組のPMTにより示されるTEMIストリームのPIDを取得してから、TEMIストリームの受信を開始する。したがって、送信装置100は、TEMIアクセスユニットにおけるタイムラインデスクリプタおよびロケーションデスクリプタを、放送におけるMPEG2−TSのPMTなどと同様に、周期的に送信することが望ましい。
ロケーションデスクリプタは、その内容が更新された場合にのみ、受信装置200に送信されればよい。これは、TEMIアクセスユニットを受信する度に、同じ内容のロケーションデスクリプタを解析することは、受信装置200における処理負荷の増大に繋がるためである。
タイムラインデスクリプタは、受信装置200において参照元のコンテンツと参照先のコンテンツのタイムラインが同期される頻度に依存して送信されればよく、基本的にはPCRの不連続が発生した場合にのみ送信されればよい。
そこで、送信装置100は、ロケーションデスクリプタの内容が更新されたことを受信装置200にシグナリングしてもよい。例えば、送信装置100は、ロケーションデスクリプタにバージョン番号を示すカウンタを設けることによってシグナリングする。あるいは、送信装置100は、TSパケットのヘッダにおけるrandom_access_indicatorをセットするなどによってシグナリングする。また、送信装置100は、TEMIアクセスユニットにおけるCRC_flag直後のreserved領域などに新規のフラグを設けてもよい。ここで、random_access_indicatorを用いる場合には、送信装置100は、random_access_indicatorを1にセットする。具体的には、送信装置100は、更新後のロケーションデスクリプタを含むTEMIアクセスユニットの先頭データを含むTSパケットのヘッダにおいてセットする。例えば、splicing_flagの値、force_reloadの値、あるいは、新規location_idの設定によって示される参照先のコンテンツなどが、ロケーションデスクリプタの内容として変更される。
このとき、受信装置200は、放送における選局直後に受信したTEMIアクセスユニットの内容に基づいて参照先のコンテンツを取得し、参照元のコンテンツと参照先のコンテンツのタイムラインの対応付けを行い、参照先のコンテンツを再生開始する。再生開始後は、受信装置200は、random_access_indicatorの値などに基づいてロケーションデスクリプタの内容が更新されたかどうかを判定し、内容が更新された場合には更新後の内容に基づいて参照先のコンテンツの切替えなどを行う。一方で、受信装置200は、TSパケットのヘッダのdiscontinuity_indicatorの値を監視して、PCRの不連続が発生したかどうかを判定する。受信装置200は、PCRの不連続が発生した場合には、TEMIアクセスユニット内のタイムラインデスクリプタを参照して、両タイムラインの対応付け(つまり同期)をやり直す。つまり、先頭のロケーションデスクリプタ、あるいは、内容が更新されてから最初に送信されるロケーションデスクリプタを含むTEMIアクセスユニットをランダムアクセスポイントとしてもよい。
また、TEMIアクセスユニットに、タイムラインデスクリプタとロケーションデスクリプタのいずれか一方のみが含まれ、受信装置200において取得したいデスクリプタが含まれないことがある。この場合は、受信装置200は、取得対象となるデスクリプタが含まれるTEMIアクセスユニットを受信することができるまで、TEMIアクセスユニットの取得を継続する。
なお、ランダムアクセスポイントは以下のように定義してもよい。
図8Aの例を用いて説明したように、スプライス区間におけるTEMIアクセスユニットから受信が開始されると、スプライス区間の直後に再生されるコンテンツを取得できない場合がある。つまり、任意のTEMIアクセスユニット(AU(i))から受信が開始された場合であって、AU(i)により示される参照先のコンテンツの直後に再生されるコンテンツを取得するための情報が、AU(i)よりも送信順が前のTEMIアクセスユニットにおいてのみ示される場合には、AU(i)はランダムアクセスポイントとはならない。したがって、AU(i)により示される参照先コンテンツの直後に再生するコンテンツを取得するための情報が、AU(i)よりも送信順が後のTEMIアクセスユニットに格納されるとき、そのAU(i)をランダムアクセスポイントとしてもよい。
図9は、本変形例に係る受信装置200の処理動作の例を示すフローチャートである。
まず、受信装置200は、選局直後に受信したTEMIアクセスユニットのタイムラインデスクリプタとロケーションデスクリプタとを解析する。これにより、受信装置200は、参照先のコンテンツを特定するとともに、参照先のコンテンツと参照元のコンテンツのタイムラインの対応付けに必要な情報を取得する(ステップS301)。次に、受信装置200は、参照先のコンテンツを受信して、参照先のコンテンツと参照元のコンテンツとの同期再生を開始する(ステップS302)。
次に、受信装置200は、ロケーションデスクリプタの内容が更新されたか否かを判定する(ステップS303)。ここで、更新されたと判定すると(ステップS303の「はい」)、受信装置200は、更新された内容に応じて、参照先のコンテンツを切り替えたり、参照先のコンテンツのURLの変更を行う。これにより、受信装置200は、更新後の参照先のコンテンツを取得する(ステップS304)。
次に、受信装置200は、PCRの不連続が発生したか否かを判定する(ステップS305)。ここで、発生したと判定すると(ステップS305の「はい」)、受信装置200は、タイムラインデスクリプタを参照して、参照元のコンテンツと参照先のコンテンツのタイムラインを再び同期する(ステップS306)。
なお、受信装置200は、ステップS303,S304を実行しなくてもよく、または、ステップS305,S306を実行しなくてもよい。つまり、受信装置200は、ステップS303,S304を含む処理と、ステップS305,S306を含む処理とのうち、何れか一方の処理のみを実行してもよい。
このように、本実施の形態における送信方法では、TEMIアクセスユニットは、タイムラインデスクリプタと、ロケーションデスクリプタとを有する。そして、タイムラインデスクリプタに、タイミング更新識別情報id1および第2の時刻を格納し、ロケーションデスクリプタに、第2のストリームに関するコンテンツの場所を示すロケーション情報(例えばURL)を格納する。そして、本実施の形態における送信方法は、さらに、第2のストリームに関するコンテンツの再生を中止して、第3のストリームに関するコンテンツの再生を開始させるためのスプライシング識別情報(例えばsplicing_flag)と、第3のストリームに関するコンテンツの場所を示すロケーション情報(例えばURL)とを含む他のロケーションデスクリプタを、上記ロケーションデスクリプタが送信された後に送信する。そして、第3のストリームに関するコンテンツの再生区間の終了時までに、上記ロケーションデスクリプタを再び送信する。例えば、上述のロケーションデスクリプタ、他のロケーションデスクリプタ、第2のストリームに関するコンテンツ、および第3のストリーム関するコンテンツは、それぞれ図8Aおよび図8Bに示す、ロケーションデスクリプタA、ロケーションデスクリプタB、コンテンツAおよびコンテンツBである。
一方、本実施の形態における受信方法は、さらに、コンテンツのつなぎ合せを指示するスプライシング識別情報(例えばsplicing_flag)と、第3のストリームに関するコンテンツの場所を示すロケーション情報とを含む第1のデスクリプタを受信したときには、第2のストリームに関するコンテンツの再生を中止して、第3のストリームに関するコンテンツの再生を開始する。さらに、第3のストリームに関するコンテンツの再生区間の終了時までに、第2のストリームに関するコンテンツの場所を示すロケーション情報を含む第2のデスクリプタを受信したときには、その再生区間の終了後に、第2のストリームに関するコンテンツの再生を再開する。例えば、上述の第1のデスクリプタ、第2のデスクリプタ、第2のストリームに関するコンテンツ、および第3のストリーム関するコンテンツは、それぞれ図8Aおよび図8Bに示す、ロケーションデスクリプタB、ロケーションデスクリプタA、コンテンツAおよびコンテンツBである。
これにより、上述の他のロケーションデスクリプタが上述の第1のデスクリプタとして受信装置に送信される。したがって、受信装置200は、他のロケーションデスクリプタに格納されているスプライシング識別情報に基づいて、第2のストリームに関するコンテンツの再生を中止して、第3のストリームに関するコンテンツを再生することができる。さらに、その第3のストリームに関するコンテンツの再生区間の終了までに、第2のストリームに関するコンテンツの場所を示すロケーション情報が格納されたロケーションデスクリプタが上述の第2のデスクリプタとして受信装置200に再送される。したがって、受信装置200は、その再生区間から第1のストリームの受信を開始した場合であっても、その再生区間の終了時には、次に再生すべきコンテンツを容易に特定して再生することができる。つまり、受信装置200は、その再生区間前から、参照元のストリームである第1のストリームの受信を開始していた場合と同様に、第3のストリームに関するコンテンツの前に再生されていた、元の第2のストリームに関するコンテンツの再生を再開することができる。
(変形例3)
ここで、スプライス区間における再生方法について説明する。
タイムライン拡張においては、受信装置は、1を示すsplicing_flagがセットされたtemi_location_descriptorを受信すると、それまで再生していたコンテンツの再生を中断する。そして、受信装置は、splicing_flagが1にセットされた参照先のコンテンツの再生を行う。しかしながら、参照先のコンテンツがMPEG−DASH、MMT、あるいは、MPEG2−TSなどによって送信される場合には、参照先のコンテンツにおけるアクセスユニットのDTSまたはPTSは、MPEG−DASHまたはMMTなどのストリームにおいて示されている。したがって、受信装置は、特にsplicing_flagがセットされた場合の動作を一意に決定することができない場合がある。
そこで、本変形例では、以下に示す送信方法および受信方法によって、スプライス区間において参照先のコンテンツを再生する動作を一意に決定することができる。ここで、MP4のようにアクセスユニットのDTSまたはPTSの絶対値が示されないフォーマットを相対時刻形式のフォーマットという。また、MPEG−DASHまたはMMTのようにアクセスユニットのDTSまたはPTSの絶対値が示されるフォーマットを、絶対時刻形式のフォーマットという。
相対時刻形式のフォーマットでは、参照先のコンテンツを示すtemi_location_descriptorを含むTEMIアクセスユニットを格納するPESパケットのヘッダに示されるDTSあるいはPTSが、参照先のコンテンツの先頭アクセスユニットの時刻情報として扱われる。この場合、受信装置200は、temi_location_descriptorを受信すると、対応するTEMIアクセスユニットを格納するPESパケットのヘッダ(DTSまたはPTS)に基づいて時刻情報を決定する。したがって、例えば、送信装置100は、PCRの値が90000となる時刻から、参照先のコンテンツの再生を開始させるときに、TEMIアクセスユニットを周期的に送信する場合には、PESパケットに含まれるヘッダのPTSの値を90000に設定する。
一方、絶対時刻形式のフォーマットでは、アクセスユニットの時刻情報は、各フォーマットにおける基準クロックに基づいた値として、フォーマット内のヘッダに示される。基準クロックは、MPEG−DASHまたはMMTではNTPの値であり、MPEG2−TSであればPCRの値となる。受信装置200は、アクセスユニットの時刻情報に従って、参照先のコンテンツを再生する。なお、図8Bに示す例を用いて説明したように、temi_location_descriptorを受信してから参照先のコンテンツを再生できるまでにタイムラグが存在する。この場合には、タイムラグに応じてDTSあるいはPTSを遅らせてもよい。また、相対時刻形式のフォーマットにおいてはタイムラインが存在しないため、temi_timeline_descriptorは不要である。
また、1を示すsplicing_flagがセットされた場合には、上記で説明した方法によってDTSまたはPTSを決定しなくてもよい。つまり、そのsplicing_flagがセットされたtemi_location_descriptorの受信時刻よりも後で、参照先のコンテンツが再生可能となった時点で再生を開始してもよい。このように、1を示すsplicing_flagがセットされたtemi_location_descriptorの受信時刻に基づいて参照先のコンテンツを再生するかどうかを示すフラグ情報を、デスクリプタ内に格納してもよい。
また、図7Cに示すシンタックスにおけるnb_addonsのフィールドの値を2以上に設定することで、参照先のコンテンツを複数指定することが可能である。このように指定される複数の参照先コンテンツを再生する方法には、(1)複数の参照先コンテンツを同時に再生する方法と、(2)複数の参照先コンテンツを格納順に1つずつ再生する方法とがある。したがって、(1)および(2)のどちらの方法で再生されるかを示す識別情報を、デスクリプタ内に格納してもよい。また、複数の参照先のコンテンツをグループ化して、グループ毎に(1)および(2)のどちらの方法で再生されるかを示す識別情報を、デスクリプタ内に格納してもよい。
(変形例4)
ここで、TEMIストリームの属性情報について説明する。
参照元のコンテンツと参照先のコンテンツの再生制御に関する以下のような情報を、TEMIストリームの属性情報として示してもよい。
参照先のコンテンツを通信ネットワーク経由で取得する際には、ネットワークの帯域または輻輳に依存して、受信を開始してから再生を開始できるまでの遅延が生じる。このため、参照元のコンテンツと参照先のコンテンツを同期再生するには、参照先のコンテンツが揃うまで参照元のコンテンツのデータをバッファリングして参照元のコンテンツの再生を遅延させる必要がある。
あるいは、受信装置200は、参照先のコンテンツにおける取得データの範囲を指定できる場合には、参照先のコンテンツのバッファリングに必要な時間を考慮して、参照先のコンテンツのうち、後のPTSを有するアクセスユニットから順に各アクセスユニットを取得する。例えば、受信装置200は、参照元のコンテンツにおいて再生開始するアクセスユニットのPTSよりも例えば10秒後のPTSを持つ、参照先のコンテンツにおけるアクセスユニットから、各アクセスユニットを順に取得する。これにより、受信装置200は、10秒後からは参照元と参照先の両コンテンツを同期再生することができる。
あるいは、(1)マルチビュー再生される場合、または(2)参照元のコンテンツが、スケーラブル符号化における基本レイヤとされ、参照先のコンテンツが拡張レイヤとされている場合などは、厳密な同期再生が要求される。しかし、これららのケースを除いては、参照元と参照先のコンテンツを同期せずにそれぞれ独立に再生することも可能である。そこで、それぞれの状況にあわせた再生モードをTEMIストリームの属性情報として示すことにより、受信装置200はその再生モードにしたがって参照元のコンテンツと参照先のコンテンツを適切に再生することができる。
また、TEMIストリームにおいて、temi_timeline_descriptorが含まれるかどうかを属性情報によって示してもよい。例えば、temi_location_descriptorが存在して、temi_timeline_descriptorが存在しない場合がある。このような場合に、参照先のコンテンツは存在するが、参照先のコンテンツと参照元のコンテンツとは同期再生する必要がないことをその属性情報によって示すことができる。あるいは、上述の場合には、参照先のコンテンツと参照元のコンテンツのタイムラインが同一であることを属性情報によって示してもよい。また、これらの情報をそれぞれ独立した識別情報により示してもよい。
temi_timeline_descriptorが存在する場合には、タイムラインのタイプを示す属性情報を示してもよい。タイムラインのタイプには、例えば、NTP(Network Time Protocol)、IETFのRFC5484において規定されるタイムコード、あるいは、メディア固有のタイムスタンプなどの3タイプがある。NTP、タイムコード、あるいは、メディア固有のタイムスタンプは、それぞれtemi_location_descriptorのhas_ntp、has_timecodeおよび、has_timestampの各フィールドにより示される。
さらに、上記の属性情報を格納するデスクリプタを規定して、PMTにおいてエレメンタリストリーム毎の属性を示す2ndループなどにそのデスクリプタを格納してもよい。
(変形例5)
TEMIアクセスユニットにおけるデスクリプタの格納順序は予め規定されていてもよい。例えば、参照先のコンテンツのタイムラインが変化しなければ、temi_timeline_descriptorのサイズは固定されている。したがって、temi_timeline_descriptor、temi_location_descriptorの順に各デスクリプタをTEMIアクセスユニットに格納する。これにより、TEMIアクセスユニットにおけるtemi_location_descriptorの開始位置は固定となる。したがって、temi_timeline_descriptorのtemi_descr_tagとtemi_descr_lengthを解析してtemi_location_descriptorの開始位置を決定する処理を省くことができ、受信装置200の処理を低減することができる。
また、temi_location_descriptorにおいてタイムラインの情報を示すフィールドの開始位置も固定となる。したがって、アクセスユニットの先頭から固定のバイトオフセットを加算した位置のデータを取得することで、デスクリプタを解析せずにタイムラインの情報を取得することができる。なお、temi_timeline_descriptorが常に存在することが保証されない場合には、受信装置200は、アクセスユニットにおける先頭デスクリプタのtemi_descr_tagの値を解析し、temi_location_descriptorが存在するかどうかを判定する。なお、TEMIアクセスユニットに格納される各デスクリプタ、及び、それらの格納順が固定であることを示すフラグを、TEMIストリームの属性情報としてデスクリプタなどに含めてもよい。
参照先のコンテンツのロケーション情報として、通信ネットワーク経由でそのコンテンツを取得する際に用いられるURLなどに加えて、放送におけるトランスポートストリームのPIDを指定してもよい。あるいは、参照先のコンテンツを参照元のコンテンツと別の放送チャネルで送信する際には、トランスポートストリームの識別番号などを更に指定してもよい。
以上、本発明の一態様に係る送信方法および受信方法について、実施の形態およびその変形例を用いて説明したが、本発明はこれらに限定されるものではない。
図10Aは、本発明の一態様に係る送信方法を示すフローチャートである。
この送信方法は、画像または音声のコンテンツに関する第1のストリームを送信する送信方法であって、ステップS11を含む。このステップS11では、タイミング更新識別情報と、第1の時刻と、第2の時刻とを含む第1のストリームを送信する。タイミング更新識別情報は、第1のストリームの送受信に用いられる第1の基準クロックと、その第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとの間の、対応関係が更新されたか否かを示す。第1の時刻は、第1の基準クロックにおける時刻である。第2の時刻は、更新後の対応関係に基づいて第1の時刻に対応付けられた第2の基準クロックにおける時刻である。
このような送信方法であっても、上記実施の形態の送信方法と同様の効果を奏することができる。
図10Bは、本発明の一態様に係る送信装置のブロック図である。
この送信装置10は、画像または音声のコンテンツに関する第1のストリームを送信する送信装置であって、送信部11を備える。この送信部11は、上述のタイミング更新識別情報と、第1の時刻と、第2の時刻とを含む第1のストリームを送信する。このような送信装置10であっても、上記実施の形態の送信装置100と同様の効果を奏することができる。
また、本発明は、上述の第1のストリームを生成するデータ生成方法またはデータ生成装置であってもよい。つまり、本発明のデータ生成方法またはデータ生成装置は、画像または音声のコンテンツに関する第1のストリームを生成する方法または装置であって、タイミング更新識別情報と、第1の時刻と、第2の時刻とを含む第1のストリームを生成する。また、本発明のデータ生成方法には、上記実施の形態およびその変形例に含まれる、送信以外の何れの処理動作が含まれていてもよく、本発明のデータ生成装置には、上記実施の形態およびその変形例に含まれる、送信を行う構成要素以外の何れの構成要素が含まれていてもよい。
図11Aは、本発明の一態様に係る受信方法を示すフローチャートである。
この受信方法は、画像または音声のコンテンツに関する第1のストリームを受信する受信方法であって、ステップS21を含む。このステップS21では、タイミング更新識別情報と、第1の時刻と、第2の時刻とを含む第1のストリームを受信する。タイミング更新識別情報は、第1のストリームの送受信に用いられる第1の基準クロックと、その第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとの間の、対応関係が更新されたか否かを示す。第1の時刻は、第1の基準クロックにおける時刻である。第2の時刻は、更新後の対応関係に基づいて第1の時刻に対応付けられた第2の基準クロックにおける時刻である。
このような受信方法であっても、上記実施の形態の受信方法と同様の効果を奏することができる。
図11Bは、本発明の一態様に係る受信装置のブロック図である。
この受信装置20は、画像または音声のコンテンツに関する第1のストリームを受信する受信装置であって、受信部21を備える。この受信部21は、上述のタイミング更新識別情報と、第1の時刻と、第2の時刻とを含む第1のストリームを受信する。このような受信装置20であっても、上記実施の形態の受信装置200と同様の効果を奏することができる。
なお、上記実施の形態およびその変形例において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPUまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の送信装置または受信装置などを実現するソフトウェアは、次のようなプログラムである。すなわち、このプログラムは、コンピュータに、図10Aまたは図11Aに示すフローチャートに含まれるステップを実行させる。
また、以下のような場合も本発明に含まれる。
(1)上記の各装置は、具体的には、マイクロプロセッサ、ROM、RAM、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。前記RAMまたはハードディスクユニットには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
(2)上記の各装置を構成する構成要素の一部または全部は、1個のシステムLSI(Large Scale Integration:大規模集積回路)から構成されているとしてもよい。システムLSIは、複数の構成部を1個のチップ上に集積して製造された超多機能LSIであり、具体的には、マイクロプロセッサ、ROM、RAMなどを含んで構成されるコンピュータシステムである。前記RAMには、コンピュータプログラムが記憶されている。前記マイクロプロセッサが、前記コンピュータプログラムにしたがって動作することにより、システムLSIは、その機能を達成する。
(3)上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なICカードまたは単体のモジュールから構成されているとしてもよい。前記ICカードまたは前記モジュールは、マイクロプロセッサ、ROM、RAMなどから構成されるコンピュータシステムである。前記ICカードまたは前記モジュールは、上記の超多機能LSIを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ICカードまたは前記モジュールは、その機能を達成する。このICカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
(4)本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、CD−ROM、MO、DVD、DVD−ROM、DVD−RAM、BD(Blu−ray(登録商標) Disc)、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
また、本発明は、前記コンピュータプログラムまたは前記デジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。
また、前記プログラムまたは前記デジタル信号を前記記録媒体に記録して移送することにより、または前記プログラムまたは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
(5)上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。
以上、一つまたは複数の態様に係る送信方法および受信方法について、実施の形態およびその変形例に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
本発明にかかる送信方法および受信方法は、タイムライン拡張を効率的に行うことができるという効果を奏し、例えば、ビデオデータおよびオーディオデータなどのメディアトランスポートを行う装置または機器に適用することができる。
10,100 送信装置
11 送信部
20,200 受信装置
21 受信部

Claims (15)

  1. 画像または音声のコンテンツに関する第1のストリームを送信する送信方法であって、
    前記第1のストリームの送受信に用いられる第1の基準クロックと、前記第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとのオフセットである対応関係が更新されたか否かを示すタイミング更新識別情報と、
    前記第1の基準クロックにおける第1の時刻と、
    更新後の前記対応関係に基づいて前記第1の時刻に対応付けられた前記第2の基準クロックにおける時刻である第2の時刻とを
    含む前記第1のストリームを送信する
    送信方法。
  2. 前記送信方法は、さらに、
    前記対応関係が更新されたか否かを判定し、
    判定の結果を示す前記タイミング更新識別情報を生成する
    請求項1に記載の送信方法。
  3. 前記対応関係が更新されたか否かの判定では、
    前記第1の基準クロックによって示される時刻の変化に不連続な変化があったか否かを判定し、不連続な変化があったと判定したときには、前記対応関係が更新されたと判定する
    請求項2に記載の送信方法。
  4. 前記第1の基準クロックは、MPEG2−TS(Moving Picture Experts Group−2 Transport Stream)におけるPCR(Program Clock Reference)である
    請求項3に記載の送信方法。
  5. 前記送信方法は、
    前記対応関係が更新されたと判定したときには、
    前記第1の基準クロックと前記第2の基準クロックとの間の、更新後の前記対応関係に応じたオフセット値を算出し、
    前記第1の時刻と、算出された前記オフセット値とに基づいて特定される前記第2の時刻を、前記第1のストリームに含める
    請求項2〜4の何れか1項に記載の送信方法。
  6. 前記第1のストリームにおけるTEMI(Timeline and External Media Information)アクセスユニットに、前記タイミング更新識別情報および前記第2の時刻を格納する
    請求項1〜5の何れか1項に記載の送信方法。
  7. 前記TEMIアクセスユニットを格納するPES(Packetized Elementary Stream)パケットのヘッダに、前記第1の時刻を格納する
    請求項6に記載の送信方法。
  8. 前記TEMIアクセスユニットは、タイムラインデスクリプタと、ロケーションデスクリプタとを有し、
    前記タイムラインデスクリプタに、前記タイミング更新識別情報および前記第2の時刻を格納し、
    前記送信方法は、さらに、
    前記ロケーションデスクリプタに、前記第2のストリームに関するコンテンツの場所を示すロケーション情報を格納する
    請求項6または7に記載の送信方法。
  9. 前記送信方法は、さらに、
    前記第2のストリームに関するコンテンツの再生を中止して、第3のストリームに関するコンテンツの再生を開始させるためのスプライシング識別情報と、前記第3のストリームに関するコンテンツの場所を示すロケーション情報とを含む他のロケーションデスクリプタを、前記ロケーションデスクリプタが送信された後に送信し、
    前記第3のストリームに関するコンテンツの再生区間の終了時までに、前記ロケーションデスクリプタを再び送信する
    請求項8に記載の送信方法。
  10. 画像または音声のコンテンツに関する第1のストリームを受信する受信方法であって、
    前記第1のストリームの送受信に用いられる第1の基準クロックと、前記第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとのオフセットである対応関係が更新されたか否かを示すタイミング更新識別情報と、
    前記第1の基準クロックにおける第1の時刻と、
    更新後の前記対応関係に基づいて前記第1の時刻に対応付けられた前記第2の基準クロックにおける時刻である第2の時刻とを
    含む前記第1のストリームを受信する
    受信方法。
  11. 前記受信方法は、さらに、
    前記第1のストリームに含まれる前記タイミング更新識別情報に基づいて、前記対応関係が更新されたか否かを判定し、
    更新されたと判定されたときには、前記第1のストリームに含まれる前記第1の時刻と前記第2の時刻とに基づいて、更新された前記対応関係を特定し、
    更新された前記対応関係に基づいて、前記第1のストリームに関するコンテンツと、前記第2のストリームに関するコンテンツとを同期させて再生する
    請求項10に記載の受信方法。
  12. 更新された前記対応関係の特定では、
    前記第1および第2の基準クロックのタイムスケールをそれぞれTs1,Ts2とし、前記第1および第2の時刻をそれぞれT_org,T_refとし、前記第1の基準クロックにおける任意の時刻をtとして表す場合、
    t×(Ts2/Ts1)+(T_ref−(T_org×Ts2/Ts1))によって算出される前記第2の基準クロックにおける時刻に、前記第1の基準クロックにおける時刻tを対応付けることによって、更新された前記対応関係を特定する
    請求項11に記載の受信方法。
  13. 前記受信方法は、さらに、
    コンテンツのつなぎ合せを指示するスプライシング識別情報と、第3のストリームに関するコンテンツの場所を示すロケーション情報とを含む第1のデスクリプタを受信したときには、前記第2のストリームに関するコンテンツの再生を中止して、前記第3のストリームに関するコンテンツの再生を開始し、
    前記第3のストリームに関するコンテンツの再生区間の終了時までに、前記第2のストリームに関するコンテンツの場所を示すロケーション情報を含む第2のデスクリプタを受
    信したときには、前記再生区間の終了後に、前記第2のストリームに関するコンテンツの再生を再開する
    請求項10〜12の何れか1項に記載の受信方法。
  14. 画像または音声のコンテンツに関する第1のストリームを送信する送信装置であって、
    前記第1のストリームの送受信に用いられる第1の基準クロックと、前記第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとのオフセットである対応関係が更新されたか否かを示すタイミング更新識別情報と、
    前記第1の基準クロックにおける第1の時刻と、
    更新後の前記対応関係に基づいて前記第1の時刻に対応付けられた前記第2の基準クロックにおける時刻である第2の時刻とを
    含む前記第1のストリームを送信する送信部を備える
    送信装置。
  15. 画像または音声のコンテンツに関する第1のストリームを受信する受信装置であって、
    前記第1のストリームの送受信に用いられる第1の基準クロックと、前記第1のストリームに関するコンテンツと同期して再生される他のコンテンツに関する第2のストリームの送受信に用いられる第2の基準クロックとのオフセットである対応関係が更新されたか否かを示すタイミング更新識別情報と、
    前記第1の基準クロックにおける第1の時刻と、
    更新後の前記対応関係に基づいて前記第1の時刻に対応付けられた前記第2の基準クロックにおける時刻である第2の時刻とを
    含む前記第1のストリームを受信する受信部を備える
    受信装置。
JP2014191896A 2013-10-11 2014-09-19 送信方法、受信方法、送信装置および受信装置 Active JP6510205B2 (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
CN201480037289.2A CN105359449B (zh) 2013-10-11 2014-10-06 发送方法、接收方法、发送装置以及接收装置
PCT/JP2014/005073 WO2015052908A1 (ja) 2013-10-11 2014-10-06 送信方法、受信方法、送信装置および受信装置
EP14853090.0A EP3057261B1 (en) 2013-10-11 2014-10-06 Transmission method, reception method, transmission device, and reception device
US15/007,042 US10368115B2 (en) 2013-10-11 2016-01-26 Transmitting method, receiving method, transmitting device, and receiving device
US16/430,740 US10945015B2 (en) 2013-10-11 2019-06-04 Transmitting method, receiving method, transmitting device, and receiving device
US17/167,174 US11849166B2 (en) 2013-10-11 2021-02-04 Transmitting method, receiving method, transmitting device, and receiving device
JP2021136752A JP7275212B2 (ja) 2013-10-11 2021-08-25 送信方法、受信方法、送信装置および受信装置
US18/386,727 US20240064359A1 (en) 2013-10-11 2023-11-03 Transmitting method, receiving method, transmitting device, and receiving device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361889728P 2013-10-11 2013-10-11
US61/889,728 2013-10-11

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2019072292A Division JP6737922B2 (ja) 2013-10-11 2019-04-04 送信方法、受信方法、送信装置および受信装置

Publications (2)

Publication Number Publication Date
JP2015076881A JP2015076881A (ja) 2015-04-20
JP6510205B2 true JP6510205B2 (ja) 2019-05-08

Family

ID=53001382

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2014191896A Active JP6510205B2 (ja) 2013-10-11 2014-09-19 送信方法、受信方法、送信装置および受信装置
JP2019072292A Active JP6737922B2 (ja) 2013-10-11 2019-04-04 送信方法、受信方法、送信装置および受信装置
JP2020122241A Active JP6935552B2 (ja) 2013-10-11 2020-07-16 送信方法、受信方法、送信装置および受信装置

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2019072292A Active JP6737922B2 (ja) 2013-10-11 2019-04-04 送信方法、受信方法、送信装置および受信装置
JP2020122241A Active JP6935552B2 (ja) 2013-10-11 2020-07-16 送信方法、受信方法、送信装置および受信装置

Country Status (4)

Country Link
US (3) US10368115B2 (ja)
EP (1) EP3057261B1 (ja)
JP (3) JP6510205B2 (ja)
CN (1) CN105359449B (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104184645B (zh) * 2013-05-27 2018-05-04 华为技术有限公司 一种生成操作请求的方法、设备及系统
JP6616064B2 (ja) 2013-07-25 2019-12-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 送信方法および受信方法
JP6506009B2 (ja) * 2013-11-22 2019-04-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 送信方法、受信方法、送信装置、及び受信装置
CN106464677A (zh) * 2014-04-09 2017-02-22 Lg电子株式会社 发送/接收广播信号的方法和设备
US9635407B2 (en) * 2014-10-16 2017-04-25 Samsung Electronics Co., Ltd. Method and apparatus for bottleneck coordination to achieve QoE multiplexing gains
US10085051B2 (en) * 2015-02-13 2018-09-25 Samsung Electronics Co., Ltd. Method and apparatus for converting MMTP stream to MPEG-2TS
CN113038188B (zh) * 2015-03-31 2023-06-06 松下电器(美国)知识产权公司 发送方法、接收方法、发送装置以及接收装置
CN107925784B (zh) 2015-08-06 2021-07-09 麦克赛尔株式会社 广播接收装置、输出影像信息生成方法、广播接收方法和录像方法
US10943271B2 (en) * 2018-07-17 2021-03-09 Xandr Inc. Method and apparatus for managing allocations of media content in electronic segments

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3462087B2 (ja) * 1998-06-17 2003-11-05 日本放送協会 デジタル放送送出装置及びデジタル放送のデータ構造
AU2002227260A1 (en) * 2000-11-06 2002-05-15 Excite@Home Integrated in-stream video ad serving
US7237250B2 (en) * 2000-11-28 2007-06-26 Navic Systems, Inc. Promotion server using video on demand channel
US7584491B2 (en) * 2001-04-25 2009-09-01 Sony Corporation System and method for managing interactive programming and advertisements in interactive broadcast systems
EP1499135A3 (en) * 2003-07-18 2006-04-12 Canon Kabushiki Kaisha Digital data multiplexing and demultiplexing
JP2007081780A (ja) * 2005-09-14 2007-03-29 Seiko Epson Corp 再生制御装置、表示装置および再生システム
WO2007091510A1 (ja) * 2006-02-07 2007-08-16 The Tokyo Electric Power Company, Incorporated コンテンツ配信システム
JP2007306363A (ja) * 2006-05-12 2007-11-22 Pioneer Electronic Corp デジタル放送受信装置
US20080165774A1 (en) * 2007-01-04 2008-07-10 Chien-Chung Huang Inter-network packet modifier and related method thereof
US8321593B2 (en) * 2007-01-08 2012-11-27 Apple Inc. Time synchronization of media playback in multiple processes
JP2009246712A (ja) * 2008-03-31 2009-10-22 Panasonic Corp デジタル放送受信装置
JP5489675B2 (ja) * 2009-11-27 2014-05-14 三菱電機株式会社 映像情報再生方法及びシステム、並びに映像情報コンテンツ
GB2481573A (en) * 2010-06-15 2012-01-04 Nds Ltd Splicng of encoded media content
JP5399984B2 (ja) 2010-06-23 2014-01-29 日本放送協会 送信装置、サーバ装置、および受信装置
KR101476934B1 (ko) * 2010-07-19 2014-12-30 엘지전자 주식회사 미디어 파일 송수신 방법 및 그를 이용한 송수신 장치
KR101831775B1 (ko) * 2010-12-07 2018-02-26 삼성전자주식회사 멀티미디어 컨텐츠를 송수신하는 송신 장치 및 수신 장치와, 그 재생 방법
KR20120084252A (ko) * 2011-01-19 2012-07-27 삼성전자주식회사 복수의 실시간 전송 스트림을 수신하는 수신 장치와 그 송신 장치 및 멀티미디어 컨텐츠 재생 방법
KR101946861B1 (ko) * 2011-09-21 2019-02-13 삼성전자주식회사 멀티미디어 방송 서비스의 미디어 데이터 동기화 방법 및 장치
KR101987756B1 (ko) * 2012-07-24 2019-06-11 삼성전자주식회사 미디어 재생 방법 및 미디어 장치

Also Published As

Publication number Publication date
JP2019169948A (ja) 2019-10-03
EP3057261A1 (en) 2016-08-17
US10945015B2 (en) 2021-03-09
JP6935552B2 (ja) 2021-09-15
US20190289355A1 (en) 2019-09-19
EP3057261A4 (en) 2016-09-28
JP2015076881A (ja) 2015-04-20
CN105359449A (zh) 2016-02-24
US20210160560A1 (en) 2021-05-27
US20160142757A1 (en) 2016-05-19
JP6737922B2 (ja) 2020-08-12
US11849166B2 (en) 2023-12-19
CN105359449B (zh) 2019-06-28
EP3057261B1 (en) 2019-03-13
US10368115B2 (en) 2019-07-30
JP2020188482A (ja) 2020-11-19

Similar Documents

Publication Publication Date Title
JP6935552B2 (ja) 送信方法、受信方法、送信装置および受信装置
JP6818848B2 (ja) 送信方法および受信方法
JP7036962B2 (ja) 再生方法および再生装置
JP6625684B2 (ja) 送信方法、受信方法、送信装置および受信装置
EP3041253B1 (en) Transmission method, receiving method, transmission device, and receiving device
JP2021122144A (ja) 再生装置およびコンテンツ送信装置
JP7453266B2 (ja) 送信装置
US20240064359A1 (en) Transmitting method, receiving method, transmitting device, and receiving device
JP2018182677A (ja) 情報処理装置、情報処理方法、プログラム、および記録媒体製造方法
JP6957186B2 (ja) 情報処理装置、情報処理方法、プログラム、および記録媒体製造方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170912

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181127

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190227

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190404

R150 Certificate of patent or registration of utility model

Ref document number: 6510205

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150