Computer graphics processing and selective visual display system – Computer graphics processing – Attributes
Reexamination Certificate
1999-10-29
2002-03-05
Hjerpe, Richard (Department: 2674)
Computer graphics processing and selective visual display system
Computer graphics processing
Attributes
C345S531000, C345S520000, C345S547000, C345S562000
Reexamination Certificate
active
06353440
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to an apparatus and method for generating a display image including video portions. In particular, the apparatus and method of the present invention may be utilized to assist a software embodied MPEG (Motion Picture Encoding Group) decoder to generate video images.
BACKGROUND OF THE INVENTION
Personal computers may be used to generate displays including video portions. For the purposes of the present application, the term “video” refers to full motion video images (e.g., derived from TV, film, video or the like) such as Cirrus Logic MotionVideo™ type displays. MotionVideo Architecture (MVA™) is described, for example, in co-pending U.S. patent application Ser. No. 08/483,584, entitled “DUAL DISPLAYS HAVING INDEPENDENT RESOLUTIONS AND REFRESH DATES”, filed Jun. 7, 1995 and incorporated herein by reference. Such video portions may be generated from a data source (e.g., CD-ROM) where video data may be encoded in one of a number of formats (e.g., MPEG-I, MPEG-II, Indeo™ or the like).
Traditionally, MPEG decoding may be performed by a dedicated hardware decoder. A hardware MPEG decoder may receive MPEG encoded data from a data source (e.g., CD-ROM) and output YUV data to discrete portions of display memory of a display controller, as illustrated in FIG.
2
.
FIG. 2
is a block diagram illustrating major components of a computer system
100
provided with display controller
120
(e.g., Video Graphics Adapter (VGA), Super VGA (SVGA) or the like). Display controller
120
may generate pixel data for display
180
(e.g., CRT, flat panel display or the like) a t a rate characteristic of the refresh rate of display
180
(e.g., 60 Hz, 72 Hz, 75 Hz, or the like) and horizontal and vertical resolution of a display image (e.g., 640×480 pixels, 1024×768 pixels, 800×600 pixels or the like). A continuous stream of pixel data may be generated by display controller
120
at the characteristic rate of display
180
.
Display controller
120
may be provided with a display memory
130
which may store pixel data in text, graphics, or video modes for output to display
180
. Host CPU
110
may be coupled to display controller
120
through bus
150
and may update the contents of display memory
130
when a display image for display
180
is to be altered. Bus
150
may comprise, for example, a PCI bus or the like. System memory
160
may be provided coupled to Host CPU
110
for storing data.
Hardware MPEG decoder
140
may be provided to decode MPEG video data from an MPEG video data source (e.g., CD-ROM or the like) and output decoded video data to system memory
160
or directly to display memory
130
. However, with the advent of increasingly powerful and faster microprocessors (e.g., Pentium™ or PowerPC™ processor or the like) it may be possible to implement MPEG decoding (or the like) entirely within software operating within host CPU
110
. For example, future versions of Microsoft® Windows 95™ may include such MPEG decoding software. Intel® also offers a software video decoding technique under the trademark Indeo™.
Applications software or operating systems (e.g., Windows™ 95) may be provided with such MPEG or Indeo™ decoding software. Placing MPEG or Indeo™ decoding software within applications software or an operating system may allow a user to view video portions on a display screen without the need for purchasing additional hardware such as dedicated MPEG hardware decoder
140
.
However, even with high performance microprocessors, decoding of MPEG data may be a host CPU intensive operation, which may degrade overall performance of computer system
100
. A large portion of host CPU cycles required to implement MPEG decoding may be required for data transfer and formatting, rather than decoding per se.
MPEG data may be decoded and decompressed (in software and/or hardware) from an MPEG data source in several steps. Host CPU
110
(or dedicated MPEG decoder
140
) may retrieve compressed/encoded MPEG data from an MPEG data source (e.g., CD-ROM or the like) and first perform a Huffman decoding, followed by inverse quantization of data, inverse DCT (Discrete Cosine Transform), and motion compensation (compression between frames). For software MPEG decoding, a 90 MHz Pentium™ microprocessor may be just barely able keep up with these first four steps at a rate of 30 frames per second.
Once decoded and decompressed, MPEG data in YUV format may be transferred from component YUV video (i.e., planar form) to a pixel video format (i.e., raster scan format). The pixel video YUV data may then be converted from YUV to RGB (Red, Blue and Green pixel data) and then stored in display memory
130
to be displayed on display
180
. Prior art hardware video accelerators may handle the YUV to RGB conversion step to remove that task from host CPU
110
. However, the step of formatting YUV component data to pixel video form may still be required.
Formatting YUV component data to pixel video form may require host CPU
110
(for hardware MPEG decoding, MPEG decoder
140
) to decode MPEG data, as discussed above into a YUV 4:2:2 video format (i.e., CCIR
601
format) where groups of two pixels may be encoded as two bytes of luminance (Y) data as well as two bytes of chrominance difference (U,V) data. Display
180
and display controller
120
may require that output data be generated in a basic pixel video (i.e., scan line) format such that all data (e.g., RGB or YUV) for each output pixel located in consecutive locations within display memory
130
.
In a YUV 4:2:2 format, two bytes of Y data may be followed by one byte of U data and one byte of V data. Each double word (DWORD) read out may thus comprise information for two adjacent pixels of data which may be read by display controller
120
in sequential addresses to be consistent with pixel video methods of display and make best use of available memory bandwidth.
Prior art MPEG decoding techniques (hardware or software) may first decompress MPEG data from an MPEG data source (e.g., CD-ROM or the like) into separate Y, U, and v values. These Y, U, and V values may then be stored initially into separate Y, U, and V memory areas (planes) in system memory
160
as illustrated in
FIG. 1A
in a format known as YUV planar format or component YUV.
System memory
160
may comprise separate contiguous areas of memory
102
,
103
and
104
for storing Y, U and V data, respectively. For video data in the CCIR
601
format, two Y values may be provided for each U and V values to comprise pixel data for two adjacent pixels. Thus, the Y portion of system memory
160
may be twice as large as each of the respective U and V portions
103
and
104
.
To combine separate Y, U, and V data into a format convenient for prior art video accelerators, host CPU
110
may first read two bytes of data from system memory area
102
containing Y data and shift one of those bytes over to a different byte location within a 32 bit DWORD register within host CPU
110
. Next, host CPU
110
may read a byte of U data from the U area
103
of system memory
160
and then read a byte of V data from the V area
104
of system memory
160
. Host CPU
110
may then combine separate Y, U, and V data into a YUV 4:2:2 formatted DWORD which in turn may be transferred to display memory
130
.
Such byte shifting operations are not particularly efficient for such processors as the Pentium® processor and thus system performance may be degraded, because a significant percentage of the CPU cycle would be used just for data reformatting (i.e., component YUV to pixel video). Moreover, reading separate Y, U, and V data from non-contiguous portions of system memory
160
may require a large number of random access memory cycles, which will not get page cycles across the bus, further degrading system performance.
For a PCI bus system, it may be possible to combine separate read cycles in an internal cache within host CPU
110
. However, processor and read cycle overhead may prevent system
100
from taking full advantage of burst cycles avai
Carr & Ferrell LLP
Hjerpe Richard
Nguyen Francis
S3 Graphics Co., Ltd.
LandOfFree
Hardware assist for YUV data format conversion to software... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Hardware assist for YUV data format conversion to software..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Hardware assist for YUV data format conversion to software... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2873414