EP3791598A1 - Broadcast delivered hls system - Google Patents
Broadcast delivered hls systemInfo
- Publication number
- EP3791598A1 EP3791598A1 EP19727228.9A EP19727228A EP3791598A1 EP 3791598 A1 EP3791598 A1 EP 3791598A1 EP 19727228 A EP19727228 A EP 19727228A EP 3791598 A1 EP3791598 A1 EP 3791598A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- streams
- channel
- abr
- stb
- chunk
- 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.)
- Pending
Links
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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
-
- 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 or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
-
- 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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- 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/6143—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a satellite
-
- 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/631—Multimode Transmission, e.g. transmitting basic layers and enhancement layers of the content over different transmission paths or transmitting with different error corrections, different keys or with different transmission protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
Definitions
- This disclosure relates generally to the field of broadcast networks and more specifically to broadcasting content to a STB and providing a set of stored audio/video (AV) information directly to a client device within a home environment.
- AV audio/video
- AV audio/video
- Traditional television and the Internet are both used to deliver audio/video (AV) content, such as entertainment and educational programs, to viewers.
- Television programming and other AV content is available not only from traditional sources like broadcast and cable television, but also from computers and mobile computing devices such as smart phones, tablets and portable computers.
- These retail devices may receive content via wired or wireless communications networks, in a home, business, or elsewhere.
- Adaptive streaming also known as adaptive bit rate (ABR) streaming
- IP Internet Protocol
- ABR streaming is conventionally based on a series of short Hypertext Transfer Protocol (HTTP) progressive downloads which is applicable to the delivery of both live and on demand content.
- HTTP Hypertext Transfer Protocol
- Examples of ABR streaming protocols include HTTP Live Streaming (HLS), MPEG Dynamic Adaptive Streaming over HTTP (DASH), Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming (HDS), and the like.
- An ABR streaming client performs the media download as a series of very small files. The content is cut into many small segments (chunks) and encoded into the desired formats.
- a chunk is a small file containing a short video segment (typically 2 to 10 seconds) along with associated audio and other data.
- Adaptive streaming relies generally on the use of HTTP as the transport protocol for these video chunks; however, other protocols may be used as well (e.g., Real Time Messaging Protocol (RTMP) is used in HDS).
- RTMP Real Time Messaging Protocol
- Playback is enabled by creating a playlist or manifest (the terms are used interchangeably in this disclosure) that includes a series of uniform resource identifiers (URIs).
- URIs uniform resource identifiers
- a uniform resource locator URL
- Each URI is usable by the client to request a single HTTP chunk.
- a server such as an origin server, stores several chunk sizes for each segment in time.
- the client estimates the available bandwidth and requests the best chunk size using the appropriate URI. Since the client is controlling when the content is requested, this is seen as a client-pull mechanism, compared to traditional streaming where the server pushes the content.
- URIs to create the playlist enables very simple client devices using web browser- type interfaces.
- Adaptive streaming was developed for video distribution over the Internet, and has long been used (e.g., by Internet video service providers such as Netflix, Hulu, YouTube, and the like) to stream AV (audio/video) content, such as video content embedded in a web site, to an ABR streaming client upon request.
- the ABR client receives the AV content for display to a user.
- ABR streaming includes the ability to switch between different encodings of the same content. These different encodings, or profiles, vary in bitrate, resolution, codec, etc.
- an ABR streaming client can choose an optimum profile based on its capabilities along with the currently available bandwidth between it and the content provider.
- a number of Multichannel Video Programming Distributors such as cable and broadband service providers who provide both cable and Internet services to subscribers, operate content delivery networks (CDNs) in which Internet Protocol (IP) is used for delivery of television programs (e.g., IPTV) over a digital packet-switched network.
- IP Internet Protocol
- adaptive bit rate streaming can be used for delivery of AV content, such as live or linear television programming and video on demand (VOD) content enabling these operators to offer an“over-the-top” (OTT) solution to their subscribers.
- VOD video on demand
- ABR e.g., HLS or DASH
- HLS High Speed Downlink Packets
- DASH Dynamic Streaming Protocol
- the ABR suite of profiles may typically have 3 to 6 or more variants of varying resolutions and bitrates. The costs for setting up this parallel network can be burdensome to such broadcasters, especially since CDNs and the two way IP connections needed to their subscriber homes would typically be purchased from third parties.
- the methods described here are applicable to any systems that include broadcast capabilities such as fiber based telco providers, cable TV providers or terrestrial broadcasters.
- a cable TV provider could choose to use the systems and methods described herein, in conjunction with their two way IP network, to more efficiently deliver their most popular channels for OTT use while conserving the bandwidth of their IP network for other data applications as well as their more lightly used OTT channels.
- a method of broadcasting channels to set top boxes (STB) in a home network includes the steps of: transmitting a plurality of streams for each channel broadcast, wherein each stream is at a different bitrate and is segmentable into chunks; receiving the plurality of streams for one or more channels at the STB; and storing a plurality of segmentable chunk durations for each of the plurality of streams for each channel received.
- FIG 1 is an overview of an existing broadcast satellite system that can be used for transmission of audio and/or video (AV) information including in- home delivery to ABR clients such as mobile phones;
- AV audio and/or video
- Figure 2 is an overview of an illustrative broadcast satellite system that can be used for transmission of audio and/or video (AV) information, also enabling in-home delivery to ABR clients but with improved performance and lower subscriber cost than that shown in Figure 1 ;
- AV audio and/or video
- Figure 3 illustrates a partial block diagram of an exemplary media streaming system or server in the home network
- Figure 4 illustrates a general flowchart for a process performed by a client device in the home network
- Figure 5 illustrates a partial block diagram of an exemplary security system for Figures 3 and 4;
- Figure 6 illustrates a general flowchart for the security system of Figure 5;
- Figure 7 illustrates a simplified block diagram of wireless communication in the home network
- Figure 8 illustrates a general flowchart for a method of processes performed by the broadcast satellite system
- Figure 9 illustrates a general flow diagram for a method of processes performed by the exemplary media streaming STB or server in the home network.
- Figure 10 illustrates a diagram of a computer system that can be used to implement elements of the client device in the disclosed system.
- ABR IP connected ABR
- DASH digital streaming
- HLS receiver style consumer devices
- Provided herein is a method that distributes a suite of ABR channels by satellite (or other broadcast medium) to a home gateway or set top with memory.
- the home gateway can buffer channels in advance, subject to memory limitations, constantly refreshing the cache so that anyone using an in-home consumer electronic device can access HLS chunks rapidly, and use the applicable ABR protocol between the gateway and the device.
- FIG. 1 is a diagram depicting an alternative embodiment of a broadcast satellite system 100 that can be used for transmission and/or storage and retrieval of audio and/or video content, such as television (TV) programming.
- the broadcast satellite system 100 comprises a broadcast site or communication station 110, which provides audio-visual (AV) content 105 in the form of multichannel programming.
- AV content 105 is shown as 300 channels, but any number of channels may be provided. As an example, 200-400 channels may be provided.
- Such channels are typically provided at a predetermined and single resolution and approximate bit rate (e.g., broadcast site 110 uses MPEG2 transport format, at high rates and high quality).
- communication station 110 transmits AV content 105 to a set-top box (STB) 130 via a satellite link with satellite 120.
- STB set-top box
- STB 130 acquires the AV content from, e.g., 300 channels, provided from broadcast site or communication station 110.
- STB 130 additionally transcodes the AV content from the received rate and quality to lower rates and quality, in support of the in-home streaming devices. This transcoding carries a cost, and the process is time consuming. Thus the consumer experience is not the same as with a full HLS infrastructure.
- a (purchased) Slingbox or other suitable media-streaming device 140 in communication with STB 130 and a Wi-Fi access point 150.
- Slingbox 140 encodes analog AV content from STB 130 to the lower bitrate and quality that in-home CE devices can process.
- Wi-Fi access point 150 a retail client device 160 may access the AV content from Slingbox 140.
- a client device may be any retail device such as, but not limited to, an Android phone, iPhone, iPad, or other tablet, or laptop.
- Slingbox 140 encodes AV content to rate match what it estimates the Wi-Fi network can carry from WiFi access point 150.
- a user tunes STB 130 first, and waits for it to acquire, then the Slingbox 140 encodes the output.
- Slingbox 140 works because an “analog hole” allows it to encode a received broadcast without violating any copy protection laws. So a user waits for the Slingbox 140 to encode the broadcast, then a Wi-Fi device such as client device 160, can access the Slingbox 140 signal through a Slingbox application or“app”, if there is one available. This app may not be using HLS in the conventional way, or at all. Some Slingbox apps need to be purchased, and some are free. When the user is done, he has waited between about 7 and 12 seconds approximately for the signal he wishes to watch. As can be appreciated, although far less expensive for the operator than deploying an entire ABR streaming infrastructure, this approach is slow, requires custom apps, and the hardware is available from a very limited number of companies.
- FIG. 2 is a diagram depicting an exemplary embodiment of a broadcast satellite system 200 that can be used for transmission and/or storage and retrieval of audio and/or video content, such as television (TV) programming.
- the broadcast satellite system 200 comprises a broadcast site or communication station 210, which provides audio-visual (AV) content 205 in the form of multichannel programming.
- AV audio-visual
- AV content 205 is shown as 300 channels, but any number of channels may be provided.
- broadcast site 210 uses MPEG2 transport format, at high rates and high quality.
- broadcast site 210 provides one or more versions of the channels in different bit rates.
- broadcast site 210 may provide one to four versions of the same, or a subset of the, 300 channels at lower resolutions and bit rates. This may be achieved using transcoding equipment (not shown) at broadcast site 210 to produce these additional lower quality/bitrate encodings. This extra transcoder cost may be amortized over all subscribers using the service.
- a lower number of streams than typical Internet-based ABR is provided, as a cost and satellite bandwidth saving measure.
- communication station 210 transmits AV content 205 to a server or set-top box (STB) 230 via a satellite link with satellite 220.
- STB set-top box
- the three low rate transport streams for each of the channels in AV content 205 may be segmented into e.g., two-second chunks and aligned with MPEG-2 packet boundaries (e.g., by starting each chunk with an anchor frame, e.g. an IDR frame, in some cases the only IDR frame in the two seconds, and employing closed MPEG GOPs).
- This alignment can be signaled in the leading packet header of each two-second chunk, avoiding the need to provide some other way to indicate where chunk boundaries are. While described as two second chunks, other lengths may be used, with shorter sizes typically leading to shorter service acquisition time, and less memory in STB 230.
- STB 230 acquires the AV content from all or a subset of the 300 channels provided from broadcast site or communication station 210. Further detail on the functioning of STB 230 is provided in Figure 3. Also in system 200 is a wireless access point (e.g. Wi-Fi) 240 in communication with STB 230. Using wireless access point 240, a client device 250 may access the AV content from STB 230.
- Wi-Fi wireless access point
- ABR is packaged as MPEG transport stream(s) without an explicit manifest file sent from broadcast site 210, and then the STB 230 caches the ABR chunks for at least the consumer's most viewed channels, reducing acquisition time of those ABR streams.
- the STB 230 reconstitutes the FILS playlist and chunks and hosts them on an internal web server for delivery throughout the home.
- FIG. 3 is a block diagram of a subsystem for implementing embodiments of the present disclosure.
- the system includes a set-top box (STB) 300.
- the STB 300 has the additional capability of streaming AV content or video assets stored in memory 310.
- the STB 300 also includes an access control module 320, an HLS segmenter module 330, an encryptor module 340, an HLS manifest creation module 350, a network interface module 360, and a guide service module 370.
- the AV content is received from a broadcast site or communication station (not shown) as a set of N x Y streams, where N represents the number of channels and Y is the number of different bit rates and resolutions (media profiles) of the N streams provided.
- a satellite STB 300 can tune to as many channels N as the manufacturer wants to support, therefore a wide band tuner may include all channels, or a subset that most closely matches a consumers’ interests or criteria may be supported. Such criteria may include the last N channels watched, genres he has indicated interest in, etc.
- 3 chunks for each stream are (pre)stored in memory 310. It should be appreciated that fast acquisition of HLS streams can be done with 3 preexisting chunks of 2 seconds each. It is desirable to keep chunks small so that at least two chunks can be described in the playlist as soon as possible after stream start-up, as this helps provide a better experience in the event that the consumer chooses a channel not currently in memory. If the chunks are 2 seconds in duration, then this nominal storage is 6 seconds of video times N times Y streams. At some point, the total memory size required may be a major consideration.
- the AV content can be pulled on-demand from memory 310 quickly, decrypted using an access control module 320 (such as the DIRECTV conditional access system), and segmented into actual HLS chunk files and provided with their associated manifest files via HLS segmenter 330 and manifest creation module 350.
- the segments are also encrypted for content protection within the home by encryptor 340. These are quick operations that do not take much processing or time.
- These segments and manifests are then effectively published to a small internal web server and network interface 360 and the client device can begin pulling the manifests and segments with its standard HLS player.
- HLS has two types of manifests, the single main manifest that identifies the various Y bitrate/resolution media profiles available (by URL), and the Y media playlists. So, a client first requests the main manifest, makes a decision about which variant it wants, then requests the associated media manifest. For 2 second segments, it reads and downloads the media playlist again approximately every 2 seconds to get the new segment information.
- a consumer can only access channels he has subscriptions for, since the same conditional access system and entitlement management process for the high rate broadcasts would be employed for the corresponding lower rate streams. This would allow the system to operate without additional management at the headend. However, if the service provider wished to charge separately for the privilege of receiving the low rate HLS streams, this can added/controlled within access control module 320 of the current STB system 300.
- encryptor 340 encrypts the segmented HLS chunk files, thereby protecting the interests of the content owner within the home. Because it is envisioned that the user is in his home environment, a time varying encryption key unique to the user may used irrespective of the chosen content. Thus, encryptor 340 may encrypt these chunk files with the user-dependent content key. It should be noted that HLS and DASH have a‘transport’ mode, where chunk files are 2- second pieces of MPEG transport streams, as are broadcast files. This is the simplest approach; however, if desired, alternate modes could also be supported, such as fragmented MPEG4 chunks. This could be done for example with an encapsulation approach, at the headend, and decapsulation after access control decryption in the STB 300 (not shown).
- guide service module 370 interacts with the client app or browser on the mobile device that is making the channel selection for what to watch, e.g., it provides the information on the programs or channels currently available, possibly enhanced with links to further information on the Internet or operator’s network, and when the user selects one from their mobile device, the guide service module 370 sends the URL for that channel back to the app on the mobile device, which the app then gives to the ABR media player that is integrated in the mobile device.
- the STB 300 further includes at least one processor and at least one memory for storing code that is executable by the processor to enable the STB 300 to perform processes according to embodiments of the present disclosure.
- the STB 300 further includes an interface 360 for transmission of the streaming HLS video assets, and the memory further stores code to enable the processor to control the interface to enable such transmission as well as to control the storage of N x Y streams in memory 310.
- FIG 4 illustrates a simplified flowchart for a process 400 performed by an ABR client device in the home network.
- the consumer browses the available content, either via an application provided by their service provider or via a web browser.
- the consumer selects content for viewing (e.g,, a channel).
- the client device downloads the main playlist file for that channel that describes the available profiles available to the client.
- the client decides which profile to select based on its estimate of network conditions as well as its capabilities.
- the client downloads the media playlist for the selected profile via the URL provided in the main playlist.
- the media playlist contains the list of media segments, or chunk files, currently available.
- the client device fetches the media segments advertised in the playlist, decrypts them, and then plays them in step 450.
- the client fetches the media playlist 430 at approximately each media segment duration time in order to find the URL for the next new segment.
- the client also makes decisions as to whether it needs to switch to a different lie based on network conditions, and if so, selects a different profile from the main manifest downloaded in step 420, then continues with this new URL through the remaining steps. This process continues until the consumer either stops playing or decides to watch a different channel, in which case the process is started fresh from step 410.
- current security systems from current traditional broadcasters may be used to deliver content and provide conditional access to the STB.
- DIRECTV may be used to deliver content and provide conditional access to the STB.
- ABR ABR format
- that content would be solely encrypted for a home environment or network.
- each home device is registered with the STB (often with a device ID or device MAC address and device“friendly name,” the latter typically for user convenience and recognition).
- Typical in-home security systems could be DTLA’s DTCP-IP, with the HLS extension
- FIG. 5 illustrates a partial block diagram of an exemplary security system 500.
- Security system 500 includes a STB portion 505 and a client device portion 545.
- STB portion 505 includes STB playlist creation module 510, a key store module 520, and STB memory 530.
- Device portion 545 includes HLS playlist processing module 550, HLS key request module 560, HLS chunk decryptor module 570, and HLS decode and display module 580.
- the device portion 545 modules may comprise browser software or built-in application platform software or even application code if desired.
- the STB playlist creation module 510 is responsible for building the main playlist file, and the Y media playlists which name the current 3 chunks available to the clients, and the key or keys used to encrypt each.
- the format of these files matches either the HLS or DASH standard, for example. Every next chunk time, this file is recreated, adding one new chunk, and dropping off the oldest chunk. These files may be requested by client devices.
- the STB key store 520 contains the key or keys used to encrypt each chunk. These keys may be requested by clients, for example.
- the STB memory module 530 may store the encrypted content chunks in a proper format, either HLS or DASH, for example. Each next chunk time, a new chunk is available in memory, and an old chunk can be discarded. These chunk files can be requested by client devices.
- HLS playlist processing module 550 downloads and processes the main playlist after channel selection. After selecting the appropriate media profile (bitrate and resolution), that media playlist can be downloaded and processed, and then the new content chunk fi!e(s), approximately every chunk time, The Key request module 560 makes an https key request, and keys are returned in encrypted form.
- the HLS chunk decryptor module 570 decrypts each content chunk in sequence with the downloaded keys.
- the decode and display module 580 presents the content to the consumer, both audio and video.
- the total number of home devices is limited, for example, up to 3.
- the user must explicitly identify those devices he wishes to use for streaming. Typically, this is done with a registration step, where the device requests inclusion in the home network for streaming, and the STB interacts with the user, typically with a Graphical User Interface (GUI) in the TV display, so that the user can accept the request.
- GUI Graphical User Interface
- the user can further examine the“white” list of devices by ID and/or assigned friendly name at the STB GUI, and delete and confirm additions as he wishes.
- Figure 6 illustrates a general flowchart 600 for the security system of Figure 5.
- the client receives a cryptographic token, for example, through the registration process. Registration may occur by opening a browser at the client, and seiecting a registration option, or by frying to select content, and being redirected to a registration option, or through a custom application. Either way, the request for registration must be confirmed by the consumer at the STB display, as described above.
- the client processes the main playlist for the selected channel, and then the desired media profiie playlist, which describes the current chunk files for video and audio, and the keys employed to encrypt them. The chunk files so identified are downloaded by the client device built-in software.
- a key used to encrypt that chunk is requested from the STB with an https mutually authenticated TLS transaction employing the token at step 630.
- the STB knows that the request is valid, and which client device has requested it.
- https keeps the key confidential in transit to the client device.
- step 640 the client decrypts each chunk, so that step 650 can decode and play the content, Each chunk time, the process repeats with a new media playlist, and so on,
- STB 300 from Figure 3 may include or be in communication with a Wi-Fi access point 710 as part of home wireless system 700.
- the AV content is processed and streamed in FILS chunks to external consumer electronic (CE) devices 720 such as a cell phone or a tablet (not shown) in a home network.
- CE devices 720 include an application or“app” for the specialized viewing of a channel selection guide.
- a browser can suffice as described above, but the operator may wish to enhance the consumer experience with some form of custom application code, or perhaps include this ABR streaming within the custom application he already supplies to his consumers.
- FIG. 8 and Figure 9 illustrate more detailed flow charts for the satellite broadcast system and home server STB system.
- a flow diagram 800 for processing at a satellite uplink includes one or more content sources 810a, 810b, ... , 81 On.
- each content source 810a, 810b, ... , 81 On represent a different channel;
- content source 810a represents channel #1
- content source 810b represents channel #2
- content source 81 On represents channel #n.
- the broadcast satellite provider can opt to source from 1 to n channels, which may be the entire channel lineup or a subset of the channel lineup.
- transcoder 820a One or more content sources 810a, 810b, ... , 81 On are provided to a transcoder 820a, 820b, ... , 820n, respectively.
- a single transcoder 820a, and its resultant outputs will be discussed; however, it should be appreciated that similar outputs are produced by transcoders 820b through 820n.
- channel #1 is encoded in e.g. 3 or more qualities/bitrates, such as a high quality/bitrate 830a, which in some embodiments can be used by existing subscriber receivers.
- two lower quality/bitrates 830b, 830c may be encoded to better enable support for subscriber devices like phones connected in the home via Wi-Fi. While shown as two lower quality/bitrates 830b, 830c, a third lower quality/bitrate (not shown) may optionally also be encoded. In some embodiments, three lower quality/bitrates are encoded without high quality/bitrate 830a. In all cases, the transcoder 820a must insure that its outputs, 830a, 830b and 830c are aligned such that their anchor frames occur at the same location in each of the outputs, and there may be an anchor frame positioned as what will become the first frame of each segment that will be created by the ABR Segmenter 945 in the STB.
- audio since audio generally requires much less bandwidth than the associated video, it is transcoded once and shared across multiple video profiles in ABR thus saving resources.
- the system operator has the flexibility to use a single audio encoding with all of the video profiles associated with each channel, separate audio encodings for each video profile, or other combinations thereof, for example, two audio profiles, each associated with two of the four video profiles encoded for the channel.
- the 3 encoded bitrates are provided to their respective pseudo- packagers, where high quality/bitrate 830a is provided to pseudo-packager 840a, and the two lower quality/bitrates 830b, 830c are provided to pseudo-packagers 840b, 840c.
- Pseudo-packagers 840a, 840b, 840c may each be a software application designed to convert MPEG-2 transport streams to HLS-compliant content (chunks) and associated playlist files, but instead of creating these chunks directly, they produce a set of instructions, or hints, that will be used by the ABR Segmenter 945 in the STB for this purpose.
- Hints can range from the signaling to indicate the segment boundaries, to providing details on each of the profile bitrates, codecs and other data needed for the actual ABR packaged manifest files, simplifying the manifest creation in the STB.
- the output of pseudo-packagers 840a, 840b, 840c for each stream is an MPEG single program transport stream (SPTS) 845a, 845b, 845c.
- SPTS MPEG single program transport stream
- each pseudo-packager 840a, 840b, 840c may include a hinting function that creates a private data stream passed along with the transport stream that can be used by the subscriber’s enhanced STB receiver ABR segmenter (e.g., 945 in Figure 9)
- the hinting function provides instructions on where to split MPEG SPTS 845a, 845b, 845c to create segments and associated ABR manifest files needed by subscriber clients to play the ABR streams.
- the private data streams are placed in the MPEG SPTS 845a, 845b, 845c as an auxiliary PID stream with private data or in an existing MPEG video stream related field for private data.
- MPEG SPTS 845a, 845b, 845c are provided to a multiplexer 850, such as an MPEG-2 multiprogram transport stream (MPTS) multiplexer.
- MPTS MPEG-2 multiprogram transport stream
- the multiplexer 850 combines all the incoming single program transport streams into a single multi-program transport stream and provides that combined stream to the Conditional Access System (CAS)/Encryptor block 860.
- CAS/Encryptor 860 may be essentially unchanged from what the satellite provider is already using.
- the encrypted multiplex can then be modulated for transmission over a single transponder of the satellite, combined with the other such signals at this facility, (not shown) and then transmitted through the satellite uplink 870.
- a flow diagram 900 for processing at home server STB 920 includes an RF broadcast signal 910 input, a STB 920, television 980 and mobile phone 990.
- STB 920 includes a tuner 925, demultiplexer 930, CPU subsystem 915, memory 935, CAS/decryptor 940, ABR segmenter 945, encryptor 950, ABR manifest generator 985, content cache & origin 955, MPEG decoder 965, guide service 970, network interface 975, and wireless access point 960.
- An optional component, DVR storage 905, is also shown and may be included in STBs that include digital video recording (DVR) capability.
- DVR digital video recording
- Broadcast signal input 910 is received by STB 920, and in some embodiments, tuner 925 is configured to select multiple MPTS muxes from input 910 covering a desired number of ABR services to be cached/offered.
- Demultiplexer 930 selects the desired set of video channels including the configured set of additional profiles and writes these to memory 935 that operates as a first-in, first-out (FIFO) storing approximately only the 3 most recent segment durations of each of the selected video channels with their associated profiles.
- FIFO first-in, first-out
- the memory 935 may be configured to cache only a subset of the available profiles for a channel (e.g., if the top profile is a 4k stream, this may not be cached as it might not be practical for ABR streaming in the home).
- some embodiments may take advantage of either user configuration or observation over time of the actual channels viewed and actual client connections within the home, both client type as well as the available bandwidth of the connection to each client, to further refine a subset of the available profiles or a subset of the available channels to cache in memory.
- a further refinement might be to store only the applicable subset of available profiles on a per channel basis based on the in-home clients that watch that channel (e.g., a mobile phone via WiFi may only be able to usefully consume profiles up to 1080p24 via WiFi while an Apple TV could use the 4k profile via its Ethernet connection).
- a tablet used in a playroom to watch children’s channels only that is farther away from the WiFi access point 960 might only support the one or two lower bitrate profiles.
- CAS/decryptor 940 is configured to decrypt the streams that are part of the ABR cached offering after channel selection by the consumer’s client device.
- ABR segmenter 945 may process the 3 bitrate SPTS streams for the selected channel into the appropriate ABR segments, e.g. HLS or DASH, using either the built-in MPEG IDR alignment markers, or possibly hinting information if sent along with those streams.
- the encryptor 950 encrypts the segments according to the specific HLS security approach, as discussed previously in Figures 5 and 6, and then stores these media segments on the local content cache 955.
- the ABR manifest generator 985 creates the main and media playlists and stores these on the local content cache 955, which typically also serves as an http origin server. In typical embodiments, this is performed for only the channel(s) currently being requested from clients such as smart phone 990.
- Network interface 975 provides the STB IP output.
- the CE device e.g., mobile phone 990
- the CE device invokes its ABR player, making http requests to the STB local content cache & origin 955, across the in-home Wi-Fi network (e.g., via Wi-Fi access point 960), pulling the ABR segments and playing them.
- the channel selection process in the device app starts with access to the web guide provided by the STB at guide service 970, just as consumers today can select their router's web page for configuration.
- legacy receivers or STBs have a top path 975 through MPEG decoder 965 to television 980, and may also offer a way to send one or more additional SPTS to other STB receiver clients in the home for live linear or on-demand television viewing via Wi-Fi or similar.
- DVR Digital Video Recording
- the primary video encoding is stored in DVR storage 905 similar to existing DVR set tops, typically in the DVR storage 905, and in addition, all of the segmentable streams for the duration of the program are stored.
- the stored segmentable streams are read from the DVR storage 905 and processed as shown in Fig. 9 from the CAS decrypt 940, local ABR segmenter 945, and encryptor 950 as the chunks are needed, and stored for a short time on the content cache & origin 955.
- DVR implementations perform CAS decrypt 940 followed by a local DVR encryption process prior to DVR storage 905; in this scenario, at playback time, the content would be read from DVR storage 905, passed through the local DVR decryption process instead of the CAS decrypt 940, and then follow the same processing through the local ABR segmenter 945, encryptor 950 as the chunks are needed, and stored on the content cache & origin 955.
- the manifest generator process 985 is modified in the DVR case to build a single complete media manifest of all the segments comprising the program as soon as the content is requested for playback.
- FIG. 10 is a diagram illustrating an exemplary computer system 1000 that couid be used to implement elements of the client device of the present disclosure.
- the computer system 1000 includes a processing device such as a computer or central processing unit (CPU) 1010, which comprises a general purpose hardware processor and/or a special purpose hardware processor and memory, such as dynamic random access memory (DRAM) 1030 and FLASH memory 1032.
- the CPU 1010 may be coupled via BUS 1038 to other peripherals 1034 such as WiFi, power, sound, etc.
- the graphics processor (GPU) and display input/output (I/O) 1020 are also coupled to the CPU typically through another connection.
- the device operates by the CPU 1010 performing instructions defined by a computer program under control of an operating system.
- the computer program and/or the operating system may be stored in the memory 1030 or 1032 and may interface with the user and/or other devices to accept input and commands and, based on such input and commands and the instructions defined by the computer program and operating system, to provide output and resuits.
- Output/results may be presented on the display 1020 or provided to another device for presentation or further processing or action.
- the display 1020 comprises a liquid crystal display (LCD) having a plurality of separately addressable pixels formed by liquid crystals. Each pixel of the display 1020 changes to an opaque or translucent state to form a part of the image on the display in response to the data or information generated by the CPU 1010.
- LCD liquid crystal display
- Other display 1020 types also indude picture elements that change state in order to create the image presented on the display 1020.
- the term“computer” is referred to herein, it is understood that the computer may include portable devices such as cellphones, portable MP3 players, video game consoles, notebook computers, pocket computers, or any other device with suitable processing, communication, and input/output capability
- Smart phones and tablets are generally structured as application platforms, that is, platforms that can accommodate third party applications in a speoifio manner.
- application platform and OS 1060 may be the iOS platform from Apple, or the Android platform from Google, generally run on some form of the Linux OS.
- Various applications 1070, 1072, 1074, and 1076 for example can be either preinstalled with the device upon purchase, or downloaded from the application store by the consumer as he wishes at a later date. Examples of such applications are one or more web browsers, special operator provided applications in support of the overall consumer experience, and perhaps a specialized registration application.
- DSP digital signal processor
- ASIC application specific integrated circuit
- FPGA field programmable gate array
- a general-purpose processor can be a microprocessor, but in the alternative, the processor can be any processor, controller, or microcontroller.
- a processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
- a software module can reside in computer or machine-readable storage media such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium including a network storage medium.
- An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium.
- the storage medium can be integral to the processor.
- the processor and the storage medium can also reside in an ASIC.
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201862670332P | 2018-05-11 | 2018-05-11 | |
PCT/US2019/032001 WO2019217959A1 (en) | 2018-05-11 | 2019-05-13 | Broadcast delivered hls system |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3791598A1 true EP3791598A1 (en) | 2021-03-17 |
Family
ID=74551297
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP19727228.9A Pending EP3791598A1 (en) | 2018-05-11 | 2019-05-13 | Broadcast delivered hls system |
Country Status (1)
Country | Link |
---|---|
EP (1) | EP3791598A1 (en) |
-
2019
- 2019-05-13 EP EP19727228.9A patent/EP3791598A1/en active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20190364330A1 (en) | Broadcast Delivered HLS System | |
US9462307B2 (en) | ABR live to VOD system and method | |
US8510555B2 (en) | Streaming video server with virtual file system and methods for use therewith | |
US9203816B2 (en) | Controlling access to copies of media content by a client device | |
US8548303B2 (en) | Reconciling digital content at a digital media device | |
US8484692B2 (en) | Method of streaming compressed digital video content over a network | |
US9118943B2 (en) | Video on demand processing | |
US20140344410A1 (en) | Fixed-length segmentation for segmented video streaming to improve playback responsiveness | |
CA2981629C (en) | Hidden replaceable media slots | |
US20120174163A1 (en) | Tuner Control for Streaming Live Television | |
US20140223502A1 (en) | Method of Operating an IP Client | |
US20090055863A1 (en) | Method and system for providing content | |
US9325945B2 (en) | Video server and client with custom key exchange and methods for use therewith | |
CN110543747A (en) | Multimedia pipeline architecture | |
US20150199498A1 (en) | Flexible and efficient signaling and carriage of authorization acquisition information for dynamic adaptive streaming | |
WO2016141811A1 (en) | Streaming media pushing method and system | |
KR100878023B1 (en) | A device of providing value-added information using channel zapping time of IPTV, a Method thereof, and a Recording device having that method | |
EP3791598A1 (en) | Broadcast delivered hls system | |
WO2019166960A1 (en) | Apparatus, method and system for multiple audio-video streams reception | |
BG4289U1 (en) | Web-based system for receiving, processing and broadcasting media streams | |
US20160323622A1 (en) | System and a method for distributed processing of video content in a mobile content gateway |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
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: 20201117 |
|
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 |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20230202 |