CN1239630A - Apparatus and method for generating on-screen display message using color realistic mode - Google Patents

Abstract

An apparatus and accompanying method for generating OSD messages by constructing an OSD bitstream that defines a set of "color-true pixels." The OSD bitstream includes an OSD header and OSD data. The OSD unit retrieves pixel control information from the OSD header, which is programmed by the decoding/display system. The OSD header includes information for programming the OSD unit's color palette and provides instructions for processing OSD data. If "color-true mode" is enabled in the OSD header, the OSD unit bypasses the palette and processes the OSD data as color-true pixels. Because the same chrominance component is shared between a pair of consecutive pixels, each successive group of four OSD data bytes represents the actual chrominance and luminance levels of both OSD pixels.

Description

Apparatus and method for generating on-screen display message using color realistic mode

The present invention relates to a method and apparatus for generating an On Screen Display (OSD) message using a color lifelike mode. More specifically, the present invention relates to a method and apparatus for increasing the number of available colors by treating OSD data as color-true pixels instead of pointers to an entire OSD palette.

On-screen display messages play an important role in consumer electronic products, providing the user with an indication of the menus they use throughout and the structure of the product. Other important features of OSD include the ability to provide closed captioning (Closed Captioning) and channel logos (logos) display.

However, changes in digital video technology standards have caused a problem that the amount of OSD messages to be generated and displayed has increased. For example, a particular High Definition Television (HDTV) specification, HDTV must display up to 216 characters in four windows, compared to the current NTSC specification which has a maximum of 128 characters in one window. These new specifications place significant pressure on decoding/display systems used to decode and display television signals (e.g., HDTV, NTSC, MPEG, etc.) The decoded data is provided to the display system with a delay of . Because the OSD message must be displayed (overlaid) with video data, the microprocessor of the decoding/display system must allocate a bandwidth portion of the memory to perform the OSD function, thereby increasing the memory bandwidth of the decoding/display system Requires and total computational overhead.

Therefore, the OSD unit of the decoding/display system includes a palette of limited size in order to reduce hardware requirements and memory accesses. That is, the OSD unit employs a set of registers (entries). Each of these entries contains a representation of the chrominance and luminance levels of an OSD pixel. By encoding these addresses (directories) to the palette as OSD data, the decode/display system can reduce memory access and hardware requirements.

However, these systems have limitations in the number of colors available for the display of OSD messages. Because the palette has a fixed size, it does not lend itself well to standard changes that may be required to support later increases in the number of colors. For example, to increase the number of colors from 16 to 256 (standard VGA), would require 240 additional registers to be added to the palette, whereas currently only 16 entries are supported.

Increasing the number of registers for this palette is indeed possible, but not cost-effective, can cause timing issues (especially for high palette access rates) and other integrated circuit (IC) design issues (e.g., increasing area on the IC). Furthermore, it is difficult and expensive to update existing decoding/display systems with fixed-size palettes.

Therefore, there is a need for a method and apparatus for increasing the number of colors available for OSD messages without increasing the hardware requirements of the decoding/display system, such as the size of the OSD palette.

The present invention relates to apparatus and accompanying methods for generating OSD messages by constructing an active OSD bitstream having a set of "color-true" pixels.

More specifically, according to the present invention, an OSD unit retrieves an OSD bitstream from a storage device. The OSD bitstream contains an OSD header and OSD data. The OSD header contains control information for programming the color palette of the OSD unit and providing instructions on OSD data processing. The control information is programmed by the processor of the decoding/display system. If the "color vivid mode" is enabled in the OSD header, the OSD unit bypasses the palette and handles the OSD data as color vivid pixels. That is, each successive group of 3 OSD data bytes represents the actual chrominance and luminance level of an OSD pixel.

To further reduce memory bandwidth requirements, the same chroma components are repeated for the next pixel. Therefore, each OSD pixel is effectively represented by only 16 bits of data.

These and other aspects of the invention will now be described with reference to the accompanying drawings.

In the attached picture:

1 is a block diagram of a decoding/display system including an OSD unit according to an aspect of the present invention;

Figure 2 is a block diagram illustrating the structure of a sampled OSD pixel bitstream using a color fidelity mode; and

Fig. 3 is a flowchart showing a method of constructing an effective OSD bitstream using the color fidelity mode.

FIG. 1 shows a block diagram of a decoding/display system for a television signal 100 (hereinafter referred to as a decoding system). The decoding system includes a processor 130 , a random access memory (RAM) 140 , a read only memory (ROM) 142 , an OSD unit 150 , a video decoder 160 , and a mixer 170 . The output of mixer 170 is coupled to display device 190 via path 180 .

The present invention is described below in terms of MPEG standards, ISO/IEC International Standards 11172 (1991) (commonly referred to as the MPEG-1 format) and 13818 (1995) (commonly referred to as the MPEG-2 format). However, those skilled in the art will recognize that the present invention may be applied or used to implement other coding systems implementing other encoding/decoding formats.

In the preferred embodiment, the decoding system 100 performs real-time audio and video decompression on various data streams (bitstreams) 120 . The bitstream 120 may include audio and video elementary streams encoded in accordance with the MPEG-1 and MPEG-2 standards. The encoded bitstream 120 is generated by an encoder (not shown) and sent to the decoding system over a communication channel. The coded bitstream contains a coded representation of a set of pictures and may include audio information associated with those pictures, eg, a multimedia data stream. The multimedia source can be an HDTV station, a video disc, a cable TV station, and the like. In turn, the decoding system 100 decodes the encoded bitstream to generate a set of decoded images for display on the display 190 in synchronization with the associated audio information. However, for the purposes of the present invention, the audio decoding functionality of the decoding system 100 is irrelevant and therefore not discussed.

More specifically, processor 130 receives bitstream 120 and bitstream 110 as input. Bitstream 110 may include various control signals and other data bitstreams not included in bitstream 120 . For example, a channel decoder or transport unit (not shown) may be disposed between the transport channel and the decoding system 100 to enable parsing and sending of data packets to a data or control stream.

In the preferred embodiment, processor 130 performs various control functions including, but not limited to, providing control data to video decoder 160 and OSD unit 150, managing access to memory and controlling the decoded image display. Although the present invention describes a single processor, those skilled in the art will appreciate that the processor 130 may include various dedicated devices to manage specific functions, such as memory controllers, microprocessor interface units, etc. .

Processor 130 receives bit stream 120 and writes these data packets into memory 140 via video decoder 160 . The bit stream optionally passes through a First-In-First-out (FIFO) buffer before being transferred to the memory via the memory data bus. There is typically another memory (not shown) which is used only by processor 130.

The memory 140 is used to store a set of data including compressed data, decoded images and OSD bit tables. As such, this memory is typically mapped to various registers, for example, bit buffers for storing compressed data, OSD buffers for storing OSD bit tables, various frame buffers for storing image frames buffer, and a display buffer for storing decoded images.

According to the MPEG standard, the video decoder 160 decodes the compressed data in the memory 140 to reconstruct the coded picture in the memory. In some cases, the decoded picture is a difference signal that is added to the stored standard picture to produce the actual picture according to the compression technique used to encode the picture (eg, to facilitate decoding of motion compensated pictures). Once the image is reconstructed, it is stored in a display buffer via mixer 170 prior to display.

Likewise, OSD unit 150 uses memory 140 to store the OSD bit table or OSD specification. The OSD unit lets the user (manufacturer) define bitmaps for each field superimposed on the decoded image. The OSD bit table may contain information about the configuration and options of a particular consumer electronic product stored in a storage device such as ROM. Alternatively, the OSD bit table may contain information about closed caption and channel information elements transmitted from cable TV, video disc, and the like. An OSD bitmap is defined as a set of regions (typically rectangular) of programmable location and size, each of which has a unique palette of available colors.

The OSD bit table is written to the OSD buffer of memory 140 for user-specified purposes. However, those skilled in the art will recognize that ROM 142 or other equivalent storage devices could also be used for this function.

When the OSD function is activated for a particular image of a frame, processor 130 manipulates the data in memory 140 to generate an OSD bit stream. The OSD bitstream includes an OSD header and OSD data (data defining the pixels of the OSD).

More specifically, processor 130 programs (formats and stores) the OSD header in memory 140 . The OSD header includes information about the location of the top and bottom OSD field tables, palette data, a pointer to the next header block, and various display modes including OSD resolution, color, and compression. Once the OSD header is programmed, the processor 130 may manipulate the OSD data in memory 140 according to a particular implementation. For example, the OSD data is formatted according to a selected mode, such as the color vivid mode discussed below. Alternatively, the processor can simply program the OSD header with a pointer to the OSD data in memory, where the stored OSD data is restored without modification to form the OSD bitstream.

Processor 130 then reports an activation status, eg, OSD active, to OSD unit 150, which responds by requesting processor 130 to access the OSD bitstream stored in memory 140. The OSD bitstream is formed and restored when the OSD unit reads the OSD headers, each followed by their associated OSD data. After receiving the OSD bit stream, the OSD unit processes the OSD pixel data according to the command or selection mode in the OSD header. The OSD unit then waits for a pair of display counters (not shown) to identify the correct location on the display for inserting the OSD information. In this position, the OSD unit sends its output to mixer 170. The output of the OSD unit 150 is a stream or sequence of digital words representing the respective luminance and chrominance on the display screen. New memory accesses may be requested as needed to maintain the necessary data (OSD bitstream) flowing through the OSD unit to generate a composite OSD display. When the last byte of OSD pixel data present in the OSD area is read from the memory, the next OSD header is read, and this process is repeated until the last OSD area of the frame is included.

Those skilled in the art will understand that the above-mentioned sequence of constructing and restoring the OSD bit stream can be changed. For example, the OSD header may be read from memory while the processor is formatting the OSD data, or the OSD unit may process and display the OSD data without restoring the entire OSD bitstream for OSD messages.

Since the OSD pixel data is overlaid onto the decoded image, the mixer 170 selectively mixes or multiplexes the decoded image with the OSD pixel data. That is, the mixer has the ability to display an OSD pixel, a pixel of the decoded image, or a combination (blending) of both pixels at each pixel position. This capability enables the display of closed captions (OSD pixel data only) or transparent channel syndication (combination of both OSD pixels and decoded image pixels) over the decoded image.

Both video coder 160 and OSD system 150 form a stream or sequence of digital words representing sets of luma and chrominance components. These video components represent sequences of digital words coupled via mixer 170 to digital-to-analog converter (DAC) 185 . The luminance and chrominance representation digital words are converted to analog luminance and chrominance signals by respective DAC sections.

The OSD unit 150 can be used to display user-defined bitmaps on any portion of the displayable screen, regardless of the size and location of the active video area. This bit table can be defined independently for each field, defined as a collection of OSD areas. A region is usually a rectangular area defined by its boundaries, and its contents are defined by bit tables. Each zone has a palette associated with it, defining a set of colors (eg 4 or 16 colors) that can be used in that zone. If desired, one of these colors can be transparent so that its entire background is shown as described above.

Although the use of palettes provides significant savings in computational overhead for low-resolution OSD implementations, it cannot provide the necessary display resolution as required by high-resolution OSD implementations. For example, the OSD message may require more colors than are available on the palette, limiting the so-called available colors to the entire number (or actual register) on the palette .

FIG. 2 shows the structure of a sample OSD bitstream 200 using color vivid mode. The OSD bitstream includes a set of OSD headers 210 each followed by OSD data 220 . In one embodiment, the header is composed of five 64-bit words, followed by any number of 64-bit OSD data (bit table) words. The OSD header 210 includes information associated with coordinates 214 of the OSD section, various entries 216 of palettes for a particular OSD section, and various function codes (bits) 212 . Those skilled in the art will appreciate that the OSD header can be of any length. A longer header provides more information and options, e.g., a palette with more entries, but at the cost of higher computational overhead, i.e., more read and write cycles are required to implement OSD functions . In fact, the content of this OSD header is representative of a particular embodiment and is not limited to the specific device shown in FIG. 2 .

The OSD area coordinates 214 include the locations of the left and right edges of the OSD area, ie, row start and stop means, column start and stop locations. For an interlaced display, the field coordinates include the location (pointer) of the top and bottom field pixel bitmaps of the corresponding OSD field. Finally, the OSD area coordinates 214 include a pointer to the next header block in memory.

Palette information 216 includes a set of entries, each entry containing a representation of the chrominance and luminance levels of an OSD pixel. Palette information 216 is used to program the OSD palette. Because each OSD header includes palette information 216, the available colors can be selectively changed for each OSD header and its associated OSD data bytes. Each palette entry may include 16 bits of data, namely, 6 bits of luma Y, 4 bits of chrominance (color difference signal) C _b , and 4 bits of luma (color difference signal) C _r . The remaining two bits are used to perform various display selections related to the present invention. In one embodiment, there are 16 entries on the palette requiring 4 bits to address each entry.

Function codes (bits) 212 include information related to various modes including, but not limited to, display selection and OSD bitstream selection. In the preferred embodiment, the function bits include a single bit indicating whether "color fidelity mode" is enabled.

The OSD data 220 includes bitmap data in order from left to right and top to bottom. Typically the OSD data is used to define the color index of each pixel in the bitmap image. In the preferred embodiment, if the "Color Vivid Mode" is enabled, the OSD data 220 includes color viz. pixels (Color Viz. format) rather than indices to palettes. In the color vivid format, the OSD data stream consists of one byte (r) 222 of the luma component, followed by two bytes of the chroma component (color difference signals _Cb 224 and _Cr 226), followed by the Another byte (228). As shown in Figure 2, this pattern is repeated for successive pixels. The length of each byte is typically set to 8 bits, thus supporting millions of possible color combinations.

For this mode of operation, OSD unit 150 simply passes the color-realistic pixels directly to mixer 170, bypassing the OSD palette, as described above. Also, to support "transparent pixels" (OSD pixels showing the decoded image from the video decoder rather than in the OSD area), the Y components are all set to "0". This arrangement causes mixer 170 to replace the OSD pixel with the corresponding pixel from the decoded image.

Furthermore, the color vivid mode allows for reduced memory bandwidth requirements by repeating the same chrominance component for the next pixel in the bitmap. That is, a pair of consecutive pixels share the same chrominance component.

For illustration, FIG. 2 shows a set of data bytes (pixel data) 231-234 defining a pixel, where each pixel data structure is 24 bits long (8 bits Y, 8 bits _Cb , and 8 bits C _r ). However, pixels 231 and 232 share the same chrominance components 224 and 226 . This pattern is repeated for successive pairs of pixels, effectively requiring only 16 bits of data to represent a single pixel (2 pixels with 32 bits of data).

This mode of operation enables processor 130 to achieve a 33% savings in the amount of data that must be transferred from memory to the OSD unit, ie, reduces the size of the OSD bitstream. More importantly, the number of available colors for each OSD area is greatly increased without increasing the size of the OSD palette. In fact, there are very few, if any, increases in hardware requirements.

FIG. 3 illustrates a method 300 of composing an OSD bitstream using color vivid mode. The method is typically recalled from a storage device, eg, memory, and executed by processor 130 . The OSD bitstream is generated by processor 130 and processed by OSD unit 150 . The method 300 works by generating an OSD header with a color vividness bit followed by a set of data bytes of color vividness pixels. To form the OSD bit stream.

Referring to FIG. 3, method 300 begins at step 305 and proceeds to step 310, where a bit in the OSD header is designated as the color fidelity mode bit. If the color vivid mode is enabled in the OSD header, then the OSD data bytes following the header define the color vivid pixels. If the color fidelity mode is not enabled, the OSD data bytes are processed in normal format, which may be a 4-bit address to a palette (or any other bitstream format, eg, MPEG standard).

At step 320, method 300 determines whether the color fidelity mode is enabled. If the query is answered in the negative, method 300 proceeds to step 325 to generate the OSD data bytes using an achromatic vivid format. The method 300 then proceeds to step 340 .

If the query at step 320 is answered in the affirmative, method 300 proceeds to step 330 where a set of color-realistic pixels is allocated within the OSD data bytes. Each color vivid pixel consists of 3 OSD data bytes, where each OSD data byte is 8 bits long. Because the chrominance component is repeated for successive pixels (or every other group of chrominance components is deleted), two OSD pixels can be accommodated in four OSD data bytes.

At step 340, the method 300 determines whether another OSD header follows the previously processed OSD data. If the various modes represented by the function bits 212 are modified, a new OSD header may be required. Likewise, a new header is required for each new OSD field on the frame. If the answer to the query is negative, method 300 proceeds to step 350 where method 300 ends. If the query is answered in the affirmative, method 300 proceeds to step 320, where steps 320-330 are repeated for each additional OSD header. In this manner, the OSD bitstream may include both color vivid OSD data bytes and achromatic vivid OSD data bytes.

Thus, there has been shown and described a novel method and apparatus for constructing an OSD bitstream defining color-realistic pixels. After considering this specification and the accompanying drawings, which disclose embodiments of the invention, it will be apparent to those skilled in the art that the invention is susceptible to many variations, modifications and other uses and applications. All without departing from the spirit and scope of the invention, which is limited only by the claims that follow.

Claims (19)

1. A method for forming an on-screen display (OSD) bit stream, said method comprising the steps of: setting a bit in the OSD header to use the bit to indicate color fidelity mode; and OSD data defining a set of color-realistic pixels is generated. 2. The method according to claim 1 , wherein each of said set of color-realistic pixels includes a luma component and a chrominance component. 3. The method according to claim 2, wherein a pair of said set of color vivid pixels share the same chrominance component. 4. The method according to claim 3, wherein said pair of color lifelike pixels comprises two consecutive color lifelike pixels. 5. The method of claim 4, wherein said arrangement of a pair of color-realistic pixels includes a first luminance component, followed by said common chrominance component, followed by a second luminance component. 6. The method according to claim 2, wherein said luminance components of the colored vivid pixels are all set to "0", so as to implement a transparent mode. 7. The method according to claim 1, wherein said OSD data generating step is performed without a palette. 8. The method according to claim 1, further comprising the step of generating OSD data defining a group of achromatic vivid pixels. 9. An OSD bit stream stored in a storage medium, comprising: a header with one bit to indicate the color fidelity mode; A set of OSD data bytes, coupled to the header, defines a set of color-realistic pixels. 10. The OSD bitstream according to claim 9, wherein each of said set of color vivid pixels includes a luma component and a chrominance component. 11. The OSD bitstream according to claim 10 , wherein a pair of said set of color vivid pixels share the same chrominance component. 12. The OSD bitstream according to claim 11 , wherein said pair of color lifelike pixels comprises two consecutive color lifelike pixels. 13. The OSD bitstream according to claim 12, wherein said arrangement of a pair of color-realistic pixels comprises a first luminance component, followed by said common chrominance component, followed by a second luminance component. 14. The OSD bit stream according to claim 10, wherein the luminance components of said colored vivid pixels are all set to "0", so as to perform a transparent mode. 15. The OSD bitstream according to claim 9, wherein said OSD data bytes further define achromatic vivid pixels. 16. A device for generating an OSD bit stream, comprising: a storage medium for storing OSD headers and OSD data; a processor, coupled to said storage medium, for enabling a color-realistic mode in said OSD header, and for reading said OSD header and said OSD data defining a set of color-realistic pixels, so that Form OSD bit stream. 17. The apparatus according to claim 16, wherein said storage medium is a read-only memory (ROM). 18. The apparatus according to claim 16, wherein said storage medium is random access memory (RAM). 19. A device for generating an OSD message comprising: a storage medium for storing an OSD bit stream with a header and OSD data; a processor, coupled to said storage medium, for programming a color lifelike mode bit in said OSD header and for formatting said OSD data defining a set of color lifelike pixels; and an OSD unit, coupled to the processor, for processing the OSD bit stream to form the OSD message.

Images