Transmission method and transmission device
The method synchronizes content transmission across broadcast and communication paths using auxiliary information, addressing delays in communication-based content reception and enhancing reception efficiency.
Patent Information
- Application Number
- JP2024099343
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2013-10-18
- Filing Date
- 2024-06-20
- Publication Date
- 2025-07-07
- Estimated Expiration
- 2034-07-15
AI Technical Summary
Existing content distribution methods fail to efficiently synchronize and synchronize content reception between broadcast and communication paths, leading to delays and inefficiencies in starting content reception via communication channels.
A content transmission method that utilizes a broadcast wave and a communication path, incorporating auxiliary information for synchronization, including location and clock information, to enable seamless content reproduction despite delayed communication reception start times.
Enables synchronized reproduction of content combining broadcast and communication, reducing delays and improving reception efficiency by providing auxiliary information for synchronization and content acquisition.
Smart Images

Figure 0007703750000001 
Figure 0007703750000002 
Figure 0007703750000003
Abstract
Description
Technical Field
[0001] The present invention relates to a transmission method and a reception method.
Background Art
[0002] Conventionally, the main transmission path for delivering content has been a broadcast wave, and as a media transport method widely used in a broadcast system using a broadcast wave, for example, there is MPEG-2 TS (Moving Picture Experts Group-2 Transport Stream).
[0003] On the other hand, with the recent progress of network technology, it has become possible to deliver content using a communication path such as the Internet. That is, it has become possible to deliver content using not only a broadcast wave but also a communication path, and the transmission paths capable of delivering content have become diversified.
[0004] For example, Non-Patent Document 1 discloses MMT (MPEG Media Transport) and the like as a new media transport method assuming content delivery using both broadcast and communication (see Non-Patent Document 1). For example, Patent Document 1 discloses a technique for accessing communication content based on data obtained from a broadcast, mainly using the broadcast.
Prior Art Documents
Non-Patent Documents
[0005]
Non-Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0006] However, in order to distribute content that combines broadcasting and communication and receive the distributed content, although discussions have been made on acquiring information (service information) related to content reception and starting content reception, rapid access operations to content by communication are not considered, and there are problems such as delays in the reception start timing of content by communication.
[0007] Therefore, an object of the present invention is to provide a content transmission method that enables the receiving side to reproduce content that combines broadcasting and communication even when the reception start timing of content by communication is delayed.
Means for Solving the Problems
[0008] In order to solve the above problems, a transmission method according to an aspect of the present invention is a content transmission method capable of transmitting content using a broadcast wave and a communication path, including: a generation step of generating the content in a format according to MMT (MPEG Media Transport); a content transmission step of transmitting the content in the format generated in the generation step; and when transmitting content using each of a broadcast wave and a communication path, an information transmission step of transmitting at least using the broadcast wave, information indicating that there is the content transmitted by the communication path, information indicating a format of meta information for reproduction control of the content transmitted by the communication path, and auxiliary information including location information indicating a destination of acquisition of the content transmitted by the communication path.
[0009] Note that these general or specific aspects may be realized by a data reception method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be realized by any combination of a data transmission method, a data reception method, an integrated circuit, a computer program, and a recording medium.
Effects of the Invention
[0010] According to the present invention, even if the reception start timing of content by communication is delayed, it is possible to realize a content transmission method or the like that can reproduce content that combines broadcast and communication on the receiving side.
Brief Description of the Drawings
[0011]
Figure 1A
Figure 1B
Figure 2
Figure 3A
Figure 3B
Figure 4A
Figure 4B
Figure 5
Figure 6A
Figure 6B
Figure 7A
Figure 7B
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13A
Figure 13B
Figure 13C
Figure 13D
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18A
Figure 18B
Figure 19A
Figure 19B
Figure 20A
Figure 20B
Figure 21A
Figure 21B
Figure 22
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Embodiments for Carrying Out the Invention
[0012] (Knowledge on which the present invention is based) Currently, a service (broadcast communication cooperation service) that uses both broadcast and communication to distribute content is being considered. Among them, a method that mainly uses broadcast and accesses content obtained from communication (hereinafter referred to as communication content) based on data obtained from broadcast is promising. As an operation at the start of viewing on the receiving side for receiving content in the broadcast communication cooperation service, similar to a conventional service that distributes content only by broadcast, after obtaining service information, it is considered to start receiving content by encoded data of audio or video, or a data carousel in the MPEG-2 system.
[0013] However, in the service information that can be obtained by conventional services, considerations for operations such as quickly accessing communication content and operations when receiving only broadcast content are not taken into account. Therefore, when performing a broadcast communication cooperation service using conventional service information, there are problems such as an increase in processing related to analyzing service information and a delay in the acquisition start timing of communication content.
[0014] In order to solve such problems, a transmission method according to an aspect of the present invention is a content transmission method capable of transmitting content using a broadcast wave and a communication path. When transmitting content using each of the broadcast wave and the communication path, it includes an information transmission step of transmitting, at least using the broadcast wave, auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path, and causing the synchronization to be taken when the receiving side receives the auxiliary information.
[0015] According to this aspect, even if the reception start timing of content by communication is delayed, it is possible to realize a content transmission method that enables the receiving side to reproduce content that combines broadcast and communication. More specifically, when content is transmitted using a broadcast wave and a communication path, auxiliary information for synchronizing the content transmitted using the broadcast wave and the communication path is transmitted. Thus, when the receiving side receives the auxiliary information, the receiving side can be made to synchronize the content.
[0016] Here, for example, in the information transmission step, the auxiliary information is transmitted prior to transmitting the content, and the auxiliary information may further include location information indicating the acquisition destination of the content or information indicating the acquisition destination of the location information.
[0017] Also, for example, in the auxiliary information transmission step, the auxiliary information may further include difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path and be transmitted.
[0018] Also, for example, in the auxiliary information transmission step, by transmitting the auxiliary information, when the reference clocks of the content are different, the receiving side may be made to synchronize by synchronizing the reference clock of the content by the communication path with the reference clock of the content by the broadcast wave based on the difference information.
[0019] Also, for example, the transmission method may include a generation step of generating the content in a format according to MMT (MPEG Media Transport), and a content transmission step of transmitting the content in the format generated in the generation step.
[0020] Also, for example, in the generation step, the auxiliary information may be generated by including it in message information that is information related to the acquisition of the content.
[0021] Also, in order to solve the above problems, a receiving method according to an aspect of the present invention includes a receiving step of receiving content transmitted using each of a broadcast wave and a communication path, and a reproduction step of performing a synchronization process and reproducing the content when receiving auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path.
[0022] Here, for example, in the receiving step, if the auxiliary information is received prior to receiving the content and the auxiliary information includes location information indicating the acquisition destination of the content, the content may be received by acquiring the content based on the location information.
[0023] Also, for example, in the receiving step, if the auxiliary information is received prior to receiving the content and the auxiliary information includes information indicating the acquisition destination of the location information indicating the acquisition destination of the content, the location information may be acquired based on the information indicating the acquisition destination of the location information, and the content may be received by acquiring the content from the acquired location information.
[0024] Also, for example, in the reproduction step, if the auxiliary information including the difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path is received in the receiving step and the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path are different, the synchronization process of the content may be performed by synchronizing the reference clock of the content by the communication path with the reference clock of the content by the broadcast wave based on the difference information, and the content may be reproduced.
[0025] Also, in order to solve the above problems, a transmission device according to an aspect of the present invention is a content transmission device capable of transmitting content using a broadcast wave and a communication path. When transmitting content using each of the broadcast wave and the communication path, it is auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path, and an information transmission unit that transmits at least the auxiliary information for causing the receiving side to perform the synchronization using the broadcast wave.
[0026] Also, in order to solve the above problems, a receiving device according to an aspect of the present invention includes a receiving unit that receives content transmitted using each of a broadcast wave and a communication path, and when receiving auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path, a playback unit that performs a process of taking the synchronization and plays back the content.
[0027] Note that these general or specific aspects may be implemented by a transmission method, a transmission device, a reception method, a reception device, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be implemented by an arbitrary combination of a data reception method, an integrated circuit, a computer program, or a recording medium.
[0028] Hereinafter, a transmission method, a reception method, and the like according to an aspect of the present invention will be specifically described with reference to the drawings.
[0029] Note that each of the embodiments described below shows a specific example of the present invention. Numerical values, shapes, materials, components, arrangement positions and connection forms of components, steps, orders of steps, etc. shown in the following embodiments are merely examples and are not intended to limit the present invention. In addition, among the components in the following embodiments, components not described in the independent claims indicating the most general concept are described as optional components.
[0030] (Embodiment 1) In this embodiment, a transmission method for transmitting and receiving content in a broadcast communication cooperation service will be described.
[0031] [Transmission Method] In this embodiment, the transmitting side transmits content (data or assets) using a broadcast wave and a communication path, but transmits service information prior to the transmission of the content.
[0032] [Service Information] Here, the service information refers to information for acquiring audio, video, or data related to data broadcasting after a channel selection operation (after channel selection), or a series of information related to the reception of content and the acquisition of metadata, such as EPG (Electronic Program Guide) information.
[0033] Currently, broadcasts are mainly transmitted using MPEG-2 TS (Transport Stream) sections, and include PAT (Program Association Table), PMT (Program Map Table), NIT (Network Information Table), CAT (Conditional Access Table), or EIT (Event Information Table) defined by ARIB (Association of Radio Industries and Businesses).
[0034] In this embodiment, MMT (MPEG Media Transport) standardized by MPEG will be described as an example of the multiplexing format on the broadcast side in a broadcast cooperation service. However, this multiplexing format is not limited to MMT, and other multiplexing formats such as TS or MPEG-DASH (Dynamic Adaptive Streaming over HTTP) may also be used.
[0035] The service information in this embodiment is transmitted in a data structure that can be stored in a multiplexed format. For example, in MMT, the service information is transmitted by a table such as an MPT (MMT Package Table) or message information such as a PA (Package Access) message. In each table, similar to the TS, auxiliary information can be described using a descriptor.
[0036] FIG. 1A and FIG. 1B are diagrams showing an example of the data structure of service information in the broadcast communication cooperation service of Embodiment 1. More specifically, FIG. 1A shows an MPT including a transmission path identifier descriptor, and FIG. 1B shows an example in which information regarding the transmission path of an asset constituting a package is described as attribute information in the transmission path identifier descriptor shown in FIG. 1A.
[0037] (Attribute information) 1) As the attribute information, information indicating whether the asset constituting the package is transmitted by (1) using only broadcasting or (2) using both broadcasting and communication may be included.
[0038] Note that the information indicating whether the audio and video data in this main body is transmitted by (1) using only broadcasting or (2) using both broadcasting and communication may be used. With this information, even when the main body is transmitted using only broadcasting, metadata different from the main body such as audio, video, still images, or HTML files can be acquired from the communication network.
[0039] 2) When the audio and video data are transmitted using both broadcasting and communication, information indicating the relationship between the data transmitted respectively may be included as attribute information.
[0040] Here, for example, when realizing scalability (temporal resolution (60fps → 120fps, etc.), spatial resolution (4k → 8k, etc.), bit depth (8bit → 10bit, etc.)), it can be indicated by the attribute information that the broadcast uses the base layer and the communication uses the enhancement layer for transmission. Note that the attribute information may indicate that although the frame rate is 60fps only for the broadcast data, the frame rate can be improved up to 120fps when using the communication data in combination. Also, it may be indicated that the data for backup of the broadcast is transmitted by communication. Thereby, the transmission side can switch to transmitting data by communication using the attribute information when the reception status of the broadcast deteriorates due to rainfall attenuation or the like.
[0041] Also, the attribute information may indicate information for identifying related assets. For example, the attribute information may indicate the asset ID of the base layer and the asset ID of the enhancement layer corresponding to the base layer.
[0042] In MMT, it is also possible to transmit the same asset using a plurality of transmission paths. Therefore, the attribute information may indicate whether the same asset is transmitted using both broadcast and communication. At this time, the identification information (such as the asset ID) of the asset may be separately indicated. The information for identifying related assets may be indicated by, for example, an individual transmission path descriptor for each asset as shown in FIG. 2. Here, FIG. 2 is a diagram showing an example of the outline of the transmission path descriptor in Embodiment 1. The individual transmission path descriptor shown in FIG. 2 may indicate information for identifying whether the asset is an asset of the base layer or the enhancement layer, or may indicate the ID of the corresponding base layer asset when the asset is an enhancement layer.
[0043] Also, the attribute information may group the broadcast assets and the communication assets respectively and indicate a list of the assets included in the group. When there are assets transmitted using both broadcast and communication, they may be grouped separately.
[0044] 3) It may also be possible to include, as attribute information, information indicating whether the audio or video transmitted by broadcast and the audio or video transmitted by communication are played back synchronously.
[0045] 4) It may also be possible to include, as attribute information, information indicating whether the clock information of the audio or video transmitted by broadcast and the clock information of the audio or video transmitted by communication are the same.
[0046] Note that the attribute information may indicate individual information as individual fields, or information indicating the type of service may be defined so that it can be identified by type. Also, the attribute information may be described in a format different from that of the descriptor.
[0047] Also, the transmission path identification descriptor may be stored in a table or message indicating information in package units, which is different from the MPT. Also, the content of the above transmission path identification descriptor may be described as a data structure different from that of the descriptor.
[0048] Also, when transmitting a plurality of packages, a table or message indicating a list of packages may be defined, and information such as the transmission path identification descriptor may be shown as package attribute information in units of packages.
[0049] FIG. 3A and FIG. 3B are diagrams showing another example of the data structure of service information in the broadcast communication cooperation service of Embodiment 1.
[0050] That is, as shown in FIGS. 3A and 3B, regarding the location information for each asset, the assets transmitted by broadcast and communication may be stored in different MPTs, respectively. At this time, the attribute information of the package can be stored in the MPT sent on the transmission path that is the entry point of the service. For example, when broadcast is the entry point, it is stored in the MPT sent by broadcast. Also, these MPTs can be identified by the table_id.
[0051] In the MMT standard, since the value of the table_id of the reference MPT is defined as zero, it is possible to set the table_id of the MPT corresponding to the transmission path serving as the entry point to zero and set the table_id of the MPT corresponding to the other transmission path to 1 or more.
[0052] Note that the MPT of the broadcast asset may be transmitted by broadcast, and the MPT of the communication asset may be transmitted by communication.
[0053] Also, the location information of the broadcast and communication assets may be stored in one MPT. In this case, the location information of each asset may be stored continuously so that it can be easily identified. For example, when there are N1 broadcast assets and N2 communication assets, first, the information of the N1 broadcast assets is described continuously, and then the information of the N2 communication assets is described continuously. Note that in the transmission path identification descriptor, it may be indicated that N1 assets are transmitted in the broadcast and N2 assets are transmitted in the communication.
[0054] In this way, on the transmission side, the service information is transmitted including the transmission path identification descriptor which is auxiliary information. Thereby, on the reception side, by simply acquiring the service information including the auxiliary information, based on the attribute information of the package described in the transmission path identification descriptor, it is possible to obtain in advance whether communication data is included, or the dependency relationship between broadcast data and communication data, etc., without analyzing the information for each asset.
[0055] In particular, when receiving communication data, there is an advantage that the delay time related to the activation of the reception process can be shortened.
[0056] [Transmission device] For example, the transmission device of the present embodiment is a content transmission device capable of transmitting content using a broadcast wave and a communication path, and generates attribute information of a package such as a transmission path identification descriptor as auxiliary information and transmits it included in the service information.
[0057] The transmission device according to this embodiment may transmit this service information periodically. When the content of this service information is updated, the updated content is reflected in the service information immediately after the update.
[0058] Also, the entry point is not limited to broadcasting, and may be communication, or may be made accessible from both broadcasting and communication. When making it accessible from both, for information in package units, at least, it is transmitted from the transmission devices of both broadcasting and communication.
[0059] Note that when receiving the content of the broadcast communication cooperation service on the receiving side, it is not always necessary to receive the data sent through both transmission paths. For example, it may be possible to receive and play only the broadcast data. At this time, since the information required when the receiving side receives communication data is unnecessary when receiving broadcast data, the transmitting side may transmit the information required when receiving communication data in communication. That is, the transmitting side may transmit information in package units on the transmission path serving as the entry point, and information specific to transmission paths such as broadcasting and communication may be transmitted on their respective transmission paths (for example, FIG. 2). Note that hereinafter, the description will be made assuming that the broadcast is the entry point.
[0060] By doing so, the service information specific to each transmission path can be generated and transmitted by the transmission device on each transmission path. However, information transmitted by MPT such as the location information of the asset may be transmitted by broadcasting because the delay time related to the start of acquisition of the asset on the communication side can be reduced by acquiring it in a batch first.
[0061] (Examples of information specific to communication) Examples of information specific to communication (communication networks such as the Internet and CDN (Contents Delivery Network)) are shown.
[0062] 1) Information related to FEC (Forward Error Correction) in packets transmitted by communication, such as the FEC method, parameters, etc. 2) Information related to QoS (Quality of Service) control, such as the packet loss rate, jitter in packet arrival time, or RTT (Round Trip Time), end-to-end delay in the communication transmission path, etc. 3) Information related to buffering from the reception of asset data until the start of decoding, such as the buffering time, buffering amount, etc.
[0063] Note that in broadcasting as well, especially in broadcasting for mobile devices (such as 1-segment broadcasting in Japan), FEC and QoS are important, but the parameters in these are different from those in the communication path. Therefore, information specific to broadcasting only needs to be transmitted in broadcasting.
[0064] On the other hand, in communication, it is possible to select a plurality of audio and video data according to the bandwidth of the communication network, such as the bit rate and frame rate. At this time, information associating the attribute information (such as the bit rate) of the selectable data with the asset ID may be transmitted. Note that such associating information may also be transmitted in broadcasting.
[0065] Note that as the associating information, information indicating whether there are a plurality of selectable assets may be shown, or when there are a plurality of selectable assets, a list of selectable assets may be shown.
[0066] [Receiving method] In this embodiment, the receiving side starts receiving (acquiring) the content after obtaining the service information. Hereinafter, the receiving method in this embodiment will be described with reference to the figures.
[0067] FIG. 4A is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Embodiment 1. FIG. 4A shows an example of the operation in which the receiving device acquires the transmission path identification descriptor of the present embodiment and determines the asset to be received.
[0068] First, as service information transmitted on the transmission path serving as an entry point, for example, an MPT table included in a PA message or an MPT message is acquired, and the transmission path identification descriptor included therein is acquired.
[0069] Next, information of the transmission path identification descriptor, such as whether an asset is transmitted using both broadcast and communication, and when both transmission paths are used, the dependency relationship between the broadcast and communication assets, is interpreted (step S101).
[0070] Messages such as PA messages are stored in the payload of packets such as MMT packets, and the packet header indicates the type of data to be stored. Therefore, when receiving an MMT package, first, the ID number (corresponding to packet_id in the MMT packet) in the packet header is referred to, and the MMT packet of the PA message is acquired.
[0071] Next, based on, for example, the playback ability of the terminal or whether the communication path is available, the asset to be received is determined (step S102).
[0072] Here, an example of the asset determination method will be described.
[0073] 1) When the receiving device is not connected to the communication network, it is determined to receive only the broadcast asset. At this time, the asset transmitted using both broadcast and communication is not received.
[0074] 2) When the basic layer of the video is transmitted by broadcast and the extended layer is transmitted by communication, if only the basic layer can be played, only the broadcast is determined to be received, and if both layers can be played, both the broadcast and the communication are determined to be received. For example, assume that time scalability of 60 fps with only the basic layer and 120 fps with both the basic layer and the extended layer can be realized. In this case, if the receiving device can only decode and display up to 60 fps, only the broadcast is received, and if it can decode and display up to 120 fps, both the broadcast and communication data are received.
[0075] 3) According to the bandwidth of the communication network to which the receiving device is connected, a receivable asset is determined from a plurality of assets with different bitrates transmitted by communication. Here, for example, information such as the bitrate of each asset is transmitted separately in service information or the like. Note that when the reception state is poor due to congestion of the communication network or the like and there is no asset that can be stably received, it may be determined not to receive the data on the communication side.
[0076] 4) Also, in preparation for deterioration of the broadcast reception environment, when backup data is being transmitted in communication, it may be determined to determine the asset to be acquired when the reception environment deteriorates. In this case, the receiving device monitors the reception environment and determines whether to receive the communication asset based on an index such as the error rate in the received data, and may perform reception processing.
[0077] 5) When receiving data (such as data of the extended layer in video) that is synchronously played with the audio or video data of the main body transmitted by broadcast from communication, in order to ensure the synchronization of the data received by broadcast and the data received by communication, special operations such as buffering the data before the start of playback may be required. In this case, from communication, it may be determined to receive only assets that do not require strict synchronization (for example, synchronization in units of frames) with the data transmitted by broadcast. For example, it may be determined to acquire from communication assets such as data such as HTML, still images, and videos that do not require strict synchronization.
[0078] Next, referring back to the flowchart of FIG. 4A, an explanation will be given.
[0079] Next, in step S103, it is determined (judged) whether to receive an asset transmitted by communication. If it is determined (judged) to receive (yes in S103), the process proceeds to S104. If it is determined (judged) not to receive (no in S103), the process proceeds to S105.
[0080] In S104, the asset is received from both the broadcast and communication transmission paths. In S105, the asset is 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 cooperation service of Embodiment 1.
[0082] Compared with FIG. 4A, in FIG. 4B, when service information specific to communication is transmitted in communication, a step (step S106) of receiving the service information is added. Since the other aspects are the same as those described in FIG. 4A, the description is omitted.
[0083] If there is service information specific to broadcast, it shall be separately received in steps not shown.
[0084] Also, if the receiving device does not support the broadcast communication cooperation service, it may only receive the broadcast asset. In this case, if there is an asset transmitted using both broadcast and communication, the asset is not received.
[0085] [Receiving Device] FIG. 5 is a block diagram showing an example of the configuration of the receiving device in Embodiment 1. FIG. 5 shows an example of the configuration of the receiving device that realizes the receiving method described in FIG. 4A.
[0086] The receiving device 100 shown in FIG. 5 includes an identification information acquisition unit 101, an asset determination unit 102, a determination unit 103, a broadcast reception unit 104, and a communication reception unit 105.
[0087] The identification information acquisition unit 101 has a function to implement step S101 shown in FIG. 4A. Specifically, the identification information acquisition unit 101 acquires service information transmitted on the transmission path serving as an entry point, and acquires the transmission path identification descriptor (auxiliary information) included therein. Then, the identification information acquisition unit 11 interprets the information of the transmission path identification descriptor.
[0088] The asset determination unit 102 has a function to implement step S102 shown in FIG. 4A, and determines the received asset based on the playback ability of the terminal or whether the communication path is available or the like.
[0089] The determination unit 103 has a function to implement step S103 shown in FIG. 4A, and determines (judges) whether to receive the asset transmitted by communication. Specifically, the determination unit 103 determines whether to receive communication data, and if it is determined to receive, the broadcast reception unit 104 and the communication reception unit 105 receive the data of the asset determined in step 102.
[0090] When the determination unit 103 determines not to receive the communication data, it receives the data using only the broadcast reception unit 14.
[0091] (Modification Example 1) In this modification example, an example in which broadcasting is transmitted using TS and communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like will be described.
[0092] FIGS. 6A and 6B are diagrams showing an example of the data structure of service information in the broadcast communication cooperation service of Modification Example 1 of Embodiment 1. FIG. 6A shows an example in which information regarding data transmitted in communication is stored in the PMT. FIG. 6B shows an example of the data structure of the transmission path identification descriptor of this modification example.
[0093] In this modification example, a transmission path identification descriptor indicating the attribute information described in FIGS. 1A and 1B is stored in the 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 shown. Therefore, in this modification example, when the content data is transmitted using a combination of communications, the location information of the data on the communication side is stored in the transmission path identification descriptor. More specifically, the attribute information includes flag information indicating whether communication is used in combination. Thereby, the transmission side can select whether to include the location information of the data on the communication side according to the value of the flag information. Note that the location information is not limited to being stored in the transmission path identification descriptor. A separate descriptor may be defined to store the location information.
[0095] (Location information) The location information is information indicating the acquisition destination of the data. In the case of the TS, it corresponds to the PID, and in the case of communication, it corresponds to the URL, URI, etc.
[0096] As the location information, the MPD (Media Presentation Description) of DASH, the SDP (Session Description Protocol) in RTP, etc. may be stored.
[0097] Also, the location information is not limited to storing the actual data of the location information such as the MPD and the SDP. Information indicating the acquisition destination of the actual data of the location information may be stored. Here, the information indicating the acquisition destination of the actual data of the location information is, for example, information indicating the URL for acquiring the MPD. However, when information indicating the acquisition destination of the actual data of the location information is stored in the location information, a delay occurs for separately acquiring the actual data of the location information. Therefore, from the viewpoint of reducing the delay until the reception of the data on the communication side starts, it is desirable to directly store the actual data in the location information.
[0098] Note that since the DASH MPD contains various information regarding the content acquisition destination, it is large in size. Therefore, instead of storing the MPD as it is in the location information, it may be possible to store a subset of information that only includes the URL of the content acquisition destination and information regarding the DTS and PTS of the segments.
[0099] Also, it is 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. As a result, when the version number is updated, the location information can be retrieved again. In addition, in order to check whether the version number has been updated, information such as the transmission path identifier descriptor in the PMT that is periodically transmitted may be sequentially checked. However, since this sequential check process is heavy, it may be possible to separately generate (referred to as a transmission path identification section) section data for storing location information and transmit it periodically.
[0101] In the receiving device, by checking the version number in the transmission path identification section, it is possible to determine whether the location information has been updated. Note that in both the program information such as PMT and the transmission path identification section, attribute information and location information may be transmitted. Alternatively, in the transmission path identification section, only the location information may be stored.
[0102] Also, after starting to acquire communication-side data based on the location information obtained from the broadcast, it may be possible to acquire the updated content of the location information in the communication. At this time, since the location information acquisition destination is required, in the broadcast transmission path identifier descriptor or the like, the location information acquisition destination may be stored together with the actual location information data.
[0103] In the receiving apparatus, it is possible to obtain updated content in communication by periodically accessing the acquisition source of the location information.
[0104] Also, when there is a mechanism such as message exchange between the DASH content distribution server and the receiving apparatus, the server may issue a message indicating that the location information has been updated to the receiving apparatus. Then, in the receiving apparatus, when the message is received, the location information may be acquired again.
[0105] Although it has been described that information regarding data transmitted in communication is stored in the PMT, it is not limited to this. The attribute information and location information may be transmitted by a section different from the PMT.
[0106] Also, based on whether the data transmitted in communication is to be synchronously reproduced with the audio or video in the broadcast, the acquisition method of the data on the communication side may be switched.
[0107] For example, when synchronous reproduction is performed, access to the data on the communication side can be enabled from the program information of the broadcast as described above. When synchronous reproduction is not performed, information for accessing the data on the communication side may be transmitted by data broadcast using, for example, the AIT (Application Information Table) defined in the hybrid broadcast specification in ARIB (Association of Radio Industries and Businesses). In the receiving apparatus, the AIT is received in the form of a table or a carousel, etc., and the data on the communication side is acquired based on the content of the AIT. When an event message transmitted by data broadcast is received for the acquired data on the communication side, the reproduction is started.
[0108] Note that even when the broadcast data and the communication data are synchronously reproduced, information such as the AIT may be used. At this time, the times such as the start time and end time of the reproduction of the data on the communication side shall be separately indicated in the data broadcast. In the receiving apparatus, the data on the communication side is reproduced according to these times.
[0109] In MPD in DASH and SDP in RTP, the start time of content playback or the start time of decoding can be indicated, and these times are specified based on a reference clock defined for each multiplexing and transmission method, such as UTC (Coordinated Universal Time). Also, the PTS (Presentation Time Stamp) and DTS (Decoding Time Stamp) of individual video frames and audio samples are set based on the reference clock. On the other hand, in broadcasting, since PCR (Program Clock Reference) serves as the reference clock, when synchronously playing back broadcast-side data and communication-side data, information indicating the correspondence relationship between their reference clocks is required.
[0110] Therefore, information indicating the correspondence relationship between the reference clocks of broadcast-side data and communication-side data may be included in program information such as PMT in broadcasting. For example, it may be information such as the time when the value of PCR in broadcasting is N1 corresponds to the time when the value of UTC in communication is N2. Note that this information may also be included in MPD, SDP, etc.
[0111] Also, in the transmission path identifier descriptor, information on the transport layer protocol, such as whether the communication-side data is transmitted by UDP (User Datagram Protocol) or TCP (Transmission Control Protocol), may be indicated. Thereby, in the receiving device, it becomes possible to open the ports used in each protocol or to determine whether it corresponds to the protocol used.
[0112] Also, identification information on the multiplexing format in the communication-side data may be indicated so that, for example, it can be identified whether it is DASH or RTP.
[0113] [Receiving Method] Hereinafter, with reference to the drawings, as a receiving method in this modification example, an example of the operation of a receiving apparatus will be described in the case where broadcasting is transmitted using TS and communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like.
[0114] FIG. 7A is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 1 of Embodiment 1. FIG. 7A shows an example of the operation of the receiving apparatus when attribute information and location information are stored in the program information of the broadcast.
[0115] The operations of each step (Steps S201 to S205) are the same as those in the flowchart of FIG. 4A. However, in FIG. 4A, the data on the broadcast side and the communication side were unified in the asset of the MMT package, whereas in FIG. 7A, the broadcast side is TS and the communication side is DASH or RTP data, which is different. Since the other points are as described in FIG. 4A, detailed description will be omitted.
[0116] FIG. 7B is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 1 of Embodiment 1. FIG. 7B shows an example of the operation in the case where access information for acquiring attribute information and location information is stored in the program information of the broadcast and the entity of the location information is not stored.
[0117] Step S301 is the same as Step S201, so the description will be omitted.
[0118] Next, in Step S302, it is determined whether to receive the data on the communication side. If it is determined to receive the data on the communication side in Step S303, the process proceeds to S304. If it is determined not to receive the data on the communication side, the process proceeds to S306.
[0119] In Step S304, the location information is acquired according to the acquisition destination of the location information of the communication-side data included in the program information of the broadcast.
[0120] On the one hand, in step S305, communication-side data is acquired based on the location information acquired in S304, and broadcast data is also acquired. Further, in S306, only the data transmitted by broadcast is acquired.
[0121] (Attribute information) The attribute information is the same as that described in Embodiment 1. However, in Embodiment 1, MMT was used as an example. Therefore, hereinafter, examples when the broadcast is TS and the communication uses DASH or RTP will be described.
[0122] 1) It may be included as attribute information the information indicating whether the data such as audio and video constituting the content is transmitted by (1) using only broadcast or (2) using both broadcast and communication.
[0123] Note that it may also be the information indicating whether the audio and video data is transmitted by (1) using only broadcast or (2) using both broadcast and communication. With this information, even when the main body is transmitted using only broadcast, the metadata such as audio, video, still images, or HTML files can be acquired from a communication network different from the main body.
[0124] 2) It may be included as attribute information the information indicating the relationship between the data transmitted respectively when audio and video are transmitted using both broadcast and communication.
[0125] Here, for example, when realizing scalability (temporal resolution (such as 60fps → 120fps), spatial resolution (such as 4k → 8k), bit depth (such as 8bit → 10bit), etc.), it can be shown that the broadcast uses the basic layer and the communication uses the extended layer for transmission according to the attribute information. As a use case, the attribute information may indicate that the frame rate is 60fps with only broadcast data, but can be improved up to 120fps when using communication data in combination. Also, the attribute information may indicate that data for backup of the broadcast is transmitted via communication. Thereby, on the transmission side, when the reception status of the broadcast deteriorates due to rain attenuation or the like, the data can be switched to be transmitted via communication using the attribute information.
[0126] Also, the attribute information may indicate information for identifying encoded streams related to each other. For example, the attribute information can indicate the PID of the TS packet storing the data of the basic layer transmitted by broadcast, the segment in the DASH data transmitted by communication, or the identification information of video data such as the track ID in MP4.
[0127] Also, the attribute information may indicate information indicating the data on the broadcast side and the data on the communication side that are synchronously played back with each other. Thereby, on the transmission side, videos of multiple viewpoints, or videos of the parent screen and the child screen in a picture-in-picture can be transmitted by broadcast and communication respectively.
[0128] 3) Information indicating whether the audio, video, etc. transmitted by broadcast and the audio, video, etc. transmitted by communication are synchronously played back may be included as attribute information.
[0129] 4) Information indicating whether the clock information of the audio and video transmitted by broadcast and the clock information of the audio and video transmitted by communication are the same may be included as attribute information.
[0130] It may also be possible to include, as attribute information, information indicating whether the data on the communication side is live content.
[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 the data whose playback time is the time (or its estimated value) obtained by adding the total time (ΔT) required from the content acquisition request until reception starts and the time for buffering the data to the current time (T2), the broadcast-side data can be played back without delay. At this time, the communication-side data is played back from time T2. On the other hand, when the content to be transmitted is live content, it may be possible to buffer the broadcast-side data by ΔT and start playing back both the broadcast and communication data at time T2.
[0132] Note that when the communication side multicasts or broadcasts the content by RTP or the like, data after the current time cannot be acquired regardless of whether the content is live content. Therefore, information indicating whether the communication-side data is multicast or broadcast may also be included in the attribute information.
[0133] [Receiving device] Next, an example of the configuration of a receiving device will be described when the broadcast is transmitted using TS and the communication is transmitted using DASH, RTP (Real-time Transport Protocol), or the like.
[0134] FIG. 8 is a block diagram showing an example of the configuration of a receiving device in Modification 1 of Embodiment 1. FIG. 8 shows an example of the configuration of a receiving device that realizes the receiving method described in FIG. 7B.
[0135] The receiving apparatus 300 shown in FIG. 8 includes an identification information acquisition unit 301, a determination unit 302, a communication sharing determination unit 303, a Loc information acquisition unit 304, a broadcast receiving unit 305, and a communication receiving unit 306. Note that the configuration of the receiving apparatus that implements the receiving method for implementing FIG. 7A corresponds to the case where the Loc information acquisition unit 304 is not provided in FIG. 8.
[0136] The identification information acquisition unit 301 has a function for implementing step S301 shown in FIG. 7B. Specifically, the identification information acquisition unit 301 acquires service information transmitted on the transmission path serving as the entry point, and acquires the transmission path identification descriptor (auxiliary information) included therein. Then, the identification information acquisition unit 301 interprets the information of the transmission path identification descriptor.
[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 reproduction capability of the terminal or whether the communication path is available.
[0138] The communication sharing determination unit 303 has a function for implementing step S303 shown in FIG. 7B, and determines (judges) whether to receive data transmitted by communication.
[0139] The Loc information acquisition unit 304 has a function for implementing step S304 shown in FIG. 7B, and acquires the location data of the communication-side data.
[0140] (Modification 2) In this modification, an example of a receiving method in the case where attribute information or location information is stored in and transmitted with broadcast program information will be described.
[0141] [Receiving Method] FIG. 9 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service according to Modification 2 of Embodiment 1. FIG. 9 shows an example of the operation until the receiving apparatus determines whether to synchronously reproduce broadcast content and communication content when attribute information or location information is stored in and transmitted with broadcast program information and then performs reproduction.
[0142] Note that the operation in FIG. 9 is based on the operation in FIG. 7A, and is described as an example when the transmitted data is not an MMT asset but more general content.
[0143] First, obtain the program information transmitted on the transmission path serving as the entry point, obtain the transmission path identifier descriptor included therein, and obtain the attribute information of the content and the location information of the communication content (step S401).
[0144] Here, when the entity of the location information is not stored in the program information, obtain the entity data of the location information by the same method as described in FIG. 7B.
[0145] Next, determine the data to be received based on the playback ability of the receiving device or whether the communication path is available (step S402).
[0146] Next, determine whether to obtain communication content (step S403). If it is determined to obtain communication content (yes in S403), proceed to step S404 and receive data from both the broadcast and communication transmission paths. Note that if it is determined (judged) not to receive (no in S403), proceed to step S409, receive data only from the broadcast, and play back only the broadcast content in step S410.
[0147] Next, determine whether to synchronously play back the broadcast content and the communication content (step S405).
[0148] If it is determined to synchronously play back (yes in S405), synchronize the reference clocks of the broadcast content and the communication content in step S406, and synchronously play back both in step S407.
[0149] Note that the synchronization of the reference clock in S406 may be performed prior to S404. This is because, for example, when pre-buffering the received data of the content and then starting playback, when starting decoding and playback after confirming that the data with PTS = T1 in the broadcast content and the data with PTS = T1 in the communication content (assuming that their PTSs are already synchronized) have been received, it is necessary for the reference clocks of both to be synchronized when determining whether the data to be synchronously played back is complete.
[0150] Also, in the synchronization of the reference clock in S406, it can be aligned with the reference clock used in either broadcast or communication. For example, when PCR (Program Clock Reference) is used in broadcast and NTP (Network Time Protocol) is used in communication, the DTS and PTS based on the NTP reference in video and audio can be converted to the PCR reference to synchronize the reference clocks in broadcast and communication. Also, the DTS and PTS of broadcast and communication may be converted to synchronize with the unique clock used within the receiving device.
[0151] Also, when the attribute information includes information indicating whether the reference clock information of multiple components is the same, and the receiving side can obtain that the reference clock information is different based on the attribute information, the above method may be used to synchronize the reference clocks in broadcast and communication.
[0152] Note that in FIG. 9, the operations when the attribute information and the location information are stored in the broadcast program information and transmitted have been described. However, if synchronous playback is not necessary in the first place, the transmission path identification descriptor describing these information may not be stored in the broadcast program information.
[0153] Also, in this modification example, although it has been described that synchronous playback is performed when attribute information and location information are stored in the program information of the broadcast, it is not limited to this. When the program information includes a transmission path identifier descriptor, the receiving device may perform synchronous playback of the stream in which the location information is described in the transmission path identifier descriptor and the broadcast stream. At this time, the transmission path identifier descriptor may not include the attribute information indicating whether the streams transmitted by broadcast and communication are synchronously played back with each other.
[0154] In other words, the receiving method in this modification example may include a receiving step of receiving the content transmitted using each of the broadcast wave and the communication path, and a playback step of performing the synchronization process and playing back the content when receiving the auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path.
[0155] [Receiving device] FIG. 10 is a block diagram showing an example of the configuration of the receiving device in Modification Example 2 of Embodiment 1. FIG. 10 shows an example of the configuration of the receiving device that realizes the receiving method described in FIG. 9.
[0156] The receiving device 400 shown in FIG. 10 includes an identification information acquisition unit 401, a determination unit 402, a communication combined 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 receiving unit 406 are the same as the identification information acquisition unit 301 to the communication receiving unit 306 described in FIG. 8, so the description thereof will be omitted.
[0158] The synchronization determination unit 407 has a function of performing the process of step S405 shown in FIG. 9.
[0159] The playback unit 408 decodes and plays back broadcast content or communication content based on the playback method determined according to the determination results in the communication sharing determination unit 403 and the synchronization determination unit 407 means.
[0160] (Modification Example 3) Hereinafter, examples different from those described above will be described as other examples.
[0161] [Other 1] The transmission path is not limited to a combination of broadcast and communication, and may be a combination of the same type of transmission paths such as broadcast and broadcast, communication and communication.
[0162] Also, when information in units of packages such as a transmission path descriptor is not shown, by interpreting the location information for each asset as shown in FIGS. 1A and 1B, it is possible to determine whether each asset is transmitted by broadcast or communication, or whether there is an asset transmitted by communication within the package.
[0163] (Location Information) The location information may include URL information of the acquisition destination of the asset, etc. When the acquisition destination is a URL, it is possible to determine whether the asset is transmitted by broadcast or communication based on whether the URL is a specific URL defined in advance in the broadcast service.
[0164] For example, when a broadcast asset is transmitted in the same stream as message information such as MPT, in the location information, as the acquisition destination of the broadcast asset, the ID of the packet storing the asset data (packet_id in the case of an MMT packet) is shown, and for an asset transmitted by communication, a URL is shown as the acquisition destination. Therefore, in the location information, it is also possible to determine whether the asset is transmitted by communication according to whether the acquisition destination is a URL.
[0165] (Modification Example of MPT Description) In FIGS. 1A and 1B above, as information for each asset, the case where location information for each asset and individual transmission path identification descriptors are defined has been described, but it is not limited thereto. A field indicating the encoding method of the asset may be provided separately. The encoding method is essential information at the time of decoding, and it is desirable to signal in information that can be obtained prior to decoding, such as in MPT. For example, it is possible to use information such as stream_type in the MPEG-2 system.
[0166] Also, in the case of an encoding method that enables scalable encoding, in addition to the encoding method, it may also be indicated whether the asset is a base layer or an enhancement layer.
[0167] Also, there are cases where multiple assets with scalability are included, such as when there are two videos with temporal scalability in the same MMT package. At this time, information indicating which base layer asset the enhancement layer asset corresponds to may be shown. For example, for an enhancement layer asset, the asset ID of the corresponding base layer asset may be shown. Also, the assets of the enhancement layer and the base layer may be grouped, and a group ID may be assigned to each asset.
[0168] These pieces of information can be shown in program information in broadcasting, etc., even when broadcasting uses TS and communication uses DASH, RTP, etc. For example, in a descriptor of PMT, etc., the dependency relationship between the video stream transmitted in broadcasting and the video stream transmitted in communication (such as the video stream on the communication side corresponding to the enhancement layer), or information indicating the encoding method of the video or audio on the communication side can be described. Also, it may be shown whether the streams on the broadcasting side and the communication side are synchronously reproduced or not.
[0169] (Information regarding the transmission path) Information indicating whether the content data is transmitted only by broadcast or transmitted using both broadcast and communication may be stored in program information such as an EPG.
[0170] For example, when performing viewing selection or recording reservation from an EPG, if the data transmitted by communication cannot be played or recorded, such as when not connected to a communication network or the receiving device does not support data acquisition by communication, message information indicating this may be displayed.
[0171] Furthermore, information indicating whether the data transmitted by communication can be acquired prior to the start time of the program may be stored. In particular, in a download type method such as DASH, by downloading the data on the communication side prior to the start of the program, both the broadcast data and the communication data can be started for playback at the start time of the program.
[0172] For example, if the data on the communication side can be acquired prior to the start time of the program, the receiving device may start receiving the data on the communication side before the start time of the program. At this time, the start time of reception is determined so that the predetermined amount of buffered data or the data for the buffering time can be received at the start time of the program.
[0173] Also, for example, it may operate in the same manner for reserved recording of programs.
[0174] In broadcast or the like, a user can select a plurality of programs at an arbitrary timing. Even if the communication data of the next program of the currently viewed channel is received in advance, if the viewing program is switched, there is no benefit in receiving the communication data in advance. Therefore, at an arbitrary viewing time, for all programs that can be viewed after the viewing time and in which data is transmitted using both broadcast and communication, it may operate to buffer the data on the communication side in advance. If the data of all programs cannot be received, programs may be selected and received within the receivable range.
[0175] Also, information indicating whether the data on the broadcast side and the data on the communication side are to be played back synchronously may be included in program information such as the EPG. When synchronous playback is to be performed, the operation may be such that the data on the communication side is buffered in advance. When synchronous playback is not performed, the reception of the data on the communication side may be started after the reception of the data on the broadcast side is started.
[0176] Even when 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] Also, these pieces of information may be stored in control information when demodulating signals transmitted over a transmission path, such as TMCC signals in the broadcast system (ISDB-T) in Japan.
[0178] By doing so, it is possible to determine at the time of demodulation whether reception in communication is necessary, and it is possible to accelerate the startup of the communication side.
[0179] (Format) Note that the HTTP-based file format is not limited to DASH, and may be HTTP Live Streaming (HLS), Microsoft Smooth Streaming (MSS), etc. Even in these systems, since there is content management information corresponding to the MPD, the relationship between the data on the broadcast side and the data on the communication side can be shown by a mechanism similar to that of DASH.
[0180] Also, on the communication side, a TS stream may be used, or a format in which a field indicating a 4-byte timestamp is added to the head of the TS packet may be used. Here, the TS with a timestamp is used in many standards such as BD (Blu-ray (registered trademark) Disc) and the IPTV forum.
[0181] [Other 2] (Attribute Information and Location Information) In the attribute information and location information, the attributes of the entire content and the individual attributes of streams such as audio and video may be stored separately.
[0182] For example, when using DASH on the communication side, the attribute information of the entire content, such as whether the broadcast content and the communication content are synchronously played, or whether the broadcast content is the basic layer of scalability and the communication content is the extended layer, may be stored in a transmission path identification descriptor or the like. On the other hand, information for identifying videos and audios that are to be synchronously played with each other, and other individual attributes for each stream, may be stored in the MPD.
[0183] As an example of the attributes for each stream, when associating the video in the broadcast with the audio of the secondary audio transmitted in the communication, in the MPD, the PID of the TS packet storing the video and the information for identifying the audio track, segment, or Adaptation Set or Representation in the DASH data, such as the audio track ID, may be associated with each other. Here, as the identification information of the media on the broadcast side, in addition to the PID, the ID of the transport stream including the TS packet of the PID, the service ID, and the like may also be included.
[0184] Note that the content of the MPD may be updated, and the update information is managed by the DASH content distribution server. Therefore, by describing particularly the individual attributes of the stream in the MPD, it is possible to achieve both the merit of reducing the information exchange between the broadcast content transmission device and the communication content transmission server, and the merit of being able to quickly start the communication content reception start process by storing the overall attributes in the information obtained at the start of broadcast reception, such as the PMT.
[0185] Also, both the overall attributes and individual attributes may be described either in a descriptor such as a PMT in broadcasting or in the MPD, or in both. For example, in broadcasting, it may be described in a descriptor of application control information such as an AIT.
[0186] (Attribute information) Furthermore, information indicating whether the clock information of streams transmitted over different transmission paths such as broadcasting and communication is synchronized with each other, or a method for synchronization, may be included in the attribute information. 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 synchronization of their clocks is not required.
[0189] Method 2) Synchronize based on clock synchronization information transmitted separately from the stream, such as a descriptor in a PMT.
[0190] Method 3) Synchronize by referring to an independent stream containing information for clock synchronization, such as the time line extension of a TS (13818-1:2013 / AMD6(2nd WD)) currently being standardized in MPEG.
[0191] In Method 3, the PID of the TS packet storing the stream for clock synchronization may be included in the attribute information.
[0192] (Modification Example 4) For example, in FIGS. 6A to 7B, etc., the storage method of location information and the like in the case where broadcasting uses TS and communication uses DASH, RTP, etc. for transmission respectively has been described.
[0193] In this modification example, a specific example will be given to explain the method of storing location information.
[0194] FIG. 11 is a diagram showing an example of the data structure of service information in the broadcast communication cooperation service of Modification Example 4 of Embodiment 1. 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 correspond to the transmission path identification descriptor.
[0195] In this modification example, the descriptor is stored in a PMT, or section data different from the PMT.
[0196] The information indicated by this descriptor includes a transmission format indicating the type of entity data referred to by the location information, the location information, and a field indicating the synchronization information between the PCR in the broadcast and the data on the communication side.
[0197] Note that in this modification example, the location information is assumed to indicate the reference destination of the entity data of the location information. Here, an example where the entity data of the location information is an MPD is shown. As the transmission format, the MPD is shown, and as the synchronization information, the synchronization information between the PCR and the NTP is shown.
[0198] Since MPD is location information used in DASH, it may be appropriate to indicate DASH as the transmission format and the reference destination of MPD as the location. In cases where the transmission format can be identified by the extension in the URL of the location information, etc., the field for the transmission format may not be included. Also, there are two cases for transmitting MPD: within a broadcast and via a communication network. When transmitting within a broadcast, private sections of MPEG-2 TS are used. Therefore, as the location information of MPD, when transmitting within a broadcast, it can indicate the PID of the private section, etc., the identification information of the TS packet storing MPD within the transport stream, and when transmitting via a communication network, it can indicate information such as a URL.
[0199] [Receiving method] Hereinafter, as a receiving method in this modification example, an example of the operation of a receiving device when synchronously reproducing a broadcast and communication content by analyzing a descriptor indicating location information will be described.
[0200] FIG. 12 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 4 of Embodiment 1.
[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 there is an MPD within the broadcast. If it exists within the broadcast (yes in S802), the process proceeds to step S803, and the actual data of MPD is acquired from the TS packet having the PID indicated by the location information. On the other hand, if there is no MPD within the broadcast (no in S802), MPD is acquired from the communication server based on the URL indicated in the location information.
[0203] Next, in step S805, based on the analysis result of the MPD, data to be acquired from the DASH content is determined, and the data is acquired by download (or progressive download, etc.).
[0204] Next, in step S806, based on the synchronization information included in the location information descriptor, or the synchronization information obtained from the TS packet storing the timeline extension information when the timeline extension of MPEG-2 TS is used, the broadcast content and the communication content are synchronously played back.
[0205] Note that when using the timeline extension, the location information descriptor may not include the synchronization information. Also, when it is not necessary to synchronously play back the DASH content and the broadcast content, the synchronization information may not be transmitted. In this case, it may be determined whether synchronous playback of both is necessary based on whether the synchronization information in the location information descriptor or the synchronization information in the data for the timeline extension exists. Whether synchronous playback is necessary may be shown separately.
[0206] Also, when synchronous playback is not necessary, in step S806, based on a user instruction or a control command in the hybrid cast application, etc., the start and end of playback of the DASH content can be determined. Note that in this case, it is assumed that it has been determined in the previous stage of S801 whether to acquire data by communication.
[0207] In FIG. 12, an example of acquiring the MPD and playing back the DASH content has been described, but the same applies to the case of acquiring and playing back data in other formats such as RTP and TS.
[0208] Note that in the timeline extension, an access unit for storing the timeline extension information is defined, and both a descriptor indicating the location information and a descriptor indicating the synchronization information can be stored in the access unit.
[0209] Therefore, without transmitting a location information descriptor, location information and synchronization information may be shown together by timeline extension. In the current timeline extension, since a PID cannot be shown as location information, a field indicating the scheme type of the location information may be extended so that the PID can be signaled.
[0210] Also, the upper limit of the section size of the PMT is restricted to 1021 bytes, and depending on the URL in the location information, it may exceed the upper limit. Although it is also possible to split and store the PMT section, it is particularly desirable that the PMT be stored in one section.
[0211] Therefore, when the section size of the PMT exceeds 1021 bytes, the location information descriptor may be transmitted by a section different from the PMT. When the location information indicates a PID, it can be contained within the size upper limit of the PMT and can be included in the PMT. Therefore, the section for storing the location information may be switched based on whether the location information is a PID or a URL.
[0212] (Modification Example 5) In Modification Example 4, it was stated that location information can also be shown in the TEMI (Timeline and Extend Media Information stream) access unit in the timeline extension.
[0213] Specifically, the URL of the content on the communication side can be described using the temi_location_descriptor. In the temi_location_descriptor, the URLs of multiple contents can be described, and there are no data size restrictions such as the section size of the PMT, so flexible operation regarding the description of the URL becomes possible.
[0214] On the other hand, in the case where the PID of the TS packet in the transport stream is used as the location information, etc., the data size of the location information is also small, and by referring to the location information descriptor and acquiring the location information when analyzing the PMT, the delay time associated with the acquisition can be reduced. Therefore, as the storage location of the location information, it is desirable that the location information descriptor and the temi_location_descriptor in the TEMI access unit can be used in combination.
[0215] Hereinafter, an example of the syntax (data structure) of the location information descriptor in this modification example will be described.
[0216] FIG. 13A is a diagram showing an example of the syntax of the location information descriptor in Modification Example 4 of Embodiment 1. FIG. 13A shows an example of the syntax of the location information descriptor for storing the location information in either the location information descriptor or the TEMI access unit.
[0217] In this modification example, it is described that the synchronization information with the PCR is described using the temi_timeline_descriptor of the TEMI access unit and is not included in the location information descriptor. The semantics for each field shown in FIG. 13A will be described.
[0218] "data_format" is the same as the transmission format shown in FIG. 11. That is, it indicates the format of the meta-information of the playback control used in the service, such as the MPD in DASH, the playback control meta-file in the VOD (Video On Demand) specification of the IPTV Forum, or the TTS (Time-stamp TS) defined in the IPTV Forum, etc. It may indicate the identification information of the stream itself, such as TTS, MP4 file, or the AV encoded data itself, rather than meta-information. It may indicate the MPT, PA message, MMT packet, asset, etc. in MMT.
[0219] For example, temporal scalability can be achieved in a video coding method such as H.265. Here, assume that a basic layer at 60 fps is transmitted in broadcasting, and encoded data of an extended layer for improving the frame rate from 60 fps to 120 fps is transmitted in communication. In this case, as the location information of the communication content, only the URL of the encoded stream of the extended layer needs to be indicated. Information such as the resolution and coding method in the encoded stream can be obtained from the broadcast data transmitting the basic layer.
[0220] "location_type" is for identifying whether the location information is indicated by the PID of the TS in broadcasting or the URL in communication. Here, it is assumed that when location_type = 0, it indicates the PID of the TS in broadcasting. Note that the location information descriptor can be used not only for TS but also in other cases such as MPEG's MMT (MPEG Media Transport). In formats other than TS, "location_type" may not be used. For example, other information for identifying the location such as the packet_id of the MMT packet in MMT may be used.
[0221] "PID" indicates the PID of the TS packet. When the broadcast is composed of multiple transport streams, the identification number of the transport stream etc. may be stored together.
[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 modified example, it is assumed that when url_location = 0, it is stored in the location information descriptor. When url_location is 1, the URL of the communication content is stored in the temi_location_descriptor in the TEMI access unit.
[0223] 「url_length」indicates the byte length of 「url_path」. 「url_path」 indicates the data of the URL.
[0224] FIG. 13B is a diagram showing an example of the syntax of the location information descriptor in Modification Example 4 of Embodiment 1. FIG. 13B shows an example different from the syntax of the location information descriptor shown in FIG. 13A. The difference from the syntax shown in FIG. 13A is that when storing location information in the TEMI access unit, the data_format field does not exist.
[0225] Here, Temi_location_descriptor can indicate the service type of TEMI in a field called service_type. This service type corresponds to data_format. Therefore, the information of data_format shall be indicated in the service_type field.
[0226] Note that in the syntax shown in FIG. 13A, both the data_format field and the service_type of temi_location_descriptor may exist. In this case, both shall indicate the same information.
[0227] In 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, as the transmission format, the data_format of the location information descriptor may be referred to, and the service_type of 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 Example 4 of Embodiment 1. FIG. 13C shows an example different from the syntax of the location information descriptor shown in FIGS. 13A and 13B.
[0229] The difference from FIG. 13A is that the conditional branch of url_location is performed first. That is, when the location information is in the location information descriptor with url_location = 0, the PID of the broadcast TS or the communication URL is stored according to the location_type. On the other hand, when url_location = 1, the location_type is not described in the location information descriptor, but in the temi_location_descriptor in the TEMI access unit, the location_type is indicated in the service_type field, and the PID of the TS in the broadcast or the communication URL is stored in the temi_location_descriptor.
[0230] FIG. 13D is a diagram showing an example of the syntax of a location information descriptor in Modification Example 4 of Embodiment 1. FIG. 13D shows an example 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 communication URL. Also, when location_type = 2, it indicates that the PID of the TS in the broadcast or the communication URL is stored in the temi_location_descriptor in the TEMI access unit.
[0232] Note that the data and data structure of the syntax of the location information descriptor are not limited to the above examples. For example, it may be used in combination with other data, such as by integrating the location type and the format type. Also, for example, in cases where the transmission format can be identified by an extension in the URL of the location information, etc., the field for the transmission format may not be included. Further, for example, if there is no location information descriptor, the location information may be indicated by temi_location_descriptor, and the field of url_location may be omitted.
[0233] (Modification Example 6) Hereinafter, an example different from the location information described in Modification Example 5 will be described.
[0234] (Other Examples of Location Information) For example, when there are two or more types of multiple timelines in the same program, there may be a plurality of TEMI streams for each type of timeline.
[0235] In this case, a plurality of location information may be stored in the location information descriptor. When storing a plurality of location information, a loop of the number of TEMI streams is created in the location information descriptor, and the location information corresponding to each TEMI stream is stored. Also, as a method of indicating the correspondence between the plurality of location information loops and the plurality of TEMI streams in the location information descriptor, for example, the order of the location information loop and the order of the ES loop (PMT second loop) indicating the TEMI stream may be in correspondence. Also, when there are two or more types of timelines, the location information may not be stored in the location information descriptor, but may be stored in temi_location_descriptor of the TEMI access unit, or the location information descriptor may be stored in the ES loop (PMT second loop).
[0236] (Update of Location Information) It is desirable that the system can also handle updates to the content of location information such as meta information.
[0237] For example, when adding a reload flag to the location information descriptor in the PMT and updating the content of the location information, set reload = 1. When the receiving device detects reload = 1, it may re-acquire the PID, URL, etc. stored in the location information on the assumption that the content of the location information has been updated. If only the data has been updated and the location information such as PID and URL has not been updated, only the data may be re-acquired.
[0238] Also, information indicating whether the location information itself or the content of data such as MPD whose acquisition destination is indicated by the location information has been updated may be shown independently.
[0239] Also, the location information descriptors in the PMT that are periodically transmitted may be sequentially checked. However, since this sequential check process is heavy, a section data for storing the location information descriptors, an event section for notifying updates, etc. may be separately generated and transmitted periodically.
[0240] In the receiving device, by checking the version number in the section, it can be determined whether the location information has been updated. Also, when transmitting the location information in a broadcast section, the update of the meta information is indicated by updating the version number of the location information section.
[0241] Also, after starting to acquire communication-side data based on the location information obtained from the broadcast, the receiving device may acquire the updated content of the location information in the communication.
[0242] [Receiving Method] Next, as a receiving method in this modification example, an example of the operation of a receiving apparatus when synchronously reproducing broadcast and communication content by analyzing a descriptor indicating location information will be described.
[0243] FIG. 14 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 6 of Embodiment 1.
[0244] Step S804 in FIG. 12 is changed to steps S906, S907, and S908 in FIG. 14. Since the other operations (steps S901 to S905) are the same as the operations in FIG. 12 (steps S801 to S803, step S805, and step S806), the description thereof will be omitted.
[0245] In step S906, it is determined whether the acquisition destination URL such as MPD is stored in the location information descriptor or the TEMI access unit. If it is in the location information descriptor (yes in S906), the process proceeds to step S907, the location information descriptor is analyzed, and the MPD is acquired from the communication server based on the URL indicated in the location information. On the other hand, in step S906, if it is determined that it is stored in the TEMI access unit (no in S906), the MPD is acquired from the communication server based on the URL indicated in the temi_location_descriptor in the TEMI access unit.
[0246] Note that in FIG. 14, an example in the case where MPD is shown as format information is shown, but even with other meta information, the broadcast content and the communication content can be synchronously reproduced by the same flow of operations.
[0247] FIG. 15 is a flowchart showing another example of the operation on the receiving side in the broadcast communication cooperation service according to Modification Example 6 of Embodiment 1. In FIG. 15, the operation when the format information is other meta information than MPD is shown. More specifically, when the format information shows the format of entity data such as a stream instead of meta information such as MPD, the operation when obtaining the URL of the entity data of the stream instead of the URL of the meta information in step S907 or step S908 shown in FIG. 14 is shown.
[0248] First, in step S1001, the receiving device analyzes the location information descriptor.
[0249] Next, it is determined whether the data indicated by the format exists in the broadcast (step S1002). If the data exists in the broadcast (yes in S1002), the process proceeds to step S1003, and the PID indicated by the location information is acquired. Here, since it is not assumed that entity data such as a stream is included in the broadcast, if the data exists in the broadcast, it is determined that the format is metadata.
[0250] Next, a meta information file is acquired from the broadcast stream based on the PID (step S1004), and the communication data to be acquired is determined (step S1005).
[0251] On the other hand, if there is data in the communication in step S1002 (no in S1002), the process proceeds to step S1008, and it is determined whether the URL of the communication data exists in the location information descriptor or in the temi_location_descriptor of the TEMI access unit. Then, depending on each case, the URL is acquired in step S1009 or step S1010.
[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 meta information is obtained from the communication stream based on the URL, and then the process proceeds to step S1005 to determine the communication data to be obtained.
[0253] After the communication data to be obtained is determined in step Sp1005, or when it is determined in step S1011 that the format is not meta information, the process proceeds to step S1006 to obtain the communication data.
[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 time line extension of MPEG-2 TS.
[0255] (Modification Example 7) So far, it has been described that it is determined whether the broadcast content and the communication content are synchronously played back, and when they are synchronously played back, the acquisition and synchronous playback of the broadcast content and the communication content are performed, but it is not limited to this.
[0256] In this modification example, information indicating whether the reference clock information of the audio or video transmitted by broadcast and the reference clock information of the audio or video transmitted by communication are the same is included in the service information (such as a transmission identification descriptor), and the operation based on this information will be described.
[0257] [Information on whether the reference clocks (time lines) of broadcast and communication are synchronized] When transmitting content using broadcast and communication using MMT, DASH, RTP, or hybrid cast, etc., information indicating whether the reference clock information of the audio or video transmitted by broadcast and the reference clock information of the audio or video transmitted by communication are the same may be stored in a transmission identification descriptor, program information, EPG, EIT, etc.
[0258] For example, when the content transmitted by broadcast and communication operates based on a common reference clock (e.g., time stamping), information indicating that it operates based on the common reference clock is stored. Also, when the content transmitted by broadcast and communication operates based on different reference clocks, information indicating that it operates based on different reference clocks is stored.
[0259] Also, only when it is indicated that different reference clock information is used in broadcast and communication, it may be indicated as information necessary for reference clock synchronization (e.g., timeline extension information). Also, the storage location of the information necessary for reference clock synchronization, the type of the information necessary for reference clock synchronization, the method of reference clock synchronization, etc. may be indicated.
[0260] Here, in the synchronization of the reference clock, it is possible to align with the reference clock used in either broadcast or communication.
[0261] For example, when PCR (Program Clock Reference) is used in broadcast and NTP (Network Time Protocol) is used in communication, the types and methods of reference clock synchronization may be shown such that the DTS and PTS based on the NTP reference in video and audio can be converted to the PCR reference to synchronize the reference clocks in broadcast and communication. Also, the types and methods of reference clock synchronization may be shown such that the DTS and PTS of broadcast and communication are converted to synchronize with the unique clock used in the receiving device.
[0262] Note that the identification information indicating the type and method of the information necessary for reference clock synchronization may be analyzed, and reference clock synchronization may be performed by a method based on the identification information.
[0263] Also, when there are multiple streams with different reference clocks, information indicating that there are multiple reference clocks with different reference clocks may be stored in the descriptor. The descriptor may be shown for each different reference clock, or may be shown with a single descriptor. Information indicating the correspondence between the reference clock and the program using the reference clock may be stored.
[0264] As information indicating whether the reference clocks are the same, it may be shown as the above-described descriptor, or other descriptors, tables, sections, etc. may be used. Also, it may be indicated depending on whether there is information necessary for clock synchronization (for example, timeline extension information, etc.). If there is information necessary for clock synchronization, the clock information may be considered different. Alternatively, using the attribute information of the communication content (for example, information regarding format or type, or the extension described in the location information or URL) shown in the transmission identification descriptor, etc., it may be indicated that the clock information is different. In the case of hybrid broadcast, it may be stored in the AIT control section or in the application.
[0265] When the receiving device determines that it is using different clock information, it synchronizes the reference clock information of the broadcast and the communication. Also, when it determines that it is using common clock information, it determines that clock synchronization is unnecessary. The receiving device receives, for example, auxiliary information including difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path, and when the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path are different, the reference clock of the content by the communication path may be synchronized to the reference clock of the content by the broadcast wave based on the difference information.
[0266] Note that, in addition to the identification result of whether the reference clock information of the data stored in the transmission identification descriptor or the like is the same, the receiving device takes into account all of the user's selection, user settings, the intentions of the content provider, service provider, or broadcasting station, or the specifications or intentions of the receiving device manufacturer through the user interface or the like, and may determine whether to actually synchronize the reference clocks of the broadcast content and the communication content.
[0267] Also, when the receiving device determines to perform reference clock synchronization, as the timing for actually performing clock synchronization, it may start synchronization after the determination, or may start when it acquires information regarding synchronization without making the determination. Alternatively, it may synchronize in accordance with the time to start acquiring the communication content (for example, a certain time before starting to acquire the content, or the same time as the start of acquisition).
[0268] Also, when the clock reproduction of the reference clock serving as the reference source (for example, the PCR of the broadcast) is not completed (the clock cannot be used in a state where the influence of jitter or the like is smoothed), the clock synchronization with the destination may be started when the clock reproduction of the reference clock information of the reference source is completed.
[0269] When information indicating whether the reference clocks of the broadcast and the communication are synchronized is shown by the EPG, similar to the pre-buffering of the communication content, it may be determined whether reference clock synchronization is necessary before the start of the broadcast and the reference clock synchronization may be started. In this way, by performing reference clock synchronization earlier, the service can be provided to the viewer earlier.
[0270] Note that the information indicating whether the reference clocks are the same is not limited to the combination of the broadcast and the communication, and is applicable when transmitted through the same path or when different reference clock information is used in data acquired from a plurality of paths such as broadcast, communication, and storage formats.
[0271] Note that some or all of the functions and processes described in this modified example may be implemented in hardware or software, or a part of them can be implemented as hardware or software.
[0272] For example, when implemented in software, functions such as instructing the functions and processes described in this modified example, notifying the state of the receiving function by PUSH, and obtaining it by PULL may be packaged and provided as API functions.
[0273] API functions can be executed from an application. When implemented as an application, it may be implemented as a resident application, or an application such as HTML5 may also be used. The above API may be implemented for data transfer and state notification between applications.
[0274] Here, as functions of API functions related to information on whether the reference clocks are synchronized, there are, for example, the following 1) to 9).
[0275] 1) Obtain information on whether the reference clock information of broadcast content and communication content is the same. 2) Obtain information on whether reference clock synchronization is necessary. 3) Obtain the type and synchronization method of each reference clock information. 4) Obtain information (such as timeline information) necessary for clock synchronization. 5) Obtain the acquisition destination of information necessary for clock synchronization. 6) Take the reference clock information of the source as an argument and return the synchronized reference destination clock information. For example, if not synchronized, return a value indicating that it is not synchronized. 7) Instruct the start of synchronization of each other's reference clocks. 8) Obtain the state of whether the reference clock synchronization is achieved. 9) Notify that the reference clock synchronization is achieved.
[0276] [Receiving method] Next, using the figures, as a receiving method in this modification example, when attribute information and location information are stored in the program information of a broadcast, an example of the operation when a receiving device determines whether to synchronously play a broadcast content and a communication content and then operates will be described.
[0277] FIG. 16 is a flowchart showing an example of the operation on the receiving side in the broadcast communication cooperation service of Modification Example 7 of Embodiment 1. Note that the operations of the flowchart shown in FIG. 16 are applicable to any broadcast communication cooperation service using a combination of multiplexing methods such as MMT, DASH, and RTP. Also, it is applicable to hybrid cast.
[0278] In FIG. 16, it is assumed that the broadcast content and the communication content are synchronized, and the determination of whether to synchronize the broadcast content and the communication content is omitted.
[0279] Also, since steps S1101 and S1102 are the same operations as steps S401 and S402 in FIG. 9, the description thereof is omitted.
[0280] Next, in step S1103, the receiving device determines whether to acquire the communication content. If it is determined to acquire the communication content (yes in S1103), the process proceeds to step S1104, where data is received from both the broadcast and communication transmission paths. Subsequently, in step S1105, it is determined 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 to synchronize the reference clocks of the broadcast content and the communication content, and in step S1107, both are synchronously played.
[0282] On the other hand, if it is determined in step S1105 that the reference clocks are the same (no in S1105), synchronous playback is performed using a common clock without synchronizing the reference clocks.
[0283] Note that after step S1105, a process of determining whether synchronization of the reference clock is necessary may be performed. For example, depending on the type and method of clock synchronization, it is determined whether the capabilities of the receiving device support clock synchronization, whether to perform clock synchronization as a specification of the receiver, or whether the user performs clock synchronization. Then, based on step S1105 and the above determination result, it may be determined whether to comprehensively synchronize the reference clock in broadcasting and communication, and proceed to step S1106 or step S1107.
[0284] Also, the synchronization of the reference clock in step S1106 may be performed prior to step S1104. This is because, for example, in the case of buffering received data of content before starting playback, it is necessary to confirm that data with PTS = T1 in broadcast content and data with PTS = T1 in communication content (where it is assumed that their PTSs are already synchronized) have been received and then start decoding and playback. And when determining whether the data to be synchronously played back is complete, it is necessary that the reference clocks of both are already synchronized.
[0285] Also, in step S1106, if clock synchronization information cannot be obtained or clock synchronization cannot be performed due to the specifications of the receiver, there may be a case where a service that combines broadcasting and communication cannot be provided to the user. In that case, it may be determined whether to receive the data transmitted by the communication in step S1103 by making determinations such as whether synchronization is essential and whether to play back without synchronization.
[0286] Note that in step S1103, in addition to the information that can be identified by the transmission path descriptor, all of the user's selections and settings, the intentions of the content provider, service provider, and broadcasting station, or the specifications and capabilities of the receiving device and the intentions of the manufacturer, etc. may be considered to determine whether to actually receive the data transmitted by communication.
[0287] [Receiving device] Next, an example of the configuration of a receiving device that realizes the operation shown in FIG. 16 will be described. FIG. 17 is a block diagram showing an example of the configuration of a receiving device in Modification 7 of Embodiment 1.
[0288] The receiving device 1100 shown in FIG. 17 includes an identification information acquisition unit 1101, a determination unit 1102, a communication combined use determination unit 1103, a Loc information acquisition unit 1104, a broadcast reception unit 1105, a communication reception unit 1106, a reference clock determination unit 1107, and a 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, so the description thereof will be omitted.
[0290] The reference clock determination unit 1107 has a function of performing the process of step S1105 shown in FIG. 16. Further, the reference clock determination unit 1107 may perform a process of determining whether the reference clocks are different and further determining whether synchronization of the reference clocks as described above is necessary.
[0291] The reproduction unit 1108, based on the method determined according to the determination result in the reference clock determination unit 1107, when the reference clocks are different, synchronizes the reference clocks and then decrypts and reproduces the broadcast content or the communication content.
[0292] Note that the functions, the configuration of the receiving device, and the receiving method described in this modification are merely examples and are not limited thereto, and any configuration that can achieve similar functions and effects may be used.
[0293] [Effects of Embodiment 1, etc.] As described above, according to the present embodiment, it is possible to realize a content transmission method, a content reception method, a transmission device, and a receiving device that can reproduce content that combines broadcast and communication on the receiving side even when the reception start timing of content by communication is delayed.
[0294] Specifically, a transmission method in one aspect of the present embodiment is a content transmission method capable of transmitting content using a broadcast wave and a communication channel. When transmitting content using each of the broadcast wave and the communication channel, it includes an information transmission step of transmitting, at least using the broadcast wave, auxiliary information for synchronizing the content by the broadcast wave and the content by the communication channel, which causes the receiving side to perform the synchronization when the receiving side receives it.
[0295] Accordingly, when transmitting content using a broadcast wave and a communication channel, auxiliary information for synchronizing the content transmitted using the broadcast wave and the communication channel is transmitted. Thus, when the receiving side receives the auxiliary information, the receiving side can be made to synchronize the content.
[0296] Here, for example, in the information transmission step, the auxiliary information is transmitted prior to transmitting the content, and the auxiliary information may further include location information indicating the acquisition destination of the content or information indicating the acquisition destination of the location information.
[0297] Also, for example, in the auxiliary information transmission step, the auxiliary information may further include difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication channel.
[0298] Also, for example, in the auxiliary information transmission step, by transmitting the auxiliary information, when the reference clocks of the content are different, the receiving side may be made to perform the synchronization by synchronizing the reference clock of the content by the communication channel with the reference clock of the content by the broadcast wave based on the difference information.
[0299] Further, for example, in the transmission method, the method may include a generation step of generating the content in a format according to MMT (MPEG Media Transport), and a content transmission step of transmitting the content in the format generated in the generation step.
[0300] Further, for example, in the generation step, the auxiliary information may be generated by including it in message information which is information related to the acquisition of the content.
[0301] Further, a reception method according to an aspect of the present embodiment includes a reception step of receiving content transmitted using each of a broadcast wave and a communication path, and when receiving auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path, performing a process of taking the synchronization and a reproduction step of reproducing the content.
[0302] Thereby, for example, when acquiring service information transmitted in a transmission path serving as an entry point such as a broadcast wave and the auxiliary information is included therein, a process of taking synchronization can be performed.
[0303] Here, for example, in the reception step, if the auxiliary information is received prior to receiving the content and the auxiliary information includes location information indicating the acquisition destination of the content, the content may be received by acquiring the content based on the location information.
[0304] Further, for example, in the reception step, if the auxiliary information is received prior to receiving the content and the auxiliary information includes information indicating the acquisition destination of location information indicating the acquisition destination of the content, the location information may be acquired based on the information indicating the acquisition destination of the location information, and the content may be received by acquiring the content from the acquired location information.
[0305] Also, for example, in the playback step, in the reception step, the auxiliary information including the difference information between the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path is received, and when the reference clock of the content by the broadcast wave and the reference clock of the content by the communication path are different, a process of synchronizing the reference clock of the content by the communication path with the reference clock of the content by the broadcast wave based on the difference information is performed to synchronize the content, and the content may be played back.
[0306] Also, a transmission device in one aspect of the present embodiment is a content transmission device capable of transmitting content using a broadcast wave and a communication path. When transmitting content using each of the broadcast wave and the communication path, it includes an information transmission unit that transmits at least the broadcast wave with auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path, which causes the receiving side to perform the synchronization when received.
[0307] Also, a receiving device in one aspect of the present embodiment includes a receiving unit that receives content transmitted using each of a broadcast wave and a communication path, and a playback unit that, when receiving auxiliary information for synchronizing the content by the broadcast wave and the content by the communication path, performs the synchronization process and plays back the content.
[0308] Also, as described above, according to the present embodiment, identification information indicating whether content including audio and video is transmitted using both communication in addition to broadcasting, and when using both broadcasting and communication, information indicating the dependency relationship between the data transmitted on both transmission paths, etc., may be generated and transmitted as content management information. Here, for example, the information indicating the dependency relationship between the data may include whether the data transmitted on both transmission paths are synchronously played back. Also, the information indicating the dependency relationship between the data may include whether the clock information of the data transmitted on both transmission paths is the same.
[0309] As a result, the transmission path through which content including audio and video is transmitted, and the dependency between data transmitted over different transmission paths can be obtained at the start of content reception, so that the determination of the assets to be received and the delay time related to the start of acquisition of communication content can be reduced.
[0310] Further, according to the present embodiment, location information of data transmitted in communication may be included in the content management information. Here, the location information of the data to be transmitted may be, for example, an MPD in MPEG-DASH. Further, the content management information may store information indicating the acquisition destination of the location information instead of the actual data of the location information such as an MPD.
[0311] As a result, the transmission path through which content including audio and video is transmitted, and the dependency between data transmitted over different transmission paths can be obtained at the start of content reception, so that the determination of the assets to be received and the delay time related to the start of acquisition of communication content can be reduced.
[0312] Further, according to the present embodiment, in the receiving apparatus, the content management information may be analyzed to determine the transmission path through which the content is received and the data to be received on each transmission path. For example, when the clock information of the data transmitted on both transmission paths is different, auxiliary information necessary for clock synchronization between the data may be acquired, and the DTS and PTS in each data may be synchronized, decoded, and played back. Further, when synchronously playing back the data transmitted on both transmission paths, auxiliary information necessary for clock synchronization between the data may be acquired, and the DTS and PTS in each data may be synchronized, decoded, and played back.
[0313] As a result, in a receiving apparatus that receives only broadcast data, it is possible to play back the broadcast data by the same operation as conventional broadcast reception and also support the playback of communication data.
[0314] Furthermore, a mechanism for synchronizing and playing back the data of broadcasting and communication can be provided for the receiving device.
[0315] Furthermore, even when the clocks of the data transmitted on a plurality of transmission paths are not synchronized, clock synchronization can be achieved by acquiring the auxiliary information necessary for clock synchronization, and the data can be played back synchronously.
[0316] (Embodiment 2) In Embodiment 1, it was described about whether the stream transmitted by broadcasting and the stream transmitted by communication are the targets of synchronous playback, or the transmission method when transmitting information indicating the dependency relationship between the streams transmitted by both transmission paths, and the receiving method for receiving such information.
[0317] Here, in order to realize flexible content playback involving user operations in the receiving device, such as when the user selects a playback target from selectable audio and video, or switches from the full-screen display of a single view to a multi-view in video, it is desirable to perform playback control in the application.
[0318] As an application, those based on the widely spread HTML (Hyper Text Markup Language) browser are mainstream. When the application is HTML, playback control can be performed by interpreting HTML. If it is HTML, there is also the merit that content selection, switching, or layout change can be described flexibly.
[0319] For example, in the hybrid cast defined in the IPTV Forum, in data that is always referenced at the start of receiving a broadcast program, such as the descriptor of PMT in TS or the descriptor of MPT in MMT, identification information indicating the existence of an application such as ait_identifier_info() is transmitted. In a receiving device compatible with the hybrid cast, when such identification information exists, application control information such as AIT is obtained from a section or data carousel in TS, information corresponding to an MMT message or data carousel in MMT, or downloaded via a communication network. Then, based on the application control information, an application such as an HTML file is obtained.
[0320] Hereafter, application control information and data of the application itself are referred to as application-related data. For the description of an application, a description language other than HTML such as XML may be used.
[0321] [Transmission Method of Default Service Information] However, there are receivers that do not support the application, or even if they support the application, there is a time lag from the start of channel selection in broadcasting or communication until the application is acquired and started.
[0322] Therefore, for the default setting information of the stream to be played and the display layout, instead of application-related data, it may be transmitted in data that is always acquired at the time of channel selection, such as PMT or MPT, or in data that can be acquired with lower latency than the time required until the application is started, such as other sections of TS or messages of MMT. And information for performing advanced playback control may be transmitted as application data such as HTML.
[0323] For example, information related to the playback control of a stream transmitted in broadcasting or communication includes: (a) information related to scalability between streams, (b) information related to stream switching such as multilingual audio and videos with different bitrates, (c) information related to simultaneous display such as information indicating multiple video streams that can be displayed simultaneously, and information related to the layout in the case of simultaneous display. If the default values of this information are called default playback control information.
[0324] In a receiving device that does not support the application, playback is performed based on the default value. On the other hand, a receiving device that supports the application starts playback based on the default value, and after the application is launched, the playback operation may be switched based on user operations or control commands of the application.
[0325] The application may switch the playback operation only for information that can be switched by user operations. For example, regarding simultaneous display, basically, switching by the user is possible, but regarding time scalability, if the stream of the extended layer can be acquired, the receiver may automatically determine the playback operation assuming that the extended layer is always used. In this case, information related to time scalability is transmitted only in the default playback control information.
[0326] Here, 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. At this time, only the information for associating the streams of the basic layer and the extended layer is transmitted by the default playback control information or by a descriptor defined in MPEG-2 TS, and whether to decode the extended layer on the application side may be determined based on the control commands of the application and user operations.
[0327] Alternatively, it may be possible to switch the playback operation by the application only for information related to the layout. For example, time scalability and stream switching do not involve changes in the layout. Therefore, these pieces of information are transmitted only in the default playback control information. On the other hand, since switching of information related to simultaneous display is assumed to be caused by user operations, the application enables the playback operation.
[0328] (Description example of default playback control information) Next, a description example of the playback control information when switching the playback operation by the application using the default playback control information will be described. Here, it is assumed that the default playback control information is stored in a descriptor and the application control information is described in HTML.
[0329] FIG. 18A is a diagram showing a description example of the default playback control information in Embodiment 2, and FIG. 18B is a diagram showing an example of the display of a video 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, as shown in FIG. 18B, the layout information indicates that the video with PID = 100 is displayed full screen.
[0330] Note that as the layout information, it may only indicate full-screen display without indicating information for specifying a stream. Also, at this time, if information (application control information) for specifying the video to be played back by default is separately indicated when there are two or more video streams, the video to be played back by default can be made to operate to be displayed full screen.
[0331] FIG. 19A is a diagram showing an example of the application control information in Embodiment 2, and FIG. 19B is a diagram showing an example of the display of a video according to the layout information of the application control information shown in FIG. 19A.
[0332] That is, in the application control information shown in FIG. 19A, two display areas, area 1 and area 2, are set by the Layout tag, and as shown in FIG. 19B, it is shown that the video with PID = 100 is displayed in area 1 and the video with PID = 200 is displayed in area 2.
[0333] Therefore, the receiving device that has received the HTML application control information shown in FIG. 19A displays the videos with PID = 100 and PID = 200 in area 1 and area 2, respectively. Note that the information for specifying the video may be, in addition to the PID, a URL or the packet ID of the MMT packet.
[0334] As described above, in the examples shown in FIGS. 19A and 19B, two types of information, scalability and layout, are shown in the default playback control information. As for the scalability, the type of scalability is time scalability, and it is shown that the video with PID = 100 is the base layer and the video with PID = 200 is the enhancement layer. As for the layout information, it is shown that the video with PID = 100 is displayed in full screen.
[0335] If only the base layer has a frame rate of 60fps and using the enhancement layer makes it 120fps, then in the default state, only the video with PID = 100 is decoded and the video equivalent to 60fps is played back by full screen display. Note that when it is separately indicated by the attribute information of the stream, such as the stream type of the MPEG-2 system, that the transmitted stream corresponds to the base layer or the enhancement layer of the scalability, these information may not be described in the default playback control information. Also, if it is separately specified that only the base layer is decoded and played back in the default state, 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 a display example of a video 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 a display example of a video 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 to decode and play an extended layer of time scalability when a button on the screen is pressed, and shows, as arguments, an index number for specifying a basic layer and an extended layer. In the Body tag, it is described that function A is called when a specific button on the remote control or the like is pressed.
[0338] When the receiving device that has received the HTML application of FIG. 21A detects that a button is pressed, it decodes the stream of the extended layer with PID = 200 and plays the video equivalent to 120 fps in full-screen display.
[0339] Streams such as audio and video to be played back by default may be separately indicated by using descriptors such as MPEG-2 system and MMT descriptors. For example, it is possible to group the streams to be played back by default and associate the group ID with the stream. Alternatively, it is also possible to define a descriptor for indicating the stream to be played back by default and include a list such as the PID of the stream to be played back by default in the descriptor.
[0340] Note that the default values in the default playback control information may be specified in advance, and when the parameter value is equal to the default value, the default playback control information may not be transmitted. For example, if full-screen display is set as the default value for the layout, in the case of full-screen display, the layout information may not be included. At this time, in a case where scalability is not used and the 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 then operates. Hereinafter, the receiving method in this embodiment will be described 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 of analyzing the default playback control information and the playback control information provided by the application to determine functions such as scalability and stream switching, and the layout when presenting the content.
[0343] First, in step S701, the receiving side selects the content to be viewed.
[0344] Next, in step S702, the receiving side analyzes the default playback control information, decodes it, determines the stream to be played back, and determines the presentation method such as the layout.
[0345] Here, the default playback control information may be transmitted included in the data that is always acquired at the time of channel selection, such as PMT or MPT, or may be transmitted separately from the application-related data, such as by an MPEG-2 TS section or an MMT message.
[0346] When the default playback control information is transmitted by a section or a message, the default value of the default playback control information may be set, and until the section or the message is received, the operation may be based on the default value of the default playback control information. Also, the stream to be decoded and played back may be determined by referring to a descriptor indicating a stream such as audio or video to be played back by default.
[0347] Next, in step S703, playback is started according to the determined playback control parameters.
[0348] Next, in step S704, it is determined whether an application is received. If not received (No in S704), the process ends. On the other hand, if received (Yes in S704), the process proceeds to step S705, and it is determined whether a playback control function is indicated in the application.
[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, and based on the playback control function indicated in the application, the playback control information is updated according to a control command or a user operation.
[0350] Next, in step S707, playback is performed according to the updated playback control parameters, and the process ends.
[0351] [Receiving device] FIG. 23 is a block diagram showing an example of the configuration of the receiving device in Embodiment 2. In FIG. 23, an example of the configuration of the receiving device that realizes the operations of the respective steps described in FIG. 22 is shown.
[0352] The receiving apparatus 700 shown in FIG. 23 includes a receiving unit 701, a default information analysis unit 702, an application information receiving unit 703, an application playback control information analysis unit 704, and a playback control execution unit 705. Since these operations are the operations in each step described in FIG. 22, the description thereof is omitted.
[0353] (Modification Example 1) The mechanism for updating the default playback control information by an application can be applied in all cases where content is transmitted by broadcasting alone, communication alone, or a combination of broadcasting and communication.
[0354] Also, the concept in the method in this embodiment can also be applied to the time line extension (13818-3:2013 / AMD6) of MPEG-2 TS that is currently being standardized by MPEG. In the time line extension of TS, when transmitting content using a plurality of multiplexed streams including at least one TS (referred to as a basic TS), information for synchronizing the reference clocks in content decoding and display in the basic TS and other multiplexed streams is provided.
[0355] Specifically, a time line extension access unit including information for associating the reference clock of a multiplexed stream different from the basic TS with the PCR of the basic TS is defined, the time line extension access unit is stored in a PES packet, and packetized into a TS packet and transmitted. In the time line extension access unit, the information for time line extension is expressed in the form of a descriptor of the MPEG-2 system. In this way, by transmitting the information for time line extension in units of PES packets, even when PCR discontinuity occurs, synchronization of the reference clock with the updated PCR can be performed quickly.
[0356] However, since PCR discontinuity generally does not occur within a single program, if the information for time line extension is received at the start of program reception and the reference clocks of each other are synchronized, resynchronization within the program is often unnecessary.
[0357] Therefore, when it is guaranteed that PCR discontinuity does not occur within a program, the default value of the information for timeline extension may be stored in a PMT or the like, and the access unit for timeline extension may not be transmitted. For example, a descriptor similar to the descriptor storing the information for timeline extension in the access unit for timeline extension may be stored in a section such as a PMT and used as the default value of the information for timeline extension. Also, the access unit for timeline extension and the default information stored in a PMT or the like may be used in combination.
[0358] Even when the access unit for timeline extension is transmitted, if it is guaranteed that PCR discontinuity does not occur within a program or until a specific time, after performing clock synchronization based on the information of the access unit for timeline extension received immediately after tuning, resynchronization may not be performed within the program or until a specific time.
[0359] Also, when transmitting the information for timeline extension by sections, the information for timeline extension corresponding to the updated PCR may be transmitted for a certain period immediately after PCR discontinuity occurs. In the receiving apparatus, if the version number of the section is updated, resynchronization is performed based on the information for timeline extension included in the section. Note that clock synchronization between streams cannot be guaranteed at a time after PCR discontinuity occurs and before resynchronization. At this time, PCR discontinuity may be separately detected based on information indicating PCR discontinuity such as the discontinuity indicator of the TS, and when discontinuity is detected, until resynchronization, the access unit of the media to be synchronized with the basic TS may be decoded and displayed assuming a fixed frame rate.
[0360] [Effects of Embodiment 2, etc.] 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 a stream that can be switched during playback, etc., the default value of the playback control information is stored in the data that is always received during channel selection, and information for updating the default playback control operation is stored in and transmitted with information related to an application such as a hybrid cast.
[0361] Here, playback is started according to the default value of the playback control. When the receiving device supports the application, the default playback control information is updated according to user operations, etc., based on the playback control function transmitted as application data.
[0362] Thereby, the delay time related to the determination of parameters related to playback control such as the layout of the content can be reduced.
[0363] (Embodiment 3) As described above, according to the MMT method, video and audio can be multiplexed and packetized and transmitted through one or more transmission paths such as broadcasting and communication. In the receiving device, packets transmitted through one or more transmission paths can be received, desired packets can be extracted from the received packets based on program information, and decoded and presented.
[0364] That is, in the MMT method, it is possible to receive media (video, audio, subtitles, etc.) transmitted through a plurality of transmission paths and configure a program. However, it is not possible to configure a program using both data downloaded and stored through broadcasting or communication and data streamed from broadcasting / communication.
[0365] Therefore, in Embodiment 3, the transmission method, receiving method, etc. when configuring a program using both data downloaded and stored through broadcasting or communication and data streamed from broadcasting / communication will be described.
[0366] Hereinafter, as a multiplexing format on the broadcast side in the broadcast cooperation service, MMT (MPEG Media Transport) standardized by MPEG will be described as an example.
[0367] In MMT, program information is transmitted by tables such as MPT (MMT Package Table) or message information such as PA (Package Access) messages. In the MPT, assets (single media such as video and audio) that make up a program and location information for transmitting the assets are described. It is also possible to transmit one asset through multiple transmission paths.
[0368] Also in this embodiment, the transmitting side transmits content (data or assets) using a broadcast wave and a communication path, but transmits service information prior to transmitting the content.
[0369] [Service Information] FIG. 24 is a diagram showing an example of the data structure of service information in the broadcast communication cooperation service of Embodiment 3. FIG. 25 is a diagram showing an example of information included in the program configuration information descriptor of Embodiment 3.
[0370] As shown in FIG. 24, a program configuration information descriptor is included in the MPT, and in this descriptor, information regarding the assets that make up a package is shown. The information regarding the assets that make up a package may include the following.
[0371] (Information Regarding Assets) 1) Information indicating whether or not the assets that make up a program include stored assets (hereinafter referred to as stored assets) may be included in the program configuration information descriptor as information regarding the assets. Here, the stored assets are, for example, assets stored in a memory such as an HDD, an internal memory, an SSD, an SD card, or a Blu-ray disc.
[0372] 2) If the assets constituting the program include stored assets, information indicating the program configuration may be included in the program configuration information descriptor as information regarding the assets.
[0373] For example, information indicating the program configuration such as the program being constituted only by stored assets, the program being constituted by stored assets and assets being transmitted (hereinafter referred to as transmitted assets), or the program being constituted by assets including stored packets and transmitted assets may be included. Also, for example, when the program is constituted by scalable-encoded video, information indicating that the transmitted assets include the base layer and the stored assets include the enhancement layer may be included. Further, information indicating whether the decoding and playback of the stored assets are essential or not for the playback of the program may be included. For example, when the content of the stored assets is additional information, playback is not essential, and information indicating that the playback of the stored assets is not essential may be included.
[0374] Also, for example, when the receiving device does not support storage or when the stored assets are not stored, based on the information indicating that the decoding and playback of the stored assets are not essential for the playback of the program, the program can be played back using the assets obtained from broadcasting or communication without using the stored assets.
[0375] 3) Information regarding the stored assets may be included in the program configuration information descriptor as information regarding the assets.
[0376] Here, for example, it may be possible to include attribute information such as a) the accumulation format of the accumulated assets, video and audio coding methods, the transmission method and multiplexing method for transmitting the accumulated assets, etc. In this case, attribute information may be given to the accumulated assets in advance, and the attribute information may be included, for example, in the header of the accumulated assets or in program information indicating the configuration of the accumulated assets. The receiving device may be made playable when the attribute information stored in the program information matches the attribute information of the accumulated assets. Also, for example, b) it may be possible to include information regarding the capabilities and functions of the receiver necessary for playing back the program including the accumulated assets. Also, for example, c) it may be possible to include information (scrambling method, viewing restriction, limited reception, copyright information) and keys for restricting program playback and viewing. In this case, the receiving device may collate the information for restricting viewing stored in the program information with the accumulated assets and determine whether the accumulated assets can be played back or viewed. Also, the receiving device may store the pre-encrypted assets and decrypt the encryption of the accumulated assets based on the transmitted key.
[0377] 4) When the assets constituting the program are composed of transmission assets and accumulated assets, the time information for synchronously playing back the transmission assets and the accumulated assets may be included as information regarding the assets in the program configuration information descriptor.
[0378] This time information may indicate, for example, the offset amount between the reference time information of the transmission assets and the reference time for which the time stamp given to the accumulated assets is the reference. Also, when the time stamp given to the accumulated assets is given based on PCR (Program Clock Reference) or NTP (Network Time Protocol), it may indicate the relative time with respect to the transmitted reference time (PCR or NTP). Also, when the accumulated assets are stored in a format having a random access table, the time information may be a time information table of the transmission assets with respect to the random access point of the accumulated assets.
[0379] (Location Information) In the MPT, location information of each asset is described for each asset. For example, when one asset exists in a plurality of locations, a plurality of location information is described in the MPT.
[0380] FIG. 26 is a diagram showing an example of information included in the location information descriptor of Embodiment 3. FIG. 27 is a diagram showing an example of a location type included in the location information descriptor of Embodiment 3.
[0381] As shown in FIG. 26, in the location information descriptor, as location information, a location type and an identifier for specifying an asset corresponding to the location type are described.
[0382] The location type represents the type of location information. For example, in the example shown in FIG. 26, since the value Value of the location type is 0xA0 (Value = 0xA0), it can be seen from FIG. 27 that it is stored locally. When it is shown that the location type is stored locally, the location information describes a local ID that uniquely indicates the stored data.
[0383] Here, the local ID may be, for example, the asset ID of the stored asset or the packet ID. It may also be a 32-bit transport file identifier defined in ARIB STD-B45, or may be newly defined. Also, various IDs such as a network ID and a stream ID may be combined to generate a local ID according to a predetermined naming rule. Further, the local ID may be assigned in advance by a broadcasting station, a transmitting station, a content provider, etc., or may be assigned by modifying the ID on the receiver side and adding additional information. It may be possible to identify data by preparing a table showing the correspondence with the ID assigned on the transmitting side and assigning a unique ID on the receiving side.
[0384] Note that the above example shows that the asset is locally stored using the location type, and it is assumed that a local ID is separately assigned. However, the following method may also be used. For example, IPv4 may be selected as the location type and specified using a locally unique IP address. For example, if the IP address is 192.168.xxx.xxx, it may be assumed that the asset is locally stored, and the asset stored in the xxx.xxx part may be specified.
[0385] In addition, a local ID is assigned to the data (file) of the stored asset. For example, it is stored in the file header in the file. The local ID may be stored in advance by the broadcasting station, transmitting station, or content provider, or it may also be considered to be stored on the receiving side.
[0386] The above descriptor is an example, and the descriptor may be configured with a data structure having a similar function. Also, the descriptor and identifier of the present embodiment may be stored in a table or message indicating information in package units different from those of MPT. It may also be transmitted using other signaling information.
[0387] Note that although MMT has been described as an example, it is not limited to MMT, and other formats such as TS and MPEG-DASH may also be used. For example, when using MPEG2-TS as the multiplexing method, it may be stored in the PMT (Program Map Table). Also, when transmitting in combination with the MPEG2-TS method and other methods, it may be stored in the TEMI (Timeline and External Media Information) access unit. When using MPEG-DASH, it may be described in the MPD (Media presentation description).
[0388] (Asset Configuration Information Descriptor) In the MMT method, it is also possible to transmit one asset through a plurality of transmission paths. At this time, an asset configuration information descriptor indicating the configuration of the asset may be stored.
[0389] FIG. 28 is a diagram showing an example of information included in the asset configuration information descriptor of Embodiment 3. That is, the information indicating the configuration of the asset can include the following.
[0390] 1) It is also possible to include information indicating that the asset is a stored asset or that the asset includes stored packets in the information indicating the configuration of the asset. Here, the case where the asset includes stored packets means a case where one asset is composed of packets transmitted from broadcasting or communication and stored packets.
[0391] 2) When the asset is a stored asset, for example, a) information indicating that the asset is composed of only stored assets, or is composed of stored packets and transmission packets, etc. may be included as information indicating the configuration of the asset. Also, b) when the asset is composed of scalable-encoded video, for example, information indicating that the transmission packet includes a base layer and the stored packet includes an enhancement layer, etc. may be included as information indicating the configuration of the asset. Also, c) information indicating whether the decoding and playback of the stored packet are essential or not may be included as information indicating the configuration of the asset. For example, when the content of the stored packet is additional information, playback is not essential, and it can be indicated that the playback of the content of the stored packet is not essential.
[0392] Thereby, for example, when the receiving device does not support storage, or when it does not store the stored packets, etc., based on the information indicating that the decoding and playback of the stored packets are not essential for the playback of the asset, the program can be played back using the packets transmitted from broadcasting or communication without using the stored packets.
[0393] Note that the above-described asset configuration information descriptor is an example, and an asset configuration information descriptor may be configured with a data structure having a similar function.
[0394] In addition, the asset configuration information descriptors and identifiers may be stored in tables or messages indicating information in package units, which are different from those of MPT. They may also be transmitted using other signaling information.
[0395] Although MMT has been described as an example, the present invention is not limited to MMT, and other formats such as TS and MPEG-DASH may also be used. For example, when using MPEG2-TS as the multiplexing method, it may be stored in a PMT (Program Map Table). Also, when transmitting in combination with the MPEG2-TS method and other methods, it may be stored in a TEMI (Timeline and External Media Information) access unit. When using MPEG-DASH, it may be described in an MPD (Media Presentation Description).
[0396] [Receiving Method and Receiving Device] Hereinafter, with reference to the drawings, an example of the operation of the receiving device in the present embodiment for synchronously playing back stored assets will be described.
[0397] FIG. 29 is a flowchart showing a receiving method in the broadcast communication cooperation service of Embodiment 3. FIG. 30 is a block diagram showing an example of the configuration of the receiving device in Embodiment 3.
[0398] The receiving device 30 shown in FIG. 30 includes a program information analysis unit 31, a stored asset identification unit 32, a stored asset information analysis unit 33, a determination unit 34, an asset acquisition unit 35, a 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 serving as an entry point and analyzes whether the program configuration includes stored assets.
[0400] Next, in step S12, the program information analysis unit 31 determines whether the elements constituting the program include accumulated assets. If it is determined that the elements constituting the program include accumulated assets (Yes in S12), the process proceeds to step S13, and information such as information indicating the configuration of the program, information regarding the accumulated assets, and relative time information with respect to the accumulated assets is acquired. If it is determined that the accumulated assets are not included (No in S12), the process proceeds to step S17, and transmission assets transmitted by broadcasting, communication, etc. are acquired and synchronously reproduced.
[0401] Next, in step S14, the receiving device 30 acquires the location information of the accumulated assets and the local ID. More specifically, when the assets are accumulated locally, the accumulated asset specifying unit 32 searches for and specifies the asset corresponding to the local ID from among the assets accumulated in the receiving device 30. Note that when there are a plurality of storage devices, it may be searched from among the plurality of storage devices, or only from within a specific storage device. Further, the accumulated asset information analysis unit 33 acquires the attribute information of the specified asset.
[0402] Next, in step S15, the determination unit 34 determines whether the program including the accumulated assets can be reproduced based on the information regarding the accumulated assets acquired in step S12 and the attribute information of the accumulated assets acquired in step S14.
[0403] If it is determined that the program can be reproduced (Yes in S15), the process proceeds to step S16, and the asset acquisition unit 35 acquires the accumulated assets in addition to the transmission assets such as broadcasting and communication. Then, the synchronization control unit 37 performs synchronization control processing between the transmission assets and the accumulated assets based on the acquired relative time information, and the synchronization presentation unit 36 performs synchronization and presentation of the program.
[0404] On the other hand, if it is determined in step S15 that the program cannot be reproduced (No in S15), the process proceeds to step S17, and transmission assets transmitted by broadcasting, communication, etc. are acquired and synchronously reproduced.
[0405] [Effect, etc. of Embodiment 3] As described above, according to this embodiment, it is possible to realize a method for generating program information, a method for playing back a program, and a playback apparatus when multiplexing a service that links broadcasting and communication by a format such as the MMT (MPEG Media Transport) method being standardized by the MPEG (Moving Picture Expert Group).
[0406] The MMT method multiplexes and packetizes video and audio, transmits them over one or more transmission paths such as broadcasting and communication, receives the packets transmitted over one or more transmission paths at a receiving apparatus, extracts desired packets from the received packets based on program information, and decodes and presents them.
[0407] In the MMT method, it is possible to receive media (such as video, audio, and subtitles) transmitted over a plurality of transmission paths and configure a program. However, it is not possible to configure a program using both data downloaded and stored in broadcasting or communication and data streamed from broadcasting / communication.
[0408] Therefore, in this embodiment, an identifier indicating that one of the media constituting the program is stored data and an identifier capable of specifying the stored media (file) are provided in the program information indicating the configuration of the program. Further, in the playback apparatus, the program information is analyzed to specify the media transmitted in broadcasting / communication and the stored data, and they are played back synchronously.
[0409] Thereby, since it is possible to configure a program using both data downloaded and stored in broadcasting or communication and data streamed from broadcasting / communication, in addition to the conventional broadcast communication cooperation service, it is possible to provide a service that cooperates with the stored files.
[0410] In addition, in this embodiment, a combination of a transmission asset and a storage asset has been described as an example, but it is not limited thereto. The transmission asset may be an asset transmitted by broadcasting, an asset transmitted by communication, or an asset transmitted from both broadcasting and communication. As services using the storage asset, the following services may be provided. An identifier indicating the content of the service may be stored in the program information.
[0411] (Services Using Storage Assets) 1) Assets constituting a program may be downloaded in advance, and only program information and time synchronization information (such as time reference information and relative values of timestamps) may be transmitted by broadcasting, and the program may be played back using the storage asset. At this time, the broadcaster can provide the program using the stored data to the viewer in real time according to the program schedule. The viewer can view the stored data as if viewing a program being broadcast in real time. It is possible to provide not only real-time broadcasts but also on-demand content.
[0412] 2) Also, program information, random access points, etc. may be downloaded and stored together with the assets constituting the program in advance, and the program may be configured in synchronization with the program information transmitted from broadcasting or communication.
[0413] 3) It is also possible to provide a service in which a normal broadcast program is transmitted using only broadcasting and is linked with the stored data only during commercials. Commercial data may be downloaded in advance from broadcasting or communication, and when the commercial time slot arrives, a program including the stored data may be provided to the viewer. Also, a plurality of commercial data may be downloaded in advance, and the commercial to be provided may be selected according to the attributes and preferences of the viewer. The attributes and preferences of the viewer may be obtained and analyzed by the receiving device, or may be obtained in cooperation with other applications or services.
[0414] 4) The broadcaster may allocate the available frequency resources to other services by providing services in cooperation with the stored data. At this time, the program information may store information indicating that the frequency resources used for the service are provided to other services.
[0415] 5) The viewer may have a function to switch to a program associated with the stored asset. For example, a viewer who is only viewing the transmission asset may switch to a program including the stored asset through a user interface such as a remote control.
[0416] 6) Also, the receiving device or the viewer may set whether to access the stored asset to configure a program. Also, it may be possible to access the stored asset to configure a program only when the program information is authenticated as reliable. The program information may store information indicating that the program information is reliable, such as a key.
[0417] (EPG) 7) The information to be displayed as the EPG (Electronic Program Guide) may be obtained from the program information or from the signaling information dedicated to the EPG.
[0418] 8) Information such as whether the program is provided using broadcasting, communication, storage, in combination, or as an extended service may be displayed in the EPG. Also, only the functions that the receiving device can provide may be displayed. For example, if the receiving device does not have the function of storing or receiving communication, information related to storage and communication may not be displayed.
[0419] 9) In a program including stored assets, information indicating whether the stored assets of the program are stored or not may be displayed on the EPG. Information indicating whether the stored assets of the program can be presented may also be displayed on the EPG. It may be indicated by characters or the like, or may be indicated by the background color of the program on the EPG. The content including the stored assets may present information related to viewing restrictions and copyrights.
[0420] 10) When reserving a program including stored assets from the EPG, information indicating whether the stored assets can be downloaded from the broadcast, downloaded from the communication, or viewed by communication streaming may be displayed on the EPG or the like. When the receiving device does not have a communication means, it may be sufficient to display only whether it can be downloaded by broadcast. The viewer selects and reserves from among the methods that can be reserved for download.
[0421] The reservation for download may be reserved by the viewer in advance from the EPG, or the receiving device may automatically download it. The selection of the download method may be made by the viewer or may be automatically selected by the receiving device.
[0422] Also, the display on the EPG and the functions of the receiving device may be changed according to the time zone in which it can be downloaded by broadcast, the time zone in which it can be downloaded by communication, and the time zone in which it can be streamed by communication.
[0423] Note that, not limited to the above display on the EPG, it may be presented by another presentation method other than the EPG.
[0424] As described above, the transmission method, the reception method, etc. according to one or more aspects of the present invention have been described based on the embodiments, but the present invention is not limited to these embodiments. As long as it does not deviate from the gist of the present invention, various modifications conceived by those skilled in the art applied to this embodiment, or forms constructed by combining components in different embodiments may also be included within the scope of one or more aspects of the present invention.
[0425] For example, in each of the above embodiments, each component may be configured by dedicated hardware or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory.
Industrial Applicability
[0426] The present invention is useful as a content transmission method, a reception method, etc. capable of transmitting content using a broadcast wave and a communication path.
Explanation of Signs
[0427] 11 Identification Information Acquisition Unit 14, 104, 305, 405, 1105 Broadcast Reception Unit 30, 100, 300, 400, 700, 1100 Receiver 31 Program Information Analysis Unit 32 Accumulated Asset Identification Unit 33 Accumulated Asset Information Analysis Unit 34, 103 Determination Unit 35 Asset Acquisition Unit 36 Synchronization Presentation Unit 37 Synchronization Control Unit 101, 301, 401, 1101 Identification Information Acquisition Unit 102 Asset Determination Unit 105, 306, 406, 1106 Communication Reception Unit 302, 402, 1102 Determination Unit 303, 403, 1103 Communication Co-Use Determination Unit 304, 404, 1104 Loc Information Acquisition Unit 407 Synchronization Determination Unit 408, 1108 Reproduction Unit 701 Receiver 702 Default Information Analysis Unit 703 Application Information Reception Unit 704 Application Reproduction Control Information Analysis Unit 705 Reproduction Control Execution Unit 1107 Reference Clock Judgment
Claims
1. A method for transmitting content capable of transmitting content using a broadcast wave and a communication channel, comprising: a generation step of generating the content in a format compliant with MMT (MPEG Media Transport); a content transmission step of transmitting the content in the format generated in the generation step; an information transmission step of transmitting, using at least the broadcast wave, auxiliary information including information indicating that there is content transmitted by the communication channel, information indicating a format of meta information for reproduction control of the content transmitted by the communication channel, and location information indicating a destination for acquiring the content transmitted by the communication channel, when transmitting the content using each of the broadcast wave and the communication channel; A transmission method.
2. A content transmission apparatus capable of transmitting content using a broadcast wave and a communication channel, comprising: a generation unit that generates the content in a format compliant with MMT (MPEG Media Transport); a content transmission unit that transmits the content in the format generated by the generation unit; an information transmission unit that transmits, using at least the broadcast wave, auxiliary information including information indicating that there is content transmitted by the communication channel, information indicating a format of meta information for reproduction control of the content transmitted by the communication channel, and location information indicating a destination for acquiring the content transmitted by the communication channel, when transmitting the content using each of the broadcast wave and the communication channel; A transmission apparatus.
Citation Information
Patent Citations
Distribution device, distribution method, reproduction device, reproduction method, distribution system, distribution program, reproduction program, and recording medium
JP2013090295A
Reception device for receiving a plurality of real-time transfer streams, transmission device for transmitting same, and method for playing multimedia content
WO2012099359A2
Method and apparatus for synchronizing media data of multimedia broadcast service
WO2013042961A1
Method for displaying contents, method for synchronizing contents, and method and device for displaying broadcast contents
WO2013055164A1
Apparatus and method for configuring control message in broadcasting system
WO2013055191A2