EP3868114B1 - Appareil et procédé de commande de syntoniseur par un logiciel médiateur - Google Patents

Appareil et procédé de commande de syntoniseur par un logiciel médiateur Download PDF

Info

Publication number
EP3868114B1
EP3868114B1 EP19816890.8A EP19816890A EP3868114B1 EP 3868114 B1 EP3868114 B1 EP 3868114B1 EP 19816890 A EP19816890 A EP 19816890A EP 3868114 B1 EP3868114 B1 EP 3868114B1
Authority
EP
European Patent Office
Prior art keywords
lmt
plp
packet
plps
link
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP19816890.8A
Other languages
German (de)
English (en)
Other versions
EP3868114A1 (fr
Inventor
Graham Clift
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Saturn Licensing LLC
Original Assignee
Saturn Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Saturn Licensing LLC filed Critical Saturn Licensing LLC
Publication of EP3868114A1 publication Critical patent/EP3868114A1/fr
Application granted granted Critical
Publication of EP3868114B1 publication Critical patent/EP3868114B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2838—Distribution of signals within a home automation network, e.g. involving splitting/multiplexing signals to/from different paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/26—Arrangements for switching distribution systems
    • 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/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/42615—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific demultiplexing arrangements
    • 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
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG 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/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
    • H04N21/4348—Demultiplexing of additional data and video streams
    • 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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H04N21/43632—Adapting the video stream to a specific local network, e.g. a Bluetooth® network involving a wired protocol, e.g. IEEE 1394
    • 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel
    • H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • 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/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4433—Implementing client middleware, e.g. Multimedia Home Platform [MHP]
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/44—Receiver circuitry for the reception of television signals according to analogue transmission standards
    • H04N5/50—Tuning indicators; Automatic tuning control

Definitions

  • the present disclosure relates generally to an apparatus and method for controlling a tuner through middleware.
  • An Advanced Television Systems Committee (ATSC) 3.0 broadcast signal may include one or more Physical Layer Pipes (PLPs). Each PLP can be modulated and encoded using one of the modes defined in ATSC Standard A/322 - Physical Layer Protocol, dated June 6, 2017 (hereinafter "A/322 Standard"). Accordingly, some PLPs may be more robust than others.
  • One ATSC 3.0 broadcast must include at least one PLP and can include an upper limit of 64 PLPs. However, receivers that process the broadcast stream may be limited to handling a maximum of four PLPs to ensure that practical receiver designs can be made since significant hardware resources are required for each PLP processor in the receiver's tuner/demod submodule.
  • the terms “a” or “an”, as used herein, are defined as one or more than one.
  • the term “plurality”, as used herein, is defined as two or more than two.
  • the term “another”, as used herein, is defined as at least a second or more.
  • the terms “including” and/or “having”, as used herein, are defined as comprising (i.e., open language).
  • the term “coupled”, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically.
  • program or “computer program” or similar terms, as used herein, is defined as a sequence of instructions designed for execution on a computer system.
  • a "program”, or “computer program” may include a subroutine, a program module, a script, a function, a procedure, an object method, an object implementation, in an executable application, an applet, a servlet, a source code, an object code, a shared library/dynamic load library and/or other sequence of instructions designed for execution on a computer system.
  • program may also be used in a second context (the above definition being for the first context).
  • the term is used in the sense of a "television program”.
  • the term is used to mean any coherent sequence of audio/video content such as those which would be interpreted as and reported in an electronic service guide (ESG) as a single television program, without regard for whether the content is a movie, sporting event, segment of a multi-part series, news broadcast, etc.
  • ESG electronic service guide
  • the term may also be interpreted to encompass commercial spots and other program-like content which may not be reported as a program in an ESG.
  • Android is a mobile operating system maintained by Google LLC. and was designed primarily for touchscreen devices.
  • Application software runs on an application framework which includes a Java library based on Open JDK.
  • the current version of USB is USB 3.0 which can accommodate a data transfer speed of up to 5 Gbibs.
  • Some embodiments of the present disclosure involve electronic devices such as a smartphone, tablet, laptop, etc. These types of devices are considered as non-TV devices because while these devices can stream content, they do not have the capability to tune to a television broadcast without additional hardware and software.
  • the present disclosure may also involve electronic devices such as televisions which do not have the ability to tune to a television broadcast without additional hardware and software (e.g., a television that includes an ATSC 1.0 tuner but not a ATSC 3.0 tuner), or to which additional tuner functionality is to be added (e.g., additional or replacement ATSC 3.0 tuner added to a television that already includes an ATSC 3.0 tuner).
  • an ATSC "service” is a collection of media components and/or metadata delivered to receivers in aggregate. Components may be of multiple media types. A service may be either continuous or intermittent. A service can be in real time or non-real time, where a real time service may include a sequence of TV Programs.
  • An example of a real-time service is live broadcast streaming audio/video content.
  • Examples of non-real-time services include, but are not limited to video-on-demand, or other interactive content like one might find on a web page.
  • Some or all components of an ATSC 3.0 service may be delivered via the broadband (internet) path.
  • a service that includes components from both broadcast and broadband is called a "hybrid" service.
  • Fig. 1 is a diagram showing an arrangement of basic components for an ATSC 3.0 system.
  • Video technology is moving from High Definition (HD) digital television to higher resolution technologies, including 4K and 8K video, High Dynamic Range (HDR), wide color gamut, and high frame rate.
  • the ATSC 3.0 system may include a digital video camera 101 that can capture Ultra High Definition (UHD) video, possibly remotely in conjunction with a mobile transmission unit 103 that provides a signal for a TV station 105.
  • the TV station 105 includes, among other things, facilities for television production and broadcast control.
  • an encoder and multiplexer may generate IP packets for a television broadcast.
  • the television broadcast may be transmitted with an ESG to one or more transmitter sites 107.
  • An ATSC 3.0 transmitter site may include an ATSC 3.0 waveform transmitter that transmits radio frequency (RF) signals via a tower transmit antenna 111.
  • the ATSC 3.0 content may be received in a home, office building, library, shop or restaurant 109 by an ATSC 3.0 TV 131, an ATSC 3.0 Gateway or Converter 133, or an ATSC 3.0 enabled mobile device 121.
  • a tablet or smartphone 135 may obtain the broadcast content via a WiFi signal provided from the Gateway or Converter.
  • tablets, smartphones or other mobile devices 121 may pick up the broadcast waveform from a tower transmit antenna 111.
  • Such mobile devices 121 may be used by a pedestrian, within a personal vehicle or within a mode of public transportation.
  • the ATSC 3.0 Gateway and Networks and Playout Servers in TV station 105 may communicate with each other via Internet 30.
  • Mobile operating systems such as the Android operating system developed by Google LLC, are operating systems for phones, tablets, smartwatches, or other mobile devices and include features for mobile or handheld use.
  • mobile devices may include mobile features of cellular communication, Global Positioning System (GPS) navigation, video or single frame cameras, speech recognition, and typically a touchscreen.
  • GPS Global Positioning System
  • Examples of other mobile operating systems include iOS, Windows 10 Mobile, etc.
  • the Android operating system has been designed primarily for touchscreen devices.
  • application software for the Android operating system runs on an application framework which includes a Java library based on Open JDK (Java Development Kit).
  • a DTV broadcaster or simply broadcaster as used herein, relates to a local television station that transmits content via radio waves as a terrestrial television transmission.
  • An ATSC 3.0 system has a layered architecture defined as a physical layer, protocols layer, management layer, and applications and presentation layer. Details of the ATSC 3.0 system is found in, for example, ATSC Standard A/300 - ATSC 3.0 System, dated October 19, 2017 (hereinafter "A/300 Standard").
  • the system architecture for an RF channel may include four main parts: Input Formatting, Bit Interleaved and Coded Modulation (BICM), Framing and Interleaving, and Waveform Generation.
  • BICM Bit Interleaved and Coded Modulation
  • Framing and Interleaving Framing and Interleaving
  • Waveform Generation Waveform Generation
  • the Physical Layer Pipe PLP is a stream of data encoded with a specific modulation, code rate and length. There may be only a single PLP for an RF channel.
  • a PLP may be delivered in a time interleaved format, employing either Convolutional Time Interleaving (CTI) or Hybrid Time Interleaving (HTI) modes of operation.
  • CTI Convolutional Time Interleaving
  • HTTP Hybrid Time Interleaving
  • the input formatting part formats input data packets into output packets called ATSC Link Layer Protocol (ALP) packets.
  • ALP ATSC Link Layer Protocol
  • the length of each ALP packet is variable.
  • the input formatting part maps the ALP packets to Baseband Packets, which include a header and a payload containing ALP packets. Baseband packets have fixed length, with the length determined by the outer code type, inner code rate and code length chosen for the target PLP.
  • Fig. 2 illustrates an exemplary TV device 200 such as TV 131 ( Fig. 1 ), which is configured to access television content and broadcaster applications.
  • the TV device 200 may be a digital television receiver that is incorporated in a vehicle or any of the fixed or mobile devices described above.
  • the TV device 200 includes receiver circuitry that is configured to receive a data stream (e.g ., a broadcast stream) from broadcasters and processing circuitry that is configured to perform various functions of the TV device 200.
  • a tuner/demodulator 202 receives broadcast emissions containing the broadcast stream.
  • the TV device 200 may alternatively or additionally be configured to receive a cable television transmission or a satellite broadcast.
  • the TV device can also communicate with the Internet 30 via a network interface 226.
  • ALP packets are forwarded to a ALP to IP processor 270 that converts these packets to Internet Protocol (IP) packets for further processing.
  • IP Internet Protocol
  • ALP packets may also be buffered and saved to persistent storage 280.
  • a demultiplexer 204 may demultiplex the data stream, which has been converted to IP packets, using any necessary files from storage 280, and deliver the demultipexed data to media engine 290 for decoding into separate audio and video (A/V) streams.
  • Files that are outputted by the demultiplexer 204 such as metadata, Low Level Signaling (LLS) and the Service Layer Signaling (SLS) files, media files, and ESG files may be provided to the CPU 238 for processing.
  • the audio is decoded by an audio decoder 210 and the video is decoded by a video decoder 214. Further, uncompressed A/V data may be received via an uncompressed A/V interface (e.g ., a HDMI interface), if available.
  • the TV device 200 generally operates under control of at least one processor, such as the CPU 238, which is coupled to the persistent storage 280, a working memory 240, program memory 242, and a graphics subsystem 244 via one or more buses ( e . g ., bus 250).
  • the graphics outputted by the graphics subsystem 244 are combined with video images by the compositor and video interface 260 to produce an output suitable for display on a video display.
  • the CPU 238 operates to carry out functions of the TV device 200 including executing script objects (control objects) contained in a broadcaster application (e.g., HTML5 application), native broadcaster application, etc., using for example an HTML5 user agent stored in the program memory 242.
  • a broadcaster application e.g., HTML5 application
  • native broadcaster application e.g., native broadcaster application
  • HTML5 user agent stored in the program memory 242.
  • the collection of files making up the broadcaster application can be delivered over broadcast as packages, via the ROUTE protocol described in ATSC Standard A/331 - Signaling, Delivery, Synchronization, and Error Protection, dated December 6, 2017 (hereinafter "A/331 Standard”).
  • A/331 Standard An exemplary protocol for delivery of broadcaster applications is described in ATSC Standard A/344 - ATSC 3.0 Interactive Content, dated December 18, 2017 (hereinafter "A/344 Standard”).
  • the CPU 238 may be coupled to any one or a combination of the TV device 200 resources to centralize control of one or more functions, in certain embodiments. In one embodiment, the CPU 238 also operates to oversee control of the TV device 200 including the tuner/demodulator 202 and other television resources.
  • Fig. 3 illustrates an embodiment of an electronic device 300, which is configured to access television content and applications via a tuner device (e.g., including a tuner/demodulator) 302 that is configured to connect to the electronic device 300 via a USB.
  • the tuner device 302 connects to the electronic device 300 via other wireless (e.g., WiFi) or wired interfaces in other embodiments.
  • the electronic device 300 may be a fixed device such as a set top box or a mobile or portable device such as a smartphone, tablet computer, laptop, or portable computer.
  • the electronic device 300 may also be a television to which additional tuner functionality is added.
  • Components of the electronic device 300 having similar numbered components with respect to the TV device 200 may provide the same functions as described above for the TV device 200.
  • the tuner device 302 receives an instruction to tune to a particular RF channel (e.g., 6MHz frequency band) to obtain an RF broadcast signal.
  • a particular RF channel e.g., 6MHz frequency band
  • the demodulation process yields ALP packets that are first converted to UDP/IP packets and then fed to middleware and upper-layer software processing in the receiver.
  • the broadcast signal includes one or more PLPs.
  • a broadcaster may choose one of several time interleaver modes for the delivery of a given PLP: none, HTI or CTI. Due to practical constraints on its design, for a receiver to process any PLP that uses CTI interleaver mode, all of its processing resources must be used. In contrast, for PLPs that use HTI interleaver mode, a practical receiver has sufficient resources to be able to process four such PLPs in parallel. In order to accommodate limitations inherent in practical receiver design, the ATSC 3.0 standard requires broadcasters to construct ATSC services such that the number of PLPs that must be processed concurrently to present one service does not exceed these limits.
  • the broadcaster must construct the multiplex such that the number of PLPs the receiver must process concurrently is no more than four, and if CTI interleaver mode is used for delivery of a service, all the components of that service must be delivered within one PLP.
  • At least one PLP carries Low Level Signaling (LLS) tables.
  • LLS tables in the broadcast emission are used by receivers to identify the presence and characteristics of each ATSC 3.0 service. Data about each service may include the channel name and number and source/destination IP address/port values used to deliver the media associated with the service.
  • SLT Service List Table
  • Each PLP carries ALP packets.
  • An ALP packet may encapsulate an Internet Protocol (IP) packet, an MPEG-2 Transport Stream (MPEG-2 TS) packet, a link layer signaling packet, or it can be a null packet.
  • IP Internet Protocol
  • MPEG-2 TS MPEG-2 Transport Stream
  • link layer signaling packet or it can be a null packet.
  • broadcast emissions defined by the ATSC 3.0 standard define data transport for service signaling and streaming media content in multicast UDP/IP packets.
  • Fig. 4 illustrates an example broadcast emission that includes six PLPs, delivered using HTI time interleaver mode, with PLP ID values 1-6.
  • the PLP ID may be a reference number associated with each PLP such as the L1D_plp_id as specified in the A/322 Standard.
  • the PLPs that are marked with a * carry LLS tables.
  • Some ALP packets may carry link-layer signaling tables including a Link Mapping Table (LMT).
  • LMT may be defined in accordance with Section 7.1.1 of ATSC Standard A/330 - Link-Layer Protocol, dated September 19, 2016 (hereinafter "A/330 Standard").
  • A/330 Standard is present in any PLP identified as carrying LLS.
  • a PLP may be identified as carrying LLS when a flag designated for indicating the presence of LLS (e.g., the L1D_plp_lls_flag as defined in the A/322 Standard, Section 9.3.4) is set to '1'.
  • Each instance of the LMT may describe mappings between PLPs and IP addresses/ports for any IP address/port associated with any service referenced in the Service List Table (SLT) (see A/331 Standard, Section 6.3) carried in the identified PLP carrying the LLS tables.
  • SLT Service List Table
  • the SLT may specify a plurality of IP addresses for a selected service, and the LMT provides the mapping between IP addresses specified in the SLT and the PLPs.
  • PLPs #2 and #4 carry LLS tables.
  • the Selection/Demux Logic shown in Fig. 4 may be configured to select four of the six transmitted PLPs and deliver to the middle and upper layers of processing in the receiver the ALP packets contained in these selected PLPs.
  • the four PLPs chosen include #2 and #4 as well as #5 and #6.
  • ALP packets from these four PLPs are passed to the next level of processing in the receiver.
  • the selection/demux logic illustrated in Fig. 4 may be located in the tuner.
  • a decision may need to be made as to which PLPs should be processed and monitored and which may be disregarded.
  • some operations in the receiver such as the "channel scan" require spending time on all PLPs carrying LLS, and the broadcast may include more than four PLPs carrying LLS or multiple PLPs where at least one uses CTI time interleaver mode.
  • it may not be possible to simultaneously monitor all PLPs carrying LLS, and a process that sequences through the PLPs so that all the LLS tables can be collected from the broadcast during the scan must be performed.
  • the tuner device when more than a predetermined number of PLPs (e.g., four in HTI mode or one in CTI mode) are broadcast in a single ATSC 3.0 broadcast emission, the tuner device must choose at most the predetermined number from the available set. In other embodiments, the number of PLPs that can be selected and processed at a time may be less than or more than four. Although the receiver may contain logic that determines the selection of the PLPs to process, this logic may need some information that is not available at the lower levels.
  • a user may select for viewing a service that requires three PLPs: (1) one delivers the LLS tables and the video component, (2) a separate one delivers the audio track in the user's preferred language, and (3) a third one delivers the closed captioning and interactive content (e.g., application) files.
  • the tuner device selects these three PLPs to satisfy the user's request for this service. However, prior to this selection, the tuner device does not have the knowledge of what service(s) the user has selected or visibility as to the structure of that service.
  • Fig. 5 illustrates an embodiment of a "conceptual protocol stack" for the ATSC 3.0 receiver. Information for each field specified in the conceptual stack is found in the A/331 Standard.
  • the lower levels of the protocol stack are the physical layer broadcast, which delivers UDP/IP packets in ALP packets.
  • the SLT may be delivered in UDP/IP packets with a predetermined IP source address and port number that has been designated for the SLT.
  • Other signaling tables, as referenced in the SLT may be delivered in IP packets.
  • Additional IP packets may contain streaming multimedia files comprising the service.
  • embodiments of the present disclosure are directed to enabling middleware processes in a receiver to access the information needed to provide commands to the tuner device that enable the tuner device to process specific PLPs.
  • Fig. 6 is a block diagram of an embodiment of a DTV receiver 600 having a television receiver application 603 such as an ATSC 3.0 television receiver application.
  • the television receiver application 603 provides functionality allowing the rendering and display to the user of broadcast (and OTT) streaming video, as well as audio and closed captioning data.
  • the television receiver application 603 may support a "runtime environment" through which broadcaster applications may be executed.
  • a broadcaster application may include content that includes HTML markup, JavaScript, and CSS as specified in the A/344 Standard.
  • additional functionality may be incorporated by means of a Web Sockets protocol.
  • the Web Sockets APIs specified in the A/344 Standard add support for capabilities including access to tuning functions, memory management, interaction between the broadcaster application and the receiver's media player (RMP), among many others.
  • a broadcaster application may be provided by a broadcaster as an adjunct to a regular streaming broadcast television service to provide interactivity or to operate in the background, for example, to monitor the user's usage of the service.
  • the broadcaster may define a type of service that is presented as the output of the broadcaster application that is associated with that service. Such services may not be offered by an ATSC 3.0 receiver that does not support the A/344 Standard interactive content specification.
  • the DTV receiver 600 includes an associated Android activity 601 component.
  • the media player 613 may be an application level media player for Android, such as ExoPlayer.
  • the media player 613 may also support Dynamic Adaptive Streaming over HTTP (DASH), SmoothStreaming, and Common Encryption.
  • the activity 601 component can accept user input from a remote control unit (RCU) or keypad to support channel change or selection, which is reflected by the "tune()" function.
  • RCU remote control unit
  • a function that may be performed by the activity 601 is to create two viewing surfaces that give the user a view of the video associated with the service (the "Player Surface") and any overlays (the "Overlay Surface") that a broadcaster application (e.g., HTML5 web application) might produce.
  • the Player Surface may be handled by the media player 613, while the Overlay Surface may be handled by Webview 615.
  • the tuner device 605 is a hardware device that can tune to and demodulate an ATSC 3.0 broadcast signal, and produce a sequence of ATSC 3.0 Link layer Protocol (ALP) packets.
  • ALP Link layer Protocol
  • the ALP packets are converted to IP packets by an ALP to IP converter 621.
  • the link layer processing used to retrieve IP packets from ALP packets can be done either within the tuner device 605 or within the television receiver application 603.
  • the television receiver application 603 interfaces with the tuner device 605 through specialized extensions to the OS system (e.g., Android) calls.
  • the tuner device 605 delivers ALP packets from among the PLPs it has been configured to process.
  • the television receiver application 603 may perform various configuration operations on the tuner device 605, including to command it to tune to a particular RF frequency, as well as to process particular PLPs.
  • the television receiver application 603 may also have required information to begin retrieving audio, video, and caption packets from the broadcast and have them sent to media player 613 for decoding and rendering.
  • the tuner device 605 demodulates PLPs to produce ALP packets which carry link-layer signaling including LMTs and ALP packets containing data required to decompress IP packets, in addition to packets containing low-level and Service Layer Signaling (SLS) tables, and files associated with services.
  • the "ALP to IP” function 621 converts ALP packets containing IP packets into IP packets by performing decompression, and in some embodiments, converts LMT instances carried in ALP packets into IP packets for delivery across an interface between the "ALP to IP" function 621 and the middleware.
  • Fig. 7 illustrates a receiver in an electronic device 700.
  • the electronic device 700 may be, for example, a set-top box, tablet computer, laptop, or smartphone which does not contain any native tuning capability.
  • the electronic device 700 may be a television to which additional tuning functionality is to be added.
  • the tuner device 705 is an external USB-connected device that connects to the electronic device 700 via a USB port.
  • the television receiver application 603 may use a UsbManager Android Class 723 for delivering and receiving information across the USB interface 725.
  • the interface 725 is a WiFi interface where external hardware 800 communicates with electronic device 700 wirelessly.
  • the tuner device 705 delivers ALP packets from the broadcast across the USB interface 725, and the ALP to IP converter block 621 performs conversion of ALP packets containing LMTs to IP packets in accordance with embodiments disclosed herein.
  • the upper or middle layer software processes have the ability to send commands to the tuner device 605 and 705, respectively, that causes the tuner device to process any specified PLP.
  • An example of the API and commands that permit the television receiver application 603 in the electronic device 700 to communicate with the tuner device 705 across the USB interface is disclosed in the application titled "Television Receiver Application for Non-Television Devices.
  • Fig. 8 illustrates an embodiment of an electronic device 700 in which external hardware 800 includes a tuner device 805 and also the "ALP to IP" converter block 821.
  • the ALP to IP converter block 821 includes the ability to convert ALP packets containing LMTs in accordance with embodiments of the present disclosure. In some embodiments according to the implementation in Fig. 8 , only IP packets flow across the portion of the USB or WiFi interface.
  • signaling tables are present in the link-layer signaling portion of the ATSC 3.0 broadcast which identify PLPs, which will deliver IP packets associated with a given source and destination IP address and port. These link-layer signaling tables are not delivered in IP packets in the broadcast emission.
  • the middle and upper-layer software processes in the receiver only process files and delivery objects transported in IP packets. Embodiment of the present disclosure describe methods whereby the middle- and upper-layer software processes can access these link-layer signaling tables.
  • the LMTs can be transported inside the UPD/IP packets to the middle and upper-layer software stack. These LMTs are used by the middle and upper-layer processes in the electronic device 700 to determine which PLPs the tuner device should activate.
  • the LMT is a data structure 900 as illustrated in Fig. 9 and defined in the A/330 Standard, Section 7.1.
  • a predetermined IP address/port is designated for IP packets containing LMT instances.
  • the tuner device 805 captures ALP packets containing LMT tables and converts them into ALP packets carrying an IP packet using the predetermined IP address/port that has been designated for LMT instances.
  • the middle or upper-level software process in the electronic device 700 may process IP packets associated with the predetermined IP address/port to extract LMT(s) to determine which PLPs to activate in the tuner device 805.
  • the LLS tables are delivered to the middleware in IP packets with an IP address/port that is designated for LLS tables such as the SLT as described in the A/331 Standard, Section 6.1.
  • the IP address/port that can be used for designating LMT instances is the same multicast IP address assigned to the ATSC for its use (224.0.23.60) but with a destination port value one higher than that assigned to ATSC by IANA, or 4938. Port 4938 is currently unassigned by the Internet Assigned Numbers Authority (IANA). IANA has assigned 224.0.23.60 to "AtscSvcSig.”
  • Fig. 10 illustrates an example ALP packet 1000 that contains an LMT.
  • an ALP packet containing an LMT that is less than 2048 bytes is structured as follows:
  • Fig. 11 illustrates an example ALP packet 1100 that includes an IP packet containing an LMT.
  • the ALP packet 1100 includes an ALP packet header 1100a, an IP header 1100b, a UDP header 1100c, and a LMT header 1100d.
  • the IP header 1100b may include a predetermined IP address (e.g., destination address)
  • the UDP header 1100c may include a predetermined port number (e.g., destination port), both of which are designated to indicate that ALP packet 1100 contains an LMT, such as LMT 900 ( Fig. 9 ).
  • the ALP packet 1000 ( Fig. 10 ) containing the LMT is detected by a tuner device, the LMT is extracted and encapsulated with LMT header 1100d, UDP header 1100c, IP header 1100b, and ALP header 1100a.
  • an ALP packet containing an uncompressed IPv4 packet of less than 2048 bytes, and encapsulating an LMT that fits in such a packet is structured as follows as illustrated in Fig. 11 :
  • ALP packets longer than 2048 bytes may be accommodated for when the length of an LMT exceeds the approximately 2000 bytes from the previously disclosed example.
  • the header_mode field when set to '1', indicates the presence of an Additional Header for single packets.
  • the Additional Header may carry five MSBits of the length when it exceeds the length that can be represented in the 11-bit length field at the beginning of the ALP packet.
  • 16 bits of length are represented, and ALP packets of 65,535 bytes can be transported.
  • each instance of the LMT describes mappings between PLPs and IP addresses/ports for any IP address/port associated with any service referenced in the SLT (e.g., A/331 Standard, Section 6.3) carried in the identified PLP carrying the LLS tables.
  • an LMT shall be present in any PLP identified as carrying LLS.
  • a given ATSC 3.0 broadcast emission may include multiple different instances of LMTs.
  • the middleware layers can access these multiple different LMTs and keeps track of them to compile a complete picture of the PLP to IP address/port mappings for the full emission.
  • the "LMT header," which includes the LMT Version and the identification of the PLP associated with this LMT instance may be used to keep track of the multiple LMT instances.
  • the version associated with a given LMT instance may be used by the receiver to determine whether or not any given instance of an LMT needs to be processed or can be discarded as a duplicate. For example, referring to Fig. 4 , the LMT delivered in PLP #2 may be at version 2, while the LMT delivered in PLP #4 is at version 6. The version is correlated to the PLP associated with the delivery of that LMT instance.
  • the 8-bit signaling version field (see A/330 Standard, Table 5.10) is included in the LMT Header part of the packet to indicate changes in the LMT. For example, the value of this field shall be incremented by 1 whenever any data of the LMT changes.
  • the signaling version field may be transported in the IP packet in the LMT version field, located just preceding the LMT itself.
  • Fig. 12 illustrates an embodiment of a process performed by a tuner device such as tuner device 605, 705, or 805.
  • the process illustrated in Fig. 12 may be initiated by the television receiver application in response to the user requesting access to a particular ATSC 3.0 television service.
  • the command to the tuner to tune to a particular RF channel may arise from the television receiver application's prior knowledge of what RF channel the requested service is transmitted on, usually discovered by a channel scan process.
  • the process may generally start at step S1200 where the tuner device receives a command from the television receiver application to tune to a particular RF channel. For example, when a DTV receiver is first turned on, the television receiver application may be launched and it may send an instruction to the tuner device to reacquire the last tuned channel. Similarly, when a tuner device is connected to an electronic device via USB, the television receiver application may send an instruction to tune to the last tuned channel.
  • step S1202 the requested RF channel is tuned and a digital broadcast signal is acquired.
  • the tuner receives a command from the television receiver application to process one or more PLPs.
  • the maximum number that can be requested is four, which corresponds to the capability of practical tuner devices.
  • the set of PLPs the receiver application requests in S1204 may be based on previously determined information about the service, specifically, which PLPs the service may be using. In some rare cases, the broadcaster may change the configuration of the broadcast signal, to, for example, begin using different PLPs for the service.
  • the receiver application may perform a "channel map refresh" of the tuned RF channel, which involves first processing (possibly in sequence, at most four at a time) all the PLPs in the broadcast signal so that all the LMTs and SLTs can be retrieved and recorded. After the "channel map refresh" is performed, the indicated PLPs can be requested.
  • step S1206 it is determined, for each selected PLP, whether it contains LLS. For each processed PLP that does not contain LLS (e.g., L1D_plp_lls_flag is set to '0'), the process continues at step S1214 wherein all ALP packets from the selected PLPs are transferred to the middleware layers in the receiver application.
  • step S1210 for each selected PLP that does contain LLS (e.g., L1D_plp_lls_flag is set to '1')
  • the process proceeds to step S1210 to extract ALP packets containing the LMT.
  • the process proceeds to step S1210 where an ALP packet containing an IP packet with the LMT, such as ALP packet 1100, is generated.
  • the ALP packet generated in step S1210 includes the LMT extracted in step S1208.
  • the ALP packet generated in step S1210 includes the LMT header 1100d containing the LMT version field and a field specifying the ID of the PLP carrying the LMT. Note that the process beginning at S 1206 is performed continuously for each selected PLP.
  • the ALP packet generated in step S1210 also includes the UDP header 1100c and IP header 1 100d. Furthermore, the UDP header 1100c may specify a destination port, and the IP header 1 100d may specify a destination address, both of which are designated to indicate the presence of the LMT. Additionally, the ALP packet generated in step S1210 includes the ALP packet header 1 100a. The process proceeds to step S1212 where the ALP packets from the selected PLPs and the ALP packet with the IP packet carrying the LMT are transferred to middleware processes. In some embodiments, where the tuner device is configured to output IP packets, the ALP to IP converter may be bypassed.
  • Fig. 13 illustrates an embodiment of a process performed by a television receiver application.
  • the process may generally start at step S1300 where an IP packet stream is received.
  • the IP packet stream may originate as a stream of ALP packets from a tuner device (e.g., 605. 705. 805), where the stream of ALP packets is passed through an ALP to IP converter (e.g., 621, 821) to produce the IP packet stream.
  • a tuner device e.g. 605. 705. 805
  • an ALP to IP converter e.g., 621, 821
  • the process proceeds to step 1302, where the LMT is extracted from the IP stream.
  • the IP packet containing the LMT is detected when the IP packet includes an address and port designated to indicate the presence of the LMT (e.g., Destination Address in IP header 1100b and Destination Port in UDP header 1100c).
  • LLS tables are retrieved from the received IP packet stream.
  • the LLS tables are included in IP packets having an address and port that are designated to indicate the presence of LLS tables.
  • the LLS tables are transmitted in the same IP packet stream that contain the LMT.
  • the LLS tables may contain a SLT, which specifies one or more IP addresses for a service.
  • step S1306 it is determined whether the LMT and LLS point to a PLP that has yet to be selected for processing. For example, this situation may occur when the SLT specifies that service A requires IP address A, the LMT specifies that PLP #5 ( Fig. 4 ) includes ALP packets for IP address A, and PLP #5 was not one of the PLPs that was processed by the tuner in step S 1204 ( Fig. 12 ). If the LMT and LLS point to an unprocessed PLP, the process proceeds to step S1308, where the television receiver application transmits a command to the tuner device that instructs the tuner device to process the unprocessed PLP.
  • the process in Fig. 13 ends.
  • the television receiver application can decode and output audio and visual content corresponding to a service associated with the broadcast stream.
  • Fig. 14 is a block diagram showing an example of a hardware configuration of a computer that can be configured to perform functions of any one or a combination of reception apparatus and service distribution system.
  • the computer is configured to perform one or a combination of the functions or steps described herein with respect to the TV device, electronic device, and/or the tuner device.
  • the computer includes a CPU 1402, ROM (read only memory) 1404, and a RAM (random access memory) 1406 interconnected to each other via one or more buses 1408.
  • the one or more buses 1408 are further connected with an input-output interface 1410.
  • the input-output interface 1410 is connected with an input portion 1412 formed by a keyboard, a mouse, a microphone, remote controller, etc.
  • the input-output interface 1410 is also connected to an output portion 1414 formed by an audio interface, video interface, display, speaker and the like; a recording portion 1416 formed by a hard disk, a non-volatile memory or other non-transitory computer readable storage medium; a communication portion 1418 formed by a network interface, modem, USB interface, fire wire interface, etc.; and a drive 1420 for driving removable media 1422 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc.
  • the CPU 1402 loads a program stored in the recording portion 1416 into the RAM 1406 via the input-output interface 1410 and the bus 1408, and then executes a program configured to provide the functionality of the one or a combination of the functions described herein with respect to the TV device, electronic device, and/or the tuner device.
  • any one or a combination of the algorithms shown in Fig. 12 and 13 may be completely performed by the circuitry included in the TV device shown in Fig. 2 .
  • the circuitry included in the tuner device, as shown in Fig. 3 may be used for the algorithm in Fig. 12
  • the circuitry included in the electronic device, as shown in Fig. 3 may be used for the algorithm in Fig. 13 .

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • Automation & Control Theory (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Circuits Of Receivers In General (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Claims (15)

  1. Appareil de réception (200) comprenant :
    un ensemble de circuits de traitement (238) configuré pour :
    recevoir des paquets IP qui comprennent des informations de signalisation provenant d'un flux de diffusion de télévision numérique reçu par un dispositif (202) syntoniseur, le flux de diffusion comprenant une pluralité de tuyaux de couche physique, PLP, chaque PLP contenant une pluralité de paquets de protocole de couche de liaison,
    extraire les informations de signalisation des paquets IP, les informations de signalisation comprenant une table de mappage de liaison, LMT, et au moins une table de signalisation de niveau bas, LLS, la LMT étant identifiée sur la base d'une adresse IP prédéterminée et d'un port désignés pour indiquer la présence de la LMT, et
    récupérer, sur la base de la LMT extraite et d'au moins une table LLS extraite, un contenu visuel et audio correspondant à un service associé au contenu de diffusion ;
    identifier une adresse IP spécifiée dans l'au moins une table LLS, l'adresse IP correspondant au service associé au flux de diffusion,
    déterminer si la LMT spécifie un PLP non traité à partir de la pluralité de PLP, qui est associé à l'adresse IP qui a été spécifiée, et
    en réponse à la détermination que la LMT spécifie le PLP non traité, communiquer une commande au dispositif syntoniseur qui donne instruction au dispositif syntoniseur de délivrer en sortie les paquets de protocole de couche de liaison associés au PLP non traité.
  2. Appareil de réception selon la revendication 1, comprenant en outre :
    le dispositif syntoniseur qui délivre en sortie des paquets de protocole de couche de liaison ; et
    un ensemble de circuits de convertisseur IP vers un protocole de couche de liaison configuré pour convertir chaque paquet de protocole de couche de liaison délivré en sortie en un paquet IP.
  3. Appareil de réception selon la revendication 1, comprenant en outre :
    une interface de bus en série universel, USB, dans lequel le dispositif syntoniseur est configuré pour se connecter à l'appareil de réception via l'interface USB.
  4. Appareil de réception selon la revendication 3, dans lequel le dispositif syntoniseur comprend un ensemble de circuits de convertisseur IP vers un protocole de couche de liaison configuré pour convertir chaque paquet de protocole de couche de liaison délivré en sortie à partir du dispositif syntoniseur en un paquet IP.
  5. Appareil de réception selon la revendication 1, dans lequel le paquet IP qui contient la LMT comprend en outre un en-tête de LMT qui spécifie (i) une version de LMT et (ii) un champ d'identification (ID) PLP qui identifie le PLP contenant la LMT, dans lequel une combinaison de la version de LMT et de l'ID de PLP fournit un identifiant de référence pour la LMT.
  6. Dispositif syntoniseur (202) comprenant :
    une interface de communication configurée pour se connecter à un appareil de réception qui exécute une application de récepteur de télévision ; et
    un ensemble de circuits de traitement configuré pour :
    (i) recevoir un flux de diffusion de télévision numérique qui comprend une pluralité de tuyaux de couche physique, PLP, chaque PLP contenant une pluralité de paquets de protocole de couche de liaison,
    (ii) identifier au moins un PLP à partir de la pluralité de PLP qui comprend une signalisation de niveau bas, LLS,
    (iii) extraire une table de mappage de liaison, LMT, à partir de l'au moins un PLP comprenant la LLS,
    (iv) générer un paquet de protocole de couche de liaison comprenant un paquet IP, qui contient la LMT et possède une adresse IP prédéterminée et un port, et
    (v) transférer le paquet de protocole de couche de liaison contenant le paquet IP avec la LMT à l'application de récepteur de télévision ;
    dans lequel le dispositif syntoniseur reçoit une commande à partir de l'application de récepteur de télévision de traiter un ou des PLP à partir la pluralité de PLP, dans lequel l'au moins un PLP identifié qui comprend la LLS est compris dans la pluralité de PLP.
  7. Dispositif syntoniseur selon la revendication 6, dans lequel l'adresse IP prédéterminée et le port sont désignés pour la LMT.
  8. Dispositif syntoniseur selon la revendication 7, dans lequel le paquet IP qui comprend la LMT comprend en outre un en-tête de LMT qui spécifie (i) une version de LMT et (ii) un champ d'ID de PLP qui identifie le PLP contenant la LMT, dans lequel une combinaison de la version de LMT et de l'ID de PLP fournit un identifiant de référence pour la LMT.
  9. Dispositif syntoniseur selon la revendication 6, dans lequel l'au moins un PLP identifié qui comprend la LLS est identifié sur la base d'un indicateur qui indique la présence de la LLS.
  10. Dispositif syntoniseur selon la revendication 6, dans lequel le paquet IP avec la LMT et au moins une table LLS sont transmis à l'application de récepteur de télévision dans un même flux de paquets IP.
  11. Support lisible par ordinateur non transitoire stockant des instructions qui, lorsqu'elles sont exécutées par un processeur, amènent le processeur à mettre en œuvre un procédé comprenant :
    la réception (S1300) de paquets IP qui comprennent des informations de signalisation provenant d'un flux de diffusion de télévision numérique reçu par un dispositif syntoniseur, le flux de diffusion comprenant une pluralité de tuyaux de couche physique, PLP, chaque PLP contenant une pluralité de paquets de protocole de couche de liaison ;
    l'extraction (S1302, S1304) des informations de signalisation des paquets IP, les informations de signalisation comprenant une table de mappage de liaison, LMT, et au moins une table de signalisation de niveau bas, LLS, la LMT étant identifiée sur la base d'une adresse IP prédéterminée et d'un port désignés pour indiquer la présence de la LMT, et
    la récupération, sur la base de la LMT extraite et d'au moins une table LLS extraite, d'un contenu visuel et audio correspondant à un service associé au contenu de diffusion ;
    l'identification (S1306) d'une adresse IP spécifiée dans l'au moins une table LLS, l'adresse IP correspondant au service associé au flux de diffusion ;
    la détermination pour savoir si la LMT spécifie un PLP non traité à partir de la pluralité de PLP qui est associé à l'adresse IP qui a été spécifiée ; et
    en réponse à la détermination que la LMT spécifie le PLP non traité, communiquer (S1308) une commande au dispositif syntoniseur qui donne instruction au dispositif syntoniseur de délivrer en sortie les paquets de protocole de couche de liaison associés au PLP non traité.
  12. Support lisible par ordinateur non transitoire selon la revendication 11, dans lequel le paquet IP qui contient la LMT comprend en outre un en-tête de LMT qui spécifie (i) une version de LMT et (ii) un champ d'ID de PLP qui identifie le PLP contenant la LMT, dans lequel une combinaison de la version de LMT et de l'ID de PLP fournit un identifiant de référence pour la LMT.
  13. Support lisible par ordinateur non transitoire stockant des instructions qui, lorsqu'elles sont exécutées par un processeur, amènent le processeur à mettre en œuvre un procédé comprenant :
    la réception d'un flux de diffusion de télévision numérique qui comprend une pluralité de tuyaux de couche physique, PLP, chaque PLP contenant une pluralité de paquets de protocole de couche de liaison ;
    l'identification (S1206) d'au moins un PLP à partir de la pluralité de PLP qui comprend une signalisation de niveau bas, LLS ;
    l'extraction (S1208) d'une table de mappage de liaison, LMT, à partir de l'au moins un PLP comprenant la LLS ;
    la génération (S1210) d'un paquet de protocole de couche de liaison comprenant un paquet IP, qui contient la LMT et possède une adresse IP prédéterminée et un port ; et le transfert (S1212) d'un paquet de protocole de couche de liaison contenant le paquet IP avec la LMT à un appareil de réception qui exécute une application de récepteur de télévision ; et
    la réception (S1204) d'une commande à partir de l'application de récepteur de télévision pour traiter un ou des PLP à partir de la pluralité de PLP, dans lequel l'au moins un PLP identifié qui comprend la LLS est compris dans la pluralité de PLP.
  14. Support lisible par ordinateur non transitoire selon la revendication 13, dans lequel l'adresse IP prédéterminée et le port sont désignés pour la LMT.
  15. Support lisible par ordinateur non transitoire selon la revendication 14, dans lequel le paquet IP qui comprend la LMT comprend en outre un en-tête de LMT qui spécifie (i) une version de LMT et (ii) un champ d'ID de PLP qui identifie le PLP contenant la LMT, dans lequel une combinaison de la version de LMT et de l'ID de PLP fournit un identifiant de référence pour la LMT.
EP19816890.8A 2018-11-23 2019-11-21 Appareil et procédé de commande de syntoniseur par un logiciel médiateur Active EP3868114B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/199,114 US10791296B2 (en) 2018-11-23 2018-11-23 Apparatus and method for tuner control by middleware
PCT/IB2019/060009 WO2020104980A1 (fr) 2018-11-23 2019-11-21 Appareil et procédé de commande de syntoniseur par un logiciel médiateur

Publications (2)

Publication Number Publication Date
EP3868114A1 EP3868114A1 (fr) 2021-08-25
EP3868114B1 true EP3868114B1 (fr) 2024-01-10

Family

ID=68808445

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19816890.8A Active EP3868114B1 (fr) 2018-11-23 2019-11-21 Appareil et procédé de commande de syntoniseur par un logiciel médiateur

Country Status (6)

Country Link
US (1) US10791296B2 (fr)
EP (1) EP3868114B1 (fr)
JP (1) JP7181511B2 (fr)
KR (1) KR102504159B1 (fr)
CN (1) CN113170219B (fr)
WO (1) WO2020104980A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113468160A (zh) * 2021-07-23 2021-10-01 杭州数梦工场科技有限公司 数据治理方法及装置、电子设备

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2555510A4 (fr) * 2010-04-01 2015-04-01 Lg Electronics Inc Appareil d'émission de signal de diffusion, appareil de réception de signal de diffusion, et procédé d'émission-réception de signal de diffusion dans un appareil d'émission-réception de signal de diffusion
WO2016076654A1 (fr) * 2014-11-13 2016-05-19 엘지전자 주식회사 Dispositif d'émission de signal de diffusion, dispositif de réception de signal de diffusion, procédé d'émission de signal de diffusion et procédé de réception de signal de diffusion
WO2016105090A1 (fr) 2014-12-22 2016-06-30 엘지전자 주식회사 Dispositif d'émission de signal de diffusion, dispositif de réception de signal de diffusion, procédé d'émission de signal de diffusion et procédé de réception de signal de diffusion
US10498792B2 (en) * 2015-05-17 2019-12-03 Lg Electronics Inc. Apparatus and method for transmitting or receiving broadcast signal
US10659281B2 (en) * 2015-07-08 2020-05-19 Lg Electronics Inc. Method and apparatus for transmitting/receiving a broadcast signal
CN107925780B (zh) * 2015-08-20 2021-03-19 Lg 电子株式会社 广播信号发送方法及广播信号接收方法
WO2017146157A1 (fr) 2016-02-23 2017-08-31 Sharp Kabushiki Kaisha Systèmes et procédé pour la signalisation de couche de liaison d'informations de couche supérieure
WO2017208854A1 (fr) * 2016-06-03 2017-12-07 ソニー株式会社 Dispositif de réception, dispositif de transmission, et procédé de traitement de données
WO2017217825A1 (fr) * 2016-06-17 2017-12-21 엘지전자(주) Dispositif et procédé de transmission/réception de signal de diffusion
US20180007307A1 (en) * 2016-07-02 2018-01-04 Qualcomm Incorporated Distributed Implementation Architecture for Broadcast Receiver

Also Published As

Publication number Publication date
EP3868114A1 (fr) 2021-08-25
WO2020104980A1 (fr) 2020-05-28
US10791296B2 (en) 2020-09-29
CN113170219B (zh) 2024-02-02
KR20210076127A (ko) 2021-06-23
CN113170219A (zh) 2021-07-23
JP7181511B2 (ja) 2022-12-01
US20200169685A1 (en) 2020-05-28
JP2022507912A (ja) 2022-01-18
KR102504159B1 (ko) 2023-02-28

Similar Documents

Publication Publication Date Title
US11006164B2 (en) TV and electronic device with external tuner and memory for personal video recording
KR100692361B1 (ko) 패킷 식별자 검색 필터링
US11956159B2 (en) Transmission device, transmission method, reception device, and reception method
CN113170222B (zh) 用于电视机和电子设备的电视接收器应用
US11729456B2 (en) Long duration error correction with fast channel change for ATSC 3.0 real-time broadcast mobile application
EP3868114B1 (fr) Appareil et procédé de commande de syntoniseur par un logiciel médiateur
US20210368244A1 (en) Method and apparatus for transmission and reception of wireless data
US11553245B1 (en) Techniques for receiving non-real time (NRT) data whilst traversing a multi-frequency network boundary
KR102524389B1 (ko) 미국 디지털 텔레비전 방송 표준 위원회(atsc) 3.0 애플리케이션이 비-atsc 3.0 서비스 상에서 실행하기 위한 장치 및 방법
US9807459B2 (en) Media interface device
KR20100118822A (ko) 아이피티브이 단말 시스템

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210518

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20230201

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SATURN LICENSING, LLC

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTC Intention to grant announced (deleted)
INTG Intention to grant announced

Effective date: 20230522

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230514

GRAJ Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted

Free format text: ORIGINAL CODE: EPIDOSDIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTC Intention to grant announced (deleted)
INTG Intention to grant announced

Effective date: 20230822

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602019044979

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20240110