Method and mechanism of automatic video buffer flipping and display sequence management

[0002] The present invention generally relates to computer system architecture, and more particularly, relates to a method and mechanism of automatic video buffer flipping and display sequence management in a computer system.

[0003] A typical computer system includes a processor subsystem of one or more microprocessors such as Intel® i386, i486, Celeron™ or Pentium® processors, a memory subsystem, one or more chipsets provided to support different types of host processors for different platforms such as desktops, personal computers (PC), servers, workstations and mobile platforms, and to provide an interface with a plurality of input/output (I/O) devices including, for example, keyboards, input devices, disk controllers, and serial and parallel ports to printers, scanners and display devices. Chipsets may integrate a large amount of I/O bus interface circuitry and other circuitry onto only a few chips. Examples of such chipsets may include Intel® 430, 440 and 450 series chipsets, and more recently Intel® 810 and 8XX series chipsets. These chipsets may implement, for example, the I/O bus interface circuitry, direct memory access (DMA) controller, graphics controller, graphics memory controller, and other additional functionality such as graphics visual and texturing enhancements, data buffering, and integrated power management functions.

[0004] For graphics/multimedia applications, video data (i.e., audio and visual data) may be captured by one of these chipsets from a video source using general video capturing techniques, and concurrently displayed for viewing purposes. During active video or animation, a series of images may be displayed on a display monitor in sequential order. Video data may be sequentially stored in a series of buffers. Software is typically provided to drive video hardware specifically configured to sequentially store images in those buffers and “flip” display contents from one image to another. The flipping of display contents of images is activated through software interrupt service provided by an operating systems (OS) such as Microsoft Windows™ 95/98, Windows NT™ and Windows 2000™. However, due to interrupt latency (delay) problem, the software-based method of flipping display contents of images can be inefficient and/or unreliable. Moreover, such a software-based method can also be cost-prohibitive and burdensome in terms of processor cycles required while increasing the likelihood of display quality problems in heavily loaded systems.

[0005] Accordingly, a need exists for a hardware-based automated solution to simultaneous video capture and display without the need for software intervention, that is, to relieve the software from the task of flipping display contents of images and increase the efficiency and performance of the simultaneous video capture and display functions while minimizing the likelihood of display quality problems in heavily loaded systems and the processor cycles required.

[0006] Accordingly, various embodiments of the present invention are directed to a hardware-based graphics controller for processing video data in a computer system. Such a graphics controller may include a video capture engine which captures fields of video data from a video source for storage in video buffers in sequential order, and generates video capture parameters from the video data for determining proper flipping operations of display contents of one image to another on a display monitor; and a video overlay engine coupled to the video capture engine, which determines proper flipping operations of display contents of one image to another from the video buffers and adjusts display settings of the display contents for a visual display on the display monitor based on the video capture parameters from the video capture engine.

[0007] A more complete appreciation of exemplary embodiments of the present invention, and many of the attendant advantages of the present invention, will become readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:

[0008] FIG. 1 illustrates a block diagram of an example computer system having a graphics/multimedia platform of multi-media engines according to an embodiment of the present invention;

[0009] FIG. 2 illustrates an example graphics controller including a video capture engine and a video overlay engine of an example computer system for processing video data according to an embodiment of the present invention;

[0010] FIG. 3 illustrates an example block diagram of an auto-flip mechanism for interpreting input parameters from a video capture engine and determining proper control for a video overlay engine according to an embodiment of the present invention;

[0011] FIGS. 4A-4B illustrate a Truth Table of the auto-flip mechanism for maintaining predetermined display setting values for different auto-flip operations based on the sequence of video capture signals from the video capture engine and overlay control signals from the video overlay engine according to an embodiment of the present invention;

[0012] FIG. 5 illustrates an example video stream decoder of an example computer system for providing video data according to an embodiment of the present invention; and

[0013] FIG. 6 illustrates another implementation of an example graphics controller including a video capture engine and a video overlay engine for processing video data according to an embodiment of the present invention.

[0014] The present invention is applicable for use with all types of computer systems, processors, video sources and chipsets, including follow-on chip designs which link together work stations such as computers, servers, peripherals, storage devices, and consumer electronics (CE) devices for audio and video communications. The video source may include video storage media, video equipments and/or video consumer electronics (CE) devices. Examples of such consumer electronics (CE) devices may include digital video discs (DVD), audio compact discs (CD), videotapes, laser discs, CD-ROMs (read only memory), digital video cameras, digital still cameras, HD-TVs, satellite networks, cable networks, video cassette recorders (VCR), printers, scanners, imaging systems and cellular systems and those CE devices which may become available as technology advances in the future. However, for the sake of simplicity, discussions will concentrate mainly on a computer system having a basic graphics/multimedia platform architecture of multi-media engines executing in parallel to deliver high performance video capabilities, although the scope of the present invention is not limited thereto. The term “graphics” may include, but may not be limited to, computer-generated images, symbols, visual representations of natural or synthetic objects and/or scenes, pictures and text.

[0015] Attention now is directed to the drawings and particularly to FIG. 1, in which an example computer system 100 having a graphics/multimedia platform of multi-media engines according to an embodiment of the present invention is illustrated. The, computer system 100 (which can be a system commonly referred to as a personal computer or PC) may include one or more processors or central processing units (CPU) 110 such as Intel® i386, i486, Celeron™ or Pentium® processors, a memory controller 120 connected to the CPU 110 via a front side bus 10, a system memory 130 connected to the memory controller 120 via a memory bus 20, a graphics controller 140 connected to the memory controller 120 via a graphics bus (e.g., Advanced Graphics Port “AGP” bus) 30.

[0016] Alternatively, the graphics controller 140 may also be configured to access the memory controller 120 via a peripheral bus such as a peripheral component interconnect (PCI) bus 40, if so desired. The PCI bus may be a high performance 32 or 64 bit synchronous bus with automatic configurability and multiplexed address, control and data lines as described in the latest version of “PC2.1” set forth by the PCI Special Interest Group (SIG) on Jun. 1, 1995 for added-on arrangements (e.g., expansion cards) with new video, networking, or disk memory storage capabilities. The graphics controller 140 controls a visual display of graphics and/or video images on a display monitor 150 (e.g., cathode ray tube CRT, liquid crystal display LCD, and flat panel display FPD). The display monitor 150 can be either an interlaced or progressive monitor, but typically is a progressive display device. A frame buffer 160 may be coupled to the graphics controller 140 for buffering the data from the graphics controller 140, CPU 110, or other devices within the computer system 100 for a visual display of video images on the display monitor 150.

[0017] A digital video disc (DVD) drive 170 is connected to the memory controller 120 via the PCI bus 40. The DVD drive 170 may be configured to read data from any one of a number of currently available DVDs. For example, the DVD may be a DVD-Video disc for displaying a movie onto the display monitor 150. Alternatively, the DVD may be a DVD-ROM disc having a computer program stored thereon in order to run the program on the computer system 100. Since the embodiments of present invention are directed to displaying DVD-Video on the display monitor 150, all references hereinafter to DVD may pertain to DVD-Video.

[0018] In the described embodiment, video and audio data from the DVD may be obtained in compressed format. The DVD may store both progressive and interlaced video content in a compressed format in accordance with a standard developed by the Motion Picture Experts Group (MPEG) for use with audio-video data (e.g., MPEG-1, MPEG-2 and MPEG-4). For example, a complete description of the MPEG-2 standard can be found in “Information Technology—Generic Coding of Moving Pictures and Associated Audio Information: Video” published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC); ISO-IEC 13818-2; May 15, 1996. However, the standard formats need not be limited to MPEG-2; other standards for use with audio-video data may also be readily utilized.

[0019] A video stream decoder 180 is connected to the graphics controller 140 and receives the compressed video data stream from the DVD drive 170. The video stream decoder 180 buffers the compressed video data stream in a dynamic random access memory (DRAM) 190, which is coupled to the video stream decoder 180. Although a DRAM is preferred for the speed, other storage devices such as a video random-access-memory (VRAM) may be utilized for the memory 190. The video stream decoder 180 then retrieves the video data from the memory 190 as needed and decompresses and decodes the video data. The decoded video data is output to the graphics controller 140 for processing and eventual display on the display monitor 150.

[0020] In a preferred embodiment of the present invention, the memory controller 120 and the graphics controller 140 may be integrated as a single graphics and memory controller hub (GMCH) including dedicated multi-media engines executing in parallel to deliver high performance 3-dimensional (3D) and 2-dimensional (2D) video capabilities. The GMCH may be implemented as a PCI chip such as, for example, PIIX4® chip and PIIX6® chip manufactured by Intel Corporation. In addition, such a GMCH may also be implemented as part of a host chipset along with an I/O controller hub (ICH) and a firmware hub (FWH). Examples of such a host chipset may include Intel® 810 and 8XX series chipsets which provide a highly-integrated three-chip solution consisting of a graphics and memory controller hub (GMCH; e.g., an Intel® 82810 or 82810-DC100 chip), an input/output (I/O) controller hub (ICH; e.g., an Intel® 82801 chip) and a firmware hub (FWH; e.g., an Intel® 82802 chip).

[0021] The GMCH may be interconnected to the system bus, include a memory controller as well as a graphic controller (which in turn may include a 3D engine, a 2D engine, and a video engine), and be interconnected to any of a system memory, a display cache (e.g., 4 megabytes (MB)), a display monitor and a television (TV; via an encoder and a digital video output signal). Likewise, the ICH may be interconnected to the GMCH, and any of: a PCI bus which may have any of a plurality of PCI-compliant slots, an Industry Standard Architecture (ISA) bus option and a local area network (LAN) option; an audio coder/decoder (Codec) and modem Codec; a plurality of Universal Serial Bus (USB) ports (USB Specification, Revision 1.0); and a plurality of Ultra/66 AT Attachment (ATA) 2 ports (X3T9.2 948D specification; commonly also known as Integrated Drive Electronics (IDE) ports). The USB ports and IDE ports may be used to provide an interface to a hard disk drive (HDD) and compact disk read-only-memory. (CD-ROM). I/O devices, a flash memory (e.g., EPROM) and super I/O may be connected to the ICH of the host chipset for extensive I/O supports and functionalities. Those I/O devices may include, for example, a keyboard controller for controlling operations of an alphanumeric keyboard, a cursor control device such as a mouse, a track ball, a touch pad, joystick, etc., a mass storage device such as magnetic tapes, hard disk drives (HDD), and/or floppy disk drives (FDD), and serial and parallel ports to printers and scanners. The flash memory and the super I/O may be connected to the ICH of the host chipset via a low pin count (LPC) bus. The flash memory may store a set of system basic input/output start up (BIOS) routines to be executed at startup of the computer system 100. The super I/O may provide an interface with another group of I/O devices.

[0022] Turning now to FIG. 2, a block diagram of a graphics controller 140 for controlling the concurrent operation of capturing video data and displaying the same on a display monitor 150 according to an embodiment of the present invention is shown. The graphics controller 140 may include, but may not be limited to, a video capture engine 200 for capturing decoded video data from a video source (e.g., video stream decoder 180) and sending the decoded video data for storage in the frame buffer 160, and a video overlay engine 220 for retrieving video data from the frame buffer 160 for a visual display on a display monitor 150. The manner in which the video data is retrieved is determined by a particular display mode technique, referred to as “bob” and “weave” modes or methods for display on the display monitor 150. For example, the “bob” and “weave” methods may be used to adjust the video data for the progressive and interlaced contents of a video stream such that the video data may be properly displayed on the display monitor 150. The “bob” method may be used for displaying the video content having the interlaced format, while the “weave” method may be used for displaying the video content having the progressive format. A number of techniques can be implemented to perform the “bob and “weave” methods for displaying progressive and interlaced video contents.

[0023] The video capture engine 200 captures fields of video data for storage in the frame buffer 160 in sequential order, and generates video capture signals (input parameters) from the video data for determining proper flipping operations of display contents of one image to another on a display monitor 150. The video overlay engine 220 then determines proper “flipping” events (auto-flip operations) of display contents of one image to another from the frame buffer 160 and adjusts display settings of the display monitor 150 accordingly for a visual display of the decoded video data on the display monitor 150 based on the sequence of input video capture signals (input parameters) from the video capture engine 200. The video capture engine 200 also provides synchronization with the video overlay engine 220 for displaying the decoded video data on the display monitor 150.

[0024] The frame buffer 150 includes, for example, a bank of video buffers (e.g., buffer 1, buffer 2 . . . buffer i) forming a circular queue. One or more fields of video data from the video capture engine 200 are stored in each buffer in a sequential order from buffer 1 to buffer i, and then wraps back to buffer 1 again. Each video buffer of the frame buffer 150 may be a two-dimensional array specified by stride, width and height, and may operate as either an interleaved buffer or a progressive (non-interleaved) buffer for storing video data of different input video formats in different video buffer modes. For example, the video data stored in the video buffer may be: I=Interlaced video, II=Interlaced video with 3:2 pulldown information, or P=progressive or non-interlaced video. Buffer mode may be: I=Interleaved buffer, and P=Progressive or non-interleaved buffer.

[0025] During active video or animation, a series of images need to be displayed on the display monitor 150 in sequential order. In order to prevent tearing artifacts from appearing on the display monitor 150, the video data is sequentially stored in multiple buffers. Each video buffer is overwritten only after the image has been displayed on the display monitor 150. The video overlay engine 220 may synchronize the reading of video data to blanking intervals of the display monitor 150 and move from one buffer to the next buffer in the frame buffer 160 in order to provide a visual display of consecutive images on the display monitor 150.

[0026] According to an embodiment of the present invention, an auto-flip mechanism 240 may be provided within the video overlay engine 220 to automate the concurrent operation of video capture and display on the display monitor 150. The auto-flip mechanism 240 is used to relieve the software from the task of “flipping” the video buffers of the frame buffer 150 for the video overlay engine 220 during video capture in order to improve the efficiency and performance of the concurrent video capture and display functions while reducing the likelihood of display quality problems in heavily loaded systems and reducing the processor cycles required by the software interrupt service.

[0027] During video capture, the video capture engine 200 may fill a bank of buffers (e.g., buffer 1, buffer 2 . . . buffer I) of the frame buffer 160 with fields of video data in a sequential order. At the completed capture of each field of video data, the video capture signals (input parameters) are passed from the video capture engine 200 to the video overlay engine 220. These video capture signals may include, but may not be limited to: Buffer Index, Buffer Field Type, Buffer Method, Picture Complete, and Capture Flip. These input parameters may be defined as follows:

[0028] Buffer Index: A current buffer pointer which identifies the field of video data that has just been captured and the buffer that has just been filled with the currently captured field of video data.

[0029] Buffer Field Type: A field status flag which indicates whether the currently captured field is an even or odd field.

[0030] Buffer Method: An identification bit which indicates whether the video overlay engine 220 accesses the current buffer as an interleaved or non-interleaved buffer (“0”=Non-Interleaved, “1”=Interleaved). An interleaved buffer may hold two consecutive fields of video data with the even field occupying the even addresses of the buffer and the odd field occupying the odd addresses. A non-interleaved buffer may hold only one field of video data.

[0031] Picture Complete: A flag which indicates that the field just captured is a completion of a displayable picture, either a simple progressive frame, or an interlaced field or the second field of a progressive frame (that just completes a picture).

[0032] Capture Flip: An event which indicates that the video capture engine 200 has just completed the capture of a field of video data.

[0033] The auto-flip mechanism 240 may then interpret video capture signals (input parameters) such as, the Buffer Index, the Buffer Field Type, the Buffer Method, the Picture Complete, and the Capture Flip from the video capture engine 200 and determine the proper automatic “flipping” events (auto-flip operations) for the video overlay engine 220 without the need for software intervention.

[0034] FIG. 3 illustrates an example block diagram of the auto-flip mechanism 240 for interpreting input parameters from the video capture engine 200 and determining the proper control for the video overlay engine 220 according to an embodiment of the present invention. As shown in FIG. 3, the auto-flip mechanism 240 may include a bank of registers 310, 320 and 330 used to synchronize the input parameters from video capture engine 200 and temporarily store those values, and a control block 340 used to control proper “flipping” events (auto-flip operations) based on the sequence of input parameters from the video capture engine 200 which are registered in the registers 310, 320 and 330.

[0035] The registers 310, 320 and 330 may be arranged, as sets of shift registers for holding, for example, the current values (n) and the previous two sets of values (n−1, n−2). Shifting may be triggered by the Capture Flip event.

[0036] The control block 340 may include a Truth Table (e.g., look-up table) 350, a State Machine 360 and output registers 370 used to define the behavior of the auto-flip mechanism 240. The Truth Table 350 maintains predetermined display setting values for different auto-flip operations based on the sequence of the video capture signals (input parameters) from the video capture engine 200 and overlay control signals from the video overlay engine 220. The State Machine 360 determines when to latch output results of the Truth Table 350 to the output registers 370, when to update the output registers 370 and how many initial delay cycles (Capture Flip events) to insert at the start of an input picture sequence on the display monitor 150.

[0037] The auto-flip operations may be classified in two categories: static-state conditions and dynamic-state conditions. Static-state auto-flip stands for the cases that the auto-flip operations stay in one operation condition. In contrast, the dynamic-state auto-flip stands for the cases that the auto-flip operates in different modes dynamically based on the input video type. Accordingly, the Truth Table 350 which illustrates auto-flip operations under static-state conditions is shown in FIG. 4A and dynamic-state conditions is shown in FIG. 4B.

[0038] Field definitions, code notations and signal terminology shown in FIGS. 4A-4B are described in Table 1 and Table 2 for simplification purposes.

[0039] Referring to FIGS. 4A-4B, the Truth Table 350 for auto-flip operations under static-state conditions and dynamic-state conditions (caused by the 3:2 pulldown undo operation in the video capture engine) according to an embodiment of the present invention is shown. Autoflip Index indicates different Autoflip operations. Static-state autoflip needs to obey the following rules:

[0040] When Autoflip Index=0, Autoflip operation may indicate WEAVE: regular progressive display for progressive video input captured in non-interleaved buffers. The picture height (H), the vertical scale factor (SFV), the stride (ST) and the initial vertical phase (Ph0) are programmed according to the input progressive frame.

[0041] When Autoflip Index=1, Autoflip operation may indicate BOB_NONINTERLEAVED display for interlaced video input captured in non-interleaved buffers. Data is stored one field per buffer. Each field of video may be displayed by “bobbing.” The picture height (H), the vertical scale factor (SFV), and the stride (ST) are programmed according to the input field. The initial vertical phases (Ph0) and (Ph1) reference to field 0 and field 1, respectively.

[0042] When Autoflip Index=2, Autoflip operation may indicate 3FIELDBOB_NONINTERLEAVED display for interlaced video input captured in non-interleaved buffers (3-field deinterlacing only. No 3:2 pulldown undo). Data is stored one field per buffer. Each field of video may be displayed with 3-field deinterlacing. The picture height (H), the vertical scale factor (SFV), and the stride (ST) are programmed according to the deinterlaced frame. Only initial vertical phase (Ph0) is used.

[0043] When Autoflip Index=4, Autoflip operation may indicate WEAVE_INTERLEAVED display for interlaced video input captured in interleaved buffers. Data is stored two fields per buffer. Fields of video may be displayed by “weaving.”

[0044] When Autoflip Index=5, Autoflip operation may indicate BOB_INTERLEAVED display for interlaced video input captured in interleaved buffers. Data is stored two fields per buffer. Fields of video may be display by “bobbing.”

[0045] When Autoflip Index=7, Autoflip operation may indicate 3FIELD_BOB_INTERLEAVED display for interlaced video input in interleaved buffers (3-field deinterlacing only). Data is stored two fields per buffer. Fields of video may be displayed with 3-field deinterlacing. The picture height (H), the vertical scale factor (SFV), and the stride (ST) are programmed according to the interleaved frame. However, the initial vertical phases (Ph0) and (Ph1) refer to field 0 and field 1, respectively.

[0046] Dynamic-state Autoflip needs to obey the following rules when Autoflip Index=6 or 8, which are the same as in conditions when Autoflip index=4 (WEAVE_INTERLEAVED), 5 (BOB_INTERLEAVED) and 7 (3FIELD_BOB_INTERLEAVED). The picture height (H), the vertical scale factor (SFV), and the stride (ST) are programmed according to the complete frame. The initial vertical phases (Ph0) and (Ph1) are programmed according to the interlaced field 0 and field 1 picture, respectively.

[0047] For example, when Autoflip Index=6, Autoflip operation may indicate Automatic 3:2 pulldown with BOB_INTERLEAVED display for interlaced video input captured in interleaved buffers. The picture height (H), the vertical scale factor (SFV), and the stride (ST) are programmed according to the complete frame. Likewise, the initial vertical phases (Ph0) and (Ph1) are programmed according to the interlaced field 0 and field 1 picture, respectively.

[0048] When Autoflip Index=8, Autoflip operation may indicate Automatic 3:2 pulldown with 3FIELD_BOB_INTERLEAVED display for interlaced video input captured in interleaved buffers. The picture height (H), the vertical scale factor (SFV), and the stride (ST) are also programmed according to the complete frame. Likewise, the initial vertical phases (Ph0) and (Ph1) are programmed according to the interlaced field 0 and field 1 picture, respectively.

[0049] As shown in FIGS. 4A-4B, the Truth Table 350 of the auto-flip mechanism 240 automates video buffer “flipping” operations and provides proper display sequence management in a computer system. Since the graphics controller 140 and the memory controller 120 of the computer system 100 may be integrated as a single graphics and memory controller hub (GMCH) of a host chipset, the auto-flip mechanism 240 may be configured as a software module, a firmware module or a comprehensive hardware/software module which may be built-in the host chipset.

[0050] For purposes of completeness, an example video stream decoder 180 for providing video data for the simultaneous operation of video capture and video display according to an embodiment of the present invention is shown in FIG. 5. The video stream decoder 180 may include a host interface 510, a memory interface 520, a video decoder 530, and a display controller 540 arranged to receive the compressed video data stream from the DVD drive 170 via the graphics controller 140, and decode the video data. The host interface 510 provides an interface to the graphics controller 140 for receipt of the compressed video data therefrom, and is coupled to the memory interface 520 for receipt of the video data from the memory 190. When the compressed video data stream enters the video stream decoder 180, the host interface 510 stores (buffers) the compressed video data stream in the memory 190 via the memory interface 520. Later, the video decoder 530 reads (retrieves) the video data from the memory 190 and decodes the video portion of the data.

[0051] The video decoder 530 couples the decoded data to the display controller 540, which performs the 3:2 pulldown conversion on the progressive frames of the decoded video data stream in a well known manner. As previously mentioned, the DVD typically has stored thereon portions of video data that are in a progressive format and portions of video data in an interlaced format. The display controller 540 performs a conversation (i.e., using the 3:2 pulldown technique) on the portions of the video data that are in the progressive format to the interlaced format. Accordingly, after the display controller 540 performs such 3:2 pulldown technique, the decoded video data will be in the interlaced format (i.e., the decoded video will be “field-based”). The display controller 540 retrieves the video data that is to be converted using the 3:2 pulldown technique from the DRAM 190 via the memory interface 520.

[0052] In the described embodiment of the present invention, the display controller 540 may be provided with a 3:2 pulldown signal generator 550 for generating a repeated_field_flag (R_flag) and a progressive_field_flag (P_flag), and a signal generator 560 for generating decoded video stream based on decoded parameters that are included in the MPEG-2 video data stream from the DVD. Examples of these binary parameters may include a top_field_first (TFF) parameter, which is used to indicate which field of a frame is first in the data stream; a repeat_first_field (RFF) parameter, which indicates whether or not a frame is to have a repeated first field; and a progressive frame (PF) parameter, which indicates the frames of the data stream that are in the progressive format. The parameters are decoded and extracted from the video stream by the video decoder 530, and are passed from the video decoder 530 to the display controller 540 for input to the 3:2 pulldown signal generator 550.

[0053] The 3:2 pulldown signal generator 550 generates the R_flag and the P_flag for each field of the decoded video data from the parameters TFF, RFF, and PF. Specifically, the R_flag is derived from the parameters TFF and RFF. When the display controller 450 performs a 3:2 pulldown operation and a repeated field is generated, the R_flag is set to “1”. Conversely, if a field is not repeated in the 3:2 pulldown conversion, R_flag is set to “0” for that particular field. The P_flag is derived from the parameter PF (i.e., progressive frame parameter) from the decoded MPEG-2 video stream. If a particular field is part of a progressive frame, P_flag is set to “1” for that particular field, and if the field is not part of a progressive frame, P_flag is set to “0” for that particular frame.

[0054] The status of the P_flag and R_flag signals generated by the signal generator 560 for each field of the decoded video stream are then passed to the display system generator 560 which encodes the state of the P_flag and R_flag in each field of the decoded video stream. The display system generator 560 also receives synchronization control information from a synchronization control generator (not shown). The synchronization control generator may be resident on the video stream decoder chip 180 or, alternatively, on another device within the computer system 100. The display system generator 560 receives the decoded video data for inclusion in the decoded video stream. The decoded video stream, with R_flag and P_flag signals encoded thereon for each field of the stream, is then sent from the display system generator 560 to the graphics controller 140.

[0055] FIG. 5 shows only that portion of the graphics controller 140 for processing the decoded video. The graphics controller 140 may include the same video capture engine 200 for capturing decoded video data from a video source (e.g., video stream decoder 180) and sending the decoded video data for storage in the frame buffer 160, and the same video overlay engine 220 for retrieving video data from the frame buffer 160 for a visual display on a display monitor 150 as described with reference to FIG. 2. However, additional circuitry implementation is shown to complement with the video stream decoder 180 as described with reference to FIG. 5. For example, the video capture engine 200 may include a video input interface 202, a sync control decoder 204 including a 3:2 pulldown detector 206, a capture data stream controller 208 and a capture buffer flip controller 210. The capture buffer flip controller 210 may be responsible for generating video capture signals (input parameters) which coordinate “flipping” events (auto-flip operations). The video overlay engine 220 may include an overlay buffer flip controller 222, an overlay data stream controller 224, and an overlay processing and display engine 226. The overlay buffer flip controller 222 may be provided with an auto-flip mechanism 240 as shown in FIG. 3 for interpreting input parameters from the video capture engine 200 and determining the proper control for the video overlay engine 220 according to an embodiment of the present invention.

[0056] The video input interface 202 is arranged to receive the decoded video stream from the video stream decoder 180. The synchronization control decoder 204 is coupled to the video input interface 202. The synchronization control decoder 204 receives the decoded video stream and detects and decodes the synchronization control signals that were embedded in the video data stream by the display system generator 560 in the video stream decoder 180. The synchronization control signals, for example, are used for horizontal and vertical synchronization of the video for the separation of odd and even fields, as well as for other functions, which are well known to those skilled in the art.

[0057] The sync control detector 204 may include a 3:2 pulldown detector 206, which detects the R_flag and P_flag signals for each field of the decoded video stream, the synchronization control information and outputs to the capture data stream controller 208 and to the capture buffer flip controller 210 within the video capture engine 200. The capture data stream controller 208 sends video data from the decoded video stream for storage in a buffer memory (shown as the frame buffer 160), via a memory interface 260. Subsequently, the overlay data stream controller 224 of the video overlay engine 220 retrieves the video data from the frame buffer 160 and sends the video data to the overlay processing and display engine 226 for displaying the video on the display monitor 150.

[0058] As described with reference to FIG. 2, the frame buffer 160 includes a bank of video buffers (e.g., buffer 1, buffer 2 . . . buffer i) forming a circular queue. One or more fields of video data from the video capture engine 200 are stored in each buffer in sequential order from buffer 1 to buffer i, and then wraps back to buffer 1 again. The capture buffer flip controller 210 indicates which video buffer 1 or 2 of the frame buffer 160 to store the video data from the capture data stream controller 208. As the video data is stored in one of the video buffers 1, 2 by the capture data stream controller 208, the overlay data stream controller 224 extracts the video data from the other video buffer for displaying the video data on the display monitor 150 via the overlay processing and display engine 226.

[0059] The capture buffer flip controller 535 further generates video capture signals (input parameters) to the overlay buffer flip controller 222, which coordinates proper “flipping” events (auto-flip operations) or switches process between the video buffers1, 2 . . . i. For example, the capture data stream controller 208 may initially store video data in the first video buffer #1 of the frame buffer 160 while the overlay data stream controller 224 may retrieve video data from the second video buffer #2 to display such video on the display monitor 150. The capture data stream controller 208 and the overlay data stream controller 224 may then receive updated pointer information for video capture and overlay display pointers from their respective flip controllers 210 and 222, such that the capture data stream controller 224 may store video data in the second video buffer #2 and the overlay data stream controller 224 may extract the video data from the first video buffer #1 (which was previously stored by the capture data stream controller 208) for a visual display on the display monitor 150.

[0060] Accordingly, the capture and overlay data stream controllers 208, 224 may switch or swap the video buffers 1, 2 of the frame buffer 160. As the capture data stream controller 208 stores data to one buffer, the overlay data stream controller 224 may load data from the other buffer. A video capture buffer pointer (not shown) may be used to address the location in the buffer for storing the data, while an overlay display buffer pointer (not shown) may be used to address the location where data is to be retrieved.

[0061] As described from the foregoing, the present invention advantageously provides a mechanism to relieve the software from the task of flipping video buffers for the video overlay engine during video capture. During video capture, the video capture engine may fill a series of buffers with video data in a sequential order. The auto-flip mechanism may interpret input parameters from the video capture engine and determine the proper control for the video overlay engine without the need for software intervention, that is, to relieve the software from the task of flipping display contents of images and increase the efficiency and performance of the concurrent video capture and display functions, while minimizing the likelihood of display quality problems in heavily loaded systems and the processor cycles required.

[0062] While there have been illustrated and described what are considered to be exemplary embodiments of the present invention, it will be understood by those skilled in the art and as technology develops that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the present invention. For example, the present invention is applicable to all types of computer systems and video consumer electronics (CE) devices, including, but not limited to, high definition TV (HDTV), video games, video imaging devices and video disks. The present invention is also applicable for all types of compressed video data stream in different formats, and need not be limited to the computer system 100 as shown in FIG. 1, but can be adapted to other video processing devices and systems. Many modifications may be made to adapt the teachings of the present invention to a particular situation without departing from the scope thereof Therefore, it is intended that the present invention not be limited to the various exemplary embodiments disclosed, but that the present invention includes all embodiments falling within the scope of the appended claims.