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

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

Info

Publication number
JP6696430B2
JP6696430B2 JP2016557731A JP2016557731A JP6696430B2 JP 6696430 B2 JP6696430 B2 JP 6696430B2 JP 2016557731 A JP2016557731 A JP 2016557731A JP 2016557731 A JP2016557731 A JP 2016557731A JP 6696430 B2 JP6696430 B2 JP 6696430B2
Authority
JP
Japan
Prior art keywords
transmission
mmtp
delivery
packet
information
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
JP2016557731A
Other languages
English (en)
Other versions
JPWO2016072343A1 (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.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Publication of JPWO2016072343A1 publication Critical patent/JPWO2016072343A1/ja
Priority to JP2020008852A priority Critical patent/JP6927338B2/ja
Application granted granted Critical
Publication of JP6696430B2 publication Critical patent/JP6696430B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H60/00Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/82Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04HBROADCAST COMMUNICATION
    • H04H20/00Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86Arrangements characterised by the broadcast information itself
    • H04H20/93Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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
    • 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/2362Generation or processing of Service Information [SI]
    • 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/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • 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/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • 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/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本技術は、送信装置、送信方法、受信装置および受信方法に関し、詳しくは、放送・通信のハイブリッドシステムに適用して好適な送信装置等に関する。
現在の放送システムでは、メディアのトランスポート方式として、MPEG−2 TS(Moving Picture Experts Group-2 Transport Stream)方式やRTP(Real Time Protocol)方式が広く使用されている(例えば、特許文献1を参照)。次世代のデジタル放送方式として、MMT(MPEG Media Transport)方式(例えば、非特許文献1参照)が検討されている。
特開2013−153291号公報
ISO/IEC DIS 23008-1:2013(E) Information technology-High efficiency coding and media delivery in heterogeneous environments-Part1:MPEG media transport(MMT)
本技術の目的は、放送・通信のハイブリッドサービスを良好に実現可能とすることにある。
本技術の概念は、
所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを生成する伝送ストリーム生成部と、
上記伝送ストリームを所定の伝送路を通じて送信する送信部と、
上記第2の伝送パケットに、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報を挿入する情報挿入部を備える
送信装置にある。
本技術において、伝送ストリーム生成部により、所定のコンポーネントを含む第1の伝送パケットおよびこの所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームが生成される。例えば、伝送パケットは、MMT(MPEG Media Transport)パケットである、ようにされてもよい。送信部により、この伝送ストリームが、所定の伝送路を通じて、受信側に送信される。例えば、所定の伝送路は、放送伝送路である、ようにされてもよい。
情報挿入部により、第2の伝送パケットに、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入される。例えば、プロトコル識別情報は、少なくともマルチキャスト配信、MMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれのプロトコルであるかを識別するための情報である、ようにされてもよい。
この場合、例えば、プロトコル識別情報がMMTP/UDP配信であることを示すとき、取得情報には、URLの他にUDPを指定するパラメータが含まれる、ようにされてもよい。また、この場合、例えば、プロトコル識別情報がMMTP/TCP配信であることを示すとき、取得情報には、URLの他にTCPを指定するパラメータが含まれる、ようにされてもよい。
このように本技術においては、第2の伝送パケットに、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入される。そのため、受信側では、この取得情報に基づいて、通信経路のコンポーネントを含む伝送パケットを有する伝送ストリームの受信を良好に行い得る。
なお、本技術において、例えば、取得情報に、パケット識別情報がさらに含まれる、ようにされてもよい。この場合、伝送ストリームに複数のコンポーネントの伝送パケットが多重化されていても、このパケット識別情報に基づいて所望のコンポーネントの伝送パケットを選択的に取得可能となる。
また、本技術の他の概念は、
所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを所定の伝送路を通じて受信する受信部を備え、
上記第2の伝送パケットには、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入されており、
上記ロケーション情報および上記プロトコル識別情報に基づき、ネットワークを通じて、所定のコンポーネントを含む第3の伝送パケットを有する伝送ストリームを上記プロトコル識別情報で示されるプロトコルで受信する通信部をさらに備える
受信装置にある。
本技術において、受信部により、所定のコンポーネントを含む第1の伝送パケットおよびこの所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームが所定の伝送路を通じて受信される。第2の伝送パケットには、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入されている。
通信部により、ロケーション情報およびプロトコル識別情報に基づいてサーバにリクエストすることで、このサーバからネットワークを通じて所定のコンポーネントを含む第3の伝送パケットを有する伝送ストリームがプロトコル識別情報で示されるプロトコルで受信される。例えば、プロトコル識別情報は、少なくともマルチキャスト配信、MMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれのプロトコルであるかを識別するための情報である、ようにされてもよい。
例えば、プロトコル識別情報がMMTP/UDP配信であることを示すとき、取得情報には、URLの他にUDPを指定するパラメータが含まれており、通信部は、URLおよびUDPを指定するパラメータを用いてサーバにリクエストすることで、このサーバからネットワークを通じて第3の伝送パケットを有する伝送ストリームをMMTP/UDP配信のプロトコルで受信する、ようにされてもよい。
また、例えば、プロトコル識別情報がMMTP/TCP配信であることを示すとき、取得情報には、URLの他にTCPを指定するパラメータが含まれており、通信部は、URLおよびTCPを指定するパラメータを用いてサーバにリクエストをすることで、このサーバからネットワークを通じてパラメータに対応した第3の伝送パケットを有する伝送ストリームをMMTP/TCP配信のプロトコルで受信する、ようにされてもよい。
また、例えば、プロトコル識別情報がMMTP/HTTP配信であることを示すとき、取得情報にはURLが含まれており、通信部は、URLおよびMPUシーケンス番号を示すパラメータを用いてサーバに順次リクエストを送信することで、このサーバからネットワークを通じてパラメータに対応したMPUシーケンス番号のMPUを含むMMTパケットを順次受信し、最初のリクエストにおけるMPUシーケンス番号を示すパラメータを、該最初のリクエストのタイミングのMPUシーケンス番号を表すものとする、ようにされてもよい。
また、例えば、プロトコル識別情報がMPU/HTTP配信であることを示すとき、取得情報にはURLが含まれており、通信部は、URLおよびMPUシーケンス番号を示すパラメータを用いてサーバに順次リクエストを送信することで、このサーバからネットワークを通じてパラメータに対応したMPUシーケンス番号のMPUを順次受信し、最初のリクエストにおけるMPUシーケンス番号を示すパラメータを、該最初のリクエストのタイミングのMPUシーケンス番号を表すものとする、ようにされてもよい。
このように本技術においては、第2の伝送パケットに挿入されて送られてくるロケーション情報およびプロトコル識別情報に基づいてサーバにリクエストすることで、このサーバからネットワークを通じて所定のコンポーネントを含む第3の伝送パケットを有する伝送ストリームがプロトコル識別情報で示されるプロトコルで受信される。そのため、通信経路のコンポーネントを含む伝送パケットを有する伝送ストリームの受信を良好に行い得る。
なお、本技術において、例えば、通信経路のコンポーネントの取得情報にはパケット識別情報がさらに含まれており、通信部は、受信された第3の伝送パケットを有する伝送ストリームから、パケット識別情報に基づいてこの第3の伝送パケットを抽出する、ようにされてもよい。この場合、伝送ストリームに複数のコンポーネントの伝送パケットが多重化されていても、このパケット識別情報に基づいて所望のコンポーネントの伝送パケットを選択的に取得可能となる。
また、本技術のさらに他の概念は、
所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを所定の伝送路を通じて受信する受信部を備え、
上記第2の伝送パケットには、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入されており、
上記受信部で受信された伝送ストリームを処理する処理部をさらに備える
受信装置にある。
本技術によれば、放送・通信のハイブリッドサービスを良好に実現できる。なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
実施の形態としての放送・通信ハイブリッドシステムの構成例を示すブロック図である。 MMT/放送の信号構成例のスタックモデルを示す図である。 MMT方式放送ストリームの構成例を示す図である。 放送送出システムから受信端末に送信される1つのチャンネル(放送番組)の放送信号のイメージを示す図である。 MMTパケットの構成例とMMTPペイロード(MMTP payload)の構成例を示す図である。 MMT/通信の信号構成例のスタックモデルを示す図である。 PAメッセージ(Package Access Message)およびMPテーブル(MPT:MMT Package Table)の構成例を概略的に示す図である。 PAメッセージの主要なパラメータの説明を示す図である。 MPテーブルの主要なパラメータの説明を示す図である。 PAメッセージの構造例(Syntax)を示す図である。 MPテーブル(MPT)の構造例(Syntax)を示す図である。 「MMT_general_location_info()」の構造例(Syntax)の一部を示す図である。 (A)マルチキャスト配信のプロトコルで配信されるアセットを受信する場合における受信シーケンスを説明するための図である。 (B)MMTP/UDP配信のプロトコルで配信されるアセットを受信する場合における受信シーケンスを説明するための図である。 (C)MMTP/TCP配信のプロトコルで配信されるアセットを受信する場合における受信シーケンスを説明するための図である。 (D)MMTP/HTTP配信のプロトコルで配信されるアセットを受信する場合における受信シーケンスを説明するための図である。 MMTP/HTTPの多重化ストリームにおける切り出し処理を説明するための図である。 (E)MPU/HTTP配信のプロトコルで配信されるアセットを受信する場合における受信シーケンスを説明するための図である。 放送送出システムの構成例を示すブロック図である。 受信端末の構成例を示すブロック図である。
以下、発明を実施するための形態(以下、「実施の形態」とする)について説明する。なお、説明を以下の順序で行う。
1.実施の形態
2.変形例
<1.実施の形態>
[放送・通信ハイブリッドシステムの構成例]
図1は、放送・通信ハイブリッドシステム10の構成例を示している。放送・通信ハイブリッドシステム10において、送信側には放送送出システム100および配信サーバ300が配置され、受信側には受信端末200が配置されている。配信サーバ300は、通信ネットワーク400を通じて受信端末200に接続される。
放送送出システム100は、ビデオ、オーディオなどのコンポーネント(アセット)を伝送メディアとして含むIP(Internet Protocol)方式の放送信号を送信する。配信サーバ300は、ビデオ、オーディオなどのコンポーネント(アセット)を伝送メディアとして含むIPパケットが連続的に配置された伝送ストリームを、例えば、受信側からの要求に応じ、通信ネットワーク400を通じて、受信側に配信する。
受信端末200は、放送送出システム100から送られてくるIP方式の放送信号を受信すると共に、配信サーバ300からIPパケットが連続的に配置された伝送ストリームを受信する。受信端末200は、このような放送・通信のハイブリッド伝送による受信信号から、提示すべきビデオ、オーディオなどの伝送メディア(コンポーネント)を取得し、画像、音声などを提示する。
IP方式の放送信号には、通信経路のコンポーネントの取得情報が挿入されている。この取得情報には、少なくともロケーション情報およびプロトコル識別情報が含まれている。受信端末200は、この取得情報に基づいて、配信サーバ300に要求し、プロトコル識別情報で示されるプロトコルで伝送ストリームの配信を受ける。
図2は、MMT/放送の信号構成例のスタックモデルを示している。下位レイヤにTLV(Type Length Value)の伝送パケットが存在する。このTLVの伝送パケットの上にIPパケットが載る。なお、伝送制御信号がシグナリング(Signaling)情報として載ったTLV伝送パケットも存在する。
IPパケットの上に、UDP(User Datagram Protocol)が載る。そして、UDPの上に、MMT(MPEG Media Transport)パケットが載る。このMMTパケットのペイロード部には、ビデオ、オーディオ等のコンポーネントの符号化データを含むMFU(MMT Fragment Unit)、あるいは伝送メディアに関する情報を含むシグナリングメッセージ(Signaling Message)が含まれる。
図3は、MMT方式放送ストリームの構成例を示している。図3(a)は、ビデオのエレメンタリストリーム(Video ES)を示している。このビデオのエレメンタリストリームは、所定の大きさの固まりに分割され、図3(b)に示すように、MFUのペイロード部に配置される。
図3(c)に示すように、MFUにMMTペイロードヘッダ(MMT payload header)が付加されてMMTPペイロード(MMTP payload)が構成される。そして、図3(d)に示すように、このMMTPペイロードにさらにMMTヘッダ(MMT header)が付加されて、MMTパケット(MMT packet)が構成される。なお、ペイロード部に、シグナリングメッセージ(Signaling Message)を含むMMTパケットも存在する。図3(e)に示すように、MMTパケットに、UDPヘッダ、IPヘッダおよびTLVヘッダが付加されて、MMT方式放送ストリームを構成するTLVパケット(TLV packet)が生成される。
なお、図示は省略されているが、TLVパケットとしては、さらに、オーディオなどのその他のコンポーネントのMMTパケットを含むTLVパケットも存在する。このMMT方式放送ストリームは、伝送メディア(コンポーネント)を含む第1のパケット(MMTパケット)と、シグナリング情報を含む第2のパケット(MMTパケット)を持つものとなる。
図4は、放送送出システム100から受信端末200に送信される1つのチャンネル(放送番組)の放送信号のイメージを示している。この放送信号には、ビデオ、オーディオなどのMMTパケットと共に、シグナリングメッセージを含むMMTパケットも含まれる。シグナリングメッセージとして、例えば、MPテーブル(MP table)などが含まれるPAメッセージ(PA message)が存在する。
図5(a)は、MMTパケットの構成例を示している。MMTパケットは、MMTパケットヘッダ(MMTP header)と、MMTPペイロード(MMTP payload)とからなる。「V」の2ビットフィールドは、MMTプロトコルのバージョンを示す。MMT規格第1版に従う場合、このフィールドは“00”とされる。「C」の1ビットフィールドは、パケットカウンタフラグ(packet_counter_flag)情報を示し、パケットカウンタフラグが存在する場合は“1”となる。「FEC」の2ビットフィールドは、FECタイプ(FEC_type)を示す。
「X」の1ビットフィールドは、拡張ヘッダフラグ(extension_flag)情報を示し、MMTパケットのヘッダ拡張を行う場合は“1”とされる。この場合、後述する「header_extension」のフィールドが存在する。「R」の1ビットフィールドは、RAPフラグ(RAP_flag)情報を示し、このMMTパケットが伝送するMMTペイロードがランダムアクセスポイントの先頭を含む場合は“1”とされる。
「type」の6ビットフィールドは、ペイロードタイプ(payload_type)情報であり、MMTPペイロードのデータタイプを示す。例えば、「0x00」はペイロードがMPU(Media Processing Unit)であることを示し、「0x02」はペイロードがシグナリングメッセージ(Signaling message)であることを示す。
「packet_id」の16ビットフィールドは、ペイロードのデータ種類を識別するためのパケット識別子(packet_id)を示す。「timestamp」の32ビットフィールドは、伝送のためのタイプスタンプ、すなわちMMTパケットが送信側から出ていくときの時刻を示す。この時刻は、NTPショートフォーマット(NTP short format)で表される。「packet_sequence_number」の32ビットフィールドは、同一のパケット識別子(packet_id)を持つMMTパケットのシーケンス番号を示す。「packet_counter」の32ビットフィールドは、パケット識別子(packet_id)の値に関係なく、同一のIPデータフローにおけるMMTパケットの順序を示す。
上述の「X」の1ビットフラグ情報が「1」であるとき、「packet_counter」の32ビットフィールドの後に、MMT拡張ヘッダである「header_extension」のフィールドが配置される。その後に、MMTPペイロード(MMTP payload)を構成する「payload data」のフィールドおよび「source_FEC_payload_ID」のフィールドが存在する。
図5(b)は、上述のMMTパケットの「payload data」のフィールドに配置されるMMTPペイロード(MMTP payload)の構成例(Syntax)を示している。なお、この例は、MMTヘッダの「type」が「0x00」であるMPUモードである場合を示している。最初にヘッダ情報が存在する。「length」の16ビットフィールドは、MMTPペイロード全体のバイトサイズを示す。“FT”の4ビットフィールドは、フィールドタイプを示す。 “0”は「MPU metadata」を含むことを示し、“1”は「Movie Fragment metadata」を含むことを示し、“2”は「MFU」を含むことを示す。
ここで、MFU(MMT Fragment Unit)は、MPUが細分化、すなわちフラグメント(Fragment)化されたものである。例えば、ビデオの場合、このMFUを一つのNALユニットに相当するように設定できる。また、例えば、通信ネットワーク伝送路で送る場合、このMFUを一つまたは複数のMTUサイズ(MTU size)で構成することもできる。
また、MPUは、ランダムアクセスポイント(RAP:Random Access Pint)から始まるものであり、1つまたは複数のアクセスユニット(AU:Access Unit)を含むものである。具体的には、例えば、1つのGOP(Group Of Picture)のピクチャが、一つのMPUの構成となることがある。このMPUは、アセット別(コンポーネント別)に定義されるものとなっている。したがって、ビデオのアセットからはビデオデータのみを含むビデオのMPUが作成され、オーディオのアセットからはオーディオデータのみを含むオーディオのMPUが作成される。
「T」の1ビットフラグ情報は、タイムドメディア(Timed Media)を伝送するか、ノンタイムドメディア(Non-Timed Media)を伝送するかを示す。“1”はタイムドメディアを示し、“0”はノンタイムドメディアを示す。
「f_i」の2ビットフィールドは、「DU payload」のフィールドに、整数個のデータユニット(DU:Data Unit)が入っているか、データユニットが断片化されて得られたフラグメント(Fragment)の最初(first)、中間、最後(last)のいずれが入っているかを示す。“0”は整数個のデータユニットが入っていることを示し、“1”は最初のフラグメントが入っていることを示し、“2”は中間のフラグメントが入っていることを示し、“3”は最後のフラグメントが入っていることを示す。
「A」の1ビットフラグ情報は、「DU payload」のフィールドに、複数個のデータユニットが入っているか否かを示す。“1”は入っていることを示し、“0”は入っていないことを示す。「frag_counter」の8ビットフィールドは、「f_i」が1〜3であるとき、何番目のフラグメントであるかを示す。
「MPU_sequence_number」の32ビットフィールドは、MPUの順番を示す番号であり、MPUを識別する情報である。例えば、1つのGOPが1つのMPUを構成する場合、あるGOPの「MPU_sequence_number」が「i」であるとき、次のGOPの「MPU_sequence_number」は「i+1」となる。
この「MPU_sequence_number」のフィールドの後に、「DU_length」、「DU_header」、「DU_payload」の各フィールドが配置される。「DU_length」の16ビットフィールドは、上述の「A=0」である場合、つまり「DU payload」のフィールドに複数個のデータユニットが入っていない場合は存在しない。また、「DU_header」のフィールドは、“FT=0/1”である場合、つまり「MPU metadata」や「Movie Fragment metadata」を含む場合は存在しない。
図6は、MMT/通信の信号構成例のスタックモデルを示している。MMT/通信による配信オプションとして、(A)マルチキャスト配信、(B)MMTP/UDP配信、(C)MMTP/TCP配信、(D)MMTP/HTTP配信、(E)MPU/HTTP配信が考えられる。
「(A)マルチキャスト配信」
マルチキャスト配信の場合、下位レイヤにIPパケットが存在する。このIPパケットの上に、UDP(User Datagram Protocol)が載る。そして、UDPの上に、MMT(MPEG Media Transport)パケットが載る。このMMTパケットのペイロード部には、ビデオ、オーディオ等のコンポーネントの符号化データを含むMPUが含まれる。
このマルチキャスト配信の場合、放送・通信ハイブリッド利用としては、輻輳対応を考慮すると最も望ましい方式である。また、このマルチキャスト配信の場合、UDP伝送なので、伝送効率はよいが、パケットロスの問題があるので、AL−FEC(Application Layer-Forward Error Correction)を必要とする可能性がある。
また、このマルチキャスト配信の場合、マネージドネットワーク(Managed Network)に直接接続されている受信端末のみが利用可能となる。また、このマルチキャスト配信の場合、マルチキャストIPストリームが、複数のアセット(コンポーネント)が多重化されたMMTPストリームを伝送するケースと、単体のアセットのみを含むMMTPストリームを伝送するケースとがある。
「(B)MMTP/UDP配信」
MMTP/UDP配信の場合、下位レイヤにIPパケットが存在する。このIPパケットの上に、UDP(User Datagram Protocol)が載る。そして、UDPの上に、MMTパケットが載る。このMMTパケットのペイロード部には、ビデオ、オーディオ等のコンポーネントの符号化データを含むMPUが含まれる。
このMMTP/UDP配信の場合、ユニキャスト(Unicast)なので、放送・通信ハイブリッド利用としては、輻輳の問題がある。また、このMMTP/UDP配信の場合、UDP伝送なので、伝送効率はよいが、AL−FECを必要とする可能性がある。また、マルチキャスト配信の場合、トータル遅延や同期の面では、TCPに比べると良好である。
また、このMMTP/UDP配信の場合、ユニキャストなので、広く一般のインターネット接続機器で利用可能となり得るが、ルータ設定によってはデフォルトでは利用できない可能性がある。このMMTP/UDP配信の場合、IPストリームが、複数のアセット(コンポーネント)が多重化されたMMTPストリームを伝送するケースと、単体のアセットのみを含むMMTPストリームを伝送するケースとがある。
「(C)MMTP/TCP配信」
MMTP/TCP配信の場合、下位レイヤにIPパケットが存在する。このIPパケットの上に、TCP(Transmission Control Protocol)が載る。そして、TCPの上に、MMTパケットが載る。このMMTパケットのペイロード部には、ビデオ、オーディオ等のコンポーネントの符号化データを含むMPUが含まれる。
このMMTP/TCP配信の場合、ユニキャストなので、広く一般のインターネット接続機器で利用可能となり得る。また、このMMTP/TCP配信の場合、ユニキャストなので、放送・通信ハイブリッド利用としては、輻輳の問題がある。また、このMMTP/TCP配信の場合、TCP伝送なので効率は犠牲となるが、再送が可能なので、AL−FECは不要となる。
また、このMMTP/TCP配信の場合、IPストリームが、複数のアセット(コンポーネント)が多重化されたMMTPストリームを伝送するケースと、単体のアセットのみを含むMMTPストリームを伝送するケースとがある。
「(D)MMTP/HTTP配信」
MMTP/HTTP配信の場合、下位レイヤにIPパケットが存在する。このIPパケットの上に、TCPが載る。そして、TCPの上に、HTTP(Hyper Text Transfer Protocol)が載り、さらにその上にMMTパケットが載る。このMMTパケットのペイロード部には、ビデオ、オーディオ等のコンポーネントの符号化データを含むMPUが含まれる。
このMMTP/HTTP配信の場合、HTTPなので、広く一般のインターネット接続機器で利用可能となり得る。また、このMMTP/HTTP配信の場合、ユニキャストなので、放送・通信ハイブリッド利用としては、輻輳の問題がある。また、このMMTP/HTTP配信の場合、TCP伝送なので効率は犠牲となるが、再送が可能なので、AL−FECは不要となる。
また、このMMTP/HTTP配信の場合、IPストリームが、複数のアセット(コンポーネント)が多重化されたMMTPストリームを伝送するケースと、単体のアセットのみを含むMMTPストリームを伝送するケースとがある。
「(E)MPU/HTTP配信」
MPU/HTTP配信の場合、下位レイヤにIPパケットが存在する。このIPパケットの上に、TCPが載る。そして、TCPの上に、HTTPが載り、このHTTPパケットのペイロード部には、ビデオ、オーディオ等のコンポーネントの符号化データを含むMPUが含まれる。
このMPU/HTTP配信の場合、HTTPなので、広く一般のインターネット接続機器で利用可能となり得る。また、このMPU/HTTP配信の場合、ユニキャストなので、放送・通信ハイブリッド利用としては、輻輳の問題がある。また、このMPU/HTTP配信の場合、TCP伝送なので効率は犠牲となるが、再送が可能なので、AL−FECは不要となる。
また、このMPU/HTTP配信の場合、MMTパケットが介在しないのでMMTP/HTTP配信に比べて伝送効率は良くなるが、逆にMMTPヘッダ等の情報が消失する課題がある。また、このMPU/HTTP配信の場合、受信端末は、HTTPにより、単一のアセット(コンポーネント)の個々のMPUファイルを取得するものとなる。
図7は、PAメッセージ(Package Access Message)およびMPテーブル(MPT:MMT Package Table)の構造を概略的に示している。また、図8は、PAメッセージの主要なパラメータの説明を示し、図9は、MPテーブルの主要なパラメータの説明を示している。
「message_id」は、各種シグナリング情報において、PAメッセージを識別する固定値である。「version」は、PAメッセージのバージョンを示す8ビット整数値である。例えば、MPテーブルを構成する一部のパラメータでも更新した場合には、+1インクリメントされる。「length」は、このフィールドの直後からカウントされる、PAメッセージのサイズを示すバイト数である。
「extension」のフィールドには、ペイロード(Payload)のフィールドに配置されるテーブルのインデックス情報が配置される。このフィールドには、「table_id」、「table_version」、「table_length」の各フィールドが、テーブル数だけ配置される。「table_id」は、テーブルを識別する固定値である。「table_version」は、テーブルのバージョンを示す。「table_length」は、テーブルのサイズを示すバイト数である。
PAメッセージのペイロード(Payload)のフィールドには、MPテーブル(MPT)と、所定数のその他のテーブル(Other table)が配置される。以下、MPテーブルの構成について説明する。
「table_id」は、各種シグナリング情報において、MPテーブルを識別する固定値である。「version」は、MPテーブルのバージョンを示す8ビット整数値である。例えば、MPテーブルを構成する一部のパラメータでも更新した場合には、+1インクリメントされる。「length」は、このフィールドの直後からカウントされる、MPテーブルのサイズを示すバイト数である。
「pack_id」は、放送および通信で伝送される全てのアセット(コンポーネント)を構成要素とする全体のパッケージとしての識別情報である。この識別情報は、テキスト情報である。「pack_id_len」は、そのテキスト情報のサイズ(バイト数)を示す。「MPT_descripors」のフィールドは、パッケージ全体に関わる記述子の格納領域である。「MPT_dsc_len」は、そのフィールドのサイズ(バイト数)を示す。
「num_of_asset」は、パッケージを構成する要素としてのアセット(コンポーネント)の数を示す。この数分だけ、以下のアセットループが配置される。「asset_id」は、アセットをユニークに識別する情報(アセットID)である。この識別情報は、テキスト情報である。「asset_id_len」は、そのテキスト情報のサイズ(バイト数)を示す。「gen_loc_info」は、アセットの取得先のロケーションを示す情報である。「asset_descriptors」のフィールドは、アセットに関わる記述子の格納領域である。「asset_dsc_len」は、そのフィールドのサイズ(バイト数)を示す。
なお、図10は、上述したPAメッセージの構造例(Syntax)を示している。また、図11は、上述したMPテーブル(MPT)の構造例(Syntax)を示している。図7における「gen_loc_info」のフィールドは、図11における「asset_location」のフィールドに対応し、アセットの取得先のロケーションを示す情報として複数の「MMT_general_location_info()」の配置が可能となっている。また、図7における「asset_descriptors」のフィールドは、図11における「asset_descriptors」のフィールドに対応している。
図12は、「MMT_general_location_info()」の構造例(Syntax)の一部を示している。「location_type」の8ビットフィールドは、アセットの取得先のロケーションを示す情報(以下、適宜、「ロケーション情報」という)のタイプを示している。上述の(A)マルチキャスト配信のプロトコルで配信されるアセットの場合、「location_type」は“0x01”あるいは“0x02”とされ、ロケーション情報として、ソースアドレス(ipv4_src_addr,ipv6_src_addr」と、デストネーションアドレス(ipv4_dst_addr,ipv6_dst_addr)と、デストネーションポート番号(dst_port)と、パケット識別子(packt_id)が挿入される。この場合、「location_type」により、マルチキャスト配信であることが識別される。
また、上述の(B)MMTP/UDP配信、(C)MMTP/TCP配信、(D)MMTP/HTTP配信あるいは(E)MPU/HTTP配信のプロトコルで配信されるアセットである場合、「location_type」は“0x05”とされ、ロケーション情報として、URL(Uniform Resource Locator)が配置される。
ここで、(B)MMTP/UDP配信のプロトコルで配信されるアセットである場合、スキーマ(schema)として“rtsp:// 〜.mmt”が指定され、さらにクエリフィールド(Query Field)により、UDPを指定するパラメータとパケット識別子(packet_id)を指定するパラメータが付加される。結局、この場合のURLは、“rtsp:// 〜.mmt?pr=udp&pid=1”のように表現される。この場合、「rtsp」と「pr=udp」により、MMTP/UDP配信であることが識別される。
また、(C)MMTP/TCP配信のプロトコルで配信されるアセットである場合、スキーマ(schema)として“rtsp:// 〜.mmt”が指定され、さらにクエリフィールド(Query Field)により、TCPを指定するパラメータとパケット識別子(packet_id)を指定するパラメータが付加される。結局、この場合のURLは、“rtsp:// 〜.mmt?pr=udp&pid=1”のように表現される。この場合、「rtsp」と「pr=tcp」により、MMTP/TCP配信であることが識別される。
また、(D)MMTP/HTTP配信のプロトコルで配信されるアセットである場合、スキーマ(schema)として“http:// 〜.mmt”が指定され、さらにクエリフィールド(Query Field)により、パケット識別子(packet_id)を指定するパラメータが付加される。結局、この場合のURLは、“http:// 〜.mmt?pr=pid=1”のように表現される。この場合、「http」と「mmt」により、MMTP/HTTP配信であることが識別される。
また、(E)MPU/HTTP配信のプロトコルで配信されるアセットである場合、スキーマ(schema)として“http:// 〜.mp4”が指定される。つまり、この場合のURLは、“http:// 〜.mp4”のように表現される。この場合、「http」と「mp4」により、MPU/HTTP配信であることが識別される。
「受信シーケンス」
次に、受信端末200における受信シーケンスについて説明する。最初に、図13を参照して、(A)マルチキャスト配信のプロトコルで配信されるアセットを受信する場合について述べる。マルチキャスト配信の場合、マルチキャストサーバ(MCサーバ)が存在する。
受信端末200は、放送信号を受信し、MPテーブル(MPT)を取得する。受信端末200は、このMPテーブルから、マルチキャスト配信のプロトコルで配信されるアセットのロケーション情報を得る。この場合のロケーション情報は、ソースアドレスと、デストネーションアドレスと、デストネーションポート番号と、パケット識別子である。この場合、受信端末200は、ロケーションタイプからマルチキャスト配信であることを識別できる。
この場合、受信端末200は、ロケーション情報に含まれているマルチキャストアドレスとポート番号を付加したジョインメッセージ(JOIN message)をエッジルータに送信する。このジョインメッセージの送信に伴って、マルチキャストサーバからのマルチキャストIPストリームが、エッジフィルタを介して、受信端末200に送られてくる。
受信端末200では、このマルチキャストIPストリームから、ロケーション情報に含まれているパケット識別子(Packet_id)でフィルタリングすることで、目的のアセット(コンポーネント)を取ることができる。この受信状態を抜けるとき、受信端末200は、マルチキャストアドレスとポート番号を付加したリーブメッセージ(LEAVE message)をエッジルータに送信する。
次に、図14を参照して、(B)MMTP/UDP配信のプロトコルで配信されるアセットを受信する場合について述べる。このMMTP/UDP配信の場合、RTSP(Real Time Streaming Protocol)のプロトコルを使用する。このMMTP/UDP配信の場合、RTSPサーバおよびMMTP/UDPサーバが存在する。これらのサーバは別個の機器として存在するか、あるいは同一の機器として存在する。図示の例では、同一の機器として存在する場合を示している。
受信端末200は、放送信号を受信し、MPテーブル(MPT)を取得する。受信端末200は、このMPテーブルから、MMTP/UDP配信のプロトコルで配信されるアセットのロケーション情報を得る。この場合のロケーション情報は、URLであり、スキーマとして“rtsp:// 〜.mmt”が指定され、さらにクエリフィールドにより、UDPを指定するパラメータとパケット識別子を指定するパラメータが付加されている。この場合、受信端末200は、「rtsp」と「pr=udp」により、MMTP/UDP配信であることを識別できる。
受信端末200は、“SETUP”のRTSPリクエストを送る。この際、受信端末200は、RTSPのヘッダに、ロケーション情報を挿入する。この場合、ロケーション情報として、MPテーブルから取得されたロケーション情報の全てが挿入されるか、あるいはパケット識別子を指定するパラメータが除かれて挿入される。このRTSPリクエストは目的のサーバに送られ、当該サーバから“OK”のレスポンスが送られてくる。
その後、受信端末200は、“PLAY”のRTSPリクエストを送る。これに対して目的のサーバから“OK”のレスポンスが送られてくる。これと同時に、MMTP/UDPサーバから伝送ストリームが受信端末200に送られてくる。受信端末200では、このストリームから、ロケーション情報に含まれているパケット識別子(Packet_id)でフィルタリングすることで、目的のアセット(コンポーネント)を取ることができる。この受信状態を抜けるとき、受信端末200は、“TEARDOWN”のRTSPリクエストを送る。これに対してサーバから“OK”のレスポンスが送られてくる。
次に、図15を参照して、(C)MMTP/TCP配信のプロトコルで配信されるアセットを受信する場合について述べる。このMMTP/TCP配信の場合も、RTSP(Real Time Streaming Protocol)のプロトコルを使用する。このMMTP/TCP配信の場合、RTSPサーバおよびMMTP/TCPサーバが存在する。これらのサーバは別個の機器として存在するか、あるいは同一の機器として存在する。図示の例では、同一の機器として存在する場合を示している。
受信端末200は、放送信号を受信し、MPテーブル(MPT)を取得する。受信端末200は、このMPテーブルから、MMTP/TCP配信のプロトコルで配信されるアセットのロケーション情報を得る。この場合のロケーション情報は、URLであり、スキーマとして“rtsp:// 〜.mmt”が指定され、さらにクエリフィールドにより、TCPを指定するパラメータとパケット識別子を指定するパラメータが付加されている。この場合、受信端末200は、「rtsp」と「pr=tcp」により、MMTP/TCP配信であることを識別できる。
受信端末200は、“SETUP”のRTSPリクエストを送る。この際、受信端末200は、RTSPのヘッダに、ロケーション情報を挿入する。この場合、ロケーション情報として、MPテーブルから取得されたロケーション情報の全てが挿入されるか、あるいはパケット識別子を指定するパラメータが除かれて挿入される。このRTSPリクエストは目的のサーバに送られ、当該サーバから“OK”のレスポンスが送られてくる。
その後、受信端末200は、“PLAY”のRTSPリクエストを送る。これに対して目的のサーバから“OK”のレスポンスが送られてくる。これと同時に、MMTP/TCPサーバから伝送ストリームが受信端末200に送られてくる。受信端末200では、このストリームから、ロケーション情報に含まれているパケット識別子(Packet_id)でフィルタリングすることで、目的のアセット(コンポーネント)を取ることができる。この受信状態を抜けるとき、受信端末200は、“TEARDOWN”のRTSPリクエストを送る。これに対してサーバから“OK”のレスポンスが送られてくる。
次に、図16を参照して、(D)MMTP/HTTP配信のプロトコルで配信されるアセットを受信する場合について述べる。このMMTP/HTTP配信の場合、HTTP(Hyper Text Transfer Protocol)のプロトコルを使用する。このMMTP/HTTP配信の場合、HTTPサーバが存在する。
受信端末200は、放送信号を受信し、MPテーブル(MPT)を取得する。受信端末200は、このMPテーブルから、MMTP/HTTP配信のプロトコルで配信されるアセットのロケーション情報を得る。この場合のロケーション情報は、URLであり、スキーマとして“http:// 〜.mmt”が指定され、さらにクエリフィールドにより、パケット識別子(packet_id)を指定するパラメータが付加されている。受信端末200は、「http」と「mmt」により、MMTP/HTTP配信であることを識別できる。
受信端末200は、HTTPリクエストをHTTPサーバに送る。この際、受信端末200は、HTTPのヘッダに、ロケーション情報を挿入する。この場合、ロケーション情報として、MPテーブルから取得されたロケーション情報に含まれる“http:// 〜.mmt”が挿入されると共に、さらにクエリフィールドにより、パケット識別子を指定するパラメータ“pid=a”と、MPUシーケンス番号を指定するパラメータ“msn=*”が付加される。パラメータ“msn=*”は、「そのタイミングのMPUシーケンス番号を持ったMPUを送って下さい」という指定になる。
このHTTPリクエストは目的のHTTPサーバに送られ、当該HTTPサーバから、HTTPレスポンスとして、HTTPリクエストを送ったタイミングのMPUシーケンス番号(=10)を持ったMPUを含むMMTPストリームが受信端末200に送られてくる。受信端末200では、このMMTPストリームから、ロケーション情報に含まれているパケット識別子(Packet_id)でフィルタリングすることで、目的のアセット(コンポーネント)を取る。
受信端末200は、MMTPストリームの受信完了後に、あるいは受信完了前に、次のMPUシーケンス番号(=11)のMPUを要求するHTTPリクエストをHTTPサーバに送る。そして、当該HTTPサーバから、HTTPレスポンスとして、次のMPUシーケンス番号(=11)のMPUを含むMMTPストリームが受信端末200に送られてくる。受信端末200は、このMMTPストリームから、ロケーション情報に含まれているパケット識別子(Packet_id)でフィルタリングすることで、目的のアセット(コンポーネント)を取ることができる。
以下、同様にして、受信端末200は、次のMPUシーケンス番号のMPUを要求するHTTPリクエストをHTTPサーバに送り、当該HTTPサーバから、HTTPレスポンスとして、次のMPUシーケンス番号のMPUを含むMMTPストリームを受信し、そのMMTPストリームから目的のアセット(コンポーネント)を取る。
なお、HTTPリクエストの際に、HTTPヘッダに含まれるパラメータ“pid=a”は、ビデオ、オーディオなどのアセットの種類の指定となる。MMTPストリームにビデオおよびオーディオが多重化されていることがある。その場合、MPUシーケンス番号は、ビデオはビデオのMPUシーケンス番号を持ち、オーディオはオーディオのMPUシーケンス番号を持つ。MPUシーケンス番号を指定したとしても、パラメータ“pid=a”がないと、どちらのアセット(コンポーネント)のMPUシーケンス番号か分からないことになる。
図17は、MMTP/HTTPの多重化ストリームにおける切り出し処理を示している。パラメータ“pid=a”がビデオを示し、MPUシーケンス番号がnのMPUを要求するHTTPリクエストを受け取ったHTTPサーバは、多重化ストリームから、ビデオのMPUシーケンス番号のn−1からnへの切り換わりからnからn+1への切り換わりまでを切り取って、受信端末200に送る。
なお、この場合、同じ多重化ストリームからオーディオも取りたいことがある。この場合、受信端末200は、ロケーション情報から、オーディオはビデオと多重化されていることを認識できる。受信端末200は、ビデオのMPUシーケンス番号で切り出されたMMTPストリームから、ロケーション情報に含まれているパケット識別子(Packet_id)でフィルタリングすることで目的のオーディオを取り出す処理をする。
次に、図18を参照して、(E)MPU/HTTP配信のプロトコルで配信されるアセットを受信する場合について述べる。このMPU/HTTP配信の場合、HTTP(Hyper Text Transfer Protocol)のプロトコルを使用する。このMPU/HTTP配信の場合、HTTPサーバが存在する。
受信端末200は、放送信号を受信し、MPテーブル(MPT)を取得する。受信端末200は、このMPテーブルから、MPU/HTTP配信のプロトコルで配信されるアセットのロケーション情報を得る。この場合のロケーション情報は、URLであり、スキーマとして“http:// 〜.mp4”が指定される。受信端末200は、「http」と「mp4」により、MPU/HTTP配信であることを識別できる。
受信端末200は、HTTPリクエストをHTTPサーバに送る。この際、受信端末200は、HTTPのヘッダに、ロケーション情報を挿入する。この場合、ロケーション情報として、MPテーブルから取得されたロケーション情報に含まれる“http:// 〜.mp4”が挿入されると共に、さらにクエリフィールドにより、MPUシーケンス番号を指定するパラメータ“msn=*”が付加される。パラメータ“msn=*”は、「そのタイミングのMPUを送って下さい」という指定になる。
このHTTPリクエストは目的のHTTPサーバに送られ、当該HTTPサーバから、HTTPレスポンスとして、HTTPリクエストを送ったタイミングのMPUシーケンス番号(=10)を持ったMPUが受信端末200に送られてくる。
受信端末200は、MPUの受信完了後に、あるいは受信完了前に、次のMPUシーケンス番号(=11)のMPUを要求するHTTPリクエストをHTTPサーバに送る。そして、当該HTTPサーバから、HTTPレスポンスとして、次のMPUシーケンス番号(=11)のMPUが受信端末200に送られてくる。
以下、同様にして、受信端末200は、次のMPUシーケンス番号のMPUを要求するHTTPリクエストをHTTPサーバに送り、当該HTTPサーバから、HTTPレスポンスとして、次のMPUシーケンス番号のMPUを受信する。
[放送送出システムの構成]
図19は、放送送出システム100の構成例を示している。この放送送出システム100は、信号送出部101と、ビデオエンコーダ102と、オーディオエンコーダ103と、シグナリング発生部104を有している。また、この放送送出システム100は、TLVシグナリング発生部105と、N個のIPサービス・マルチプレクサ106-1〜106-Nと、TLV・マルチプレクサ107と、変調/送信部108を有している。
信号送出部101は、例えば、TV局のスタジオとか、VTR等の記録再生機であり、ビデオ、オーディオのストリームデータを各エンコーダに送出する。ビデオエンコーダ102は、信号送出部101から送出されるビデオデータを符号化し、さらにパケット化して、ビデオのMMTパケットを含むIPパケットをIPサービス・マルチプレクサ106-1に送る。オーディオエンコーダ103は、信号送出部101から送出されるオーディオデータを符号化し、さらにパケット化して、オーディオのMMTパケットを含むIPパケットをIPサービス・マルチプレクサ106-1に送る。
シグナリング発生部104は、シグナリングメッセージを発生し、ペイロード部にこのシグナリングメッセージが配置されたMMTパケットを含むIPパケットをIPサービス・マルチプレクサ106-1に送る。この場合、シグナリング発生部104は、PAメッセージに、MPテーブル(MPT)を配置する(図11〜図12参照)。このMPテーブルには、上述したように、放送および通信で伝送される全てのアセット(コンポーネント)の情報が含まれる。この情報には、各アセットのロケーション情報も含まれている。
IPサービス・マルチプレクサ106-1は、各エンコーダから送られてくるIPパケットの時分割多重化を行う。この際、IPサービス・マルチプレクサ106-1は、各IPパケットにTLVヘッダを付加して、TLVパケットとする。IPサービス・マルチプレクサ106-1は、一つのトランスポンダの中にいれる一つのチャネル部分を構成する。IPサービス・マルチプレクサ106-2〜106-Nは、IPサービス・マルチプレクサ106-1と同様の機能を持ち、その1つのトランスポンダの中に入れる他のチャネル部分を構成する。
TLVシグナリング発生部105は、シグナリング(Signaling)情報を発生し、このシグナリング(Signaling)情報をペイロード部に配置するTLVパケットを生成する。TLV・マルチプレクサ107は、IPサービス・マルチプレクサ106-1〜106-NおよびTLVシグナリング発生部105で生成されるTLVパケットを多重化して、放送ストリームを生成する。変調/送信部108は、TLV・マルチプレクサ107で生成される放送ストリームに対して、RF変調処理を行って、RF伝送路に送出する。
図19に示す放送送出システム100の動作を簡単に説明する。信号送出部101から送出されるビデオデータは、ビデオエンコーダ102に供給される。このビデオエンコーダ102では、ビデオデータが符号化され、さらにパケット化されて、ビデオのMMTパケットを含むIPパケットが生成される。このIPパケットは、IPサービス・マルチプレクサ106-1に送られる。また、信号送出部101から送出されるオーディオデータに対しても同様の処理が行われる。そして、オーディオエンコーダ103で生成されるオーディオのMMTパケットを含むIPパケットがIPサービス・マルチプレクサ106-1に送られる。
また、シグナリング発生部104では、シグナリングメッセージが発生され、ペイロード部にこのシグナリングメッセージが配置されたMMTパケットを含むIPパケットが生成される。このIPパケットは、IPサービス・マルチプレクサ106-1に送られる。この際、PAメッセージに、MPテーブル(MPT)が配置される。
IPサービス・マルチプレクサ106-1では、各エンコーダおよびシグナリング発生部104から送られてくるIPパケットの時分割多重化が行われる。この際、各IPパケットにTLVヘッダが付加されて、TLVパケットとされる。このIPサービス・マルチプレクサ106-1では、一つのトランスポンダの中に入れる1つのチャネル部分の処理が行われ、IPサービス・マルチプレクサ106-2〜106-Nでは、その一つのトランスポンダの中に入れる他のチャネル部分の処理が同様に行われる。
IPサービス・マルチプレクサ106-1〜106-Nで得られるTLVパケットは、TLV・マルチプレクサ107に送られる。このTLV・マルチプレクサ107には、さらに、TLVシグナリング発生部105から、シグナリング(Signaling)情報をペイロード部に配置するTLVパケットも送られる。
TLV・マルチプレクサ107では、IPサービス・マルチプレクサ106-1〜106-NおよびTLVシグナリング発生部105で生成されるTLVパケットが多重化されて、放送ストリームが生成される。この放送ストリームは、変調/送信部108に送られる。変調/送信部108では、この放送ストリームに対してRF変調処理が行われ、そのRF変調信号が放送信号としてRF伝送路に送出される。
[受信端末の構成]
図20は、受信端末200の構成例を示している。この受信端末200は、CPU201と、チューナ/復調部202と、ネットワークインタフェース部203と、デマルチプレクサ204を有している。また、この受信端末200は、ビデオデコーダ205と、オーディオデコーダ206を有している。
CPU201は、制御部を構成し、受信端末200の各部の動作を制御する。チューナ/復調部202は、RF変調信号を受信し、復調処理を行って、放送ストリームを得る。ネットワークインタフェース部203は、配信サーバ300から通信ネットワーク400を介して配信されるサービスの伝送ストリームを受信する。
デマルチプレクサ204は、チューナ/復調部202で得られる放送ストリームおよびネットワークインタフェース部203で得られる伝送ストリームに対して、デマルチプレクス処理およびデパケット化処理を行って、シグナリング情報、ビデオ、オーディオの符号化データなどを出力する。
ビデオデコーダ205は、デマルチプレクサ204で得られる符号化ビデオデータの復号化を行ってベースバンドのビデオデータを得る。オーディオデコーダ206は、デマルチプレクサ204で得られる符号化オーディオデータの復号化を行ってベースバンドのオーディオデータを得る。
図20に示す受信端末200の動作を簡単に説明する。チューナ/復調部202では、RF伝送路を通じて送られてくるRF変調信号が受信され、復調処理が行われて、放送ストリームが得られる。この放送ストリームは、デマルチプレクサ204に送られる。また、ネットワークインタフェース部203では、配信サーバ300から通信ネットワーク400を介して配信されるサービスの伝送ストリームが受信され、デマルチプレクサ204に送られる。
デマルチプレクサ204では、チューナ/復調部202からの放送ストリームやネットワークインタフェース部203からの伝送ストリームに対して、デマルチプレクス処理およびデパケット化処理が行われ、シグナリング情報、ビデオ、オーディオの符号化データなどが抽出される。
デマルチプレクサ204で抽出される各種のシグナリング情報はCPUバス207を介してCPU201に送られる。このシグナリング情報には、TLV−SI、MMT−SIが含まれる。上述したように、TLV−SIはTLVの伝送パケットの上に載る伝送制御信号(TLV−NIT/AMT)であり、MMT−SIはMMTパケットのペイロード部に含まれるシグナリング情報としてのシグナリングメッセージである(図2参照)。CPU201は、このシグナリング情報に基づいて、受信端末200の各部の動作を制御する。
デマルチプレクサ204で抽出される符号化ビデオデータはビデオデコーダ205に送られて復号化され、ベースバンドのビデオデータが得られる。また、デマルチプレクサ204で抽出される符号化オーディオデータはオーディオデコーダ206に送られて復号化され、音声出力用のベースバンドのオーディオデータが得られる。
上述したように、図1に示す放送・通信ハイブリッドシステム10においては、通信経路のアセット(コンポーネント)に関し、MPテーブルに、少なくともロケーション情報およびプロトコル識別情報が含まれる取得情報が挿入される。そのため、受信側では、この取得情報に基づいて、通信経路のコンポーネントを含む伝送パケットを有する伝送ストリームの受信を良好に行い得る。
また、図1に示す放送・通信ハイブリッドシステム10においては、MPテーブルに挿入される通信経路のアセット(コンポーネント)の取得情報に、パケット識別情報が含まれる。そのため、MMTPストリームに複数のアセットの伝送パケットが多重化されているケースであっても、受信側では、所望の伝送パケットを選択的に取得可能となる。
<2.変形例>
なお、上述実施の形態では、伝送パケットがMMTパケットである例を示した。本技術は、これに限定されるものではなく、その他の同様の伝送パケットを取り扱う場合にも、本技術を適用できることは勿論である。
また、本技術は、以下のような構成を取ることもできる。
(1)所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを生成する伝送ストリーム生成部と、
上記伝送ストリームを所定の伝送路を通じて送信する送信部と、
上記第2の伝送パケットに、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報を挿入する情報挿入部を備える
送信装置。
(2)上記取得情報に、パケット識別情報がさらに含まれる
前記(1)に記載の送信装置。
(3)上記プロトコル識別情報は、少なくともマルチキャスト配信、MMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれのプロトコルであるかを識別するための情報である
前記(1)または(2)に記載の送信装置。
(4)上記プロトコル識別情報が上記MMTP/UDP配信であることを示すとき、上記取得情報には、URLの他にUDPを指定するパラメータが含まれる
前記(3)に記載の送信装置。
(5)上記プロトコル識別情報が上記MMTP/TCP配信であることを示すとき、上記取得情報には、URLの他にTCPを指定するパラメータが含まれる
前記(3)に記載の送信装置。
(6)上記伝送パケットは、MMTパケットである
前記(1)から(5)のいずれかに記載の送信装置。
(7)上記所定の伝送路は、放送伝送路である
前記(1)から(6)のいずれかに記載の送信装置。
(8)所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを生成する伝送ストリーム生成ステップと、
送信部により、上記伝送ストリームを所定の伝送路を通じて送信する送信ステップと、
上記第2の伝送パケットに、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報を挿入する情報挿入ステップを有する
送信方法。
(9)所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを所定の伝送路を通じて受信する受信部を備え、
上記第2の伝送パケットには、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入されており、
上記ロケーション情報および上記プロトコル識別情報に基づいてサーバにリクエストすることで、該サーバからネットワークを通じて所定のコンポーネントを含む第3の伝送パケットを有する伝送ストリームを上記プロトコル識別情報で示されるプロトコルで受信する通信部をさらに備える
受信装置。
(10)上記通信経路のコンポーネントの取得情報にはパケット識別情報がさらに含まれており、
上記通信部は、上記受信された第3の伝送パケットを有する伝送ストリームから、上記パケット識別情報に基づいて該第3の伝送パケットを抽出する
前記(9)に記載の受信装置。
(11)上記プロトコル識別情報は、少なくともマルチキャスト配信、MMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれのプロトコルであるかを識別するための情報である
前記(9)または(10)に記載の受信装置。
(12)上記プロトコル識別情報が上記MMTP/UDP配信であることを示すとき、
上記取得情報には、URLの他にUDPを指定するパラメータが含まれており、
上記通信部は、
上記URLおよび上記UDPを指定するパラメータを用いてサーバにリクエストすることで、該サーバからネットワークを通じて上記第3の伝送パケットを有する伝送ストリームを上記MMTP/UDP配信のプロトコルで受信する
前記(11)に記載の受信装置。
(13)上記プロトコル識別情報が上記MMTP/TCP配信であることを示すとき、
上記取得情報には、URLの他にTCPを指定するパラメータが含まれており、
上記通信部は、
上記URLおよび上記TCPを指定するパラメータを用いてサーバにリクエストをすることで、該サーバからネットワークを通じて上記第3の伝送パケットを有する伝送ストリームを上記MMTP/TCP配信のプロトコルで受信する
前記(11)に記載の受信装置。
(14)上記プロトコル識別情報がMMTP/HTTP配信であることを示すとき、
上記取得情報にはURLが含まれており、
上記通信部は、
上記URLおよびMPUシーケンス番号を示すパラメータを用いてサーバに順次リクエストを送信することで、該サーバからネットワークを通じて上記パラメータに対応したMPUシーケンス番号のMPUを含むMMTパケットを順次受信し、
最初のリクエストにおけるMPUシーケンス番号を示すパラメータを、該最初のリクエストのタイミングのMPUシーケンス番号を表すものとする
前記(11)に記載の受信装置。
(15)上記プロトコル識別情報がMPU/HTTP配信であることを示すとき、
上記取得情報にはURLが含まれており、
上記通信部は、
上記URLおよびMPUシーケンス番号を示すパラメータを用いてサーバに順次リクエストを送信することで、該サーバからネットワークを通じて上記パラメータに対応したMPUシーケンス番号のMPUを順次受信し、
最初のリクエストにおけるMPUシーケンス番号を示すパラメータを、該最初のリクエストのタイミングのMPUシーケンス番号を表すものとする
前記(11)に記載の受信装置。
(16)上記伝送パケットは、MMTパケットである
前記(9)から(15)のいずれかに記載の受信装置。
(17)上記所定の伝送路は、放送伝送路である
前記(9)から(16)のいずれかに記載の受信装置。
(18)受信部により、所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを所定の伝送路を通じて受信する受信ステップを有し、
上記第2の伝送パケットには、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入されており、
通信部により、上記ロケーション情報および上記プロトコル識別情報に基づき、ネットワークを通じて、所定のコンポーネントを含む第3の伝送パケットを有する伝送ストリームを上記プロトコル識別情報で示されるプロトコルで受信する通信ステップをさらに有する
受信方法。
(19)所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを時分割的に多重化した伝送ストリームを所定の伝送路を通じて受信する受信部を備え、
上記第2の伝送パケットには、少なくともロケーション情報およびプロトコル識別情報が含まれる、通信経路のコンポーネントの取得情報が挿入されており、
上記受信部で受信された伝送ストリームを処理する処理部をさらに備える
受信装置。
10・・・放送・通信ハイブリッドシステム
100・・・放送送出システム
101・・・信号送出部
102・・・ビデオエンコーダ
103・・・オーディオエンコーダ
104・・・シグナリング発生部
105・・・TLVシグナリング発生部
106-1〜106-N・・・IPサービス・マルチプレクサ
107・・・TLV・マルチプレクサ
108・・・変調/送信部
200・・・受信端末
201・・・CPU
202・・・チューナ/復調部
203・・・ネットワークインタフェース部
204・・・デマルチプレクサ
205・・・ビデオデコーダ
206・・・オーディオデコーダ
207・・・CPUバス
300・・・配信サーバ
400・・・通信ネットワーク

Claims (12)

  1. 所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを多重化した伝送ストリームを生成する伝送ストリーム生成部と、
    上記伝送ストリームを所定の伝送路を通じて送信する送信部と、
    上記第2の伝送パケットに、通信経路のコンポーネントを取得するためのロケーション情報であるURLを挿入する情報挿入部を備え、
    上記URLは、上記通信経路のコンポーネントのユニキャスト配信プロトコル識別情報を含み、
    上記ユニキャスト配信プロトコル識別情報は、少なくともMMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれかのユニキャスト配信プロトコルを識別するための情報である
    送信装置。
  2. 上記ユニキャスト配信プロトコル識別情報が上記MMTP/UDP配信であることを示すとき、上記URLはUDPを指定するパラメータを含む
    請求項に記載の送信装置。
  3. 上記ユニキャスト配信プロトコル識別情報が上記MMTP/TCP配信であることを示すとき、上記URLはTCPを指定するパラメータを含む
    請求項に記載の送信装置。
  4. 上記伝送パケットは、MMTパケットである
    請求項1に記載の送信装置。
  5. 上記所定の伝送路は、放送伝送路である
    請求項1に記載の送信装置。
  6. 所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを多重化した伝送ストリームを生成する伝送ストリーム生成ステップと、
    送信部により、上記伝送ストリームを所定の伝送路を通じて送信する送信ステップと、
    上記第2の伝送パケットに、通信経路のコンポーネントを取得するためのロケーション情報であるURLを挿入する情報挿入ステップを有し、
    上記URLは、上記通信経路のコンポーネントのユニキャスト配信プロトコル識別情報を含み、
    上記ユニキャスト配信プロトコル識別情報は、少なくともMMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれかのユニキャスト配信プロトコルを識別するための情報である
    送信方法。
  7. 所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを多重化した伝送ストリームを所定の伝送路を通じて受信する受信部を備え、
    上記第2の伝送パケットには、通信経路のコンポーネントを取得するためのロケーション情報であるURLが挿入されており、
    上記URLは、上記通信経路のコンポーネントのユニキャスト配信プロトコル識別情報を含み、
    上記ユニキャスト配信プロトコル識別情報は、少なくともMMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれかのユニキャスト配信プロトコルを識別するための情報であり、
    上記URLに基づいてサーバにリクエストすることで、該サーバからネットワークを通じて所定のコンポーネントを含む第3の伝送パケットを有する伝送ストリームを上記ユニキャスト配信プロトコル識別情報で示されるユニキャスト配信プロトコルで受信する通信部をさらに備える
    受信装置。
  8. 上記ユニキャスト配信プロトコル識別情報が上記MMTP/UDP配信であることを示すとき、
    上記URLはUDPを指定するパラメータを含み、
    上記通信部は、
    上記URLおよび上記UDPを指定するパラメータを用いてサーバにリクエストすることで、該サーバからネットワークを通じて上記第3の伝送パケットを有する伝送ストリームを上記MMTP/UDP配信のユニキャスト配信プロトコルで受信する
    請求項に記載の受信装置。
  9. 上記ユニキャスト配信プロトコル識別情報が上記MMTP/TCP配信であることを示すとき、
    上記URLはTCPを指定するパラメータを含み、
    上記通信部は、
    上記URLおよび上記TCPを指定するパラメータを用いてサーバにリクエストをすることで、該サーバからネットワークを通じて上記第3の伝送パケットを有する伝送ストリームを上記MMTP/TCP配信のユニキャスト配信プロトコルで受信する
    請求項に記載の受信装置。
  10. 上記伝送パケットは、MMTパケットである
    請求項に記載の受信装置。
  11. 上記所定の伝送路は、放送伝送路である
    請求項に記載の受信装置。
  12. 受信部により、所定のコンポーネントを含む第1の伝送パケットおよび該所定のコンポーネントに関する情報を含む第2の伝送パケットを多重化した伝送ストリームを所定の伝送路を通じて受信する受信ステップを有し、
    上記第2の伝送パケットには、通信経路のコンポーネントを取得するためのロケーション情報であるURLが挿入されており、
    上記URLは、上記通信経路のコンポーネントのユニキャスト配信プロトコル識別情報を含み、
    上記ユニキャスト配信プロトコル識別情報は、少なくともMMTP/UDP配信、MMTP/TCP配信、MMTP/HTTP配信およびMPU/HTTP配信のいずれかのユニキャスト配信プロトコルを識別するための情報であり、
    通信部により、上記URLに基づいてサーバにリクエストすることで、該サーバからネットワークを通じて所定のコンポーネントを含む第3の伝送パケットを有する伝送ストリームを上記ユニキャスト配信プロトコル識別情報で示されるユニキャスト配信プロトコルで受信する通信ステップをさらに有する
    受信方法。
JP2016557731A 2014-11-05 2015-10-29 送信装置、送信方法、受信装置および受信方法 Active JP6696430B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020008852A JP6927338B2 (ja) 2014-11-05 2020-01-23 送信方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014225484 2014-11-05
JP2014225484 2014-11-05
PCT/JP2015/080526 WO2016072343A1 (ja) 2014-11-05 2015-10-29 送信装置、送信方法、受信装置および受信方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2020008852A Division JP6927338B2 (ja) 2014-11-05 2020-01-23 送信方法

Publications (2)

Publication Number Publication Date
JPWO2016072343A1 JPWO2016072343A1 (ja) 2017-08-17
JP6696430B2 true JP6696430B2 (ja) 2020-05-20

Family

ID=55909069

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2016557731A Active JP6696430B2 (ja) 2014-11-05 2015-10-29 送信装置、送信方法、受信装置および受信方法
JP2020008852A Active JP6927338B2 (ja) 2014-11-05 2020-01-23 送信方法
JP2021127872A Active JP7188510B2 (ja) 2014-11-05 2021-08-04 送信方法および受信装置
JP2022191176A Pending JP2023021166A (ja) 2014-11-05 2022-11-30 送信方法および受信装置

Family Applications After (3)

Application Number Title Priority Date Filing Date
JP2020008852A Active JP6927338B2 (ja) 2014-11-05 2020-01-23 送信方法
JP2021127872A Active JP7188510B2 (ja) 2014-11-05 2021-08-04 送信方法および受信装置
JP2022191176A Pending JP2023021166A (ja) 2014-11-05 2022-11-30 送信方法および受信装置

Country Status (4)

Country Link
EP (1) EP3217673A4 (ja)
JP (4) JP6696430B2 (ja)
BR (1) BR112017008892A2 (ja)
WO (1) WO2016072343A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102519209B1 (ko) * 2015-06-17 2023-04-07 한국전자통신연구원 스테레오스코픽 비디오 데이터를 처리하기 위한 mmt 장치 및 방법

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2667622B1 (en) * 2011-01-19 2019-05-01 Samsung Electronics Co., Ltd Apparatus and method for configuring a control message in a broadcast system
EP3913822B1 (en) * 2011-10-13 2022-06-22 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving multimedia service
JP6153298B2 (ja) * 2012-04-24 2017-06-28 シャープ株式会社 配信装置、再生装置、データ構造、配信方法、制御プログラム、および記録媒体
KR101501344B1 (ko) * 2012-05-02 2015-03-10 삼성전자주식회사 멀티미디어 서비스 송수신 방법 및 장치
JP5641090B2 (ja) * 2013-03-14 2014-12-17 ソニー株式会社 送信装置、送信方法、受信装置および受信方法

Also Published As

Publication number Publication date
JP2020074589A (ja) 2020-05-14
JPWO2016072343A1 (ja) 2017-08-17
EP3217673A1 (en) 2017-09-13
JP2021180517A (ja) 2021-11-18
JP7188510B2 (ja) 2022-12-13
EP3217673A4 (en) 2018-04-18
WO2016072343A1 (ja) 2016-05-12
JP2023021166A (ja) 2023-02-09
BR112017008892A2 (pt) 2017-12-19
JP6927338B2 (ja) 2021-08-25

Similar Documents

Publication Publication Date Title
US10715844B2 (en) Method and apparatus for transceiving data for multimedia transmission system
JP6419235B2 (ja) デジタル放送システムにおけるデータを受信する装置
JP6330804B2 (ja) 送信装置、伝送ストリームの送信方法および処理装置
JP7400875B2 (ja) 受信装置
JP6798585B2 (ja) 送信装置、送信方法および受信装置
JP2023021166A (ja) 送信方法および受信装置
KR101855327B1 (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181023

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181023

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190604

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190729

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20191029

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200123

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20200130

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200406

R151 Written notification of patent or utility model registration

Ref document number: 6696430

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151