Transmitting Device

Abstract

To allow for quick access to contents by communication when reproducing contents on a receiving side using broadcasting and communication in combination.SOLUTION: Provided is a content transmitting device capable of transmitting contents using a broadcast wave and a communication path, said device including an information transmission unit that, when transmitting contents using the broadcast wave and the communication path, respectively, transmits control information using at least the broadcast wave from among the broadcast wave and the communication path, the control information including information that indicates that there is a content transmitted by the communication path and information for reproducing a content by the broadcast wave and a content by the communication path, that pertains in particular to the content transmitted by the communication path. The information transmission unit transmits the basic layer of content by using the broadcast wave and the extension layer by using the communication path, and, for transmission by the communication path, transmits information that indicates the asset of which basic layer the asset of the extension layer corresponds to.SELECTED DRAWING: Figure 13A

Description

[Technical field]

[0001] The present invention relates to a transmitting method and a receiving method. [Background technology]

[0002] Conventionally, the main transmission path for distributing content has been broadcast waves, and an example of a media transport method that is widely used in broadcasting systems using broadcast waves is MPEG-2 TS (Moving Picture Experts Group-2 Transport Stream).

[0003] Meanwhile, with the recent advances in network technology, it has become possible to distribute content using communication paths such as the Internet. In other words, content can now be distributed using not only broadcast waves but also communication paths, and the transmission paths over which content can be distributed are becoming more diverse.

[0004] For example, Non-Patent Document 1 discloses MMT (MPEG Media Transport) as a new media transport method that assumes the combined use of broadcasting and communication to distribute content (see Non-Patent Document 1). For example, Patent Document 1 discloses a technology that mainly uses broadcasting and accesses communication content based on data acquired from the broadcasting. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Information technology - High efficiency coding and media delivery in heterogeneous environment - Part1:MPEG media transport(MMT), ISO / IEC DIS 23008-1 Summary of the Invention [Problem to be solved by the invention]

[0006] However, although there has been discussion about obtaining information (service information) relating to content reception, etc. and starting content reception in order to distribute content and receive distributed content using a combination of broadcasting and communications, no consideration has been given to quick access to content via communications, resulting in issues such as delays in the timing at which content reception via communications starts.

[0007] SUMMARY OF THE PRESENT DISCLOSURE An object of the present invention is to provide a content transmission method that enables quick access to content via communication when content that is both broadcast and communication is reproduced on the receiving side. [Means for solving the problem]

[0008] In order to solve the above problem, a transmitting device according to one embodiment of the present invention is a content transmitting device capable of transmitting content using broadcast waves and a communication path, and when transmitting content using both the broadcast waves and the communication path, the transmitting device has an information transmitting unit that transmits control information including information indicating that there is content to be transmitted via the communication path, and information for reproducing the content via the broadcast waves and the content via the communication path, which is information related to the content to be transmitted via the communication path, and transmits the control information using at least the broadcast waves of the broadcast waves and the communication path, the information transmitting unit transmits a base layer of the content using the broadcast waves and an enhancement layer using the communication path, and in the transmission via the communication path, transmits information indicating which asset of the enhancement layer corresponds to which asset of the base layer, and in the transmission via the broadcast waves, transmits information indicating the type of control information of the content transmitted via the communication path, and the information transmitting unit transmits location information indicating the source from which the content was obtained or information indicating the source from which the location information was obtained.

[0009] In addition, these general or specific aspects may be realized by a data receiving method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized by any combination of a data transmitting method, a data receiving method, an integrated circuit, a computer program, and a recording medium. Effect of the Invention

[0010] According to the present invention, it is possible to realize a content transmission method and the like that enables quick access to content via communication when content that is both broadcast and communication is reproduced on the receiving side. [Brief description of the drawings]

[0011] [Figure 1A] 2 is a diagram showing an example of a data structure of service information in the broadcast communication cooperative service of the first embodiment. FIG. [Figure 1B] 2 is a diagram showing an example of a data structure of service information in the broadcast communication cooperative service of the first embodiment. FIG. [Diagram 2] FIG. 2 is a diagram showing an example of an outline of a transmission path identification descriptor in the first embodiment. [Figure 3A] 13 is a diagram showing another example of the data structure of the service information in the broadcast communication cooperative service of the first embodiment. FIG. [Figure 3B] 13 is a diagram showing another example of the data structure of the service information in the broadcast communication cooperative service of the first embodiment. FIG. [Figure 4A] 11 is a flowchart showing an example of an operation on a receiving side in the broadcast communication cooperative service of the first embodiment. [Figure 4B] 13 is a flowchart showing another example of the operation of the receiving side in the broadcast communication cooperative service of the first embodiment. [Diagram 5] FIG. 2 is a block diagram showing an example of a configuration of a receiving device according to the first embodiment. [Figure 6A] 13 is a diagram showing an example of a data structure of service information in a broadcast communication cooperative service according to a first modification of the first embodiment. FIG. [Figure 6B]13 is a diagram showing an example of a data structure of service information in a broadcast communication cooperative service according to a first modification of the first embodiment. FIG. [Figure 7A] 13 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to the first modification of the first embodiment. [Figure 7B] 13 is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperative service according to the first modification of the first embodiment. [Figure 8] FIG. 11 is a block diagram showing an example of a configuration of a receiving device according to a first modification of the first embodiment. [Figure 9] 13 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to the second modification of the first embodiment. [Figure 10] FIG. 11 is a block diagram showing an example of a configuration of a receiving device in a second modification of the first embodiment. [Figure 11A] 13 is a diagram showing an example of a data structure of application control information in a broadcast communication cooperative service according to a fourth modification of the first embodiment. FIG. [Figure 11B] 13 is a diagram showing an example of a data structure of application control information in a broadcast communication cooperative service according to a fourth modification of the first embodiment. FIG. [Figure 12] 13 is a diagram showing another example of the data structure of application control information in the broadcast communication cooperative service according to the fourth modification of the first embodiment. FIG. [Figure 13A] 13 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to the fourth modification of the first embodiment. [Figure 13B] 13 is a flowchart showing a comparative example of the operation on the receiving side in the broadcast communication cooperative service of the fourth modification of the first embodiment. [Figure 14] 13 is a diagram showing an example of a data structure of service information in the broadcast communication cooperative service according to the first example of the second embodiment. FIG. [Figure 15] 13 is a flowchart showing an example of an operation on a receiving side in the broadcast communication cooperative service according to the first example of the second embodiment. [Figure 16A]FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in Example 2 of the second embodiment. [Figure 16B] FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in Example 2 of the second embodiment. [Figure 16C] FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in Example 2 of the second embodiment. [Figure 16D] FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in Example 2 of the second embodiment. [Figure 17] 13 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to Example 3 of the second embodiment. [Figure 18] 13 is a flowchart showing another example of the operation of the receiving side in the broadcast communication cooperative service according to the example 3 of the second embodiment. [Figure 19] 13 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to Example 4 of the second embodiment. [Figure 20] FIG. 13 is a block diagram showing an example of a configuration of a receiving device according to a fourth example of the second embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] (Findings on which the present invention is based) Currently, services that combine broadcasting and communications to deliver content (broadcasting and communications integrated services) are being considered. Among these, a method that focuses on broadcasting and accesses content acquired via communications (hereafter referred to as communications content) based on data acquired from broadcasting is particularly promising. When viewing begins on the receiving side of content in broadcasting and communications integrated services, it is expected that after acquiring service information, content reception will begin using encoded audio or video data, or a data carousel in the MPEG-2 system, as in conventional services that deliver content only via broadcasting.

[0013] However, the service information that can be acquired by the conventional services does not take into consideration the operation of quickly accessing communication content, the operation of selecting and receiving only broadcast content, etc. Therefore, when performing a broadcasting and communication cooperation service using the conventional service information, there are problems such as an increase in the processing related to the analysis of the service information and a delay in the timing of starting to acquire communication content.

[0014] Similarly, the hybrid cast standard, which was standardized by the IPTV Forum and has also been adopted by the ARIB standard, does not take into consideration operations such as quick access to communication content or operations when selecting and receiving only broadcast content.

[0015] In the conventional hybridcast specification, which was standardized by the IPTV Forum and has also been adopted in the ARIB standard, an HTML5 application is downloaded on the communication side and started when an event message is fired, etc. Therefore, it does not support playback control of communication content based on the PTS (Presentation Time Stamp) or DTS (Decoding Time Stamp) in the audio and video frames on the broadcast side, and there are issues such as not being able to support highly accurate synchronized playback, such as synchronizing the display time of broadcast content and communication content on a frame-by-frame basis.

[0016] In order to solve such problems, a transmission method according to one aspect of the present invention is a content transmission method capable of transmitting content using broadcast waves and a communication path, and when transmitting content using both the broadcast waves and the communication path, includes an information transmission step of including information regarding the content to be transmitted via the communication path in application control information, which information is for synchronizing the content via the broadcast waves with the content via the communication path when received by a receiving side, and transmitting the information using at least the broadcast waves of the broadcast waves and the communication path.

[0017] According to this aspect, it is possible to realize a content transmission method that enables rapid access to content via communication when content that combines broadcasting and communication is played back on the receiving side. More specifically, when content is transmitted using broadcast waves and a communication path, information for synchronizing the contents transmitted using the broadcast waves and the communication path is included in the application control information and transmitted, so that when the receiving side receives application control information including this information, the receiving side can be allowed to quickly access the content via communication according to this information, and the receiving side can be allowed to synchronize the contents.

[0018] Here, for example, in the information transmitting 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 source from which the content was obtained or information indicating the source from which the location information was obtained.

[0019] Also, for example, in the information transmitting step, difference information between a reference clock of the content by the broadcast wave and a reference clock of the content by the communication path may be included in the application control information and transmitted.

[0020] Also, for example, in the information transmission step, the application control information may be transmitted, thereby allowing the receiving side to achieve synchronization by synchronizing a reference clock of content via the communication path with a reference clock of content via the broadcast wave based on the difference information.

[0021] In addition, in order to solve the above problem, a receiving method according to one embodiment of the present invention includes a receiving step of receiving content transmitted using both a broadcast wave and a communication path, and a playback step of performing a synchronization process and playing the content when application control information for synchronizing the content transmitted via the broadcast wave and the content transmitted via the communication path, the application control information including information regarding the content transmitted via the communication path, is received from at least the broadcast wave of the broadcast wave and the communication path.

[0022] Here, for example, in the receiving step, the application control information may be received prior to receiving the content, and if the application control information includes location information indicating the location from which the content is to be obtained, the content may be received by obtaining the content based on the location information.

[0023] Also, for example, in the receiving step, the application control information is received prior to receiving the content, and if the application control information includes information indicating the source of location information indicating the source of the content, the location information may be obtained based on the information indicating the source of the location information, and the content may be received by obtaining the content from the obtained location information.

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

[0025] In addition, in order to solve the above problem, a transmitting device according to one embodiment of the present invention is a content transmitting device capable of transmitting content using broadcast waves and a communication path, and when transmitting content using both the broadcast waves and the communication path, is equipped with an information transmitting unit that includes information regarding the content transmitted via the communication path in application control information, which information is for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication path when received by the receiving side, and transmits the information using at least the broadcast waves of the broadcast waves and the communication path.

[0026] In addition, in order to solve the above problem, a receiving device according to one embodiment of the present invention includes a receiving unit that receives content transmitted using both broadcast waves and a communication path, and a playback unit that, when application control information is received, performs a synchronization process and plays the content, and when application control information is received that includes information for synchronizing the content transmitted via the broadcast waves and the content transmitted via the communication path and information related to the content transmitted via the communication path.

[0027] In addition, these general or specific aspects may be realized by a transmitting method, a transmitting device, a receiving method, a receiving device, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized by any combination of a data receiving method, an integrated circuit, a computer program, or a recording medium.

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

[0029] Note that the embodiments described below each show a specific example of the present invention. The numerical values, shapes, materials, components, the arrangement and connection of the components, steps, and the order of steps shown in the following embodiments are merely examples and are not intended to limit the present invention. Furthermore, among the components in the following embodiments, components that are not described in an independent claim showing a superordinate concept are described as optional components.

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

[0031] [How to send] In this embodiment, the transmitting side transmits content (data or assets) using broadcast waves and a communication path, but transmits service information prior to transmitting the content.

[0032] [Service Information] Here, service information refers to information for obtaining audio, video, or data related to data broadcasting after a channel selection operation (after channel selection), or a series of information related to receiving content or obtaining metadata, such as EPG (Electric Program Guide) information.

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

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

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

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

[0037] (Attribute information) 1) The attribute information may include information indicating whether the assets constituting the package are transmitted by (1) broadcasting only or (2) a combination of broadcasting and communication.

[0038] The information may indicate whether the audio and video data of the main content will be transmitted by (1) broadcasting only or (2) broadcasting and communication. This information allows the audio, video, still images, and metadata other than the main content, such as HTML files, to be acquired from the communication network even if the main content is transmitted by broadcasting only.

[0039] 2) When audio or video data is transmitted by both broadcasting and communication, information indicating the relationship between the data transmitted by each of the broadcasting and communication may be included as attribute information.

[0040] Here, for example, when realizing scalability (temporal resolution (e.g., 60 fps to 120 fps), spatial resolution (e.g., 4k to 8k), bit depth (e.g., 8 bit to 10 bit)), the attribute information can indicate that the base layer will be used for broadcasting and the enhancement layer will be used for communication. The attribute information may also indicate that the frame rate of broadcast data alone is 60 fps, but that the frame rate can be improved to 120 fps when communication data is used in combination. It may also indicate that backup data for broadcasting will be transmitted via communication. This allows the transmitting side to use the attribute information to switch to transmitting data via communication when the broadcast reception conditions deteriorate due to rain attenuation or the like.

[0041] The attribute information may also indicate information for identifying assets related to each other. For example, the attribute information may indicate an asset ID of a base layer and an asset ID of an 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 broadcasting and communication. In this case, identification information of the asset (such as an asset ID) may be separately indicated. Information for identifying related assets may be indicated by an individual transmission path identification descriptor for each asset, for example, as shown in FIG. 2. Here, FIG. 2 is a diagram showing an example of an outline of a transmission path identification descriptor in the first embodiment. The individual transmission path identification descriptor shown in FIG. 2 may indicate, for example, information for identifying whether the asset is a base layer asset or an extension layer asset, or, if the asset is an extension layer asset, may indicate the ID of the corresponding base layer asset.

[0043] In addition, the attribute information may group broadcast assets and communication assets, and indicate a list of assets included in each group. When there are assets that are transmitted by both broadcasting and communication, they may be grouped separately.

[0044] 3) Information indicating whether audio and video transmitted by broadcasting and audio and video transmitted by communication are played back in sync may be included as attribute information.

[0045] The attribute information may indicate each piece of information as an individual field, or may define information indicating the type of service so that the service can be identified by the type. The attribute information may be described in a format different from that of the descriptor.

[0046] The transmission path identification descriptor may be stored in a table or message indicating information on a package basis, which is different from the MPT. The contents of the transmission path identification descriptor may be described as a data structure different from the descriptor.

[0047] Furthermore, when transmitting a plurality of packages, a table or message showing a list of packages may be defined, and information such as a transmission path identification descriptor may be shown as package attribute information as information on a package unit basis.

[0048] 3A and 3B are diagrams illustrating another example of the data structure of the service information in the broadcast communication cooperative service according to the first embodiment.

[0049] That is, as shown in Figures 3A and 3B, the location information for each asset may be stored in separate MPTs for assets transmitted by broadcasting and communication. In this case, the attribute information of the package can be stored in the MPT sent in the transmission path that is the entry point of the service. For example, when broadcasting is the entry point, the package attribute information is stored in the MPT sent by broadcasting. Moreover, these MPTs can be identified by table_id.

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

[0051] The MPT of a broadcast asset may be transmitted by broadcasting, and the MPT of a communication asset may be transmitted by communication.

[0052] Also, the location information of broadcasting and communication assets may be stored in one MPT. In this case, the location information of each asset may be stored consecutively so that it can be easily identified. For example, if there are N1 broadcasting assets and N2 communication assets, first, the information of the N1 broadcasting assets is described consecutively, and then the information of the N2 communication assets is described consecutively. Note that the transmission path identification descriptor may indicate that the N1 assets are transmitted by broadcasting and the N2 assets are transmitted by communication.

[0053] In this way, the transmitting side transmits the service information including the transmission path identification descriptor, which is auxiliary information. As a result, the receiving side can obtain in advance, by simply acquiring the service information including the auxiliary information, whether communication data is included or not, or the dependency relationship between the broadcast data and the communication data, 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 communication data is received, there is an advantage in that the delay time associated with starting the reception process can be reduced.

[0055] [Transmitting device] For example, the transmitting device of this embodiment is a content transmitting device capable of transmitting content using broadcast waves and communication paths, and generates package attribute information such as a transmission path identification descriptor as auxiliary information, and transmits it by including it in the service information.

[0056] The transmitting device of 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] In addition, the entry point is not limited to broadcasting, but may be communication, or entry may be possible from both broadcasting and communication. When entry is possible from both, package-based information is transmitted from at least both broadcasting and communication transmitting devices.

[0058] Note that when the receiving side receives the content of the broadcasting and communication cooperation service, it is not necessary to receive data transmitted through both transmission paths. For example, only the broadcast data may be received and played. In this case, since the information required when the receiving side receives the communication data is not required when receiving the broadcast data, the transmitting side may transmit the information required when receiving the communication data in the communication. In other words, the transmitting side may transmit information in package units through a transmission path that serves as an entry point, and transmit information specific to the transmission path such as broadcasting and communication through each transmission path (for example, FIG. 2). Note that in the following description, it is assumed that broadcasting is the entry point.

[0059] In this way, the service information specific to each transmission path can be generated and transmitted by the transmitting device in each transmission path. However, the information transmitted by MPT, such as asset location information, can be transmitted by broadcasting because the delay time associated with the start of asset acquisition on the communication side can be reduced by first acquiring the information all at once.

[0060] (Examples of communication-specific information) Examples of information specific to communications (communications networks such as the Internet and CDNs (Content Delivery Networks)) are shown below.

[0061] 1) Information related to FEC (Forward Error Correction) in packets sent via communication, such as FEC method and parameters 2) Information related to QoS (Quality of Service) control, such as packet loss rate, packet arrival time jitter, RTT (Round Trip Time), and end-to-end delay in a communication channel 3) Information about buffering from the time the asset data is received until the start of decoding, such as buffering time and amount

[0062] In broadcasting, FEC and QoS are important, especially for broadcasting for mobile devices (such as one-segment broadcasting in Japan), but the parameters for these are different from those for communication paths. Therefore, information specific to broadcasting only needs to be transmitted 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 the bit rate and frame rate. At this time, information that associates attribute information (such as bit rate) of the selectable data with the asset ID may be transmitted. Note that such association information may be transmitted in a broadcast.

[0064] The associated information may indicate whether or not there are multiple selectable assets, or, if there are multiple selectable assets, may indicate a list of the selectable assets.

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

[0066] Fig. 4A is a flowchart showing an example of an operation of a receiving side in the broadcast communication cooperation service according to the embodiment 1. Fig. 4A shows an example of an operation in which a receiving device acquires a transmission path identification descriptor according to the embodiment and determines an asset to be received.

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

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

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

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

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

[0072] 1) When the receiving device is not connected to a communication network, it determines to receive only broadcast assets, and does not receive assets transmitted by both broadcast and communication.

[0073] 2) In the case where the base layer of a video is transmitted by broadcast and the enhancement layer is transmitted by communication, if only the base layer can be played back, it is determined to receive only the broadcast, and if both layers can be played back, it is determined to receive both the broadcast and communication. For example, it is assumed that a temporal scalability of 60 fps can be realized with only the base layer, and 120 fps with the base layer and enhancement layer. In this case, if the receiving device can only decode and display up to 60 fps, it will only receive the broadcast data, and if it can decode and display up to 120 fps, it will receive both the broadcast and communication data.

[0074] 3) A receivable asset is determined from among a plurality of assets with different bit rates transmitted by communication according to the bandwidth of the communication network to which the receiving device is connected. Here, for example, information such as the bit rate of each asset is transmitted separately in service information, etc. Note that when the reception state is poor due to congestion of the communication network, etc., and there are no assets that can be stably received, it may be determined not to receive data from the communication side.

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

[0076] 5) When receiving data (such as video enhancement layer data) from communication that is played back in synchronization with the main audio or video data transmitted by broadcasting, special operations such as buffering the data before playback starts may be required to ensure synchronization between the data received by broadcasting and the data received by communication. In this case, only assets that do not require strict synchronization (such as frame-by-frame synchronization) with the data transmitted by broadcasting may be received from communication. For example, assets such as HTML data, still images, and videos that do not require strict synchronization may be determined to be acquired from communication.

[0077] Returning to the flowchart of FIG. 4A, the following description will be given.

[0078] Next, in step S103, it is determined (judged) whether or not to receive the asset transmitted by communication. If it is determined (judged) that the asset will be received (Yes in S103), the process proceeds to S104; if it is determined (judged) that the asset will not be received (No in S103), the process proceeds to S105.

[0079] In S104, assets are received from both the broadcast and communication transmission paths, and in S105, assets are received only from the broadcast.

[0080] FIG. 4B is a flowchart illustrating another example of the operation on the receiving side in the broadcast communication cooperative service according to the first embodiment.

[0081] In comparison with Fig. 4A, Fig. 4B adds a step (step S106) of receiving service information specific to the communication when the service information is transmitted in the communication. The rest is the same as that described in Fig. 4A, so the description will be omitted.

[0082] If there is service information specific to the broadcast, it is assumed that this is received separately in a step not shown.

[0083] In addition, if the receiving device does not support the broadcast communication cooperation service, it is sufficient to receive only the broadcast assets. In this case, if there is an asset transmitted by combining broadcast and communication, the asset is not received.

[0084] [Receiving device] Fig. 5 is a block diagram showing an example of the configuration of a receiving device in embodiment 1. Fig. 5 shows an example of the configuration of a 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 judgment unit 103, a broadcast receiving unit 104, and a communication receiving unit 105.

[0086] The identification information acquisition unit 101 has a function of implementing step S101 shown in Fig. 4A. Specifically, the identification information acquisition unit 101 acquires service information transmitted on a transmission path serving as an entry point, and acquires a transmission path identification descriptor (auxiliary information) included therein. 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 for implementing step S102 shown in FIG. 4A, and determines an asset to be received based on the playback capability of the terminal or whether a communication path is available.

[0088] The determination unit 103 has a function for realizing step S103 shown in Fig. 4A, and decides (determines) whether to receive an asset transmitted by communication. Specifically, the determination unit 103 determines whether to receive communication data, and when it is determined to receive the data, the broadcast receiving unit 104 and the communication receiving unit 105 receive the data of the asset determined in step 102.

[0089] If the determination unit 103 determines that communication data is not to be received, it receives the data using only the broadcast receiving unit 14 .

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

[0091] 6A and 6B are diagrams showing an example of the data structure of service information in the broadcast communication cooperation service of the first modification of the first embodiment. Fig. 6A shows an example of storing information on data transmitted in communication in a PMT. Fig. 6B shows an example of the data structure of a transmission path identification descriptor of this modification.

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

[0093] In the program information in the TS such as the PMT, only the location information of the data transmitted by the TS is indicated. Therefore, in this modification, when the content data is transmitted by also using communication, 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 or not communication is also used. This allows the transmitting side to select whether or not 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 that indicates the source of data, and corresponds to a PID in the case of TS, or a URL or URI in the case of communication.

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

[0096] In addition, the location information may store information indicating a source of the location information entity data, not limited to the case where the location information entity data such as MPD or SDP is stored. Here, the information indicating a source of the location information entity data is, for example, information indicating a URL for acquiring an MPD. However, when information indicating a source of the location information entity data is stored in the location information, a delay occurs due to separately acquiring the location information entity data. Therefore, from the viewpoint of reducing the delay until the communication side starts receiving data, it is desirable to directly store the entity data in the location information.

[0097] In addition, the DASH MPD is large in size because it contains various information related to the content acquisition destination. Therefore, instead of storing the MPD as is in the location information, subset information including only the URL of the content acquisition destination and information related to the DTS and PTS of the segment may be stored.

[0098] It is also desirable to be able to handle updates to the content of location information such as MPD.

[0099] For example, a version number may be assigned to the location information. This allows the location information to be reacquired when the version number is updated. Note that, in order to confirm whether the version number has been updated, information such as the transmission path identification descriptor in the cyclically transmitted PMT may be checked sequentially. However, since this sequential checking process is heavy, section data for storing the location information, etc. may be generated separately (called a transmission path identification section) and transmitted 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 attribute information and location information may be transmitted in both the program information such as the PMT and the transmission path identification section. Alternatively, only location information may be stored in the transmission path identification section.

[0101] In addition, after starting to acquire data on the communication side based on location information acquired from broadcasting, updated content of the location information may be acquired in communication. At this time, since the source of acquisition of the location information is required, the source of acquisition of the location information may be stored together with the entity data of the location information in the transmission path identification descriptor of the broadcasting, etc.

[0102] The receiving device can obtain updated information through communication, for example by periodically accessing the source of location information.

[0103] In addition, if there is a mechanism for exchanging messages between a DASH content delivery server and a receiving device, the server may issue a message to the receiving device indicating that the location information has been updated. Then, when the receiving device receives the message, the receiving device may reacquire the location information.

[0104] Although the information regarding data transmitted in communication is stored in the PMT in the description, this is not limiting. Attribute information and location information may be transmitted in a section different from the PMT.

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

[0106] For example, in the case of synchronous playback, the data on the communication side can be accessed from the program information of the broadcast as described above. In the case of non-synchronous playback, information for accessing the data on the communication side can be transmitted by data broadcasting using, for example, an AIT (Application Information Table) defined in the hybrid cast specifications of the Association of Radio Industries and Businesses (ARIB). The receiving device receives the AIT in the form of a table or carousel, and acquires the data on the communication side based on the contents of the AIT. The acquired data on the communication side starts to be played back when an event message transmitted by data broadcasting is received.

[0107] Information such as the AIT may also be used when broadcast data and communication data are played back synchronously. In this case, the playback start and end times of the communication data are separately indicated in the data broadcast. The receiving device plays back the communication data according to these times.

[0108] In the MPD in DASH and the SDP in RTP, the playback start time or the decoding start time of the content can be indicated, and these times are specified based on a reference clock defined for each multiplexing or transmission method, such as UTC (Coordinated Universal Time). In addition, the presentation time stamp (PTS) and decoding time stamp (DTS) of each video frame and audio sample are also set based on the reference clock. On the other hand, in broadcasting, since the program clock reference (PCR) is the reference clock, when the broadcast data and the communication data are synchronously played back, information indicating the correspondence between the respective reference clocks is required.

[0109] Therefore, information indicating the correspondence between the reference clocks of the broadcast data and the communication data may be included in the program information such as the PMT in the broadcast. For example, the information may indicate that the time when the PCR value in the broadcast is N1 and the time when the UTC value in the communication is N2 correspond to the same time. This information may be included in the MPD, SDP, etc.

[0110] The transmission path identification descriptor may also indicate 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), etc. This enables the receiving device to open a port used in each protocol, or to determine whether the protocol being used is supported.

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

[0112] [How to receive] Hereinafter, with reference to the drawings, an example of the operation of the receiving device in the case where broadcasting is transmitted using TS and communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like will be described as a receiving method in this modified example.

[0113] Fig. 7A is a flowchart showing an example of an operation of a receiving side in a broadcast communication cooperation service according to Modification 1 of Embodiment 1. Fig. 7A shows an example of an operation of a receiving device when attribute information and location information are stored in program information of a broadcast.

[0114] The operation of each step (step S201 to step S205) is the same as the flowchart in Fig. 4A, but the difference is that while in Fig. 4A the data on the broadcast side and the communication side are unified as assets of the MMT package, in Fig. 7A the data on the broadcast side is TS and on the communication side is DASH or RTP data. Other points are as explained in Fig. 4A, so detailed explanations are omitted.

[0115] Fig. 7B is a flowchart showing another example of the operation of the receiving side in the broadcast communication cooperation service of Variation 1 of Embodiment 1. Fig. 7B shows an example of the operation when attribute information and access information for acquiring location information are stored in the broadcast program information, but the actual location information is not stored.

[0116] Step S301 is similar to step S201, and therefore the description will be omitted.

[0117] Next, in step S302, it is determined (judged) whether or not to receive communication side data, and in step S303, if communication side data is to be received, the process proceeds to S304, and if communication side data is not to be received, the process proceeds to S306.

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

[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 also acquired, and in S306, only data transmitted by broadcast is acquired.

[0120] (Attribute information) The attribute information is similar to that described in embodiment 1, however, since embodiment 1 was described using MMT as an example, the following describes an example in which TS is used for broadcasting and DASH or RTP is used for communication.

[0121] 1) The attribute information may include information indicating whether the data such as audio and video that constitute the content will be transmitted by either (1) broadcasting only or (2) a combination of broadcasting and communication.

[0122] The information may indicate whether the audio and video data are transmitted by (1) broadcasting only or (2) broadcasting and communication. This information allows the audio, video, still images, and metadata such as HTML files to be obtained from a communication network separate from the main content, even if the main content is transmitted by broadcasting only.

[0123] 2) When audio or video is transmitted by both broadcasting and communication, information indicating the relationship between the data transmitted by each of the broadcasting and communication may be included as attribute information.

[0124] Here, for example, when realizing scalability (temporal resolution (e.g., 60 fps to 120 fps), spatial resolution (e.g., 4k to 8k), bit depth (e.g., 8 bit to 10 bit)), the attribute information can indicate that the base layer will be used for broadcasting and the enhancement layer will be used for communication. The attribute information may indicate, as a use case, that the frame rate of broadcast data alone is 60 fps, but that the frame rate can be improved to 120 fps when communication data is used in combination. The attribute information may also indicate that backup data for broadcasting will be transmitted via communication. This allows the transmitting side to use the attribute information to switch to transmitting data via communication when the broadcast reception conditions deteriorate due to rain attenuation or the like.

[0125] The attribute information may also indicate information for identifying encoded streams related to each other. For example, the attribute information may indicate identification information of video data such as a PID of a TS packet in which data of a base layer transmitted by broadcasting is stored, a segment in DASH data transmitted by communication, or a track ID in MP4.

[0126] The attribute information may also indicate information indicating broadcast data and communication data that are synchronously played back with each other, allowing the transmitting side to transmit, for example, multi-viewpoint video or parent and child screen video in a picture-in-picture by broadcasting and communication, respectively.

[0127] 3) Information indicating whether audio, video, etc. transmitted by broadcasting and audio, video, etc. transmitted by communication are reproduced in sync with each other may be included as attribute information.

[0128] 4) Information indicating whether the clock information of audio and video transmitted by broadcasting is the same as the clock information of audio and video transmitted by communication may be included as attribute information.

[0129] 5) Information indicating whether the data on the communication side is live content may be included as attribute information.

[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 reception from data whose playback time is the time (T2) obtained by adding the total time (△T) required from the content acquisition request to the start of reception (or an estimate thereof) and the time to buffer the data to the current time, the broadcast data can be played back without delay. At this time, the communication data is played back from time T2. On the other hand, if the content to be transmitted is live content, the broadcast data may be buffered for △T, and playback of both the broadcast and communication data may start at time T2.

[0131] When the communication side multicasts or broadcasts the content using RTP or the like, data after the current time cannot be obtained regardless of whether the content is live or not. Therefore, information indicating whether the data on the communication side is multicast or broadcast may be included in the attribute information.

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

[0133] Fig. 8 is a block diagram showing an example of the configuration of a receiving device in Variation 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 decision unit 302, a communication joint 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 of Fig. 7A corresponds to the case in Fig. 8 where the Loc information acquisition unit 304 is not present.

[0135] The identification information acquisition unit 301 has a function of implementing step S301 shown in Fig. 7B. Specifically, the identification information acquisition unit 301 acquires service information transmitted on a transmission path serving as an entry point, and acquires a transmission path identification descriptor (auxiliary information) included therein. 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 implementing step S302 shown in FIG. 7B, and determines the data to be received based on the playback capability of the terminal or whether a communication path is available.

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

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

[0139] (Variation 2) In this modified example, an example of a receiving method will be described in which attribute information and location information are stored in broadcast program information and transmitted.

[0140] [How to receive] Fig. 9 is a flowchart showing an example of the operation of the receiving side in the broadcast communication cooperation service of Modification 2 of Embodiment 1. Fig. 9 shows an example of the operation from when attribute information and location information are stored in broadcast program information and transmitted, until when the receiving device determines whether or not to synchronously play back the broadcast content and the communication content and plays them back.

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

[0142] First, program information transmitted on a transmission path serving as an entry point is obtained, a transmission path identification descriptor contained therein is obtained, and attribute information of the content and location information of the communication content are obtained (step S401).

[0143] Here, if the entity of the location information is not stored in the program information, the entity data of the location information is obtained in the same manner as described in FIG. 7B.

[0144] Next, the data to be received is determined based on the reproduction capability of the receiving device or whether a communication path is available (step S402).

[0145] Next, it is determined whether or not to acquire communication content (step S403), and if it is determined to acquire communication content (Yes in S403), the process proceeds to step S404, where data is received from both the broadcast and communication transmission paths. If it is determined (determined) not to receive the content (No in S403), the process proceeds to step S409, where data is received only from the broadcast, and only the broadcast content is played back in step S410.

[0146] Next, it is determined whether or not the broadcast content and the communication content are to be synchronously played back (step S405).

[0147] If it is determined that the contents are to be played back in a synchronized manner (Yes in S405), the reference clocks of the broadcast content and the communication content are synchronized in step S406, and the two contents are played back in a synchronized manner in step S407.

[0148] The synchronization of the reference clock in S406 may be performed prior to S404. This is because, in cases where playback is started after pre-buffering the received data of the content, decoding and playback may be started after confirming that data with a PTS of T1 in the broadcast content and data with a PTS of T1 in the communication content (where the PTSs of both are assumed to be already synchronized) have been received, and therefore, when determining whether the data to be played back in sync with each other are available, it is necessary that the reference clocks of both are already synchronized.

[0149] Furthermore, in synchronizing the reference clock in S406, it is possible to align it with the reference clock used in either broadcasting or communication. For example, if PCR (Program Clock Reference) is used in broadcasting and NTP (Network Time Protocol) is used in communication, the reference clocks in broadcasting and communication can be synchronized by converting the NTP-based DTS and PTS for video and audio to the PCR-based DTS and PTS for broadcasting and communication. Also, the DTS and PTS for broadcasting and communication may be converted so as to be synchronized with a unique clock used in the receiving device.

[0150] In addition, in Figure 9, we have explained the operation when attribute information and location information are stored in the broadcast program information and transmitted, but if there is no need for synchronous playback in the first place, the transmission path identification descriptor describing this information does not have to be stored in the broadcast program information.

[0151] In addition, the reference clock can be synchronized with the clock used in either broadcasting or communication. For example, if PCR (Program Clock Reference) is used in broadcasting and NTP (Network Time Protocol) is used in communication, the reference clocks in broadcasting and communication can be synchronized by converting the NTP-based DTS and PTS for video and audio to the PCR-based DTS and PTS. The DTS and PTS for broadcasting and communication may be converted so as to be synchronized with a unique clock used in the receiving device.

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

[0153] The receiving device 400 shown in FIG. 10 includes an identification information acquisition unit 401, a determination unit 402, a communication use 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 reception unit 406 are similar to the identification information acquisition unit 301 to the communication reception unit 306 described with reference to FIG. 8, and therefore a description thereof will be omitted.

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

[0156] The playback unit 408 decodes and plays back the broadcast content or the communication content based on the playback method determined by the results of the determination made by the communication concurrent use determination unit 403 and the synchronization determination unit 407 .

[0157] (Variation 3) Below, other examples that are different from those described above will be described.

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

[0159] In addition, when package-based information such as a transmission path identification descriptor is not indicated, location information for each asset such as that shown in Figures 1A and 1B may be interpreted to determine whether each asset is transmitted by broadcast or communication, or whether there are any assets in the package that are transmitted by communication.

[0160] (Location information) The location information may include URL information of the acquisition destination of the asset. If the acquisition destination is a URL, it is possible to determine whether the asset is transmitted by broadcasting or communication based on whether the URL is a specific URL predefined in the broadcasting service.

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

[0162] (MPT description variation) In the above-mentioned Fig. 1A and Fig. 1B, the location information for each asset and an individual transmission path identification descriptor are defined as the information for each asset, but the present invention is not limited to this. A field indicating the encoding method of the asset may be provided separately. The encoding method is essential information for decoding, and it is desirable to signal it in information that can be obtained prior to decoding, such as MPT. For example, information such as stream_type in the MPEG-2 system can be used.

[0163] In addition, in the case of a coding method that allows scalable coding, along with the coding method, it may be indicated whether the asset is a base layer or an enhancement layer.

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

[0165] This information can be indicated in the program information in the broadcast, even when the broadcast uses TS and the communication uses DASH or RTP. For example, in the PMT descriptor, it is possible to describe the dependency between the video stream transmitted by the broadcast and the video stream transmitted by the communication (e.g., the video stream on the communication side corresponds to an extension layer), or information indicating the coding method of the video and audio on the communication side. It may also be possible to indicate whether the stream on the broadcast side and the stream on the communication side are played back in sync.

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

[0167] For example, when selecting viewing or scheduling a recording from the EPG, if the data transmitted via communication cannot be played back or recorded because the device is not connected to a communication network or the receiving device does not support obtaining data via communication, a message to that effect may be displayed.

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

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

[0170] The same operation may also be performed when, for example, programming recording of a program.

[0171] In broadcasting, etc., a user can select multiple programs at any time, and even if communication data of the next program on the channel being viewed is received in advance, if the viewed program is switched, there is no advantage to receiving the communication data in advance. Therefore, at any viewing time, the communication side data may be buffered in advance for all programs that can be viewed after the viewing time and whose data is transmitted by both broadcasting and communication. 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 data and the communication data are synchronously reproduced may be included in the program information such as EPG, and if the data is synchronously reproduced, the communication data may be buffered in advance. If the data is not synchronously reproduced, the communication data may be received after the broadcast data has started to be received.

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

[0174] In addition, this information may be stored in the control information used when demodulating a signal transmitted through a transmission path, such as a TMCC signal in the Japanese broadcasting system (ISDB-T).

[0175] This makes it possible to determine at the time of demodulation whether reception is necessary in communication, thereby speeding up the startup of the communication side.

[0176] (format) Note that the HTTP-based file format is not limited to DASH, but may be HTTP Live Streaming (HLS), Microsoft Smooth Streaming (MSS), etc. These formats also have content management information equivalent to MPD, so the relationship between the data on the broadcast side and the data on the communication side can be shown using a mechanism similar to DASH.

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

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

[0179] For example, when DASH is used on the communication side, attribute information of the entire content, such as whether the broadcast content and the communication content are synchronously played back, or whether the broadcast content is the base layer of scalability and the communication content is the extended layer, may be stored in a transmission path identification descriptor, etc. On the other hand, individual attributes for each stream, such as information for identifying video and audio that are the targets of synchronous playback, may be stored in the MPD.

[0180] As an example of attributes for each stream, when video in broadcasting is associated with audio of secondary audio transmitted in communication, the PID of the TS packet storing the video may be associated with information for identifying an audio track or segment in DASH data, such as an audio track ID, or an adaptation set or representation, in the MPD. Here, the identification information of the media on the broadcasting side may include, in addition to the PID, the ID of a transport stream including a TS packet of the PID, a service ID, etc.

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

[0182] In addition, both the overall attribute and the individual attribute may be described in either a descriptor such as a PMT in broadcasting or an MPD, or may be described in both. For example, in broadcasting, they may be described in a descriptor of application control information such as an AIT.

[0183] (Attribute information) Furthermore, the attribute information may include a method for synchronizing clock information of streams transmitted over different transmission paths, such as broadcasting and communication. 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 there is no need to synchronize their clocks with each other.

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

[0187] Method 3) Synchronize by referencing an independent stream that contains information for clock synchronization, such as the TS timeline extension (13818-1:2013 / AMD6 (2nd WD)) currently being standardized by MPEG.

[0188] In method 3, the attribute information may include the PID of a TS packet that stores a stream for clock synchronization.

[0189] (Variation 4) Hybridcast is a new service that combines broadcasting and communications and has been standardized by the IPTV Forum and is also included in the ARIB standard.

[0190] In the conventional hybridcast specification, which was standardized by the IPTV Forum and has also been adopted in the ARIB standard, the link between broadcasting services and communication services is based on application control information (AIT: Application Information Table).

[0191] However, in the conventional Hybridcast specification, an HTML5 application is downloaded on the communication side and the application is started when an event message is fired, etc. Therefore, the conventional Hybridcast specification does not support playback control of communication content based on the PTS (Presentation Time Stamp) or DTS (Decoding Time Stamp) in the frames of audio and video on the broadcast side, and is not capable of high-precision synchronized playback such as synchronizing the display times of broadcast content and communication content on a frame-by-frame basis.

[0192] In this modification, a mechanism for synchronizing and playing back broadcast content and communication content with high accuracy by extending the conventional hybrid cast specifications will be described.

[0193] In the following, the extension of application control information that enables highly accurate synchronized playback will be described, and then the transmission method, playback method, etc. in this modified example will be described.

[0194] [Execution mode] In the application control information of this modification, information indicating the execution mode when executing an application is newly introduced. There are two execution modes, mode 1 and mode 2, and examples of the execution modes are shown below.

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

[0196] In Mode 1, like conventional Hybridcast standard applications, startup or state transition is performed by control codes such as AUTOSTART, PRESENT, and PREFETCH, or event messages. In Mode 1, synchronous playback with reference to the PTS or DTS of other audio or video streams is not required.

[0197] For example, an application example in the conventional hybrid cast standard is VOD (Video On Demand). With this VOD, when an application is started, a UI with a play start button and other buttons is displayed, and when the user presses the play start button, the content starts to be downloaded or streamed and played.

[0198] (Mode 2) Mode 2 is an execution mode that requires highly accurate synchronization with contents transmitted via transmission paths other than broadcast waves.

[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, the base layer data transmitted by broadcast and the enhancement layer data acquired by an application are decoded and displayed using the mutually synchronized DTS and PTS, respectively. Here, the streams of audio, video, etc. that are played back in synchronization with each other are acquired by referring to the attribute information of the content described above.

[0200] (Application behavior in mode 2) In the application, the playback method of the content on the communication side is determined based on the execution mode. The operation in mode 1 is the same as in the past, so a description thereof is omitted. Below, the operation of the application in mode 2 is described.

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

[0202] If only the communication content is decoded and played back according to the DTS or PTS converted to the synchronized clock after clock synchronization has been performed, the communication content can be processed independently of the playback process of the broadcast content.

[0203] On the other hand, when spatial scalability is applied to video and the base layer is transmitted by broadcasting and the enhancement layer is transmitted by communication, the enhancement layer is decoded using the decoding result of the base layer, so it is necessary to control the decoding processes of the broadcast content and the communication content in an integrated manner. In addition, when the broadcast content and the communication content are pre-buffered before playback is started, or when the reception buffer of either content overflows or underflows during playback, it is necessary to control the playback processes of both transmission paths in an integrated manner. For example, the reception of data on the overflowed side is stopped, or when underflow occurs, the playback processes of both the broadcast content and the communication content are stopped until data of a predetermined length of time or a predetermined data size can be received.

[0204] Here, when at least one of the processes from reception to decoding and playback on both transmission paths is to be controlled in an integrated manner, control commands are exchanged between the application on the communication side and the playback processing unit of the broadcast content. For example, the system operates according to the following control commands.

[0205] 1) Decoding process-related: For example, this is performed by a control command that requests and obtains data of an access unit that corresponds to a specific DTS or PTS. Note that only at the start of playback, an access unit synchronized with broadcasting and communication is obtained, and thereafter, a control command may be used to request and obtain data of the access unit that is immediately following in ascending order of DTS or PTS.

[0206] 2) Data reception related: Operates according to a control command that instructs the stopping / restarting of data reception, or notifies that a data amount that satisfies a predetermined condition has accumulated in a pre-buffering buffer. Note that when data reception is stopped or restarted, subsequent processing such as decoding and playback may also be stopped or restarted, or a control command for a specific subsequent processing may be specified separately.

[0207] In addition, when an application operates in mode 2, there are two main ways to deal with overflow or underflow of the pre-buffering buffer: waiting until data is available on both transmission lines before playing, or playing only the data that is available and skipping the data that is not available.

[0208] Therefore, in addition to specifying the playback mode, information indicating how to deal with overflow or underflow of the pre-buffering buffer may be specified.

[0209] For example, in broadcasting, there is no congestion on the transmission line and no underflow due to congestion, so broadcast content is played back according to the DTS and PTS of the access unit. If the buffer for communication content underflows due to congestion on the communication line, playback of the access unit of the communication content for which no data exists in the DTS is skipped.

[0210] Here, when DASH is used as the communication content, when the buffer underflows, playback can be started quickly by skipping some segments without acquiring all of the subsequent segments.

[0211] More specifically, suppose that the DASH segments are SEG1, SEG2, SEG3, ... in ascending order of DTS, and the DTS of the first access unit of the segments is T1, T2, T3, .... In this case, if an underflow occurs during reception of SEG1, by skipping reception of SEG2 and receiving SEG3, it becomes more likely that the data of the first access unit of SEG3 will be received at time T3, and as a result, it becomes possible to start decoding and playing both broadcast and communication contents from time T3. When SEG2 is received, it is highly likely that the underflow state will continue, so by skipping the received segment, it is expected that playback can be resumed quickly.

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

[0213] In addition, if the attribute information of the content transmitted by the broadcast PMT or the like indicates that the communication content is to be played back in synchronous with the broadcast content, or if the location information of the communication content can be identified as a specific file such as a DASH MPD based on the extension of the location information, the execution mode may be determined without explicitly describing the execution mode as control information.

[0214] Furthermore, when content transmitted through a plurality of transmission paths is to be played back in a synchronized manner, the entire process from reception of broadcast and communication to playback may be controlled by a single application.

[0215] [Application Control Information] Next, an example will be described in which, in the hybrid cast specification, when broadcast content and communication content are synchronously played back, information related to data transmitted in communication is stored in application control information.

[0216] 6A and 6B show an example in which the location information of the data on the communication side is stored in the transmission path identification descriptor and then stored in the PMT. In this modification, an example in which the transmission path identification descriptor is stored in the application control information will be described.

[0217] In the conventional Hybridcast specification, a transmission path identification descriptor is not stored in the application control information, and location information must be acquired after the application is executed, which causes delays. In contrast, by storing a transmission path identification descriptor in the application control information and describing (placing) location information in the transmission path identification descriptor, content acquisition can be started more quickly.

[0218] Here, the application control information is, for example, an AIT (Application Information Table), which is information that controls the start and end of an application, as well as resources and access. For example, the application control information describes an application ID that identifies an application, a control code that can control the life cycle of the application, such as start and end, and location information of the application. Furthermore, the application control information is specified in a section format and an XML format, and the transmission method includes a method of transmitting in a section format and a method of transmitting application control information in XML format by a data carousel. When transmitting application control information, a data encoding method descriptor including ait_identifier_info() is placed in the ES loop of the PMT.

[0219] 11A and 11B are diagrams showing an example of a data structure of application control information in a broadcast communication cooperative service according to Modification 4 of Embodiment 1. Specifically, Fig. 11A and 11B show an example in which information on data transmitted in communication is stored in application control information in a section format.

[0220] In this modification, a transmission path identification descriptor is also stored in the descriptor for each application in order to indicate the attribute information and the like described in Figures 1A and 1B. For example, since program information in a TS such as a PMT indicates only location information of data transmitted by the TS, when content data is transmitted using communication in combination, location information of 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 also used, and whether to include location information of data on the communication side is selected depending on the value of the flag information.

[0221] Here, location information is information indicating the source of data, and corresponds to a PID for a TS section, a URL or URI for communication, etc. As location information, MPD (Media Presentation Description) in DASH, SDP (Session Description Protocol) in RTP, etc. can be stored.

[0222] Note that a separate descriptor may be defined to store the location information. Also, instead of storing the entity data of the location information, such as MPD or SDP, information indicating the acquisition destination of the entity data may be indicated.

[0223] For example, it is possible to indicate a URL for acquiring the MPD. However, since a delay occurs due to separately acquiring the entity data of the location information, it is preferable to directly store the entity data in order to reduce the delay until the communication side starts receiving data. However, since the MPD of DASH includes various information related to the acquisition destination of the content, the size of the MPD is large. Therefore, instead of storing the MPD as it is, it is also possible to store subset information including only the URL of the acquisition destination of the content and information related to the DTS and PTS of the segment.

[0224] In this modification, as shown in FIG. 11A and FIG. 11B, an example has been described in which the transmission path identification descriptor is stored in a loop for each application, but the present invention is not limited to this.

[0225] For example, when one transmission path identification descriptor is used by multiple 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, the remaining application loops can be omitted by indicating 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 identification descriptor may be stored in a loop (loop count N) immediately under application control information, an identifier capable of identifying the transmission path identification descriptor may be assigned, and the identifier to be referenced in each application may be referenced.

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

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

[0229] Also, information indicating the acquisition source of the entity of the location information may be indicated inside the application. In this case, instead of indicating the acquisition source of the entity of the location information, information that can identify the application whose acquisition source is indicated (for example, application ID or URL of the application) may be indicated, or the acquisition source of the entity of the location information may not be indicated.

[0230] 12 is a diagram showing another example of the data structure of application control information in the broadcasting and communication cooperative service of the fourth modification of the first embodiment. That is, in this modification, as shown in FIG. 12, information indicating that the application information identifier includes a transmission identification descriptor 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 more quickly that the content is broadcasting and communication cooperative content, and the time required for synchronous playback of broadcast and communication can be shortened.

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

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

[0233] In this modification, the application control information is described using the section format, but 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 the section format or the XML format.

[0234] In this modification, a different section may be defined without using application control information to achieve a similar function. In this case, information for identifying a section including a transmission path identification descriptor (such as a PID or a stream type) may be stored in the PMT. It is desirable to be able to handle updates to the contents of location information such as the MPD. For example, the version number of the application control information may indicate that the MPD has been updated, or a control code in the application control information may be used to indicate that the MPD has been updated when the control code is indicated as MPD_CHANGE, or when the MPD is acquired from communication, the control code may be set as MPD_REROAD to cause the application to reacquire the MPD.

[0235] In this modification, attribute information and location information may be transmitted in both program information such as a PMT and a transmission path identification descriptor. In this case, only location information may be stored in the transmission path identification descriptor.

[0236] In addition, in this modification, after starting to acquire data on the communication side based on location information acquired from broadcasting, updated content of the location information may be acquired in communication. At this time, since the acquisition destination of the location information is necessary, the acquisition destination of the location information may be stored together with the entity data of the location information in the transmission path identification descriptor of the broadcasting. The receiving device can acquire the updated content in communication by periodically accessing the acquisition destination of the location information. When a mechanism such as message exchange exists between the distribution server of the DASH content and the receiving device, the server may issue a message indicating that the location information has been updated to the receiving device, and the receiving device may reacquire the location information when receiving the message.

[0237] In this modification, information indicating the correspondence between the reference clocks of the broadcasting data and the communication data, as described with reference to Figs. 6A and 6B, may be included in the transmission path identification descriptor or the application control information.

[0238] In addition, in this modification, the transmission path identification descriptor may indicate information on a transport layer protocol, such as whether data on the communication side is transmitted by UDP (User Datagram Protocol) or TCP (Transmission Control Protocol). This enables the receiving device to open a port used in each protocol, or to determine whether the protocol used is supported. Also, identification information of the multiplexing format in the data on the communication side may be indicated to identify, for example, whether it is DASH or RTP. This makes it possible to determine that the location information is described in the MPD format if the multiplexing format is DASH, for example.

[0239] [How to send] In this embodiment, the transmitting side transmits content (data or assets) using broadcast waves and a communication path, but transmits application control information prior to transmitting the content.

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

[0241] Fig. 13A is a flowchart showing an example of the operation of the receiving side in the broadcast communication cooperation service of the fourth modification of the first embodiment. Fig. 13A shows an example of the operation when attribute information and location information are stored in the broadcast application control information. It is assumed that the assets shown in Fig. 13A are TS data on the broadcast side and DASH or RTP data on the communication side. The attribute information is the same as that described in Fig. 7A.

[0242] First, in step S501, application control information is acquired. Next, the operation following step S502 is performed, but the operations after step S502 (step S502, step S504 to step S506) are the same as the operations described in Fig. 7A (step S201, step S203 to step S205), so the description will be omitted. Only step S503, which is a different operation, will be described below.

[0243] In step S503, it is determined whether or not to receive data transmitted via communication based on the information in the transmission path identification descriptor, and it is also determined whether or not to receive an application transmitted via communication based on the location information of the application described in the application control information.

[0244] Fig. 13B is a flowchart showing a comparative example of the operation of the receiving side in the broadcast communication cooperation service of Variation 4 of Embodiment 1. Fig. 13B shows an operation example in which attribute information and access information for acquiring location information are stored in the broadcast program information, but the actual location information is not stored.

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

[0246] In step S603, it is determined whether or not to receive data transmitted via communication based on the information in the transmission path identification descriptor, and it is also determined whether or not to receive an application transmitted via communication based on the location information of the application described in the application control information.

[0247] In addition, the operation flow shown in Fig. 13A does not have a step of acquiring location information on the communication side, as compared with the operation flow shown in Fig. 13B. As a result, the operation on the receiving side shown in Fig. 13A makes it possible to quickly acquire the start of data reception of communication.

[0248] In addition, in the operation flow shown in Fig. 13A, processing equivalent to step S405, step S406, and step S407 described in Fig. 9 may be performed. That is, it is determined whether the broadcast content and the communication content are synchronously played back, and if synchronous playback is to be performed, synchronization information may be obtained from the transmission path identification descriptor, and the reference clocks for broadcasting and communication may be synchronized to perform synchronous playback.

[0249] Furthermore, at the time when it is determined in step S503 or step S603 that data transmitted by communication will be received, preparations for starting an application may be made.

[0250] For example, the time it takes for an application to be executed can be reduced by having the HTML5 browser launch when it determines that data transmitted via communication has been received.

[0251] Also, in step S603, for example, when it is determined that the location information of the communication side is to be transmitted by communication, an application may be immediately started to acquire the location information of the communication side. Furthermore, after acquiring the location information of the communication side, buffering of the communication content may be started. The start timing of buffering may be specified by a control command of the application control information, or pre-buffering time information may be described in the location information of the communication side, and the receiving device may analyze and perform pre-buffering.

[0252] In addition, an application specified by application control information may be acquired from broadcasting or communication as an application for acquiring location information on the communication side or an application for acquiring communication content, and executed. Also, an application for acquiring location information on the communication side or an application for acquiring communication content may be realized as a resident application. For example, a control command of the application control information may instruct control of execution of an HTML5 application or a resident application, acquisition of data, etc., or execution of an HTML5 application or a resident application, acquisition of data, etc. may be controlled at the discretion of the receiving device.

[0253] Also, if the location information describes information about the capabilities of the receiving device necessary to play the content, 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, if it is determined that the receiving device cannot play the content after acquiring the location information of the communication side in step S605, the process may proceed to step S607 and only data transmitted by broadcasting may be received.

[0254] In addition, the API commands may be used to control the storage of communication side location information and communication content information acquired by various methods in the memory of the receiving device, the acquisition of information from the memory, and the transfer of information between applications. An application can acquire part or all of the communication side location information by executing an API command. For example, location information acquired by a resident application can be set in the memory of the receiving device by an API command, and the information can be retrieved from the memory by an API command from an HTML5 application.

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

[0256] This makes it possible to obtain the transmission path over which content including audio and video is transmitted, and the dependencies between data transmitted over different transmission paths, at the start of content reception, thereby reducing delay times associated with determining the assets to be received and with starting to receive communication content.

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

[0258] This makes it possible to obtain the transmission path over which content including audio and video is transmitted, and the dependencies between data transmitted over different transmission paths, at the start of content reception, thereby reducing delay times associated with determining the assets to be received and with starting to receive communication content.

[0259] According to the present embodiment, the receiving device may analyze the management information of the content to determine the transmission path for receiving the content and the data to be received on each transmission path. When the data transmitted on both transmission paths is to be synchronously played back, auxiliary information required for clock synchronization between the data may be obtained, and the DTS and PTS in each data may be synchronized, decoded, and played back.

[0260] As a result, in a receiving device that receives only broadcast data, it is possible to reproduce broadcast data in the same manner as in conventional broadcast reception, and it is also possible to handle reproduction of communication data.

[0261] Furthermore, a mechanism can be provided for receiving devices to play back broadcast and communication data in synchronization.

[0262] Furthermore, as described above, according to this embodiment, it is possible to realize a content transmission method, receiving method, transmitting device, and receiving device that enable rapid access to content via communication when playing content that combines broadcasting and communication on the receiving side.

[0263] Here, for example, a transmission method in one aspect of the present embodiment is a content transmission method capable of transmitting content using broadcast waves and a communication path, and when transmitting content using both the broadcast waves and the communication path, includes an information transmission step of including information regarding the content to be transmitted via the communication path in application control information, which information is for synchronizing the content via the broadcast waves with the content via the communication path when received by a receiving side, and transmitting the information using at least the broadcast waves of the broadcast waves and the communication path.

[0264] As a result, when content is transmitted using broadcast waves and a communication path, information regarding the content transmitted via the communication path, which is information for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication path when received by the receiving side, is transmitted together with the application control information. Therefore, when the receiving side receives the application control information, the receiving side can quickly access the content transmitted via communication in accordance with this information, and synchronization between the contents can be achieved.

[0265] Also, for example, in the information transmitting 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 source from which the content was obtained or information indicating the source from which the location information was obtained.

[0266] Furthermore, a receiving method in one aspect of this embodiment includes a receiving step of receiving content transmitted using both a broadcast wave and a communication path, and when application control information for synchronizing the content transmitted via the broadcast wave and the content transmitted via the communication path, which information includes information regarding the content transmitted via the communication path, is received from at least the broadcast wave of the broadcast wave and the communication path, a playback step of performing a synchronization process and playing the content.

[0267] This makes it possible to obtain application control information transmitted over a transmission path that serves as an entry point, such as a broadcast wave, and if the application control information contains information regarding the content transmitted over the communication path and for synchronizing the content transmitted over the broadcast wave with the content transmitted over the communication path, then it is possible to perform a synchronization process.

[0268] Also, for example, in the receiving step, the application control information may be received prior to receiving the content, and if the application control information includes location information indicating the location from which the content is to be obtained, the content may be received by obtaining the content based on the location information.

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

[0270] In addition, the transmitting device in one aspect of this embodiment is a content transmitting device capable of transmitting content using broadcast waves and a communication path, and when transmitting content using both the broadcast waves and the communication path, is equipped with an information transmitting unit that includes information regarding the content to be transmitted via the communication path in application control information, which information is for synchronizing the content via the broadcast waves with the content via the communication path when received by the receiving side, and transmits the information using at least the broadcast waves of the broadcast waves and the communication path.

[0271] In addition, a receiving device in one aspect of this embodiment includes a receiving unit that receives content transmitted using both broadcast waves and a communication path, and a playback unit that, when application control information is received that includes information for synchronizing the content transmitted via the broadcast waves and the content transmitted via the communication path and information regarding the content transmitted via the communication path, performs a synchronization process and plays the content.

[0272] (Embodiment 2) Example 1 For example, in the third variant of the first embodiment, in Figures 6A to 7B and the like, a method of storing location information and the like in a case where broadcasting is performed using TS and communication is performed using DASH, RTP, or the like has been described, but this is not limited to this.

[0273] In this embodiment, a specific example of a method for storing location information will be described as Example 1.

[0274] Fig. 14 is a diagram showing an example of a data structure of service information in the broadcasting and 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 an 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 be equivalent to the transmission path identification descriptor.

[0275] In this embodiment, the descriptor is stored in the PMT or in section data different from the PMT.

[0276] The information indicated by this descriptor includes a transmission format indicating the type of actual data referenced 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 this embodiment, the location information indicates a reference destination of the entity data of the location information. Here, an example is shown in which the entity data of the location information is an MPD, and the MPD is indicated as the transmission format, and the synchronization information is indicated as the synchronization information between PCR and NTP.

[0278] Since MPD is location information used in DASH, DASH may be indicated as the transmission format, and the reference destination of MPD may be indicated as the location. In cases where the transmission format can be identified by the extension of the URL of the location information, the transmission format field does not need to be included. In addition, there are two ways to transmit MPD: in-broadcast and via a communication network. When transmitting in-broadcast, a private section of MPEG-2 TS is used.

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

[0280] [How to receive] Hereinafter, as a receiving method in this embodiment, an example of the operation of the receiving device in the case where a descriptor indicating location information is analyzed and broadcast and communication contents are synchronously played back will be described.

[0281] FIG. 15 is a flowchart illustrating an example of an operation on the receiving side in the broadcast communication cooperative service according to the first example of the second embodiment.

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

[0283] Next, in step S802, it is determined whether an MPD is present in the broadcast. If an MPD is present in the broadcast (an MPD is transmitted by the broadcast) (Yes in S802), the process proceeds to step S803, where the entity data of the MPD is obtained from a TS packet having a PID indicated by the location information. On the other hand, if an MPD is not present in the broadcast (No in S802), the MPD is obtained from a communication server based on a URL or the like indicated in the location information.

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

[0285] Next, in step S806, the broadcast content and the communication content are played back in synchronization based on the synchronization information included in the location information descriptor, or, if MPEG-2 TS timeline extension is used, based on the synchronization information obtained from the TS packet that stores the timeline extension information.

[0286] In addition, when using the timeline extension, the location information descriptor does not need to include synchronization information. In addition, when it is not necessary to synchronously play the DASH content and the broadcast content, the synchronization information does not need to be transmitted. In this case, it may be determined whether or not the synchronous playback of the two is necessary based on the synchronization information of the location information descriptor or the presence of synchronization information in the data for timeline extension. Whether or not the synchronous playback is necessary may be indicated separately.

[0287] Also, if synchronous playback is not required, in step S806, the start and end of playback of the DASH content can be determined based on a user instruction or a control command in the hybrid cast application, etc. In this case, it is assumed that whether or not to obtain data through communication has been determined in the previous stage of S801.

[0288] Although an example of acquiring an MPD and playing back DASH content has been described with reference to FIG. 15, the same applies to acquiring and playing back data in other formats such as RTP or TS.

[0289] In addition, in the timeline extension, an access unit that stores timeline extension information is defined, and both a descriptor indicating location information and a descriptor indicating synchronization information can be stored in the access unit.

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

[0291] In addition, the upper limit of the PMT section size is limited to 1021 bytes, and depending on the URL in the location information, this limit may be exceeded. Although it is possible to divide and store the PMT section, it is especially desirable to store the PMT in a single section.

[0292] Therefore, if the section size of the PMT exceeds 1021 bytes, the location information descriptor may be transmitted in a section different from the PMT. Note that if the location information indicates a PID, it can be contained within the upper limit of the PMT size and can be included in the PMT, so the section in which the location information is stored may be switched based on whether the location information is a PID or a URL.

[0293] Example 2 In the first embodiment, it has been described that location information can also be indicated in a Timeline and Extend Media Information stream (TEMI) access unit in timeline extension.

[0294] Specifically, the URL of the content on the communication side can be described using temi_location_descriptor. In temi_location_descriptor, the URL of multiple contents can be described, and there is no restriction on data size like the section size of PMT, so the description of URLs can be flexibly operated.

[0295] On the other hand, when the location information indicates the PID of a TS packet in a transport stream, the data size of the location information is small, and the delay time involved in obtaining the location information can be reduced by referencing the location information descriptor and obtaining the location information when analyzing the PMT. Therefore, it is desirable to be able to use both the location information descriptor and the temi_location_descriptor in the TEMI access unit as a storage location for the location information.

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

[0297] Fig. 16A is a diagram showing an example of the syntax of a location information descriptor in Example 2 of Embodiment 2. Fig. 16A shows an example of the syntax of a location information descriptor for storing location information in either a location information descriptor or a TEMI access unit.

[0298] In this embodiment, it is assumed that 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 meta information for playback control used in the service, such as MPD in DASH, playback control meta file in the VOD (Video On Demand) specification of the IPTV Forum, or TTS (Time-stamp TS) specified in the IPTV Forum, etc. It may indicate identification information of the stream itself, rather than meta information, such as TTS, MP4 file, or AV encoded data itself. It may also indicate MPT, PA message, MMT packet, asset, etc. in MMT.

[0300] For example, temporal scalability can be realized in a video coding method such as H.265. Assume that a base layer of 60 fps is transmitted in broadcasting, and encoded data of an enhancement layer for increasing the frame rate from 60 fps to 120 fps is transmitted in communication. In this case, only the URL of the encoded stream of the enhancement layer needs to be indicated as location information of the communication content. Information such as the resolution and encoding method of the encoded stream can be obtained in the broadcast data transmitting the base 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, location_type=0 indicates the PID of the TS in broadcasting. Note that the location information descriptor can also be used in formats other than TS, such as MPEG Media Transport (MMT) of MPEG. In formats other than TS, "location_type" does not need to 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. If a broadcast is composed of multiple transport streams, the identification number of the transport stream may also be stored.

[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, 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 temi_location_descriptor in the TEMI access unit.

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

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

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

[0307] In addition, in the syntax shown in Fig. 16A, the data_format field and the service_type of the 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 in Fig. 16A, the data_format of the location information descriptor may be referenced as the transmission format, 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 Example 2 of Embodiment 2. Fig. 16C shows an example of the syntax of the location information descriptor different from that shown in Fig. 16A and Fig. 16B.

[0310] The difference from Fig. 16A is that the condition branch of url_location is performed first. In other words, when url_location = 0 and the location information is in the location information descriptor, 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, and the location_type is indicated in the service_type field in the temi_location_descriptor in the TEMI access unit, and the PID of the broadcast TS 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 Example 2 of Embodiment 2. Fig. 16D shows an example of the syntax of the location information descriptor different from that shown in Figs. 16A to 16C.

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

[0313] The data and data structure of the syntax of the location information descriptor are not limited to the above example. For example, the location type and the format type may be combined and used in combination with other data. In addition, in cases where the transmission format can be identified by the extension in the URL of the location information, for example, the transmission format field does not need to be included. In addition, for example, if the location information descriptor does not exist, the location information may be indicated by temi_location_descriptor, and the url_location field may be omitted.

[0314] Example 3 Hereinafter, an example of location information different from that described in the second embodiment will be described.

[0315] (Other examples of location information) For example, when two or more types of timelines exist in the same program, each type of timeline may contain multiple TEMI streams.

[0316] In this case, multiple pieces of location information may be stored in the location information descriptor. When multiple pieces of location information are stored, loops are created in the location information descriptor as many as the number of TEMI streams, and location information corresponding to each TEMI stream is stored. In addition, as a method of indicating the correspondence between multiple location information loops and multiple TEMI streams in the location information descriptor, for example, the order of the location information loops and the order of the ES loops (PMT second loop) indicating the TEMI streams may be the same, and so on. In addition, when two or more types of timelines exist, 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] (Location information update) It is desirable to be able to handle updates to the content of location information such as meta-information.

[0318] For example, a reload flag may be added to the location information descriptor in the PMT, and when the content of the location information is to be updated, reload=1 may be set, and when reload=1, the receiving device may determine that the content of the location information has been updated and may reacquire the PID, URL, etc. stored in the location information. If location information such as the PID or URL has not been updated and only the data has been updated, only the data may be reacquired.

[0319] Furthermore, the location information itself, or information indicating whether the contents of data such as an MPD whose acquisition source is indicated by the location information have been updated, may be indicated independently.

[0320] Alternatively, the location information descriptor in the periodically transmitted PMT may be checked one by one. However, since this sequential checking process is heavy, section data for storing the location information descriptor and an event section for notifying updates may be generated separately and transmitted periodically.

[0321] The receiving device can determine whether the location information has been updated by checking the version number in the section, and when the location information is transmitted in a broadcast section, the version number of the location information section is updated to indicate that the meta information has been updated.

[0322] Also, after starting to acquire data on the communication side based on location information acquired from broadcasting, updated contents of the location information may be acquired through communication.

[0323] [How to receive] Next, as a receiving method in this embodiment, an example of the operation of the receiving device in the case where a descriptor indicating location information is analyzed and broadcast and communication contents are synchronously played back will be described.

[0324] FIG. 17 is a flowchart illustrating an example of an operation on the receiving side in the broadcast communication cooperative service according to the third example of the second embodiment.

[0325] Step S804 in Fig. 15 is changed to steps S906, S907, and S908 in Fig. 17. The other operations (steps S901 to S905) are similar to those in Fig. 15 (steps S801 to S803, S805, and S806), so a detailed description will be omitted.

[0326] In step S906, it is determined whether the URL of the acquisition source of the MPD, etc. is stored in the location information descriptor or in the TEMI access unit. If it is in the location information descriptor (Yes in S906), the process proceeds to step S907, where the location information descriptor is analyzed and the MPD is acquired from the communication server based on the URL indicated in the location information. On the other hand, if it is determined in step S906 that it is stored in the TEMI access unit (No in S906), the MPD is acquired from the communication server based on the URL indicated in the temi_location_descriptor in the TEMI access unit.

[0327] Although FIG. 17 shows an example in which MPD is indicated as the format information, broadcast content and communication content can be synchronously played back by performing the same flow operations even if other meta information is used.

[0328] Fig. 18 is a flowchart showing another example of the operation of the receiving side in the broadcast communication cooperation service of Example 3 of the second embodiment. Fig. 18 shows the operation when the format information is meta information other than MPD. More specifically, when the format information indicates a format of entity data such as a stream, rather than meta information such as an MPD, the operation shows the operation when the URL of the entity data of the stream is acquired instead of the URL of the meta information in step S907 or step S908 shown in Fig. 11.

[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, where the PID indicated in the location information is obtained. Since it is not assumed here that actual data such as a stream is included in the broadcast, if data exists in the broadcast, the format is determined to be metadata.

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

[0332] On the other hand, if data exists in the communication in step S1002 (No in S1002), the process proceeds to step S1008 to determine 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 the case, the URL is obtained 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, where the meta information is acquired from the communication stream based on the URL, and the process proceeds to step S1005, where the communication data to be acquired is determined.

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

[0335] Finally, in step S1007, the broadcast content and the communication content are synchronously played back based on the synchronization information included in the location information descriptor or the synchronization information indicated by the timeline extension of the MPEG-2 TS.

[0336] Example 4 So far, it has been explained that it is determined whether the broadcast content and the communication content are to be played back in synchronization, and if so, the broadcast content and the communication content are acquired and played back in synchronization, but this is not limited to the above.

[0337] In this embodiment, information indicating whether the reference clock information for audio and video transmitted by broadcasting is the same as the reference clock information for audio and video transmitted by communication is included in the service information (transmission identification descriptor, etc.), and the operation based on this information will be described.

[0338] [Information on whether the reference clock (timeline) between broadcasting and communication is synchronized] When content using broadcasting and communication is transmitted using MMT, DASH, RTP, hybrid cast, or the like, information indicating whether the reference clock information of audio or video transmitted by broadcasting is the same as the reference clock information of audio or video transmitted by communication may be stored in a transmission identification descriptor, program information, EPG, EIT, etc.

[0339] For example, if the contents transmitted by broadcasting and communication are operated based on a common reference clock (e.g., time stamps are added, etc.), information indicating that the contents are operated based on the common reference clock is stored. Also, if the contents transmitted by broadcasting and communication are operated based on different reference clocks, information indicating that the contents are operated based on different reference clocks is stored.

[0340] Also, only when it is indicated that different reference clock information is used for broadcasting and communication, information necessary for reference clock synchronization (e.g., timeline extension information, etc.) may be indicated. Also, it may indicate a storage location of information necessary for reference clock synchronization, a type of information necessary for reference clock synchronization, a method of reference clock synchronization, etc.

[0341] Here, in 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 type and method of reference clock synchronization may be indicated such that the reference clocks in broadcasting and communication can be synchronized by converting the NTP-based DTS and PTS for video and audio to the PCR-based DTS and PTS. Also, the type and method of reference clock synchronization may be indicated such that the DTS and PTS for broadcasting and communication are converted so as to be synchronized with a unique clock used in the receiving device.

[0343] It is also possible to analyze identification information indicating the type and method of information required for reference clock synchronization, and perform reference clock synchronization using a method based on the identification information.

[0344] In addition, 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. A descriptor may be indicated for each different reference clock, or may be indicated by one descriptor. Information indicating the correspondence between the reference clock and the program using the reference clock may be stored.

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

[0346] If the receiving device determines that different clock information is being used, it synchronizes the reference clock information for broadcasting and communication, and if it determines that common clock information is being used, it determines that clock synchronization is not necessary.

[0347] In addition, the receiving device may take into consideration not only the identification result of whether the reference clock information of the data is the same, stored in a transmission identification descriptor, etc., but also all of the following factors, such as user selection and user settings via a user interface, the intentions of the content provider, service operator, or broadcasting station, the specifications and specifications of the receiving device, and the intentions of the receiver manufacturer, and determine whether to actually synchronize the reference clocks of the broadcast content and the communication content.

[0348] Furthermore, when the receiving device determines to synchronize with the reference clock, the timing of actually synchronizing the clock may be after the determination, or may be started when information regarding synchronization is acquired without waiting for the determination, or may be synchronized to coincide with the time when acquisition of communication content is started (for example, a certain time before the start of content acquisition, or the same time as the start of acquisition, etc.).

[0349] In addition, if clock recovery of the reference clock (e.g., broadcast PCR) that is the reference source has not been completed (the clock has not yet been made available for use by smoothing out the effects of jitter, etc.), clock synchronization with the reference destination may be started once clock recovery of the reference clock information of the reference source has been completed.

[0350] If the EPG indicates whether the reference clocks for broadcasting and communication are synchronized, it is possible to determine whether the reference clocks need to be synchronized and to start synchronizing the reference clocks before the start of broadcasting, as in the case of pre-buffering of communication content. In this way, by synchronizing the reference clocks earlier, it is possible to provide services to viewers earlier.

[0351] In addition, the information indicating whether the reference clock is the same is not limited to the combination of broadcasting and communication, but can be applied when the data is transmitted via the same route, or when different reference clock information is used in data obtained from multiple routes such as broadcasting, communication, and storage formats.

[0352] Note that some or all of the functions and processes described in this embodiment may be implemented in hardware or software, or a portion of the functions and processes may be implemented in hardware or software.

[0353] For example, when implementing in software, the functions and processing described in this embodiment, functions to instruct the functions and processing, to notify the status of the receiving function by PUSH, and to obtain the functions by PULL may be packaged and provided as API functions.

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

[0355] Here, examples of API functions related to information on whether the reference clock is synchronized include the following 1) to 9).

[0356] 1) Obtains information on whether the reference clock information of broadcast content and communication content is the same. 2) Obtains information on whether reference clock synchronization is necessary. 3) Obtains the type of reference clock information and synchronization method for each. 4) Obtains information necessary for clock synchronization (timeline information, etc.). 5) Obtains the source from which to obtain the information necessary for clock synchronization. 6) Takes the clock information of the reference source as an argument and returns the clock information of the synchronized reference destination. For example, if synchronization is not achieved, returns a value indicating that synchronization is not achieved. 7) Instructs the start of synchronization of each other's reference clocks. 8) Obtains the status of whether reference clock synchronization is achieved. 9) Notifies that reference clock synchronization has been achieved.

[0357] [How to receive] Below, using the figures, we will explain an example of the operation of the receiving method in this embodiment, when attribute information and location information are stored in the broadcast program information and the receiving device determines whether to play the broadcast content and the communication content synchronously and operates accordingly.

[0358] Fig. 19 is a flowchart showing an example of the operation of the receiving side in the broadcasting and communication cooperation service of Example 4 of the second embodiment. The operation of the flowchart shown in Fig. 19 is applicable to a broadcasting and communication cooperation service using any combination of multiplexing methods such as MMT, DASH, and RTP. 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 a determination as to whether or not to synchronize the broadcast content and the communication content is omitted.

[0360] Moreover, steps S1101 and S1102 are the same operations as steps S401 and S402 in FIG. 9, and therefore the description thereof will be omitted.

[0361] Next, in step S1103, the receiving device determines whether to acquire the communication content. If it is determined to acquire the communication content (Yes in S1103), the process proceeds to step S1104, where data is received from both the broadcast and communication transmission paths, and in the following 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, where the reference clocks of the broadcast content and the communication content are synchronized, and in step S1107, both are played back in synchronization.

[0363] On the other hand, if it is determined in step S1105 that the reference clocks are the same (No in S1105), the reference clocks are not synchronized, and synchronous reproduction is performed using a common clock.

[0364] After step S1105, a process for determining whether or not reference clock synchronization is necessary may be performed. For example, depending on the type and method of clock synchronization, it may be determined whether the receiving device's capabilities support clock synchronization, whether or not clock synchronization is required as a receiver specification, or whether or not the user will perform clock synchronization. Then, depending on the results of step S1105 and the above determination, it may be determined overall whether or not reference clock synchronization is required for broadcasting and communication, and the process may proceed to step S1106 or step S1107.

[0365] Also, the synchronization of the reference clock in step S1106 may be performed prior to step S1104. This is because, for example, when the received data of the content is pre-buffered before playback is started, decoding and playback may be started after confirming that the data with a PTS of T1 in the broadcast content and the data with a PTS of T1 in the communication content (where the PTSs of both are assumed to be already synchronized) have been received. This is because, when determining whether the data to be played back in sync with each other are available, it is necessary that the reference clocks of both are already synchronized.

[0366] In addition, in step S1106, if clock synchronization cannot be performed because clock synchronization information cannot be acquired or because of the receiver specifications, it may not be possible to provide the user with a service that combines broadcasting and communication. In that case, it may be possible to determine whether or not to receive the data transmitted by communication in step S1103 by determining whether synchronization is essential or whether playback without synchronization is possible.

[0367] In addition, in step S1103, in addition to the information that can be identified by the transmission path identification descriptor, the decision as to whether or not to actually receive the data transmitted by communication may be made by taking into consideration all of the following: user's choices and settings, the intentions of the content provider, service operator, or broadcasting station, the specifications and specifications of the receiving device, and the intentions of the manufacturer.

[0368] [Receiving device] Next, a description will be given of an example of the configuration of a receiving device that realizes the operation shown in Fig. 19. Fig. 20 is a block diagram showing an example of the configuration of a receiving device according to Example 4 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 use determination unit 1103, a Loc information acquisition unit 1104, a broadcast receiving unit 1105, a communication receiving unit 1106, a reference clock determination unit 1107, and a reproduction unit 1108.

[0370] The identification information acquisition unit 1101 to the communication reception unit 1106 are similar to the identification information acquisition unit 301 to the communication reception unit 306 described with reference to FIG. 8, and therefore a description thereof will be omitted.

[0371] The reference clock determination unit 1107 has a function of performing the process of step S1105 shown in Fig. 19. Furthermore, the reference clock determination unit 1107 may perform a process of determining whether or not the reference clocks are different, and then, whether or not synchronization of the reference clocks is required as described above.

[0372] If the reference clocks are different, the reproduction unit 1108 synchronizes the reference clocks based on the method determined by the result of the determination in the reference clock determination unit 1107, and then decodes and reproduces the broadcast content or communication content.

[0373] The functions, configuration of the receiving device, and receiving method described in this modified example are merely examples, and are not limited to these, but may be anything that can achieve similar functions and effects.

[0374] [Effects of the second embodiment] As described above, according to this embodiment, identification information indicating whether content including audio and video is transmitted by using communication in addition to broadcasting, and information indicating the dependency between data transmitted on both transmission paths when broadcasting and communication are used in combination, may be generated and transmitted as content management information. Here, for example, the information indicating the dependency between data may include whether data transmitted on both transmission paths are synchronously reproduced. Furthermore, the information indicating the dependency between data may include whether clock information of data transmitted on both transmission paths is the same.

[0375] This makes it possible to obtain the transmission path over which content including audio and video is transmitted, and the dependencies between data transmitted over different transmission paths, at the start of content reception, thereby reducing delay times associated with determining the assets to be received and with starting to receive communication content.

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

[0377] This makes it possible to obtain the transmission path over which content including audio and video is transmitted, and the dependencies between data transmitted over different transmission paths, at the start of content reception, thereby reducing delay times associated with determining the assets to be received and with starting to receive communication content.

[0378] Also, according to this embodiment, the receiving device may analyze the management information of the content to determine the transmission path for receiving the content 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 required for clock synchronization between the data may be obtained, and the DTS and PTS in each data may be synchronized, decoded, and played. When the data transmitted on both transmission paths is to be played synchronously, auxiliary information required for clock synchronization between the data may be obtained, and the DTS and PTS in each data may be synchronized, decoded, and played.

[0379] As a result, in a receiving device that receives only broadcast data, it is possible to reproduce broadcast data in the same manner as in conventional broadcast reception, and it is also possible to handle reproduction of communication data.

[0380] Furthermore, a mechanism can be provided for receiving devices to play back broadcast and communication data in synchronization.

[0381] Furthermore, even if the clocks of data transmitted over a plurality of transmission paths are not synchronized, the clocks can be synchronized by acquiring auxiliary information required for clock synchronization, and data can be reproduced in a synchronized manner.

[0382] As described above, according to this embodiment, it is possible to realize a content transmission method, receiving method, transmitting device, and receiving device that enable rapid access to content via communication when playing content that combines broadcasting and communication on the receiving side.

[0383] Here, for example, a transmission method in one aspect of this embodiment is a content transmission method capable of transmitting content using broadcast waves and a communication path, and when transmitting content using both the broadcast waves and the communication path, includes an information transmission step of including information regarding the content to be transmitted via the communication path in application control information, which information is for synchronizing the content via the broadcast waves with the content via the communication path when received by a receiving side, and transmitting the information using at least the broadcast waves of the broadcast waves and the communication path.

[0384] As a result, when content is transmitted using broadcast waves and a communication path, information regarding the content transmitted via the communication path, which is information for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication path when received by the receiving side, is transmitted together with the application control information. Therefore, when the receiving side receives the application control information, the receiving side can quickly access the content transmitted via communication, and the contents can be synchronized.

[0385] Also, for example, in the information transmitting 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 source from which the content was obtained or information indicating the source from which the location information was obtained.

[0386] Also, for example, in the information transmitting step, difference information between a reference clock of the content by the broadcast wave and a reference clock of the content by the communication path may be included in the application control information and transmitted.

[0387] Also, for example, in the information transmission step, the application control information may be transmitted, thereby allowing the receiving side to achieve synchronization by synchronizing a reference clock of content via the communication path with a reference clock of content via the broadcast wave based on the difference information.

[0388] Furthermore, a receiving method in one aspect of this embodiment includes a receiving step of receiving content transmitted using both a broadcast wave and a communication path, and when application control information for synchronizing the content transmitted via the broadcast wave and the content transmitted via the communication path, which information includes information regarding the content transmitted via the communication path, is received from at least the broadcast wave of the broadcast wave and the communication path, a playback step of performing a synchronization process and playing the content.

[0389] This makes it possible to obtain application control information transmitted over a transmission path that serves as an entry point, such as a broadcast wave, and if the application control information contains information regarding the content transmitted over the communication path and for synchronizing the content transmitted over the broadcast wave with the content transmitted over the communication path, then it is possible to perform a synchronization process.

[0390] Here, for example, in the receiving step, the application control information may be received prior to receiving the content, and if the application control information includes location information indicating the location from which the content is to be obtained, the content may be received by obtaining the content based on the location information.

[0391] Also, for example, in the receiving step, the application control information is received prior to receiving the content, and if the application control information includes information indicating the source of location information indicating the source of the content, the location information may be obtained based on the information indicating the source of the location information, and the content may be received by obtaining the content from the obtained location information.

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

[0393] Although the transmission method and the reception method according to one or more aspects of the present invention have been described based on the embodiments, the present invention is not limited to these embodiments. As long as they do not deviate from the spirit of the present invention, various modifications conceived by those skilled in the art to the present embodiments and forms constructed by combining components of 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 implemented by dedicated hardware, or may be implemented by executing a software program suitable for each component. Each component may be implemented by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.

[0395] Furthermore, for example, the attribute information may include information indicating whether the clock information of the audio or video transmitted by broadcasting is the same as the clock information of the audio or video transmitted by communication.

[0396] In addition, in synchronizing the reference clock in S406, if the attribute information includes information indicating whether the reference clock information of multiple components is the same, and the receiving side can obtain that the reference clock information is different based on the attribute information, the reference clocks in broadcasting and communication may be synchronized using the above method.

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

[0398] In addition, although the attribute information may include a method for synchronizing clock information of streams transmitted through different transmission paths such as broadcasting and communication, this is not limiting. The attribute information may include a method for synchronizing information indicating whether clock information of streams transmitted through different transmission paths such as broadcasting and communication is synchronized with each other, or a method for synchronizing the information. [Industrial Applicability]

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

[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 Department 103 Judgment section 105, 306, 406, 1106 Communication receiver 302, 402, 1102 Decision Section 303, 403, 1103 Communication use determination unit 304, 404, 1104 Loc information acquisition section 407 Synchronization Judgment Unit 408, 1108 Reproduction Department 1107 Reference clock judgment unit

Claims

[Claim 1] A content transmission device capable of transmitting content using broadcast waves and a communication path, an information transmitting unit that, when transmitting content using each of a broadcast wave and a communication path, includes in control information information indicating that there is the content to be transmitted via the communication path, and information for reproducing the content via the broadcast wave and the content via the communication path, and information related to the content to be transmitted via the communication path, and transmits the information using at least the broadcast wave of the broadcast wave and the communication path; The information transmission unit transmits a base layer of the content using the broadcast wave and an enhancement layer of the content using the communication path, In the transmission via the communication path, information indicating which of the assets of the base layer corresponds to which of the assets of the enhancement layer is transmitted; In the transmission by the broadcast wave, information indicating a type of control information of the content to be transmitted by the communication path is transmitted; The information transmitting unit transmits location information indicating a source of the content or information indicating a source of the location information. Transmitting device.

Images