Method and Apparatus for Processing Video

This application is a continuation of U.S. application Ser. No. 17/248,575 filed Jan. 29, 2021, which is hereby incorporated by reference in its entirety as if fully set forth herein.

A user device requesting a transcoded video may request a video encoded at a particular bit rate, but the user device may have very little knowledge of its network's capacity. If a user device selects a video fragment with a bit rate that is too high for their network, the video playback experience may be poor. More efficient video processing methods are desired.

Systems and methods are described for processing video content. Content may be encoded/transcoded for delivery to a computing device that requested content. The content may be encoded as temporally interlaced blocks, which interlaces frames in the content with respect to time. Because the frames are temporally interlaced, receiving only a portion of the temporally interlaced blocks is still sufficient to play back a full-length video at a reduced quality (e.g., at a reduced bit rate or lower resolution). The CDN or computing device may also dynamically select the video bit rate by terminating the network connection. For example, if network conditions are poor, the CDN or computing device may terminate the network connection causing the computing device to decode the partially received temporally interlaced blocks and play back the reduced quality version of the video content.

Systems and methods are described for processing content. Content may be encoded/transcoded for delivery via a network (e.g., the content origin, CDN, or other intermediary service) to a playback device such as a computing device. The computing device may decode and/or display the content. The terms transcode and encode may be used interchangeably herein. The techniques for video processing described herein may be applicable to any delivery method including but not limited to Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP) (DASH), HTTP Live Streaming (HLS), the QAM digital television standard, and ABR streaming.

shows systemconfigured for video processing. The systemmay comprise a video data source, an encoder/transcoder, a CDN, and a computing device. The CDNmay comprise a CDN or other intermediary service. The video data source, the encoder/transcoder, the CDN, the computing device, and/or any other component of the systemmay be interconnected via a network. The networkmay comprise a wired network, a wireless network, or any combination thereof. The networkmay comprise a public network, such as the Internet. The networkmay comprise a private network, such as a content provider's distribution system. The networkmay communicate using technologies such as WLAN technology based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, wireless cellular technology, Bluetooth, coaxial cable, Ethernet, fiber optics, microwave, satellite, Public Switched Telephone Network (PTSN), Digital Subscriber Line (DSL), BPL, or any other appropriate technologies.

The computing devicemay comprise a user device, a client device, a television, a monitor, a laptop, a desktop, a smart phone, a set-top box, a cable modem, a gateway, a tablet, a wearable computing device, a mobile computing device, any computing device configured to receive and/or playback video, the like, and/or any combination of the foregoing. The computing devicemay comprise a decoder, a buffer, and a video player. The computing device(e.g., the video player) may be communicatively connected to a display. The displaymay be a separate and discrete component from the computing device, such as a television display connected to a set-top box. The displaymay be integrated with the computing device. The decoder, the video player, the buffer, and the displaymay be realized in a single device, such as a laptop or mobile device. The decodermay decompress/decode encoded video content. The encoded video content may be received from the encoder/transcoderor the CDN.

The CDNmay comprise one or more computing devices such as serversA,B,C. The one or more serversA,B,C of the CDNmay be configured to act as intermediary servers located between the computing deviceand the video data source. The one or more serversA,B,C of the CDNmay serve cached content to the computing device. The cached content may comprise video content such as one or more video fragments. The CDNmay receive a request for content from the computing device. The CDNmay authorize/authenticate the request and/or the computing devicefrom which the request originated. The request for content may comprise a request for video content, a channel, a video on-demand asset, a website address, a video asset associated with a streaming service, the like, and/or any combination of the foregoing. The CDNmay send the request to the video data source.

The video data sourcemay comprise a broadcast source, a headend, a server (e.g., a server streaming video or a video on-demand server), a cable modem termination system, the like, and/or any combination of the foregoing. The video data sourcemay send uncompressed, raw video data comprising a sequence of frames. The frames may comprise pixels. A pixel may comprise a smallest controllable element of a frame. A frame may comprise bits for controlling each associated pixel. A portion of the bits for an associated pixel may control a luma value (e.g., light intensity) of each associated pixel. A portion of the bits for an associated pixel may control one or more chrominance value (e.g., color) of the pixel.

The video data sourcemay receive requests for content (e.g., video data) from the encoder/transcoder, the computing device, or the CDN. The video data sourcemay send uncompressed video data to the encoder/transcoderbased on a request for content from the encoder/transcoder, the computing device, or the CDN. The video data source, the encoder/transcoder, and the CDNmay also be co-located at a premises in multiple devices or a single device, located at separate premises, or associated with separate instances in the cloud.

The encoder/transcodermay encode/transcode the content received from the video data source. The encoder/transcodermay receive uncompressed video data (e.g., plurality of frames) from the video data source(either through the same channel/format or via different channels). The encoder/transcodermay encode (e.g., compress) the uncompressed video data to generate encoded content. The encoder/transcodermay comprise a codec comprising an encoder and decoder. The codecs described herein may be based on standards including but not limited to H.265/MPEG—High Efficiency Video Coding (HEVC), H.264/MPEG—Advanced Video Coding (AVC), or Versatile Video Coding (VVC).

Transcoding video may result in video fragments encoded at numerous bit rates. Computing devices may request a video fragment at a bit rate based on the performance of their network. For example, computing devices communicating via networks with higher available bandwidth may request higher quality video fragments (e.g., video fragments transcoded at higher bit rates). If a video fragment is selected with a bit rate that is too high for their network, the video playback experience may be poor. For example, the time-to-first-frame may be undesirably long. Further, because these video fragments are temporally linear, if a video fragment download fails, the same video fragment must be requested again, or playback of the video content may be disrupted or incomplete.

The systemmay be configured to process content encoded in a plurality of temporally interlaced blocks. Spatial interlacing involves interlacing an image such that the entire image can be displayed at various levels of quality as the image file is received. For example, spatial interlacing allows web browsers to display a fuzzy-but-complete image when the image is only partially downloaded and to display a progressively clearer image as the full file is completely downloaded. Temporally interlacing video comprises spatially interlacing each frame of the video with respect to time. Video file formats typically include the entire first frame, followed by the entire second frame, and so on. A temporally interlaced video file may comprise a portion of each of one or more frames. For example, a temporally interlaced video file may comprise a portion of the first frame, followed by a portion of the second frame, and so on. For example, a temporally interlaced video file may comprise one byte of the first frame, followed by one byte of the second frame, and so on.

Encoding video into temporally interlaced blocks may enable dynamic selection of a video bit rate. For example, encoding video into temporally interlaced blocks may enable the content origin such as the video data source, the CDN(or other intermediary service), or the computing deviceto select a video bit rate dynamically. For example, the bit rate may be determined dynamically by displaying a portion of a video file causing a reduced quality version of the video to be displayed. The bit rate may be selected dynamically based on network conditions. Additionally, if a connection between the CDNand the computing deviceis terminated before a full-length video is delivered, the computing devicemay still view a reduced quality version of the full-length video if the frames have been temporally interlaced based on the techniques disclosed herein.

The encoder/transcodermay encode the content into a plurality of blocks. The plurality of blocks may be temporally interlaced. Each block of the plurality of blocks may comprise a portion of a frame of the plurality of frames. The portion may comprise a plurality of bytes of the frame. The encoder/transcodermay send the encoded content to the requesting component, such as the CDNor the computing device. The decoder may receive the compressed video and decode the video (e.g., into a decompressed format). Because the blocks are temporally interlaced, the computing devicemay receive portions of each frame in a video before receiving further portions of the same frame. As a result, once the computing devicereceives a number of blocks matching the total number of frames in the video, the computing devicehas enough video data to decode/display a complete image/fragment of the video, at least at a reduced quality.

shows an example video file formatfor video content encoded as a plurality of temporally interlaced blocks. The video file format may comprise one or more of the following: information indicating a time to display each frame, information indicating a quantity of frames in the video, and the encoded plurality of temporally interlaced blocks. The quantity of frames in the videomay be encoded, to indicate to a playback computing device where a second block for the first frame begins. For example, if each block is 5 bytes, and there are 10 frames in the video, then the first block for the first frame comprises bytes 1-5 and the second block of the first frame comprises bytes 51-55, and so on.

shows an example data formatfor video content encoded as a plurality of temporally interlaced blocks. Each temporally interlaced block, of the plurality of temporally interlaced blocks, may comprise a portion of one of the three frames of the video content. For example, each temporally interlaced block may comprise a portion of the bytes in a frame. For example,shows a plurality of blocks and each block comprises a portion of one of the three frames: a first block for the first frame (frame 0, block 0), a first block for the second frame (frame 1, block 0), a first block for the third frame (frame 2, block 0), a second block for the first frame (frame 0, block 1), a second block for the second frame (frame 1, block 1), a second block for the third frame (frame 2, block 1), a third block for the first frame (frame 0, block 2), a third block for the second frame (frame 1, block 2), and a third block for the third frame (frame 2, block 2).

shows an example methodfor encoding.shows the input videoand the output video. The input video may comprise frame 0 comprising blocks 0-4, frame 1 comprising blocks 0-4, and frame 2 comprising blocks 0-4. At step, an encoding device (e.g., a computing device comprising a codec or an encoder) may determine the number of frames per time interval and any other metadata. The determination may indicate the milliseconds per frame and the other metadata. The determining may be based on a request for content from a computing device. The request may be received by a content origin, CDN, or other intermediary service. The frames per time interval may indicate that there are 10 frames per time interval. The metadata may comprise other format information associated with the video content. At step, the encoding device may determine the number of frames in the video. The number of frames in the video may comprise 3 frames.

At step, the encoding device may encode the first block for each frame. A first plurality of temporally interlaced blocksmay comprise frame 0, block 0; frame 1, block 0; and frame 2, block 0. The first plurality of temporally interlaced blocksmay comprise a first portion of each frame of the input video.

At step, the encoding device may encode a second plurality of temporally interlaced blocks. The second block for each framemay comprise frame 0, block 1; frame 1, block 1; and frame 2, block 1. The second plurality of temporally interlaced blocksmay comprise a second portion of each frame of the input video.

At step, the encoding device may continue encoding blocks for the remaining portions of the frames to complete encoding of the output video. The remaining blocks may comprise the third block of each framecomprising frame 0, block 2; frame 1, block 2; and frame 2, block 2. The remaining blocks may comprise the fourth block of each framecomprising frame 0, block 3; frame 1, block 3; and frame 2, block 3. The remaining blocks may comprise the fifth block of each framecomprising frame 0, block 4; frame 1, block 4; and frame 2, block 4.

shows an example method. While each step in the methodofis shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, concurrently with each other, or serially with each other. The example methoddepicts streaming video from a CDNto a computing devicewith a high bandwidth connection. At step, a request for video content may be received by the CDNand from the computing device. The computing devicemay comprise any device comprising a codec/decoder. The video content may comprise a plurality of video fragments. The video content may comprise a 12 MB, 2-second video fragment. The CDNmay comprise a CDN or other intermediary service.

At step, the CDNmay encode the video fragment as a plurality of temporally interlaced blocks. Each temporally interlaced block, of the temporally interlaced plurality of blocks, may comprise a portion of a frame of the video content. For example, each temporally interlaced block may comprise a portion of the bytes in a frame. For example, the CDNmay encode a first block for a first frame, a first block for a second frame, and a first block for every subsequent frame in the video content. Once every first block for every frame is encoded, the CDNmay encode a second block for the first frame, a second block for the second frame, and a second block for every subsequent frame in the video content. The CDNmay continue encoding blocks for each remaining portion of each frame.

At step, the CDNmay stream the encoded 12 MB video fragment to the computing device. The CDNmay have a stable connection with the computing deviceenabling the CDNto stream the full video fragment to the computing devicein 1 second. This may cause the computing deviceto successfully receive the highest video bit rate in sufficient time to play back the full video.

shows an example method. While each step in the methodofis shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, concurrently with each other, or serially with each other. The example methoddepicts streaming video from a CDNto a computing devicethat may have a network connection with insufficient bandwidth for playback of a high bit rate video. At step, a request for video content may be received by the CDNand from the computing device. The computing devicemay comprise any device comprising a codec/decoder. The video content may comprise a plurality of video fragments. The video content may comprise a 12 MB, 2-second video fragment. The CDNmay comprise a CDN or other intermediary service.

At step, the CDN may encode the video fragment as a plurality of temporally interlaced blocks. Each temporally interlaced block, of the temporally interlaced plurality of blocks, may comprise a portion of a frame of the video content. For example, each temporally interlaced block may comprise a portion of the bytes in a frame. For example, the CDNmay encode a first block for a first frame, a first block for a second frame, and a first block for every subsequent frame in the video content. Once every first block for every frame is encoded, the CDNmay encode a second block for the first frame, a second block for the second frame, and a second block for every subsequent frame in the video content. The CDNmay continue encoding blocks for each remaining portion of each frame.

At step, the CDNmay stream the encoded 12 MB video fragment to the computing device. The CDNmay have a poor connection with the computing deviceenabling the CDNto only stream 6 MB of the 12 MB video fragment to the computing devicein 1.9 seconds. This performance may cause the computing deviceto have insufficient time to play back the full video. This poor performance may be based on low bandwidth available in the network.

At step, the CDNmay determine that the computing devicewill be unable to playback the full 2-second video fragment because it will take longer than 2 seconds to stream the full video to the computing device. At step, the CDNmay terminate the connection with the computing device. Terminating the connection may terminate streaming of video fragment. Because the video fragment was encoded as a plurality of temporally interlaced blocks, terminating the connection may cause playback, by the computing device, of the video fragment at the highest possible bit rate for the computing device. For example, decoding each first block of every frame causes the video fragment to be played back at a reduced quality (e.g., at a low quality bit rate or resolution). By decoding each subsequent block of every frame that was received prior to the connection termination, the video fragment may be played back at increasingly improved quality until the computing devicereaches the highest bit rate that it is capable of playing back. For example, the video fragment may be played back at a lower quality (e.g., a low quality bit rate or resolution) than the original 12 MB video fragment.

shows an example method. While each step in the methodofis shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, concurrently with each other, or serially with each other. The example methoddepicts streaming video from a CDNto a computing devicethat may have a network connection with insufficient bandwidth for reception of a high bit rate video from the content origin. At step, a request for video content may be received by the CDNand from the computing device. The computing devicemay comprise any device comprising a codec/decoder. The video content may comprise a plurality of video fragments. The video content may comprise a 12 MB, 2-second video fragment. The CDNmay comprise a CDN or other intermediary service.

At step, the CDNmay request the video fragment from the content origin. At step, the content originmay encode the video fragment as a plurality of temporally interlaced blocks. Each temporally interlaced block, of the temporally interlaced plurality of blocks, may comprise a portion of a frame of the video content. For example, each temporally interlaced block may comprise a portion of the bytes in a frame. For example, the content originmay encode a first block for a first frame, a first block for a second frame, and a first block for every subsequent frame in the video content. Once every first block of every frame is encoded, the content originmay encode a second block for the first frame, a second block for the second frame, and a second block for every subsequent frame in the video content. The content originmay continue encoding blocks for each remaining portion of each frame.

At step, the content originmay send, in one second, only 6 MB of the 12 MB, 2-second video fragment. This performance may cause the computing deviceto have insufficient time to play back the full video. This poor performance may be based on low bandwidth available in the network. At step, the CDNmay determine that it would take at least one second to respond to the computing device. At step, the CDNmay stream the 6 MB of the video fragment providing the computing devicewith a dynamically determined bit rate. The bit rate is dynamically determined because the video fragment was encoded as a plurality of temporally interlaced blocks causing the computing deviceto play back the full video fragment even though only 6 MB of the 12 MB video was delivered. For example, decoding each first block of every frame causes the video fragment to be played back at a reduced quality (e.g., at a low quality bit rate or resolution). By decoding each subsequent block of every frame of the 6 MB video fragment, the video is played back at increasingly improved quality until the computing devicedecodes the 6 MB video fragment. At step, the content originmay stream, to the CDN, the remaining 6 MB of the video content. A maximum bit rate version of the video may then be stored in the CDN(e.g., in a cache). The CDNmay then provide the full 12 MB video to other computing devices in response to future requests.

shows an example method. While each step in the methodofis shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, concurrently with each other, or serially with each other. The example methoddepicts streaming video from a CDNto a computing devicethat may have received only a portion of the video from the content origin. At step, a request for video content may be received by the CDNand from the computing device. The computing devicemay comprise any device comprising a codec/decoder. The video content may comprise a plurality of video fragments. The video content may comprise a 12 MB, 2-second video fragment. The CDNmay comprise a CDN or other intermediary service.

At step, the CDNmay request the video fragment from the content origin. At step, the content originmay encode the video fragment as a plurality of temporally interlaced blocks. Each temporally interlaced block, of the temporally interlaced plurality of blocks, may comprise a portion of a frame of the video content. For example, each temporally interlaced block may comprise a portion of the bytes in a frame. For example, the content originmay encode a first block for a first frame, a first block for a second frame, and a first block for every subsequent frame in the video content. Once every first block of every frame is encoded, the content originmay encode a second block for the first frame, a second block for the second frame, and a second block for every subsequent frame in the video content. The content originmay continue encoding blocks for each remaining portion of each frame.

At step, the content originmay send, in one second, 11 MB of the 12 MB, 2-second video fragment, and then the connection between the content originand CDNmay fail. At step, the CDNmay determine that 11/12 of the video is sufficient to send to the computing device. For example, this determination may be made heuristically. At step, the CDNmay stream the 11 MB of the video fragment providing the computing devicewith a dynamically determined bit rate that is at a slightly reduced quality. The bit rate is dynamically determined because the video fragment was encoded as a plurality of temporally interlaced blocks causing the computing deviceto play back the full video fragment even though a slightly reduced quality version of the video was provided (11 MB of the 12 MB). For example, decoding each first block of every frame causes the video fragment to be played back at a reduced quality (e.g., at a low quality bit rate or resolution). By decoding each subsequent block of every frame of the 11 MB video fragment, the video is played back at increasingly improved quality until the computing devicedecodes the 11 MB video fragment. At step, the CDNmay send a request for the remaining bytes of the video. The request may, for example, comprise a range request or other partial data request mechanism. A maximum bit rate version of the video may then be stored in the CDN(e.g., in a cache). The CDNmay then provide the full 12 MB video to other computing devices in response to future requests.

shows an example method. The methodof, may be performed by any device, for example, by any of the devices depicted inor described herein. While each step in the methodofis shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, concurrently with each other, or serially with each other. At step, a request for video content may be received from a computing device. For example, a CDN may receive a request for video content from a computing device. The CDN may send the request to a content origin. The video content may comprise at least one of: one or more video fragments; one or more video segments; or streamed video content such as a program, show, or movie. At step, a quantity of frames, associated with the video content, may be determined. For example, the CDN or the content origin may determine the quantity of frames associated with the video content. The quantity of frames may represent a time interval within a video or the full length of the video.

At step, based on the quantity of frames, a plurality of temporally interlaced blocks of the video content may be encoded. Each temporally interlaced block, of the temporally interlaced plurality of blocks, may comprise a portion of a frame of the video content. Each temporally interlaced block may comprise a portion of the bytes in a frame. The plurality of temporally interlaced blocks may comprise a sequence of each portion of each frame of video content. For example, the CDN or the content origin may encode a first block of a first frame, a first block of a second frame, and a first block of every subsequent frame in the video content. Once every first block of every frame is encoded, the CDN or content origin may encode a second block of the first frame, a second block of a second frame, and a second block of every subsequent frame in the video content. The CDN or content origin may continue encoding blocks for each remaining portion of each frame.

As a result of the frames of video content having been encoded as a plurality of temporally interlaced blocks, the bit rate of the video content may be determined dynamically. For example, the CDN or the content origin encoding the video the video may select the bit rate of the video content. The CDN or the content origin may use a determination of the computing device's bandwidth and/or latency, factored with the quantity of frames (e.g., the length of the video content or video fragment length), to determine the bit rate. Alternatively, the CDN or the content origin may use a hard-coded or configurable bit rate when encoding video, which may be less than the true maximum bit rate or file size that is being encoded. To select a bit rate lower than the maximum, the CDN may terminate the connection to the computing device as though the complete file had been sent, which causes the computing device to display the blocks received prior to the termination. If the quantity of blocks is as least as much as the determined quantity of frames, a full-length fragment of the video content is able to be displayed, at least at a low quality (e.g., low quality bit rate or resolution). This allows the CDN to serve a partially successful result, which represents the complete video fragment length at a reduced quality (e.g., at a low quality bit rate or resolution), but without temporal interlacing, the CDN cannot send the complete video length.

With traditional non-interlaced video using variant manifests for bit rates, a CDN or the content origin cannot choose a bit rate, and it serves whichever files the computing device requests. The techniques disclosed herein enable a CDN or the content origin to select a bit rate. This results in reduced computational cost because the CDN or the content origin encodes the video content with a single transcoding/encoding instead encoding more than one variant. This feature allows the CDN or the content origin to select a bit rate and effectively transcode on the fly with zero computational cost. The CDN may store only one copy of each video to cache. With streaming video technologies (e.g., technologies based on fragments and manifests, such as HLS or DASH), the CDN caches multiple variant manifests for every bit rate, as well as fragments of the same video at every encoded bit rate. With temporal interlacing, variants become unnecessary, and so the CDN may cache only a single copy of the video, reducing not only storage costs, but also reducing origin requests, internal CDN tier traffic, and computing device requests. Reduced storage costs on a CDN also result in increased cache efficiency.

For example, a content origin may provide an 4K resolution video. Instead of transcoding the full 4K resolution video, the content origin may determine that it may only serve a 1080p resolution at the time. This determination may be based on network conditions at that time. The content origin may encode a single 4K video at its highest resolution, and send a 1080p video to the CDN and to computing devices for playback, simply by encoding the video content as a plurality of temporally interlaced blocks and truncating and only sending ¼ of the file.

At step, at least a same quantity of the plurality of temporally interlaced blocks as the quantity of frames, may be sent, to the computing device. This may cause decoding/display, by the computing device, of a full-length fragment of the video content. For example, decoding each first block of every frame causes a full-length fragment of the video content to be displayed at a reduced quality (e.g., low quality bit rate or resolution). By decoding each subsequent block of every frame, the full-length fragment of the video content is displayed at increasingly improved quality. For example, a computing device may receive each first block of every frame from a CDN, and the connection to the CDN may terminate. The computing device may decode each first block of every frame causing display of a full-length fragment of the video content to be displayed at a low quality (e.g., low quality bit rate or resolution). The CDN or the computing device may reestablish the connection so that the remaining blocks of the plurality of blocks are sent.

This technique may enable the computing device to select a bit rate for the video content. The bit rate selection may be based on the computing device's connection determination. The computing device may select the bit rate by, for example, terminating the connection after a given number of bytes are received or by sending an HTTP Range Request or other partial data request mechanism. With traditional non-temporally-interlaced video technologies which use variant manifests for variable bit rate, the computing device may select the bit rate, but this may require a new HTTP and potentially new TCP connection. With traditional non-temporally-interlaced video technologies, the computing device also needs to know the desired bit rate before the request is initiated, and it may require the computing device to request multiple bit rates in order to quickly downshift variants.

For example, in poor network conditions, the computing device may playback a same quantity of the encoded plurality of temporally interlaced blocks as the quantity of frames to allow the computing device to watch an uninterrupted video (at a reduced quality), where an intermittent network would otherwise make a traditional video fragment result in black screens for the missing period of time. The computing device may also shift quality of video without a new request, by continuing to receive a file as long as the computing device has the capability to play it back (for example up to 2 seconds for a 2-second fragment). This enables the computing device to more efficiently upshift and downshift requests. With traditional video fragments, the computing device must send a new request, incurring the overhead of a new HTTP request and potentially new TCP connection.

With temporal interlacing, the computing device may determine to upshift or downshift during a request, and simply terminate the connection sooner or later, without requiring a new request for the new bit rate. The computing device may achieve a dynamic time-to-first-frame. On the first request the computing device may receive a same quantity of the encoded plurality of temporally interlaced blocks as the quantity of frames (e.g., a portion of the bytes of the full video), then determine a tradeoff between how high quality the computing device desired to display the first frame, versus how long to wait with a black screen until displaying the first frame.

For example, the computing device may select a low time-to-first-frame for a first fragment of the video and receive more bytes for a highest possible bit rate for its bandwidth with the next fragment. The computing device may also dynamically determine latency and bandwidth during the first request and terminate it if the computing device determines it has reached the desired ratio of quality to time. With traditional video, the computing device must predict beforehand its network performance, and if the prediction is incorrect, the time-to-first-frame will be longer than necessary, or the quality poorer than necessary.

shows an example method. The methodof, may be performed by any device, for example, by any of the devices depicted inor described herein. While each step in the methodofis shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, concurrently with each other, or serially with each other. At step, a request for video content may be sent. For example, a computing device may send the request to a CDN. The CDN may send the request to a content origin. The video content may comprise at least one of: one or more video fragments; one or more video segments; or streamed video content such as a program, show, or movie.

At step, based on the request, a plurality of temporally interlaced blocks of the video content may be received. Each temporally interlaced block, of the temporally interlaced plurality of blocks, may comprise a portion of a frame of the requested video content. Each temporally interlaced block may comprise a portion of the bytes in a frame. The plurality of temporally interlaced blocks may comprise a sequence of each portion of each frame of video content. The plurality of temporally interlaced blocks may comprise at least a same quantity as a quantity of frames associated with the video content.

For example, the CDN or the content origin may have encoded a first block of a first frame, a first block of a second frame, and a first block of every subsequent frame in the video content. Once every first block of every frame is encoded, the CDN or content origin may have encoded a second block of the first frame, a second block of a second frame, and a second block of every subsequent frame in the video content. The CDN or content origin may have continued encoding blocks for each remaining portion of each frame.

As a result of the frames of video content having been encoded as a plurality of temporally interlaced blocks, the bit rate of the video content may be determined dynamically. For example, the CDN or the content origin encoding the video the video may select the bit rate of the video content. The CDN or the content origin may use a determination of the computing device's bandwidth and/or latency, factored with the quantity of frames (e.g., the length of the video content or video fragment length), to determine the bit rate. Alternatively, the CDN or the content origin may use a hard-coded or configurable bit rate when encoding video, which may be less than the true maximum bit rate or file size that is being encoded. To select a bit rate lower than the maximum, the CDN may terminate the connection to the computing device as though the complete file had been sent, which causes the computing device to display the blocks received prior to the termination. If the quantity of blocks is as least as much as the determined quantity of frames, a full-length fragment of the video content is able to be displayed, at least at a low quality (e.g., low quality bit rate or resolution). This allows the CDN to serve a partially successful result, which represents the complete video fragment length at a reduced quality (e.g., at a low quality bit rate or resolution), but without temporal interlacing, the CDN cannot send the complete video length.

At step, the plurality of temporally interlaced blocks may be decoded by the computing device. This may cause output, by the computing device, of a full-length fragment of the video content. For example, decoding each first block of every frame causes a full-length fragment of the video content to be displayed at a reduced quality (e.g., low quality bit rate or resolution). By decoding each subsequent block of every frame, the full-length fragment of the video content is displayed at increasingly improved quality. For example, the computing device may receive each first block of every frame from a CDN, and the connection to the CDN may terminate. The computing device may decode each first block of every frame causing display of a full-length fragment of the video content to be displayed at a low quality (e.g., low quality bit rate or resolution). The CDN or the computing device may reestablish the connection so that the remaining blocks of the plurality of blocks are sent.

This technique may enable the computing device to select a bit rate for the video content. The bit rate selection may be based on the computing device's connection determination. The computing device may select the bit rate by, for example, terminating the connection after a given number of bytes are received or by sending an HTTP Range Request or other partial data request mechanism. With traditional non-temporally-interlaced video technologies which use variant manifests for variable bit rate, the computing device may select the bit rate, but this may require a new HTTP request and potentially new TCP connection. With traditional non-temporally-interlaced video technologies, the computing device also needs to know the desired bit rate before the request is initiated, and it may require the computing device to request multiple bit rates in order to quickly downshift variants.

For example, in poor network conditions, the computing device may playback a same quantity of the encoded plurality of temporally interlaced blocks as the quantity of frames to allow the computing device to watch an uninterrupted video (at a reduced quality), where an intermittent network would otherwise make a traditional video fragment result in black screens for the missing period of time. The computing device may also shift quality of video without a new request, by continuing to receive a file as long as the computing device has the capability to play it back (for example up to 2 seconds for a 2-second fragment). This enables the computing device to more efficiently upshift and downshift requests. With traditional video fragments, the computing device must send a new request, incurring the overhead of a new HTTP request and potentially new TCP connection.