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

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

Info

Publication number
WO2015045362A1
WO2015045362A1 PCT/JP2014/004863 JP2014004863W WO2015045362A1 WO 2015045362 A1 WO2015045362 A1 WO 2015045362A1 JP 2014004863 W JP2014004863 W JP 2014004863W WO 2015045362 A1 WO2015045362 A1 WO 2015045362A1
Authority
WO
WIPO (PCT)
Prior art keywords
transmission
reference clock
clock information
packet
stored
Prior art date
Application number
PCT/JP2014/004863
Other languages
English (en)
French (fr)
Inventor
賀敬 井口
遠間　正真
加藤　久也
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2014183694A external-priority patent/JP6313170B2/ja
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to EP14847603.9A priority Critical patent/EP3054608A4/en
Priority to CN201480045742.4A priority patent/CN105519020B/zh
Publication of WO2015045362A1 publication Critical patent/WO2015045362A1/ja
Priority to US15/075,229 priority patent/US9992549B2/en
Priority to US15/956,301 priority patent/US10321200B2/en
Priority to US16/394,781 priority patent/US10715876B2/en
Priority to US16/892,774 priority patent/US11272258B2/en
Priority to US17/588,936 priority patent/US11665405B2/en
Priority to US18/135,981 priority patent/US20230254546A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6143—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a satellite
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6175—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
    • H04N21/6193—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network involving transmission via a satellite
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Definitions

  • This disclosure relates to a transmission method or the like in the case of transmitting content through broadcasting using an IP (Internet Protocol) packet.
  • IP Internet Protocol
  • the MMT method (see Non-Patent Document 1) is a multiplexing method for multiplexing and packetizing content such as video and audio and transmitting the content through one or more transmission paths such as broadcasting or communication.
  • the MMT method is applied to a broadcasting system, the reference clock information on the transmission side is transmitted to the reception side, and the reception device generates a system clock in the reception device based on the reference clock information.
  • MPEG media transport MMT
  • a transmission method is a transmission method in content transmission using an IP (Internet Protocol) packet performed through broadcasting, and stores at least one first transmission unit in which the IP packet is stored.
  • the content is reproduced in the first transmission unit located at the head of the second transmission unit at the head of at least one of the streams included in the frame.
  • a recording medium such as a system, an apparatus, a method, an integrated circuit, a computer program, or a computer-readable CD-ROM.
  • a recording medium such as a system, an apparatus, a method, an integrated circuit, a computer program, or a computer-readable CD-ROM.
  • These comprehensive or specific aspects may be realized by any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.
  • FIG. 1 is a diagram illustrating a protocol stack when transmission is performed using the MMT scheme and the advanced BS transmission scheme.
  • FIG. 2 is a diagram illustrating a data structure of a TLV packet.
  • FIG. 3 is a block diagram showing a basic configuration of the receiving apparatus.
  • FIG. 4 is a block diagram showing a functional configuration of the receiving apparatus when the reference clock information is stored in the extension field of the MMT packet header.
  • FIG. 5 is a diagram illustrating a flow of obtaining reference clock information of the receiving apparatus when the reference clock information is stored in the extension field of the MMT packet header.
  • FIG. 6 is a block diagram illustrating a functional configuration of the receiving device when the reference clock information is stored in the control information.
  • FIG. 1 is a diagram illustrating a protocol stack when transmission is performed using the MMT scheme and the advanced BS transmission scheme.
  • FIG. 2 is a diagram illustrating a data structure of a TLV packet.
  • FIG. 3 is a block diagram showing a basic configuration of the
  • FIG. 7 is a diagram illustrating an acquisition flow of the reference clock information of the receiving device when the reference clock information is stored in the control information.
  • FIG. 8 is a block diagram showing a configuration of a receiving apparatus when reference clock information is stored in a TLV packet.
  • FIG. 9 is a diagram illustrating an example in which the long format NTP is stored in the TLV packet.
  • FIG. 10 is a diagram illustrating an acquisition flow of the reference clock information of the receiving device when the reference clock information is stored in the TLV packet.
  • FIG. 11 is a diagram illustrating a configuration in which the reference clock information is added immediately before the header of the IP packet.
  • FIG. 12 is a diagram illustrating a configuration in which the reference clock information is added immediately before the TLV packet.
  • FIG. 13 is a diagram illustrating a configuration of a transmission slot.
  • FIG. 14 is a diagram illustrating a configuration of a slot header of a transmission slot.
  • FIG. 15 is a diagram illustrating an example in which a flag is stored in an undefined area of the slot header.
  • FIG. 16 is a diagram showing a configuration of TMCC control information in the transmission system of the advanced broadband satellite digital broadcasting.
  • FIG. 17 is a diagram illustrating stream type / relative stream information of TMCC control information.
  • FIG. 18 is a diagram illustrating an example in which the reference clock information is stored in the undefined field of the slot header.
  • FIG. 19 is a block diagram illustrating a functional configuration of the receiving apparatus when information indicating that the reference clock information is included in the slot header is stored in the TMCC control information.
  • FIG. 20 is a diagram illustrating an acquisition flow of the reference clock information when information indicating that the reference clock information is included in the slot header is stored in the TMCC control information.
  • FIG. 21 is a diagram illustrating a flow when a bit string at a specific position is extracted from an IP packet or a compressed IP packet.
  • FIG. 22 is a block diagram illustrating a functional configuration of the transmission apparatus.
  • FIG. 23 is a diagram illustrating an operation flow of the transmission apparatus.
  • the present disclosure relates to a hybrid distribution system that uses an MMT (MPEG Media Transport) method being standardized by MPEG (Moving Picture Expert Group), transmits reference clock information from a transmission side, and receives reference clock information on a reception side.
  • MMT MPEG Media Transport
  • the present invention relates to a method and an apparatus for generating (reproducing) a reference clock.
  • the MMT method is a multiplexing method for multiplexing and packetizing video and audio and transmitting them through one or more transmission paths such as broadcasting or communication.
  • the reference clock on the transmission side is synchronized with NTP (Network Time Protocol) defined in IETF RFC 5905, and based on the reference clock, PTS (Presentation Time Stamp) or DTS (Decode) Give the media a time stamp such as Time Stamp.
  • NTP Network Time Protocol
  • PTS Presentation Time Stamp
  • DTS Decode
  • the reference clock information on the transmission side is transmitted to the reception side, and the reception device generates a reference clock (hereinafter also referred to as a system clock) in the reception device based on the reference clock information.
  • control information such as a message, a table, or a descriptor
  • MMT packet header added.
  • the MMT packet is transmitted through a broadcast transmission path or a communication transmission path by being stored in an IP packet.
  • the MMT packet When transmitting an MMT packet using the advanced BS transmission system defined by the ARIB standard, the MMT packet is encapsulated into an IP packet, the IP packet is encapsulated into a TLV (Type Length Value) packet, and then the advanced BS transmission system is used. Store in the specified transmission slot.
  • TLV Type Length Value
  • the TLV packet is extracted from the transmission slot
  • the IP packet is extracted from the TLV packet
  • the IP packet is extracted from the TLV packet
  • the IP packet Multiple processes such as extracting the MMT packet from the MMT packet and further extracting the reference clock information from the header or payload of the MMT packet, and there are many processes for acquiring the reference clock information, and more time is required until the acquisition. Cost.
  • the processing in the IP layer and higher layers is generally software processing.
  • the reference clock information is stored in the MMT packet, the reference clock information is extracted and reproduced by the software program. In this case, there is a problem that jitter is generated in the acquired reference clock information due to the processing capability of the CPU, interrupts and priorities from other software programs, and the like.
  • a transmission method is a transmission method in content transmission using an IP (Internet Protocol) packet performed through broadcasting, and the first transmission unit in which the IP packet is stored is 1
  • the first transmission unit located at the head in the second transmission unit at the head of at least one of the streams included in the frame includes the first transmission unit, Reference clock information indicating the time for content playback is included.
  • the reception device can change the position of the reference clock information of the at least one stream. It can be specified in advance. Therefore, the receiving apparatus can reduce (simplify) the process of acquiring the reference clock information for the at least one stream.
  • An example of the first transmission unit is a TLV packet
  • an example of the second transmission unit is a slot
  • an example of a transmission frame is a transmission slot.
  • the frame includes a plurality of the streams, and in the generation step, the first transmission unit located at the head in the second transmission unit at the head of each stream included in the frame includes the first transmission unit.
  • Reference clock information indicating the time for reproducing the content may be included.
  • the receiving device specifies the position of each reference clock information of the plurality of streams in advance. can do. Therefore, the receiving apparatus can reduce (simplify) the process of acquiring the reference clock information of each of the plurality of streams.
  • the first transmission unit may be a variable-length transmission unit
  • the second transmission unit may be a fixed-length transmission unit
  • the IP packet stored in the first transmission unit located at the head may be an IP packet not subjected to header compression.
  • the position of the reference clock information can be specified in more detail on the reception side. Therefore, it is possible to simplify the process in which the receiving device acquires the reference clock information.
  • the first transmission unit is a TLV (Type Length Value) packet
  • the second transmission unit is a slot in the advanced BS transmission system
  • the frame is a transmission slot in the advanced BS transmission system. May be.
  • the reference clock information may be NTP (Network Time Protocol).
  • the frame may be transmitted at a predetermined transmission cycle.
  • a reception method is a reception method in content transmission using an IP packet performed through broadcasting, and includes a second transmission unit including one or more first transmission units in which the IP packet is stored.
  • a transmission frame storing a plurality of transmission units, including one or more streams composed of one or more second transmission units, and within at least one second transmission unit at the head of the stream Using the reception step of receiving a frame in which reference clock information is included in the first transmission unit located at the head, extracting the reference clock information from the received frame, and using the extracted reference clock information Generating a clock for reproducing the content.
  • a transmission apparatus is a transmission apparatus used for content transmission using IP packets performed through broadcasting, and stores one or more first transmission units in which the IP packets are stored
  • a generation unit configured to generate a transmission frame storing a plurality of second transmission units; and a transmission unit configured to transmit the generated frame.
  • the frame includes one or more second transmission units. At least one stream included in the frame, and the generation unit is configured to play back the content in a first transmission unit positioned at a head in a second transmission unit at a head of at least one of the streams included in the frame.
  • a receiving apparatus is a receiving apparatus used for content transmission using an IP packet performed through broadcasting, and includes a first transmission unit in which at least one first transmission unit is stored.
  • 2 is a transmission frame storing a plurality of transmission units, and includes at least one stream composed of one or more second transmission units, and at least one second transmission unit at the head of the stream
  • a reception unit that receives a frame in which reference clock information is included in the first transmission unit located at the top of the frame, an extraction unit that extracts the reference clock information from the received frame, and the extracted reference clock information
  • a generation unit for generating a clock for reproducing the content.
  • a recording medium such as a system, an apparatus, a method, an integrated circuit, a computer program, or a computer-readable CD-ROM.
  • a recording medium such as a system, an apparatus, a method, an integrated circuit, a computer program, or a computer-readable CD-ROM.
  • These comprehensive or specific aspects may be realized by any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.
  • FIG. 1 is a diagram illustrating a protocol stack when transmission is performed using the MMT scheme and the advanced BS transmission scheme.
  • MMT MMT
  • MPUs Media Presentation Units
  • MFUs Media Fragment Units
  • an MMT packet header is also attached to control information such as an MMT message to form an MMT packet.
  • the MMT packet header is provided with a field for storing NTP in a 32-bit short format, and this field can be used for QoS control of a communication line.
  • the MMT packetized data is encapsulated in an IP packet having a UDP header or an IP header.
  • IP packets having the same source IP address, destination IP address, source port number, destination port number, and protocol type in the IP header or UDP header is defined as an IP data flow.
  • the plurality of IP packets included have redundant headers. For this reason, in one IP data flow, some IP packets are header-compressed.
  • FIG. 2 is a diagram illustrating a data structure of a TLV packet.
  • the TLV packet stores an IPv4 packet, an IPv6 packet, a compressed IP packet, a NULL packet, and a transmission control signal. These pieces of information are identified using an 8-bit data type. Transmission control signals include, for example, AMT (Address Map Table) and NIT (Network Information Table). In the TLV packet, a 16-bit field is used to indicate the data length (in bytes), and then the data value is stored. Since there is 1-byte header information before the data type (not shown in FIG. 2), the TLV packet has a total header area of 4 bytes.
  • AMT Address Map Table
  • NIT Network Information Table
  • a TLV packet is mapped to a transmission slot in the advanced BS transmission system, and pointers indicating the beginning position of the first packet and the end position of the last packet included in each slot in TMCC (Transmission and Multiplexing Configuration Control) control information / Slot information is stored.
  • TMCC Transmission and Multiplexing Configuration Control
  • FIG. 3 is a block diagram showing a basic configuration of the receiving apparatus. Note that the configuration of the receiving apparatus in FIG. 3 is simplified, and a more specific configuration will be described later separately according to the manner in which the reference clock information is stored.
  • the receiving device 20 includes a receiving unit 10, a decoding unit 11, a TLV demultiplexer (DEMUX) 12, an IP demultiplexer (DEMUX) 13, and an MMT demultiplexer (DEMUX) 14.
  • a receiving unit 10 includes a receiving unit 10, a decoding unit 11, a TLV demultiplexer (DEMUX) 12, an IP demultiplexer (DEMUX) 13, and an MMT demultiplexer (DEMUX) 14.
  • the receiving unit 10 receives transmission path encoded data.
  • the decoding unit 11 decodes the transmission path encoded data received by the receiving unit 10, performs error correction, and extracts a TMCC control signal and TLV data.
  • the TLV data extracted by the decoding unit 11 is subjected to DEMUX processing by the TLV demultiplexer 12.
  • the DEMUX process of the TLV demultiplexer 12 differs depending on the data type. For example, when the data type is a compressed IP packet, the TLV demultiplexer 12 performs processing such as restoring the compressed header and passing it to the IP layer.
  • the IP demultiplexer 13 performs processing such as header analysis of IP packets or UDP packets, and extracts MMT packets for each IP data flow.
  • the MMT demultiplexer 14 performs a filtering process (MMT packet filtering) based on the packet ID stored in the MMT packet header.
  • MMT packet filtering a filtering process
  • a descriptor, a table, or a message for storing reference clock information is defined and stored in an MMT packet as control information
  • a descriptor, a table indicating reference clock information, or an identifier indicating a message is control information. Shown in The control information is stored in the MMT packet on the transmission side.
  • the receiving device 20 can identify the reference clock information based on the identifier.
  • the reference clock information may be stored in the MMT packet by using an existing descriptor (for example, CRI_descriptor ()).
  • extension field For example, there is a method of storing using a header_extension field (hereinafter referred to as an extension field).
  • the extension field is enabled by setting the extension_flag of the MMT packet header to “1”.
  • an extension field type indicating the data type of data stored in the extension field is stored, and in the extension field type, information indicating reference clock information (for example, 64-bit long format NTP) is stored. There is a method of storing the reference clock information in the extension field.
  • the receiving device 20 refers to the extension field of the MMT packet. If the extended field type indicates that it is reference clock information, the reference clock information is extracted and the clock is reproduced.
  • reference clock information may be stored in an existing header field. Further, when there are unused fields or when there are fields that are not necessary for broadcasting, the reference clock information may be stored in these fields.
  • the reference clock information may be stored using both the existing field and the extension field.
  • an existing 32-bit short format NTP field and an extension field may be used in combination.
  • the reference clock information is, for example, the time when the first bit of the MMT packet in which the reference clock information is stored passes through a predetermined position (for example, when output from a specific component of the transmission apparatus). However, the time when a bit at another position passes a predetermined position may be used.
  • the MMT packet including the control information is transmitted at a predetermined transmission interval.
  • the reference clock information is stored in the extension field of the MMT packet, it is stored in the extension field of the header of the predetermined MMT packet. Specifically, for example, at least one reference clock information is stored in the header extension field of the MMT packet at intervals of 100 ms.
  • the program information stores the packet ID of the MMT in which the reference clock information is stored.
  • the receiving device 20 analyzes the program information and acquires an MMT packet in which the reference clock information is stored.
  • the packet ID of the MMT packet storing the reference clock information may be defined in advance as a fixed value. Thereby, the receiving device 20 can acquire the reference clock information without analyzing the program information.
  • FIG. 4 is a block diagram illustrating a functional configuration of the reception device 20 when the reference clock information is stored in the extension field of the MMT packet header.
  • FIG. 5 is a diagram illustrating an acquisition flow of the reference clock information of the reception device 20 when the reference clock information is stored in the extension field of the MMT packet header.
  • the MMT demultiplexer 14 when the reference clock information is stored in the extension field of the MMT packet header, the MMT demultiplexer 14 is provided with a reference clock information extraction unit 15 (an example of an extraction unit).
  • a reference clock generation unit 16 (an example of a generation unit) is provided at the subsequent stage of the multiplexer 14.
  • the decoding unit 11 of the receiving device 20 decodes the transmission path encoded data received by the receiving unit 10 (S101), and extracts the TLV packet from the transmission slot (S102).
  • the TLV demultiplexer 12 performs DEMUX on the extracted TLV packet and extracts an IP packet (S103). At this time, the header of the compressed IP packet is reproduced.
  • the IP demultiplexer 13 demultiplexes the IP packet, acquires the designated IP data flow, and extracts the MMT packet (S104).
  • the MMT demultiplexer 14 analyzes the header of the MMT packet and determines whether or not the extension field is used and whether or not there is reference clock information in the extension field (S106). If there is no reference clock information in the extension field (No in S106), the process is terminated.
  • the reference clock information extraction unit 15 extracts the reference clock information from the extension field (S107). Then, the reference clock generation unit 16 generates a system clock based on the extracted reference clock information (S108). In other words, the system clock is a clock for reproducing content.
  • FIG. 6 is a block diagram illustrating a functional configuration of the receiving device 20 when the reference clock information is stored in the control information.
  • FIG. 7 is a diagram illustrating an acquisition flow of the reference clock information of the reception device 20 when the reference clock information is stored in the control information.
  • the reference clock information extraction unit 15 is arranged at the subsequent stage of the MMT demultiplexer 14.
  • step S111 to step S114 is the same as the flow of step S101 to step S104 described in FIG.
  • the MMT demultiplexer 14 acquires the packet ID of the packet including the reference clock information from the program information (S115), and acquires the MMT packet of the packet ID (S116). Subsequently, the reference clock information extraction unit 15 extracts the reference clock information from the control signal included in the extracted MMT packet (S117), and the reference clock generation unit 16 obtains the system clock based on the extracted reference clock information. Generate (S118).
  • the receiving apparatus 20 extracts the TLV packet from the transmission slot, and the TLV Extract the IP packet from the packet. Further, the receiving device 20 extracts the MMT packet from the IP packet, and further extracts the reference clock information from the header or payload of the MMT packet. As described above, when the reference clock information is stored in the MMT packet, there are many processes for acquiring the reference clock information, and more time is required for the acquisition.
  • processing for assigning a time stamp to media such as video and audio based on the reference clock and processing for transmitting the media are realized using the MMT method, and transmission of the reference clock information is performed lower than the MMT layer.
  • a method performed using a lower layer, a lower protocol, or a lower multiplexing scheme will be described.
  • FIG. 8 is a block diagram illustrating a configuration of the reception device 20 when the reference clock information is stored in the TLV packet.
  • FIG. 8 is different from FIGS. 4 and 6 in the arrangement of the reference clock information extraction unit 15 and the reference clock generation unit 16.
  • the synchronization unit 17 and the decryption presentation unit 18 are also illustrated.
  • the TLV packet is composed of an 8-bit data type, a 16-bit data length, and 8 * N-bit data.
  • a 1-byte header (not shown in FIG. 2) is present before the data type.
  • the data type is specifically defined as, for example, 0x01: IPv4 packet, 0x03: header compressed IP packet, and the like.
  • the data type is defined using the undefined area of the data type.
  • the data type is described to indicate that the data is the reference clock information.
  • FIG. 9 is a diagram illustrating an example in which the long format NTP is stored in the TLV packet, and the long format NTP is stored in the data field.
  • the reference clock information extraction unit 15 analyzes the data type of the TLV packet, and when the reference clock information is stored, analyzes the data length and extracts the reference clock information from the data field.
  • the reference clock information extraction unit 15 may acquire the reference clock information without analyzing the data length field. For example, when it is indicated that the data type is 64 bit long low mat NTP, the reference clock information extraction unit 15 may extract the 4th byte + 1 bit to the 4th byte + 64th bit. Further, the reference clock information extraction unit 15 may extract only desired bits from the 64-bit data.
  • FIG. 10 is a diagram illustrating an acquisition flow of the reference clock information of the reception device 20 when the reference clock information is stored in the TLV packet.
  • the decoding unit 11 decodes the transmission path encoded data received by the receiving unit 10 (S121), and extracts the TLV packet from the transmission slot (S122).
  • the TLV demultiplexer 12 analyzes the data type of the TLV packet (S123), and determines whether the data type is reference clock information (S124).
  • the reference clock information extraction unit 15 extracts the reference clock information from the data field of the TLV packet (S125).
  • the reference clock generation unit 16 generates a system clock based on the reference clock information (S126).
  • the reference clock information acquisition flow ends.
  • the IP demultiplexer 13 extracts the IP packet according to the data type. Then, the IP DEMUX process and the MMT DEMUX process are performed on the extracted IP packet to extract the MMT packet. Further, the synchronization unit 17 outputs the video data to the decoding presentation unit 18 at a timing when the time stamp of the video data included in the extracted MMT packet matches the reference clock generated in step S126, and the decoding presentation unit 18 Decodes and presents video data.
  • the reference clock information is stored in the type data of the TLV packet, and the reference clock information is stored in the data field of the TLV packet.
  • the reference clock information is stored in the data field of the TLV packet.
  • the reference clock information can be extracted and reproduced in lower layers across the IP layer, the reference clock information can be extracted by hardware implementation. As a result, the influence of jitter and the like can be reduced as compared with the case where the extraction of the reference clock information is performed by software implementation, and a reference clock with higher accuracy can be generated.
  • the data length field may not be transmitted.
  • an identifier indicating that the data length field is data that is not transmitted is stored.
  • the reference clock information is stored in the data field of the TLV packet.
  • the reference clock information may be added immediately before or after the TLV packet.
  • the reference clock information may be added immediately before or after the data stored in the TLV packet. In these cases, a data type that can identify the location where the reference clock information is added is assigned.
  • FIG. 11 is a diagram showing a configuration in which the reference clock information is added immediately before the header of the IP packet.
  • the data type indicates an IP packet with reference clock information.
  • the receiving device 20 sets a predetermined reference clock information length from the beginning of the data field of the TLV packet. By extracting the bits, reference clock information can be acquired.
  • the data length may specify the length of data including the length of the reference clock information, or may specify the length not including the length of the reference clock information.
  • the receiving device 20 When the data length including the length of the reference clock information is designated as the data length, the receiving device 20 (reference clock information extraction unit 15) has a length obtained by subtracting the length of the reference clock information from the data length. Data is acquired immediately after the reference clock information. When the data length that does not include the length of the reference clock information is specified, the receiving device 20 (reference clock information extraction unit 15) uses the data of the length specified in the data length as the reference clock. Obtained immediately after information.
  • FIG. 12 is a diagram showing a configuration in which the reference clock information is added immediately before the TLV packet.
  • the data type is a conventional data type
  • an identifier indicating that the TLV packet is a TLV packet with reference clock information is stored in, for example, the slot header of the transmission slot or TMCC control information.
  • FIG. 13 is a diagram illustrating a configuration of a transmission slot
  • FIG. 14 is a diagram illustrating a configuration of a slot header of the transmission slot.
  • the transmission slot is composed of a plurality of slots (in the example of FIG. 13, 120 slots of Slot # 1-Slot # 120).
  • the number of bits included in each slot is a fixed number of bits uniquely determined based on the error correction coding rate, has a slot header, and stores one or more TLV packets.
  • the TLV packet has a variable length.
  • the transmission slot is composed of 120 slots per frame, and the modulation scheme is assigned to the slot in units of 5 slots.
  • a maximum of 16 streams can be transmitted within one frame. Note that, for a plurality of streams included in one transmission slot, for example, content transmitted by the stream (or a provider providing the content) is different from each other.
  • a stream is composed of one or more slots, and one slot does not span a plurality of streams.
  • the slot header When an identifier indicating that the TLV packet is a TLV packet with reference clock information is stored in the slot header, for example, information that can specify the position of the TLV packet with reference clock information in the slot, the type of reference clock information, and data The length and the like are stored by extending (using) the undefined field of the slot header.
  • the slot header A flag may be stored in the undefined area.
  • FIG. 15 is a diagram illustrating an example in which a flag is stored in an undefined area of the slot header.
  • a flag (denoted as “F” in the figure) indicating whether or not the reference clock information is included in the slot is stored in the undefined area of the slot header. Based on such a flag, the reception apparatus 20 may determine that the leading TLV packet is a TLV packet with reference clock information.
  • FIG. 16 is a diagram showing a configuration of TMCC control information in the transmission system of the advanced broadband satellite digital broadcasting.
  • Information for specifying and referring to the TLV packet with reference clock information may be stored in the extended information in the TMCC control information shown in FIG. 16, or may be stored in other places in the TMCC control information.
  • the stream type / relative stream information of the TMCC control information may be used as information for specifying and referring to the TLV packet with the reference clock information.
  • FIG. 17 is a diagram illustrating stream type / relative stream information of TMCC control information.
  • the stream type for each of the 16 streams is indicated by 8 bits. That is, according to the transmission slot of one frame, a maximum of 16 streams (16 types) can be transmitted. For example, the stream type of the MPEG2-TS stream is “00000000”, and the stream type of the TLV stream is “00000010”. However, for other streams, there is currently no allocation type or is undefined.
  • the stream type of the TLV stream with the reference clock is defined as, for example, “00000100”, and “00000100” is stored in the stream type / relative stream information of the TMCC control information when the relative stream is the TLV stream with the reference clock.
  • a TLV packet including the reference clock information is stored once every 5 slots as a slot allocation unit or once every frame. .
  • the receiving device 20 analyzes the stream type / relative stream information of the TMCC control information.
  • the receiving device 20 receives the TLV packet with the reference clock from the predetermined slot. get.
  • the receiving apparatus 20 may determine that the reference clock information is included in the stream when the stream type of the received stream is a stream type TLV packet. This is because the reference clock information is not normally used in the reproduction of the download type TLV packet.
  • TMCC control information When information for specifying and referring to a TLV packet with reference clock information is stored in the extended information of TMCC control information, for example, information for each of 16 relative streams is stored in the extended area of TMCC control information.
  • FIG. 18 is a diagram illustrating an example in which the reference clock information is stored in the undefined field of the slot header.
  • the reference clock information may be stored in a predetermined slot, or information indicating that the reference clock information is included in the slot header.
  • the predetermined slot is, for example, the first slot (Slot # 1 in the example of FIG. 13) of the transmission slots, and the reference clock stored in the IP packet in the first TLV packet in this slot. Information may be included.
  • the predetermined slot is, for example, the first slot of each stream included in the transmission slot, and is stored in the IP packet in the first TLV packet in this slot.
  • Reference clock information may also be included.
  • TMCC control information may store information for specifying and referring to the slot header including the reference clock information.
  • the method for storing the information for specifying and referring to the slot header including the reference clock information in the TMCC control information is the same as the method for storing the information for specifying and referring to the TLV packet with the reference clock information described above. Therefore, explanation is omitted.
  • the receiving apparatus 20 analyzes the TMCC control signal and extracts the reference clock information from the slot header when it is determined that the slot header has the reference clock information.
  • FIG. 19 is a block diagram illustrating a functional configuration of the reception device 20 when information indicating that the reference clock information is included in the slot header is stored in the TMCC control information.
  • FIG. 20 is a diagram illustrating an acquisition flow of the reference clock information when information indicating that the reference clock information is included in the slot header is stored in the TMCC control information.
  • the reference clock information extraction unit 15 is connected to the decoding unit 11. A reference clock signal is obtained from the output transmission slot.
  • the decoding unit 11 decodes the transmission path encoded data (S131), analyzes the TMCC control signal (S132), and determines whether there is reference clock information in the slot header in the transmission slot. (S133). If there is reference clock information in the slot header (Yes in S133), the reference clock information extraction unit 15 extracts the reference clock information from the slot header (S134), and the reference clock generation unit 16 uses the reference clock information based on the reference clock information. A system reference clock (system clock) is generated (S135). On the other hand, if there is no reference clock information in the slot header (No in S133), the reference clock information acquisition flow ends.
  • system clock system clock
  • Such a receiving apparatus 20 can acquire the reference clock information at the layer of the transmission slot, it can acquire the reference clock information even earlier than the case where it is stored in the TLV packet.
  • the reference clock information in the TLV packet or the transmission slot, it is possible to reduce the processing until the reference clock information is acquired in the receiving device 20, and the acquisition time of the reference clock information. Can be shortened.
  • the reference clock information is stored in the physical layer in this way, acquisition and reproduction of the reference clock information by hardware can be easily realized, and a clock with higher accuracy than acquisition and reproduction of the reference clock information by software. Playback is possible.
  • the transmission method according to the first embodiment can be summarized as follows.
  • a system including a plurality of layers (protocols) including the IP layer the time stamp of the media is obtained based on the reference clock information in a layer higher than the IP layer.
  • reference clock information is transmitted in a layer lower than the IP layer. According to such a configuration, it becomes easy for the receiving device 20 to process the reference clock information by hardware.
  • the time at which the first bit of the TLV packet is transmitted on the transmission side is stored as the reference clock information. Further, a predetermined time other than the transmission time of the first bit may be stored as the reference clock information.
  • TLV packets including reference clock information are transmitted at predetermined intervals.
  • the TLV packet including the reference clock information is included in the transmission slot and transmitted at a predetermined transmission cycle.
  • at least one reference clock information may be stored and transmitted in a TLV packet at 100 ms intervals.
  • TLV packets including reference clock information may be arranged at predetermined intervals at predetermined locations in the transmission slot of the advanced BS transmission system.
  • a TLV packet including reference clock information is stored once every 5 slot units, which is a slot allocation unit of the TLV packet, and the reference clock information is stored in the first TLV packet of the first slot among the 5 slot units. May be. That is, the TLV packet including the reference clock information may be arranged at the head of the head slot in the transmission slot (that is, immediately after the slot header).
  • TLV packets including reference clock information may be arranged at predetermined intervals at predetermined locations in transmission slots of the transmission system of the advanced broadband satellite digital broadcasting.
  • the reference clock information may be stored in the first TLV packet of the first slot once every five slots that are slot allocation units. That is, the reference clock information may be included in the TLV packet positioned at the head in the head slot of each stream included in the transmission slot. Further, the reference clock information may be stored in the first slot in the relative stream.
  • the transmission cycle and the transmission interval of the reference clock information may be changed according to the modulation scheme or coding rate of the transmission path coding scheme.
  • a method for storing reference clock information in an upper layer such as an MMT packet and storing the MMT packet in which the reference clock information is stored in an IP packet will be described.
  • an MMT packet that is an upper layer is directly referenced from a lower layer such as a TLV packet.
  • the reference clock information included in the MMT packet is acquired without performing normal DEMUX processing.
  • the reference clock information is included in the control information stored in the MMT packet described above.
  • a predetermined packet ID is assigned to the control information including the reference clock information.
  • the MMT packet including the reference clock information is stored in a dedicated IP data flow, and the transmission source IP address, destination IP address, transmission source port number, destination port number, and protocol are determined in advance. A type is given.
  • the TLV demultiplexer 12 can extract an IP packet including reference clock information by acquiring a predetermined IP data flow. .
  • the receiving device 20 can extract the IP packet including the reference clock information by referring to the context identifier of the compressed IP packet header.
  • an IP packet including reference clock information may be specified not to be header-compressed, or may be specified to be necessarily header-compressed.
  • a predetermined context identifier may be assigned to the IP packet including the reference clock information, and it may be defined that all headers are compressed.
  • an identifier indicating that the packet is an IP packet belonging to an IP data flow including reference clock information in the data type field of TLV, or an identifier indicating a compressed IP packet belonging to an IP data flow including reference clock information, etc. It is also possible to define The method will be described below.
  • the receiving device 20 determines the TLV data type, and if it is determined that the reference clock information is included, the receiving device 20 directly acquires the reference clock information included in the MMT packet from the IP packet.
  • the receiving device 20 extracts the reference clock information included in the MMT packet by extracting the bit string at the specific position from the IP packet or the compressed IP packet without analyzing the IP address, the port number, or the context identifier. May be.
  • Extracting a bit string at a specific position means, for example, extracting information for a specific length from a position offset by a fixed-length byte from a TLV packet header, and thereby acquiring reference clock information.
  • the fixed length byte offset length for extracting the reference clock information is uniquely determined for each of the IP packet and the compressed IP packet. Therefore, after determining the TLV data type, the receiving apparatus 20 can acquire the reference clock information by immediately extracting information for a specific length from the position offset by a fixed-length byte.
  • the upper layer reference clock information may be acquired from the lower layer by defining other protocols and identifiers.
  • an identifier indicating whether or not the reference clock information is included in the IP packet may be stored in a field other than the TLV data type.
  • the reference time information included in the MMT packet may be extracted by extracting a bit string at a specific position from the IP packet or the compressed IP packet without analyzing the IP address, the port number, and the context identifier.
  • FIG. 21 is a diagram illustrating a flow when a bit string at a specific position is extracted from an IP packet or a compressed IP packet. Note that the configuration of the receiving device 20 in this case is the same as the block diagram shown in FIG.
  • the decoding unit 11 decodes transmission path encoded data received by the receiving unit 10 (S141), and extracts a TLV packet from the transmission path slot (S142).
  • the TLV demultiplexer 12 analyzes the data type of the TLV packet (S143), and determines whether the data type is an IP including the reference clock information (S144). If it is determined that the data type is not an IP packet including reference clock information (No in S144), the flow ends. When it is determined that the data type is an IP packet including the reference clock information (Yes in S144), the IP packet and the MMT packet are analyzed to determine whether the IP header is compressed (S145).
  • reference clock information included in the MMT packet at a position offset by a fixed length N bytes from the TLV header is acquired (S146). If the IP header is compressed (Yes in S145), reference clock information included in the MMT packet at a position offset by a fixed length M bytes from the TLV header is acquired (S147).
  • the reference clock generation unit 16 generates a system clock based on the reference clock information (S148).
  • the data structure of the IP packet header differs depending on whether the IP packet is IPv4 or IPv6, the fixed length N bytes and M bytes have different values.
  • Normal MMT packets including audio, video, and control signals are subjected to DEMUX processing in normal steps, whereas MMT packets including reference clock information are collectively processed by DEMUX processing from a lower layer to an upper layer. Done. Thereby, even if the reference clock information is stored in the upper layer, the reference clock information can be acquired in the lower layer. That is, the processing for acquiring the reference clock information can be reduced, the time until acquisition of the reference clock information can be shortened, and the hardware can be easily implemented.
  • a plurality of reference clock information may be transmitted in one or more layers.
  • the receiving device 20 may select either one of the reference clock information and use it to generate a reference clock (system clock), or use both to generate the reference clock. It may be generated.
  • the receiving device 20 may select highly accurate reference clock information, or may select reference clock information that can be acquired earlier.
  • the reception device 20 can reproduce the 32-bit short format NTP, the NTP field included in the conventional MMT packet header is unnecessary. For this reason, other information may be stored in the NTP field, or header compression may be performed by reducing the NTP field.
  • header compression information indicating that the NTP field has been reduced is transmitted.
  • the receiving apparatus 20 When the NTP field is reduced, the receiving apparatus 20 generates a reference clock using other reference clock information and reproduces a 32-bit short format NTP.
  • the communication receiving apparatus may use the 32-bit short format NTP for QoS control and may not use the reference clock information. Therefore, the reference clock information may not be transmitted on the communication transmission path. If the end-to-end delay of the communication transmission path is within a certain range, the reference clock information may be used for clock recovery.
  • the case where the MMT / IP / TLV method is used has been described as an example.
  • a method other than the MMT method may be used as the multiplexing method.
  • the present disclosure can be applied to the MPEG2-TS system, the RTP system, or the MPEG-DASH system.
  • RoHC Robot Header Compression
  • HCfB Header Compression for Broadcasting
  • GSE Generic Stream Encapsulation
  • ULE Uniform Light-weight. Encapsulation
  • the present disclosure can be applied to any of the above-described methods.
  • the time until acquisition of the reference clock information in the receiving device 20 is reduced, the processing is reduced, and the hardware is implemented. High accuracy of the clock can be realized.
  • FIG. 22 is a block diagram illustrating a functional configuration of the transmission apparatus.
  • FIG. 23 is a diagram illustrating an operation flow of the transmission apparatus.
  • the transmission device 30 includes a generation unit 31 and a transmission unit 32.
  • the components of the transmission device 30 are specifically realized by a microcomputer, a processor, a dedicated circuit, or the like.
  • the transmission device 30 is specifically a broadcast server, and is an example of the “transmission side” in the first embodiment.
  • the generation unit 31 generates, for example, a transmission slot that stores a plurality of slots in which one or more TLV packets in which IP packets are stored are stored (S151 in FIG. 23).
  • the transmission slot includes a plurality of relative streams including one or more slots.
  • the generation unit 31 reproduces content (for example, broadcast content such as video or audio) in the receiving device 20 in the TLV packet positioned at the head in the head slot of each relative stream included in the transmission slot.
  • Reference clock information such as NTP indicating the time of the current time is included.
  • the generation unit 31 includes an encoding unit that encodes broadcast content, an MMT multiplexer, an IP multiplexer, a TLV multiplexer, and the like.
  • the TLV packet is an example of a first transmission unit
  • the slot is an example of a second transmission unit
  • the transmission slot is an example of a transmission frame.
  • a relative stream is an example of a stream.
  • the transmission unit 32 transmits the transmission slot (transmission path encoded data including the transmission slot) generated by the generation unit 31 through broadcasting (S152 in FIG. 23).
  • the reception apparatus 20 includes a plurality of reception clocks by including the reference clock information in the TLV packet positioned at the head of each relative stream in the transmission slot.
  • the process of acquiring the reference clock information for each stream can be simplified. Therefore, it is possible to shorten the time until the receiving device 20 acquires the reference clock information.
  • each component may be configured by dedicated hardware or may be realized by executing a software program suitable for each component.
  • Each component may be realized by a program execution unit such as a CPU or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory.
  • Each component may be a circuit. These circuits may constitute one circuit as a whole, or may be separate circuits. Each of these circuits may be a general-purpose circuit or a dedicated circuit.
  • another processing unit may execute a process executed by a specific processing unit.
  • the order of the plurality of processes may be changed, and the plurality of processes may be executed in parallel.
  • reception device reception method
  • transmission device transmission method
  • the transmission method of the present disclosure is useful as a transmission method that can reduce processing for acquiring reference clock information on the receiving side when the MMT method is applied to a broadcasting system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

　放送を通じて行われるＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）パケットを用いたコンテンツの伝送における送信方法であって、ＩＰパケットが格納される第１の伝送単位が１以上格納された第２の伝送単位を複数格納した伝送用のフレームを生成する生成ステップと、生成されたフレームを送信する送信ステップとを含み、フレームには、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、生成ステップにおいては、フレームに含まれる少なくとも１つのストリームの先頭の第２の伝送単位において先頭に位置する第１の伝送単位に、受信側においてコンテンツの再生のための時刻を示す基準クロック情報を含める。

Description

送信方法、受信方法、送信装置、及び受信装置
　本開示は、ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）パケットを用い、放送を通じてコンテンツを伝送する場合の送信方法等に関する。
　ＭＭＴ方式（非特許文献１参照）は、映像及び音声などのコンテンツを多重化及びパケット化し、放送または通信などの一つ以上の伝送路で送信するための多重化方式である。ＭＭＴ方式を放送システムに適用する場合、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置におけるシステムクロックを生成する。
Ｉｎｆｏｒｍａｔｉｏｎ　ｔｅｃｈｎｏｌｏｇｙ　－　Ｈｉｇｈ　ｅｆｆｉｃｉｅｎｃｙ　ｃｏｄｉｎｇ　ａｎｄ　ｍｅｄｉａ　ｄｅｌｉｖｅｒｙ　ｉｎ　ｈｅｔｅｒｏｇｅｎｅｏｕｓ　ｅｎｖｉｒｏｎｍｅｎｔ　－　Ｐａｒｔ１：ＭＰＥＧ　ｍｅｄｉａ　ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ　ＤＩＳ　２３００８－１
　本開示の一態様に係る送信方法は、放送を通じて行われるＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）パケットを用いたコンテンツの伝送における送信方法であって、前記ＩＰパケットが格納される第１の伝送単位が１以上格納された第２の伝送単位を複数格納した伝送用のフレームを生成する生成ステップと、生成された前記フレームを送信する送信ステップとを含み、前記フレームには、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、前記生成ステップにおいては、前記フレームに含まれる少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に、前記コンテンツの再生のための時刻を示す基準クロック情報を含める。
　なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよい。また、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
　本開示の一態様に係る送信方法等によれば、受信側で基準クロック情報を取得するための処理を軽減することができる。
図１は、ＭＭＴ方式及び高度ＢＳ伝送方式を用いて伝送を行う場合のプロトコルスタック示す図である。 図２は、ＴＬＶパケットのデータ構造を示す図である。 図３は、受信装置の基本構成を示すブロック図である。 図４は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置の機能構成を示すブロック図である。 図５は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図６は、制御情報に基準クロック情報が格納される場合の受信装置の機能構成を示すブロック図である。 図７は、制御情報に基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図８は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置の構成を示すブロック図である。 図９は、ロングフォーマットＮＴＰがＴＬＶパケットに格納される例を示す図である。 図１０は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図１１は、ＩＰパケットのヘッダの直前に基準クロック情報が付加される構成を示す図である。 図１２は、ＴＬＶパケットの直前に基準クロック情報が付加される構成を示す図である。 図１３は、伝送スロットの構成を示す図である。 図１４は、伝送スロットのスロットヘッダの構成を示す図である。 図１５は、スロットヘッダの未定義領域にフラグが格納される例を示す図である。 図１６は、高度広帯域衛星デジタル放送の伝送方式におけるＴＭＣＣ制御情報の構成を示す図である。 図１７は、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報を示す図である。 図１８は、スロットヘッダの未定義フィールドに基準クロック情報が格納される例を示す図である。 図１９は、ＴＭＣＣ制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置の機能構成を示すブロック図である。 図２０は、スロットヘッダに基準クロック情報を含むことを示す情報がＴＭＣＣ制御情報に格納される場合の基準クロック情報の取得フローを示す図である。 図２１は、ＩＰパケットまたは圧縮ＩＰパケットから特定位置のビット列を抽出する場合のフローを示す図である。 図２２は、送信装置の機能構成を示すブロック図である。 図２３は、送信装置の動作フローを示す図である。
　（本開示の基礎となった知見）
　本開示は、ＭＰＥＧ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　Ｅｘｐｅｒｔ　Ｇｒｏｕｐ）で規格化中のＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）方式を用いるハイブリッド配信システムにおいて、送信側から基準クロック情報を送信し、受信側で基準クロック情報を受信し、基準クロックを生成（再生）する方法及び装置に関する。
　ＭＭＴ方式は、映像及び音声を多重化及びパケット化し、放送または通信などの一つ以上の伝送路で送信するための多重化方式である。
　ＭＭＴ方式を放送システムに適用する場合、送信側の基準クロックをＩＥＴＦ　ＲＦＣ　５９０５に規定されるＮＴＰ（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）に同期させ、基準クロックを基に、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｔｉｍｅ　Ｓｔａｍｐ）や、ＤＴＳ（Ｄｅｃｏｄｅ　Ｔｉｍｅ　Ｓｔａｍｐ）などのタイムスタンプをメディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置における基準クロック（以下、システムクロックとも記載する）を生成する。
　放送システムでは、基準クロック情報として絶対時刻を示すことの可能な６４ビットのロングフォーマットＮＴＰが使用されることが望ましい。しかし、従来のＭＭＴ方式では、ＭＭＴパケットヘッダに３２ビットのショートフォーマットＮＴＰを格納して伝送することは規定されているが、ロングフォーマットＮＴＰを伝送することは規定されておらず、受信機側で精度のよい基準クロック情報を取得することができない。
　これに対し、メッセージ、テーブル、または記述子などの制御情報としてロングフォーマットＮＴＰを定義し、制御情報にＭＭＴパケットヘッダを付加して伝送することが可能である。この場合、ＭＭＴパケットは、ＩＰパケットに格納されるなどして放送伝送路または通信伝送路を通じて伝送される。
　ＭＭＴパケットをＡＲＩＢ規格で規定される高度ＢＳ伝送方式を用いて伝送する場合、ＭＭＴパケットをＩＰパケットへカプセル化し、ＩＰパケットをＴＬＶ（Ｔｙｐｅ　Ｌｅｎｇｔｈ　Ｖａｌｕｅ）パケットへカプセル化した後、高度ＢＳ伝送方式で規定される伝送スロットへと格納する。
　しかし、送信側においてＭＭＴパケットのレイヤに基準クロック情報を格納した場合、受信側で基準クロック情報を得るためには、伝送スロットからＴＬＶパケットを抽出し、ＴＬＶパケットからＩＰパケットを抽出し、ＩＰパケットからＭＭＴパケットを抽出し、さらにＭＭＴパケットのヘッダまたはペイロードから基準クロック情報を抽出する、といった複数の処理が必要であり、基準クロック情報を取得するための処理が多く、さらに取得までにより多くの時間を要する。
　また、ＩＰレイヤ以上のレイヤにおける処理はソフトウェア処理であることが一般的であり、ＭＭＴパケットに基準クロック情報が格納されている場合、ソフトウェアプログラムによって基準クロック情報が抽出及び再生される。この場合、ＣＰＵの処理能力や、他のソフトウェアプログラムからの割り込みや優先度などによって、取得する基準クロック情報にジッタが生じることが課題である。
　そこで、本開示の一態様に係る送信方法は、放送を通じて行われるＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）パケットを用いたコンテンツの伝送における送信方法であって、前記ＩＰパケットが格納される第１の伝送単位が１以上格納された第２の伝送単位を複数格納した伝送用のフレームを生成する生成ステップと、生成された前記フレームを送信する送信ステップとを含み、前記フレームには、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、前記生成ステップにおいては、前記フレームに含まれる少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に、前記コンテンツの再生のための時刻を示す基準クロック情報を含める。
　このように、伝送スロットに含まれる少なくとも１つのストリームの先頭のスロット内の先頭に位置するＴＬＶパケットに基準クロック情報を含めることで、受信装置は、当該少なくとも１つのストリームの基準クロック情報の位置をあらかじめ特定することができる。したがって、受信装置は、上記少なくとも１つのストリームに対する、基準クロック情報を取得する処理を軽減（簡素化）できる。なお、第１の伝送単位の一例は、ＴＬＶパケットであり、第２の伝送単位の一例は、スロットであり、伝送用のフレームの一例は、伝送スロットである。
　また、前記フレームには、前記ストリームが複数含まれ、前記生成ステップにおいては、前記フレームに含まれる各前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に、前記コンテンツの再生のための時刻を示す基準クロック情報を含めてもよい。
　このように、伝送スロットに含まれる各ストリームの先頭のスロット内の先頭に位置するＴＬＶパケットに基準クロック情報を含めることで、受信装置は、複数のストリームのそれぞれの基準クロック情報の位置をあらかじめ特定することができる。したがって、受信装置は、複数のストリームそれぞれの基準クロック情報を取得する処理を軽減（簡素化）できる。
　また、前記第１の伝送単位は、可変長の伝送単位であり、前記第２の伝送単位は、固定長の伝送単位であってもよい。
　また、前記先頭に位置する第１の伝送単位に格納されるＩＰパケットは、ヘッダ圧縮されていないＩＰパケットであってもよい。
　このように、送信側でＩＰパケットのヘッダ圧縮の有無を規定することにより、受信側で基準クロック情報の位置をさらに詳しく特定することができる。したがって、受信装置が基準クロック情報を取得する処理を簡素化できる。
　また、前記第１の伝送単位は、ＴＬＶ（Ｔｙｐｅ　Ｌｅｎｇｔｈ　Ｖａｌｕｅ）パケットであり、前記第２の伝送単位は、高度ＢＳ伝送方式におけるスロットであり、前記フレームは、高度ＢＳ伝送方式における伝送スロットであってもよい。
　また、前記基準クロック情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）であってもよい。
　また、前記送信ステップにおいては、前記フレームを所定の送信周期で送信してもよい。
　本開示の一態様に係る受信方法は、放送を通じて行われるＩＰパケットを用いたコンテンツの伝送における受信方法であって、前記ＩＰパケットが格納される第１の伝送単位が１以上含まれる第２の伝送単位を複数格納した伝送用のフレームであって、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、かつ、少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に基準クロック情報が含まれるフレームを受信する受信ステップと、受信された前記フレームから前記基準クロック情報を抽出するステップと、抽出された前記基準クロック情報を用いて前記コンテンツを再生するためのクロックを生成する生成ステップとを含む。
　本開示の一態様に係る送信装置は、放送を通じて行われるＩＰパケットを用いたコンテンツの伝送に用いられる送信装置であって、前記ＩＰパケットが格納される第１の伝送単位が１以上格納された第２の伝送単位を複数格納した伝送用のフレームを生成する生成部と、生成された前記フレームを送信する送信部とを備え、前記フレームには、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、前記生成部は、前記フレームに含まれる少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に、前記コンテンツの再生のための時刻を示す基準クロック情報を含める。
　本開示の一態様に係る受信装置は、放送を通じて行われるＩＰパケットを用いたコンテンツの伝送に用いられる受信装置であって、前記ＩＰパケットが格納される第１の伝送単位が１以上含まれる第２の伝送単位を複数格納した伝送用のフレームであって、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、かつ、少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に基準クロック情報が含まれるフレームを受信する受信部と、受信された前記フレームから前記基準クロック情報を抽出する抽出部と、抽出された前記基準クロック情報を用いて前記コンテンツを再生するためのクロックを生成する生成部とを備える。
　なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよい。また、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　（実施の形態１）
　［ＭＭＴ方式の基本的な構成］
　まず、ＭＭＴ方式の基本的な構成について説明する。図１は、ＭＭＴ方式及び高度ＢＳ伝送方式を用いて伝送を行う場合のプロトコルスタックを示す図である。
　ＭＭＴ方式では、映像や音声などの情報を、複数のＭＰＵ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｕｎｉｔ）や複数のＭＦＵ（Ｍｅｄｉａ　Ｆｒａｇｍｅｎｔ　Ｕｎｉｔ）に格納し、ＭＭＴパケットヘッダを付与してＭＭＴパケット化する。
　一方、ＭＭＴ方式では、ＭＭＴメッセージなどの制御情報に対してもＭＭＴパケットヘッダを付与し、ＭＭＴパケット化する。ＭＭＴパケットヘッダには、３２ビットのショートフォーマットのＮＴＰを格納するフィールドが設けられており、このフィールドは、通信回線のＱｏＳ制御等に用いることができる。
　ＭＭＴパケット化されたデータは、ＵＤＰヘッダまたはＩＰヘッダを有するＩＰパケットにカプセル化される。このとき、ＩＰヘッダまたはＵＤＰヘッダにおいて、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別が同じパケットの集合をＩＰデータフローとした場合、１つのＩＰデータフローに含まれる複数のＩＰパケットは、ヘッダが冗長である。このため、１つのＩＰデータフローにおいては、一部のＩＰパケットは、ヘッダ圧縮される。
　次に、ＴＬＶパケットについて詳細に説明する。図２は、ＴＬＶパケットのデータ構造を示す図である。
　ＴＬＶパケットには、図２に示されるように、ＩＰｖ４パケット、ＩＰｖ６パケット、圧縮ＩＰパケット、ＮＵＬＬパケット、及び、伝送制御信号が格納される。これらの情報は、８ビットのデータタイプを用いて識別される。伝送制御信号には、例えばＡＭＴ（Ａｄｄｒｅｓｓ　Ｍａｐ　Ｔａｂｌｅ）、及び、ＮＩＴ（Ｎｅｔｗｏｒｋ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）などがある。また、ＴＬＶパケットにおいては、１６ビットのフィールドを用いてデータ長（バイト単位）が示され、そのあとにデータの値が格納される。データタイプの前には１バイトのヘッダ情報がある（図２において図示せず）ため、ＴＬＶパケットは、合計４バイトのヘッダ領域を有する。
　ＴＬＶパケットは、高度ＢＳ伝送方式における伝送スロットにマッピングされ、ＴＭＣＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ　ａｎｄ　Ｍｕｌｔｉｐｌｅｘｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｃｏｎｔｒｏｌ）制御情報に、スロットごとに包含される最初のパケットの先頭位置と最後のパケットの末尾の位置を示すポインタ／スロット情報が格納される。
　次に、ＭＭＴパケットを高度ＢＳ伝送方式を用いて伝送する場合の受信装置の構成について説明する。図３は、受信装置の基本構成を示すブロック図である。なお、図３の受信装置の構成は、簡略化されたものであり、より具体的な構成については、基準クロック情報が格納される態様に応じて個別に後述される。
　受信装置２０は、受信部１０と、復号部１１と、ＴＬＶデマルチプレクサ（ＤＥＭＵＸ）１２と、ＩＰデマルチプレクサ（ＤＥＭＵＸ）１３と、ＭＭＴデマルチプレクサ（ＤＥＭＵＸ）１４とを備える。
　受信部１０は、伝送路符号化データを受信する。
　復号部１１は、受信部１０によって受信された伝送路符号化データを復号し、誤り訂正などを施し、ＴＭＣＣ制御信号、及び、ＴＬＶデータを抽出する。復号部１１によって抽出されたＴＬＶデータは、ＴＬＶデマルチプレクサ１２によってＤＥＭＵＸ処理される。
　ＴＬＶデマルチプレクサ１２のＤＥＭＵＸ処理は、データタイプに応じて異なる。例えば、データタイプが圧縮ＩＰパケットである場合は、ＴＬＶデマルチプレクサ１２は、圧縮されたヘッダを復元してＩＰレイヤに渡すなどの処理を行う。
　ＩＰデマルチプレクサ１３は、ＩＰパケットまたはＵＤＰパケットのヘッダ解析などの処理を行い、ＩＰデータフローごとにＭＭＴパケットを抽出する。
　ＭＭＴデマルチプレクサ１４では、ＭＭＴパケットヘッダに格納されているパケットＩＤを基にフィルタリング処理（ＭＭＴパケットフィルタリング）を行う。
　［ＭＭＴパケットに基準クロック情報を格納する方法］
　上記図１～図３を用いて説明したＭＭＴ方式では、ＭＭＴパケットヘッダに３２ビットのショートフォーマットＮＴＰを格納して伝送することができるが、ロングフォーマットＮＴＰを伝送する方法は存在しない。
　以下、ＭＭＴパケットに基準クロック情報を格納する方法について説明する。まず、ＭＭＴパケット内に基準クロック情報を格納する方法について説明する。
　基準クロック情報を格納するための記述子、テーブル、またはメッセージを定義し、制御情報としてＭＭＴパケットに格納する場合、基準クロック情報を示す記述子やテーブル、またはメッセージであることを示す識別子が制御情報内に示される。そして、制御情報は、送信側においてＭＭＴパケットに格納される。
　これにより、受信装置２０は、識別子を基に基準クロック情報を識別することができる。なお、既存のディスクリプタ（例えば、ＣＲＩ＿ｄｅｓｃｒｉｐｔｏｒ（）等）を用いることによって、基準クロック情報がＭＭＴパケットに格納されてもよい。
　次に、ＭＭＴパケットヘッダに基準クロック情報を格納する方法について説明する。
　例えば、ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎフィールド（以下拡張フィールドと記載する。）を用いて格納する方法がある。拡張フィールドは、ＭＭＴパケットヘッダのｅｘｔｅｎｓｉｏｎ＿ｆｌａｇを’１’とすることで有効になる。
　拡張フィールドには、拡張フィールドに格納するデータのデータ種別を示す拡張フィールドタイプを格納し、拡張フィールドタイプに、基準クロック情報（例えば、６４ビットのロングフォーマットＮＴＰ）であることを示す情報を格納し、拡張フィールドに基準クロック情報を格納する方法がある。
　この場合、受信装置２０は、ＭＭＴパケットヘッダのｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇが’１’となっている場合は、ＭＭＴパケットの拡張フィールドを参照する。拡張フィールドタイプに基準クロック情報であることが示されている場合には、基準クロック情報を抽出し、クロックを再生する。
　なお、基準クロック情報は、既存のヘッダフィールドに格納されてもよい。また、未使用のフィールドがある場合や、放送に必要のないフィールドがある場合、これらのフィールドに基準クロック情報が格納されてもよい。
　また、基準クロック情報は、既存のフィールドと拡張フィールドとを併用して格納されてもよい。例えば、既存の３２ｂｉｔショートフォーマットＮＴＰフィールドと拡張フィールドとが併用されてもよい。
　既存フィールドと互換性を保つために、６４ｂｉｔロングフォーマットＮＴＰのうち、ショートフォーマットのフォーマットに対応する３２ｂｉｔ部分のみが既存フィールドに格納され、残りの３２ｂｉｔが拡張フィールドに格納されてもよい。
　なお、基準クロック情報は、例えば、基準クロック情報が格納されるＭＭＴパケットの先頭のビットが所定の位置を通過するとき（例えば、送信装置の特定の構成要素から出力されるとき）の時刻であるが、他の位置のビットが所定の位置を通過するときの時刻であってもよい。
　基準クロック情報が制御情報としてＭＭＴパケットに格納される場合、制御情報を含むＭＭＴパケットは、所定の送信間隔で送信される。
　基準クロック情報がＭＭＴパケットの拡張フィールドに格納される場合は、所定のＭＭＴパケットのヘッダの拡張フィールドに格納される。具体的には、例えば、基準クロック情報は、１００ｍｓ間隔で少なくとも１つ以上、ＭＭＴパケットのヘッダ拡張フィールドに格納される。
　なお、ＭＭＴパケットに基準クロック情報が格納される場合、プログラム情報には、基準クロック情報が格納されているＭＭＴのパケットＩＤが格納される。受信装置２０は、プログラム情報を解析し、基準クロック情報が格納されたＭＭＴパケットを取得する。このとき、基準クロック情報が格納されたＭＭＴパケットのパケットＩＤは、あらかじめ固定値として規定されてもよい。これにより、受信装置２０は、プログラム情報を解析することなく基準クロック情報を取得できる。
　［ＭＭＴパケットに基準クロック情報を格納した場合の動作フロー］
　次に、ＭＭＴパケットに基準クロック情報を格納した場合の動作フロー（基準クロック情報の取得フロー）について説明する。
　まず、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローについて説明する。図４は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置２０の機能構成を示すブロック図である。図５は、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローを示す図である。
　図４に示されるように、ＭＭＴパケットヘッダの拡張フィールドに基準クロック情報が格納される場合、ＭＭＴデマルチプレクサ１４内には、基準クロック情報抽出部１５（抽出部の一例）が設けられ、ＭＭＴデマルチプレクサ１４の後段には、基準クロック生成部１６（生成部の一例）が設けられる。
　図５のフローにおいて、受信装置２０の復号部１１は、受信部１０が受信した伝送路符号化データを復号し（Ｓ１０１）、伝送スロットからＴＬＶパケットを抽出する（Ｓ１０２）。
　次に、ＴＬＶデマルチプレクサ１２は、抽出されたＴＬＶパケットをＤＥＭＵＸし、ＩＰパケットを抽出する（Ｓ１０３）。このとき、圧縮ＩＰパケットのヘッダが再生される。
　次に、ＩＰデマルチプレクサ１３は、ＩＰパケットをＤＥＭＵＸし、指定されたＩＰデータフローを取得し、ＭＭＴパケットを抽出する（Ｓ１０４）。
　次に、ＭＭＴデマルチプレクサ１４は、ＭＭＴパケットのヘッダを解析し、拡張フィールドが使用されているかどうか、拡張フィールドに基準クロック情報があるかどうかの判定を行う（Ｓ１０６）。拡張フィールドに基準クロック情報がない場合は（Ｓ１０６でＮｏ）、処理を終了する。
　一方、拡張フィールドに基準クロック情報があると判定された場合（Ｓ１０６でＹｅｓ）、基準クロック情報抽出部１５は、拡張フィールドから基準クロック情報を抽出する（Ｓ１０７）。そして、基準クロック生成部１６は、抽出された基準クロック情報を基にシステムクロックを生成する（Ｓ１０８）。システムクロックは、言い換えれば、コンテンツを再生するためのクロックである。
　次に、制御情報に基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローについて説明する。図６は、制御情報に基準クロック情報が格納される場合の受信装置２０の機能構成を示すブロック図である。図７は、制御情報に基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローを示す図である。
　図６に示されるように、制御情報に基準クロック情報が格納される場合、基準クロック情報抽出部１５は、ＭＭＴデマルチプレクサ１４の後段に配置される。
　図７のフローにおいて、ステップＳ１１１～ステップＳ１１４の処理は、図５で説明したステップＳ１０１～ステップＳ１０４のフローと同一である。
　ステップＳ１１４に続いて、ＭＭＴデマルチプレクサ１４は、プログラム情報から基準クロック情報を含むパケットのパケットＩＤを取得し（Ｓ１１５）、当該パケットＩＤのＭＭＴパケットを取得する（Ｓ１１６）。続いて、基準クロック情報抽出部１５は、抽出したＭＭＴパケットに含まれる制御信号から基準クロック情報を抽出し（Ｓ１１７）、基準クロック生成部１６は、抽出された基準クロック情報を基にシステムクロックを生成する（Ｓ１１８）。
　［ＴＬＶパケットに基準クロック情報を格納する方法］
　図５及び図７で説明したように、ＭＭＴパケットに基準クロック情報が格納される場合、受信側で基準クロック情報を得るためには、受信装置２０は、伝送スロットからＴＬＶパケットを抽出し、ＴＬＶパケットからＩＰパケットを抽出する。さらに、受信装置２０は、ＩＰパケットからＭＭＴパケットを抽出し、さらにＭＭＴパケットのヘッダまたはペイロードから基準クロック情報を抽出する。このように、ＭＭＴパケットに基準クロック情報が格納される場合、基準クロック情報を取得するための処理が多く、さらに取得までに多くの時間を要することが課題である。
　そこで、基準クロックを基に映像や音声などのメディアにタイムスタンプを付与する処理及びメディアを伝送する処理は、ＭＭＴ方式を用いて実現し、かつ、基準クロック情報の伝送を、ＭＭＴレイヤよりも下位のレイヤ、下位のプロトコル、または下位の多重化方式を用いて行う方法について説明する。
　まず、ＴＬＶパケットに基準クロック情報を格納して伝送する方法について説明する。図８は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置２０の構成を示すブロック図である。
　図８に示される受信装置２０では、基準クロック情報抽出部１５と、基準クロック生成部１６との配置が図４及び図６と異なる。また、図８では同期部１７及び復号提示部１８も図示されている。
　ＴＬＶパケットの構成は、上記図２に示されるように、８ビットのデータタイプ、１６ビットのデータ長、及び８＊Ｎビットのデータから構成される。また、上述のようにデータタイプの前には、図２において図示されない１バイトのヘッダが存在する。なお、データタイプは、具体的には、例えば、０ｘ０１：ＩＰｖ４パケット、０ｘ０３：ヘッダ圧縮したＩＰパケットなどと規定される。
　新規のデータをＴＬＶパケットに格納するために、データタイプの未定義領域を用いてデータタイプが規定される。ＴＬＶパケットに基準クロック情報が格納されていることを示すために、データタイプには、データが基準クロック情報であることを示す記述がなされる。
　なお、データタイプは、基準クロックの種類ごとに規定されてもよい。例えば、ショートフォーマットＮＴＰ、ロングフォーマットＮＴＰ、及びＰＣＲ（Ｐｒｏｇｒａｍ　Ｃｌｏｃｋ　Ｒｅｆｅｒｅｎｃｅ）を示すデータタイプがそれぞれ個別に規定されてもよい。図９は、ロングフォーマットＮＴＰがＴＬＶパケットに格納される例を示す図であり、ロングフォーマットＮＴＰは、データフィールドに格納されている。
　この場合、基準クロック情報抽出部１５は、ＴＬＶパケットのデータタイプを解析し、基準クロック情報が格納されている場合には、データ長を解析し、データフィールドから基準クロック情報を抽出する。
　なお、データタイプによって、データ長が一意に決定されている場合、基準クロック情報抽出部１５は、データ長フィールドを解析することなく基準クロック情報を取得してもよい。例えば、データタイプが６４ｂｉｔロングローマットＮＴＰであることが示されている場合、基準クロック情報抽出部１５は、４バイト＋１ビット目から４バイト＋６４ビット目までを抽出してもよい。また、基準クロック情報抽出部１５は、６４ｂｉｔのデータから、所望のビットだけを抽出してもよい。
　次に、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置２０の動作フロー（基準クロック情報の取得フロー）について、図１０を用いて説明する。図１０は、ＴＬＶパケットに基準クロック情報が格納される場合の受信装置２０の基準クロック情報の取得フローを示す図である。
　図１０のフローにおいては、まず、復号部１１は、受信部１０が受信した伝送路符号化データを復号し（Ｓ１２１）、伝送スロットからＴＬＶパケットを抽出する（Ｓ１２２）。
　次に、ＴＬＶデマルチプレクサ１２は、ＴＬＶパケットのデータタイプを解析し（Ｓ１２３）、データタイプが基準クロック情報であるかどうかの判定を行う（Ｓ１２４）。データタイプが基準クロックである場合は（Ｓ１２４でＹｅｓ）、基準クロック情報抽出部１５は、ＴＬＶパケットのデータフィールドから基準クロック情報を抽出する（Ｓ１２５）。そして、基準クロック生成部１６は、基準クロック情報を基に、システムクロックを生成する（Ｓ１２６）。一方、データタイプが基準クロック情報でない場合は（Ｓ１２４でＮｏ）、基準クロック情報の取得フローは終了する。
　また、図示されないフローにおいて、ＩＰデマルチプレクサ１３は、データタイプに応じてＩＰパケットを抽出する。そして、抽出されたＩＰパケットに対してＩＰ　ＤＥＭＵＸ処理、及びＭＭＴ　ＤＥＭＵＸ処理が行われてＭＭＴパケットが抽出される。さらに、同期部１７は、抽出されたＭＭＴパケットに含まれる映像データのタイムスタンプがステップＳ１２６で生成された基準クロックに一致するタイミングで復号提示部１８に当該映像データを出力し、復号提示部１８は、映像データを復号及び提示する。
　以上説明した送信方法では、ＴＬＶパケットのタイプデータにおいて基準クロック情報を格納していることが示され、ＴＬＶパケットのデータフィールドに基準クロック情報が格納される。このように、ＭＭＴレイヤよりも下位のレイヤまたは下位のプロトコルを用いて基準クロック情報を格納し、送信することにより、受信装置２０における基準クロック情報を抽出するまでの処理や時間を削減することができる。
　また、ＩＰレイヤにまたがって、より下位のレイヤで基準クロック情報が抽出・再生できるため、基準クロック情報の抽出をハードウェア実装により行うことができる。これにより、基準クロック情報の抽出をソフトウェア実装により行う場合よりもジッタなどの影響を軽減することができ、より高精度な基準クロックを生成することが可能となる。
　次に、基準クロック情報を格納するその他の方法について説明する。
　上記図１０のフローにおいて、データタイプによってデータ長が一意に決定される場合、データ長フィールドは、送信されなくてもよい。なお、データ長フィールドが送信されない場合は、データ長フィールドが送信されないデータであることを示す識別子が格納される。
　また、図１０の説明では、基準クロック情報は、ＴＬＶパケットのデータフィールドに格納されたが、基準クロック情報は、ＴＬＶパケットの直前や直後に付加されてもよい。また、基準クロック情報は、ＴＬＶパケットに格納されるデータの直前や直後に付加されてもよい。これらの場合、基準クロック情報が付加されている場所を特定できるようなデータタイプが付与される。
　例えば、図１１は、ＩＰパケットのヘッダの直前に基準クロック情報が付加される構成を示す図である。この場合、データタイプは、基準クロック情報付ＩＰパケットであることを示す。受信装置２０（基準クロック情報抽出部１５）は、データタイプが基準クロック情報付ＩＰパケットであること示す場合、ＴＬＶパケットのデータフィールドの先頭から、あらかじめ定めされた所定の基準クロック情報の長さのビットを抽出することにより、基準クロック情報を取得できる。このとき、データ長は、基準クロック情報の長さを含むデータの長さを指定してもよいし、基準クロック情報の長さを含まない長さを指定してもよい。データ長に基準クロック情報の長さを含むデータの長さが指定されている場合、受信装置２０（基準クロック情報抽出部１５）は、データ長から基準クロック情報の長さを減算した長さのデータを基準クロック情報の直後から取得する。データ長に基準クロック情報の長さを含まないデータの長さが指定されている場合、受信装置２０（基準クロック情報抽出部１５）は、データ長に指定されている長さのデータを基準クロック情報の直後から取得する。
　また、図１２は、ＴＬＶパケットの直前に基準クロック情報が付加される構成を示す図である。この場合、データタイプは従来通りのデータタイプとし、ＴＬＶパケットが基準クロック情報付ＴＬＶパケットであること示す識別子が、例えば、伝送スロットのスロットヘッダまたはＴＭＣＣ制御情報に格納される。図１３は、伝送スロットの構成を示す図であり、図１４は、伝送スロットのスロットヘッダの構成を示す図である。
　図１３に示されるように、伝送スロットは、複数のスロット（図１３の例では、Ｓｌｏｔ＃１－Ｓｌｏｔ＃１２０の１２０個のスロット）から構成される。各スロットに含まれるビット数は、誤り訂正の符号化率に基づいて一意に定められた固定ビット数であり、スロットヘッダを有し、１以上のＴＬＶパケットが格納される。なお、図１３に示されるように、ＴＬＶパケットは、可変長である。
　図１４に示されるように、スロットヘッダの先頭ＴＬＶ指示フィールド（１６ｂｉｔｓ）には、スロット中の最初のＴＬＶパケットの先頭バイトの位置を、スロットヘッダを除いたスロット先頭からのバイト数で示したものが格納される。スロットヘッダの残りの１６０ｂｉｔｓは、未定義である。伝送スロットは、上述のように１フレームあたり１２０個のスロットで構成され、スロットへの変調方式の割り当ては５スロット単位である。また、１フレーム内では最大１６のストリームを伝送可能である。なお、１つの伝送スロットに含まれる複数のストリームは、例えば、当該ストリームによって伝送されるコンテンツ（または、コンテンツを提供する事業者）が互いに異なる。また、ストリームは、１以上のスロットで構成され、１つのスロットが複数のストリームにまたがることはない。
　ＴＬＶパケットが基準クロック情報付ＴＬＶパケットであること示す識別子が、スロットヘッダに格納される場合、例えば、スロット内において基準クロック情報付ＴＬＶパケットの位置を特定できる情報、基準クロック情報の種類、及びデータ長などが、スロットヘッダの未定義フィールドを拡張（利用）して格納される。
　なお、基準クロック情報付ＴＬＶパケットの位置を特定できる情報、基準クロック情報の種類、及び、データ長のすべての情報がスロットヘッダに格納されていなくてもよい。基準クロック情報付ＴＬＶパケットを特定及び参照することができる情報が示されていればよい。
　例えば、基準クロック情報が、６４ビットロングフォーマットＮＴＰであり、１つのスロットに格納できる基準クロック情報付ＴＬＶパケットは１つであり、かつ、必ず先頭のＴＬＶパケットであると定義される場合、スロットヘッダの未定義領域にフラグが格納されてもよい。図１５は、スロットヘッダの未定義領域にフラグが格納される例を示す図である。
　図１５の例では、スロットヘッダの未定義領域に、当該スロットに基準クロック情報が含まれているかどうか示すフラグ（図中で「Ｆ」と記載）が格納されている。このようなフラグによって、受信装置２０は、先頭のＴＬＶパケットが基準クロック情報付ＴＬＶパケットであると判断してもよい。
　また、ＴＬＶパケットが基準クロック情報付ＴＬＶパケットであること示す識別子（情報）は、ＴＭＣＣ制御情報に格納されてもよい。図１６は、高度広帯域衛星デジタル放送の伝送方式におけるＴＭＣＣ制御情報の構成を示す図である。
　基準クロック情報付ＴＬＶパケットを特定及び参照するための情報は、図１６に示されるＴＭＣＣ制御情報内の拡張情報に格納されてもよいし、ＴＭＣＣ制御情報内のその他の場所に格納されてもよい。例えば、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報が、基準クロック情報付ＴＬＶパケットを特定及び参照するための情報として使用されてもよい。図１７は、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報を示す図である。
　図１７に示されるように、ストリーム種別／相対ストリーム情報においては、１６本のストリーム毎のストリーム種別が８ビットで示される。つまり、１フレームの伝送スロットによれば、最大１６本（１６種別）のストリームを伝送することができる。例えば、ＭＰＥＧ２－ＴＳストリームのストリーム種別は、「００００００００」であり、ＴＬＶストリームのストリーム種別は、「００００００１０」である。しかしながら、その他のストリームに対しては、現状、割り当て種別なし又は未定義である。
　そこで、基準クロック付ＴＬＶストリームのストリーム種別を、例えば「０００００１００」と定義し、相対ストリームが基準クロック付ＴＬＶストリームである場合には、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報に「０００００１００」を格納する。ここで、ストリーム種別が「０００００１００」となっているストリームにおいては、例えば、スロット割り当て単位である５スロット単位に一回、または、フレーム単位に一回、基準クロック情報を含むＴＬＶパケットが格納される。
　このような構成においては、受信装置２０は、ＴＭＣＣ制御情報のストリーム種別／相対ストリーム情報を解析し、ストリーム種別が「０００００１００」となっている場合、あらかじめ定められたスロットから基準クロック付ＴＬＶパケットを取得する。
　なお、ダウンロード型ＴＬＶパケットを含むストリーム種別と、映像や音声などのストリーム型ＴＬＶパケットを含むストリーム種別とが定義される場合が考えられる。このような場合、受信装置２０は、受信したストリームのストリーム種別が、ストリーム型ＴＬＶパケットであるときに、ストリームに基準クロック情報が含まれると判断してもよい。なぜなら、ダウンロード型のＴＬＶパケットの再生においては、通常、基準クロック情報は用いられないからである。
　また、基準クロック情報付ＴＬＶパケットを特定及び参照するための情報がＴＭＣＣ制御情報の拡張情報に格納される場合は、例えば、１６本の相対ストリーム毎の情報がＴＭＣＣ制御情報の拡張領域に格納される。
　また、図１８に示されるように、スロットヘッダの未定義フィールドに基準クロック情報が格納される領域が新たに定義されてもよい。図１８は、スロットヘッダの未定義フィールドに基準クロック情報が格納される例を示す図である。
　また、あらかじめ定められたスロットに基準クロック情報が格納されてもよいし、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納されてもよい。ここで、あらかじめ定められたスロットは、例えば、伝送スロットのうちの先頭のスロット（図１３の例ではＳｌｏｔ＃１）であり、このスロット内の先頭のＴＬＶパケットにＩＰパケットに格納された基準クロック情報が含まれてもよい。また、伝送スロットに複数のストリームが含まれる場合、あらかじめ定められたスロットは、例えば、伝送スロットに含まれる各ストリームの先頭のスロットであり、このスロット内の先頭のＴＬＶパケットにＩＰパケットに格納された基準クロック情報が含まれてもよい。
　また、ＴＭＣＣ制御情報には、基準クロック情報を含むスロットヘッダを特定し参照するための情報が格納されてもよい。なお、基準クロック情報を含むスロットヘッダを特定及び参照するための情報のＴＭＣＣ制御情報への格納方法は、上述した基準クロック情報付ＴＬＶパケットを特定及び参照するための情報の格納方法と同様であるため、説明が省略される。
　この場合、受信装置２０は、ＴＭＣＣ制御信号を解析し、スロットヘッダに基準クロック情報があると判定した場合には、スロットヘッダから基準クロック情報を抽出する。
　また、ＴＭＣＣ制御情報に基準クロック情報を含むことを示す情報が格納されてもよい。図１９は、ＴＭＣＣ制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置２０の機能構成を示すブロック図である。図２０は、スロットヘッダに基準クロック情報を含むことを示す情報がＴＭＣＣ制御情報に格納される場合の基準クロック情報の取得フローを示す図である。
　図１９に示されるように、ＴＭＣＣ制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置２０においては、基準クロック情報抽出部１５は、復号部１１から出力される伝送スロットから基準クロック信号を取得する。
　図２０のフローでは、復号部１１は、伝送路符号化データを復号し（Ｓ１３１）、ＴＭＣＣ制御信号を解析し（Ｓ１３２）、伝送スロット内のスロットヘッダに基準クロック情報があるかどうかを判定する（Ｓ１３３）。スロットヘッダに基準クロック情報がある場合は（Ｓ１３３でＹｅｓ）、基準クロック情報抽出部１５は、スロットヘッダから基準クロック情報を抽出し（Ｓ１３４）、基準クロック生成部１６は、基準クロック情報を基にシステムの基準クロック（システムクロック）を生成する（Ｓ１３５）。一方、スロットヘッダに基準クロック情報がない場合は（Ｓ１３３でＮｏ）、基準クロック情報の取得フローは終了する。
　このような受信装置２０は、伝送スロットのレイヤで基準クロック情報を取得することができるため、ＴＬＶパケットに格納する場合よりもさらに早く基準クロック情報を取得できる。
　以上説明したように、ＴＬＶパケットや伝送スロットに基準クロック情報を格納することにより、受信装置２０において、基準クロック情報を取得するまでの処理を軽減することができ、かつ、基準クロック情報の取得時間を短縮できる。
　また、このように、物理レイヤにおいて基準クロック情報が格納されることにより、ハードウェアによる基準クロック情報の取得及び再生が容易に実現でき、ソフトウェアによる基準クロック情報の取得及び再生よりも精度の高いクロック再生が可能である。
　また、上記実施の形態１に係る送信方法は、まとめると、ＩＰレイヤを含む複数のレイヤ（プロトコル）が存在するシステムにおいて、ＩＰレイヤより上位のレイヤで基準クロック情報を基にメディアのタイムスタンプを付与し、ＩＰレイヤより下位のレイヤで基準クロック情報を送信する。このような構成によれば、受信装置２０において基準クロック情報をハードウェアで処理することが容易となる。
　なお、同様の思想に基づき、ＩＰパケット内にＭＭＴパケットに格納されない状態で基準クロック情報を格納することも考えられる。このような場合であっても、ＭＭＴパケットに基準クロック情報が格納される場合よりも、基準クロック情報を取得するための処理を軽減することができる。
　［基準クロック情報の送出周期］
　以下、基準クロック情報の送出周期について補足する。
　ＴＬＶパケットに基準クロック情報を格納する場合、例えば、送信側においてＴＬＶパケットの先頭のビットが送出される時刻を基準クロック情報として格納する。また、先頭のビットの送出時刻ではなく、他に定められた所定の時刻が基準クロック情報として格納されてもよい。
　基準クロック情報を含むＴＬＶパケットは、所定の間隔で送信される。言い換えれば、基準クロック情報を含むＴＬＶパケットは、伝送スロットに含まれて所定の送信周期で送信される。例えば、基準クロック情報は、１００ｍｓ間隔に少なくとも１つ以上、ＴＬＶパケットに格納されて伝送されてもよい。
　また、高度ＢＳ伝送方式の伝送スロットの所定の場所に、所定の間隔で基準クロック情報を含むＴＬＶパケットが配置されてもよい。また、ＴＬＶパケットのスロット割り当て単位である５スロット単位ごとに一回、基準クロック情報を含むＴＬＶパケットが格納され、５スロット単位のうち一番初めのスロットの先頭のＴＬＶパケットに基準クロック情報が格納されてもよい。すなわち、伝送スロット内の先頭のスロット内の先頭（つまり、スロットヘッダの直後）に、基準クロック情報を含むＴＬＶパケットが配置されてもよい。
　また、高度広帯域衛星デジタル放送の伝送方式の伝送スロットの所定の場所に、所定の間隔で基準クロック情報を含むＴＬＶパケットが配置されてもよい。例えば、スロット割り当て単位である５スロット単位にごとに一回、基準クロック情報が一番初めのスロットの先頭のＴＬＶパケットに格納されてもよい。すなわち、伝送スロットに含まれる各ストリームの先頭のスロット内で先頭に位置するＴＬＶパケットに、基準クロック情報が含まれてもよい。また、基準クロック情報は、相対ストリームの中で１番目のスロットに格納されてもよい。
　また、基準クロック情報の送出周期及び送出間隔は、伝送路符号化方式の変調方式または符号化率に応じて変更されてもよい。
　［上位レイヤの基準クロック情報を早く取得する方法］
　次に、受信装置２０において下位レイヤから上位レイヤまでのＤＥＭＵＸを一括で処理することにより、基準クロック情報の取得までの時間を短縮する方法について説明する。
　ここでは、ＭＭＴパケットなどの上位レイヤに基準クロック情報を格納し、基準クロック情報が格納されたＭＭＴパケットをＩＰパケットに格納する方法について説明する。以下で説明する方法では、基準クロック情報が格納されたＩＰパケットをＴＬＶパケットに格納するためのプロトコルを定義することにより、ＴＬＶパケットのような下位レイヤから、上位レイヤであるＭＭＴパケットを直接参照し、通常のＤＥＭＵＸ処理をすることなくＭＭＴパケットに含まれる基準クロック情報を取得する。
　送信側において、基準クロック情報は、上述のＭＭＴパケットに格納される制御情報に含まれる。基準クロック情報を含む制御情報には、あらかじめ定められたパケットＩＤが付与される。そして、送信側においては、基準クロック情報を含むＭＭＴパケットは、専用のＩＰデータフローに格納され、あらかじめ定められた、送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別が付与される。
　このように生成された伝送路符号化データを受信した受信装置２０においては、ＴＬＶデマルチプレクサ１２があらかじめ定められたＩＰデータフロー取得することにより、基準クロック情報を含むＩＰパケットを抽出することができる。
　なお、ＩＰパケットがヘッダ圧縮される場合には、例えば、同一のＩＰデータフローであることを示すコンテクスト識別子に、基準クロック情報を含むＩＰパケットであることを示す識別子が付与される。コンテクスト識別子は、圧縮ＩＰパケットヘッダに格納されている。この場合、受信装置２０は、圧縮ＩＰパケットヘッダのコンテクスト識別子を参照することにより、基準クロック情報を含むＩＰパケットを抽出できる。
　また、基準クロック情報を含むＩＰパケットは、ヘッダ圧縮されないと規定されてもよいし、必ずヘッダ圧縮されると規定されてもよい。基準クロック情報を含むＩＰパケットには、あらかじめ定めされたコンテクスト識別子が付与され、すべてのヘッダが圧縮されると規定されてもよい。
　また、ＴＬＶのデータタイプフィールドに、基準クロック情報を含むＩＰデータフローに属するＩＰパケットであることを示す識別子、または、基準クロック情報を含むＩＰデータフローに属する圧縮ＩＰパケットであることを示す識別子などを定義する方法も考えられる。以下ではその方法について説明する。
　受信装置２０は、ＴＬＶのデータタイプを判定し、基準クロック情報を含むと判定されれば、ＩＰパケットからＭＭＴパケット内に含まれる基準クロック情報を直接取得する。
　このように、受信装置２０は、ＩＰアドレスやポート番号、コンテクスト識別子を解析することなく、ＩＰパケットや圧縮ＩＰパケットから特定位置のビット列を抽出することで、ＭＭＴパケットに含まれる基準クロック情報を抽出してもよい。特定位置のビット列を抽出するとは、例えば、ＴＬＶパケットヘッダから、固定長バイトだけオフセットした位置から特定の長さ分の情報を抽出することを意味し、これにより、基準クロック情報が取得される。
　基準クロック情報を抽出するための固定長バイトのオフセットの長さは、ＩＰパケットと圧縮ＩＰパケットとのそれぞれにおいて一意に決まる。このため、受信装置２０は、ＴＬＶのデータタイプを判定した後、直ちに固定長バイトだけオフセットした位置から特定の長さ分の情報を抽出することにより基準クロック情報を取得できる。
　なお、上記の方法は一例であり、他のプロトコルや識別子を定義することにより、下位レイヤから上位レイヤの基準クロック情報が取得されてもよい。例えば、ＩＰパケットに基準クロック情報を含むかどうかの識別子がＴＬＶデータタイプ以外のフィールドに格納されてもよい。
　また、例えば、ＩＰアドレスやポート番号、コンテクスト識別子を解析することなく、ＩＰパケットまたは圧縮ＩＰパケットから特定位置のビット列を抽出することで、ＭＭＴパケットに含まれる基準時刻情報を抽出してもよい。図２１は、ＩＰパケットまたは圧縮ＩＰパケットから特定位置のビット列を抽出する場合のフローを示す図である。なお、この場合の受信装置２０の構成は、図８に示されるブロック図と同様である。
　図２１のフローにおいては、まず、復号部１１は、受信部１０が受信した伝送路符号化データを復号し（Ｓ１４１）、伝送路スロットからＴＬＶパケットを抽出する（Ｓ１４２）。
　次に、ＴＬＶデマルチプレクサ１２は、ＴＬＶパケットのデータタイプを解析し（Ｓ１４３）、データタイプが基準クロック情報を含むＩＰであるかどうかの判定を行う（Ｓ１４４）。データタイプが基準クロック情報を含むＩＰパケットでないと判定された場合（Ｓ１４４でＮｏ）、フローは終了する。データタイプが基準クロック情報を含むＩＰパケットであると判定された場合（Ｓ１４４でＹｅｓ）、ＩＰパケット及びＭＭＴパケットを解析し、ＩＰヘッダが圧縮されているかどうかの判定を行う（Ｓ１４５）。
　ＩＰヘッダが圧縮されていない場合（Ｓ１４５でＮｏ）、ＴＬＶヘッダから固定長Ｎバイトだけオフセットした位置のＭＭＴパケットの中に含まれる基準クロック情報を取得する（Ｓ１４６）。ＩＰヘッダが圧縮されている場合（Ｓ１４５でＹｅｓ）、ＴＬＶヘッダから固定長Ｍバイトだけオフセットした位置のＭＭＴパケットの中に含まれる基準クロック情報を取得する（Ｓ１４７）。
　最後に、基準クロック生成部１６は、基準クロック情報を基に、システムクロックを生成する（Ｓ１４８）。
　なお、ＩＰパケットがＩＰｖ４であるか、ＩＰｖ６であるかによって、ＩＰパケットヘッダのデータ構造が異なるため、固定長Ｎバイトや、Ｍバイトは異なる値となる。
　音声、映像、及び制御信号などを含む通常のＭＭＴパケットは、通常のステップでＤＥＭＵＸ処理が行なわれるのに対し、基準クロック情報を含むＭＭＴパケットは、下位レイヤから上位レイヤまでのＤＥＭＵＸ処理が一括で行われる。これにより、上位レイヤに基準クロック情報が格納されている場合であっても、下位レイヤにおいて基準クロック情報の取得ができる。つまり、基準クロック情報の取得のための処理を軽減し、かつ、基準クロック情報の取得までの時間を短縮することができ、ハードウェア実装も容易となる。
　（その他の実施の形態）
　以上、実施の形態１について説明したが、本開示は、上記実施の形態に限定されるものではない。
　上記実施の形態では、基準クロック情報の格納方法について説明したが、１つ以上のレイヤで複数の基準クロック情報が送信されてもよい。複数の基準クロック情報が送信されている場合、受信装置２０は、どちらか一方の基準クロック情報を選択して基準クロック（システムクロック）の生成に用いてもよいし、両方を用いて基準クロックを生成してもよい。このとき、受信装置２０は、精度の高い基準クロック情報を選択してもよいし、より早く取得できる基準クロック情報を選択してもよい。
　また、例えば、従来のＭＭＴパケットヘッダに含まれる３２ｂｉｔショートフォーマットＮＴＰに加えて、より高精度な基準クロック情報を送信することが想定される。このような場合、送信側からは、受信装置２０が高精度な基準クロック情報を用いて３２ｂｉｔショートフォーマットＮＴＰを再生するための情報がさらに送信される。このような情報は、例えば、互いのクロックの相対関係を示す時刻情報であり、ＣＲＩ＿ｄｅｓｃｒｉｐｔｏｒ（）等を用いて送信される構成などが考えられる。
　なお、受信装置２０において３２ｂｉｔショートフォーマットＮＴＰが再生できる場合には、従来のＭＭＴパケットヘッダに含まれるＮＴＰフィールドは不要である。このため、ＮＴＰフィールドには別の情報が格納されてもよいし、ＮＴＰフィールドを削減することによりヘッダ圧縮が行われてもよい。ヘッダ圧縮がされる場合には、ＮＴＰフィールドを削減したことを示す情報が送信される。受信装置２０は、ＮＴＰフィールドが削減されている場合には、他の基準クロック情報を用いて基準クロックを生成するとともに、３２ｂｉｔショートフォーマットＮＴＰを再生する。
　また、ＭＭＴパケットが通信伝送路を用いて伝送される場合、通信受信装置は、ＱｏＳ制御のために３２ｂｉｔショートフォーマットＮＴＰを使用し、基準クロック情報は使用しない可能性がある。そのため、通信伝送路では基準クロック情報が送信されなくてもよい。また、通信伝送路のＥｎｄ－ｔｏ－Ｅｎｄ遅延が一定以内である場合は、基準クロック情報をクロック再生に用いてもよい。
　なお、上記実施の形態１では、ＭＭＴ／ＩＰ／ＴＬＶ方式を用いる場合を例に説明したが、多重化方式として、ＭＭＴ方式以外の方式が用いられてもよい。例えば、ＭＰＥＧ２－ＴＳ方式、ＲＴＰ方式、またはＭＰＥＧ－ＤＡＳＨ方式にも本開示を適用することができる。
　また、ＩＰパケットのヘッダ圧縮の方法としては、ＲｏＨＣ（Ｒｏｂｕｓｔ　Ｈｅａｄｅｒ　Ｃｏｍｐｒｅｓｓｉｏｎ）、及びＨＣｆＢ（Ｈｅａｄｅｒ　Ｃｏｍｐｒｅｓｓｉｏｎ　ｆｏｒ　Ｂｒｏａｄｃａｓｔｉｎｇ）がある。
　ＩＰパケットを放送に格納する方式としては、ＴＬＶ方式以外にも、ＧＳＥ（Ｇｅｎｅｒｉｃ　Ｓｔｒｅａｍ　Ｅｎｃａｐｓｕｌａｔｉｏｎ）方式、及びＵＬＥ（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ　Ｌｉｇｈｔ－ｗｅｉｇｈｔ．　Ｅｎｃａｐｓｕｌａｔｉｏｎ）を用いたＩＰｏｖｅｒＴＳ方式などがある。
　以上のようないずれの方式を用いる場合にも本開示は適用可能であり、本開示の適用により、受信装置２０における基準クロック情報を取得までの時間の短縮や処理の軽減、ハードウェア化実装によるクロックの高精度化などを実現することができる。
　また、本開示は、上記のような方法で基準クロック情報を格納した伝送スロットを送信する送信装置（送信方法）として実現されてもよい。以下、このような送信装置の構成について補足する。図２２は、送信装置の機能構成を示すブロック図である。図２３は、送信装置の動作フローを示す図である。
　図２２に示されるように、送信装置３０は、生成部３１と、送信部３２とを備える。なお、送信装置３０の構成要素は、具体的には、マイクロコンピュータ、プロセッサ、または専用回路などによって実現される。
　送信装置３０は、具体的には、放送サーバであり、上記実施の形態１の「送信側」の一例である。
　生成部３１は、例えば、ＩＰパケットが格納されたＴＬＶパケットが１以上格納されたスロットを複数格納した伝送スロットを生成する（図２３のＳ１５１）。ここで、伝送スロットには、１以上のスロットで構成される相対ストリームが複数含まれるとする。
　このとき、生成部３１は、伝送スロットに含まれる各相対ストリームの先頭のスロット内で先頭に位置するＴＬＶパケットに、受信装置２０におけるコンテンツ（例えば、映像または音声などの放送コンテンツ）の再生のための時刻を示すＮＴＰなどの基準クロック情報を含める。生成部３１は、具体的には、放送コンテンツを符号化する符号化部、ＭＭＴマルチプレクサ、ＩＰマルチプレクサ、及び、ＴＬＶマルチプレクサなどからなる。なお、ＴＬＶパケットは、第１の伝送単位の一例であり、スロットは、第２の伝送単位の一例であり、伝送スロットは、伝送用のフレームの一例である。相対ストリームは、ストリームの一例である。
　送信部３２は、生成部３１によって生成された伝送スロット（伝送スロットを含む伝送路符号化データ）を、放送を通じて送信する（図２３のＳ１５２）。
　上記実施の形態１でも説明したように、このような送信装置３０によれば、伝送スロット内の各相対ストリームの先頭に位置するＴＬＶパケットに基準クロック情報を含めることで、受信装置２０が複数のストリームそれぞれの基準クロック情報を取得する処理を簡素化できる。したがって、受信装置２０が基準クロック情報を取得するまでの時間を短縮することができる。
　なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
　また、各構成要素は、回路でもよい。これらの回路は、全体として１つの回路を構成してもよいし、それぞれ別々の回路でもよい。また、これらの回路は、それぞれ、汎用的な回路でもよいし、専用の回路でもよい。
　例えば、上記各実施の形態において、特定の処理部が実行する処理を別の処理部が実行してもよい。また、複数の処理の順序が変更されてもよいし、複数の処理が並行して実行されてもよい。
　以上、一つまたは複数の態様に係る受信装置（受信方法）及び送信装置（送信方法）について、実施の形態に基づいて説明したが、本開示は、この実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
　本開示の送信方法は、ＭＭＴ方式を放送システムに適用する場合に、受信側で基準クロック情報を取得するための処理を軽減することができる送信方法として有用である。
　１０　受信部
　１１　復号部
　１２　ＴＬＶデマルチプレクサ
　１３　ＩＰデマルチプレクサ
　１４　ＭＭＴデマルチプレクサ
　１５　基準クロック情報抽出部
　１６　基準クロック生成部
　１７　同期部
　１８　復号提示部
　２０　受信装置
　３０　送信装置
　３１　生成部
　３２　送信部

Claims (10)

  1. 　放送を通じて行われるＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）パケットを用いたコンテンツの伝送における送信方法であって、
    　前記ＩＰパケットが格納される第１の伝送単位が１以上格納された第２の伝送単位を複数格納した伝送用のフレームを生成する生成ステップと、
    　生成された前記フレームを送信する送信ステップとを含み、
    　前記フレームには、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、
    　前記生成ステップにおいては、前記フレームに含まれる少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に、前記コンテンツの再生のための時刻を示す基準クロック情報を含める
    　送信方法。
  2. 　前記フレームには、前記ストリームが複数含まれ、
    　前記生成ステップにおいては、前記フレームに含まれる各前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に、前記コンテンツの再生のための時刻を示す基準クロック情報を含める
    　請求項１に記載の送信方法。
  3. 　前記第１の伝送単位は、可変長の伝送単位であり、
    　前記第２の伝送単位は、固定長の伝送単位である
    　請求項１または２に記載の送信方法。
  4. 　前記先頭に位置する第１の伝送単位に格納されるＩＰパケットは、ヘッダ圧縮されていないＩＰパケットである
    　請求項１～３のいずれか１項に記載の送信方法。
  5. 　前記第１の伝送単位は、ＴＬＶ（Ｔｙｐｅ　Ｌｅｎｇｔｈ　Ｖａｌｕｅ）パケットであり、
    　前記第２の伝送単位は、高度ＢＳ伝送方式におけるスロットであり、
    　前記フレームは、高度ＢＳ伝送方式における伝送スロットである
    　請求項１～４のいずれか１項に記載の送信方法。
  6. 　前記基準クロック情報は、ＮＴＰ（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）である
    　請求項１～５のいずれか１項に記載の送信方法。
  7. 　前記送信ステップにおいては、前記フレームを所定の送信周期で送信する
    　請求項１～６のいずれか１項に記載の送信方法。
  8. 　放送を通じて行われるＩＰパケットを用いたコンテンツの伝送における受信方法であって、
    　前記ＩＰパケットが格納される第１の伝送単位が１以上含まれる第２の伝送単位を複数格納した伝送用のフレームであって、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、かつ、少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に基準クロック情報が含まれるフレームを受信する受信ステップと、
    　受信された前記フレームから前記基準クロック情報を抽出するステップと、
    　抽出された前記基準クロック情報を用いて前記コンテンツを再生するためのクロックを生成する生成ステップとを含む
    　受信方法。
  9. 　放送を通じて行われるＩＰパケットを用いたコンテンツの伝送に用いられる送信装置であって、
    　前記ＩＰパケットが格納される第１の伝送単位が１以上格納された第２の伝送単位を複数格納した伝送用のフレームを生成する生成部と、
    　生成された前記フレームを送信する送信部とを備え、
    　前記フレームには、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、
    　前記生成部は、前記フレームに含まれる少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に、前記コンテンツの再生のための時刻を示す基準クロック情報を含める
    　送信装置。
  10. 　放送を通じて行われるＩＰパケットを用いたコンテンツの伝送に用いられる受信装置であって、
    　前記ＩＰパケットが格納される第１の伝送単位が１以上含まれる第２の伝送単位を複数格納した伝送用のフレームであって、１以上の第２の伝送単位で構成されるストリームが１以上含まれ、かつ、少なくとも１つの前記ストリームの先頭の第２の伝送単位内で先頭に位置する第１の伝送単位に基準クロック情報が含まれるフレームを受信する受信部と、
    　受信された前記フレームから前記基準クロック情報を抽出する抽出部と、
    　抽出された前記基準クロック情報を用いて前記コンテンツを再生するためのクロックを生成する生成部とを備える
    　受信装置。
PCT/JP2014/004863 2013-09-30 2014-09-24 送信方法、受信方法、送信装置、及び受信装置 WO2015045362A1 (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
EP14847603.9A EP3054608A4 (en) 2013-09-30 2014-09-24 TRANSMITTING METHOD, RECEIVING METHOD, TRANSMITTING APPARATUS, AND RECEIVER APPARATUS
CN201480045742.4A CN105519020B (zh) 2013-09-30 2014-09-24 发送方法、接收方法、发送装置、及接收装置
US15/075,229 US9992549B2 (en) 2013-09-30 2016-03-21 Transmission method, reception method, transmission apparatus, and reception apparatus
US15/956,301 US10321200B2 (en) 2013-09-30 2018-04-18 Transmission method, reception method, transmission apparatus, and reception apparatus
US16/394,781 US10715876B2 (en) 2013-09-30 2019-04-25 Transmission method, reception method, transmission apparatus, and reception apparatus
US16/892,774 US11272258B2 (en) 2013-09-30 2020-06-04 Transmission method, reception method, transmission apparatus, and reception apparatus
US17/588,936 US11665405B2 (en) 2013-09-30 2022-01-31 Transmission method, reception method, transmission apparatus, and reception apparatus
US18/135,981 US20230254546A1 (en) 2013-09-30 2023-04-18 Transmission method, reception method, transmission apparatus, and reception apparatus

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201361884335P 2013-09-30 2013-09-30
US61/884,335 2013-09-30
JP2014-183694 2014-09-09
JP2014183694A JP6313170B2 (ja) 2013-09-30 2014-09-09 送信方法、受信方法、送信装置、及び受信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/075,229 Continuation US9992549B2 (en) 2013-09-30 2016-03-21 Transmission method, reception method, transmission apparatus, and reception apparatus

Publications (1)

Publication Number Publication Date
WO2015045362A1 true WO2015045362A1 (ja) 2015-04-02

Family

ID=52742534

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/004863 WO2015045362A1 (ja) 2013-09-30 2014-09-24 送信方法、受信方法、送信装置、及び受信装置

Country Status (2)

Country Link
US (3) US11272258B2 (ja)
WO (1) WO2015045362A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3068138A4 (en) * 2013-11-08 2016-12-14 Panasonic Ip Corp America TRANSMISSION METHOD, RECEIVING METHOD, TRANSMISSION DEVICE AND RECEPTION DEVICE
CN107852522A (zh) * 2015-08-07 2018-03-27 索尼公司 接收设备和数据处理方法
US11050512B2 (en) 2017-05-08 2021-06-29 Sony Corporation Transmission device, and transmission method

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021027568A (ja) * 2019-08-09 2021-02-22 ソニーセミコンダクタソリューションズ株式会社 受信装置、データ伸長方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004088766A (ja) * 2002-07-22 2004-03-18 Matsushita Electric Ind Co Ltd データ管理装置及びデータ管理システム
WO2013055180A1 (en) * 2011-10-13 2013-04-18 Samsung Electronics Co., Ltd. Encoding apparatus and encoding method in data communication system
JP2013528997A (ja) * 2010-04-20 2013-07-11 サムスン エレクトロニクス カンパニー リミテッド メディアデータを送受信するためのインターフェース装置及び方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040019681A1 (en) 2002-07-22 2004-01-29 Tadashi Nakamura Data management apparatus and data management system
JP5378165B2 (ja) 2009-11-10 2013-12-25 日本電信電話株式会社 ネットワーク符号化システム及び方法
JP5400575B2 (ja) 2009-11-11 2014-01-29 日本放送協会 可変長パケットの送信装置、受信装置及びプログラム
JP6382029B2 (ja) * 2013-09-20 2018-08-29 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置、及び受信装置
JP6313170B2 (ja) 2013-09-30 2018-04-18 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置、及び受信装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004088766A (ja) * 2002-07-22 2004-03-18 Matsushita Electric Ind Co Ltd データ管理装置及びデータ管理システム
JP2013528997A (ja) * 2010-04-20 2013-07-11 サムスン エレクトロニクス カンパニー リミテッド メディアデータを送受信するためのインターフェース装置及び方法
WO2013055180A1 (en) * 2011-10-13 2013-04-18 Samsung Electronics Co., Ltd. Encoding apparatus and encoding method in data communication system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3068138A4 (en) * 2013-11-08 2016-12-14 Panasonic Ip Corp America TRANSMISSION METHOD, RECEIVING METHOD, TRANSMISSION DEVICE AND RECEPTION DEVICE
CN107852522A (zh) * 2015-08-07 2018-03-27 索尼公司 接收设备和数据处理方法
US10785525B2 (en) 2015-08-07 2020-09-22 Saturn Licensing Llc Reception apparatus and data processing method
US11050512B2 (en) 2017-05-08 2021-06-29 Sony Corporation Transmission device, and transmission method

Also Published As

Publication number Publication date
US11272258B2 (en) 2022-03-08
US20230254546A1 (en) 2023-08-10
US11665405B2 (en) 2023-05-30
US20220150599A1 (en) 2022-05-12
US20200296474A1 (en) 2020-09-17

Similar Documents

Publication Publication Date Title
JP6560469B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP6649522B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP6871449B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP6665331B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP6300134B1 (ja) 送信方法、送信装置及びシステム
JP2022121490A (ja) 送信方法、受信方法、送信装置及び受信装置
JP7257648B2 (ja) 逆多重化装置及び逆多重化方法
JP2023120255A (ja) 送信方法、及び、送信装置
WO2015075880A1 (ja) 送信方法、受信方法、送信装置、及び受信装置
WO2015045362A1 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP7512471B2 (ja) 送信方法、及び、送信装置
WO2016056201A1 (ja) 送信方法、送信装置及びシステム
WO2016031173A1 (ja) 送信方法、受信方法、送信装置及び受信装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14847603

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2014847603

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2014847603

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE