Patent Description:
Switching from one stream to another stream occurs at stream access points (SAP) located at the start of each segment within a stream. In conventional systems, an instantaneous decoder refresh (IDR) frame is used for each SAP. IDR frames are used as SAPs because they instruct the client device's decoder to reset its picture reference buffer thereby preventing the decoder from referencing previous frames from the previous stream with a bitrate, resolution, or quality that may no longer be applicable because of the changed network conditions.

However, when network conditions are steady, the use of IDR frames throughout an ABR stream results in resetting the picture reference buffer unnecessarily whenever an IDR frame is decoded within the stream. Video quality and video compression efficiency would be improved if unnecessarily resetting the picture reference buffer could be avoided. Accordingly, there is a need for improved ABR techniques.

Systems and methods are described herein for processing video. An encoder implementing the systems and methods described herein may generate, for a sequence of video frames, a plurality of first segments and a plurality of second segments. The plurality of first segments may comprise stream access points (SAPs) of a first type that do not reset a picture reference buffer. The plurality of second segments may comprise SAPs of a second type that do reset the picture reference buffer. The encoder may send first segments of the plurality of first segments to a computing device streaming video when network conditions are steady. The encoder may send a second segment of the plurality of second segments following a switch, by the computing device, to a different bitrate based on a change to the network conditions. Once the computing device has decoded the second segment, the encoder may send subsequent first segments at the different bitrate.

The following drawings show generally, by way of example, but not by way of limitation, various examples discussed in the present disclosure. In the drawings:.

Systems and methods are described herein for processing video. Video content may comprise video frames or other images. Video frames may comprise pixels. A pixel may comprise a smallest controllable element of a video frame. A video 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 may be processed by a video codec comprising an encoder and decoder. When video frames are transmitted from one location to another, the encoder may encode the video (e.g., into a compressed format) using a compression technique prior to transmission. The decoder may receive the compressed video and decode the video (e.g., into a decompressed format).

A group of pictures (GOP) may start with an intra-coded picture (I-frame), which comprises a complete image, or an instantaneous decoder refresh (IDR) frame. An IDR frame may be referred to as a refresh frame because it resets a picture reference buffer in the decoder so that subsequent frames cannot refer to any frames prior to the IDR frame. In contrast, with an I-frame, the decoder can continue to reference frame information prior to the I-frame.

Frames in a GOP may also comprise a predicted picture (P-frame), which comprises only the changes in the image from a previous frame. For example, only movement from the previous frame may be encoded in the P-frame, which saves space because unchanged pixels do not need be encoded in the P-frame.

Frames in a GOP may also comprise a bidirectional predicted picture (B-frame) comprising differences between the current frame and both a previous frame and a subsequent frame, which therefore saves space by encoding fewer pixels than a P-frame.

The embodiments described herein are directed to enhancements in Adaptive Bitrate (ABR) streaming, which as described above, is used to encode a video input stream into multiple streams at different bitrates. Each ABR stream may be referred to herein as a variant. Each variant may comprise one or more segments that each comprise a plurality of frames. The enhancements described herein cause improved video quality for an ABR system and also cause improvements in the efficiency of the video compression of the ABR segments.

The ABR segments in the embodiments described herein comprise two segments for each segment. The first of the two segments may begin with an I-frame. When network conditions are steady, and no variant switch is needed, a computing device that is streaming content may continue to request and decode ABR segments that begin with I-frames. As noted above, using I-frames enables the decoder to reference frame data from previous frames and segments. This enhancement improves the quality of the video playback because referencing frame data from previous segments causes a smoother viewing experience. Further, referencing frame data from previous frames and segments enables the system to encode less frame data or fewer frames per each segment, resulting in improved compression.

When network conditions change (e.g., changing network bandwidth, channel changes, time shifting, etc.), the computing device may request and decode an ABR segment of a new variant, and the first ABR segment of the new variant may begin with an IDR frame. Once the first segment of the new variant is decoded, the computing device may begin requesting and decoding ABR segments of the new variant that each begin with an I-frame. Requesting and decoding ABR segments beginning with an I-frame may continue until another variant switch is performed.

<FIG> shows a system <NUM> configured for video processing. The system <NUM> may comprise a video data source <NUM>, an encoder <NUM>, a content delivery system <NUM>, a computing device <NUM>, and a video archive system <NUM>. The video archive system <NUM> may be communicatively connected to a database <NUM> to store archived video data.

The video data source <NUM>, the encoder <NUM>, the content delivery system <NUM>, the computing device <NUM>, the video archive system <NUM>, and/or any other component of the system <NUM> may be interconnected via a network <NUM>. The network <NUM> may comprise a wired network, a wireless network, or any combination thereof. The network <NUM> may comprise a public network, such as the Internet. The network <NUM> may comprise a private network, such as a content provider's distribution system. The network <NUM> may communicate using technologies such as WLAN technology based on the Institute of Electrical and Electronics Engineers (IEEE) <NUM> 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 video data source <NUM> may comprise a headend, a television or movie studio, a video camera, a video on-demand server, a cable modem termination system, the like, and/or any combination of the foregoing. The video data source <NUM> may provide uncompressed, raw video data comprising a sequence of frames. The video data source <NUM> and the encoder <NUM> may be incorporated as a single device and/or may be co-located at a premises. The video data source <NUM> may provide the uncompressed video data based on a request for the uncompressed video data, such as a request from the encoder <NUM>, the computing device <NUM>, the content delivery system <NUM>, and/or the video archive system <NUM>.

The content delivery system <NUM> may receive a request for video data from the computing device <NUM>. The content delivery system <NUM> may authorize/authenticate the request and/or the computing device <NUM> from which the request originated. The request for video data may comprise a request for a linear video playing on 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 video data source <NUM> may transmit the requested video data to the encoder <NUM>.

The encoder <NUM> may encode (e.g., compress) the video data. The encoder <NUM> may transmit the encoded video data to the requesting component, such as the content delivery system <NUM> or the computing device <NUM>. The content delivery system <NUM> may transmit the requested encoded video data to the requesting computing device <NUM>. The video archive system <NUM> may provide a request for encoded video data. The video archive system <NUM> may provide the request to the encoder <NUM> and/or the video data source <NUM>. Based on the request, the encoder <NUM> may receive the corresponding uncompressed video data. The encoder <NUM> may encode the uncompressed video data to generate the requested encoded video data. The encoded video data may be provided to the video archive system <NUM>. The video archive system <NUM> may store (e.g., archive) the encoded video data from the encoder <NUM>. The encoded video data may be stored in the database <NUM>. The stored encoded video data may be maintained for purposes of backup or archive. The stored encoded video data may be stored for later use as "source" video data, to be encoded again and provided for viewer consumption. The stored encoded video data may be provided to the content delivery system <NUM> based on a request from a computing device <NUM> for the encoded video data. The video archive system <NUM> may provide the requested encoded video data to the computing device <NUM>.

The computing device <NUM> may comprise a decoder <NUM>, a buffer <NUM>, and a video player <NUM>. The computing device <NUM> (e.g., the video player <NUM>) may be communicatively connected to a display <NUM>. The display <NUM> may be a separate and discrete component from the computing device <NUM>, such as a television display connected to a set-top box. The display <NUM> may be integrated with the computing device <NUM>. The decoder <NUM>, the video player <NUM>, the buffer <NUM>, and the display <NUM> may be realized in a single device, such as a laptop or mobile device. The computing device <NUM> (and/or the computing device <NUM> paired with the display <NUM>) may comprise 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 decoder <NUM> may decompress/decode the encoded video data. The encoded video data may be received from the encoder <NUM>. The encoded video data may be received from the content delivery system <NUM>, and/or the video archive system <NUM>.

<FIG> is a diagram of an example ABR transcoder output <NUM>. <FIG> shows an example group of compressed frames and the picture type output of each frame. In the example of <FIG>, the output frames are shown in the order in which they are decoded (not displayed on a display device). The ABR transcoder output <NUM> comprises variant <NUM><NUM> and variant <NUM><NUM>. The depiction of two variants is for exemplary purposes and more than two variants may be output by the ABR transcoder (e.g., there may three or more variants).

Each variant comprises a plurality of segments. Variant <NUM><NUM> comprises segment <NUM><NUM> and segment <NUM><NUM>. Variant <NUM><NUM> comprises segment <NUM><NUM> and segment <NUM><NUM>. The depiction of two segments is for exemplary purposes and more than two segments may be in a variant (e.g., there may be three or more segments). The boundary of the segments amongst the variants are aligned (e.g., the boundaries of segment <NUM><NUM> in variant <NUM><NUM> is aligned with segment <NUM><NUM> in variant <NUM><NUM>), and the aligned segments comprise the same video content to be viewed by the streaming computing device (e.g., decoding segment <NUM><NUM> in variant <NUM><NUM> or segment <NUM><NUM> in variant <NUM><NUM> result in viewing the same content).

Each segment comprises a plurality of frames. Segment <NUM><NUM> in variant <NUM><NUM> comprises IDR1 frame <NUM>, P1 frame <NUM>, B1 frame <NUM>, B2 frame <NUM>, P2 frame <NUM>, B3 frame <NUM>, B4 frame <NUM>, P3 frame <NUM>, B5 frame <NUM>, and B6 frame <NUM>. Segment <NUM><NUM> in variant <NUM><NUM> comprises IDR2 frame <NUM>, P4 frame <NUM>, B7 frame <NUM>, B8 frame <NUM>, P5 frame <NUM>, B9 frame <NUM>, B10 frame <NUM>, P6 frame <NUM>, B11 frame <NUM>, and B12 frame <NUM>. IDR2 frame <NUM> comprises an SAP.

Segment <NUM><NUM> in variant <NUM><NUM> comprises IDR1 frame <NUM>, P1 frame <NUM>, B1 frame <NUM>, B2 frame <NUM>, P2 frame <NUM>, B3 frame <NUM>, B4 frame <NUM>, P3 frame <NUM>, B5 frame <NUM>, and B6 frame <NUM>. Segment <NUM><NUM> in variant <NUM><NUM> comprises IDR2 frame <NUM>, P4 frame <NUM>, B7 frame <NUM>, B8 frame <NUM>, P5 frame <NUM>, B9 frame <NUM>, B10 frame <NUM>, P6 frame <NUM>, B11 frame <NUM>, and B12 frame <NUM>. IDR2 frame <NUM> comprises a SAP. Each frame in the segments depicted in <FIG> are aligned (e.g., IDR2 frame <NUM> and IDR2 frame <NUM> are aligned).

The depiction of only IDR, P, and B frames within each segment of <FIG> is for exemplary purposes and other frames could be used following the IDR frames in each segment. For example, a larger segment may include an I-frame in the middle of the segment following the IDR frame of that segment. In another example, the segment may comprise additional P or B frames. The selection of the types of frames used in each segment is based on the encoder design and the content being viewed.

In accordance with the techniques disclosed herein, the ABR transcoder output of <FIG> may be modified to comprise two segments per segment listed. For example, segment <NUM><NUM> in variant <NUM><NUM> and segment <NUM><NUM> in variant <NUM><NUM> as shown in <FIG> may be modified such that the transcoder outputs, for each variant, a segment <NUM> (starting with an I-frame resulting in an open GOP) and a segment <NUM>' (starting with an IDR frame resulting in a closed GOP).

Including closed GOP segments (e.g., segment <NUM>', segment <NUM>', segment <NUM>'. segment x') enables seamless switching when moving from one variant to another variant during upscaling or downscaling to address changing network bandwidth, channel changes, time shifting, etc. Further, including the open GOP segments (e.g., segment <NUM>, segment <NUM>, segment <NUM>. segment x) enables a decoder to continue referencing frame data from previous segments when a variant switch is not necessary. As described above, this enhancement improves the quality of the video playback because referencing frame data from previous segments causes a smoother viewing experience. In an example, during a bitstream switch, a client player may be modified to retrieve the segment x' file first after the bitstream switch, decode segment x', and then return to decoding the segment x files.

<FIG> show examples of an ABR segment <NUM>. The enhanced ABR segment <NUM> comprises segment <NUM><NUM> and segment <NUM>' <NUM>, which each comprise the same frame data for the same variant. Segment <NUM><NUM> would be decoded by a computing device streaming content when no variant switch was necessary following decoding of the previous segment (e.g., following decoding of segment <NUM> in the same variant). Segment <NUM>' <NUM> would be decoded by the computing device after a variant switch following decoding of the previous segment (e.g., following decoding of segment <NUM> in a different variant).

<FIG> is a diagram of an example of the enhanced ABR segment <NUM> showing frames in the order that they would be decoded. Referring to <FIG>, segment <NUM><NUM> comprises I1 frame <NUM>, B7 frame <NUM>, B8 frame <NUM>, P4 frame <NUM>, B9 frame <NUM>, B10 frame <NUM>, P5 frame <NUM>, B11 frame <NUM>, and B12 frame <NUM>.

Segment <NUM>' <NUM> comprises IDR (B7) frame <NUM>, P' (I1) frame <NUM>, B' (B8, IDR'-P') frame <NUM>, P4 frame <NUM>, B9 frame <NUM>, B10 frame <NUM>, P5 frame <NUM>, B11 frame <NUM>, and B12 frame <NUM>. The information in the parentheses in segment <NUM>' <NUM> corresponds to the frame data encoded in that frame in segment <NUM>' <NUM>. For example, IDR' frame <NUM> in segment <NUM>' <NUM> is encoded as an IDR frame carrying the same frame data as B7 frame <NUM> from segment <NUM><NUM>. P' frame <NUM> in segment <NUM>' <NUM> is encoded as a P-frame carrying the same frame data as I1 frame <NUM> in segment <NUM><NUM>. B' frame <NUM> in segment <NUM>' <NUM> is encoded with the same frame data as B8 frame <NUM> in segment <NUM><NUM> and is encoded to use IDR' frame <NUM> and P' frame <NUM> as references for bidirectional prediction (which comprise the frame data for B7 frame <NUM> and I1 frame <NUM>, respectively). The remaining frames in segment <NUM>' <NUM> after B' frame <NUM> are the same as in segment <NUM><NUM>.

As a result, segment <NUM><NUM> and segment <NUM>' <NUM> each comprise the same source frame data so that the computing device has access to the same segment <NUM> content for both the case when a variant switch is necessary (decoding segment <NUM>' <NUM> is necessary) or a variant switch was not necessary (segment <NUM><NUM> is decoded). Further, the enhanced ABR transcoder generated the additional segment (segment <NUM>' <NUM>) by re-encoding only the first three frames and by using the remaining six frames from segment <NUM><NUM>. Accordingly, this technique, by only re-encoding three additional frames, causes an improved viewing quality experience by using I-frames at the start of each segment when no variant switch was needed, while still providing access to an additional nine-frame segment for use when switching variants.

<FIG> is a diagram of the example of the enhanced ABR segment showing frames in the order that they would be presented on a display device. Referring to <FIG>, segment <NUM><NUM> shows B7 frame <NUM>, B8 frame <NUM>, I1 frame <NUM>, B9 frame <NUM>, B10 frame <NUM>, P4 frame <NUM>, B11 frame <NUM>, B12 frame <NUM>, and P5 frame <NUM>.

Segment <NUM>' <NUM> comprises IDR (B7) frame <NUM>, B' (B8, IDR'-P') frame <NUM>, P' (I1) frame <NUM>, B9 frame <NUM>, B10 frame <NUM>, P4 frame <NUM>, B11 frame <NUM>, B12 frame <NUM>, and P5 frame <NUM>. As described above, the source data of IDR' frame <NUM> is the same as that used for B7 frame <NUM>, the source data of B' frame <NUM> is the same as that used for B8 frame <NUM>, and the source data of P' frame <NUM> is the same as that used for I1 frame <NUM>. As a result of this technique, the presentation orders for segment <NUM><NUM> and segment <NUM>' <NUM> are the same. Accordingly, if a variant switch is necessary, the computing device receiving segment <NUM>' <NUM> would display the same content as it would have if no switch was made and segment <NUM><NUM> was displayed instead.

<FIG> is an example system <NUM>. The system <NUM> may comprise an ABR encoder/transcoder/packager <NUM> implementing the techniques described herein. The ABR encoder/transcoder/packager <NUM> may receive video <NUM>, which has been compressed or uncompressed. The ABR encoder/transcoder/packager <NUM> may generate multiple bitrate streams for each variant and transmit the multiple bitstreams to a content delivery network <NUM>. The multiple bitrate streams may comprise variant <NUM> at <NUM> Mbps <NUM>, variant <NUM> at <NUM> Mbps <NUM>, and variant <NUM> at <NUM> Mbps <NUM>.

Each variant may comprise a segment and corresponding segment'. Variant <NUM> at <NUM> Mbps <NUM> may comprise segment x <NUM>, segment y <NUM>, and segment z <NUM> and also corresponding segment x' <NUM>, segment y' <NUM>, and segment z' <NUM>. Variant <NUM> at <NUM> Mbps <NUM> may comprise segment x <NUM>, segment y <NUM>, and segment z <NUM> and also corresponding segment x' <NUM>, segment y' <NUM>, and segment z' <NUM>. Variant <NUM> at <NUM> Mbps <NUM> may comprise segment x <NUM>, segment y <NUM>, and segment z <NUM> and also corresponding segment x' <NUM>, segment y' <NUM>, and segment z' <NUM>.

A computing device such as a player <NUM> (e.g., an HTTP Live Streaming (HLS) player or a Dynamic Adaptive Streaming over HTTP (DASH) player) may receive each variant via the CDN <NUM>. The player <NUM> may be modified to retrieve the segment' when switching variants. For example, when streaming content, a computing device may receive an indication that the ABR streams comprise the enhanced ABR segments described above. For example, in an ABR system using HLS, support for signaling that a segment x' is available (e.g., segment x' <NUM>, segment x' <NUM>, and segment x' <NUM> in the example of <FIG>) may be accomplished by adding a custom tag in the HLS master manifest file. The custom tag may, for example, be X-SwitchSegmentPostFix. This custom tag value may be added to the file name for segment x (e.g., segment X <NUM> in the example of <FIG>) to indicate that a segment x' is available. For example, if "_sw" is used as the name for the custom tag, X-SwitchSegmentPostFix, and the file name of segment x is "segmentx. ts," then the file name for segment x' may be "segmentx_sw. " The computing device using HLS may be configured to detect the custom tags in the segment file names and then may retrieve the segment x' files when performing a variant switch.

In another example, in an ABR system using DASH, support for signaling that a segment x' is available (e.g., segment x' <NUM>, segment x' <NUM>, and segment x' <NUM> in the example of <FIG>) may be accomplished by adding a custom attribute in each video (e.g., SwitchSegmentPostFix). This custom attribute may be added to the file name for segment x (e.g., segment <NUM><NUM> in the example of <FIG>) to indicate that a segment x' is available. For example, if "_sw" is used as the name of the custom attribute, SwitchSegmentPostFix, and the file name of segment x is "segmentx. mp4," then the file name for segment x' would be "segmentx_sw. " The computing device using DASH may be configured to detect the custom attributes in the segment file names and then may retrieve the segment x' files when performing a variant switch.

<FIG> shows an example variant switch in the system of <FIG> <NUM>. In this example, a computing device streaming video has decoded segment x <NUM> in variant <NUM><NUM>. The computing device may then determine that a variant switch is desirable based on a network condition change (e.g., a change in network bandwidth, a channel change, a time shift command, etc.) and may switch <NUM> to variant <NUM><NUM>. Because a variant switch <NUM> has just been performed and the previous bitrate, resolution, or quality associated with variant <NUM><NUM> no longer apply, the computing device begins decoding variant <NUM><NUM> by decoding segment y' <NUM>, which begins with an IDR' frame <NUM> resulting in resetting the picture reference buffer and decoding subsequent frames with new bitrate, resolution, or quality values. If after decoding segment y'<NUM>, another variant switch is not needed, the computing device would decode segment z <NUM>, which begins with an I-frame (e.g., I3 frame <NUM>) allowing the decoder to reference frame data from the previous segment (e.g., segment y' <NUM>) and resulting in a higher quality viewing experience as frames in variant <NUM><NUM> are decoded.

<FIG> shows an example method <NUM>. The method <NUM> of <FIG>, may be performed by the encoder <NUM> or computing device <NUM> of <FIG>. The method <NUM> of <FIG>, may be performed by the ABR encoder/transcoder packager <NUM> of <FIG>. While each step in the method <NUM> of <FIG> is shown and described separately, multiple steps may be executed in a different order than what is shown, in parallel with each other, or concurrently with each other.

At step <NUM>, the encoder determines, for a sequence of video frames, a plurality of first segments and a plurality of second segments, wherein the plurality of first segments comprise SAPs of a first type that do not reset a picture reference buffer, and wherein the plurality of second segments comprise SAPs of a second type that do reset the picture reference buffer. The first type comprises an I-frame, and the second type comprises an IDR frame as shown in the examples of <FIG>.

Each segment of the plurality of first segments may comprise an I-frame, one or more P-frames, and one or more B-frames as shown in the examples of <FIG>. Each segment of the plurality of second segments may comprise a subset of those frames but still comprise source frame data that matches source frame data in a first segment of the plurality of first segments so that the computing device streaming the content may view the same content whether decoding a first segment or its corresponding second segment.

At step <NUM>, the encoder sends, at a first bitrate, to a computing device, at least one segment of the plurality of first segments. At step <NUM>, the encoder receives, from the computing device, a request for segments encoded at a second bitrate. The request may be based on at least one of: changing network bandwidth, a channel change by the computing device, or a time shifting command by the computing device. The request may be enabled by detection by the computing device of an indication in the bitstream that a stream at another bitrate is available. At step <NUM>, the encoder sends, at the second bitrate, to the computing device, a segment of the plurality of second segments and a subsequent segment of the plurality of first segments in the sequence.

Each first segment of the plurality of first segments may comprise an I-frame, one or more P-frames, and one or more B-frames as shown in the examples of <FIG>. Each segment of the plurality of second segments may comprise a subset of those frames but still comprise source frame data that matches source frame data in a first segment of the plurality of first segments so that the computing device streaming the content may view the same content whether decoding a first segment or its corresponding second segment.

At step <NUM>, the encoder may send, at a first bitrate, via a content delivery network and to a computing device, at least one segment of the plurality of first segments. At step <NUM>, the encoder may send, at a second bitrate, via the content delivery network to the computing device and in response to a switch by the computing device from the first bitrate to the second bitrate, a segment of the plurality of second segments, wherein the second segment follows the at least one first segment in the sequence. The switch may be based on at least one of: changing network bandwidth, a channel change by the computing device, or a time shifting command by the computing device. The switch may be enabled by detection by the computing device of an indication in the bitstream that a stream at another bitrate is available. At step <NUM>, the encoder may send, at the second bitrate, via the content delivery network to the computing device and based on the computing device decoding the second segment, a subsequent segment of the plurality of first segments in the sequence.

At step <NUM>, the computing device may receive, at a first bitrate, at least one segment of a plurality of first segments, wherein the plurality of first segments were determined from a sequence of video frames and comprise SAPs of a first type that do not reset a picture reference buffer. The first type comprises an I-frame as shown in the examples of <FIG>. Each first segment of the plurality of first segments may comprise an I-frame, one or more P-frames, and one or more B-frames as shown in the examples of <FIG>.

At step <NUM>, the computing device may send a request for segments encoded at a second bitrate. The request may be based on at least one of: changing network bandwidth, a channel change by the computing device, or a time shifting command by the computing device. The request may be enabled by detection by the computing device of an indication in the bitstream that a stream at another bitrate is available. At step <NUM>, the computing device may receive, at the second bitrate, a segment of a plurality of second segments and a subsequent segment of the plurality of first segments in the sequence, wherein the plurality of second segments were determined from the sequence and comprise SAPs of a second type that do reset the picture reference buffer. Each segment of the plurality of second segments may comprise a subset of those frames but still comprise source frame data that matches source frame data in a first segment of the plurality of first segments so that the computing device may view the same content whether decoding a first segment or its corresponding second segment. The second type comprises an IDR frame as shown in the examples of <FIG>.

At step <NUM>, the encoder may determine, for a sequence of video frames, a plurality of first segments and a plurality of second segments, wherein the plurality of first segments comprise SAPs of a first type that do not reset a picture reference buffer, and wherein the plurality of second segments comprise SAPs of a second type that do reset the picture reference buffer. The first type comprises an I-frame, and the second type comprises an IDR frame as shown in the examples of <FIG>.

At step <NUM>, the encoder may send, at a first bitrate, to a computing device, a segment of the plurality of first segments. At step <NUM>, the encoder may receive, from the computing device, a request for subsequent segments encoded at the first bitrate. The request may be based on steady network bandwidth or other steady network conditions. At step <NUM>, the encoder may send, at the first bitrate, to the computing device, a subsequent segment of the plurality of first segments in the sequence, wherein an SAP of the subsequent segment comprises an I-frame.

At step <NUM>, the computing device may receive, at a first bitrate, at least one segment of a plurality of first segments, wherein the plurality of first segments were determined from a sequence of video frames and comprise SAPs of a first type that do not reset a picture reference buffer. The first type comprises an I-frame as shown in the examples of <FIG>. Each first segment of the plurality of first segments may comprise an I-frame, one or more P-frames, and one or more B-frames as shown in the examples of <FIG>. A plurality of second segments may also be determined from the sequence and comprise SAPs of a second type that do reset the picture reference buffer. Each segment of the plurality of second segments may comprise a subset of those frames but still comprise source frame data that matches source frame data in a first segment of the plurality of first segments so that the computing device may view the same content whether decoding a first segment or its corresponding second segment. The second type comprises an IDR frame as shown in the examples of <FIG>.

At step <NUM>, the computing device may send a request for subsequent segments encoded at the first bitrate. The request may be based on steady network bandwidth or other steady network conditions. At step <NUM>, the computing device may receive, at the first bitrate, a subsequent segment of the plurality of first segments in the sequence, wherein an SAP of the subsequent segment comprises an I-frame.

<FIG> depicts a computing device <NUM> that may be used in various aspects, such as the servers, modules, and/or devices depicted in <FIG>. With regard to the example architectures of <FIG>, the devices may each be implemented in an instance of a computing device <NUM> of <FIG>. The computer architecture shown in <FIG> shows a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, PDA, e-reader, digital cellular phone, or other computing node, and may be utilized to execute any aspects of the computers described herein, such as to implement the methods described in relation to <FIG>.

The computing device <NUM> may include a baseboard, or "motherboard," which is a printed circuit board to which a multitude of components or devices may be connected by way of a system bus or other electrical communication paths. One or more central processing units (CPUs) <NUM> may operate in conjunction with a chipset <NUM>. The CPU(s) <NUM> may be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computing device <NUM>.

The CPU(s) <NUM> may perform the necessary operations by transitioning from one discrete physical state to the next through the manipulation of switching elements that differentiate between and change these states. Switching elements may generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements may be combined to create more complex logic circuits including registers, adders-subtractors, arithmetic logic units, floating-point units, and the like.

The CPU(s) <NUM> may be augmented with or replaced by other processing units, such as GPU(s) <NUM>. The GPU(s) <NUM> may comprise processing units specialized for but not necessarily limited to highly parallel computations, such as graphics and other visualization-related processing.

A chipset <NUM> may provide an interface between the CPU(s) <NUM> and the remainder of the components and devices on the baseboard. The chipset <NUM> may provide an interface to a random access memory (RAM) <NUM> used as the main memory in the computing device <NUM>. The chipset <NUM> may further provide an interface to a computer-readable storage medium, such as a read-only memory (ROM) <NUM> or non-volatile RAM (NVRAM) (not shown), for storing basic routines that may help to start up the computing device <NUM> and to transfer information between the various components and devices. ROM <NUM> or NVRAM may also store other software components necessary for the operation of the computing device <NUM> in accordance with the aspects described herein.

The computing device <NUM> may operate in a networked environment using logical connections to remote computing nodes and computer systems through local area network (LAN) <NUM>. The chipset <NUM> may include functionality for providing network connectivity through a network interface controller (NIC) <NUM>, such as a gigabit Ethernet adapter. A NIC <NUM> may be capable of connecting the computing device <NUM> to other computing nodes over a network <NUM>. It should be appreciated that multiple NICs <NUM> may be present in the computing device <NUM>, connecting the computing device to other types of networks and remote computer systems.

The computing device <NUM> may be connected to a mass storage device <NUM> that provides non-volatile storage for the computer. The mass storage device <NUM> may store system programs, application programs, other program modules, and data, which have been described in greater detail herein. The mass storage device <NUM> may be connected to the computing device <NUM> through a storage controller <NUM> connected to the chipset <NUM>. The mass storage device <NUM> may consist of one or more physical storage units. A storage controller <NUM> may interface with the physical storage units through a serial attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computing device <NUM> may store data on a mass storage device <NUM> by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of a physical state may depend on various factors and on different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage units and whether the mass storage device <NUM> is characterized as primary or secondary storage and the like.

For example, the computing device <NUM> may store information to the mass storage device <NUM> by issuing instructions through a storage controller <NUM> to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible, with the foregoing examples provided only to facilitate this description. The computing device <NUM> may further read information from the mass storage device <NUM> by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the mass storage device <NUM> described herein, the computing device <NUM> may have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media may be any available media that provides for the storage of non-transitory data and that may be accessed by the computing device <NUM>.

By way of example and not limitation, computer-readable storage media may include volatile and non-volatile, transitory computer-readable storage media and non-transitory computer-readable storage media, and removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, other magnetic storage devices, or any other medium that may be used to store the desired information in a non-transitory fashion.

A mass storage device, such as the mass storage device <NUM> depicted in <FIG>, may store an operating system utilized to control the operation of the computing device <NUM>. The operating system may comprise a version of the LINUX operating system. The operating system may comprise a version of the WINDOWS SERVER operating system from the MICROSOFT Corporation. According to further aspects, the operating system may comprise a version of the UNIX operating system. Various mobile phone operating systems, such as IOS and ANDROID, may also be utilized. It should be appreciated that other operating systems may also be utilized. The mass storage device <NUM> may store other system or application programs and data utilized by the computing device <NUM>.

The mass storage device <NUM> or other computer-readable storage media may also be encoded with computer-executable instructions, which, when loaded into the computing device <NUM>, transforms the computing device from a general-purpose computing system into a special-purpose computer capable of implementing the aspects described herein. These computer-executable instructions transform the computing device <NUM> by specifying how the CPU(s) <NUM> transition between states, as described herein. The computing device <NUM> may have access to computer-readable storage media storing computer-executable instructions, which, when executed by the computing device <NUM>, may perform the methods described in relation to <FIG>.

A computing device, such as the computing device <NUM> depicted in <FIG>, may also include an input/output controller <NUM> for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, an input/output controller <NUM> may provide output to a display, such as a computer monitor, a flat-panel display, a digital projector, a printer, a plotter, or other type of output device. It will be appreciated that the computing device <NUM> may not include all of the components shown in <FIG>, may include other components that are not explicitly shown in <FIG>, or may utilize an architecture completely different than that shown in <FIG>.

As described herein, a computing device may be a physical computing device, such as the computing device <NUM> of <FIG>. A computing node may also include a virtual machine host process and one or more virtual machine instances. Computer-executable instructions may be executed by the physical hardware of a computing device indirectly through interpretation and/or execution of instructions stored and executed in the context of a virtual machine.

It is to be understood that the methods and systems described herein are not limited to specific methods, specific components, or to particular implementations. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

As used in the specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Similarly, when values are expressed as approximations, by use of the antecedent "about," it will be understood that the particular value forms another embodiment.

Throughout the description and claims of this specification, the word "comprise" and variations of the word, such as "comprising" and "comprises," means "including but not limited to," and is not intended to exclude, for example, other components, integers or steps. "Exemplary" means "an example of' and is not intended to convey an indication of a preferred or ideal embodiment. "Such as" is not used in a restrictive sense, but for explanatory purposes.

Components are described that may be used to perform the described methods and systems. When combinations, subsets, interactions, groups, etc., of these components are described, it is understood that while specific references to each of the various individual and collective combinations and permutations of these may not be explicitly described, each is specifically contemplated and described herein, for all methods and systems. This applies to all aspects of this application including, but not limited to, operations in described methods. Thus, if there are a variety of additional operations that may be performed it is understood that each of these additional operations may be performed with any specific embodiment or combination of embodiments of the described methods.

The present methods and systems may be understood more readily by reference to the following detailed description of preferred embodiments and the examples included therein and to the Figures and their descriptions.

As will be appreciated by one skilled in the art, the methods and systems may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the methods and systems may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. More particularly, the present methods and systems may take the form of web-implemented computer software. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

Embodiments of the methods and systems are described below with reference to block diagrams and flowchart illustrations of methods, systems, apparatuses and computer program products. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, may be implemented by computer program instructions. These computer program instructions may be loaded on a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.

These computer program instructions may also be stored in a computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

The various features and processes described herein may be used independently of one another, or may be combined in various ways. In addition, certain methods or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto may be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically described, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the described example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the described example embodiments.

It will also be appreciated that various items are illustrated as being stored in memory or on storage while being used, and that these items or portions thereof may be transferred between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other embodiments, some or all of the software modules and/or systems may execute in memory on another device and communicate with the illustrated computing systems via inter-computer communication. Furthermore, in some embodiments, some or all of the systems and/or modules may be implemented or provided in other ways, such as at least partially in firmware and/or hardware, including, but not limited to, one or more application-specific integrated circuits ("ASICs"), standard integrated circuits, controllers (e.g., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field-programmable gate arrays ("FPGAs"), complex programmable logic devices hard disk, a memory, a network, or a portable media article to be read by an appropriate device or via an appropriate connection. The systems, modules, and data structures may also be transmitted as generated data signals (e.g., as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission media, including wireless-based and wired/cable-based media, and may take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). Such computer program products may also take other forms in other embodiments. Accordingly, the present invention may be practiced with other computer system configurations.

Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its operations be performed in a specific order. Accordingly, where a method claim does not actually recite an order to be followed by its operations or it is not otherwise specifically stated in the claims or descriptions that the operations are to be limited to a specific order, it is no way intended that an order be inferred, in any respect. This holds for any possible non-express basis for interpretation, including: matters of logic with respect to arrangement of steps or operational flow; plain meaning derived from grammatical organization or punctuation; and the number or type of embodiments described in the specification.

Claim 1:
A method comprising:
for any sequence of video frames of a video content requested by a computing device, determining:
a first variant encoded at a first bitrate comprising a first set of segments comprising stream access points, SAPs and a corresponding second set of segments comprising SAPs, wherein each segment in the first set of segments has a corresponding segment in the second set of segments, wherein all SAPs of the first set of segments are of a first type that do not reset a picture reference buffer, wherein all SAPs of the second set of segments are of a second type that do reset a picture reference buffer, and
a second variant encoded at a second bitrate comprising a third set of segments comprising SAPs and a fourth set of segments comprising SAPs, wherein each segment in the third set of segments has a corresponding segment in the fourth set of segments, wherein all SAPs of the third set of segments are of the first type that do not reset a picture reference buffer, wherein all SAPs of the fourth set of segments are of the second type that do reset a picture reference buffer;
wherein the first type comprises an I-frame and the second type comprises an instantaneous decoder refresh, IDR, frame.
sending, at the first bitrate, to the computing device, at least one segment of the first variant, wherein the at least one segment comprises a SAP of the first type ;
receiving, from the computing device, a request for content encoded at the second bitrate; and
sending, at the second bitrate, to the computing device, a segment of the second variant comprising a SAP of the second type and a next segment of the second variant comprising a SAP of the first type.