Transmission method, and transmission device

Abstract

To provide a transmission method of a content capable of regenerating a content that combines broadcasting and communication on a receiving side, even if timing of receiving the content through the communication is delayed.SOLUTION: The transmission method includes: a generation step of generating a content in a format conforming to MMT; a content transmitting step of transmitting the content in the format generated in the generation step; and an information transmitting step of, when transmitting the content using both a broadcast wave and a communication channel, transmitting information indicating that there is a content to be transmitted via the communication channel, information indicating the format of meta information for playback control of the content to be transmitted via the communication path, and auxiliary information including location information indicating an acquisition destination of the content to be transmitted via the communication path by using the broadcast wave. In the generation step, auxiliary information is generated including the same in message information which is information about the acquisition of the content.SELECTED DRAWING: Figure 2

Description

[Technical Field]

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

[0002] Conventionally, the main transmission path for distributing content has been broadcast waves, and an example of a media transport method 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 channels such as the Internet. In other words, content can now be distributed using not only broadcast waves but also communication channels, and the transmission channels 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 content distribution using both broadcasting and communication (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 broadcast. [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) related to content reception and the like in order to distribute content using a combination of broadcasting and communications and receive distributed content, and then starting to receive content, no consideration has been given to quick access to content via communications, which leads to issues such as delays in the timing at which content reception via communications begins.

[0007] SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide a content transmission method that allows the receiving side to play back content that combines broadcasting and communication even if the timing at which the content starts to be received via communication is delayed. [Means for solving the problem]

[0008] In order to solve the above problem, a transmission method according to one embodiment of the present invention is a content transmission method capable of transmitting content using broadcast waves and a communication path, and includes: a generation step of generating the content in a format conforming to MMT (MPEG Media Transport); a content transmission step of transmitting the content in the format generated in the generation step; and, when transmitting content using both broadcast waves and a communication path, an information transmission step of transmitting, using at least the broadcast waves, auxiliary information including information indicating the existence of the content to be transmitted via the communication path, information indicating the format of meta information for playback control of the content to be transmitted via the communication path, and location information indicating the source of acquisition of the content to be transmitted via the communication path, and in the generation step, the auxiliary information is generated by being included in message information which is information regarding the acquisition of the content.

[0009] These general or specific aspects may be realized by a data receiving method, an integrated circuit, a computer program, or a computer-readable recording medium such as a 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. [Effects of the Invention]

[0010] According to the present invention, it is possible to realize a content transmission method and the like that allows the receiving side to play back content that combines broadcasting and communication even if the timing at which the content starts to be received via communication is delayed. [Brief explanation of the drawings]

[0011] [Figure 1A] 3 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] 3 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 2] FIG. 2 is a diagram showing an example of an outline of a transmission path identification descriptor according to the first embodiment. [Figure 3A] FIG. 10 is a diagram illustrating another example of the data structure of service information in the broadcasting and communication cooperative service according to the first embodiment. [Figure 3B] FIG. 10 is a diagram illustrating another example of the data structure of service information in the broadcasting and communication cooperative service according to the first embodiment. [Figure 4A] 10 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to the first embodiment. [Figure 4B] 10 is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperative service according to the first embodiment. [Figure 5] FIG. 2 is a block diagram showing an example of the configuration of a receiving device according to the first embodiment. [Figure 6A] FIG. 10 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. [Figure 6B]FIG. 10 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. [Figure 7A] 10 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] 10 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. 10 is a block diagram showing an example of the configuration of a receiving device according to a first modification of the first embodiment. [Figure 9] 10 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. 10 is a block diagram showing an example of the configuration of a receiving device according to a second modification of the first embodiment. [Figure 11] FIG. 13 is a diagram showing an example of a data structure of service information in a broadcasting and communication cooperative service according to a fourth modification of the first embodiment. [Figure 12] 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 13A] FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in a fourth modification of the first embodiment. [Figure 13B] FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in a fourth modification of the first embodiment. [Figure 13C] FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in a fourth modification of the first embodiment. [Figure 13D] FIG. 13 is a diagram showing an example of the syntax of a location information descriptor in a fourth modification of the first embodiment. [Figure 14] 13 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to the sixth modification of the first embodiment. [Figure 15] 13 is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperative service according to the sixth modification of the first embodiment. [Figure 16] 13 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to the seventh modification of the first embodiment. [Figure 17] FIG. 13 is a block diagram showing an example of the configuration of a receiving device according to a seventh modification of the first embodiment. [Figure 18A] FIG. 11 is a diagram showing an example of description of default playback control information in the second embodiment. [Figure 18B] 18B is a diagram showing an example of video display according to the layout information of the default playback control information shown in FIG. 18A. FIG. [Figure 19A] FIG. 11 is a diagram showing an example of application control information in the second embodiment. [Figure 19B] 19B is a diagram showing an example of video display according to the layout information of the application control information shown in FIG. 19A. FIG. [Figure 20A] FIG. 11 is a diagram showing another example of description of default playback control information in the second embodiment. [Figure 20B] 20B is a diagram showing an example of video display according to the layout information of the default playback control information shown in FIG. 20A. FIG. [Figure 21A] FIG. 11 is a diagram showing an example of application control information in the second embodiment. [Figure 21B] 21B is a diagram showing an example of video display according to the layout information of the application control information shown in FIG. 21A. FIG. [Figure 22] 10 is a flowchart showing an example of the operation of the receiving side in the second embodiment. [Figure 23] FIG. 10 is a block diagram showing an example of the configuration of a receiving device according to a second embodiment. [Figure 24] FIG. 11 is a diagram showing an example of the data structure of service information in a broadcasting and communication cooperative service in the third embodiment. [Figure 25] FIG. 11 is a diagram showing an example of information included in a program configuration information descriptor according to the third embodiment. [Figure 26] FIG. 11 is a diagram showing an example of information included in a location information descriptor according to the third embodiment. [Figure 27] FIG. 11 is a diagram showing an example of a location type included in a location information descriptor according to the third embodiment. [Figure 28] FIG. 11 is a diagram showing an example of information included in an asset configuration information descriptor according to the third embodiment. [Figure 29] 11 is a flowchart showing a receiving method in the broadcast communication cooperative service of the third embodiment. [Figure 30] FIG. 11 is a block diagram showing an example of the configuration of a receiving device according to a third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] (Findings that form the basis of the present invention) Currently, services that deliver content by combining broadcasting and communications (broadcast-communications integrated services) are being considered. Among these, a promising method is one that uses broadcasting as the primary medium and accesses content acquired via communications (hereafter referred to as communications content) based on data acquired from broadcasting. When receiving content in a broadcast-communications integrated service, it is expected that the receiver will begin receiving the content via coded audio and video data or a data carousel in an MPEG-2 system after acquiring service information, similar to conventional services that deliver content only via broadcasting.

[0013] However, the service information that can be acquired through conventional services does not take into consideration the operation of quickly accessing communication content, the operation of selectively receiving only broadcast content, etc. Therefore, when providing a broadcasting and communication integrated service using conventional service information, there are issues such as an increase in the amount of processing related to analyzing the service information and a delay in the timing of starting to acquire communication content.

[0014] 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 channel, and when transmitting content using both broadcast waves and a communication channel, includes an information transmission step of transmitting, using at least the broadcast waves, auxiliary information for synchronizing the content via the broadcast waves with the content via the communication channel, the auxiliary information causing the synchronization when received by the receiving side.

[0015] According to this aspect, it is possible to realize a content transmission method that enables a receiving side to play back content that combines broadcasting and communication even if the timing at which the content reception via communication starts is delayed. More specifically, when content is transmitted using broadcast waves and a communication path, auxiliary information for synchronizing the content transmitted using the broadcast waves and the communication path is transmitted, so that when the receiving side receives the auxiliary information, the receiving side can synchronize the content.

[0016] Here, for example, in the information transmission step, the auxiliary information may be transmitted prior to transmitting the content, and the auxiliary 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.

[0017] Furthermore, for example, in the auxiliary information transmitting step, the auxiliary information may further include differential information between a reference clock of the content via the broadcast wave and a reference clock of the content via the communication path, and the differential information may be transmitted.

[0018] Also, for example, in the auxiliary information transmission step, if the reference clock of the content is different by transmitting the auxiliary information, the reference clock of the content via the communication path may be synchronized with the reference clock of the content via the broadcast wave based on the difference information, thereby allowing the receiving side to achieve the synchronization.

[0019] Also, for example, the transmission method may include a generation step of generating the content in a format conforming to MMT (MPEG Media Transport), and a content transmission step of transmitting the content in the format generated in the generation step.

[0020] Furthermore, for example, in the generating step, the auxiliary information may be generated by being included in message information that is information relating to acquisition of the content.

[0021] In addition, in order to solve the above problem, a receiving method according to one aspect of the present invention includes a receiving step of receiving content transmitted using both broadcast waves and a communication channel, and a playback step of, when auxiliary information for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication channel is received, performing the synchronization process and playing back the content.

[0022] Here, for example, in the receiving step, the auxiliary information is received prior to receiving the content, and if the auxiliary information includes location information indicating where 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 auxiliary information is received prior to receiving the content, and if the auxiliary 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 reproduction step, the auxiliary information including difference information between the reference clock of the content via the broadcast wave and the reference clock of the content via the communication path is received in the reception step, and if the reference clock of the content via the broadcast wave and the reference clock of the content via the communication path are different, a process of synchronizing the content by synchronizing the reference clock of the content via the communication path with the reference clock of the content via the broadcast wave based on the difference information is performed, and the content is reproduced.

[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 broadcast waves and a communication path, is provided with an information transmitting unit that transmits auxiliary information using at least the broadcast waves, which is auxiliary information for synchronizing the content via the broadcast waves with the content via the communication path, and which causes the synchronization when received by the receiving side.

[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 channel, and a playback unit that, when auxiliary information for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication channel is received, performs the synchronization process and plays back the content.

[0027] These general or specific aspects may be realized by a transmission method, a transmission 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 reception method, an integrated circuit, a computer program, or a recording medium.

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

[0029] It should be noted that the embodiments described below each illustrate a specific example of the present invention. The numerical values, shapes, materials, components, component placement and connection configurations, steps, and step order 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 the independent claims that represent the highest concept are described as optional components.

[0030] (Embodiment 1) In this embodiment, a transmission method for transmitting and receiving content in a broadcasting and communication cooperation 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 MPEG-2 TS (Transport Stream) sections, which include PAT (Program Association Table), PMT (Program Map Table), NIT (Network Information Table), CAT (Conditional Access Table), or EIT (Event Information Table) defined by ARIB (Association of Radio Industries and Businesses).

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

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

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

[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 also indicate whether the audio and video data of the main program will be transmitted by (1) broadcasting only or (2) broadcasting and communication. This information allows audio, video, still images, or metadata separate from the main program, such as HTML files, to be acquired from the communication network even if the main program is transmitted by broadcasting only.

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

[0040] Here, for example, when scalability (temporal resolution (e.g., 60 fps → 120 fps), spatial resolution (e.g., 4k → 8k), bit depth (e.g., 8 bit → 10 bit)) is to be realized, 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 increased 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, as shown in FIG. 2, for example. Here, FIG. 2 is a diagram showing an example of an overview 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] The attribute information may also be used to group broadcast assets and communication assets, and to indicate a list of assets included in each group. If there are assets that are transmitted via both broadcast 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] 4) 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 may be included as attribute information.

[0046] 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 also be written in a format different from that of the descriptor.

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

[0048] 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.

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

[0050] That is, as shown in Figures 3A and 3B, the location information for each asset may be stored in separate MPTs for assets transmitted via broadcasting and communications. In this case, the attribute information for the package can be stored in the MPT sent on the transmission path that is the entry point for the service. For example, if broadcasting is the entry point, the package attribute information is stored in the MPT sent via broadcasting. These MPTs can be identified by table_id.

[0051] In the MMT standard, the value of the 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.

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

[0053] Furthermore, the location information of broadcasting and communication assets may be stored in a single MPT. In this case, the location information of each asset may be stored consecutively to facilitate easy identification. For example, if there are N1 broadcasting assets and N2 communication assets, the information of the N1 broadcasting assets is first described consecutively, followed by the information of the N2 communication assets. Note that the transmission path identification descriptor may indicate that N1 assets are transmitted via broadcasting and N2 assets are transmitted via communication.

[0054] In this way, the transmitting side transmits the service information including the transmission path identification descriptor as 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 the dependency relationship between broadcast data and communication data, based on the package attribute information described in the transmission path identification descriptor, without analyzing the information for each asset.

[0055] In particular, when receiving communication data, there is an advantage in that the delay time associated with starting the reception process can be reduced.

[0056] [Transmitting device] For example, the transmitting device of this embodiment is a content transmitting device that can transmit 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.

[0057] 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.

[0058] Furthermore, 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.

[0059] Note that when the receiving side receives content from the broadcasting and communication cooperation service, it is not necessary to receive data sent through both transmission paths. For example, it may receive and play only the broadcast data. 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 through 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 or communication, through each transmission path (for example, Figure 2). Note that the following description will be given assuming that broadcasting is the entry point.

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

[0061] (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.

[0062] 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 the communication transmission path. 3) Information about buffering, such as buffering time and amount, from when asset data is received until decoding begins

[0063] In broadcasting, FEC and QoS are important, especially for mobile broadcasting (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 during broadcasting.

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

[0065] 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.

[0066] [Receiving method] 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.

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

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

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

[0070] 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, the ID number in the packet header (corresponding to packet_id in an MMT packet) is first referenced to obtain the MMT packet of the PA message.

[0071] 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).

[0072] Here, an example of a method for determining assets will be described.

[0073] 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 via both broadcast and communication.

[0074] 2) When 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, assume that temporal scalability of 60 fps can be achieved 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 receive only the broadcast data, but if it can decode and display up to 120 fps, it will receive both the broadcast and communication data.

[0075] 3) A receivable asset is determined from multiple 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 if the reception state is poor due to congestion in the communication network or the like and there are no assets that can be stably received, it may be determined not to receive data from the communication side.

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

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

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

[0079] Next, in step S103, it is decided (determined) whether or not to receive the asset transmitted by communication, and if it is decided (determined) to receive it (Yes in S103), proceed to S104, and if it is decided (determined) not to receive it (No in S103), proceed to S105.

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

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

[0082] 4A, in FIG. 4B, when service information specific to a communication is transmitted in the communication, a step of receiving the service information (step S106) is added. The rest is the same as that explained in FIG. 4A, so the explanation will be omitted.

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

[0084] Furthermore, if the receiving device does not support the broadcast and communication integrated service, it may receive only broadcast assets. In this case, if there is an asset transmitted via both broadcast and communication, the asset will not be received.

[0085] [Receiver] Fig. 5 is a block diagram showing an example of the configuration of a receiving device according to Embodiment 1. Fig. 5 shows an example of the configuration of a receiving device that realizes the receiving method described in Fig. 4A.

[0086] The receiving device 100 shown in FIG. 5 includes an identification information acquiring unit 101, an asset determining unit 102, a determining unit 103, a broadcast receiving unit 104, and a communication receiving unit 105.

[0087] The identification information acquisition unit 101 has a function to realize step S101 shown in Fig. 4A. Specifically, the identification information acquisition unit 101 acquires service information transmitted on a transmission path that is an entry point, and acquires a transmission path identification descriptor (auxiliary information) included therein. Then, the identification information acquisition unit 101 interprets the information of the transmission path identification descriptor.

[0088] The asset determination unit 102 has a function for implementing step S102 shown in FIG. 4A, and determines the asset to be received based on the playback capabilities of the terminal or whether a communication path is available.

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

[0090] 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 .

[0091] (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.

[0092] 6A and 6B are diagrams showing an example of the data structure of service information in a broadcasting and communication cooperative service according to Modification 1 of Embodiment 1. Fig. 6A shows an example in which information about data transmitted in communication is stored in a PMT. Fig. 6B shows an example of the data structure of a transmission path identification descriptor according to this modification.

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

[0094] 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 content data is transmitted using communication in addition, the location information of the data on the communication side is stored in the transmission path identification descriptor. More specifically, the attribute information includes flag information indicating whether communication is also used. This allows the transmitting side to select whether to include the location information of the data on the communication side depending on 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.

[0095] (Location information) Location information is information that indicates the source of data, and corresponds to a PID in the case of TS, a URL or URI in the case of communication, etc.

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

[0097] Furthermore, the location information is not limited to storing entity data of location information such as MPD or SDP, but may also store information indicating a source from which the entity data of the location information is to be acquired. Here, the information indicating a source from which the entity data of the location information is to be acquired is, for example, information indicating a URL for acquiring an MPD. However, when information indicating a source from which the entity data of the location information is to be acquired is stored in the location information, a delay occurs due to the need to separately acquire the entity data of the location information. 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.

[0098] Note that the DASH MPD is large in size because it contains various information related to the source of content. Therefore, instead of storing the MPD as is in the location information, it is also possible to store subset information that includes only the URL of the source of content and information related to the DTS and PTS of the segment.

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

[0100] 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 to confirm whether the version number has been updated, information such as the transmission path identification descriptor in the periodically transmitted PMT may be checked sequentially. However, since this sequential check process is heavy, section data for storing location information, etc. may be generated separately (called a transmission path identification section) and transmitted periodically.

[0101] The receiving device can determine whether the location information has been updated by checking the version number in the transmission path identification section. 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.

[0102] Furthermore, 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 through communication. At this time, since the source of the location information is required, the source of the location information may be stored together with the entity data of the location information in a broadcast transmission path identification descriptor or the like.

[0103] The receiving device can obtain updated information through communication by periodically accessing the source of the location information.

[0104] Furthermore, if a mechanism for exchanging messages exists between a DASH content distribution server and a receiving device, the server may issue a message to the receiving device indicating that the location information has been updated, and the receiving device may then reacquire the location information upon receiving the message.

[0105] Although the information about data transmitted in communication is stored in the PMT in the above description, this is not limitative. Attribute information and location information may be transmitted in a section different from the PMT.

[0106] Furthermore, the method of acquiring data on the communication side may be switched based on whether the data transmitted in communication is played back in synchronization with the audio and video in the broadcast.

[0107] For example, in the case of synchronous playback, the data on the communication side can be accessed from the broadcast program information 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 ARIB (Association of Radio Industries and Businesses) hybrid cast specifications. 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. Playback of the acquired data on the communication side begins when an event message transmitted by data broadcasting is received.

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

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

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

[0111] The transmission path identification descriptor may also indicate transport layer protocol information, such as whether the data on the communication side is transmitted by UDP (User Datagram Protocol) or TCP (Transmission Control Protocol), which enables the receiving device to open ports used in each protocol or determine whether the protocol being used is supported.

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

[0113] [Receiving method] Below, with reference to the drawings, we will explain an example of the operation of a receiving device as a receiving method in this modified example when broadcasting is transmitted using TS and communication is transmitted using DASH, RTP (Real-time Transport Protocol), etc.

[0114] 7A is a flowchart showing an example of the operation of the receiving side in the broadcast communication cooperative service according to Variation 1 of Embodiment 1. FIG. 7A shows an example of the operation of the receiving device when attribute information and location information are stored in broadcast program information.

[0115] The operation of each step (step S201 to step S205) is the same as in the flowchart of Fig. 4A, but the difference is that in Fig. 4A, the data on the broadcasting side and the communication side is unified as an asset of the MMT package, whereas in Fig. 7A, the broadcasting side is TS data and the communication side is DASH or RTP data. As other points are as explained in Fig. 4A, detailed explanation will be omitted.

[0116] Fig. 7B is a flowchart showing another example of the operation of the receiving side in the broadcast communication cooperative service according to 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.

[0117] Step S301 is similar to step S201, and therefore a description thereof will be omitted.

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

[0119] In step S304, location information is acquired in accordance with the acquisition source of the location information of the communication side data included in the broadcast program information.

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

[0121] (Attribute information) The attribute information is the same as that described in embodiment 1, but since embodiment 1 used MMT as an example, the following describes an example where TS is used for broadcasting and DASH or RTP is used for communication.

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

[0123] The information may also indicate whether the audio and video data will be transmitted using (1) broadcast only or (2) both broadcast and communication. This information allows the audio, video, still images, and metadata such as HTML files to be acquired from a communication network separate from the main content, even if the main content is transmitted using broadcast only.

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

[0125] Here, for example, when realizing scalability (temporal resolution (e.g., 60 fps → 120 fps), spatial resolution (e.g., 4k → 8k), bit depth (e.g., 8 bit → 10 bit)), the attribute information can indicate that broadcasting will use the base layer and communication will use the enhancement layer. The attribute information may indicate a use case in which the frame rate of broadcast data alone is 60 fps, but the frame rate can be increased 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.

[0126] The attribute information may also indicate information for identifying related coded streams. For example, the attribute information may indicate a PID of a TS packet storing basic layer data transmitted by broadcasting, a segment in DASH data transmitted by communication, or video data identification information such as a track ID in MP4.

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

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

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

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

[0131] 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 required 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 begin at time T2.

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

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

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

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

[0136] The identification information acquisition unit 301 has a function to realize step S301 shown in Fig. 7B. Specifically, the identification information acquisition unit 301 acquires service information transmitted on a transmission path that is 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.

[0137] 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.

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

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

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

[0141] [Receiving method] Fig. 9 is a flowchart showing an example of the operation of the receiving side in the broadcast communication cooperative service according to 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 to synchronously play back broadcast content and communication content, and plays them back.

[0142] 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.

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

[0144] 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.

[0145] 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).

[0146] Next, it is determined whether to acquire the communication content (step S403), and if it is determined to acquire the 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.

[0147] Next, it is determined whether or not the broadcast content and the communication content are to be played back in synchronization with each other (step S405).

[0148] If it is determined that synchronous playback is to be performed (Yes in S405), the reference clocks of the broadcast content and the communication content are synchronized in step S406, and both are played back in synchronization in step S407.

[0149] The synchronization of the reference clocks in S406 may be performed prior to S404. This is because, for example, when playback is started after pre-buffering received content data, 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 (assuming that the PTSs of both are already synchronized) have been received, and when determining whether the data to be played back in synchronization with each other are available, it is necessary that the reference clocks of both are synchronized.

[0150] 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 for 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. Furthermore, the DTS and PTS for broadcasting and communication may be converted so as to synchronize with a specific clock used in the receiving device.

[0151] In addition, if the attribute information contains 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.

[0152] 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 may not be stored in the broadcast program information.

[0153] In addition, in this modification, synchronous playback is described as occurring when attribute information and location information are stored in the broadcast program information, but this is not limited to this. If the program information includes a transmission path identification descriptor, the receiving device may perform synchronous playback of a stream whose location information is described in the transmission path identification descriptor and the broadcast stream. In this case, the transmission path identification descriptor does not need to include attribute information indicating whether the streams transmitted by broadcast and communication are to be played back synchronously with each other.

[0154] In other words, the receiving method in this variant may include a receiving step of receiving content transmitted using both broadcast waves and a communication channel, and a playback step of, when auxiliary information for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication channel is received, performing the synchronization process and playing back the content.

[0155] [Receiver] 10 is a block diagram showing an example of the configuration of a receiving device according to 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.

[0156] The receiving device 400 shown in Figure 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.

[0157] The identification information acquisition unit 401 to the communication reception unit 406 are the same as the identification information acquisition unit 301 to the communication reception unit 306 described in FIG. 8, and therefore a description thereof will be omitted.

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

[0159] 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 means.

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

[0161] [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 path, such as broadcast and broadcast, or communication and communication.

[0162] In addition, if package-based information such as a transmission path identification descriptor is not indicated, it may be possible 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, by interpreting the location information for each asset such as that shown in Figures 1A and 1B.

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

[0164] 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 source of the broadcast asset, and for an asset transmitted via communication, a URL is indicated as the source. Therefore, whether an asset is transmitted via communication may be determined depending on whether the source of the asset is a URL in the location information.

[0165] (MPT description variation) 1A and 1B, the information for each asset is defined as location information for each asset and an individual transmission path identification descriptor, but this is not limited to this. A separate field indicating the encoding method of the asset may be provided. The encoding method is essential information for decoding, and it is desirable to signal it using 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.

[0166] Furthermore, if the encoding method is capable of scalable encoding, it may also be indicated whether the asset is a base layer or an enhancement layer, along with the encoding method.

[0167] In addition, there may be cases where multiple scalable assets are included in the same MMT package, such as when there are two videos with temporal scalability. In such cases, 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 an enhancement layer asset. Furthermore, enhancement layer and base layer assets may be grouped, and a group ID may be assigned to each asset.

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

[0169] (Information about transmission paths) 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 EPG.

[0170] 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 indicating this may be displayed.

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

[0172] 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 before 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 data for a buffering time can be received at the program start time.

[0173] Moreover, the same operation may be performed in the case of, for example, scheduled recording of a program.

[0174] In broadcasting and the like, a user can select multiple programs at any time, and even if communication data for the next program on the channel currently being viewed is received in advance, if the viewed program is switched, there is no benefit to receiving the communication data in advance. Therefore, at any viewing time, the communication side data for all programs that can be viewed after the viewing time and whose data is transmitted using both broadcast and communication may be buffered in advance. If it is not possible to receive data for all programs, the user may select and receive programs within the receivable range.

[0175] Furthermore, information indicating whether the broadcast data and the communication data are to be played back synchronously may be included in the program information such as EPG, and if synchronous playback is to be performed, the communication data may be buffered in advance. If synchronous playback is not to be performed, reception of the communication data may begin after reception of the broadcast data has begun.

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

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

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

[0179] (format) Note that HTTP-based file formats are not limited to DASH, but can also be HTTP Live Streaming (HLS) or Microsoft Smooth Streaming (MSS), and these methods 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.

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

[0181] [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.

[0182] For example, when DASH is used on the communication side, attribute information of the entire content, such as whether broadcast content and communication content are played back in sync, 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.

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

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

[0185] In addition, both the overall attributes and the individual attributes 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.

[0186] (Attribute information) Furthermore, the attribute information may include information indicating whether or not the clock information of streams transmitted over different transmission paths, such as broadcasting and communication, is synchronized with one another, or a method for synchronizing the clock information. In this case, the receiving device may perform clock synchronization based on this information.

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

[0188] Method 1) The streams to be synchronized are based on a common clock, and there is no need to synchronize their clocks.

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

[0190] Method 3) Synchronization is performed 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.

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

[0192] (Variation 4) For example, in FIGS. 6A to 7B, a method for storing location information and the like in cases where TS is used for broadcasting and DASH or RTP is used for communication has been described.

[0193] In this modification, a specific example of a method for storing location information will be described.

[0194] Fig. 11 is a diagram showing an example of the data structure of service information in the broadcasting and communication cooperative service according to the fourth modification of the first embodiment. Fig. 11 shows an example of a descriptor (location information descriptor) indicating location information such as 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.

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

[0196] 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.

[0197] In this modification, 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 synchronization information between PCR and NTP is indicated as the synchronization information.

[0198] Since the MPD is location information used in DASH, it is possible to indicate DASH as the transmission format and the reference destination of the MPD as the location. In cases where the transmission format can be identified by, for example, an extension in the URL of the location information, the transmission format field does not need to be included. Furthermore, there are two ways in which the MPD can be transmitted: within a broadcast or via a communication network. When transmitted within a broadcast, a private section of an MPEG-2 TS is used, for example. Therefore, the location information of the MPD can indicate identification information of a TS packet that stores the MPD in a 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 communication network.

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

[0200] FIG. 12 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.

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

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

[0203] Next, in step S805, the 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.).

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

[0205] Note that when timeline extension is used, synchronization information does not need to be included in the location information descriptor. Furthermore, if synchronized playback of DASH content and broadcast content is not required, synchronization information does not need to be transmitted. In this case, whether synchronized playback of the two is required may be determined based on the synchronization information in the location information descriptor or whether synchronization information is present in the data for timeline extension. Whether synchronized playback is required may also be indicated separately.

[0206] If synchronized playback is not required, in step S806, the start and end of playback of the DASH content can be determined based on user instructions or control commands in the Hybridcast application, etc. In this case, it is assumed that whether or not to obtain data via communication has been determined in the previous stage of S801.

[0207] Although an example in which an MPD is acquired and DASH content is played back has been described with reference to FIG. 12, the same applies to cases in which data in other formats such as RTP or TS is acquired and played back.

[0208] In the timeline extension, an access unit for storing 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.

[0209] 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, it is not possible to indicate a PID as location information, so the field indicating the scheme type of location information may be extended to enable signaling of a PID.

[0210] In addition, the maximum section size of a PMT is limited to 1021 bytes, and depending on the URL in the location information, this limit may be exceeded. Although it is possible to store PMT sections in separate sections, it is particularly desirable to store the PMT in a single section.

[0211] 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 PMT size limit and can be included in the PMT, so the section that stores the location information may be switched depending on whether the location information is a PID or a URL.

[0212] (Variation 5) In the fourth modification, it has been described that location information can also be indicated in a TEMI (Timeline and Extend Media Information stream) access unit in timeline extension.

[0213] Specifically, the temi_location_descriptor can be used to describe the URL of the content on the communication side. The temi_location_descriptor can describe the URLs of multiple contents and does not have any data size restrictions like the section size of the PMT, allowing for flexible operation when describing URLs.

[0214] 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 associated with 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 store the location information in both the location information descriptor and the temi_location_descriptor in the TEMI access unit.

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

[0216] Fig. 13A is a diagram showing an example of the syntax of a location information descriptor in Variation 4 of Embodiment 1. Fig. 13A 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.

[0217] In this modification, 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. 13A will be described.

[0218] "data_format" is the same as the transmission format shown in Fig. 11. In other words, it indicates the format of meta information for playback control used in the service, such as the MPD in DASH, the playback control meta file in the IPTV Forum's VOD (Video On Demand) specifications, or the TTS (Time-stamp TS) specified by the IPTV Forum, etc. It may indicate identification information for the stream itself, rather than meta information, such as a TTS, MP4 file, or the AV encoded data itself. It may also indicate an MPT, PA message, MMT packet, asset, etc. in MMT.

[0219] For example, temporal scalability can be achieved in a video encoding format such as H.265. Assume that a base layer of 60 fps is transmitted via broadcasting, and encoded data of an enhancement layer for increasing the frame rate from 60 fps to 120 fps is transmitted via communication. In this case, the location information of the communication content only needs to indicate the URL of the encoded stream of the enhancement layer. Information such as the resolution and encoding format of the encoded stream can be obtained from the broadcast data transmitting the base layer.

[0220] "location_type" is used to identify 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.

[0221] "PID" indicates the PID of the TS packet. If the broadcast is made up of multiple transport streams, the transport stream identification number may also be stored.

[0222] "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 modification, when url_location=0, it is stored in the location information descriptor. When url_location is 1, the URL of the communication content is stored in the temi_location_descriptor in the TEMI access unit.

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

[0224] Figure 13B is a diagram showing an example of the syntax of a location information descriptor in Variation 4 of Embodiment 1. Figure 13B shows an example of the syntax of the location information descriptor different from that shown in Figure 13A. The difference from the syntax shown in Figure 13A is that when location information is stored in a TEMI access unit, the data_format field does not exist.

[0225] 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, data_format information is indicated in the service_type field.

[0226] 13A, the data_format field and the service_type of the temi_location_descriptor may both exist. In this case, both fields indicate the same information.

[0227] In the temi_location_descriptor, it is also possible to indicate only the URL of the communication content without signaling the service_type. Therefore, when using the syntax of Fig. 13A, 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.

[0228] Fig. 13C is a diagram showing an example of the syntax of a location information descriptor in Modification 4 of Embodiment 1. Fig. 13C shows an example of the syntax of the location information descriptor different from that shown in Fig. 13A and Fig. 13B.

[0229] The difference from Fig. 13A is that a conditional branch for url_location is performed first. In other words, when url_location = 0 and location information is in the location information descriptor, the PID of the broadcast TS or the communication URL is stored according to location_type. On the other hand, when url_location = 1, 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.

[0230] Fig. 13D is a diagram showing an example of the syntax of a location information descriptor in Modification 4 of Embodiment 1. Fig. 13D shows an example of the syntax of the location information descriptor different from the syntax of the location information descriptor shown in Figs. 13A to 13C.

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

[0232] The data and data structure of the location information descriptor syntax are not limited to the above example. For example, the location type and format type may be combined and used in combination with other data. Furthermore, 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 need not be included. Furthermore, for example, if a location information descriptor does not exist, the location information may be represented by temi_location_descriptor, and the url_location field may be omitted.

[0233] (Variation 6) Hereinafter, an example of location information different from that described in the fifth modification will be described.

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

[0235] 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 equal to the number of TEMI streams are created in the location information descriptor, and location information corresponding to each TEMI stream is stored. In addition, as a method of indicating the correspondence between multiple location information loops in the location information descriptor and multiple TEMI streams, for example, the correspondence may be indicated by matching the order of the location information loops with the order of the ES loops (PMT second loop) indicating the TEMI streams. 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).

[0236] (Location information update) It is desirable to be able to handle updates to the content of location information such as meta information.

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

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

[0239] Alternatively, the location information descriptors in the periodically transmitted PMT may be checked sequentially. However, since this sequential checking process is heavy, it is also possible to generate separate section data for storing the location information descriptors and event sections for notifying updates, and transmit these separately.

[0240] The receiving device can determine whether the location information has been updated by checking the version number in the section. Also, if 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.

[0241] Furthermore, 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 through communication.

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

[0243] FIG. 14 is a flowchart showing an example of an operation on the receiving side in the broadcast communication cooperative service according to the sixth modification of the first embodiment.

[0244] Step S804 in Fig. 12 is changed to steps S906, S907, and S908 in Fig. 14. The other operations (steps S901 to S905) are the same as those in Fig. 12 (steps S801 to S803, step S805, and step S806), so a detailed description will be omitted.

[0245] In step S906, it is determined whether the URL for obtaining the MPD or the like is stored in the location information descriptor or the TEMI access unit. If it is in the location information descriptor (Yes in S906), the process proceeds to step S907, where the location information descriptor is analyzed and the MPD is obtained 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 obtained from the communication server based on the URL indicated in temi_location_descriptor in the TEMI access unit.

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

[0247] Fig. 15 is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperative service according to Variation 6 of Embodiment 1. Fig. 15 shows the operation when the format information is meta information other than an MPD. More specifically, when the format information indicates the format of entity data such as a stream rather than meta information such as an MPD, the operation is shown 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. 14.

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

[0249] Next, it is determined whether the data indicated in the format exists in the broadcast (step S1002). If data exists in the broadcast (Yes in S1002), the process proceeds to step S1003, where the PID indicated in the location information is acquired. Since it is not assumed here that actual data such as streams will be included in the broadcast, if data exists in the broadcast, the format is determined to be metadata.

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

[0251] On the other hand, if data exists in the communication in step S1002 (No in S1002), the process proceeds to step S1008, where it is determined whether the URL of the communication data exists in the location information descriptor or in the temi_location_descriptor of the TEMI access unit. Then, the URL is acquired in step S1009 or step S1010, depending on the case.

[0252] 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.

[0253] 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.

[0254] 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.

[0255] (Variation 7) So far, we have explained that it is determined whether the broadcast content and the communication content are played back in synchronization, and if they are, the broadcast content and the communication content are acquired and played back in synchronization, but this is not limited to this.

[0256] In this variant, 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.

[0257] [Information on whether the reference clock (timeline) between broadcasting and communication is synchronized] When content that uses broadcasting and communication is transmitted using MMT, DASH, RTP, hybridcast, or the like, 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 may be stored in a transmission identification descriptor, program information, EPG, EIT, etc.

[0258] For example, if the content transmitted by broadcasting and communication operates based on a common reference clock (e.g., by adding a timestamp), information indicating that the content operates based on the common reference clock is stored. Also, if the content transmitted by broadcasting and communication operates based on different reference clocks, information indicating that the content operates based on different reference clocks is stored.

[0259] Also, only when it is indicated that different reference clock information is used for broadcasting and communication, information necessary for reference clock synchronization (for example, timeline extension information, etc.) may be indicated. Also, it may be possible to indicate the storage location of the information necessary for reference clock synchronization, the type of information necessary for reference clock synchronization, the method of reference clock synchronization, etc.

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

[0261] For example, if PCR (Program Clock Reference) is used in broadcasting and NTP (Network Time Protocol) is used in communications, the type and method of reference clock synchronization may be indicated as follows: the NTP-based DTS and PTS for video and audio can be converted to the PCR-based DTS and PTS for broadcasting and communications, thereby synchronizing the reference clocks for broadcasting and communications. Alternatively, the type and method of reference clock synchronization may be indicated as follows: the DTS and PTS for broadcasting and communications are converted so as to synchronize with a specific clock used in the receiving device.

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

[0263] Furthermore, if 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 a single descriptor may be used. Information indicating the correspondence between the reference clock and the program using that reference clock may also be stored.

[0264] 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 by the presence or absence of information necessary for clock synchronization (e.g., timeline extension information, etc.). If the information necessary for clock synchronization is present, it may be determined that the clock information is different. Alternatively, attribute information of the communication content indicated in a transmission identification descriptor, etc. (e.g., information about the format or type, or location information or an extension described in a URL) may be used to indicate that the clock information is different. In the case of hybridcast, it may be stored in an AIT controlled section or an application.

[0265] If the receiving device determines that different clock information is being used, it synchronizes the reference clock information for broadcasting and communication. If it determines that common clock information is being used, it determines that clock synchronization is unnecessary. For example, the receiving device may receive auxiliary information including difference information between the reference clock of the content via the broadcast wave and the reference clock of the content via the communication path, and if the reference clock of the content via the broadcast wave and the reference clock of the content via the communication path are different, it may synchronize the reference clock of the content via the communication path with the reference clock of the content via the broadcast wave based on the difference information.

[0266] In addition, the receiving device may take into consideration not only the identification result of whether the reference clock information of the data stored in the transmission identification descriptor, etc. is the same, but also all factors such as user selection and user settings via the 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.

[0267] Furthermore, when the receiving device determines to synchronize with the reference clock, the timing of the actual clock synchronization may start after the determination, or may start when information regarding synchronization is acquired without waiting for the determination, or may synchronize with the time when acquisition of the communication content starts (for example, a certain time before the start of content acquisition, or the same time as the start of acquisition).

[0268] 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.

[0269] If the EPG indicates whether the reference clocks for broadcasting and communications are synchronized, it may be possible to determine whether reference clock synchronization is necessary and start synchronization of the reference clocks before the start of broadcasting, as in the case of pre-buffering of communications content. In this way, by synchronizing the reference clocks earlier, services can be provided to viewers more quickly.

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

[0271] Note that some or all of the functions and processes described in this modification may be implemented in hardware or software, and some may be implemented in hardware or software.

[0272] For example, when implementing in software, functions such as instructing the functions and processing described in this variant, notifying the status of the receiving function by PUSH, and obtaining by PULL may be packaged and provided as API functions.

[0273] API functions can be executed from applications. When implemented as an application, it can be implemented as a resident application or an application such as HTML5. The above API can also be implemented as a means of passing data between applications and notifying status.

[0274] Here, the API functions related to information on whether the reference clock is synchronized include, for example, the following 1) to 9).

[0275] 1) Obtains information on whether the reference clock information for broadcast content and communication content is the same. 2) Obtains information on whether reference clock synchronization is required. 3) Obtains the type of reference clock information and synchronization method for each. 4) Obtains information required for clock synchronization (timeline information, etc.). 5) Obtains the source of information required 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.

[0276] [Receiving method] Below, using the figures, we will explain an example of the operation of the receiving method in this modified example, 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.

[0277] Fig. 16 is a flowchart showing an example of the operation of the receiving side in the broadcasting and communication cooperation service according to the seventh modification of the first embodiment. Note that the operation of the flowchart shown in Fig. 16 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 hybridcast.

[0278] In FIG. 16, it is assumed that the broadcast content and the communication content are synchronized, and the determination of whether or not to synchronize the broadcast content and the communication content is omitted.

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

[0280] Next, in step S1103, the receiving device determines whether to acquire the communication content. If it determines to acquire the communication content (Yes in S1103), it proceeds to step S1104, receives data from both the broadcast and communication transmission paths, and then in the following step S1105, determines whether the reference clocks of the broadcast content and the communication content are the same or different.

[0281] 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.

[0282] 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 playback is performed using a common clock.

[0283] After step S1105, a process for determining whether 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 capabilities of the receiving device support clock synchronization, whether clock synchronization is required as a receiver specification, or whether clock synchronization is required by the user. Then, based on the results of step S1105 and the above determination, it may be determined overall whether reference clock synchronization is required for broadcasting and communication, and the process may proceed to step S1106 or step S1107.

[0284] Furthermore, the synchronization of the reference clocks in step S1106 may be performed prior to step S1104. This is because, for example, when playback is started after pre-buffering received content data, 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 (assuming that the PTSs of both are already synchronized) have been received. This is because, when determining whether the data to be played back in synchronization with each other are available, it is necessary that the reference clocks of both are synchronized.

[0285] In addition, if clock synchronization is not possible in step S1106 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 such cases, it may be possible to determine whether to receive the data transmitted by communication in step S1103 by determining whether synchronization is required or whether playback is possible without synchronization.

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

[0287] [Receiver] Next, a description will be given of an example of the configuration of a receiving device that realizes the operation shown in Fig. 16. Fig. 17 is a block diagram showing an example of the configuration of a receiving device according to Variation 7 of the first embodiment.

[0288] The receiving device 1100 shown in Figure 17 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.

[0289] The identification information acquisition unit 1101 to the communication reception unit 1106 are the same as the identification information acquisition unit 301 to the communication reception unit 306 described in FIG. 8, and therefore a description thereof will be omitted.

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

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

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

[0293] [Effects of the First Embodiment] 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 the receiving side to play content that combines broadcasting and communication even if the start timing of content reception via communication is delayed.

[0294] Specifically, 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 broadcast waves and a communication path, includes an information transmission step of transmitting, using at least the broadcast waves, auxiliary information for synchronizing the content via the broadcast waves with the content via the communication path, the auxiliary information causing the synchronization when received by the receiving side.

[0295] Thus, when contents are transmitted using broadcast waves and a communication path, auxiliary information for synchronizing the contents transmitted using the broadcast waves and the communication path is transmitted, so that when the receiving side receives the auxiliary information, the receiving side can synchronize the contents.

[0296] Here, for example, in the information transmission step, the auxiliary information may be transmitted prior to transmitting the content, and the auxiliary 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.

[0297] Furthermore, for example, in the auxiliary information transmitting step, the auxiliary information may further include differential information between a reference clock of the content via the broadcast wave and a reference clock of the content via the communication path, and the differential information may be transmitted.

[0298] Also, for example, in the auxiliary information transmission step, if the reference clock of the content is different by transmitting the auxiliary information, the reference clock of the content via the communication path may be synchronized with the reference clock of the content via the broadcast wave based on the difference information, thereby allowing the receiving side to achieve the synchronization.

[0299] Also, for example, the transmission method may include a generation step of generating the content in a format conforming to MMT (MPEG Media Transport), and a content transmission step of transmitting the content in the format generated in the generation step.

[0300] Furthermore, for example, in the generating step, the auxiliary information may be generated by being included in message information that is information relating to acquisition of the content.

[0301] Furthermore, a receiving method in one aspect of this embodiment includes a receiving step of receiving content transmitted using both broadcast waves and a communication channel, and a playback step of, when auxiliary information for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication channel is received, performing the synchronization process and playing back the content.

[0302] This allows service information transmitted over a transmission path serving as an entry point, such as a broadcast wave, to be acquired, and if auxiliary information is included therein, processing for achieving synchronization can be performed.

[0303] Here, for example, in the receiving step, the auxiliary information is received prior to receiving the content, and if the auxiliary information includes location information indicating where the content is to be obtained, the content may be received by obtaining the content based on the location information.

[0304] Also, for example, in the receiving step, the auxiliary information is received prior to receiving the content, and if the auxiliary 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.

[0305] Also, for example, in the reproduction step, the auxiliary information including difference information between the reference clock of the content via the broadcast wave and the reference clock of the content via the communication path is received in the reception step, and if the reference clock of the content via the broadcast wave and the reference clock of the content via the communication path are different, a process of synchronizing the content by synchronizing the reference clock of the content via the communication path with the reference clock of the content via the broadcast wave based on the difference information is performed, and the content is reproduced.

[0306] Furthermore, 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 broadcast waves and a communication path, is provided with an information transmitting unit that transmits auxiliary information using at least the broadcast waves, which is auxiliary information for synchronizing the content via the broadcast waves with the content via the communication path, and which, when received by the receiving side, causes the synchronization.

[0307] 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 channel, and a playback unit that, when auxiliary information for synchronizing the content transmitted via the broadcast waves with the content transmitted via the communication channel is received, performs the synchronization process and plays back the content.

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

[0309] This allows the transmission path over which content including audio and video is transmitted, and the dependencies between data transmitted over different transmission paths, to be obtained at the start of content reception, thereby reducing delays in determining the assets to receive and in starting to receive communication content.

[0310] Furthermore, according to this embodiment, location information of data transmitted in communication may be included in content management information. Here, the location information of the data to be transmitted may be, for example, an MPD in MPEG-DASH. Furthermore, the content management information may store information indicating a source of location information, rather than actual data of location information such as an MPD.

[0311] This allows the transmission path over which content including audio and video is transmitted, and the dependencies between data transmitted over different transmission paths, to be obtained at the start of content reception, thereby reducing delays in determining the assets to receive and in starting to receive communication content.

[0312] Furthermore, 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, if 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 back. Furthermore, if the data transmitted on both transmission paths are to be played back 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 back.

[0313] 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, while also being able to handle reproduction of communication data.

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

[0315] 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.

[0316] (Embodiment 2) In the first embodiment, we have explained the transmission method for transmitting information indicating whether a stream transmitted by broadcasting and a stream transmitted by communication are subject to synchronous playback, or the dependency between the streams transmitted via both transmission paths, and the receiving method for receiving such information.

[0317] Here, in order to realize flexible content playback on a receiving device that involves user intervention, such as when a user selects what to play from available audio or video, or when switching from a single-view full-screen display to a multi-view display in a video, it is desirable to perform playback control in the application.

[0318] Most applications are based on the widely used HTML (Hyper Text Markup Language) browser. When an application uses HTML, playback control can be performed by interpreting the HTML. HTML also has the advantage of allowing for flexible coding of content selection and switching, layout changes, and so on.

[0319] For example, in hybridcast, as defined by the IPTV Forum, identification information indicating the presence of an application, such as ait_identifier_info(), is transmitted in data that is always referenced when starting to receive a broadcast program, such as the PMT descriptor in TS and the MPT descriptor in MMT. If this identification information is present, a hybridcast-compatible receiving device obtains application control information, such as AIT, from information equivalent to a section or data carousel in TS, or an MMT message or data carousel in MMT, or by downloading it via a communications network. Then, the device obtains applications, such as HTML files, based on the application control information.

[0320] Hereinafter, the application control information and the data of the application itself will be referred to as application-related data. Applications may be written in a description language other than HTML, such as XML.

[0321] [Default service information sending method] However, there are receivers that do not support the application, or even if the application is supported, there is a time lag from the start of channel selection in broadcasting or communication until the application is acquired and started.

[0322] Therefore, the default setting information for the stream to be played and the display layout may be transmitted not as application-related data but as data that is always acquired when tuning in, such as PMT or MPT, or data that can be acquired with less delay than the time it takes to start an application, such as other TS sections or MMT messages.In addition, information for advanced playback control may be transmitted as application data, such as HTML.

[0323] For example, information related to playback control of streams transmitted in broadcasting or communications includes (a) information about scalability between streams, (b) information about switching between streams such as multilingual audio or video with different bit rates, (c) information about simultaneous display such as information indicating multiple video streams that can be displayed simultaneously, and information about the layout when simultaneous display is performed, and the default values ​​of this information are called default playback control information.

[0324] A receiving device that does not support the application will perform playback based on default values, while a receiving device that supports the application will start playback based on default values ​​and, after the application is launched, switch playback operations based on user actions or application control commands.

[0325] The application may switch the playback operation only for information that can be switched by user operation. For example, simultaneous display is basically switchable by the user, but for temporal scalability, the receiver may automatically determine the playback operation by always using the enhancement layer if the enhancement layer stream is available. In this case, information about temporal scalability is transmitted only in the default playback control information.

[0326] In TS, information related to playback control is basically executed by the application, but information related to scalability may be transmitted in the default playback control information. In this case, only information for associating the base layer and enhancement layer streams may be transmitted in the default playback control information or by a descriptor specified in MPEG-2 TS, and the application may decide whether to decode the enhancement layer based on the application's control command or user operation.

[0327] Alternatively, the application may switch playback operations only for layout-related information. For example, temporal scalability and stream switching do not involve layout changes. Therefore, this information is transmitted only in the default playback control information. On the other hand, information about simultaneous display is expected to be switched by user operation, so playback operations can be performed by the application.

[0328] (Example of default playback control information) Next, an example of how to write playback control information when switching playback operations based on default playback control information using an application will be described. Here, it is assumed that the default playback control information is stored in a descriptor, and the application control information is written in HTML.

[0329] Fig. 18A is a diagram showing an example of description of default playback control information in embodiment 2, and Fig. 18B is a diagram showing an example of video display according to the layout information of the default playback control information shown in Fig. 18A. That is, in the default playback control information shown in Fig. 18A, the layout information indicates that the video with PID=100 is to be displayed in full screen as shown in Fig. 18B.

[0330] The layout information may only indicate full-screen display without indicating information for specifying the stream. In this case, if there are two or more video streams, by separately indicating information (application control information) for specifying the video to be played by default, the video to be played by default can be operated to be displayed in full-screen.

[0331] FIG. 19A is a diagram showing an example of application control information in the second embodiment, and FIG. 19B is a diagram showing an example of video display according to the layout information of the application control information shown in FIG. 19A.

[0332] That is, the application control information shown in Figure 19A indicates that two display areas, Area 1 and Area 2, are set using the Layout tag, and that the video with PID=100 is displayed in Area 1 and the video with PID=200 is displayed in Area 2, as shown in Figure 19B.

[0333] 19A, the receiving device will display the videos with PID=100 and PID=200 in areas 1 and 2, respectively. Note that the information identifying the video may be a URL or a packet ID of an MMT packet, in addition to the PID.

[0334] 19A and 19B, the default playback control information indicates two types of information: scalability and layout. The scalability indicates that the type of scalability is temporal scalability, that the video with PID=100 is the base layer, and that the video with PID=200 is the enhancement layer. The layout information indicates that the video with PID=100 is displayed in full screen.

[0335] If the frame rate of the base layer alone is 60 fps and increases to 120 fps by using the enhancement layer, then in the default state, only the video with PID=100 is decoded and video equivalent to 60 fps is played back in full screen display. Note that if the stream attribute information, such as the stream type of the MPEG-2 system, separately indicates that the transmitted stream corresponds to the scalability base layer or enhancement layer, this information does not need to be described in the default playback control information. Also, if it is separately specified that in the default state, only the base layer is decoded and played back, the layout information may only indicate full screen display.

[0336] Fig. 20A is a diagram showing another description example of default playback control information in embodiment 2, and Fig. 20B is a diagram showing an example of video display according to the layout information of the default playback control information shown in Fig. 20A. Fig. 21A is a diagram showing an example of application control information in embodiment 2, and Fig. 21B is a diagram showing an example of video display according to the layout information of the application control information shown in Fig. 21A.

[0337] In Fig. 21A, function A is defined by a Script tag. Function A is a function that instructs decoding and playback of the temporal scalability enhancement layer when a button on the screen is pressed, and indicates, as an argument, index numbers that identify the base layer and enhancement layer, etc. The Body tag describes that function A will be called when a specific button on the remote control is pressed, etc.

[0338] When the button is pressed, the receiving device that has received the HTML application in FIG. 21A decodes the enhancement layer stream with PID=200 and plays back video equivalent to 120 fps in full screen display.

[0339] The audio, video, and other streams to be played by default may be separately indicated using descriptors such as MPEG-2 system or MMT. For example, the streams to be played by default may be grouped and the group ID may be associated with the stream. Alternatively, a descriptor may be defined to indicate the streams to be played by default, and the descriptor may include a list of the PIDs of the streams to be played by default.

[0340] Note that default values ​​for the default playback control information may be defined in advance, and if the parameter values ​​are equal to the default values, the default playback control information may not be transmitted. For example, if full-screen display is the default layout, layout information may not be included in full-screen display. In this case, if scalability is not used and stream switching is not supported, the default playback control information may not be transmitted.

[0341] [Receiving method] In this embodiment, after acquiring the service information, the receiving side analyzes the default playback control information and the playback control information provided by the application and operates accordingly. The receiving method in this embodiment will be described below with reference to the drawings.

[0342] Fig. 22 is a flowchart showing an example of the operation of the receiving side in embodiment 2. Fig. 22 shows an example of the operation when analyzing default playback control information and playback control information provided by an application to determine functions such as scalability and stream switching, and a layout for presenting content.

[0343] First, in step S701, the receiving side selects the channel of the content to be viewed.

[0344] Next, in step S702, the receiving side analyzes the default playback control information, determines the stream to be decoded and played back, and determines the presentation method, such as the layout.

[0345] Here, the default playback control information may be transmitted by being included in data that is always acquired when selecting a channel, such as PMT or MPT, or may be transmitted separately from application-related data, such as in an MPEG-2 TS section or MMT message.

[0346] When the default playback control information is transmitted by a section or a message, a default value of the default playback control information may be set, and the device may operate based on the default value of the default playback control information until the section or message is received. Also, the stream to be decoded and played may be determined by referring to a descriptor indicating the stream, such as audio or video, to be played by default.

[0347] Next, in step S703, playback starts in accordance with the determined playback control parameters.

[0348] Next, in step S704, it is determined whether or not to receive the application, and if not (No in S704), the process ends. On the other hand, if it is to be received (Yes in S704), the process proceeds to step S705, where it is determined whether or not the application indicates a playback control function.

[0349] In step S705, if the playback control function is not indicated (No in S705), the process ends. If the playback control function is indicated (Yes in S705), the process proceeds to step S706, where the playback control information is updated according to the control command or user operation based on the playback control function indicated in the application.

[0350] Next, in step S707, playback is performed in accordance with the updated playback control parameters, and the process ends.

[0351] [Receiver] 23 is a block diagram showing an example of the configuration of a receiving device according to Embodiment 2. In FIG. 23, an example of the configuration of a receiving device that realizes the operations of the steps described in FIG.

[0352] 23 includes a receiving unit 701, a default information analyzing unit 702, an application information receiving unit 703, an application playback control information analyzing unit 704, and a playback control executing unit 705. These operations are the operations in the steps described in FIG. 22, and therefore will not be described here.

[0353] (Variation 1) The mechanism for updating the default playback control information by an application can be applied to all cases where content is transmitted by broadcasting alone, communication alone, or a combination of broadcasting and communication.

[0354] The concept of the method in this embodiment can also be applied to the MPEG-2 TS timeline extension (13818-3:2013 / AMD6) currently being standardized by MPEG. In the TS timeline extension, when content is transmitted using multiple multiplexed streams including at least one TS (called a basic TS), information is provided to synchronize the reference clocks for decoding and displaying content between the basic TS and other multiplexed streams.

[0355] Specifically, a timeline extension access unit is defined, which includes information associating a reference clock of a multiplexed stream different from the basic TS with the PCR of the basic TS. The timeline extension access unit is stored in a PES packet, which is then packetized and transmitted as a TS. In the timeline extension access unit, the information for timeline extension is expressed in the format of an MPEG-2 system descriptor. In this way, by transmitting the information for timeline extension in PES packet units, the reference clock can be quickly synchronized with the updated PCR even if a PCR discontinuity occurs.

[0356] However, PCR discontinuities do not generally occur within a single program, so if information for timeline extension is received at the start of program reception and the reference clocks are synchronized, resynchronization within the program is often not necessary.

[0357] Therefore, if it is guaranteed that no PCR discontinuities will occur within a program, a default value for the information for timeline extension may be stored in the PMT or the like, and the access unit for timeline extension may not be transmitted. For example, a descriptor similar to the descriptor that stores the information for timeline extension in the access unit for timeline extension may be stored in a section such as the PMT and used as the default value for the information for timeline extension. Also, the access unit for timeline extension and the default information stored in the PMT or the like may be used together.

[0358] Even when a timeline extension access unit is transmitted, if it is guaranteed that PCR discontinuity will not occur within the program or until a specific time, after clock synchronization is performed based on the information in the timeline extension access unit received immediately after tuning, re-synchronization may not be performed within the program or until a specific time.

[0359] Furthermore, when transmitting timeline extension information in sections, timeline extension information corresponding to the updated PCR may be transmitted for a certain period of time immediately after a PCR discontinuity occurs. If the version number of a section has been updated, the receiving device performs resynchronization based on the timeline extension information included in that section. Note that clock synchronization between streams cannot be guaranteed after a PCR discontinuity occurs but before resynchronization. In this case, a PCR discontinuity may be detected separately based on information indicating a PCR discontinuity, such as a TS discontinuity indicator. If a discontinuity is detected, the basic TS and the access units of the media to be synchronized may be decoded and displayed assuming a fixed frame rate until resynchronization.

[0360] [Effects of the second embodiment] As described above, according to this embodiment, when transmitting playback control information including layout information regarding video display in content including audio and video, or information indicating streams that can be switched during playback, a default value for the playback control information is stored in data that is always received when selecting a channel, and information for updating the default playback control operation is stored in information related to an application such as hybridcast and transmitted.

[0361] Here, playback is started according to the default playback control values, and if the receiving device is compatible with the application, the default playback control information is updated according to user actions, etc., based on the playback control functions transmitted as application data.

[0362] This reduces the delay time involved in determining parameters related to playback control, such as the layout of content.

[0363] (Embodiment 3) As described above, the MMT method allows video and audio to be multiplexed and packetized and transmitted over one or more transmission paths for broadcasting, communications, etc. A receiving device can receive packets transmitted over one or more transmission paths, extract desired packets from the received packets based on program information, and decode and present them.

[0364] In other words, the MMT method makes it possible to compose a program by receiving media (video, audio, subtitles, etc.) transmitted over multiple transmission paths, but it is not possible to compose a program using both data downloaded and stored via broadcasting or communication and data streamed from broadcasting or communication.

[0365] Therefore, in the third embodiment, we will explain the transmission and reception methods when a program is constructed using both data downloaded and stored via broadcasting or communication, and data streamed from broadcasting or communication.

[0366] In the following, the multiplexing format on the broadcast side in the broadcast collaborative service will be described using MMT (MPEG Media Transport) standardized by MPEG as an example.

[0367] In MMT, program information is transmitted using tables such as the MMT Package Table (MPT) or message information such as the Package Access (PA) message. The MPT describes the assets (single media such as video and audio) that make up the program and the location information for transmitting the assets. It is also possible to transmit a single asset over multiple transmission paths.

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

[0369] [Service Information] Fig. 24 is a diagram showing an example of a data structure of service information in the broadcast communication cooperative service according to the third embodiment. Fig. 25 is a diagram showing an example of information included in a program configuration information descriptor according to the third embodiment.

[0370] As shown in Figure 24, a program configuration information descriptor is included in the MPT, and this descriptor indicates information about the assets that make up the package. The information about the assets that make up the package can include the following:

[0371] (Asset information) 1) Information indicating whether the assets constituting a program include accumulated assets (hereinafter referred to as accumulated assets) may be included in the program configuration information descriptor as information about the assets. Accumulated assets here refer to assets stored in, for example, a HDD, internal memory, SSD, SD card, or other memory, or a Blu-ray disc.

[0372] 2) When the assets that make up a program include accumulative assets, information indicating the program configuration may be included in the program configuration information descriptor as information about the assets.

[0373] For example, the information may include information indicating the configuration of the program, such as whether the program is composed only of storage assets, whether the program is composed of storage assets and transmitted assets (hereinafter referred to as transmission assets), or whether the program is composed of assets including storage packets and transmission assets. Furthermore, for example, if the program is composed of scalably coded video, information may be included indicating that the transmission assets include a base layer and the storage assets include an enhancement layer. Furthermore, information may be included indicating whether decoding and playback of the storage assets is required or not for playback of the program. For example, if the content of the storage asset is additional information, playback may be deemed not to be required, and information indicating that playback of the storage asset is not required may be included.

[0374] Furthermore, for example, if the receiving device does not support storage or if no storage assets are stored, the program can be played back using assets obtained from broadcasting or communication, without using stored assets, based on information indicating that decoding and playback of stored assets is not required to play the program.

[0375] 3) Information about the accumulated asset may be included in the program configuration information descriptor as information about the asset.

[0376] For example, the information may include a) attribute information such as the storage format of the accumulative asset, the video / audio encoding method, the transmission method and multiplexing method used to transmit the accumulative asset, etc. In this case, the attribute information may be assigned to the accumulative asset in advance, and the attribute information may be included in, for example, the header of the accumulative asset or program information indicating the configuration of the accumulative asset. A receiving device may be able to play back an accumulative asset when the attribute information stored in the program information matches the attribute information of the accumulative asset. For example, the information may include b) information on the receiver's capabilities and functions required to play back a program including the accumulative asset. For example, the information may include c) information (scrambling method, viewing restrictions, conditional reception, copyright information) or a key for restricting playback or viewing of the program. In this case, the receiving device may compare the viewing restriction information stored in the program information with the accumulative asset to determine whether or not the accumulative asset can be played back or viewed. The receiving device may also store pre-encrypted assets and decrypt the accumulative asset based on the transmitted key.

[0377] 4) When the assets that make up a program are composed of transmission assets and storage assets, time information for synchronizing and playing back the transmission assets and storage assets may be included in the program configuration information descriptor as information about the assets.

[0378] This time information may indicate, for example, an offset amount of the reference time information of the transmission asset relative to a reference time that is the basis for the timestamp assigned to the accumulative asset. Furthermore, if the timestamp assigned to the accumulative asset is assigned based on a PCR (Program Clock Reference) or an NTP (Network Time Protocol), the time information may indicate a relative time relative to the transmitted reference time (PCR or NTP). Furthermore, if the accumulative asset is stored in a format with a random access table, the time information may be a time information table of the transmission asset relative to the random access point of the accumulative asset.

[0379] (Location information) The MPT describes the location information of each asset. For example, if one asset exists in multiple locations, the MPT describes multiple location information.

[0380] Fig. 26 is a diagram showing an example of information included in the location information descriptor according to the third embodiment. Fig. 27 is a diagram showing an example of location types included in the location information descriptor according to the third embodiment.

[0381] As shown in FIG. 26, the location information descriptor describes, as location information, a location type and an identifier that identifies an asset according to the location type.

[0382] The location type indicates the type of location information. For example, in the example shown in Fig. 26, the value of the location type is 0xA0 (Value = 0xA0), so it can be seen from Fig. 27 that it is stored locally. When the location type indicates that it is stored locally, a local ID that uniquely identifies the stored data is written in the location information.

[0383] Here, the local ID may be, for example, the asset ID of a stored asset or a packet ID. It may also be a 32-bit transport file identifier specified in ARIB STD-B45, or a newly specified one. A local ID may be generated by combining various IDs, such as a network ID or a stream ID, according to a predetermined naming convention. A local ID may be assigned in advance by a broadcasting station, a transmitting station, a content provider, or the like, or may be modified or assigned by the receiver with additional information. The receiver may assign its own unique ID, and a table showing the correspondence with the ID assigned by the transmitter may be prepared to identify the data.

[0384] In the above example, the location type is used to indicate that the asset is stored locally, and a separate local ID is assigned, but the following method may also be used. For example, IPv4 may be selected as the location type, and a local IP address may be used to specify the asset. For example, if the IP address is 192.168.xxx.xxx, the asset is considered to be stored locally, and the xxx.xxx portion may be used to identify the stored asset.

[0385] In addition, a local ID is assigned to the stored asset data (file). For example, it is stored in the file header. The local ID may be stored in advance by the broadcasting station, transmitting station, or content provider, or it may also be stored on the receiving side.

[0386] The above descriptors are merely examples, and the descriptors may be configured with a data structure having similar functions. Furthermore, the descriptors and identifiers of this embodiment may be stored in a table or message indicating package-unit information different from that of the MPT. They may also be transmitted using other signaling information.

[0387] Although MMT has been used as an example in the description, the present invention is not limited to MMT and other formats such as TS and MPEG-DASH may also be used. For example, when MPEG2-TS is used as the multiplexing method, the data may be stored in a PMT (Program Map Table). Furthermore, when transmitting a combination of the MPEG2-TS method and another method, the data may be stored in a TEMI (Timeline and External Media Information) access unit. When MPEG-DASH is used, the data may be described in an MPD (Media Presentation Description).

[0388] (Asset Configuration Information Descriptor) The MMT method also allows a single asset to be transmitted over multiple transmission paths. In this case, an asset configuration information descriptor that indicates the asset configuration may be stored.

[0389] 28 is a diagram showing an example of information included in the asset configuration information descriptor according to Embodiment 3. That is, the information indicating the asset configuration can include the following:

[0390] 1) Information indicating that the asset is a storage asset or that the asset contains storage packets may be included in the asset configuration. Here, an asset containing storage packets refers to an asset consisting of packets transmitted via broadcasting or communication and stored packets.

[0391] 2) If the asset is a storage asset, the information indicating the asset configuration may include, for example, a) information indicating that the asset is composed only of a storage asset or that the asset is composed of storage packets and transmission packets. Also, b) if the asset is composed of scalably coded video, the information indicating the asset configuration may include, for example, information indicating that the transmission packets include a base layer and the storage packets include an enhancement layer. Also, c) the information indicating the asset configuration may include information indicating whether decoding and playback of the storage packets is mandatory or not. For example, if the content of the storage packets is additional information, playback may be omitted, indicating that playback of the content of the storage packets is not mandatory.

[0392] This means that, for example, if the receiving device does not support storage or has not stored storage packets, the program can be played back using packets transmitted from broadcasting or communications rather than using stored packets, based on information indicating that decoding and playback of stored packets is not required to play the asset.

[0393] The above-described asset configuration information descriptor is an example, and the asset configuration information descriptor may be configured with a data structure having a similar function.

[0394] In addition, the asset configuration information descriptor and identifier may be stored in a table or message indicating information on a package basis, different from that of the MPT, or may be transmitted using other signaling information.

[0395] Although MMT has been used as an example in the description, the present invention is not limited to MMT and other formats such as TS and MPEG-DASH may also be used. For example, when MPEG2-TS is used as the multiplexing method, the data may be stored in a PMT (Program Map Table). Furthermore, when transmitting a combination of the MPEG2-TS method and another method, the data may be stored in a TEMI (Timeline and External Media Information) access unit. When MPEG-DASH is used, the data may be described in an MPD (Media Presentation Description).

[0396] [Receiving method and receiving device] An example of the operation of the receiving device in this embodiment to synchronously play back stored assets will be described below with reference to the drawings.

[0397] Fig. 29 is a flowchart showing a receiving method in the broadcast communication cooperative service according to the third embodiment. Fig. 30 is a block diagram showing an example of the configuration of a receiving device according to the third embodiment.

[0398] The receiving device 30 shown in FIG. 30 includes a program information analysis unit 31, an accumulated asset identification unit 32, an accumulated asset information analysis unit 33, a determination unit 34, an asset acquisition unit 35, a synchronous presentation unit 36, and a synchronous control unit 37.

[0399] First, in step S11, the program information analysis unit 31 analyzes the program configuration information descriptor that serves as the entry point, and analyzes whether the configuration of the program includes any accumulative assets.

[0400] Next, in step S12, the program information analysis unit 31 determines whether the elements constituting the program include accumulative assets. If it is determined that the elements constituting the program include accumulative assets (Yes in S12), the process proceeds to step S13, where information indicating the program configuration, information related to accumulative assets, relative time information with respect to accumulative assets, etc. If it is determined that the elements constituting the program do not include accumulative assets (No in S12), the process proceeds to step S17, where transmission assets transmitted via broadcasting, communication, etc. are obtained and played back in sync.

[0401] Next, in step S14, the receiving device 30 acquires location information and a local ID of the accumulated asset. More specifically, if the asset is accumulated locally, the accumulated asset identification unit 32 searches for and identifies the asset corresponding to the local ID from among the assets accumulated in the receiving device 30. Note that if there are multiple accumulation devices, the search may be performed among the multiple accumulation devices, or only within a specific accumulation device. Furthermore, the accumulated asset information analysis unit 33 acquires attribute information of the identified asset.

[0402] Next, in step S15, the judgment unit 34 judges whether or not the program including the accumulative asset can be played back based on the information about the accumulative asset acquired in step S12 and the attribute information about the accumulative asset acquired in step S14.

[0403] If it is determined that the program can be played back (Yes in S15), the process proceeds to step S16, where the asset acquisition unit 35 acquires storage assets in addition to transmission assets such as broadcasting and communication. Then, the synchronization control unit 37 performs synchronization control processing between the transmission assets and storage assets based on the acquired relative time information, and the synchronization presentation unit 36 ​​synchronizes and presents the program.

[0404] On the other hand, if it is determined in step S15 that the program cannot be played back (No in S15), the process proceeds to step S17, where a transmission asset transmitted by broadcasting or communication is acquired and synchronized / played back.

[0405] [Effects of the Third Embodiment] As described above, according to this embodiment, it is possible to realize a method for generating program information when a service that combines broadcasting and communication is multiplexed using a format such as the MMT (MPEG Media Transport) method that is currently being standardized by the MPEG (Moving Picture Expert Group), a method for playing back a program, and a playback device.

[0406] The MMT method multiplexes and packets video and audio, transmits them over one or more transmission paths such as broadcasting or communications, and receives the packets transmitted over one or more transmission paths at the receiving device, extracts the desired packets from the received packets based on the program information, and decodes and presents them.

[0407] The MMT method makes it possible to construct a program by receiving media (video, audio, subtitles, etc.) transmitted over multiple transmission paths. However, it is not possible to construct a program using both data downloaded and stored via broadcasting or communication and data streamed from broadcasting or communication.

[0408] Therefore, in this embodiment, the program information showing the program configuration includes an identifier indicating that one of the media making up the program is stored data, and an identifier that can identify the stored media (file). Furthermore, the playback device analyzes the program information, identifies the media transmitted by broadcasting or communication and the stored data, and plays them in sync.

[0409] This allows programs to be constructed using both data downloaded and stored via broadcasting or communications, and data streamed from broadcasting or communications, making it possible to provide services linked to stored files in addition to conventional broadcasting and communications integrated services.

[0410] In this embodiment, a combination of a transmission asset and a storage asset has been described as an example, but the present invention is not limited to this. The transmission asset may be an asset transmitted by broadcasting or an asset transmitted by communication. It may also be an asset transmitted by both broadcasting and communication. The following services may be provided as services using storage assets. An identifier indicating the content of the service may be stored in the program information.

[0411] (Services using accumulated assets) 1) It is possible to download the assets that make up a program in advance, transmit only program information and time synchronization information (such as time reference information and relative values ​​of timestamps) during broadcasting, and play the program using stored assets. In this case, broadcasters can provide viewers with programs using stored data in real time according to the program schedule. Viewers can watch the stored data as if they were watching a program being broadcast in real time. In addition to real-time broadcasting, on-demand content can also be provided.

[0412] 2) It is also possible to download and store program information and random access points along with the assets that make up a program in advance, and then compose the program in synchronization with the program information transmitted via broadcasting or communication.

[0413] 3) It is also possible to transmit regular broadcast programs only via broadcasting, and provide a service that links with stored data only during commercial breaks. Commercial data may be downloaded in advance from broadcast or communication, and a program including the stored data may be provided to viewers during commercial breaks. Alternatively, multiple commercial data may be downloaded in advance, and commercials to be provided may be selected based on the viewer's attributes and preferences. Viewer attributes and preferences may be acquired and analyzed by the receiving device, or may be acquired in conjunction with other apps or services.

[0414] 4) A broadcaster may allocate free frequency resources to other services by providing services linked to stored data, and in this case, the program information may include information indicating that the frequency resources used by the service in question are being provided to other services.

[0415] 5) A viewer may have the ability to switch to a program linked to a storage asset. For example, a viewer who is viewing only a transmission asset may switch to a program that includes a storage asset using a user interface such as a remote control.

[0416] 6) Furthermore, the receiving device or the viewer may set whether or not it is permitted to access the storage assets to compose a program. Also, it may be permitted to access the storage assets to compose a program only if the program information is authenticated as trustworthy. The program information may store information such as a key to indicate that the program information is trustworthy.

[0417] (EPG) 7) Information to be displayed as an EPG (Electronic Program Guide) may be obtained from program information or from signaling information dedicated to EPG.

[0418] 8) The EPG may display information such as whether a program is provided via broadcasting, communication, storage, a combination of these, or as an extended service. Also, only the functions that the receiving device can provide may be displayed. For example, if the receiving device does not have the storage function or the communication receiving function, information regarding storage or communication may not be displayed.

[0419] 9) For a program that includes accumulative assets, information indicating whether the accumulative assets of the program are accumulated or not may be displayed on the EPG. Information indicating whether the accumulative assets of the program are available for presentation may be displayed on the EPG. This may be indicated by text or by the background color of the program in the EPG. Content that includes accumulative assets may display information related to viewing restrictions and copyrights.

[0420] 10) When reserving a program that includes a storage asset from an EPG, the EPG or the like may display whether the storage asset can be downloaded from broadcast, downloaded from communication, or viewed via streaming communication. If the receiving device does not have communication means, it may only display whether broadcast download is available. Viewers can reserve by selecting from the available download reservation methods.

[0421] The viewer may reserve the download in advance from the EPG, or the receiving device may automatically download. The viewer may select the download method, or the receiving device may automatically select the method.

[0422] Furthermore, the display of the EPG and the functions of the receiving device may be changed depending on the time period during which downloading is possible via broadcasting, the time period during which downloading is possible via communication, and the time period during which streaming is possible via communication.

[0423] It should be noted that the display is not limited to the EPG described above, and the display may be performed in a manner other than the EPG.

[0424] While the transmission method and 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 conceivable by those skilled in the art to the present embodiments and configurations constructed by combining components of different embodiments may also be included within the scope of one or more aspects of the present invention.

[0425] For example, in each of the above embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory. [Industrial Applicability]

[0426] The present invention is useful as a content transmission method, a content reception method, etc., that can transmit content using broadcast waves and communication paths. [Explanation of symbols]

[0427] 11 Identification information acquisition unit 14, 104, 305, 405, 1105 Broadcast receiving unit 30, 100, 300, 400, 700, 1100 receiving device 31 Program Information Analysis Unit 32 Accumulated Asset Identification Department 33 Accumulated Asset Information Analysis Department 34, 103 Judgment section 35 Asset Acquisition Department 36 Synchronous Presentation Unit 37 Synchronization control section 101, 301, 401, 1101 Identification information acquisition unit 102 Asset Determination Department 105, 306, 406, 1106 Communication receiver 302, 402, 1102 Decision Section 303, 403, 1103 Communication combined use determination unit 304, 404, 1104 Loc information acquisition section 407 Synchronization Judgment Unit 408, 1108 Reproduction Department 701 Receiving unit 702 Default Information Analysis Unit 703 Application information receiving unit 704 Application playback control information analysis unit 705 Playback control execution unit 1107 Reference clock judgement

Claims

1. A content transmission method capable of transmitting content using broadcast waves and a communication path, comprising: a generating step of generating the content in a format conforming to MMT (MPEG Media Transport); a content transmission step of transmitting the content in the format generated in the generation step; an information transmitting step of transmitting, in a case where the content is transmitted using both a broadcast wave and a communication path, auxiliary information including information indicating the presence of the content to be transmitted via the communication path, information indicating a format of meta information for playback control of the content to be transmitted via the communication path, and location information indicating a source of the content to be transmitted via the communication path, using at least the broadcast wave; In the generating step, the auxiliary information is generated by being included in message information which is information relating to acquisition of the content. Sending method.

2. A content transmission device capable of transmitting content using broadcast waves and a communication path, a generating unit that generates the content in a format conforming to MMT (MPEG Media Transport); a content transmission unit that transmits the content in the format generated by the generation unit; an information transmitting unit that, when transmitting content using both a broadcast wave and a communication path, transmits, using at least the broadcast wave, information indicating the presence of the content transmitted via the communication path, information indicating a format of meta information for playback control of the content transmitted via the communication path, and auxiliary information including location information indicating a source of the content transmitted via the communication path; the generation unit generates the auxiliary information by including the auxiliary information in message information that is information related to acquisition of the content; Transmitting device.

Images