Patent Application
20140362098
The present disclosure relates generally to electronic devices. More specifically, the present disclosure relates to systems and methods for display stream compression (DSC).
Electronic devices have become smaller and more powerful in order to meet consumer needs and to improve portability and convenience. Consumers have become dependent upon electronic devices and have come to expect increased functionality. Some examples of electronic devices include desktop computers, laptop computers, cellular phones, smart phones, media players, integrated circuits, etc.
Many electronic devices include a display for presenting information to consumers. For example, portable electronic devices include displays for allowing digital media to be consumed at almost any location where a consumer may be. For instance a consumer may use an electronic device with a display to check email, view pictures, watch videos, see social network updates, etc. In many cases, larger displays enhance usability and enjoyment for consumers.
However, the power requirements of a display may be problematic. For portable electronic devices, the power requirement of a display may significantly limit the battery life. The increasing demand for reducing power consumption while providing the same viewing experience for the consumer may be problematic. As can be observed from this discussion, systems and methods for reducing the power consumption of a display may be beneficial.
A method for video coding is described. A compressed bitstream is received from a host via a data link. Each slice of the compressed bitstream is mapped to a compressed frame buffer. The compressed frame buffer supports selective overwriting for regional updates. Parallel processing of the compressed data is performed in the compressed frame buffer. Pixel data is written to a display panel.
Slice data may be interleaved for transmission. Slice data may be provided to each decoder without buffering compressed data. The transmission of compressed data may use scheduling to avoid collisions between mapping slices to the compressed frame buffer and decoding slices from the compressed frame buffer. A decoder may begin decoding a frame from the compressed frame buffer after an offset from the beginning of a frame time. The decoder may operate on slices in raster scan at a uniform rate until the end of the frame.
The method may be performed by a mobile device. In one configuration, the method may be performed by a display stream compression decoder on the mobile device. The compressed frame buffer may be linear. A compressed slice location list may be maintained for the compressed frame buffer. The compressed slice location list may include a start time for each slice, an end time for each slice and a location of the slice within the compressed frame buffer.
Regional updates may be implemented when a limited number of full slices of compressed data are received. Regional updates may include the location of a slice, a size of the slice and where the slice is located in the compressed frame buffer. The compressed frame buffer may include reserved space for each slice based on slice geometry and a maximum size of each slice. The content and transmission of the compressed bitstream may be constrained by multiple hypothetical reference decoders (HRDs). The arrival of bits in an ith HRD may be delayed by
bits relative to the arrival of bits in a 0th HRD. R may be a bit rate and M may be a number of HRDs. Bits may arrive at an HRD at a uniform rate of R/M bits per pixel time P. For example the constraint may be that none of the parallel HRDs overflow or underflow.
An electronic device is also described. The electronic device includes a compressed buffer that supports selective overwriting for regional updates. The electronic device also includes a slice mapper that maps a compressed bitstream to the compressed buffer. The electronic device further includes one or more decoders that perform parallel processing of compressed data from the compressed buffer. The electronic device also includes a display panel that displays decoded data.
Various configurations are now described with reference to the Figures, where like reference numbers may indicate functionally similar elements. The systems and methods as generally described and illustrated in the Figures herein could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of several configurations, as represented in the Figures, is not intended to limit scope, as claimed, but is merely representative of the systems and methods.
The electronic device 102 may be a user equipment (UE), a mobile station, a subscriber station, an access terminal, a remote station, a user terminal, a terminal, a handset, a subscriber unit, a wireless communication device, a laptop, a portable video game unit, etc. The electronic device 102 may include a display module 104. The display module 104 may allow the electronic device 102 to display high quality video to a user (i.e., via a display panel 108) with reduced power consumption. For example, the display module 104 may include mobile display panels 108 where battery life is critical. The display module 104 may support compression over the display link layer and within a compressed frame buffer 112 in the display module 104 by including a display stream compression (DSC) decoder 110. The display stream compression (DSC) decoder 110 is discussed in additional detail below in relation to
The embedded Display Port (eDP) 1.4 standard defines some tools for saving power. These tools include panel self refresh (PSR), link level compression and self refresh with selective update (PSR2). Panel self refresh (PSR) allows a host graphics unit to enter a low power state when the display content is unchanging. The display module 104 may refresh the display on the display panel 108 based on a local frame memory. However, panel self refresh (PSR) needs a frame memory within the display module 104 to operate.
Link level compression applies compression to the video data transmitted across the data link, allowing the data link to run at a lower rate (thereby saving power). Link level compression may use simple codecs. The compression algorithm may be a relatively simplistic operation performed on samples without a spatial transform. However, the lack of guarantees on the compression ratio necessitates that the decoder have an uncompressed frame buffer to support selective regional updates.
Regional updates may work in conjunction with a frame buffer, allowing the display source to send data for the regions of the display that have changed, while relying on the data in the frame buffer for areas which have not changed. Regional updates may be particularly effective when most of an image is constant (e.g., editing a document on a computer). In eDP 1.3, regional updates (also referred to as selective updates) are described by a set of scan lines and X position within the scan lines. The X position may be required to be a multiple of 16. Selective regional updates may include compression but the compressed data must be decompressed prior to storage in a frame buffer.
In eDP 1.4, the display module 104 may require either an uncompressed frame buffer or compression/transcoding. The display module 104 may also require two lines of uncompressed memory for the bitstream buffer (although the display module 104 may be able to implement this requirement with less memory). Furthermore, the display module in eDP 1.4 may require that the source encoder have tight buffer management when using compressed data.
The use of compression in the frame buffer of a display (i.e., the compressed frame buffer 112) may reduce the size/cost of the frame buffer as well as reduce the power consumption of the electronic device 102. The use of a reduced display refresh when the native display panel has a hold characteristic (such as recent indium gallium zinc oxide (IGZO) panels) may also result in power savings for the electronic device 102.
A display stream compression (DSC) decoder 110 that includes a compressed frame buffer 112 and that is capable of using regional updates may include additional restrictions. For the bitstream structure, the stream must be divisible into independently decodable unites (referred to as slices) to enable the replacement of regions in future frames. The slice structure may only change on full frame updates. A compressed slice may be required to be less than a bound established when a full frame was coded to avoid overwriting other slices. In addition, each slice must be identifiable within a code stream either by marker codes or at known positions (i.e., a fixed slice size). This is because the display stream compression (DSC) decoder 110 needs to know where to place regional updates in the compressed frame buffer 112 and the display stream compression (DSC) decoder 110 needs to know the end of each slice (either by the given size or by the marker codes).
The scheduling of regional updates needs to be controlled to avoid damaging data being decoded by updates to the code stream. In one configuration, the schedule of possible times to transmit regional updates may be based on the first/last line of the update. Regional updates may also be required to signal the region of the update, thereby allowing the display stream compression (DSC) decoder 110 to determine the slice addresses from the regional update. Existing methods describe the region of the update in a regional update using pixel coordinates, which may not be practicable. The frame may be padded to an integer number of slices (height and width) or the frame may allow smaller slices (i.e., partial width slices). The regional update syntax needs to be compatible with existing eDP handling of regional updates.
The use of display stream compression (DSC) may provide power and cost savings for mobile devices while enabling higher resolution throughput. There are two types of display stream compression (DSC) under consideration: high throughput and reduced power. For high throughput, it is anticipated that display stream compression (DSC) will support high resolution displays over limited display links. Both visual quality and compression efficiency are key elements of high throughput display stream compression (DSC). Complexity is important, since memory for the code stream buffer is less than both the line and the clock rate needed to provide the pixel output rate. The high throughput application includes block to raster conversions that may be too complex. Furthermore, the high throughput application ignores the error rate assumed to be addressed by the transport layer forward error correction (FEC). The high throughput application has an initial target of 12 bits per pixel (bpp) based on the projected link rates.
For the reduced power application, link layer compression may be used to reduce the data rate (and hence reduce the power consumption). The reduced power applications support existing power saving tools such as panel self refresh (PSR) and regional updates of embedded Display Port (eDP) 1.4. The reduced power application may support frame buffer compression with an algorithm common to link layer compression to avoid the cost of transcoding. Reduced power applications have a target bit per pixel (bpp) of 8. A fixed compressed slice size may be needed to support panel self refresh (PSR) and the compressed frame buffer 112.
The host 228 may include a frame buffer 214. The frame buffer 214 may include a group of pixels 216 (referred to as slice N) that is to be provided to the display module 204. In one configuration, the slice N may be a regional update. The frame buffer 214 provides each slice to an encoder 218. The encoder 218 outputs a compressed slice (e.g., slice N compressed) to a transmitter 220. The transmitter 220 then provides the compressed slice to the display module via a data link (referred to as the physical layer (PHY)). The transmitter 220 is thus providing a continuous stream of data (i.e., a compressed bitstream 239) to the display module 204 with a maximum number of bits per pixel (MaxLinkBitsPerPixel). For selective regional updates, the data flow may be suspended (thus, the compressed bitstream 239 may not be continuous). The compressed bitstream 239 may be divided into independently decodable slices. The use of display stream compression (DSC) may enable higher resolution over limited display links such as Display Port, HDMI and USB 3.0.
The display module 204 receives the compressed bitstream 239 using a receiver 222. The receiver 222 then provides the received compressed bitstream 239 to a display stream compression (DSC) decoder 210. The display stream compression (DSC) decoder 210 may include a slice mapper 224, control data 226, a compressed frame buffer 212, a decoder 232 and display geometry 234. The display stream compression (DSC) decoder 210 may map slices of regional updates in the compressed frame buffer 212 (also referred to as a compressed bitstream buffer). The slice mapper 224 may determine where slices 240a are placed in the compressed frame buffer 224 (i.e., the compressed slice location stored in a compressed slice location list 230), which is determined from control data 226 obtained from the received compressed bitstream 239. Because the compressed data may be interleaved, the slice mapper 224 may need to deinterleaves the compressed data before placing slices 240a in the compressed frame buffer 224.
The size of compressed slices 240a may be bounded by a limit (which implies the necessary size of the compressed frame buffer 239). In addition, the encoder 218 must ensure that unchanged slices in the compressed frame buffer 212 are not overwritten. Thus, untransmitted slices 240 will not be overwritten in the frame buffer 214. Furthermore, the transmission of regional updates should be restricted to avoid collisions between the slice mapper 224 and the decoder 232 each accessing the compressed frame buffer 212 at the same time. This is not a significant issue with an uncompressed frame buffer but can be problematic with a compressed frame buffer 212.
The compressed bitstream 239 may be a compressed representation of pixels 216 for display. The compressed bitstream 239 for each frame may be decomposed into independently decodable units (slices 240). Each slice 240 may include an identifier based on the position in raster scan order. The code stream structure may have the ability to start and end each slice 240 within the code stream. In one configuration, this may require a fixed number of bits per slice 240. In another configuration, the slice 240 size may be signaled as part of an update. Markers in the code stream may also be used at slice 240 boundaries. In one configuration, single slices 240 per update may be used, making the start of each slice 240 determined by the update command from the host 228.
Each slice 240 may be bounded based on the number of bits per pixel (bpp) placed on the compressed frame buffer 212 as given in Equation (1):
∀nSize(Slice[n])≦NumberPixelsPerSlice·MaxBufferBitsPerPixel. (1)
The total data from all slices 240 for each frame may be limited based on a bound on the number of bits per pixel placed on the link rate between the transmitter 220 and the receiver 222 (in addition to the limits on the individual slice 240 size) as described in Equation (2):
ΣSize(Slice[n])≦NumberPixelsPerFrame·MaxLinkBitsPerPixel. (2)
The display stream compression (DSC) decoder 210 may maintain a compressed slice location list 230. The compressed slice location list 230 allows the slice mapper 224 and the decoder 232 to determine the location (i.e., the starting point and ending point) of each slice 240 in the compressed frame buffer 212. The slice 240 geometry determines the number of pixels per slice 240. A bound on the slice 240 size MaxSliceSize may be set by the number of pixels in the slice 240 and the parameter MaxBufferBitsPerPixel as given in Equation (3):
MaxSliceSize=NumberPixelsPerSlice·MaxBufferBitsPerPixel. (3)
The compressed frame buffer 212 may allocate this amount of space (i.e., the MaxSliceSize) for the slice 240 and any future regional updates of the slice 240. The start of each slice 240 in the compressed frame buffer 212 is determined by the number of pixels in each slice 240 and the bound on bits per pixel (bpp) in a slice 240: SliceStart[n]=n·MaxSliceSize. The slice 240 start may typically be rounded up to the nearest byte boundary in implementations. The end of each slice 240 in the compressed frame buffer 212 is determined by the start and by the number of compressed bits used to represent the slice 240: slice—bits[n].
The slice mapper 224 is responsible for receiving a code stream in a full frame or regional updates and mapping the code stream to the compressed frame buffer 212. The slice mapper 224 may read the slice number from the compressed bitstream 239 or regional update and determine where the data should be placed in the compressed frame buffer 239 (and how much data to write). The slice number may be inferred by tracking the amount of data received since the beginning of a frame rather than signaled explicitly. In one configuration, the compressed data for slices 240 may be interleaved during transmission. The interleaving may include interleaving data from the slices 240 in each row. Interleaving may be performed at the bit/byte level.
The slice mapper 224 may also update the compressed slice location list 230. For example, the slice mapper 224 may update the compressed slice location list 230 with the actual size in bits of each compressed slice 240. The compressed slice location list 230 may indicate whether slice 240 sizes are fixed, the starting point of a slice 240 and the ending point of a slice 240 within the compressed frame buffer 212. The slice mapper 224 may copy the compressed data for each slice 240 received from the physical layer (PHY) into the compressed frame buffer 212. The slice mapper 224 may also introduce data alignment or structure onto the data written to the compressed frame buffer 212.
The compressed frame buffer 212 may hold the code stream for each slice 240 of the frame. Space may be reserved for each slice 240 based on the slice 240 geometry and the maximum size of each slice 240 according to Equation (3) above. The data in the compressed frame buffer 212 may be accessed in an interleaved/parallel fashion. The data may be interleaved during transmission. A slice 240 row time interleaved data transmission refers to scenarios where data from each slice 240 in a row is interleaved at slice 240 row time intervals. For bit/byte interleaved slice 240 data, no additional buffering is needed for the compressed data. Individual slice 240 columns may be delayed relative to each other to further reduce buffering needs.
The decoder 232 may decode compressed data (e.g., slice M compressed 240b) from the compressed frame buffer 212. The decoder 232 may then write the pixel data 238 to the display panel 236. The slice 240 structure may permit slices 240 to be decoded in parallel. Parallel processing of slices 240 is especially useful for processing slices 240 in a line. Parallel processing of slices 240 is discussed in additional detail below in relation to
The decoder 232 may need to access both the start and end positions of slices 240 in the compressed frame buffer 212 in order to decode the slices 240. Thus, the decoder 232 may read the compressed slice location list 230 to access necessary information. The display geometry 234 may determine where pixels should be written to the display panel 236. If parallel slice 240 decoding and raster scan writing are used for writing to a display panel 236, the pixel output of individual parallel decoders 232 may be interleaved.
The slice mapper 224 may write data to the same buffer that the decoder 232 is reading from. Without restrictions, the data being read by the decoder 232 could be overwritten by the slice mapper 224 as new data arrives. To avoid these collisions, a schedule of available times to access the compressed frame buffer 212 (read or write) may be enforced. It may be assumed that the decoder 232 begins decoding a frame from the compressed frame buffer 212 at an offset from the beginning of the frame time. The decoder 232 may operate on slices 240 in raster scan at a uniform rate until the end of the frame. Before the decoder 232 can access data for slice N 240, the encoder 218 must have first transmitted slice N 240 to the display module 204. The schedule of times for the encoder 218 to transmit data to the decoder 232 within a time frame may be limited by this constraint.
For regional updates, a limited number of full slices 240 of compressed data are sent from the host 228 to the display module 204. This is different from eDP 1.4, where selected regional updates are scan line based. The X position of selected regional updates may be any multiple of 16. Each regional update may include information describing the location of a slice 240 (e.g., the slice 240 number in a raster scan), information allowing the slice mapper 224 to determine the size of the slice 240 and information indicating where the slice 240 data should be placed in the compressed frame buffer 212. A regional update may include one or more slices 240. If a regional update includes multiple slices 240, the regional update may also include information describing location bits within the regional update for each slice 240 (e.g., signal slice 240 size, markers).
Regional updates may not be allowed at arbitrary times within a time frame (to prevent collisions between the slice mapper 224 and the decoder 232). This is similar to the constraint mentioned above, where the decoder 232 is assumed to operate at a uniform rate following the start of a frame. The transmission of a regional update may be restricted, such that the regional update is available before the decoder 232 access slices 240 corresponding to the regional update.
The parallel decoding HRD is appropriate for parallel decoding of partial width slices 540 for increased throughput. The parallel decoding HRD reverts to the serial HRD when slices are equal to full width. A selective update HRD is appropriate for mobile devices using a compressed frame buffer 112.
In the proposed parallel HRD model, M refers to the number of threads, R is the bit rate, S is the size of the individual HRD buffers and D is the initial decoding delay. Each frame 444 is composed of slices 440 with width W/M, which form M columns of slices 440. Each column may be referred to as a thread. Each thread may have multiple slices 440 in height. The pixel time is denoted by P.
A parallel set of M HRDs may operate with relative delay and constant rates. There are M HRD models (one per thread). Each HRD buffer has equal size S and is initialized empty at the start of each frame 444. The operating rate is a constant input rate equal to the bits per pixel (bpp) link rate R/M for the HRD buffer of each thread. The initial decoding delay is specified as a number of pixels times
for the ith HRD model. The arrival of bits in the ith HRD is delayed by
bits relative to the arrival of bits in the 0th HRD. After an initial delay, the bits arrive at each HRD at a uniform rate of R/M bits per pixel time P.
Parallel operation occurs on all threads. The removal schedule begins by removing bits from the ith HRD after the specified initial delay. Coded bits are removed from the ith HRD representing a group of pixels in the ith thread at each group time (P*M*number of pixels per group). The removal continues to remove bits corresponding to each group of pixels. When M=1, the parallel HRD model reverts to the serial HRD model. Each thread has an HRD which operates in parallel but is suitably delayed. The parallel HRD model enables an efficient parallel implementation but does not mandate a parallel implementation. The limits on the compressed bitrate variation may be used to design serial slice decoders as well.
For an application using selective updates, a frame buffer already exists. The requirements on the bitstream and the arrival schedule are reduced as compared to other HRD models. The slice geometry may be fixed (but can be selected from the options the decoder 232 presents). In addition, the size of a compressed slice 240 is fixed (i.e., bpp* pixels in a slice). The slice 240 data arrival may be constrained to allow decoding pipelined one row of slices 240 behind the transmission.
For the selective update HRD model shown, the slice 240 height H and width W are specified. The compressed frame buffer 112 is initially empty and the first frame 444 must include data for all slices 440 of the picture. During each frame 444, compressed data corresponding to a slice 440 in rows n*H through (n+1)*H can only be written to the HRD during line times n*H through (n+1)*H. The transport layer is responsible for ensuring this, either through appropriate buffering of received data or transport timing limitations. Slices 440 may be selectively skipped while obeying this constraint. Compressed data corresponding to slices 440 in rows m*H through (m+1)*H are read from the HRD at time (m+1)*H. The bits are not removed and are available for decoding subsequent frames 444 until overwritten.
In addition to delivering data according to the appropriate HRD model, the transport layer may convey additional information such as slice geometry, slice location information, and various flags. The slice geometry may specify the fixed spatial decomposition of each frame 444 into slices 440. The slices 440 may be numbered in raster scan order. The slice height/width should be consistent with low level compression size requirements (the slice 440 must include full code unit blocks). The frame 444 may be padded to an integer number of slices 440 high and wide. It may also be required that all slices 440 have the same size.
The slice geometry, slice size and picture resolution may be signaled to a decoder 232 external to the code stream or encoded in the code stream and extracted by the slice mapper 224. Slice geometry is typically fixed but could be changing. A change in slice geometry may be followed by a frame 444 that includes all slices 240 for the frame 444 in the new geometry (i.e., limited regional updates are not allowed when slice geometry changes). Each slice 440 that is received needs to be routed to an appropriate location/HRD model.
The transport layer may convey a flag indicating if the current frame 444 can be used for future partial update applications (i.e., the current frame 444 must be saved for the future). In some applications, this flag is required to be zero. But for mobile applications, this flag may be 1, which indicates data will be saved for future frames 444, or 0, which indicates that the data will not be needed and the memory may be powered down. The transport layer may also convey a flag that indicates all slices 440 are in the current frame 444. If all slices 440 are in the frame, slices 440 can be routed based on the order of arrival. If all slices 440 are not in a frame, each slice 440 can be routed based on slice identifier.
A serial HRD has a buffer size of S bits, which is equal to the rate buffer size S. The bits per pixel rate is equal to the bpp rate R of the DSC encoder that the serial HRD is modeled on. The initial decode delay may be specified as part of the DSC configuration in units of pixel times. The input schedule may specify that bits start to arrive at an arbitrary time. Bits may arrive at the specified bits per pixel time rate. Bits may begin to be removed from the buffer after specified initial decode delay pixel times. Then, a specified number of bits per group may be removed at each group time. The group time is the pixel time multiplied by the number of pixels per group. The bits per group may have a fractional component. If so, the integer component of the value may be removed and the residual fraction may be added to the value to be removed at the next group. Bits may continue to be removed until the last group of the slice is decoded.
The round robin slice decoding may decode lines 842 of pixels from all slices 440 in a row via time multiplexing to avoid significant raster buffering needs of the output. If the slices 440 are multiplexed per slice row time, the data for a row may not fit in a row time (likely for the first row of each slice 440). The decoder 832 must wait until data from the second row time has begun to arrive before beginning to decode the first line, to avoid stalling. This may increase the buffering needs. If finer levels of multiplexing are used (such as per byte or per bit), the buffering at the transport layer is minimal but each slice 440 needs a rate buffer equal to M*HRD size for slices 440 of width W/M, resulting in a total rate buffer that is approximately equal to that of a full frame. Individual slices 440 may be delayed by 1/M of a line time relative to the previous slice 440.
The decoded pixels 948 are then sent to the display in raster order (referred to as raster out 946). Parallel slice decoding may require a single line buffer that is
of a line 942. The decoder 932 and raster out 946 are phased appropriately for a single line buffer.
Each slice 440 that is decoded in parallel may be delayed so that a single line raster buffer is sufficient. The individual slice decoders 932 may be staggered to reduce the reconstruction buffer. The decoder i+1 may be delayed 1/M line times relative to the decoder i. There may be M independent rate buffers. Data may be added to the buffer using various methods such as slice line time multiplexed or bit/byte multiplexed. The data may be removed from each rate buffer by a decoder 932 running at a reduced rate of W/M pixels per line time. The rate buffer capacity of the ith decoder is the size of the individual rate buffer. The relative delay to other decoders of (i−1)/M line times may increase the buffering needs. The total buffering is approximately the rate buffer of the picture without slices plus the buffer of
line times of compressed data.
Both round robin and parallel processing may reduce the slice to raster conversion buffer size requirement. The buffering of the input may be increased to assure data is available for the decoders 932. Interleaved or parallel decoding of slices 440 requires access to data from all slices 440 of a row before the first slice 440 is fully decoded. The relative delay of an individual column of slices 440 is that column i+1 is delayed by i/M. The design of buffers should be such that buffering is not merely moved to the compressed domain.
The electronic device 1002 includes a processor 1055 that controls operation of the electronic device 1002. The processor 1055 may also be referred to as a CPU. Memory 1049, which may include both read-only memory (ROM), random access memory (RAM) or any type of device that may store information, provides instructions 1051a (e.g., executable instructions) and data 1053a to the processor 1055. A portion of the memory 1049 may also include non-volatile random access memory (NVRAM). The memory 1049 may be in electronic communication with the processor 1055.
Instructions 1051b and data 1053b may also reside in the processor 1055. Instructions 1051b and/or data 1053b loaded into the processor 1055 may also include instructions 1051a and/or data 1053a from memory 1049 that were loaded for execution or processing by the processor 1055. The instructions 1051b may be executed by the processor 1055 to implement the systems and methods disclosed herein.
The electronic device 1002 may include one or more communication interfaces 1057 for communicating with other electronic devices. The communication interfaces 1057 may be based on wired communication technology, wireless communication technology, or both. Examples of communication interfaces 1057 include a serial port, a parallel port, a Universal Serial Bus (USB), an Ethernet adapter, an IEEE 1094 bus interface, a small computer system interface (SCSI) bus interface, an infrared (IR) communication port, a Bluetooth wireless communication adapter, a wireless transceiver in accordance with 3rd Generation Partnership Project (3GPP) specifications and so forth.
The electronic device 1002 may include one or more output devices 1061 and one or more input devices 1059. Examples of output devices 1061 include a speaker, printer, etc. One type of output device that may be included in an electronic device 1002 is a display device 1063. Display devices 1063 used with configurations disclosed herein may utilize any suitable image projection technology, such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED), gas plasma, electroluminescence or the like. A display controller 1065 may be provided for converting data stored in the memory 1049 into text, graphics, and/or moving images (as appropriate) shown on the display 1063. Examples of input devices 1059 include a keyboard, mouse, microphone, remote control device, button, joystick, trackball, touchpad, touchscreen, lightpen, etc.
The various components of the electronic device 1002 are coupled together by a bus system 1067, which may include a power bus, a control signal bus and a status signal bus, in addition to a data bus. However, for the sake of clarity, the various buses are illustrated in
The term “computer-readable medium” refers to any available medium that can be accessed by a computer or a processor. The term “computer-readable medium,” as used herein, may denote a computer- and/or processor-readable medium that is non-transitory and tangible. By way of example, and not limitation, a computer-readable or processor-readable medium may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray® disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.
It should be noted that one or more of the methods described herein may be implemented in and/or performed using hardware. For example, one or more of the methods or approaches described herein may be implemented in and/or realized using a chipset, an application-specific integrated circuit (ASIC), a large-scale integrated circuit (LSI) or integrated circuit, etc.
Each of the methods disclosed herein comprises one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another and/or combined into a single step without departing from the scope of the claims. In other words, unless a specific order of steps or actions is required for proper operation of the method that is being described, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.
It is to be understood that the claims are not limited to the precise configuration and components illustrated above. Various modifications, changes and variations may be made in the arrangement, operation and details of the systems, methods, and apparatus described herein without departing from the scope of the claims.
