Receiving device

Abstract

To enable quick access to content through communication in reproducing the content using both broadcasting and communication on a receiving side.SOLUTION: A receiving device comprises: a receiving unit that receives content transmitted by using a broadcast wave and a communication path; and a reproducing unit that reproduces the content when receiving control information including information indicating that there is content transmitted through the communication path, and information for reproducing content transmitted by the broadcast wave and the content transmitted through the communication path, the information on the content transmitted through the communication path. The receiving unit uses the broadcast wave to receive a basic layer of the content, and uses the communication path to receive an extension layer. The receiving unit uses the communication path to receive information indicating to which asset of the basic layer an asset of the extension layer corresponds. The receiving unit uses the broadcast wave to receive information indicating the type of the control information of the content transmitted through the communication path.SELECTED DRAWING: Figure 13A

Description

Technical Field

[0001] The present invention relates to a transmission method and a reception method.

Background Art

[0002] Conventionally, the main transmission path for distributing content is a broadcast wave, and as a media transport method widely used in a broadcast system using a broadcast wave, for example, there is MPEG-2 TS (Moving Picture Experts Group-2 Transport Stream).

[0003] On the other hand, with the recent progress of network technology, it has become possible to distribute content using a communication path such as the Internet. That is, content can be distributed not only using a broadcast wave but also using a communication path, and the transmission paths for distributing content are diversified.

[0004] For example, Non-Patent Document 1 discloses MMT (MPEG Media Transport) and the like as a new media transport method assuming distribution of content using both broadcast and communication (see Non-Patent Document 1). For example, Patent Document 1 discloses a technique for accessing communication content based on data obtained from a broadcast, mainly using the broadcast.

Prior Art Documents

Non-Patent Documents

[0005]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] However, in order to distribute content that combines broadcasting and communication and receive the distributed content, although discussions have been made on acquiring information (service information) related to content reception and starting content reception, rapid access operations to content via communication are not considered, and there are problems such as delays in the content reception start timing via communication.

[0007] Therefore, an object of the present invention is to provide a content transmission method that enables rapid access to content via communication when reproducing content that combines broadcasting and communication on the receiving side.

Means for Solving the Problems

[0008] In order to solve the above problems, a receiving apparatus according to an aspect of the present invention includes a receiving unit that receives content transmitted using each of a broadcast wave and a communication path, information indicating that there is the content transmitted via the communication path, and control information including information for reproducing the content by the broadcast wave and the content by the communication path and information related to the content transmitted via the communication path. When the control information is received, the receiving apparatus includes a reproducing unit that reproduces the content. The receiving unit receives the basic layer of the content using the broadcast wave and the extended layer using the communication path. The receiving unit receives, using the communication path, information indicating which asset of the basic layer the asset of the extended layer corresponds to. The receiving unit receives, using the broadcast wave, information indicating the type of control information of the content transmitted via the communication path. The receiving unit receives location information indicating the acquisition destination of the content or information indicating the acquisition destination of the location information.

[0009] Note that these general or specific aspects may be implemented in a data reception method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be implemented in any combination of a data transmission method, a data reception method, an integrated circuit, a computer program, and a recording medium.

Advantages of the Invention

[0010] According to the present invention, it is possible to realize a content transmission method or the like that enables quick access to content by communication when reproducing content that uses both broadcasting and communication on the receiving side.

Brief Description of the Drawings

[0011]

Figure 1A

Figure 1B

Figure 2

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 5

Figure 6A

Figure 6B

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

Figure 12

Figure 13A

Figure 13B

Figure 14

Figure 15

Figure 16A

Figure 16B

Figure 16C

Figure 16D

Figure 17

Figure 18

Figure 19

Figure 20

Embodiments for Carrying Out the Invention

[0012] (Knowledge on which the present invention is based) Currently, a service (broadcast communication cooperation service) that distributes content by using both broadcast and communication in combination is being studied. Among them, a method of accessing content obtained from communication (hereinafter referred to as communication content) based on data obtained from broadcast, with broadcast as the main, is promising. As an operation at the start of viewing on the receiving side for receiving content in the broadcast communication cooperation service, similar to a conventional service that distributes content only by broadcast, after obtaining service information, it is considered to start receiving content by using encoded data of audio or video, or a data carousel in the MPEG-2 system.

[0013] However, in the service information that can be obtained by conventional services, considerations for rapid access operations to communication content and operations when receiving only broadcast content are not taken into account. Therefore, when performing a broadcast communication cooperation service using conventional service information, there are problems such as an increase in processing related to the analysis of service information and a delay in the acquisition start timing of communication content.

[0014] Also, in the hybrid broadcast standard standardized by the IPTV Forum and already adopted in the ARIB standard, considerations for rapid access operations to communication content and operations when receiving only broadcast content are not taken into account.

[0015] In the specifications of conventional hybrid broadcasts standardized by the IPTV Forum and already adopted in the ARIB standard, on the communication side, an HTML5 application is downloaded and the application is started with the firing of an event message. Therefore, it does not support the playback control of communication content based on PTS (Presentation Time Stamp) and DTS (Decoding Time Stamp) in the audio and video frames on the broadcast side, and there are problems such as it being unable to support high-precision synchronous playback such as synchronizing the display times of broadcast content and communication content in frame units.

[0016] In order to solve such problems, a transmission method according to an aspect of the present invention is a content transmission method capable of transmitting content using a broadcast wave and a communication path. When transmitting content using each of the broadcast wave and the communication path, information for synchronizing the content by the broadcast wave and the content by the communication path when received by the receiving side, and information related to the content transmitted by the communication path are included in the application control information, and an information transmission step of transmitting using at least the broadcast wave among the broadcast wave and the communication path is included.

[0017] According to this aspect, it is possible to realize a content transmission method that enables quick access to content by communication when playing content that combines broadcasting and communication on the receiving side. More specifically, when transmitting content using a broadcast wave and a communication path, information for synchronizing between the content transmitted using the broadcast wave and the communication path is included in the application control information and transmitted. Therefore, when the receiving side receives the application control information including this information, the receiving side can be made to quickly access the content by communication according to this information, and the receiving side can be made to synchronize between the contents.

[0018] Here, for example, in the information transmission step, the application control information may be transmitted prior to transmitting the content, and the application control information may further include location information indicating the acquisition destination of the content or information indicating the acquisition destination of the location information.

[0019] Also, for example, in the information transmission step, the application control information may further include difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path.

[0020] Also, for example, in the information transmission step, by transmitting the application control information, the receiving side may be made to synchronize by synchronizing the reference clock of the content by the communication path with the reference clock of the content by the broadcast wave based on the difference information.

[0021] Also, in order to solve the above problems, a receiving method according to an aspect of the present invention includes a receiving step of receiving content transmitted using each of a broadcast wave and a communication path, and application control information that is information for synchronizing the content by the broadcast wave and the content by the communication path and that includes information regarding the content transmitted by the communication path. When the application control information is received from at least the broadcast wave among the broadcast wave and the communication path, a process of taking the synchronization is performed, and a playback step of playing back the content is included.

[0022] Here, for example, in the receiving step, before receiving the content, when the application control information is received and the application control information includes location information indicating a acquisition destination of the content, the content may be received by acquiring the content based on the location information.

[0023] Also, for example, in the receiving step, before receiving the content, when the application control information is received and the application control information includes information indicating an acquisition destination of location information indicating a acquisition destination of the content, the location information is acquired based on the information indicating the acquisition destination of the location information, and the content is received by acquiring the content from the acquired location information.

[0024] Also, for example, in the playback step, in the receiving step, when the application control information including difference information between a reference clock of the content by the broadcast wave and a reference clock of the content by the communication path is received, and when the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path are different, a process of taking the synchronization of the content is performed by synchronizing the reference clock of the content by the communication path with the reference clock of the content by the broadcast wave based on the difference information, and the content may be played back.

[0025] Also, in order to solve the above problems, a transmission device according to one aspect of the present invention is a content transmission device capable of transmitting content using a broadcast wave and a communication path. When transmitting content using each of the broadcast wave and the communication path, information for synchronizing the content by the broadcast wave and the content by the communication path when received by the receiving side, and information related to the content transmitted by the communication path are included in the application control information, and an information transmission unit that transmits using at least the broadcast wave among the broadcast wave and the communication path is provided.

[0026] Also, in order to solve the above problems, a receiving device according to one aspect of the present invention includes a receiving unit that receives content transmitted using each of a broadcast wave and a communication path, and when receiving application control information including information for synchronizing the content by the broadcast wave and the content by the communication path and including information related to the content transmitted by the communication path, performs a process of taking the synchronization and a reproduction unit that reproduces the content.

[0027] Note that these general or specific aspects may be implemented by a transmission method, a transmission device, a reception method, a reception device, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be implemented by an arbitrary combination of a data reception method, an integrated circuit, a computer program, or a recording medium.

[0028] Hereinafter, a transmission method, a reception method, and the like according to one aspect of the present invention will be specifically described with reference to the drawings.

[0029] Note that each of the embodiments described below shows a specific example of the present invention. The numerical values, shapes, materials, components, arrangement positions and connection forms of the components, steps, order of steps, etc. shown in the following embodiments are merely examples and are not intended to limit the present invention. Also, among the components in the following embodiments, components not described in the independent claims indicating the most general concept are described as arbitrary components.

[0030] (Embodiment 1) In this embodiment, a transmission method for transmitting and receiving content in a broadcast communication cooperation service will be described.

[0031] [Transmission Method] In this embodiment, the transmitting side transmits content (data or assets) using a broadcast wave and a communication path, but transmits service information prior to the transmission of the content.

[0032] [Service Information] Here, the service information refers to information for acquiring audio, video, or data related to data broadcasting after a channel selection operation (after channel selection), or a series of information related to the reception of content and the acquisition of metadata, such as EPG (Electronic Program Guide) information.

[0033] Currently, broadcasts are mainly transmitted using sections of MPEG-2 TS (Transport Stream), and include PAT (Program Association Table), PMT (Program Map Table), NIT (Network Information Table), CAT (Conditional Access Table), or EIT (Event Information Table) defined by ARIB (Association of Radio Industries and Businesses).

[0034] In this embodiment, MMT (MPEG Media Transport) standardized by MPEG will be described as an example of the multiplexing format on the broadcast side in a broadcast cooperation service. However, this multiplexing format is not limited to MMT, and other multiplexing formats such as TS or MPEG-DASH (Dynamic Adaptive Streaming over HTTP) may also be used.

[0035] The service information in this embodiment is transmitted in a data structure that can be stored in a multiplexed format. For example, in MMT, the service information is transmitted by tables such as MPT (MMT Package Table) or message information such as PA (Package Access) messages. In each table, similar to TS, auxiliary information can be described using descriptors.

[0036] FIG. 1A and FIG. 1B are diagrams showing an example of the data structure of service information in the broadcast communication cooperation service of Embodiment 1. More specifically, FIG. 1A shows an MPT including a transmission path identifier descriptor, and FIG. 1B shows an example in which information regarding the transmission path of an asset constituting a package is described as attribute information in the transmission path identifier descriptor shown in FIG. 1A.

[0037] (Attribute information) 1) It may be included as attribute information the information indicating whether the asset constituting the package is transmitted by either (1) using only broadcast or (2) using both broadcast and communication.

[0038] Note that the information indicating whether the audio and video data in this main body is transmitted by either (1) using only broadcast or (2) using both broadcast and communication may be used. With this information, even when the main body is transmitted using only broadcast, metadata other than the main body such as audio, video, still images, or HTML files can be obtained from the communication network.

[0039] 2) When the audio and video data are transmitted using both broadcast and communication, it may be included as attribute information the information indicating the relationship between the data transmitted respectively.

[0040] Here, for example, when realizing scalability (temporal resolution (such as 60fps → 120fps), spatial resolution (such as 4k → 8k), bit depth (such as 8bit → 10bit)), it can be indicated by the attribute information that the broadcast uses the base layer and the communication uses the enhancement layer for transmission. Note that the attribute information may indicate that although the frame rate of the broadcast data alone is 60fps, the frame rate can be improved up to 120fps when combined with communication data. Also, it may be indicated that the data for backup of the broadcast is transmitted by communication. Thereby, the transmitting side can switch to transmitting data by communication using the attribute information when the reception status of the broadcast deteriorates due to rain attenuation or the like.

[0041] Also, the attribute information may indicate information for identifying assets related to each other. For example, 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.

[0042] In MMT, it is also possible to transmit the same asset using multiple transmission paths. Therefore, the attribute information may indicate whether the same asset is transmitted using both broadcast and communication. At this time, the identification information (such as asset ID) of the asset may be separately indicated. The information for identifying related assets may be indicated by, for example, an individual transmission path descriptor for each asset as shown in FIG. 2. Here, FIG. 2 is a diagram showing an example of the outline of the transmission path descriptor in Embodiment 1. The individual transmission path descriptor shown in FIG. 2 may indicate information for identifying whether the asset is an asset of the base layer or the enhancement layer, or may indicate the ID of the corresponding asset of the base layer when the asset is an enhancement layer.

[0043] Also, the attribute information may group the broadcast assets and the communication assets respectively, and indicate a list of the assets included in the group. When there are assets transmitted using both broadcast and communication, they may be grouped separately.

[0044] 3) It may also be possible to include, as attribute information, information indicating whether the audio and video transmitted by broadcasting and the audio and video transmitted by communication are played back synchronously.

[0045] Note that 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. Also, the attribute information may be described in a format different from that of the descriptor.

[0046] Also, the transmission path identification descriptor may be stored in a table or message indicating information in package units, which is different from the MPT. Also, the content of the above transmission path identification descriptor may be described in a data structure different from that of the descriptor.

[0047] Also, when transmitting a plurality of packages, a table or message indicating a list of packages may be defined, and information such as the transmission path identification descriptor may be shown as the attribute information of the package in package units.

[0048] FIG. 3A and FIG. 3B are diagrams showing another example of the data structure of service information in the broadcast communication cooperation service of Embodiment 1.

[0049] That is, as shown in FIGS. 3A and 3B, for the location information for each asset, the assets transmitted by broadcasting and communication may be stored in different MPTs respectively. At this time, 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 broadcasting is the entry point, it is stored in the MPT sent by broadcasting. Also, these MPTs can be identified by the table_id.

[0050] In the MMT standard, since the value of the table_id of the reference MPT is defined as zero, it is possible to set the table_id of the MPT corresponding to the transmission path serving as the entry point to zero and set the table_id of the MPT corresponding to the other transmission path to 1 or more.

[0051] Note that the MPT of the broadcast asset may be transmitted by broadcast, and the MPT of the communication asset may be transmitted by communication.

[0052] Also, it may be possible to store the location information of the broadcast and communication assets in one MPT. In this case, the location information of each asset may be stored continuously so that it can be easily identified. For example, when there are N1 broadcast assets and N2 communication assets, first, the information of the N1 broadcast assets is described continuously, and then the information of the N2 communication assets is described continuously. Note that in the transmission path identification descriptor, it may be indicated that N1 assets are transmitted in the broadcast and N2 assets are transmitted in the communication.

[0053] In this way, on the transmission side, the service information is transmitted including the transmission path identification descriptor, which is auxiliary information. As a result, on the reception side, by simply acquiring the service information including the auxiliary information, it is possible to obtain in advance whether communication data is included or the dependency relationship between broadcast data and communication data, etc., based on the attribute information of the package described in the transmission path identification descriptor, without analyzing the information for each asset.

[0054] In particular, when receiving communication data, there is an advantage that the delay time related to the activation of the reception process can be shortened.

[0055] [Transmission device] For example, the transmission device of the present embodiment is a content transmission device capable of transmitting content using a broadcast wave and a communication path, and generates attribute information of a package such as a transmission path identification descriptor as auxiliary information and transmits it included in the service information.

[0056] The transmission device according to this embodiment may transmit this service information periodically. When the content of this service information is updated, the updated content is reflected in the service information immediately after the update.

[0057] Also, the entry point is not limited to broadcasting, and may be communication, or may be configured to allow entry from both broadcasting and communication. When allowing entry from both, for information in package units, at least, it is transmitted from the transmission devices of both broadcasting and communication.

[0058] Note that when receiving the content of the broadcast communication cooperation service on the receiving side, it is not always necessary to receive the data sent by both transmission paths. For example, it may be sufficient to receive and play only the broadcast data. At this time, since the information required when the receiving side receives communication data is unnecessary when receiving broadcast data, the transmitting side may transmit the information required when receiving communication data in communication. That is, the transmitting side may transmit information in package units on the transmission path that serves as the entry point, and information specific to the transmission path such as broadcasting and communication may be transmitted on each transmission path (for example, FIG. 2). In the following, it will be described assuming that the broadcast is the entry point.

[0059] By doing so, the service information specific to each transmission path can be generated and transmitted by the transmission device on each transmission path. However, information transmitted by MPT such as the location information of the asset may be transmitted by broadcasting because the delay time related to the start of acquisition of the asset on the communication side can be reduced by acquiring it all at once first.

[0060] (Examples of information specific to communication) Examples of information specific to communication (communication networks such as the Internet and CDN (Contents Delivery Network)) are shown.

[0061] 1) Information related to FEC (Forward Error Correction) in packets transmitted by communication, such as, for example, the FEC method, parameters, etc. 2) Information related to QoS (Quality of Service) control, such as, for example, packet loss rate, jitter of packet arrival time, or RTT (Round Trip Time), end-to-end delay in the communication transmission path, etc. 3) Information related to buffering from the reception of asset data until the start of decoding, such as, for example, buffering time, buffering amount, etc.

[0062] Note that also in broadcasting, especially in broadcasting for mobile devices (such as one-segment broadcasting in Japan), FEC and QoS are important, but the parameters in these are different from those of the communication path. Therefore, information specific to broadcasting may be transmitted only in broadcasting.

[0063] On the other hand, in communication, it is possible to select a plurality of audio and video data according to the bandwidth of the communication network, such as bit rate and frame rate. At this time, information associating the attribute information (such as bit rate) of the selectable data with the asset ID may be transmitted. Note that such associating information may also be transmitted in broadcasting.

[0064] Note that as the associating information, information indicating whether there are a plurality of selectable assets may be shown, or when there are a plurality of selectable assets, a list of selectable assets may be shown.

[0065] [Receiving Method] In this embodiment, the receiving side starts receiving (acquiring) the content after acquiring the service information. Hereinafter, the receiving method in this embodiment will be described with reference to the drawings.

[0066] FIG. 4A is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Embodiment 1. FIG. 4A shows an example of the operation in which the receiving apparatus acquires the transmission path identifier descriptor of the present embodiment and determines the asset to be received.

[0067] First, as service information transmitted on the transmission path serving as an entry point, for example, an MPT table included in a PA message or an MPT message is acquired, and the transmission path identifier descriptor included therein is acquired.

[0068] Next, information of the transmission path identifier descriptor, such as whether an asset is transmitted using both broadcast and communication and, when both transmission paths are used, the dependency relationship between the broadcast and communication assets, is interpreted (step S101).

[0069] Messages such as PA messages are stored in the payload of packets such as MMT packets, and the packet header indicates the type of data to be stored. Therefore, when receiving an MMT package, first, the ID number (corresponding to packet_id in the MMT packet) in the packet header is referred to, and the MMT packet of the PA message is acquired.

[0070] Next, based on, for example, the playback ability of the terminal or whether the communication path is available, the asset to be received is determined (step S102).

[0071] Here, an example of the method for determining an asset will be described.

[0072] 1) When the receiving apparatus is not connected to the communication network, it is determined that only the broadcast asset is received. At this time, the asset transmitted using both broadcast and communication is not received.

[0073] 2) When the basic layer of the video is transmitted by broadcast and the extended layer is transmitted by communication, if only the basic layer is playable, it is determined to receive only the broadcast, and if both layers are playable, it is determined to receive both the broadcast and the communication. For example, assume that time scalability of 60 fps with only the basic layer and 120 fps with both the basic layer and the extended layer can be achieved. In this case, if the receiving device can only decode and display up to 60 fps, it receives only the broadcast, and if it can decode and display up to 120 fps, it receives both the broadcast and communication data.

[0074] 3) According to the bandwidth of the communication network to which the receiving device is connected, a receivable asset is determined from a plurality of assets with different bitrates transmitted by communication. Here, for example, information such as the bitrate of each asset is transmitted separately in service information or the like. In addition, when the reception state is poor due to congestion of the communication network or the like and there is no asset that can be stably received, it may be determined not to receive the data on the communication side.

[0075] 4) Also, in preparation for deterioration of the broadcast reception environment, when backup data is being transmitted in communication, it may be determined to determine the asset to be acquired when the reception environment deteriorates. In this case, the receiving device monitors the reception environment, determines whether to receive the communication asset based on an index such as the error rate in the received data, and may perform reception processing.

[0076] 5) When receiving data (such as data of the extended layer in video) that is synchronously played with the audio or video data of the main body transmitted by broadcast from communication, in order to ensure the synchronization of the data received by broadcast and the data received by communication, special operations such as buffering the data before the start of playback may be required. In this case, from communication, it may be determined to receive only assets that do not require strict synchronization (such as synchronization in units of frames) with the data transmitted by broadcast. For example, it may be determined to acquire from communication assets such as data like HTML, still images, and videos that do not require strict synchronization.

[0077] Next, return to the flowchart of FIG. 4A for description.

[0078] Next, in step S103, it is determined (judged) whether to receive the asset transmitted by communication. If it is determined (judged) to receive (yes in S103), the process proceeds to S104. If it is determined (judged) not to receive (no in S103), the process proceeds to S105.

[0079] In S104, the asset is received from both the broadcast and communication transmission paths. In S105, the asset is received only from the broadcast.

[0080] FIG. 4B is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperation service of Embodiment 1.

[0081] Compared with FIG. 4A, in FIG. 4B, when service information specific to communication is transmitted in communication, a step (step S106) of receiving the service information is added. Since other aspects are the same as those described in FIG. 4A, the description is omitted.

[0082] Note that if there is service information specific to broadcast, it shall be separately received in steps not shown.

[0083] Also, if the receiving device does not support the broadcast communication cooperation service, it may only receive the broadcast asset. In this case, if there is an asset transmitted using both broadcast and communication, the asset is not received.

[0084] [Receiving Device] FIG. 5 is a block diagram showing an example of the configuration of the receiving device in Embodiment 1. FIG. 5 shows an example of the configuration of the receiving device that realizes the receiving method described in FIG. 4A.

[0085] The receiving device 100 shown in FIG. 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.

[0086] 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 in the transmission path serving as an entry point, and acquires a transmission path identification descriptor (auxiliary information) included therein. Then, the identification information acquisition unit 11 interprets the information of the transmission path identification descriptor.

[0087] 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 ability of the terminal or whether the communication path is available or the like.

[0088] The determination unit 103 has a function of realizing step S103 shown in FIG. 4A, and determines (judges) whether to receive the asset transmitted by communication. Specifically, the determination unit 103 determines whether to receive communication data, and if it is determined to receive, in the broadcast reception unit 104 and the communication reception unit 105, the data of the asset determined in step 102 is received.

[0089] If the determination unit 103 determines not to receive the communication data, the data is received using only the broadcast reception unit 14.

[0090] (Modification Example 1) In this modification example, an example in which the broadcast is transmitted using TS and the communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like will be described.

[0091] FIGS. 6A and 6B are diagrams showing an example of the data structure of service information in the broadcast communication cooperation service of Modification Example 1 of Embodiment 1. FIG. 6A shows an example in which information regarding 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 example.

[0092] In this modified example, a transmission path identification descriptor indicating attribute information and the like described in FIGS. 1A and 1B is stored in the PMT, which is an example of service information.

[0093] In program information such as PMT in the TS, only the location information of the data transmitted by the TS is shown. Therefore, in this modified example, when the content data is transmitted using a combination of communications, the location information of the data on the communication side is stored in the transmission path identification descriptor. More specifically, the attribute information includes flag information indicating whether communication is used in combination. Thereby, the transmission side can select whether to include the location information of the data on the communication side according to the value of the flag information. Note that the location information is not limited to being stored in the transmission path identification descriptor. A separate descriptor may be defined to store the location information.

[0094] (Location Information) Location information is information indicating the acquisition destination of data. In the case of a TS, it corresponds to a PID, and in the case of communication, it corresponds to a URL, URI, or the like.

[0095] As the location information, the MPD (Media Presentation Description) of DASH, the SDP (Session Description Protocol) in RTP, or the like may be stored.

[0096] Also, the location information is not limited to storing the actual data of the location information such as MPD and SDP, and information indicating the acquisition destination of the actual data of the location information may be stored. Here, the information indicating the acquisition destination of the actual data of the location information is, for example, information indicating a URL for acquiring the MPD. However, when information indicating the acquisition destination of the actual data of the location information is stored in the location information, a delay occurs for separately acquiring the actual data of the location information. Therefore, from the viewpoint of reducing the delay until the reception of the data on the communication side starts, it is desirable to directly store the actual data in the location information.

[0097] Note that since the MPD of DASH contains various information regarding the content acquisition destination, it is large in size. Therefore, instead of storing the MPD as it is in the location information, it may be possible to store a subset of information that only includes the URL of the content acquisition destination and information regarding the DTS and PTS of the segments.

[0098] Also, it is desirable to be able to support updates to the content of location information such as MPD.

[0099] For example, a version number may be assigned to the location information. As a result, when the version number is updated, the location information can be retrieved again. In addition, in order to confirm whether the version number has been updated, information such as the transmission path identification descriptor in the PMT that is periodically transmitted may be sequentially checked. However, since this sequential check process is heavy, it may be possible to separately generate section data for storing location information etc. (referred to as a transmission path identification section) and transmit it periodically.

[0100] In the receiving device, by checking the version number in the transmission path identification section, it is possible to determine whether the location information has been updated. Note that in both the program information such as PMT and the transmission path identification section, attribute information and location information may be transmitted. Alternatively, in the transmission path identification section, only the location information may be stored.

[0101] Also, after starting to acquire communication-side data based on the location information obtained from the broadcast, it may be possible to acquire the updated content of the location information in the communication. At this time, since the location information acquisition destination is required, in the transmission path identification descriptor of the broadcast etc., the location information acquisition destination may be stored together with the actual data of the location information.

[0102] In the receiving device, the updated content can be obtained in communication by periodically accessing the location information acquisition source.

[0103] Also, when there is a mechanism such as message exchange between the DASH content distribution server and the receiving device, the server may issue a message indicating that the location information has been updated to the receiving device. And in the receiving device, when receiving the message, the location information may be reacquired.

[0104] Note that although it has been described that information regarding data transmitted in communication is stored in the PMT, it is not limited to this. The attribute information and location information may be transmitted by a section different from the PMT.

[0105] Also, based on whether the data transmitted in communication is synchronously reproduced with the audio or video in the broadcast, the acquisition method of the data on the communication side may be switched.

[0106] For example, when synchronously reproduced, access to the data on the communication side can be enabled from the program information of the broadcast as described above. When not synchronously reproduced, information for accessing the data on the communication side may be transmitted by data broadcast using the AIT (Application Information Table) defined in the hybrid cast specification in ARIB (Association of Radio Industries and Businesses). In the receiving device, the AIT is received in the form of a table or a carousel, etc., and the data on the communication side is acquired based on the content of the AIT. When an event message transmitted by data broadcast is received for the acquired data on the communication side, the reproduction is started.

[0107] Note that even when the broadcast data and the communication data are synchronously reproduced, information such as the AIT may be used. At this time, the times such as the start and end of reproduction of the data on the communication side shall be separately indicated in the data broadcast. In the receiving device, the data on the communication side is reproduced according to these times.

[0108] In MPD in DASH and SDP in RTP, it is possible to indicate the content playback start time or the decoding start time, and these times are specified based on a reference clock defined for each multiplexing or transmission method, such as UTC (Coordinated Universal Time). Also, the PTS (Presentation Time Stamp) and DTS (Decoding Time Stamp) of individual video frames and audio samples are set based on the reference clock. On the other hand, in broadcasting, since the PCR (Program Clock Reference) serves as the reference clock, when synchronously playing back the data on the broadcasting side and the data on the communication side, information indicating the correspondence relationship between their reference clocks is required.

[0109] Therefore, information indicating the correspondence relationship between the reference clocks of the data on the broadcasting side and the data on the communication side may be included in program information such as PMT in broadcasting. For example, it may be information such as the time when the value of PCR in broadcasting is N1 corresponds to the time when the value of UTC in communication is N2. Note that this information may also be included in MPD, SDP, etc.

[0110] Also, in the transmission path identifier descriptor, information on the transport layer protocol, such as whether the data on the communication side is transmitted by UDP (User Datagram Protocol) or TCP (Transmission Control Protocol), may be indicated. Thereby, in the receiving device, it becomes possible to open the ports used in each protocol or to determine whether it corresponds to the protocol used.

[0111] Also, by indicating the identification information of the multiplexing format in the data on the communication side, it may be possible to identify whether it is, for example, DASH or RTP.

[0112] [Receiving Method] Next, using the figures, as a reception method in this modification example, an example of the operation of a receiving apparatus will be described when broadcasting is transmitted using TS and communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like.

[0113] Figure 7A is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 1 of Embodiment 1. Figure 7A shows an example of the operation of the receiving apparatus when attribute information and location information are stored in the program information of the broadcast.

[0114] The operations of each step (Steps S201 to S205) are the same as those in the flowchart of Figure 4A. However, in Figure 4A, the data on the broadcast side and the communication side were unified in the asset of the MMT package, whereas in Figure 7A, the broadcast side is TS and the communication side is DASH or RTP data, which is different. Since the other points are as described in Figure 4A, detailed description is omitted.

[0115] Figure 7B is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 1 of Embodiment 1. Figure 7B shows an example of the operation when access information for acquiring attribute information and location information is stored in the program information of the broadcast and the entity of the location information is not stored.

[0116] Step S301 is the same as Step S201, so the description is omitted.

[0117] Next, in Step S302, it is determined whether to receive the data on the communication side. If it is determined to receive the data on the communication side in Step S303, the process proceeds to S304. If it is determined not to receive the data on the communication side, the process proceeds to S306.

[0118] In Step S304, the location information is acquired according to the acquisition destination of the location information of the communication-side data included in the program information of the broadcast.

[0119] On the other hand, in step S305, communication-side data is acquired based on the location information acquired in S304, and broadcast data is acquired. Also, in S306, only the data transmitted by broadcast is acquired.

[0120] (Attribute information) The attribute information is the same as that described in Embodiment 1. However, since MMT was used as an example in Embodiment 1, an example in the case where the broadcast is TS and the communication uses DASH or RTP will be described below.

[0121] 1) It may be included as attribute information the information indicating whether the data such as audio and video constituting the content is transmitted by either (1) using only broadcast or (2) using both broadcast and communication.

[0122] Note that it may be the information indicating whether the audio and video data is transmitted by either (1) using only broadcast or (2) using both broadcast and communication. With this information, even when the main body is transmitted using only broadcast, the metadata such as audio, video, still images, or HTML files can be acquired from a communication network different from the main body.

[0123] 2) It may be included as attribute information the information indicating the relationship between the data transmitted respectively when audio and video are transmitted using both broadcast and communication.

[0124] Here, for example, when realizing scalability (temporal resolution (60fps → 120fps, etc.), spatial resolution (4k → 8k, etc.), bit depth (8bit → 10bit, etc.)), it can be shown that the broadcast uses the base layer and the communication uses the enhancement layer for transmission according to the attribute information. The attribute information may indicate, as a use case, that the frame rate is 60fps with only broadcast data, but can be improved up to 120fps when using communication data in combination. Also, the attribute information may indicate that data for backup of the broadcast is transmitted via communication. Thereby, the transmitting side can switch to transmitting data via communication when the reception status of the broadcast deteriorates due to rainfall attenuation or the like, using the attribute information.

[0125] Also, the attribute information may indicate information for identifying encoded streams related to each other. For example, the attribute information can indicate the PID of the TS packet storing the data of the base layer transmitted by broadcast, the segment in the DASH data transmitted by communication, or the identification information of video data such as the track ID in MP4.

[0126] Also, the attribute information may indicate information indicating the data on the broadcast side and the data on the communication side that are synchronously played back with each other. Thereby, the transmitting side can transmit videos of multiple viewpoints, or videos of the parent screen and the child screen in a picture-in-picture, respectively, by broadcast and communication.

[0127] 3) It may also be included as attribute information the information indicating whether the audio, video, etc. transmitted by broadcast and the audio, video, etc. transmitted by communication are synchronously played back.

[0128] 4) It may also be included as attribute information the information indicating whether the clock information of the audio and video transmitted by broadcast and the clock information of the audio and video transmitted by communication are the same.

[0129] 5) It may also be possible to include, as attribute information, information indicating whether the data on the communication side is live content.

[0130] For example, if the content to be transmitted is not live content, data after the current time (T1) can be acquired. Therefore, by starting to receive from the data whose playback time is the time (or its estimated value) obtained by adding the total time (ΔT) required from the content acquisition request until the start of reception and the time for buffering the data to the current time (T2), the broadcast-side data can be played back without delay. At this time, the communication-side data is played back from time T2. On the other hand, when the content to be transmitted is live content, it may be possible to buffer the broadcast-side data by ΔT and start playing back both the broadcast and communication data at time T2.

[0131] Note that when the communication side multicasts or broadcasts the content using RTP or the like, data after the current time cannot be acquired regardless of whether the content is live content. Therefore, information indicating whether the communication-side data is multicast or broadcast may also be included in the attribute information.

[0132] [Receiving device] Next, an example of the configuration of a receiving device will be described when the broadcast is transmitted using TS and the communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like.

[0133] FIG. 8 is a block diagram showing an example of the configuration of a receiving device in Modification 1 of Embodiment 1. FIG. 8 shows an example of the configuration of a receiving device that realizes the receiving method described in FIG. 7B.

[0134] The receiving device 300 shown in FIG. 8 includes an identification information acquisition unit 301, a determination unit 302, a communication combined use determination unit 303, a Loc information acquisition unit 304, a broadcast receiving unit 305, and a communication receiving unit 306. Note that the configuration of the receiving device that realizes the receiving method for realizing FIG. 7A corresponds to the case where the Loc information acquisition unit 304 is not present in FIG. 8.

[0135] The identification information acquisition unit 301 has a function for realizing step S301 shown in FIG. 7B. Specifically, the identification information acquisition unit 301 acquires service information transmitted on the transmission path serving as the entry point, and acquires the transmission path identification descriptor (auxiliary information) included therein. Then, the identification information acquisition unit 301 interprets the information of the transmission path identification descriptor.

[0136] The determination unit 302 has a function for realizing step S302 shown in FIG. 7B, and determines the data to be received based on the playback ability of the terminal or whether the communication path is available.

[0137] The communication combined use determination unit 303 has a function for realizing step S303 shown in FIG. 7B, and determines (judges) whether to receive the data transmitted by communication.

[0138] The Loc information acquisition unit 304 has a function for realizing step S304 shown in FIG. 7B, and acquires the location data of the communication side data.

[0139] (Modification Example 2) In this modification example, an example of a receiving method in the case where attribute information and location information are stored in and transmitted with the broadcast program information will be described.

[0140] [Receiving Method] FIG. 9 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 2 of Embodiment 1. FIG. 9 shows an example of the operation until the receiving device determines whether to synchronously play the broadcast content and the communication content and plays them when the attribute information and the location information are stored in and transmitted with the broadcast program information.

[0141] Note that the operation in FIG. 9 is based on the operation in FIG. 7A, and is described as an example when the transmitted data is not an MMT asset but more general content.

[0142] First, obtain the program information transmitted on the transmission path serving as the entry point, obtain the transmission path identifier descriptor included therein, and obtain the attribute information of the content and the location information of the communication content (step S401).

[0143] Here, when the entity of the location information is not stored in the program information, obtain the entity data of the location information by the same method as described in FIG. 7B.

[0144] Next, determine the data to be received based on the playback ability of the receiving device or whether the communication path is available (step S402).

[0145] Next, determine whether to obtain the communication content (step S403). If it is determined to obtain the communication content (yes in S403), proceed to step S404 and receive data from both the broadcast and communication transmission paths. Note that if it is determined (judged) not to receive (no in S403), proceed to step S409, receive data only from the broadcast, and play back only the broadcast content in step S410.

[0146] Next, determine whether to synchronously play back the broadcast content and the communication content (step S405).

[0147] If it is determined to synchronously play back (yes in S405), synchronize the reference clocks of the broadcast content and the communication content in step S406, and synchronously play back both in step S407.

[0148] Note that the synchronization of the reference clock in S406 may be performed prior to S404. This is because, for example, when starting playback after pre-buffering the received data of the content, it may be necessary to confirm that the data with PTS = T1 in the broadcast content and the data with PTS = T1 in the communication content (assuming that their PTSs are already synchronized) have been received, and then start decoding and playback. When determining whether the data to be synchronously played back is complete, it is necessary for the reference clocks of both to be synchronized.

[0149] Also, in the synchronization of the reference clock in S406, it can be aligned with the reference clock used in either broadcast or communication. For example, when PCR (Program Clock Reference) is used in broadcast and NTP (Network Time Protocol) is used in communication, the DTS and PTS based on the NTP reference in video and audio can be converted to the PCR reference to synchronize the reference clocks in broadcast and communication. Also, the DTS and PTS of broadcast and communication may be converted to synchronize with the unique clock used within the receiving device.

[0150] Note that in FIG. 9, the operation when the attribute information and location information are stored in the broadcast program information and transmitted is described. However, if synchronous playback is not necessary in the first place, the transmission path identification descriptor describing these information may not be stored in the broadcast program information.

[0151] Also, in synchronizing the reference clock, it is possible to align it with the clock used in either broadcasting or communication. For example, when PCR (Program Clock Reference) is used in broadcasting and NTP (Network Time Protocol) is used in communication, the DTS and PTS based on the NTP reference in video and audio can be converted to the PCR reference to synchronize the reference clocks in broadcasting and communication. Note that the DTS and PTS of broadcasting and communication may be converted to synchronize with the unique clock used within the receiving device.

[0152] [Receiving device] FIG. 10 is a block diagram showing an example of the configuration of the receiving device in Modification 2 of Embodiment 1. FIG. 10 shows an example of the configuration of the receiving device that realizes the receiving method described in FIG. 9.

[0153] The receiving device 400 shown in FIG. 10 includes an identification information acquisition unit 401, a determination unit 402, a communication sharing determination unit 403, a Loc information acquisition unit 404, a broadcast receiving unit 405, a communication receiving unit 406, a synchronization determination unit 407, and a playback unit 408.

[0154] The identification information acquisition unit 401 to the communication receiving unit 406 are the same as the identification information acquisition unit 301 to the communication receiving unit 306 described in FIG. 8, so the description is omitted.

[0155] The synchronization determination unit 407 has a function of performing the process of step S405 shown in FIG. 9.

[0156] The playback unit 408 decodes and plays back the broadcast content or the communication content based on the playback method determined by the determination results in the communication sharing determination unit 403 and the synchronization determination unit 407 means.

[0157] (Modification 3) Hereinafter, those different from the above-described ones will be described as other examples.

[0158] [Other 1] The transmission path is not limited to a combination of broadcasting and communication, and may be a combination of the same type of transmission paths such as broadcasting and broadcasting, communication and communication.

[0159] Also, when information in units of packages such as a transmission path descriptor is not shown, by interpreting the location information for each asset as shown in FIGS. 1A and 1B, it can be determined whether each asset is transmitted by broadcasting or communication, or whether there is an asset transmitted by communication within the package.

[0160] (Location information) The location information may include URL information of the acquisition destination of the asset. When the acquisition destination is a URL, it can be determined whether the asset is transmitted by broadcasting or communication based on whether the URL is a specific URL defined in advance in the broadcast service.

[0161] For example, when a broadcast asset is transmitted in the same stream as message information such as MPT, in the location information, as the acquisition destination of the broadcast asset, the ID of the packet storing the asset data (packet_id in the case of an MMT packet) is shown, and for an asset transmitted by communication, a URL is shown as the acquisition destination. Therefore, in the location information, it may be determined whether the asset is transmitted by communication according to whether the acquisition destination is a URL.

[0162] (Modification example of MPT description) In FIGS. 1A and 1B above, the case where the location information for each asset and individual transmission path descriptors are defined as information for each asset has been described, but it is not limited thereto. A field indicating the encoding method of the asset may be provided separately. The encoding method is essential information at the time of decoding, and it is desirable to signal it in information that can be acquired prior to decoding such as MPT. For example, it is possible to use information such as stream_type in the MPEG-2 system.

[0163] Also, in the case of an encoding method that enables scalable encoding, in addition to the encoding method, it may be indicated whether the asset is a base layer or an enhancement layer.

[0164] Also, in the same MMT package, there may be cases where multiple assets with scalability are included, such as when there are two videos with temporal scalability. At this time, information indicating which base layer asset the enhancement layer asset corresponds to may be shown. For example, for an enhancement layer asset, the asset ID of the corresponding base layer asset may be shown. Also, the assets of the enhancement layer and the base layer may be grouped, and a group ID may be assigned to each asset.

[0165] These pieces of information can be shown in program information such as in the case of broadcasting using TS and communication using DASH, RTP, etc. For example, in a PMT descriptor or the like, the dependency relationship between the video stream transmitted by broadcasting and the video stream transmitted by communication (such as the video stream on the communication side corresponding to the enhancement layer), or information indicating the encoding method of the video or audio on the communication side can be described. Also, it may be indicated whether the stream on the broadcasting side and the stream on the communication side are synchronously reproduced.

[0166] (Information regarding the transmission path) Information indicating whether the content data is transmitted only by broadcasting or transmitted using both broadcasting and communication may be stored in program information such as the EPG.

[0167] For example, when making a viewing selection or a recording reservation from the EPG, if the data transmitted by communication cannot be played or recorded, such as when not connected to a communication network or when the receiving device does not support data acquisition by communication, message information indicating that may be displayed.

[0168] Furthermore, it may store information indicating whether data transmitted by communication can be acquired prior to the start time of a program. In particular, in a download-type system such as DASH, by downloading communication-side data prior to the start of a program, it is possible to start playing back both broadcast data and communication data at the program start time.

[0169] For example, if communication-side data can be acquired prior to the program start time, the receiving device may start receiving the communication-side data before the program start time. At this time, the reception start time is determined so that the predetermined buffering data amount or the data for the buffering time can be received at the program start time.

[0170] Also, for example, it may operate in the same manner in program reservation recording and the like.

[0171] In broadcasting, etc., a user can select a plurality of programs at an arbitrary timing, and even if communication data for the next program of the currently viewed channel is received in advance, if the viewed program is switched, no merit is obtained even if the communication data is received in advance. Therefore, at an arbitrary viewing time, for all programs that can be viewed after the viewing time and for which data is transmitted using both broadcasting and communication, it may operate so as to buffer communication-side data in advance. If it is not possible to receive data for all programs, programs may be selected and received within the receivable range.

[0172] Also, information indicating whether the broadcast-side data and the communication-side data are played back synchronously is also included in program information such as an EPG. If they are played back synchronously, it may operate so as to buffer the communication-side data in advance. If they are not played back synchronously, the reception of the communication-side data may be started after the reception of the broadcast-side data is started.

[0173] Note that even if such information is not included in the EPG, similar information can be obtained by analyzing MPT in MMT or PMT when using TS for broadcasting, etc., and a similar message can be displayed.

[0174] In addition, in control information when demodulating signals transmitted on a transmission path, such as TMCC signals in the broadcasting system (ISDB-T) in Japan, these pieces of information may be stored.

[0175] By doing so, it is possible to determine at the time of demodulation whether reception in communication is necessary, and it is possible to accelerate the startup of the communication side.

[0176] (Format) Note that the HTTP-based file format is not limited to DASH, and may be HTTP Live Streaming (HLS), Microsoft Smooth Streaming (MSS), etc. In these systems as well, since there is content management information corresponding to MPD, the relationship between the data on the broadcasting side and the data on the communication side can be shown by the same mechanism as DASH.

[0177] Also, on the communication side, a TS stream may be used, or a format in which a field indicating a 4-byte timestamp is added to the head of a TS packet may be used. Here, the TS with a timestamp is used in many standards such as BD (Blu-ray (registered trademark) Disc) and the IPTV forum.

[0178] [Others 2] (Attribute information and location information) In the attribute information and location information, the attributes of the entire content and the individual attributes of streams such as audio and video may be stored separately.

[0179] For example, when using DASH on the communication side, it may be possible to store the attribute information of the entire content, such as whether the broadcast content and the communication content are synchronously played, or whether the broadcast content is the basic layer of scalability and the communication content is the extended layer, in a transmission path identifier descriptor or the like. On the other hand, it may also be possible to store the individual attributes of each stream, such as information for identifying videos and audios that are the targets of synchronous playback, in the MPD.

[0180] As an example of the attributes of each stream, when associating the video in the broadcast with the audio of the secondary audio transmitted in the communication, in the MPD, the PID of the TS packet storing the video and the information for identifying the audio track, segment, or Adaptation Set or Representation in the DASH data, such as the audio track ID, may be associated with each other. Here, as the identification information of the media on the broadcast side, in addition to the PID, the ID of the transport stream including the TS packet of the PID, the service ID, etc. may also be included.

[0181] Note that the content of the MPD may be updated, and the update information is managed by the DASH content delivery server. Therefore, by describing particularly the individual attributes of the stream in the MPD, it is possible to achieve both the merit of reducing the information exchange between the broadcast content sending device and the communication content sending server, and the merit of being able to quickly start the communication content reception start process by storing the overall attributes in the information obtained at the start of broadcast reception, such as the PMT.

[0182] Also, both the overall attributes and the individual attributes may be described either in a descriptor such as the PMT in the broadcast or in the MPD, or in both. For example, in the broadcast, it may be described in a descriptor of application control information such as the AIT.

[0183] (Attribute Information) Furthermore, information on a method for synchronizing clock information of streams transmitted over different transmission paths such as broadcasting and communication may be included in the attribute information. In this case, the receiving device may perform clock synchronization based on this information.

[0184] For example, information for identifying the following three methods may be described as attribute information.

[0185] Method 1) The streams to be synchronized are based on a common clock, and synchronization of their respective clocks is not required.

[0186] Method 2) Synchronize based on clock synchronization information transmitted separately from the stream, such as a descriptor in the PMT.

[0187] Method 3) Synchronize by referring to an independent stream containing information for clock synchronization, such as the time line extension of the TS currently being standardized in MPEG (13818-1:2013 / AMD6(2nd WD)).

[0188] In Method 3, the PID of the TS packet storing the stream for clock synchronization may be included in the attribute information.

[0189] (Modification Example 4) As a new service that combines broadcasting and communication, there is a hybrid cast standard that has been standardized in the IPTV Forum and is also adopted in the ARIB standard.

[0190] In the conventional hybrid cast specification that has been standardized in the IPTV Forum and is also adopted in the ARIB standard, the relationship between the broadcast service and the communication service is made to function based on the application control information (AIT: Application Information Table).

[0191] However, in the conventional hybrid cast specification, on the communication side, an HTML5 application is downloaded and the application is started when an event message is fired or the like. Therefore, the conventional hybrid cast specification does not support the reproduction control of communication content based on PTS (Presentation Time Stamp) or DTS (Decoding Time Stamp) in the audio or video frames on the broadcast side, and cannot support high-precision synchronous reproduction such as synchronizing the display times of broadcast content and communication content in frame units.

[0192] In this modified example, an explanation will be given of a mechanism for synchronously reproducing broadcast content and communication content with high precision by expanding the conventional hybrid cast specification.

[0193] Below, an explanation will be given of the expansion of application control information that enables high-precision synchronous reproduction, and then, the transmission method, reproduction method, etc. in this modified example will be explained.

[0194] [Execution Mode] In the application control information of this modified example, information indicating the execution mode when the application is executed is newly introduced. There are Mode 1 and Mode 2 for the execution mode, and examples of the execution mode are shown below.

[0195] (Mode 1) Mode 1 is an execution mode that does not require high-precision synchronization with other content.

[0196] Also, in Mode 1, like an application conforming to the conventional hybrid cast standard, control codes such as AUTOSTART, PRESENT, PREFETCH, etc., or an event message is used to start or perform a state transition. In Mode 1, synchronous reproduction with reference to PTS or DTS of other audio or video streams is not necessary.

[0197] For example, as an application example in a conventional hybrid cast standard, there is VOD (Video On Demand). In this VOD, when the application is launched, a UI with a play start button and the like is displayed. When the user presses the play start button, the content is downloaded or streaming is started for playback.

[0198] (Mode 2) Mode 2 is an execution mode that requires high-precision synchronization with content transmitted over a transmission path other than the broadcast wave.

[0199] In Mode 2, for example, video in a broadcast and audio acquired by an application are played back in synchronization with each other's PTS. Also, for example, when video scalability is applied, in the data of the base layer transmitted by broadcast and the enhancement layer acquired by the application, DTS and PTS synchronized with each other are used for decoding and display respectively. Here, streams such as audio and video that are played back in synchronization with each other are acquired with reference to the attribute information of the content described above.

[0200] (Operation of the application in Mode 2) In the application, based on the above execution mode, the playback method of the content on the communication side is determined. Since the operation in Mode 1 is the same as the conventional one, the description is omitted. Hereinafter, the operation of the application in Mode 2 will be described.

[0201] The basic operation when synchronously playing back broadcast content and communication content is as shown in the flowchart of FIG. 9.

[0202] If, after clock synchronization, the communication content is only decoded and played back according to the DTS and PTS converted to the synchronized clock, the processing of the communication content can be carried out independently of the playback processing of the broadcast content.

[0203] On one hand, when spatial scalability is applied in video and the basic layer is transmitted via broadcast and the enhancement layer is transmitted via communication respectively, it is necessary to integrate and control the decoding processes of broadcast content and communication content because the enhancement layer is decoded using the decoding result of the basic layer. Also, when both the broadcast content and the communication content are pre-buffered before starting playback, or when the reception buffer of either content overflows or underflows during playback, it is also necessary to integrate and control the playback processes of both transmission paths. For example, when the data reception on the overflow side is stopped, or when an underflow occurs, processes such as stopping the playback processes of both the broadcast content and the communication content until data of a predetermined time length or a predetermined data size can be received are performed.

[0204] Here, when integrally controlling at least any one of the processes from reception to decoding and playback on both transmission paths, there is a transfer of control commands between the communication-side application and the playback processing unit of the broadcast content. For example, it operates according to control commands such as the following.

[0205] 1) Related to decoding processing: For example, it operates according to a control command that requests and acquires data of an access unit corresponding to a specific DTS or PTS. Note that only at the start of playback, an access unit synchronized between broadcast and communication is acquired, and thereafter, a control command that requests and acquires data of the immediately subsequent access unit in ascending order of DTS or PTS may also be used.

[0206] 2) Related to data reception: It operates according to a control command that instructs the stop and restart of data reception or communicates that a data amount satisfying a predetermined condition has accumulated in the buffer for pre-buffering. Note that at the time of stopping and restarting data reception, the subsequent processes such as decoding and playback may be stopped and restarted, or control commands for specific subsequent processes may be separately defined.

[0207] In addition, in the operation of the application in Mode 2, as measures against buffer overflow and underflow in the pre-buffering buffer, there are roughly two countermeasures: waiting until the data on both transmission paths is aligned and then playing back, or playing back only the one with aligned data and skipping the playback of the unaligned one.

[0208] Therefore, in addition to specifying the playback mode, it may be possible to specify information indicating the countermeasure method against buffer overflow and underflow in the pre-buffering buffer.

[0209] For example, in broadcasting, there is no congestion in the transmission path and no underflow due to congestion occurs. Therefore, for broadcast content, it is assumed that playback is performed according to the DTS and PTS of the access unit. When the buffer of communication content underflows due to congestion in the communication path, the playback of the access unit of communication content where there is no data in DTS is skipped.

[0210] Here, when using DASH as communication content, when the buffer underflows, it is possible to quickly start playback by skipping some segments without acquiring all subsequent segments.

[0211] More specifically, assuming that each segment of DASH is SEG1, SEG2, SEG3,... in ascending order of DTS, and the DTS of the leading access unit of the segment is T1, T2, T3,... In this case, if an underflow occurs during the reception of SEG1, by skipping the reception of SEG2 and receiving SEG3, the possibility of receiving the data of the leading access unit of SEG3 at time T3 becomes high. As a result, decoding and playback of both broadcast and communication content can be started from time T3. If SEG2 is received, the underflow state is likely to continue, so by skipping the received segment, quick resumption of playback is expected.

[0212] Also, for example, when the communication side experiences an underflow, the playback of the broadcast content is stopped until the buffering of the data of the communication content is completed and it becomes playable.

[0213] In the attribute information of the content transmitted by the broadcast PMT or the like, when it is indicated that the communication content is a target for synchronous playback of the broadcast content, or when it can be identified based on the extension of the location information of the communication content that the location information is a specific file such as a DASH MPD, the execution mode may be determined without explicitly describing it as control information.

[0214] Also, when synchronously playing back the content transmitted over multiple transmission paths, it may be possible to control the reception to playback of the broadcast and communication by a single application.

[0215] [Application Control Information] Next, in the hybrid broadcast specification, an example of storing information regarding the data transmitted in communication in the application control information when synchronously playing back the broadcast content and the communication content will be described.

[0216] In FIGS. 6A and 6B, an example of storing the location information of the data on the communication side in the transmission path identification descriptor and storing it in the PMT was shown. In this modification example, an example of the case where the transmission path identification descriptor is stored in the application control information will be described.

[0217] In the conventional hybrid broadcast specification, the transmission path identification descriptor is not stored in the application control information, and since it is necessary to acquire the location information after the application is executed, a delay occurs. On the other hand, by storing the transmission path identification descriptor in the application control information and describing (placing) the location information in the transmission path identification descriptor, the acquisition of the content can be started earlier.

[0218] Here, the application control information is, for example, AIT (Application Information Table), which is information for controlling the startup, termination, resources, and access of an application. For example, the application control information includes an application ID for identifying the application, a control code capable of controlling the life cycle such as startup and termination of the application, and location information of the application. In addition, the formats of the section form and the XML form of the application control information are defined, and the transmission methods include a method of transmitting in the section form and a method of transmitting the XML-formatted application control information by a data carousel. When transmitting the application control information, a data encoding method descriptor including ait_identifier_info() is arranged in the ES loop of the PMT.

[0219] FIG. 11A and FIG. 11B are diagrams showing an example of the data structure of application control information in the broadcast communication cooperation service of Modification Example 4 of Embodiment 1. Specifically, FIGS. 11A and 11B show an example of storing information related to data transmitted in communication in section-form application control information.

[0220] Also in this modification example, in order to show the attribute information and the like described in FIGS. 1A and 1B, a transmission path identifier descriptor is stored in the descriptor for each application. For example, in program information in a TS such as a PMT, only the location information of the data transmitted by the TS is shown. Therefore, when the content data is transmitted using communication, the location information of the communication-side data is stored in the transmission path identifier descriptor. More specifically, in the attribute information, by including flag information indicating whether communication is used in combination, whether to include the location information of the communication-side data is selected according to the value of the flag information.

[0221] Here, the location information is information indicating the acquisition source of data. In the case of the TS section, it corresponds to the PID, and in the case of communication, it corresponds to the URL, URI, etc. As the location information, it is possible to store the MPD (Media Presentation Description) of DASH, the SDP (Session Description Protocol) in RTP, etc.

[0222] Note that a separate descriptor may be defined to store the location information. Also, instead of storing the actual data of the location information such as MPD and SDP, information indicating the acquisition source of the actual data may be shown.

[0223] For example, it is possible to show the URL for acquiring the MPD. However, since there is a delay for separately acquiring the actual data of the location information, in order to reduce the delay until the reception of the data on the communication side starts, it is desirable to directly store the actual data. However, since the MPD of DASH contains various information regarding the acquisition source of the content, the size of the MPD is large. Therefore, instead of storing the MPD as it is, it may be possible to store a subset of information including only the URL of the acquisition source of the content and information regarding the DTS and PTS of the segment.

[0224] Note that in this modification example, as shown in FIGS. 11A and 11B, an example of storing the transmission path identification descriptor in the loop for each application has been described, but it is not limited thereto.

[0225] For example, when one transmission path identification descriptor is shared by a plurality of applications, the transmission path identification descriptor may be stored in the loop of at least one of the applications that use the transmission path identification descriptor. In this case, in the remaining application loops, it can be omitted by showing information that can refer to the transmission path identification descriptor. The information that can refer to the transmission path identification descriptor is, for example, the loop number of the application in which the transmission path identification descriptor is stored or the application ID.

[0226] Also, a transmission path identifier descriptor may be stored in a loop (number of loops N) immediately below the application control information, an identifier capable of identifying the transmission path identifier descriptor may be assigned, and an identifier to be referred to in each application may be referred to.

[0227] Also, an example of the case where the entity of the location information is stored in the transmission path identifier descriptor is not limited to the above example.

[0228] For example, when the size of the entity of the location information is large, the transmission path identifier descriptor including the entity of the location information or the application information including the transmission path identifier descriptor may be described in a loop (here, the loop of N1) after the application information not including the entity of the location information. Thereby, data other than the entity data of the location information can be acquired first. Also, a receiving device that does not need to acquire the entity data of the location information may complete the acquisition of the application control information without acquiring the entity data of the location information until the end.

[0229] Also, information indicating the acquisition destination of the entity of the location information may be indicated inside the application. At this time, instead of indicating the acquisition destination of the entity of the location information, information capable of identifying the application for which the acquisition destination is indicated (for example, application ID, URL of the application, etc.) may be indicated, or the acquisition destination of the entity of the location information may not be indicated.

[0230] Also, FIG. 12 is a diagram showing another example of the data structure of the application control information in the broadcast communication cooperation service of Modification Example 4 of Embodiment 1. That is, in this modification example, as shown in FIG. 12, information indicating that the transmission identifier descriptor is included in the application information identifier and attribute information may be stored in a descriptor such as ait_identifier_info() stored in the PMT. By analyzing the PMT, the receiver can know earlier that it is broadcast communication cooperation content, and the time until synchronous playback of broadcast and communication can be shortened.

[0231] Also, among the transmission path identification descriptors, only the attribute information may be transmitted in the PMT.

[0232] Also, for example, an identifier such as an application type may indicate that the application is an HTML5 application that operates in conjunction with broadcasting.

[0233] Note that in this modified example, the application control information in section format is used for explanation, but it is not limited thereto. The transmission path identification descriptor may be stored in the application control information in XML format. In this case, the transmission path identification descriptor may be expressed in either section format or XML format.

[0234] Also, in this modified example, another section may be defined without using the application control information to achieve a similar function. In this case, the PMT may store information (such as PID or stream type) for specifying the section containing the transmission path identification descriptor. It is desirable to be able to handle updates to the content of location information such as MPD. For example, it may be indicated that the MPD is updated by the version number of the application control information, or it may be assumed that the MPD is updated when the control code in the application control information is, for example, indicated as MPD_CHANGE. When the MPD is obtained from communication, the application may be made to re-obtain it with the control code set as MPD_REROAD.

[0235] Also, in this modified example, both the program information such as PMT and the transmission path identification descriptor may transmit the attribute information and the location information. In this case, only the location information may be stored in the transmission path identification descriptor.

[0236] Also, in this modified example, after starting to acquire communication - side data based on the location information obtained from the broadcast, the updated content of the location information may be acquired in the communication. At this time, since the acquisition destination of the location information is required, in the broadcast transmission - path identifier descriptor or the like, together with the entity data of the location information, the acquisition destination of the location information may also be stored. In the receiving device, the updated content can be acquired in the communication by periodically accessing the acquisition destination of the location information. When there is a mechanism such as message exchange between the DASH content delivery server and the receiving device, a message indicating that the location information has been updated may be issued from the server to the receiving device, and in the receiving device, when the message is received, the location information may be acquired again, etc.

[0237] Also, in this modified example, the information indicating the correspondence relationship between the reference clocks of the broadcast - side data and the communication - side data, which was described in FIGS. 6A and 6B, may be included in the transmission - path identifier descriptor or the application control information.

[0238] Also, in this modified example, in the transmission - path identifier descriptor, information on the transport - layer protocol, such as whether the communication - side data is transmitted by UDP (User Datagram Protocol) or TCP (Transmission Control Protocol), may be indicated. Thereby, in the receiving device, it becomes possible to open the ports used in each protocol or to determine whether it corresponds to the protocol being used. Also, the identification information of the multiplexing format in the communication - side data may be indicated so that, for example, whether it is DASH or RTP can be identified. Thereby, for example, if the multiplexing format is DASH, it can be determined that the location information is described in the MPD format.

[0239] [Transmission method] In this embodiment, the transmitting side transmits content (data or assets) using broadcast waves and a communication channel, and prior to transmitting the content, it transmits application control information.

[0240] [Receiving method] In this embodiment, the receiving side starts receiving (acquiring) the content after obtaining the application control information. Hereinafter, the receiving method in this modification will be described with reference to the drawings. That is, an example of the operation of a receiving apparatus in the case of broadcast communication cooperation using the hybrid cast specification will be described. In this modification, an example will be described in which the broadcast is transmitted using TS and the communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like.

[0241] FIG. 13A is a flowchart showing an example of the operation of the receiving side in the broadcast communication cooperation service of Modification 4 of Embodiment 1. FIG. 13A shows an example of the operation when attribute information and location information are stored in the application control information of the broadcast. Note that the assets shown in FIG. 13A are assumed to be TS on the broadcast side and DASH or RTP data on the communication side. The attribute information is equivalent to the content described in FIG. 7A.

[0242] First, in step S501, the application control information is acquired. Next, the operations subsequent to step S502 are performed. However, the operations after step S502 (steps S502, S504 to S506) are the same as the operations (steps S201, S203 to S205) described in FIG. 7A, and thus the description thereof will be omitted. Hereinafter, only step S503, which performs different operations, will be described.

[0243] In step S503, based on the information of the transmission path identifier descriptor, it is determined whether to receive the data transmitted from the communication, and based on the location information of the application described in the application control information, it is determined whether to receive the application transmitted from the communication.

[0244] Figure 13B is a flowchart showing a comparative example of the operation on the receiving side in the broadcast communication cooperation service according to Modification Example 4 of Embodiment 1. In Figure 13B, in the program information of the broadcast, operation examples are shown in the case where the attribute information and the access information for acquiring the location information are stored, and the entity of the location information is not stored.

[0245] In step S601, after acquiring the application control information, the operation following step S602 is performed. However, the operations after step S602 (step S602, steps S604 to S607) are the same as the operations (step S301, steps S303 to S305) described in Figure 7B, so the description is omitted.

[0246] In step S603, it is determined whether to receive the data transmitted by communication based on the information of the transmission path identifier descriptor, and it is determined whether to receive the application transmitted by communication based on the location information of the application described in the application control information.

[0247] Note that the operation flow shown in Figure 13A does not have a step of acquiring the location information on the communication side as compared with the operation flow shown in Figure 13B. Thereby, in the operation on the receiving side shown in Figure 13A, it is possible to quickly acquire the start of data reception of the communication.

[0248] Also, in the operation flow shown in Figure 13A, the processes corresponding to steps S405, S406, and S407 described in Figure 9 may be performed. That is, it is determined whether the broadcast content and the communication content are synchronously reproduced. If they are synchronously reproduced, synchronous information is acquired from the transmission path identifier descriptor, and the reference clocks of the broadcast and the communication are synchronized to perform synchronous reproduction.

[0249] Also, in step S503 or step S603, when it is determined to receive the data transmitted by communication, the startup preparation of the application may be performed.

[0250] For example, when it is determined that data transmitted by communication is received, by starting the HTML5 browser at that time, the time until the application is executed can be shortened.

[0251] Also, in step S603, for example, when it is determined that communication-side location information is transmitted by communication, the application may be immediately started and the communication-side location information may be acquired. Further, after acquiring the communication-side location information, buffering of communication content may be started. The timing of starting the buffering may be instructed by a control command of application control information, or time information for pre-buffering may be described in the communication-side location information and analyzed and pre-buffered by the receiving device.

[0252] Note that, as the application for acquiring the communication-side location information or the application for acquiring the communication content, the application specified by the application control information may be acquired from broadcasting or communication and executed. Also, the application for acquiring the communication-side location information or the application for acquiring the communication content may be realized as a resident application. For example, control such as execution of an HTML5 application or a resident application and acquisition of data may be instructed by a control command of the application control information, or control such as execution of an HTML5 application or a resident application and acquisition of data may be performed based on the determination of the receiving device.

[0253] Also, when information regarding the capabilities of the receiving device necessary for playing back the content is described in the location information, the receiving device acquires the playback capabilities of the receiving device using an API command. In this case, the application that analyzes the location information is given the authority to acquire the playback capabilities of the receiving device. For example, when it is determined after acquiring the communication-side location information in step S605 that the receiving device cannot play back the content, the process may proceed to step S607 and only the data transmitted by broadcasting may be received.

[0254] Also, control for storing, retrieving from memory, or passing between applications the location information of the communication side and the information of communication content obtained by various methods may be realized by API commands. An application can obtain part or all of the location information of the communication side by executing an API command. For example, it is also possible to set the location information obtained by a resident application to the memory of the receiving device by an API command and get it from the memory by an API command from an HTML5 application.

[0255] [Effects of Embodiment 1, etc.] As described above, according to this embodiment, identification information indicating whether content including audio and video is transmitted using both communication and broadcasting in addition to broadcasting, and information indicating the dependency relationship between the data transmitted on both transmission paths when using both broadcasting and communication may be generated and transmitted as content management information. Here, for example, the information indicating the dependency relationship between the data may include whether the data transmitted on both transmission paths is synchronously reproduced. Also, the information indicating the dependency relationship between the data may include whether the clock information of the data transmitted on both transmission paths is the same.

[0256] Thereby, since the transmission path through which content including audio and video is transmitted and the dependency relationship between the data transmitted on different transmission paths can be obtained at the start of content reception, it is possible to reduce the determination of the received asset and the delay time related to the start of obtaining communication content.

[0257] Also, according to this embodiment, the location information of the data transmitted in communication may be included in the content management information. Here, the location information of the data to be transmitted may be, for example, the MPD in MPEG-DASH. Also, instead of the actual data of the location information such as MPD, information indicating the acquisition destination of the location information may be stored in the content management information.

[0258] Thereby, since the transmission path through which content including audio and video is transmitted and the dependency between data transmitted on different transmission paths can be obtained at the start of content reception, it is possible to reduce the determination of the assets to be received and the delay time related to the start of acquisition of communication content.

[0259] Also, according to the present embodiment, in the receiving apparatus, it may be possible to analyze the management information of the content and determine the transmission path for receiving the content and the data to be received on each transmission path. Further, when synchronously reproducing the data transmitted on both transmission paths, it may be possible to obtain the auxiliary information necessary for clock synchronization between the data, synchronize the DTS and PTS in each data, decode, and reproduce.

[0260] Thereby, in a receiving apparatus that receives only broadcast data, it is possible to support the reproduction of communication data while enabling the reproduction of broadcast data by the same operation as conventional broadcast reception.

[0261] Furthermore, a mechanism for synchronously reproducing the broadcast and communication data can be provided to the receiving apparatus.

[0262] Also, as described above, according to the present embodiment, it is possible to realize a content transmission method, a receiving method, a transmitting apparatus, and a receiving apparatus that enable quick access to communication-based content when reproducing content using both broadcast and communication on the receiving side.

[0263] Here, for example, the transmission method in one aspect of the present embodiment is a content transmission method capable of transmitting content using a broadcast wave and a communication channel. When transmitting content using each of the broadcast wave and the communication channel, it is information for causing the receiving side to synchronize the content by the broadcast wave and the content by the communication channel when the receiving side receives it, and information regarding the content transmitted by the communication channel is included in the application control information, and includes an information transmission step of transmitting using at least the broadcast wave among the broadcast wave and the communication channel.

[0264] Thereby, when transmitting content using a broadcast wave and a communication channel, information for causing the receiving side to synchronize the content by the broadcast wave and the content by the communication channel when the receiving side receives it, and information regarding the content transmitted by the communication channel is included in the application control information and transmitted. Therefore, when the receiving side receives the application control information, the receiving side can be made to quickly access the content by communication according to this information, and the content can be synchronized.

[0265] Further, for example, in the information transmission step, the application control information is transmitted prior to transmitting the content, and the application control information may further include location information indicating the acquisition destination of the content or information indicating the acquisition destination of the location information.

[0266] Also, the receiving method in one aspect of the present embodiment includes a receiving step of receiving content transmitted using each of a broadcast wave and a communication channel, and information for synchronizing the content by the broadcast wave and the content by the communication channel, which is information regarding the content transmitted by the communication channel, is included in the application control information. When received from at least the broadcast wave among the broadcast wave and the communication channel, a synchronization process is performed, and a playback step of playing back the content.

[0267] Accordingly, for example, in a transmission path serving as an entry point such as a broadcast wave, if application control information transmitted therein includes information for synchronizing content transmitted by a broadcast wave and content transmitted by a communication path, and the information relates to the content transmitted by the communication path, a synchronization process can be performed.

[0268] Also, for example, in the receiving step, if the application control information is received prior to receiving the content, and the application control information includes location information indicating the acquisition destination of the content, the content may be received by acquiring the content based on the location information.

[0269] Also, for example, in the receiving step, if the application control information is received prior to receiving the content, and the application control information includes information indicating the acquisition destination of location information indicating the acquisition destination of the content, the location information may be acquired based on the information indicating the acquisition destination of the location information, and the content may be received by acquiring the content from the acquired location information.

[0270] In addition, a transmission device according to an aspect of the present embodiment is a content transmission device capable of transmitting content using a broadcast wave and a communication path. When transmitting content using each of the broadcast wave and the communication path, information for synchronizing the content transmitted by the broadcast wave and the content transmitted by the communication path when received by the receiving side, and information related to the content transmitted by the communication path are included in the application control information, and an information transmission unit that transmits information using at least the broadcast wave among the broadcast wave and the communication path is provided.

[0271] Also, a receiving apparatus according to an aspect of the present embodiment includes a receiving unit that receives content transmitted using each of a broadcast wave and a communication path, and information for synchronizing the content by the broadcast wave and the content by the communication path. When receiving application control information including information related to the content transmitted by the communication path, a playback unit that performs a process of taking the synchronization and plays back the content.

[0272] (Embodiment 2) (Example 1) For example, in Modification 3 of Embodiment 1, in FIGS. 6A to 7B, etc., the storage method of location information and the like in the case where broadcasting uses TS and communication uses DASH, RTP, etc. for transmission, respectively, has been described, but it is not limited to this.

[0273] In the present embodiment, as Example 1, a specific example of the storage method of location information will be described.

[0274] FIG. 14 is a diagram showing an example of the data structure of service information in the broadcast communication cooperation service of Example 1 of Embodiment 2. FIG. 14 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. Therefore, the location information descriptor may be considered to correspond to the transmission path identification descriptor.

[0275] In the present example, the descriptor is stored in a PMT or section data different from the PMT.

[0276] Information indicated by this descriptor includes a transmission format indicating the type of entity data referred to by the location information, the location information, and a field indicating synchronization information between the PCR in broadcasting and the data on the communication side.

[0277] In addition, in this embodiment, the location information shall indicate the reference destination of the entity data of the location information. Here, an example where the entity data of the location information is MPD is shown. As the transmission format, MPD is shown, and as the synchronization information, the synchronization information between PCR and NTP is shown.

[0278] Since MPD is the location information used in DASH, as the transmission format, DASH may be indicated, and as the location, the reference destination of MPD may be indicated. In cases where the transmission format can be identified by the extension in the URL of the location information, etc., the field of the transmission format may not be included. Also, there are two cases for MPD: when it is transmitted within a broadcast and when it is transmitted via a communication network. When transmitted within a broadcast, a private section of MPEG-2 TS, etc., is used.

[0279] Therefore, as the location information of MPD, when transmitted within a broadcast, it can indicate the identification information of the TS packet storing MPD in the transport stream, such as the PID of the private section, and when transmitted via a communication network, it can indicate information such as a URL.

[0280] [Receiving Method] Hereinafter, as an example of the receiving method in this embodiment, an example of the operation of a receiving device when analyzing a descriptor indicating location information and synchronously playing back broadcast and communication content will be described.

[0281] FIG. 15 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Example 1 of Embodiment 2.

[0282] First, in step S801, the location information descriptor stored in the PMT, etc., is analyzed.

[0283] Next, in step S802, it is determined whether an MPD exists in the broadcast. If it exists in the broadcast (i.e., the MPD is transmitted by the broadcast) (yes in S802), the process proceeds to step S803, and the actual data of the MPD 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 or the like indicated in the location information.

[0284] Next, in step S805, based on the analysis result of the MPD, the data to be acquired from the DASH content is determined, and the data is acquired by download (or progressive download, etc.).

[0285] Next, in step S806, based on the synchronization information included in the location information descriptor or, when the time line extension of the MPEG-2 TS is used, the synchronization information acquired from the TS packet storing the time line extension information, the broadcast content and the communication content are synchronously reproduced.

[0286] Note that when using the time line extension, the location information descriptor may not include the synchronization information. Also, when it is not necessary to synchronously reproduce the DASH content and the broadcast content, the synchronization information may not be transmitted. In this case, it may be determined whether synchronous reproduction of both is necessary based on whether the synchronization information in the location information descriptor or the synchronization information in the data for the time line extension exists. Whether synchronous reproduction is necessary may be separately indicated.

[0287] Also, when synchronous reproduction is not necessary, in step S806, based on a user instruction or a control command in the hybrid broadcast application, etc., the start and end of the reproduction of the DASH content can be determined. Note that in this case, it is assumed that whether to acquire data by communication has been determined in the stage before S801.

[0288] In FIG. 15, an example of acquiring MPD and playing DASH content was described, but the same applies when acquiring and playing data in other formats such as RTP and TS.

[0289] In addition, in the timeline extension, 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.

[0290] Therefore, without transmitting the location information descriptor, both the location information and the synchronization information may be indicated by the timeline extension. In the current timeline extension, since the PID cannot be indicated as the location information, the field indicating the scheme type of the location information may be extended so that the PID can be signaled.

[0291] Also, the upper limit of the PMT section size is limited to 1021 bytes, and depending on the URL in the location information, it may exceed the upper limit. Although it is possible to divide and store the PMT section, it is particularly desirable that the PMT be stored in one section.

[0292] Therefore, when the PMT section size exceeds 1021 bytes, the location information descriptor may be transmitted in a section different from the PMT. When the location information indicates the PID, it can be contained within the PMT size limit and can be included in the PMT. Therefore, the section for storing the location information may be switched based on whether the location information is the PID or the URL.

[0293] (Example 2) In Example 1, it was stated that location information can also be indicated in the TEMI (Timeline and Extend Media Information stream) access unit in the timeline extension.

[0294] Specifically, the URL of the content on the communication side can be described using the temi_location_descriptor. In the temi_location_descriptor, the URLs of multiple contents can be described, and there are no data size restrictions such as the section size of the PMT. Therefore, flexible operation regarding the description of URLs becomes possible.

[0295] On the other hand, in the case where the PID of the TS packet in the transport stream is used as the location information, the data size of the location information is also small. By referring to the location information descriptor to obtain the location information during the analysis of the PMT, the delay time associated with the acquisition can be reduced. Therefore, as the storage location of the location information, it is desirable that the location information descriptor and the temi_location_descriptor in the TEMI access unit can be used in combination.

[0296] Hereinafter, an example of the syntax (data structure) of the location information descriptor in this embodiment will be described.

[0297] FIG. 16A is a diagram showing an example of the syntax of the location information descriptor in the second embodiment of the second embodiment. FIG. 16A shows an example of the syntax of the location information descriptor for storing the location information in either the location information descriptor or the TEMI access unit.

[0298] In this embodiment, it will be described that the synchronization information with the PCR is described using the temi_timeline_descriptor of the TEMI access unit and is not included in the location information descriptor. The semantics of each field shown in FIG. 16A will be described.

[0299] 「data_format」 is the same as the transmission format shown in FIG. 14. That is, it indicates the format of the playback control meta-information used in the service, such as the MPD in DASH, the playback control meta-file in the VOD (Video On Demand) specification of the IPTV Forum, or the TTS (Time-stamp TS) defined in the IPTV Forum, etc. It may indicate the identification information of the stream itself, rather than meta-information, such as TTS, MP4 files, or the AV encoded data itself. It may also indicate the MPT, PA messages, MMT packets, assets, etc. in MMT.

[0300] For example, temporal scalability can be realized in a video encoding scheme such as H.265. Here, assume that the basic layer of 60 fps is transmitted in broadcasting, and the encoded data of the enhancement layer for improving the frame rate from 60 fps to 120 fps is transmitted in communication. In this case, as the location information of the communication content, only the URL of the encoded stream of the enhancement layer needs to be indicated. Information such as the resolution and encoding scheme in the encoded stream can be obtained from the broadcast data transmitting the basic layer.

[0301] 「location_type」 is for identifying whether the location information is indicated by the PID of the TS in broadcasting or the URL in communication. Here, it is assumed that when location_type = 0, it indicates the PID of the TS in broadcasting. Note that the location information descriptor can be used in addition to TS, for example, in MPEG's MMT (MPEG Media Transport). In formats other than TS, "location_type" may not be used. For example, other information for identifying the location, such as the packet_id of the MMT packet in MMT, may be used.

[0302] "PID" indicates the PID of the TS packet. When the broadcast is composed of multiple transport streams, the identification number of the transport stream, etc. may be stored together.

[0303] "url_location" indicates whether the URL of the communication content is stored in the location information descriptor or in the TEMI access unit. In this embodiment, it is assumed that when url_location = 0, it is stored in the location information descriptor. When url_location is 1, the URL of the communication content is stored in the temi_location_descriptor in the TEMI access unit.

[0304] "url_length" indicates the byte length of "url_path". "url_path" indicates the data of the URL.

[0305] Figure 16B is a diagram showing an example of the syntax of the location information descriptor in Example 2 of Embodiment 2. Figure 16B shows an example different from the syntax of the location information descriptor shown in Figure 16A. The difference from the syntax shown in Figure 16A is that when storing location information in the TEMI access unit, the data_format field does not exist.

[0306] Here, Temi_location_descriptor can indicate the TEMI service type in a field called service_type. This service type corresponds to data_format. Therefore, the information of data_format shall be indicated in the service_type field.

[0307] Note that in the syntax shown in Figure 16A, the data_format field and the service_type of temi_location_descriptor may both exist. In this case, both indicate the same information.

[0308] In the temi_location_descriptor, it is also possible to indicate only the URL of the communication content without signaling the service_type. Therefore, when using the syntax of FIG. 16A, as the transmission format, the data_format of the location information descriptor may be referred to, and the service_type of the temi_location_descriptor may not be signaled.

[0309] FIG. 16C is a diagram showing an example of the syntax of the location information descriptor in the second embodiment of the second embodiment. FIG. 16C shows an example different from the syntax of the location information descriptor shown in FIGS. 16A and 16B.

[0310] The difference from FIG. 16A is that it first makes a conditional branch of url_location. That is, when the location information is in the location information descriptor with url_location = 0, the PID of the broadcast TS or the communication URL is stored according to the location_type. On the other hand, when url_location = 1, the location_type is not described in the location information descriptor, but in the temi_location_descriptor in the TEMI access unit, the location_type is indicated in the service_type field, and the PID of the TS in the broadcast or the communication URL is stored in the temi_location_descriptor.

[0311] FIG. 16D is a diagram showing an example of the syntax of the location information descriptor in the second embodiment of the second embodiment. FIG. 16D shows an example different from the syntax of the location information descriptor shown in FIGS. 16A to 16C.

[0312] The difference from FIG. 16A is that the url_location and location_type are integrated. When location_type = 0, it indicates the PID of the broadcast. When location_type = 1, it indicates the communication URL. Also, when location_type = 2, it indicates that the PID of the TS in the broadcast or the communication URL is stored in the temi_location_descriptor in the TEMI access unit.

[0313] Note that the data and data structure of the syntax of the location information descriptor are not limited to the above example. For example, it may be used in combination with other data, such as integrating and indicating the location type and the format type. Also, for example, when the transmission format can be identified by the extension in the URL of the location information, etc., the field of the transmission format may not be included. Also, for example, if the location information descriptor does not exist, the field of url_location may be omitted on the assumption that the location information is indicated by the temi_location_descriptor.

[0314] (Example 3) Hereinafter, an example different from the location information described in Example 2 will be described.

[0315] (Other Examples of Location Information) For example, when there are two or more types of multiple timelines in the same program, there may be multiple TEMI streams for each type of timeline.

[0316] In this case, the location information descriptor may store a plurality of location information. When storing a plurality of location information, a loop of the number of TEMI streams is created within the location information descriptor, and the location information corresponding to each TEMI stream is stored. Also, as a method for indicating the correspondence between the plurality of location information loops and the plurality of TEMI streams in the location information descriptor, for example, it may be such that the order of the location information loops and the order of the ES loop (PMT second loop) indicating the TEMI stream match, which is the correspondence. Also, when there are two or more types of timelines, the location information may not be stored in the location information descriptor but may be stored in the temi_location_descriptor of the TEMI access unit, or the location information descriptor may be stored in the ES loop (PMT second loop).

[0317] (Update of Location Information) Note that it is desirable to be able to handle updates to the content of location information such as meta information as well.

[0318] For example, an reload flag is added to the location information descriptor in the PMT, and when updating the content of the location information, reload = 1 is set. When the receiving device sees reload = 1, it may assume that the content of the location information has been updated and re-acquire the PID, URL, etc. stored in the location information. If the location information such as PID and URL has not been updated and only the data has been updated, only the data may be re-acquired.

[0319] Also, information indicating whether the location information itself or the content of data such as the MPD whose acquisition destination is indicated by the location information has been updated may be shown independently.

[0320] Also, the location information descriptors in the periodically transmitted PMT may be sequentially checked. However, since the processing of this sequential check is heavy, section data for storing location information descriptors and the like, and an event section for notifying updates may be separately generated and periodically transmitted.

[0321] In the receiving device, it is possible to determine whether the location information has been updated by checking the version number in the section. Also, when transmitting the location information in the broadcast section, updating the version number of the location information section indicates the update of the meta information.

[0322] Also, after starting to acquire communication-side data based on the location information obtained from the broadcast, the updated content of the location information may be acquired in the communication.

[0323] [Receiving Method] Next, as a receiving method in this embodiment, an example of the operation of a receiving device when analyzing a descriptor indicating location information and synchronously playing back broadcast and communication content will be described.

[0324] FIG. 17 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Example 3 of Embodiment 2.

[0325] Step S804 in FIG. 15 is changed to steps S906, S907, and S908 in FIG. 17. Since the other operations (steps S901 to S905) are the same as the operations in FIG. 15 (steps S801 to S803, S805, and S806), the description will be omitted.

[0326] In 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 stored in the location information descriptor (yes in S906), the process proceeds to step S907, where the location information descriptor is analyzed, and 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 it is stored in the TEMI access unit (no in S906), MPD is acquired from the communication server based on the URL indicated in the temi_location_descriptor in the TEMI access unit.

[0327] Note that in FIG. 17, an example in the case where MPD is shown as format information is presented, but even for other meta-information, the broadcast content and the communication content can be synchronously reproduced with the same flow of operations.

[0328] FIG. 18 is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperation service of Example 3 of Embodiment 2. In FIG. 18, the operation when the format information is other meta-information than MPD is shown. More specifically, when the format information indicates the format of physical data such as a stream instead of meta-information such as MPD, the operation when the URL of the physical data of the stream is acquired instead of the URL of the meta-information in step S907 or step S908 shown in FIG. 11 is shown.

[0329] First, in step S1001, the receiving device analyzes the location information descriptor.

[0330] Next, it is determined whether the data indicated in the format exists in the broadcast (step S1002). If the data exists in the broadcast (yes in S1002), the process proceeds to step S1003, and the PID indicated in the location information is acquired. Here, since it is not assumed that the broadcast contains physical data such as a stream, if the data exists in the broadcast, it is determined that the format is metadata.

[0331] Next, a meta information file is acquired from the broadcast stream based on the PID (step S1004), and the communication data to be acquired is determined (step S1005).

[0332] On the other hand, if there is no data 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 temi_location_descriptor of the TEMI access unit. Then, depending on each case, the URL is acquired in step S1009 or step S1010.

[0333] In step S1011, it is determined whether the format is meta information. If the format is meta information (yes in S1011), the process proceeds to step S1012, meta information is acquired from the communication stream based on the URL, and the process proceeds to step S1005 to determine the communication data to be acquired.

[0334] After the communication data to be acquired in step Sp1005 is determined, or if it is determined in step S1011 that the format is not meta information, the process proceeds to step S1006 to acquire the communication data.

[0335] Finally, in 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 time line extension of MPEG-2 TS.

[0336] (Example 4) So far, it has been described that whether the broadcast content and the communication content are synchronously played is determined, and when they are synchronously played, the acquisition and synchronous playback of the broadcast content and the communication content are performed, but it is not limited to this.

[0337] In this embodiment, information indicating whether the reference clock information of the audio or video transmitted by broadcast and the reference clock information of the audio or video transmitted by communication are the same is included in the service information (such as a transmission identification descriptor), and the operations based on this information will be described.

[0338] [Information on whether the reference clocks (timelines) of broadcast and communication are synchronized] When transmitting content using broadcast and communication through MMT, DASH, RTP, or hybrid cast, etc., information indicating whether the reference clock information of the audio or video transmitted by broadcast and the reference clock information of the audio or video transmitted by communication are the same may be stored in a transmission identification descriptor, program information, EPG, EIT, etc.

[0339] For example, when the content transmitted by broadcast and communication operates based on a common reference clock (such as the addition of timestamps), information indicating that it operates based on the common reference clock is stored. Also, when the content transmitted by broadcast and communication operates based on different reference clocks, information indicating that it operates based on different reference clocks is stored.

[0340] Also, only when it is indicated that different reference clock information is used in broadcast and communication, information indicating the information necessary for reference clock synchronization (such as timeline extension information) may be shown. Also, the storage location of the information necessary for reference clock synchronization, the type of information necessary for reference clock synchronization, the method of reference clock synchronization, etc. may be shown.

[0341] Here, in terms of synchronizing the reference clock, it is possible to align it with the reference clock used in either broadcasting or communication.

[0342] For example, when PCR (Program Clock Reference) is used in broadcasting and NTP (Network Time Protocol) is used in communication, the types and methods of reference clock synchronization may be shown by converting the DTS and PTS based on the NTP reference in video and audio to the PCR reference so that the reference clocks in broadcasting and communication can be synchronized. Also, the types and methods of reference clock synchronization may be shown by converting the DTS and PTS of broadcasting and communication to synchronize with the unique clock used within the receiving device.

[0343] Note that the identification information indicating the types and methods 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.

[0344] Also, when there are multiple streams with different reference clocks, information indicating that there are multiple reference clocks with different reference clocks may be stored in the descriptor. The descriptor may be shown for each different reference clock, or may be shown by a single descriptor. Information indicating the correspondence between the reference clock and the program using the reference clock may also be stored.

[0345] As information indicating whether the reference clocks are the same, it may be indicated as a descriptor as described above, or other descriptors, tables, sections, etc. may be used. Also, it may be indicated based on whether there is information necessary for clock synchronization (for example, timeline extension information, etc.). If there is information necessary for clock synchronization, the clock information may be considered different. Alternatively, the attribute information of the communication content (for example, information regarding format or type, or the extension described in the location information or URL) indicated in a transmission identification descriptor or the like may be used to indicate that the clock information is different. In the case of hybrid cast, it may be stored in the AIT control section or in the application.

[0346] When the receiving device determines that different clock information is being used, it synchronizes the reference clock information of the broadcast and the communication. Also, when it determines that common clock information is being used, it determines that clock synchronization is unnecessary.

[0347] Note that in addition to the identification result of whether the reference clock information of the data stored in a transmission identification descriptor or the like is the same, the receiving device takes into account all of the user's selection or user settings through a user interface or the like, the intention of the content provider, service provider, or broadcasting station, or the specifications or specifications of the receiving device or the intention of the receiver manufacturer, and may determine whether to actually perform reference clock synchronization of the broadcast content and the communication content.

[0348] Also, when the receiving device determines to perform reference clock synchronization, as the timing for actually performing clock synchronization, it may start synchronization after the determination, or may start when it acquires information regarding synchronization without waiting for the determination. Alternatively, it may synchronize in accordance with the time to start acquiring the communication content (for example, a certain time before starting to acquire the content, or the same time as the start of acquisition).

[0349] In addition, when the clock reproduction of the reference clock (e.g., the PCR of the broadcast) serving as the reference source is not completed (the clock is not in a state where it can be used, such as by smoothing the influence of jitter, etc.), the clock synchronization with the destination may be started when the clock reproduction of the reference clock information of the reference source is completed.

[0350] When information indicating whether the reference clocks of the broadcast and the communication are synchronized is shown by the EPG, similar to the pre-buffering of communication content, it may be possible to determine whether clock synchronization is necessary before the start of the broadcast and start the clock synchronization. By performing the clock synchronization earlier in this way, the service can be provided to the viewer earlier.

[0351] Note that the information indicating whether the reference clocks are the same is not limited to the combination of the broadcast and the communication, and is applicable when transmitted through the same path or when different reference clock information is used in data obtained from a plurality of paths such as the broadcast, the communication, and the storage format.

[0352] Note that some or all of the functions and processes described in this embodiment may be implemented in hardware or in software. It is also possible to implement some in hardware or software.

[0353] For example, when implemented in software, functions and processes described in this embodiment may be packaged, such as functions for instructing the functions and processes described, notifying the state of the reception function by PUSH, or obtaining by PULL, and provided as API functions.

[0354] The API functions can be executed from an application. When implemented as an application, it may be implemented as a resident application or an application such as HTML5 may also be used. The above API may be implemented for data transfer and state notification between applications.

[0355] Here, as functions of API functions related to information on whether the reference clock is synchronized, there are, for example, the following 1) to 9).

[0356] 1) Obtain information on whether the reference clock information of broadcast content and communication content is the same. 2) Obtain information on whether reference clock synchronization is necessary. 3) Obtain the type and synchronization method of each reference clock information. 4) Obtain information necessary for clock synchronization (such as timeline information). 5) Obtain the acquisition destination of information necessary for clock synchronization. 6) Take the reference clock information of the source as an argument and return the synchronized reference destination clock information. For example, if not synchronized, return a value indicating that it is not synchronized. 7) Instruct the start of synchronization of the mutual reference clocks. 8) Obtain the state of whether the reference clock synchronization is achieved. 9) Notify that the reference clock synchronization has been achieved.

[0357] [Receiving Method] Hereinafter, using the drawings, as a receiving method in this embodiment, when attribute information and location information are stored in the program information of the broadcast, an example of the operation when the receiving apparatus determines whether to synchronously reproduce the broadcast content and the communication content and operates will be described.

[0358] FIG. 19 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Example 4 of Embodiment 2. Note that the operation of the flowchart shown in FIG. 19 is applicable to any multiplexing method combination such as MMT, DASH, RTP, etc. in the broadcast communication cooperation service. It is also applicable to hybrid cast.

[0359] In FIG. 19, it is assumed that the broadcast content and the communication content are synchronized, and the determination of whether to synchronize the broadcast content and the communication content is omitted.

[0360] In addition, since steps S1101 and S1102 are the same operations as steps S401 and S402 in FIG. 9, the description thereof is omitted.

[0361] Next, in step S1103, the receiving device determines whether to acquire communication content. If it is determined to acquire communication content (yes in S1103), the process proceeds to step S1104, where data is received from both the broadcast and communication transmission paths. Subsequently, in step S1105, it is determined whether the reference clocks of the broadcast content and the communication content are the same or different.

[0362] If it is determined in step S1105 that the reference clocks are different (yes in S1105), the process proceeds to step S1106 to synchronize the reference clocks of the broadcast content and the communication content, and in step S1107, both are played back synchronously.

[0363] On the other hand, if it is determined in step S1105 that the reference clocks are the same (no in S1105), synchronous playback is performed using a common clock without synchronizing the reference clocks.

[0364] Note that after step S1105, a process of determining whether reference clock synchronization is necessary may be performed. For example, depending on the type and method of clock synchronization, it is determined whether the capabilities of the receiving device support clock synchronization, or whether clock synchronization is specified as a receiver specification, or whether the user requests clock synchronization. Then, based on step S1105 and the above determination result, it may be determined comprehensively whether to synchronize the reference clocks in the broadcast and communication, and the process may proceed to step S1106 or step S1107.

[0365] In addition, the synchronization of the reference clock in step S1106 may be performed prior to step S1104. This is because, in the case of buffering the received data of the content before starting playback, for example, when it is confirmed that the data with PTS = T1 in the broadcast content and the data with PTS = T1 in the communication content (where it is assumed that the PTSs of both are already synchronized) have been received and then decoding and playback are started. And when determining whether the data to be synchronously played back are complete, it is necessary for the reference clocks of both to be synchronized.

[0366] Also, in step S1106, if clock synchronization information cannot be obtained or clock synchronization cannot be achieved due to the specifications of the receiver, it may not be possible to provide the user with a service that links broadcast and communication. In that case, it may be determined whether to receive the data transmitted by the communication in step S1103 by making a determination such as whether synchronization is essential or whether playback can be performed without synchronization.

[0367] Note that in step S1103, in addition to the information that can be identified by the transmission path identifier descriptor, all factors such as user selection and settings, the intentions of content providers, service providers, and broadcasters, or the specifications and designs of the receiving device and the manufacturer's intentions should be considered to determine whether to actually receive the data transmitted by communication.

[0368] [Receiving device] Next, an example of the configuration of a receiving device that realizes the operation shown in FIG. 19 will be described. FIG. 20 is a block diagram showing an example of the configuration of a receiving device in the fourth embodiment of the second embodiment.

[0369] The receiving device 1100 shown in FIG. 20 includes an identification information acquisition unit 1101, a determination unit 1102, a communication sharing determination unit 1103, a Loc information acquisition unit 1104, a broadcast reception unit 1105, a communication reception unit 1106, a reference clock determination unit 1107, and a playback unit 1108.

[0370] 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 in FIG. 8, and thus the description thereof is omitted.

[0371] The reference clock determination unit 1107 has a function of performing the process of step S1105 shown in FIG. 19. Further, the reference clock determination unit 1107 may perform a process of determining whether the reference clocks are different and further determining whether synchronization of the reference clocks as described above is necessary.

[0372] The playback unit 1108, based on the method determined by the determination result in the reference clock determination unit 1107, when the reference clocks are different, synchronizes the reference clocks and then decrypts and plays back the broadcast content or the communication content.

[0373] Note that the functions, the configuration of the receiving apparatus, and the receiving method described in this modification example are merely examples and are not limited thereto, and any configuration may be used as long as the same functions and effects can be achieved.

[0374] [Effects of Embodiment 2, etc.] As described above, according to the present embodiment, identification information indicating whether content including audio and video is transmitted using both broadcast and communication in addition to broadcast, and information indicating the dependency relationship between the data transmitted on both transmission paths when using both broadcast and communication may be generated and transmitted as content management information. Here, for example, the information indicating the dependency relationship between the data may include whether the data transmitted on both transmission paths are synchronously played back. Further, the information indicating the dependency relationship between the data may include whether the clock information of the data transmitted on both transmission paths is the same.

[0375] Thereby, since the transmission path through which content including audio and video is transmitted and the dependency relationship between the data transmitted on different transmission paths can be obtained at the start of content reception, it is possible to reduce the determination of the asset to be received and the delay time related to the start of acquisition of communication content.

[0376] Further, according to this embodiment, location information of data transmitted in communication may be included in content management information. Here, the location information of the transmitted data may be, for example, an MPD in MPEG-DASH. Also, in the content management information, instead of the actual data of the location information such as an MPD, information indicating the acquisition destination of the location information may be stored.

[0377] Thereby, since the transmission path through which content including audio and video is transmitted and the dependency between data transmitted on different transmission paths can be obtained at the start of content reception, the determination of the received assets and the delay time related to the start of acquisition of communication content can be reduced.

[0378] Further, according to this embodiment, in the receiving apparatus, the content management information may be analyzed to determine the transmission path through which the content is received and the data to be received on each transmission path. For example, when the clock information of the data transmitted on both transmission paths is different, auxiliary information necessary for clock synchronization between the data may be obtained, and the DTS and PTS in each data may be synchronized, decoded, and played back. Also, when synchronously playing back the data transmitted on both transmission paths, auxiliary information necessary for clock synchronization between the data may be obtained, and the DTS and PTS in each data may be synchronized, decoded, and played back.

[0379] Thereby, in a receiving apparatus that receives only broadcast data, it is possible to reproduce the broadcast data by the same operation as conventional broadcast reception and also support the reproduction of communication data.

[0380] Furthermore, a mechanism for synchronously playing back the broadcast and communication data can be provided to the receiving apparatus.

[0381] Furthermore, even when the clocks of the data transmitted through a plurality of transmission paths are not synchronized, clock synchronization can be achieved and the data can be played back synchronously by acquiring auxiliary information necessary for clock synchronization.

[0382] As described above, according to the present embodiment, it is possible to realize a content transmission method, a reception method, a transmission device, and a reception device that enable quick access to content by communication when playing back content using both broadcast and communication on the receiving side.

[0383] Here, for example, the transmission method in one aspect of the present embodiment is a content transmission method capable of transmitting content using a broadcast wave and a communication path. When transmitting content using each of the broadcast wave and the communication path, information for synchronizing the content by the broadcast wave and the content by the communication path when received by the receiving side, and information regarding the content transmitted by the communication path are included in the application control information, and an information transmission step of transmitting at least using the broadcast wave among the broadcast wave and the communication path is included.

[0384] Thereby, when transmitting content using a broadcast wave and a communication path, information for synchronizing the content by the broadcast wave and the content by the communication path when received by the receiving side, and information regarding the content transmitted by the communication path are included in the application control information and transmitted. Thus, when the receiving side receives the application control information, the receiving side can be made to quickly access the content by communication, and synchronization between the contents can be achieved.

[0385] Also, for example, in the information transmission step, the application control information may be transmitted prior to transmitting the content, and the application control information may further include location information indicating the acquisition destination of the content or information indicating the acquisition destination of the location information.

[0386] Further, for example, in the information transmission step, the application control information may further include difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path and be transmitted.

[0387] Further, for example, in the information transmission step, by transmitting the application control information, the reference clock of the content by the communication path may be synchronized with the reference clock of the content by the broadcast wave based on the difference information, and the receiving side may be made to perform the synchronization.

[0388] Also, a receiving method according to an aspect of the present embodiment includes a receiving step of receiving content transmitted using each of a broadcast wave and a communication path, and application control information that is information for synchronizing the content by the broadcast wave and the content by the communication path and that includes information regarding the content transmitted by the communication path. When the application control information is received from at least the broadcast wave among the broadcast wave and the communication path, a synchronization process is performed, and a playback step of playing back the content.

[0389] Thereby, for example, when application control information transmitted in a transmission path serving as an entry point such as a broadcast wave is acquired and includes information for synchronizing the content by the broadcast wave and the content by the communication path and that is information regarding the content transmitted by the communication path, a synchronization process can be performed.

[0390] Here, for example, in the receiving step, if the application control information is received prior to receiving the content and the application control information includes location information indicating the acquisition destination of the content, the content may be received by acquiring the content based on the location information.

[0391] Further, for example, in the receiving step, before receiving the content, the application control information is received. If the application control information includes information indicating a location for acquiring location information indicating the acquisition destination of the content, the location information is acquired based on the information indicating the acquisition destination of the location information, and the content is received by acquiring the content from the acquired location information.

[0392] Also, for example, in the playback step, in the receiving step, the application control information including difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path is received. And when the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path are different, a process of synchronizing the reference clock of the content by the communication path with the reference clock of the content by the broadcast wave based on the difference information is performed to synchronize the content, and the content may be played back.

[0393] As described above, the transmission method, reception method, etc. according to one or more aspects of the present invention have been described based on the embodiments. However, the present invention is not limited to these embodiments. As long as the gist of the present invention is not deviated from, various modifications conceived by those skilled in the art applied to these embodiments, or forms constructed by combining components in different embodiments may also be included within the scope of one or more aspects of the present invention.

[0394] For example, in each of the above 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.

[0395] Further, for example, the attribute information may include information indicating whether the clock information of audio and video transmitted by broadcasting and the clock information of audio and video transmitted by communication are the same.

[0396] Also, in the synchronization of the reference clock in S406, if the attribute information includes information indicating whether the reference clock information of a plurality of components is the same, and the receiving side can obtain that the reference clock information is different based on the attribute information, the above method may be used to synchronize the reference clocks in broadcasting and communication.

[0397] Further, when content is transmitted using a broadcast wave and a communication path, a transmission path identification descriptor may be transmitted, and when content is transmitted using only a broadcast wave, the transmission path identification descriptor may not be transmitted. According to this configuration, the receiver can determine whether the content is transmitted using both the communication path or only the broadcast wave based on whether the transmission path identification descriptor is included.

[0398] Also, although it is said that the method for synchronizing the clock information of the streams transmitted over different transmission paths such as broadcasting and communication may be included in the attribute information, it is not limited thereto. Information indicating whether the clock information of the streams transmitted over different transmission paths such as broadcasting and communication is synchronized with each other, or a method for synchronization may be included in the attribute information.

Industrial Applicability

[0399] The present invention is useful as a content transmission method, a receiving method, etc. capable of transmitting content using a broadcast wave and a communication path.

Explanation of Signs

[0400] 11 Identification information acquisition unit 14, 104, 305, 405, 1105 Broadcast receiving unit 100, 300, 400, 1100 Receiver 101, 301, 401, 1101 Identification Information Acquisition Unit 102 Asset Determination Unit 103 Judgment Unit 105, 306, 406, 1106 Communication Reception Unit 302, 402, 1102 Determination Unit 303, 403, 1103 Communication Co - use Judgment Unit 304, 404, 1104 Loc Information Acquisition Unit 407 Synchronization Judgment Unit 408, 1108 Reproduction Unit 1107 Reference Clock Judgment Unit

Claims

Claim 1 a receiving unit that receives content transmitted using each of a broadcast wave and a communication channel; a reproducing unit that reproduces the content when receiving control information including information indicating that there is the content transmitted through the communication channel and information for reproducing the content by the broadcast wave and the content by the communication channel, the information being related to the content transmitted through the communication channel; the receiving unit receives a basic layer of the content using the broadcast wave and an extended layer using the communication channel; the receiving unit receives, using the communication channel, information indicating which asset of the basic layer the asset of the extended layer corresponds to; the receiving unit receives, using the broadcast wave, information indicating a type of control information of the content transmitted through the communication channel; the receiving unit receives location information indicating an acquisition destination of the content or information indicating an acquisition destination of the location information; a receiving apparatus.

Images