Nothing Special   »   [go: up one dir, main page]

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

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

Info

Publication number
WO2016031173A1
WO2016031173A1 PCT/JP2015/004071 JP2015004071W WO2016031173A1 WO 2016031173 A1 WO2016031173 A1 WO 2016031173A1 JP 2015004071 W JP2015004071 W JP 2015004071W WO 2016031173 A1 WO2016031173 A1 WO 2016031173A1
Authority
WO
WIPO (PCT)
Prior art keywords
reference clock
clock information
information
stored
packet
Prior art date
Application number
PCT/JP2015/004071
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 JP2015152753A external-priority patent/JP6667128B2/ja
Application filed by パナソニックＩｐマネジメント株式会社 filed Critical パナソニックＩｐマネジメント株式会社
Priority to EP15836696.3A priority Critical patent/EP3188486A4/en
Priority to CN201580041969.6A priority patent/CN106576189B/zh
Publication of WO2016031173A1 publication Critical patent/WO2016031173A1/ja
Priority to US15/437,483 priority patent/US11743312B2/en
Priority to US18/221,983 priority patent/US12143430B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/07—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information characterised by processes or methods for the generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/20—Arrangements for broadcast or distribution of identical information via plural systems
    • H04H20/24—Arrangements for distribution of identical information via broadcast system and non-broadcast system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • 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/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/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
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/18—Arrangements for synchronising broadcast or distribution via plural systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/668—Internet protocol [IP] address subnets

Definitions

  • the present disclosure relates to a transmission method, a reception method, a transmission device, and a reception device.
  • the MMT (MPEG Media Transport) method (see Non-Patent Document 1) is a multiplexing method for multiplexing and packetizing content such as video and audio, and transmitting the result 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
  • ISO / IEC-1 DIS 8 ARIB Standard ARIB STD-B44 2.0 version
  • “Transmission system for advanced broadband satellite digital broadcasting” Chapter 3 “Guidelines for transmission of time information”
  • a transmission method is a transmission method in which one or more streams are stored in one channel and a plurality of services are stored in one stream in broadcasting, and the plurality of services are transmitted.
  • a generation step of generating a stream that includes a plurality of IP (Internet Protocol) data flows that correspond one-to-one and that store a corresponding service, and a transmission step of transmitting the generated stream is included.
  • a reception method is a reception method for receiving a stream in which a stream of one channel 1 or more is stored and a plurality of services are stored in one stream in broadcasting, and the plurality of services
  • IP Internet Protocol
  • 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 diagram illustrating a configuration of TMCC extension information.
  • FIG. 23 is a diagram illustrating an example of the data structure of the extension area in which the extension types classified as described above are used.
  • FIG. 24 is a diagram illustrating the syntax when the extension type is used.
  • FIG. 25 is a block diagram illustrating a functional configuration of the receiving apparatus according to the second embodiment.
  • FIG. 26 is a diagram illustrating an operation flow of the reception apparatus according to the second embodiment.
  • FIG. 27 is a diagram schematically illustrating an example in which reference clock information is stored in each of a plurality of layers.
  • FIG. 28 is a diagram schematically illustrating an example in which a plurality of reference clock information is stored in one layer.
  • FIG. 29 is a block diagram for explaining an example in which data of different broadcasting stations are stored separately in streams.
  • FIG. 30 is a diagram for explaining a transmission method of difference information.
  • FIG. 31 is a diagram for explaining a modification of the difference information transmission method.
  • FIG. 32 is a block diagram illustrating a functional configuration of the receiving apparatus according to the third embodiment.
  • FIG. 33 is a diagram illustrating an operation flow of the reception apparatus according to the third embodiment.
  • FIG. 34 is a diagram illustrating another operation flow of the reception apparatus according to Embodiment 3.
  • FIG. 35 is a block diagram illustrating a functional configuration of the transmission apparatus.
  • FIG. 36 is a diagram illustrating an operation flow of the transmission apparatus.
  • FIG. 37 is a block diagram of a receiving apparatus according to the fourth embodiment.
  • FIG. 38 is a diagram illustrating timings of the main signal and the reference clock information according to the fourth embodiment.
  • FIG. 39 is a diagram illustrating an operation flow in the decoding unit according to the fourth embodiment.
  • FIG. 40 is a diagram showing an operation flow in the receiving apparatus according to the fourth embodiment.
  • FIG. 41 is a diagram showing an operation flow in the upper layer according to the fourth embodiment.
  • FIG. 42 is a diagram illustrating an operation flow of the decoding apparatus according to the fourth embodiment.
  • FIG. 43 is a diagram illustrating an operation flow of the demultiplexer according to the fourth embodiment.
  • FIG. 44A is a diagram showing a configuration example of a service when the MPEG-2 TS system according to the fifth embodiment is used.
  • FIG. 44B is a diagram showing a configuration example of a service when the MPEG-2 TS system according to Embodiment 5 is used.
  • FIG. 45A is a diagram illustrating a configuration example of a service when the MMT / TLV scheme according to the fifth embodiment is used.
  • FIG. 45B is a diagram illustrating a configuration example of a service when the MMT / TLV scheme according to Embodiment 5 is used.
  • FIG. 46A is a diagram illustrating an operation example of the MMT / TLV system according to the fifth embodiment.
  • FIG. 46B is a diagram illustrating an operation example of the MMT / TLV system according to the fifth embodiment.
  • FIG. 47 is a diagram illustrating an operation flow of the reception apparatus according to the fifth embodiment.
  • FIG. 48 is a diagram illustrating a configuration example of a package ID according to the fifth embodiment.
  • FIG. 49 is a diagram illustrating a configuration example of a service according to the fifth embodiment.
  • FIG. 50 is a diagram illustrating a configuration example of a service according to the fifth embodiment.
  • FIG. 51 is a block diagram of a transmission apparatus according to the fifth embodiment.
  • FIG. 52 is a diagram illustrating an operation flow of the transmission apparatus according to the fifth embodiment.
  • FIG. 53 is a block diagram of a receiving apparatus according to the fifth embodiment.
  • FIG. 54 is a diagram showing an operation flow of the receiving apparatus according to the fifth embodiment.
  • the present disclosure relates to a hybrid distribution system that uses the MMT method being standardized by MPEG (Moving Picture Expert Group), transmits reference clock information from the transmission side, receives reference clock information from the reception side, and generates a reference clock (
  • the present invention relates to a method and an apparatus for reproducing.
  • 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.
  • unnecessary data processing may occur in the receiving device.
  • processing of data that is not viewed may occur in the receiving device.
  • the data of services that are not viewed in order to acquire the data of the services that are viewed. There is a problem that needs to be processed.
  • a transmission method is a transmission method in which one or more streams are stored in one channel and a plurality of services are stored in one stream in broadcasting, and the plurality of services are transmitted.
  • a generation step of generating a stream that includes a plurality of IP (Internet Protocol) data flows that correspond one-to-one and that store a corresponding service, and a transmission step of transmitting the generated stream is included.
  • the receiving device only needs to process the IP data flow corresponding to the service to be viewed in one stream. Therefore, the processing amount of the receiving device can be reduced.
  • a correspondence relationship between the plurality of services and specific information for specifying the plurality of IP data flows storing the plurality of services is different from the plurality of IP data flows.
  • the stream further including an IP data flow in which program control information to be shown is stored may be generated.
  • the service may be stored in an MMT (MPEG Media Transport) packet in the corresponding IP data flow.
  • MMT MPEG Media Transport
  • the IP data flow may be stored in a TLV (Type Length Value) packet.
  • TLV Type Length Value
  • a reception method is a reception method for receiving a stream in which a stream of one channel 1 or more is stored and a plurality of services are stored in one stream in broadcasting, and the plurality of services
  • IP Internet Protocol
  • the receiving device only needs to process the IP data flow corresponding to the service to be viewed in one stream. Therefore, the processing amount of the receiving device can be reduced.
  • a correspondence relationship between the plurality of services and specific information for specifying the plurality of IP data flows storing the plurality of services is different from the plurality of IP data flows.
  • the stream further including an IP data flow in which program control information is stored is received, and in the reproduction step, an IP data flow corresponding to a service to be reproduced is identified based on the program control information, and the identified IP Services stored in the data flow may be played back.
  • the service may be stored in an MMT (MPEG Media Transport) packet in the corresponding IP data flow.
  • MMT MPEG Media Transport
  • the IP data flow may be stored in a TLV (Type Length Value) packet.
  • TLV Type Length Value
  • a transmission apparatus is a transmission apparatus that stores one or more streams in one channel and stores and transmits a plurality of services in one stream in broadcasting, and includes the plurality of services.
  • a generation unit that generates a stream that includes a plurality of IP (Internet Protocol) data flows that correspond one-to-one and stores a corresponding service, and a transmission unit that transmits the generated stream.
  • IP Internet Protocol
  • the receiving device only needs to process the IP data flow corresponding to the service to be viewed in one stream. Therefore, the processing amount of the receiving device can be reduced.
  • a receiving apparatus is a receiving method for receiving a stream in which one or more streams are stored in one channel and a plurality of services are stored in one stream in broadcasting,
  • a receiving unit that receives the stream including a plurality of IP (Internet Protocol) data flows that correspond one-to-one with a service and stores the corresponding service; and a reproducing unit that reproduces one of the plurality of services from the stream; including.
  • IP Internet Protocol
  • the receiving device only needs to process the IP data flow corresponding to the service to be viewed in one stream. Therefore, the processing amount of the receiving device can be reduced.
  • 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 shows a protocol stack diagram 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
  • the TLV packet is mapped to a transmission slot in the advanced BS transmission system, and the beginning position of the first packet included in each slot and the end of the last packet are included in TMCC (Transmission and Multiplexing Configuration Control) control information (control signal). Pointer / slot information indicating the position 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 TMCC control information 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 device 20 analyzes the TMCC control information, and if it is determined that there is reference clock information in the slot header, it extracts the reference clock information from the slot header.
  • 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 an acquisition flow of 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 information (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, the acquisition and reproduction of the reference clock information by hardware can be easily realized, and the clock with higher accuracy than the 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 Further, such an identifier may be defined in a field other than the data type field of TLV.
  • the reference clock information When the reference clock information is directly referenced from a lower layer, the reference clock information is stored at a predetermined position, and a packet (MMT packet, IP packet, TLV packet, etc.) storing the reference clock information is a reference clock.
  • a packet MMT packet, IP packet, TLV packet, etc.
  • a packet dedicated to information Further, the length of the field before the reference clock information is made constant, for example, the packet header length is fixed.
  • the length of the field before the reference clock information may not be constant. It is only necessary that the length of the field before the reference clock information can be specified in the lower layer.
  • the receiving device 20 signals the position of the reference clock information by signaling which is A or B in the lower layer. Can be identified.
  • the position information of the reference clock information that can directly reference the reference clock information of the upper layer may be stored in the lower layer, and the receiving apparatus 20 may refer to the lower layer based on the position information.
  • 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 extraction at this time may be performed not from a position offset from the TLV packet header by a fixed length but from a position offset from a specific field of the TLV.
  • 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.
  • the MMT including the reference clock information based on the unique identification information (packet ID) given to the MMT packet including the reference clock information.
  • packet ID unique identification information
  • a packet may be specified.
  • the reference clock information is extracted from the specific field as described above.
  • the receiving apparatus 20 specifies the MMT packet including the reference clock information using the above method, specifies the position of the reference clock information based on the MMT packet header information, and extracts it.
  • the data stored in the IP packet may not be the MMT packet, and may be data having another data structure, for example.
  • the reference clock information may be included in the IP packet with a data structure different from that of the MMT packet.
  • identification information or reference clock indicating that data including reference clock information is stored in a dedicated IP data flow and is data including reference clock information. Identification information indicating an IP data flow including information is given.
  • the receiving device 20 identifies that the data includes the reference clock information or the IP data flow including the data including the reference clock information, and extracts the reference clock information when the reference clock information is included. In addition, when the reference clock information is stored at a specific position in the data, the receiving device 20 can extract the reference clock information included in the data by referring to the specific position from the packet configuration of the lower layer.
  • the receiving device 20 uses the reference clock from different fixed-length offset positions based on whether it is an IP packet or a compressed IP packet. Extract information. However, if it is determined that the IP packet including the reference clock information is not subjected to header compression or that all the IP packets including the reference clock information are subjected to header compression, it is determined whether the IP packet or the compressed IP packet is received by the receiving device 20 Can be omitted. Further, after the header of the compressed IP packet is restored, it may be determined whether or not the reference clock information is included.
  • FIG. 21 is a flow for extracting a bit string at a specific position 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).
  • the reference clock information extraction unit 15 acquires the reference clock information included in the MMT packet at a position offset by a fixed length N bytes from the TLV header (S146). .
  • the reference clock information extraction unit 15 acquires the reference clock information included in the MMT packet at a position offset by a fixed length M bytes from the TLV header (S147). .
  • step S146 the reference clock information extraction unit 15 acquires the reference clock information included in the MMT packet from the position offset by N bytes from the TLV header.
  • step S147 the reference clock information extraction unit 15 acquires reference clock information included in the MMT packet from a position offset by M bytes from the TLV header.
  • 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.
  • the proposed method of using the extension area of the conventional TMCC control information is limited to a method of transmitting a data payload such as text or an image using TMCC control information over several frames. Therefore, there is a problem that the method of using the extension area of the TMCC control information is limited.
  • control information (control signal) whose value does not change from frame to frame, such as the conventional transmission mode and slot information, or control information whose value changes from frame to frame, such as reference clock information, is payload data that spans several frames. At the same time, it could not be stored in the extension area of TMCC control information.
  • the receiving device can receive and analyze TMCC control information by a receiving method that differs for each type based on the type of data.
  • TMCC extension information [Configuration of TMCC extended information]
  • the basic configuration of TMCC control information is the configuration shown in FIG. 16, and the types of control information stored in TMCC control information are roughly divided into the following two types.
  • control information related to a frame, and control information whose value does not change for each frame.
  • the minimum update interval of such control information is in units of frames.
  • the changed information is transmitted two frames ahead.
  • notification is performed by incrementing the 8-bit change instruction.
  • control information corresponds to information other than pointer information and slot information.
  • control information related to a frame is control information whose value changes for each frame. Since such control information is information whose value changes for each frame, no change instruction is given.
  • control information is specifically pointer information and slot information.
  • the TMCC extension information is composed of a 16-bit extension identification and a 3598-bit extension area, as shown in FIG. 22A, and the extension area is valid by setting a value other than all 0 to the extension identification. It becomes.
  • FIG. 22 is a diagram illustrating a configuration of TMCC extension information.
  • FIG. 22 (B) of FIG. 22 is a diagram showing an example of a bit allocation method when an extension area is used as a payload, which has been conventionally proposed.
  • the number of pages is configured by 16 bits, and the additional information payload is transmitted over how many frames the TMCC control information being transmitted is transmitted. Indicate.
  • the page number is composed of 16 bits and indicates the number of pages of the TMCC control information currently being transmitted.
  • the additional information type is composed of 8 bits and specifies the type of additional information. Specifically, the additional information type is, for example, a character (caption) super, graphic, audio, or the like.
  • the entire extension area is used as a payload, and control information such as conventional TMCC control information cannot be stored in the extension area using the extension area.
  • extension types The types of information and data stored in the TMCC extension area (hereinafter referred to as extension types) are classified as follows, for example.
  • Type A -Control information related to the frame, and the value does not change for each frame.
  • ⁇ Minimum update interval is in frame units. When there is a change in the value, the information after the change is transmitted two frames ahead.
  • Type B -Control information related to the frame, and the value changes for each frame.
  • Type C Used as payload (conventional extension method).
  • the same change instruction field as that of the TMCC that is not the extension area may be used, or the change instruction field may be independently defined in the extension area.
  • FIG. 23 is a diagram showing an example of the data structure (bit arrangement) of the extension area in which the extension types classified in this way are used.
  • FIG. 24 is a diagram illustrating the syntax when the extension type is used.
  • extension data having the length indicated by the data length is stored for each extension type. Is done.
  • data having a length indicated by the data length is extracted from the extension area and processed.
  • the receiving apparatus acquires data only when there is an instruction to change, and when there is a change in the Type A data, the receiving apparatus follows the change in the control information, assuming that the control information has been changed. Process.
  • the receiving device acquires Type B data for each frame because Type B data is data whose value changes for each frame. For example, when the reference clock information whose value changes for each frame is stored in the TMCC control information, it is stored in the type B data area.
  • the Type C data includes payload information of the conventional extension method, and the receiving apparatus operates according to the acquisition of the conventional extension method for the Type C data.
  • the details of the data structure for each extension type need to be specified separately.
  • identifiers similar to the additional information type and the target service designation method in the Type C data shown in FIG. 22B may be defined in other types.
  • the additional information type may be defined using a common table, or the extended identification and the additional information type may be merged.
  • the information whose data length may change in the middle may be the same type as the data of Type A.
  • the change instruction may be issued by transmitting information after the change two frames ahead.
  • the receiving apparatus refers to the data length of the extension type and confirms whether there is any change in the data length.
  • the data structure is not limited to the structure shown in FIG.
  • the data length of the extension type when the data length of the extension type is fixed in advance, the data length may not be transmitted.
  • the data length of the extension type TypeA in FIG. 23 is a fixed length, the data length of the extension type TypeA does not have to be arranged in the data structure.
  • the data length of the extension type TypeA and the data length of the extension type TypeB are fixed lengths, not all types of data lengths need be arranged.
  • a flag indicating whether or not there is extended type data may be provided in the data structure.
  • the syntax in the case of using the extension type is not limited to the syntax shown in (a) of FIG.
  • the number of extension areas is set, and the extension type and extension area length are stored for each extension area number. Subsequently, extension data corresponding to the number of extension areas is stored.
  • Such a configuration can be applied to future expansion types.
  • a configuration can store a plurality of data of the same extension type, it is not necessary to determine the details of the data configuration for the same extension type in advance.
  • a payload as Type C
  • a plurality of pieces of data with different page numbers such as video and audio can be described in the same frame.
  • the number of extension areas, the extension type, and the extension area length may be the same type as Type A. That is, these pieces of information may be defined as information according to the change instruction. In this way, it is easy to determine whether or not there is a change by continuously storing data according to the change instruction.
  • an undefined area may be provided for the extension type in preparation for future expansion.
  • an extension type to be introduced in the future for example, the following types are assumed.
  • a change instruction is performed in the same manner as Type A, but processing is performed immediately on the frame after obtaining the change instruction, not information that precedes two frames.
  • the emergency flag may be transmitted using an extension type accompanied by a change instruction, and the emergency data may be transmitted using a payload. Further, the extension type may be divided according to whether or not the change instruction is followed.
  • FIG. 25 is a block diagram illustrating a functional configuration of the receiving apparatus according to the second embodiment.
  • FIG. 26 is a diagram illustrating an operation flow of the reception apparatus according to the second embodiment. In the following description, it is assumed that there are only three types of extension, Type A, Type B, and Type C as described above.
  • the receiving device 40 includes an extension identification unit 41, an extension type determination unit 42, a change instruction confirmation unit 43, a data update confirmation unit 44, and an update data acquisition unit 45.
  • the extended identification unit 41 analyzes the extended identification of the TMCC control information (S161). Here, if the extension identification is other than all 0, it is determined that the extension area is valid, and the receiving apparatus 40 executes the following process for each extension area.
  • the extended type determination unit 42 determines (determines) the extended type (S162).
  • the extension type is Type A (Type A in S162)
  • the data of the area specified by the extension area length is control information according to the change instruction without changing the value for each frame. Therefore, the change instruction confirmation unit 43 confirms the change instruction for each frame (S163).
  • the data update confirmation unit 44 determines data update (S164).
  • the update data acquisition unit 45 acquires the updated extension data and executes a process associated with the change (S165). .
  • step S164 when it is not determined as described above in step S164 (No in S164), the update data acquisition unit 45 determines that the extension data is not changed.
  • step S162 When it is determined in step S162 that the extension type is Type B (Type B in S162), the update data acquisition unit 45 refers to the data specified by the extension area length and acquires data updated for each frame. Then, the process associated with the change is executed (S167).
  • step S162 If it is determined in step S162 that the extension type is Type C (Type C in S162), the update data acquisition unit 45 executes processing based on the reception method of the conventional payload extension method (S166).
  • the update data acquisition unit 45 confirms the change instruction, If there is a change instruction, it is checked whether the information has been updated.
  • the receiving device 40 may determine the reception process based on the extension type, and may determine in which processing block the data processing is performed. For example, the receiving apparatus 40 may determine that the data of Type A and the data of Type B are processed by hardware, and the data of Type C is processed by software.
  • the second embodiment has described the method of dividing the TMCC extension area in the advanced BS transmission scheme for each extension type and storing the extension data in the TMCC extension area.
  • the receiving device 40 determines the extension data processing method based on the extension type.
  • the payload and the reference clock information can be simultaneously stored in the extension area.
  • the receiving apparatus 40 can first acquire the payload data of only one frame even while the payload data extending over several frames cannot be received. Therefore, the receiving device 40 can acquire and present highly urgent information earlier.
  • FIG. 27 is a diagram schematically illustrating an example in which reference clock information is stored in each of a plurality of layers.
  • the first layer is a higher layer than the second layer, and the first reference clock information is stored in the first layer.
  • Second reference clock information is stored in the second layer.
  • the transmitting apparatus basically performs the MUX process of the second layer after the MUX process of the first layer.
  • the receiving apparatus basically performs the DEMUX process of the first layer after the DEMUX process of the second layer.
  • the transmission apparatus includes the first reference clock information, the second reference clock information,
  • the following information can be stored as information indicating the relationship.
  • the transmission apparatus can include information indicating that a plurality of reference clock information is stored in a transmission signal (for example, a transmission frame) in the transmission signal.
  • a transmission signal for example, a transmission frame
  • the transmission apparatus stores information indicating that the reference clock information is stored in a layer other than the layer in at least one of the layers including the reference clock information.
  • the transmission apparatus may indicate that a plurality of reference clock information is stored in a layer that does not include the reference clock information.
  • the transmission apparatus may store information indicating whether or not the reference clock information is included in the upper layer (first layer) in the lower layer (second layer).
  • the receiving apparatus can determine whether to perform acquisition of the reference clock information of the lower layer and reproduction of the reference clock in consideration of whether the upper layer includes the reference clock information in the processing of the lower layer.
  • the transmission device can include information on the first reference clock information and the second reference clock information in the transmission signal.
  • the transmission apparatus stores information indicating the type of reference clock information included in each layer in each layer.
  • the transmission apparatus stores information indicating the type of reference clock information included in a layer other than the layer in each layer.
  • the reference clock information includes, for example, 32-bit NTP, 64-bit NTP, 24-bit SMPTE time code, and the like.
  • Information indicating the type of the reference clock information includes the format of the reference clock information (including information such as accuracy). It is information that can specify.
  • the transmission device can include information indicating the relative relationship between the first reference clock information and the second clock information in the transmission signal.
  • the transmission device can include information indicating the relative relationship of the accuracy of the reference clock information.
  • the transmission device includes information indicating that the accuracy of the second reference clock information is higher or lower than the accuracy of the first reference clock information.
  • the information indicating such a relative relationship may be information indicating a relative relationship based on the size of the total number of bits of the reference clock information, or based on the size of the number of bits in the integer part. It may be information indicating.
  • the information indicating the relative relationship may be information indicating the relative relationship of resolution (resolution) accuracy based on the number of bits of the decimal part. Also, the information indicating the relative relationship is based on the reference clock information based on the reliability of the reference clock information in the transmission device, the quality of the transmission path, and the accuracy due to the difference in processing capability in transmission processing and reception processing. It may be information indicating the relative relation of accuracy at the time of acquisition.
  • the information indicating the relative relationship may be information indicating a difference in accuracy between the reference clock information. For example, when there is a difference in the number of decimal bits, information indicating the difference in the number of decimal bits may be used.
  • the information indicating the relative relationship may be information indicating whether the mutual accuracy is the same, or may be stored as information indicating the relative relationship only when the accuracy is different. In addition, when the relative relationship of precision is known beforehand, the information which shows such a relative relationship of precision may not be included.
  • the receiving apparatus indicates that the accuracy of the second reference clock information is lower than the accuracy of the first reference clock information. In this case, it is possible to perform control such that acquisition and reproduction of the first reference clock information is performed without performing acquisition and reproduction of the second reference clock information, and synchronous reproduction is performed based on the first reference clock information.
  • the receiving device may acquire and reproduce the first reference clock information. First, it is possible to perform control such that acquisition and reproduction of the second reference clock information is performed, and synchronous reproduction is performed based on the second reference clock information.
  • the transmission device can include information indicating a relative relationship in time between the reference clock information in the transmission signal. Specifically, the transmission device transmits information indicating the relative time between the first reference clock information and the second reference clock information. For example, the transmission apparatus transmits using CRI_descriptor in the MMT scheme. Information indicating whether the first reference clock information and the second reference clock information are generated based on the same reference clock may be included.
  • each reference clock information is generated based on the same reference clock, there is usually a difference in acquisition timing of the first reference clock information and the second reference clock information in the receiving apparatus. That is, a fixed time difference occurs in the end-to-end delay of each reference clock information.
  • the transmission apparatus calculates a time difference ⁇ _A between the application timing of the first reference clock information and the application timing of the second reference clock information, and uses the calculated time difference ⁇ _A as the first reference clock information and the second reference clock information. It is stored in the transmission signal as a time corresponding to the acquisition timing of the reference clock information.
  • the receiving apparatus obtains the time difference ⁇ _A from the transmission signal, and corrects the end-to-end delay difference between the first reference clock information and the second reference clock information based on the time difference ⁇ _A.
  • each reference clock information is generated based on a reference clock having the same format, and each reference clock information has a fixed delay difference ⁇ _B
  • the transmission apparatus sets a fixed delay difference ⁇ _B of the reference clock information. Store and send the information shown.
  • the receiving apparatus acquires the delay difference ⁇ _B and corrects the fixed delay difference of the reference clock based on the delay difference ⁇ _B.
  • the transmission apparatus transmits the second layer, which is a lower layer, including the fixed delay ⁇ _B.
  • the second reference clock information is represented by a difference from the first clock information based on the first reference clock information. May be. in this case.
  • the second reference clock information may be used as a base.
  • the transmission apparatus can include information on whether to use the reference clock information stored in different layers in the transmission signal.
  • the transmission device includes, for example, information indicating that the second reference clock information stored in the second layer is to be used in the first layer in the transmission signal.
  • the receiving apparatus can determine to generate the second reference clock information and output it to the first layer based on the information.
  • Information as described above is stored in at least one or more layers.
  • such information may be stored only in the first layer, or may be stored only in the second layer.
  • Such information may be stored in both layers.
  • the information regarding the reference clock information in the layer may be stored, and only the information indicating the relative relationship may be stored in at least one or more layers.
  • the information indicating the relative relationship is preferably stored in a lower layer (second layer). Alternatively, it may be stored in a lower layer (not shown in FIG. 27) than the second layer.
  • the receiving apparatus can acquire information on the reference clock information of the upper layer (first layer) during the DEMUX processing of the lower layer (second layer), thereby enabling higher-speed processing.
  • the combination of the first layer and the second layer may be any combination.
  • the combination of the first layer and the second layer may be a combination of an MMT layer and an IP layer, an MMT layer and a transmission layer, and an IP layer and a transmission layer.
  • the combination of the first layer and the second layer may be a combination of MMT and TS in the case of MMOverTS.
  • the above information is stored in the control signal of each layer.
  • the MMT system it is stored in descriptors, tables, messages, and packet header information.
  • the MPEG2-TS system it is stored in descriptors, tables, sections, and header information. Further, it may be stored in a TMCC or slot header in the transmission layer.
  • the transmission method is DVB, it is stored in TPS, L1 data, L2 data, P1 data, P2 data, and the like.
  • first reference clock information and the second reference clock information may be the same type of reference clock information or different types of reference clock information. Further, the first reference clock information and the second reference clock information may be reference clock information with different accuracy. The first reference clock information and the second reference clock information may be reference clock information based on the same reference clock, or may be reference clock information based on different reference clocks.
  • the transmission apparatus may transmit three or more reference clock information, or may store and transmit the reference clock information in each of three or more layers. Further, the reference clock information may be stored in each of different fields in the data structure in the same layer. Another layer may exist between the first layer and the second layer.
  • the reference clock information is, for example, NTP, time code, and PTP, but other reference clock information may be used. Further, the reference clock information may be information on other times (for example, TOT (Time Offset Table) and TDT (Time Date Table)).
  • FIG. 28 is a diagram schematically illustrating an example in which a plurality of reference clock information is stored in one layer.
  • the first layer includes three pieces of reference clock information including first reference clock information, second reference clock information, and third reference clock information.
  • the transmission device can store information on the first reference clock information and the second reference clock information, information indicating the relative relationship between each (accuracy and time), and the like.
  • FIG. 29 is a block diagram for explaining an example in which data of different broadcasting stations are stored separately in streams.
  • the first broadcast station 51, the second broadcast station 52, and the third broadcast station 53 are configured to transmit data generated by the respective broadcast stations by wire or radio such as an optical line. Used to transmit to the satellite transmitting station 54.
  • the satellite transmitting station 54 multiplexes the streams of the respective broadcasting stations on the same advanced BS transmission system transmission channel.
  • the satellite transmitting station 54 stores the reference clock information corresponding to the stream of each broadcasting station in the TMCC and transmits it to the receiving device 50.
  • the first reference clock information is the reference clock information of the first broadcast station 51
  • the second reference clock information is the reference clock information of the second broadcast station 52
  • the third reference clock information corresponds to the third broadcasting station 53, respectively.
  • each reference clock information in the satellite transmission station 54 is received until it arrives at the satellite transmission station. There is a time difference due to a difference in end-to-end delay due to processing delay or transmission delay.
  • the common reference clock information used in each broadcasting station is NTP_base
  • the first reference clock information in the satellite transmission station is NTP_base + ⁇ 1
  • the second reference clock information is NTP_base + ⁇ 2
  • the third reference clock information is It is expressed as NTP_base + ⁇ 3.
  • the transmission apparatus transmits common reference clock information NTP_base, and difference information ( ⁇ 1, ⁇ 2, ⁇ 3) between each reference clock information and common reference clock information. May be sent.
  • FIG. 30 is a diagram for explaining a transmission method of difference information. Also, for example, of the 64-bit reference clock information, the base reference clock information is expressed by the upper 16 bits, and the difference information is expressed by the remaining 48 bits, thereby reducing the amount of information (size) when transmitting the reference clock information. can do.
  • the base reference clock information may not be NTP_base, and may be the earliest (small delay) reference clock information among a plurality of pieces of reference clock information.
  • the base reference clock information (reference value) may be a value smaller than the value of the earliest reference clock information.
  • FIG. 31 is a diagram for explaining a modification of the difference information transmission method. With the transmission method as shown in FIG. 31, the information amount (size) at the time of transmission of the reference clock information can be reduced.
  • the receiving device 50 regenerates the base reference clock using the base reference clock information. After the reproduction of the base reference clock information, each reference clock may be generated using the difference information.
  • FIG. 32 is a block diagram illustrating a functional configuration of the receiving device 50.
  • FIG. 33 is a diagram illustrating an operation flow of the reception device 50.
  • the reference clock information is stored only in one of the IP layer and the transmission layer, and the receiving device 50 reproduces the reference clock based on one of the reference clock information.
  • the receiving device 50 includes a receiving unit 10, a decoding unit 11, a TLV demultiplexer 12, an IP demultiplexer 13, an MMT demultiplexer 14, a synchronization unit 17, and a decoding presentation unit 18.
  • the receiving apparatus 50 includes a first reference clock information extraction unit 15a, a second reference clock information extraction unit 15b, a first reference clock generation unit 16a, and a second reference clock generation unit 16b.
  • the transmission layer control information (slot header, TMCC, etc., here TMCC), a flag indicating whether or not there is reference clock information in the IP layer is stored.
  • the transmission layer control information stores reference clock information when there is no reference clock information in the IP layer.
  • the transmission layer control information when there is no reference clock information in the IP layer, a flag indicating whether or not the reference clock information acquired in the transmission layer is necessary for processing of the upper layer, or a reproduced reference clock A flag indicating whether information is necessary for processing of the upper layer is stored.
  • the reference clock information is a 64-bit NTP
  • the NTP is stored in a 64-bit field indicating the reference clock information.
  • a flag indicating whether or not there is reference clock information in the IP layer may be provided in the field of reference clock information.
  • the receiving device 50 determines that the value is not reference clock information but is in the IP layer. It is determined that the flag indicates that there is information.
  • the receiving device 50 determines that there is reference clock information when ALL1 is indicated only once in the reference clock information field, and if the ALL1 is indicated continuously for a predetermined number of times or more, A value based on a predetermined rule such as determining that there is reference clock information may be used as a flag.
  • the decoding unit 11 of the receiving device 50 analyzes TMCC that is control information in the transmission layer, and analyzes various flags and reference clock information (S171). And the decoding part 11 performs determination based on the said flag (S172).
  • the second reference clock information extraction unit 15b acquires (extracts) the reference clock information in the transmission layer. Then, the second reference clock generation unit 16b reproduces (generates) the reference clock.
  • the decoding unit 11 determines whether or not the reference clock regenerated in the transmission layer is necessary for processing of the upper layer (S174).
  • the second reference clock generation unit 16b outputs the regenerated reference clock in step S174 to the upper layer. (S175). If it is not determined that the reference clock regenerated in the transmission layer is necessary for processing in the upper layer (No in S174), the process is terminated.
  • the first reference clock information extraction unit 15a and the first reference clock generation unit 16a acquire the reference clock information and reproduce the reference clock in the IP layer (S176).
  • the acquisition of the reference clock information and the reproduction of the reference clock in the transmission layer may not be performed (S173).
  • the reference clock information may be passed to the upper layer instead of outputting the recovered reference clock, and the reference clock may be recovered in the upper layer. Further, reference clock information may be newly generated based on the reference clock reproduced in the transmission layer, and the generated reference clock information may be output to the upper layer.
  • the method for outputting the reference clock to the upper layer is to output the recovered reference clock as it is, or to store or convert the acquired reference clock information or newly generated reference clock information in the data structure to be output to the upper layer. There is a method to output.
  • FIG. 34 is a diagram illustrating another operation flow of the reception device 50.
  • the configuration of the receiving device 50 is the same as that shown in FIG.
  • the reference clock information can be stored in each of the IP layer and the transmission layer, and when a plurality of reference clock information is stored, relative information on the accuracy of the reference clock information is stored. Shall.
  • the decoding unit 11 analyzes the TMCC (S181), and performs determination based on the flag (S182). When it is determined that there is no reference clock information in the IP layer (No in S182), acquisition of the reference clock information and reproduction of the reference clock are performed in the transmission layer (S185).
  • step S182 if it is determined in step S182 that there is reference clock information in the IP layer (Yes in S182), the decoding unit 11 is more accurate between the reference clock information in the transmission layer and the reference clock information in the IP layer. Is determined (S183). When it is determined that the reference clock information of the IP layer is more accurate than the reference clock information of the transmission layer (Yes in S183), acquisition of the reference clock information and reproduction of the reference clock are performed in the IP layer (S184). . When it is determined that the accuracy of the reference clock information of the IP layer is lower than that of the reference clock information of the transmission layer (No in S183), acquisition of the reference clock information and reproduction of the reference clock are performed in the transmission layer (S185). .
  • a plurality of pieces of reference clock information may be transmitted in one or more layers.
  • the receiving device 50 may select either one of the reference clock information and use it for generating a reference clock (system clock), or use both to generate the reference clock. It may be generated. At this time, the receiving device 50 may select reference clock information with high accuracy, or may select reference clock information that can be acquired earlier.
  • the reference clock information when the reference clock information is transmitted in a plurality of layers, information indicating that the reference clock information is transmitted in a plurality of layers may be stored on the transmission side. Further, information indicating that the reference clock information is transmitted in a plurality of layers, or information related to the layer or protocol in which the reference clock information is transmitted may be transmitted in the lower layer. Furthermore, information indicating the relationship between reference clock information stored in different layers may be transmitted.
  • the receiving apparatus 50 can determine that the reference clock information is included in the upper layer during the DEMUX processing of the lower layer, and determines which reference clock information to use based on the determination. be able to.
  • the determination of which reference clock information to use may be determined based on which layer's reference clock recovery is supported by the receiving device 50, or a recommended reference clock recovery is specified by the broadcast station. Also good.
  • the reception device 50 may extract the reference clock information included in the upper layer from the lower layer at the same time as extracting the reference clock information in the lower layer. . Then, the receiving device 50 may generate a reference clock using at least one or more extracted reference clock information.
  • a plurality of reference clock information may be transmitted through a plurality of transmission paths.
  • a plurality of reference clock information may be transmitted through a plurality of transmission paths, or information relating to a transmission path in which the reference clock information is transmitted may be transmitted.
  • 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 When the NTP field is reduced, the receiving apparatus generates a reference clock using other reference clock information and reproduces a 32-bit short format NTP.
  • the receiving device 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, and by applying the present disclosure, it is possible to shorten the time until acquisition of reference clock information in the receiving device, reduce processing, and implement a clock by hardware implementation. High accuracy can be realized.
  • the reference clock information in the above embodiment is NTP when the multiplexing method is MMT.
  • the reference clock information is PCR (Program Clock Reference). is there.
  • PTP defined by IEEE 1588 may be transmitted in the NTP format. Only some bits of the NTP may be transmitted. That is, the reference clock information may be information indicating the time set by the transmission side. Note that NTP does not necessarily mean an NTP value in an NTP server that is generally used on the Internet.
  • FIG. 35 is a block diagram illustrating a functional configuration of the transmission apparatus.
  • FIG. 36 is 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. 36).
  • the generation unit 31 broadcasts content (for example, video or audio) to an IP packet (hereinafter also referred to as a target IP packet) stored in the TLV packet located at the head in the head slot in the transmission slot.
  • First reference clock information such as NTP indicating the time for reproducing (content) is included.
  • the target IP packet is an IP packet not subjected to header compression, and the first reference clock information is stored in a data structure different from that of the MMT packet in the target IP packet, for example.
  • the generation unit 31 stores second reference clock information indicating the time for reproducing the content in the control information (TMCC) in the transmission slot.
  • 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.
  • 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. 36).
  • the processing for the reception device to acquire the reference clock information can be simplified. Therefore, it is possible to shorten the time until the receiving device acquires the reference clock information.
  • the second reference clock information indicating the time for reproducing the content is stored in the control information in the frame, so that the receiving apparatus can select either the first reference clock information or the second reference clock information. Whether to use the reference clock information can be selected.
  • FIG. 37 is a block diagram showing a configuration of receiving apparatus 60 according to the present embodiment.
  • the receiving device 60 includes a decoding device 61 that performs lower layer processing, and a demultiplexing device 62 that performs upper layer processing.
  • the decoding device 61 and the demultiplexing device 62 are formed as different LSIs. Note that the decoding device 61 and the demultiplexing device 62 may be formed as a single LSI.
  • the decoding device 61 includes a receiving unit 10 and a decoding unit 11.
  • the receiving unit 10 receives transmission path encoded data.
  • the decoding unit 11 extracts the TLV packet by decoding the transmission path encoded data received by the receiving unit 10, and outputs the TLV packet to the demultiplexer 62.
  • the demultiplexing device 62 includes an acquisition unit 63 and a demultiplexing unit 64.
  • the acquisition unit 63 acquires the main TLV packet from the decoding device 61.
  • the demultiplexer 64 demultiplexes the TLV packet.
  • the demultiplexing unit 64 includes processing units other than the receiving unit 10 and the decoding unit 11 among the processing units illustrated in FIG.
  • the demultiplexing unit 64 may include processing units other than the receiving unit 10 and the decoding unit 11 among the processing units included in the receiving apparatus described in the other embodiments.
  • the demultiplexing unit 64 does not need to include all of these processing units, and may include only a part thereof.
  • the demultiplexer 62 controls the output of the decoder 61.
  • the reproduced reference clock is not output to the upper layer demultiplexing apparatus 62,
  • the reference clock information is passed to the demultiplexer 62, and the method of reproducing the reference clock in the demultiplexer 62 is captured and described in detail.
  • Non-Patent Document 2 ARIB Standard ARIB STD-B44 (2.0), Chapter 3 “Guidelines on Time Information Transmission” in “Transmission Method of Advanced Broadband Satellite Digital Broadcasting”) The transmission / reception of the reference clock based on the data structure will be described.
  • the above standard describes a method for storing the reference clock information in the TMCC, the time information to be specifically transmitted and the operation in the receiving device are not specified, and accurate time information is obtained in the receiving device. I can't.
  • the reference clock information stored in the TMCC is the time when the TMCC signal leaves the transmission server”, but it is not a specific definition.
  • the TMCC control information (TMCC control signal) is generated for each transmission frame in a separate system from the main system main signal for each transmission frame, and is subjected to error correction coding and interleaving processing.
  • the signal (the main signal is also a signal after error correction coding and interleaving processing) is mapped in a distributed manner.
  • FIG. 38 is a diagram showing the timing of the main signal and reference clock information.
  • the reference clock information When the reference clock information is stored in the TMCC control information, the reference clock information (NPTn, NPTn + 1,... In FIG. 38) is generated at intervals (T F ) of the transmission frame time length. After the reference clock information is generated, it is transmitted in units of transmission frames. At this time, processing delay due to error correction coding, interleave processing, transmission frame transmission timing, and the like occurs from generation of the reference clock information to transmission of the transmission frame.
  • NTPn is stored and transmitted in the transmission frame M + 1
  • NTPn + 1 is stored and transmitted in the transmission frame M + 2.
  • the transmission delay is 0, and the transmission time and the reception time of the transmission frame are the same.
  • the receiving device receives data for one transmission frame, and extracts TMCC control information after error correction processing and deinterleaving processing. Therefore, the reception timing of the reference clock information is delayed by one frame or more.
  • processing delay occurs in transmission and reception due to error correction and interleaving processing.
  • the reference clock information is stored in the TMCC control information according to the following method.
  • the transmission device sets the reference clock information stored in the TMCC control information at, for example, the time when the main signal transmission frame sends the server (for example, the time when the first packet of the transmission frame sends the server).
  • the receiving device stores the reference clock information extracted from the TMCC control information at the head position of the next transmission frame and transmits it to the upper layer.
  • the relative relationship due to the difference in processing delay between the main line system and the TMCC control information system is an integral multiple of the transmission frame (N ⁇ T F ) (N is an integer).
  • N ⁇ TF is corrected.
  • the time when the transmission device has corrected N ⁇ TF may be stored in the TMCC control information, or the reception device may correct the time. If N cannot be determined uniquely, the receiving apparatus estimates N and corrects the time.
  • the transmission device When the reference clock information is transmitted by the main signal (TLV packet) in addition to the TMCC control information, the transmission device stores the same time as the time stored in the TLV packet in the TMCC control information. To do. Alternatively, the transmission apparatus stores, in the TMCC control information, a time when correction according to N ⁇ TF is performed on the time stored in the TLV packet.
  • the receiving apparatus by correcting the time information extracted from the TMCC control information by N ⁇ TF , the same time as the time stored in the main signal is calculated, and the calculated time is output to the upper layer.
  • the receiving apparatus may replace the reference clock information in the TLV packet and output it.
  • the upper layer can handle these reference clock information as the same information.
  • the receiving device 60 selects a method of outputting only one of the reference clock information stored in the TMCC control information and the TLV packet as a main signal (TLV packet), a method of outputting both, and the like. It may be switched by, for example. Further, this switching in the lower layer may be selected by the demultiplexer 62 in the upper layer. When the decoding device 61 and the demultiplexing device 62 are physically different, one method may be selected by a register or the like. Further, when outputting only one of the reference clock information stored in the TMCC control information and the TLV packet, it may be possible to select which one to output.
  • the decoding device 61 can uniquely identify the TLV packet in which the reference clock information is stored in the transmission layer.
  • the demultiplexer 62 of the upper layer cannot grasp the boundary information of the transmission frame, it can be determined whether or not the received TLV packet includes the reference clock information after analyzing the TLV packet header and the IP packet header. It becomes. Therefore, in the present embodiment, the lower layer decoding apparatus 61 sends the TLV packet to the head of the TLV stream in the transmission frame, or the TLV packet is the reference clock information. Is included (signaled). Accordingly, the upper layer demultiplexer 62 can detect that the TLV packet includes the reference clock information without analyzing the header of the IP packet.
  • the TLV packet As a method of signaling that the TLV packet is the head of the TLV stream in the transmission frame or that the TLV packet includes the reference clock information, there is a method of using an undefined area of the packet type of the TLV packet, for example.
  • the decoding device 61 when the reference clock information is included in the IPv4 packet, the decoding device 61 rewrites the TLV type from the TLV type indicating the IPv4 packet to the TLV type indicating the IPv4 packet including the reference clock information. The rewritten TLV packet is output to the demultiplexer 62.
  • the decoding device 61 When the reference clock information is included in the IPv6 packet, the decoding device 61 rewrites the TLV type from the TLV type indicating the IPv6 packet to the TLV type indicating the IPv6 packet including the reference clock information. The rewritten TLV packet is output to the demultiplexer 62.
  • the receiving device 60 may include a switch that can select whether or not to signal that the TLV packet includes the reference clock information from the decoding device 61 to the demultiplexing device 62. For example, this selection may be made from the demultiplexer 62.
  • FIG. 39 is a diagram illustrating an operation flow in the decoding unit 11 of the reception device 60.
  • the decoding unit 11 decodes the transmission frame (S191), and then the reference clock information to be processed is the reference clock information stored in the TMCC or the reference clock information stored in the main signal. It is determined whether it exists (S192). When the reference clock information stored in the main signal is processed (the main signal in S192), the decoding unit 11 outputs the TLV packet as it is to the upper layer (S193). On the other hand, when processing the reference clock information stored in the TMCC control information (TMCC in S192), the decoding unit 11 extracts the reference clock information from the TMCC control information, corrects the extracted reference clock information, and performs correction. The later reference clock information is stored in the first TLV packet of the TLV stream in the transmission frame, and the TLV packet is output to the demultiplexer 62 (S194).
  • FIG. 40 is a diagram illustrating an operation flow in the receiving device 60 including the decoding unit 11.
  • the demultiplexer 62 (upper layer) designates reference clock information output from the decoder 61 to the demultiplexer 62 (S201).
  • the decoding device 61 outputs the TLV packet as it is to the demultiplexer 62 (S203).
  • the decoding device 61 extracts the reference clock information from the TMCC control information and extracts it.
  • the corrected reference clock information is corrected, the corrected reference clock information is stored in the first TLV packet of the TLV stream in the transmission frame, and the TLV packet is output to the demultiplexer 62 (S204).
  • FIG. 41 is a diagram showing an operation flow in the demultiplexer 62 when the decoding device 61 is signaling to the TLV packet type whether or not the TLV packet includes reference clock information.
  • the demultiplexer 62 analyzes the packet type of the TLV packet acquired from the decoder 61 (S211), and determines whether the TLV packet includes reference clock information (S212).
  • the demultiplexer 62 acquires the reference clock information without analyzing the IP packet header (S213). Thereby, the processing time can be shortened and the processing amount can be reduced.
  • the demultiplexer 62 performs normal TLV Demux and IP Demux assuming that the TLV packet does not include the reference clock information (S214). .
  • the receiving device 60 identifies the reference clock information by the TLV packet type. This eliminates the need for IP address analysis. This is because, by identifying the reference clock information by the TLV packet type, there is one IP data flow for storing the reference clock information and one IP data flow for storing the MMT packet. This is because the analysis of the IP address for identifying the flow becomes unnecessary.
  • the decoding apparatus 61 and the demultiplexing apparatus 62 perform the following processing.
  • FIG. 42 is a diagram showing an operation flow in the decoding device 61 according to the present embodiment.
  • the receiving unit 10 receives a transmission slot (S221).
  • the transmission slot stores a plurality of slots (second transmission units) including one or more TLV packets (first transmission units) obtained by multiplexing the contents. Frame for transmission.
  • the TLV packet located at the head in the head slot in the transmission slot includes the reference clock information.
  • the decoding unit 11 acquires a plurality of TLV packets by decoding the transmission slot. Further, the decoding unit 11 further generates information for specifying the TLV packet located at the head in the head slot in the transmission slot (S222).
  • the decoding unit 11 stores the reference clock information as the management information (packet type) of the TLV packet stored in the TLV packet located at the head in the head slot in the transmission slot. Stores information indicating inclusion.
  • the information for specifying the TLV packet positioned first in the first slot in the transmission slot is the TLV positioned first in the first slot in the transmission slot among the plurality of TLV packets in the transmission slot. Information indicating a packet.
  • the decoding unit 11 generates information for specifying the TLV packet located at the head in the head slot in the transmission slot, and notifies the demultiplexer 62 of the information. Specifically, the decoding unit 11 adds the information to the TLV packet, or notifies the demultiplexer 62 of the information using another signal.
  • the decoding unit 11 outputs the TLV packet including the information or the TLV packet and the information to the demultiplexer (S223).
  • FIG. 43 is a diagram showing an operation flow in the demultiplexer 62 according to the present embodiment.
  • each TLV packet includes management information (packet type) indicating that the TLV packet includes the reference clock information when the TLV packet includes the reference clock information.
  • the demultiplexing unit 64 specifies a TLV packet including the reference clock information based on the management information (S232), and acquires the reference clock information from the specified TLV packet (S233). Further, the demultiplexing unit 64 acquires content by demultiplexing a plurality of TLV packets (S234).
  • receiving apparatus 60 information for specifying a TLV packet including reference clock information is notified from decoding apparatus 61 to demultiplexing apparatus 62.
  • the demultiplexer 62 can acquire the reference clock information without analyzing the IP packet header or the like, so that the processing amount can be reduced and the processing speed can be increased.
  • 44A and 44B are diagrams showing an example of service configuration when the conventional MPEG-2 TS system is used, and control information indicating the service configuration.
  • a plurality of services are stored in one stream, and a service ID is given for each service.
  • the service ID of service # 1 is 221
  • the service ID of service # 2 is 222
  • the service ID of service # 3 is 223.
  • One service includes a plurality of components (video, audio, subtitles, data, control information, etc.), and configuration information of the plurality of components is described in the program information for each service.
  • Program information in the MPEG-2 TS is PMT (Program Map Table), which indicates a PID for identifying a packet for each component.
  • Program information is shown for each service, and a list of program information is shown in control information for managing the program.
  • Control information for managing programs in MPEG-2 TS is PAT (Program Association Table), which shows a service ID of a plurality of program information (PMT) and a list of PIDs for identifying packets. Further, the PID of the PAT is known and predetermined.
  • the receiving apparatus acquires a PAT using a known PID (step 1), and acquires a PMT corresponding to the specified service ID from a list of PMTs inside the PAT (step 2).
  • the receiving device acquires the PMT using the acquired PID, specifies the PID of the component constituting the service, and acquires the component using the specified PID (step 3).
  • MPEG-2 TS always requires three steps until component acquisition.
  • FIG. 44B is a diagram showing an example in which one service is stored in one stream.
  • the number of services is one, one PMT is sufficient.
  • the PID of the component constituting the service can be specified using the above method.
  • mottled organization even if there is only one service, there are always three services.
  • a PMT and a service ID are required.
  • each of the three PMTs points to the same component. This has the advantage that the number of services and the service list in the PAT do not change even when mottled broadcasting is performed in a time division manner.
  • the same contents are described in the three PMTs shown in FIG. 44B except for the service ID.
  • FIG. 45A and FIG. 45B are diagrams showing this service configuration example.
  • a stream indicated by one or more TLV-IDs is stored in one physical channel, and a plurality of streams indicated by one TLV-ID are stored in a plurality of streams.
  • Multiple organizations that store services are possible. That is, it is possible to perform a mottled broadcast in which the number of services is changed in a time division within a given band.
  • the switching in mottled broadcasting may be switching of resolution such as 4k broadcasting and 8k broadcasting as well as switching between SD and HD. Further, not only resolution switching but also service switching with different frame rates or transmission quality may be used. In other words, there may be mottled broadcasting of a combination of services that share bandwidth.
  • MMT MMT Package Table
  • PLT Package List Table
  • PLT indicates a list for each package, and indicates a package ID of a plurality of services and a packet ID of a PA message that transmits an MPT indicating the configuration of the service corresponding to each service.
  • PLT may use not only a packet ID but also an IP address, a UDP port number, a URL, and the like in order to indicate a PA message for transmitting an MPT indicating a service configuration.
  • Both MPT and PLT are indicated in the PA message, and are associated with packet IDs for identifying packets that transmit the PA message.
  • the packet ID of the PA message including PLT is known and predetermined. Note that the number of bits of the package ID is arbitrary and may be variable. In the MMT / TLV system, it is specified that the service ID is stored in the lower 16 bits.
  • the receiving apparatus receives the PA message including the PLT from the known packet ID (step 1), determines whether the lower 16 bits of the package ID indicated by the MPT included in the PA message matches the service ID, If they match, the packet ID of the component is specified based on the MPT, and the component of the specified packet ID is acquired (step 2). If they do not match, the receiving apparatus refers to the PLT, acquires the packet ID of the PA message that transmits the MPT that matches the service ID, specifies the packet ID of the component based on the MPT, and specifies the specified packet ID Are acquired (step 3).
  • the component can be acquired in two steps, so the MPEG-2 TS system As a result, the channel selection time can be shortened.
  • mottled broadcasting (4k broadcast ⁇ 3 service and 8k service ⁇ 1 service) using the MMT / TLV system is operated.
  • FIG. 45B is a diagram illustrating a configuration example in the case of 8k service ⁇ 1.
  • the user views the same service regardless of which service ID is specified among the three service IDs.
  • the MPEG-2 TS method always requires three steps to acquire a component, whereas the MMT / TLV method acquires a component in two steps when service # 1 is specified. it can.
  • the steps until the component acquisition is performed by the designated service ID. The number is different and not preferred.
  • the receiving apparatus first acquires a PA message in which the PLT is stored.
  • This PA message always includes MPT # 1 of service # 1. That is, when service # 2 or service # 3 is designated, the receiving apparatus acquires MPT # 2 or MPT # 3 even though the desired service information has already been obtained by acquiring MPT # 1. It is necessary to process the steps. This leads to not only an increase in channel selection time but also an increase in processing amount of the receiving apparatus.
  • the transmitting device stores information indicating that these are virtual services and there is only one substantial service in the stream even when there are a plurality of services.
  • the transmission device stores information indicating that the data is not multi-organized in the MPT # 1 or the PLT in the mottled broadcast.
  • the video component descriptor stored in the MPT indicates that the video resolution is 8k, it may be determined that there is only one substantial service.
  • the receiving device analyzes MPT # 1 or PLT based on the above information and determines whether there is only one substantial service. When there is only one substantial service, the receiving apparatus does not acquire MPT # 2 or MPT # 3, but acquires a component based on MPT # 1. As a result, the receiving device can always acquire a component in two steps regardless of the specified service ID.
  • FIG. 46A is a diagram showing a conventional operation example when the service # 2 is designated.
  • FIG. 46B is a diagram illustrating an operation example of this embodiment when the service # 2 is designated.
  • the conventional method shown in FIG. 46A requires three steps of processing, whereas the method of the present embodiment shown in FIG. 46B reduces the processing to two steps.
  • FIG. 47 is a diagram showing an operation flow of the receiving apparatus according to the present embodiment.
  • the receiving apparatus determines whether the data is multi-organized by analyzing MPT # 1 or PLT (S241). If the data is multi-organization (Yes in S242), the receiving apparatus acquires MPT # 2 or MPT # 3, and acquires the component by analyzing MPT # 2 or MPT # 3 (S243). On the other hand, when the data is not multi-organization (No in S242), the receiving apparatus acquires the component by analyzing MPT # 1 (S244).
  • Another service ID corresponding to the same service is stored using an area other than the lower 16 bits of the package ID in MPT or PLT. For example, if MPT # 1 to # 3 correspond to the same service, as shown in FIG. 48, the service IDs of MPT # 2 and MPT # 3 are lower 16 of the package ID in MPT # 1 or PLT. An area other than a bit may be used. Similarly, other service IDs corresponding to the same service may be indicated in the package IDs of MPT # 2 and MPT # 3.
  • the receiving apparatus acquires MPT # 2 or MPT # 3 by confirming whether or not the desired service ID (service # 1, service # 2, or service # 3) is included in the package ID of MPT # 1. You can get the component without doing it.
  • reception processing processing such as TLV Demux, IP header expansion (reduction of reduced header), IP Demux, and MMT Demux is required.
  • processing such as TLV Demux, IP header expansion (reduction of reduced header), IP Demux, and MMT Demux is required.
  • IP data flow service as shown in FIG.
  • PLT is control information that stores information across multiple services
  • a single PLT cannot exist across all IP data flows, so a single PLT is used to indicate a list of multiple services.
  • I can't.
  • IP data flow # 1 is extracted in IP Demux
  • IP data flow # 2 is extracted in IP Demux
  • no other IP data flow (service) can be selected because there is no PLT in IP data flow # 2.
  • the packet ID is unique within the IP data flow, and when the IP data flow is crossed, it is not guaranteed that the packet ID is unique. Therefore, the data cannot be specified only by the packet ID across the IP data flow.
  • the first method is a method in which the PLT is copied to all IP data flows and stored in each IP data flow (service).
  • the packet ID of the PLT stored in each IP data flow is the same.
  • the receiving apparatus can perform channel selection based on the PLT.
  • the receiving apparatus may perform processing without using the PLT, assuming that there is only one service.
  • the second method is a method of storing the PLT in a dedicated IP data flow (IP data flow # 0) as shown in FIG. That is, only the PLT is stored in a different IP data flow than the MPT and components. This makes it possible for PLTs to exist across IP data flows. For example, by specifying an IP data flow (service) and a packet ID in the PLT, the MPT of a desired service can be specified.
  • IP data flow # 0 IP data flow
  • the receiving device can extract and process only a desired service in IP Demux, and the processing amount and power consumption can be reduced.
  • the receiving device uses the IP address of the uncompressed IP packet and the context identifier of the compressed IP packet, and reduces the processing amount and power consumption by not expanding the header if it is not the desired service. May be.
  • the MMT packet ID is unique in the IP data flow
  • there is only one PLT in the IP data flow and therefore there may be a plurality of PLTs for each IP data flow. In that case, only one service may be stored in one IP data flow.
  • PLT may not be used.
  • FIG. 51 is a block diagram of transmitting apparatus 70 according to the present embodiment.
  • the transmission device 70 includes a generation unit 71 and a transmission unit 72.
  • FIG. 52 is a flowchart of a transmission method by the transmission apparatus 70 according to the present embodiment.
  • the generation unit 71 has a one-to-one correspondence with a plurality of services # 1 to # 3 and a plurality of IP (Internet Protocol) data flows # 1 to # 3 in which corresponding services are stored. Is generated (S251).
  • the generation unit 71 is an IP data flow different from the plurality of IP data flows # 1 to # 3, and includes a plurality of services # 1 to # 3 and a plurality of IP data flows.
  • a stream further including an IP data flow # 0 in which PLT, which is program control information indicating a correspondence relationship with specific information (IP address or packet ID) specifying # 1 to # 3, is stored.
  • the transmission unit 72 transmits the stream generated by the generation unit 71 to the reception device (S252).
  • FIG. 53 is a block diagram of receiving apparatus 80 according to the present embodiment.
  • the receiving device 80 includes a receiving unit 81 and a reproducing unit 82.
  • the reception unit 81 corresponds to the reception unit 10 in each of the above-described embodiments
  • the reproduction unit 82 corresponds to a processing unit other than the reception unit 10.
  • FIG. 54 is a flowchart of a reception method by the reception device 80 according to the present embodiment.
  • the receiving unit 81 receives a stream including a plurality of IP data flows # 1 to # 3 in which the corresponding services are stored on a one-to-one basis and corresponding services are stored (S261).
  • the receiving unit 81 is an IP data flow different from the plurality of IP data flows # 1 to # 3, and includes a plurality of services # 1 to # 3 and a plurality of IP data flows.
  • PLT which is program control information indicating a correspondence relationship with specific information (IP address or packet ID) specifying # 1 to # 3
  • the reproducing unit 82 reproduces one of a plurality of services from the stream (S262). Specifically, the playback unit 82 specifies an IP data flow corresponding to the service to be played back based on the PLT, and plays back the service stored in the specified IP data flow.
  • the receiving device 80 does not need to process data of services that are not viewed, and thus the processing amount can be reduced.
  • 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 on the reception side when the MMT method is applied to a broadcasting system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (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/JP2015/004071 2014-08-28 2015-08-17 送信方法、受信方法、送信装置及び受信装置 WO2016031173A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP15836696.3A EP3188486A4 (en) 2014-08-28 2015-08-17 Transmission method, reception method, transmission device, and reception device
CN201580041969.6A CN106576189B (zh) 2014-08-28 2015-08-17 发送方法、接收方法、发送装置及接收装置
US15/437,483 US11743312B2 (en) 2014-08-28 2017-02-21 Transmission method, reception method, transmission apparatus, and reception apparatus
US18/221,983 US12143430B2 (en) 2015-07-31 2023-07-14 Transmission method, reception method, transmission apparatus, and reception apparatus

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462043121P 2014-08-28 2014-08-28
US62/043,121 2014-08-28
JP2015-152753 2015-07-31
JP2015152753A JP6667128B2 (ja) 2014-08-28 2015-07-31 送信方法、受信方法、送信装置及び受信装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/437,483 Continuation US11743312B2 (en) 2014-08-28 2017-02-21 Transmission method, reception method, transmission apparatus, and reception apparatus

Publications (1)

Publication Number Publication Date
WO2016031173A1 true WO2016031173A1 (ja) 2016-03-03

Family

ID=55399090

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/004071 WO2016031173A1 (ja) 2014-08-28 2015-08-17 送信方法、受信方法、送信装置及び受信装置

Country Status (2)

Country Link
JP (4) JP7022936B2 (ja)
WO (1) WO2016031173A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017163888A1 (ja) * 2016-03-22 2017-09-28 ソニー株式会社 受信装置、データ処理方法、及び、送受信システム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010130473A (ja) * 2008-11-28 2010-06-10 Nippon Hoso Kyokai <Nhk> 一方向伝送路に用いる送信端末、受信端末及び伝送システム

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112008000552B4 (de) * 2007-05-14 2020-04-23 Samsung Electronics Co., Ltd. Verfahren und Vorrichtung zum Empfangen von Rundfunk
US10320500B2 (en) * 2007-09-18 2019-06-11 Qualcomm Incorporated Method and apparatus to enable fast channel switching with limited DVB receiver memory
CA2823037C (en) * 2010-12-26 2016-05-24 Lg Electronics Inc. Method for transmitting a broadcast service, and method and apparatus for receiving same
WO2012099423A2 (ko) * 2011-01-19 2012-07-26 삼성전자 주식회사 방송 시스템에서의 제어 메시지 구성 장치 및 방법
JP2013201682A (ja) * 2012-03-26 2013-10-03 Pioneer Electronic Corp 受信装置、チャンネルサーチ方法、プログラム、および記録媒体

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010130473A (ja) * 2008-11-28 2010-06-10 Nippon Hoso Kyokai <Nhk> 一方向伝送路に用いる送信端末、受信端末及び伝送システム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ASSOCIATION OF RADIO INDUSTRIES AND BUSINESSES: "Digital Hoso System Kaihatsu Bukai, Shiryo UHD Saku 4-2-5 Cho Koseisaido Television Hoso System ni Kansuru Chukan Hokoku (Tajuka Hoshiki), Ministry of Internal Affairs and Communications Information and Communications Council", 1 December 2013 (2013-12-01), pages 1 - 34 , 53 to 54, Retrieved from the Internet <URL:http://warp.ndl.go.jp/info:ndljp/pid/8380046/www.soumu.go.jp/main_content/000262096.pdf> [retrieved on 20151027] *
SHUICHI AOKI ET AL.: "A Study on Implementation of MMT in Next Generation Broadcasting Systems", FIT2013 DAI 12 KAI FORUM ON INFORMATION TECHNOLOGY KOEN RONBUNSHU, vol. 3, 20 August 2013 (2013-08-20), pages 355 - 356, XP008185019 *
SHUICHI AOKI: "Media Transport Technologies for Next Generation Broadcasting Systems", NHK SCIENCE AND TECHNICAL RESEARCH LABORATORIES R&D REPORT, no. 140, 15 July 2013 (2013-07-15), pages 22 - 31, XP008180293, ISSN: 0914-7535 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017163888A1 (ja) * 2016-03-22 2017-09-28 ソニー株式会社 受信装置、データ処理方法、及び、送受信システム
US11190625B2 (en) 2016-03-22 2021-11-30 Sony Corporation Reception device, data processing method, and transmission/reception system

Also Published As

Publication number Publication date
JP7022936B2 (ja) 2022-02-21
JP2022048222A (ja) 2022-03-25
JP7249563B2 (ja) 2023-03-31
JP7462250B2 (ja) 2024-04-05
JP2023068005A (ja) 2023-05-16
US20230353620A1 (en) 2023-11-02
JP2021057916A (ja) 2021-04-08
JP2024069460A (ja) 2024-05-21

Similar Documents

Publication Publication Date Title
JP7072097B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP6827223B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP6566338B2 (ja) 送信方法、送信装置及びシステム
JP2022121490A (ja) 送信方法、受信方法、送信装置及び受信装置
JP6505413B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP7257648B2 (ja) 逆多重化装置及び逆多重化方法
WO2015068352A1 (ja) 送信方法、受信方法、送信装置、及び受信装置
WO2015075880A1 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP2024069460A (ja) 送信方法、受信方法、送信装置及び受信装置
WO2016056201A1 (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: 15836696

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2015836696

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015836696

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE