Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-07-15
2002-07-16
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C345S522000, C717S127000
Reexamination Certificate
active
06421738
ABSTRACT:
TECHNICAL FIELD
This invention relates to screen capture video. More particularly, this invention relates to a method and system for capturing and encoding full-screen video graphics into an electronic file.
BACKGROUND OF THE INVENTION
With the release of new versions of computer program modules, such as word processing program modules and spreadsheet program modules, even experienced computer users may need tutoring on the new features of a recently-released version of a program module. Thus, tutorials and demonstrations are a vital part of training programs that are conducted when a program module is released. Screen capture video is often used in connection with these tutorials and demonstrations so that the audience is able to see an accurate visual representation of the screen when certain selections and features of the program module are executed. For example, prior to a tutorial, a tutor may execute certain selections and features of a program module and capture these selections using a screen capture video program module. The video may then be replayed during the tutorial. Thus, during the tutorial, the tutor is free to concentrate on the tutorial while demonstrating features of the program module by simply playing the screen capture video.
Most existing screen capture video program modules capture video by “grabbing” a raster bitmap image of the display screen at a fixed time interval, such as every {fraction (1/10)}th of a second. However, screen capture video program modules that sample at fixed time intervals suffer from some drawbacks. One drawback of sampling the screen at a fixed time interval is that changes that occur in the time period between the samples are not captured. For example, suppose the screen capture video program module captures the screen at time (n) and time (n+10 ms). If the user is dragging a cursor across the screen, any movement of the cursor between time (n) and time (n+10 ms) is not captured. The playback of the screen capture video is jerky because of the uncaptured data.
Some screen capture video program modules store the captured raster bitmap images, or frames, as raw and uncompressed data. Storing the captured frames as raw and uncompressed data suffers from several drawbacks. A single 640×480 resolution frame will typically exceed 307,200 bytes in length (and considerably more bytes at higher bit depths and resolutions). Thus, one drawback of storing captured frames as raw and uncompressed data is that the disk subsystem generally cannot effectively process the volume of data being written out during capturing and the volume of data being read in during playback. Thus, there are delays and slowdowns in the computer system.
An alternative screen capture video method that has been developed is to use difference analysis to store captured frames instead of storing the captured frames as raw and uncompressed data. Difference analysis comprises determining the pixel differences between a current captured frame and a previous captured frame and saving only those pixels that have changed. However, difference analysis suffers from several problems of its own. One problem with difference analysis is that it requires the storage of the previous frame in a copy buffer which occupies valuable and limited memory space. Another problem with difference analysis is that the comparison between the previous captured frame and the current captured frame requires much the bandwidth of the processing unit in a computer system. Thus, other applications that require the processing unit are slowed down, and the computer system appears to be running slowly and inefficiently to the user.
In addition to the problems outlined above, still another problem with existing screen capture video program modules is their inability to detect palette changes. In other words, when the color of an object on the screen is changed, existing screen capture video program modules typically will not detect this change and color mismatches occur.
There is a need in the art for a method and system that captures screen frames without losing any of the actions that occur on the screen. In other words, there is a need in the art for a lossless screen capture video program module. There is still a further need in the art for a method and system for capturing screen movements that reduce the amount of memory and disk storage required for a given screen capture video. There is also a need in the art for a screen capture video method that accurately portrays the palette colors displayed on the screen and that does not result in color mismatches.
SUMMARY OF THE INVENTION
The present invention satisfies the above described needs by providing a system and method for capturing and encoding full-screen video graphics. Generally described, the present invention provides a computer-implemented method that captures and encodes all of the API function calls that call routines which change the screen of a monitor.
In one aspect, the present invention provides a method for encoding video graphics of a computer system including a monitor. The video graphics are displayed on the monitor by a number of graphical application programming interface (API) routines. The graphical API routines are executed in response to a plurality of graphical API function calls. The method comprises hooking all of the graphical API function calls so that when one of the graphical API routines is called the graphical API function call will be diverted to an encoding subroutine. Under the control of the encoding subroutine, the graphical API function call is unhooked. A determination is made whether any initial state parameters need to be stored and, if so, then the initial state parameters are stored in records. The graphical API function is then called and executed. A determination is made whether the graphical API function call was successfully executed and, if not, then the hook is restored to the graphical API function call. However, if the graphical API function call was successfully executed, then determining whether the graphical API function call was directed to the monitor and, if not, then the hook to the graphical API function call is restored.
If the graphical API function call was directed to the monitor, then a determination is made whether there are any dependent objects of the graphical API function call that need to be stored. If so, the dependent objects are stored in records. The graphical API function call is then stored in a record.
In yet another aspect, each graphical API function call may be hooked by determining a memory address of the graphical API routine associated with the graphical API function call. The memory address, or logical code page, for the graphical API routine in memory is fixed in memory. The bytes of the graphical API routine that are to be overwritten are saved. The bytes of the graphical API routine are then overwritten so that the graphical API function call will be directed to a screen capture video program module. The graphical API function call is hooked after the above steps.
In still another aspect, the step of determining whether the graphical API function call was successfully executed may be accomplished by checking the return code of the graphical API function call.
In another aspect, the step of determining whether there are any dependent objects of the graphical API function call that need to be stored may be accomplished by determining whether a dependent object of the graphical API function call is dirty and, if so, then storing a new record for the dependent object.
These and other features, advantages, and aspects of the present invention may be more clearly understood and appreciated from a review of the following detailed description of the disclosed embodiments and by reference to the appended drawings and claims.
REFERENCES:
patent: 5355493 (1994-10-01), Silberbauer et al.
patent: 5475843 (1995-12-01), Halviatti et al.
patent: 5487172 (1996-01-01), Hyatt
patent: 5796413 (1998-08-01), Shipp et al.
patent: 5889518 (1999-03-01), Poreh et al.
Olsen Thomas W.
Ratan Maithreyi Lakshmi
Bullock, Jr. Lewis A.
Courtenay III St. John
Merchant & Gould
LandOfFree
Method and system for capturing and encoding full-screen... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for capturing and encoding full-screen..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for capturing and encoding full-screen... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2878391