WO2015011915A1 - 送信方法および受信方法ならびに送信装置および受信装置 - Google Patents

送信方法および受信方法ならびに送信装置および受信装置 Download PDF

Info

Publication number
WO2015011915A1
WO2015011915A1 PCT/JP2014/003844 JP2014003844W WO2015011915A1 WO 2015011915 A1 WO2015011915 A1 WO 2015011915A1 JP 2014003844 W JP2014003844 W JP 2014003844W WO 2015011915 A1 WO2015011915 A1 WO 2015011915A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
content
communication
data
broadcast
Prior art date
Application number
PCT/JP2014/003844
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
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to EP19205604.2A priority Critical patent/EP3641318A1/en
Priority to CN201480027612.8A priority patent/CN105230026B/zh
Priority to EP14830237.5A priority patent/EP3026920B1/en
Publication of WO2015011915A1 publication Critical patent/WO2015011915A1/ja
Priority to US14/970,750 priority patent/US10356474B2/en
Priority to US16/423,436 priority patent/US11102547B2/en
Priority to US17/375,351 priority patent/US11711580B2/en
Priority to US18/206,743 priority patent/US20230319355A1/en

Links

Images

Classifications

    • 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • 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/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/13—Arrangements for device control affected by the broadcast information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44012—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving rendering scenes according to scene graphs, e.g. MPEG-4 scene graphs
    • 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/47—End-user applications
    • H04N21/488—Data services, e.g. news ticker
    • H04N21/4888—Data services, e.g. news ticker for displaying teletext characters
    • 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/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
    • 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
    • H04H—BROADCAST COMMUNICATION
    • H04H2201/00—Aspects of broadcast communication
    • H04H2201/40—Aspects of broadcast communication characterised in that additional data relating to the broadcast data are available via a different channel than the broadcast channel

Definitions

  • the present disclosure relates to a data transmission method, a data reception method, a transmission device, and a reception device.
  • a main transmission path for distributing content is a broadcast wave.
  • a media transport method widely used in a broadcast system using a broadcast wave for example, MPEG-2 TS (Moving Picture Experts Group-2) (Transport Stream).
  • Non-Patent Document 1 includes MMT (MPEG Media Transport) and the like as a new media transport system that is assumed to deliver content using both broadcasting and communication (see Non-Patent Document 1).
  • Patent Document 1 discloses a technique for accessing communication content based on data acquired from a broadcast mainly for the broadcast.
  • MPEG media transport MMT
  • a transmission method is a content transmission method capable of transmitting content using a broadcast wave and a communication channel, and when transmitting content using each of the broadcast wave and the communication channel.
  • Information transmission for transmitting auxiliary information at least using the broadcast wave, which is auxiliary information for synchronizing the content of the broadcast wave and the content of the communication channel and is received by the receiving side Includes steps.
  • the present disclosure even if the reception start timing of content by communication is delayed, the content using both broadcast and communication can be reproduced on the receiving side.
  • FIG. 1A is a diagram illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the first embodiment.
  • FIG. 1B is a diagram illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the first embodiment.
  • FIG. 2 is a diagram illustrating an example of an outline of a transmission path identification descriptor according to the first embodiment.
  • FIG. 3A is a diagram showing another example of the data structure of service information in the broadcast communication cooperative service of the first embodiment.
  • FIG. 3B is a diagram illustrating another example of the data structure of the service information in the broadcast communication cooperative service according to the first embodiment.
  • FIG. 4A is a flowchart illustrating an example of an operation on the reception side in the broadcast communication cooperative service according to the first embodiment.
  • FIG. 4B is a flowchart illustrating another example of the operation on the receiving side in the broadcast communication cooperative service according to the first embodiment.
  • FIG. 5 is a block diagram illustrating an example of a configuration of the receiving device according to the first embodiment.
  • FIG. 6A is a diagram illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the first modification of the first embodiment.
  • FIG. 6B is a diagram illustrating an example of a data structure of service information in the broadcast communication cooperative service according to the first modification of the first embodiment.
  • FIG. 7A is a flowchart illustrating an example of an operation on the reception side in the broadcast communication cooperative service according to the first modification of the first embodiment.
  • FIG. 7B is a flowchart illustrating another example of the operation on the reception side in the broadcast communication cooperative service according to the first modification of the first exemplary embodiment.
  • FIG. 8 is a block diagram illustrating an example of a configuration of a reception device in the first modification of the first embodiment.
  • FIG. 9 is a flowchart illustrating an example of an operation on the reception side in the broadcast communication cooperative service according to the second modification of the first embodiment.
  • FIG. 10 is a block diagram illustrating an example of a configuration of a reception device in the second modification of the first embodiment.
  • FIG. 11 is a diagram illustrating an example of a data structure of service information in the broadcast communication cooperative service according to the fourth modification of the first embodiment.
  • FIG. 12 is a flowchart illustrating an example of the operation on the reception side in the broadcast communication cooperative service according to the fourth modification of the first embodiment.
  • FIG. 13A is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13B is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13C is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13A is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13B is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13C is a diagram illustrating an example of the
  • FIG. 13D is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 14 is a flowchart illustrating an example of an operation on the reception side in the broadcast communication cooperative service according to the sixth modification of the first embodiment.
  • FIG. 15 is a flowchart illustrating another example of the operation on the reception side in the broadcast communication cooperative service according to the sixth modification of the first embodiment.
  • FIG. 16 is a flowchart illustrating an example of the operation on the reception side in the broadcast communication cooperative service according to the seventh modification of the first embodiment.
  • FIG. 17 is a block diagram illustrating an exemplary configuration of a receiving apparatus according to the seventh modification of the first embodiment.
  • FIG. 18A is a diagram showing a description example of default reproduction control information in the second exemplary embodiment.
  • FIG. 18B is a diagram showing a video display example according to the layout information of the default playback control information shown in FIG. 18A.
  • FIG. 19A is a diagram illustrating an example of application control information according to Embodiment 2.
  • FIG. 19B is a diagram showing a video display example according to the layout information of the application control information shown in FIG. 19A.
  • FIG. 20A is a diagram showing another description example of default reproduction control information in Embodiment 2.
  • FIG. 20B is a diagram showing a video display example according to the layout information of the default playback control information shown in FIG. 20A.
  • FIG. 21A is a diagram illustrating an example of application control information according to Embodiment 2.
  • FIG. 21A is a diagram illustrating an example of application control information according to Embodiment 2.
  • FIG. 21B is a diagram showing a display example of video according to the layout information of the application control information shown in FIG. 21A.
  • FIG. 22 is a flowchart illustrating an example of the operation on the reception side in the second embodiment.
  • FIG. 23 is a block diagram illustrating an example of a configuration of a receiving device in the second embodiment.
  • FIG. 24 is a diagram illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the third embodiment.
  • FIG. 25 is a diagram illustrating an example of information included in the program configuration information descriptor according to the third embodiment.
  • FIG. 26 is a diagram illustrating an example of information included in the location information descriptor according to the third embodiment.
  • FIG. 27 is a diagram illustrating an example of location types included in the location information descriptor according to the third embodiment.
  • FIG. 28 is a diagram illustrating an example of information included in the asset configuration information descriptor according to the third embodiment.
  • FIG. 29 is a flowchart illustrating a reception method in the broadcast communication cooperative service according to the third embodiment.
  • FIG. 30 is a block diagram illustrating an example of a configuration of a reception device in Embodiment 3.
  • a transmission method is a content transmission method capable of transmitting content using a broadcast wave and a communication path, and each of the broadcast wave and the communication path When transmitting content using the auxiliary information to synchronize the content by the broadcast wave and the content by the communication path, the auxiliary information to be synchronized when received by the receiving side, at least An information transmission step of transmitting using the broadcast wave.
  • a content transmission method capable of reproducing content using both broadcast and communication on the receiving side even when the reception start timing of content by communication is delayed. More specifically, when content is transmitted using a broadcast wave and a communication channel, auxiliary information for synchronizing the content transmitted using the broadcast wave and the communication channel is transmitted. When the side receives the auxiliary information, the receiving side can be synchronized between the contents.
  • the auxiliary information is transmitted prior to transmitting the content, and the auxiliary information further includes location information indicating an acquisition destination of the content or an acquisition destination of the location information. May be included.
  • the auxiliary information may be transmitted by including difference information between the content reference clock by the broadcast wave and the content reference clock by the communication path.
  • the auxiliary information transmitting step when the reference clock of the content is different by transmitting the auxiliary information, the content clock based on the broadcast path is set based on the difference information.
  • the receiver may be synchronized with the reference clock.
  • the content is generated in a format according to MMT (MPEG Media Transport); A content transmission step of transmitting the content in the format generated in the generation step.
  • MMT MPEG Media Transport
  • the auxiliary information may be generated by being included in message information that is information related to the acquisition of the content.
  • a reception method includes a reception step of receiving content transmitted using each of a broadcast wave and a communication path, the content based on the broadcast wave, A reproduction step of performing the synchronization processing and reproducing the content when auxiliary information for synchronization with the content via the communication path is received.
  • the location The content may be received by acquiring the content based on information.
  • the auxiliary information is received prior to receiving the content, and the auxiliary information includes information indicating an acquisition destination of location information indicating an acquisition destination of the content
  • the content may be received by acquiring the location information based on information indicating an acquisition destination of the location information and acquiring the content from the acquired location information.
  • the reception step receives the auxiliary information including difference information between a content reference clock based on the broadcast wave and a content reference clock based on the communication path, and uses the broadcast wave.
  • the content reference clock and the content reference clock by the communication channel are different, the content synchronization by synchronizing the content reference clock by the communication channel with the content reference clock by the broadcast wave based on the difference information
  • the content may be played back by performing a process.
  • a transmission device capable of transmitting content using a broadcast wave and a communication path, each of the broadcast wave and the communication path.
  • the auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path, and at least the auxiliary information to be synchronized when received by the receiving side
  • An information transmission unit for transmitting using the broadcast wave is provided.
  • a receiving device includes a receiving unit that receives content transmitted using each of a broadcast wave and a communication channel, the content based on the broadcast wave, A reproduction unit that performs the synchronization process and reproduces the content when auxiliary information for synchronization with the content through the communication path is received.
  • a recording medium recording medium such as a transmission method, a transmission apparatus, a reception method, a reception apparatus, an integrated circuit, a computer program, or a computer-readable CD-ROM.
  • the data reception method, the integrated circuit, the computer program, or the recording medium may be implemented in any combination.
  • the transmission side transmits content (data or assets) using broadcast waves and communication channels, but transmits service information prior to content transmission.
  • the service information is information for acquiring data related to audio or video or data broadcasting after channel selection operation (after channel selection), or information of EPG (Electric Program Guide), etc. Refers to a series of information related to content reception and metadata acquisition.
  • the current broadcasting is mainly transmitted using the MPEG-2 TS (Transport Stream) section, PAT (Program Association Table), PMT (Program Map Table), NIT (Network Information Table), CAT (Condition). (Access Table) or EIT (Event Information Table) defined by ARIB (Radio Industry Association).
  • an MMT MPEG Media Transport
  • MPEG Media Transport
  • TS Transport
  • MPEG-DASH Dynamic Adaptive Streaming over HTTP
  • the service information in this embodiment is transmitted in a data structure that can be stored in a multiplexed format.
  • service information is transmitted by a table such as MPT (MMT Package Table) or message information such as PA (Package Access) message.
  • MPT MMT Package Table
  • PA Package Access
  • auxiliary information can be described using a descriptor, similarly to TS.
  • FIG. 1A and 1B are diagrams illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the first embodiment. More specifically, FIG. 1A shows an MPT including a transmission path identification descriptor, and FIG. 1B relates to a transmission path of assets constituting a package in the transmission path identification descriptor shown in FIG. 1A, for example. An example in which information is described as attribute information is shown.
  • Assets constituting a package may include, as attribute information, information indicating whether (1) using only broadcasting or (2) using both broadcasting and communication in combination. .
  • the audio and video data of the main part may be information indicating whether (1) using only broadcasting or (2) using both broadcasting and communication. With this information, even when the main part is transmitted using only broadcasting, metadata other than the main part such as audio, video, still image, or HTML file can be acquired from the communication network.
  • the transmission side can switch to transmitting data by communication when the reception state of the broadcast deteriorates due to rain attenuation or the like using the attribute information.
  • the attribute information may indicate information for identifying assets related to each other.
  • the attribute information may indicate the asset ID of the base layer and the asset ID of the enhancement layer corresponding to the base layer.
  • the attribute information may indicate whether the same asset is transmitted using both broadcasting and communication.
  • identification information (asset ID or the like) of the asset may be indicated separately.
  • Information for identifying the related asset may be indicated by an individual transmission path identification descriptor for each asset as shown in FIG.
  • FIG. 2 is a diagram illustrating an example of an outline of the transmission path identification descriptor according to the first embodiment.
  • the individual transmission path identification descriptor shown in FIG. 2 may indicate, for example, information for identifying whether the asset is a base layer asset or an enhancement layer asset, or the asset is an extension layer. In some cases, the ID of the corresponding base layer asset may be indicated.
  • the attribute information may be a group of broadcast assets and communication assets, and may indicate a list of assets included in the group. If there are assets that are transmitted using both broadcast and communication, they may be grouped separately.
  • Information indicating whether or not audio and video transmitted by broadcasting and audio and video transmitted by communication are reproduced in synchronization may be included as attribute information.
  • the attribute information may indicate individual information as individual fields, or may define information indicating the type of service so that it can be identified by type.
  • the attribute information may be described in a format different from that of the descriptor.
  • the transmission path identification descriptor may be stored in a table or message indicating package unit information different from MPT. Further, the content of the transmission path identification descriptor may be described as a data structure different from that of the descriptor.
  • a table or a message indicating a list of packages may be defined, and information such as a transmission path identification descriptor may be indicated as package attribute information as package unit information.
  • 3A and 3B are diagrams showing another example of the data structure of the service information in the broadcast communication cooperative service of the first embodiment.
  • the assets transmitted by broadcasting and communication may be stored in different MPTs.
  • the attribute information of the package can be stored in the MPT sent on the transmission path that is the entry point of the service. For example, when broadcast becomes an entry point, it is stored in MPT sent by broadcast. Also, these MPTs can be identified by table_id.
  • the value of the table_id of the reference MPT is defined as zero. Therefore, the table_id of the MPT corresponding to the transmission path as the entry point is set to zero, and the table_id of the MPT corresponding to the other transmission path is 1 or more. And so on.
  • the MPT of the broadcast asset may be transmitted by broadcasting, and the MPT of the communication asset may be transmitted by communication.
  • the location information of broadcasting and communication assets may be stored in one MPT.
  • location information of each asset may be stored easily so that it can be easily identified. For example, when there are N1 broadcast assets and N2 communication assets, first describe N1 broadcast asset information continuously, and then N2 communication asset information continuously. Describe.
  • the transmission path identification descriptor may indicate that N1 assets are transmitted in broadcasting and N2 assets are transmitted in communication.
  • the transmission information including the transmission path identification descriptor that is auxiliary information is transmitted. Accordingly, on the receiving side, only by acquiring service information including auxiliary information, whether or not communication data is included in the attribute information of the package described in the transmission path identification descriptor, or broadcast data and communication data Dependencies etc. can be acquired in advance without analyzing information for each asset.
  • the transmission device is a content transmission device capable of transmitting content using broadcast waves and communication channels, generates package attribute information such as a transmission channel identification descriptor as auxiliary information, and provides service information. To be included and sent.
  • the transmission apparatus may transmit this service information periodically.
  • the contents of the service information are updated, the updated contents are reflected in the service information immediately after the update.
  • the entry point is not limited to broadcasting, and may be communication, or entry may be made from both broadcasting and communication.
  • the information for each package is transmitted from at least both broadcasting and communication transmitting devices.
  • the transmitting side may transmit information necessary for receiving the communication data in communication.
  • the transmission side may transmit information on a package unit on a transmission path that is an entry point, and information unique to the transmission path such as broadcasting and communication may be transmitted on each transmission path (for example, FIG. 2). In the following description, it is assumed that broadcasting is an entry point.
  • service information unique to each transmission path can be generated and transmitted by a transmission device in each transmission path.
  • information transmitted by the MPT such as asset location information, may be transmitted by broadcasting since it can be acquired in a lump to reduce the delay time related to the start of asset acquisition on the communication side.
  • FEC Forward Error Correction
  • a packet transmitted by communication such as FEC method and parameters 2
  • packet loss rate For example, packet loss rate, jitter at packet arrival time, RTT (Round Trip Time), communication Information related to QoS (Quality of Service) control, such as end-to-end delay in the transmission path 3)
  • QoS Quality of Service
  • end-to-end delay in the transmission path For example, buffering from when asset data is received until decoding starts, such as buffering time and buffering amount Information
  • FEC and QoS are important in broadcasting, particularly in broadcasting for mobiles (such as one-segment broadcasting in Japan), but the parameters in these are different from the communication channel. Therefore, information unique to broadcasting need only be transmitted in broadcasting.
  • information indicating whether or not there are a plurality of selectable assets may be indicated, or when a plurality of selectable assets exist, a list of selectable assets may be indicated. .
  • the receiving side starts receiving (acquiring) content after acquiring service information.
  • the reception method in the present embodiment will be described with reference to the drawings.
  • FIG. 4A is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperative service of the first embodiment.
  • FIG. 4A shows an example of an operation in which the receiving apparatus acquires the transmission path identification descriptor of the present embodiment and determines an asset to be received.
  • an MPT table included in a PA message or an MPT message is acquired as service information transmitted on a transmission path serving as an entry point, and a transmission path identification descriptor included therein is acquired.
  • the information on the transmission path identification descriptor such as whether the asset is transmitted using both broadcasting and communication, and when both transmission paths are used, interprets the information of the transmission path identification descriptor, such as the dependency between the broadcasting and communication assets ( Step S101).
  • a message such as a PA message is stored in the payload of a packet such as an MMT packet, and the type of data stored is indicated by the packet header. Therefore, when receiving the MMT package, first, the MMT packet of the PA message is acquired with reference to the ID number (corresponding to packet_id in the MMT packet) in the packet header.
  • the asset to be received is determined based on the playback capability of the terminal or whether or not the communication path is available (step S102).
  • Receivable assets are determined from a plurality of assets having different bit rates transmitted by communication according to the bandwidth of the communication network to which the receiving device is connected.
  • information such as the bit rate of each asset is separately transmitted in service information or the like. If the reception state is poor due to congestion of the communication network and there is no asset that can be stably received, it may be determined not to receive data on the communication side.
  • the asset to be acquired may be determined when the reception environment deteriorates.
  • the reception device may monitor the reception environment, determine whether to receive communication assets based on an index such as an error rate in the reception data, and perform reception processing.
  • step S103 it is determined (determined) whether or not to receive an asset transmitted by communication. If it is determined (determined) to receive (Yes in S103), the process proceeds to S104, and it is determined (determined) that it is not received. If yes (No in S103), the process proceeds to S105.
  • the asset is received from both the broadcast and communication transmission paths, and in S105, the asset is received only from the broadcast.
  • FIG. 4B is a flowchart illustrating another example of the operation on the reception side in the broadcast communication cooperative service according to the first embodiment.
  • step S106 when service information unique to communication is transmitted in communication, a step of receiving the service information (step S106) is added. Others are the same as those described with reference to FIG.
  • the receiving device does not support the broadcasting / communication cooperation service, it is sufficient to receive only broadcasting assets. In this case, when there is an asset that is transmitted using both broadcasting and communication, the asset is not received.
  • FIG. 5 is a block diagram illustrating an example of a configuration of the receiving device according to the first embodiment.
  • FIG. 5 shows an example of the configuration of a receiving apparatus that implements the receiving method described in FIG. 4A.
  • 5 includes an identification information acquisition unit 101, an asset determination unit 102, a determination unit 103, a broadcast reception unit 104, and a communication reception unit 105.
  • the identification information acquisition unit 101 has a function of realizing step S101 shown in FIG. 4A. Specifically, the identification information acquisition unit 101 acquires service information transmitted on a transmission path serving as an entry point, and acquires a transmission path identification descriptor (auxiliary information) included therein. And the identification information acquisition part 11 interprets the information of a transmission path identification descriptor.
  • the asset determination unit 102 has a function of realizing step S102 shown in FIG. 4A, and determines the asset to be received based on the playback capability of the terminal or whether the communication path is available.
  • the determination unit 103 has a function of realizing step S103 illustrated in FIG. 4A, and determines (determines) whether to receive an asset transmitted through communication. Specifically, the determination unit 103 determines whether or not to receive communication data. When it is determined that the communication data is received, the broadcast reception unit 104 and the communication reception unit 105 receive the asset data determined in step 102. .
  • the determination unit 103 determines not to receive communication data, the determination unit 103 receives data using only the broadcast receiving unit 14.
  • Modification 1 An example in which broadcasting is transmitted using TS and communication is transmitted using DASH or RTP (Real-time Transport Protocol) will be described.
  • FIG. 6A and 6B are diagrams illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the first modification of the first embodiment.
  • FIG. 6A shows an example in which information related to data transmitted in communication is stored in the PMT.
  • FIG. 6B shows an example of the data structure of the transmission path identification descriptor of this modification.
  • a transmission path identification descriptor indicating the attribute information described with reference to FIGS. 1A and 1B is stored in the PMT which is an example of service information.
  • location information of communication-side data is stored in the transmission path identification descriptor. More specifically, flag information indicating whether or not communication is used together is included in the attribute information. Thereby, the transmission side can select whether to include location information of data on the communication side according to the value of the flag information.
  • the location information is not limited to being stored in the transmission path identification descriptor. A descriptor may be separately defined to store location information.
  • the location information is information indicating a data acquisition destination, and corresponds to PID for TS and URL or URI for communication.
  • DASH MPD Media Presentation Description
  • RTP SDP Session Description Protocol
  • the location information is not limited to storing location data entity data such as MPD or SDP, but may also store information indicating the location data location data acquisition source.
  • the information indicating the acquisition destination of the location data entity data is, for example, information indicating the URL for acquiring the MPD.
  • the information indicating the acquisition destination of the location data entity data is stored in the location information, a delay for separately acquiring the location data entity data occurs. Therefore, it is desirable to store the entity data directly in the location information from the viewpoint of reducing the delay until the communication side data reception starts.
  • the DASH MPD is large in size because it contains various information regarding the content acquisition destination. Therefore, instead of storing the MPD as it is in the location information, it is also possible to store the subset information including only the URL of the content acquisition destination and the information regarding the DTS and PTS of the segment.
  • a version number may be assigned to the location information. Thereby, when the version number is updated, the location information can be acquired again.
  • information such as a transmission path identification descriptor in the PMT that is periodically transmitted may be sequentially checked.
  • section data for storing location information and the like may be separately generated (referred to as a transmission path identification section) and periodically transmitted.
  • attribute information and location information may be transmitted in both the program information such as the PMT and the transmission path identification section. Alternatively, only the location information may be stored in the transmission path identification section.
  • the updated content of the location information may be acquired in communication.
  • the location information acquisition destination since the location information acquisition destination is required, the location information acquisition destination may be stored together with the entity data of the location information in a broadcast transmission path identification descriptor or the like.
  • the receiving device can acquire the updated content in communication by periodically accessing the location information acquisition destination.
  • the server may issue a message indicating that the location information has been updated to the receiving device.
  • the receiving apparatus may re-acquire location information when a message is received.
  • the attribute information and the location information may be transmitted by a section different from the PMT.
  • the data acquisition method on the communication side may be switched based on whether or not the data transmitted in communication is reproduced in synchronization with audio or video in broadcasting.
  • the data on the communication side can be accessed from the broadcast program information as described above. If synchronized playback is not performed, information for accessing data on the communication side may be transmitted by data broadcasting using AIT (Application Information Table) defined in the hybrid cast specification of ARIB (Radio Industry Association). Good.
  • AIT Application Information Table
  • the receiving apparatus receives the AIT in a format such as a table or a carousel, and acquires data on the communication side based on the contents of the AIT.
  • the acquired communication data is started to be reproduced when an event message transmitted by data broadcasting is received.
  • information such as AIT may also be used when broadcast data and communication data are synchronously reproduced. At this time, it is assumed that the time of starting and ending reproduction of data on the communication side is separately shown in the data broadcast. The receiving device reproduces the data on the communication side according to these times.
  • MPD in DASH and SDP in RTP can indicate the content playback start time or decryption start time, and these times are specified for each multiplexing and transmission system such as UTC (Coordinated Universal Time). It is specified based on the reference clock. Also, PTS (Presentation Time Stamp) and DTS (Decoding Time Stamp) of individual video frames and audio samples are set based on the reference clock.
  • PCR Program Clock Reference
  • PCR Program Clock Reference
  • information indicating the correspondence relationship between the data on the broadcast side and the reference clock of the data on the communication side may be included in program information such as PMT in the broadcast.
  • program information such as PMT in the broadcast.
  • it may be information such that the time at which the PCR value in broadcasting is N1 and the time at which the UTC value in communication is N2 correspond to the same time.
  • Such information may be included in MPD, SDP, and the like.
  • the transmission path identification descriptor may indicate transport layer protocol information such as whether the data on the communication side is transmitted by UDP (User Datagram Protocol) or TCP (Transmission Control Protocol). .
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • the receiving device can open a port used in each protocol, or determine whether the port is compatible with the protocol used.
  • the identification information of the multiplexing format in the data on the communication side may be shown so as to be able to identify whether it is DASH or RTP, for example.
  • FIG. 7A is a flowchart illustrating an example of the operation on the reception side in the broadcast communication cooperative service according to the first modification of the first embodiment.
  • FIG. 7A shows an example of the operation of the receiving apparatus when attribute information and location information are stored in broadcast program information.
  • each step is the same as that in the flowchart of FIG. 4A.
  • the data on the broadcast side and the communication side are unified with the assets of the MMT package.
  • the broadcasting side is TS and the communication side is DASH or RTP data. Since the other points are the same as those described with reference to FIG. 4A, detailed description thereof is omitted.
  • FIG. 7B is a flowchart illustrating another example of the operation on the reception side in the broadcast communication cooperative service according to the first modification of the first embodiment.
  • FIG. 7B shows an example of an operation in the case where attribute information and access information for acquiring location information are stored in the broadcast program information, and the actual location information is not stored.
  • step S301 is the same as step S201, description thereof is omitted.
  • step S302 it is determined (determined) whether or not data on the communication side is received.
  • step S303 when data on the communication side is received, the process proceeds to S304, and when data on the communication side is not received. Advances to S306.
  • step S304 the location information is acquired according to the location information acquisition location of the communication data included in the broadcast program information.
  • step S305 communication side data is acquired based on the location information acquired in S304, and broadcast data is acquired.
  • step S306 only data transmitted by broadcasting is acquired.
  • attribute information is the same as that described in the first embodiment, since the MMT is used as an example in the first embodiment, an example in which broadcasting uses TS and communication uses DASH or RTP will be described below.
  • the audio and video data may be information indicating which one of (1) using only broadcasting and (2) using both broadcasting and communication is used in combination. With this information, even when the main part is transmitted using only broadcasting, metadata such as audio, video, still image, or HTML file can be obtained from a communication network different from the main part.
  • attribute information When audio or video is transmitted using both broadcasting and communication, information indicating the relationship of data transmitted by each may be included as attribute information.
  • broadcasting uses the basic layer for communication.
  • the attribute information may indicate that, as a use case, the frame rate is 60 fps with only broadcast data, but the frame rate can be improved to 120 fps when communication data is used together.
  • the attribute information may indicate that broadcast backup data is transmitted by communication. Thereby, the transmission side can switch to transmitting data by communication when the reception state of the broadcast deteriorates due to rain attenuation or the like using the attribute information.
  • the attribute information may indicate information for identifying encoded streams related to each other.
  • the attribute information indicates identification information of video data such as a PID of a TS packet storing base layer data transmitted by broadcasting, a segment in DASH data transmitted by communication, or a track ID in MP4. be able to.
  • the attribute information may indicate broadcast side data and information indicating communication side data that are synchronously reproduced.
  • the transmission side can transmit a multi-viewpoint video, or a video of a main screen and a sub-screen in picture-in-picture, by broadcasting and communication, respectively.
  • Information indicating whether or not audio and video transmitted by broadcasting and audio and video transmitted by communication are reproduced in synchronization may be included as attribute information.
  • Information indicating whether the data on the communication side is live content may be included as attribute information.
  • the time (T2) obtained by adding the time (or estimated value) from the content acquisition request to the start of reception and the total time ( ⁇ T) for buffering data to the current time is the reproduction time.
  • Broadcast data can be reproduced without delay by starting reception from the data. At this time, the data on the communication side is reproduced from time T2.
  • the broadcast side data may be buffered by ⁇ T, and reproduction of both broadcast and communication data may be started at time T2.
  • FIG. 8 is a block diagram showing an example of the configuration of the receiving apparatus in the first modification of the first embodiment.
  • FIG. 8 shows an example of the configuration of a receiving apparatus that implements the receiving method described in FIG. 7B.
  • 7A corresponds to the case where the Loc information acquisition unit 304 is not provided in FIG.
  • the identification information acquisition unit 301 has a function of realizing step S301 shown in FIG. 7B. Specifically, the identification information acquisition unit 301 acquires service information transmitted on a transmission path serving as an entry point, and acquires a transmission path identification descriptor (auxiliary information) included therein. And the identification information acquisition part 301 interprets the information of a transmission path identification descriptor.
  • the determination unit 302 has a function of realizing step S302 illustrated in FIG. 7B, and determines data to be received based on the playback capability of the terminal or whether or not the communication path is available.
  • the communication combination determination unit 303 has a function of realizing step S303 illustrated in FIG. 7B, and determines (determines) whether to receive data transmitted through communication.
  • the Loc information acquisition unit 304 has a function of realizing step S304 illustrated in FIG. 7B and acquires the location data of the communication side data.
  • Modification 2 In this modification, an example of a reception method when attribute information and location information are stored and transmitted in broadcast program information will be described.
  • FIG. 9 is a flowchart illustrating an example of an operation on the reception side in the broadcast communication cooperative service according to the second modification of the first embodiment.
  • FIG. 9 shows an operation example until the receiving apparatus determines whether to reproduce the broadcast content and the communication content synchronously when the attribute information and the location information are stored and transmitted in the broadcast program information and reproduces them. It is shown.
  • the operation in FIG. 9 is based on the operation in FIG. 7A, but is described as an example in which the transmission data is not a MMT asset but a more general content.
  • program information transmitted on a transmission path serving as an entry point is acquired, a transmission path identification descriptor included therein is acquired, and content attribute information and communication content location information are acquired (step S401).
  • the location information entity data is acquired by the same method as described in FIG. 7B.
  • step S402 data to be received is determined based on the reproduction capability of the receiving device or whether or not the communication path is available.
  • step S403 it is determined whether or not to acquire communication contents. If it is determined to acquire communication contents (Yes in S403), the process proceeds to step S404, and data is received from both the broadcast and communication transmission paths. To do. If it is determined (determined) not to be received (No in S403), the process proceeds to step S409, where data is received only from the broadcast, and only the broadcast content is reproduced in step S410.
  • step S405 it is determined whether or not the broadcast content and the communication content are to be reproduced in synchronization.
  • step S405 If it is determined that synchronized playback is to be performed (Yes in S405), the reference clocks of the broadcast content and communication content are synchronized in step S406, and both are synchronized and reproduced in step S407.
  • the synchronization of the reference clock in S406 may be performed prior to S404. This is because, for example, when playback is started after pre-buffering the received data of content, data in which PTS is T1 in broadcast content and data in which PTS is T1 in communication content (where each PTS is already When it is determined whether or not the data to be synchronized and reproduced is complete, both reference clocks are This is because it is necessary to be synchronized.
  • the reference clock in S406 it can be aligned with the reference clock used in either broadcasting or communication.
  • PCR Program Clock Reference
  • NTP Network Time Protocol
  • DTS and PTS based on NTP standards in video and audio are converted to PCR standards.
  • the reference clock for broadcasting and communication can be synchronized.
  • DTS and PTS for broadcasting and communication may be converted so as to synchronize with a specific clock used in the receiving apparatus.
  • the receiver can acquire that the reference clock information differs depending on the attribute information, use the above method.
  • the reference clock in broadcasting and communication may be synchronized.
  • the attribute information and the location information are described as being synchronously reproduced when stored in the broadcast program information, but the present invention is not limited to this.
  • the reception apparatus may perform synchronous reproduction of the stream in which the location information is described in the transmission path identification descriptor and the broadcast stream.
  • the transmission path identification descriptor does not have to include attribute information indicating whether or not streams transmitted through broadcasting and communication are reproduced in synchronization with each other.
  • the reception method in this modification is for synchronizing the reception step of receiving the content transmitted using each of the broadcast wave and the communication channel, and the content of the broadcast wave and the content of the communication channel.
  • the auxiliary information may include a reproduction step of performing the synchronization process and reproducing the content.
  • FIG. 10 is a block diagram illustrating an example of a configuration of a reception device in the second modification of the first embodiment.
  • FIG. 10 shows an example of the configuration of a receiving apparatus that implements the receiving method described in FIG.
  • 10 includes an identification information acquisition unit 401, a determination unit 402, a communication combination determination unit 403, a Loc information acquisition unit 404, a broadcast reception unit 405, a communication reception unit 406, and a synchronization determination unit. 407 and a playback unit 408.
  • the identification information acquisition unit 401 to the communication reception unit 406 are the same as the identification information acquisition unit 301 to the communication reception unit 306 described with reference to FIG.
  • the synchronization determination unit 407 has a function of performing the process of step S405 shown in FIG.
  • the playback unit 408 decodes the broadcast content or communication content based on the playback method determined by the determination result of the communication combination determination unit 403 and the synchronization determination unit 407, and plays back.
  • the transmission path is not limited to a combination of broadcast and communication, and may be a combination of transmission paths of the same type such as broadcast and broadcast, communication and communication.
  • each asset can be broadcast or communicated by interpreting the location information for each asset as shown in FIGS. 1A and 1B. It may be determined whether or not there is an asset transmitted by communication in the package.
  • the location information may include URL information of an asset acquisition destination.
  • the acquisition destination is a URL
  • whether the asset is transmitted by broadcasting or communication can be determined based on whether the URL is a specific URL defined in advance in the broadcasting service.
  • the ID of the packet storing the asset data (packet_id in the case of an MMT packet) is stored as the broadcast asset acquisition destination in the location information.
  • the URL is shown as the acquisition destination. Therefore, in the location information, whether the asset is transmitted by communication may be determined depending on whether the acquisition destination is a URL.
  • FIG. 1A and FIG. 1B described above the case where location information for each asset and individual transmission path identification descriptors are defined as information for each asset is described, but the present invention is not limited thereto. You may provide the field which shows the encoding system of an asset separately.
  • the encoding method is essential information at the time of decoding, and it is desirable to perform signaling in information that can be acquired prior to decoding, such as MPT. For example, information such as stream_type in the MPEG-2 system can be used.
  • an encoding method capable of scalable encoding it may indicate whether the asset is a basic layer or an enhancement layer together with the encoding method.
  • a plurality of scalable assets are included, such as when there are two temporally scalable videos in the same MMT package.
  • information indicating which base layer asset the asset of the enhancement layer corresponds to may be indicated.
  • the asset ID of the corresponding base layer asset may be indicated.
  • the assets of the extension layer and the base layer may be grouped and a group ID may be assigned to each asset.
  • Pieces of information can be shown in program information in broadcasting even when TS uses TS for broadcasting and DASH or RTP for communication.
  • a PMT descriptor or the like a dependency between a video stream transmitted by broadcasting and a video stream transmitted by communication (such as a communication-side video stream corresponds to an extension layer), or a communication-side video And information indicating the audio encoding method can be described. Also, it may indicate whether or not the broadcast-side stream and the communication-side stream are synchronized and reproduced.
  • Information indicating whether the content data is transmitted only by broadcasting, or transmitted by using both broadcasting and communication may be stored in program information such as EPG.
  • data transmitted by communication is played back, such as not connected to a communication network, or the receiving device does not support acquisition of data by communication, Alternatively, when recording cannot be performed, message information indicating that may be displayed.
  • information indicating whether or not data transmitted by communication can be acquired prior to the start time of the program may be stored.
  • a download-type system such as DASH
  • the receiving device may start receiving the data on the communication side before the program start time.
  • the reception start time is determined so that a predetermined amount of buffering data or data corresponding to the buffering time can be received at the program start time.
  • the same operation may be performed in the reserved recording of a program.
  • the user can select a plurality of programs at arbitrary timing. Even if the communication data of the next program of the channel being viewed is received in advance, the communication data is previously stored when the viewing program is switched. Even if it receives, the merit is not obtained. Therefore, the data on the communication side should be buffered in advance for all programs that can be viewed after the viewing time at any viewing time and the data is transmitted using both broadcasting and communication. It may work. If the data of all programs cannot be received, the program may be selected and received within the receivable range.
  • information indicating whether the broadcast side data and the communication side data are reproduced synchronously is also included in the program information such as EPG, and when the synchronous side reproduction is performed, the communication side data is buffered in advance. May operate as follows. If the synchronized playback is not performed, the communication side data may be started to be received after the reception of the broadcast side data is started.
  • Such information may be stored in control information when demodulating a signal transmitted through a transmission line such as a TMCC signal in a Japanese broadcasting system (ISDB-T).
  • a transmission line such as a TMCC signal in a Japanese broadcasting system (ISDB-T).
  • HTTP-based file format is not limited to DASH, and may be HTTP Live Streaming (HLS), Microsoft Smooth Streaming (MSS), or the like, and in these methods, content management information corresponding to MPD is also possible. Therefore, the relationship between the data on the broadcast side and the data on the communication side can be shown by a mechanism similar to that of DASH.
  • HLS HTTP Live Streaming
  • MSS Microsoft Smooth Streaming
  • a TS stream may be used, or a format in which a field indicating a 4-byte time stamp is added to the head of the TS packet may be used.
  • the TS with time stamp is used in many standards such as BD (Blu-ray (registered trademark) Disc) and IPTV forum.
  • attribute information of the entire content such as whether the broadcast content and the communication content are synchronously reproduced, or whether the broadcast content is a basic scalability layer and the communication content is an extended layer. May be stored in a transmission path identification descriptor or the like.
  • individual attributes for each stream such as information for identifying video and audio that are the targets of synchronous playback, may be stored in the MPD.
  • attributes for each stream in the case of associating video in broadcasting with audio of sub-audio transmitted in communication, in MPD, in the DASH data such as PID of TS packet storing video and audio track ID Information for identifying an audio track or segment, or Adaptation Set or Representation may be associated with each other.
  • the identification information of the media on the broadcast side may include the ID of the transport stream including the TS packet of the PID, the service ID, etc. in addition to the PID.
  • the contents of MPD may be updated, and the update information is managed by the DASH content distribution server. Therefore, in particular, by describing the individual attributes of the stream in the MPD, it is possible to reduce the exchange of information between the broadcast content transmission apparatus and the communication content transmission server, and the overall attribute is set at the start of broadcast reception such as PMT. By storing it in the information to be acquired, it is possible to achieve both the merit of quickly starting the communication content reception start processing.
  • both the global attribute and the individual attribute may be described in either a descriptor such as PMT in broadcasting or MPD, or may be described in both.
  • PMT in broadcasting
  • MPD it may be described in a descriptor of application control information such as AIT.
  • attribute information a method of synchronizing information indicating whether or not clock information of streams transmitted on different transmission paths such as broadcasting and communication are synchronized with each other, or a method for synchronizing may be included in the attribute information.
  • the receiving device may perform clock synchronization based on this information.
  • attribute information information for identifying the following three methods.
  • Method 3 Synchronize with reference to an independent stream including information for clock synchronization, such as the TS timeline extension (13818-1: 2013 / AMD6 (2nd WD)) currently standardized in MPEG .
  • the attribute information may include the PID of the TS packet storing the clock synchronization stream.
  • Modification 4 For example, in FIGS. 6A to 7B and the like, the storage method of the location information and the like in the case where the broadcast is transmitted using TS and the communication is transmitted using DASH or RTP has been described.
  • FIG. 11 is a diagram illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the fourth modification of the first embodiment.
  • FIG. 11 shows an example of a descriptor (location information descriptor) indicating location information such as MPD. Note that the location information may be included in the transmission path identification descriptor described above. For this reason, the location information descriptor may be considered to correspond to the transmission path identification descriptor.
  • the descriptor is stored in the PMT or section data different from the PMT.
  • the information indicated by the descriptor includes a transmission format indicating the type of entity data referred to by the location information, location information, and a field indicating synchronization information between the PCR and the data on the communication side in broadcasting.
  • the location information indicates the reference destination of the entity data of the location information.
  • the entity data of the location information is MPD
  • MPD is shown as the transmission format
  • synchronization information of PCR and NTP is shown as the synchronization information.
  • MPD is location information used in DASH
  • DASH may be indicated as a transmission format
  • a reference destination of MPD may be indicated as a location.
  • the transmission format field may not be included.
  • MPD transmission within a broadcast and transmission via a communication network.
  • an MPEG-2 TS private section or the like is used.
  • the location information of the MPD indicates identification information of the TS packet storing the MPD in the transport stream, such as the private section PID when transmitting within the broadcast, and the URL when transmitting via the communication network. Information can be shown.
  • FIG. 12 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperative service of the fourth modification of the first embodiment.
  • step S801 the location information descriptor stored in the PMT or the like is analyzed.
  • step S802 it is determined whether MPD exists in the broadcast. If it exists in the broadcast (MPD is transmitted by broadcast) (Yes in S802), the process proceeds to step S803, and MPD entity data is acquired from the TS packet having the PID indicated by the location information. On the other hand, if the MPD does not exist in the broadcast (NO in S802), the MPD is acquired from the communication server based on the URL indicated in the location information.
  • step S805 data to be acquired from the DASH content is determined based on the MPD analysis result, and the data is acquired by download (or progressive download, etc.).
  • step S806 based on the synchronization information included in the location information descriptor or the synchronization information acquired from the TS packet storing the timeline extension information when MPEG-2 TS timeline extension is used. Broadcast content and communication content are played back synchronously.
  • the location information descriptor need not include synchronization information. Further, when there is no need to synchronize and reproduce the DASH content and the broadcast content, the synchronization information may not be transmitted. In this case, based on whether the synchronization information of the location information descriptor or the synchronization information in the data for timeline extension exists, it may be determined whether or not the two need to be synchronized. Whether synchronized playback is necessary may be indicated separately.
  • step S806 the start and end of playback of DASH content can be determined based on a user instruction or a control command in a hybrid cast application. In this case, it is assumed that whether to acquire data by communication is determined in the previous stage of S801.
  • FIG. 12 illustrates an example in which MPD is acquired and DASH content is reproduced, but the same applies to the case where data of another method such as RTP or TS is acquired and reproduced.
  • an access unit for storing timeline extension information can be defined, and both a descriptor indicating location information and a descriptor indicating synchronization information can be stored in the access unit.
  • both the location information and the synchronization information may be indicated by timeline expansion without transmitting the location information descriptor.
  • the field indicating the scheme type of the location information may be extended so that the PID can be signaled.
  • the upper limit of the section size of the PMT is limited to 1021 bytes, and may exceed the upper limit depending on the URL in the location information. Although it is possible to store the PMT section separately, it is desirable that the PMT is stored in one section.
  • the location information descriptor may be transmitted by a section different from the PMT.
  • the location information indicates PID, it can be within the upper limit of the size of the PMT and can be included in the PMT. Therefore, the location information is based on whether the location information is PID or URL. May be switched.
  • Modification 5 In the modified example 4, it has been described that the location information can also be indicated in a timeline and extended media information stream (TEMI) access unit.
  • TEMI extended media information stream
  • the URL of the content on the communication side can be described using temi_location_descriptor.
  • Temi_location_descriptor URLs of a plurality of contents can be described, and since there is no data size restriction such as the section size of the PMT, flexible operation can be performed regarding the description of the URL.
  • the data size of the location information is small, and the location information is obtained by analyzing the PMT with reference to the location information descriptor. Such a delay time can be reduced. Therefore, it is desirable that a location information descriptor and a temi_location_descriptor in the TEMI access unit can be used together as a location information storage location.
  • FIG. 13A is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13A shows a syntax example of a location information descriptor for storing location information in either a location information descriptor or a TEMI access unit.
  • Data_format is the same as the transmission format shown in FIG.
  • reproduction control meta information used in services such as MPD in DASH, reproduction control metafile in VOD (Video On Demand) specification of IPTV Forum, or TTS (Time-stamp TS) defined in IPTV Forum, etc.
  • TTS Time-stamp TS
  • identification information of the stream itself may be indicated.
  • MPT, PA message, MMT packet, asset, etc. in MMT may be indicated.
  • H. Temporal scalability can be realized in a moving image coding scheme such as H.265.
  • a base layer of 60 fps is transmitted by broadcasting and encoded data of an enhancement layer for improving the frame rate from 60 fps to 120 fps is transmitted by communication.
  • the URL of the encoded stream of the enhancement layer may be shown as the location information of the communication content.
  • Information such as resolution and encoding method in the encoded stream can be acquired in the broadcast data that transmits the base layer.
  • “Location_type” is for identifying whether the location information is indicated by the PID of the TS in broadcasting or the URL in communication.
  • location_type 0, the PID of the TS in broadcasting is indicated.
  • the location information descriptor can be used in other than TS such as MPEG MMT (MPEG Media Transport).
  • MPEG MMT MPEG Media Transport
  • location_type may not be used.
  • packet_id of the MMT packet in the MMT may be used.
  • PID indicates the PID of the TS packet.
  • the transport stream identification number and the like may be stored together.
  • “Url_length” indicates the byte length of “url_path”. “Url_path” indicates URL data.
  • FIG. 13B is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13B shows an example different from the syntax of the location information descriptor shown in FIG. 13A.
  • the difference from the syntax shown in FIG. 13A is that the data_format field does not exist when location information is stored in the TEMI access unit.
  • Temi_location_descriptor can indicate the service type of TEMI in a field called service_type.
  • This service type corresponds to data_format. Therefore, the data_format information is indicated in the service_type field.
  • temi_location_descriptor it is also possible to indicate only the URL of the communication content without signaling service_type. Therefore, when the syntax of FIG. 13A is used, the data_format of the location information descriptor is referred to as the transmission format, and the service_type of the temi_location_descriptor may not be signaled.
  • FIG. 13C is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13C shows an example different from the syntax of the location information descriptor shown in FIGS. 13A and 13B.
  • FIG. 13D is a diagram illustrating an example of the syntax of the location information descriptor in the fourth modification of the first embodiment.
  • FIG. 13D shows an example different from the syntax of the location information descriptor shown in FIGS. 13A to 13C.
  • url_location and location_type are integrated.
  • the syntax data and data structure of the location information descriptor are not limited to the above example.
  • the location type and the format type may be shown in combination, and may be used in combination with other data.
  • the transmission format field may not be included.
  • the location information may be indicated by temi_location_descriptor, and the url_location field may be omitted.
  • Modification 6 (Modification 6)
  • Modification 5 an example different from the location information described in Modification 5 will be described.
  • a plurality of TEMI streams may be included for each type of timeline.
  • a plurality of pieces of location information may be stored in the location information descriptor.
  • loops corresponding to the number of TEMI streams are created in the location information descriptor, and location information corresponding to each TEMI stream is stored.
  • the order of the loops of the location information and the order of the ES loops (PMT second loop) indicating the TEMI streams match. It is good also as what is to correspond.
  • the location information may not be stored in the location information descriptor, but may be stored in the temmi_location_descriptor of the TEMI access unit, or the location information descriptor may be stored in the ES loop (PMT second loop). ) May be stored.
  • the PID and URL stored in the location information may be reacquired. If the location information such as PID and URL is not updated and only the data is updated, only the data may be reacquired.
  • the location information itself, or information indicating whether the content of data such as MPD whose acquisition source is indicated by the location information may be independently indicated.
  • the location information descriptor in the PMT transmitted periodically may be checked sequentially.
  • section data for storing location information descriptors and the like, an event section for notifying that it has been updated, and the like may be separately generated and periodically transmitted.
  • the receiving device can determine whether the location information has been updated by checking the version number in the section. Further, when the location information is transmitted in the broadcast section, the update of the meta information is indicated by updating the version number of the location information section.
  • the updated content of the location information may be acquired in communication.
  • FIG. 14 is a flowchart showing an example of the operation on the reception side in the broadcasting / communication cooperation service according to the sixth modification of the first embodiment.
  • step S804 in FIG. 12 is changed to step S906, step S907, and step S908.
  • Other operations are the same as the operations (steps S801 to S803, S805, and S806) in FIG.
  • step S906 it is determined whether the acquisition destination URL such as MPD is stored in the location information descriptor or the TEMI access unit. If it is in the location information descriptor (Yes in S906), the process proceeds to step S907, where the location information descriptor is analyzed, and the MPD is acquired from the communication server based on the URL indicated in the location information. On the other hand, if it is determined in step S906 that the data is stored in the TEMI access unit (NO in S906), the MPD is acquired from the communication server based on the URL indicated by the temmi_location_descriptor in the TEMI access unit.
  • FIG. 14 shows an example in which MPD is shown as the format information, broadcast content and communication content can be synchronously reproduced by the same flow operation even with other meta information.
  • FIG. 15 is a flowchart illustrating another example of the operation on the reception side in the broadcast communication cooperative service according to the sixth modification of the first embodiment.
  • FIG. 15 shows the operation when the format information is meta information other than MPD. More specifically, when the format information indicates not the meta information such as MPD but the format of entity data such as a stream, in place of the meta information URL in steps S907 and S908 shown in FIG. The operation when acquiring the URL of the entity data of the stream is shown.
  • step S1001 the receiving apparatus analyzes the location information descriptor.
  • step S1002 it is determined whether or not the data indicated in the format exists in the broadcast (step S1002). If data exists in the broadcast (Yes in S1002), the process proceeds to step S1003, and the PID indicated in the location information is acquired.
  • the format is determined to be metadata.
  • a meta information file is acquired from the broadcast stream based on the PID (step S1004), and communication data to be acquired is determined (step S1005).
  • step S1002 if data exists in the communication in step S1002 (No in S1002), the process proceeds to step S1008, and it is determined whether the URL of the communication data exists in the location information descriptor or in the temmi_location_descriptor of the TEMI access unit. . Then, according to each case, the URL is acquired in step S1009 or step S1010.
  • step S1011 it is determined whether the format is meta information. If the format is meta information (Yes in S1011), the process advances to step S1012 to acquire meta information from the communication stream based on the URL, and the process advances to step S1005 to determine communication data to be acquired.
  • step Sp1005 After the communication data to be acquired is determined in step Sp1005 or when it is determined in step S1011 that the format is not meta information, the process proceeds to step S1006 to acquire communication data.
  • step S1007 the broadcast content and the communication content are synchronously reproduced based on the synchronization information included in the location information descriptor or the synchronization information indicated by the MPEG-2 TS timeline extension.
  • the reference clock information of audio and video transmitted by broadcasting and the reference of audio and video transmitted by communication Information indicating whether the clock information is the same may be stored in a transmission identification descriptor, program information, EPG, EIT, or the like.
  • information necessary for reference clock synchronization may be indicated.
  • the storage location of information necessary for reference clock synchronization, the type of information necessary for reference clock synchronization, the method of reference clock synchronization, and the like may be indicated.
  • PCR Program Clock Reference
  • NTP Network Time Protocol
  • the DTS and PTS in the NTP standard in video and audio are converted into the PCR standard to convert the broadcast
  • the type and method of reference clock synchronization may be indicated so that the reference clock in communication can be synchronized.
  • the type and method of reference clock synchronization may be indicated such that DTS and PTS of broadcasting and communication are converted so as to synchronize with a specific clock used in the receiving apparatus.
  • identification information indicating the type and method of information necessary for reference clock synchronization may be analyzed, and reference clock synchronization may be performed by a method based on the identification information.
  • information indicating that there are a plurality of reference clocks having different reference clocks may be stored in the descriptor.
  • the descriptor may be indicated for each different reference clock, or may be indicated by one descriptor.
  • Information indicating the correspondence between the reference clock and the program using the reference clock may be stored.
  • information indicating whether or not the reference clocks are the same it may be indicated as a descriptor as described above, or another descriptor, table, section, or the like may be used. Moreover, you may show by whether information (for example, timeline extension information etc.) required for clock synchronization exists. If information necessary for clock synchronization exists, the clock information may be different. Alternatively, the clock information is different using the attribute information of the communication content (for example, information on the format or type, or the extension described in the location information or URL) indicated in the transmission identification descriptor or the like. May be shown.
  • hybrid cast it may be stored in an AIT controlled section or application.
  • the receiving device determines that different clock information is used, it synchronizes the reference clock information for broadcasting and communication. When it is determined that common clock information is used, it is determined that clock synchronization is unnecessary.
  • the receiving device receives, for example, auxiliary information including difference information between a content reference clock by a broadcast wave and a content reference clock by a communication channel, and also receives a content reference clock by a broadcast wave and a content reference clock by a communication channel. May differ from each other based on the difference information, the content reference clock based on the communication channel may be synchronized with the content reference clock based on the broadcast wave.
  • the receiving device selects the user by the user interface, user settings, content provider, service provider, broadcast It may be determined whether or not the reference clock synchronization between the broadcast content and the communication content is actually performed in consideration of all of the intention of the station, the specifications and specifications of the receiving device, the intention of the receiver manufacturer, and the like.
  • the receiving device may start synchronization after the determination as the timing for actually performing the clock synchronization, or when the information related to the synchronization is acquired without performing the determination. You may start. Or you may synchronize according to the time which starts acquisition of communication content (for example, the fixed time before starting acquisition of content, the same time as acquisition start, etc.).
  • the reference source may be started when the clock recovery of the reference clock information is completed.
  • the EPG When the information about whether the reference clock of broadcasting and communication is synchronized is indicated by the EPG, as in the case of pro-buffering of communication content, it is possible to determine whether the synchronization of the reference clock is necessary before the start of broadcasting.
  • the synchronization of the reference clock may be started. In this way, by synchronizing the reference clock earlier, the service can be provided to the viewer earlier.
  • the information indicating whether the reference clocks are the same is not limited to the combination of broadcast and communication, and data acquired from a plurality of routes such as broadcast, communication, storage format, etc. In particular, it is applicable if different reference clock information is used.
  • the functions and processes described in this modification are instructed, the reception function status is notified by PUSH, and the functions acquired by PULL are packaged and provided as API functions. Also good.
  • API functions can be executed from the application. When implemented as an application, it may be implemented as a resident application, or an application such as HTML5 may be used.
  • the API may be implemented as data exchange between applications and status notification.
  • the functions of the API function related to the information on whether the reference clock is synchronized include, for example, the following 1) to 9).
  • 1) Information on whether or not the reference clock information of broadcast content and communication content is the same is acquired. 2) Obtain information about whether reference clock synchronization is required. 3) Acquire the type and synchronization method of each reference clock information. 4) Acquire information (timeline information, etc.) necessary for clock synchronization. 5) Acquire an acquisition destination of information necessary for clock synchronization. 6) Using the reference source clock information as an argument, the synchronized reference destination clock information is returned. For example, when synchronization is not established, a value indicating that synchronization is not established is returned. 7) Instruct the start of synchronization of the reference clocks of each other. 8) Obtain the status of whether the reference clock is synchronized. 9) Notify that the reference clock is synchronized.
  • FIG. 16 is a flowchart showing an example of the operation on the receiving side in the broadcasting / communication cooperation service according to the seventh modification of the first embodiment. Note that the operation of the flowchart shown in FIG. 16 can be applied to a broadcasting / communication cooperation service using any combination of multiplexing schemes such as MMT, DASH, and RTP. It can also be applied to hybrid casting.
  • multiplexing schemes such as MMT, DASH, and RTP. It can also be applied to hybrid casting.
  • FIG. 16 is based on the premise that the broadcast content and the communication content are synchronized, and the determination of whether the broadcast content and the communication content are synchronized is omitted.
  • steps S1101 and S1102 are the same operations as steps S401 and S402 in FIG.
  • step S1103 the receiving apparatus determines whether to acquire communication content. If it is determined to acquire the communication content (Yes in S1103), the process proceeds to step S1104, where data is received from both the broadcast and communication transmission paths, and in the subsequent step S1105, the reference clocks of the broadcast content and the communication content are the same. Or not.
  • step S1105 If it is determined in step S1105 that the reference clocks are different (yes in S1105), the process proceeds to step S1106, where the reference clocks of the broadcast content and communication content are synchronized, and in step S1107, both are synchronously reproduced.
  • step S1105 if it is determined in step S1105 that the reference clocks are the same (No in S1105), the reference clocks are not synchronized and are reproduced using a common clock.
  • step S1105 processing for determining whether or not the reference clock needs to be synchronized may be performed. For example, depending on the type and method of clock synchronization, it is determined whether the capability of the receiver is compatible with clock synchronization, whether the clock is synchronized as the receiver specification, or whether the user performs clock synchronization. To do. Then, based on step S1105 and the above determination result, it may be determined whether or not to synchronize the reference clock in broadcasting and communication comprehensively, and the process may proceed to step S1106 or step S1107.
  • the synchronization of the reference clock in step S1106 may be performed prior to step S1104. This is because, for example, when the received data of the content is pre-buffered and then started to be reproduced, the data whose PTS is T1 in the broadcast content and the data whose PTS is T1 in the communication content (where the PTSs are already synchronized) This is because the decoding and reproduction may be started after confirming that it has been received. This is because it is necessary to synchronize both reference clocks when determining whether or not the data to be synchronously reproduced is prepared.
  • step S1106 if clock synchronization cannot be performed due to failure to acquire clock synchronization information or due to receiver specifications, a service linked with broadcasting and communication may not be provided to the user. In that case, whether to receive data transmitted by the communication in step S1103 can be determined by determining whether synchronization is essential or whether playback is performed without synchronization. Good.
  • step S1103 in addition to the information that can be identified by the transmission path identification descriptor, user selection and setting, content provider or service provider, broadcast station intention, receiver specification or specification, manufacturer intention, etc. In consideration of all, it may be determined whether to actually receive data transmitted by communication.
  • FIG. 17 is a block diagram illustrating an exemplary configuration of a receiving apparatus according to the seventh modification of the first embodiment.
  • 17 includes an identification information acquisition unit 1101, a determination unit 1102, a communication combination determination unit 1103, a Loc information acquisition unit 1104, a broadcast reception unit 1105, a communication reception unit 1106, and a reference clock determination.
  • the identification information acquisition unit 1101 to the communication reception unit 1106 are the same as the identification information acquisition unit 301 to the communication reception unit 306 described with reference to FIG.
  • the reference clock determination unit 1107 has a function of performing the process of step S1105 shown in FIG. In addition, the reference clock determination unit 1107 may determine whether the reference clocks are different and then perform a process of determining whether the reference clock synchronization is necessary as described above.
  • the reproduction unit 1108 Based on the method determined by the determination result in the reference clock determination unit 1107, the reproduction unit 1108 synchronizes the reference clock when the reference clock is different, and then decodes and reproduces the broadcast content or communication content.
  • a content transmission method, reception method, and transmission device capable of reproducing content using both broadcast and communication on the receiving side even when the content reception start timing by communication is delayed. And a receiver can be realized.
  • the transmission method according to one embodiment of the present invention is a content transmission method capable of transmitting content using a broadcast wave and a communication path, and the content is transmitted using each of the broadcast wave and the communication path.
  • the auxiliary information for synchronizing the content of the broadcast wave and the content of the communication channel, and the auxiliary information to be synchronized when received by the receiving side, at least the broadcast wave An information transmission step of transmitting by using.
  • auxiliary information for synchronizing the content transmitted using the broadcast wave and the communication path is transmitted, so that the receiving side transmits the auxiliary information. Can be synchronized between the contents on the receiving side.
  • the auxiliary information is transmitted prior to transmitting the content, and the auxiliary information further includes location information indicating an acquisition destination of the content or an acquisition destination of the location information. May be included.
  • the auxiliary information may be transmitted by including difference information between the content reference clock by the broadcast wave and the content reference clock by the communication path.
  • the auxiliary information transmitting step when the reference clock of the content is different by transmitting the auxiliary information, the content clock based on the broadcast path is set based on the difference information.
  • the receiver may be synchronized with the reference clock.
  • a generation step of generating the content in a format according to MMT MPEG Media Transport
  • a content transmission step of transmitting the content in the format generated in the generation step May be included.
  • the auxiliary information may be generated by being included in message information that is information related to the acquisition of the content.
  • the reception method includes a reception step of receiving content transmitted using each of a broadcast wave and a communication path, and synchronization between the content based on the broadcast wave and the content via the communication path.
  • a process of performing the synchronization is performed, and a playback step of playing back the content is included.
  • service information transmitted on a transmission path as an entry point such as a broadcast wave is acquired, and when auxiliary information is included in the information, synchronization processing can be performed.
  • the location The content may be received by acquiring the content based on information.
  • the auxiliary information is received prior to receiving the content, and the auxiliary information includes information indicating an acquisition destination of location information indicating an acquisition destination of the content
  • the content may be received by acquiring the location information based on information indicating an acquisition destination of the location information and acquiring the content from the acquired location information.
  • the reception step receives the auxiliary information including difference information between a content reference clock based on the broadcast wave and a content reference clock based on the communication path, and uses the broadcast wave.
  • the content reference clock and the content reference clock by the communication channel are different, the content synchronization by synchronizing the content reference clock by the communication channel with the content reference clock by the broadcast wave based on the difference information
  • the content may be played back by performing a process.
  • the transmission device is a content transmission device capable of transmitting content using a broadcast wave and a communication path, and transmits the content using each of the broadcast wave and the communication path.
  • auxiliary information for synchronizing the content of the broadcast wave with the content of the communication channel, and transmitting the auxiliary information using the broadcast wave at least when the receiving side receives the auxiliary information.
  • An information transmission unit is provided.
  • the reception device includes a reception unit that receives content transmitted using each of a broadcast wave and a communication channel, and synchronization between the content of the broadcast wave and the content of the communication channel.
  • a playback unit that performs the synchronization process and plays back the content.
  • identification information indicating whether content including audio and video is transmitted using communication in addition to broadcasting, and broadcasting and communication are used together.
  • information indicating dependency relations between data transmitted through both transmission paths may be generated and transmitted as content management information.
  • the information indicating the dependency relationship between the data may include whether or not the data transmitted in both transmission paths is synchronously reproduced.
  • the information indicating the dependency relationship between the data may include whether or not the clock information of the data transmitted in both transmission paths is the same.
  • the transmission path through which content including audio and video is transmitted, and the dependency between data transmitted through different transmission paths can be acquired at the start of content reception.
  • the delay time related to the start of acquisition can be reduced.
  • location information of data transmitted in communication may be included in content management information.
  • the location information of the data to be transmitted may be, for example, MPD in MPEG-DASH.
  • the content management information may store information indicating the location information acquisition destination instead of entity data of location information such as MPD.
  • the transmission path through which content including audio and video is transmitted, and the dependency between data transmitted through different transmission paths can be acquired at the start of content reception.
  • the delay time related to the start of acquisition can be reduced.
  • the receiving apparatus may analyze content management information and determine a transmission path for receiving the content and data received in each transmission path. For example, when the clock information of the data transmitted in both transmission paths is different, auxiliary information necessary for clock synchronization between the data is acquired, and DTS and PTS in each data are synchronized, decoded, and reproduced It is good. In addition, when synchronously reproducing data transmitted on both transmission paths, auxiliary information necessary for clock synchronization between data is acquired, and DTS and PTS in each data are synchronized, decoded, and reproduced. You may do that.
  • a receiving apparatus that receives only broadcast data can support the reproduction of communication data while enabling the reproduction of the broadcast data by the same operation as the conventional broadcast reception.
  • the clocks of data transmitted through a plurality of transmission paths are not synchronized, the clocks can be synchronized by acquiring auxiliary information necessary for clock synchronization, and the data can be reproduced synchronously.
  • HTML Hyper Text Markup Language
  • ait_identifier_info in data that is always referred to at the start of broadcast program reception such as PMT descriptor in TS and MPT descriptor in MMT.
  • the identification information shown is transmitted.
  • application control information such as AIT is used as information corresponding to a section or data carousel in TS, an MMT message or data carousel in MMT, or a communication network. Download and get via. Then, an application such as an HTML file is acquired based on the application control information.
  • application control information and application data are referred to as application-related data.
  • An application description may use a description language other than HTML, such as XML.
  • the default setting information of the stream to be played back and the display layout is not application-related data, but data that must be acquired at the time of tuning, such as PMT and MPT, or other TS sections and MMT messages. It may be transmitted in data that can be acquired with a lower delay than the time taken to do so. Information for performing advanced reproduction control may be transmitted as application data such as HTML.
  • information relating to playback control of a stream transmitted in broadcasting or communication includes (a) information relating to scalability between streams, and (b) information relating to stream switching such as multilingual audio and video having different bit rates.
  • (C) information on simultaneous display such as information indicating a plurality of video streams that can be displayed at the same time, information on layout in the case of simultaneous display, and the like. The default value of these information is referred to as default reproduction control information. To do.
  • Receiving devices that do not support applications perform playback based on default values.
  • the receiving device corresponding to the application may start reproduction based on the default value and switch the reproduction operation based on a user operation or an application control command after the application is activated.
  • the information that can be switched by the user action may be switched by the application.
  • switching by the user is basically possible, but for temporal scalability, if the enhancement layer stream can be acquired, the enhancement layer is always used and the receiver automatically plays back. The action may be determined. In this case, the information on time scalability is transmitted only in the default playback control information.
  • information related to playback control is basically executed by an application, but information related to scalability may be transmitted in default playback control information.
  • information related to scalability may be transmitted in default playback control information.
  • only the information for associating the base layer and enhancement layer streams is transmitted using default playback control information or a descriptor specified in MPEG-2 TS, and the application side It may be determined whether to decode the enhancement layer at.
  • Example of default playback control information Next, description examples of the reproduction control information when the reproduction operation based on the default reproduction control information is switched by an application will be described.
  • the default reproduction control information is stored in the descriptor, and the application control information is described in HTML.
  • FIG. 18A is a diagram showing a description example of default playback control information in the second embodiment
  • the layout information may indicate only full screen display without showing information for specifying a stream.
  • the information (application control information) for specifying the video to be played back by default is indicated separately, all of the video played back by default will be displayed. It can be operated to display on the screen.
  • FIG. 19A is a diagram illustrating an example of application control information in the second embodiment
  • FIG. 19B is a diagram illustrating a video display example according to the layout information of the application control information illustrated in FIG. 19A.
  • the information specifying the video may be a URL or a packet ID of an MMT packet.
  • scalability two types of information, scalability and layout, are shown in the default playback control information.
  • scalability it is indicated that the type of scalability is temporal scalability
  • stream attribute information such as the stream type of the MPEG-2 system that the stream to be transmitted corresponds to the basic layer or the extension layer of scalability, these information are used as default reproduction control information. Need not be described.
  • the layout information may indicate only full-screen display.
  • FIG. 20A is a diagram illustrating another description example of the default playback control information in the second embodiment
  • FIG. 20B is a diagram illustrating a video display example according to the layout information of the default playback control information illustrated in FIG. 20A. is there.
  • FIG. 21A is a diagram illustrating an example of application control information in the second embodiment
  • FIG. 21B is a diagram illustrating a video display example according to the layout information of the application control information illustrated in FIG. 21A.
  • the function A is defined by the Script tag.
  • the function A is a function for instructing decoding and reproduction of the temporal scalability enhancement layer when a button on the screen is pressed, and indicates an index number for specifying the base layer and the enhancement layer as an argument.
  • the Body tag describes that the function A is called when a specific button or the like of the remote controller is pressed.
  • Streams such as audio and video to be played back by default may be indicated separately by using an MPEG-2 system, MMT descriptor, or the like.
  • MMT descriptor For example, it is possible to group streams to be played back by default and associate the group ID with the stream.
  • a default value in the default reproduction control information may be defined in advance, and the default reproduction control information may not be transmitted when the parameter value is equal to the default value. For example, if full screen display is set as a default value as a layout, layout information may not be included in the case of full screen display. At this time, in a case where scalability is not used and stream switching is not supported, the default playback control information may not be transmitted.
  • the reception side operates after analyzing the default reproduction control information and the reproduction control information provided by the application after obtaining the service information.
  • the reception method in the present embodiment will be described with reference to the drawings.
  • FIG. 22 is a flowchart showing an example of the operation on the receiving side in the second embodiment.
  • FIG. 22 shows an example of the operation when determining the layout when presenting the functions and the functions such as scalability and stream switching by analyzing the default reproduction control information and the reproduction control information provided by the application. Has been.
  • step S701 the receiving side selects a content to be viewed.
  • step S702 the receiving side analyzes the default reproduction control information, determines a stream to be decoded and reproduced, and determines a presentation method such as a layout.
  • the default playback control information may be transmitted by being included in data that is always acquired at the time of channel selection, such as PMT or MPT, or may be transmitted separately from the application-related data, such as an MPEG-2 TS section or MMT. It may be transmitted by a message or the like.
  • the default value of the default playback control information is set, and based on the default value of the default playback control information until the section or message is received. It may be operated.
  • the stream to be decoded and reproduced may be determined by referring to a descriptor indicating a stream such as audio or video to be reproduced by default.
  • step S703 reproduction is started according to the determined reproduction control parameter.
  • step S704 it is determined whether or not an application is received. If not received (NO in S704), the process ends. On the other hand, if it is received (Yes in S704), the process proceeds to step S705, and it is determined whether or not the playback control function is indicated in the application.
  • step S705 if the playback control function is not indicated (No in S705), the process is terminated. If the playback control function is indicated (Yes in S705), the process proceeds to step S706, and the playback control information is updated according to the control command and the user operation based on the playback control function indicated in the application.
  • step S707 playback is performed according to the updated playback control parameter, and the process is terminated.
  • FIG. 23 is a block diagram illustrating an example of a configuration of a receiving device in the second embodiment.
  • FIG. 23 shows an example of the configuration of a receiving apparatus that realizes the operation of each step described in FIG.
  • reception unit 701 includes a reception unit 701, a default information analysis unit 702, an application information reception unit 703, an application reproduction control information analysis unit 704, and a reproduction control execution unit 705. Since these operations are the operations in each step described with reference to FIG.
  • Modification 1 The mechanism for updating the default reproduction control information by an application can be applied to all cases in which content is transmitted by broadcasting alone, communication alone, or a combination of broadcasting and communication.
  • the concept of the method in this embodiment can also be applied to the MPEG-2 TS timeline extension (13818-3: 2013 / AMD6) currently being standardized by MPEG.
  • the TS timeline extension when content is transmitted using a plurality of multiplexed streams including at least one TS (referred to as a basic TS), the content is decoded in the basic TS and other multiplexed streams. Provides information for synchronizing the reference clock in the display.
  • a timeline extension access unit including information that associates a reference clock of a multiplexed stream different from the base TS and the PCR of the base TS is defined, and the timeline extension access unit is stored in the PES packet.
  • TS packet is transmitted.
  • the information for timeline extension is expressed in the MPEG-2 system descriptor format.
  • discontinuity of PCR generally does not occur within a single program, if information for timeline expansion is received at the start of program reception and the reference clocks are synchronized with each other, Often, resynchronization is not required.
  • the default value of the timeline extension information is stored in the PMT or the like, and the access unit for timeline extension is not transmitted. May be.
  • a descriptor similar to the descriptor for storing information for timeline extension can be stored in a section such as PMT and used as a default value of information for timeline extension.
  • the timeline extension access unit and default information stored in the PMT or the like may be used in combination.
  • information for timeline extension corresponding to the updated PCR may be transmitted for a certain period immediately after the occurrence of PCR discontinuity.
  • the version number of the section is updated, resynchronization is performed based on the information for extending the timeline included in the section.
  • clock synchronization between streams cannot be guaranteed at a time after the occurrence of PCR discontinuity and before resynchronization.
  • a PCR discontinuity is separately detected based on information indicating the discontinuity of the PCR, such as the discontinuity indicator of the TS, and when the discontinuity is detected, the basic TS and the synchronization target are detected until resynchronization.
  • the media access unit may be decoded and displayed assuming a fixed frame rate.
  • playback control information including layout information related to video display or information indicating a stream that can be switched during playback is transmitted.
  • the default value of the playback control information is stored in the data that is always received at the time of channel selection, and the information for updating the default playback control operation is stored in the information related to the application such as hybrid cast and transmitted.
  • playback is started according to the default value of the playback control, and when the receiving apparatus supports the application, the default playback control information is updated according to the user operation or the like based on the playback control function transmitted as application data. .
  • Video and audio can be multiplexed and packetized and transmitted via one or more transmission paths such as broadcasting and communication.
  • the receiving device can receive a packet transmitted through one or more transmission paths, extract a desired packet from the received packets based on the program information, and decode / present the packet.
  • a program in the MMT system, it is possible to configure a program by receiving media (video, audio, subtitles, etc.) transmitted through a plurality of transmission paths.
  • media video, audio, subtitles, etc.
  • a program cannot be configured using both data downloaded and accumulated by broadcasting or communication and data streamed from broadcasting or communication.
  • a transmission method, a reception method, and the like will be described in the case where a program is configured using both data downloaded and accumulated by broadcasting and communication and data streamed from broadcasting and communication.
  • an MMT MPEG Media Transport
  • program information is transmitted using message information such as a table such as MPT (MMT Package Table) or PA (Package Access) message.
  • MPT MMT Package Table
  • PA Package Access
  • assets single media such as video and audio constituting a program and location information for transmitting the assets are described. It is also possible to transmit one asset through a plurality of transmission paths.
  • the transmission side transmits content (data or assets) using broadcast waves and communication paths, but transmits service information prior to content transmission.
  • FIG. 24 is a diagram illustrating an example of a data structure of service information in the broadcasting / communication cooperation service according to the third embodiment.
  • FIG. 25 is a diagram illustrating an example of information included in the program configuration information descriptor according to the third embodiment.
  • a program configuration information descriptor is included in the MPT, and in this descriptor, information on assets constituting the package is indicated.
  • Information about the assets that make up a package can include:
  • Information about assets Information about assets
  • an accumulated asset Information indicating whether or not an asset constituting a program includes an accumulated asset (hereinafter referred to as an accumulated asset) may be included in the program configuration information descriptor as information about the asset.
  • the accumulated assets are assets accumulated in, for example, a memory such as an HDD, an internal memory, an SSD, an SD card, or a Blu-ray disc.
  • information indicating the program configuration may be included in the program configuration information descriptor as information about the asset.
  • the program is composed only of accumulated assets
  • the program is composed of accumulated assets and assets that are transmitted (hereinafter referred to as transmission assets), or the assets that contain accumulated packets and transmitted assets
  • Information indicating the configuration of the program such as
  • information indicating that the transmission asset includes a basic layer and the stored asset includes an extension layer may be included.
  • information indicating whether decryption and reproduction of stored assets are essential or not may be included in the reproduction of the program. For example, when the content of the accumulated asset is additional information, reproduction may not be essential, and information indicating that reproduction of the accumulated asset is not essential may be included.
  • stored assets are based on information indicating that decryption / playback of stored assets is not essential for program playback.
  • the program can be played back using assets acquired from broadcasting or communication.
  • Information related to stored assets may be included in the program configuration information descriptor as information related to assets.
  • attribute information such as a storage format of a stored asset, a video / audio encoding method, a transmission method or a multiplexing method for transmitting the stored asset may be included.
  • attribute information is given to the stored asset in advance, and the attribute information may be included in, for example, the header of the stored asset or program information indicating the configuration of the stored asset.
  • the receiving device may be able to play back when the attribute information stored in the program information matches the attribute information of the stored asset.
  • b) information on the capability and function of the receiver necessary for reproducing the program including the stored asset may be included.
  • c) information (scramble method, viewing restriction, limited reception, copyright information) and a key for restricting reproduction and viewing of the program may be included.
  • the receiving apparatus may collate information stored in the program information for restricting viewing with stored assets and determine whether the stored assets can be played back or viewed.
  • the receiving apparatus may store assets that have been encrypted in advance, and decrypt the encryption of the stored assets based on the transmitted key.
  • the time information for synchronizing the transmission assets and storage assets to be played back is included in the program configuration information descriptor as information about the assets. Also good.
  • the time information may indicate, for example, an offset amount with respect to the reference time information of the transmission asset with respect to the reference time that is the reference of the time stamp given to the accumulated asset.
  • the time stamp given to the accumulated asset is given based on PCR (Program Clock Reference) or NTP (Network Time Protocol), it indicates the relative time with respect to the transmitted reference time (PCR or NTP). Also good.
  • the time information may be a time information table of a transmission asset with respect to a random access point of the stored asset when the stored asset is stored in a format having a random access table.
  • asset location information is described for each asset. For example, when one asset exists in a plurality of locations, a plurality of pieces of location information are described in the MPT.
  • FIG. 26 is a diagram illustrating an example of information included in the location information descriptor according to the third embodiment.
  • FIG. 27 is a diagram illustrating an example of location types included in the location information descriptor according to the third embodiment.
  • a location type and an identifier for identifying an asset corresponding to the location type are described as location information.
  • the local ID may be, for example, an asset ID of an accumulated asset or a packet ID. Further, it may be a 32-bit transport file identifier defined in ARIB STD-B45, or may be newly defined. Also, a local ID may be generated according to a predetermined naming rule by combining various IDs such as a network ID and a stream ID. The local ID may be given in advance by a broadcasting station, a transmitting station, a content provider, or the like, or may be given by modifying the ID on the receiver side and adding additional information. A unique ID may be assigned on the receiving side, and a table indicating a correspondence relationship with the ID assigned on the transmitting side may be prepared to specify data.
  • the location type is used to indicate that assets are stored locally, and a local ID is assigned separately.
  • IPv4 may be selected as the location type and specified using a local unique IP address.
  • the IP address is 192.168 .. xxx. xxx, it is assumed that the asset is stored locally, and xxx. The asset accumulated in the portion xxx may be specified.
  • a local ID is assigned to the stored asset data (file). For example, it is stored in the file header in the file.
  • the local ID may be stored in advance by the broadcasting station, transmitting station, content provider, or stored on the receiving side.
  • the above descriptor is an example, and the descriptor may be composed of a data structure having a similar function. Further, the descriptors and identifiers of the present embodiment may be stored in a table or message indicating package unit information different from MPT. You may transmit using other signaling information.
  • MMT Media presentation description
  • MPEG2-TS Media presentation description
  • PMT Program Map Table
  • TEMI Timeline and External Media Information
  • Asset configuration information descriptor In the MMT system, one asset can be transmitted through a plurality of transmission paths. At this time, an asset configuration information descriptor indicating the configuration of the asset may be stored.
  • FIG. 28 is a diagram illustrating an example of information included in the asset configuration information descriptor according to the third embodiment. That is, the information indicating the asset configuration can include the following.
  • the asset may be a stored asset, or the asset may include a stored packet in information indicating the configuration of the asset.
  • the case where an asset includes an accumulated packet is a case where one asset is composed of a packet transmitted from broadcasting or communication and an accumulated packet.
  • the asset may include information indicating that the asset is configured only from the stored asset or configured from a stored packet and a transmission packet as information indicating the configuration of the asset. Good.
  • a) when an asset is composed of scalable encoded video for example, information indicating that a transmission packet includes a basic layer and an accumulation layer includes an extension layer may be included as information indicating the configuration of the asset. Good.
  • c) as an asset configuration information indicating whether decoding and reproduction of a stored packet is essential or not may be included as information indicating the asset configuration. For example, when the content of the stored packet is additional information, it can be shown that the reproduction is not essential and the reproduction of the content of the stored packet is not essential.
  • accumulation is performed based on information indicating that decoding / reproduction of the accumulation packet is not essential for asset reproduction.
  • a program can be reproduced using a packet transmitted from broadcasting or communication without using a packet.
  • asset configuration information descriptor described above is an example, and the asset configuration information descriptor may be configured with a data structure having a similar function.
  • the asset configuration information descriptor and identifier may be stored in a table or message indicating information in units of packages different from the MPT. You may transmit using other signaling information.
  • MMT Media presentation description
  • MPEG2-TS Media presentation description
  • PMT Program Map Table
  • TEMI Timeline and External Media Information
  • FIG. 29 is a flowchart showing a reception method in the broadcasting / communication cooperation service of the third embodiment.
  • FIG. 30 is a block diagram illustrating an example of a configuration of a reception device in Embodiment 3.
  • a program information analysis unit 31 includes a program information analysis unit 31, a stored asset identification unit 32, a stored asset information analysis unit 33, a determination unit 34, an asset acquisition unit 35, a synchronization presentation unit 36, and a synchronization control unit 37.
  • a program information analysis unit 31 includes a program information analysis unit 31, a stored asset identification unit 32, a stored asset information analysis unit 33, a determination unit 34, an asset acquisition unit 35, a synchronization presentation unit 36, and a synchronization control unit 37.
  • step S11 the program information analysis unit 31 analyzes a program configuration information descriptor serving as an entry point, and analyzes whether a stored asset is included in the program configuration.
  • step S12 the program information analysis unit 31 determines whether or not the accumulated assets are included in the elements constituting the program. If it is determined that the component constituting the program includes the accumulated asset (Yes in S12), the process proceeds to step S13, and information such as information indicating the program configuration, information related to the accumulated asset, and relative time information with the accumulated asset is acquired. . If it is determined that the stored asset is not included (No in S12), the process proceeds to step S17, and a transmission asset transmitted by broadcasting or communication is acquired and synchronously reproduced.
  • the receiving device 30 acquires the location information of the accumulated asset and the local ID. More specifically, when the asset is stored locally, the stored asset specifying unit 32 searches and specifies the asset corresponding to the local ID from among the assets stored in the receiving device 30. When there are a plurality of storage devices, the search may be performed from a plurality of storage devices, or only a specific storage device may be searched. Further, the accumulated asset information analysis unit 33 acquires the attribute information of the identified asset.
  • step S15 the determination unit 34 determines whether or not the program including the accumulated asset can be reproduced based on the information related to the accumulated asset acquired in step S12 and the attribute information of the accumulated asset acquired in step S14. judge.
  • step S15 If it is determined that the program is reproducible (Yes in S15), the process proceeds to step S16, and the asset acquisition unit 35 acquires stored assets in addition to transmission assets such as broadcasting and communication. Then, based on the acquired relative time information, the synchronization control unit 37 performs a synchronization control process between the transmission asset and the stored asset, and the synchronization presenting unit 36 synchronizes and presents the program.
  • step S15 determines whether the program is not reproducible (No in S15). If it is determined in step S15 that the program is not reproducible (No in S15), the process proceeds to step S17, where a transmission asset transmitted by broadcasting or communication is acquired and synchronized / reproduced.
  • video and audio are multiplexed and packetized, transmitted through one or more transmission paths such as broadcasting and communication, and received in one or more transmission paths in a receiving apparatus, and program information is used as a basis.
  • a desired packet is extracted from the received packets, and is decoded and presented.
  • a program In the MMT system, it is possible to configure a program by receiving media (video, audio, subtitles, etc.) transmitted through a plurality of transmission paths.
  • media video, audio, subtitles, etc.
  • a program cannot be configured using both data downloaded and accumulated by broadcasting or communication and data streamed from broadcasting or communication.
  • an identifier indicating that one of the media constituting the program is stored data and an identifier for identifying the stored media (file) are provided in the program information indicating the program configuration.
  • the playback device analyzes the program information, identifies the media transmitted by broadcasting / communication and the stored data, and plays back in synchronization.
  • the program can be configured using both the data downloaded and stored by broadcasting and communication and the data streamed from broadcasting and communication. It is possible to provide linked services.
  • the transmission asset may be an asset transmitted by broadcasting or an asset transmitted by communication. Moreover, the asset transmitted from both broadcasting and communication may be sufficient.
  • the following services may be provided as services using stored assets. An identifier indicating the content of the service may be stored in the program information.
  • the program information and random access points may be downloaded and stored together with the assets constituting the program in advance, and the program may be configured in synchronization with the program information transmitted from broadcast or communication.
  • the broadcaster may allocate free frequency resources to other services by providing services linked with stored data.
  • the program information may store information indicating that the frequency resource used for the service is provided to another service.
  • the viewer may have a function of switching to a program linked with stored assets. For example, a viewer who views only transmission assets may switch to a program including stored assets by a user interface such as a remote controller.
  • the receiving device or the viewer may set whether the program may be configured by accessing the stored asset.
  • the program may be configured by accessing the stored asset only when the program information is authenticated as reliable.
  • the program information may store a key or the like as information indicating that the program information can be trusted.
  • EPG Electronic Program Guide
  • Program Information to be displayed as EPG may be acquired from program information or may be acquired from signaling information dedicated to EPG.
  • Information such as whether the program is provided using broadcast, provided using communication, provided using storage, provided in combination, or provided as an extended service May be displayed on the EPG. Further, only functions that can be provided by the receiving apparatus may be displayed. For example, when the receiving device does not have a function for accumulating or receiving a communication, information regarding accumulation or communication may not be displayed.
  • information indicating whether the stored assets of the program are stored or not may be displayed on the EPG.
  • Information indicating whether or not the accumulated assets of the program can be presented may be displayed on the EPG. It may be indicated by characters or the like, or may be indicated by the background color of the EPG program.
  • Content including stored assets may present information related to viewing restrictions and copyrights.
  • the download reservation may be made in advance by the viewer from the EPG, or may be automatically downloaded by the receiving device.
  • the viewer may select the download method, or the receiving device may select it automatically.
  • the display of the EPG and the function of the receiving device may be changed depending on the time zone that can be downloaded by broadcasting, the time zone that can be downloaded by communication, and the time zone that can be streamed by communication.
  • the display is not limited to the EPG display described above, and may be presented by another presentation method other than the EPG.
  • the transmission method and the reception method according to one or more aspects of the present disclosure have been described based on the embodiment, but the present disclosure is not limited to the embodiment. Unless it deviates from the gist of the present disclosure, one or more of the present disclosure may be applied to various modifications conceived by those skilled in the art in the present embodiment, or forms configured by combining components in different embodiments. It may be included within the scope of the embodiments.
  • 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.
  • the present disclosure is useful as a content transmission method, a reception method, and the like that can transmit content using broadcast waves and communication channels.
  • Program information analysis unit 32 Accumulated asset identification unit 33 Accumulated asset information analysis unit 34, 103 Unit 35 asset acquisition unit 36 synchronization presentation unit 37 synchronization control unit 101, 301, 401, 1101 identification information acquisition unit 102 asset determination unit 105, 306, 406, 1106 communication reception unit 302, 402, 1102 determination unit 303, 403, 1103 Communication combination determination unit 304, 404, 1104 Loc information acquisition unit 407 Synchronization determination unit 408, 1108 Playback unit 701 Reception unit 702 Default information analysis unit 703 Application information reception unit 704 Application reproduction control information analysis unit 705 Playback control execution unit 1107 Reference data Click the determination unit

Abstract

　本開示の一態様に係る送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、放送波によるコンテンツと通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に同期を取らせる補助情報を、少なくとも前記放送波を用いて送信する情報送信ステップを含む。これによって、通信によるコンテンツの受信開始タイミングが遅延しても、受信側で放送と通信とを併用したコンテンツが再生可能となる。

Description

送信方法および受信方法ならびに送信装置および受信装置
　本開示は、データ送信方法およびデータ受信方法ならびに送信装置および受信装置に関する。
　従来、コンテンツを配信するための主な伝送路は放送波であり、放送波を用いた放送システムで広く用いられているメディアトランスポート方式として、例えば、ＭＰＥＧ－２　ＴＳ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ－２　Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）がある。
　一方、近年のネットワーク技術の進展に伴い、インターネットなどの通信路を用いてコンテンツを配信することができるようになっている。つまり、放送波だけでなく通信路も用いてコンテンツを配信できるようになっており、コンテンツを配信可能な伝送路が多様化している。
　例えば、非特許文献１には、放送と通信とを併用してコンテンツを配信することを想定した新たなメディアトランスポート方式として、ＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）などがある（非特許文献１参照）。例えば、特許文献１には、放送をメインとして、放送から取得したデータに基づいて、通信コンテンツにアクセスする技術が開示されている。
Ｉｎｆｏｒｍａｔｉｏｎ　ｔｅｃｈｎｏｌｏｇｙ　－　Ｈｉｇｈ　ｅｆｆｉｃｉｅｎｃｙ　ｃｏｄｉｎｇ　ａｎｄ　ｍｅｄｉａ　ｄｅｌｉｖｅｒｙ　ｉｎ　ｈｅｔｅｒｏｇｅｎｅｏｕｓ　ｅｎｖｉｒｏｎｍｅｎｔ　－　Ｐａｒｔ１：ＭＰＥＧ　ｍｅｄｉａ　ｔｒａｎｓｐｏｒｔ（ＭＭＴ）、ＩＳＯ／ＩＥＣ　ＤＩＳ　２３００８－１
　本開示の一態様に係る送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に前記同期を取らせる補助情報を、少なくとも前記放送波を用いて送信する情報送信ステップを含む。
　なお、これらの全般的または具体的な態様は、データ受信方法、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、データ送信方法、データ受信方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示によれば、通信によるコンテンツの受信開始タイミングが遅延しても、受信側で放送と通信とを併用したコンテンツが再生可能となる。
図１Ａは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 図１Ｂは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 図２は、実施の形態１における伝送路識別デスクリプタの概要の一例を示す図である。 図３Ａは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。 図３Ｂは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。 図４Ａは、実施の形態１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 図４Ｂは、実施の形態１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 図５は、実施の形態１における受信装置の構成の一例を示すブロック図である。 図６Ａは、実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 図６Ｂは、実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 図７Ａは、実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 図７Ｂは、実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 図８は、実施の形態１の変形例１における受信装置の構成の一例を示すブロック図である。 図９は、実施の形態１の変形例２の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 図１０は、実施の形態１の変形例２における受信装置の構成の一例を示すブロック図である。 図１１は、実施の形態１の変形例４の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 図１２は、実施の形態１の変形例４の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 図１３Ａは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 図１３Ｂは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 図１３Ｃは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 図１３Ｄは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。 図１４は、実施の形態１の変形例６の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 図１５は、実施の形態１の変形例６の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。 図１６は、実施の形態１の変形例７の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。 図１７は、実施の形態１の変形例７における受信装置の構成の一例を示すブロック図である。 図１８Ａは、実施の形態２におけるデフォルト再生制御情報の記述例を示す図である。 図１８Ｂは、図１８Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 図１９Ａは、実施の形態２におけるアプリケーション制御情報の一例を示す図である。 図１９Ｂは、図１９Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 図２０Ａは、実施の形態２におけるデフォルト再生制御情報の別の記述例を示す図である。 図２０Ｂは、図２０Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 図２１Ａは、実施の形態２におけるアプリケーション制御情報の一例を示す図である。 図２１Ｂは、図２１Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。 図２２は、実施の形態２における受信側の動作の一例を示すフローチャートである。 図２３は、実施の形態２における受信装置の構成の一例を示すブロック図である。 図２４は、実施の形態３における放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。 図２５は、実施の形態３のプログラム構成情報記述子に含まれる情報の一例を示す図である。 図２６は、実施の形態３のロケーション情報記述子に含まれる情報の一例を示す図である。 図２７は、実施の形態３のロケーション情報記述子に含まれるロケーションタイプの一例を示す図である。 図２８は、実施の形態３のアセット構成情報記述子に含まれる情報の一例を示す図である。 図２９は、実施の形態３の放送通信連携サービスにおける受信方法を示すフローチャートである。 図３０は、実施の形態３における受信装置の構成の一例を示すブロック図である。
　（本開示の基礎となった知見）
　現在、放送と通信とを併用して、コンテンツを配信するサービス（放送通信連携サービス）が検討されている。中でも、放送をメインとして、放送から取得したデータに基づいて、通信から取得したコンテンツ（以下通信コンテンツ）にアクセスする方式が有望である。放送通信連携サービスにおけるコンテンツを受信する受信側での視聴開始時の動作としては、放送のみでコンテンツを配信する従来のサービスと同様に、サービス情報を取得後に、オーディオやビデオの符号化データ、または、ＭＰＥＧ－２システムにおけるデータカルーセルなどによりコンテンツの受信を開始することが考えられている。
　しかしながら、従来のサービスで取得できるサービス情報では、通信コンテンツへの迅速なアクセス動作や放送コンテンツのみを選択して受信する際の動作などに対する考慮はされていない。そのため、従来のサービス情報を利用して放送通信連携サービスを行う場合には、サービス情報の解析に係る処理が増加したり通信コンテンツの取得開始タイミングが遅延したりするなどの課題がある。
　このような課題を解決するために、本開示の一態様に係る送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に前記同期を取らせる補助情報を、少なくとも前記放送波を用いて送信する情報送信ステップを含む。
　本態様によれば、通信によるコンテンツの受信開始タイミングが遅延しても受信側で放送と通信とを併用したコンテンツを再生可能なコンテンツの送信方法を実現することができる。より具体的には、放送波と通信路を用いてコンテンツを送信した場合には、放送波と通信路とを用いて送信したコンテンツ間との同期を取るための補助情報を送信するので、受信側が補助情報を受信したときには受信側にコンテンツ間の同期を取らせることができる。
　ここで、例えば、前記情報送信ステップでは、前記コンテンツを送信するのに先だって前記補助情報を送信し、前記補助情報には、さらに、前記コンテンツの取得先を示すロケーション情報または前記ロケーション情報の取得先を示す情報が含まれていてもよい。
　また、例えば、前記補助情報送信ステップでは、さらに、前記補助情報に、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含めて送信してもよい。
　また、例えば、前記補助情報送信ステップでは、前記補助情報を送信することにより、前記コンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記受信側に前記同期を取らせてもよい。
　また、例えば、前記送信方法では、前記コンテンツを、ＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）にしたがったフォーマットで生成する生成ステップと、
　前記コンテンツを、前記生成ステップで生成されたフォーマットで送信するコンテンツ送信ステップと、を含んでもよい。
　また、例えば、前記生成ステップでは、前記補助情報を、前記コンテンツの取得に関する情報であるメッセージ情報に含めて生成してもよい。
　また、上記課題を解決するために、本開示の一態様に係る受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む。
　ここで、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記補助情報を受信し、前記補助情報に、前記コンテンツの取得先を示すロケーション情報が含まれている場合には、前記ロケーション情報に基づき前記コンテンツを取得することで、前記コンテンツを受信してもよい。
　また、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記補助情報を受信し、前記補助情報に、前記コンテンツの取得先を示すロケーション情報の取得先を示す情報が含まれている場合には、前記ロケーション情報の取得先を示す情報に基づき前記ロケーション情報を取得し、取得した前記ロケーション情報から前記コンテンツを取得することで、前記コンテンツを受信してもよい。
　また、例えば、前記再生ステップでは、前記受信ステップにおいて、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含む前記補助情報を受信し、かつ、前記放送波によるコンテンツの基準クロックおよび前記通信路によるコンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記コンテンツの同期を取る処理を行い、前記コンテンツを再生してもよい。
　また、上記課題を解決するために、本開示の一態様に係る送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって、受信側が受信した場合に前記同期を取らせる補助情報を少なくとも前記放送波を用いて送信する情報送信部を備える。
　また、上記課題を解決するために、本開示の一態様に係る受信装置は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える。
　なお、これらの全般的または具体的な態様は、送信方法、送信装置、受信方法、受信装置、集積回路、コンピュータプログラムまたはコンピュータで読み取り可能なＣＤ－ＲＯＭなどの記録媒体記録媒体で実現されてもよく、データ受信方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。
　以下、本開示の一態様に係る送信方法および受信方法等について、図面を参照しながら具体的に説明する。
　なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
　（実施の形態１）
　本実施の形態では、放送通信連携サービスにおけるコンテンツを送信および受信する送信方法について説明する。
　［送信方法］
　本実施の形態では、送信側は、放送波と通信路を用いてコンテンツ（データまたはアセット）を送信するが、コンテンツの送信に先だってサービス情報を送信する。
　［サービス情報］
　ここで、サービス情報とは、選局動作後（選局後）にオーディオやビデオ、もしくは、データ放送に関連するデータなどを取得するための情報、または、ＥＰＧ（Ｅｌｅｃｔｒｉｃ　Ｐｒｏｇｒａｍ　Ｇｕｉｄｅ）の情報など、コンテンツの受信やメタデータの取得に関連する一連の情報を指す。
　なお、現状の放送は、主に、ＭＰＥＧ－２　ＴＳ（Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）のセクションを用いて送信され、ＰＡＴ（Ｐｒｏｇｒａｍ　Ａｓｓｏｃｉａｔｉｏｎ　Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ　Ｍａｐ　Ｔａｂｌｅ）、ＮＩＴ（Ｎｅｔｗｏｒｋ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）、ＣＡＴ（Ｃｏｎｄｉｔｉｏｎａｌ　Ａｃｃｅｓｓ　Ｔａｂｌｅ）、または、ＡＲＩＢ（電波産業会）において規定されたＥＩＴ（Ｅｖｅｎｔ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）などが含まれる。
　本実施の形態では、放送連携サービスにおける放送側の多重化フォーマットとして、ＭＰＥＧで規格化されたＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）を例に挙げて説明する。しかし、この多重化フォーマットはＭＭＴに限定されるものではなく、ＴＳやＭＰＥＧ－ＤＡＳＨ（Ｄｙｎａｍｉｃ　Ａｄａｐｔｉｖｅ　Ｓｔｒｅａｍｉｎｇ　ｏｖｅｒ　ＨＴＴＰ）など他の多重化フォーマットであってもよい。
　本実施の形態におけるサービス情報は、多重化フォーマットに格納できるデータ構造において送信される。例えばＭＭＴでは、サービス情報は、ＭＰＴ（ＭＭＴ　Ｐａｃｋａｇｅ　Ｔａｂｌｅ）などのテーブル、あるいは、ＰＡ（Ｐａｃｋａｇｅ　Ａｃｃｅｓｓ）メッセージなどのメッセージ情報により送信される。なお、各テーブルにおいては、ＴＳと同様に、デスクリプタを用いて補助情報を記述することができる。
　図１Ａ及び図１Ｂは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。より具体的には、図１Ａには、伝送路識別デスクリプタが含まれたＭＰＴが示されており、図１Ｂでは、図１Ａに示す伝送路識別デスクリプタにおいて、例えばパッケージを構成するアセットの伝送路に関する情報が属性情報として記述されている例が示されている。
　（属性情報）
　１）パッケージを構成するアセットが、（１）放送のみを用いる、および、（２）放送と通信とを併用のうちのどちらの方法により送信されるかを示す情報を属性情報として含めるとしてもよい。
　なお、本編のオーディオとビデオのデータが、（１）放送のみを用いる、および、（２）放送と通信とを併用のうちのどちらの方法により送信されるかを示す情報であってもよい。この情報により、本編が放送のみを用いて送信される場合でも、オーディオ、ビデオ、静止画、あるいは、ＨＴＭＬファイルなどの本編とは別のメタデータなどは、通信ネットワークから取得できる。
　２）オーディオやビデオのデータが、放送と通信とを併用して送信される際に、それぞれで送信されるデータの関連を示す情報を属性情報として含めるとしてもよい。
　ここで、例えば、スケーラビリティ（時間解像度（６０ｆｐｓ→１２０ｆｐｓなど）、空間解像度（４ｋ→８ｋなど）、ビット深度（８ｂｉｔ→１０ｂｉｔなど））を実現する場合、属性情報により放送は基本レイヤを、通信は拡張レイヤを用いて送信することを示すことができる。なお、属性情報は、放送データのみではフレームレートが６０ｆｐｓであるが、通信データを併用すると１２０ｆｐｓまでフレームレートを向上できるなどを示すとしてもよい。また、放送のバックアップ用のデータを通信で送信することを示してもよい。これにより、送信側は、属性情報を用いて、降雨減衰などで放送の受信状況が悪化した場合には、通信によりデータを送信するように切替えることができる。
　また、属性情報は、互いに関連するアセットを識別するための情報を示すとしてもよい。例えば、属性情報が基本レイヤのアセットＩＤと、基本レイヤに対応する拡張レイヤのアセットＩＤを示すとしてもよい。
　ＭＭＴでは、同一のアセットを複数の伝送路を用いて送信することも可能である。従って、属性情報は、同一アセットが放送と通信を併用して送信されるかどうかを示してもよい。このとき、当該アセットの識別情報（アセットＩＤなど）を別途示すとしてもよい。関連するアセットを識別するための情報を、例えば図２に示すようにアセット毎の個別の伝送路識別デスクリプタにより示してもよい。ここで、図２は、実施の形態１における伝送路識別デスクリプタの概要の一例を示す図である。図２に示す個別の伝送路識別デスクリプタは、例えば当該アセットが、基本レイヤ、あるいは、拡張レイヤのどちらのアセットであるかを識別するための情報を示すとしてもよいし、当該アセットが拡張レイヤである場合には、対応する基本レイヤのアセットのＩＤなどを示すとしてもよい。
　また、属性情報は、放送のアセットと通信のアセットとをそれぞれグループ化し、グループ内に含まれるアセットのリストを示すとしてもよい。放送と通信を併用して送信されるアセットが存在する場合には、別途グループ化してもよい。
　３）放送により送信されるオーディオやビデオと、通信により送信されるオーディオやビデオとが、同期再生されるかどうかを示す情報を属性情報として含めるとしてもよい。
　４）放送により送信されるオーディオやビデオのクロック情報と、通信により送信されるオーディオやビデオのクロック情報とが、同じかどうかを示す情報を属性情報として含めるとしてもよい。
　なお、属性情報は、個々の情報を個別のフィールドとして示してもよいし、サービスのタイプを示す情報を定義して、タイプにより識別できるようにしてもよい。また、属性情報は、デスクリプタとは異なる形式により記述されるとしてもよい。
　また、伝送路識別デスクリプタは、ＭＰＴとは異なる、パッケージ単位の情報を示すテーブルやメッセージに格納するとしてもよい。また、上記の伝送路識別デスクリプタの内容をデスクリプタとは異なるデータ構造として記述してもよい。
　また、複数のパッケージを送信する際には、パッケージの一覧を示すテーブルやメッセージを定義して、パッケージ単位の情報として、伝送路識別デスクリプタのような情報をパッケージの属性情報として示してもよい。
　図３Ａ及び図３Ｂは、実施の形態１の放送通信連携サービスにおけるサービス情報のデータ構造の別の一例を示す図である。
　すなわち、図３Ａおよび図３Ｂに示すように、アセット毎のロケーション情報については、放送と通信とで送信されるアセットを、それぞれ別のＭＰＴに格納してもよい。このとき、パッケージの属性情報は、サービスのエントリポイントとなる伝送路において送られるＭＰＴに格納できる。例えば、放送がエントリポイントとなる場合には、放送で送られるＭＰＴに格納する。また、これらのＭＰＴはｔａｂｌｅ＿ｉｄにより識別できる。
　ＭＭＴ規格では、基準となるＭＰＴのｔａｂｌｅ＿ｉｄの値はゼロと規定されているため、エントリポイントとなる伝送路に対応するＭＰＴのｔａｂｌｅ＿ｉｄをゼロとし、他方の伝送路に対応するＭＰＴのｔａｂｌｅ＿ｉｄを１以上とするなどが可能である。
　なお、放送アセットのＭＰＴは放送により、通信アセットのＭＰＴは通信により送信してもよい。
　また、放送と通信のアセットのロケーション情報を１つのＭＰＴに格納するとしてもよい。この場合、それぞれのアセットのロケーション情報を連続して格納するなどして容易に識別できるようにすればよい。例えば、放送のアセットがＮ１個、通信のアセットがＮ２個存在する場合には、まず、Ｎ１個の放送アセットの情報を連続して記述し、その後にＮ２個の通信アセットの情報を連続して記述する。なお、伝送路識別デスクリプタにおいて、Ｎ１個のアセットが放送において、Ｎ２個のアセットが通信において送信される旨を示してもよい。
　このように、送信側において、サービス情報に補助情報である伝送路識別デスクリプタを含めて送信する。それにより、受信側において、補助情報を含むサービス情報を取得するだけで、伝送路識別デスクリプタに記述されるパッケージの属性情報により、通信のデータが含まれるかどうか、あるいは、放送データと通信データとの依存関係などを、アセット毎の情報を解析することなく前もって取得できる。
　特に、通信データを受信する際には、受信処理の起動に係る遅延時間を短縮できるというメリットがある。
　［送信装置］
　例えば、本実施の形態の送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、補助情報として伝送路識別デスクリプタなどパッケージの属性情報を生成し、サービス情報に含めて送信する。
　本実施の形態の送信装置は、このサービス情報を、周期的に送信してもよい。このサービス情報の内容が更新される際には、更新直後にその更新した内容をサービス情報において反映する。
　また、エントリポイントは、放送に限定されるものではなく、通信であってもよいし、放送と通信の両方からエントリできるようにしてもよい。なお、両方からエントリ可能とする際には、パッケージ単位の情報については、少なくとも、放送と通信の両方の送信装置から送信する。
　なお、受信側において放送通信連携サービスのコンテンツを受信する際には、必ずしも両伝送路により送られるデータを受信しなくてもよい。例えば、放送のデータのみを受信して再生するとしてもよい。このとき、受信側が通信データを受信する際に必要となる情報は、放送データの受信時には不要であるため、送信側は通信データを受信する際に必要となる情報を通信において送信するとしてもよい。すなわち、送信側は、パッケージ単位の情報についてエントリポイントとなる伝送路において送信し、放送、通信など伝送路に固有の情報は、それぞれの伝送路において送信するとしてもよい（例えば図２）。なお、以下では、放送がエントリポイントであるとして説明する。
　こうすることで、各伝送路に固有のサービス情報は、各伝送路における送信装置が生成して送信できる。ただし、アセットのロケーション情報などＭＰＴにより送信される情報は、最初に一括して取得することで、通信側のアセットの取得開始に係る遅延時間が低減できるため、放送で送信してもよい。
　（通信に固有の情報の例）
　通信（インターネット、ＣＤＮ（Ｃｏｎｔｅｎｔｓ　Ｄｅｌｉｖｅｒｙ　Ｎｅｔｗｏｒｋ）などの通信ネットワーク）に固有の情報の例を示す。
　１）例えばＦＥＣの方式、パラメータなど、通信により送信するパケットにおけるＦＥＣ（Ｆｏｒｗａｒｄ　Ｅｒｒｏｒ　Ｃｏｒｒｅｃｔｉｏｎ）に関連する情報
　２）例えばパケットロス率や、パケット到着時刻のジッタ、あるいは、ＲＴＴ（Ｒｏｕｎｄ　Ｔｒｉｐ　Ｔｉｍｅ）、通信伝送路におけるｅｎｄ－ｔｏ－ｅｎｄ遅延など、ＱｏＳ（Ｑｕａｌｉｔｙ　ｏｆ　Ｓｅｒｖｉｃｅ）コントロールに関連する情報
　３）例えばバッファリング時間、バッファリング量など、アセットのデータを受信してから復号開始するまでのバッファリングに関する情報
　なお、放送においても、特に移動体向けの放送（日本における１セグメント放送など）においては、ＦＥＣやＱｏＳが重要となるが、これらにおけるパラメータは通信路とは異なる。そのため、放送に固有の情報は、放送においてのみ送信すればよい。
　一方、通信においては、ビットレートやフレームレートなど、通信ネットワークの帯域に応じた複数のオーディオやビデオデータを選択可能とすることができる。このとき、選択可能なデータの属性情報（ビットレートなど）とアセットＩＤとを対応付ける情報を送信してもよい。なお、このような対応付ける情報は、放送において送信してもよい。
　なお、対応付ける情報として、選択可能な複数のアセットが存在するかどうかを示す情報を示してもよいし、選択可能な複数のアセットが存在する場合に、選択可能なアセットのリストを示してもよい。
　［受信方法］
　本実施の形態では、受信側は、サービス情報を取得後に、コンテンツの受信（取得）を開始する。以下、図を用いて、本実施の形態における受信方法について説明する。
　図４Ａは、実施の形態１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。図４Ａには、受信装置が本実施の形態の伝送路識別デスクリプタを取得して、受信するアセットを決定する動作の一例が示されている。
　まず、エントリポイントとなる伝送路において送信されるサービス情報として例えばＰＡメッセージ、あるいは、ＭＰＴメッセージなどに含まれるＭＰＴテーブルを取得して、その中に含まれる伝送路識別デスクリプタを取得する。
　次に、放送と通信を併用してアセットが送信されるかどうか、及び、両伝送路が使われる際には、放送と通信のアセットの依存関係など、伝送路識別デスクリプタの情報を解釈する（ステップＳ１０１）。
　ＰＡメッセージなどのメッセージは、ＭＭＴパケットなどのパケットのペイロードに格納され、パケットヘッダにより、格納されるデータの種別が示される。従って、ＭＭＴパッケージの受信時には、まず、パケットヘッダにおけるＩＤ番号（ＭＭＴパケットではｐａｃｋｅｔ＿ｉｄに相当）を参照して、ＰＡメッセージのＭＭＴパケットを取得する。
　次に、端末の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するアセットを決定する（ステップＳ１０２）。
　ここで、アセットの決定方法の例について説明する。
　１）受信装置が通信ネットワークに接続していない場合には、放送のアセットのみ受信すると決定する。このとき、放送と通信とを併用して送信されるアセットは受信しない。
　２）ビデオの基本レイヤが放送、拡張レイヤが通信により送信される場合に、基本レイヤのみ再生可能な場合には放送のみを、両レイヤを再生可能な場合には放送と通信とを共に受信すると決定する。例えば、基本レイヤのみで６０ｆｐｓ、基本レイヤおよび拡張レイヤで１２０ｆｐｓの時間スケーラビリティが実現できるとする。この場合に受信装置が６０ｆｐｓまでしか復号、表示できなければ放送のみを、１２０ｆｐｓまで復号、表示できる場合には放送と通信の両データを受信する。
　３）受信装置が接続する通信ネットワークの帯域に応じて、通信により送信されるビットレートの異なる複数のアセットから、受信可能なアセットを決定する。ここで、例えば、各アセットのビットレートなどの情報は、別途サービス情報などにおいて送信されるものとする。なお、通信ネットワークの輻輳などにより受信状態が悪く、安定して受信可能なアセットが存在しない場合には、通信側のデータを受信しないと決定してもよい。
　４）また、放送の受信環境悪化に備えて、通信においてバックアップ用のデータが送信されている場合、受信環境が悪化したときには取得するアセットを決定するとしてもよい。この場合、受信装置は、受信環境をモニタし、受信データにおけるエラー率などの指標に基づいて、通信のアセットを受信するかどうかを判定し、受信処理を行えばよい。
　５）放送により送信される本編のオーディオやビデオのデータと同期再生されるデータ（ビデオにおける拡張レイヤのデータなど）を通信から受信する際には、放送により受信したデータと通信により受信したデータの同期を保証するために、再生開始前にデータをバッファリングするなど特別な動作が必要となる場合がある。この場合において、通信からは、放送により送信されるデータと厳密な同期（例えば、フレーム単位での同期など）が必要でないアセットのみ受信することとしてもよい。例えば、ＨＴＭＬなどのデータ、静止画、厳密な同期が不要な動画などのアセットであれば通信から取得すると決定するとしてもよい。
　以下、図４Ａのフローチャートに戻って説明する。
　次に、ステップＳ１０３では、通信により送信されるアセットを受信するかどうかを決定（判定）し、受信すると決定（判定）した場合（Ｓ１０３ではい）、Ｓ１０４に進み、受信しないと決定（判定）した場合（Ｓ１０３でいいえ）には、Ｓ１０５に進む。
　Ｓ１０４では、放送と通信との両伝送路からアセットを受信し、Ｓ１０５では、放送のみからアセットを受信する。
　図４Ｂは、実施の形態１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。
　図４Ｂは、図４Ａと比較して、通信に固有のサービス情報が通信において送信される場合に、当該サービス情報を受信するステップ（ステップＳ１０６）が追加されている。その他については、図４Ａで説明したものと同様のため、説明を省略する。
　なお、放送に固有のサービス情報が存在する場合には、図示しないステップにおいて別途受信するものとする。
　また、受信装置が放送通信連携サービスに対応していない場合には、放送のアセットのみを受信するとすればよい。この場合、放送と通信とを併用して送信されるアセットが存在する場合には、当該アセットは受信しない。
　［受信装置］
　図５は、実施の形態１における受信装置の構成の一例を示すブロック図である。図５では、図４Ａで説明した受信方法を実現する受信装置の構成の一例が示されている。
　図５に示す受信装置１００は、識別情報取得部１０１と、アセット決定部１０２と、判定部１０３と、放送受信部１０４と、通信受信部１０５とを備える。
　識別情報取得部１０１は、図４Ａに示すステップＳ１０１を実現する機能を備える。具体的には、識別情報取得部１０１は、エントリポイントとなる伝送路において送信されるサービス情報を取得し、その中に含まれる伝送路識別デスクリプタ（補助情報）を取得する。そして、識別情報取得部１１は、伝送路識別デスクリプタの情報を解釈する。
　アセット決定部１０２は、図４Ａに示すステップＳ１０２を実現する機能を備え、端末の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するアセットを決定する。
　判定部１０３は、図４Ａに示すステップＳ１０３を実現する機能を備え、通信により送信されるアセットを受信するかどうかを決定（判定）する。具体的には、判定部１０３は、通信データを受信するかどうかを判定し、受信すると判定した場合には放送受信部１０４および通信受信部１０５において、ステップ１０２において決定したアセットのデータを受信する。
　判定部１０３は、通信データを受信しないと判定した場合には、放送受信部１４のみを用いてデータを受信する。
　（変形例１）
　本変形例では、放送はＴＳを用いて送信し、通信はＤＡＳＨやＲＴＰ（Ｒｅａｌ－ｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）などを用いて送信する場合の例について説明する。
　図６Ａ及び図６Ｂは、実施の形態１の変形例１の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。図６Ａには、通信において送信されるデータに関する情報をＰＭＴに格納する例が示されている。図６Ｂには、本変形例の伝送路識別デスクリプタのデータ構造の一例が示されている。
　本変形例では、サービス情報の一例であるＰＭＴに、図１Ａおよび図１Ｂにおいて説明した属性情報など示す伝送路識別デスクリプタが格納される。
　ＰＭＴなどＴＳにおけるプログラム情報では、ＴＳにより送信されるデータのロケーション情報のみが示される。そのため、本変形例では、コンテンツのデータが通信を併用して送信される際には、通信側のデータのロケーション情報を伝送路識別デスクリプタに格納する。より具体的には、属性情報において、通信が併用されるかどうかを示すフラグ情報を含める。これにより、送信側は、当該フラグ情報の値に応じて、通信側のデータのロケーション情報を含めるかどうかを選択することができる。なお、ロケーション情報は、伝送路識別デスクリプタに格納される場合に限らない。別途デスクリプタを定義して、ロケーション情報を格納してもよい。
　（ロケーション情報）
　ロケーション情報とは、データの取得先を示す情報であり、ＴＳであればＰＩＤ、通信であればＵＲＬやＵＲＩなどが相当する。
　ロケーション情報としては、ＤＡＳＨのＭＰＤ（Ｍｅｄｉａ　Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ）や、ＲＴＰにおけるＳＤＰ（Ｓｅｓｓｉｏｎ　Ｄｅｓｃｒｉｐｔｉｏｎ　Ｐｒｏｔｏｃｏｌ）などを格納してもよい。
　また、ロケーション情報には、ＭＰＤやＳＤＰなどのロケーション情報の実体データを格納する場合に限らず、ロケーション情報の実体データの取得先を示す情報を格納するとしてもよい。ここで、ロケーション情報の実体データの取得先を示す情報は、例えば、ＭＰＤを取得するためのＵＲＬを示す情報などである。ただし、ロケーション情報にロケーション情報の実体データの取得先を示す情報を格納する場合には、ロケーション情報の実体データを別途取得するための遅延が発生する。そのため、通信側のデータを受信開始するまでの遅延を低減する観点から、ロケーション情報には、実体データを直接格納するのが望ましい。
　なお、ＤＡＳＨのＭＰＤには、コンテンツの取得先に関して様々な情報が含まれるため、サイズが大きい。従って、ロケーション情報にＭＰＤをそのまま格納するのではなく、コンテンツの取得先のＵＲＬと、セグメントのＤＴＳやＰＴＳに関する情報のみを含むサブセット化した情報を格納するとしてもよい。
　また、ＭＰＤなどロケーション情報の内容の更新にも対応できることが望ましい。
　例えば、ロケーション情報に対してバージョン番号を付与するなどしてもよい。これにより、バージョン番号が更新された場合には、ロケーション情報を取得し直すことができる。なお、バージョン番号が更新されたかどうかを確認するために、周期的に送信されるＰＭＴ内の伝送路識別デスクリプタなどの情報を逐次チェックしてもよい。しかし、この逐次チェックの処理は重いため、ロケーション情報などを格納するためのセクションデータを別途生成（伝送路識別セクションと呼ぶ）し、周期的に送信するとしてもよい。
　受信装置においては、伝送路識別セクションにおけるバージョン番号を確認すればロケーション情報が更新されたかどうかを判定できる。なお、ＰＭＴなどのプログラム情報と、伝送路識別セクションの双方において、属性情報やロケーション情報を送信してもよい。あるいは、伝送路識別セクションにおいては、ロケーション情報のみを格納してもよい。
　また、放送から取得したロケーション情報に基づいて通信側のデータを取得開始した後は、通信においてロケーション情報の更新内容を取得してもよい。このとき、ロケーション情報の取得先が必要となるため、放送の伝送路識別デスクリプタなどにおいて、ロケーション情報の実体データと共に、ロケーション情報の取得先も合わせて格納してもよい。
　受信装置では、ロケーション情報の取得先に定期的にアクセスするなどして、通信において更新内容を取得できる。
　また、ＤＡＳＨコンテンツの配信サーバと受信装置との間でメッセージ交換などの仕組みが存在する場合には、ロケーション情報が更新されたことを示すメッセージをサーバが受信装置に対して発行するとしてもよい。そして、受信装置では、メッセージを受信した際にはロケーション情報を取得し直すなどしてもよい。
　なお、通信において送信されるデータに関する情報をＰＭＴに格納するとして説明したがこれに限らない。属性情報やロケーション情報を、ＰＭＴとは異なるセクションにより送信するとしてもよい。
　また、通信において送信されるデータが、放送におけるオーディオやビデオと同期再生されるかどうかに基づいて、通信側のデータの取得方法を切替えてもよい。
　例えば、同期再生される場合には、上述したように放送のプログラム情報から通信側のデータにアクセスできるようにする。同期再生されない場合には、ＡＲＩＢ（電波産業会）におけるハイブリッドキャスト仕様に規定されたＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）などを用いて、通信側のデータにアクセスするための情報をデータ放送により送信してもよい。受信装置では、テーブル、あるいは、カルーセルなどの形式でＡＩＴを受信し、ＡＩＴの内容に基づいて通信側のデータを取得する。取得した通信側のデータは、データ放送により送信されるイベントメッセージを受信すると、再生開始される。
　なお、放送データと通信データとが同期再生される場合にも、ＡＩＴなどの情報を利用してもよい。このとき、通信側のデータの再生開始、終了などの時刻は、別途データ放送内に示されるものとする。受信装置では、これらの時刻に従って、通信側のデータを再生する。
　ＤＡＳＨにおけるＭＰＤや、ＲＴＰにおけるＳＤＰでは、コンテンツの再生開始時刻、あるいは、復号開始時刻を示すことができ、これらの時刻はＵＴＣ（Ｃｏｏｒｄｉｎａｔｅｄ　Ｕｎｉｖｅｒｓａｌ　Ｔｉｍｅ）など、多重化や伝送の方式毎に規定される基準クロックに基づいて指定される。また、個々のビデオフレームやオーディオのサンプルのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｔｉｍｅ　Ｓｔａｍｐ）やＤＴＳ（Ｄｅｃｏｄｉｎｇ　Ｔｉｍｅ　Ｓｔａｍｐ）も、基準クロックに基づいて設定される。一方、放送では、ＰＣＲ（Ｐｒｏｇｒａｍ　Ｃｌｏｃｋ　Ｒｅｆｅｒｅｎｃｅ）が基準クロックとなるため、放送側のデータと通信側のデータとを同期再生する際には、互いの基準クロックの対応関係を示す情報が必要となる。
　従って、放送側のデータと通信側のデータの基準クロックの対応関係を示す情報を、放送におけるＰＭＴなどのプログラム情報に含めてもよい。例えば、放送におけるＰＣＲの値がＮ１である時刻と、通信におけるＵＴＣの値がＮ２である時刻が同一時刻に相当するなどの情報であってもよい。なお、これらの情報は、ＭＰＤやＳＤＰなどに含めてもよい。
　また、伝送路識別デスクリプタにおいて、通信側のデータが、ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）、及び、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）のいずれによって送信されるかなど、トランスポート層のプロトコルの情報を示してもよい。これにより、受信装置においては、各プロトコルにおいて使用するポートをオープンする、あるいは、使用されるプロトコルに対応しているかどうか判断するなどが可能となる。
　また、通信側のデータにおける多重化フォーマットの識別情報を示して、例えば、ＤＡＳＨ、あるいはＲＴＰであるかどうかなどを識別できるようにしてもよい。
　［受信方法］
　以下、図を用いて、本変形例における受信方法として、放送がＴＳを用いて送信され、通信がＤＡＳＨやＲＴＰ（Ｒｅａｌ－ｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）などを用いて送信される場合の受信装置の動作の一例について説明する。
　図７Ａは、実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。図７Ａには、属性情報やロケーション情報が放送のプログラム情報に格納される際の受信装置の動作の一例が示されている。
　各ステップ（ステップＳ２０１～ステップＳ２０５）の動作は、図４Ａのフローチャートと同様であるが、図４Ａにおいては、放送側と通信側とのデータがＭＭＴパッケージのアセットで統一されていたのに対し、図７Ａでは放送側はＴＳ、通信側はＤＡＳＨやＲＴＰのデータとなる点において異なる。それ以外の点については、図４Ａで説明した通りであるため、詳細な説明は省略する。
　図７Ｂは、実施の形態１の変形例１の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。図７Ｂでは、放送のプログラム情報において、属性情報、及び、ロケーション情報を取得するためのアクセス情報が格納され、ロケーション情報の実体は格納されない場合の動作の一例が示されている。
　ステップＳ３０１は、ステップＳ２０１と同様であるので、説明を省略する。
　次に、ステップＳ３０２において、通信側のデータを受信するかどうかを決定（判定）し、ステップＳ３０３において、通信側のデータを受信する際にはＳ３０４に進み、通信側のデータを受信しない場合にはＳ３０６に進む。
　ステップＳ３０４では、放送のプログラム情報に含まれる通信側データのロケーション情報の取得先に従って、ロケーション情報を取得する。
　一方、ステップＳ３０５では、Ｓ３０４で取得したロケーション情報に基づいて通信側データを取得すると共に、放送データを取得する。また、Ｓ３０６では、放送により送信されるデータのみを取得する。
　（属性情報）
　属性情報は、実施の形態１において説明した内容と同様であるが、実施の形態１ではＭＭＴを例に説明したため、以下、放送がＴＳ、通信がＤＡＳＨやＲＴＰを用いる際の例について説明する。
　１）コンテンツを構成するオーディオやビデオなどのデータが、（１）放送のみを用いる、および（２）放送と通信を併用のうちのどちらの方法により送信されるかを示す情報を属性情報として含めるとしてもよい。
　なお、オーディオとビデオのデータが、（１）放送のみを用いる、および、（２）放送と通信とを併用のうちのどちらの方法により送信されるかを示す情報であってもよい。この情報により、本編が放送のみを用いて送信される場合でも、オーディオ、ビデオ、静止画、あるいは、ＨＴＭＬファイルなどのメタデータなどは、本編とは別の通信ネットワークから取得できる。
　２）オーディオやビデオが、放送と通信とを併用して送信される際に、それぞれで送信されるデータの関連を示す情報を属性情報として含めるとしてもよい。
　ここで、例えば、スケーラビリティ（時間解像度（６０ｆｐｓ→１２０ｆｐｓなど）、空間解像度（４ｋ→８ｋなど）、ビット深度（８ｂｉｔ→１０ｂｉｔなど））を実現する場合に、属性情報により放送は基本レイヤを、通信は拡張レイヤを用いて送信することを示すことができる。属性情報は、ユースケースとして、放送データのみではフレームレートが６０ｆｐｓであるが、通信データを併用すると１２０ｆｐｓまでフレームレートを向上できるなどを示すとしてもよい。また、属性情報は、放送のバックアップ用のデータを通信で送信することを示してもよい。これにより、送信側は、属性情報を用いて、降雨減衰などで放送の受信状況が悪化した場合には、通信によりデータを送信するように切替えることができる。
　また、属性情報は、互いに関連する符号化ストリームを識別するための情報を示すとしてもよい。例えば、属性情報は、放送で送信される基本レイヤのデータが格納されるＴＳパケットのＰＩＤと、通信で送信されるＤＡＳＨデータにおけるセグメント、あるいは、ＭＰ４におけるトラックＩＤなどのビデオデータの識別情報を示すことができる。
　また、属性情報は、互いに同期再生される放送側のデータと、通信側のデータを示す情報を示すとしてもよい。これにより、送信側は、複数視点の映像、あるいは、ピクチャ・イン・ピクチャにおける親画面と子画面の映像を、それぞれ放送と通信とにより送信するなどができる。
　３）放送により送信されるオーディオやビデオなどと、通信により送信されるオーディオやビデオなどとが、同期再生されるかどうかを示す情報を属性情報として含めるとしてもよい。
　４）放送により送信されるオーディオやビデオのクロック情報と、通信により送信されるオーディオやビデオのクロック情報とが、同じかどうかを示す情報を属性情報として含めるとしてもよい。
　５）通信側のデータがライブコンテンツであるかどうかを示す情報を属性情報として含めるとしてもよい。
　例えば、送信されるコンテンツがライブコンテンツでなければ、現在時刻（Ｔ１）よりも後のデータを取得することができる。従って、コンテンツの取得要求から受信開始するまでにかかる時間（あるいは、その推定値）、及び、データをバッファリングする時間の総和（△Ｔ）を現在時刻に加算した時刻（Ｔ２）が再生時刻となるデータから受信開始することで、放送側のデータを遅延させることなく再生できる。この時、通信側のデータは時刻Ｔ２から再生される。一方、送信されるコンテンツがライブコンテンツである場合には、放送側のデータを△Ｔだけバッファリングして、時刻Ｔ２において放送と通信のデータを共に再生開始するなどしてもよい。
　なお、通信側がコンテンツをＲＴＰなどによりマルチキャスト、あるいは、ブロードキャストする場合には、そのコンテンツがライブコンテンツであるかどうかに関わらず、現在時刻よりも後のデータは取得できない。従って、通信側のデータがマルチキャストやブロードキャストであるかどうかを示す情報も属性情報に含めるとしてもよい。
　［受信装置］
　次に、放送がＴＳを用いて送信され、通信がＤＡＳＨやＲＴＰ（Ｒｅａｌ－ｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）などを用いて送信される場合の受信装置の構成の一例について説明する。
　図８は、実施の形態１の変形例１における受信装置の構成の一例を示すブロック図である。図８では図７Ｂで説明した受信方法を実現する受信装置の構成の一例が示されている。
　図８に示す受信装置３００は、識別情報取得部３０１と、決定部３０２と、通信併用判定部３０３と、Ｌｏｃ情報取得部３０４と、放送受信部３０５と、通信受信部３０６とを備える。なお、図７Ａを実現する受信方法を実現する受信装置の構成は、図８で、Ｌｏｃ情報取得部３０４がない場合に対応する。
　識別情報取得部３０１は、図７Ｂに示すステップＳ３０１を実現する機能を備える。具体的には、識別情報取得部３０１は、エントリポイントとなる伝送路において送信されるサービス情報を取得し、その中に含まれる伝送路識別デスクリプタ（補助情報）を取得する。そして、識別情報取得部３０１は、伝送路識別デスクリプタの情報を解釈する。
　決定部３０２は、図７Ｂに示すステップＳ３０２を実現する機能を備え、端末の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するデータを決定する。
　通信併用判定部３０３は、図７Ｂに示すステップＳ３０３を実現する機能を備え、通信により送信されるデータを受信するかどうかを決定（判定）する。
　Ｌｏｃ情報取得部３０４は、図７Ｂに示すステップＳ３０４を実現する機能を備え、通信側データのロケーションデータを取得する。
　（変形例２）
　本変形例では、属性情報やロケーション情報が放送のプログラム情報に格納されて送信される場合の受信方法の一例について説明する。
　［受信方法］
　図９は、実施の形態１の変形例２の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。図９には、属性情報やロケーション情報が放送のプログラム情報に格納されて送信される場合に受信装置が放送コンテンツと通信コンテンツとを同期再生するかどうかを判定して再生するまでの動作例について示されている。
　なお、図９の動作は、図７Ａにおける動作に基づいているが、送信データをＭＭＴのアセットとせずに、より一般的なコンテンツとした場合の例として記載している。
　まず、エントリポイントとなる伝送路において送信されるプログラム情報を取得して、その中に含まれる伝送路識別デスクリプタを取得し、コンテンツの属性情報や通信コンテンツのロケーション情報を取得する（ステップＳ４０１）。
　ここで、ロケーション情報の実体がプログラム情報に格納されない場合には、図７Ｂで説明したのと同様の方法によりロケーション情報の実体データを取得する。
　次に、受信装置の再生能力、あるいは、通信路が利用可能かどうかなどに基づいて、受信するデータを決定する（ステップＳ４０２）。
　次に、通信コンテンツを取得するかどうかを決定し（ステップＳ４０３）、通信コンテンツを取得すると決定した場合には（Ｓ４０３ではい）、ステップＳ４０４に進み、放送と通信の両伝送路からデータを受信する。なお、受信しないと決定（判定）した場合（Ｓ４０３でいいえ）には、ステップＳ４０９に進み、放送のみからデータを受信して、ステップＳ４１０で放送コンテンツのみを再生する。
　次に、放送コンテンツと通信コンテンツを同期再生するかどうかを判定する（ステップＳ４０５）。
　同期再生すると決定した場合には（Ｓ４０５ではい）、ステップＳ４０６において放送コンテンツと通信コンテンツとの基準クロックを同期させて、ステップＳ４０７において両者を同期再生する。
　なお、Ｓ４０６における基準クロックの同期は、Ｓ４０４に先立って実施するとしてもよい。これは、コンテンツの受信データをプリバッファリングしてから再生開始する場合などでは、放送コンテンツにおいてＰＴＳがＴ１となるデータと、通信コンテンツにおいてＰＴＳがＴ１となるデータ（ここで、互いのＰＴＳは既に同期されているものとする）が受信済みとなることを確認して復号、再生を開始することがあり、互いに同期再生されるデータが揃っているかどうかを判定する際に、両者の基準クロックが同期済みであることが必要となるためである。
　また、Ｓ４０６における基準クロックの同期においては、放送、あるいは、通信のいずれかで使用されている基準クロックに揃えることができる。例えば、放送においてＰＣＲ（Ｐｒｏｇｒａｍ　Ｃｌｏｃｋ　Ｒｅｆｅｒｅｎｃｅ）が用いられ、通信においてＮＴＰ（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）が用いられる場合には、ビデオやオーディオにおけるＮＴＰ基準でのＤＴＳやＰＴＳを、ＰＣＲ基準に変換することで、放送と通信とにおける基準クロックを同期できる。また、受信装置内で使用される固有のクロックと同期するように、放送と通信とのＤＴＳやＰＴＳを変換してもよい。
　また、複数のコンポーネントの基準クロック情報が同じかどうかを示す情報を属性情報に含まれており、属性情報により基準クロック情報が異なることを受信側で取得できる場合には、上記の方法を用いて放送と通信とにおける基準クロックを同期するとしてもよい。
　なお、図９では、属性情報やロケーション情報が放送のプログラム情報に格納されて送信される場合の動作について説明したが、そもそも同期再生される必要がなければ、これらの情報を記述した伝送路識別デスクリプタが放送のプログラム情報に格納されないとしてもよい。
　また、本変形例では、属性情報やロケーション情報が放送のプログラム情報に格納される場合に同期再生されると説明したがそれに限らない。プログラム情報に、伝送路識別デスクリプタが含まれている場合には、伝送路識別デスクリプタにロケーション情報が記述されているストリームと、放送ストリームとを、受信装置は同期再生を行うとしてもよい。このとき、伝送路識別デスクリプタには、放送と通信により伝送されるストリームが互いに同期再生されるかどうかを示す属性情報は含めなくてもよい。
　換言すると、本変形例における受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含むとしてもよい。
　［受信装置］
　図１０は、実施の形態１の変形例２における受信装置の構成の一例を示すブロック図である。図１０では、図９で説明した受信方法を実現する受信装置の構成の一例が示されている。
　図１０に示す受信装置４００は、識別情報取得部４０１と、決定部４０２と、通信併用判定部４０３と、Ｌｏｃ情報取得部４０４と、放送受信部４０５と、通信受信部４０６と、同期判定部４０７と、再生部４０８とを備える。
　識別情報取得部４０１～通信受信部４０６は、図８で説明した識別情報取得部３０１～通信受信部３０６と同様であるので説明を省略する。
　同期判定部４０７は、図９に示すステップＳ４０５の処理を行う機能を備える。
　再生部４０８は、通信併用判定部４０３、及び、同期判定部４０７手段における判定結果により決定された再生方法に基づいて、放送コンテンツあるいは通信コンテンツを復号して、再生する。
　（変形例３）
　以下では、上記で説明したものと異なるものをその他の例として説明する。
　［その他１］
　伝送路は、放送と通信との組合せに限定されるものではなく、放送と放送、通信と通信など同種の伝送路の組合せであってもよい。
　また、伝送路識別デスクリプタのようなパッケージ単位の情報が示されない場合には、図１Ａおよび図１Ｂに示したようなアセット毎のロケーション情報を解釈することで、各アセットが放送と通信とのどちらにより送信されるか、あるいは、パッケージ内に通信により送信されるアセットが存在するかどうかなどを決定してもよい。
　（ロケーション情報）
　ロケーション情報においては、アセットの取得先のＵＲＬ情報などを含むとしてもよい。取得先がＵＲＬである場合には、当該ＵＲＬが、放送サービスにおいて予め規定された特定のＵＲＬであるかどうかに基づいて、アセットが放送、通信のどちらで送信されるかを決定できる。
　例えばＭＰＴなどのメッセージ情報と同一のストリームにおいて放送アセットが送信される場合には、ロケーション情報において、放送アセットの取得先として、アセットのデータを格納するパケットのＩＤ（ＭＭＴパケットの場合はｐａｃｋｅｔ＿ｉｄ）が示され、通信により送信されるアセットについては、取得先としてＵＲＬが示される。従って、ロケーション情報において、取得先がＵＲＬであるかどうかに応じて、アセットが通信により送信されるかどうかを決定してもよい。
　（ＭＰＴの記述の変形例）
　上記図１Ａおよび図１Ｂにおいては、アセット毎の情報として、アセット毎のロケーション情報、及び、個別の伝送路識別デスクリプタを定義した場合を説明したが、それに限らない。アセットの符号化方式を示すフィールドを別途設けてもよい。符号化方式は復号時に必須の情報であり、ＭＰＴのように復号に先立って取得できる情報においてシグナリングすることが望ましい。例えば、ＭＰＥＧ－２システムにおけるｓｔｒｅａｍ＿ｔｙｐｅのような情報を用いることが可能である。
　また、スケーラブルな符号化が可能な符号化方式である場合には、符号化方式と共に、当該アセットが基本レイヤであるか、拡張レイヤであるかを示してもよい。
　また、同一ＭＭＴパッケージにおいて、時間スケーラビリティを有するビデオが２つ存在する場合など、スケーラビリティを有するアセットが複数含まれるケースもある。このとき、拡張レイヤのアセットが、どの基本レイヤのアセットと対応するかを示す情報を示してもよい。例えば、拡張レイヤのアセットに対しては、対応する基本レイヤのアセットのアセットＩＤを示してもよい。また、拡張レイヤと基本レイヤのアセットをグループ化して、各アセットに対してグループのＩＤを割り振ってもよい。
　これらの情報は、放送はＴＳを利用し、通信はＤＡＳＨやＲＴＰなどを利用する場合でも、放送におけるプログラム情報などにおいて示すことができる。例えば、ＰＭＴのデスクリプタ等において、放送で送信されるビデオストリームと通信で送信されるビデオストリームとの間の依存関係（通信側のビデオストリームが拡張レイヤに相当するなど）、あるいは、通信側のビデオやオーディオの符号化方式を示す情報を記述できる。また、放送側のストリームと通信側のストリームとが同期再生されるかどうかなどを示してもよい。
　（伝送路に関する情報）
　コンテンツのデータが放送のみで送信されるか、あるいは、放送と通信を併用して送信されるかなどを示す情報は、ＥＰＧなどの番組情報に格納してもよい。
　例えば、ＥＰＧから視聴選択、あるいは、録画予約を行う場合に、通信ネットワークに接続していない、あるいは、受信装置が通信によるデータの取得に対応していないなど、通信により送信されるデータが再生、あるいは、録画できない場合には、その旨を示すメッセージ情報を表示してもよい。
　さらに、通信により送信されるデータが、番組の開始時刻に先立って取得可能であるかどうかを示す情報を格納してもよい。特に、ＤＡＳＨなどダウンロード型の方式では、番組開始に先立って通信側のデータをダウンロードしておくことで、番組開始時刻において、放送のデータと通信のデータを共に再生開始することができる。
　例えば通信側のデータが番組開始時刻に先立って取得可能である場合には、受信装置は、番組開始時刻よりも前に通信側のデータを受信開始するとしてもよい。このとき、予め定めたバッファリングのデータ量、あるいは、バッファリング時間分のデータが番組開始時刻において受信できるように、受信開始時刻を決定する。
　また、例えば、番組の予約録画などにおいても同様に動作してもよい。
　なお、放送などでは、ユーザーが複数の番組を任意のタイミングで選択可能であり、視聴中のチャネルの次番組の通信データを予め受信しても、視聴番組の切替えが発生すると、通信データを予め受信してもメリットが得られない。そこで、任意の視聴時刻において、当該視聴時刻よりも後に視聴可能であって、放送と通信を併用してデータが送信される全ての番組について、通信側のデータを予めバッファリングしておくように動作してもよい。全ての番組のデータを受信できない場合には、受信可能な範囲内で番組を選択し、受信してもよい。
　また、放送側のデータと通信側のデータが同期再生されるかどうかを示す情報もＥＰＧなどの番組情報に含めておいて、同期再生される場合には、通信側のデータを予めバッファリングするように動作してもよい。同期再生されない場合は、放送側のデータの受信開始後に通信側のデータを受信開始してもよい。
　なお、ＥＰＧにこのような情報が含まれない場合でも、ＭＭＴにおけるＭＰＴ、あるいは、放送にＴＳを用いる際のＰＭＴなどを解析して同様の情報を取得して、同様のメッセージを表示できる。
　また、日本における放送方式（ＩＳＤＢ－Ｔ）におけるＴＭＣＣ信号など、伝送路で伝送される信号を復調する際の制御情報において、これらの情報を格納してもよい。
　こうすることで、通信における受信が必要かどうかを、復調時に判定でき、通信側の起動を早めることができる。
　（フォーマット）
　なお、ＨＴＴＰベースのファイルフォーマットはＤＡＳＨに限定されるものではなく、ＨＴＴＰ　Ｌｉｖｅ　Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）やＭｉｃｒｏｓｏｆｔ　Ｓｍｏｏｔｈ　Ｓｔｒｅａｍｉｎｇ（ＭＳＳ）などであってもよく、これらの方式においても、ＭＰＤに相当するコンテンツ管理情報が存在するため、ＤＡＳＨと同様の仕組みにより放送側のデータと通信側のデータとの関係を示すことができる。
　また、通信側においても、ＴＳのストリームを用いてもよいし、ＴＳパケットの先頭に４バイトのタイムスタンプを示すフィールドを追加したフォーマットであってもよい。ここでタイムスタンプ付のＴＳはＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）や、ＩＰＴＶフォーラムなど多くの規格において使用されるものである。
　［その他２］
　（属性情報とロケーション情報）
　属性情報やロケーション情報において、コンテンツ全体の属性と、オーディオやビデオなどのストリームの個別の属性とを分けて格納してもよい。
　例えば、通信側においてＤＡＳＨを用いる場合は、放送コンテンツと通信コンテンツとが同期再生されるか、あるいは、放送コンテンツがスケーラビリティの基本レイヤで、通信コンテンツが拡張レイヤであるかなど、コンテンツ全体の属性情報を伝送路識別デスクリプタなどに格納するとしてもよい。一方、互いに同期再生の対象となるビデオやオーディオを識別するための情報など、ストリーム毎の個別の属をＭＰＤに格納するとしてもよい。
　ストリーム毎の属性例として、放送におけるビデオと、通信において送信される副音声のオーディオを関連付ける場合には、ＭＰＤにおいて、ビデオを格納するＴＳパケットのＰＩＤと、オーディオのトラックＩＤなどＤＡＳＨのデータ内においてオーディオのトラックやセグメント、あるいは、Ａｄａｐｔａｔｉｏｎ　ＳｅｔやＲｅｐｒｅｓｅｎｔａｔｉｏｎを識別するための情報を互いに関連付けるとしてもよい。ここで、放送側のメディアの識別情報としては、ＰＩＤの他に、当該ＰＩＤのＴＳパケットを含むトランスポートストリームのＩＤや、サービスＩＤなどを含んでもよい。
　なお、ＭＰＤの内容は更新されることがあり、更新情報はＤＡＳＨコンテンツの配信サーバが管理する。そのため、特にストリームの個別属性についてはＭＰＤにおいて記述することにより、放送コンテンツの送出装置と通信コンテンツの送出サーバとの間における情報の交換を低減できるというメリットと、全体属性はＰＭＴなど放送受信開始時に取得する情報に格納することで通信コンテンツの受信開始処理を迅速に起動できるメリットとを両立できる。
　また、全体属性と個別属性の両方を、放送におけるＰＭＴなどのデスクリプタ、あるいは、ＭＰＤのどちらか一方において記述してもよいし、両方において記述してもよい。例えば放送においては、ＡＩＴなどのアプリケーション制御情報の記述子において記述してもよい。
　（属性情報）
　さらに、放送や通信など異なる伝送路において送信されるストリームのクロック情報が互いに同期されているかどうかを示す情報を同期する方法、あるいは同期するための方法を属性情報に含めてもよい。この場合、受信装置は、本情報に基づいてクロック同期を行うとしてもよい。
　例えば、下記の３つの方法を識別するための情報を属性情報として記述してもよい。
　方法１）同期対象となるストリームは共通のクロックに基づいており、互いのクロックの同期は不要である。
　方法２）ＰＭＴ内のデスクリプタのように、ストリームとは別途送信されるクロック同期用の情報に基づいて同期する。
　方法３）現在ＭＰＥＧで規格化中であるＴＳのタイムライン拡張（１３８１８－１：２０１３／ＡＭＤ６（２ｎｄ　ＷＤ））のように、クロック同期のための情報を含む独立したストリームを参照して同期する。
　なお、方法３においては、クロック同期用のストリームを格納するＴＳパケットのＰＩＤを属性情報に含めてもよい。
　（変形例４）
　例えば図６Ａ～図７Ｂなどにおいて、放送はＴＳを用いて、通信はＤＡＳＨやＲＴＰなどを用いてそれぞれ送信するケースにおけるロケーション情報などの格納方法については説明した。
　本変形例では、ロケーション情報の格納方法について具体的な例をあげて説明する。
　図１１は、実施の形態１の変形例４の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。図１１には、ＭＰＤなどのロケーション情報を示すデスクリプタ（ロケーション情報デスクリプタ）の例が示されている。なお、ロケーション情報は、上述した伝送路識別デスクリプタに含めてもよい。そのため、ロケーション情報デスクリプタは伝送路識別デスクリプタに相当するとして考えてもよい。
　本変形例において、デスクリプタは、ＰＭＴ、あるいは、ＰＭＴとは異なるセクションデータなどに格納される。
　このデスクリプタにより示される情報としては、ロケーション情報により参照される実体データの種別を示す伝送フォーマット、ロケーション情報、及び、放送におけるＰＣＲと通信側のデータとの同期情報を示すフィールドが含まれる。
　なお、本変形例においてロケーション情報は、ロケーション情報の実体データの参照先を示すものとする。ここでは、ロケーション情報の実体データがＭＰＤである場合の例を示しており、伝送フォーマットとしてはＭＰＤが示され、同期情報としては、ＰＣＲとＮＴＰとの同期情報が示される。
　ＭＰＤは、ＤＡＳＨにおいて使用されるロケーション情報であるため、伝送フォーマットとしてはＤＡＳＨを示し、ロケーションとしてＭＰＤの参照先を示すことにしてもよい。ロケーション情報のＵＲＬにおける拡張子などにより伝送フォーマットを識別できる場合などにおいては、伝送フォーマットのフィールドを含めなくてもよい。また、ＭＰＤは放送内で送信する場合と、通信ネットワーク経由で送信する場合の２通りがあり、放送内で送信する場合には、ＭＰＥＧ－２　ＴＳのプライベートセクションなどを用いる。従って、ＭＰＤのロケーション情報としては、放送内で送信する場合にはプライベートセクションのＰＩＤなど、トランスポートストリーム内でＭＰＤを格納するＴＳパケットの識別情報を示し、通信ネットワーク経由で送信する場合にはＵＲＬなどの情報を示すことができる。
　［受信方法］
　以下、本変形例における受信方法として、ロケーション情報を示すデスクリプタを解析して放送と通信コンテンツとを同期再生する場合の受信装置の動作の一例について説明する。
　図１２は、実施の形態１の変形例４の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。
　まず、ステップＳ８０１において、ＰＭＴなどに格納されるロケーション情報デスクリプタを解析する。
　次に、ステップＳ８０２において、放送内にＭＰＤが存在するかどうかを判定する。放送内に存在する（放送によりＭＰＤが送信される）場合には（Ｓ８０２ではい）、ステップＳ８０３に進み、ロケーション情報により示されるＰＩＤを持つＴＳパケットからＭＰＤの実体データを取得する。一方、放送内にＭＰＤが存在しない場合には（Ｓ８０２でいいえ）、ロケーション情報において示されるＵＲＬなどに基づいて通信サーバからＭＰＤを取得する。
　次に、ステップＳ８０５では、ＭＰＤの解析結果に基づいて、ＤＡＳＨコンテンツの中から取得するデータを決定し、ダウンロード（またはプログレッシブダウンロードなど）により当該データを取得する。
　次に、ステップＳ８０６において、ロケーション情報デスクリプタに含まれる同期情報、あるいは、ＭＰＥＧ－２　ＴＳのタイムライン拡張が使用される場合にはタイムライン拡張情報を格納するＴＳパケットから取得した同期情報に基づいて、放送コンテンツと通信コンテンツとを同期再生する。
　なお、タイムライン拡張を用いる場合には、ロケーション情報デスクリプタには同期情報を含めなくてもよい。また、ＤＡＳＨコンテンツと放送コンテンツとを同期再生する必要がない場合には、同期情報は送信しなくてもよい。この場合、ロケーション情報デスクリプタの同期情報、あるいは、タイムライン拡張用のデータにおける同期情報が存在するかどうかに基づいて、両者の同期再生が必要かどうかを判定してもよい。同期再生が必要かどうかは、別途示してもよい。
　また、同期再生が必要でない場合には、ステップＳ８０６では、ユーザーの指示、あるいは、ハイブリッドキャストのアプリケーションにおける制御コマンドなどに基づいて、ＤＡＳＨコンテンツの再生開始と終了とを決定できる。なお、この場合、通信によるデータを取得するかどうかは、Ｓ８０１の前段において決定しているものとする。
　図１２では、ＭＰＤを取得してＤＡＳＨコンテンツを再生する例について説明したが、ＲＴＰやＴＳなど他の方式のデータを取得して再生する場合も同様である。
　なお、タイムライン拡張においては、タイムライン拡張情報を格納するアクセスユニットを定義し、アクセスユニット内に、ロケーション情報を示すデスクリプタと同期情報を示すデスクリプタの両方を格納することができる。
　従って、ロケーション情報デスクリプタを送信せずに、タイムライン拡張によりロケーション情報と同期情報を共に示してもよい。現状のタイムライン拡張においては、ロケーション情報としてＰＩＤを示すことができないため、ロケーション情報のスキームタイプを示すフィールドを拡張し、ＰＩＤをシグナリングできるようにしてもよい。
　また、ＰＭＴのセクションサイズの上限は１０２１バイトに制限されており、ロケーション情報におけるＵＲＬによっては、上限を超えることがある。ＰＭＴセクションを分割して格納することも可能であるが、特にＰＭＴは１つのセクションに格納されることが望ましい。
　従って、ＰＭＴのセクションサイズが１０２１バイトを超える場合には、ロケーション情報デスクリプタをＰＭＴとは異なるセクションにより送信してもよい。なお、ロケーション情報がＰＩＤを示す場合には、ＰＭＴのサイズ上限以内に収めることが可能であり、ＰＭＴに含めることができるため、ロケーション情報がＰＩＤ、ＵＲＬのどちらであるかに基づいて、ロケーション情報を格納するセクションを切替えてもよい。
　（変形例５）
　変形例４において、タイムライン拡張におけるＴＥＭＩ（Ｔｉｍｅｌｉｎｅ　ａｎｄ　Ｅｘｔｅｎｄ　Ｍｅｄｉａ　Ｉｎｆｏｒｍａｔｉｏｎ　ｓｔｒｅａｍ）アクセスユニットにおいてもロケーション情報を示すことができることを述べた。
　具体的には、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒを用いて通信側のコンテンツのＵＲＬなどを記述できる。Ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒにおいては、複数コンテンツのＵＲＬを記述できると共に、ＰＭＴのセクションサイズのようなデータサイズの制約も存在しないことから、ＵＲＬの記述に関して柔軟な運用が可能となる。
　一方で、ロケーション情報としてトランスポートストリーム内のＴＳパケットのＰＩＤを示す場合などでは、ロケーション情報のデータサイズも小さく、ロケーション情報デスクリプタを参照してＰＭＴの解析時にロケーション情報を取得することで、取得に係る遅延時間を低減できる。そのため、ロケーション情報の格納場所としては、ロケーション情報デスクリプタとＴＥＭＩアクセスユニット内のｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒを併用できることが望ましい。
　以下、本変形例におけるロケーション情報デスクリプタのシンタックス（データ構造）の一例について説明する。
　図１３Ａは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１３Ａには、ロケーション情報をロケーション情報デスクリプタ、あるいは、ＴＥＭＩアクセスユニットのいずれかに格納するためのロケーション情報デスクリプタのシンタックス例が示されている。
　本変形例では、ＰＣＲとの同期情報はＴＥＭＩアクセスユニットのｔｅｍｉ＿ｔｉｍｅｌｉｎｅ＿ｄｅｓｃｒｉｐｔｏｒを用いて記述されることとし、ロケーション情報デスクリプタには含めていないとして説明する。図１３Ａに示すフィールド毎のセマンティクスについて説明する。
　「ｄａｔａ＿ｆｏｒｍａｔ」は、図１１に示す伝送フォーマットと同様である。つまり、ＤＡＳＨにおけるＭＰＤ、ＩＰＴＶフォーラムのＶＯＤ（Ｖｉｄｅｏ　Ｏｎ　Ｄｅｍａｎｄ）仕様における再生制御メタファイル、あるいは、ＩＰＴＶフォーラムなどにおいて規定されるＴＴＳ（Ｔｉｍｅ－ｓｔａｍｐ　ＴＳ）など、サービスで使用する再生制御のメタ情報のフォーマットを示す。ＴＴＳやＭＰ４ファイル、あるいは、ＡＶの符号化データそのものなど、メタ情報ではなく、ストリーム自体の識別情報を示してもよい。ＭＭＴにおけるＭＰＴ、ＰＡメッセージやＭＭＴパケット、アセットなどを示してもよい。
　例えば、Ｈ．２６５などの動画符号化方式において時間スケーラビリティを実現することができる。ここで、放送で６０ｆｐｓの基本レイヤを送信し、通信において６０ｆｐｓから１２０ｆｐｓにフレームレートを向上させるための拡張レイヤの符号化データを送信するとする。この場合、通信コンテンツのロケーション情報としては、拡張レイヤの符号化ストリームのＵＲＬのみを示せばよい。符号化ストリームにおける解像度や符号化方式などの情報は、基本レイヤを送信する放送データにおいて取得することが可能である。
　「ｌｏｃａｔｉｏｎ＿ｔｙｐｅ」は、ロケーション情報が、放送におけるＴＳのＰＩＤ、あるいは、通信におけるＵＲＬにより示されるかを識別するためのものである。ここでは、ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝０である場合に放送におけるＴＳのＰＩＤを示すものとする。なお、ロケーション情報デスクリプタは、例えば、ＭＰＥＧのＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）などＴＳ以外においても使用可能である。ＴＳ以外のフォーマットにおいては、「ｌｏｃａｔｉｏｎ＿ｔｙｐｅ」を用いなくてもよい。例えば、ＭＭＴにおけるＭＭＴパケットのｐａｃｋｅｔ＿ｉｄなどロケーションを識別するための他の情報を用いてもよい。
　「ＰＩＤ」は、ＴＳパケットのＰＩＤを示す。放送が複数のトランスポートストリームから構成される場合には、トランスポートストリームの識別番号などを合わせて格納してもよい。
　「ｕｒｌ＿ｌｏｃａｔｉｏｎ」は、通信コンテンツのＵＲＬが、ロケーション情報デスクリプタ内、あるいは、ＴＥＭＩアクセスユニットのどちらに格納されるかを示す。本変形例では、ｕｒｌ＿ｌｏｃａｔｉｏｎ＝０である場合に、ロケーション情報デスクリプタに格納されるものとする。ｕｒｌ＿ｌｏｃａｔｉｏｎが１である場合には、通信コンテンツのＵＲＬはＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに格納される。
　「ｕｒｌ＿ｌｅｎｇｔｈ」は、「ｕｒｌ＿ｐａｔｈ」のバイト長を示す。「ｕｒｌ＿ｐａｔｈ」は、ＵＲＬのデータを示す。
　図１３Ｂは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１３Ｂには、図１３Ａで示したロケーション情報デスクリプタのシンタックスとは別の例が示されている。図１３Ａに示すシンタックスとの違いは、ロケーション情報をＴＥＭＩアクセスユニットに格納する場合には、ｄａｔａ＿ｆｏｒｍａｔフィールドが存在しないという点である。
　ここで、Ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒは、ｓｅｒｖｉｃｅ＿ｔｙｐｅと呼ばれるフィールドにおいてＴＥＭＩのサービスタイプを示すことができる。このサービスタイプがｄａｔａ＿ｆｏｒｍａｔに相当する。従って、ｄａｔａ＿ｆｏｒｍａｔの情報は、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドにおいて示すこととする。
　なお、図１３Ａに示すシンタックスでは、ｄａｔａ＿ｆｏｒｍａｔフィールドと、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ＿ｔｙｐｅとが共に存在することがある。この場合、両者は同一の情報を示すものとする。
　ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒでは、ｓｅｒｖｉｃｅ＿ｔｙｐｅをシグナリングせずに通信コンテンツのＵＲＬのみを示すことも可能である。従って、図１３Ａのシンタックスを用いる場合には、伝送フォーマットとしてはロケーション情報デスクリプタのｄａｔａ＿ｆｏｒｍａｔを参照し、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒのｓｅｒｖｉｃｅ＿ｔｙｐｅはシグナリングしないこととしてもよい。
　図１３Ｃは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１３Ｃには、図１３Ａおよび図１３Ｂで示したロケーション情報デスクリプタのシンタックスとは別の例が示されている。
　図１３Ａとの違いは、初めにｕｒｌ＿ｌｏｃａｔｉｏｎの条件分岐をしている点にある。つまり、ｕｒｌ＿ｌｏｃａｔｉｏｎ＝０でロケーション情報がロケーション情報デスクリプ内にある場合は、ｌｏｃａｔｉｏｎ＿ｔｙｐｅに応じて放送のＴＳのＰＩＤや通信ＵＲＬが格納される。一方、ｕｒｌ＿ｌｏｃａｔｉｏｎ＝１の場合は、ｌｏｃａｔｉｏｎ＿ｔｙｐｅはロケーション情報デスクリプタ内には記述されず、ＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ内に、ｓｅｒｖｉｃｅ＿ｔｙｐｅフィールドにおいてｌｏｃａｔｉｏｎ＿ｔｙｐｅを示し、ｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに放送におけるＴＳのＰＩＤ或いは通信ＵＲＬを格納する。
　図１３Ｄは、実施の形態１の変形例４におけるロケーション情報デスクリプタのシンタックスの一例を示す図である。図１３Ｄには、図１３Ａ～図１３Ｃで示したロケーション情報デスクリプタのシンタックスとは別の例が示されている。
　図１３Ａとの違いは、ｕｒｌ＿ｌｏｃａｔｉｏｎとｌｏｃａｔｉｏｎ＿ｔｙｐｅとを統合した点である。ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝０である場合は放送のＰＩＤを示し、ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝１の場合は通信のＵＲＬを示す。また、ｌｏｃａｔｉｏｎ＿ｔｙｐｅ＝２の場合はＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに、放送におけるＴＳのＰＩＤ或いは通信ＵＲＬが格納されることを示す。
　なお、ロケーション情報デスクリプタのシンタックスのデータやデータ構造は、上述の例に限るものではない。例えばロケーションタイプとフォーマットタイプとを統合して示すなど、他のデータと組み合わせて用いてもよい。また、例えばロケーション情報のＵＲＬにおける拡張子などにより伝送フォーマットを識別できる場合などにおいては、伝送フォーマットのフィールドを含めなくてもよい。また、例えばロケーション情報デスクリプタが存在しなければ、ロケーション情報がｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒにより示されることとして、ｕｒｌ＿ｌｏｃａｔｉｏｎのフィールドを省略してもよい。
　（変形例６）
　以下、変形例５で説明したロケーション情報とは別の例について説明する。
　（ロケーション情報のその他の例）
　例えば、同一プログラム内に２種類以上の複数のタイムラインが存在する場合、タイムラインの種類毎に複数のＴＥＭＩストリームを含む場合がある。
　この場合、ロケーション情報デスクリプタに複数のロケーション情報を格納してもよい。複数のロケーション情報を格納する場合には、ロケーション情報デスクリプタ内にＴＥＭＩストリームの数のループを作成し、それぞれのＴＥＭＩストリームに対応するロケーション情報を格納する。また、ロケーション情報デスクリプタにおける複数のロケーション情報ループと複数のＴＥＭＩストリームとの対応関係を示す方法として、例えばロケーション情報のループの順番と、ＴＥＭＩストリームを示すＥＳループ（ＰＭＴ第２ループ）の順番が一致するものが対応関係にあるなどとしてもよい。また、２種類以上のタイムラインが存在する場合には、ロケーション情報はロケーション情報デスクリプタに格納せず、ＴＥＭＩアクセスユニットのｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに格納するとしてもよいし、ロケーション情報デスクリプタをＥＳループ（ＰＭＴ第２ループ）に格納してもよい。
　（ロケーション情報の更新）
　なお、メタ情報などのロケーション情報の内容の更新にも対応できることが望ましい。
　例えば、ＰＭＴ内のロケーション情報デスクリプタにｒｅｌｏａｄフラグを追加し、ロケーション情報の内容を更新する場合にはｒｅｌｏａｄ＝１とし、受信装置はｒｅｌｏａｄ＝１である場合にはロケーション情報の内容が更新されたとして、ロケーション情報に格納されているＰＩＤやＵＲＬなどを再取得してもよい。ＰＩＤやＵＲＬなどのロケーション情報は更新されておらず、データのみが更新されている場合は、データのみを再取得してもよい。
　また、ロケーション情報自体、あるいは、ロケーション情報により取得先が示されるＭＰＤなどのデータの内容が更新されたかを示す情報を、それぞれ独立に示してもよい。
　また、周期的に送信されるＰＭＴ内のロケーション情報デスクリプタを逐次チェックしてもよい。しかし、この逐次チェックの処理は重たいため、ロケーション情報デスクリプタなどを格納するためのセクションデータや、更新されたことを通知するイベント用セクションなどを別途生成し、周期的に送信してもよい。
　受信装置では、セクションにおけるバージョン番号を確認すればロケーション情報が更新されたかどうかを判定できる。また、ロケーション情報を放送のセクションで送信する場合には、ロケーション情報のセクションのバージョン番号を更新することで、メタ情報の更新を示す。
　また、放送から取得したロケーション情報に基づいて通信側のデータを取得開始した後は、通信においてロケーション情報の更新内容を取得してもよい。
　［受信方法］
　次に、本変形例における受信方法として、ロケーション情報を示すデスクリプタを解析して放送と通信コンテンツとを同期再生する場合の受信装置の動作の一例について説明する。
　図１４は、実施の形態１の変形例６の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。
　図１２のステップＳ８０４が図１４ではステップＳ９０６、ステップＳ９０７，およびステップＳ９０８に変わっている。その他の動作（ステップＳ９０１～ステップＳ９０５）は、図１２の動作（ステップＳ８０１～ステップＳ８０３、ステップＳ８０５およびステップＳ８０６）と同様であるので説明を諸略する。
　ステップＳ９０６において、ＭＰＤなどの取得先ＵＲＬがロケーション情報デスクリプタ、あるいは、ＴＥＭＩアクセスユニットのどちらに格納されるかを判定する。ロケーション情報デスクリプタにある場合は（Ｓ９０６ではい）、ステップＳ９０７に進み、ロケーション情報デスクリプタを解析し、ロケーション情報に示されるＵＲＬに基づいて通信サーバからＭＰＤを取得する。一方、ステップＳ９０６において、ＴＥＭＩアクセスユニットに格納されていると判定された場合には（Ｓ９０６でいいえ）、ＴＥＭＩアクセスユニットにおけるｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに示されるＵＲＬに基づいて通信サーバからＭＰＤを取得する。
　なお、図１４では、フォーマット情報としてＭＰＤが示されている場合の例について示されているが、他のメタ情報であっても同様のフローの動作で放送コンテンツと通信コンテンツとを同期再生できる。
　図１５は、実施の形態１の変形例６の放送通信連携サービスにおける受信側の動作の別の一例を示すフローチャートである。図１５では、フォーマット情報がＭＰＤ以外の他のメタ情報である場合の動作の動作が示されている。より具体的には、フォーマット情報に、ＭＰＤのようなメタ情報ではなく、ストリームなどの実体データのフォーマットが示されている場合に、図１４に示すステップＳ９０７やステップＳ９０８においてメタ情報のＵＲＬの代わりにストリームの実体データのＵＲＬを取得する場合の動作が示されている。
　まず、ステップＳ１００１において、受信装置は、ロケーション情報デスクリプタを解析する。
　次に、フォーマットに示されるデータが放送内に存在するかどうかを判定する（ステップＳ１００２）。放送内にデータが存在する場合には（Ｓ１００２ではい）、ステップＳ１００３に進み、ロケーション情報に示されるＰＩＤを取得する。ここでは、ストリームなどの実体データを放送内に含むことを想定していないため、放送内にデータが存在する場合には、そのフォーマットはメタデータであることが確定する。
　次に、ＰＩＤに基づいて放送ストリームからメタ情報ファイルを取得し（ステップＳ１００４）、取得する通信データを決定する（ステップＳ１００５）。
　一方、ステップＳ１００２において通信にデータが存在する場合には（Ｓ１００２でいいえ）、ステップＳ１００８に進み、通信データのＵＲＬがロケーション情報デスクリプタに存在するか、ＴＥＭＩアクセスユニットのｔｅｍｉ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒに存在するかを判定する。そして、それぞれの場合に応じて、ステップＳ１００９またはステップＳ１０１０においてＵＲＬを取得する。
　ステップＳ１０１１では、フォーマットがメタ情報であるかの判定をする。フォーマットがメタ情報である場合には（Ｓ１０１１ではい）、ステップＳ１０１２に進み、ＵＲＬに基づいて通信ストリームからメタ情報を取得し、ステップＳ１００５に進み、取得する通信データを決定する。
　ステップＳｐ１００５において取得する通信データが決まった後や、ステップＳ１０１１においてフォーマットがメタ情報でないと判定された場合には、ステップＳ１００６に進み、通信データを取得する。
　最後に、ステップＳ１００７では、ロケーション情報デスクリプタに含まれる同期情報、あるいは、ＭＰＥＧ－２　ＴＳのタイムライン拡張により示される同期情報に基づいて、放送コンテンツと通信コンテンツを同期再生する。
　（変形例７）
　これまでは、放送コンテンツと通信コンテンツとが同期再生されるかどうかを判定して、同期再生される場合に、放送コンテンツと通信コンテンツとの取得や同期再生をするとして説明をしたが、これに限らない。
　本変形例では、放送により送信されるオーディオやビデオの基準クロック情報と、通信により送信されるオーディオやビデオの基準クロック情報とが、同じかどうかを示す情報がサービス情報（伝送識別デスクリプタ等）に含まれ、この情報に基づいた動作について説明する。
　［放送と通信との基準クロック（タイムライン）が同期しているかの情報］
　放送と通信とを用いたコンテンツをＭＭＴやＤＡＳＨ、ＲＴＰ、或いはハイブリッドキャストなどを用いて伝送する場合、放送により送信されるオーディオやビデオの基準クロック情報と、通信により送信されるオーディオやビデオの基準クロック情報とが、同じかどうかを示す情報を伝送識別デスクリプタやプログラム情報、ＥＰＧやＥＩＴなどに格納するとしてもよい。
　例えば、放送と通信とにより伝送されるコンテンツが、共通の基準クロックに基づいて動作（例えば、タイムスタンプの付与など）されている場合、共通の基準クロックに基づいて動作していることを示す情報を格納する。また、放送と通信とにより伝送されるコンテンツが異なる基準クロックに基づいて動作されている場合、異なる基準クロックに基づいて動作していることを示す情報を格納する。
　また、放送と通信とで異なる基準クロック情報を用いていることを示す場合のみ、基準クロック同期に必要な情報（例えば、タイムライン拡張情報など）を示すとしてもよい。また、基準クロック同期に必要な情報の格納場所や、基準クロック同期に必要な情報の種類、基準クロック同期の方法などを示してもよい。
　ここで、基準クロックの同期においては、放送または通信のいずれかで使用されている基準クロックに揃えることが可能である。
　例えば、放送においてＰＣＲ（Ｐｒｏｇｒａｍ　Ｃｌｏｃｋ　Ｒｅｆｅｒｅｎｃｅ）が用いられ、通信においてＮＴＰ（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）が用いられる場合、ビデオやオーディオにおけるＮＴＰ基準でのＤＴＳやＰＴＳを、ＰＣＲ基準に変換することで、放送と通信とにおける基準クロックを同期できるというように基準クロック同期の種類や方法を示してもよい。また、受信装置内で使用される固有のクロックと同期するように、放送と通信のＤＴＳやＰＴＳを変換するというように基準クロック同期の種類や方法を示ししてもよい。
　なお、基準クロック同期に必要な情報の種類や方法を示した識別情報を解析し、識別情報に基づいた方法で基準クロック同期をしてもよい。
　また、基準クロックが異なるストリームが複数ある場合、基準クロックが異なる基準クロックが複数あることを示す情報をデスクリプタに格納してもよい。デスクリプタを異なる基準クロックごとに示してもよいし、一つのデスクリプタで示してもよい。基準クロックと当該基準クロックを用いたプログラムとの対応関係を示す情報を格納してもよい。
　基準クロックが同じかどうかを示す情報としては、上記のようなデスクリプタとして示してもよいし、他のデスクリプタやテーブル、セクションなどを用いてもよい。また、クロック同期に必要な情報（例えば、タイムライン拡張情報など）が存在するかどうかによって示してもよい。クロック同期に必要な情報が存在すれば、クロック情報が異なるとしてもよい。あるいは、伝送識別デスクリプタなどに示された、通信コンテンツの属性情報（たとえば、フォーマットや種類に関する情報、あるいは、ロケーション情報やＵＲＬに記述された拡張子など）を用いて、クロック情報が異なるということを示してもよい。
　ハイブリッドキャストの場合は、ＡＩＴコントロールドセクションや、アプリケーションの中に格納してもよい。
　受信装置は、異なるクロック情報を用いていると判定した場合には、放送と通信の基準クロック情報を同期させる。また、共通のクロック情報を用いていると判定した場合、クロックの同期は不要と判断する。受信装置は、例えば、放送波によるコンテンツの基準クロックと通信路によるコンテンツの基準クロックとの差分情報を含む補助情報を受信し、かつ、放送波によるコンテンツの基準クロックおよび通信路によるコンテンツの基準クロックが異なる場合には、その差分情報に基づき通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させるとしてもよい。
　なお、受信装置は、伝送識別デスクリプタなどに格納された、データの基準クロック情報が同じかどうかの識別結果に加え、ユーザーインタフェースなどによるユーザーの選択やユーザー設定、コンテンツ提供者やサービス事業者、放送局の意図、または受信装置のスペックや仕様、受信機メーカーの意図など、すべてを勘案し、実際に放送コンテンツと通信コンテンツの基準クロック同期をするかどうかを判定してもよい。
　また、受信装置は、基準クロック同期をすると判定した場合に、実際にクロック同期をするタイミングとしては、判定後に同期開始してもよいし、判定をまたずに、同期に関する情報を取得した際に開始してもよい。あるいは、通信コンテンツの取得を開始する時間に合わせて同期してもよい（例えばコンテンツの取得を開始する一定時間前や、取得開始と同じ時間など）。
　また、参照元となる基準クロック（例えば、放送のＰＣＲ）のクロック再生が完了していない（ジッタ等の影響を平滑するなどしてクロックの使用ができる状態になっていない）場合は、参照元の基準クロック情報のクロック再生が完了した時点で、参照先とのクロックの同期を開始するとしてもよい。
　放送と通信との基準クロックが同期しているかの情報が、ＥＰＧによって示されている場合は、通信コンテンツのプロバッファリングと同様に、放送開始前に基準クロックの同期が必要かどうかの判定や基準クロックの同期を開始してもよい。このように、より早く基準クロックの同期を行うことで、より早く、サービスを視聴者に提供できる。
　なお、基準クロックが同じかどうかを示す情報は、放送と通信との組み合わせに限られるものではなく、同じ経路で伝送される場合や、放送や通信、蓄積フォーマットなど複数の経路から取得されるデータ中で、異なる基準クロック情報を用いていれば適用可能である。
　なお、本変形例で説明する機能や処理の一部または全部は、ハードウェアで実装してもよいし、ソフトウェアで実装してもよい。一部をハードウェアあるいはソフトウェアとして実装することもできる。
　例えば、ソフトウェアで実装する場合は、本変形例で説明した機能や処理を指示したり、受信機能の状態をＰＵＳＨで通知したり、ＰＵＬＬで取得する機能などをパッケージし、ＡＰＩ関数として提供してもよい。
　ＡＰＩ関数は、アプリケーションから実行できる。アプリケーションとして実装する場合は、レジデントアプリケーションで実装してもよいし、ＨＴＭＬ５などのアプリケーションも用いてもよい。上記ＡＰＩをアプリケーション間でのデータの受け渡し、状態の通知として実装してもよい。
　ここで、基準クロックが同期しているかの情報に関連するＡＰＩ関数の機能としては例えば下記の１）～９）のようなものがある。
１）放送コンテンツと通信コンテンツの基準クロック情報が同じかどうかの情報を取得する。
２）基準クロック同期が必要かどうかの情報を取得する。
３）それぞれの基準クロック情報の種類や同期方法を取得する。
４）クロック同期に必要な情報（タイムライン情報など）を取得する。
５）クロック同期に必要な情報の取得先を取得する。
６）参照元のクロック情報を引数とし、同期のとれた参照先のクロック情報を返す。例えば、同期がとれていない場合は、同期がとれていないことを示す値を返す。
７）互いの基準クロックの同期開始を指示する。
８）基準クロック同期がとれているかどうかの状態を取得する。
９）基準クロック同期がとれたことを通知する。
　［受信方法］
　以下、図を用いて、本変形例における受信方法として、属性情報やロケーション情報が放送のプログラム情報に格納される場合に、受信装置が放送コンテンツと通信コンテンツとを同期再生するかどうかを判定して動作するときの動作の一例について説明する。
　図１６は、実施の形態１の変形例７の放送通信連携サービスにおける受信側の動作の一例を示すフローチャートである。なお、図１６に示すフローチャートの動作は、ＭＭＴやＤＡＳＨ、ＲＴＰなどいかなる多重化方式の組み合わせを用いた放送通信連携サービスにも適用可能である。また、ハイブリッドキャストにも適用可能である。
　図１６では、放送コンテンツと通信コンテンツとが同期されることを前提としており、放送コンテンツと通信コンテンツとを同期するかどうかの判定は省略している。
　また、ステップＳ１１０１およびステップＳ１１０２は、図９のステップＳ４０１およびステップＳ４０２と同様の動作であるので、説明を省略する。
　次に、ステップＳ１１０３において、受信装置は通信コンテンツを取得するかどうかを決定する。通信コンテンツを取得すると決定した場合には（Ｓ１１０３ではい）、ステップＳ１１０４に進み、放送と通信の両伝送路からデータを受信し、続くステップＳ１１０５において、放送コンテンツと通信コンテンツとの基準クロックが同じか異なるかを判定する。
　ステップＳ１１０５において基準クロックが異なると判定した場合には（Ｓ１１０５ではい）、ステップＳ１１０６に進み、放送コンテンツと通信コンテンツとの基準クロックを同期させ、ステップＳ１１０７において両者を同期再生する。
　一方、ステップＳ１１０５において基準クロックが同じであると判定した場合には（Ｓ１１０５でいいえ）、基準クロックの同期をせずに、共通のクロックを用いて同期再生する。
　なお、ステップＳ１１０５の後に、基準クロックの同期が必要かどうかを判定する処理を行ってもよい。例えば、クロック同期の種類や方法によって、受信装置の能力がクロックの同期に対応するかどうか、あるいは、受信機の仕様としてクロック同期をするかどうか、あるいはユーザーがクロック同期をするかどうかなどを判定する。そして、ステップＳ１１０５と上記の判定結果によって、総合的に放送と通信とにおける基準クロックの同期をするかどうかを判定し、ステップＳ１１０６またはステップＳ１１０７に進むとしてもよい。
　また、ステップＳ１１０６における基準クロックの同期は、ステップＳ１１０４に先立って実施してもよい。これは、コンテンツの受信データをプリバッファリングしてから再生開始する場合など、放送コンテンツにおいてＰＴＳがＴ１となるデータと、通信コンテンツにおいてＰＴＳがＴ１となるデータ（ここで、互いのＰＴＳは既に同期されているものとする）が受信済みとなることを確認して復号、再生を開始することがあるからである。そして、互いに同期再生されるデータが揃っているかどうかを判定する際に、両者の基準クロックが同期済みであることが必要となるためである。
　また、ステップＳ１１０６において、クロック同期情報が取得できないなどによって、または、受信機の仕様によって、クロック同期ができない場合、放送と通信との連携したサービスをユーザーに提供できない場合がある。その場合には、同期させることが必須かどうか、同期させずに再生してもいか、などの判定をすることによって、ステップＳ１１０３の通信により送信されるデータを受信するかどうかを判定してもよい。
　なお、ステップＳ１１０３では、伝送路識別デスクリプタで識別できる情報の他にも、ユーザーの選択や設定、コンテンツ提供者やサービス事業者、放送局の意図、または受信装置のスペックや仕様、メーカーの意図など、すべてを勘案し、実際に通信により送信されるデータを受信するかどうかを決定してもよい。
　［受信装置］
　次に、図１６に示す動作を実現する受信装置の構成の一例について説明する。図１７は、実施の形態１の変形例７における受信装置の構成の一例を示すブロック図である。
　図１７に示す受信装置１１００は、識別情報取得部１１０１と、決定部１１０２と、通信併用判定部１１０３と、Ｌｏｃ情報取得部１１０４と、放送受信部１１０５と、通信受信部１１０６と、基準クロック判定部１１０７と、再生部１１０８とを備える。
　識別情報取得部１１０１～通信受信部１１０６は、図８で説明した識別情報取得部３０１～通信受信部３０６と同様であるので説明を省略する。
　基準クロック判定部１１０７は、図１６に示すステップＳ１１０５の処理を行う機能を備える。また、基準クロック判定部１１０７は、基準クロックが異なるかどうかを判定した上で、さらに、上述したような基準クロックの同期が必要かどうかを判定する処理を行うとしてもよい。
　再生部１１０８は、基準クロック判定部１１０７における判定結果により決定された方法に基づいて、基準クロックが異なる場合は基準クロックを同期した後に、放送コンテンツまたは通信コンテンツを復号して、再生する。
　なお、本変形例で説明した機能や受信装置の構成、受信方法は一例であり、これに限られるものでなく、同様の機能や効果が実現できるものであればよい。
　［実施の形態１の効果等］
　以上のように、本実施の形態によれば、通信によるコンテンツの受信開始タイミングが遅延しても受信側で放送と通信とを併用したコンテンツを再生可能なコンテンツの送信方法、受信方法、送信装置および受信装置を実現できる。
　具体的には、本実施の形態の一態様における送信方法は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に前記同期を取らせる補助情報を、少なくとも前記放送波を用いて送信する情報送信ステップを含む。
　これにより、放送波と通信路を用いてコンテンツを送信した場合には、放送波と通信路とを用いて送信したコンテンツ間との同期を取るための補助情報を送信するので、受信側が補助情報を受信したときには受信側にコンテンツ間の同期を取らせることができる。
　ここで、例えば、前記情報送信ステップでは、前記コンテンツを送信するのに先だって前記補助情報を送信し、前記補助情報には、さらに、前記コンテンツの取得先を示すロケーション情報または前記ロケーション情報の取得先を示す情報が含まれていてもよい。
　また、例えば、前記補助情報送信ステップでは、さらに、前記補助情報に、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含めて送信してもよい。
　また、例えば、前記補助情報送信ステップでは、前記補助情報を送信することにより、前記コンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記受信側に前記同期を取らせてもよい。
　また、例えば、前記送信方法では、前記コンテンツを、ＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）にしたがったフォーマットで生成する生成ステップと、前記コンテンツを、前記生成ステップで生成されたフォーマットで送信するコンテンツ送信ステップと、を含んでもよい。
　また、例えば、前記生成ステップでは、前記補助情報を、前記コンテンツの取得に関する情報であるメッセージ情報に含めて生成してもよい。
　また、本実施の形態の一態様における受信方法は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む。
　これにより、例えば放送波などエントリポイントとなる伝送路において送信されるサービス情報を取得し、その中に補助情報が含まれていた場合には、同期を取る処理を行うことができる。
　ここで、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記補助情報を受信し、前記補助情報に、前記コンテンツの取得先を示すロケーション情報が含まれている場合には、前記ロケーション情報に基づき前記コンテンツを取得することで、前記コンテンツを受信してもよい。
　また、例えば、前記受信ステップでは、前記コンテンツを受信するのに先だって前記補助情報を受信し、前記補助情報に、前記コンテンツの取得先を示すロケーション情報の取得先を示す情報が含まれている場合には、前記ロケーション情報の取得先を示す情報に基づき前記ロケーション情報を取得し、取得した前記ロケーション情報から前記コンテンツを取得することで、前記コンテンツを受信してもよい。
　また、例えば、前記再生ステップでは、前記受信ステップにおいて、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含む前記補助情報を受信し、かつ、前記放送波によるコンテンツの基準クロックおよび前記通信路によるコンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記コンテンツの同期を取る処理を行い、前記コンテンツを再生してもよい。
　また、本実施の形態の一態様における送信装置は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって、受信側が受信した場合に前記同期を取らせる補助情報を少なくとも前記放送波を用いて送信する情報送信部を備える。
　また、本実施の形態の一態様における受信装置は、放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える。
　また、以上のように、本実施の形態によれば、オーディオやビデオを含むコンテンツが、放送に加えて通信を併用して送信されるかどうかを示す識別情報、および、放送と通信を併用する際には、両伝送路において送信されるデータ間の依存関係などを示す情報を、コンテンツの管理情報として生成し、送信するとしてもよい。ここで、例えば、データ間の依存関係を示す情報は、両伝送路において送信されるデータが同期再生されるかどうかを含むとしてもよい。また、データ間の依存関係を示す情報は、両伝送路において送信されるデータのクロック情報が同じかどうかを含むとしてもよい。
　それにより、オーディオやビデオを含むコンテンツが送信される伝送路、および、異なる伝送路において送信されるデータ間の依存関係が、コンテンツの受信開始時に取得できるので、受信するアセットの決定や、通信コンテンツの取得開始に係る遅延時間が低減できる。
　また、本実施の形態によれば、通信において送信されるデータのロケーション情報を、コンテンツの管理情報に含めるとしてもよい。ここで、送信されるデータのロケーション情報は、例えば、ＭＰＥＧ－ＤＡＳＨにおけるＭＰＤであるとしてもよい。また、コンテンツ管理情報には、ＭＰＤなどのロケーション情報の実体データではなく、ロケーション情報の取得先を示す情報を格納してもよい。
　それにより、オーディオやビデオを含むコンテンツが送信される伝送路、および、異なる伝送路において送信されるデータ間の依存関係が、コンテンツの受信開始時に取得できるので、受信するアセットの決定や、通信コンテンツの取得開始に係る遅延時間が低減できる。
　また、本実施の形態によれば、受信装置においては、コンテンツの管理情報を解析して、コンテンツを受信する伝送路、および、各伝送路において受信するデータを決定するとしてもよい。例えば、両伝送路において送信されるデータのクロック情報が異なる場合は、データ間のクロック同期のために必要な補助情報を取得し、各データにおけるＤＴＳやＰＴＳを同期して、復号し、再生するとしてもよい。また、両伝送路において送信されるデータを同期再生する場合には、データ間のクロック同期のために必要な補助情報を取得して、各データにおけるＤＴＳやＰＴＳを同期して、復号し、再生するとしてもよい。
　それにより、放送データのみを受信する受信装置においては、従来の放送受信と同様の動作により放送データの再生を可能としつつ、通信データの再生に対応することができる。
　さらに、受信装置に対しては、放送と通信のデータを同期して再生するための仕組みを提供することができる。
　さらに、複数の伝送路で伝送されるデータのクロック間の同期がとれていない場合でも、クロック同期に必要な補助情報を取得することによりクロックの同期をし、データを同期再生できる。
　（実施の形態２）
　実施の形態１では、放送で送信するストリームと通信で送信するストリームとが同期再生の対象となるか、あるいは、両伝送路により送信されるストリーム間の依存関係などを示す情報を送信する際の送信方法、及び、それら情報を受信する受信方法等について説明した。
　ここで、選択可能なオーディオやビデオからユーザーが再生対象を選択する場合や、ビデオにおいて単一ビューの全画面表示からマルチビューに切替えるなど、ユーザー動作の介在を伴う柔軟なコンテンツ再生を受信装置において実現するには、アプリケーションにおいて再生制御を行うのが望ましい。
　アプリケーションとしては、広く普及しているＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）のブラウザに基づくものが主流である。アプリケーションがＨＴＭＬである場合、ＨＴＭＬを解釈することで再生制御を行うことができる。ＨＴＭＬであれば、コンテンツの選択や切替え、あるいは、レイアウトの変更などを柔軟に記述できるというメリットもある。
　例えば、ＩＰＴＶフォーラムにおいて規定されるハイブリッドキャストでは、ＴＳにおけるＰＭＴの記述子や、ＭＭＴにおけるＭＰＴの記述子など放送番組の受信開始時に必ず参照されるデータにおいて、ａｉｔ＿ｉｄｅｎｔｉｆｉｅｒ＿ｉｎｆｏ（）などアプリケーションが存在することを示す識別情報を送信する。ハイブリッドキャストに対応した受信装置においては、当該識別情報が存在する場合には、ＡＩＴなどのアプリケーション制御情報をＴＳにおけるセクションやデータカルーセル、ＭＭＴにおけるＭＭＴメッセージやデータカルーセルに相当する情報、あるいは、通信ネットワーク経由でダウンロードして取得する。その上で、アプリケーション制御情報に基づいて、ＨＴＭＬファイルなどのアプリケーションを取得する。
　以降、アプリケーション制御情報やアプリケーション自体のデータを、アプリケーション関連データと呼ぶ。アプリケーションの記述には、ＸＭＬなどＨＴＭＬ以外の記述言語を用いてもよい。
　［デフォルトとなるサービス情報の送信方法］
　しかしながら、アプリケーションに対応しない受信機が存在する、あるいは、アプリケーションに対応していたとしても、アプリケーションを取得してから起動するまでには放送や通信における選局開始からのタイムラグが発生する。
　従って、再生すべきストリームや表示レイアウトのデフォルト設定情報については、アプリケーション関連データではなく、ＰＭＴやＭＰＴなど選局時に必ず取得するデータ、あるいは、他のＴＳのセクションやＭＭＴのメッセージなど、アプリケーションを起動するまでにかかる時間よりも低遅延で取得できるデータにおいて送信してもよい。そして、高度な再生制御を行うための情報はＨＴＭＬなどのアプリケーションデータとして送信するとしてもよい。
　例えば、放送あるいは通信において送信されるストリームの再生制御に関連する情報としては、（ａ）ストリーム間のスケーラビリティに関する情報、（ｂ）マルチリンガルの音声や、ビットレートの異なるビデオなどストリームの切替えに関する情報、（ｃ）同時に表示可能な複数のビデオのストリームを示す情報など同時表示に関する情報、及び、同時表示する場合のレイアウトに関する情報などがあり、これらの情報のデフォルト値をデフォルト再生制御情報と呼ぶとする。
　アプリケーションに対応しない受信装置においては、デフォルト値に基づいて再生を行う。一方、アプリケーションに対応する受信装置は、デフォルト値に基づいて再生を開始し、アプリケーションの起動後に、ユーザー動作、あるいは、アプリケーションの制御コマンドなどに基づいて再生動作を切替えるとすればよい。
　ユーザー動作による切替えが可能な情報についてのみ、アプリケーションによって再生動作を切替えてもよい。例えば、同時表示に関しては、基本的にはユーザーによる切替えが可能であるが、時間スケーラビリティに関しては、拡張レイヤのストリームが取得可能であれば常に拡張レイヤを使用するとして、受信機が自動的に再生動作を決定してもよい。この場合、時間スケーラビリティに関する情報は、デフォルト再生制御情報においてのみ送信する。
　ここで、ＴＳにおいては、再生制御に関する情報は基本的にはアプリケーションにより実行されるが、スケーラビリティに関する情報はデフォルト再生制御情報において送信してもよい。このとき、基本レイヤと拡張レイヤのストリームを対応付けるための情報のみをデフォルト再生制御情報、あるいは、ＭＰＥＧ－２　ＴＳで規定する記述子により送信し、アプリケーションの制御コマンドやユーザー動作に基づいて、アプリケーション側において拡張レイヤを復号するかどうかを決定してもよい。
　また、レイアウトに関連する情報についてのみ、アプリケーションによって再生動作を切替えるとしてもよい。例えば、時間スケーラビリティやストリーム切替えは、レイアウトの変更を伴わない。従って、これらの情報はデフォルト再生制御情報においてのみ送信する。一方で、同時表示に関する情報はユーザー動作による切替えが想定されるため、アプリケーションによる再生動作を可能とする。
　（デフォルト再生制御情報の記述例）
　次に、デフォルト再生制御情報による再生動作をアプリケーションによって切替える際の再生制御情報の記述例について説明する。ここで、デフォルト再生制御情報は記述子に格納され、アプリケーション制御情報はＨＴＭＬにより記述されるものとする。
　図１８Ａは、実施の形態２におけるデフォルト再生制御情報の記述例を示す図であり、図１８Ｂは、図１８Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。すなわち、図１８Ａに示すデフォルト再生制御情報において、図１８Ｂに示すようにＰＩＤ＝１００のビデオを全画面表示することがレイアウト情報により示されている。
　なお、レイアウト情報としては、ストリームを特定するための情報を示さずに、全画面表示することのみを示してもよい。また、このとき、ビデオストリームが２本以上存在する場合には、デフォルトで再生されるビデオを特定するための情報（アプリケーション制御情報）を別途示すことにすれば、デフォルトで再生されるビデオを全画面表示するように動作させることができる。
　図１９Ａは、実施の形態２におけるアプリケーション制御情報の一例を示す図であり、図１９Ｂは、図１９Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。
　すなわち、図１９Ａに示すアプリケーション制御情報では、領域１と領域２の２つの表示領域をＬａｙｏｕｔタグにより設定し、図１９Ｂに示すようにＰＩＤ＝１００のビデオを領域１に表示し、ＰＩＤ＝２００のビデオを領域２に表示することが示されている。
　したがって、図１９Ａに示すＨＴＭＬのアプリケーション制御情報を受信した受信装置は、領域１と領域２に、それぞれＰＩＤ＝１００とＰＩＤ＝２００とのビデオを表示する。なお、ビデオを特定する情報は、ＰＩＤ以外にも、ＵＲＬ、あるいは、ＭＭＴパケットのパケットＩＤなどであってもよい。
　このように、図１９Ａおよび１９Ｂに示す例では、デフォルト再生制御情報において、スケーラビリティとレイアウトとの２種類の情報が示されている。スケーラビリティとしては、スケーラビリティの種類が時間スケーラビリティであり、ＰＩＤ＝１００のビデオが基本レイヤで、ＰＩＤ＝２００のビデオが拡張レイヤであることが示される。レイアウト情報としては、ＰＩＤ＝１００のビデオを全画面表示することが示される。
　基本レイヤのみではフレームレートが６０ｆｐｓであり、拡張レイヤを用いることで１２０ｆｐｓになるとすると、デフォルトの状態では、ＰＩＤ＝１００のビデオのみを復号して、６０ｆｐｓ相当の映像が全画面表示により再生される。なお、送信されるストリームがスケーラビリティの基本レイヤや拡張レイヤに相当することが、ＭＰＥＧ－２システムのストリームタイプなどストリームの属性情報によって別途示される場合には、デフォルト再生制御情報としては、これらの情報を記述しなくてもよい。また、デフォルトの状態では基本レイヤのみを復号して再生することを別途規定しておけば、レイアウト情報としては、全画面表示することのみを示してもよい。
　図２０Ａは、実施の形態２におけるデフォルト再生制御情報の別の記述例を示す図であり、図２０Ｂは、図２０Ａに示すデフォルト再生制御情報のレイアウト情報に従ったビデオの表示例について示す図である。図２１Ａは、実施の形態２におけるアプリケーション制御情報の一例を示す図であり、図２１Ｂは、図２１Ａに示すアプリケーション制御情報のレイアウト情報に従ったビデオの表示例について示す図である。
　図２１Ａでは、Ｓｃｒｉｐｔタグにより関数Ａが定義される。関数Ａは、画面上のボタンが押された場合に時間スケーラビリティの拡張レイヤを復号、再生することを指示する関数であり、引数として、基本レイヤと拡張レイヤを特定するインデックス番号などを示す。Ｂｏｄｙタグにおいては、リモコンの特定のボタンなどが押された場合に、関数Ａを呼び出す旨が記述される。
　図２１ＡのＨＴＭＬアプリケーションを受信した受信装置は、ボタンが押下げられると、ＰＩＤ＝２００の拡張レイヤのストリームを復号し、１２０ｆｐｓ相当の映像を全画面表示により再生する。
　デフォルトで再生するオーディオやビデオなどのストリームは、ＭＰＥＧ－２システムやＭＭＴの記述子などを用いることにより別途示してもよい。例えば、デフォルトで再生するストリームをグループ化して、グループのＩＤとストリームとを対応付けることが可能である。あるいは、デフォルトで再生するストリームを示すための記述子を規定して、記述子の中にデフォルトで再生するストリームのＰＩＤなどのリストを含めることも可能である。
　なお、デフォルト再生制御情報におけるデフォルト値を予め規定しておき、パラメータ値が当該デフォルト値と等しい場合にはデフォルト再生制御情報を送信しないことにしてもよい。例えば、レイアウトとして全画面表示をデフォルト値とすれば、全画面表示の場合には、レイアウト情報を含めなくてもよい。このとき、スケーラビリティが使われておらず、ストリームの切替えにも対応しないケースでは、デフォルト再生制御情報を送信しなくてもよい。
　［受信方法］
　本実施の形態では、受信側は、サービス情報を取得後に、デフォルト再生制御情報、及び、アプリケーションにより提供される再生制御情報を解析して、動作する。以下、図を用いて、本実施の形態における受信方法について説明する。
　図２２は、実施の形態２における受信側の動作の一例を示すフローチャートである。図２２には、デフォルト再生制御情報、及び、アプリケーションにより提供される再生制御情報を解析して、スケーラビリティやストリーム切替えなどの機能、コンテンツを提示する際のレイアウトを決定する際の動作の一例が示されている。
　まず、ステップＳ７０１において、受信側は、視聴するコンテンツを選局する。
　次に、ステップＳ７０２において、受信側は、デフォルト再生制御情報を解析し、復号して再生するストリームを決定するとともに、レイアウトなどの提示方法を決定する。
　ここで、デフォルト再生制御情報は、ＰＭＴやＭＰＴなど選局時に必ず取得するデータに含めて送信されるとしてもよいし、アプリケーション関連データとは別途送信される、ＭＰＥＧ－２　ＴＳのセクションやＭＭＴのメッセージなどにより送信されるとしてもよい。
　デフォルト再生制御情報がセクションやメッセージにより送信される場合には、デフォルト再生制御情報のデフォルト値を設定しておき、当該セクションやメッセージを受信するまでの間は、デフォルト再生制御情報のデフォルト値に基づいて動作するとしてもよい。また、復号して再生するストリームは、デフォルトで再生するオーディオやビデオなどのストリームを示す記述子を参照することにより決定してもよい。
　次に、ステップＳ７０３において、決定した再生制御パラメータに従って再生開始する。
　次に、ステップＳ７０４において、アプリケーションを受信するか判定し、受信しない場合（Ｓ７０４でいいえ）には、処理を終了する。一方、受信する場合（Ｓ７０４ではい）には、ステップＳ７０５に進み、アプリケーションにおいて再生制御機能が示されているか判定する。
　ステップＳ７０５において、再生制御機能が示されていない場合には（Ｓ７０５でいいえ）、処理を終了する。再生制御機能が示されている場合には（Ｓ７０５ではい）、ステップＳ７０６に進み、アプリケーションに示される再生制御機能に基づいて、制御コマンドやユーザー動作に従って再生制御情報を更新する。
　次に、ステップＳ７０７において、更新後の再生制御パラメータに従って再生し、処理を終了する。
　［受信装置］
　図２３は、実施の形態２における受信装置の構成の一例を示すブロック図である。図２３では、図２２で説明した各ステップの動作を実現する受信装置の構成の一例が示されている。
　図２３に示す受信装置７００は、受信部７０１と、デフォルト情報解析部７０２と、アプリ情報受信部７０３と、アプリ再生制御情報解析部７０４と、再生制御実行部７０５とを備える。これらの動作は、図２２で説明した各ステップにおける動作であるため、説明を省略する。
　（変形例１）
　デフォルト再生制御情報をアプリケーションにより更新する仕組みは、放送単独、通信単独、あるいは、放送と通信を併用してコンテンツを送信する全ての場合において適用できる。
　また、本実施の形態における手法における考え方は、現在ＭＰＥＧで規格化中のＭＰＥＧ－２　ＴＳのタイムライン拡張（１３８１８－３：２０１３／ＡＭＤ６）においても適用できる。ＴＳのタイムライン拡張においては、少なくとも１つのＴＳ（基本ＴＳと呼ぶ）を含む複数の多重化ストリームを用いてコンテンツを送信する際に、基本ＴＳと、それ以外の多重化ストリームにおいてコンテンツの復号や表示における基準クロックを同期させるための情報を提供する。
　具体的には、基本ＴＳと異なる多重化ストリームの基準クロックと、基本ＴＳのＰＣＲとを対応付ける情報を含むタイムライン拡張用アクセスユニットを定義し、タイムライン拡張用アクセスユニットをＰＥＳパケットに格納し、ＴＳパケット化して送信する。タイムライン拡張用アクセスユニットにおいては、タイムライン拡張用の情報はＭＰＥＧ－２システムの記述子の形式により表現される。このように、ＰＥＳパケット単位でタイムライン拡張用の情報を送信することで、ＰＣＲの不連続が発生した場合にも、更新後のＰＣＲとの基準クロックの同期が迅速に行える。
　しかしながら、ＰＣＲの不連続は単一の番組内においては一般的には発生しないため、番組の受信開始時にタイムライン拡張用の情報を受信して、互いの基準クロックを同期すれば、番組内においての再同期は不要であることが多い。
　従って、番組内でＰＣＲの不連続が発生しないことが保証される場合には、ＰＭＴなどにタイムライン拡張用の情報のデフォルト値を格納して、タイムライン拡張用のアクセスユニットは送信しないことにしてもよい。例えば、タイムライン拡張用アクセスユニットにおいてタイムライン拡張用の情報を格納する記述子と同様の記述子をＰＭＴなどのセクションに格納して、タイムライン拡張用の情報のデフォルト値として使用できる。また、タイムライン拡張用アクセスユニットとＰＭＴなどに格納されるデフォルト情報とを併用してもよい。
　タイムライン拡張用アクセスユニットが送信される場合においても、番組内、あるいは、特定の時刻までＰＣＲの不連続が発生しないことが保証される場合には、選局直後に受信するタイム来拡張用アクセスユニットの情報に基づいてクロック同期を行った後は、番組内、あるいは、特定の時刻までは再同期を行わないことにしてもよい。
　また、タイムライン拡張用の情報をセクションにより送信する場合には、ＰＣＲの不連続が発生した直後から一定期間の間、更新後のＰＣＲに対応したタイムライン拡張用の情報を送信してもよい。受信装置においては、セクションのバージョン番号が更新されていれば、当該セクションに含まれるタイムライン拡張用の情報に基づいて再同期を行う。なお、ＰＣＲ不連続の発生後であって、再同期よりも前の時刻においては、ストリーム間のクロック同期が保証できない。このときは、ＴＳのｄｉｓｃｏｎｔｉｎｕｉｔｙ　ｉｎｄｉｃａｔｏｒなどＰＣＲの不連続を示す情報に基づいて別途ＰＣＲの不連続を検出し、不連続を検出した場合には、再同期までの間は、基本ＴＳと同期対象となるメディアのアクセスユニットを固定フレームレートと仮定して復号、表示するなどしてもよい。
　［実施の形態２の効果等］
　以上のように、本実施の形態によれば、オーディオやビデオを含むコンテンツにおける、ビデオの表示に関するレイアウト情報、あるいは、再生時に切替え可能なストリームを示す情報などを含む再生制御情報を送信する際に、選局時に必ず受信するデータに再生制御情報のデフォルト値を格納し、デフォルトの再生制御動作を更新するための情報を、ハイブリッドキャストなどのアプリケーションに関連する情報に格納して送信する。
　ここで、再生制御のデフォルト値に従って再生を開始し、受信装置がアプリケーションに対応する場合には、アプリケーションデータとして送信される再生制御機能に基づいて、ユーザー動作などに従ってデフォルトの再生制御情報を更新する。
　それにより、コンテンツのレイアウトなど再生制御に係るパラメータの決定に係る遅延時間が低減できる。
　（実施の形態３）
　上述したように、ＭＭＴ方式によれば、映像及び音声を多重、パケット化し、放送や通信などの一つ以上の伝送路で送信することができる。受信装置においては、一つ以上の伝送路で伝送されたパケットを受信し、プログラム情報を基に受信されたパケットの中から所望のパケットを抽出し、復号・提示をすることができる。
　つまり、ＭＭＴ方式では、複数の伝送路で伝送されたメディア（映像や音声、字幕など）を受信してプログラムを構成することが可能である。しかし、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成することができない。
　そこで、実施の形態３では、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成する場合の送信方法および受信方法等について説明する。
　以下では、放送連携サービスにおける放送側の多重化フォーマットとしては、ＭＰＥＧで規格化されたＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）を例に説明する。
　ＭＭＴでは、ＭＰＴ（ＭＭＴ　Ｐａｃｋａｇｅ　Ｔａｂｌｅ）などのテーブル、あるいは、ＰＡ（Ｐａｃｋａｇｅ　Ａｃｃｅｓｓ）メッセージなどのメッセージ情報によりプログラム情報が送信される。ＭＰＴには、プログラムを構成するアセット（ビデオ、オーディオなどの単一メディア）や、アセットを伝送するロケーション情報が記述されている。一つのアセットを複数の伝送路によって伝送することも可能である。
　本実施の形態でも、送信側は、放送波と通信路を用いてコンテンツ（データまたはアセット）を送信するが、コンテンツの送信に先だってサービス情報を送信する。
　［サービス情報］
　図２４は、実施の形態３の放送通信連携サービスにおけるサービス情報のデータ構造の一例を示す図である。図２５は、実施の形態３のプログラム構成情報記述子に含まれる情報の一例を示す図である。
　図２４に示すようにＭＰＴ内にプログラム構成情報記述子が含まれ、本記述子において、パッケージを構成するアセットに関する情報が示される。パッケージを構成するアセットに関する情報には下記を含めることができる。
　（アセットに関する情報）
　１）プログラムを構成するアセットに、蓄積されているアセット（以後、蓄積アセットと呼ぶ）を含むか含まないかを示す情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。ここで、蓄積されているアセットとは、例えばＨＤＤや内部メモリ、ＳＳＤ、ＳＤカードなどのメモリ、ブルーレイディスクなどに蓄積されているアセットである。
　２）プログラムを構成するアセットに蓄積アセットを含む場合、プログラムの構成を示す情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。
　例えば、プログラムが蓄積アセットのみで構成されている、プログラムが蓄積アセットと伝送されているアセット（以後、伝送アセットと呼ぶ）とで構成されている、または、プログラムが蓄積パケットを含むアセットと伝送アセットで構成される、といったプログラムの構成を示す情報を含めるとしてもよい。また、例えばプログラムがスケーラブル符号化された映像で構成される場合、伝送アセットに基本レイヤを含み、蓄積アセットに拡張レイヤを含むことを示す情報を含めるとしてもよい。また、プログラムの再生に、蓄積アセットの復号、再生が必須か、必須でないかを示す情報を含めるとしてもよい。例えば、蓄積アセットのコンテンツが付加的な情報である場合、再生は必須でないとし、蓄積アセットの再生が必須でないことを示す情報を含めるとしてもよい。
　また、例えば受信装置が蓄積に対応していない場合、あるいは蓄積アセットが蓄積されていない場合などには、プログラムの再生に蓄積アセットの復号・再生が必須でないことを示す情報を基に、蓄積アセットを用いず、放送や通信から取得したアセットを用いてプログラムを再生することができる。
　３）蓄積アセットに関する情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。
　ここで、例えば、ａ）蓄積アセットの蓄積フォーマットや、映像・音声符号化方式、蓄積アセットを伝送した伝送方式や多重化方式などの属性情報を含めるとしてもよい。この場合、蓄積アセットにはあらかじめ属性情報を付与し、属性情報は、例えば蓄積アセットのヘッダや、蓄積アセットの構成を示すプログラム情報などに含めればよい。受信装置がプログラム情報に格納された属性情報と蓄積アセットの属性情報が一致したときに再生可能としてもよい。また、例えば、ｂ）蓄積アセットを含むプログラムを再生するために必要な受信機の能力、機能に関する情報を含めるとしてもよい。また、例えば、ｃ）プログラムを再生や視聴を制限するための情報（スクランブル方式、視聴制限、限定受信、著作権情報）や鍵を含めるとしてもよい。この場合、受信装置は、プログラム情報に格納された視聴を制限するための情報と、蓄積アセットとを照合し、蓄積アセットの再生や視聴の可否を判断してもよい。また、受信装置は、あらかじめ暗号化されたアセットを蓄積し、送信された鍵を基に蓄積アセットの暗号を復号してもよい。
　４）プログラムを構成するアセットが、伝送アセットと蓄積アセットから構成されている場合、伝送アセットと蓄積アセットを同期して再生にするための時刻情報をアセットに関する情報としてプログラム構成情報記述子に含めるとしてもよい。
　この時刻情報は、例えば、蓄積アセットに付与されているタイムスタンプの基準となる基準時刻に対する伝送アセットの基準時刻情報とのオフセット量を示すとしてもよい。また、蓄積アセットに付与されているタイムスタンプがＰＣＲ（Ｐｒｏｇｒａｍ　Ｃｌｏｃｋ　Ｒｅｆｅｒｅｎｃｅ）やＮＴＰ（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）に基づいて付与されている場合、伝送された基準時刻（ＰＣＲやＮＴＰ）に対する相対時刻を示すとしてもよい。また、時刻情報は、蓄積アセットがランダムアクセステーブルをもつフォーマットで蓄積されている場合、蓄積アセットのランダムアクセスポイントに対する伝送アセットの時刻情報テーブルであってもよい。
　（ロケーション情報）
　ＭＰＴ内には、アセット毎に、アセットのロケーション情報が記述される。例えば一つのアセットが複数のロケーションに存在する場合は、ＭＰＴ内には複数のロケーション情報が記述される。
　図２６は、実施の形態３のロケーション情報記述子に含まれる情報の一例を示す図である。図２７は、実施の形態３のロケーション情報記述子に含まれるロケーションタイプの一例を示す図である。
　図２６に示すように、ロケーション情報記述子には、ロケーション情報として、ロケーションタイプとロケーションタイプに応じたアセットの特定する識別子とが記述される。
　ロケーションタイプは、ロケーション情報のタイプを表す。例えば、図２６に示す例では、ロケーションタイプの値Ｖａｌｕｅが０ｘＡ０（Ｖａｌｕｅ＝０ｘＡ０）であるので、図２７より、ローカルに蓄積されていることがわかる。ロケーションタイプに、ローカルに蓄積されていることが示されている場合、ロケーション情報には蓄積されているデータを一意に示すローカルＩＤを記述される。
　ここで、ローカルＩＤは、例えば、蓄積されているアセットのアセットＩＤでもよいし、パケットＩＤでもよい。また、ＡＲＩＢ　ＳＴＤ－Ｂ４５に規定されている３２ｂｉｔのトランスポートファイル識別子でもよいし、新たに規定してもよい。また、ネットワークＩＤや、ストリームＩＤなど、さまざまなＩＤを組み合わせ、所定の命名規則に従い、ローカルＩＤを生成してもよい。また、ローカルＩＤは、放送局、送信局、コンテンツプロバイダー等があらかじめ付与してもよいし、受信機側でＩＤを修正、追加の情報を加えて付与してもよい。受信側で独自のＩＤを付与し、送信側で付与されたＩＤとの対応関係を示すテーブルを用意してデータを特定できるとしてもよい。
　なお、上記の例は、ロケーションタイプを用いてアセットがローカルに蓄積されていることを示し、別途ローカルＩＤを付与するとしたが、次の方法を用いてもよい。例えば、ロケーションタイプとしてＩＰｖ４を選択し、ローカル特有のＩＰアドレスを用いて指定してもよい。例えば、ＩＰアドレスが、１９２．１６８．ｘｘｘ．ｘｘｘとなっている場合は、アセットがローカルに蓄積されているとし、ｘｘｘ．ｘｘｘの部分で蓄積されたアセットを特定するとしてもよい。
　また、蓄積されているアセットのデータ（ファイル）には、ローカルＩＤを付与する。例えば、ファイルの中のファイルヘッダに格納する。ローカルＩＤはあらかじめ放送局、送信局、コンテンツプロバイダーが格納してもよいし、受信側で格納することも考えられる。
　上記の記述子は一例であり、同様の機能を持つデータ構造で記述子を構成してもよい。また、本実施の形態の記述子、識別子はＭＰＴのとは異なる、パッケージ単位の情報を示すテーブルやメッセージに格納してもよい。他のシグナリング情報を用いて送信してもよい。
　なお、ＭＭＴを例に説明したが、ＭＭＴに限定されるものではなく、ＴＳやＭＰＥＧ－ＤＡＳＨなど他のフォーマットであってもよい。例えば、多重化方式としてＭＰＥＧ２－ＴＳを用いる場合は、ＰＭＴ（Ｐｒｏｇｒａｍ　Ｍａｐ　Ｔａｂｌｅ）に格納してもよい。また、ＭＰＥＧ２－ＴＳ方式と他の方式とを組み合わせて伝送する場合、ＴＥＭＩ（Ｔｉｍｅｌｉｎｅ　ａｎｄ　Ｅｘｔｅｒｎａｌ　Ｍｅｄｉａ　Ｉｎｆｏｒｍａｔｉｏｎ）アクセスユニットに格納してもよい。ＭＰＥＧ－ＤＡＳＨを用いる場合は、ＭＰＤ（Ｍｅｄｉａ　ｐｒｅｓｅｎｔａｔｉｏｎ　ｄｅｓｃｒｉｐｔｉｏｎ）に記述してもよい。
　（アセット構成情報記述子）
　ＭＭＴ方式では、一つのアセットを複数の伝送路によって伝送することも可能である。このとき、アセットの構成を示すアセット構成情報記述子を格納してもよい。
　図２８は、実施の形態３のアセット構成情報記述子に含まれる情報の一例を示す図である。すなわち、アセットの構成を示す情報には下記を含めることができる。
　１）当該アセットが蓄積アセットであることや、アセットが蓄積パケットをアセットの構成を示す情報に含めるとしてもよい。ここで、アセットが蓄積パケットを含む場合とは、一つのアセットが放送や通信から伝送されるパケットと、蓄積されたパケットから構成される場合である。
　２）アセットが蓄積アセットである場合、例えば、ａ）当該アセットが蓄積アセットのみで構成されている、蓄積パケットと伝送パケットからと構成されているといった情報をアセットの構成を示す情報として含むとしてもよい。また、ｂ）アセットがスケーラブル符号化された映像で構成される場合、例えば伝送パケットに基本レイヤを含み、蓄積パケットに拡張レイヤを含むことを示す情報などをアセットの構成を示す情報として含むとしてもよい。また、ｃ）アセットの構成として、蓄積パケットの復号、再生が必須であるか必須でないかを示す情報をアセットの構成を示す情報として含むとしてもよい。例えば、蓄積パケットのコンテンツが付加的な情報である場合、再生は必須でないとし、蓄積パケットのコンテンツの再生が必須でないことを示すことができる。
　これにより、例えば受信装置が蓄積に対応していない場合、あるいは蓄積パケットを蓄積していない場合などには、アセットの再生に蓄積パケットの復号・再生が必須でないことを示す情報を基に、蓄積パケットを用いず、放送や通信から伝送されるパケットを用いてプログラムを再生することができる。
　なお、上述したアセット構成情報記述子は一例であり、同様の機能を持つデータ構造でアセット構成情報記述子を構成してもよい。
　また、アセット構成情報記述子、識別子はＭＰＴのとは異なる、パッケージ単位の情報を示すテーブルやメッセージに格納してもよい。他のシグナリング情報を用いて送信してもよい。
　なお、ＭＭＴを例に説明したが、ＭＭＴに限定されるものではなく、ＴＳやＭＰＥＧ－ＤＡＳＨなど他のフォーマットであってもよい。例えば、多重化方式としてＭＰＥＧ２－ＴＳを用いる場合は、ＰＭＴ（Ｐｒｏｇｒａｍ　Ｍａｐ　Ｔａｂｌｅ）に格納してもよい。また、ＭＰＥＧ２－ＴＳ方式と他の方式とを組み合わせて伝送する場合、ＴＥＭＩ（Ｔｉｍｅｌｉｎｅ　ａｎｄ　Ｅｘｔｅｒｎａｌ　Ｍｅｄｉａ　Ｉｎｆｏｒｍａｔｉｏｎ）アクセスユニットに格納してもよい。ＭＰＥＧ－ＤＡＳＨを用いる場合は、ＭＰＤ（Ｍｅｄｉａ　ｐｒｅｓｅｎｔａｔｉｏｎ　ｄｅｓｃｒｉｐｔｉｏｎ）に記述してもよい。
　［受信方法および受信装置］
　以下、図を用いて、本実施の形態における受信装置が、蓄積アセットを同期再生する動作の一例について説明する。
　図２９は、実施の形態３の放送通信連携サービスにおける受信方法を示すフローチャートである。図３０は、実施の形態３における受信装置の構成の一例を示すブロック図である。
　図３０に示す受信装置３０は、プログラム情報解析部３１と、蓄積アセット特定部３２、蓄積アセット情報解析部３３、判定部３４と、アセット取得部３５と、同期提示部３６と、同期制御部３７とを備える。
　まず、ステップＳ１１において、プログラム情報解析部３１は、エントリポイントとなるプログラム構成情報記述子を解析し、プログラムの構成に蓄積アセットを含むかを解析する。
　次に、ステップＳ１２において、プログラム情報解析部３１は、プログラムを構成する要素に蓄積アセットを含むか判定する。プログラムを構成する要素に蓄積アセットを含むと判定した場合（Ｓ１２でＹｅｓ）、ステップＳ１３に進み、プログラムの構成を示す情報や蓄積アセットに関する情報、蓄積アセットとの相対時刻情報などの情報を取得する。蓄積アセットを含まないと判定した場合は（Ｓ１２でＮｏ）、ステップＳ１７に進み、放送や通信などで伝送される伝送アセットを取得して同期再生する。
　次に、ステップＳ１４において、受信装置３０は、蓄積アセットのロケーション情報や、ローカルＩＤを取得する。より具体的には、アセットがローカルに蓄積されている場合は、蓄積アセット特定部３２は、受信装置３０に蓄積されているアセットの中から、ローカルＩＤに対応するアセットを検索して特定する。なお、蓄積装置が複数ある場合は、複数の蓄積装置の中から検索してもよいし、特定の蓄積装置の中のみを検索するとしてもよい。また、蓄積アセット情報解析部３３は、特定したアセットの属性情報を取得する。
　次に、ステップＳ１５において、判定部３４は、ステップＳ１２で取得された蓄積アセットに関する情報と、ステップＳ１４で取得された蓄積アセットの属性情報とを基に、蓄積アセットを含むプログラムを再生可能かどうか判定する。
　プログラムが再生可能と判定されれば（Ｓ１５でＹｅｓ）、ステップＳ１６に進み、アセット取得部３５が放送や通信などの伝送アセットに加え、蓄積アセットを取得する。そして、同期制御部３７は、取得された相対時刻情報を基に、伝送アセットと蓄積アセットとの同期制御処理を施し、同期提示部３６はプログラムの同期や提示を行う。
　一方、ステップＳ１５においてプログラムが再生不可能と判定されれば（Ｓ１５でＮｏ）、ステップＳ１７に進み、放送や通信などで伝送される伝送アセットを取得して同期・再生する。
　［実施の形態３の効果等］
　以上のように、本実施の形態によれば、放送及び通信を連携させたサービスを、ＭＰＥＧ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　Ｅｘｐｅｒｔ　Ｇｒｏｕｐ）で規格化中のＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）方式などのフォーマットにより多重化する際のプログラム情報の生成方法、及びプログラムの再生方法、及び再生装置を実現することができる。
　ＭＭＴ方式は、映像・音声を多重・パケット化し、放送や通信などの一つ以上の伝送路で送信し、受信装置において一つ以上の伝送路で伝送されたパケットを受信し、プログラム情報を基に受信されたパケットの中から所望のパケットを抽出し、復号・提示をする。
　ＭＭＴ方式では、複数の伝送路で伝送されたメディア（映像や音声、字幕など）を受信してプログラムを構成することが可能である。しかし、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成することができない。
　そこで、本実施の形態では、プログラムの構成を示すプログラム情報に、プログラムを構成するメディアの一つが蓄積されたデータであることを示す識別子と、蓄積されたメディア（ファイル）を特定できる識別子を設ける。また、再生装置においは、プログラム情報を解析し、放送・通信で伝送されているメディアと蓄積されたデータを特定し、同期して再生する。
　それにより、放送や通信でダウンロードして蓄積したデータと、放送・通信からストリーミングされたデータの両方を用いてプログラムを構成することができるので、従来の放送通信連携サービスに加え、蓄積したファイルと連携したサービスを提供することができる。
　なお、本実施の形態では、伝送アセットと蓄積アセットとの組み合わせを例に説明したが、それに限らない。伝送アセットは、放送で伝送されるアセットでも良いし、通信で伝送されるアセットでもよい。また、放送と通信両方から伝送されるアセットでもよい。蓄積アセットを用いたサービスとして、下記のようなサービスを提供してもよい。プログラム情報にサービスの内容を示す識別子を格納してもよい。
　（蓄積アセットを用いたサービス）
　１）あらかじめプログラムを構成するアセットをダウンロードしておき、放送ではプログラム情報や時刻同期情報（時刻基準情報やタイムスタンプの相対値など）のみを送信し、蓄積アセットを用いてプログラムを再生してもよい。このとき、放送業者は、蓄積データを用いたプログラムを、番組編成にそってリアルタイムに視聴者に提供することが可能となる。視聴者はあたかもリアルタイムに放送されている番組を視聴するかのごとく、蓄積データを視聴することができる。リアルタイムな放送だけでなくオンデマンドのコンテンツ提供も可能である。
　２）また、あらかじめプログラムを構成するアセットとともにプログラム情報やランダムアクセスポイントなどをダウロード・蓄積し、放送や通信から伝送されるプログラム情報と同期してプログラムを構成してもよい。
　３）通常の放送番組は放送のみを用いて送信し、コマーシャル時のみ蓄積データと連携するサービスを提供することも可能である。あらかじめコマーシャルデータを放送又は通信からダウンロードしておき、コマーシャルの時間帯になった時に、蓄積データを含むプログラムを視聴者に提供するとしてもよい。また、複数のあらかじめ複数のコマーシャルデータをダウンロードしておき、視聴者の属性や嗜好に応じて提供するコマーシャルを選択してもよい。視聴者の属性や嗜好などは、受信装置が取得し解析したものであってもよいし、他のアプリやサービスと連携して取得してもよい。
　４）放送業者は、蓄積データと連携させたサービスを提供することにより、空いた周波数リソースを他のサービスに割り当ててもよい。このとき、プログラム情報には当該サービスに使用されている周波数リソースが他のサービスに提供されていることを示す情報を格納してもよい。
　５）視聴者が蓄積アセットと連携したプログラムに切り替える機能を有してもよい。例えば、伝送アセットのみを視聴している視聴者が、リモコンなどのユーザーインタフェースによって、蓄積アセットを含むプログラムに切り替えてもよい。
　６）また、蓄積アセットにアクセスしてプログラムを構成してもよいかを受信装置または視聴者が設定してもよい。また、プログラム情報が、信頼できると認証されている場合にのみ蓄積アセットにアクセスしてプログラムを構成できるとしてもよい。プログラム情報には、そのプログラム情報が信頼できることを示す情報は鍵などを格納してもよい。
　（ＥＰＧ）
　７）ＥＰＧ（Ｅｌｅｃｔｒｏｎｉｃ　Ｐｒｏｇｒａｍ　Ｇｕｉｄｅ）として表示する情報は、プログラム情報から取得してもよいし、ＥＰＧ専用のシグナリング情報から取得してもよい。
　８）プログラムが、放送を用いて提供されるか、通信を用いて提供されるか、蓄積を用いて提供されるか、組み合わせて提供されるか、または拡張サービスとして提供されるか等の情報をＥＰＧに表示してもよい。また、受信装置が提供できる機能のみを表示してもよい。例えば、受信装置が蓄積する機能や通信を受信する機能を保有していない場合は、蓄積や通信に関する情報を表示しないとしてもよい。
　９）蓄積アセット含むプログラムにおいて、当該プログラムの蓄積アセットが蓄積されているか蓄積されていないかを示す情報をＥＰＧ上に表示してもよい。当該プログラムの蓄積アセットを提示可能かどうかを示す情報をＥＰＧ上に表示してもよい。文字などで示してもよいし、ＥＰＧのプログラムの背景色などで示してもよい。蓄積アセットを含むコンテンツが視聴制限や著作権に係る情報を提示してもよい。
　１０）蓄積アセットを含むプログラムをＥＰＧから予約する場合、蓄積アセットを放送からダウンロード可能か、通信からダウンロード可能か、または通信のストリーミングにより視聴可能かをＥＰＧ等に表示してもよい。受信装置が通信手段を有していない場合は、放送ダウンロード可能かのみを表示するとしてもよい。視聴者はダウンロード予約可能な方法のなかから選択して予約する。
　ダウンロードの予約は、事前に視聴者がＥＰＧから予約してもよいし、受信装置が自動でダウンロードしてもよい。ダウンロード方法の選択は視聴者がしてもよいし、受信装置が自動で選択してもよい。
　また、放送によりダウンロードできる時間帯、通信によりダウンロードできる時間帯、通信によりストリーミングできる時間帯によってＥＰＧの表示や受信装置の機能を変化させてもよい。
　なお、上述のＥＰＧの表示に限らず、ＥＰＧ以外の別の提示方法で提示してもよい。
　以上、本開示の一つまたは複数の態様に係る送信方法および受信方法等について、実施の形態に基づいて説明したが、本開示は、この実施の形態に限定されるものではない。本開示の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本開示の一つまたは複数の態様の範囲内に含まれてもよい。
　例えば、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
　本開示は、放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法、受信方法などとして有用である。
　１１　識別情報取得部
　１４，１０４，３０５，４０５，１１０５　放送受信部
　３０，１００，３００，４００，７００，１１００　受信装置
　３１　プログラム情報解析部
　３２　蓄積アセット特定部
　３３　蓄積アセット情報解析部
　３４，１０３　判定部
　３５　アセット取得部
　３６　同期提示部
　３７　同期制御部
　１０１，３０１，４０１，１１０１　識別情報取得部
　１０２　アセット決定部
　１０５，３０６，４０６，１１０６　通信受信部
　３０２，４０２，１１０２　決定部
　３０３，４０３，１１０３　通信併用判定部
　３０４，４０４，１１０４　Ｌｏｃ情報取得部
　４０７　同期判定部
　４０８，１１０８　再生部
　７０１　受信部
　７０２　デフォルト情報解析部
　７０３　アプリ情報受信部
　７０４　アプリ再生制御情報解析部
　７０５　再生制御実行部
　１１０７　基準クロック判定部

Claims (12)

  1. 　放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信方法であって、
    　放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって受信側が受信した場合に前記同期を取らせる補助情報を、少なくとも前記放送波を用いて送信する情報送信ステップを含む、
    　送信方法。
  2. 　前記情報送信ステップでは、
    　前記コンテンツを送信するのに先だって前記補助情報を送信し、
    　前記補助情報には、さらに、前記コンテンツの取得先を示すロケーション情報または前記ロケーション情報の取得先を示す情報が含まれている、
    　請求項１に記載の送信方法。
  3. 　前記補助情報送信ステップでは、さらに、
    　前記補助情報に、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含めて送信する、
    　請求項１または２に記載の送信方法。
  4. 　前記補助情報送信ステップでは、前記補助情報を送信することにより、前記コンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記受信側に前記同期を取らせる、
    　請求項３に記載の送信方法。
  5. 　前記送信方法では、
    　前記コンテンツを、ＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）にしたがったフォーマットで生成する生成ステップと、
    　前記コンテンツを、前記生成ステップで生成されたフォーマットで送信するコンテンツ送信ステップと、を含む、
    　請求項１～４のいずれか１項に記載の送信方法。
  6. 　前記生成ステップでは、前記補助情報を、前記コンテンツの取得に関する情報であるメッセージ情報に含めて生成する、
    　請求項５に記載の送信方法。
  7. 　放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信ステップと、
    　前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生ステップと、を含む、
    　受信方法。
  8. 　前記受信ステップでは、
    　前記コンテンツを受信するのに先だって前記補助情報を受信し、
    　前記補助情報に、前記コンテンツの取得先を示すロケーション情報が含まれている場合には、前記ロケーション情報に基づき前記コンテンツを取得することで、前記コンテンツを受信する、
    　請求項７に記載の受信方法。
  9. 　前記受信ステップでは、
    　前記コンテンツを受信するのに先だって前記補助情報を受信し、
    　前記補助情報に、前記コンテンツの取得先を示すロケーション情報の取得先を示す情報が含まれている場合には、
    　前記ロケーション情報の取得先を示す情報に基づき前記ロケーション情報を取得し、取得した前記ロケーション情報から前記コンテンツを取得することで、前記コンテンツを受信する、
    　請求項７に記載の受信方法。
  10. 　前記再生ステップでは、
    　前記受信ステップにおいて、前記放送波によるコンテンツの基準クロックと前記通信路によるコンテンツの基準クロックとの差分情報を含む前記補助情報を受信し、かつ、前記放送波によるコンテンツの基準クロックおよび前記通信路によるコンテンツの基準クロックが異なる場合には、前記差分情報に基づき前記通信路によるコンテンツの基準クロックを前記放送波によるコンテンツの基準クロックに同期させることで前記コンテンツの同期を取る処理を行い、前記コンテンツを再生する、
    　請求項７～９のいずれか１項に記載の受信方法。
  11. 　放送波と通信路を用いてコンテンツを送信可能なコンテンツの送信装置であって、
    　放送波と通信路とのそれぞれを用いてコンテンツを送信する場合には、前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報であって、受信側が受信した場合に前記同期を取らせる補助情報を少なくとも前記放送波を用いて送信する情報送信部を備える、
    　送信装置。
  12. 　放送波と通信路とのそれぞれを用いて送信されたコンテンツを受信する受信部と、
    　前記放送波によるコンテンツと前記通信路によるコンテンツとの同期を取るための補助情報を受信した場合には、前記同期を取る処理を行い、前記コンテンツを再生する再生部と、を備える、
    　受信装置。
PCT/JP2014/003844 2013-07-25 2014-07-22 送信方法および受信方法ならびに送信装置および受信装置 WO2015011915A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
EP19205604.2A EP3641318A1 (en) 2013-07-25 2014-07-22 Transmission method and reception method, and transmission device and reception device
CN201480027612.8A CN105230026B (zh) 2013-07-25 2014-07-22 发送方法、接收方法、发送装置及接收装置
EP14830237.5A EP3026920B1 (en) 2013-07-25 2014-07-22 Transmission method and reception method, and transmission device and reception device
US14/970,750 US10356474B2 (en) 2013-07-25 2015-12-16 Transmission method, reception method, transmission device, and reception device
US16/423,436 US11102547B2 (en) 2013-07-25 2019-05-28 Transmission method, reception method, transmission device, and reception device
US17/375,351 US11711580B2 (en) 2013-07-25 2021-07-14 Transmission method, reception method, transmission device, and reception device
US18/206,743 US20230319355A1 (en) 2013-07-25 2023-06-07 Transmission method, reception method, transmission device, and reception device

Applications Claiming Priority (16)

Application Number Priority Date Filing Date Title
US201361858155P 2013-07-25 2013-07-25
US61/858,155 2013-07-25
US201361862115P 2013-08-05 2013-08-05
US61/862,115 2013-08-05
US201361863041P 2013-08-07 2013-08-07
US61/863,041 2013-08-07
US201361880283P 2013-09-20 2013-09-20
US61/880,283 2013-09-20
US201361883251P 2013-09-27 2013-09-27
US61/883,251 2013-09-27
US201361890981P 2013-10-15 2013-10-15
US61/890,981 2013-10-15
US201361892539P 2013-10-18 2013-10-18
US61/892,539 2013-10-18
JP2014145344A JP6616064B2 (ja) 2013-07-25 2014-07-15 送信方法および受信方法
JP2014-145344 2014-07-15

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/970,750 Continuation US10356474B2 (en) 2013-07-25 2015-12-16 Transmission method, reception method, transmission device, and reception device

Publications (1)

Publication Number Publication Date
WO2015011915A1 true WO2015011915A1 (ja) 2015-01-29

Family

ID=52491367

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/003844 WO2015011915A1 (ja) 2013-07-25 2014-07-22 送信方法および受信方法ならびに送信装置および受信装置

Country Status (5)

Country Link
US (4) US10356474B2 (ja)
EP (2) EP3641318A1 (ja)
JP (5) JP6616064B2 (ja)
CN (2) CN111314762A (ja)
WO (1) WO2015011915A1 (ja)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015073267A (ja) * 2013-09-06 2015-04-16 日本放送協会 送信装置、受信装置および限定受信システム
JP2016052008A (ja) * 2014-08-29 2016-04-11 シャープ株式会社 放送信号送信装置、放送信号受信装置、テレビジョン受像機、放送信号伝送システム、制御プログラム、および記録媒体
JP2016052010A (ja) * 2014-08-29 2016-04-11 シャープ株式会社 放送信号送信装置、放送信号受信装置、テレビジョン受像機、放送信号伝送システム、制御プログラム、および記録媒体
JP2016111717A (ja) * 2016-01-25 2016-06-20 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP5957161B1 (ja) * 2016-04-27 2016-07-27 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP2016195410A (ja) * 2016-06-17 2016-11-17 シャープ株式会社 放送信号受信装置、放送信号受信方法、制御プログラム、および記録媒体
WO2017077881A1 (ja) * 2015-11-05 2017-05-11 ソニー株式会社 コンテンツ再生装置、およびコンテンツ再生方法
JP6140381B1 (ja) * 2017-03-31 2017-05-31 シャープ株式会社 放送信号送受信システム、および放送信号送受信方法
CN107787586A (zh) * 2015-06-23 2018-03-09 三星电子株式会社 用于在多媒体系统中发送和接收信号的方法和装置
CN107925784A (zh) * 2015-08-06 2018-04-17 麦克赛尔株式会社 广播接收装置、输出影像信息生成方法、广播接收方法和录像方法
JP2018196130A (ja) * 2018-07-18 2018-12-06 シャープ株式会社 放送信号送信装置、放送信号送信方法、制御プログラム、および記録媒体
US20190017938A1 (en) * 2017-07-12 2019-01-17 Dr. Johannes Heidenhain Gmbh Diffractive biosensor
JP2019205206A (ja) * 2019-09-04 2019-11-28 マクセル株式会社 出力制御方法及び放送受信装置
CN111711851A (zh) * 2015-07-24 2020-09-25 麦克赛尔株式会社 广播接收装置和接收装置
US10880596B2 (en) 2015-06-23 2020-12-29 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving signal in multimedia system
EP3304904B1 (en) * 2015-06-03 2022-01-26 Nokia Technologies Oy A method, an apparatus, a computer program for video coding

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6625318B2 (ja) * 2013-08-29 2019-12-25 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法および受信方法
KR101844235B1 (ko) 2013-12-23 2018-04-02 엘지전자 주식회사 하나 이상의 네트워크를 통해 방송 컨텐츠를 송수신하는 장치 및 방법
US10728610B2 (en) 2014-02-26 2020-07-28 Sony Corporation Receiving apparatus, receiving method, transmission apparatus, and transmission method
EP3177026B1 (en) * 2014-08-01 2021-03-31 Sony Corporation Reception device, reception method, transmission device, and transmission method
JP6341809B2 (ja) * 2014-08-29 2018-06-13 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP6341810B2 (ja) * 2014-08-29 2018-06-13 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
US9635407B2 (en) * 2014-10-16 2017-04-25 Samsung Electronics Co., Ltd. Method and apparatus for bottleneck coordination to achieve QoE multiplexing gains
EP3217606B1 (en) * 2014-11-07 2023-11-29 Sony Group Corporation Transmission device, transmission method, reception device, and reception method
KR102126257B1 (ko) * 2015-02-13 2020-06-24 에스케이텔레콤 주식회사 멀티뷰 스트리밍 서비스 지원 방법 및 이를 지원하는 장치
JP6043825B2 (ja) * 2015-03-20 2016-12-14 ヤフー株式会社 情報処理装置、情報処理方法、情報処理プログラム、および配信装置
CN113038188B (zh) * 2015-03-31 2023-06-06 松下电器（美国）知识产权公司 发送方法、接收方法、发送装置以及接收装置
JP6591775B2 (ja) * 2015-04-15 2019-10-16 マクセル株式会社 出力制御方法
JP2016201765A (ja) * 2015-04-14 2016-12-01 日立マクセル株式会社 放送受信装置及び映像出力方法
US10257583B2 (en) * 2016-02-17 2019-04-09 Arris Enterprises Llc Method for delivering and presenting targeted advertisements without the need for time synchronized content streams
JP2018006846A (ja) * 2016-06-28 2018-01-11 日本放送協会 同期提示システム、同期提示方法及び同期提示プログラム
CN113923491A (zh) * 2016-09-06 2022-01-11 麦克赛尔株式会社 广播接收系统
JP6175207B1 (ja) * 2017-06-12 2017-08-02 シャープ株式会社 放送信号受信装置、放送信号受信方法、テレビジョン受像機、制御プログラム、および記録媒体
JP6175208B1 (ja) * 2017-06-12 2017-08-02 シャープ株式会社 放送信号送受信システム、および放送信号送受信方法
JP6181898B1 (ja) * 2017-06-26 2017-08-16 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP6181897B1 (ja) * 2017-06-26 2017-08-16 シャープ株式会社 放送信号受信装置、放送信号受信方法、テレビジョン受像機、制御プログラム、および記録媒体
JP6251835B2 (ja) * 2017-07-20 2017-12-20 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP6251834B2 (ja) * 2017-07-20 2017-12-20 シャープ株式会社 放送信号受信装置、放送信号受信方法、テレビジョン受像機、制御プログラム、および記録媒体
JP2018133809A (ja) * 2018-03-29 2018-08-23 マクセル株式会社 放送番組の録画予約の制御方法
JP6784817B2 (ja) * 2019-09-19 2020-11-11 マクセル株式会社 出力制御方法
JP7063947B2 (ja) * 2020-07-07 2022-05-09 マクセル株式会社 放送受信装置
JP2020184780A (ja) * 2020-07-07 2020-11-12 マクセル株式会社 放送受信装置
JP2020184781A (ja) * 2020-07-07 2020-11-12 マクセル株式会社 放送受信装置
JP7239762B2 (ja) * 2020-07-07 2023-03-14 マクセル株式会社 放送受信装置におけるコピー制御方法
JP7239763B2 (ja) * 2020-07-07 2023-03-14 マクセル株式会社 放送受信装置におけるコピー制御方法
JP7063946B2 (ja) * 2020-07-07 2022-05-09 マクセル株式会社 放送受信装置
JP6845967B2 (ja) * 2020-10-23 2021-03-24 マクセル株式会社 出力制御方法
JP6849852B2 (ja) * 2020-10-23 2021-03-31 マクセル株式会社 出力制御方法
JP7222060B2 (ja) * 2020-11-04 2023-02-14 マクセル株式会社 出力制御方法
JP7239760B2 (ja) 2021-03-04 2023-03-14 マクセル株式会社 出力制御方法
JP7048787B2 (ja) * 2021-03-04 2022-04-05 マクセル株式会社 出力制御方法
WO2022222470A1 (zh) * 2021-04-22 2022-10-27 海信视像科技股份有限公司 接收机
BE1029802B1 (fr) * 2021-09-28 2023-04-24 Demute Synchronisation d'informations fournies par deux dispositifs différents
JP7434619B2 (ja) 2021-12-23 2024-02-20 マクセル株式会社 出力制御方法
JP7447321B2 (ja) 2022-09-08 2024-03-11 マクセル株式会社 コンテンツの蓄積及び出力方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012099399A2 (ko) * 2011-01-18 2012-07-26 삼성전자주식회사 방송통신 융합형 서비스를 위한 전송 방법 및 장치
WO2012099359A2 (ko) * 2011-01-19 2012-07-26 삼성전자 주식회사 복수의 실시간 전송 스트림을 수신하는 수신 장치와 그 송신 장치 및 멀티미디어 컨텐츠 재생 방법

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4236106B2 (ja) * 2002-03-28 2009-03-11 三菱電機株式会社 ディジタル放送送信装置およびその方法、ディジタル放送受信装置およびその方法
FR2859859A1 (fr) * 2003-09-16 2005-03-18 France Telecom Procede et module de reception de signaux de television
US20050166135A1 (en) * 2004-01-05 2005-07-28 Burke David G. Apparatus, system and method for synchronized playback of data transmitted over an asynchronous network
WO2006105010A1 (en) * 2005-03-25 2006-10-05 Neocific, Inc. Methods and apparatus for cellular broadcasting and communication system
US8213768B2 (en) 2005-03-08 2012-07-03 Panasonic Corporation Packet transmitting apparatus
KR20070027070A (ko) * 2005-08-29 2007-03-09 삼성전자주식회사 방송/통신 결합서비스 정보 송수신 방법 및 장치
JP2007221376A (ja) * 2006-02-15 2007-08-30 Sharp Corp コンテンツ再生装置、放送コンテンツ送信装置、制御データ供給装置、ユーザ属性値供給装置、放送システム、コンテンツ再生方法、及び、放送コンテンツ送信方法
WO2008084947A1 (en) * 2007-01-08 2008-07-17 Sk Telecom Co., Ltd. System and method for synchroning broadcast content with supplementary information
US20080279535A1 (en) * 2007-05-10 2008-11-13 Microsoft Corporation Subtitle data customization and exposure
WO2008141341A1 (en) * 2007-05-14 2008-11-20 Picongen Wireless Inc. Method and apparatus for wireless hdmi clock regeneration
ATE496490T1 (de) * 2007-08-09 2011-02-15 Inlet Technologies Bewahrung von untertiteln durch videotranskodierung
US8776144B2 (en) * 2008-10-16 2014-07-08 Industrial Technology Research Institute Mobile TV system and method for synchronizing the rendering of streaming services thereof
US9986270B2 (en) * 2010-09-21 2018-05-29 Saturn Licensing Llc Reception and transmission of trigger information for application program control
AU2012207719B2 (en) 2011-01-19 2016-05-19 Samsung Electronics Co., Ltd. Apparatus and method for configuring a control message in a broadcast system
EP2498494A1 (en) * 2011-03-11 2012-09-12 Thomson Licensing Decoder and method at the decoder for synchronizing the rendering of contents received through different networks
KR101946861B1 (ko) * 2011-09-21 2019-02-13 삼성전자주식회사 멀티미디어 방송 서비스의 미디어 데이터 동기화 방법 및 장치
KR101353073B1 (ko) * 2011-10-05 2014-04-02 오큐브 주식회사 소셜네트워크서비스를 이용한 오픈 마켓형 종합 쇼핑몰 운영시스템
KR101965385B1 (ko) * 2011-10-10 2019-04-03 한국전자통신연구원 융합형 ３ｄｔｖ에서 컨텐츠 스트림에 접근하는 컨텐츠 제공 장치 및 방법, 그리고 컨텐츠 재생 장치 및 방법
WO2013055164A1 (ko) * 2011-10-13 2013-04-18 삼성전자 주식회사 콘텐츠 디스플레이 방법, 콘텐츠 동기화 방법, 방송 콘텐츠 디스플레이 방법 및 디스플레이 장치
EP3554088B1 (en) 2011-10-13 2024-02-07 Samsung Electronics Co., Ltd. Apparatus and method for configuring control message in broadcasting system
JP5921852B2 (ja) 2011-10-21 2016-05-24 シャープ株式会社 配信装置
JPWO2013061525A1 (ja) * 2011-10-26 2015-04-02 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 放送受信装置、再生装置、放送通信システム、放送受信方法、再生方法およびプログラム
JPWO2013061526A1 (ja) * 2011-10-26 2015-04-02 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 放送受信装置、放送受信方法およびプログラム
EP2611051B1 (en) * 2011-12-29 2014-06-04 Thomson Licensing Method for synchronizing media services
JP5588489B2 (ja) * 2012-10-09 2014-09-10 日立マクセル株式会社 送受信システムおよび情報処理方法
JP2014241520A (ja) * 2013-06-12 2014-12-25 日本放送協会 送信システム、情報送信装置、プラットフォーム装置及び受信装置
JP6510205B2 (ja) * 2013-10-11 2019-05-08 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置および受信装置
WO2015156618A1 (ko) * 2014-04-09 2015-10-15 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012099399A2 (ko) * 2011-01-18 2012-07-26 삼성전자주식회사 방송통신 융합형 서비스를 위한 전송 방법 및 장치
WO2012099359A2 (ko) * 2011-01-19 2012-07-26 삼성전자 주식회사 복수의 실시간 전송 스트림을 수신하는 수신 장치와 그 송신 장치 및 멀티미디어 컨텐츠 재생 방법

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018196132A (ja) * 2013-09-06 2018-12-06 日本放送協会 送信装置、受信装置および限定受信システム
JP2019013026A (ja) * 2013-09-06 2019-01-24 日本放送協会 送信装置
JP2015073267A (ja) * 2013-09-06 2015-04-16 日本放送協会 送信装置、受信装置および限定受信システム
JP2016052008A (ja) * 2014-08-29 2016-04-11 シャープ株式会社 放送信号送信装置、放送信号受信装置、テレビジョン受像機、放送信号伝送システム、制御プログラム、および記録媒体
JP2016052010A (ja) * 2014-08-29 2016-04-11 シャープ株式会社 放送信号送信装置、放送信号受信装置、テレビジョン受像機、放送信号伝送システム、制御プログラム、および記録媒体
EP3304904B1 (en) * 2015-06-03 2022-01-26 Nokia Technologies Oy A method, an apparatus, a computer program for video coding
CN107787586B (zh) * 2015-06-23 2020-12-25 三星电子株式会社 用于在多媒体系统中发送和接收信号的方法和装置
US10880596B2 (en) 2015-06-23 2020-12-29 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving signal in multimedia system
CN107787586A (zh) * 2015-06-23 2018-03-09 三星电子株式会社 用于在多媒体系统中发送和接收信号的方法和装置
CN111711851A (zh) * 2015-07-24 2020-09-25 麦克赛尔株式会社 广播接收装置和接收装置
CN111711851B (zh) * 2015-07-24 2022-11-22 麦克赛尔株式会社 广播接收装置和接收装置
CN113259750A (zh) * 2015-08-06 2021-08-13 麦克赛尔株式会社 广播接收装置
CN107925784A (zh) * 2015-08-06 2018-04-17 麦克赛尔株式会社 广播接收装置、输出影像信息生成方法、广播接收方法和录像方法
CN113259750B (zh) * 2015-08-06 2023-02-03 麦克赛尔株式会社 影像显示装置
CN107925784B (zh) * 2015-08-06 2021-07-09 麦克赛尔株式会社 广播接收装置、输出影像信息生成方法、广播接收方法和录像方法
JPWO2017077881A1 (ja) * 2015-11-05 2018-08-16 ソニー株式会社 コンテンツ再生装置、およびコンテンツ再生方法
WO2017077881A1 (ja) * 2015-11-05 2017-05-11 ソニー株式会社 コンテンツ再生装置、およびコンテンツ再生方法
US10405028B2 (en) 2015-11-05 2019-09-03 Sony Corporation Content reproduction apparatus and content reproduction method
JP2016111717A (ja) * 2016-01-25 2016-06-20 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP2016167861A (ja) * 2016-04-27 2016-09-15 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP5957161B1 (ja) * 2016-04-27 2016-07-27 シャープ株式会社 放送信号送受信システムおよび放送信号送受信方法
JP2016195410A (ja) * 2016-06-17 2016-11-17 シャープ株式会社 放送信号受信装置、放送信号受信方法、制御プログラム、および記録媒体
JP2017143560A (ja) * 2017-03-31 2017-08-17 シャープ株式会社 放送信号送受信システム、および放送信号送受信方法
JP6140381B1 (ja) * 2017-03-31 2017-05-31 シャープ株式会社 放送信号送受信システム、および放送信号送受信方法
US20190017938A1 (en) * 2017-07-12 2019-01-17 Dr. Johannes Heidenhain Gmbh Diffractive biosensor
JP2018196130A (ja) * 2018-07-18 2018-12-06 シャープ株式会社 放送信号送信装置、放送信号送信方法、制御プログラム、および記録媒体
JP2019205206A (ja) * 2019-09-04 2019-11-28 マクセル株式会社 出力制御方法及び放送受信装置

Also Published As

Publication number Publication date
EP3026920A4 (en) 2016-07-06
US10356474B2 (en) 2019-07-16
JP2020031437A (ja) 2020-02-27
US20190281353A1 (en) 2019-09-12
EP3026920B1 (en) 2019-10-30
JP7057411B2 (ja) 2022-04-19
US11102547B2 (en) 2021-08-24
JP7280408B2 (ja) 2023-05-23
JP2015027082A (ja) 2015-02-05
EP3641318A1 (en) 2020-04-22
JP2021057918A (ja) 2021-04-08
CN111314762A (zh) 2020-06-19
EP3026920A1 (en) 2016-06-01
JP2023099620A (ja) 2023-07-13
CN105230026A (zh) 2016-01-06
US20230319355A1 (en) 2023-10-05
CN105230026B (zh) 2020-03-06
JP2022089899A (ja) 2022-06-16
US20160100220A1 (en) 2016-04-07
US11711580B2 (en) 2023-07-25
JP6818848B2 (ja) 2021-01-20
JP6616064B2 (ja) 2019-12-04
US20210345000A1 (en) 2021-11-04

Similar Documents

Publication Publication Date Title
JP7057411B2 (ja) 送信方法および受信方法
US11765414B2 (en) Transmitting method, receiving method, transmitting apparatus, and receiving apparatus
JP7453266B2 (ja) 送信装置
US20130346566A1 (en) Apparatus and method of transmitting and receiving associated broadcasting contents based on heterogeneous network
KR20130050953A (ko) 미디어 파일 송수신 방법 및 그를 이용한 송수신 장치
US10469919B2 (en) Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
JP2015076881A (ja) 送信方法、受信方法、送信装置および受信装置
WO2015052908A1 (ja) 送信方法、受信方法、送信装置および受信装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480027612.8

Country of ref document: CN

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

Ref document number: 14830237

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2014830237

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE