DIGITAL RIGHTS MANAGEMENT (DRM) OPERATION BASED ON MEDIA TRANSPORT (MMT) FOR THE ADVANCED TELEVISION SYSTEMS COMMITTEE, INC. (ATSC) 3.0.

Abstract

A decoding device includes a communication interface and a processor operatively coupled to the communication interface. The communication interface receives at least a portion of a broadcast stream containing media data, including media samples. The processor identifies information elements containing DRM processing information within the broadcast stream. Each information element is associated with a corresponding media sample from the media data. For each information element, the processor also identifies the media sample associated with that information element. Based on the information element, the processor further identifies the DRM processing information for that media sample. Finally, the processor decodes the media sample based on the DRM processing information.

Description

DIGITAL RIGHTS MANAGEMENT (DRM) OPERATION BASED ON MEDIA TRANSPORT (MMT) FOR THE ADVANCED TELEVISION SYSTEMS COMMITTEE, INC. (ATSC) 3.0. Field of Invention This invention relates generally to broadcasting devices and processes. More specifically, this invention relates to the Moving Picture Experts Group (MPEG) Media Transport (MMT)-based digital rights management (DRM) operation for the Advanced Television Systems Committee, Inc. (ATSC) 3.0. Background of the Invention ATSC 3.0 receivers and transmitters are being deployed worldwide. An ATSC 3.0 client is coming soon in the United States. Major mobile equipment manufacturers are implementing the ATSC 3.0 client in new electronic devices. Brief Description of the Invention Solution to the problem This invention provides an MMT-based DRM operation for ATSC 3.0. In a first embodiment, a decoding device includes a communication interface and a Ln / eznz / B / YiAi cor Ref. 349647 processor operatively coupled to the communication interface. The communication interface receives at least a portion of a broadcast stream that includes media data comprising media samples. The processor identifies information elements containing digital rights management (DRM) processing information in the broadcast stream, wherein each information element is associated with a respective media sample of the media data. For each information element, the processor also identifies the media sample that is associated with the information element. The processor further identifies, based on the information element, DRM processing information for a media sample. In addition, the processor decodes the media sample based on the DRM processing information. In a second embodiment, a method includes receiving, using a communication interface of the set-top box device, at least a portion of a broadcast stream including media data comprising media samples. The method also includes identifying, using a processor of the set-top box device operatively coupled to the communication interface, information elements containing digital rights management (DRM) processing information in the broadcast stream, wherein each information element is associated with a respective media sample of the media data. For each information element, the method further includes identifying, using the processor, the media sample that is associated with the information element. The method further includes identifying, based on the information element, DRM processing information for that media sample.The method further includes decoding, using the processor, the media sample based on the DRM processing information. According to one embodiment, the mode of operation indicates a sample-based mode of operation, identifying the media sample comprises identifying a sample of a media fragment based on the identification information, and decoding the media sample comprises decoding the identified sample of the media fragment based on the decryption information. According to one embodiment, each signaling message further includes a security properties descriptor indicating the decryption device, and the method further comprises accessing a license server based on information in the security properties descriptor, obtaining a license from the license server, and decrypting the media samples using the license. According to one embodiment, the security properties cor l Ln / eznz / B / YiAi descriptor includes information indicating that a signaling message contains license server URL information, a number of licenses for the media samples, and for each license for a respective media sample, a license type, a length of a URL, and the URL. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions and claims. Before carrying out the DETAILED DESCRIPTION below, it may be beneficial to establish definitions of certain words and phrases used throughout this patent document. The term "couple" and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with each other. The terms "transmit," "receive," and "communicate," as well as their derivatives, encompass both direct and indirect communication. The terms "include" and "comprise," as well as their derivatives, mean inclusion without limitation. The term "or" is inclusive and means "and / or." The phrase "associated with," as well as its derivatives, means to include, be included within, interconnect with, contain, be contained within, connect with or with, couple to or with, be communicable with, cooperate with, intercalate, juxtapose, be in close proximity to, be attached to or with, have, have a property of, have a relationship to or with, or the like.The term controller means any device, system, or part thereof that controls at least one operation. Such a controller may be implemented in hardware or in a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, either locally or remotely. The phrase "at least one of," when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, "at least one of: A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C. In addition, various functions described below may be implemented or supported by one or more computer programs, each of which is formed from computer-readable program code and embodied in a computer-readable medium. The terms application and program refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in suitable computer-readable code. The phrase computer-readable program code includes any type of computer code, including source code, object code, and executable code.The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as read-only memory (ROM), random-access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. Non-transitory computer-readable medium excludes wired, wireless, optical, or other communication links that carry electrical or other transient signals. Non-transitory computer-readable medium includes media on which data can be stored permanently and media on which data can be stored and then overwritten, such as a rewritable optical disc or an erasable memory device. Definitions of certain other words and phrases are provided throughout this patent document. Those skilled in the art should understand that in many, if not most, instances, such definitions apply to past and future uses of those defined words and phrases. Brief Description of the Figures For a more complete understanding of the present invention and its advantages, reference is now made to the following description taken in conjunction with the accompanying figures, in which like reference numerals represent like parts: FIGURE 1 illustrates an example communication system in accordance with one embodiment of this invention. FIGURES 2 and 3 illustrate example electronic devices in accordance with one embodiment of this invention. FIGURE 4 illustrates a block diagram of an example environment architecture for MMT-based DRM operation for ATSC 3.0 in accordance with an embodiment of this invention. FIGURE 5 is a diagram illustrating a hierarchical structure of an ATSC 3.0 receiver protocol stack according to an exemplary embodiment. FIGURE 6 illustrates an exemplary packetization diagram of timed media data transmitted in an out-of-order mode in accordance with this invention. FIGURE 7 illustrates an example of DRM architecture for MMF in accordance with this invention. FIGS. 8A through 8C illustrate an example MPU with cor l Ln / eznz / B / YiAi suggestion tracks in accordance with this invention. FIGS. 9A and 9B illustrate example methods for operating an MMT DRM receiver that may not be connected to the Internet in accordance with this invention. FIGURE 10 illustrates an example method for MMT-based DRM operation for ATSC 3.0 in accordance with this invention. Detailed Description of the Invention FIGS. 1 through 10, described below, and the various embodiments used to describe the principles of the present invention are for illustrative purposes only and should not be construed as limiting the scope of the invention in any way. Those skilled in the art will understand that the principles of the present invention may be implemented in any type of suitably arranged device or system. FIGURE 1 illustrates an example of a communication system 100 in accordance with one embodiment of this invention. The embodiment of the communication system 100 shown in FIGURE 1 is for illustration only. Other embodiments of the communication system 100 may be used without departing from the scope of this invention. The communication system 100 includes a network 102 that facilitates communication between various components in the communication system 100. For example, the network 102 may communicate IP packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, or other information between network addresses. The network 102 includes one or more local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of a global network such as the Internet, or any other communication system(s) at one or more locations. In this example, the network 102 facilitates communications between a server 104 and various client devices 106-116. The client devices 106-116 may be, for example, a smartphone, a tablet, a laptop, a personal computer, a handheld device, a HMD, or the like. The server 104 may represent one or more servers. Each server 104 includes any suitable computing or processing device that can provide computing services for one or more client devices, such as the client devices 106-116. Each server 104 could, for example, include one or more processing devices, one or more memories that store instructions and data, and one or more network interfaces that facilitate communication across the network 102.As described in more detail below, the server 104 may transmit a compressed bit stream to one or more display devices, such as a client device 106-116. In certain embodiments, each server 104 may include an encoder. Each client device 106-116 represents any suitable computing or processing device that interacts with at least one server (such as server 104) or other computing device(s) via network 102. Client devices 106-116 include a desktop computer 106, a mobile telephone or mobile device 108 (such as a smartphone), a PDA 110, a laptop computer 112, a tablet computer 114, and an HMD 116. However, any additional client device could be used in communication system 100. Smartphones represent a class of mobile devices 108 that are handheld devices with mobile operating systems and integrated mobile broadband cellular network connections for voice, short message service (SMS), and Internet data communications. In certain embodiments, any of the client devices 106-116 may include an encoder, a decoder, or both.For example, mobile device 108 may record a video and then encode the video allowing the video to be streamed to one of client devices 106-116. In this example, some client devices 108116 communicate indirectly with the network 102. For example, the mobile device 108 and the PDA 110 communicate through one or more base stations 118, such as cellular base stations or eNodeBs (eNBs). In addition, the laptop computer 108 communicates with the network 102. 112, the tablet 114 and the HMD 116 communicate through one or more wireless access points 120, such as IEEE 802.11 wireless access points. Note that these are for illustration only and that each client device 106-116 could communicate directly with the network 102 or indirectly with the network 102 through any suitable intermediate device or network. In certain embodiments, the server 104 or any client device 106-116 may be used to compress multimedia data, generate a bitstream representing the multimedia data, and transmit the bitstream to another client device such as any client device 106-116. In certain embodiments, any of the client devices 106-114 securely and efficiently transmits information to another device, such as, for example, the server 104. Furthermore, any of the client devices 106-116 may trigger the transmission of information between itself and the server 104. Any of the client devices 106-114 may function as a VR display when connected to a headset via mounts, and operate similarly to the HMD 116. For example, the mobile device 108 when connected to a mount system and worn over a user's eyes may operate similarly to the HMD 116. The mobile device 108 (or any other client device 106-116) may trigger the transmission of information between itself and the server 104. In certain embodiments, any one of the client devices 106-116 or the server 104 may create media data, compress media data, transmit media data, receive media data, render media data, or a combination thereof. For example, the server 104 may then compress media data to generate a bitstream and then transmit the bitstream to one or more of the client devices 106-116. For another example, one of the client devices 106-116 may compress media data to generate a bitstream and then transmit the bitstream to another of the client devices 106-116 or the server 104. Although FIGURE 1 illustrates an example of a communication system 100, various changes may be made to FIGURE 1. For example, communication system 100 could include any number of each component in any suitable arrangement. Generally, computing and communication systems come in a wide variety of configurations, and FIGURE 1 does not limit the scope of this invention to any particular configuration. While FIGURE 1 illustrates an operating environment in which various features described in this patent application may be used, these features could be used in any other suitable system. FIGS. 2 and 3 illustrate exemplary electronic devices in accordance with one embodiment of this invention. In particular, FIG. 2 illustrates an exemplary server 200, and server 200 may represent server 104 in FIG. 1. Server 200 may represent one or more encoders, decoders, local servers, remote servers, clustered computers, and components acting as a single integrated resource pool, a cloud-based server, and the like. Server 200 may be accessed by one or more of client devices 106-116 of FIG. 1 or another server. As shown in FIG. 2, the server 200 includes a bus system 205 that supports communication between at least one processing device (such as a processor 210), at least one storage device 215, at least one communications interface 220, and at least one input / output (I / O) unit 225. The server 200 may represent one or more local servers, one or more compression servers, or one or more encoding servers, such as an encoder. In certain embodiments, the encoder may perform decoding. The processor 210 executes instructions that may be stored in a memory 230. The processor 210 may include any suitable number and type of processors or other devices in any suitable arrangement. Exemplary types of processors 210 include microprocessors, microcontrollers, digital signal processors, field-programmable gate arrays, application-specific integrated circuits, and discrete circuits. In certain embodiments, the processor 210 may encode multimedia data stored within the storage devices 215. Memory 230 and persistent storage 235 are examples of storage devices 215 that represent any structure capable of storing and facilitating retrieval of information (such as data, program code, or other suitable information on a temporary or permanent basis). Memory 230 may represent random access memory or any other suitable volatile or non-volatile storage device(s). Persistent storage 235 may contain one or more components or devices that support long-term data storage, such as read-only memory, a hard drive, flash memory, or an optical disk. The communications interface 220 supports communications with other systems or devices. For example, the communications interface 220 could include a network interface card or a wireless transceiver that facilitates communications across the network 102 of FIGURE 1. The communications interface 220 may support communications over any suitable physical or wireless communication link. For example, the communications interface 220 may transmit a bit stream containing multimedia data to another device such as one of the client devices 106-116. The I / O unit 225 allows for data input and output. For example, the I / O unit 225 may provide a connection for user input via a keyboard, mouse, keypad, touchscreen, or other suitable input device. The I / O unit 225 may also send output to a display, printer, or other suitable output device. Note, however, that the I / O unit 225 may be omitted, such as when I / O interactions with the server 200 occur over a network connection. Note that while FIGURE 2 is described as representative of the server 104 of FIGURE 1, the same or a similar structure could be used on one or more of the various client devices 106-116. For example, a desktop computer 106 or a laptop computer 112 could have the same or similar structure as that shown in FIGURE 2. cor l Ln / eznz / B / YiAi FIGURE 3 illustrates an exemplary electronic device 300, and the electronic device 300 could represent one or more of the client devices 106-116 in FIGURE 1. The electronic device 300 may be a mobile communication device, such as, for example, a mobile station, a subscriber station, a wireless terminal, a desktop computer (similar to the desktop computer 106 of FIGURE 1), a handheld electronic device (similar to the mobile device 108, the PDA 110, the laptop computer 112, the tablet computer 114, or the HMD 116 of FIGURE 1), and the like. In certain embodiments, one or more of the client devices 106-116 of FIGURE 1 may include the same or similar configuration as the electronic device 300. In certain embodiments, the electronic device 300 is an encoder, a decoder, or both.For example, the electronic device 300 may be used with data transfer applications, image or video compression, image or video decompression, encoding, decoding, and media rendering. As shown in FIGURE 3, the electronic device 300 includes an antenna 305, a radio frequency (RF) transceiver 310, a transmit (TX) processing circuit 315, a microphone 320, and a receive (RX) processing circuit 325. The RF transceiver cor l Ln / eznz / e / YiAi 310 may include, for example, an RF transceiver, a BLUETOOTH transceiver, a WI-FI transceiver, a ZIGBEE transceiver, an infrared transceiver, and various other wireless communication signals. The electronic device 300 also includes a speaker 330, a processor 340, an input / output (I / O) interface (IF) 345, an input 350, a display 355, a memory 360, and one or more sensors 365. The memory 360 includes an operating system (OS) 363 and one or more applications 362. The RF transceiver 310 receives, from the antenna 305, an incoming RF signal transmitted from an access point (such as a base station, WI-FI router, or BLUETOOTH device) or other device in the network 102 (such as a WI-FI, BLUETOOTH, cellular, 5G, LTE, LTEA, WiMAX, or any other type of wireless network device). The RF transceiver 310 converts the incoming RF signal to generate an intermediate frequency or baseband signal. The intermediate frequency or baseband signal is sent to the RX processing circuit 325 which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or intermediate frequency signal. The RX processing circuit 325 transmits the processed baseband signal to the speaker 330 (such as for voice data) or to the processor 340 for further processing (such as for web browsing data). cor l Ln / eznz / B / YiAi The TX processing circuit 315 receives analog or digital voice data from the microphone 320 or other baseband data outgoing from the processor 340. The outgoing baseband data may include web data, email, or interactive video game data. The TX processing circuit 315 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or intermediate frequency signal. The RF transceiver 310 receives the outgoing processed baseband or intermediate frequency signal from the TX processing circuit 315 and converts the baseband or intermediate frequency signal into an RF signal that is transmitted via the antenna 305. The processor 340 may include one or more processors or other processing devices. The processor 340 may execute instructions that are stored in the memory 360, such as the OS 361 to control the general operation of the electronic device 300. For example, the processor 340 could control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver 310, the RX processing circuitry 325, and the TX processing circuitry 315 according to well-known principles. The processor 340 may include any suitable number and type of processors or other devices in any suitable arrangement. For example, in certain embodiments, the processor 340 includes at least one microprocessor or microcontroller.Example processor types 340 include microprocessors, microcontrollers, digital signal processors, field-programmable gate arrays, application-specific integrated circuits, and discrete circuits. The processor 340 is also capable of executing other processes and programs resident in the memory 360, such as operations that receive and store data. The processor 340 may move data into or out of the memory 360 as required by a running process. In certain embodiments, the processor 340 is configured to execute one or more applications 362 based on the operating system 361 or in response to signals received from external sources or an operator. For example, the applications 362 may include an encoder, a decoder, a VR or AR application, a camera application (for still images and videos), a video phone calling application, an email client, a social networking client, an SMS messaging client, a virtual assistant, and the like. In certain embodiments, the processor 340 is configured to receive and transmit multimedia content. The processor 340 is also coupled to the I / O interface 345 which provides the electronic cor l Ln / eznz / B / YiAi device 300 the ability to connect to other devices, such as the client devices 106-114. The I / O interface 345 is the communication path between these accessories and the processor 340. The processor 340 is also coupled to the input 350 and the display 355. The operator of the electronic device 300 may use the input 350 to enter data or input into the electronic device 300. The input 350 may be a keyboard, touch screen, mouse, trackball, voice input, or other device capable of acting as a user interface to allow a user to interact with the electronic device 300. For example, the input 350 may include voice recognition processing, thereby allowing a user to enter a voice command. In another example, the input 350 may include a touchpad, a pen (digital) sensor, a key, or an ultrasonic input device. The touchpad may recognize, for example, touch input in at least one scheme, such as a capacitive scheme, a pressure-sensitive scheme, an infrared scheme, or an ultrasonic scheme.Input 350 may be associated with sensor(s) 365 and / or a camera providing additional input to processor 340. In certain embodiments, sensor 365 includes one or more inertial measurement units (IMUs) (such as accelerometers, gyroscopes, and magnetometers), motion sensors, optical sensors, cameras, pressure sensors, heart rate sensors, altimeter, and the like. Input 350 may also include control circuitry. In the capacitive scheme, input 350 may recognize touch or proximity. The display 355 may be a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED), an active matrix OLED (AMOLED) display, or other display capable of displaying text and / or graphics, such as from websites, videos, games, images, and the like. The display 355 may be sized to fit within a HMD. The display 355 may be a singular display or multiple displays capable of creating a stereoscopic display. In certain embodiments, the display 355 is a heads-up display (HUD). The display 355 may display 3D objects, such as a 3D point cloud. Memory 360 is coupled to processor 340. Part of memory 360 may include RAM, and another part of memory 360 may include Flash memory or other ROM. Memory 360 may include persistent storage representing any structure capable of storing and facilitating retrieval of information (such as data, program code, and / or other suitable information). Memory 360 may contain one or more components or devices that support long-term data storage, such as read-only memory, a hard drive, Flash memory, or an optical disc. Memory 360 may also contain multimedia content. Multimedia content may include various types of media such as images, videos, three-dimensional content, VR content, AR content, 3D point clouds, and the like. The electronic device 300 further includes one or more sensors 365 that can measure a physical quantity or detect an activation state of the electronic device 300 and convert measured or detected information into an electrical signal.For example, sensor 365 may include one or more buttons for touch input, a camera, a gesture sensor, IMU sensors (such as a gyroscope or gyro sensor and an accelerometer), an eye tracking sensor, an air pressure sensor, a magnetic sensor or magnetoneter, a grip sensor, a proximity sensor, a color sensor, a biophysical sensor, a temperature / humidity sensor, an illumination sensor, an ultraviolet (UV) sensor, an electromyography (EMG) sensor, an electroencephalogram (EEG), an electrocardiogram (ECG) sensor, an infrared sensor, an ultrasound sensor, an iris sensor, a fingerprint sensor, a color sensor (such as a red, green, blue (RGB) sensor), and the like. Sensor 365 may further include control circuitry for controlling any of the sensors included therein. Although FIGS. 2 and 3 illustrate examples of electronic devices, various changes may be made to FIGS. 2 and 3. For example, various components in FIGS. 2 and 3 could be combined, further subdivided, or omitted, and additional components could be added according to particular needs. As a particular example, processor 340 could be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Furthermore, as is the case with computing and communications, electronic devices and servers may have a wide variety of configurations, and FIGS. 2 and 3 do not limit this invention to any particular electronic device or server. FIGURE 4 illustrates a block diagram of an example environment architecture 400 for MMT-based DRW operation for ATSC 3.0 in accordance with one embodiment of this invention. The embodiment of FIGURE 4 is for illustration only. Other embodiments may be used without departing from the scope of this invention. As shown in FIG. 4, the example environment architecture 400 includes an encoder 410 and a decoder 450 in communication over a network 402. The network 402 may be the same as or similar to the network 102 of FIG. 1. In certain embodiments, the network 402 represents a cloud of computers interconnected by one or more networks, wherein the network is a computing system using clustered computers and components that act as a single set of continuous resources when accessed. Furthermore, in certain embodiments, the network 402 is connected to one or more servers (such as server 104 of FIG. 1, server 200), one or more electronic devices (such as client devices 106-116 of FIG. 1, electronic device 300), the encoder 410, and the decoder 450.Furthermore, in certain embodiments, the network 402 may be connected to an information repository (not shown) containing multimedia content that may be encoded by the encoder 410, decoded by the decoder 450, or rendered and displayed on an electronic device. In certain embodiments, the encoder 410 and decoder 450 may represent the server 104, one of the client devices 106-116 of FIGURE 1, or another suitable device. The encoder 410 and decoder 450 may include internal components similar to the server 200 of FIG. 2 and the electronic device 300 of FIG. 3. In certain embodiments, the encoder 410 and decoder 450 may be a cloud of computers interconnected by one or more networks, each of which is a computing system that uses clustered computers and components to act as a single, continuous set of resources when accessed via the network 402. In some embodiments, a portion of the components included in the encoder 410 or decoder 450 may be included in different devices, such as multiple servers 104 or 200, multiple client devices 106-116, or another combination of different devices.In certain embodiments, the encoder 410 is operatively connected to an electronic device or a server while the decoder 450 is operatively connected to an electronic device. In certain embodiments, the encoder 410 and the decoder 450 are the same device or are operatively connected to the same device. The decoder 450 may include a communication interface and a processor operatively coupled to the communication interface. The communication interface receives at least a portion of a broadcast stream that includes media data comprising media samples. The processor identifies information elements containing digital rights management (DRM) processing information in the broadcast stream, wherein each information element is associated with a respective media sample of the media data. For each information element, the processor also identifies the media sample that is associated with the information element. The processor further identifies, based on the information element, DRM processing information for a media sample. In addition, the processor decodes the media sample based on the DRM processing information. Although FIGURE 4 illustrates examples of an encoder and a decoder, various changes may be made to FIGURE 4. For example, various components in FIGURE 4 could be combined, subdivided, or omitted, and additional components could be added according to particular needs. As a particular example, encoder 410 or decoder 450 could be divided into several components. Furthermore, as is the case with computing and communications, encoders and decoders can come in a wide variety of configurations, and FIGURE 4 does not limit this invention to any particular encoder or decoder. FIGURE 5 is a diagram illustrating a hierarchical structure of an ATSC 3.0 receiver protocol stack 500 according to an exemplary embodiment. ATSC 3.0 services may be delivered using three functional layers, including a physical layer 502, a delivery layer 504, and a service management layer 506. The physical layer 502 may provide mechanisms by which signaling, service advertisement, and IR packet streams are transported across the broadcast physical layer 508 and / or the broadband physical layer 510.The delivery layer 504 provides object transport and object streaming functionality, which is enabled by the MPEG Media Transport Protocol (MMTP) 512 or Real-time Object Delivery Protocol over Unicast (ROUTE) 514, operating in a UDP 516 / IP 518 multicast over the broadcast physical layer 508, and enabled by the HTTP protocol 520 in a TCP 522 / IP 524 unicast over the broadband physical layer 510. The service management layer 506 primarily supports the means for service discovery and acquisition to allow different types of services, such as linear TV and / or HTML5 application service, to be transported by the underlying physical and delivery layers 502. cor l Ln / eznz / B / YiAi Referring to FIGURE 5, a service includes multimedia data 526 and signaling 528 for transferring information necessary to acquire and consume the multimedia data 526 at a receiver. The multimedia data 526 may be encapsulated into a format suitable for transmission prior to transmission. An encapsulation method may follow a media processor unit (MPU) 530 defined in ISO / IEC 23008-1 MPEG Media Transport (MMT) or a DASH segment format defined in ISO / IEC 23009-1 Dynamic Adaptive Streaming over HTTP (DASH) 530. The multimedia data 526 and signaling 528 are packaged according to an application layer protocol. FIGURE 5 illustrates a case where an MMT protocol (MMTP) 512 defined in MMT and a Real-time Object Delivery over Unidirectional Transport (ROUTE) 514 protocol are used as the application layer protocol. In this case, a method is required to report information about an application protocol, over which a service is carried, by a separate method other than the application layer protocol so that the receiver knows over which application layer protocol the service is carried. A service list table (SLT) 532 illustrated in FIG. 5 represents a signaling method and packages information about the service into a table to satisfy the aforementioned purpose. The packaged media data and signaling included in the SLT 532 are transferred to a transmission link layer 534 via a user data protocol (UDP) 516 and an Internet protocol (IP) 518. An example of the transmission link layer 534 includes an ATSC 3.0 link layer protocol (ALP) defined in the ATSC 3.0 standard (hereinafter referred to as 'ATSC 3.0'). The ALP protocol generates an ALP packet using an IP packet as input and transfers the ALP packet to a broadcast physical layer 508. The broadcast physical layer 508 may generate a physical layer frame by processing the ALP packet signal as input, convert the physical layer frame into a radio signal, and transmit the radio signal. In this case, the broadcast physical layer 508 has at least one signal processing path. An example of the signal processing path may include an ATSC 3.0 or second-generation digital terrestrial video broadcasting (DVB-T2) physical layer pipeline (PLP), and one or more services or some of the services may be assigned to the PLP. FIGURE 6 illustrates an exemplary diagram of packetization of timed media data transmitted in an out-of-order mode 600 in accordance with various embodiments of the present invention. Packetization of an MPU containing timed media may be carried out in a mode compatible with the MPU format and / or independent of the MPU format. In MPU format independent mode, the MPU is packaged into data units of equal size (except for the last data unit, the size of which may differ) or a predefined size according to the size of the MPU of the underlying delivery network by using Generic File Delivery (GFD). In other words, MPU format independent mode packetization can only consider the size of the data to be carried in the packet. The type field for the MMTP packet header is set to 0x00 to indicate that the packetization is in format independent mode.In MPU format compatible mode, the packetization procedure considers the boundaries of different data types in MPU to generate packets using MPU mode. The resulting packets carry delivery data units of either MPU metadata 602, movie clip metadata 604, or a motion clip unit (MFU) 606. The resulting packets cannot carry more than two different types of delivery data units (Ln / eznz / B / YiAi). The MPU metadata delivery data unit is assigned DU_type 0x01. The MPU metadata includes a file type (ftyp) frame 608, an MMT processing unit (mmpu) frame 610, the movie frame (moov) 612, and any other frames that apply to the entire MPU.The movie clip metadata delivery data unit 604 consists of the movie clip frame (moof) 614 and a movie data frame header (mdat) 616 (excluding any media data) and is assigned DU_type 0x02. The media data, the MFUs 606 in the mdat 618 of the MPU, are then split into multiple MFU delivery data units 620 in a format-aware manner. This may be done, for example, with the help of the MMT hint track. The MFU may include 1) media data only, 2) media data with a sequence number, and 3) media data with some control information. Each MFU is prepended with the MFU header, which has the syntax and semantics. The MFU header is followed by the MFU media data. Low latency signaling and delivery of digital rights management (DRM) signaling information has not been defined, including an MMT out-of-order delivery mode 600 delivery that enables low latency media delivery and signaling and delivery of DRM information for cor l Ln / eznz / e / YiAi out-of-order delivery mode 600. For out-of-order delivery mode 600, video data is stored in mdat 618 and metadata (e.g., timing data) is stored in moof 614. The data in moof 614 cannot be fully constructed before mdat 618 is completed. The out-of-order delivery mode 600 allows for independent delivery of mdat data units 620 following creation of a specific mdat data unit 620 and delivery of the metadata in the moof 614 after all mdat data units 620 have been delivered. In a certain embodiment, the moof 614 may be transmitted at any time after completion of the moof 614 regardless of the number of mdat data units 620 already transmitted or remaining to be transmitted as long as at least a single mdat data unit 620 is transferred before completion of the moof 614. The DRM information may be stored in the mode 614 and delivered at the end of a transmission order for the out-of-order delivery mode 600. For the low latency mode, the DRM information for decrypting media data should be delivered before or just after each media data is delivered to reduce transmission delay. A sample code included in a linear hash coding (LDC) message is shown below. base_presentation_time_offset coding_dependency_structure_flag if (coding_dependency_structure_flag - - 1) ( period_of_intra_coded_sample for (i=0 ; i <NI;i * t) { sample_composition_time_offset_sign sample_composition_time_offset_value}} The LDC message can provide decoding time and presentation time for a media sample to eliminate the delay in waiting for fragment metadata. The out-of-order delivery delay can only be an MPU duration, and the out-of-order delivery delay with the LDC message can be set to zero. FIGURE 7 illustrates an exemplary DRM architecture 700 for MMT in accordance with this invention. The embodiment of the DRM architecture 700 illustrated in FIGURE 7 is for illustration only. FIGURE 7 does not limit the scope of this invention to any particular implementation of DRM for MMT. I COOKED As shown in FIG. 7, a conceptual model of DRM operation for MMT is depicted when the receiver is not connected to the Internet. The receiver 702 may receive the license information for DRM operation from the offline license server 706 before receiving the service from the streaming server 708. The streaming server 708 may send service and signaling information for DRM operations to the receiver 702, such as an ATSC 3 MMT signaling message containing security_properties_descriptors_LAURL and SI_descriptor. The receiver 702 may include a receiving media player (RMP) 710, a broadcasting application 712, and a content decryption module (CDM) 714. The RMP 710 of the receiver 702 may process signaling information and decode media components. When the media components are encrypted, the content decryption model is used to decrypt the content. To decrypt the media component, the RMP 710 may acquire license information by processing information in the metadata frames and ATSC 3 MMT signaling messages in the MPU and retrieve a license 704 from the local storage 716. The streaming server 708 may submit a streaming application along with the service, then the receiver 702 may execute the media content after retrieval and validation for interactive services. Content protection in MMT is based on the ISO / IEC23001-7 Common Encryption Framework (CENC) for various DRM systems. Proprietary and system-specific signaling information for protection is delivered in two ways, including via MMT signaling messages, and is carried in MPUs in designated metadata frames defined by the ISO Base Media File Format (BMFF). When the service is encrypted, the Service@protected attribute in SLT 532 is present and set to true and ComponentInfo@componentProtectedFlag of at least one component listed in BundleDescriptionMMT must be set to true. For the delivery of DRM-related information to prepare the receiver 702 before content delivery, some information is sent as MMT signaling messages in addition to the ISOBMFF-defined metadata frames of the MPUs 532. The security_properties_descriptors_LAURL shown below is carried by the MMT ATSC 3.0 signaling message, mmt atsc3 message(), and contains information for CENC and standardized license acquisition information. The signaling message could be represented by the entries in Table 1. cor l Ln / eznz / B / YiAi Table 1. Signaling message cor l Ln / eznz / B / YiAi Sintaxis No. de bits Formato sccurity properties descriptor I.Al'RI.t i ¡ descriptor tag 16 uinisht descriptor length 16 uinishf number of assets X uintshf for (i 0; i- number of assets; i· · 1 ¡ asset id length >2 ninish f for (¡ 0: j· asset id length; j- · t ; asset id Inte X uinisht schcine codc presen! 1 hslhf defanlt Kll) picscnt 1 bslbf 1 ícense i uto picscnt 1 bslbt resen cd s •00000' iftschnie codc presentí ¡ scheinc codc 4‘X uinisbf » ift defanlt Kll) presentí ¡ defanlt Kll) length X uinisbt for (j 0; j- dctault Kll) length; j- -) I defanlt Kll) bxte X uinisbf > tu r\ c N a c 1 i l i f (1 ice n se_i n tb_pre se n t) ! 8 u imsbf nuinher of 1 icense inIb for (i=0; i<number_of_liccnse_info; i · · ) ¡ liccnsetypc 8 uimsbf 1 A (ÍRI. lengtli 8 uimsbf for (j^O; j<URL length; 8 uimsbf j ·') ! l.A l;RI. byte 1 1 1 1 SI descriptor!) var Subclausc 10.5.5 of ♦ 1 23008-1 cari The descriptor_tag field represents a 16-bit unsigned integer field that can have an OxOOOC value, identifying this descriptor as security_properties_descriptor(). The descripcor_length field represents a 16-bit unsigned integer field that can specify a length (in bytes) from immediately following this field to the end of this descriptor. The number_of_assets field represents an 8-bit unsigned integer field that can specify the number of DRM-protected assets described by this descriptor. Asset_id_length represents a 32-bit unsigned integer field that can specify the length in bytes of a DRM-protected asset ID. The asset_id_byte field represents an 8-bit unsigned integer field that can contain one byte of a DRM-protected asset ID.The scheme_code_present flag represents a 1-bit Boolean flag that may indicate that a scheme_code element is present when set to '1', and the flag may indicate that a scheme_code element is not present and that an asset is protected by a CENC scheme when set to '0'. The default_KID_present flag represents a 1-bit Boolean flag that may indicate, when set to '1', that the default KID for this DRM-protected asset is present, and when set to '0', may indicate that the default KID for this DRM-protected asset is present. The scheme_code field represents a 32-bit unsigned integer field that may specify a 4-character code for a protection scheme.The default_KID_length field represents a 1-bit unsigned integer field that may specify the length in bytes of the default KID for this DRM-protected resource, where the value of this field may be set to 16. The default KID byte field represents an 8-bit unsigned integer field that may contain one byte of a default KID. SI_descriptor() represents a descriptor whose syntax and semantics may be as defined in subclause 10.5.5 of ISO / IEC 23008-1. The License info present flag represents a 1-bit boolean flag that will indicate, when set to '1', that URL information for ATSC 702 receivers to directly access the 706 license server. The number_of_license_info field represents an 8-bit unsigned integer field that may specify the amount of license information signaled for the current asset.The license_type field represents an 8-bit unsigned integer field that may specify an applicable license type 704 as specified in Table 2. LA_URL_length represents an 8-bit unsigned integer field that may specify the length in bytes of the URL for the license acquisition. The LA_URL_byte field represents an 8-bit unsigned integer field that may contain one byte of the URL for the license acquisition. The code values ​​for the license_type field can be represented in the following Table 2. cor l Ln / eznz / B / YiAi Table 2. Code values ​​for license_type Industry sinnific? id tvne 0x00 0x01 Reserved for ATSC license-1.0, Direct license acquisition by ATSC 3.0 receivers and the URI scheme is a valid endpoint for access. 0x02 groupLicense-1.0, Provides a path for a group-based license. The ATSC 3.0 receiver may need to parse the URI specifically for that DRM system to access any local group licenses. 0x03 0x04- OxFF contentld-1.0, Provides information for the DRM-specific content identifier used to generate KIDs. The URI must be parsed to extract relevant information using RESE-based notation. Reserved for industry. See ATSC Code Point Registry The CENC value can be used for the scheme_code field of security_properties_descriptors_LAURL and the urn:mpeg:cene:2013 extension namespace is assumed. The default KID signaled in security_properties_descriptors_LAURL for each component may be sufficient for the receiver 702 to acquire a DRM license 704 or to identify a previously acquired license 704 that can be used to decrypt a component. Since the default KID is signaled by security_properties_descriptors_LAURL for each component, the default_KID allows a player to determine if a new 704 license needs to be acquired for each component by comparing their default KIDs to each other and to the default_KIDs of stored 704 licenses. A player can simply compare these KID strings and determine what unique 704 licenses are needed without interpreting the DRM-specific license information. Each DRM system may define a Protection System Specific Header (pssh) frame for use with its registered SystemID and is nominally stored in moov 612 and may additionally be present in moof 614. The frame information may be copied to the SI_descriptor of security_properties_descriptors_LAURL carried in the ATSC 3.0 MMT signaling message by the streaming server. Information for accessing a server for the ATSC to receive in order to acquire a license 704, the license type 704, and the URL for accessing the license server 706 for license acquisition may be added to the security_properties_descriptors_LAURL carried in the ATSC 3.0 MMT signaling message by the streaming server. More than one of the following methods may be indicated for acquiring a valid license. License-1.0 represents a direct license acquisition 704 by ATSC 3.0 receivers 702 and the URI scheme is a valid endpoint for access. The groupLicense-1.0 may provide a path for a group-based license cor l Ln / eznz / B / YiAi 704. The ATSC 3.0 receiver 702 may need to parse the DRM-specific URI to access any local group licenses 704. Contentld-l.0 may provide information for the DRM-specific content identifier used to generate KIDs. The URI must be parsed to extract relevant information using REST-based notation. When an out-of-order delivery mode 600 is used, i.e., the mdat media data is delivered before other frames are delivered, encryption metadata may be delivered as a signaling message so that the ATSC 3.0 receiver 702 can start decrypting the media data immediately without any additional delay. The receiver 702 uses the signaling message to acquire information about the number of bytes of clear data and protected data in each subsample of each sample, and the count of encrypted blocks and unencrypted blocks in the protection pattern for each group of samples before it receives moof 614 or moov 612. The low_delay_decryption_information_descriptor() is carried by the ATSC 3.0 MMT signaling message, a mmt_atsc3_message(), which contains encryption metadata for a specific sample. The descriptor uses an MPU_sequence_number field, a movie_fragment_sequence_number field, and a sample_number field to identify a specific sample to which the descriptor information applies. cor l Ln / eznz / B / YiAi This message supports two modes of operation, MPU-based mode of operation and sample-based mode of operation, distinguished by an operation mode field. In MPU-based mode of operation, a descriptor can contain information about all samples on an MPU with a single descriptor. In this mode, a single descriptor provides the sample group description structures CencSampleEncryptionlnformationGroupEntry for all sample groups defined on the MPU. In addition, a single descriptor also provides a list of samples associated with each sample group and CencSampleAuxiliaryDataFormat for all samples in an MPU-based mode of operation. In sample-based mode of operation, a descriptor provides information about a single sample and a corresponding SampleEncryptionBox associated with that sample.Additionally, the descriptor in this mode carries CencSampleEncryptionlnformationGroupEntry sample group description structures for a sample group with which this descriptor is associated, whenever necessary. If the sample group description structure has already been delivered for the same sample group, the CencSampleEncryptionlnformationGroupEntry sample group description structures may be omitted from being included in the descriptor. The ATSC 3.0 MMT signaling message cor l Ln / eznz / B / YiAi may be represented by the entries in Table 3. Table 3. ATSC 3.0 MMT signaling message cor l Ln / eznz / B / YiAi. Syntax No. of bits Formato lm\ and in!<«nn;Uion dv-*ctiph'H l ! descíipt<'f t..'1 1 6 mti. J'l life'.u iplor Icn-'th Ib ii i tr. >br X*Pl scgucr.ce nuiiilxT ; » m te sbf ojKration n'.rdc uiTr.sbt s.tinp\· LT>*up into pr¿s <r( 1 UltEshr rccncd 1 11 i: 1t (opci.Eion rh*du 1 i ¡ ftx»\ ic Ir.t'.-r’icrJ xcqiiciw rnrrhcr uin.sl»! sjtEp’c iiuiii bcr s uitr.sbf %.ιπ;ρ!ς t’tvup η..ηιΙκτ i! ( > ,nrplc group prv^vnt 1 > ¡ X ui te\b? d / V ot b>'\ h»r < k 0 k· In N-· ot xc i .· I\<\ k - - ) ; 52 uiti.U't .ο;· hn -'Me X uinixh? ot svnv box L'f t ti i:. n -xi / v *>! SVIK here. r · · i ¡ 52 111 TE %bt µ.·' *. box b\:c X u ι ¡τι sbf if < o|vr j;ion ni<>d< 2 ι ¡ run.bcf o! _iiu>\ iv_t: jgnivsr.s bu »i ·Λ mi ti! be r *H niodc 1 r.iericrts. i ~ ¡ X ύπτιοί'! movic fragmcnt scquence number 32 uimsbf nuinbei_of_samplc_uroups 8 uimsbf tor(j 0: j--»numbcr_ot_samplc_groups:j--) 1 sizc of scig box 32 uimsbf torlk 0: k'bytcs ot scig box; k--> ¡ seig box byte 8 uimsbf number ot ^ampies 8 uimsbf tor Ι·'ηιιηιΙκ'Γ_οΙ_χίΐιιιρ!υχ, 1-—) ¡ samplc_ number 8 uimsbf size ot' aux info 32 uimsbf fot (if 0; m <sizc_of_aux_info. ni**) ¡ aux info byte 8 uimxbf The descriptor_tag field represents an integer field A 16-bit unsigned CQC I that may have the value OxOOOE, identifying this descriptor as low_delay_decryption_descriptor(). The descriptor length field represents a 16-bit unsigned integer field that may specify the length (in bytes) from immediately following this field to the end of this descriptor. The MPU sequence number field represents a 32-bit unsigned integer field that may specify the sequence number of the MPU to which this descriptor applies. The operation_mode field represents a 3-bit unsigned integer field that may specify the mode of operation for which this descriptor is used as specified in Table 4. Table 4. Code values ​​for operation_mode Meaning of license type 0 Reserved for ATSC sample-based mode of operation. The descriptor carries decoding information for the sample identified by the combination of MPU sequence number, movie fragment sequence number, and sample number. cor l Ln / eznz / B / YiAi MPU-based mode of operation. The descriptor carries decryption information for all MPU samples identified by MPUsequenceNumber. -7 Reserved for industry. See ATSC Code Point Registry The sample_group_info_present flag represents a 1-bit boolean flag that can indicate whether the CencSampleEncryptionlnformationGroupEntry is carried when set to '1' or not when set to '0' . The movie_fragment_sequence_number field represents a 32-bit unsigned integer field that can specify the sequence number of the movie fragment where the information is applied. The sample_number field represents a 32-bit unsigned integer field that can specify a sequence number of a sample within a movie fragment where the information is applied. The size_of_seig_box field represents a 32-bit unsigned integer field that can specify a size of a CencSampleEncryptionlnformationGroupEntry box for a sample group.When operation_mode is equal to '1', the size_of_seig_box field may indicate a size of the CencSampleEncryptionlnformationGroupEntry box for a sample group with which this descriptor is associated. When operation_mode is equal to '2', the size_of_seig_box field may indicate a size of the CencSampleEncryptionlnformationGroupEntry box for a sample group whose group_description_index is equal to j. The seig_box_byte field represents an 8-bit unsigned integer field that can contain the kth byte of the CencSampleEncryptionlnformationGroupEntry box for a sample group. When operation_mode is equal to '1', the seig_box_byte field can carry one kth byte of the CencSampleEncryptionlnformationGroupEntry box for a sample group with which this descriptor is associated.When operation_mode is equal to '2', the seig_box_byte field can carry a kth byte of the SampleEncryptionInformationGroupEntry frame for a sample group whose group_description_index is equal to j. The size_of_senc_box field represents a 32-bit unsigned integer field that can specify the size of the SampleEncryptionBox for the sample with which this descriptor is associated. The senc_box_byte field represents an 8-bit unsigned integer field that can hold an nth byte of a SampleEncryptionBox frame for the sample with which this descriptor is associated. The number_of_movie_fragments field represents an 8-bit unsigned integer field that can specify the number of movie fragments contained in an MPU to which this descriptor is applied.The number of sample groups field represents an 8-bit unsigned integer field that can specify a number of sample groups defined in the movie fragment to which the information applies in the current loop. number_of_sampies represents an 8-bit unsigned integer field that can specify the number of samples belonging to the sample group whose group_description_index is equal to j . The size_of_aux_info field represents a 32-bit unsigned integer field that can specify a size of the CencSampleAuxiliaryDataFormat data structure applied to the currently described sample. The aux_info_byte field represents an 8-bit unsigned integer field that can contain an mth byte of CencSampleAuxiliaryDataFormat. Although FIGURE 7 illustrates an example DRM 700 architecture for MMT, various changes may be made to FIGURE 7. For example, the number and location of various components of the DRM 700 architecture may vary as needed or desired. Furthermore, the DRM 700 architecture may be used in any other suitable MMT process and is not limited to the specific processes described above. FIGS. 8A-8C illustrate an exemplary MPU 800 with hint tracks 802 in accordance with this invention. In particular, FIG. 8A illustrates an exemplary MPU 800 with hint tracks 802, FIG. 8B illustrates an exemplary hint track 802, and FIG. 8C illustrates an exemplary media track 804. The embodiments of the exemplary MPU 800 illustrated in FIGS. 8A-80 are for illustration only. FIGS. 8A-80 do not limit the scope of this invention to any particular implementation of an MPU. The MPU 800 may correspond to the MPU shown in FIG. As shown in FIGS. 8A-80, an MPU 800 may include at least one hint track 802 before the respective media tracks 804, the media tracks 804, and a moof 806 inducing a hint track header 808 and a media track header 810. A sample 802 may be created for each media sample 804. The hint sample 802 may carry decryption information, typically stored in moof 806, corresponding to the respective media sample. In this manner, moof information for decrypting a respective media sample may be generated and transmitted before the entire moof 806 is completed. The moof 806 may correspond to the moof 614 shown in FIG. In case an out-of-order delivery mode 600 is used, i.e. the media data of the 'mdat' frame is delivered before other frames are delivered, the metadata needed for decrypting that media data is delivered as hint samples 802 to reduce the number of signaling messages to be processed. The sender copies information for decrypting the media samples 804 into LowDelayProcessinglnfo for each hint sample 802 of the SampleEncryptionBox of the corresponding media samples 804. The semantics of each LowDelayProcessinglnfo field can be identical to those of SampleEncryptionBox fields with an identical name. Because LowDelayProcessinglnfo can only contain information for a single sample, a field over a number of SampleEncryptionBox samples is not copied. The sender can deliver that LowDelayProcessinglnfo along with media samples 804. Receiver 702 may use that LowDelayProcessinglnfo instead of SampleEncryptionBox to decrypt a media sample 804 without waiting for moof 806 or moov 612 containing media samples to be delivered. SampleEncryptionBox. Note that a cor l Ln / eznz / B / YiAi The full SampleEncryptionBox corresponding to the 804 media samples of a movie fragment is not replaced by LowDelayProcessinglnfo and is delivered as part of moof 806 regardless of the use of LowDelayProcessinglnfo. The 'mtha' sample entry type is used for MMT 802 hint tracks in ATSC 3.0. This sample entry type includes version indication and reserved bits for introducing new flags for future extensions. A sample syntax for the 802 hint track can be represented as follows: cor iin / eznz / B / YiAi aligncd(8) class MMTHintATSC3SampleEntiy() cxtends SainplcEntryCmtha’) ¡ unsigned int( 16) hinitrackvcrsion = 1; unsigned int( 16) highestcoinpatibleversion I; unsigned int( 1) has nifiis flag; unsigned int( 1) is timcd; unsigned int( 1) deeryption info flag; unsigned int( 13) reserved; i f Where the hinttrackversion field may specify a version of this hint track. The current version is 1 . The highestcompatibleversion field may specify an oldest version with which a hint track is backward compatible. The has_mfus_flag field may represent a flag indicating whether the MPUs 800 are fragmented into MFUs. If this flag is set to FALSE, the hint track 802 applies to the entire MPU 800, i.e., each hint track fragment will have a single sample. Otherwise, each hint sample 802 applies to a corresponding MFU. The is_timed field may indicate whether the multimedia data hinted by this track is timed or untimed data. The low delay decryption info flag field may indicate whether low-delay decryption information of the multimedia data hinted by this track is included in the hint samples.If this field's value is set to '1', then the information is included in the samples. If this field's value is set to '0', then the information is not included in the samples. A sample structure of an MMT hint track for ATSC 3.0 can vary according to a value of the hinttrackversion field set in the sample input box. Based on the value of the hinttrackversion field, the values ​​of the different flag sets set by the sample input box are evaluated, and an additional data structure is included at the end of the hint sample. The hinttrackversion field can be represented by the following syntax: Ln / eznz / B / YiAi. COCI alignedí 8 > elass MMTHSainplcATSC3(liinttraekversion) < unsigned int(32) scquence nuinber; if (istimcd) 1 signcd int(8) bringkrefindex; unsigned int(32) niovicfragnicnt scquencc number unsigned inl(32) sainplenuinber; unsigncd int(8) priority; unsigned int(8) dependeney counter; unsigncd int(32) offset; unsigned int(32) lengtli; } el se | unsigned int( 16) iteni lL); I if(hinttraekversion — l)| if(low delay dccryption info flag)¡ unsigned int(24) flags; L owDelay Dccryption I n fo() Wherein the hinttrackversion field may contain a value set by the sample entry to which this sample belongs. The sequence number field represents an integer that may indicate a sequence order of this MFU within the MPU 800. Discontinuity of sequence numbers within an MPU 800 is allowed to indicate that certain MFUs (whose sequence number was not in the sequence) were not processed after packetization by the MPU 800. Examples of MFU processing are delivery and caching by the underlying network entity. The movie fragment sequence number field represents a sequence number of the movie fragment to which the media data of this MFU belongs (see ISO / IEC 1449612:2015, 8.8.5). The movie_fragment_sequence_number field on an MPU 800 may start with 1 for the first movie fragment on the MPU 800 and may increment by 1 for each subsequent movie fragment on that MPU 800.The trackrefíndex field represents an ID of a media track from which the MFU data is extracted. The samplenumber field represents a number of the sample from which this MFU is extracted. The sample number n points to the nth sample of the accumulated samples of the current movie clip. The sample number of the first sample of the movie clip is set to 1 (see ISO / IEC 14496-12:2015, 8.8.8). The priority field may indicate a priority of an MFU with respect to other MFUs within an MPU 800. The dependency counter field may indicate a number of MFUs whose decoding depends on this MFU. The value of this field is equal to a number of subsequent MFUs in a sequence number field order that may not be decoded correctly without this MFU. For example, if the value of this field is equal to n, subsequent MFUs may not be decoded correctly without this MFU.The offset field represents an offset in the media data contained in an MFU. The offset base is the beginning of a frame containing mdat. The MFU can be positioned at a position indicating the offset. The length field represents a length of data corresponding to an MFU in bytes. The item ID field represents, for untimed media data, an ID of an item contained in this MFU. The hinttrackversion field can be a version of a hint track indicated by a sample entry of a track. The flags field can carry the same value as a flags field of the SampleEncryptionBox to which this sample belongs. The low_delay_decryption_info_flag field can contain a value set by a sample entry to which this sample belongs. Below is an example syntax for low-delay decryption information. cor l Ln / eznz / B / YiAi aligned(8) elass LowDelayDecrypticnlnfb() f < unsigncd int(Per Samplc IV Size*8) InitializationVector; ifíflags & 0x000002) ft unsigncd int( 16) subsamplc count: I unsigncd int( 16) DytcsOfClcarData; unsigncd int(32) BylesOíProlcclcdDala; ! [ subsamplc count ] I COOKED Where the InitializationVector field may be the same as the semantics of the InitializationVector field of SampleEncryptionBox in ISO / IEC 23001-7. The InitializationVector field may carry the same value as the InitializationVector field of SampleEncryptionBox corresponding to the same sample. The subsample_count value may be the same as the semantics of the subsample_count field of SampleEncryptionBox in ISO / IEC 23001-7. The subsample count field may carry the same value as the subsample_count field of SampleEncryptionBox corresponding to the same sample. The BytesOfClearData field may be the same as the semantics of the BytesOfClearData field of SampleEncryptionBox in ISO / IEC 23001-7. The BytesOfClearData field can have the same value as the BytesOfClearData field of the corresponding SampleEncryptionBox for the same sample. The BytesOfProtectedData field can have the same semantics as the BytesOfClearData field of the SampleEncryptionBox in ISO / IEC 23001-7. The BytesOfProtectedData field can have the same value as the BytesOfProtectedData field of the corresponding SampleEncryptionBox for the same sample. Since 802 hint samples may not be independent media but an integral part of an MPU 800, 802 hint samples must be delivered along with the media data they are describing, which means they must be delivered via MMTP packets whose package_id field value is the same as that of the MMTP packet delivering the media data they are describing. An MPU 800 is delivered with MMTP packets whose packet_id field in the MMTP packet header is the same. When an MPU 800 is delivered, the MPU Fragment Type, FT, field in the MMTP payload header is used to distinguish the data types of an MPU 800. To differentiate packets containing hint sample data from packets containing media data, a new fragment type value is defined for the hint sample cor l Ln / eznz / B / YiAi as shown in Table 5. Table 5. Data type and data unit definition FT Description Contents 0 MPU Metadata contains the ftyp, nunpu, moov, and meta frames, as well as any additional frames that appear in between. 1 Movie Clip Metadata contains the moof frame and the mdat frame, excluding all media data within the mdat frame but including any auxiliary sample information fragments. 2 MFC contains a timed media data sample or subsample, or an untimed media data element. 3 MMT Hint Sample for ATSC 3 contains an MMT Hint Sample data sample for ATSC type 3 that describes the media data delivered by MMT packets with the same packetid. 4- 15 Reserved for private use reserved The DU header for timed media is used for suggestion samples. The value of the DU header fields for the suggestion sample is set to the same value as the DU header for the media sample described in that suggestion sample, except for the offset field. An example structure of a fragment of an MPU 800 for low-latency delivery out of mode is shown in FIG. The MPU 800 contains two tracks, a media track for media data and a hint track for hint data containing hint samples 802 on top of those media samples 804. For low-latency delivery and processing, a sample location is arranged such that the media sample 804 is directly preceded by the corresponding hint sample. The composition timestamp of a hint sample 802 is set to the same value as the corresponding media sample. An example structure of MMTP packets delivered by an MPU 800 including the MMT hint track 802 for ATSC 3.0 is shown in FIGS. 8B and 8C. The media data 812 and hint data 814 are delivered via separate MMTP packets. The value of the package id field of MMTP packets containing media data 812 and hint data is set to the same value since they are parts of the same MPU 800. For MMTP packets containing media data 812, the value of the FT field 816 of the payload header 818 may be set to 2, and for MMTP packets containing hint data 814, the value of the FT field 816 of the payload header 818 may be set to 3. Both the media data 812 and hint data 814 may use the DU header 820 for a timed MPU 800.The value of the DU header fields 820 for hint data 814 may be exactly the same as a value of the same cor l Ln / eznz / e / YiAi fields for video data it describes, except for the offset field. To reduce processing delay by clients, the MMTP packet containing hint data 814 directly precedes packets containing media data 812 that are described by that hint data 814. Although FIGS. 8A-80 illustrate an MPU 800 with suggestion tracks 802, various changes may be made to FIGS. 8A-80. For example, the number and location of various components of the MPU 800, suggestion track 802, and media track 804 may vary as necessary or desired. Furthermore, the MPU 800, suggestion track 802, and media track 804 may be used in any other suitable MMT process and are not limited to the specific processes described above. Below is an example Receiver operation illustrating the processing of 704-encrypted content locally on a Receiver that is not connected to the Internet. A user selects a Service with encrypted audio and video. If a Broadcast Application is also present in the Service definition, the Receiver receives and executes it once the packet containing it has been retrieved and validated. FIGS. 9A and 9B illustrate example methods 900, 901 for operating an MMT DRM receiver 702 that may not be connected to the Internet in accordance with this invention. For ease of explanation, the methods 900, 901 of FIGS. 9A and 9B are described as being carried out using the receiver 702 of FIG. However, the methods 900, 901 may be used with any other suitable system and any other suitable receiver. As shown in FIGS. 9A and 9B, the receiver 702 may determine whether a service@protected value of the SLT 532 is set to true in step 902. The RMP 710 may set rmpPlaybackStateChange to -1. If the service@protected value of the SLT is not set to true, the method 900 terminates. The receiver 702 may determine whether any Componentinfo@componentProtectedFlag value of USBD is set to true in step 904. When the Service@protected attribute in SLT 532 is present and set to true and the Componentinfo@componentProtectedFlag of at least one of the components listed in BundleDescriptionMMT is set to true, then the RMP 710 may discover that the service is encrypted and may set rmpPlaybackStateChange to 3. The receiver 702 may parse an mmt_atsc3_message() containing the security_properties_descriptors_LAURL descriptor in step 906. The RMP 710 may parse the MMT ATSC 3.0 signaling message (cor l Ln / eznz / B / YiAi mmt atsc3 message), containing the security_properties_descriptors_LAURL to discover if a DRM system ID that the RMP 710 supports is listed. The receiver 702 may determine if a system ID is found in step 908. For each component, the DRM system ID may be known from the value of the system id field of the SI descriptor whose asset id matches the value of the ComponentInfo@componentId attribute of BundleDescriptionMMT or the MMT asset ID of the MP table. If one is found, processing continues. The RMP 710 may initiate the CDM 714 relevant to the given DRM system ID. If neither of the componentinfo@componentprotectedflag values ​​of the USBD are set to true, the method 900 terminates with an error. The receiver 702 may determine if a license key is available on the CDM 714 in step 910. The CDM 714 in the receiver 702 associated with the DRM system ID may check if the license key required to decrypt the video and audio is already in storage. In this example, the CDM 714 may determine that no pre-existing license 704 is available for this content and prepares a license request for the key. The CDM 714 notifies the RMP 710 that a key is required to cor l Ln / eznz / B / YiAi KID1 and KID2. If a group license 704 is available in CDM 714, method 900 skips to step 914. As shown in FIGURE 9A, the receiver 702 may determine if a groupLicense-1.0 is available in step 912. The RMP 710 may detect that a license type 704 equal to groupLicense-1.0 is available in the license_type field of the security properties descriptors LAURL contained in the ATSC 3.0 MMT signaling message and may recognize that a license 704 may be retrieved locally by the receiver 702. When the groupLicense-1.0 is not available, the method 900 terminates with an error. As shown in FIGURE 9B, the broadcast server and receiver 702 may assume that license type 704 groupLicense-1.0 is used. The server may then indicate whether at least one of the service components is encrypted via the Service@protected attribute in SLT 532 and Componentlnfo@componentProtectedFlag. The broadcast server may also signal an SI_descriptor in an asset descriptor loop to obtain DRM information. The receiver 702 may identify a DRM system ID directly from the SI descriptor in the MP table and use the identified DRM system ID to retrieve license information from the license 704 in the local storage 716. In this embodiment, step 912 is skipped or omitted. cor l Ln / eznz / B / YiAi The receiver 702 may retrieve a license key or license 704 from local storage 716 in step 914. The RMP 710 may extract a license server URL value 706 from the LA URL byte fields of security_properties_descriptors_LAURL contained in the ATSC 3.0 MMT signaling message. The RMP 710 may locate the license 704 locally. This process involves no user interaction. The RMP 710 may issue the license 704 to the CDM 714 for each of the KIDs. The receiver 702 may decrypt the component in step 916. The CDM 714 may receive the license 704, save the license 704, and use the license 704 to derive a key needed to decrypt the content. The receiver may use the key to decrypt the component. Although FIGS. 9A and 9B illustrate examples of the method 900, 901 for operating a MMT DRM receiver 702 that may not be connected to the Internet, various changes may be made to FIGS. 9A and 9B. For example, although shown as a series of steps, various steps in FIGS. 9A and 9B may overlap, occur in parallel, or occur any number of times. FIGURE 10 illustrates an exemplary method 1000 for MMT-based DRM operation for ATSC 3.0 in accordance with this invention. For ease of explanation, the method 1000 of FIGURE 10 is described as being carried out using the Ln / eznz / B / YiAi receiver 702 of FIGURE 7. However, the method 1000 may be used with any other suitable system and any other suitable receiver. As shown in FIGURE 10, receiver 702 may receive a portion of a transmission stream that includes media data comprising a media sample at step 1002. The portion of the transmission stream may include receiving a signaling message, a hint track, and one or more media samples corresponding to the media data. Receiver 702 may identify one or more information elements in the broadcast stream in step 1004. The information element may be included in a signaling message or in a time-interlaced sequence of hint tracks and media tracks. For the time-interlaced sequence, each hint track carries decryption information for a following media track. The information element is associated with a respective media sample of the media data. The signaling message may be an mmt_atsc3_message field. The signaling message includes a decryption information descriptor, such as a low_delay_decrytpion_information_descriptor field. The information descriptor may include an indication of a mode of operation, decryption information, and identification information. The mode of operation may be an operation_mode field. The operation mode may indicate a sample-based operation mode or an MPU-based operation mode. The identification information may identify a sample of a media fragment when in the sample-based operation mode. The media fragment may be identified by a combination of the MPU sequence number field, the movie fragment sequence number field, and the sample number field. The identification information may identify an MPU 800 when in the MPU-based operation mode.The MPU 800 can be identified by the MPU_sequence_number field. The receiver 702 may identify a media sample from the media data in step 1006. One or more media samples may be identified from the media data associated with the DRM processing information. The one or more media samples may be received after receiving the information element. For sample-based mode of operation, a sample of a media fragment can be identified based on the identification information. For MPU-based mode of operation, samples of an MPU 800 can be identified based on the identification information. The receiver 702 may identify DRM processing information for a media sample based on the information element in step 1008. When a signaling message indicates an out-of-order delivery mode 600 and the moof 806 is received after the media data, the received moof 806 is associated with the media data received before the moof 806. When a hint track indicates an out-of-order delivery mode 600, decryption information for each media sample is received in a hint track before the media sample. However, the decryption information is divided into a number of hint tracks equal to the number of media samples. The receiver 702 may decode the media sample at step 1010. The receiver 702 may decode the media sample based on the DRM processing information. When a signaling message is used, the moof 806 is received after the media sample, and the decryption information in the moof 806 is used to decrypt the media sample. When a hint track is used, the decryption information for decoding a media sample is received in a track sample associated with the media sample. In the sample-based mode of operation, the identified sample of the media fragment may be decoded based on the decryption information. In the MPU-based mode of operation, the identified samples from the Ln / eznz / B / YiAi of the MPU 800 may be decoded based on the decryption information. Although FIGURE 10 illustrates an example of a method 1000 for MMT-based DRM operation for ATSC 3.0, various changes may be made to FIGURE 10. For example, although shown as a series of steps, various steps in FIGURE 10 may overlap, occur in parallel, or occur any number of times. Although the present invention has been described in exemplary embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present invention encompass those changes and modifications that fall within the scope of the appended claims. Nothing in the description in this application should be construed as implying that any particular element, step, or function is an essential element that should be included within the scope of the claims. The scope of the patented subject matter is defined by the claims. It is noted that in relation to this date, the best method known to the applicant to put the aforementioned invention into practice is the one that is clear from the present description of the invention.

Claims

1. A decoding device comprising: a communication interface configured to receive at least a portion of a broadcast stream including media data comprising media samples; and a processor operatively coupled to the communication interface, the processor configured to: identify information elements containing digital rights management (DRM) processing information in the broadcast stream, each information element being associated with a respective media sample of the media data; for each information element: identify the media sample that is associated with the information element; identify, based on the information element, DRM processing information for that media sample; and decode the media sample based on the DRM processing information.

2. The decoding device according to claim 1, characterized in that, to identify the information elements in the broadcast stream, the processor is further configured to identify suggestion samples in a time-interlaced sequence of the suggestion samples and the media samples.

3. The decoding device according to claim 2, characterized in that each of the suggestion samples carries decryption information for its respective media sample.

4. The decoding device according to claim 3, characterized in that each of the suggestion samples directly precedes its respective media sample.

5. The decoding device according to claim 1, characterized in that, to identify the information elements in the broadcast stream, the processor is further configured to identify signaling messages received before the media samples.

6. The decoding device according to claim 5, characterized in that each signaling message includes an indication of an operation mode, decryption information, and identification information of its respective media sample.

7. The decoding device according to claim 6, characterized in that: the operation mode indicates a sample-based operation mode, to identify a media sample, the processor is further configured to identify a sample of a media fragment based on the identification information, and to decode a media sample, the processor is further configured to decode the identified sample of the media fragment based on the decryption information.

8. The decryption device according to claim 5, characterized in that: each signaling message further includes a security property descriptor indicating the decryption device, and the processor is further configured to: access a license server based on the information in the security property descriptor, obtain a license from the license server, and decrypt the media samples using the license.

9. The decoding device according to claim 8, characterized in that the security property descriptor includes: information indicating that a signaling message contains URL information of the license server, a number of licenses for the media samples, and for each license for a respective media sample, a type of the license, a length of a URL and the URL.

10. A method for a set-top box device, comprising: receiving, using a communication interface of the set-top box device, at least a portion of a broadcast stream including media data comprising media samples; identifying, using a processor of the set-top box device operatively coupled to the communication interface, information elements containing digital rights management (DRM) processing information in the broadcast stream, wherein each information element is associated with a respective media sample of the media data; for each information element: identifying, using the processor, the media sample that is associated with the information element; identifying, based on the information element, DRM processing information for that media sample;and decoding, using the processor, a media sample based on the DRM processing information.; 11. The method of claim 10, wherein identifying the information elements in the broadcast stream comprises identifying suggestion samples in a time-interleaved sequence of the suggestion samples and the media samples.

12. The method according to claim 11, characterized in that each of the suggestion samples carries decryption information for its respective media sample.

13. The method according to claim 12, characterized in that each of the suggestion samples directly precedes its respective media sample.

14. The method of claim 10, wherein, to identify the information elements in the broadcast stream, the processor is further configured to identify cor l Ln / eznz / B / YiAi signaling messages received before the media samples.

15. The method according to claim 14, characterized in that each signaling message includes an indication of an operation mode, decryption information, and identification information of its respective media sample.

Images