WO2018016295A1 - 受信装置、およびデータ処理方法 - Google Patents
受信装置、およびデータ処理方法 Download PDFInfo
- Publication number
- WO2018016295A1 WO2018016295A1 PCT/JP2017/024126 JP2017024126W WO2018016295A1 WO 2018016295 A1 WO2018016295 A1 WO 2018016295A1 JP 2017024126 W JP2017024126 W JP 2017024126W WO 2018016295 A1 WO2018016295 A1 WO 2018016295A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- event
- data
- emergency information
- information
- notification
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
- H04N21/814—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts comprising emergency warnings
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
- H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
- H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
- H04H60/25—Arrangements for updating broadcast information or broadcast-related information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/488—Data services, e.g. news ticker
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/488—Data services, e.g. news ticker
- H04N21/4882—Data services, e.g. news ticker for displaying messages, e.g. warnings, reminders
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/8166—Monomedia components thereof involving executable data, e.g. software
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
Definitions
- the present disclosure relates to a receiving device and a data processing method. More specifically, for example, the present invention relates to a receiving apparatus that executes processing for receiving data via a broadcast wave or a network and outputting the received data to a display unit or the like, and a data processing method corresponding to communication data.
- OTT Over The Top
- OTT content Distribution content by OTT
- OTT video image (video) data distribution service using OTT
- OTT-V Over The Top Video
- DASH Dynamic Adaptive Streaming HTTP
- HTTP HyperText Transfer Protocol
- a content distribution server such as a broadcasting station can reproduce content on various clients as data distribution destinations.
- a manifest file describing the URL and URL is created and provided to the client.
- the client acquires the manifest file from the server, selects the optimum bit rate content according to the size of the display unit of the own device and the available communication band, and receives and plays back the selected content. It is possible to dynamically change the bit rate according to fluctuations in the network bandwidth, and it is possible for the client side to switch and receive the optimal content according to the situation at any time, reducing the occurrence of video interruptions Playback is realized. Note that adaptive (adaptive) streaming is described in, for example, Japanese Patent Application Laid-Open No. 2011-87103.
- One-way communication by broadcast waves, etc., or two-way communication via a network such as the Internet one-way from a transmission device such as a broadcasting station or other content server to a reception device such as a TV, PC, or portable terminal
- a transmission device such as a broadcasting station or other content server
- a reception device such as a TV, PC, or portable terminal
- a transmission device such as a broadcasting station or other content server
- a reception device such as a TV, PC, or portable terminal
- ATSC Advanced Television System Commitment
- middleware that performs reception processing of ATSC 3.0 broadcasts on a broadcast distribution device (tuner mounted device) that implements an ATSC 3.0 compliant physical layer (ATSC-PHY)
- ATSC-PHY ATSC 3.0 compliant physical layer
- application programs used on the Internet or the like that is, so-called client applications are used as they are under the control of signaling data, and various applications provided by broadcast content output processing, broadcast waves, etc. are used.
- client applications are used as they are under the control of signaling data
- various applications provided by broadcast content output processing, broadcast waves, etc. are used.
- a server such as a dedicated server, a PC, a TV, a tablet, a smartphone, etc.
- a broadcast service installed in a home or hot spot
- an ATSC 3.0 compliant physical layer ATSC-PHY
- ATSC 3.0 ATSC 3.0
- the broadcast received data is transmitted to the user device (PC, TV, tablet, smartphone, etc.) via the network (LAN / WiFi such as a home network or hotspot).
- the network LAN / WiFi such as a home network or hotspot
- the user device that has input the broadcast reception data transferred through the server uses the application (for example, ATSC 3.0 DASH client application) running on the reproduction control unit or application control unit of the user device to reproduce the broadcast content.
- application for example, ATSC 3.0 DASH client application
- various applications distributed by broadcasting can be executed.
- middleware that performs analysis of signaling data including control information of the ATSC 3.0 broadcast service is a termination device that can perform immediate analysis processing at the timing of receiving the signaling data.
- the middleware may receive emergency information from the transmission device 20, for example. Specifically, for example, emergency information such as the occurrence of an earthquake or the occurrence of terrorism.
- the middleware notifies the playback control unit (client) that is executing the output (display) control of the broadcast service as soon as possible when detecting the reception of such emergency information, and outputs the emergency information as display data. Is required.
- the middleware When the middleware is configured by a home server, for example, various remote clients (PC, TV, tablet, smartphone, etc.) may be connected to the middleware via a network. In these remote clients, the reproduction control unit and application control unit of each client display various data on the display unit. The middleware needs to notify the reproduction control unit and the application control unit of such a remote client that emergency information has been received as soon as possible, and output the emergency information as display data.
- remote clients PC, TV, tablet, smartphone, etc.
- EAS Emergency Alert System
- various emergency information such as weather disaster information, terrorism information, and other emergency evacuation are provided. It is possible to notify information quickly.
- the emergency information notified using the EAS includes various different levels of emergency information such as a notification item at the national level such as a message from the president and a local notification item at the state or local government level.
- the present disclosure has been made in view of, for example, the above-described problems.
- middleware that performs analysis of received data receives emergency information
- various clients that perform reproduction of received data via the middleware are notified. It is an object of the present invention to provide a receiving apparatus and a data processing method for realizing reliable presentation of emergency information by a client.
- the first aspect of the present disclosure is: Middleware that executes analysis processing of received data from the transmitting device; An output data control unit for executing an output control process of received data from the transmission device; The middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification, The output data control unit The event notification data is acquired, and the emergency information acquisition or display processing is performed based on the acquired event notification data.
- the second aspect of the present disclosure is: It has middleware that executes analysis processing of received data from the transmitting device,
- the middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification,
- the received emergency information event notification data is in a receiving device that provides a client that executes an output control process of received data from the transmitting device.
- the third aspect of the present disclosure is: It has an output data control unit that executes output control processing of received data from the transmission device,
- the output data control unit Obtaining emergency information event notification data including configuration data of an emergency information delivery notification transmitted by the transmission device; Based on the acquired event notification data, the receiving apparatus executes the acquisition or display processing of emergency information.
- the fourth aspect of the present disclosure is: A data processing method executed in the receiving device,
- the receiving device is: Middleware that executes analysis processing of received data from the transmitting device;
- An output data control unit for executing an output control process of received data from the transmission device;
- the middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification,
- the output data control unit In the data processing method, the event notification data is acquired, and the emergency information is acquired or displayed based on the acquired event notification data.
- the fifth aspect of the present disclosure is: A data processing method executed in the receiving device,
- the receiving device is: It has middleware that executes analysis processing of received data from the transmitting device,
- the middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification,
- the generated emergency information event notification data is provided to a client that executes output control processing of received data from the transmission device.
- the sixth aspect of the present disclosure is: A data processing method executed in the receiving device,
- the receiving device is: It has an output data control unit that executes output control processing of received data from the transmission device,
- the output data control unit Obtaining emergency information event notification data including configuration data of an emergency information delivery notification transmitted by the transmission device;
- system is a logical set configuration of a plurality of devices, and is not limited to one in which the devices of each configuration are in the same casing.
- the middleware of a receiving device that performs broadcast content output processing receives an emergency information distribution notification transmitted by the transmitting device, and generates emergency information event notification data including configuration data of the received emergency information distribution notification To do.
- the output data control unit acquires event notification data, and executes emergency information acquisition or display processing based on the acquired event notification data. For example, when the emergency information superimposed on the image is distributed, the application presentation content is removed by event notification, and in the case of the signaling emergency information distribution, the quick emergency information acquisition and output processing is performed.
- this configuration it is possible to realize a configuration that enables quick and reliable presentation processing of emergency information to a viewer.
- the effects described in the present specification are merely examples and are not limited, and may have additional effects.
- Notification configuration of on-screen message type emergency information delivery notification using the segment application (In-band) event notification method 8-1-3 Execution sequence of event generation, transfer, and processing based on event based on on-screen message type emergency information delivery notification 8-2. Configuration for notifying signaling data application type emergency information delivery notification as event information 8-2-1. Notification configuration of signaling data application type emergency information delivery notification using the MPD application event notification method 8-2-2. Notification configuration of signaling data application type emergency information distribution notification using the segment application (In-band) event notification method 8-2-2. 8. Execution sequence of event generation, transfer, and processing based on event based on signaling data applied type emergency information delivery notification Example of configuration with server and client dedicated to event information transfer] 9-1.
- Event generation, transfer based on signaling data application type emergency information delivery notification, and execution sequence of event based processing 10.
- a communication system 10 includes a transmission device 20 that is a communication device that transmits content such as image data and audio data, and communication that receives the content transmitted by the transmission device 20 via a broadcast wave or a network.
- a tuner-mounted receiving device 30 that is a device, a tuner-mounted receiving device 30 that receives content transmitted by the transmitting device 20, and a tuner-unmounted receiving device 40 that receives the content via a network.
- the transmission device 20 is a device that provides content, such as a broadcasting station 21 and a content server 22.
- the tuner-mounted receiving device 30 is a receiving device that includes a tuner for receiving broadcast waves.
- a general user client device a home server, a relay server installed in a public facility, and the like.
- a relay server including a home server
- the tuner non-mounting receiving device 40 is a receiving device that does not include a tuner for receiving broadcast waves.
- Data communication between the transmission device 20 and the tuner-implemented reception device 30 is communication using at least one of bidirectional communication, one-way communication, one-way communication using a broadcast wave, or the like via a network such as the Internet. As done.
- the content transmission from the transmission device 20 to the tuner-implemented reception device 30 is executed in accordance with, for example, the DASH (MPEG-DASH) standard which is a standard of adaptive (adaptive) streaming technology.
- the DASH (Dynamic Adaptive Streaming over HTTP) standard is a standard related to adaptive (adaptive) streaming delivery using a streaming protocol based on HTTP (Hyper Text Transfer Protocol) as described above.
- the MPEG-DASH standard includes the following two standards.
- A a standard concerning a manifest file (MPD: Media Presentation Description) for describing metadata that is management information of a moving image or an audio file
- B Standards related to file format (segment format) for video content transmission; Content distribution from the transmission device 20 to the tuner-mounted reception device 30 is executed in accordance with the MPEG-DASH standard.
- MPD Media Presentation Description
- the content received by the tuner-implemented receiving device 30 is transferred to the tuner non-implemented receiving device 40 via a network (home network (LAN / WiFi, etc. if home), WiFi, etc. if a hot spot).
- the tuner-mounted receiving device 30 and the tuner non-mounted receiving device 40 can reproduce the content transmitted by the transmitting device 20.
- the transmission device 20 encodes the content data and generates a data file including the encoded data and the metadata of the encoded data.
- the encoding process is performed in accordance with, for example, an MP4 file format defined in MPEG.
- the encoded data file is called “mdat”, and the metadata is called “moov” or “moof”.
- the content provided by the transmission device 20 to the tuner-implemented reception device 30 is various data such as music data, video data such as movies, television programs, videos, photos, documents, pictures and charts, games and software. .
- Transmission data of the transmission device 20 will be described with reference to FIG. As shown in FIG. 2, the transmitting apparatus 20 that performs data transmission according to the MPEG-DASH standard transmits the following plural types of data roughly.
- A Signaling data 50
- B AV segment 60
- C Other data (ESG, NRT content, etc.) 70
- the AV segment 60 is composed of images (Video) and audio (Audio) data to be reproduced by the receiving device, that is, program content provided by a broadcasting station, for example.
- images Video
- Audio Audio
- the receiving device that is, program content provided by a broadcasting station, for example.
- it is configured by the above-described MP4 encoded data (mdat) and metadata (moov, moof).
- the AV segment is also called a DASH segment.
- the signaling data 50 includes program schedule information such as a program guide, address information (URL (Uniform Resource Locator), etc.) necessary for program acquisition, and information necessary for content playback processing, such as codec information (encoding).
- program schedule information such as a program guide, address information (URL (Uniform Resource Locator), etc.
- information necessary for content playback processing such as codec information (encoding).
- Control information such as a system
- guidance information such as a system
- notification information such as notification information
- application control information such as earthquake information and terrorism information.
- the signaling data 50 is transmitted from the transmission device 20 as data in, for example, an XML (Extensible Markup Language) format.
- the signaling data is repeatedly transmitted from time to time. For example, it is repeatedly transmitted every 100 msec. This is because the receiving device (client) can obtain the signaling data immediately at any time.
- the client (receiving device) executes processing necessary for receiving and playing program content without delay, such as acquisition of necessary program content access address and codec setting processing, based on receivable signaling data as needed. It becomes possible.
- emergency information such as earthquake information and terrorism information can be provided to many receiving devices throughout the lifetime without causing a large delay.
- the other data 70 includes, for example, ESG (Electronic Service Guide), NRT content, and the like.
- ESG is an electronic service guide, and is guide information such as a program guide.
- NRT content is non-real-time content.
- the NRT content includes, for example, various application files executed on the browser of the receiving device 30 as a client, data files such as moving images and still images, and the like.
- Signaling data 50 B
- AV segment 60 C
- Other data ESG, NRT content, etc.
- FLUTE File Delivery over Uni-directional Transport
- FLUTE File Delivery over Uni-directional Transport
- a file generated on the server side which is a transmission device is transmitted to a client which is a reception device in accordance with the FLUTE protocol.
- the tuner-implemented receiving apparatus (client) 30 stores the URL and version of the received file in association with the file, for example, in a storage unit (client cache). Files with the same URL but different versions are considered to have been updated.
- the FLUTE protocol performs only one-way file transfer control, and does not have a selective file filtering function on the client. However, on the client side using metadata associated with the file to be transferred by FLUTE, the metadata is associated with the file. By selecting, it becomes possible to realize selective filtering and to configure and update a local cache reflecting the user's preference.
- the metadata can be expanded and incorporated into the FLUTE protocol, or can be separately described using a protocol such as ESG (Electronic Service Guide).
- FLUTE was originally specified as a file transfer protocol in multicast.
- FLUTE is composed of a combination of FDT and a scalable file object multicast protocol called ALC, specifically, its building blocks LCT and FEC components.
- FLUTE Real-Time Object Delivery over Unidirectional Transport
- ATSC Advanced Television System Commitment
- FIG. 3 is a diagram illustrating an example of a protocol stack of the transmission device and the reception device.
- the example shown in FIG. 3 has two protocol stacks for processing the following two communication data.
- A Broadcast (including multicast) communication (for example, broadcast-type data distribution)
- B Unicast (broadband) communication (for example, HTTP-type P2P communication)
- the left side of FIG. 3 is a protocol stack corresponding to (a) broadcast communication (for example, broadcast-type data distribution).
- the right side of FIG. 3 is a protocol stack corresponding to (b) unicast (broadband) communication (for example, HTTP type P2P communication).
- the protocol stack corresponding to (a) broadcast communication (for example, broadcast-type data distribution) shown on the left side of FIG. 3 has the following layers in order from the lower layer.
- Broadcast physical layer Broadcast PHY
- IP Multicast IP Multicast
- ESG, NRTcontent, DASH (ISO BMFF) and Video / Audio / CC, signaling SLS: Service Level Signaling
- SLS Service Level Signaling
- Application layer Application layer (Applications (HTML5))
- the signaling data layer is also set as an upper layer of the IP multicast layer (IP Multicast) and the UDP layer.
- the signaling layer is a layer applied to transmission / reception of the signaling data 50 described above with reference to FIG.
- the signaling data includes program schedule information such as a program guide, address information (URL and the like) necessary for program acquisition, and information necessary for content reproduction processing, such as codec information (encoding method and the like).
- codec information encoding method and the like.
- Various information such as information, control information, and emergency information such as earthquake information and terrorism information are included.
- the signaling data includes, for example, the following two different types of signaling data.
- LLS lower layer signaling
- SLS Service Level Signaling
- SLS Service Level Signaling
- LLS is signaling data storing control information, guidance information, metadata, etc. for each service unit, for example, each program unit.
- LLS low layer signaling
- LLS is signaling data storing control information, guidance information, metadata, and the like higher than SLS, and includes information for acquiring SLS, for example.
- the signaling data includes access information of AV segments received and reproduced by the receiving device (client) and guidance information and control information necessary for post-reception processing such as decoding processing, and is repeatedly transmitted from the transmitting device as needed. It is.
- USD User Service Description
- MPD Media Presentation Description
- signaling data are data necessary for reception, playback processing, and control processing of AV segments and applications (application programs) transmitted from the transmission device in the reception device (client). It is set as (metafile) and transmitted from the transmission device.
- the broadcast physical layer (Broadcast PHY) is a physical layer configured by a communication control unit that controls, for example, a broadcast communication unit for performing broadcast communication.
- the IP multicast layer (IP Multicast) is a layer that executes data transmission / reception processing according to IP multicast.
- the UDP layer is a UDP packet generation and analysis processing layer.
- the ROUTE layer is a layer that stores and retrieves transfer data according to the ROUTE protocol, which is an extended FLUTE protocol.
- ROUTE like FLUTE, is a multicast file object multicast protocol called ALC, and is specifically composed of a combination of its building blocks LCT and FEC components.
- FIG. 4 shows protocol stacks for ROUTE and FLUTE.
- ESG, NRT content, DASH (ISO BMFF), and Video / Audio / CC are data transferred according to the ROUTE protocol.
- the broadcast delivery service according to the DASH standard is called MBMS (Multimedia Broadcast Multicast Service).
- MBMS Multimedia Broadcast Multicast Service
- eMBMS evolved Multimedia Broadcast Service
- MBMS and eMBMS are broadcast-type delivery services that deliver the same data, such as movie content, all at once to a plurality of user terminals (UEs), which are receiving devices located in a specific area, using a common bearer. It is a service.
- UEs user terminals
- the same content can be simultaneously provided to a number of receiving devices such as smartphones, PCs, and televisions located in the distribution service providing area.
- MBMS and eMBMS specify a process for downloading a file according to the 3GPP file format (ISO-BMFF file, MP4 file) according to the transfer protocol ROUTE or FLUTE.
- 3GPP file format ISO-BMFF file, MP4 file
- Signaling data 50 (B) AV segment 60 (C) Other data (ESG, NRT content, etc.) 70 Many of these data are transmitted according to the ROUTE protocol or the FLUTE protocol.
- ESG, NRT content, DASH (ISO BMFF), and Video / Audio / CC are data transferred according to the ROUTE protocol.
- ESG is an electronic service guide, and is guide information such as a program guide.
- NRTcontent is non-real-time content.
- the NRT content includes, for example, various application files executed on the browser of the receiving device that is a client, data files such as moving images and still images, and the like.
- Video / Audio / CC is actual data to be reproduced, such as video and audio distributed according to the DASH standard.
- the application layer (Applications (HTML5)) is an application layer that executes generation or analysis of data to be transferred according to the ROUTE protocol, and other various data output control, for example, data generation using HTML5, Perform analysis and output processing.
- HTML5 Applications
- the protocol stack corresponding to (b) unicast (broadband) communication (for example, HTTP-type P2P communication) shown on the right side of FIG. 3 has the following layers in order from the lower layer.
- Broadband PHY (2) IP unicast layer (IP Unicast) (3) TCP layer (4) HTTP layer (5) ESG, Signaling, NRT content, DASH (ISO BMFF) and Video / Audio / CC (6) Application layer (Applications (HTML5))
- the broadband physical layer (Broband PHY) is a physical layer configured by a communication control unit such as a device driver that controls a communication unit such as a network card that performs broadband communication.
- the IP unicast layer (IP Unicast) is a layer that executes IP unicast transmission / reception processing.
- the HTTP layer is an HTTP packet generation and analysis processing layer. This upper layer is the same as the stack configuration of (a) broadcast communication (for example, broadcast-type data distribution) on the left side of FIG.
- the transmission device (server) 20 and the tuner-implemented reception device (client) 30 have two processing systems shown in FIG. (A) Broadcast communication (for example, broadcast-type data distribution) (B) Unicast (broadband) communication (for example, HTTP-type P2P communication) Processing according to at least one of these two communication protocol stacks is performed.
- A Broadcast communication (for example, broadcast-type data distribution)
- B Unicast (broadband) communication (for example, HTTP-type P2P communication) Processing according to at least one of these two communication protocol stacks is performed.
- the tuner non-implementation receiving apparatus (client) 40 performs a communication process with the tuner implementation receiving apparatus (client) 30 as a processing system on the right side of FIG. (B) Unicast (broadband) communication (for example, HTTP-type P2P communication) Communication processing according to this communication protocol stack is executed.
- the attributes of a file group (including URL as a file identifier) multicast-transferred according to ROUTE (FLUTE) can be described in the control file of ROUTE (FLUTE). It can also be described in signaling data that describes the session. Further detailed attributes of the file transfer session can also be described by ESG (which can also be applied for presentation to the end user).
- ATSC Advanced Television System Commitment
- IP-based transport stack a file based on the MPEG-DASH file format (ISO-BMFF file, MP4 file) has been expanded from RUTE (File Delivery over Unidirectional Transport) (ROUTE (Real-Time Object).
- RUTE File Delivery over Unidirectional Transport
- ROUTE Real-Time Object
- fragmented MP4 fragmented MP4 file sequence of DASH standard, MPD (Media Presentation Description) that is a metafile storing DASH standard control information (signaling data), and broadcast distribution
- MPD Media Presentation Description
- S-TSID Service based Transport Session Description
- EAS Emergency Alert System
- various emergency information such as meteorological disaster information, terrorism information, and the like are prepared using this EAS. It is possible to quickly notify other emergency evacuation information.
- the emergency information notified using the EAS includes various different levels of emergency information such as a notification item at the national level such as a message from the president and a local notification item at the state or local government level.
- ATSC Advanced Television Systems Committee
- IPAWS Integrated Public Alert and Warning System
- a transmission device such as a broadcasting station transmits emergency information according to an AEAT (Advanced Emergency Alerting Table) or CAP (Common Alerting Protocol) format defined as a standard for emergency information transmission according to the Integrated Public Alert System (IPAWS).
- AEAT Advanced Emergency Alerting Table
- CAP Common Alerting Protocol
- IPAWS Integrated Public Alert System
- various attribute information of emergency information such as the category of emergency information, the urgency level and source information of emergency information, and area information that needs to be notified of emergency information, are included in AEAT and CAP messages. Detailed information is given.
- the receiving device that has received this AEAT or CAP message analyzes the received message and selects and outputs (displays) necessary information according to, for example, the category or urgency of emergency information or the current position of the receiving device. To do.
- the tuner-implemented receiving device 30 has middleware that analyzes received data.
- the middleware receives emergency information such as occurrence of an earthquake or terrorism, it receives emergency information. It is necessary to notify the client (user device) playing the broadcast service via the middleware as soon as possible at the timing when the message is detected.
- the tuner-implemented receiving apparatus 30 includes middleware (ATSC 3.0 broadcast receiving middleware) that executes analysis of signaling data including control information of the ATSC 3.0 broadcast service, but the tuner non-implemented receiver 40 includes such middleware. Does not have.
- the tuner-implemented receiving device 30 needs to notify emergency information such as the occurrence of an earthquake or terrorism detected by the middleware to various clients (user devices) playing the broadcast service via the middleware as soon as possible. It becomes.
- an emergency message is received by an application (for example, an ATSC 3.0 DASH client application) operating on a playback control unit or an application control unit of a remote client (PC, TV, tablet, smartphone, etc.) connected to a network. I have to notify you.
- an emergency message is superimposed (overlaid) on a program image of a broadcast program being displayed on a client such as a smartphone, but the other broadcast application being executed on the client or the client itself executes If the application presentation is overlaid (overlaid) on the program image by the application, the user cannot see the emergency message unless the application presentation is excluded, leading the user to a dangerous situation. This is because there is a risk of it.
- FIG. 5 shows a configuration for distributing image data in which emergency information is superimposed on an image of program content distributed by a transmission apparatus such as a broadcasting station.
- a transmission apparatus such as a broadcasting station.
- the broadcast station If, for example, baseball broadcast program content is distributed as a normal program display and emergency information occurs, the broadcast station generates program content in which the emergency information is superimposed on the baseball relay image and sends it to the receiving device. To deliver.
- the emergency information delivery method for delivering the emergency information directly superimposed on the reproduction content is called an on-screen message (OnScreenMessage) type emergency information delivery method.
- OnScreenMessage on-screen message
- FIG. 6 is a diagram for explaining an example of transmission processing of an on-screen message (OnScreenMessage) type emergency information distribution method.
- the transmission apparatus 20 such as a broadcasting station distributes program content corresponding to a plurality of channels (CH1.1, CH1.2) via a program distribution path and distribution of signaling data via a signaling transmission path, for example.
- the program described with reference to FIG. 5 is a channel (CH1.1) program, and broadcasts news from time t0 to t1, and baseball broadcast starts from time t1. Thereafter, the transmission device 20 as a broadcasting station generates program content in which emergency information is superimposed on the baseball broadcast image at time t2 and distributes the program content to the reception device 30. The user (viewer) watching the baseball broadcast on the receiving device 30 side can check the emergency information superimposed on the baseball relay screen.
- CH1.1 channel
- FIG. 7B is an example in which the weather forecast display application is executed and the weather forecast information is displayed while the user (viewer) is watching the baseball broadcast.
- This weather forecast display application is, for example, an application distributed separately by the broadcasting station in addition to the baseball broadcast broadcast content, or an application acquired in advance as NRT content by the client (television) side.
- FIG. 8 shows a signaling data applied emergency information distribution method.
- the transmission device 20 such as a broadcasting station can transmit emergency information using a communication path dedicated to signaling data (LLS: Lower Layer Signaling), which is a communication path different from a normal program distribution path.
- LLS Lower Layer Signaling
- the emergency information according to the previously described AEAT (Advanced Emergency Alerting Table) or CAP (Common Alerting Protocol) format is transmitted according to this signaling data applied emergency information distribution method.
- the program is a channel (CH1.1) program
- news is broadcast from time t0 to t1
- baseball broadcast is started from time t1.
- the transmission device 20 serving as a broadcasting station generates signaling data (LLS) storing emergency information at time t2 and distributes it to the reception device 30.
- the receiving device 30 receives this signaling data, and displays the emergency information acquired from the signaling data on the display screen of the baseball broadcast.
- AEAT and CAP include data corresponding to the position information of the receiving device, for example, control information for providing evacuation route information. By using these, evacuation corresponding to the position of each receiving device is included. It is possible to display a route map.
- FIG. 9 shows a display example of map information.
- the map data shown in FIG. 9 (3c) is also transmission data by signaling data.
- signaling data such as AEAT and CAP
- various attribute information of emergency information for example, category of emergency information, urgency information and source information of emergency information, area information that needs to be notified of emergency information, etc.
- Detailed information on various emergency information names can be recorded, and the receiving device analyzes the received signaling data, and is necessary depending on, for example, the category and urgency of the emergency information, or the current position of the receiving device
- Various information can be selected and output (displayed). By applying these information sails, a map corresponding to the position of the receiving device can be displayed as shown in FIG. 9 (3c).
- the user may confirm the emergency information. Can not.
- the receiving device 30 receives the signaling data immediately after the transmission processing by the transmitting device 20 and does not perform the display processing. There is a possibility that the emergency information confirmation process by the (viewer) is delayed and the safety of the user cannot be secured.
- the present disclosure realizes a configuration that prevents the occurrence of such a problem and enables the user (viewer) to confirm emergency information reliably and immediately (timely).
- the broadcast server 21 transmits an AV segment made up of broadcast contents, signaling data, and other data by broadcast waves or broadcast transmission via a network.
- the data distribution server 22 which is a transmitting apparatus other than the broadcast server 21 also transmits AV segments, signaling data, and other data composed of broadcast contents and the like by broadcast transmission via the network.
- the tuner-implemented receiving apparatus 30 includes a middleware 110, an HTTP proxy server 120, a playback control unit (DASH client) 131, an output control unit 132, and an application control unit 140.
- a middleware 110 As shown in FIG. 10, the tuner-implemented receiving apparatus 30 includes a middleware 110, an HTTP proxy server 120, a playback control unit (DASH client) 131, an output control unit 132, and an application control unit 140.
- DASH client playback control unit
- the middleware 110 receives the data provided by the broadcast server 21 and analyzes it.
- the middleware 110 has the following components. Communication unit (PHY / MAC) 111, LLS signaling acquisition unit 112, LLS signaling analyzer 113, SLS signaling acquisition unit 114, SLS signaling analysis unit (MPD event insertion unit) 115, Segment acquisition unit 117, In-band event insertion unit 118.
- the communication unit (PHY / MAC) 111 receives data provided by the broadcast server 21 via broadcast waves.
- An LLS signaling acquisition unit 112 and an LLS signaling analysis unit 113 receive and analyze lower layer signaling data (LLS) received via the communication unit 111.
- the SLS signaling acquisition unit 114 and the SLS signaling analysis unit 115 receive and analyze service level signaling data (SLS) received via the communication unit 111.
- the segment acquisition unit 117 acquires a segment that stores program content data such as video and audio, NRT content such as an application, and data such as signaling data.
- the SLS signaling analysis unit 115 also functions as an MPD event insertion unit.
- the SLS signaling analysis unit 115 includes notification information such as changes and details of broadcast programs and transmission data, information related to applications executed in the receiving device, and information on processing necessary in the receiving device such as emergency information related information. It functions as an MPD event insertion unit that executes processing for inserting event information into MPD (Media Presentation Description) that is signaling data.
- An in-band event insertion unit 118 executes processing for inserting event information such as emergency information into a segment.
- the event information includes, for example, information to be notified to the receiving device, such as a change in the program table, a change in the data mode of the broadcast content, and a processing to be executed when the broadcast content is reproduced in the receiving device, and execution of some processing.
- Information to request includes, for example, information to be notified to the receiving device, such as a change in the program table, a change in the data mode of the broadcast content, and a processing to be executed when the broadcast content is reproduced in the receiving device, and execution of some processing.
- emergency information and event information related to emergency information related information are newly set as this event information, an event notification using this event information is performed, and prompt and reliable display of emergency information in the receiving device is performed.
- data processing for realizing is performed. Specifically, for example, when the application presentation content described above with reference to FIG. 7 is displayed, event information storing the request for exclusion processing of the presentation content is transmitted to notify the event.
- event information storing emergency information related information for notifying the issue status of emergency messages transmitted as signaling data and access information is provided to the client, enabling quick acquisition and display of emergency information.
- the data received by the middleware 110 is stored in the cache unit (proxy cache) 121 of the proxy server 120.
- the proxy server 120 further stores data acquired from the data distribution server 22 via the network in the cache unit (proxy cache) 122.
- the proxy server 120 inputs data requests from, for example, the reproduction control units (DASH clients) 131 and 151, the application control units 133 and 153, the emergency information control units 140 and 160, and the like to the address resolution unit 123, and sends the requested data. It is acquired from the cache unit (proxy cache) 121, 122 or the outside and provided.
- a playback control unit (DASH client) 131 executes playback control of content transmitted according to the DASH (MPEG-DASH) standard.
- the MPEG-DASH standard includes the following two standards.
- A a standard concerning a manifest file (MPD: Media Presentation Description) for describing metadata that is management information of a moving image or an audio file
- B Standards related to file format (segment format) for video content transmission; Content distribution from the transmission device 20 to the tuner-mounted reception device 30 is executed in accordance with the MPEG-DASH standard.
- the content is transmitted as a segment which is a predetermined unit of divided data in accordance with, for example, an MP4 file format defined in MPEG, and the reproduction control unit (DASH client) 131 refers to the manifest file (MPD) to select the content to be reproduced. Execute processing to acquire the stored segment.
- MPD manifest file
- the playback control unit (DASH client) 131 further includes an event extraction unit that extracts events stored in, for example, MPDs and segments, and notifies the application control unit 133 and the emergency information control unit 140 of the events.
- the event information to be notified includes, for example, event information including request for processing to be executed on the receiving device side and information for enabling processing in accordance with transmission of emergency information from the transmitting device. A specific example of processing using these event information will be described in detail later.
- the output control unit 132 takes out the encoded content from the segment acquired by the reproduction control unit, decodes it, and outputs it to an output unit such as a display unit.
- the application control unit 133 acquires various applications for executing news, player information at the time of baseball broadcast, map information in a travel program, hotel information, quizzes, questionnaire processing, etc. Execute application control such as application start and end. Furthermore, the application control unit 133 executes, for example, the application presentation content display process and the removal process described with reference to FIG. 7 according to the event information extracted by the event extraction unit of the reproduction control unit 131.
- the emergency information control unit 140 also executes signaling data application type emergency information acquisition processing described with reference to FIG. 8 according to the event information extracted by the event extraction unit of the reproduction control unit 131, for example. Details of the process to which the event information is applied will be described later.
- the tuner non-implementation receiving apparatus (client B) 40 shown in FIG. 10 is connected to the tuner implementation receiving apparatus (client A) 30 via a network such as Ethernet (registered trademark) or Wi-Fi, for example, and the tuner implementation receiving apparatus. (Client A) Communication with 30 is executed.
- the tuner non-implementation receiving device (client B) 40 is a tuner-implemented receiving device (client A) 30 that receives data such as content received by the tuner-implemented receiving device (client A) 30 from the broadcast server 21 or the data distribution server 22. To receive the content and execute the content reproduction.
- FIG. 11 shows that the tuner-mounted receiving device (client A) 30 has Playback control unit (DASH client) 131, An output control unit 132; Application control unit 133, Emergency information control unit 140,
- the tuner non-mounting receiving apparatus (client B) 40 has, Playback control unit (DASH client) 151, Output controller 152, Application control unit 153, Emergency information control unit 160, It is a figure which shows these detailed structures.
- the playback control unit (DASH client) 131 of the tuner-implemented receiving apparatus (client A) 30 includes an MPD acquisition unit 201, an MPD analysis unit 202, a segment acquisition unit 203, a segment (MP4) analysis unit 204, and an event extraction unit 205. .
- the playback control unit (DASH client) 131 executes playback control of content transmitted according to the DASH (MPEG-DASH) standard.
- the MPD acquisition unit 201 acquires a manifest file (MPD: Media Presentation Description), which is a management information description file for moving images and audio files.
- MPD is provided from the broadcast server 21 and the data distribution server 22, stored in the proxy server 120, and then acquired by the playback control unit 131.
- the MPD analysis unit 202 analyzes the description content of the MPD acquired by the MPD acquisition unit 201, and provides the segment acquisition unit with information necessary for acquiring a segment corresponding to the reproduction target data. Further, the MPD analysis unit 202 outputs the MPD to the event extraction unit 205 when the event information is included in the MPD.
- the event extraction unit 205 analyzes the event information recorded in the MPD, and the event information is (A) On-screen message (OnScreenMessage) type emergency information has been distributed; (B) Signaling data application type emergency information has been distributed; It is determined whether the event information includes the notification data (a) or (b).
- the event extraction unit 205 determines that the event information is event information indicating “(a) On-screen message (OnScreenMessage) type emergency information has been distributed”, the event extraction unit 205 sends the event information to the application control unit 133. Output.
- the event extraction unit 205 determines that the event information is event information indicating that “(b) signaling data application type emergency information has been distributed”, the event extraction unit 205 displays the event information as an emergency information control unit 140, Alternatively, the data is output to the application control unit 133.
- the application control unit 133 confirms the application execution state.
- the application presentation content described with reference to FIG. 7 is presented on the program content, processing for removing the application presentation content is executed.
- the emergency information control unit 140 receives the emergency information stored in the input event information, Alternatively, signaling data (signaling data such as AEAT and CAP) is reliably acquired using the access information of emergency information, and output control for the display unit is performed. , With this processing, when signaling data application-type emergency information is distributed, the emergency information can be immediately acquired and reliably shown to the user.
- the application control unit 133 may be configured to execute the process as the emergency information control unit 140.
- the event extraction unit 205 indicates that “(b) signaling data application type emergency information has been distributed. Is output to the application control unit 133.
- the segment acquisition unit 203 acquires a segment corresponding to the reproduction target data according to the MPD analysis result of the MPD analysis unit 202.
- a segment is predetermined unit data set according to a file format (segment format) for content transmission composed of AV data.
- the segment analysis unit 204 acquires encoded image data, encoded audio data, and the like from the segment acquired by the segment acquisition unit 203, and outputs them to the decoding unit (decoder) 211 of the output control unit 132.
- segment analysis unit 204 outputs the segment to the event extraction unit 205 when event information is included in the segment.
- the event extraction unit 205 analyzes the event information stored in the segment, and the event information (A) On-screen message (OnScreenMessage) type emergency information has been distributed; (B) Signaling data application type emergency information has been distributed; It is determined whether the event information includes the notification data (a) or (b).
- OnScreenMessage On-screen message
- B Signaling data application type emergency information has been distributed
- the event extraction unit 205 determines that the event information is event information indicating “(a) On-screen message (OnScreenMessage) type emergency information has been distributed”, the event extraction unit 205 sends the event information to the application control unit 133. Output.
- the event extraction unit 205 determines that the event information is event information indicating that “(b) signaling data application type emergency information has been distributed”, the event extraction unit 205 displays the event information as an emergency information control unit 140, Alternatively, the data is output to the application control unit 133.
- the processes of the application control unit 133 and the emergency information control unit 140 that have received these event information are the same as the processes when the MPD storage event information is received.
- the output control unit 132 of the tuner-implemented receiving apparatus (client A) 30 includes a decoding unit (decoder) 211 and an output unit (renderer) 212.
- the decoding unit (decoder) 211 executes a decoding process (tercode) of the encoded image data and the encoded audio data provided from the segment analysis unit 204.
- the output unit 212 outputs the decoded image data and audio data to the output unit (display, speaker).
- the playback control unit (DASH client) 151 of the tuner non-implemented receiving apparatus (client B) 40 includes an MPD acquisition unit 251, an MPD analysis unit 252, a segment acquisition unit 253, a segment (MP4) analysis unit 254, and an event extraction unit. 255.
- the output control unit 152 includes a decoding unit (decoder) 261 and an output unit (renderer) 262. These configurations and the processing to be executed are the same as the configuration and processing of the tuner-implemented receiving apparatus (client A) 30.
- the MPD and the segment are input to the reproduction control unit (DASH client) 151 of the tuner non-implemented receiver (client B) 40 via the proxy server 120 of the tuner-equipped receiver (client A) 30 and the network.
- the application file is input to the application control unit 153 of the tuner non-implementation receiving apparatus (client B) 40 via the proxy server 120 of the tuner implementation receiving apparatus (client A) 30 and the network.
- the playback control units (DASH clients) 131 and 151 of the tuner-mounted receiver (client A) 30 and the tuner-unmounted receiver (client B) 40 are execution units of the ATSC 3.0 client application (3.0 DASH client). is there.
- the ATSC 3.0 client application runs on a browser implemented on the ATSC 3.0 broadcast receiving client device. Alternatively, it may be executed not only as a browser application but also as a native application.
- the ATSC 3.0 client application executed by the playback control units (DASH clients) 131 and 151 includes an ATSC 3.0 DASH client application (3.0 DASH client), an ATSC 3.0 stream application (3.0 Application), and the like. . Further, as a native application, an application manager (“3.0 Application Manager”) that performs life cycle control of these Web applications, an AEAT message renderer application (“CAP Message Renderer”), and the like are included.
- the ATSC 3.0 client application of the playback control unit (DASH client) 131, 151, and the output control unit 132, 152 are the data received by the middleware (Client Local ATSC Middleware) 110, the proxy server (Client Local HTTP Proxy Server) 120 Processing of data received via the network is executed.
- middleware Clientt Local ATSC Middleware
- proxy server Clientt Local HTTP Proxy Server
- DASH-MPD file DASH segment file
- other general application files other general application files
- SLS Service level Signaling file that stores the signaling data obtained by the middleware 110 or the proxy server 120, and the stream Render and control applications.
- This model always accesses the outside world via the proxy server 120 from the ATSC 3.0 client application executed by the playback control units (DASH clients) 131 and 151 and the application executed by the application control unit 160. It is possible to increase the portability of the application because there is no awareness of whether the files are acquired via broadcasting or via the Internet (network transparency is provided). Become. Therefore, there is no need to install an application specifically for broadcasting, and broadcasting can be implemented regardless of which of the Internet is used.
- ATSC 3.0 client application executed by playback control unit (DASH client) 131, 151 requests acquisition of DASH-MPD file, DASH segment file, other general application files, and signaling data file (HTTP request) Then, the proxy server 120 receiving it determines whether to acquire via the broadcast reception stack or via the network in the address resolution unit (Broadcast / Broadband Address Resolver) 123.
- DASH client playback control unit
- 151 requests acquisition of DASH-MPD file, DASH segment file, other general application files, and signaling data file (HTTP request) Then, the proxy server 120 receiving it determines whether to acquire via the broadcast reception stack or via the network in the address resolution unit (Broadcast / Broadband Address Resolver) 123.
- SLS Signaling Parser SLS Signaling Analysis unit
- SLS Signaling Parser makes an acquisition request to the SLS signaling acquisition unit (SLS Signaling Retriever) 114 for USBD / USD, S-TSID, and the like, which are ATSC 3.0 signaling meta.
- the SLS signaling acquisition unit (SLS Signaling Retriever) 114 extracts the signaling meta carried by the SLS LCT packet broadcast-received via the communication unit (ATSC tuner: ATSC 3.0 PHY / MAC) 111.
- the SLS signaling analysis unit (SLS Signaling Parser) 114 also extracts the signaling meta from the url included in the segment or application part acquisition request, and resolves the broadcast distribution address information for acquiring the target file. . If it is known that the broadcast is distributed, the LCT packet storing the desired file is acquired from the broadcast stream based on the broadcast distribution address information and stored in the cache (Proxy Cache) units 121 and 122. expand.
- the proxy server 120 returns the file to the reproduction control unit 131 and the application control unit 140 (as an HTTP response). If the URL included in the application part acquisition request is not in the signaling meta, the proxy server 120 acquires the file via a normal net stack.
- the SLS signaling analysis unit (SLS Signaling Parser) 114 also has a function as an MPD event insertion unit (MPD Event Inserter).
- An MPD event is one of DASH events. DASH events are transferred by DASH MPD or DASH segment, and events scheduled in advance or unscheduled in the streaming protocol (event activation time is undecided) It is a mechanism to control.
- DASH event transfer methods There are the following two types of DASH event transfer methods.
- A an MPD applied event notification method in which event information is inserted and transferred into MPD (Media Presentation Description) which is signaling data
- B A segment application (In-band) event notification method in which event information is inserted into a segment and transferred; There are these two types.
- the event information is inserted into the MPD (Media Presentation Description) that is signaling data and transferred is the MPD event insertion unit in the SLS signaling analysis unit 115, and the event information is inserted into the segment and transferred.
- the following notification information is transmitted to the receiving device using the signaling data (LLS: Lower Layer Signaling) transmitted by the broadcast server 21.
- LLS Lower Layer Signaling
- On-screen message OnScreen Message
- type emergency information has been distributed (on-screen message notification: On Screen Message Notification)
- Notification that signaling data applied emergency information (AEAT, CAP, etc.) has been distributed: (AEAT Message Notification)
- AEAT is described as a representative example as signaling data application type emergency information.
- the processing of the present disclosure is not limited to AEAT, and similar processing is possible for various signaling data applied emergency information having a data format other than AEAT.
- the AEAT data format will be described later.
- the LLS signaling acquisition unit 112 and the LLS signaling analysis unit 113 of the middleware 110 of the tuner implementation receiving device 30 extract notifications regarding these emergency information from the signaling data (LLS) transmitted from the transmission device such as the broadcast server 21,
- the extracted notification data is input to the MPD event insertion unit in the SLS signaling analysis unit 115.
- the MPD event insertion unit in the SLS signaling analysis unit 115 inserts these notification data into the MPD
- the in-band event insertion unit 118 inserts these notifications into the segment.
- the MPD and the segment in which the event information is inserted are input to the playback control units (DASH clients) 131 and 151 through the cache unit 121, for example.
- DASH clients playback control units
- the transmitting device 20 such as the broadcast server 21 transmits the following notification information to the receiving device using signaling data (LLS: Lower Layer Signaling).
- LLS Lower Layer Signaling
- A On-screen message type emergency information delivery notification (On Screen Message Notification)
- B Signaling data application type emergency information delivery notification (AEAT Message Notification)
- LLS Lower Layer Signaling
- the signaling data includes different types of signaling data using the following two different layers.
- LLS lower layer signaling
- SLS Service Level Signaling
- SLS Service Level Signaling
- LLS is signaling data storing control information, guidance information, metadata, etc. for each service unit, for example, each program unit.
- LLS low layer signaling
- LLS is signaling data storing control information, guidance information, metadata, and the like higher than SLS, and includes information for acquiring SLS, for example.
- the middleware 110 of the tuner-implemented receiving apparatus 30 shown in FIG. 10 executes acquisition and analysis processing of signaling data such as LLS (lower layer signaling) and SLS (service level signaling).
- the LLS signaling acquisition unit 112 and the LLS signaling analysis unit 113 of the middleware 110 illustrated in FIG. 10 execute LLS (lower layer signaling) acquisition and analysis processing.
- SLS signaling acquisition unit 114 and the SLS signaling analysis unit (MPD event insertion unit) 115 of the middleware 110 shown in FIG. 10 execute SLS (service level signaling) acquisition and analysis processing.
- the LLS signaling acquisition unit 112, the LLS signaling analysis unit 113, the SLS signaling acquisition unit 114, and the SLS signaling analysis unit (MPD event insertion unit) 115 of the middleware 110 illustrated in FIG. 10 always receive the signaling data transmitted from the transmission device 20. If the monitoring and unprocessed signaling data is detected, it is immediately acquired and analyzed. As described above, the transmission device 20 repeatedly transmits signaling data, and the middleware 110 can acquire and analyze new signaling data without causing a large delay.
- the following emergency information delivery notification data may be included in LLS (lower layer signaling) that is signaling data transmitted by the transmission device 20.
- LLS lower layer signaling
- On-screen message type emergency information delivery notification data On Screen Message Notification
- B Signaling data application type emergency information delivery notification data (AEAT Message Notification)
- FIG. 12 is a detailed configuration example of signaling data (LLS) including “(a) On-screen message type emergency information delivery notification data (On Screen Message Notification)”. On-screen message type emergency information delivery notification data is described as XML data.
- the data shown in FIG. 12 is a hierarchical configuration diagram of XML data in which XML data is shown as a hierarchical configuration.
- the on-screen message type emergency information delivery notification data includes, for example, the following data.
- Emergency information application target service identifier (2) Emergency information application target service identifier
- Screen clear execution target service identifier range (4) Screen clear execution period (5) Screen clear processing necessity flag
- the screen clear process is a process of setting the broadcast content to be viewable by stopping the display of the overlay content on the screen such as the application-presented content as described with reference to FIG.
- FIG. 13 is a detailed configuration example of “(b) signaling data application type emergency information delivery notification data (AEAT Message Notification)”. Signaling data application type emergency information delivery notification data is also described as XML data.
- the data shown in FIG. 13 is a hierarchical configuration diagram of XML data showing the XML data as a hierarchical configuration.
- the signaling data application type emergency information delivery notification data includes, for example, the following data.
- the middleware 110 of the tuner-implemented receiver 30 shown in FIGS. 10 and 11 obtains and analyzes the signaling data (LLS) including the emergency information related data shown in FIGS. It becomes possible to know without delay.
- LLS signaling data
- On-screen message type emergency information delivery notification On Screen Message Notification
- B Signaling data application type emergency information delivery notification (AEAT Message Notification)
- the reproduction processing of the program content transmitted by the transmission device 20 such as the broadcast server 21 is executed by the tuner-mounted reception device 30 shown in FIGS. (DASH clients) 131 and 151.
- the application-presenting content presentation process described with reference to FIG. 7 is executed by the tuner-mounted receiving device 30 shown in FIGS. 10 and 11 and the application control unit 133 of the tuner-unmounted receiving device 40. , 153.
- the playback control units (DASH clients) 131 and 151 continuously execute HTTP acquisition of DASH segments that store playback data such as images and sounds that are program data constituent data. Therefore, once streaming playback is started, the DASH client continuously performs HTTP acquisition / playback processing.
- the playback control units (DASH clients) 131 and 151 execute a pull-type communication session that is always connected to the middleware 110 or the proxy server 120 that performs the function as the DASH server that provides the DASH segment, and obtains necessary data. Acquisition and reproduction processing, for example, output of broadcast content. In this segment acquisition session, it becomes a problem to be able to transmit any signaling update event notification or the signaling itself.
- the emergency information delivery notification by the signaling data (LLS) described above using the event (Event) mechanism defined in DASH that is, (A) On-screen message type emergency information delivery notification (On Screen Message Notification), (B) Signaling data application type emergency information delivery notification (AEAT Message Notification), The notification information is provided without delay to the tuner-mounted receiving device 30 shown in FIGS. Realize.
- DASH that operates on another device connected via a device and a network (home network (LAN / WiFi, etc.) in the home, WiFi, etc. in the hot spot) that implements the ATSC 3.0 broadcast receiving middleware by the processing of the present disclosure
- a network home network (LAN / WiFi, etc.) in the home, WiFi, etc. in the hot spot) that implements the ATSC 3.0 broadcast receiving middleware by the processing of the present disclosure
- client applications such as players and AEAT parsers and viewers
- the application presentation data that has been superimposed on the emergency message displayed on the moving image screen while being synchronized with the stream is excluded, for example, AEAT Additional information such as emergency information and map information sent separately from the moving image stream can be provided and output without delay.
- the DASH standard defines an event notification mechanism called a DASH event (DASH Event).
- the event notification mechanism includes, for example, notification information such as changes and details of broadcast programs and transmission data, information on applications executed in the reception device, information to be notified to the reception device, information on processing required in the reception device, and the like. This is a mechanism for notifying event information.
- MPD Event is a method for notifying an event using MPD (Media Presentation Description) which is one of the signaling data defined in the DASH standard.
- EventStream event stream
- Period period
- MPD Event information necessary for event processing can be provided to the client in units of periods using the MPD.
- A) Event schedule such as activation (start / execution / activation) timing of various events
- FIG. 14 is a diagram showing a format of MPD.
- the MPD has a configuration capable of describing information such as attributes and control information in units of the following specified ranges for each stream of images and audio.
- Period Period
- Adaptation that defines data types such as images and sounds
- Representation that defines image type, audio type, etc.
- SegmentInfo which is an information recording area in units of video and audio segments (AV segments)
- FIG. 15 is a diagram in which AV segment-compatible information (control information, management information, attribute information, etc.) recorded in the MPD is developed in time series. Assume that time elapses from left to right. This time axis corresponds to, for example, the playback time of AV content in the receiving device.
- MPD is a part of signaling data and is transmitted, for example, prior to an AV segment.
- MPD can record information in the following data units.
- Period Period
- Adaptation that defines data types such as images and sounds
- Representation that defines image type, audio type, etc.
- SegmentInfo Segment Info which is an information recording area in units of video and audio segments (AV segments)
- FIG. 15 is a diagram showing these data areas expanded by time axis and data type.
- FIG. 15 shows the following two adaptations.
- V Adaptation V (Adaptation (V)) which is an image corresponding information recording area
- A Adaptation A (Adaptation (A)), which is a voice-corresponding information recording area
- V Adaptation V
- V1 which is an information recording area corresponding to a low bit rate image
- V2 Representation (V2)
- V2 Representation (V2)
- Adaptation A which is an audio image-corresponding information recording area, has the following two representations (Representation) as information recording areas in units of streams having different attributes.
- A1 Representation (A1) which is an information recording area for Japanese voice
- A2) Representation (A2) Representation (A2)
- A2 Representation (A2)
- each representation has a structure that can record information in a period corresponding to a playback time axis and further in a segment unit.
- a receiving device that selects and reproduces a high bit rate image and Japanese speech reproduces information related to the high bit rate image and Japanese speech to be reproduced when the segment (11) of period 1 is reproduced. Select from to get.
- the MPD recording information to be selected becomes the information of the segment areas 301 and 302 shown in the figure.
- the receiving device selects and references only information corresponding to data (segment) to be reproduced by the own device from the MPD transmitted from the transmitting device as signaling data.
- the MPD including event information has the following description, for example.
- This data recording / recording area is a recording area for the start time information of the first period corresponding to the data recorded in the MPD. For example, UTC time is used as the time information.
- This data recording recording area is a period start time information recording area.
- the offset time from the start time (MPD / @ availabilityStartTime) defined in MPD is recorded.
- This data recording / recording area is a recording area for event stream designation information indicating an event type or the like and time scale information.
- the event type and the like are defined by “EventStream schemeIdUri'urn: xxx ′” and the optional “EventStream / @ value”.
- timescale “ 1000 ” indicates that the unit time of the presentation time (presentationTime) recorded below is 1/1000 second.
- Event data 1 ⁇ / Event>
- This data recording / recording area is a recording area for event data, and a recording area for event scheduling data such as event activation (execution start) time and duration.
- the event data is composed of data such as entity data, metadata, commands, etc. necessary for executing the event, access information thereof, and the like. Further, the activation time (such as start of execution) and duration of the event are recorded.
- Event data 1 ⁇ / Event>
- This data recording / recording area is also a recording area for event data, and a recording area for event scheduling data such as event activation (execution start) time and duration.
- the event data is composed of data such as entity data, metadata, commands, etc. necessary for executing the event, access information thereof, and the like. Further, the activation time (such as start of execution) and duration of the event are recorded.
- ⁇ AdaptationSet> ⁇ Representation /> ⁇ Representation /> These are data recording areas for recording information for each data type.
- EventStream / @ schemeIdUri and optional EventStream / @ value
- attributes define the event type
- Event data that is, data such as entity data, metadata, and commands necessary for executing the event, access information thereof, and the like can be added to the content part of the EventStream / Event element.
- Event stored as data elements below MPD / Period / EventStream / Event (what to store) is the value of the “EventStream / @ schemIdUri” attribute ((urn in the example of FIG. 16) : Xxx) is specified (defined).
- MPD Event is applicable only when the contents of a period described in the MPD can be determined before sending the MPD.
- FIG. 17 is a diagram for explaining the procedure of MPD analysis processing (parsing) executed in the receiving apparatus.
- FIG. 17 shows the following figures. (1) MPD (2) Period unit information (3) Representation unit information (4) Segment unit information
- a receiving device that receives an AV segment and executes playback processing of AV content acquires MPD included in signal link data received in advance before receiving the AV segment, and corresponds to data to be played back on the self-running land. Get information from MPD.
- period unit information having a specific period (information recorded) corresponding to the AV segment playback time is selected. Further, representation unit information corresponding to the type of data to be reproduced in the own apparatus (client) is selected, and (4) segment unit information corresponding to the reproduction target segment is selected. With reference to the data recorded in (4) segment unit information, it is possible to acquire an AV segment to be played back and various information necessary for AV segment playback.
- the receiving device activates a specified event (event activation processing such as execution and start) according to the recorded event information. become.
- an event insertion execution device 310 that executes generation (or acquisition) and output of MPD that records event information, and an event that receives event recording MPD and executes processing according to MPD recording event information.
- the configuration and processing example of the execution device 320 will be described.
- FIG. 18 shows an event insertion execution device 310 that executes generation (or acquisition) and output of an MPD in which event information is recorded on the left side. Further, the right side of FIG. 18 shows an event execution device 320 that inputs an MPD in which event information is recorded and executes processing (event activation) according to the event information recorded in the MPD.
- the event insertion execution device 310 receives the signaling data such as MPD, the signaling data such as MPD, and the AV segment at the broadcast server 21, the data distribution server 22, or the receiving device that transmits the AV segment.
- This is the middleware 110 (middleware 110 shown in FIGS. 10 and 11) of the receiving device that is output to the reproduction control unit 131 of the receiving device.
- the event execution device 320 shown on the right side of FIG. 18 specifically has a playback control unit (FIGS. 10 and 11) of a receiving device that inputs signaling data such as MPD and AV segments and executes content playback processing.
- a playback control unit (FIGS. 10 and 11) of a receiving device that inputs signaling data such as MPD and AV segments and executes content playback processing.
- the event insertion execution device 310 includes a data output unit (DASH server) 311 and an event processing unit (event server) 312. Note that these server functions are functions of signaling data such as MPD, broadcasting server 21 that transmits AV segments, data distribution server 22, and middleware 110 (middleware 110 shown in FIGS. 10 and 11) of the receiving device. It is. Hereinafter, processing executed by the event insertion execution device 310 will be described for each processing step.
- DASH server data output unit
- event server event processing unit
- Step S11 First, in step S11, the data output unit (DASH server) 311 of the event insertion execution apparatus 310 generates or acquires a segment including MPD as signal link data and AV data constituting playback content.
- DASH server data output unit
- the event insertion execution device 310 is the broadcast server 21 or the data distribution server 22, a process for generating or acquiring an MPD and a segment is performed.
- the event insertion execution device 310 is the middleware 110 of the receiving device (middleware 110 shown in FIGS. 10 and 11), the MPD and the segment are acquired from the received data.
- Step S12 the event processing unit (event server) 312 of the event insertion execution device 310 generates or acquires event information.
- Event information is, for example, a notification or request for execution of some processing to the receiving device, such as a change in the program guide, a change in the data mode of the broadcast content, or a processing to be executed when the broadcast content is reproduced in the receiving device. It is information for.
- the event insertion execution device 310 When the event insertion execution device 310 is the broadcast server 21 or the data distribution server 22, a process for generating or acquiring event information is performed. When the event insertion execution device 310 is the middleware 110 of the receiving device (middleware 110 shown in FIGS. 10 and 11), processing for acquiring event information from the received data is performed.
- Step S13 the data output unit (DASH server) 311 of the event insertion execution device 310 inserts event information into the MPD as signal link data in step S13.
- the event information recording MPD described above with reference to FIG. 16 is generated.
- the event type, contents, event activation time, duration information, and the like are recorded.
- the receiving device can activate (e.g., execute) a specified event at a specified time according to the event information recorded in the MPD, and perform a process for continuing the specified event for a specified duration.
- Step S14 the data output unit (DASH server) 311 of the event insertion execution device 310 transmits (outputs) the event information recording MPD in which the event information is recorded in the MPD as the signal link data.
- DASH server data output unit 311 of the event insertion execution device 310
- the event information recording MPD is transmitted via a broadcast wave or a network.
- the event insertion execution device 310 is the middleware 110 of the receiving device (middleware 110 shown in FIGS. 10 and 11)
- the event information recording MPD is output to the proxy server or the playback control unit.
- Steps S15 to S16 Next, the data output unit (DASH server) 311 of the event insertion execution device 310 transmits (outputs) the segment storing the AV content and the like in steps S15 to S16.
- the segment transmission is continuously executed after step S16.
- the segment is transmitted via a broadcast wave or a network.
- the event insertion execution device 310 is the middleware 110 of the receiving device (middleware 110 shown in FIGS. 10 and 11)
- the segment is output to the proxy server or the playback control unit.
- the event execution device 320 receives the playback data of MPD or the like, or the playback control unit (reproduction control units 131 and 151 shown in FIGS. ).
- the process executed by the event execution device 320 illustrated in FIG. 18 is a process executed by the reproduction control units 131 and 151 of the reception device.
- the playback control unit is illustrated as being separated in units of processing types corresponding to the types of processing to be executed. Specifically, a playback control unit (event client) 321 as an event response processing execution unit, a playback control unit (DASH client) 322 that executes content playback processing using MPD and AV segments, and these two processing units Show.
- Step S21 First, the playback control unit (DASH client) 322 of the event execution device 320 makes an MPD acquisition request as signal link data to the event insertion execution device 310 in step S21.
- DASH client DASH client
- Step S22 the playback control unit (DASH client) 322 of the event execution device 320 acquires event information from the MPD acquired from the event insertion execution device 310 in step S22.
- the MPD acquired here is the event information recording MPD, that is, the event information MPD shown in FIG.
- the event information recording MPD records the type and content of the event, the activation time (for example, activation of execution, stop, etc.) of the event, duration information, and the like.
- the receiving device can activate (e.g., execute) a specified event at a specified time according to the event information recorded in the MPD, and perform a process for continuing the specified event for a specified duration.
- Step S23 the reproduction control unit (event client) 321 of the event execution device 320 performs event application scheduling processing according to the event information acquired from the MPD in step S23.
- the event information recording MPD records the type and content of the event, the activation time of the event, the duration information, and the like, and the playback control unit (event client) of the event execution device 320.
- Reference numeral 321 refers to these pieces of information and performs event execution scheduling processing.
- Step S24 Next, the playback control unit (DASH client) 322 of the event execution device 320 makes a segment acquisition request to the event insertion execution device 310 in step S24.
- Step S25 the playback control unit (DASH client) 322 of the event execution device 320 acquires AV content and the like from the segment acquired in step S24 and executes playback processing.
- DASH client DASH client
- Step S26 the playback control unit (event client) 321 of the event execution device 320 performs an event application process scheduled according to the event information acquired from the MPD, that is, an event activation (event execution, start, etc.) process. .
- Steps S27 to S29 The processes in steps S27 to S29 are the same as the processes in steps S24 to S26. This series of processing is continuously executed.
- the reception device can execute various events according to the event information recorded in the MPD in conjunction with the process of receiving and playing back the AV segment.
- In-band Event Signaling is another event notification method defined in the DASH standard
- the transmission device 20 shown in FIG. 1 encodes content data, generates a data file including the encoded data and the metadata of the encoded data, and transmits the data file.
- the encoding process is performed in accordance with, for example, an MP4 file format defined in MPEG.
- the transmission apparatus 20 When the transmission apparatus 20 generates an MP4 format data file, the encoded data file is called “mdat”, and the metadata is called “moov” or “moof”.
- the content provided by the transmission apparatus 20 is various data such as music data, video data such as movies, television programs, videos, photos, documents, pictures and charts, games and software.
- the initialization segment is a segment that stores initialization data such as setting information necessary for executing content reproduction, such as setting of a decoder in the receiving device 30.
- a media segment is a segment that stores encoded content (AV content) to be reproduced.
- the initialization segment includes the following pieces of information.
- the (b) media segment includes the following pieces of information as shown in FIG. (B1) Header information (msdh) including segment file type information, etc. (B2) Access information (sidx) indicating boundary information of a plurality of sub-segments (Sub-Segment) stored in the media segment, random access points of media data (mdat) that is encoded content stored in the media segment, etc. ), (B3) A plurality of sub-segments (Sub-Segment),
- a plurality of sub-segments is composed of one or a plurality of fragments (Fragments).
- the fragment includes the following data.
- Media data (mdat) that is encoded content to be played back
- Metadata (moof) corresponding to media data (mdat)
- Various information control information, management information, attribute information, etc. corresponding to the media data (mdat).
- Media data (mdat), metadata (moof), and other various information (control information, management information, attribute information, etc.) are individually stored in boxes defined in the MP4 format.
- AV data is stored in the mdat box.
- Metadata is stored in the moof box.
- Various other information is also stored in boxes defined according to the respective information.
- Event information is stored in an event information storage box [emsg box] defined in the MP4 format as a box for storing event information as a part of various information.
- FIG. 20 shows data in two event information storage boxes (emsg) in which two event information of event identifiers 1 and 2 are individually stored.
- the event information storage box (emsg) has the following description, for example.
- box_type 'emsg' This data recording / recording area is a box type recording area. It is described that this box (data storage box defined in MP4) is an event information storage box (emsg).
- This data recording / recording area is a recording area for event designation information indicating an event type or the like.
- event_duration 0xFFFF
- This data recording area is an event identification information recording area.
- message_data [] event data-1
- This data recording area is an event data recording area.
- the event data is composed of data such as entity data, metadata, commands, etc. necessary for executing the event, access information thereof, and the like.
- event information can be recorded and transferred in the segment stream (in-stream).
- event type can be defined in the “scheme_id_uri” field and the optional “value” field.
- event data that is, data such as entity data, metadata, and commands necessary for executing the event, access information thereof, and the like can be added to the “message_data” field.
- an event insertion execution device 310 that executes generation (or acquisition) and output of a segment in which event information is recorded, and event information recorded in the segment after receiving the event recording information segment.
- the configuration and processing example of the event execution device 320 that executes the corresponding processing will be described.
- FIG. 21 shows an event insertion execution device 310 that executes generation (or acquisition) and output of a segment in which event information is recorded on the left side. Further, the right side of FIG. 21 shows an event execution device 320 that inputs a segment in which event information is recorded and executes processing (event activation) according to the event information recorded in the segment.
- the event insertion execution device 310 receives the signaling data such as MPD, the signaling data such as MPD, and the AV segment at the broadcast server 21, the data distribution server 22, or the receiving device that transmits the AV segment.
- This is the middleware 110 (middleware 110 shown in FIGS. 10 and 11) of the receiving device that is output to the reproduction control unit 131 of the receiving device.
- the event execution device 320 shown on the right side of FIG. 21 specifically has a playback control unit (FIGS. 10 and 11) of a receiving device that inputs signaling data such as MPD and AV segments and executes content playback processing.
- a playback control unit FIG. 10 and 11
- the event insertion execution device 310 includes a data output unit (DASH server) 311 and an event processing unit (event server) 312. Note that these server functions are functions of signaling data such as MPD, broadcasting server 21 that transmits AV segments, data distribution server 22, and middleware 110 (middleware 110 shown in FIGS. 10 and 11) of the receiving device. It is. Hereinafter, processing executed by the event insertion execution device 310 will be described for each processing step.
- DASH server data output unit
- event server event processing unit
- Step S31 First, in step S31, the data output unit (DASH server) 311 of the event insertion execution apparatus 310 generates or acquires a segment including MPD as signal link data and AV data constituting playback content.
- DASH server data output unit
- the event insertion execution device 310 is the broadcast server 21 or the data distribution server 22, a process for generating or acquiring an MPD and a segment is performed.
- the event insertion execution device 310 is the middleware 110 of the receiving device (middleware 110 shown in FIGS. 10 and 11), the MPD and the segment are acquired from the received data.
- Event information is, for example, a notification or request for execution of some processing to the receiving device, such as a change in the program guide, a change in the data mode of the broadcast content, or a processing to be executed when the broadcast content is reproduced in the receiving device. It is information for.
- the event insertion execution device 310 When the event insertion execution device 310 is the broadcast server 21 or the data distribution server 22, a process for generating or acquiring event information is performed. When the event insertion execution device 310 is the middleware 110 of the receiving device (middleware 110 shown in FIGS. 10 and 11), processing for acquiring event information from the received data is performed.
- Step S33 the data output unit (DASH server) 311 of the event insertion execution device 310 inserts event information into the segment.
- a segment including an emsg box which is an event information recording box defined in the MP4 format described above with reference to FIG. 20 is generated.
- the event type, contents, event activation time, duration information, and the like are recorded.
- the receiving apparatus can activate (e.g., execute) a specified event at a specified time according to the event information recorded in the emsg box in the segment, and can perform a process for continuing the specified event for a specified duration.
- Step S34 Next, the data output unit (DASH server) 311 of the event insertion execution device 310 transmits (outputs) MPD as signal link data in step S34.
- the MPD is transmitted via a broadcast wave or a network.
- the MPD is output to the proxy server or the playback control unit.
- Steps S35 to S36 the data output unit (DASH server) 311 of the event insertion execution device 310 transmits (outputs) the segment storing the AV content and the like in steps S35 to S36.
- the segment to be transmitted is a segment including an event information recording box (emsg) defined in the MP4 format.
- the segment transmission is continuously executed after step S36.
- the segment is transmitted via a broadcast wave or a network.
- the event insertion execution device 310 is the middleware 110 of the receiving device (middleware 110 shown in FIGS. 10 and 11)
- the segment is output to the proxy server or the playback control unit.
- the event execution device 320 receives the playback data of MPD or the like, or the playback control unit (reproduction control units 131 and 151 shown in FIGS. ).
- the processing executed by the event execution device 320 shown in FIG. 21 is processing executed by the reproduction control units 131 and 151 of the reception device.
- the reproduction control unit is shown separately according to the type of processing to be executed. That is, it is divided into two processing units, a playback control unit (event client) 321 as an event response processing execution unit and a playback control unit (DASH client) 322 that executes content playback processing using MPD and AV segments. ing.
- Step S41 First, the reproduction control unit (DASH client) 322 of the event execution device 320 makes an MPD acquisition request as signal link data to the event insertion execution device 310 in step S41.
- DASH client reproduction control unit
- Step S42 the playback control unit (DASH client) 322 of the event execution device 320 makes a segment acquisition request to the event insertion execution device 310 in step S44.
- Step S43 the playback control unit (DASH client) 322 of the event execution device 320 acquires event information from the segment acquired from the event insertion execution device 310 in step S42.
- the segment acquired here has an event information recording box (emsg). That is, it is assumed to be a segment (event information recording segment) including an event information recording box (emsg) in which event information shown in FIG. 20 is recorded.
- emsg event information recording box
- the type and content of the event, the activation time of the event, the duration information, and the like are recorded.
- the receiving device can activate (e.g., execute) a specified event at a specified time according to the event information recorded in this segment, and perform a process for continuing the specified event for a specified duration.
- Step S44 the reproduction control unit (event client) 321 of the event execution device 320 performs an event application process scheduled according to the event information acquired from the segment, that is, an event activation (event execution, start, etc.) process. .
- Step S45 the playback control unit (DASH client) 322 of the event execution device 320 acquires AV content and the like from the segment acquired in step S42, and executes playback processing.
- DASH client DASH client
- Steps S46 to S49 The processes in steps S46 to S49 are the same as the processes in steps S42 to S45. This series of processing is continuously executed as segment processing.
- the receiving device can execute various events according to the event information recorded in the event information recording box (emsg) in the segment in conjunction with the process of receiving and playing back the AV segment. It becomes.
- the middleware 110 of the tuner-implemented receiver 30 shown in FIGS. 10 and 11 acquires and analyzes the signaling data (LLS) shown in FIGS. Can be obtained without delay.
- LLS signaling data
- On-screen message type emergency information delivery notification On Screen Message Notification
- B Signaling data application type emergency information delivery notification (AEAT Message Notification)
- the reproduction processing of the program content transmitted by the transmission device 20 such as the broadcast server 21 is executed by the tuner-mounted reception device 30 shown in FIGS. 10 and 11 or the reproduction control unit (DASH) of the tuner non-mounting reception device 40.
- Client 131, 151.
- the application-presenting content presentation process described with reference to FIG. 7 is executed by the tuner-mounted receiving device 30 shown in FIGS. 10 and 11 and the application control unit 133 of the tuner-unmounted receiving device 40. , 153. Therefore, unless the reproduction control units (DASH clients) 131 and 151 and the application control units 133 and 153 recognize that the emergency information delivery notifications (a) and (b) have been made, the application presentation content is deleted. Processing or emergency information display processing cannot be executed.
- the following notification information notified by signaling data (LLS): (A) On-screen message type emergency information delivery notification (On Screen Message Notification), (B) Signaling data application type emergency information delivery notification (AEAT Message Notification), These emergency information delivery notifications can be transferred from the middleware to the playback control units (DASH clients) 131 and 151 and the application control units 133 and 153 promptly, and processing corresponding to these notifications can be executed without delay.
- an event notification mechanism is used.
- On-screen message event OnScreenMessage Event
- AEATDerived Event Signaling data applied emergency information delivery event
- the event notification process is executed from the middleware 110 of the tuner-mounted receiver 30 to the tuner-mounted receiver 30 and the playback control units (DASH clients) 131 and 151 of the tuner-unmounted receiver 40, and further playback is performed. This is executed for the tuner-mounted receiving device 30 and the application control units 133 and 153 and the emergency information control units 140 and 160 of the tuner non-mounted receiving device 40 via the control units (DASH clients) 131 and 151.
- On-screen message event (OnScreenMessage Event) is event information for notifying that “Onscreen Message Notification Notification” has been delivered by signaling data (LLS). .
- AEATDelivered Event notifies that “(b) signaling data application type emergency information delivery notification (AEAT Message Notification)” has been delivered by the signaling data (LLS). Event information.
- the above two events are newly defined.
- (A) The identifier of the on-screen message event (OnScreenMessage Event) is as follows. schemeIdUri "" urn: atsc: onScreenMessage "
- the event information in which this identifier is set is event information for notifying that the emergency information message is superimposed on the video stream (as a video). For example, the event information is notified to the application control units 133 and 153, and the application presentation content on the emergency information message is excluded.
- the identifier of the (b) signaling data application type emergency information distribution event is the following identifier.
- schemeIdUri “urn: atsc: AEATDerived”
- the event information in which this identifier is set is event information for notifying that an emergency information message such as AEAT or CAP is distributed as signaling data.
- This event information is notified to the reproduction control units 131 and 151, the application control units 133 and 153, the emergency information control units 140 and 260, etc., and emergency information (AEAT) is acquired from the distributed signaling data, or the signaling data
- AEAT emergency information
- the emergency information is acquired by using the access information recorded in the above, and a process for displaying the acquired emergency information is executed.
- the signaling data applied emergency information distribution event (AEATDerived Event) is recorded as event information data.
- the emergency information (AEAT) message file includes the map information described above with reference to FIG.
- DASH event transfer methods there are the following two types of DASH event transfer methods.
- A an MPD applied event notification method in which event information is inserted and transferred into MPD (Media Presentation Description) which is signaling data
- B A segment application (In-band) event notification method in which event information is inserted into a segment and transferred; There are these two types.
- the on-screen message type emergency information delivery notification will be sequentially described for each processing method to which the two types of event transfer methods are applied.
- the event information is obtained from, for example, the middleware 110 of the tuner-mounted receiver 30 shown in FIGS. 10 and 11, the tuner-mounted receiver 30 and the tuner-unmounted receiver.
- 40 playback control units (DASH clients) 131 and 151 are transferred.
- the on-screen message event (OnScreenMessage Event) generation process for notifying that the on-screen message type emergency information delivery notification has been received using the MPD application event notification method is the tuner-implemented receiving apparatus 30 shown in FIGS. 10 and 11.
- the SLS signaling analyzing unit (MPD event inserting unit) 115 of the present invention executes the processing.
- On-screen message event is a process for notifying that an emergency information message has been superimposed (as a video) on a video stream such as program content, and for displaying nothing on the emergency information message Is event information requesting.
- the process of superimposing the emergency information message on the video stream is performed by the transmission device 20 such as the broadcast server 21 when an emergency occurs, and the execution timing is unpredictable. That is, the activation time of this event cannot be described.
- MPD Event information necessary for event processing is transmitted to the client in units of periods using the MPD.
- A Event schedule such as activation (start / execution / activation) timing of various events,
- B Event processing to be processed by the client (receiving device) at each timing;
- C Data to be passed to the application running on the client at the time of event execution, etc.
- the process of superimposing the emergency information message on the video stream is executed by the transmission device 20 such as the broadcast server 21 when an emergency occurs, and the execution timing thereof is unpredictable. It is not possible to define an event schedule such as activation (start / execution / activation) timing in units of periods. Therefore, in order for the reproduction control unit (DASH client) 131, 151, etc. to acquire “emergency information event insertion MPD” in which the event information of the on-screen message event (OnScreenMessage Event) is inserted without delay, “emergency information event insertion MPD” It is necessary to notify the reproduction control unit (DASH client) 131, 151, etc. in advance that it is necessary to acquire “
- the LLS signaling analysis unit 113 of the middleware 110 detects an on-screen message type emergency information delivery notification (On Screen Message Notification) from the signaling data (LLS), and detects the detected information as an SLS signaling analysis unit (MPD event insertion unit). ) 115,
- the SLS signaling analysis unit (MPD event insertion unit) 115 generates an on-screen message event (OnScreenMessage Event), and stores the MPD in which the on-screen message event (OnScreenMessage Event) is recorded in the cache unit (proxy cache) 121. To do. Furthermore, using the existing DASH event notification mechanism, the playback control unit (DASH client) 131, 151 is notified of the change or update of the MPD being used by the playback control unit (DASH client) 131, 151. .
- the playback control units (DASH clients) 131 and 151 receive the MPD update event notification, apply the message data recorded in the event notification, and execute the MPD update process. That is, the MPS in which the on-screen message event (OnScreenMessage Event) generated by the SLS signaling analysis unit (MPD event insertion unit) 115 and stored in the cache unit (proxy cache) 121 is recorded in the above step (S02) is reproduced.
- the control units (DASH clients) 131 and 151 are made to obtain the updated MPD.
- the playback control units (DASH clients) 131 and 151 can acquire MPDs that record “on-screen message event (OnScreenMessage Event)”.
- the reproduction control units (DASH clients) 131 and 151 can know that the emergency information message is superimposed (as a video) on a video stream such as program content by referring to the updated MPD.
- DASH Dynamic Stream
- MPD Validity Expiration MPD Validity Expiration
- MPD Patch MPD Patch
- DASH events are all events used for MPD update notification.
- the event type (identifier) schemeIdUri “urn: mpeg: dash: event: 2012”.
- different attributes value attributes are set for these two events, and the two events can be distinguished by these attributes.
- the type (identifier) and attribute (value attribute) of the MPD Validity Expiration Notification Event are as follows.
- the type (identifier) and attribute (value attribute) of the MPD patch (MPD Patch) notification event are as follows.
- the MPD Validity Expiration Notification Event is an event for notifying that the MPD being used by the playback control unit (DASH client) has been changed or updated. Normally, the MPD update time is notified by being described in the MPD by MPD @ minimumUpdatePeriod, which is an attribute of MPD.
- the playback control unit (DASH client) as a client determines that the acquired MPD is valid until the time described in the minimum UpdatePeriod.
- the segment application (in-band) event notification method is a method for storing and notifying event notification information in a segment stream. That is, an event notification indicating that the MPD needs to be updated is inserted into the segment, and transferred to the reproduction control unit (DASH client).
- the playback control unit (DASH client) has confirmed all the input segments, and can know that the MPD update is necessary in this segment confirmation process.
- time information that needs to be updated is recorded as message data.
- message_data [] Stores the time information that needs to be updated.
- the playback control unit (DASH client) When the playback control unit (DASH client) detects this event from the segment, the playback control unit (DASH client) applies the access information similar to the access information (url) of the currently used MPD file, and at the time recorded as the message data, Re-acquire. By this process, the updated MPD can be acquired.
- “Necessary time for update” is set to “Now”.
- MPD Patch Another MPD patch (MPD Patch) notification event updates (modifies) the MPD itself rather than telling the time when the MPD update is required, unlike the MPD Validity Expiration notification event. ) Send command (patch script).
- the playback control unit updates the content itself by applying this command to the acquired MPD.
- the event notification process for performing the MPD update notification described in the step (S02) can be executed using these existing DASH event notification mechanisms.
- the reproduction control units (DASH clients) 131 and 151 can acquire the updated MPD in which the on-screen message event (OnScreenMessage Event) is recorded by the processing of the above-described steps (S01) to (S03). it can.
- FIG. 22 shows an example of MPD data in which on-screen message event (OnScreenMessage Event) information is recorded.
- the MPD has the following description, for example.
- Event presentationTime '(difference (period) from the period start time of the target period (Period) during which the event is started (activated)) (Emergency information (on-screen message) data or URL for accessing emergency information data) ⁇ / Event> .... ⁇ / EventStream> ... ⁇ AdaptationSet> ... ⁇ / Period> ⁇ / MPD>
- This data recording / recording area is a recording area for the start time information of the first period corresponding to the data recorded in the MPD. For example, UTC time is used as the time information.
- This data recording recording area is a period start time information recording area.
- the offset time from the start time (MPD / @ availabilityStartTime) defined in MPD is recorded.
- This data recording / recording area is a recording area for event stream designation information indicating an event type or the like and time scale information.
- timescale “ 1000 ”” indicates that the unit time of the presentation time (presentationTime) recorded below is 1/1000 second.
- ⁇ Event presentationTime '(difference (period) from the period start time of the target period (Period) during which the event is started (activated)) (Emergency information (on-screen message) data or URL for accessing emergency information data)
- This data recording / recording area is a recording area for event data, and a recording area for event scheduling data such as event activation (execution start) time and duration.
- event scheduling data such as event activation (execution start) time and duration.
- event data for example, actual data of an emergency information message or access information thereof is recorded.
- ⁇ AdaptationSet> ⁇ Representation /> ⁇ Representation /> These are data recording areas in which information for each data type is recorded, and in the case of an on-screen message event, identification information of a broadcast stream on which emergency information is superimposed is recorded.
- the reproduction control units (DASH clients) 131 and 151 shown in FIGS. 10 and 11 acquire data from the segment while referring to the MPD, and continuously execute output control of the broadcast stream.
- event notification information is acquired from the segment stream by the segment application (In-band) event notification method described above.
- the playback control units (DASH clients) 131 and 151 update MPDs storing on-screen message events (OnScreenMessage Event), that is, onscreen message events (OnScreenMessage Event) having the configuration described with reference to FIG. ) Is recorded.
- the reproduction control units (DASH clients) 131 and 151 refer to the on-screen message event (OnScreenMessage Event) recorded in the updated MPD to know the timing at which the emergency information is superimposed on the broadcast content image and distributed. It becomes possible.
- the event extraction units 205 and 255 of the reproduction control units (DASH clients) 131 and 151 further transfer the on-screen message event (OnScreenMessage Event) recorded in the MPD to the application control units 133 and 153.
- the application control units 133 and 153 perform processing for stopping the display of the application presentation content. Specifically, for example, the display of the weather forecast information presentation content described above with reference to FIG. 7 is stopped. This process allows the user (viewer) to surely confirm the emergency information that is superimposed and distributed on the broadcast content image.
- the on-screen message event (OnScreenMessage Event) generating process for notifying that the on-screen message type emergency information delivery notification has been received is generated by the tuner shown in FIGS. This is executed by the in-band event insertion unit 118 of the mounted receiving device 30.
- On-screen message event is a process for notifying that an emergency information message has been superimposed (as a video) on a video stream such as program content, and for displaying nothing on the emergency information message Is event information requesting.
- the in-band event insertion unit 118 of the tuner-implemented receiving apparatus 30 shown in FIG. 11 inserts this on-screen message event (OnScreenMessage Event) in the segment.
- OnScreenMessage Event This on-screen message event
- FIG. 23 shows a data configuration example of the event information storage box (emsg) in which the on-screen message event (OnScreenMessage Event) is set in the segment.
- emsg the on-screen message event (OnScreenMessage Event) is set in the segment.
- the event information storage box (emsg) has the following description, for example.
- box_type 'emsg' This data recording / recording area is a box type recording area. It is described that this box (data storage box defined in MP4) is an event information storage box (emsg).
- This data recording / recording area is a recording area for event designation information indicating an event type or the like.
- Scheme_id_uri “ urn: atsc: onScreenMessage ′ ”can confirm that this event is an on-screen message event (OnScreenMessage Event).
- an event type or the like can be defined by an optional “value”.
- event scheduling data such as event activation (execution start etc.) time and duration.
- event activation execution start etc.
- the start time when the emergency information is superimposed and displayed on the broadcast content image and the duration of the superimposed display are recorded.
- event data for example, entity data of an emergency information message or access information thereof can be recorded.
- This data recording area is an event identification information recording area.
- This data recording area is an event data recording area.
- the event data is composed of data such as entity data, metadata, commands, etc. necessary for executing the event, access information thereof, and the like. For example, the actual data of the emergency information message or the access information thereof is recorded.
- event information can be recorded and transferred in the segment stream (in-stream).
- event type can be defined in the “scheme_id_uri” field and the optional “value” field.
- event data that is, data such as entity data, metadata, and commands necessary for executing the event, access information thereof, and the like can be added to the “message_data” field.
- the reproduction control units (DASH clients) 131 and 151 shown in FIGS. 10 and 11 acquire data from the segment while referring to the MPD, and continuously execute output control of the broadcast stream.
- the playback control units (DASH clients) 131 and 151 refer to the on-screen message event (OnScreenMessage Event) recorded in the segment to know the timing at which the emergency information is superimposed on the broadcast content image and distributed. It becomes possible.
- the event extraction units 205 and 255 of the reproduction control units (DASH clients) 131 and 151 further transfer the on-screen message event (OnScreenMessage Event) in this segment to the application control units 133 and 153.
- the application control units 133 and 153 perform processing for stopping the display of the application presentation content. Specifically, for example, the display of the weather forecast information presentation content described above with reference to FIG. 7 is stopped. This process allows the user (viewer) to surely confirm the emergency information that is superimposed and distributed on the broadcast content image.
- On-screen message event (OnScreenMessage Event) Enabled to notify the playback control unit (DASH client) from the middleware that the “On Screen Message Notification Notification (On Screen Message Notification)” has been distributed by signaling data (LLS). .
- a transmission device 410 that generates and outputs AV segments, emergency information, MPD, signaling data, and the like.
- (2) Receive an AV segment, emergency information, MPD, signaling data, etc., and generate event information that records the emergency information notification status, etc., or an event insertion MPD or event insertion segment recorded in the segment Tuner mounted receiver middleware 420, (3) Tuner-implemented / non-implemented receiver that receives an AV segment, event insertion MPD, or event insertion segment from the tuner-implemented receiver middleware 420 and executes AV segment playback processing or event information processing Device output data control unit 430,
- the tuner-implemented receiver middleware 420 corresponds to the middleware 110 of the tuner-equipped receiver 30 shown in FIGS.
- the tuner-mounted / unmounted receiver output data control unit 430 includes the tuner-mounted receiver 30 shown in FIGS. 10 and 11, the reproduction control units (DASH clients) 131 and 151 of the tuner-unmounted receiver 40, and output control.
- the units 132 and 152, the application control units 133 and 153, and the emergency information control units 140 and 160 corresponds to the units 132 and 152, the application control units 133 and 153, and the emergency information control units 140 and 160.
- the transmission apparatus 410 shown in FIG. A stream server 411 for generating a playback content stream, etc. DASH server 412 for generating MPD and segment, Emergency information server 413 for generating emergency information, Broadcast signal generation unit (broadcast server) 414 that executes transmission of MPD, segment, and emergency information,
- Broadcast server Broadcast signal generation unit
- Step S201 First, processing executed by the transmission device 410 will be described.
- the emergency information server 413 of the transmission device 410 generates emergency information to be displayed by being superimposed on an image constituting the broadcast content, and superimposes it on the image generated by the stream server 411.
- the emergency information distributed on the broadcast content image that is, the on-screen message type emergency information is generated, and the image generated by the stream server 411 is generated.
- the image generated by the stream server 411 is generated.
- superimpose the emergency information distributed on the broadcast content image
- Step S202 the emergency information server 413 of the transmission device 410 outputs a notification indicating that the on-screen message type emergency information is superimposed on the broadcast content image to the reception device via the broadcast signal generation unit (broadcast server) 414. To do.
- This signaling data transmission is performed using a session different from a communication session such as a broadcast stream.
- Step S203 the stream server 411 of the transmission device 410 generates a stream in which the emergency information generated by the emergency information server 413 is superimposed on the image, and outputs the stream to the DASH server.
- Steps S204 to S205 Next, the DASH server 412 of the transmission apparatus 410 generates MPD or segment as signal link data in step S204, and transmits it via the broadcast signal generation unit (broadcast server) 414 in step S205.
- the segment includes images and sound as broadcast content configuration data.
- the MPD includes various control information, guidance information, and the like to be applied to broadcast content reproduction processing. As described above with reference to FIG. 14 and others, the MPD has a configuration capable of describing attribute information and control information in units of a predetermined data range for each stream of images and audio.
- the broadcast signal generation unit (broadcast server) 414 performs processing for transmitting MPD and segments on broadcast waves.
- the transmission device 410 is a data distribution server that executes data transmission via a network such as the Internet, the MPD and the segment are transmitted via the network.
- the tuner-mounted receiver middleware 420 has the same configuration as the middleware 110 of the tuner-mounted receiver 30 shown in FIGS.
- the tuner-implemented receiver middleware 420 receives the AV segment transmitted by the transmitter 410, emergency information, MPD, signaling data, etc., and records event information in which the emergency information notification status is recorded in the MPD or segment. Generate an event insertion MPD or event insertion segment, Further, the generated event insertion MPD or event insertion segment is transferred to the tuner-mounted / non-mounted receiver output data control unit 430.
- the process of each step executed by the tuner-implemented receiver middleware 420 will be described.
- Step S211 When the tuner-implemented receiver middleware 420 receives a notification indicating that the on-screen message type emergency information has been superimposed on the broadcast content image from the transmitter 410, the tuner-implemented receiver middleware 420 executes an on-screen message event generation process in step S211. To do.
- the tuner-implemented receiver middleware 420 receives signaling data (LLS: Lower Layer Signaling) transmitted from the transmitter 410 in the process of step S202 of the emergency information server of the transmitter 410.
- signaling data LLS
- the on-screen message On Screen Message
- the on-screen message notification On Screen Message Notification
- the tuner-implemented receiver middleware 420 In response to this notification, the tuner-implemented receiver middleware 420 generates event information stored in the MPD or segment.
- the emergency information transmitted by the transmission device 410 is on-screen emergency information that is directly superimposed on the broadcast content component image, and the tuner-mounted reception device middleware 420 sends an on-screen message event (OnScreenMessage Event). Generate.
- the on-screen message event (OnScreenMessage Event) is used to notify that the “on-screen message type emergency information delivery notification (OnScreen Message Notification)” has been delivered by the signaling data (LLS). Event information.
- Step S212 the tuner-implemented receiving apparatus middleware 420 records the event information generated in step S211, that is, the on-screen message event (OnScreenMessage Event) information in at least one of the MPD and the segment.
- the on-screen message event OnScreenMessage Event
- DASH event transfer methods there are the following two types of DASH event transfer methods.
- A an MPD applied event notification method in which event information is inserted and transferred into MPD (Media Presentation Description) which is signaling data
- B A segment application (In-band) event notification method in which event information is inserted into a segment and transferred; There are these two types.
- an on-screen message event (OnScreenMessage Event) is inserted into the MPD.
- an MPD in which the on-screen message event (OnScreenMessage Event) information described above with reference to FIG. 22 is recorded is generated.
- This process is executed in the SLS signaling generation unit (MPD event insertion unit) 115 of the middleware 110 shown in FIG.
- the MPD or segment into which the on-screen message event (OnScreenMessage Event) is inserted includes, for example, the following data.
- Emergency information on-screen message (OnScreenMessage)) data or URL for accessing emergency information data
- Step S213 the tuner-implemented receiver middleware 420 transfers the MPD and the segment to the tuner-implemented / non-implemented receiver output data control unit 430 in step S213.
- This process is specifically executed via the proxy server 121.
- the reproduction control unit (DASH client) of the tuner-implemented / non-implemented receiver output data control unit 430 that is, the reproduction control units (DASH client) 131 and 151 shown in FIGS. 10 and 11 are connected to the cache unit (proxy) of the proxy server 120.
- Cache) 121 is accessed to obtain MPD and segments.
- the MPD or segment acquired by the playback control unit (DASH client) 131, 151 includes an MPD in which the on-screen message event (OnScreenMessage Event) generated by the playback control unit (DASH client) 131, 151 is inserted in step S212. Or a segment is included.
- the MPD with the on-screen message event (OnScreenMessage Event) inserted is delayed to the tuner-mounted / non-mounted receiver output data control unit 430, that is, the playback control units (DASH clients) 131 and 151 shown in FIGS. In order to obtain all of them, it is necessary to notify the MPD update in advance as described above.
- the tuner-implemented receiver middleware 420 first executes an existing MPD update event notification process to which a segment application (in-band) event notification method is applied. That is, it notifies the playback control units (DASH clients) 131 and 151 that the MPD has been updated. In response to this notification, the reproduction control units (DASH clients) 131 and 151 can acquire the MPD in which the on-screen message event (OnScreenMessage Event) is inserted without delay.
- OnScreenMessage Event OnScreenMessage Event
- FIG. 24 shows an application control unit 431 and a playback control unit 432 of the tuner-mounted / non-mounted receiver output data control unit 430.
- These configurations correspond to the configurations of the application control units 133 and 153 and the playback control units 131 and 151 of the tuner-mounted receiver 30 and the tuner-unmounted receiver 40 shown in FIGS.
- Step S221) the playback control unit (DASH client) 432 of the tuner-implemented / non-implemented receiver output data controller 430 receives an on-screen message event (OnScreenMessage Event) from the MPD or segment received via the tuner-equipped receiver middleware 420. Is extracted and transferred to the application control unit 431.
- OnScreenMessage Event an on-screen message event
- the playback control unit (DASH client) 432 is an MPD that records the on-screen message event (OnScreenMessage Event) information described above with reference to FIG. From the segment in which the on-screen message event (OnScreenMessage Event) information described above with reference to FIG. 23 is recorded, Extract on-screen message event (OnScreenMessage Event).
- the MPD or segment into which the on-screen message event (OnScreenMessage Event) is inserted includes, for example, the following data.
- Emergency information on-screen message (OnScreenMessage)) data or URL for accessing emergency information data
- Step S222 the application control unit 431 of the tuner mounted / non-mounted receiver output data control unit 430 executes processing according to the event information received from the playback control unit (DASH client) 432 in step S222.
- the application control unit 431 performs a process of stopping the display of the application presentation content. Specifically, for example, the display of the weather forecast information presentation content described above with reference to FIG. 7 is stopped. This process allows the user (viewer) to surely confirm the emergency information that is superimposed and distributed on the broadcast content image.
- Step S223 the playback control unit (DASH client) 432 of the tuner-mounted / non-mounted receiver output data controller 430 acquires AV content from the segment received via the tuner-mounted receiver middleware 420 and executes playback processing. .
- the playback control unit (DASH client) 432 of the tuner-mounted / non-mounted receiver output data controller 430 receives event information generated by the tuner-mounted receiver middleware 420 in conjunction with the process of receiving and playing back the AV segment.
- An insertion MPD or event information segment is acquired, and it is possible to detect that emergency information is superimposed and displayed on an image of broadcast content.
- the display of the application presentation content executed by the application control unit is stopped, and the emergency information superimposed on the image of the broadcast content is displayed by the application presentation content. It is possible to prevent the state from being hidden and to make the user (viewer) surely confirm.
- the signaling data application-type emergency information delivery notification (AEAT Message Notification) is a communication path different from the normal program delivery path, for example, the previously described signaling data (LLS: LLS) as described above with reference to FIG. : An emergency information notification method in which a message as emergency information and evacuation route information are transmitted using a communication path of Lower Layer Signaling.
- the emergency information transmission processing according to the AEAT (Advanced Emergency Alerting Table) or CAP (Common Alerting Protocol) format described above with reference to FIG. 13 is executed according to this signaling data application type emergency information distribution method. .
- DASH event transfer methods there are the following two types of DASH event transfer methods.
- A an MPD applied event notification method in which event information is inserted and transferred into MPD (Media Presentation Description) which is signaling data
- B A segment application (In-band) event notification method in which event information is inserted into a segment and transferred; There are these two types.
- the signaling data application type emergency information delivery notification will be sequentially described for each processing method to which the above two types of event transfer methods are applied.
- the event information is obtained from, for example, the middleware 110 of the tuner-mounted receiver 30 shown in FIGS. 10 and 11, the tuner-mounted receiver 30 and the tuner-unmounted receiver.
- 40 playback control units (DASH clients) 131 and 151 are transferred.
- the generation processing of the “signaling data applied emergency information (AEAT) delivery event (AEATDerived Event)” informing that the signaling data applied emergency information delivery notification has been received using the MPD applied event notification method is shown in FIGS.
- a signaling data application type emergency information (AEAT) delivery event (AEATDerived Event) is a message or evacuation route information as emergency information, which is a communication route different from a normal program delivery route, for example, the previously described signaling data (LLS: : Lower Layer Signaling) is used for transmission to the receiving device.
- AEAT AEATDerived Event
- LLS Lower Layer Signaling
- the transmission of emergency information is performed by the transmitting device 20 such as the broadcast server 21 when an emergency occurs. Its execution timing is unpredictable. Therefore, the activation time of this event cannot be described.
- the LLS signaling analysis unit 113 of the middleware 110 detects a signaling data application type emergency information delivery notification (On Screen Message Notification) from the signaling data (LLS), and sends the detected information to the SLS signaling analysis unit (MPD event insertion unit). ) 115,
- the SLS signaling analysis unit (MPD event insertion unit) 115 generates a signaling data applied emergency information (AEAT) delivery event (AEATDerived Event), and a signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) Is stored in the cache unit (proxy cache) 121. Furthermore, using the existing DASH event notification mechanism, the playback control unit (DASH client) 131, 151 is notified of the change or update of the MPD being used by the playback control unit (DASH client) 131, 151. .
- the playback control units (DASH clients) 131 and 151 receive the MPD update event notification, apply the message data recorded in the event notification, and execute the MPD update process. That is, in the above step (S02), the SLS signaling analysis unit (MPD event insertion unit) 115 generates the signaling data applied emergency information (AEAT) distribution event (AEATDerived Event) stored in the cache unit (proxy cache) 121. MPDs having the above recorded are acquired by the playback control units (DASH clients) 131 and 151 as updated MPDs.
- AEAT signaling data applied emergency information
- the reproduction control unit (DASH client) 131, 151 acquires the MPD in which the “signaling data applied emergency information (AEAT) delivery event (AEATDerived Event)” is recorded. can do.
- the playback control units (DASH clients) 131 and 151 can know that the emergency information message has been or has been distributed as signaling data (for example, LLS).
- the following existing method defined in the DASH specification can be applied to the event notification process for notifying that the MPD has been updated described in step (S02).
- One is an MPD Validity Expiration (MPD Validity Expiration) notification event
- the other is an MPD Patch (MPD Patch) notification event.
- the reproduction control units (DASH clients) 131 and 151 are updated by recording the signaling data applied emergency information (AEAT) distribution event (AEATDerived Event) by the processing of the above steps (S01) to (S03). MPD can be acquired.
- AEAT signaling data applied emergency information
- FIG. 25 shows an example of MPD data in which signaling data applied emergency information (AEAT) distribution event information is recorded.
- the MPD has the following description, for example.
- Event presentationTime '(difference (period) from the period start time of the target period (Period) during which the event is started (activated)) (Signaling data application type emergency information (AEAT) data or emergency information (AEAT) data access URL) ⁇ / Event> .... ⁇ / EventStream> ... ⁇ AdaptationSet> ... ⁇ / Period> ⁇ / MPD>
- This data recording / recording area is a recording area for the start time information of the first period corresponding to the data recorded in the MPD. For example, UTC time is used as the time information.
- This data recording recording area is a period start time information recording area.
- the offset time from the start time (MPD / @ availabilityStartTime) defined in MPD is recorded.
- This data recording / recording area is a recording area for event stream designation information indicating an event type or the like and time scale information.
- timescale “ 1000 ” indicates that the unit time of the presentation time (presentationTime) recorded below is 1/1000 second.
- ⁇ Event presentationTime '(difference (period) from the period start time of the target period (Period) during which the event is started (activated)) (Signaling data application type emergency information (AEAT) data or emergency information (AEAT) data access URL)
- This data recording / recording area is a recording area for event data, and a recording area for event scheduling data such as event activation (execution start) time and duration.
- event data for example, actual data of an emergency information message or access information thereof is recorded.
- ⁇ AdaptationSet> ⁇ Representation /> ⁇ Representation /> These are data recording areas in which information for each data type is recorded.
- AEAT signaling data application type emergency information
- the reproduction control units (DASH clients) 131 and 151 shown in FIGS. 10 and 11 acquire data from the segment while referring to the MPD, and continuously execute output control of the broadcast stream.
- event notification information is acquired from the segment stream by the segment application (In-band) event notification method described above.
- the reproduction control units (DASH clients) 131 and 151 have the configuration described with reference to FIG. 25, which is an updated MPD that stores a signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) according to this event information.
- An MPD in which a signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) is recorded is acquired.
- the playback control unit (DASH client) 131, 151 acquires emergency information (AEAT) configuration data directly from the signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) recorded in the updated MPD.
- AEAT emergency information
- the emergency information (AEAT) is acquired from the cache unit 121 of the proxy server 120 in accordance with the emergency information (AEAT) access information recorded in the updated MPD.
- the middleware 110 When the middleware 110 receives the signaling data (LLS) storing the emergency information (AEAT) transmitted from the transmission device 20, the middleware 110 stores the received emergency information (AEAT) in the cache unit 121 of the proxy server 120. Execute.
- the event extraction units 205 and 255 of the playback control units (DASH clients) 131 and 151 further transmit the signaling data applied emergency information (AEAT) distribution event (AEATDerived Event) recorded in the MPD to the application control units 133 and 153. Alternatively, it is transferred to the emergency information control units 140 and 160. If the event does not include emergency information (AEAT) data, the emergency information (AEAT) is obtained from the cache unit 121 of the proxy server 120 according to the access information of the emergency information (AEAT) recorded in the updated MPD, and the application The data is transferred to the control units 133 and 153 or the emergency information control units 140 and 160.
- AEAT emergency information
- the application control units 133 and 153 or the emergency information control units 140 and 160 analyze the emergency information (AEAT) acquired via the reproduction control units (DASH clients) 131 and 151, and store it in the emergency information (AEAT).
- the process of displaying the urgent message, the map information of the evacuation route, etc. is executed. Specifically, for example, the emergency information display process described above with reference to FIGS. 8 and 9 is executed. This process allows the user (viewer) to confirm the emergency information distributed as the signaling data with certainty.
- the generation processing of the “signaling data application type emergency information (AEAT) delivery event (AEATDerived Event)” informing that the signaling data application type emergency information delivery notification has been received is shown in FIG. 10 is executed by the in-band event insertion unit 118 of the tuner-implemented receiver 30 shown in FIG.
- a signaling data application type emergency information (AEAT) delivery event (AEATDerived Event) is a message or evacuation route information as emergency information, which is a communication route different from a normal program delivery route, for example, the previously described signaling data (LLS: : Lower Layer Signaling) is used for transmission to the receiving device.
- AEAT AEATDerived Event
- LLS Lower Layer Signaling
- the in-band event insertion unit 118 of the tuner-implemented receiving apparatus 30 shown in FIG. 11 inserts this signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) in the segment.
- AEAT signaling data applied emergency information
- FIG. 26 shows a data configuration example of an event information storage box (emsg) in which a signaling data applied emergency information (AEAT) distribution event (AEATDerived Event) is set in a segment.
- emsg event information storage box
- AEAT signaling data applied emergency information
- AEATDerived Event AEATDerived Event
- the event information storage box (emsg) has the following description, for example.
- box_type 'emsg' This data recording / recording area is a box type recording area. It is described that this box (data storage box defined in MP4) is an event information storage box (emsg).
- This data recording / recording area is a recording area for event designation information indicating an event type or the like.
- Scheme_id_uri “ urn: atsc: AEATDerived ””
- this event is a signaling data applied emergency information (AEAT) delivery event (AEATDerived Event).
- an event type or the like can be defined by an optional “value”.
- event scheduling data such as event activation (execution start etc.) time and duration.
- AEAT signaling data application-type emergency information
- AEAT the start time and duration of distribution of emergency information (AEAT) can be recorded.
- event data for example, entity data of an emergency information message or access information thereof can be recorded.
- This data recording area is an event identification information recording area.
- message_data [] (emergency information (AEAT) data or URL for accessing emergency information data)
- This data recording area is an event data recording area.
- the event data is composed of data such as entity data, metadata, commands, etc. necessary for executing the event, access information thereof, and the like. For example, the actual data of the emergency information message or the access information thereof is recorded.
- event information can be recorded and transferred in the segment stream (in-stream).
- event type can be defined in the “scheme_id_uri” field and the optional “value” field.
- event data that is, data such as entity data, metadata, and commands necessary for executing the event, access information thereof, and the like can be added to the “message_data” field.
- the reproduction control units (DASH clients) 131 and 151 shown in FIGS. 10 and 11 acquire data from the segment while referring to the MPD, and continuously execute output control of the broadcast stream.
- the reproduction control unit (DASH client) 131, 151 acquires emergency information (AEAT) configuration data directly from the signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) recorded in the segment, Alternatively, the emergency information (AEAT) is acquired from the cache unit 121 of the proxy server 120 in accordance with the emergency information (AEAT) access information recorded in the updated MPD.
- AEAT emergency information
- the event extraction units 205 and 255 of the reproduction control units (DASH clients) 131 and 151 further send the signaling data applied emergency information (AEAT) distribution event (AEATDerived Event) in this segment to the application control units 133 and 153, or , Forward to the emergency information control unit 140,160.
- AEAT emergency information
- the emergency information (AEAT) data is not included in the event, the emergency information (AEAT) is acquired from the cache unit 121 of the proxy server 120 according to the access information of the emergency information (AEAT) recorded in the segment, and application control is performed.
- the emergency information (AEAT) is acquired from the cache unit 121 of the proxy server 120 according to the access information of the emergency information (AEAT) recorded in the segment, and application control is performed.
- the emergency information control units 140 and 160 To the units 133 and 153 or the emergency information control units 140 and 160.
- the application control units 133 and 153 or the emergency information control units 140 and 160 analyze the emergency information (AEAT) acquired via the reproduction control units (DASH clients) 131 and 151, and store it in the emergency information (AEAT).
- the process of displaying the urgent message, the map information of the evacuation route, etc. is executed. Specifically, for example, the emergency information display process described above with reference to FIGS. 8 and 9 is executed. This process allows the user (viewer) to confirm the emergency information distributed as the signaling data with certainty.
- A MPD application event notification method
- B Segment application event notification method
- AEAT In-band Event Signaling
- a transmission device 410 that generates and outputs AV segments, emergency information, MPD, signaling data, and the like.
- (2) Receive an AV segment, emergency information, MPD, signaling data, etc., and generate event information that records the emergency information notification status, etc., or an event insertion MPD or event insertion segment recorded in the segment Tuner mounted receiver middleware 420, (3) Tuner-implemented / non-implemented receiver that receives an AV segment, event insertion MPD, or event insertion segment from the tuner-implemented receiver middleware 420 and executes AV segment playback processing or event information processing Device output data control unit 430,
- the tuner-implemented receiver middleware 420 corresponds to the middleware 110 of the tuner-equipped receiver 30 shown in FIGS.
- the tuner-mounted / unmounted receiver output data control unit 430 includes the tuner-mounted receiver 30 shown in FIGS. 10 and 11, the reproduction control units (DASH clients) 131 and 151 of the tuner-unmounted receiver 40, and output control.
- the units 132 and 152, the application control units 133 and 153, and the emergency information control units 140 and 160 corresponds to the units 132 and 152, the application control units 133 and 153, and the emergency information control units 140 and 160.
- the transmission device 410 shown in FIG. A stream server 411 for generating a playback content stream, etc. DASH server 412 for generating MPD and segment, Emergency information server 413 for generating emergency information, Broadcast signal generation unit (broadcast server) 414 that executes transmission of MPD, segment, and emergency information,
- DASH server 412 for generating MPD and segment
- Emergency information server 413 for generating emergency information
- Broadcast signal generation unit (broadcast server) 414 that executes transmission of MPD, segment, and emergency information
- Step S401 Next, in step S401, the stream server 411 of the transmission device 410 generates a stream composed of images, sounds, and the like as broadcast content configuration data, and outputs the stream to the DASH server.
- Steps S402 to S403 Next, the DASH server 412 of the transmission device 410 generates MPD or segment as the signal link data in step S402, and transmits it through the broadcast signal generation unit (broadcast server) 414 in step S403.
- the segment includes images and sound as broadcast content configuration data.
- the MPD includes various control information, guidance information, and the like to be applied to broadcast content reproduction processing. As described above with reference to FIG. 14 and others, the MPD has a configuration capable of describing attribute information and control information in units of a predetermined data range for each stream of images and audio.
- the broadcast signal generation unit (broadcast server) 414 performs processing for transmitting MPD and segments on broadcast waves.
- the transmission device 410 is a data distribution server that executes data transmission via a network such as the Internet, the MPD and the segment are transmitted via the network.
- Steps S404 to S405) First, the emergency information server 413 of the transmission device 410 generates emergency information (AEAT) to be transmitted as signaling data in step S404, and transmits it via the broadcast signal generation unit (broadcast server) 414 in step S405.
- AEAT emergency information
- the emergency information generated by the emergency information server 413 is, for example, emergency information (AEAT: Advanced Emergency Alerting Table) having the data format described above with reference to FIG.
- the AEAT includes, for example, an emergency information message as emergency information, display data such as map information indicating an evacuation route, display data access information, and the like. This signaling data transmission is performed using a session different from a communication session such as a broadcast stream.
- the tuner-mounted receiver middleware 420 has the same configuration as the middleware 110 of the tuner-mounted receiver 30 shown in FIGS.
- the tuner-implemented receiver middleware 420 receives an AV segment transmitted by the transmitter 410, emergency information, MPD, signaling data, and the like, and stores emergency information (AEAT) itself or emergency information (AEAT) access information.
- AEAT emergency information
- the process of each step executed by the tuner-implemented receiver middleware 420 will be described.
- Step S411 When receiving the signaling data applied emergency information (AEAT) from the transmitting apparatus 410, the tuner-implemented receiving apparatus middleware 420 executes a signaling data applied emergency information (AEAT) distribution event generation process in step S411.
- AEAT signaling data applied emergency information
- the tuner-implemented receiver middleware 420 receives signaling data (LLS: Lower Layer Signaling) storing emergency information (AEAT) transmitted from the transmitter 410 in the process of step S405 of the emergency information server of the transmitter 410. .
- signaling data LLS: Lower Layer Signaling
- AEAT emergency information
- the tuner-implemented receiver middleware 420 generates event information to be stored in the MPD or segment in response to the reception of the signaling data (LLS).
- the emergency information transmitted by the transmission device 410 is signaling data application type emergency information (AEAT)
- the tuner-implemented reception device middleware 420 sends a signaling data application type emergency information (AEAT) distribution event (AEATDerived Event).
- AEAT signaling data application type emergency information
- the signaling data applied emergency information (AEAT) delivery event (AEATDelivered Event) notifies that the “signaling data applied emergency information (AEAT)” is delivered by the signaling data (LLS).
- Event information and emergency information (AEAT) configuration data or data including emergency information (AEAT) access information are examples of the signaling data applied emergency information (AEAT) delivery event.
- Step S412 the tuner-implemented receiving apparatus middleware 420 sends the event information generated in step S411 to at least one of the MPD and the segment, that is, the signaling data applied emergency information (AEAT) delivery event (AEATDerived Event). Record information.
- AEAT the signaling data applied emergency information
- DASH event transfer methods there are the following two types of DASH event transfer methods.
- A an MPD applied event notification method in which event information is inserted and transferred into MPD (Media Presentation Description) which is signaling data
- B A segment application (In-band) event notification method in which event information is inserted into a segment and transferred; There are these two types.
- a signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) is inserted into the MPD.
- AEAT signaling data applied emergency information
- AEATDerived Event an MPD in which the signaling data applied emergency information (AEAT) delivery event information (AEATDerived Event) information described above with reference to FIG. 25 is generated.
- This process is executed in the SLS signaling generation unit (MPD event insertion unit) 115 of the middleware 110 shown in FIG.
- a signaling data applied emergency information (AEAT) distribution event (AEATDerived Event) is inserted into the segment.
- AEAT signaling data applied emergency information
- AEATDerived Event a segment in which the signaling data applied emergency information (AEAT) delivery event information (AEATDerived Event) information described above with reference to FIG. 26 is recorded is generated.
- This process is executed by the in-band event insertion unit 118 of the middleware 110 shown in FIG.
- the following data is included in the MPD or segment in which the signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) is inserted.
- AEAT emergency information
- AEAT emergency information
- AEAT emergency information
- Step S413 the tuner-mounted receiver middleware 420 transfers the MPD and the segment to the tuner-mounted / non-mounted receiver output data control unit 430 in step S413.
- This process is specifically executed via the proxy server 121.
- the reproduction control unit (DASH client) of the tuner-implemented / non-implemented receiver output data control unit 430 that is, the reproduction control units (DASH client) 131 and 151 shown in FIGS. 10 and 11 are connected to the cache unit (proxy) of the proxy server 120.
- Cache) 121 is accessed to obtain MPD and segments.
- the MPD or segment acquired by the playback control unit (DASH client) 131, 151 includes the signaling data applied emergency information (AEAT) delivery event (AEATDerived) generated by the playback control unit (DASH client) 131, 151 in step S412. MPD or segment into which Event) is inserted.
- AEAT signaling data applied emergency information
- the MPD into which the signaling data applied emergency information (AEAT) delivery event (AEATDelivered Event) is inserted is used as a tuner-mounted / non-mounted receiver output data control unit 430, that is, the playback control unit (DASH) shown in FIGS.
- AEAT signaling data applied emergency information
- DASH playback control unit
- the tuner-implemented receiver middleware 420 first executes an existing MPD update event notification process to which a segment application (in-band) event notification method is applied. That is, it notifies the playback control units (DASH clients) 131 and 151 that the MPD has been updated. In response to this notification, the playback control units (DASH clients) 131 and 151 can acquire the MPD in which the signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) is inserted without delay.
- AEAT signaling data applied emergency information
- Step S414 In the process of step S414, the access information of emergency information (AEAT) is recorded in the MPD or segment transferred to the tuner mounted / non-mounted receiver output data control unit 430 by the tuner mounted receiver middleware 420 in step S413. This is a process executed when emergency information (AEAT) data is not included or when new output (display) data is required.
- AEAT emergency information
- the tuner-mounted receiving device middleware 420 responds to the emergency information (AEAT) acquisition request from the tuner-mounted / non-mounted receiving device output data control unit 430 to send emergency information (AEAT) including output data to the tuner mounted / not mounted. Transfer to the non-implemented receiver output data control unit 430.
- AEAT emergency information
- FIG. 27 shows the emergency information control unit 433 and the reproduction control unit 432 of the tuner-mounted / non-mounted receiver output data control unit 430.
- These configurations correspond to the configurations of the emergency information control units 140 and 160 and the playback control units 131 and 151 of the tuner-mounted receiver 30 and the tuner-unmounted receiver 40 shown in FIGS.
- the emergency information control unit 433 is set to execute data rendering such as an emergency message or a map included in the emergency information (AEAT).
- AEAT emergency information
- the application shown in FIGS. It is also possible for the control units 133 and 153 to execute data rendering such as an emergency message or a map included in the emergency information (AEAT). That is, the emergency information control unit 433 shown in FIG. 27 can be replaced with an application control unit.
- Step S421 First, the playback control unit (DASH client) 432 of the tuner-implemented / non-implemented receiver output data controller 430 receives signaling data applied emergency information (AEAT) from the MPD or the segment received via the tuner-equipped receiver middleware 420. ) A delivery event (AEATDerived Event) is extracted and transferred to the emergency information control unit 433.
- AEAT signaling data applied emergency information
- the playback control unit (DASH client) 432 is an MPD in which the signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) information described above with reference to FIG. From the segment in which the signaling data application type emergency information (AEAT) delivery event (AEATDerived Event) information described above with reference to FIG. 23 is recorded, A signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) is extracted.
- AEAT signaling data applied emergency information
- the following data is included in the MPD or segment in which the signaling data applied emergency information (AEAT) delivery event (AEATDerived Event) is inserted.
- AEAT emergency information
- AEAT emergency information
- AEAT emergency information
- duration duration
- Steps S422 to S423 the emergency information control unit 433 of the tuner-mounted / non-mounted receiver output data control unit 430 acquires the event information received from the reproduction control unit (DASH client) 432 in step S422, and in step S423, the emergency information (AEAT) The process which outputs data to a display part is performed.
- DASH client reproduction control unit
- AEAT emergency information
- the event information received from the playback control unit (DASH client) 432 includes emergency information (AEAT) data for output (display)
- the emergency information (AEAT) is acquired from the received event information.
- an emergency message or map information included in the emergency information (AEAT) is displayed.
- access information of emergency information is recorded in the event information received from the playback control unit (DASH client) 432, and access is not included when emergency information (AEAT) data for output (display) is not included.
- step S423 After executing processing for acquiring emergency information (AEAT) from tuner-implemented receiver middleware 420 using the information, in step S423, an emergency message or map information included in the acquired emergency information (AEAT) is displayed. .
- the emergency information (AEAT) acquired by the tuner-implemented receiver middleware 420 is stored in the cache unit 121 of the proxy server 120 illustrated in FIG. 10, and the emergency information control unit 433 is stored in the cache unit 121 of the proxy server 120.
- This acquisition process may be executed by the reproduction control unit (DASH client) 432 and provided to the emergency information control unit 433 from the reproduction control unit (DASH client) 432. ,
- Step S424 the playback control unit (DASH client) 432 of the tuner-mounted / non-mounted receiver output data controller 430 acquires AV content from the segment received via the tuner-mounted receiver middleware 420 and executes playback processing. .
- the playback control unit (DASH client) 432 of the tuner-mounted / non-mounted receiver output data controller 430 receives event information generated by the tuner-mounted receiver middleware 420 in conjunction with the process of receiving and playing back the AV segment. It is possible to acquire the inserted MPD or event information segment, detect that emergency information (AEAT) is transmitted as signaling data, and acquire and display emergency information (AEAT) from the signaling data.
- AEAT emergency information
- AEAT was demonstrated as an example as signaling data application type emergency information, it is emergency information which has formats other than AEAT, and about emergency information transmitted by applying signaling data, what format emergency information has Even so, the processing of the present disclosure can be applied.
- the middleware 110 of the tuner-implemented receiver 30 is provided with an event processing server 501 that executes an emergency information related event transfer process, and the tuner-mounted receiver 30 and the playback control unit (not tuner-implemented receiver 40) ( Event processing clients 511 and 521 are provided in parallel with DASH clients 131 and 151.
- Playback control units (DASH clients) 131 and 151 of tuner-mounted receiver 30 and tuner-unmounted receiver 40 B1 Event processing clients 511 and 521 are added in parallel with the playback control units (DASH clients) 131 and 151, (B2) Deletion of the event extraction units 205 and 255 in the reproduction control units (DASH clients) 131 and 151 shown in FIG.
- Other configurations of the configuration shown in FIG. 28 are the same as those of FIGS. 10 and 11 described above.
- the LLS signaling analysis unit 113 when the LLS signaling analysis unit 113 receives signaling data (LLS) including notification regarding emergency information, the LLS signaling analysis unit 113 transfers the signaling data to the event processing server 501. Specifically, for example, it is signaling data (LLS) including the notification data described above with reference to FIGS.
- signaling data (LLS) including the notification data described above with reference to FIGS.
- FIG. (A) On-screen message type emergency information delivery notification data (On Screen Message Notification) ” is signaling data (LLS) having a constituent element.
- the data shown in FIG. (B) Signaling data (LLS) having signaling data application type emergency information delivery notification data (AEAT Message Notification) as a constituent element.
- the LLS signaling analysis unit 113 of the middleware 110 shown in FIG. 28 receives the signaling data (LLS) including the notification related to the emergency information (a) or (b), the signaling data is sent to the event processing server 501. Forward.
- the event processing server 501 generates event information based on the signaling data (LLS) received from the LLS signaling analysis unit 113 and including notification regarding emergency information of any one of (a) and (b) above, and the generated event information Are transferred to the event processing clients 511 and 521.
- LLS signaling data
- the event information generated by the event processing server 501 is (A) On-screen message type emergency information delivery notification data (On Screen Message Notification) ”as signaling data (LLS) (B) Signaling data (LLS) having signaling data application type emergency information delivery notification data (AEAT Message Notification) as a constituent element
- the event information includes any one of the data (a) and (b).
- an event information relay session which is a secure session dedicated to emergency information transfer, is established in advance, and a constantly connected state is maintained.
- the event processing server 501 forwards event information based on signaling data (LLS) including notification regarding emergency information to the event processing clients 511 and 521 via the event information relay session.
- LLS signaling data
- the event processing clients 511 and 521 analyze the event information received from the event processing server 501 and execute necessary processing according to the analysis result. Specifically, the received event information is (A) On-screen message type emergency information delivery notification (On Screen Message Notification), If the application content is presented by the application running on the application control units 133 and 153, the event information is notified to the application control units 133 and 153. Processing for stopping the presentation processing of the presented content is performed.
- On-screen message type emergency information delivery notification On Screen Message Notification
- the received event information (B) Signaling data application type emergency information delivery notification (AEAT Message Notification), If the event information includes the event information, the emergency information control units 140 and 160 or the application control units 133 and 153 are notified of the event information, and the emergency information control units 140 and 160 or the application control unit 133 , 153, a process for obtaining emergency information (AEAT) and displaying a message included in the emergency information (AEAT) is performed.
- AEAT Signaling data application type emergency information delivery notification
- FIG. 29 shows the following three apparatuses. (1) Transmitter 410, (2) tuner mounted receiver middleware 420; (3) tuner mounted / non-mounted receiver output data control unit 430,
- FIG. 24 and FIG. 27 various configurations for generating and outputting AV segments, MPDs, and the like have been described. However, in the sequence diagram shown in FIG. Segment and MPD generation and transmission processing configurations are omitted, and only emergency information processing is shown. In parallel with the process for the emergency information described with reference to FIG. 28, the AV segment and MPD generation, transmission, and use (reproduction) processes are executed.
- Step S501 First, processing executed by the transmission device 410 will be described.
- the emergency information server 413 of the transmission device 410 generates emergency information to be displayed by being superimposed on an image constituting the broadcast content, and superimposes it on the image generated by the stream server 411.
- the emergency information distributed on the broadcast content image that is, the on-screen message type emergency information is generated, and the image generated by the stream server 411 is generated.
- the image generated by the stream server 411 is generated.
- superimpose the emergency information distributed on the broadcast content image
- Step S502 the emergency information server 413 of the transmission device 410 outputs a notification indicating that the on-screen message type emergency information is superimposed on the broadcast content image to the reception device via the broadcast signal generation unit (broadcast server) 414. To do.
- This signaling data transmission is performed using a session different from a communication session such as a broadcast stream.
- the tuner-implemented receiver middleware 420 has an event processing server 421.
- the event processing server 421 corresponds to the event processing server 501 in the middleware 110 of the tuner implementation receiving device 30 shown in FIG.
- an event information relay session that is a secure session dedicated to emergency information transfer is established. This session is always connected.
- Step S512 the event processing server 421 inputs “signaling data (LLS)” that is transmitted from the transmission device 410 and includes “on-screen message type emergency information delivery notification data (On Screen Message Notification)”.
- This signal link data (LLS) is input via the LLS signaling analysis unit 113 of the middleware 110 shown in FIG.
- LLS signaling data
- LLS signaling data
- FIG. 29 shows the application control unit 431 and the event processing client 435 of the tuner-mounted / non-mounted receiver output data control unit 430.
- These configurations correspond to the configurations of the application control units 133 and 153 and the event processing clients 511 and 521 of the tuner-mounted receiver 30 and the tuner-unmounted receiver 40 shown in FIG.
- Step S521 the event processing client 435 of the tuner-implemented / non-implemented receiver output data control unit 430 communicates with the event processing server 421 of the tuner-implemented receiver middleware 420 for an event information relay session that is a secure session dedicated to emergency information transfer. Establish. This session is always connected.
- Step S522 the event processing client 435 of the tuner-mounted / non-mounted receiver output data control unit 430 receives an event from the event processing server 421 of the tuner-mounted receiver middleware 420.
- Event information generated based on “Signaling data (LLS) having“ On Screen Message Notification Notification Data (On Screen Message Notification) ”as a component” is input.
- This event information includes recording information of “On Screen Message Notification Notification Data (On Screen Message Notification Notification)” described above with reference to FIG.
- step S523 the application control unit 431 of the tuner mounted / non-mounted receiver output data control unit 430 executes processing according to the event information received from the event processing client 435.
- the application control unit 431 performs a process of stopping the display of the application presentation content. Specifically, for example, the display of the weather forecast information presentation content described above with reference to FIG. 7 is stopped. This process allows the user (viewer) to surely confirm the emergency information that is superimposed and distributed on the broadcast content image.
- FIG. 30 shows the following three apparatuses. (1) Transmitter 410, (2) tuner mounted receiver middleware 420; (3) tuner mounted / non-mounted receiver output data control unit 430,
- FIG. 30 also shows only the processing for emergency information, omitting the AV segment and MPD generation and transmission processing configuration, as in FIG. In parallel with the process for the emergency information described with reference to FIG. 30, the AV segment and MPD generation, transmission, and use (reproduction) processes are executed.
- Step S601 to S602 First, processing executed by the transmission device 410 will be described.
- the emergency information server 413 of the transmission device 410 generates emergency information (AEAT) to be transmitted as signaling data in step S601, and transmits it via the broadcast signal generation unit (broadcast server) 414 in step S602.
- AEAT emergency information
- the emergency information generated by the emergency information server 413 is, for example, emergency information (AEAT: Advanced Emergency Alerting Table) having the data format described above with reference to FIG.
- the AEAT includes, for example, an emergency information message as emergency information, display data such as map information indicating an evacuation route, display data access information, and the like. This signaling data transmission is performed using a session different from a communication session such as a broadcast stream.
- the tuner-implemented receiver middleware 420 has an event processing server 421.
- the event processing server 421 corresponds to the event processing server 501 in the middleware 110 of the tuner implementation receiving device 30 shown in FIG.
- an event information relay session that is a secure session dedicated to emergency information transfer is established. This session is always connected.
- Step S612 the event processing server 421 inputs “signaling data (LLS)” including “signaling data application type emergency information delivery notification (AEAT Message Notification)” transmitted from the transmission device 410 as a component.
- This signal link data (LLS) is input via the LLS signaling analysis unit 113 of the middleware 110 shown in FIG.
- LLS signaling data
- LLS signaling data
- Step S613 the event processing server 421 of the tuner-implemented receiver middleware 420 transfers emergency information to the event information transferred to the event client 435 of the tuner-implemented / non-implemented receiver output data control unit 430 in step S612. Is output when data for output such as a message or map is not included.
- the event processing server 421 of the tuner-implemented receiver middleware 420 transfers emergency information (AEAT) including output data to the event processing client 435 in response to an emergency information (AEAT) acquisition request from the event processing client 435.
- AEAT emergency information
- FIG. 30 shows the emergency information control unit 433 and the event processing client 435 of the tuner-mounted / non-mounted receiver output data control unit 430.
- These configurations correspond to the configurations of the emergency information control units 140 and 160 and the event processing clients 511 and 521 of the tuner-mounted receiver 30 and the tuner-unmounted receiver 40 shown in FIG.
- the emergency information control unit 433 is set to execute data rendering such as an emergency message or a map included in the emergency information (AEAT).
- the application control unit 133 shown in FIG. , 153 can also perform data rendering such as emergency messages and maps included in emergency information (AEAT). That is, the emergency information control unit 433 shown in FIG. 30 can be replaced with an application control unit.
- Step S621 First, the event processing client 435 of the tuner-implemented / non-implemented receiver output data control unit 430 communicates with the event processing server 421 of the tuner-implemented receiver middleware 420 for an event information relay session that is a secure session dedicated to emergency information transfer. Establish. This session is always connected.
- Step S622 the event processing client 435 of the tuner-mounted / non-mounted receiver output data control unit 430 receives an event from the event processing server 421 of the tuner-mounted receiver middleware 420.
- Event information generated based on “signaling data (LLS) having“ signaling data applied emergency information delivery notification (AEAT Message Notification) ”as a constituent element” is input.
- This event information includes the recording information of “signaling data application type emergency information delivery notification (AEAT Message Notification)” described above with reference to FIG.
- This event information includes, for example, the following data.
- Steps S623 to S624 the emergency information control unit 433 of the tuner-mounted / non-mounted receiver output data control unit 430 acquires event information received from the event processing client 435 in step S623, and in step S624, emergency information (AEAT) data Is output to the display unit.
- AEAT emergency information
- the event information received from the event processing client 435 includes emergency information (AEAT) data for output (display)
- the emergency information (AEAT) is acquired from the received event information, and step S423 is performed.
- the emergency message or map information included in the emergency information (AEAT) is displayed.
- the access information of emergency information (AEAT) is recorded in the event information received from the event processing client 435 and the emergency information (AEAT) data for output (display) is not included, the access information is used.
- the process of acquiring emergency information (AEAT) from the event processing server 421 of the tuner-implemented receiving apparatus middleware 420 in step S624, an emergency message or map information included in the acquired emergency information (AEAT) is displayed. To do.
- the event processing client 435 of the tuner-mounted / non-mounted receiver output data control unit 430 acquires the event information generated by the event processing server 421 of the tuner-mounted receiver middleware 420 and acquires emergency information (AEAT). Can be displayed.
- AEAT emergency information
- AEAT was demonstrated as an example as signaling data application type emergency information, it is emergency information which has formats other than AEAT, and about emergency information transmitted by applying signaling data, what format emergency information has Even so, the processing of the present disclosure can be applied.
- FIG. 31 shows a configuration example of the transmission device (server) 20 and the reception device (client) 30.
- the transmission device (server) 20 includes a data processing unit 751, a communication unit 752, and a storage unit 753.
- the receiving devices (clients) 30 and 40 include a communication unit 771, a communication data processing unit 772, an output data processing unit 773, a storage unit 774, an input unit 775, and an output unit 776.
- the data processing unit 751 of the transmission device (server) 20 executes various data processing for executing the data distribution service. For example, generation of configuration data of the data distribution service and transmission control are performed. Further, the data processing unit 751 performs generation and transmission processing of application, emergency information, signaling data, and other various data in addition to AV stream data such as broadcast content provided to the receiving device (client) 30.
- the communication unit 752 performs communication processing such as distribution of application, emergency information, signaling data, and other various data in addition to AV stream data such as broadcast content.
- the storage unit 753 stores AV stream data such as broadcast contents to be distributed, as well as applications, emergency information, signaling data, and other various data. Further, the storage unit 753 is used as a work area for data processing executed by the data processing unit 751 and is also used as a storage area for various parameters.
- the receiving devices (clients) 30 and 40 include a communication unit 771, a communication data processing unit 772, an output data processing unit 773, a storage unit 774, an input unit 775, and an output unit 776.
- the communication unit 771 has different settings for the communication unit of the tuner-mounted receiver 30 and for the tuner-unmounted receiver 40.
- the communication unit of the tuner-implemented receiving device 30 receives data distributed from the transmitting device (server) 20, for example, AV stream data such as broadcast content, as well as applications, emergency information, signaling data, and other various data. . Furthermore, it is configured as a communication unit capable of transmitting and receiving data via a network such as a LAN or Wi-Fi.
- the communication unit of the non-tuner receiving device 40 does not have a tuner unit that can receive broadcast waves, and is configured as a communication unit that can execute data transmission / reception via a network such as LAN or Wi-Fi.
- the communication data processing unit 772 corresponds to the middleware 110 of the communication data processing unit 772 shown in FIG. Processing such as acquisition of signaling data, analysis, generation of event information, generation of event insertion MPD, event insertion segment, and the like are executed.
- the event processing server 501 described with reference to FIG. 28 may be included.
- the output data processing unit 773 includes a playback control unit (DASH client), an output control unit, an application control unit, an emergency information control unit, an event processing client, and the like, and executes, for example, processing according to the above-described embodiment. To do. Specifically, in addition to broadcast content output control, emergency information output control, application presentation content display control processing, and the like are executed.
- DASH client playback control unit
- an output control unit an application control unit
- an emergency information control unit an emergency information control unit
- an event processing client and the like
- the reproduction data is output to an output unit 776 such as a display unit or a speaker.
- the storage unit 774 stores AV segments, MPDs, recent state information, signaling data, and the like. Further, the storage unit 774 is used as a work area for data processing executed by the data processing unit 771 and also used as a storage area for various parameters.
- FIG. 32 shows a hardware configuration example of a communication device applicable as the transmission device 20 and the reception device 30.
- a CPU (Central Processing Unit) 801 functions as a data processing unit that executes various processes according to a program stored in a ROM (Read Only Memory) 802 or a storage unit 808. For example, processing according to the sequence described in the above-described embodiment is executed.
- a RAM (Random Access Memory) 803 stores programs executed by the CPU 801, data, and the like. These CPU 801, ROM 802, and RAM 803 are connected to each other by a bus 804.
- the CPU 801 is connected to an input / output interface 805 via a bus 804.
- the input / output interface 805 is connected to an input unit 806 including various switches, a keyboard, a mouse, and a microphone, and an output unit 807 including a display and a speaker. Yes.
- the CPU 801 executes various processes in response to a command input from the input unit 806 and outputs a processing result to the output unit 807, for example.
- the storage unit 808 connected to the input / output interface 805 includes, for example, a hard disk, and stores programs executed by the CPU 801 and various data.
- a communication unit 809 functions as a transmission / reception unit for data communication via a network such as the Internet or a local area network, and further as a transmission / reception unit for broadcast waves, and communicates with an external device.
- the drive 810 connected to the input / output interface 805 drives a removable medium 811 such as a semiconductor memory such as a magnetic disk, an optical disk, a magneto-optical disk, or a memory card, and executes data recording or reading.
- a removable medium 811 such as a semiconductor memory such as a magnetic disk, an optical disk, a magneto-optical disk, or a memory card, and executes data recording or reading.
- the encoding or decoding of data can be executed as a process of the CPU 801 as a data processing unit, but a configuration including a codec as dedicated hardware for executing the encoding process or the decoding process may be adopted.
- the technology disclosed in this specification can take the following configurations.
- middleware for executing processing for analyzing received data from a transmission device;
- An output data control unit for executing an output control process of received data from the transmission device;
- the middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification,
- the output data control unit A receiving device that acquires the event notification data and executes emergency information acquisition or display processing based on the acquired event notification data.
- the emergency information delivery notification sent by the sending device is An on-screen message type emergency information delivery notification for notifying delivery of emergency information superimposed on a transmission image of the transmission device;
- the middleware is Generate emergency information event notification data indicating that on-screen message type emergency information delivery notification has been made,
- the application control unit constituting the output data control unit is Based on the acquired emergency information event notification data, the output of the application presentation content to the display unit is stopped, and the emergency information superimposed on the transmission image of the transmission device is controlled to be visible (1) The receiving device described.
- the emergency information delivery notification sent by the sending device is A signaling data application type emergency information delivery notification for notifying delivery of emergency information by signaling data transmitted from the transmitting device;
- the middleware is Generate emergency information event notification data indicating that signaling data application type emergency information delivery notification has been made,
- the output data control unit Processing to display the emergency information included in the acquired emergency information event notification data, Alternatively, the receiving device according to (1) or (2), wherein any one of processes for outputting emergency information acquired using emergency information access information included in the acquired emergency information event notification data to a display unit is executed.
- the signaling data application type emergency information delivery notification is: The receiving apparatus according to (3), which is a notification including an AEAT (Advanced Emergency Alerting Table) defined as a standard for emergency information.
- AEAT Advanced Emergency Alerting Table
- the middleware is As the emergency information event notification data, Generating an emergency information event insertion MPD in which the configuration data of the emergency information delivery notification is inserted into MPD (Media Presentation Description);
- the output data control unit The receiving device according to any one of (1) to (4), wherein an emergency information acquisition or display process is executed based on the acquired information from the emergency information event insertion MPD.
- the middleware is As a pre-process for causing the output data control unit to acquire the emergency information event insertion MPD without delay, The receiving device according to (5), wherein an MPD update notification is output to the output data control unit.
- the middleware is As the emergency information event notification data, Generate an emergency information event insertion segment in which the configuration data of the emergency information delivery notification is inserted into the segment, The output data control unit The receiving device according to any one of (1) to (6), wherein emergency information acquisition or display processing is executed based on information acquired from the emergency information event insertion segment.
- the middleware is Store the generated emergency information event notification data in the cache,
- the output data control unit The receiving device according to any one of (1) to (7), wherein the event notification data is acquired by accessing the cache unit.
- the middleware is An event processing server for generating and transmitting the emergency information event notification data;
- the output data control unit The event processing client that receives the emergency information event notification data from the event processing server,
- the event processing client establishes a session dedicated to event transfer with the event processing server, and receives the emergency information event notification data from the event processing server via the established dedicated session (1) to (4) )
- the receiving device according to any one of
- the middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification, A receiving device that provides generated emergency information event notification data to a client that executes an output control process of received data from the transmitting device.
- the emergency information delivery notification transmitted by the transmitting device is An on-screen message type emergency information delivery notification for notifying delivery of emergency information superimposed on a transmission image of the transmission device;
- the middleware is The receiving device according to (10), which generates emergency information event notification data indicating that an on-screen message type emergency information delivery notification has been made.
- the emergency information delivery notification sent by the sending device is A signaling data application type emergency information delivery notification for notifying delivery of emergency information by signaling data transmitted from the transmitting device;
- the middleware is The receiving device according to (10) or (11), wherein emergency information event notification data indicating that a signaling data application type emergency information delivery notification has been made is generated.
- the middleware is As the emergency information event notification data, The receiving device according to any one of (10) to (12), wherein an emergency information event insertion MPD is generated by inserting the configuration data of the emergency information delivery notification into an MPD (Media Presentation Description).
- an emergency information event insertion MPD is generated by inserting the configuration data of the emergency information delivery notification into an MPD (Media Presentation Description).
- the middleware is As the emergency information event notification data, The receiving device according to any one of 10 to (13), wherein an emergency information event insertion segment is generated by inserting the configuration data of the emergency information delivery notification into a segment.
- the output data control unit Obtaining emergency information event notification data including configuration data of an emergency information delivery notification transmitted by the transmission device; A receiving device that executes emergency information acquisition or display processing based on acquired event notification data.
- the emergency information delivery notification transmitted by the transmitting device is An on-screen message type emergency information delivery notification for notifying delivery of emergency information superimposed on a transmission image of the transmission device;
- the output data control unit Get emergency information event notification data indicating that on-screen message type emergency information delivery notification has been made,
- the application control unit constituting the output data control unit is On the basis of the acquired emergency information event notification data, the output of the application presentation content to the display unit is stopped, and the emergency information superimposed on the transmission image of the transmission device is made visible (15).
- the emergency information delivery notification transmitted by the transmitting device is A signaling data application type emergency information delivery notification for notifying delivery of emergency information by signaling data transmitted from the transmitting device;
- the output data control unit Obtain emergency information event notification data indicating that signaling data application type emergency information delivery notification has been made, Processing to display the emergency information included in the acquired emergency information event notification data, Or the receiving apparatus as described in (15) or (16) which performs either of the processes which output the emergency information acquired using the emergency information access information contained in the acquired emergency information event notification data to a display part.
- a data processing method executed in the receiving device is: Middleware that executes analysis processing of received data from the transmitting device; An output data control unit for executing an output control process of received data from the transmission device; The middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification, The output data control unit A data processing method for acquiring the event notification data and executing emergency information acquisition or display processing based on the acquired event notification data.
- a data processing method executed in the receiving device is: It has middleware that executes analysis processing of received data from the transmitting device, The middleware is Receiving the emergency information delivery notification transmitted by the transmitting device, generating emergency information event notification data including the configuration data of the received emergency information delivery notification, A data processing method for providing generated emergency information event notification data to a client that executes output control processing of received data from the transmission device.
- a data processing method executed in the receiving device is: It has an output data control unit that executes output control processing of received data from the transmission device, The output data control unit Obtaining emergency information event notification data including configuration data of an emergency information delivery notification transmitted by the transmission device; A data processing method for executing emergency information acquisition or display processing based on acquired event notification data.
- the series of processes described in the specification can be executed by hardware, software, or a combined configuration of both.
- the program recording the processing sequence is installed in a memory in a computer incorporated in dedicated hardware and executed, or the program is executed on a general-purpose computer capable of executing various processing. It can be installed and run.
- the program can be recorded in advance on a recording medium.
- the program can be received via a network such as a LAN (Local Area Network) or the Internet and installed on a recording medium such as a built-in hard disk.
- the various processes described in the specification are not only executed in time series according to the description, but may be executed in parallel or individually according to the processing capability of the apparatus that executes the processes or as necessary.
- the system is a logical set configuration of a plurality of devices, and the devices of each configuration are not limited to being in the same casing.
- the middleware of a receiving device that performs broadcast content output processing receives an emergency information distribution notification transmitted by the transmitting device, and generates emergency information event notification data including configuration data of the received emergency information distribution notification To do.
- the output data control unit acquires event notification data, and executes emergency information acquisition or display processing based on the acquired event notification data. For example, when the emergency information superimposed on the image is distributed, the application presentation content is removed by event notification, and in the case of the signaling emergency information distribution, the quick emergency information acquisition and output processing is performed.
- this configuration it is possible to realize a configuration that enables quick and reliable presentation processing of emergency information to a viewer.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- Emergency Management (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Alarm Systems (AREA)
- Communication Control (AREA)
- Hardware Redundancy (AREA)
Abstract
Description
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術として、例えば特許文献2(特開2014-057227号公報)がある。
ATSC3.0では、ATSC3.0準拠物理層(ATSC-PHY)を実装した放送配信用デバイス(チューナ実装デバイス)上に、ATSC3.0放送の受信処理等を実行するミドルウェア(ATSC3.0放送受信ミドルウェア)を実装させることで、ATSC放送用の制御情報等を含むシグナリングデータを受信して、シグナリングデータによる様々な制御を可能とする構成を検討している。
これらのサーバが、いったんATSC3.0放送サービスを受信した後、ネットワーク(ホームネットワークやホットスポット等のLAN/WiFi等)を介して、ユーザ装置(PC、TV、タブレット、スマホ等)に放送受信データを転送する。
ミドルウェアは、このような緊急情報の受信を検知したタイミングでできるだけ早く、放送サービスの出力(表示)制御を実行している再生制御部(クライアント)に通知し、緊急情報を表示データとして出力させることが必要となる。
これらのリモートのクライアントでは、各クライアントの再生制御部やアプリケーション制御部が、様々なデータを表示部に表示している。
ミドルウェアは、このようなリモートクライアントの再生制御部やアプリケーション制御部に対しても、できるだけ早く緊急情報が受信されたことを通知し、緊急情報を表示データとして出力させることが必要となる。
このような場合、スマホのアプリケーション制御部にアプリ提示物を削除させる処理を要求することが必要となる。
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部は、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置にある。
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供する受信装置にある。
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部は、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置にある。
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部が、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法にある。
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供するデータ処理方法にある。
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部が、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法にある。
具体的には、例えば、放送コンテンツ出力処理を行なう受信装置のミドルウェアが、送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成する。出力データ制御部は、イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する。例えば、画像上に重畳された緊急情報が配信される場合は、イベント通知により、アプリ提示コンテンツの除去を実行させ、シグナリング緊急情報配信の場合は、迅速な緊急情報の取得、出力処理を実行させる。
本構成により、緊急情報の迅速、かつ確実な視聴者への提示処理を可能とした構成が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
1.通信システムの構成例について
2.データ通信プロトコルFLUTE、およびROUTEについて
3.送信装置と受信装置の実行する通信処理例について
4.緊急情報の送信と出力処理の概要について
5.受信装置の構成例と処理例について
6.シグナリングデータを適用した緊急情報配信通知処理について
7.イベント通知構成について
7-1.MPD適用イベント通知方式(=MPD Event)について
7-2.セグメント適用イベント通知方式(=In-band Event Signaling)について
8.緊急情報配信通知処理のためのイベント通知構成について
8-1.オンスクリーンメッセージ型緊急情報配信通知をイベント情報として通知する構成について
8-1-1.MPD適用イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について
8-1-2.セグメント適用(In-band)イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について
8-1-3.オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
8-2.シグナリングデータ適用型緊急情報配信通知をイベント情報として通知する構成について
8-2-1.MPD適用イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について
8-2-2.セグメント適用(In-band)イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について
8-2-3.シグナリングデータ適用型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
9.イベント情報の転送専用のサーバとクライアントを有する構成例について]
9-1.オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
9-2.シグナリングデータ適用型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
10.送信装置と受信装置の構成例について
11.本開示の構成のまとめ
まず、図1を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図1に示すように、通信システム10は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置20と、送信装置20の送信するコンテンツを放送波やネットワークを介して受信する通信装置であるチューナ実装受信装置30と、送信装置20の送信するコンテンツをチューナ実装受信装置30、ネットワークを介して受信するチューナ非実装受信装置40を有する。
チューナ実装受信装置30は、放送波を受信するためのチューナを備えた受信装置である。例えば一般ユーザのクライアント装置やホームサーバ、公共施設に設置された中継サーバ等である。具体的には、例えば、中継サーバ(ホームサーバ等を含む)31、テレビ32、PC33、携帯端末34等である。
また、チューナ非実装受信装置40は、放送波を受信するためのチューナを備えていない受信装置である。具体的には、例えば、PC41、携帯端末42等である。
なお、DASH(Dynamic Adaptive Streaming overHTTP)規格は、前述したようにHTTP(HyperText Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブ(適応型)ストリーミング配信に関する規格である。
(a)動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル(MPD:Media Presentation Description)に関する規格、
(b)動画コンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に関する規格、
送信装置20から、チューナ実装受信装置30に対するコンテンツ配信は、上記のMPEG-DASH規格に従って実行される。
チューナ実装受信装置30や、チューナ非実装受信装置40は、送信装置20の送信したコンテンツの再生を行なうことができる。
MPEG-DASH規格に従ってデータ送信を実行する送信装置20は、図2に示すように、大きく分けて以下の複数種類のデータの送信を行う。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
このシグナリングデータ50は、例えばXML(Extensible Markup Language)形式のデータとして送信装置20から送信される。
これは、受信装置(クライアント)が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント(受信装置)は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
また、地震情報、テロ情報等の緊急情報についても、大きな遅れを発生させることなく多くの受信装置に一生に提供することが可能となる。
ESGは、電子サービスガイド(Electronic Service Guide)であり、例えば番組表等の案内情報である。
NRTコンテンツはノンリアルタイム型のコンテンツである。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG,NRTコンテンツ等)70
これらのデータは、例えば、データ通信プロトコル:FLUTE(File Delivery over Uni-directional Transport)に従って送信される。
データ通信プロトコル:FLUTE(File Delivery over Uni-directional Transport)はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル(URLとバージョンで識別される)は、FLUTEプロトコルに従って、受信装置であるクライアントに送信される。
同じURLでバージョンが異なるものはファイルの中身が更新されているものとみなす。FLUTEプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、FLUTEで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、FLUTEプロトコルに拡張して組み込むこともできるし、別途ESG(Electronic Service Guide)等のプロトコルで記述することもできる。
次に、送信装置と受信装置の実行する通信処理例について説明する。
図3は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図3に示す例は、以下の2つの通信データの処理を行なうための2つのプロトコルスタックを有する。
(a)ブロードキャスト(マルチキャストも含む)通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
図3の右側が、(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)に対応するプロトコルスタックである。
(1)ブロードキャスト物理レイヤ(Broadcast PHY)
(2)IPマルチキャストレイヤ(IP Multicast)
(3)UDPレイヤ
(4)ROUTE(=拡張型FLUTE)レイヤ
(5)ESG,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC、シグナリング(SLS:Service Level Signaling)
(6)アプリケーションレイヤ(Applications(HTML5))
LLS(ローワレイヤシグナリング)
SLS(サービスレベルシグナリング)
SLS(サービスレベルシグナリング)は、各サービス単位、例えば各番組単位の制御情報、案内情報、メタデータ等を格納したシグナリングデータである。
LLS(ローワレイヤシグナリング)は、SLSより上位の制御情報、案内情報、メタデータ等を格納したシグナリングデータであり、例えば、SLSを取得するための情報等が含まれる。
USDには、様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ(AVセグメント)に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータであるMPD(メディアプレゼンテーションディスクリプション(Media Presentation Description))がある。
(2)IPマルチキャストレイヤ(IP Multicast)は、IPマルチキャストに従ったデータ送受信処理を実行するレイヤである。
(3)UDPレイヤは、UDPパケットの生成、解析処理レイヤである。
ROUTEは、FLUTEと同様、ALCと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるLCTやFECコンポーネントの組み合わせにより構成される。
図4に、ROUTE、およびFLUTEに関するプロトコルスタックを示す。
MBMSやeMBMSは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末(UE)に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。MBMSやeMBMSに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやPC、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
(a)シグナリングデータ50
(b)AVセグメント60
(c)その他のデータ(ESG、NRTコンテンツ等)70
これらのデータの多くはROUTEプロトコル、またはFLUTEプロトコルに従って送信される。
前述したように、NRTコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
Video/Audio/CCは、DASH規格に従って配信されるビデオやオーディオ等、再生対象となる実データである。
(1)ブロードバンド物理レイヤ(Broaband PHY)
(2)IPユニキャストレイヤ(IP Unicast)
(3)TCPレイヤ
(4)HTTPレイヤ
(5)ESG,Signaling,NRTcontent,DASH(ISO BMFF)およびVideo/Audio/CC
(6)アプリケーションレイヤ(Applications(HTML5))
(2)IPユニキャストレイヤ(IP Unicast)は、IPユニキャスト送受信処理を実行するレイヤである。
(3)HTTPレイヤは、HTTPパケットの生成、解析処理レイヤである。
この上位レイヤは、図3左側の(a)ブロードキャスト通信(例えば放送型データ配信)のスタック構成と同様である。
(a)ブロードキャスト通信(例えば放送型データ配信)
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
これら2つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
(b)ユニキャスト(ブロードバンド)通信(例えばHTTP型のP2P通信)
この通信プロトコルスタックに従った通信処理を実行する。
ATSC3.0におけるIPベースのトランスポートスタックの標準化において、MPEG-DASHのファイルフォーマット(ISO-BMFFファイル、MP4ファイル)に基づくファイルをFLUTE(File Delivery over Unidirectional Transport)を拡張したROUTE(Real-Time Object Delivery over Unidirectional Transport)プロトコルにより転送する方法が提案され、標準候補方式として設定された。
図1を参照して説明した通信システムにおいて、送信装置20から緊急情報が送信され、チューナ実装受信装置30が受信した場合、この緊急情報は、チューナ実装受信装置30やチューナ非実装受信装置40の表示部に、いち早く出力し、遅滞なくユーザが確認可能な状態にすることが必要となる。
このAEATやCAPメッセージを受信した受信装置は、受信メッセージを解析して、例えば緊急情報のカテゴリや緊急度、あるいは、受信装置の現在位置等に応じて必要な情報を選択して出力(表示)する。
チューナ実装受信装置30は、ATSC3.0放送サービスの制御情報を含むシグナリングデータの解析等を実行するミドルウェア(ATSC3.0放送受信ミドルウェア)を有するが、チューナ非実装受信装置40は、このようなミドルウェアを有していない。
ミドルウェアは、例えば、ネットワーク接続されたリモートのクライアント(PC、TV、タブレット、スマホ等)の再生制御部やアプリケーション制御部上で稼働するアプリケーション(例えばATSC3.0 DASHクライアントアプリケーション)に緊急メッセージが受信されたことを通知しなければない。
図5は、放送局等の送信装置が配信する番組コンテンツの画像上に緊急情報を重畳した画像データを配信する構成である。
(a)通常番組表示として例えば野球中継の番組コンテンツが配信されている際に、緊急情報が発生すると、放送局側で緊急情報を野球中継画像上に重畳した番組コンテンツを生成して受信装置に配信する。
このように、再生コンテンツに緊急情報を直接重畳して配信する緊急情報配信方式は、オンスクリーンメッセージ(OnScreenMessage)型緊急情報配信方式と呼ばれる。
放送局等の送信装置20は、例えば番組配信路を介した複数のチャンネル(CH1.1,CH1.2)対応の番組コンテンツの配信と、シグナリング伝送路を介したシグナリングデータの配信を行う
その後、放送局である送信装置20は、時間t2おいて緊急情報を野球中継画像上に重畳した番組コンテンツを生成して受信装置30に配信する。
受信装置30側で野球中継を見ているユーザ(視聴者)は、野球中継画面に重畳された緊急情報を確認することができる。
具体例を図7に示す。
図7(2b)に示す例は、ユーザ(視聴者)が野球中継を見ている間に、天気予報表示アプリケーションを実行し、天気予報情報の表示を実行している例である。
この天気予報表示アプリケーションは、例えば、放送局が野球中継放送コンテンツに併せて、別途、配信したアプリケーション、あるいは、クライアント(テレビ)側が事前にNRTコンテンツとして取得したアプリケーション等である。
図7(2c)に示すように、番組コンテンツ上に緊急情報が重畳表示されている場合には、緊急情報がアプリケーション提示コンテンツによって隠れてしまい、ユーザ(視聴者)が確認できないという事態が発生する。
図8は、シグナリングデータ適用型緊急情報配信方式を示している。
例えば放送局等の送信装置20は、通常の番組配信経路とは異なる通信経路であるシグナリングデータ(LLS::Lower Layer Signaling)専用の通信経路を利用して緊急情報を送信することが可能である。
先に説明したAEAT(Advanced Emergency Alerting Table)や、CAP(Common Alerting Protocol)フォーマットに従った緊急情報は、このシグナリングデータ適用型緊急情報配信方式に従って送信される。
その後、放送局である送信装置20は、時間t2おいて緊急情報を格納したシグナリングデータ(LLS)を生成して受信装置30に配信する。
受信装置30は、このシグナリングデータを受信し、野球中継の表示画面上にシグナリングデータから取得した緊急情報を表示する。
図9(3c)に示す地図データも、シグナリングデータによる送信データである。
例えば、前述したAEATや、CAP等のシグナリングデータには、緊急情報の様々な属性情報、例えば、緊急情報のカテゴリ、緊急情報の緊急度や発信元情報、緊急情報の通知が必要な地域情報等、様々な緊急情報名に関する詳細な情報が記録可能であり、受信装置は、受信したシグナリングデータを解析して、例えば緊急情報のカテゴリや緊急度、あるいは、受信装置の現在位置等に応じて必要な情報を選択して出力(表示)することができる。
これらの情報帆を適用して、図9(3c)に示すように、受信装置の位置に応じた地図を表示することができる。
(a)オンスクリーンメッセージ(OnScreenMessage)型緊急情報配信方式、
(b)シグナリングデータ適用型緊急情報配信方式、
また、図8、図9を参照して説明したシグナリングデータ適用方式の場合、受信装置30は、このシグナリングデータの送信装置20による送信処理後、即座に受信して表示処理を行なわなければ、ユーザ(視聴者)による緊急情報の確認処理が遅れ、ユーザの安全が確保できなくなる恐れがある。
本開示は、このような問題の発生を防止し、緊急情報を確実にかつ即座(タイムリ)にユーザ(視聴者)に確認させることを可能とした構成を実現するものである。
次に、図10以下を参照して、図1を参照して説明したチューナ実装受信装置(クライアントA)30と、チューナ非実装受信装置(クライアントB)40の構成例と処理例について説明する。
放送サーバ21は、放送波や、ネットワークを介したブロードキャスト送信により、放送コンテンツ等からなるAVセグメント、シグナリングデータ、その他のデータを送信する。
図には示していないが、放送サーバ21以外の送信装置であるデータ配信サーバ22もネットワークを介したブロードキャスト送信により、放送コンテンツ等からなるAVセグメント、シグナリングデータ、その他のデータを送信する。
ミドルウェア110は、以下の構成要素を有する。
通信部(PHY/MAC)111、
LLSシグナリング取得部112、
LLSシグナリング解析部113、
SLSシグナリング取得部114、
SLSシグナリング解析部(MPDイベント挿入部)115、
セグメント取得部117、
インバンドイベント挿入部118。
LLSシグナリング取得部112と、LLSシグナリング解析部113は、通信部111を介して受信するローワレイヤ・シグナリングデータ(LLS:Lower Layer Signaling)を受信し、解析する。
SLSシグナリング取得部114と、SLSシグナリング解析部115は、通信部111を介して受信するサービスレベル・シグナリングデータ(SLS:Service Level Signaling)を受信し、解析する。
セグメント取得部117は、映像、音声等の番組コンテンツデータや、アプリケーション等のNRTコンテンツ、さらにシグナリングデータ等のデータを格納したセグメントを取得する。
SLSシグナリング解析部115は、放送番組や送信データの変更や詳細等の通知情報、受信装置において実行するアプリケーションに関する情報、さらに緊急情報関連の情報等、受信装置において必要となる処理の情報などを含むイベント情報をシグナリングデータであるMPD(Media Presentation Description)内に挿入する処理を実行するMPDイベント挿入部として機能する。
インバンド(In-band)イベント挿入部118は、緊急情報等のイベント情報をセグメント内に挿入する処理を実行する。
具体的には、例えば、先に図7を参照して説明したようなアプリケーション提示コンテンツが表示されている場合、この提示コンテンツの排除処理要求を格納したイベント情報を送信してイベント通知を行う。
また、シグナリングデータとして送信される緊急メッセージの発行状況やアクセス情報を通知する緊急情報関連情報を格納したイベント情報をクライアントに提供して、迅速な緊急情報の取得、表示を可能とする。
これらの具体的な処理については後段で詳細に説明する。
前述したように、MPEG-DASH規格には、以下の2つの規格が含まれる。
(a)動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル(MPD:Media Presentation Description)に関する規格、
(b)動画コンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に関する規格、
送信装置20から、チューナ実装受信装置30に対するコンテンツ配信は、上記のMPEG-DASH規格に従って実行される。
通知するイベント情報には、例えば送信装置からの緊急情報の送信に伴って、受信装置側において実行すべき処理の要求や処理を可能とするための情報を含むイベント情報が含まれる。
これらのイベント情報を適用した処理の具体例については後段で詳細に説明する。
さらに、アプリケーション制御部133は、再生制御部131のイベント抽出部の抽出したイベント情報に従って、例えば、図7を参照して説明したアプリケーション提示コンテンツの表示処理や除去処理等を実行する。
緊急情報制御部140も、再生制御部131のイベント抽出部の抽出したイベント情報に従って、例えば、図8を参照して説明したシグナリングデータ適用型の緊急情報の取得処理等を実行する。
これら、イベント情報を適用した処理の詳細については後段で説明する。
チューナ非実装受信装置(クライアントB)40は、チューナ実装受信装置(クライアントA)30が、放送サーバ21や、データ配信サーバ22から受信したコンテンツ等のデータを、チューナ実装受信装置(クライアントA)30を介して受信し、コンテンツ再生を実行する。
再生制御部(DASHクライアント)151、
出力制御部152、
アプリケーション制御部153、
緊急情報制御部160、
これらの構成を有する。
これらの構成、機能は、チューナ実装受信装置(クライアントA)30において説明した再生制御部(DASHクライアント)131、出力制御部132、アプリケーション制御部133、緊急情報制御部140と同様である。
再生制御部(DASHクライアント)131、
出力制御部132と、
アプリケーション制御部133、
緊急情報制御部140、
チューナ非実装受信装置(クライアントB)40の有する、
再生制御部(DASHクライアント)151、
出力制御部152、
アプリケーション制御部153、
緊急情報制御部160、
これらの詳細構成を示す図である。
MPD取得部201は、動画や音声ファイルの管理情報記述ファイルであるマニフェスト・ファイル(MPD:Media Presentation Description)を取得する。
MPDは、放送サーバ21、データ配信サーバ22から提供され、プロキシサーバ120に格納された後、再生制御部131が取得する。
さらに、MPD解析部202は、MPDにイベント情報が含まれている場合、MPDをイベント抽出部205に出力する。
(a)オンスクリーンメッセージ(OnScreenMessage)型の緊急情報が配信されたこと、
(b)シグナリングデータ適用型の緊急情報が配信されたこと、
上記(a),(b)のいずれの通知データを含むイベント情報かを判定する。
一方、イベント抽出部205は、イベント情報が、「(b)シグナリングデータ適用型の緊急情報が配信されたこと」を示すイベント情報であると判定した場合、このイベント情報を緊急情報制御部140、またはアプリケーション制御部133に出力する。
この処理により、オンスクリーンメッセージ(OnScreenMessage)型の緊急情報が配信された場合、緊急情報を確実にユーザに見せることが可能となる。
この処理により、シグナリングデータ適用型の緊急情報が配信された場合、緊急情報を即座に取得し、確実にユーザに見せることが可能となる。
セグメントは、AVデータからなるコンテンツ伝送用のファイル・フォーマット(セグメント・フォーマット)に従って設定される所定の単位データである。
(a)オンスクリーンメッセージ(OnScreenMessage)型の緊急情報が配信されたこと、
(b)シグナリングデータ適用型の緊急情報が配信されたこと、
上記(a),(b)のいずれの通知データを含むイベント情報かを判定する。
一方、イベント抽出部205は、イベント情報が、「(b)シグナリングデータ適用型の緊急情報が配信されたこと」を示すイベント情報であると判定した場合、このイベント情報を緊急情報制御部140、またはアプリケーション制御部133に出力する。
復号部(デコーダ)211は、セグメント解析部204から提供された符号化画像データ、符号化音声データの復号処理(テーコード)を実行する。
出力部212は、復号された画像データ、音声データを出力部(ディスプレイ、スピーカ)に出力する。
また、出力制御部152は、復号部(デコーダ)261と、出力部(レンダラ)262を有する。
これらの構成、および実行する処理は、チューナ実装受信装置(クライアントA)30の構成、処理と同様である。
また、チューナ非実装受信装置(クライアントB)40のアプリケーション制御部153には、チューナ実装受信装置(クライアントA)30のプロキシサーバ120、ネットワークを介してアプリケーションファイルが入力される。
ATSC3.0クライアントアプリケーションは、ATSC3.0放送受信クライアントデバイス上に実装されたブラウザ上で実行される。あるいは、ブラウザアプリケーションとしてだけではなくネィティブアプリケーションとして実行される場合もある。
さらに、ネィティブアプリケーションとして実装されるものとして、これらのWebアプリケーションのライフサイクル制御を行うアプリケーションマネジャ("3.0 Application Manager")、AEATメッセージレンダラーアプリケーション("CAP Message Renderer")等が含まれる。
従って放送向けのみに特化してアプリケーションを実装する必要がなく、放送もインターネットのどちらを使うかによらない実装とすることができる。
MPDイベントとは、DASHイベントのうちの1つである。
DASHイベントは、DASHのMPD、もしくは、DASHセグメントにより、ストリーミングのプロトコルの中で、あらかじめスケジュールされた、もしくは、スケジュールの決まっていない(イベントのアクティベート(活性化)時刻が未定な)イベントを転送・制御する機構である。
(a)イベント情報をシグナリングデータであるMPD(Media Presentation Description)内に挿入して転送するMPD適用イベント通知方式、
(b)イベント情報をセグメント内に挿入して転送するセグメント適用(In-band)イベント通知方式、
これらの2種類がある。
(a)オンスクリーンメッセージ(OnScreenMessage)型緊急情報が配信されたこと(オンスクリーンメッセージ通知:On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報(AEAT、CAP等)が配信されたことの通知:(AEAT Message Notification)、
ただし、本開示の処理は、AEATに限らず、AEAT以外のデータフォーマットを持つ様々なシグナリングデータ適用型緊急情報に対しても、同様の処理が可能である。
なお、AEATのデータフォーマットについては後段で説明する。
抽出された通知データを、SLSシグナリング解析部115内のMPDイベント挿入部に入力する。
SLSシグナリング解析部115内のMPDイベント挿入部は、これらの通知データを、MPDに挿入し、インバンドイベント挿入部118は、これらの通知をセグメント内に挿入する。
これらのイベント情報が挿入されたMPDやセグメントは、キャッシュ部121を介して、例えば再生制御部(DASHクライアント)131,151に入力される。
上述したように、放送サーバ21等の送信装置20は、シグナリングデータ(LLS:Lower Layer Signaling)を利用して以下の通知情報を受信装置に送信する。
(a)オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)、
以下、このシグナリング(LLS)を利用した緊急情報配信通知処理構成について説明する。
LLS(ローワレイヤシグナリング)
SLS(サービスレベルシグナリング)
SLS(サービスレベルシグナリング)は、各サービス単位、例えば各番組単位の制御情報、案内情報、メタデータ等を格納したシグナリングデータである。
LLS(ローワレイヤシグナリング)は、SLSより上位の制御情報、案内情報、メタデータ等を格納したシグナリングデータであり、例えば、SLSを取得するための情報等が含まれる。
図10に示すミドルウェア110のLLSシグナリング取得部112と、LLSシグナリング解析部113が、LLS(ローワレイヤシグナリング)の取得、解析処理を実行する。
なお、前述したように送信装置20は、シグナリングデータを繰り返し、送信しており、ミドルウェア110は、新規のシグナリングデータを大きな遅延を発生させることなく取得し、解析することが可能である。
(a)オンスクリーンメッセージ型緊急情報配信通知データ(On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報配信通知データ(AEAT Message Notification)、
上記(a),(b)の緊急情報配信通知データを含むシグナリングデータ(LLS)の詳細構成例について、図12、図13を参照して説明する。
図12は、「(a)オンスクリーンメッセージ型緊急情報配信通知データ(On Screen Message Notification)」を含むシグナリングデータ(LLS)の詳細構成例である。
オンスクリーンメッセージ型緊急情報配信通知データはXMLデータとして記述される。
図12に示すデータはXMLデータを階層構成として示したXMLデータの階層構成図である。
(1)緊急情報適用放送ストリーム識別子
(2)緊急情報適用対象サービス識別子
(3)画面クリア実行対象サービス識別子範囲
(4)画面クリア実行期間
(5)画面クリア処理要否フラグ
シグナリングデータ適用型緊急情報配信通知データもXMLデータとして記述される。
図13に示すデータはXMLデータを階層構成として示したXMLデータの階層構成図である。
(1)緊急情報の識別子、発行者、優先度情報等
(2)緊急情報の有効期間、タイプ、適用地域情報等
(3)緊急情報メッセージ等
(4)メディア(Media)情報:各言語対応緊急情報メッセージ、地図等のデータ、またはデータのアクセス情報等
(a)オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)、
本開示の処理では、シグナリングデータ(LLS)によって通知される、以下の通知情報、すなわち、
(a)オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)、
これらの緊急情報配信通知をミドルウェアから、再生制御部(DASHクライアント)131,151や、アプリケーション制御部133,153にいち早く転送し、これらの通知に対応した処理を遅延なく実行させることを可能とするものである。
このために、例えばイベント通知機構を利用した処理を実行する。
従って、一旦、ストリーミング再生が開始されると、DASHクライアントはHTTP取得/再生処理を継続して行う。
このセグメント取得セッション中で、なんらかのシグナリングの更新イベント通知、もしくはシグナリングそのものの伝送を行えるようにすることが課題となる。
(a)オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)、
これらの通知情報を図10、図11に示すチューナ実装受信装置30や、チューナ非実装受信装置40の再生制御部(DASHクライアント)131,151、アプリケーション制御部133,153に遅延なく提供する構成を実現する。
次に、DASH規格において規定されているイベント通知構成について説明する。
DASH規格では、DASHイベント(DASH Event)と呼ばれるイベント通知機構が定義されている。
イベント通知機構は、例えば、放送番組や送信データの変更や詳細等の通知情報、受信装置において実行するアプリケーションに関する情報、受信装置に通知すべき情報、受信装置において必要となる処理の情報など、様々なイベント情報の通知を行うための機構である。
(a)MPD適用イベント通知方式(=MPD Event)、
(b)セグメント適用イベント通知方式(=In-band Event Signaling)
これらの2種類のイベント通知方式が規定されている。
以下、これらの2つのイベント通知方式の詳細について、順次、説明する。
MPD適用イベント通知方式(=MPD Event)は、DASH規格に規定されたシグナリングデータの1つであるMPD(Media Presentation Description)を利用してイベントを通知する方式である。
具体的には、MPD適用イベント通知方式(=MPD Event)では、
(a)様々なイベントのアクティベート(開始/実行/活性化)タイミング等のイベントスケジュール、
(b)各タイミングにおいてクライアント(受信装置)が処理すべきイベント処理、さらに、
(c)イベント実行時にクライアント上で稼働するアプリケーションに渡すべきデータ等、
これらをMPDに記述することができる。
MPDは、画像や、音声それぞれのストリームごとに、以下の規定範囲単位で属性等の情報や制御情報を記述することが可能な構成を持つ。
(1)時間軸上の区間を規定したピリオド(Period)
(2)画像、音声等のデータ種類等を規定したアダプテーション(Adaptation)
(3)画像の種類、音声の種類等を規定したリプレゼンテーション(Representation)
(4)画像、音声のセグメント(AVセグメント)単位の情報記録領域となるセグメントインフォ(SegmentInfo)
左から右に時間が経過するものとする。この時間軸は、例えば受信装置におけるAVコンテンツの再生時間に対応する。
MPDは、図14を参照して説明したように、以下の各データ単位で情報が記録できる。
(1)時間軸上の区間を規定したピリオド(Period)
(2)画像、音声等のデータ種類等を規定したアダプテーション(Adaptation)
(3)画像の種類、音声の種類等を規定したリプレゼンテーション(Representation)
(4)画像、音声のセグメント(AVセグメント)単位の情報記録領域となるセグメントインフォ(SegmentInfo)
図15は、これらのデータ領域を時間軸、およびデータ種類別に展開して示した図である。
(V)画像対応情報記録領域であるアダプテーションV(Adaptation(V))
(A)音声対応情報記録領域であるアダプテーションA(Adaptation(A))
(V1)低ビットレート画像対応の情報記録領域であるリプレゼンテーション(V1)(Representation(V1))
(V2)高ビットレート画像対応の情報記録領域であるリプレゼンテーション(V2)(Representation(V2))
(A1)日本語音声対応の情報記録領域であるリプレゼンテーション(A1)(Representation(A1))
(A2)英語音声対応の情報記録領域であるリプレゼンテーション(A2)(Representation(A2))
この選択対象とするMPDの記録情報が、図に示すセグメント領域301,302の情報となる。
例えば、受信装置(クライアント)における様々な処理要求を通知するためのイベント通知も、このMPDに記録することができる。
図16は、MPDを用いたイベント通知、すなわち、MPD適用イベント通知方式(=MPD Event)を適用した場合のMPDの記述例を示す図である。
イベント情報を含むMPDは、例えば以下の記述を有する。
<Period startTime='0'>
・・・
<EventStream schemeIdUri='urn:xxx' timescale='1000'>
<Event presentationTime='0' duration='1000'>イベントデータ1</Event>
<Event presentationTime='1000' duration='4000'>イベントデータ2</Event>
….
</EventStream>
・・・
<AdaptationSet>
<Representation/>
<Representation/>
</AdaptationSet>
・・・
</Period>
</MPD>
<MPD availabilityStartTime="2011-12-25T12:30:00
このデータ記録記録領域は、このMPDに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばUTC時刻が用いられる。
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。MPDにおいて規定されるスタート時間(MPD/@availabilityStartTime)からのオフセット時間が記録される。
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
「EventStream schemeIdUri'urn:xxx'」と、オプショナルな「EventStream/@value」によりイベントの種類等が定義される。
さらに、「timescale='1000'」は、以下に記録されるプレゼンテーションタイム(presentationTime)の単位時間は1/1000秒であることを示す。
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート(実行開始等)時間や継続時間等のイベントスケジューリングデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
さらに、イベントのアクティベート(実行開始等)時間や継続時間が記録される。
この例は、イベントデータ1によって特定されるイベントを、アクティベート(活性化/実行)時刻=0で1000単位時間継続することを指定している。
このデータ記録記録領域も、イベントデータの記録領域と、イベントのアクティベート(実行開始等)時間や継続時間等のイベントスケジューリングデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
さらに、イベントのアクティベート(実行開始等)時間や継続時間が記録される。
この例は、イベントデータ2によって特定されるイベントを、アクティベート(活性化/実行)時刻=1000で4000単位時間継続することを指定している。
<AdaptationSet>
<Representation/>
<Representation/>
これらは、各データ種類別の情報を記録するデータ記録領域である。
EventStream/@schemeIdUri(とオプショナルなEventStream/@value)属性によりイベントの種類を定義し、
EventStream/Event要素のコンテンツパートにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
なお、この、MPD適用イベント通知方式(MPD Event)は、MPDの送出前に、MPD内に記述されるピリオドの内容が確定できる場合にのみ適用可能である。
図17には、以下の各図を示している。
(1)MPD
(2)ピリオド単位情報
(3)リプレゼンテーション単位情報
(4)セグメント単位情報
前に予め受信するシグナリンクデータに含まれるMPDを取得し、自走土地において再生するデータに対応する情報をMPDから取得する。
さらに、自装置(クライアント)において再生するデータの種類に対応したリプレゼンテーション単位情報を選択し、さらに、再生対象セグメントに対応する(4)セグメント単位情報を選択する。
この(4)セグメント単位情報に記録されたデータを参照して、再生対象となるAVセグメントの取得や、AVセグメント再生に必要となる様々な情報を取得することができる。
また、図18の右側には、イベント情報を記録したMPDを入力してMPDに記録されたイベント情報に応じた処理(イベントアクティベート)を実行するイベント実行装置320を示している。
イベント挿入実行装置310は、データ出力部(DASHサーバ)311、イベント処理部(イベントサーバ)312を有する。
なお、これらのサーバ機能は、MPD等のシグナリングデータや、AVセグメントを送信する放送サーバ21、データ配信サーバ22、さらに、受信装置のミドルウェア110(図10、図11に示すミドルウェア110)が有する機能である。
以下、イベント挿入実行装置310の実行する処理について、処理ステップごとに説明する。
まず、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS11において、シグナリンクデータとしてのMPD、および再生コンテンツを構成するAVデータを含むセグメントを生成、または取得する。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、MPD、セグメントを受信データから取得する処理を行なう。
次に、イベント挿入実行装置310のイベント処理部(イベントサーバ)312は、ステップS12において、イベント情報を生成または、取得する。
イベント情報とは、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して何らかの処理の実行を通知あるいは要求するための情報である。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、イベント情報を受信データから取得する処理を行なう。
次に、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS13において、シグナリンクデータとしてのMPDに対して、イベント情報の挿入を行う。
この処理によって、先に図16を参照して説明したイベント情報記録MPDが生成される。
イベントの種類、内容や、イベントのアクティベート(活性化)時刻、継続時間情報等が記録されている。
受信装置は、このMPDに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート(例えば実行)し、指定継続時間、継続させる処理などを行うことが可能となる。
次に、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS14において、シグナリンクデータとしてのMPDにイベント情報を記録したイベント情報記録MPDを送信(出力)する。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、イベント情報記録MPDを、プロキシサーバ、あるいは再生制御部に出力する。
次に、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS15~S16において、AVコンテンツ等を格納したセグメントを送信(出力)する。
セグメント送信は、ステップS16以降、継続的に実行される。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、セグメントを、プロキシサーバ、あるいは再生制御部に出力する。
イベント実行装置320は、具体的には、MPD等のシグナリングデータや、AVセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部(図10、図11に示す再生制御部131,151)である。
なお、図18においては、再生制御部を、実行する処理の種類に応じた処理種類単位で分離した構成として示している。
具体的には、イベント対応処理実行部としての再生制御部(イベントクライアント)321と、MPDやAVセグメントを適用したコンテンツ再生処理を実行する再生制御部(DASHクライアント)322、これら2つの処理部を示している。
まず、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS21において、イベント挿入実行装置310に対してシグナリンクデータとしてのMPDの取得要求を行う。
次に、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS22において、イベント挿入実行装置310から取得したMPDからイベント情報を取得する。
イベント情報記録MPDには、イベントの種類、内容や、イベントのアクティベート(例えば実行、停止等の活性化)時刻、継続時間情報等が記録されている。
受信装置は、このMPDに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート(例えば実行)し、指定継続時間、継続させる処理などを行うことが可能となる。
次に、イベント実行装置320の再生制御部(イベントクライアント)321は、ステップS23において、MPDから取得したイベント情報に従って、イベント適用のスケジューリング処理を行なう。
前述したように、イベント情報記録MPDには、イベントの種類、内容や、イベントのアクティベート(活性化)時刻、継続時間情報等が記録されており、イベント実行装置320の再生制御部(イベントクライアント)321は、これらの情報を参照して、イベント実行のスケジューリング処理を行なう。
次に、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS24において、イベント挿入実行装置310に対してセグメントの取得要求を行う。
次に、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS25において、ステップS24で取得したセグメントからAVコンテンツ等を取得し再生処理を実行する。
次に、イベント実行装置320の再生制御部(イベントクライアント)321は、ステップS26において、MPDから取得したイベント情報に従ってスケジューリングされたイベントの適用処理、すなわちイベントアクティベート(イベント実行、開始等)処理を行なう。
ステップS27~S29の処理は、ステップS24~S26の処理と同様の処理である。
この一連の処理は、継続的に実行されることになる。
次に、DASH規格において規定されたもう1つのイベント通知方式であるセグメント適用イベント通知方式(=In-band Event Signaling)について説明する。
(a)初期化セグメント(Initialization Segment)、
(b)メディアセグメント(Media Segment)(=AVセグメント)、
これらの2種類に分けられる。
(b)メディアセグメント(Media Segment)(=AVセグメント)は、再生対象となる符号化コンテンツ(AVコンテンツ)を格納したセグメントである。
(a1)セグメントのファイルタイプ情報等からなるヘッダ情報(dash)、
(a2)メディアセグメントによって送信する符号化コンテンツであるメディアデータ(mdat)のコーデック(符号化態様)情報等の初期化情報を含むメタデータ(moov)、
(b1)セグメントのファイルタイプ情報等からなるヘッダ情報(msdh)、
(b2)メディアセグメントに格納された複数のサブセグメント(Sub-Segment)の境界情報や、メディアセグメントに格納された符号化コンテンツであるメディアデータ(mdat)のランダムアクセスポイント等を示すアクセス情報(sidx)、
(b3)複数のサブセグメント(Sub-Segment)、
フラグメント(Fragment)は、以下の各データを含む。
再生対象となる符号化コンテンツであるメディアデータ(mdat)、
メディアデータ(mdat)に対応するメタデータ(moof)、
メディアデータ(mdat)に対応する各種情報(制御情報、管理情報、属性情報など)。
mdatボックスにはAVデータが格納される。
moofボックスにはメタデータが格納される。
その他の各種情報も、それぞれの情報に応じて定義されるボックスに格納される。
図20には、イベント識別子1,2の2つのイベント情報を個別に格納した2つのイベント情報格納ボックス(emsg)のデータを示している。
box_type='emsg'
scheme_id_uri="urn:xxx"
value=0
timescale=1000
presentation_time_delta=0
event_duration = 0xFFFF
id=1
message_data[]=イベントデータ-1
box_type='emsg'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス(MP4におい規定されるデータ格納ボックス)が、イベント情報格納ボックス(emsg)であることを記述している。
value=0
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「scheme_id_uri="urn:xxx"」と、オプショナルな「value」によりイベントの種類等を定義する。
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「timescale='1000'」は、以下に記録されるプレゼンテーションタイム(presentationTime)の単位時間は1/1000秒であることを示す。
event_duration=0xFFFF
これらのデータ記録記録領域は、イベントのアクティベート(実行開始等)時間や継続時間等のイベントスケジューリングデータの記録領域である。イベント指定情報によって特定されるイベントのアクティベート(活性化/実行)時刻=0で、時刻=0xFFFFまで継続することを指定している。なお、0xFFFFは終了時間を定義していないことを示し、このイベント情報格納ボックスの設定されたセグメントに対応するAVコンテンツの再生終了まで、イベントを継続してもしなくてもよいという指定であることを意味する。
このデータ記録領域は、イベント識別情報記録領域である。
このデータ記録領域は、イベントデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
また、「message_data」フィールドにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
また、図21の右側には、イベント情報を記録したセグメントを入力してセグメントに記録されたイベント情報に応じた処理(イベントアクティベート)を実行するイベント実行装置320を示している。
イベント挿入実行装置310は、データ出力部(DASHサーバ)311、イベント処理部(イベントサーバ)312を有する。
なお、これらのサーバ機能は、MPD等のシグナリングデータや、AVセグメントを送信する放送サーバ21、データ配信サーバ22、さらに、受信装置のミドルウェア110(図10、図11に示すミドルウェア110)が有する機能である。
以下、イベント挿入実行装置310の実行する処理について、処理ステップごとに説明する。
まず、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS31において、シグナリンクデータとしてのMPD、および再生コンテンツを構成するAVデータを含むセグメントを生成、または取得する。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、MPD、セグメントを受信データから取得する処理を行なう。
次に、イベント挿入実行装置310のイベント処理部(イベントサーバ)312は、ステップS32において、イベント情報を生成または、取得する。
イベント情報とは、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して何らかの処理の実行を通知あるいは要求するための情報である。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、イベント情報を受信データから取得する処理を行なう。
次に、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS33において、セグメントに対して、イベント情報の挿入を行う。
この処理によって、先に図20を参照して説明したMP4フォーマットにおいて規定されるイベント情報記録ボックスであるemsgボックスを含むセグメントが生成される。
イベントの種類、内容や、イベントのアクティベート(活性化)時刻、継続時間情報等が記録されている。
受信装置は、このセグメント内のemsgボックスに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート(例えば実行)し、指定継続時間、継続させる処理などを行うことが可能となる。
次に、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS34において、シグナリンクデータとしてのMPDを送信(出力)する。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、MPDをプロキシサーバ、あるいは再生制御部に出力する。
次に、イベント挿入実行装置310のデータ出力部(DASHサーバ)311は、ステップS35~S36において、AVコンテンツ等を格納したセグメントを送信(出力)する。
送信するセグメントは、MP4フォーマットにおいて規定されるイベント情報記録ボックス(emsg)を含むセグメントである。
セグメント送信は、ステップS36以降、継続的に実行される。
イベント挿入実行装置310が受信装置のミドルウェア110(図10、図11に示すミドルウェア110)である場合は、セグメントを、プロキシサーバ、あるいは再生制御部に出力する。
イベント実行装置320は、具体的には、MPD等のシグナリングデータや、AVセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部(図10、図11に示す再生制御部131,151)である。
なお、図21においては、再生制御部を、実行する処理の種類に応じて分離して示している。すなわち、イベント対応処理実行部としての再生制御部(イベントクライアント)321と、MPDやAVセグメントを適用したコンテンツ再生処理を実行する再生制御部(DASHクライアント)322の2つの処理部に区分して示している。
まず、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS41において、イベント挿入実行装置310に対してシグナリンクデータとしてのMPDの取得要求を行う。
次に、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS44において、イベント挿入実行装置310に対してセグメントの取得要求を行う。
次に、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS42において、イベント挿入実行装置310から取得したセグメントからイベント情報を取得する。
受信装置は、このセグメントに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート(例えば実行)し、指定継続時間、継続させる処理などを行うことが可能となる。
次に、イベント実行装置320の再生制御部(イベントクライアント)321は、ステップS44において、セグメントから取得したイベント情報に従ってスケジューリングされたイベントの適用処理、すなわちイベントアクティベート(イベント実行、開始等)処理を行なう。
次に、イベント実行装置320の再生制御部(DASHクライアント)322は、ステップS45において、ステップS42で取得したセグメントからAVコンテンツ等を取得し再生処理を実行する。
ステップS46~S49の処理は、ステップS42~S45の処理と同様の処理である。
この一連の処理は、セグメント単位の処理として継続的に実行されることになる。
次に、上述したイベント通知機構を利用して緊急情報自体、または緊急情報が配信されたことを通知する構成について説明する。
(a)オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)、
従って、これら再生制御部(DASHクライアント)131,151や、アプリケーション制御部133,153が、上記(a),(b)の緊急情報配信通知がなされたことを把握しない限り、アプリケーション提示コンテンツの削除処理や、緊急情報の表示処理を実行することができない。
(a)オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)、
(b)シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)、
これらの緊急情報配信通知をミドルウェアから、再生制御部(DASHクライアント)131,151や、アプリケーション制御部133,153にいち早く転送し、これらの通知に対応した処理を遅延なく実行させることを可能とするものであり、このための処理として、イベント通知機構を利用する。
(a)オンスクリーンメッセージイベント(OnScreenMessage Event)
(b)シグナリングデータ適用型緊急情報配信イベント(AEATDelivered Event)
これら2つのイベントのイベント識別子(schemeIdUri=urn:uniform resource name)は、以下の識別子とする。
(a)オンスクリーンメッセージイベント(OnScreenMessage Event)の識別子は、以下の識別子とする。
schemeIdUri="urn:atsc:onScreenMessage"
例えばアプリケーション制御部133,153に、このイベント情報を通知して、緊急情報メッセージ上のアプリ提示コンテンツの排除を実行させる。
schemeIdUri="urn:atsc:AEATDelivered"
再生制御部131,151、あるいはアプリケーション制御部133,153、緊急情報制御部140,260等に、このイベント情報を通知し、配信されたシグナリングデータから緊急情報(AEAT)を取得、または、シグナリングデータに記録されたアクセス情報を用いて緊急情報を取得し、取得した緊急情報を表示する処理を実行させる。
シグナリングデータ(LLS)によって配信された緊急情報(AEAT)メッセージそのものを格納、または
緊急情報(AEAT)メッセージファイルのアクセス情報(url)を記録、
これらいずれかの構成とする。
いずれの場合も、イベント情報に基づいて、緊急情報(AEAT)メッセージが取得可能である。
なお、緊急情報(AEAT)メッセージファイルには、先に図9を参照して説明した地図情報等も含まれる。
まず、オンスクリーンメッセージ型緊急情報配信通知をイベント情報として通知する構成について説明する。
(a)イベント情報をシグナリングデータであるMPD(Media Presentation Description)内に挿入して転送するMPD適用イベント通知方式、
(b)イベント情報をセグメント内に挿入して転送するセグメント適用(In-band)イベント通知方式、
これらの2種類がある。
なお、上記(a),(b)いずれの場合も、イベント情報は、例えば、図10、図11に示すチューナ実装受信装置30のミドルウェア110から、チューナ実装受信装置30と、チューナ非実装受信装置40の再生制御部(DASHクライアント)131,151に転送されることになる。
まず、MPD適用イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について説明する。
すなわち、このイベントのアクティベート(活性化)時刻を記述することはできない。
具体的には、MPD適用イベント通知方式(=MPD Event)では、
(a)様々なイベントのアクティベート(開始/実行/活性化)タイミング等のイベントスケジュール、
(b)各タイミングにおいてクライアント(受信装置)が処理すべきイベント処理、さらに、
(c)イベント実行時にクライアント上で稼働するアプリケーションに渡すべきデータ等、
これらをMPDに記述することができる。
従って、オンスクリーンメッセージイベント(OnScreenMessage Event)のイベント情報を挿入した「緊急情報イベント挿入MPD」を遅滞なく再生制御部(DASHクライアント)131,151等に取得させるためには、「緊急情報イベント挿入MPD」の取得が必要であることを、再生制御部(DASHクライアント)131,151等に、事前に知らせることが必要となる。
(S01)ミドルウェア110のLLSシグナリング解析部113が、シグナリングデータ(LLS)から、オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)を検出し、検出情報をSLSシグナリング解析部(MPDイベント挿入部)115に通知、
さらに、再生制御部(DASHクライアント)131,151が利用中のMPDが変更、または更新されたことを、既存のDASHイベント通知機構を利用して再生制御部(DASHクライアント)131,151に通知する。
再生制御部(DASHクライアント)131,151は、更新されたMPDを参照することで、緊急情報メッセージが番組コンテンツ等のビデオストリーム上に(ビデオとして)重畳されたことを知ることが可能となる。
DASHスペックでは以下の2種類のイベントがDASH既定のイベントとして定義されている。
1つは、MPD有効期限経過(MPD Validity Expiration)通知イベントであり、
もう1つは、MPDパッチ(MPD Patch)通知イベントである。
これらのイベント(DASHイベント)は、いずれもMPDの更新通知に利用するイベントである。どちらもそのイベントのタイプ(識別子)は、
schemeIdUri="urn:mpeg:dash:event:2012"である。
ただし、これら2つのイベントには異なる属性(value属性)が設定され、この属性によって2つイベントを区別することが可能となる。
schemeIdUri="urn:mpeg:dash:event:2012"
value="1"
一方、MPDパッチ(MPD Patch)通知イベントのタイプ(識別子)と属性(value属性)は以下の通りである。
schemeIdUri="urn:mpeg:dash:event:2012"
value="2"
通常MPD更新時間はMPDの属性であるMPD@minimumUpdatePeriodによりMPD内に記載して通知される。
クライアントとしての再生制御部(DASHクライアント)は、このminimumUpdatePeriodに記載さる時刻までは取得したMPDが有効であると判断する。
セグメント適用(in-band)イベント通知方式は、セグメントのストリーム中にイベント通知情報を格納して通知する方式である。
すなわち、セグメント中にMPDの更新が必要となったことを示すイベント通知を挿入して、再生制御部(DASHクライアント)に転送する。
再生制御部(DASHクライアント)は、入力セグメントについては、全て確認しており、このセグメント確認過程で、MPD更新が必要となったことを知ることができる。
in-band Eventのemsg boxの、
message_data[]
に更新が必要となる時刻情報を格納する。
なお、緊急のMPD更新が必要となる場合は、"更新が必要となる時刻"を"今すぐ"に設定する。
in-band Eventのemsg boxの
message_data[]
に格納する。
再生制御部(DASHクライアント)は、セグメントから、このイベントを検出すると、取得済みのMPDに、このコマンドを適用して内容そのものを更新する。
このように、上述したステップ(S01)~(S03)の処理によって、再生制御部(DASHクライアント)131,151は、オンスクリーンメッセージイベント(OnScreenMessage Event)を記録した更新されたMPDを取得することができる。
MPDは、例えば以下の記述を有する。
<Period startTime='0'>
・・・
<EventStream schemeIdUri='urn:atsc:onScreenMessage' timescale='1000'>
<Event presentationTime='(イベントの開始(アクティベート)される対象期間(Period)のピリオド開始時刻からの差分(経過時間))
(緊急情報(オンスクリーンメッセージ(OnScreenMessage))データ、または緊急情報データアクセス用URL)
</Event>
・・・.
</EventStream>
・・・
<AdaptationSet>
・・・
</Period>
</MPD>
<MPD availabilityStartTime="2011-12-25T12:30:00
このデータ記録記録領域は、このMPDに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばUTC時刻が用いられる。
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。MPDにおいて規定されるスタート時間(MPD/@availabilityStartTime)からのオフセット時間が記録される。
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
「EventStream schemeIdUri='urn:atsc:onScreenMessage'」により、このイベントが、オンスクリーンメッセージイベント(OnScreenMessage Event)であることが確認できる。
さらに、「timescale='1000'」は、以下に記録されるプレゼンテーションタイム(presentationTime)の単位時間は1/1000秒であることを示す。
(緊急情報(オンスクリーンメッセージ(OnScreenMessage))データ、または緊急情報データアクセス用URL)
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート(実行開始等)時間や継続時間等のイベントスケジューリングデータの記録領域である。
オンスクリーンメッセージイベントの場合、放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間が記録可能である。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
<AdaptationSet>
<Representation/>
<Representation/>
これらは、各データ種類別の情報を記録するデータ記録領域であり、オンスクリーンメッセージイベントの場合、緊急情報が重畳表示される放送ストリームの識別情報等が記録される。
再生制御部(DASHクライアント)131,151は、このイベント情報に従って、オンスクリーンメッセージイベント(OnScreenMessage Event)を格納した更新MPD、すなわち図22を参照して説明した構成を持つオンスクリーンメッセージイベント(OnScreenMessage Event)を記録したMPDを取得する。
アプリケーション制御部133,153は、アプリケーション提示コンテンツを表示部に表示している場合、そのアプリケーション提示コンテンツの表示を停止させる処理を行なう。
具体的には、例えば、先に図7を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ(視聴者)に確実に確認させることが可能となる。
次に、セグメント適用(In-band)イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について説明する。
セグメント適用イベント通知方式(=In-band Event Signaling)において利用されるMP4フォーマットデータ内のイベント情報格納ボックス(emsg)の一般的なデータ構成例については、先に図20を参照して説明した通りである。
box_type='emsg'
scheme_id_uri="urn:atsc:onScreenMessage"
value=0
timescale=1000
presentation_time_delta=0
event_duration = 0xFFFF
id=1
message_data[]=(緊急情報(オンスクリーンメッセージ(OnScreenMessage))データ、または緊急情報データアクセス用URL)
box_type='emsg'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス(MP4におい規定されるデータ格納ボックス)が、イベント情報格納ボックス(emsg)であることを記述している。
value=0
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「scheme_id_uri="urn:atsc:onScreenMessage'」により、このイベントが、オンスクリーンメッセージイベント(OnScreenMessage Event)であることが確認できる。
さらに、オプショナルな「value」によりイベントの種類等を定義可能となる。
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「timescale='1000'」は、以下に記録されるプレゼンテーションタイム(presentationTime)の単位時間は1/1000秒であることを示す。
event_duration=0xFFFF
これらのデータ記録記録領域は、イベントのアクティベート(実行開始等)時間や継続時間等のイベントスケジューリングデータの記録領域である。
オンスクリーンメッセージイベントの場合、放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間が記録される。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録可能である。
このデータ記録領域は、イベント識別情報記録領域である。
このデータ記録領域は、イベントデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
また、「message_data」フィールドにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
アプリケーション制御部133,153は、アプリケーション提示コンテンツを表示部に表示している場合、そのアプリケーション提示コンテンツの表示を停止させる処理を行なう。
具体的には、例えば、先に図7を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ(視聴者)に確実に確認させることが可能となる。
上述したように、新たに定義したイベントである、
オンスクリーンメッセージイベント(OnScreenMessage Event)
は、シグナリングデータ(LLS)によって、「オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)」が配信されたことを、ミドルウェアから、再生制御部(DASHクライアント)に通知することを可能とした。
(a)MPD適用イベント通知方式(=MPD Event)、
(b)セグメント適用イベント通知方式(=In-band Event Signaling)
以下、これらの2種類のイベント通知方式を利用したオンスクリーンメッセージイベント(OnScreenMessage Event)の生成、転送、およびイベントに基づく処理の実行シーケンスについて、順次、説明する。
(1)AVセグメントや、緊急情報、MPD、シグナリングデータ等の生成と出力を実行する送信装置410、
(2)AVセグメントや、緊急情報、MPD、シグナリングデータ等を受信し、緊急情報の通知状況等を記録したイベント情報をMPD、またはセグメント内に記録したイベント挿入MPD、またはイベント挿入セグメントを生成するチューナ実装受信装置ミドルウェア420、
(3)チューナ実装受信装置ミドルウェア420から、AVセグメントや、イベント挿入MPD、またはイベント挿入セグメント等を受領してAVセグメントの再生処理や、イベント情報に応じた処理を実行するチューナ実装/非実装受信装置出力データ制御部430、
また、チューナ実装/非実装受信装置出力データ制御部430は、図10、図11に示すチューナ実装受信装置30と、チューナ非実装受信装置40の再生制御部(DASHクライアント)131,151、出力制御部132,152、アプリケーション制御部133,153、緊急情報制御部140,160に相当する。
再生コンテンツのストリーム等の生成を行うストリームサーバ411、
MPDやセグメントの生成を行うDASHサーバ412、
緊急情報の生成を行う緊急情報サーバ413、
MPD、セグメント、緊急情報の送信を実行する放送信号生成部(放送サーバ)414、
これらの4つの構成を分割してしている。
これらは、送信装置の実行する様々な処理を理解しやすくするために処理単位で区別して記載しているが、例えば、図1に示す放送サーバ21、データ配信サーバ22が有する機能であり、1つの送信装置(送信サーバ)において実行する構成としてもよい。
(ステップS201)
まず、送信装置410の緊急情報サーバ413は、放送コンテンツを構成する画像に重畳して表示するための緊急情報を生成し、ストリームサーバ411の生成する画像に重畳する。
例えば、先に図5等を参照して説明したように、放送コンテンツの画像上に重畳して配信する緊急情報、すなわちオンスクリーンメッセージ型緊急情報を生成して、ストリームサーバ411の生成する画像に重畳する。
次に、送信装置410の緊急情報サーバ413は、放送信号生成部(放送サーバ)414を介して、オンスクリーンメッセージ型緊急情報を放送コンテンツの画像上に重畳したことを示す通知を受信装置に出力する。
このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
次に、送信装置410のストリームサーバ411は、ステップS203において、緊急情報サーバ413の生成した緊急情報を画像上に重畳したストリームを生成してDASHサーバに出力する。
次に、送信装置410のDASHサーバ412は、ステップS204において、シグナリンクデータとしてのMPDやセグメントを生成し、ステップS205において、放送信号生成部(放送サーバ)414を介して送信する。
MPDには、放送コンテンツの再生処理に適用するための様々な制御情報、案内情報等が含まれる。
先に図14他を参照して説明したように、MPDは、画像や、音声それぞれのストリームごとに、所定のデータ範囲単位の属性情報や制御情報を記述することが可能な構成を持つ。
一方、送信装置410が、インターネット等のネットワークを介したデータ送信を実行するデータ配信サーバである場合は、MPDやセグメントを、ネットワークを介して送信する。
チューナ実装受信装置ミドルウェア420は、図10、図11に示すチューナ実装受信装置30のミドルウェア110と同様の構成を持つ。
チューナ実装受信装置ミドルウェア420は、送信装置410の送信するAVセグメントや、緊急情報、MPD、シグナリングデータ等を受信し、緊急情報の通知状況等を記録したイベント情報をMPD、またはセグメント内に記録したイベント挿入MPD、またはイベント挿入セグメントを生成する、
さらに、生成したイベント挿入MPD、またはイベント挿入セグメントをチューナ実装/非実装受信装置出力データ制御部430に転送する。
チューナ実装受信装置ミドルウェア420の実行する各ステップの処理について説明する。
チューナ実装受信装置ミドルウェア420は、送信装置410から、オンスクリーンメッセージ型緊急情報が放送コンテンツの画像上に重畳されたことを示す通知を受信すると、ステップS211において、オンスクリーンメッセージイベントの生成処理を実行する。
シグナリングデータ(LLS)には、オンスクリーンメッセージ(OnScreenMessage)型の緊急情報の配信がなされること(オンスクリーンメッセージ通知:On Screen Message Notification)が記録されている。
本例において、送信装置410の送信する緊急情報は、放送コンテンツの構成画像に直接重畳されたオンスクリーン型の緊急情報であり、チューナ実装受信装置ミドルウェア420は、オンスクリーンメッセージイベント(OnScreenMessage Event)を生成する。
次に、チューナ実装受信装置ミドルウェア420は、ステップS212において、MPD、またはセグメントの少なくともいずれかに、ステップS211で生成したイベント情報、すなわち、オンスクリーンメッセージイベント(OnScreenMessage Event)情報を記録する。
(a)イベント情報をシグナリングデータであるMPD(Media Presentation Description)内に挿入して転送するMPD適用イベント通知方式、
(b)イベント情報をセグメント内に挿入して転送するセグメント適用(In-band)イベント通知方式、
これらの2種類がある。
この処理によって、先に図22を参照して説明したオンスクリーンメッセージイベント(OnScreenMessage Event)情報を記録したMPDが生成される。
なお、この処理は、図10に示すミドルウェア110のSLSシグナリング生成部(MPDイベント挿入部)115において実行される。
この処理によって、先に図23を参照して説明したオンスクリーンメッセージイベント(OnScreenMessage Event)情報を記録したセグメントが生成される。
なお、この処理は、図10に示すミドルウェア110のインバンドイベント挿入部118において実行される。
(1)緊急情報(オンスクリーンメッセージ(OnScreenMessage))データ、または緊急情報データアクセス用URL、
(2)放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間、
これらのデータが記録される。
次に、チューナ実装受信装置ミドルウェア420は、ステップS213において、MPDやセグメントをチューナ実装/非実装受信装置出力データ制御部430に転送する。
なお、この処理は、具体的には、プロキシサーバ121を介して実行される。
チューナ実装/非実装受信装置出力データ制御部430の再生制御部(DASHクライアント)、すなわち、図10、図11に示す再生制御部(DASHクライアント)131,151が、プロキシサーバ120のキャッシュ部(プロキシキャッシュ)121をアクセスしてMPDやセグメントを取得する。
すなわち、再生制御部(DASHクライアント)131,151にMPD更新がなされたことを通知する。
再生制御部(DASHクライアント)131,151は、この通知に応じて、オンスクリーンメッセージイベント(OnScreenMessage Event)を挿入したMPDを遅延なく取得することができる。
図24には、チューナ実装/非実装受信装置出力データ制御部430のアプリケーション制御部431、再生制御部432を示している。これらの構成は、図10、図11に示すチューナ実装受信装置30とチューナ非実装受信装置40のアプリケーション制御部133,153、再生制御部131,151の各構成に対応する。
まず、チューナ実装/非実装受信装置出力データ制御部430の再生制御部(DASHクライアント)432は、チューナ実装受信装置ミドルウェア420を介して受信したMPD、またはセグメントから、オンスクリーンメッセージイベント(OnScreenMessage Event)を抽出し、アプリケーション制御部431に転送する。
先に図23を参照して説明したオンスクリーンメッセージイベント(OnScreenMessage Event)情報を記録したセグメントから、
オンスクリーンメッセージイベント(OnScreenMessage Event)を抽出する。
(1)緊急情報(オンスクリーンメッセージ(OnScreenMessage))データ、または緊急情報データアクセス用URL、
(2)放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間、
これらのデータが記録されている。
次に、チューナ実装/非実装受信装置出力データ制御部430のアプリケーション制御部431は、ステップS222において、再生制御部(DASHクライアント)432から受領したイベント情報に応じた処理を実行する。
具体的には、例えば、先に図7を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ(視聴者)に確実に確認させることが可能となる。
次に、チューナ実装/非実装受信装置出力データ制御部430の再生制御部(DASHクライアント)432は、チューナ実装受信装置ミドルウェア420を介して受信したセグメントからAVコンテンツ等を取得し再生処理を実行する。
次に、シグナリングデータ適用型緊急情報配信通知をイベント情報として通知する構成について説明する。
(a)イベント情報をシグナリングデータであるMPD(Media Presentation Description)内に挿入して転送するMPD適用イベント通知方式、
(b)イベント情報をセグメント内に挿入して転送するセグメント適用(In-band)イベント通知方式、
これらの2種類がある。
なお、上記(a),(b)いずれの場合も、イベント情報は、例えば、図10、図11に示すチューナ実装受信装置30のミドルウェア110から、チューナ実装受信装置30と、チューナ非実装受信装置40の再生制御部(DASHクライアント)131,151に転送されることになる。
まず、MPD適用イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について説明する。
従って、このイベントのアクティベート(活性化)時刻を記述することはできない。
(S01)ミドルウェア110のLLSシグナリング解析部113が、シグナリングデータ(LLS)から、シグナリングデータ適用型緊急情報配信通知(On Screen Message Notification)を検出し、検出情報をSLSシグナリング解析部(MPDイベント挿入部)115に通知、
さらに、再生制御部(DASHクライアント)131,151が利用中のMPDが変更、または更新されたことを、既存のDASHイベント通知機構を利用して再生制御部(DASHクライアント)131,151に通知する。
再生制御部(DASHクライアント)131,151は、更新されたMPDを参照することで、緊急情報メッセージがシグナリングデータ(例えばLLS)として配信された、または配信されることを知ることが可能となる。
1つは、MPD有効期限経過(MPD Validity Expiration)通知イベントであり、
もう1つは、MPDパッチ(MPD Patch)通知イベントである。
MPDは、例えば以下の記述を有する。
<Period startTime='0'>
・・・
<EventStream schemeIdUri='urn:atsc:AEATDelivered' timescale='1000'>
<Event presentationTime='(イベントの開始(アクティベート)される対象期間(Period)のピリオド開始時刻からの差分(経過時間))
(シグナリングデータ適用型緊急情報(AEAT)データ、または緊急情報(AEAT)データアクセス用URL)
</Event>
・・・.
</EventStream>
・・・
<AdaptationSet>
・・・
</Period>
</MPD>
<MPD availabilityStartTime="2011-12-25T12:30:00
このデータ記録記録領域は、このMPDに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばUTC時刻が用いられる。
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。MPDにおいて規定されるスタート時間(MPD/@availabilityStartTime)からのオフセット時間が記録される。
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
「EventStream schemeIdUri='urn:atsc:AEATDelivered'」により、このイベントが、シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)であることが確認できる。
さらに、「timescale='1000'」は、以下に記録されるプレゼンテーションタイム(presentationTime)の単位時間は1/1000秒であることを示す。
(シグナリングデータ適用型緊急情報(AEAT)データ、または緊急情報(AEAT)データアクセス用URL)
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート(実行開始等)時間や継続時間等のイベントスケジューリングデータの記録領域である。
シグナリングデータ適用型緊急情報(AEAT)配信イベントの場合、緊急情報(AEAT)が配信される開始時間、継続時間が記録可能である。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
<AdaptationSet>
<Representation/>
<Representation/>
これらは、各データ種類別の情報を記録するデータ記録領域であり、シグナリングデータ適用型緊急情報(AEAT)配信イベントの場合、緊急情報が重畳表示される放送ストリームの識別情報等が記録される。
再生制御部(DASHクライアント)131,151は、このイベント情報に従って、シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)を格納した更新MPD、すなわち図25を参照して説明した構成を持つシグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)を記録したMPDを取得する。
イベントに緊急情報(AEAT)データが含まれていない場合は、更新MPDに記録された緊急情報(AEAT)のアクセス情報に従って、緊急情報(AEAT)をプロキシサーバ120のキャッシュ部121から取得し、アプリケーション制御部133,153、または、緊急情報制御部140,160に転送する。
具体的には、例えば、先に図8、図9を参照して説明した緊急情報の表示処理を実行する。
この処理により、シグナリングデータとして配信される緊急情報をユーザ(視聴者)に確実に確認させることが可能となる。
次に、セグメント適用(In-band)イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について説明する。
セグメント適用イベント通知方式(=In-band Event Signaling)において利用されるMP4フォーマットデータ内のイベント情報格納ボックス(emsg)の一般的なデータ構成例については、先に図20を参照して説明した通りである。
box_type='emsg'
scheme_id_uri="urn:atsc:AEATDelivered"
value=0
timescale=1000
presentation_time_delta=0
event_duration = 0xFFFF
id=1
message_data[]=(緊急情報(AEAT)データ、または緊急情報(AEAT)データアクセス用URL)
box_type='emsg'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス(MP4におい規定されるデータ格納ボックス)が、イベント情報格納ボックス(emsg)であることを記述している。
value=0
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「scheme_id_uri="urn:atsc:AEATDelivered'」により、このイベントが、シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)であることが確認できる。
さらに、オプショナルな「value」によりイベントの種類等を定義可能となる。
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「timescale='1000'」は、以下に記録されるプレゼンテーションタイム(presentationTime)の単位時間は1/1000秒であることを示す。
event_duration=0xFFFF
これらのデータ記録記録領域は、イベントのアクティベート(実行開始等)時間や継続時間等のイベントスケジューリングデータの記録領域である。
シグナリングデータ適用型緊急情報(AEAT)配信イベントの場合、緊急情報(AEAT)が配信される開始時間、継続時間が記録可能である。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録可能である。
このデータ記録領域は、イベント識別情報記録領域である。
このデータ記録領域は、イベントデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
また、「message_data」フィールドにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
イベントに緊急情報(AEAT)データが含まれていない場合は、セグメントに記録された緊急情報(AEAT)のアクセス情報に従って、緊急情報(AEAT)をプロキシサーバ120のキャッシュ部121から取得し、アプリケーション制御部133,153、または、緊急情報制御部140,160に転送する。
具体的には、例えば、先に図8、図9を参照して説明した緊急情報の表示処理を実行する。
この処理により、シグナリングデータとして配信される緊急情報をユーザ(視聴者)に確実に確認させることが可能となる。
上述したように、新たに定義したイベントである、
シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)
は、シグナリングデータ(LLS)によって、「シグナリングデータ適用型緊急情報配信通知(AEATメッセージ通知:AEAT Message Notification)」が配信されたことを、ミドルウェアから、再生制御部(DASHクライアント)に通知することを可能とした。
(a)MPD適用イベント通知方式(=MPD Event)、
(b)セグメント適用イベント通知方式(=In-band Event Signaling)
以下、これらの2種類のイベント通知方式を利用したシグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)の生成、転送、およびイベントに基づく処理の実行シーケンスについて、順次、説明する。
(1)AVセグメントや、緊急情報、MPD、シグナリングデータ等の生成と出力を実行する送信装置410、
(2)AVセグメントや、緊急情報、MPD、シグナリングデータ等を受信し、緊急情報の通知状況等を記録したイベント情報をMPD、またはセグメント内に記録したイベント挿入MPD、またはイベント挿入セグメントを生成するチューナ実装受信装置ミドルウェア420、
(3)チューナ実装受信装置ミドルウェア420から、AVセグメントや、イベント挿入MPD、またはイベント挿入セグメント等を受領してAVセグメントの再生処理や、イベント情報に応じた処理を実行するチューナ実装/非実装受信装置出力データ制御部430、
また、チューナ実装/非実装受信装置出力データ制御部430は、図10、図11に示すチューナ実装受信装置30と、チューナ非実装受信装置40の再生制御部(DASHクライアント)131,151、出力制御部132,152、アプリケーション制御部133,153、緊急情報制御部140,160に相当する。
再生コンテンツのストリーム等の生成を行うストリームサーバ411、
MPDやセグメントの生成を行うDASHサーバ412、
緊急情報の生成を行う緊急情報サーバ413、
MPD、セグメント、緊急情報の送信を実行する放送信号生成部(放送サーバ)414、
これらの4つの構成を分割してしている。
これらは、送信装置の実行する様々な処理を理解しやすくするために処理単位で区別して記載しているが、例えば、図1に示す放送サーバ21、データ配信サーバ22が有する機能であり、1つの送信装置(送信サーバ)において実行する構成としてもよい。
(ステップS401)
次に、送信装置410のストリームサーバ411は、ステップS401において、放送コンテンツ構成データとしての画像や音声等からなるストリームを生成してDASHサーバに出力する。
次に、送信装置410のDASHサーバ412は、ステップS402において、シグナリンクデータとしてのMPDやセグメントを生成し、ステップS403において、放送信号生成部(放送サーバ)414を介して送信する。
MPDには、放送コンテンツの再生処理に適用するための様々な制御情報、案内情報等が含まれる。
先に図14他を参照して説明したように、MPDは、画像や、音声それぞれのストリームごとに、所定のデータ範囲単位の属性情報や制御情報を記述することが可能な構成を持つ。
一方、送信装置410が、インターネット等のネットワークを介したデータ送信を実行するデータ配信サーバである場合は、MPDやセグメントを、ネットワークを介して送信する。
まず、送信装置410の緊急情報サーバ413は、ステップS404において、シグナリングデータとして送信する緊急情報(AEAT)を生成し、ステップS405において、放送信号生成部(放送サーバ)414を介して送信する。
AEATには、例えば緊急情報としての緊急情報メッセージや、避難経路を示す地図情報などの表示用データ、あるいは表示用データのアクセス情報等が含まれる。
なお、このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
チューナ実装受信装置ミドルウェア420は、図10、図11に示すチューナ実装受信装置30のミドルウェア110と同様の構成を持つ。
チューナ実装受信装置ミドルウェア420は、送信装置410の送信するAVセグメントや、緊急情報、MPD、シグナリングデータ等を受信し、緊急情報(AEAT)自体、あるいは緊急情報(AEAT)のアクセス情報を格納したイベント情報をMPD、またはセグメント内に記録したイベント挿入MPD、またはイベント挿入セグメントを生成する、
さらに、生成したイベント挿入MPD、またはイベント挿入セグメントをチューナ実装/非実装受信装置出力データ制御部430に転送する。
チューナ実装受信装置ミドルウェア420の実行する各ステップの処理について説明する。
チューナ実装受信装置ミドルウェア420は、送信装置410から、シグナリングデータ適用型緊急情報(AEAT)を受信すると、ステップS411において、シグナリングデータ適用型緊急情報(AEAT)配信イベントの生成処理を実行する。
本例において、送信装置410の送信する緊急情報は、シグナリングデータ適用型緊急情報(AEAT)であり、チューナ実装受信装置ミドルウェア420は、シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)を生成する。
次に、チューナ実装受信装置ミドルウェア420は、ステップS412において、MPD、またはセグメントの少なくともいずれかに、ステップS411で生成したイベント情報、すなわち、シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)情報を記録する。
(a)イベント情報をシグナリングデータであるMPD(Media Presentation Description)内に挿入して転送するMPD適用イベント通知方式、
(b)イベント情報をセグメント内に挿入して転送するセグメント適用(In-band)イベント通知方式、
これらの2種類がある。
この処理によって、先に図25を参照して説明したシグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)情報を記録したMPDが生成される。
なお、この処理は、図10に示すミドルウェア110のSLSシグナリング生成部(MPDイベント挿入部)115において実行される。
この処理によって、先に図26を参照して説明したシグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)情報を記録したセグメントが生成される。
なお、この処理は、図10に示すミドルウェア110のインバンドイベント挿入部118において実行される。
(1)緊急情報(AEAT)データ、または緊急情報(AEAT)データアクセス用URL、
(2)緊急情報の配信開始時間、配信継続時間、
これらのデータが記録される。
次に、チューナ実装受信装置ミドルウェア420は、ステップS413において、MPDやセグメントをチューナ実装/非実装受信装置出力データ制御部430に転送する。
なお、この処理は、具体的には、プロキシサーバ121を介して実行される。
チューナ実装/非実装受信装置出力データ制御部430の再生制御部(DASHクライアント)、すなわち、図10、図11に示す再生制御部(DASHクライアント)131,151が、プロキシサーバ120のキャッシュ部(プロキシキャッシュ)121をアクセスしてMPDやセグメントを取得する。
すなわち、再生制御部(DASHクライアント)131,151にMPD更新がなされたことを通知する。
再生制御部(DASHクライアント)131,151は、この通知に応じて、シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)を挿入したMPDを遅延なく取得することができる。
ステップS414の処理は、チューナ実装受信装置ミドルウェア420が、ステップS413で、チューナ実装/非実装受信装置出力データ制御部430に転送したMPDやセグメントに、緊急情報(AEAT)のアクセス情報が記録され、緊急情報(AEAT)データが含まれていない場合や、新たな出力(表示)用データが必要となるに実行される処理である。
図27には、チューナ実装/非実装受信装置出力データ制御部430の緊急情報制御部433、再生制御部432を示している。これらの構成は、図10、図11に示すチューナ実装受信装置30とチューナ非実装受信装置40の緊急情報制御部140,160と、再生制御部131,151の各構成に対応する。
すなわち、図27に示す緊急情報制御部433をアプリケーション制御部に置き換えることも可能である。
まず、チューナ実装/非実装受信装置出力データ制御部430の再生制御部(DASHクライアント)432は、チューナ実装受信装置ミドルウェア420を介して受信したMPD、またはセグメントから、シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)を抽出し、緊急情報制御部433に転送する。
先に図23を参照して説明したシグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)情報を記録したセグメントから、
シグナリングデータ適用型緊急情報(AEAT)配信イベント(AEATDelivered Event)を抽出する。
(1)緊急情報(AEAT)データ、または緊急情報(AEAT)データアクセス用URL、
(2)緊急情報(AEAT)の配信開始時間、継続時間、
これらのデータが記録されている。
次に、チューナ実装/非実装受信装置出力データ制御部430の緊急情報制御部433は、ステップS422において、再生制御部(DASHクライアント)432から受領したイベント情報を取得し、ステップS423において、緊急情報(AEAT)データを表示部に出力する処理を実行する。
次に、チューナ実装/非実装受信装置出力データ制御部430の再生制御部(DASHクライアント)432は、チューナ実装受信装置ミドルウェア420を介して受信したセグメントからAVコンテンツ等を取得し再生処理を実行する。
次に、図10、図11を参照して説明したチューナ実装受信装置30とチューナ非実装受信装置40の構成を変更し、緊急情報関連イベント情報の送受信を実行する緊急情報関連イベント情報専用のサーバとクライアントを利用した構成例について説明する。
(a)チューナ実装受信装置30のミドルウェア110
(a1)緊急情報関連イベントの転送処理を実行するイベント処理サーバ501を追加、
(a2)図10に示すインバンドイベント挿入部118の削除、
(a3)図10に示すSLSシグナリング解析部115のMPDイベント挿入機能の削除
(b)チューナ実装受信装置30とチューナ非実装受信装置40の再生制御部(DASHクライアント)131,151
(b1)再生制御部(DASHクライアント)131,151と並列にイベント処理クライアント511,521を追加、
(b2)図11に示す再生制御部(DASHクライアント)131,151内のイベント抽出部205,255の削除、
図28に示す構成のその他の構成は、先に説明した図10、図11と同一である。
具体的には、例えば、先に図12、図13を参照して説明した通知データを含むシグナリングデータ(LLS)である。
先に説明したように、図12に示すデータは、
(a)オンスクリーンメッセージ型緊急情報配信通知データ(On Screen Message Notification)」を構成要素とするシグナリングデータ(LLS)である。
また、図13に示すデータは、
(b)シグナリングデータ適用型緊急情報配信通知データ(AEAT Message Notification)を構成要素とするシグナリングデータ(LLS)である。
(a)オンスクリーンメッセージ型緊急情報配信通知データ(On Screen Message Notification)」を構成要素とするシグナリングデータ(LLS)
(b)シグナリングデータ適用型緊急情報配信通知データ(AEAT Message Notification)を構成要素とするシグナリングデータ(LLS)
これら(a),(b)いずれかのデータを含むイベント情報である。
イベント処理サーバ501は、は、このイベント情報中継セッションを介して、緊急情報に関する通知を含むシグナリングデータ(LLS)に基づくイベント情報をイベント処理クライアント511,521に転送する。
具体的には、受信したイベント情報が、
(a)オンスクリーンメッセージ型緊急情報配信通知(On Screen Message Notification)、
を含むイベント情報である場合には、アプリケーション制御部133,153に、このイベント情報を通知して、アプリケーション制御部133,153において実行中のアプリにより、アプリコンテンツの提示がなされている場合、その提示コンテンツの提示処理を中止させる処理を行なう。
(b)シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)、
を含むイベント情報である場合には、緊急情報制御部140,160、あるいは、アプリケーション制御部133,153に、このイベント情報を通知して、緊急情報制御部140,160、あるいは、アプリケーション制御部133,153において、緊急情報(AEAT)の取得と緊急情報(AEAT)に含まれるメッセージ等の表示処理を実行させる処理を行なう。
次に、図28に示すイベント処理サーバ501と、イベント処理クライアント511,521を有する構成を用いた具体的な処理シーケンスについて、説明する。
まず、図29に示すシーケンス図を参照して、オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて説明する。
(1)送信装置410、
(2)チューナ実装受信装置ミドルウェア420、
(3)チューナ実装/非実装受信装置出力データ制御部430、
図28を参照して説明する緊急情報に対する処理に並行して、AVセグメント、MPDの生成、送信、利用(再生)処理が実行される。
(ステップS501)
まず、送信装置410の緊急情報サーバ413は、放送コンテンツを構成する画像に重畳して表示するための緊急情報を生成し、ストリームサーバ411の生成する画像に重畳する。
例えば、先に図5等を参照して説明したように、放送コンテンツの画像上に重畳して配信する緊急情報、すなわちオンスクリーンメッセージ型緊急情報を生成して、ストリームサーバ411の生成する画像に重畳する。
次に、送信装置410の緊急情報サーバ413は、放送信号生成部(放送サーバ)414を介して、オンスクリーンメッセージ型緊急情報を放送コンテンツの画像上に重畳したことを示す通知を受信装置に出力する。
このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
チューナ実装受信装置ミドルウェア420は、イベント処理サーバ421を持つ。
イベント処理サーバ421は、図28に示すチューナ実装受信装置30のミドルウェア110内のイベント処理サーバ501に相当する。
チューナ実装受信装置ミドルウェア420のイベント処理サーバ421は、ステップS511において、チューナ実装/非実装受信装置出力データ制御部430のイベント処理クライアント435(=図28に示すイベント処理クライアント511,521)との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
次に、イベント処理サーバ421は、送信装置410の送信した
「オンスクリーンメッセージ型緊急情報配信通知データ(On Screen Message Notification)」を構成要素とするシグナリングデータ(LLS)」を入力する。
このシグナリンクデータ(LLS)は、図28に示すミドルウェア110のLLSシグナリング解析部113を介して入力する。
図29には、チューナ実装/非実装受信装置出力データ制御部430のアプリケーション制御部431、イベント処理クライアント435を示している。これらの構成は、図28に示すチューナ実装受信装置30とチューナ非実装受信装置40のアプリケーション制御部133,153、イベント処理クライアント511,521の各構成に対応する。
まず、チューナ実装/非実装受信装置出力データ制御部430のイベント処理クライアント435は、チューナ実装受信装置ミドルウェア420のイベント処理サーバ421との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
まず、チューナ実装/非実装受信装置出力データ制御部430のイベント処理クライアント435は、チューナ実装受信装置ミドルウェア420のイベント処理サーバ421から、
「オンスクリーンメッセージ型緊急情報配信通知データ(On Screen Message Notification)」を構成要素とするシグナリングデータ(LLS)」に基づいて生成されたイベント情報入力する。
このイベント情報には、先に図12を参照して説明した「オンスクリーンメッセージ型緊急情報配信通知データ(On Screen Message Notification)」の記録情報が含まれている。
次に、チューナ実装/非実装受信装置出力データ制御部430のアプリケーション制御部431は、ステップS523において、イベント処理クライアント435から受領したイベント情報に応じた処理を実行する。
具体的には、例えば、先に図7を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ(視聴者)に確実に確認させることが可能となる。
次に、図30に示すシーケンス図を参照して、シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて説明する。
(1)送信装置410、
(2)チューナ実装受信装置ミドルウェア420、
(3)チューナ実装/非実装受信装置出力データ制御部430、
図30を参照して説明する緊急情報に対する処理に並行して、AVセグメント、MPDの生成、送信、利用(再生)処理が実行される。
(ステップS601~S602)
まず、送信装置410の緊急情報サーバ413は、ステップS601において、シグナリングデータとして送信する緊急情報(AEAT)を生成し、ステップS602において、放送信号生成部(放送サーバ)414を介して送信する。
AEATには、例えば緊急情報としての緊急情報メッセージや、避難経路を示す地図情報などの表示用データ、あるいは表示用データのアクセス情報等が含まれる。
なお、このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
チューナ実装受信装置ミドルウェア420は、イベント処理サーバ421を持つ。
イベント処理サーバ421は、図28に示すチューナ実装受信装置30のミドルウェア110内のイベント処理サーバ501に相当する。
チューナ実装受信装置ミドルウェア420のイベント処理サーバ421は、ステップS611において、チューナ実装/非実装受信装置出力データ制御部430のイベント処理クライアント435(=図28に示すイベント処理クライアント511,521)との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
次に、イベント処理サーバ421は、送信装置410の送信した
「シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)」を構成要素とするシグナリングデータ(LLS)」を入力する。
このシグナリンクデータ(LLS)は、図28に示すミドルウェア110のLLSシグナリング解析部113を介して入力する。
ステップS613の処理は、チューナ実装受信装置ミドルウェア420のイベント処理サーバ421が、ステップS612で、チューナ実装/非実装受信装置出力データ制御部430のイベント書クライアント435に転送した、イベント情報に、緊急情報として出力するメッセージや地図等の出力用データが含まれていない場合に実行される処理である。
図30には、チューナ実装/非実装受信装置出力データ制御部430の緊急情報制御部433、イベント処理クライアント435を示している。これらの構成は、図28に示すチューナ実装受信装置30とチューナ非実装受信装置40の緊急情報制御部140,160と、イベント処理クライアント511,521の各構成に対応する。
すなわち、図30に示す緊急情報制御部433をアプリケーション制御部に置き換えることも可能である。
まず、チューナ実装/非実装受信装置出力データ制御部430のイベント処理クライアント435は、チューナ実装受信装置ミドルウェア420のイベント処理サーバ421との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
まず、チューナ実装/非実装受信装置出力データ制御部430のイベント処理クライアント435は、チューナ実装受信装置ミドルウェア420のイベント処理サーバ421から、
「シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)」を構成要素とするシグナリングデータ(LLS)」に基づいて生成されたイベント情報入力する。
このイベント情報には、先に図13を参照して説明した「シグナリングデータ適用型緊急情報配信通知(AEAT Message Notification)」の記録情報が含まれている。
(1)緊急情報(AEAT)データ、または緊急情報(AEAT)データアクセス用URL、
(2)緊急情報(AEAT)の配信開始時間、継続時間、
これらのデータが記録されている。
次に、チューナ実装/非実装受信装置出力データ制御部430の緊急情報制御部433は、ステップS623において、イベント処理クライアント435から受領したイベント情報を取得し、ステップS624において、緊急情報(AEAT)データを表示部に出力する処理を実行する。
次に、通信装置である送信装置(サーバ)20と、受信装置(クライアント)30,40の装置構成例について、図31、図32を参照して説明する。
送信装置(サーバ)20は、データ処理部751、通信部752、記憶部753を有する。
受信装置(クライアント)30,40は、通信部771、通信データ処理部772、出力データ処理部773、記憶部774、入力部775、出力部776を有する。
記憶部753は配信対象とする放送コンテンツ等のAVストリームデータの他、アプリケーション、緊急情報、シグナリングデータ、その他の様々なデータなどが格納される。
さらに、記憶部753は、データ処理部751の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
チューナ実装受信装置30の通信部は、送信装置(サーバ)20から配信されるデータ、例えば放送コンテンツ等のAVストリームデータの他、アプリケーション、緊急情報、シグナリングデータ、その他の様々なデータ等を受信する。
さらに、LAN、Wi-Fi等のネットワークを介したデータ送受信が可能な通信部として構成される。
一方、チューナ非実装受信装置40の通信部は、放送波を受信可能なチューナ部は持たず、LAN,Wi-Fi等のネットワークを介したデータ送受信を実行絵可能な通信部として構成される。
シグナリングデータの取得、解析、イベント情報の生成、イベント挿入MPD、イベント挿入セグメント等の生成等の処理を実行する。
図28を参照して説明したイベント処理サーバ501が含まれる場合もある。
具体的には、放送コンテンツの出力制御の他、緊急情報の出力制御、アプリケーション提示コンテンツの表示制御処理等を実行する。
再生データは表示部やスピーカ等の出力部776に出力される。
記憶部774はAVセグメント、MPD、近況情報、シグナリングデータなどが格納される。
さらに、記憶部774は、データ処理部771の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
(1) 送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部は、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する(1)に記載の受信装置。
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部は、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する(1)または(2)に記載の受信装置。
緊急情報の規格として規定されたAEAT(Advanced Emergency Alerting Table)を含む通知である(3)に記載の受信装置。
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、MPD(Media Presentation Description)に挿入した緊急情報イベント挿入MPDを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入MPDからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する(1)~(4)いずれかに記載の受信装置。
前記出力データ制御部に、前記緊急情報イベント挿入MPDを遅滞なく取得させるための事前処理として、
前記出力データ制御部に対してMPD更新通知を出力する(5)に記載の受信装置。
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入セグメントからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する(1)~(6)いずれかに記載の受信装置。
生成した緊急情報イベント通知データをキャッシュ部に格納し、
前記出力データ制御部は、
前記キャッシュ部をアクセスして、前記イベント通知データを取得する(1)~(7)いずれかに記載の受信装置。
前記緊急情報イベント通知データを生成し、送信するイベント処理サーバを有し、
前記出力データ制御部は、
前記緊急情報イベント通知データを、前記イベント処理サーバから受信するイベント処理クライアントを有し、
前記イベント処理クライアントは、前記イベント処理サーバと間でイベント転送専用のセッションを確立して、確立した専用セッションを介して前記緊急情報イベント通知データを前記イベント処理サーバから受信する(1)~(4)いずれかに記載の受信装置。
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供する受信装置。
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する(10)に記載の受信装置。
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する(10)または(11)に記載の受信装置。
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、MPD(Media Presentation Description)に挿入した緊急情報イベント挿入MPDを生成する(10)~(12)いずれかに記載の受信装置。
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成する(10~(13)いずれかに記載の受信装置。
前記出力データ制御部は、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記出力データ制御部は、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する(15)に記載の受信装置。
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記出力データ制御部は、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する(15)または(16)に記載の受信装置。
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部が、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供するデータ処理方法。
前記受信装置は、
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部が、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。
具体的には、例えば、放送コンテンツ出力処理を行なう受信装置のミドルウェアが、送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成する。出力データ制御部は、イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する。例えば、画像上に重畳された緊急情報が配信される場合は、イベント通知により、アプリ提示コンテンツの除去を実行させ、シグナリング緊急情報配信の場合は、迅速な緊急情報の取得、出力処理を実行させる。
本構成により、緊急情報の迅速、かつ確実な視聴者への提示処理を可能とした構成が実現される。
20 送信装置
21 放送サーバ
22 データ配信サーバ
30 チューナ実装受信装置
31 中継サーバ
32 TV
33 PC
34 携帯端末
40 チューナ非実装受信装置
41 PC
42 携帯端末
50 シグナリングデータ
60 AVセグメント
70 その他のデータ
110 ミドルウェア
111 通信部(PHY/MAC)
112 LLSシグナリング取得部
113 LLSシグナリング解析部
114 SLSシグナリング取得部
115 SLSシグナリング解析部(MPDイベント挿入部)
117 セグメント取得部
118 インバンドイベント挿入部
120 HTTPプロキシサーバ
121,122 キャッシュ部
123 アドレス解決部
131,151 再生制御部
132,152 出力制御部
133,153 アプリケーション制御部
140,160 緊急情報制御部
201,251 MPD取得部
202,252 MPD解析部
203,253 セグメント取得部
204,254 セグメント解析部
205,255 イベント抽出部
211,261 復号部
212,262 出力部
310 イベント挿入実行装置
311 データ出力部(DASHサーバ)
312 イベント処理部(イベントサーバ)
320 イベント実行装置
321 再生制御部(イベントクライアント)
322 再生制御部(DASHクライアント)
410 送信装置
411 ストリームサーバ
412 DASHサーバ
413 緊急情報サーバ
414 放送信号処理部(放送サーバ)
420 チューナ受信装置ミドルウェア
421 イベント処理サーバ
430 チューナ実装/非実装受信装置出力データ制御部
431 アプリケーション制御部
432 再生制御部
433 緊急情報制御部
435 イベント処理クライアント
501 イベント処理サーバ
511,521 イベント処理クライアント
751 データ処理部
752 通信部
753 記憶部
771 通信部
772 通信データ処理部
773 出力データ処理部
774 記憶部
775 入力部
776 出力部
801 CPU
802 ROM
803 RAM
804 バス
805 入出力インタフェース
806 入力部
807 出力部
808 記憶部
809 通信部
810 ドライブ
811 リムーバブルメディア
Claims (20)
- 送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部は、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。 - 送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する請求項1に記載の受信装置。 - 送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部は、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する請求項1に記載の受信装置。 - 前記シグナリングデータ適用型緊急情報配信通知は、
緊急情報の規格として規定されたAEAT(Advanced Emergency Alerting Table)を含む通知である請求項3に記載の受信装置。 - 前記ミドルウェアは、
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、MPD(Media Presentation Description)に挿入した緊急情報イベント挿入MPDを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入MPDからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する請求項1に記載の受信装置。 - 前記ミドルウェアは、
前記出力データ制御部に、前記緊急情報イベント挿入MPDを遅滞なく取得させるための事前処理として、
前記出力データ制御部に対してMPD更新通知を出力する請求項5に記載の受信装置。 - 前記ミドルウェアは、
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入セグメントからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する請求項1に記載の受信装置。 - 前記ミドルウェアは、
生成した緊急情報イベント通知データをキャッシュ部に格納し、
前記出力データ制御部は、
前記キャッシュ部をアクセスして、前記イベント通知データを取得する請求項1に記載の受信装置。 - 前記ミドルウェアは、
前記緊急情報イベント通知データを生成し、送信するイベント処理サーバを有し、
前記出力データ制御部は、
前記緊急情報イベント通知データを、前記イベント処理サーバから受信するイベント処理クライアントを有し、
前記イベント処理クライアントは、前記イベント処理サーバと間でイベント転送専用のセッションを確立して、確立した専用セッションを介して前記緊急情報イベント通知データを前記イベント処理サーバから受信する請求項1に記載の受信装置。 - 送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供する受信装置。 - 送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する請求項10に記載の受信装置。 - 送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する請求項10に記載の受信装置。 - 前記ミドルウェアは、
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、MPD(Media Presentation Description)に挿入した緊急情報イベント挿入MPDを生成する請求項10に記載の受信装置。 - 前記ミドルウェアは、
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成する請求項10に記載の受信装置。 - 送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部は、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。 - 送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記出力データ制御部は、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する請求項15に記載の受信装置。 - 送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記出力データ制御部は、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する請求項15に記載の受信装置。 - 受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部が、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。 - 受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供するデータ処理方法。 - 受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部が、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/317,260 US10863247B2 (en) | 2016-07-20 | 2017-06-30 | Receiving device and data processing method |
JP2018528470A JPWO2018016295A1 (ja) | 2016-07-20 | 2017-06-30 | 受信装置、およびデータ処理方法 |
MX2019000491A MX2019000491A (es) | 2016-07-20 | 2017-06-30 | Dispositivo de recepcion y metodo de procesamiento de datos. |
EP17830815.1A EP3490266B1 (en) | 2016-07-20 | 2017-06-30 | Receiving device and data processing method |
CA3029975A CA3029975A1 (en) | 2016-07-20 | 2017-06-30 | Receiving device and data processing method |
KR1020197000581A KR102438011B1 (ko) | 2016-07-20 | 2017-06-30 | 수신 장치 및 데이터 처리 방법 |
BR112019000571A BR112019000571A2 (pt) | 2016-07-20 | 2017-06-30 | dispositivo de recepção e método de processamento de dados. |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016142280 | 2016-07-20 | ||
JP2016-142280 | 2016-07-20 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2018016295A1 true WO2018016295A1 (ja) | 2018-01-25 |
Family
ID=60992117
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2017/024126 WO2018016295A1 (ja) | 2016-07-20 | 2017-06-30 | 受信装置、およびデータ処理方法 |
Country Status (8)
Country | Link |
---|---|
US (1) | US10863247B2 (ja) |
EP (1) | EP3490266B1 (ja) |
JP (1) | JPWO2018016295A1 (ja) |
KR (1) | KR102438011B1 (ja) |
BR (1) | BR112019000571A2 (ja) |
CA (1) | CA3029975A1 (ja) |
MX (1) | MX2019000491A (ja) |
WO (1) | WO2018016295A1 (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021027450A (ja) * | 2019-08-02 | 2021-02-22 | 日本放送協会 | 配信システム、受信装置およびプログラム |
JP2021043709A (ja) * | 2019-09-11 | 2021-03-18 | 日本放送協会 | コンテンツ配信サーバ、コンテンツ配信システム、及びプログラム |
JP2021117755A (ja) * | 2020-01-27 | 2021-08-10 | 日本放送協会 | コンテンツ配信装置、端末、およびプログラム |
JP2022550166A (ja) * | 2020-04-13 | 2022-11-30 | テンセント・アメリカ・エルエルシー | 混合イベントメッセージトラックを含むメディアシステムおよび方法 |
US20230179835A1 (en) * | 2020-02-19 | 2023-06-08 | Sony Corporation | Personalized emergency alert |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10750220B2 (en) * | 2018-04-06 | 2020-08-18 | Enensys Technologies | Method for generating a STL stream, local adapter and corresponding computer program |
US20220094458A1 (en) * | 2020-09-18 | 2022-03-24 | Arris Enterprises Llc | Emergency alert system management in smart media device ecosystem |
US11687386B2 (en) * | 2020-10-07 | 2023-06-27 | Tencent America LLC | MPD validity expiration processing model |
US11617017B2 (en) * | 2021-06-30 | 2023-03-28 | Rovi Guides, Inc. | Systems and methods of presenting video overlays |
WO2023153786A1 (en) * | 2022-02-09 | 2023-08-17 | Samsung Electronics Co., Ltd. | Method of managing media communication in mission critical (mc) system, mc server, and receiver thereof |
US20240031047A1 (en) * | 2022-07-25 | 2024-01-25 | Sony Group Corporation | Delivery of extended emergency notifications through sensory feedback |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006333490A (ja) * | 2005-05-27 | 2006-12-07 | Matsushita Electric Ind Co Ltd | 放送記録再生装置 |
JP2008166863A (ja) * | 2006-12-26 | 2008-07-17 | Sharp Corp | 放送受信装置および携帯端末装置、ならびにこれらを用いた災害通知システムおよび災害通知方法 |
JP2014017741A (ja) * | 2012-07-10 | 2014-01-30 | Sharp Corp | コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体 |
JP2015061195A (ja) * | 2013-09-18 | 2015-03-30 | ソニー株式会社 | 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム |
Family Cites Families (53)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6543051B1 (en) * | 1998-08-07 | 2003-04-01 | Scientific-Atlanta, Inc. | Emergency alert system |
US7260823B2 (en) * | 2001-01-11 | 2007-08-21 | Prime Research Alliance E., Inc. | Profiling and identification of television viewers |
US6684240B1 (en) * | 1999-12-15 | 2004-01-27 | Gateway, Inc. | Method of setting parental lock levels based on example content |
GB0005727D0 (en) * | 2000-03-10 | 2000-05-03 | Koninkl Philips Electronics Nv | Television |
US20020083468A1 (en) * | 2000-11-16 | 2002-06-27 | Dudkiewicz Gil Gavriel | System and method for generating metadata for segments of a video program |
US8046799B2 (en) * | 2000-11-27 | 2011-10-25 | The Directv Group, Inc. | Daypart based navigation paradigm |
US20020124252A1 (en) * | 2001-03-02 | 2002-09-05 | Schaefer Scott R. | Method and system to provide information alerts via an interactive video casting system |
US7380262B2 (en) * | 2001-06-12 | 2008-05-27 | Thomson Licensing | Method and apparatus for generating a list of suggested scheduled television programs |
US20030018970A1 (en) * | 2001-07-19 | 2003-01-23 | Digeo, Inc. | Object representation of television programs within an interactive television system |
US7089578B2 (en) * | 2001-09-29 | 2006-08-08 | Koninklijke Philips Electronics N.V. | Apparatus and method for dynamically updating a viewer profile in a digital television device |
US20030216133A1 (en) * | 2002-05-16 | 2003-11-20 | Poltorak Alexander I. | Apparatus and method for providing emergency broadcast information via a media playing device |
US7870279B2 (en) * | 2002-12-09 | 2011-01-11 | Hrl Laboratories, Llc | Method and apparatus for scanning, personalizing, and casting multimedia data streams via a communication network and television |
US7500235B2 (en) * | 2003-09-05 | 2009-03-03 | Aol Time Warner Interactive Video Group, Inc. | Technique for updating a resident application and associated parameters in a user terminal through a communications network |
US20050086685A1 (en) * | 2003-10-20 | 2005-04-21 | New Technology Management Inc. | Method and system for providing emergency alert system messages in an internet protocol |
US7643564B2 (en) * | 2003-10-28 | 2010-01-05 | Motorola, Inc. | Method and apparatus for recording and editing digital broadcast content |
WO2006055920A2 (en) * | 2004-11-19 | 2006-05-26 | Tivo Inc. | Method and apparatus for secure transfer of previously broadcasted content |
US20060234672A1 (en) * | 2005-04-15 | 2006-10-19 | Adler Robert M | Geographically specific picture telephone advisory alert broadcasting system |
US20070047520A1 (en) * | 2005-08-31 | 2007-03-01 | Byers Charles C | Method for calling multimedia IP units about an impending emergency situation |
KR101165631B1 (ko) * | 2005-11-09 | 2012-07-17 | 엘지전자 주식회사 | 디지털 방송의 dcc 기능을 이용한 비상 사태 경보 처리방법, 데이터 구조 및 이를 위한 방송 수신기 |
US8583758B2 (en) * | 2005-11-30 | 2013-11-12 | Qwest Communications International Inc. | Network based format conversion |
JP2007178927A (ja) * | 2005-12-28 | 2007-07-12 | Canon Inc | 情報検索装置および方法 |
US20080134043A1 (en) * | 2006-05-26 | 2008-06-05 | Sony Corporation | System and method of selective media content access through a recommednation engine |
CN101083807A (zh) * | 2006-06-02 | 2007-12-05 | 鸿富锦精密工业(深圳)有限公司 | 移动通讯设备 |
US7602277B1 (en) * | 2006-10-17 | 2009-10-13 | Cingular Wireless Ii, Llc | Emergency alert information based upon subscriber location |
KR20080046325A (ko) | 2006-11-22 | 2008-05-27 | 엘지전자 주식회사 | 지상파 방송의 비상 사태 경보와 관련된 방송 신호, 이를처리하는 방법 및 이를 위한 방송 수신기 |
KR101526475B1 (ko) * | 2007-06-29 | 2015-06-05 | 가부시키가이샤 한도오따이 에네루기 켄큐쇼 | 표시 장치 및 그 구동 방법 |
US20100060789A1 (en) * | 2007-08-24 | 2010-03-11 | Panasonic Corporation | Reception device and reception method |
US20090150925A1 (en) * | 2007-12-06 | 2009-06-11 | At&T Labs, Inc. | System and Method of Providing An Alert |
US8655266B2 (en) * | 2007-12-17 | 2014-02-18 | Cisco Technology, Inc. | System and method for using mobile media players in a peer-to-peer network |
US9628208B2 (en) * | 2008-02-26 | 2017-04-18 | International Business Machines Corporation | System, method and program product for customizing presentation of television content to a specific viewer and location |
US8380159B2 (en) * | 2008-03-20 | 2013-02-19 | At&T Mobility Ii Llc | Provision of an emergency alert system alert message via a personal area network compatible accessory |
US8190118B2 (en) * | 2008-03-26 | 2012-05-29 | At&T Mobility Ii Llc | Integration of emergency alert information |
US8526909B2 (en) * | 2008-03-27 | 2013-09-03 | At&T Mobility Ii Llc | Systems and methods for activating a security system upon receipt of emergency alert messages |
US8275347B2 (en) * | 2008-03-31 | 2012-09-25 | At&T Mobility Ii Llc | Emergency alert initiation via a mobile device |
US20090300695A1 (en) * | 2008-05-29 | 2009-12-03 | At&T Knowledge Ventures, L.P. | System and method of identifying events scheduled at a media recorder |
US9300993B2 (en) * | 2008-08-29 | 2016-03-29 | Centurylink Intellectual Property Llc | Method and system for providing a content notification for a set-top box |
US20100162300A1 (en) | 2008-12-19 | 2010-06-24 | At&T Intellectual Property I,L.P. | Methods And Systems For Creating An Emergency Alert Channel |
US8566863B2 (en) | 2009-01-15 | 2013-10-22 | Lg Electronics Inc. | Digital broadcast receiver and method for processing emergency alert system data in digital broadcast receiver |
WO2010082780A2 (en) * | 2009-01-18 | 2010-07-22 | Lg Electronics Inc. | Iptv and method for controlling emergency alert system widget in iptv |
US8467275B2 (en) * | 2009-05-29 | 2013-06-18 | Centurylink Intellectual Property Llc | System and method for sharing user content through a set-top box |
US8250598B2 (en) * | 2009-10-13 | 2012-08-21 | At&T Intellectual Property I, L.P. | Method and apparatus for transmitting emergency alert messages |
JP2011087103A (ja) | 2009-10-15 | 2011-04-28 | Sony Corp | コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供 |
US8756646B2 (en) * | 2009-11-25 | 2014-06-17 | Centurylink Intellectual Property Llc | System and method for the exchange and storage of set-top box data |
US8856855B2 (en) * | 2009-11-25 | 2014-10-07 | Centurylink Intellectual Property Llc | System and method for tuning a set-top box remotely via a social network |
US20120102522A1 (en) * | 2010-10-26 | 2012-04-26 | Emmett Long | Emergency notification system and method utilizing preemption of active media sessions |
US8745655B2 (en) * | 2010-12-16 | 2014-06-03 | Verizon Patent And Licensing Inc. | Emergency alerts during playback of video streams on portable devices |
US20130274936A1 (en) * | 2012-04-15 | 2013-10-17 | Swan, Llc | Broadcast energy demand systems and methods |
US9173070B2 (en) * | 2012-04-24 | 2015-10-27 | At&T Intellectual Property I, L.P. | Receiving an emergency alert message via a broadcast data channel |
JP6348251B2 (ja) | 2012-09-13 | 2018-06-27 | サターン ライセンシング エルエルシーSaturn Licensing LLC | 端末装置、受信方法、およびプログラム |
US9055350B2 (en) * | 2012-11-16 | 2015-06-09 | At&T Intellectual Property I, Lp | Method and apparatus for communicating emergency information |
US8805320B2 (en) * | 2012-11-28 | 2014-08-12 | At&T Intellectual Property I, Lp | Method and system for message collision avoidance |
US20140244997A1 (en) * | 2013-02-25 | 2014-08-28 | Qualcomm Incorporated | Emergency mode for iot devices |
US10666961B2 (en) * | 2016-01-08 | 2020-05-26 | Qualcomm Incorporated | Determining media delivery event locations for media transport |
-
2017
- 2017-06-30 KR KR1020197000581A patent/KR102438011B1/ko active IP Right Grant
- 2017-06-30 CA CA3029975A patent/CA3029975A1/en active Pending
- 2017-06-30 US US16/317,260 patent/US10863247B2/en active Active
- 2017-06-30 MX MX2019000491A patent/MX2019000491A/es unknown
- 2017-06-30 WO PCT/JP2017/024126 patent/WO2018016295A1/ja unknown
- 2017-06-30 BR BR112019000571A patent/BR112019000571A2/pt unknown
- 2017-06-30 JP JP2018528470A patent/JPWO2018016295A1/ja active Pending
- 2017-06-30 EP EP17830815.1A patent/EP3490266B1/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006333490A (ja) * | 2005-05-27 | 2006-12-07 | Matsushita Electric Ind Co Ltd | 放送記録再生装置 |
JP2008166863A (ja) * | 2006-12-26 | 2008-07-17 | Sharp Corp | 放送受信装置および携帯端末装置、ならびにこれらを用いた災害通知システムおよび災害通知方法 |
JP2014017741A (ja) * | 2012-07-10 | 2014-01-30 | Sharp Corp | コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体 |
JP2015061195A (ja) * | 2013-09-18 | 2015-03-30 | ソニー株式会社 | 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム |
Non-Patent Citations (2)
Title |
---|
"Sinclair Broadcast Group and LG Electronics Conduct First ATSC 3.0 Advanced Emergency Alert Broadcast", AWARN, 18 April 2016 (2016-04-18), XP055562032, Retrieved from the Internet <URL:http://awarn.org/blog/sinclair-broadcast-group-and-lg-electronics-conduct-first-atsc-3-0-advanced-emergency-alert-broadcast/#> [retrieved on 20170920] * |
See also references of EP3490266A4 * |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021027450A (ja) * | 2019-08-02 | 2021-02-22 | 日本放送協会 | 配信システム、受信装置およびプログラム |
JP7390816B2 (ja) | 2019-08-02 | 2023-12-04 | 日本放送協会 | 配信システム、受信装置およびプログラム |
JP2021043709A (ja) * | 2019-09-11 | 2021-03-18 | 日本放送協会 | コンテンツ配信サーバ、コンテンツ配信システム、及びプログラム |
JP7389594B2 (ja) | 2019-09-11 | 2023-11-30 | 日本放送協会 | コンテンツ配信サーバ、コンテンツ配信システム、及びプログラム |
JP2021117755A (ja) * | 2020-01-27 | 2021-08-10 | 日本放送協会 | コンテンツ配信装置、端末、およびプログラム |
JP7454951B2 (ja) | 2020-01-27 | 2024-03-25 | 日本放送協会 | コンテンツ配信装置、端末、およびプログラム |
US20230179835A1 (en) * | 2020-02-19 | 2023-06-08 | Sony Corporation | Personalized emergency alert |
JP2022550166A (ja) * | 2020-04-13 | 2022-11-30 | テンセント・アメリカ・エルエルシー | 混合イベントメッセージトラックを含むメディアシステムおよび方法 |
JP7271791B2 (ja) | 2020-04-13 | 2023-05-11 | テンセント・アメリカ・エルエルシー | 混合イベントメッセージトラックを含むメディアシステムおよび方法 |
Also Published As
Publication number | Publication date |
---|---|
EP3490266B1 (en) | 2022-09-21 |
US10863247B2 (en) | 2020-12-08 |
US20190230419A1 (en) | 2019-07-25 |
EP3490266A1 (en) | 2019-05-29 |
EP3490266A4 (en) | 2019-05-29 |
MX2019000491A (es) | 2019-06-10 |
JPWO2018016295A1 (ja) | 2019-05-16 |
KR20190029575A (ko) | 2019-03-20 |
KR102438011B1 (ko) | 2022-08-31 |
BR112019000571A2 (pt) | 2019-07-02 |
CA3029975A1 (en) | 2018-01-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2018016295A1 (ja) | 受信装置、およびデータ処理方法 | |
KR102506963B1 (ko) | 수신 장치, 송신 장치, 및 데이터 처리 방법 | |
US11617007B2 (en) | Broadcast receiving device, method of operating broadcast receiving device, linking device for linking to broadcast receiving device, and method of operating linking device | |
US20200221161A1 (en) | Reception apparatus, transmission apparatus, and data processing method | |
AU2010294783B2 (en) | Method and device for providing complementary information | |
US10491969B2 (en) | Broadcast reception device and operating method thereof, and companion device interoperating with the broadcast reception device and operating method thereof | |
US10469919B2 (en) | Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method | |
US10567098B2 (en) | Reception apparatus, transmission apparatus, and data processing method | |
US11388485B2 (en) | Receiving device, receiving method, transmission device, and transmission method | |
US10425689B2 (en) | Reception apparatus, transmission apparatus, and data processing method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17830815 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2018528470 Country of ref document: JP Kind code of ref document: A |
|
ENP | Entry into the national phase |
Ref document number: 3029975 Country of ref document: CA |
|
ENP | Entry into the national phase |
Ref document number: 20197000581 Country of ref document: KR Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
REG | Reference to national code |
Ref country code: BR Ref legal event code: B01A Ref document number: 112019000571 Country of ref document: BR |
|
ENP | Entry into the national phase |
Ref document number: 2017830815 Country of ref document: EP Effective date: 20190220 |
|
REG | Reference to national code |
Ref country code: BR Ref legal event code: B01E Ref document number: 112019000571 Country of ref document: BR Free format text: APRESENTE TRADUCAO DA CERTIDAO DE DEPOSITO DA PRIORIDADE NO PAIS DE ORIGEM OU DECLARACAO ASSINADA, AMBAS CONTENDO TODOS OS DADOS IDENTIFICADORES DA PRIORIDADE, CONFORME ART. 16, 2O, DA LPI. |
|
ENP | Entry into the national phase |
Ref document number: 112019000571 Country of ref document: BR Kind code of ref document: A2 Effective date: 20190111 |