Methods, systems, and apparatuses for enhanced adaptive bitrate segmentation

Systems and methods are described herein for processing video. An encoder 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 segments of the plurality of first segments to a computing device streaming video when network conditions are steady. The encoder may send a 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 segment the plurality of second segments, the encoder may send subsequent first segments at the different bitrate.

BACKGROUND

An Adaptive Bitrate (ABR) transcoder encodes an uncompressed or compressed video input stream into multiple streams at different bitrates. When network conditions change, a client device streaming content may decide to switch from one stream to another stream in order to accommodate the changing network conditions. For example, when less network bandwidth is available, the client device may switch to a stream with a lower bitrate.

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.

SUMMARY

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.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

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.1shows a system100configured for video processing. The system100may comprise a video data source102, an encoder104, a content delivery system108, a computing device110, and a video archive system120. The video archive system120may be communicatively connected to a database122to store archived video data.

The video data source102, the encoder104, the content delivery system108, the computing device110, the video archive system120, and/or any other component of the system100may be interconnected via a network106. The network106may comprise a wired network, a wireless network, or any combination thereof. The network106may comprise a public network, such as the Internet. The network106may comprise a private network, such as a content provider's distribution system. The network106may 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 video data source102may 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 source102may provide uncompressed, raw video data comprising a sequence of frames. The video data source102and the encoder104may be incorporated as a single device and/or may be co-located at a premises. The video data source102may provide the uncompressed video data based on a request for the uncompressed video data, such as a request from the encoder104, the computing device110, the content delivery system108, and/or the video archive system120.

The content delivery system108may receive a request for video data from the computing device110. The content delivery system108may authorize/authenticate the request and/or the computing device110from 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 source102may transmit the requested video data to the encoder104.

The encoder104may encode (e.g., compress) the video data. The encoder104may transmit the encoded video data to the requesting component, such as the content delivery system108or the computing device110. The content delivery system108may transmit the requested encoded video data to the requesting computing device110. The video archive system120may provide a request for encoded video data. The video archive system120may provide the request to the encoder104and/or the video data source102. Based on the request, the encoder104may receive the corresponding uncompressed video data. The encoder104may encode the uncompressed video data to generate the requested encoded video data. The encoded video data may be provided to the video archive system120. The video archive system120may store (e.g., archive) the encoded video data from the encoder104. The encoded video data may be stored in the database122. 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 system108based on a request from a computing device110for the encoded video data. The video archive system120may provide the requested encoded video data to the computing device110.

The computing device110may comprise a decoder112, a buffer114, and a video player116. The computing device110(e.g., the video player116) may be communicatively connected to a display118. The display118may be a separate and discrete component from the computing device110, such as a television display connected to a set-top box. The display118may be integrated with the computing device110. The decoder112, the video player116, the buffer114, and the display118may be realized in a single device, such as a laptop or mobile device. The computing device110(and/or the computing device110paired with the display118) 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 decoder112may decompress/decode the encoded video data. The encoded video data may be received from the encoder104. The encoded video data may be received from the content delivery system108, and/or the video archive system120.

FIG.2is a diagram of an example ABR transcoder output200.FIG.2shows an example group of compressed frames and the picture type output of each frame. In the example ofFIG.2, the output frames are shown in the order in which they are decoded (not displayed on a display device). The ABR transcoder output200comprises variant 1201and variant 2204. 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 1201comprises segment 1202and segment 2203. Variant 2204comprises segment 1205and segment 2206. 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 1202in variant 1201is aligned with segment 1205in variant 2204), and the aligned segments comprise the same video content to be viewed by the streaming computing device (e.g., decoding segment 1202in variant 1201or segment 1205in variant 2204result in viewing the same content).

The depiction of only IDR, P, and B frames within each segment ofFIG.2is 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 ofFIG.2may be modified to comprise two segments per segment listed. For example, segment 2203in variant 1201and segment 2206in variant 2204as shown inFIG.2may be modified such that the transcoder outputs, for each variant, a segment 2 (starting with an I-frame resulting in an open GOP) and a segment 2′ (starting with an IDR frame resulting in a closed GOP).

Including closed GOP segments (e.g., segment 1′, segment 2′, segment 3′ . . . 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 1, segment 2, segment 3 . . . 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.

FIGS.3A-3Bshow examples of an ABR segment300. The enhanced ABR segment300comprises segment 2301and segment 2′302, which each comprise the same frame data for the same variant. Segment 2301would 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 1 in the same variant). Segment 2′302would be decoded by the computing device after a variant switch following decoding of the previous segment (e.g., following decoding of segment 1 in a different variant).

As a result, segment 2301and segment 2′302each comprise the same source frame data so that the computing device has access to the same segment 2 content for both the case when a variant switch is necessary (decoding segment 2′302is necessary) or a variant switch was not necessary (segment 2301is decoded). Further, the enhanced ABR transcoder generated the additional segment (segment 2′302) by re-encoding only the first three frames and by using the remaining six frames from segment 2301. 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.3Bis 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 toFIG.3B, segment 2301shows B7 frame312, B8 frame313, I1 frame311, B9 frame315, B10 frame316, P4 frame314, B11 frame318, B12 frame319, and P5 frame317.

FIG.4Ais an example system400. The system400may comprise an ABR encoder/transcoder/packager401implementing the techniques described herein. The ABR encoder/transcoder/packager401may receive video410, which has been compressed or uncompressed. The ABR encoder/transcoder/packager401may generate multiple bitrate streams for each variant and transmit the multiple bitstreams to a content delivery network402. The multiple bitrate streams may comprise variant 1 at 20 Mbps411, variant 2 at 16 Mbps412, and variant 3 at 12 Mbps413.

Each variant may comprise a segment and corresponding segment′. Variant 1 at 20 Mbps411may comprise segment x420, segment y421, and segment z422and also corresponding segment x′423, segment y′424, and segment z′425. Variant 2 at 16 Mbps412may comprise segment x426, segment y427, and segment z428and also corresponding segment x′429, segment y′430, and segment z′431. Variant 3 at 12 Mbps413may comprise segment x432, segment y433, and segment z434and also corresponding segment x′435, segment y′436, and segment z′437.

A computing device such as a player403(e.g., an HTTP Live Streaming (HLS) player or a Dynamic Adaptive Streaming over HTTP (DASH) player) may receive each variant via the CDN402. The player403may 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′423, segment x′429, and segment x′435in the example ofFIG.4A) 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 X420in the example ofFIG.3) 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.ts.” 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′423, segment x′429, and segment x′435in the example ofFIG.4A) 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 2301in the example ofFIG.3) 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.mp4.” 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.4Bshows an example variant switch in the system ofFIG.4A400. In this example, a computing device streaming video has decoded segment x420in variant 1411. 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 switch450to variant 2412. Because a variant switch450has just been performed and the previous bitrate, resolution, or quality associated with variant 1411no longer apply, the computing device begins decoding variant 2412by decoding segment y′430, which begins with an IDR′ frame450resulting in resetting the picture reference buffer and decoding subsequent frames with new bitrate, resolution, or quality values. If after decoding segment y′430, another variant switch is not needed, the computing device would decode segment z428, which begins with an I-frame (e.g., I3 frame460) allowing the decoder to reference frame data from the previous segment (e.g., segment y′430) and resulting in a higher quality viewing experience as frames in variant 2412are decoded.

FIG.5shows an example method500. The method500ofFIG.5, may be performed by the encoder104or computing device110ofFIG.1. The method500ofFIG.5, may be performed by the ABR encoder/transcoder packager401ofFIG.4. While each step in the method500ofFIG.5is 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 step510, 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 may comprise an I-frame, and the second type may comprise an IDR frame as shown in the examples ofFIGS.3-4.

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 ofFIGS.3-4. 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 step520, the encoder may send, at a first bitrate, to a computing device, at least one segment of the plurality of first segments. At step530, the encoder may receive, 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 step540, the encoder may send, 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.

FIG.6shows an example method600. The method600ofFIG.6, may be performed by the encoder104or computing device110ofFIG.1. The method600ofFIG.6, may be performed by the ABR encoder/transcoder packager401ofFIG.4. While each step in the method600ofFIG.6is 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 step610, 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 may comprise an I-frame, and the second type may comprise an IDR frame as shown in the examples ofFIGS.3-4.

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 ofFIGS.3-4. 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 step620, 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 step630, 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 step640, 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.

FIG.7shows an example method700. The method700ofFIG.7, may be performed by the encoder104or computing device110ofFIG.1. The method700ofFIG.7, may be performed by the ABR encoder/transcoder packager401ofFIG.4. While each step in the method700ofFIG.7is 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 step710, 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 may comprise an I-frame as shown in the examples ofFIGS.3-4. 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 ofFIGS.3-4.

At step720, 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 step730, 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 may comprise an IDR frame as shown in the examples ofFIGS.3-4.

FIG.8shows an example method800. The method800ofFIG.8, may be performed by the encoder104or computing device110ofFIG.1. The method800ofFIG.8, may be performed by the ABR encoder/transcoder packager401ofFIG.4. While each step in the method800ofFIG.8is 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 step810, 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 may comprise an I-frame, and the second type may comprise an IDR frame as shown in the examples ofFIGS.3-4.

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 ofFIGS.3-4. 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 step820, the encoder may send, at a first bitrate, to a computing device, a segment of the plurality of first segments. At step830, 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 step840, 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.

FIG.9shows an example method900. The method900ofFIG.9, may be performed by the encoder104or computing device110ofFIG.1. The method900ofFIG.9, may be performed by the ABR encoder/transcoder packager401ofFIG.4. While each step in the method900ofFIG.9is 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 step910, 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 may comprise an I-frame as shown in the examples ofFIGS.3-4. 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 ofFIGS.3-4. 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 may comprise an IDR frame as shown in the examples ofFIGS.3-4.

At step920, 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 step930, 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.10depicts a computing device1000that may be used in various aspects, such as the servers, modules, and/or devices depicted inFIGS.1-4. With regard to the example architectures ofFIGS.1-4, the devices may each be implemented in an instance of a computing device1000ofFIG.10. The computer architecture shown inFIG.10shows 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 toFIGS.5-9.

The computing device1000may 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)1004may operate in conjunction with a chipset1006. The CPU(s)1004may be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computing device1000.

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

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

The computing device1000may operate in a networked environment using logical connections to remote computing nodes and computer systems through local area network (LAN)1016. The chipset1006may include functionality for providing network connectivity through a network interface controller (NIC)1022, such as a gigabit Ethernet adapter. A NIC1022may be capable of connecting the computing device1000to other computing nodes over a network1016. It should be appreciated that multiple NICs1022may be present in the computing device1000, connecting the computing device to other types of networks and remote computer systems.

The computing device1000may be connected to a mass storage device1028that provides non-volatile storage for the computer. The mass storage device1028may store system programs, application programs, other program modules, and data, which have been described in greater detail herein. The mass storage device1028may be connected to the computing device1000through a storage controller1024connected to the chipset1006. The mass storage device1028may consist of one or more physical storage units. A storage controller1024may 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.

A mass storage device, such as the mass storage device1028depicted inFIG.10, may store an operating system utilized to control the operation of the computing device1000. 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 device1028may store other system or application programs and data utilized by the computing device1000.

The mass storage device1028or other computer-readable storage media may also be encoded with computer-executable instructions, which, when loaded into the computing device1000, 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 device1000by specifying how the CPU(s)1004transition between states, as described herein. The computing device1000may have access to computer-readable storage media storing computer-executable instructions, which, when executed by the computing device1000, may perform the methods described in relation toFIG.5.

A computing device, such as the computing device1000depicted inFIG.10, may also include an input/output controller1032for 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 controller1032may 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 device1000may not include all of the components shown inFIG.10, may include other components that are not explicitly shown inFIG.10, or may utilize an architecture completely different than that shown inFIG.10.

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.

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.