CN107148779B

CN107148779B - Method for transmitting media content

Info

Publication number: CN107148779B
Application number: CN201580057430.XA
Authority: CN
Inventors: 温德尔·什
Original assignee: Ai Ruishi LLC
Current assignee: Commscope UK Ltd
Priority date: 2014-10-22
Filing date: 2015-10-19
Publication date: 2020-10-23
Anticipated expiration: 2035-10-19
Also published as: CN107148779A; EP3210383A1

Abstract

Methods of delivering media content are provided that provide for significantly reduced block sizes. The method includes receiving, at an HTTP streamer, one or more adaptive transport streams from a media preparation unit into a memory buffer. The received transport stream comprises a plurality of switchable segments, each switchable segment comprising one or more delivery chunks, the switchable segments being marked with segment boundary points and the delivery chunks being marked with chunk boundary points. One or more of the delivery chunks from the requested switchable segment are then transmitted to the requesting client device until a terminating segment boundary point is reached, where each delivery chunk is independently decodable, and the client device can begin decoding and rendering the received delivery chunks even when the HTTP streamer has not completely received the entire requested switchable segment from the media preparation unit.

Description

Method for transmitting media content

Priority requirement

Priority of earlier U.S. provisional application serial No. 62/066,971, filed 2014, 10, 22, 35u.s.c. § 119(e), which is incorporated herein by reference.

Technical Field

The present disclosure relates to the field of digital video streaming, and more particularly to the field of using Adaptive Transport Streaming (ATS) and block transport coding to reduce latency in adaptive bit rate streaming.

Background

Streaming live or pre-recorded media content over a network such as the internet to client devices such as set-top boxes, computers, smart phones, mobile devices, tablet computers, game consoles, and other devices is becoming increasingly popular. Delivery of such media content typically relies on adaptive bitrate streaming techniques such as MPEG-DASH, HTTP Live Streaming (HLS), and HTTP smooth streaming.

A stream of media content encoded with adaptive bitrate streaming techniques is typically divided into a plurality of segments, where each segment may be independently accessible. The client device may play the media stream by requesting and decoding the first segment, requesting and decoding the second segment, and continuing to request and decode subsequent segments as long as the user of the client device wishes to play the media content, or until playback reaches the end of the media content.

In addition, the segmentation of the stream may allow the client device to transition between different bit rate versions of the stream that have each been encoded at different quality levels. For example, when network conditions are congested, a client device may begin playback of a media stream by requesting segments encoded at a low bit rate, while when network conditions improve, the client device may transition to a higher quality version of the stream by requesting subsequent segments encoded at a higher bit rate.

While segmenting media streams can be useful, conventional segmentation processes introduce delays, particularly in the delivery of live content. In most adaptive bit rate streaming implementations, the server can only provide the full segment to the requesting client device. However, the segments typically have a length of at least a few seconds, such as 2 to 10 seconds. Thus, the initial delivery of the stream to the end user cannot begin until after the first segment is completed. This introduces a delay of at least the length of the segment before live content can otherwise be viewed. In addition, since the first segment is delayed in this manner, all subsequent segments will be similarly delayed and the video will never be available in real time.

These types of delays can be frustrating for users. For example, live sports broadcasts are popular, and viewers often want to see an event on the screen as soon as possible after the event occurs in the stadium. However, even if the length of each segment is relatively short, such as two seconds, the two seconds of content must be fully encoded and packaged into segments before being sent to the client device. Thus, due to the segmentation process, the events shown on the screen will always lag real-time by at least two seconds. Such a delay may be disappointing to enthusiasts, because when an exciting event occurs during a game, they may first learn by an online scoreboard or radio before they can actually see it occurring on the screen.

While some viewers may not be concerned about receiving live video with delay, the time taken to begin viewing the video stream can still be annoying to those viewers. Since the first video segment needs to be fully encoded and packetized before it is sent to the viewer's device, there may be a delay, such as 2-10 seconds, after the viewer requests the video stream, at least equal to the size of the segment before it starts to be played for the viewer. A multi-second tuning delay can be frustrating to viewers accustomed to the immediate tuning time provided by conventional televisions.

One way to reduce this type of tuning delay may be to reduce the size of the segments. For example, unlike the 10 second segment typically used in some current streaming technologies, the segment size can be shortened to 2 seconds so that the decoding device can begin playback after receiving the first 2 seconds of content. However, all segments are typically encoded with leading anchor frames, which use more data than other frames. Therefore, reducing the segment size requires more anchor frames and utilizes more data, which can reduce coding efficiency and impact bandwidth usage and performance. In addition, reducing the segment size will generally result in more segments and thus will increase the number of HTTP requests and replies needed to deliver them to the client device.

Disclosure of Invention

There is a need for a system and method for transmitting delivery blocks from individual switchable segments within a continuous adaptive transport stream using block transfer coding, even when the transmitting device does not already know the full size of the switchable segments, or even in the case where the transmitting device does not already have a full copy of the switchable segments. This may allow transmission, decoding, and rendering of live content to begin almost immediately after a client device requests a switchable segment, without waiting for a complete switchable segment to be encoded and transmitted.

In one embodiment, the present disclosure provides a method for transmitting media content, the method comprising receiving, at a HTTP streamer (streamer), an adaptive transport stream description from a media preparation unit, the adaptive transport stream description describing media content available from the media content preparation unit as one or more adaptive transport streams, wherein each of the one or more adaptive transport streams is a continuous stream comprising a plurality of switchable segments, the plurality of switchable segments each comprising one or more delivery blocks, the switchable segments being labeled with segment boundary points, and the delivery blocks being labeled with block boundary points, wherein a position between each of the plurality of switchable segments is a position at which a client device may switch to a different one of the one or more adaptive transport streams; publishing a playlist, wherein an HTTP streamer lists identifiers of one or more of the plurality of switchable segments; receiving the one or more adaptive transport streams from the media preparation unit into a memory buffer at the HTTP streamer, receiving a request at the HTTP streamer from the client device for a particular switchable segment identified on the playlist, and transmitting one or more delivery chunks from the particular switchable segment to the client device until a terminating segment boundary point is reached, responding to the request using a chunking transfer encoding, wherein each of the one or more delivery blocks is part of a single switchable segment that is independently decodable by a client device, so that even when the HTTP streamer has not completely received the requested switchable segment from the media preparation unit, the HTTP streamer is also configured to begin transmitting delivery chunks from the requested switchable segment, and the client device may also begin decoding and rendering received delivery chunks.

In another embodiment, the present disclosure provides a method of encoding media content, the method comprising: receiving, at a media preparation unit, a media content segment from a source; encoding the media content segment into a plurality of adaptive transport streams at varying bit rate levels using a media preparation unit, each of the plurality of adaptive transport streams being a continuous stream comprising a plurality of switchable segments, such that a decoding device can switch from one of the plurality of adaptive transport streams to a different one of the plurality of adaptive transport streams at a location between adjacent switchable segments; encoding each of the plurality of adaptive transport streams using a media preparation unit such that each of the plurality of switchable segments includes one or more delivery blocks, wherein each delivery block within a particular switchable segment is an independently decodable portion of the particular switchable segment; each of the plurality of adaptive transport streams is marked with a plurality of segment boundary points marking a start point and/or an end point of each of the switchable segments within the adaptive transport stream, and each of the plurality of adaptive transport streams is marked with a plurality of block boundary points marking a start point and/or an end point of each of the delivery blocks within each switchable segment within the adaptive transport stream.

In another embodiment, the present disclosure provides a method of delivering media content, the method comprising: receiving media content from a source at a media preparation unit, encoding the media content into a plurality of adaptive transport streams at varying bit rate levels using the media preparation unit, each of the plurality of adaptive transport streams being a continuous stream comprising a plurality of switchable segments, such that a decoding device can switch from one of the plurality of adaptive transport streams to a different one of the plurality of adaptive transport streams at a location between adjacent switchable segments; encoding each of the plurality of adaptive transport streams using a media preparation unit such that each of the plurality of switchable segments includes one or more delivery blocks, wherein each delivery block within a particular switchable segment is an independently decodable portion of the particular switchable segment; marking each of a plurality of adaptive transport streams with a plurality of segment boundary points marking a start point and/or an end point of each switchable segment within the adaptive transport stream; marking each of the plurality of adaptive transport streams with a plurality of block boundary points that mark a starting point and/or an ending point of each delivery block within each switchable segment in the plurality of adaptive transport streams; transmitting an adaptive transport stream description describing a plurality of adaptive transport streams from the media preparation unit to the HTTP streamer; publishing a playlist, wherein an HTTP streamer lists identifiers of one or more of the plurality of switchable segments; receiving, at the HTTP streamer, the plurality of adaptive transport streams from a media preparation unit into a memory buffer; receiving, at the HTTP streamer from a client device, a request for a particular switchable segment identified on the playlist; and responding to the request using chunking transfer encoding by transmitting one or more delivery chunks from the particular switchable segment to the client device until a terminating segment boundary point is reached, wherein even when the HTTP streamer has not completely received the requested switchable segment from the media preparation unit, the HTTP streamer is configured to begin transmitting delivery chunks from the requested switchable segment and the client device may begin decoding and rendering the received delivery chunks.

Drawings

Further details of the invention are explained with the aid of the drawings, in which:

fig. 1 depicts a system for delivering media content, including an HTTP streamer in communication with a media preparation unit and one or more client devices.

FIG. 2 depicts a portion of a non-limiting example of adaptive transport flow.

Fig. 3A depicts an exemplary embodiment of a playlist listing virtual identifiers.

Fig. 3B depicts an exemplary embodiment of a playlist that lists segment identifiers.

Fig. 4 depicts a portion of an adaptive transport stream received into a memory buffer at an HTTP streamer.

Fig. 5 depicts a first exemplary process for transmitting an adaptive transport stream from an HTTP streamer to a client device using chunking transport encoding.

Fig. 6A-6C depict examples of switchable segments of an adaptive transport stream received into a memory buffer and delivery blocks of the switchable segments transmitted to a requesting client device.

Fig. 7 depicts a second exemplary process for transmitting an adaptive transport stream from an HTTP streamer to a client device using chunking transport encoding.

FIG. 8 depicts a block diagram of an exemplary embodiment of a computer system.

Detailed Description

Fig. 1 depicts a system for delivering media content 102. Media preparation unit 104 can selectively communicate and/or exchange data with HTTP streamer 106, and one or more client devices 108 can selectively communicate and/or exchange data with HTTP streamer 106.

The media preparation unit 104 may be an encoder and/or transcoder that includes one or more processors, data storage systems or memories, and/or communication links or interfaces. The media preparation unit 104 may receive the media content 102 from a source such as a broadcaster or content provider. The media content 102 may include audio and/or video. In some embodiments and/or scenarios, media content 102 may be a live broadcast, while in other embodiments and/or scenarios, media content 102 may be pre-recorded. The media preparation unit 104 may be configured to encode and/or transcode the received media content 102 into at least one adaptive transport stream 110. In some contexts and/or embodiments, the media preparation unit 104 may encode and/or transcode the received media content 102 into multiple alternative adaptive transport streams 110, such as different versions each encoded at different quality levels or bitrates.

Fig. 2 depicts a portion of a non-limiting example of an adaptive transport stream 110. The adaptive transport stream 110 may be a continuous transport stream. By way of non-limiting example, the adaptive transport stream 110 may be a continuous MPEG2 transport stream. In some embodiments, the media preparation unit 104 may be based onSuch as

OpenCable^TMThe canonical specification prepares the adaptive transport stream 110, however in other embodiments the media preparation unit 104 may prepare the adaptive transport stream 110 in any other desired format.

Adaptive transport stream 110 may include a series of groups of pictures (GOPs), each GOP including one or more frames 202. Each frame 202 may be encoded and decoded by intra-prediction and/or inter-prediction. Data within an intra-predicted frame 202, also referred to as an I-frame or key-frame, alone may also be used to encode and decode the I-frame independently of other frames 202. The inter-predicted frame 202 may be encoded and decoded with reference to one or more other frames 202, such as by encoding the differences between the inter-predicted frame 202 and one or more reference frames 202. An inter-predicted frame 202 that can be encoded and decoded with reference to a previous frame 202 may be referred to as a P-frame. An inter-predicted frame 202 that can be encoded and decoded with reference to both previous and subsequent frames 202 may be referred to as a B-frame. Each GOP may start with an I-frame so that the decoding device can independently decode the leading I-frame and then use this decoding information to help decode any subsequent P-frames or B-frames within the GOP.

A plurality of independently decodable switchable segments 204 can exist within the adaptive transport stream 110 as shown in fig. 2. By way of non-limiting example, each switchable segment 204 may be a portion of the adaptive transport stream 110, such as a 2 to 10 second portion of the media content 102. Each individual switchable segment 204 may include one or more GOPs.

The location between each switchable segment 204 in the adaptive transport stream 110 may be a location where the client device 108 may switch between different versions of the adaptive transport stream 110. By way of a non-limiting example, a client device 108 experiencing network congestion may request and playback a switchable segment 204 from a version of the adaptive transport stream 110 that is encoded at a relatively low bit rate suitable for delivery over a network at a current congestion level. However, when the client device 108 reaches the end of the switchable segment 204 and determines that the network conditions have improved, the client device 108 may request the next switchable segment 204 from a different version of the adaptive transport stream 110 encoded at a higher bitrate.

Although the adaptive transport stream 110 may be encoded as a continuous transport stream, the media preparation unit 104 may provide information indicating the location of the segment boundary point 206 within the continuous adaptive transport stream 110. The segment boundary points 206 may indicate the start and/or end of each switchable segment 204 within the continuous adaptive transport stream 110.

In some embodiments, segment boundary points 206 may be identified within private data associated with adaptive transport stream 110. By way of non-limiting example, segment boundary points 206 may be Encoder Boundary Points (EBPs) that are based on content

OpenCable^TMThe specification is marked when it is encoded. In other embodiments, segment boundary points 206 may be identified in common data associated with the adaptive transport stream 110, such as segment boundary descriptors within common MPEG data fields. In still other embodiments, the location of segment boundary point 206 may be inferred from other data. By way of non-limiting example, the first frame 202 of each switchable segment 204 may be encoded as a special type of I-frame, called an IDR (instantaneous decoder refresh) frame, which indicates to the decoding device that its reference picture buffer should be emptied. Each IDR frame may indicate the start of a switchable segment 204 such that the identity of the IDR frame may also indicate a segment boundary point 206.

Each switchable segment 204 may include one or more delivery blocks 208. Each delivery block 208 may be a portion of the switchable segment 204, such as a single frame 202, a partial GOP, or one or more complete GOPs.

In some embodiments, each delivery block 208 may be an independently decodable sub-segment of the switchable segment 204, such that a decoding device may decode and render each delivery block 208 immediately upon receiving the sub-segment without waiting for additional delivery blocks 208. By way of non-limiting example, the delivery block 208 may be a single 8-frame GOP taken from a larger ten-second switchable segment 204 that includes multiple GOPs. As another non-limiting example, when the switchable segments 204 comprise all I frames, their delivery blocks 208 may be separate frames 202, as each frame may be independently decoded.

As shown in fig. 2, media preparation device 104 may indicate the location of block boundary point 210 within adaptive transport stream 110 by public or private data, in a manner similar to that in which segment boundary point 206 may be indicated. Each block boundary point 210 may mark the beginning and/or end of a delivery block 208 within a switchable segment 204.

Returning to fig. 1, the media preparation unit 104 may provide access to the adaptive transport stream 110 to the HTTP streamer 106 via a network, such as the internet or any other data network. The HTTP streamer 106 may join the multicast group associated with the media preparation unit 104 to begin receiving the adaptive transport stream 110.

The HTTP streamer 106 may be an encapsulator and/or server configured to deliver the independently switchable segments 204 from the adaptive transport stream 110 to the client devices 108 that have requested them. The HTTP streamer 106 may comprise an Internet Protocol Television (IPTV) server, an Over The Top (OTT) server, or any other type of server or network element. HTTP streamer 106 may have one or more processors, data storage systems or memories, and/or communication links or interfaces. As shown in fig. 4 below, HTTP streamer 106 may have one or more memory buffers 402, and HTTP streamer 106 may at least temporarily store the received portion of adaptive transport stream 110 into memory buffers 402.

Each client device 108 may be a set-top box, cable box, television, computer, smart phone, mobile device, tablet computer, game console, or any other device configured to request, receive, and playback switchable segment 204. Client device 108 may have one or more processors, data storage systems or memories, and/or communication links or interfaces.

In some embodiments, HTTP streamer 106 may also receive adaptive transport stream description 112 from media preparation unit 104. The adaptive delivery stream description 112 may be a Media Presentation Description (MPD), manifest, or other information describing one or more adaptive delivery streams 110 available from the media preparation unit 104 to the HTTP streamer 106. By way of non-limiting example, media preparation unit 104 may provide HTTP streamer 106 with adaptive delivery stream description 112 describing segments of media content 102, such as the name of media content 102, and identifiers of a plurality of different adaptive delivery stream 110 versions of media content 102 that may be obtained or will be available at different bitrates from media preparation unit 104.

The HTTP streamer 106 may use the adaptive transport stream description 112 to generate a playlist 114 for the client device 108 that describes the media content 102 and the available switchable segments 204. The playlist 114 may be an MPD, manifest, or other information describing one or more switchable segments 204 that may be requested by the client device 108 from the HTTP streamer 106. By way of non-limiting example, the playlist 114 may be a DASH (HTTP-based dynamic adaptive streaming) MPD. The HTTP streamer 106 may publish the playlist 114 for the client device 108.

Fig. 3A depicts a first embodiment of a playlist 114. In some embodiments or scenarios, such as when media content 102 is a live broadcast and client device 108 is likely to request the most recent switchable segment 204 to present media content 102 as close to live as possible, HTTP streamer 106 may prepare playlist 114 with virtual identifier 302 linked to the version of the most recent switchable segment 204 in adaptive transport stream 110. By way of non-limiting example, HTTP streamer 106 may prepare a playlist 114 that lists virtual identifiers 302, such as versions encoded at different bitrates, of the adaptive transport stream 110 for each level of quality available from the media preparation unit 104. The client device 108 can use the virtual identifiers 302 in the playlist 114 to request the most recent switchable segments 204 at a desired level of quality from the HTTP streamer 106 without needing to know the specific identifier or URL of the most recent switchable segments 204 at the HTTP streamer 106.

Fig. 3B depicts an alternative embodiment of the playlist 114. In an alternative embodiment, the HTTP streamer 106 may list unique segment identifiers 304, such as file names or URLs, for particular switchable segments 204 on the playlist 114. The HTTP streamer 106 may analyze the portion of the adaptive transport stream 110 that it has received in the memory buffer 402 to identify the switchable segments 204 that were at least partially received and add segment identifiers 304 to those switchable segments 204 on the playlist 114. In some embodiments, the playlist 114 may list segment identifiers 304 for alternate versions of each switchable segment 204, such as collocated switchable segments 204 from the adaptive transport stream 110 encoded at different bit rates.

In these embodiments, the HTTP streamer 106, upon initially receiving a portion of a new switchable segment 204, may include a segment identifier 304 for the new switchable segment 204 on the playlist 114 even though it has not received the entire switchable segment 204. By way of non-limiting example, as soon as the HTTP streamer 106 encounters a new segment boundary point 206 in the adaptive transport stream 110, it can add the segment identifier 304 of the new switchable segment 204 to the playlist 114 even though it has not received another segment boundary point 206 marking the end of the switchable segment 204 and the start of the next switchable segment 204. In the case of live content, as more of adaptive transport stream 110 is received in memory buffer 402 of HTTP streamer 106 and new switchable segments 204 are identified, HTTP streamer 106 may update playlist 114 with new segment identifiers 304.

When client device 108 uses playlist 114 to request switchable segments 204, HTTP streamer 106 may use segment boundary points 206 to identify the end points of the various switchable segments 204 within adaptive transport stream 110, and may thus encapsulate and/or deliver switchable segments 204 from continuous adaptive transport stream 110 to client device 108 that has requested them. HTTP may be used as a content delivery mechanism to transport switchable segments 204 from HTTP streamer 106 to requesting client device 108 over a network such as the internet or any other data network. HTTP streamer 106 may communicate the respective switchable segments 204 to client device 108 as segments of an adaptive bit rate streaming technique used by client device 108, such as MPEG-DASH, HTTP Live Streaming (HLS), or HTTP smooth streaming.

In some embodiments, the HTTP streamer 106 may use zero-copy fragmentation to transmit data associated with a single switchable segment 204 to the requesting client device 108. In these embodiments, HTTP streamer 106 may receive data from adaptive transport stream 110 into memory buffer 402, as shown in fig. 4. In some embodiments, the memory buffer 402 may hold up to a predetermined amount of data from the adaptive transport stream 110, such as the most recent n seconds of the received media content 102, the most recent n bytes received, the most recent n switchable segments 204 received, or any other metric of data.

Using zero-copy segmentation, when a particular switchable segment 204 has been requested by a client device 108, HTTP streamer 106 may transfer data associated with that switchable segment 204 directly from memory buffer 402 to the requesting client device 108 without first copying the data to a different storage location or copying the data to one or more separate files. By way of non-limiting example, HTTP streamer 106 may track bit ranges in its memory buffer 402 in received adaptive transport streams 110 corresponding to different switchable segments 204 within adaptive transport streams 110, and HTTP streamer 106 may use these bit ranges to provide requested switchable segments 204 to client device 108 directly from portions of adaptive transport streams 110 in memory buffer 402. Similarly, the HTTP streamer 106 may use zero-copy fragmentation to transfer individual delivery chunks 208 from the larger switchable segment 204 from the memory buffer 402 using zero-copy fragmentation to the client device 108.

The HTTP streamer 106 may use the Chunk Transport Encoding (CTE) as defined in HTTP 1.1 to sequentially deliver individual delivery chunks 208 from each requested switchable segment 204 to the requesting client device 108. As described above, each delivery block 208 may be selected to be as small as a single frame 202, or may be selected to be any other size between a single frame 202 and a complete switchable segment 204. In some embodiments, the HTTP streamer 106 may identify the start point and/or end point of each delivery chunk 208 within the requested switchable segment 204 from the chunk boundary points 210 added by the media preparation unit 104 during encoding of the adaptive transport stream 110.

With chunking encoding, the HTTP streamer 106 can begin transferring portions of the requested switchable segment 204 from its memory buffer 402 to the client device 108 as delivery chunks 208, even though the HTTP streamer 106 has not received the complete switchable segment 204 and does not know the complete size of the switchable segment 204.

By way of non-limiting example, HTTP streamer 106 may receive live broadcasts from media preparation unit 104 as adaptive transport stream 110 in substantially real-time. As soon as HTTP streamer 106 finds a segment boundary point 206 that indicates the start of a switchable segment 204 within adaptive transport stream 110, HTTP streamer 106 may use block boundary point 210 to identify a decodable delivery block 208 within that switchable segment 204. Once HTTP streamer 106 determines from the chunk boundary point 210 that HTTP streamer 106 has received a complete delivery chunk 208 in its memory buffer 402, HTTP streamer 106 may send the delivery chunk 208 to the requesting client device 108 even if HTTP streamer 106 has not received a further delivery chunk 208 from the switchable segment, or a further portion of adaptive transport stream 110 containing segment boundary point 206 indicating the end of switchable segment 204. HTTP streamer 106 may continue to receive more portions of adaptive transport stream 110 from media preparation unit 104 in real-time and may continue to send additional delivery blocks 208 to client device 108 until the next segment boundary point 206 in adaptive transport stream 110 is received and processed. At this point, the HTTP streamer 106 may send an indication to the client device 108 that the requested switchable segment 204 has terminated, such as the last delivery block 208 of length zero.

Fig. 5 depicts a first exemplary process for sending data from one or more adaptive transport streams 110 from an HTTP streamer 106 to a client device 108 using chunking encoding. The process of fig. 5 may be used when the media content 102 is a live broadcast and the client device 108 wishes to play back the live content in real-time.

At step 502, HTTP streamer 106 may receive adaptive transport stream description 112 associated with a segment of media content 102, such as a live broadcast, from media preparation unit 104. The adaptive transport stream description 112 may describe information about the media content 102 and one or more associated adaptive transport streams 110 available from the media preparation unit 104, such as different versions of the media content 102 encoded at different bitrates. Media preparation unit 104 may have encoded, or be encoding, each adaptive transport stream 110 identified in adaptive transport stream description 112 using segment boundary points 206 and block boundary points 210, segment boundary points 206 indicating the start and/or end points of respective switchable segments 204 within the continuous adaptive transport stream 110, and block boundary points 210 marking the start and/or end points of delivery blocks 208 within each switchable segment 204.

At step 504, the HTTP streamer 106 may publish the playlist 114 for the client device 108. The HTTP streamer 106 may use the adaptive transport stream description 112 to determine the quality levels available from the media preparation unit and list the virtual identifiers 302 of the most recent switchable segments 204 at each available quality level on the playlist 114, as shown in fig. 3A.

At step 506, HTTP streamer 106 may receive a request from client device 108 for the version of the most recent switchable segment 204. By way of a non-limiting example, the client device 108 can request the most recent switchable segment 204 at a desired level of quality using one of the virtual identifiers 302 on the playlist 114 for playback of the media content 102 in near real-time. If HTTP streamer 106 has not begun receiving adaptive transport stream 110 from media preparation unit 104, HTTP streamer 106 may join the multicast group associated with media preparation unit 104 and may begin receiving adaptive transport stream 110 into its memory buffer 402.

At step 508, the HTTP streamer 106 may use chunking transmission encoding to transmit the delivery chunks 208 from the requested switchable segments 204 to the requesting client device 108. In some embodiments, HTTP streamer 106 may send data associated with the requested switchable segment 204 directly from its memory buffer 402 to the requesting client device 108 using zero-copy segmentation.

The first delivery block 208 sent in response to the client device's request for the most recent switchable segment 204 may be the most recent complete delivery block 208 held in the memory buffer 402 of the HTTP streamer. The HTTP streamer 106 may use the block boundary points 210 inserted by the media preparation unit 104 to identify delivery blocks 208 within the portion of the adaptive transport stream 110 maintained in its memory buffer 402. By way of non-limiting example, fig. 6A depicts switchable segment 204 having been partially received into memory buffer 402 of an HTTP streamer. Although only a few frames 202 in a complete switchable segment 204 are received in memory, a complete delivery block 208 defined by block boundary points 210 has been received and the HTTP streamer 106 may send the delivery block 208 to the requesting client device 108. When media preparation unit 104 inserts block boundary point 210 within adaptive transport stream 110 to mark independently decodable portions of media content 102, client device 108 may immediately begin decoding delivery block 208 and playing back its frames 202 even if other portions of switchable segment 204 have not been received.

When responding to a request from client device 108, HTTP streamer 106 may track its location within switchable segment 204 such that the next delivery block 208 after the most recently sent delivery block 208 may then be sent to client device 108 as appropriate. By way of non-limiting example, fig. 6B depicts a scenario in which HTTP streamer 106 has sent a first delivery chunk 208 from switchable segment 204 to requesting client device 108, and then sends a second delivery chunk 208 from the same switchable segment when it receives and detects a chunk boundary point 210 indicating the end of second delivery chunk 208.

At step 510, HTTP streamer 106 may determine whether it has reached segment boundary point 206 within adaptive transport stream 110. If HTTP streamer 106 has not reached segment boundary point 206 within adaptive transport stream 110 after sending delivery chunks 208 to client device 108, HTTP streamer 106 may return to step 508 to transmit the next delivery chunk 208 from requested switchable segment 204 to the requesting client device 108 using chunking transport encoding. However, if HTTP streamer 106 determines during step 510 that it has reached segment boundary point 206 within adaptive transport stream 110, HTTP streamer 106 may determine that it has reached the end point of current switchable segment 204 and may move to step 512. By way of non-limiting example, fig. 6B-6C depict a scenario in which HTTP streamer 106 sends delivery block 208 to client device 108 and then encounters segment boundary point 206 as the next data segment within the portion of adaptive transport stream 110 in memory buffer 402 of HTTP streamer 106.

At step 512, the HTTP streamer 106 may transmit the terminate delivery block 208 to the client device 108 to indicate the end of the switchable segment 204 requested by the client device 108. As described above, in some embodiments, the stop delivery block 208 may have a length of zero. The terminate delivery block 208 may indicate to the requesting client device 108 that the last delivery block 208 associated with the requested switchable segment 204 has been sent and has reached the end of the switchable segment 204.

After receiving the terminate delivery block 208, the client device 108 can either use the playlist 114 to request the next switchable segment 204 from the adaptive transport stream 110 at the same or different quality level, or end playback of the media content 102.

During step 514, the HTTP streamer 106 may determine whether a new request for the switchable segment 204 has been received from the requesting client device 108. If client device 108 has requested another switchable segment 204, HTTP streamer 106 may return to step 508 to begin transmitting delivery chunks 208 of the requested switchable segment 204 to client device 108. If client device 108 has not requested additional switchable segments 204, the process may end and/or HTTP streamer 106 may wait for future requests for switchable segments 204.

Fig. 7 depicts a second exemplary process for transmitting data from one or more adaptive transport streams 110 to client device 108 from HTTP streamer 106 using chunking encoding. The process of fig. 7 may be used when the media content 102 is a live broadcast and the client device 108 wishes to play back the live content in near real-time, or when the media content 102 is live or pre-recorded and the client device 108 can traverse the content for a seek.

At step 702, HTTP streamer 106 may receive adaptive transport stream description 112 from media preparation unit 104 associated with a segment of media content 102. The adaptive transport stream description 112 may describe information about the media content 102 available from the media preparation unit 104 and one or more associated adaptive transport streams 110, such as different versions of the media content 102 encoded at different bitrates. Media preparation unit 104 may have encoded, or be encoding, each adaptive transport stream 110 identified in adaptive transport stream description 112 using segment boundary points 206 and block boundary points 210, segment boundary points 206 indicating the start and/or end points of the respective switchable segments 204 within the continuous adaptive transport stream 110, and block boundary points 210 marking the start and/or end points of delivery blocks 208 within each switchable segment 204.

After receiving adaptive transport stream description 112, HTTP receiver 106 may join the multicast group associated with media preparation unit 104 and may begin receiving adaptive transport stream 110 into its memory buffer 402. HTTP streamer 106 may examine the portion of adaptive transport stream 110 received in its memory buffer 402 for segment boundary points 206 marking the beginning of each switchable segment 204 within adaptive transport stream 110.

At step 704, the HTTP streamer 106 may publish the playlist 114 for the client device 108. The HTTP streamer 106 may list the segment identifiers 304 of the identified switchable segments on the playlist 114, as shown in fig. 3B. As described above, the HTTP streamer 106 may list incomplete switchable segments 204 on the playlist 114, such as switchable segments 204 from live broadcasts that have not been fully received in its memory buffer 402. By way of non-limiting example, when HTTP streamer 106 finds a segment boundary point 206 marking the beginning of a switchable segment 204 in a received portion of adaptive transport stream 110, it may list segment identifiers 304 of switchable segments 204 in playlist 114 even though a complete switchable segment 204 has not been received from media preparation unit 104.

In some embodiments, the playlist 114 may be continuously or periodically updated as more portions of the adaptive transport stream 110 are received from the media preparation unit 104. By way of non-limiting example, when media preparation unit 104 sends a live broadcast to HTTP streamer 106 as one or more adaptive transport streams 110, HTTP streamer 106 may issue an initial version of playlist 114 listing segment identifiers 304 that begin switchable segments 204 as soon as adaptive transport streams 110 from media preparation unit 104 are initially received by HTTP streamer 106. As more portions of the live broadcast are received, and as additional segment boundary points 206 are encountered marking the end of a switchable segment 204 and the beginning of the next switchable segment 204, the HTTP streamer 106 may publish a new playlist 114 or update a previous version of the playlist 114 to add segment identifiers 304 for the additional switchable segments 204.

At step 706, the HTTP streamer 106 may receive a request for the switchable segment 204 from the client device 108. By way of a non-limiting example, the client device 108 may use one of the segment identifiers 304 on the playlist 114 to request the most recently listed switchable segment 204 in the published playlist 114 for near real-time playback of the media content 102. As another non-limiting example, the client device 108 may request switchable segments 204 listed elsewhere in the playlist 114 to jump back to an earlier point in the video.

At step 708, the HTTP streamer 106 may use chunking transport encoding to transmit the delivery chunks 208 from the requested switchable segments 204 to the requesting client device 108. In some embodiments, HTTP streamer 106 may send data associated with the requested switchable segment 204 directly from its memory buffer 402 to the requesting client device 108 using zero-copy segmentation. The first delivery block 208 sent in response to the client device's request for the latest switchable segment 204 may be the most recent complete delivery block 208 held in the memory buffer 402 of the HTTP streamer 106. The HTTP streamer 106 may use the block boundary points 210 inserted by the media preparation unit 104 to identify delivery blocks 208 within the portion of the adaptive transport stream 110 maintained in its memory buffer 402. By way of non-limiting example, fig. 6A depicts switchable segment 204 having been partially received into memory buffer 402 of an HTTP streamer. Although only a few frames 202 in a complete switchable segment 204 are received in memory, a complete delivery chunk 208 defined by chunk boundary points 210 has been received, and the HTTP streamer 106 may send the delivery chunk 208 to the requesting client device 108. When media preparation unit 104 inserts block boundary point 210 within adaptive transport stream 110 to mark independently decodable portions of media content 102, client device 108 may immediately begin decoding delivery block 208 and playing back its frames 202 even if other portions of switchable segment 204 have not been received.

When responding to a request from client device 108, HTTP streamer 106 may track its location within switchable segment 204 such that the next delivery block 208 after the most recently sent delivery block 208 may then be sent to client device 108 as appropriate. As a non-limiting example, fig. 6B depicts a scenario in which the HTTP streamer 106 has sent a first delivery chunk 208 from a switchable segment 204 to the requesting client device 108, and then sends a second delivery chunk 208 from the same switchable segment when it receives and detects a chunk boundary point 210 indicating the end of the second delivery chunk 208.

At step 710, HTTP streamer 106 may determine whether it has reached segment boundary point 206 within adaptive transport stream 110. If HTTP streamer 106 has not reached segment boundary point 206 within adaptive transport stream 110 after sending delivery chunks 208 to client device 108, HTTP streamer 106 may return to step 708 to transmit the next delivery chunk 208 from requested switchable segment 204 to the requesting client device 108 using chunking transport encoding. However, if HTTP streamer 106 determines during step 710 that it has reached segment boundary point 206 within adaptive transport stream 110, HTTP streamer 106 may determine that it has reached the end point of current switchable segment 204 and may move to step 712. As a non-limiting example, fig. 6B-6C depict a scenario in which the HTTP streamer 106 sends a delivery block 208 to the client device 108 and then encounters a segment boundary point 206 as the next data segment within the portion of the adaptive transport stream 110 in the memory buffer 402 of the HTTP streamer 106.

At step 712, the HTTP streamer 106 may transmit the terminate delivery block 208 to the client device 108 to indicate the end of the switchable segment 204 requested by the client device 108. As described above, in some embodiments, the stop delivery block 208 may have a length of zero. The terminate transfer block 208 may indicate to the requesting client device 108 that the last delivery block 208 associated with the requested switchable segment 204 has been sent and the end of the switchable segment 204 has been reached.

During step 714, the HTTP streamer 106 may determine whether a new request for the switchable segment 204 has been received from the requesting client device 108. If client device 108 has requested another switchable segment 204, HTTP streamer 106 may return to step 708 to begin transmitting the delivery chunks 208 of the requested switchable segment 204 to client device 108. If client device 108 does not request additional switchable segments 204, the process may end and/or HTTP streamer 106 may wait for future requests for switchable segments 204.

The processes of fig. 5 and 7 may reduce or substantially eliminate tuning delay when the client device 108 initially requests a live video stream. By way of non-limiting example, in fig. 5, the client device 108 may use the virtual identifier 302 on the playlist 114 to automatically request the latest version of the switchable segment 204 from the live video stream, even though the HTTP streamer 106 has not received the full latest switchable segment. As another non-limiting example, as shown in fig. 7, HTTP streamer 106 may list a new switchable segment 204 on playlist 114 immediately after finding a starting segment boundary point 206 in adaptive transport stream 110, even though HTTP streamer 106 has not received the entire new switchable segment and client device 108 may request it as soon as the new switchable segment 202 appears on playlist 114.

Since delivery chunks 208 may be independently decodable portions of the larger switchable segment 204, HTTP streamer 106 may respond to requests for switchable segments 204 by sending individual delivery chunks 208 to requesting client devices 108, even though HTTP streamer 106 has not received the entire switchable segment 204. In this way, rather than waiting for the HTTP streamer 106 to receive a complete switchable segment 204 and for the complete switchable segment 204 to be sent to the client device 108, the client device 108 may begin playback of live video with a delay of only the size of the delivery chunk 208 after the adaptive transport stream 110 is received by the HTTP streamer 106. Since the delivery block 208 may be a single or partial GOP, or even individual frames 202, the initial tuning delay may be minimized. The minimization of the initial tuning time, in turn, can minimize latency in playback of subsequent portions of live content.

Execution of the sequences of instructions necessary to practice an embodiment may be performed by one or more computer systems 800, as shown in FIG. 8. By way of non-limiting example, media preparation unit 104, HTTP streamer 106, and/or client device 108 may be computer system 800. Although a description of one computer system 800 may be presented herein, it should be understood that any number of computer systems 800 may be employed that communicate with each other.

A computer system 800 according to one embodiment will now be described with reference to fig. 8, fig. 8 being a block diagram of the functional components of the computer system 800. As used herein, the term computer system 800 is used broadly to describe any computing device that can store and independently execute one or more programs.

Computer system 800 may include a communication interface 814 coupled to bus 806. Communication interface 814 may provide a two-way communication between computer systems 800. Communication interface 814 of respective computer system 800 may send and receive electrical, electromagnetic or optical signals, which include data streams representing various types of signal information, such as instructions, messages, and data. The communication link 815 may link one computer system 800 with another computer system 800. For example, the communication link 815 may be a LAN, an Integrated Services Digital Network (ISDN) card, a modem, or the Internet.

Computer system 800 can transmit and receive messages, data, and instructions, including programs such as applications or code, through its corresponding communication link 815 and communication interface 814. The received program code may be executed by a corresponding processor 807 as it is received, and/or stored in storage device 810, or other associated non-volatile storage for later execution.

In some embodiments, the computer system 800 may operate in conjunction with a data storage system 831, such as the data storage system 831 comprising a database 832 readily accessible by the computer system 800. Computer system 800 may communicate with data storage system 831 through data interface 833.

Computer system 800 may include a bus 806 or other communication mechanism for communicating instructions, messages, and data, collectively referred to as information, and one or more processors 807 coupled with bus 806 for processing information. Computer system 800 may also include a main memory 808, such as a Random Access Memory (RAM) or other dynamic storage device, coupled to bus 806 for storing dynamic data and instructions to be executed by processor 807. Computer system 800 may also include a Read Only Memory (ROM)809 or other static storage device coupled to bus 806 for storing static data and instructions for processor 807. A storage device 810, such as a magnetic disk or optical disk, may also be provided and coupled to bus 806 for storing data and instructions for processor 807.

Computer system 800 may be coupled via bus 806 to a display device 811, such as an LCD screen. An input device 812, such as alphanumeric and/or other keys, may be coupled to bus 806 for communicating information and command selections to processor 807.

According to one embodiment, the individual computer systems 800 perform specific operations by their respective processors 807, and the processors 807 execute one or more sequences of one or more instructions contained in main memory 808. Such instructions may be read into main memory 808 from another computer usable medium, such as ROM 809 or storage device 810. Execution of the sequences of instructions contained in main memory 808 causes processor 807 to perform the processes described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and/or software.

Although the present invention has been described in particular detail hereinabove, this was merely to teach one of ordinary skill in the art how to make and use the invention. Many additional modifications will fall within the scope of the invention, as that scope is defined by the appended claims.

Claims

1. A method of delivering media content, comprising:

receiving, at an HTTP streamer, an adaptive transport stream description from a media preparation unit, the adaptive transport stream description describing media content available from the media preparation unit as one or more adaptive transport streams, wherein each adaptive transport stream of the one or more adaptive transport streams is a continuous stream comprising a plurality of switchable segments, the switchable segments each comprising one or more delivery blocks, the switchable segments being labeled with segment boundary points and the delivery blocks being labeled with block boundary points, wherein a location between each switchable segment of the plurality of switchable segments is a location at which a client device can switch to a different adaptive transport stream of the one or more adaptive transport streams;

publishing, with the HTTP streamer, a playlist listing identifiers of one or more of the plurality of switchable segments, the switchable segments including delivery chunks;

receiving the one or more adaptive transport streams from the media preparation unit into a memory buffer at the HTTP streamer;

receiving, at the HTTP streamer from the client device, a request for a particular switchable segment identified on the playlist to be received at a requested bitrate;

responding to the request in the HTTP streamer by processing the received one of the plurality of adaptive transport streams in real-time transmission by:

continuing to receive a delivery block of switchable segments before the particular switchable segment until the delivery block reaches a segment boundary point;

identifying boundary markers for the one or more blocks only in the particular switchable segment; and

sending the one or more delivery chunks from the particular switchable segment to the client device at the requested bit rate using HTTP blocking transmission encoding until a termination segment boundary point is reached,

wherein each delivery chunk of the one or more delivery chunks is part of the particular switchable segment that is independently decodable by the client device, such that the HTTP streamer is configured to begin transmitting delivery chunks from the requested switchable segment when the HTTP streamer has not received additional switchable segments of the switchable segment from the media preparation unit, such that the client device begins decoding and rendering the received delivery chunks.

2. The method of claim 1, wherein the media content is a live broadcast.

3. The method of claim 1, wherein the segment boundary points are encoder boundary points inserted into private data when the media content is encoded according to an OpenCable standard.

4. The method of claim 1, wherein the segment boundary points are inserted into common data.

5. The method of claim 1, wherein the HTTP streamer publishes virtual identifiers on the playlist, the virtual identifiers each pointing to a switchable segment most recently received in part or in full from the media preparation unit.

6. The method of claim 1, wherein said HTTP streamer publishes segment identifiers on said playlist, said segment identifiers each pointing to a full switchable segment or a partial switchable segment identified by said HTTP streamer according to open and/or closed segment boundary points within said one or more adaptive transport streams.

7. The method of claim 6, wherein when said HTTP streamer encounters a starting segment boundary point marking the start of a new switchable segment in said one or more adaptive transport streams, a new segment identifier is added to said playlist.

8. The method of claim 1, further comprising: upon reaching the termination segment boundary point, sending a termination delivery block of length zero to the client device.

9. The method of claim 1, further comprising: transmitting each of the delivery blocks to the client device using a zero-copy segmentation within the memory buffer, wherein bits in the memory buffer corresponding to a single delivery block identified by an open boundary point and/or a closed block boundary point are transferred directly from the memory buffer to the client device.

10. The method of claim 1, wherein said HTTP streamer receives said adaptive transport stream ready including all boundary markers for said switchable segment identifications and markers, and wherein said HTTP streamer incrementally transmits said chunks in response to a media request by said client.