This paper outlines Sonic Technologies
approach to VGA Independence for DVD (and
other motion video formats). Included are
descriptions of what it is, what it isn't,
and what it means to PC OEMs, Retailers,
and End-Users.
By our definition, VGA Independence is
the elimination of common video display
problems associated with sub-standard Video
Graphic Adapter (VGA) functions. We accomplish
this by replacing these functions with host
CPU-based alternatives, in order to display
high-quality motion video on as wide a variety
of VGA subsystems as possible.
But before we can describe the Sonic
approach to VGA Independence, it is necessary
to first discuss why motion video playback
has typically been VGA dependent.
The most fundamental reason is that the
display of motion video involves the movement
and processing of a full screen of information
every 1/30th of a second. For DVD Video,
this can mean 20 MB/sec of data are send
to the VGA subsystem! When handling full
de-interlacing of field data, this transfer
rate increases to 40 MB/sec. That's just
for video; it doesn't include any other
VGA data that needs to be processed, such
as the desktop display, the mouse cursor,
other windows, etc.
Most of the data being fed to the VGA subsystem,
comes from the CPU's Write Buffer. The CPU
fills the Write Buffer independently of
the VGA subsystem, and the VGA subsystem
gets the data out as fast as it can. If
the VGA subsystem can't empty the buffer
fast enough, the CPU will stall and wait
for the buffer to become available again.
While the CPU is stalled, other processing
is stalled as well!
If the CPU stalls, video playback immediately
suffers. Frames aren't processed fast enough
and the video begins to drop frames, stutter
and look jerky.
This stall condition generally occurs when
the rate of data transferred to the VGA
subsystem exceeds 20% of the total VGA subsystem
bandwidth. Given this condition, we find
that in order to achieve the required 40
MB/sec for flawless digital video, the VGA
subsystem must maintain a minimum
200 MB/sec throughout.
With these rigorous demands for transfer
efficiency, one tends to rely on the VGA
card to do most of the work. This is often
the best thing to do, since many VGA subsystems
include hardware support for just this kind
of data movement. But relying on hardware
assistance essentially means being dependent
on it.
VGA subsystems vary widely from one manufacturer
to another, with different performance capabilities
and special features for games, CAD/CAM,
video, etc. Exploiting the special features
of these VGA subsystems usually involves
specific software development for each one
of them. As a result, broad VGA compatibility
becomes a time- and resource-consuming endeavor.
Thankfully, the Microsoft® Windows operating
system and many VGA subsystem manufacturers
have begun to standardize video playback
capabilities. Increasing numbers of VGA
subsystems are offering the same basic support
for video playback, in addition to their
unique enhancements. This makes it possible
for a single product implementation to run
on more platforms than was previously possible.
Unfortunately, advances in the OS and standardized
methods usually lag behind market demand.
This lag forces developers to suffer the
limitations of the current environment,
or invent alternatives to provide the needed
capabilities until an industry-wide solution
appears.
In the following sections, we will discuss
what Windows provides today, and then what
it doesn't. Finally we will present our
approach to video playback while waiting
for the OS — and standards — to evolve.
Microsoft DirectDraw
DirectDraw provides device-independent
access to display memory, a hardware blitter,
hardware overlay support, and surface flipping
functions. Essentially, applications using
DirectDraw can allocate memory, fill it
with image data, and display it in a manner
consistent with motion video, without having
to know the specifics of how the memory
is stored or used inside the VGA subsystem.
DirectDraw also abstracts a lot of the more
complex vagaries of memory by presenting
everything in a flat memory model, rather
than the historical address:offset model.
DirectDraw provides these capabilities
through a Hardware Abstraction Layer (HAL).
The HAL is device-specific, provided by
each VGA manufacturer. It presents a standardized
interface to DirectDraw, through which the
necessary functionality for video display
can be negotiated. Applications never talk
directly to the HAL. Rather, they use the
functions defined by DirectDraw to interact
with the HAL in a device-independent way.
The HAL implements only device-specific
(and device-supported) features, and reports
them to DirectDraw. If any basic functions
are missing, DirectDraw can usually still
perform them, through emulation. This is
done through a Hardware Emulation Layer
(HEL). Again, hardware abstraction and hardware
emulation are all handled by DirectDraw,
so the application needn't worry about what
the VGA hardware supports or doesn't support
(see Figure 1.).
Figure
1:
DirectDraw architecture overview
Among the common VGA features that are
instrumental to video display, we will discuss
the following: Scaling, Overlay, Deinterlacing
and Surface Flipping. How well or poorly
the VGA developer implements these features
will have an enormous effect on the quality
of video during DVD (and DTV) playback.
Scaling
Many VGA subsystems support scaling for
video surfaces. There are two types of scaling,
up-scaling and down-scaling.
Up-scaling occurs when a video image is
stretched larger than its original size
for display. An example of this would be
taking a 640x480 image and stretching it
to fit full screen on a 1024x768 monitor
display. Up-scaling may occur proportionally
(fixed aspect ratio) or disproportionally
(variable aspect ratio).
Down-scaling occurs when a video image
is shrunk smaller than its original size
for display. An example of this would be
taking a 640x480 image and shrinking it
to fit in a 320x240 viewer window. As with
up-scaling, down-scaling may occur proportionally
or disproportionally.
In either case, the direction you are scaling
is irrelevant. The application simply tells
DirectDraw the size of the current image
data and the size of the destination video
surface, and DirectDraw automatically handles
the scaling tasks (up or down).
However, if the VGA hardware doesn't
support scaling, the DirectDraw HEL does
not have the capability of performing this
task. Scaling simply isn't done in this
case. Video that is too big for the display
window is cropped to fit; video that is
too small for the display area, is generally
centered in the window and surrounded with
black or a neutral color.
Figure
2:
Overview of up- and down-scaling
Overlay surfaces
Overlay surfaces are separate areas of
display memory, reserved specifically for
holding video image data. These surfaces
are linked to special hardware in the VGA
subsystem that can overlay them onto any
computer-generated graphics that might also
be on the main computer screen.
Figure 3: Overlay overview.
Thus, overlay surfaces with their hardware
support can often accelerate the display
of video on a computer monitor and improve
the viewer's experience.
In the event that a VGA subsystem does
not have specific hardware for surface support,
DirectDraw's HEL handles the task. Performance
is generally not as good, since the CPU
must perform the tasks of specialized hardware,
but again, the video player application
doesn't need to know or care.
Scaling
Many VGA subsystems handle up-scaling very
well. Some have straightforward algorithms
to stretch the image to a larger size, while
others use complex algorithms to stretch,
smooth, and filter the image to a high quality.
A small number of VGA subsystems don't handle
up-scaling very well, but they are rare
and fading away.
A larger number of VGA subsystems do not
handle down-scaling very well at all. But
rather than report to DirectDraw that they
don't do down-scaling, they implement a
basic, low-grade algorithm. There is no
way for DirectDraw to know how well or poorly
scaling is implemented, so the results are
often not as predictable as they should
be.
Some of the techniques used by these VGA
subsystems are:
- For vertical down-scaling, most implementations use a line-dropping
algorithm. This deletes some of the image data and compresses the rest
together to make it smaller, leaving diagonal lines looking jagged and
rough.
Figure
4: Vertical down-scaling by line-dropping
- For horizontal down-scaling, there are a number of implementation
choices but many resort to cutting the data in half (binary reduction)
and then scaling the much smaller result back up to the desired size.
This results in equally rough looking video.
Figure
5: Horizontal scaling by binary reduction
and up-scaling
The overall effect is that image quality
is reduced and the viewer suffers. It is
very difficult to detect these different
low-grade techniques programmatically; making
it almost impossible for a software application
to know when poor quality scaling it being
used.
In cases where low-grade scaling is done
through the blit engine of the VGA subsystem,
the overall performance of DVD playback
is lowered dramatically. This is due to
the fact that the VGA card typically performs
scaling and blit operations when the video
surface is unlocked. It interprets an unlock
event as its signal that the DVD software
has finished decoding an image into the
surface.
Any time the surface is unlocked, the VGA
drivers (and other applications) can access
it and perform additional operations, such
as scaling. Each driver or application that
wishes to manipulate the surface in some
way then places its own lock and holds it
until its operation is complete. While other
applications lock the surface, the original
DVD software can't access the surface until
all other locks are removed.
However, in the course of decoding image
data into an overlay surface, there are
times when the surface is unlocked for reasons
other than completion. A VGA subsystem that
uses the type of scaling described here
has no way to detect why a surface was unlocked;
only that it was.
In the event that it was unlocked for a
reason other than completion, a problem
arises when the DVD software attempts to
re-lock it. If the VGA scaling routines
have surfaces locked, the DVD software has
to wait until the VGA subsystem lets go,
before it can finish writing data into the
surface.
Such delays interrupt the extremely time-sensitive
operation of decoding and displaying 60
individual fields (combined into 30 frames)
of image data every second to produce motion
video. Thinking about this inversely for
a moment, it means that all of the operations
that need to be performed on an individual
field must be completed in 1/60th of a second.
Often, the VGA subsystem interrupts processing
(when it incorrectly locks a surface) for
more than 1/60th of a second. This causes
fields to be dropped (as the DVD software
tries to keep up with new incoming fields).
The end-user will see dropped, stuttering
frames and generally poor video quality.
De-interlacing
Motion video from the television world
consists of 30 frames of video displayed
each second, resulting in the appearance
of smooth motion. Due to early television
technology limitations that won't be discussed
here, each of these frames is divided into
two fields. Each field consists of half
the image, sliced line-by-line. Thus, the
odd field consists of all the odd numbered
scan lines and the even field consists of
all the even numbered scan lines. The fields
are then displayed, one after the other
using a method called "interlacing."
Most computer displays do not use interlacing.
Rather, they display each of the lines of
a frame "progressively," in a non-interlaced
manner. So, to display interlaced movies
on a non-interlaced computer display, a
process of de-interlacing is needed.
Figure
6: Example of two fields interlaced into
a single frame
"Bob and Weave"
There are many ways to perform de-interlacing,
but the most visually successful is to display
each field in succession, using an algorithm
called "Bob." Because each field contains
only half the vertical resolution of a full
frame, it must be doubled in vertical size.
This can be accomplished by simply repeating
each scan line in the field, but is more
successful when pixel interpolation is performed.
In this case, new lines are synthesized,
based upon analysis of the neighboring scan
lines.
The Bob part comes when we realize that
picture content in the even field is one
line higher than that in the odd field.
So, a line must be added to the even field
to keep the picture content from 'bobbing'
up and down on alternate frames. The result
is a series of complete frames, delivered
to a progressive scan monitor at a rate
of 60 frames per second (fps).
In some cases, a VGA subsystem performs
deinterlacing by simply pasting two fields
together without any processing or smoothing.
This can produce heavily distorted frames,
especially if scaling is performed on the
resulting frame. Proper combination of fields
into frames involves smoothing and averaging
of the content on a scan-line by scan-line
basis and requires a lot of performance
capability on the part of the VGA subsystem.
As with scaling, if the VGA drivers report
de-interlacing capabilities, there is no
way for DirectDraw to know how well or how
poorly they are implemented. So when relying
on DirectDraw for de-interlacing, the results
are, again, not as predictable as they should
be.
The result is often rough looking video.
In some extreme cases (as in a scene transition),
the two fields will actually contain different
scenes, and simply combining them will result
in a flickering, out-of-focus image that
looks very bad.
Figure
7: Effect of improperly combined fields.
It is very difficult to detect this programmatically,
making it almost impossible for a player
application to know when the VGA subsystem
is not combining fields properly.
Deinterlacing can be further complicated
when the frame rate of the source material
doesn't match that of the display technology.
For instance, most theatrical motion pictures
are shot on film at a rate of 24 fps. When
encoded to DVD, the 24 fps rate is preserved.
Most computers, on the other hand, redraw
their screens at least 60 times per second
(and sometimes much more frequently).
The process of repeating or combining or
otherwise manipulating frames from one frame-rate
to another requires another algorithm called
"Weave." When implemented properly, the
Bob and Weave algorithms can produce a 60
fps progressive-scanned video display that
is almost indistinguishable from the motion
picture or video source. When implemented
poorly, or not at all, the results are disastrous!
Incorrectly deinterlacing poorly scaled
video compounds the detrimental effects
of both processes resulting in very poor
video quality. This is a bad situation to
find yourself in.
Surface flipping
To facilitate the rapid display of fields — and
support combining fields into frames — the
frames of video are decoded into surfaces.
There are usually multiple surfaces residing
in memory, and the VGA subsystem "flips"
them one by one onto the main display for
the viewer to see. The other surfaces are
kept out of sight while new video data are
being stored into them; to be displayed
as soon as the appropriate time occurs.
This cycle is repeated over and over again,
with new images being filled into the hidden
surfaces while the current image is being
displayed in the visible surface.
Figure
8: Example of surface flipping using 3 surfaces
Timing Issues
The flipping of surfaces is very time-critical.
We cannot begin writing new data into a
surface until we are sure it is no longer
the visible surface. If we did, the top
and bottom portions of the displayed image
wouldn't match, causing a very awkward tearing
of the video.
DirectDraw provides a very simple function
called "Flip( )" to perform surface flipping.
As the application finishes decoding the
video data into the hidden surfaces, calls
are made to this function to display them.
Then subsequent calls are made to a function
called GetFlipStatus( ) which would either
report that the Flip( ) is complete, or
that it is still in progress. Only when
the status is complete can we begin writing
new data.
Unfortunately, in an effort to speed up
some forms of display, VGA drivers sometimes
report flip completion too soon. As with
scaling and de-interlacing, it is very difficult
to detect programmatically whether the VGA
subsystem is timing the surface flips correctly.
Image Quality Issues
It is also not always possible to know
exactly how a given VGA subsystem places
data into a surface for flipping. Some VGA
adapters simply decode raw video fields
into a surface (thus producing a half-resolution
image). Some may attempt one form or another
of field averaging, combination, interpolation,
etc. If the adapter has trouble with scaling
or deinterlacing in general, then its ability
to prepare surfaces for flipping will almost
surely be affected. In many cases, the result
is unsatisfactory video playback and a disappointed
end-user.
Summary
Obviously, any one of the conditions described
above can result in an unsatisfactory experience
for the viewer. A combination of any or
all of them just compounds the problem rendering
the system unusable for motion video playback.
In the best-and least likely of cases,
the viewer understands that the environment
is not capable of high quality motion video
display and ceases trying to use it for
that. In the worst — and more likely — of cases
the viewer believes the environment to be
solid and the recently added motion video
playback feature to have the problem.
So, how do we address these problems? By
implementing a layer of video scaling, de-interlacing,
and surface flipping that can be performed
by the host CPU in the event that the VGA
subsystem is either not capable at all,
or has only basic implementations that do
not meet expected quality requirements.
Collectively this layer of host CPU-based
functions provides what we call "VGA Independence."
Areas of focus
Given the dramatic and obvious visual impact
of poor scaling and poor de-interlacing,
these two areas make up the primary focus
of our VGA Independence efforts. Detecting
and compensating for these two deficiencies
has the greatest benefit for improving poor
image quality, and making us less reliant
on the capabilities (or lack thereof) of
the VGA subsystem. Thereby gaining us
a level of VGA independence!
The general idea is to attempt to identify
known environments by checking for key characteristics.
If we are able to recognize the environment,
we use a set of developed and tested parameters
for working with that VGA subsystem. For
instance, we query the VGA adapter and discover
that it is a Cataract 350 product based
on the Globe Viscera graphics chipset. Knowing
this, we can load the set of Viscera customized
parameters and play to the strengths of
that platform.
If we are not able to identify a known
environment, we attempt to access each of
the known interfaces we have developed and
test it against the unknown VGA device.
If the VGA subsystem responds correctly
to one of these interfaces, even though
it does not identify itself as that system,
we will use the parameters for the similar
VGA subsystem. For instance, we may detect
a VGA adapter from an unknown manufacturer,
but be able to determine that it uses the
same Viscera chipset used in Cataract's
adapter. Frequently, we can treat the unknown
adapter as if it were the branded one, by
directly addressing its chipset.
If the VGA environment is totally new,
and we do not have a set of developed parameters
to rely on, we need to figure out how to
best run within this new environment. We
have a general algorithm that detects the
environment and scales our response to best
fit the given conditions. It is more complex
than the one pictured below, but follows
the general idea. There are multiple-levels
of CPU assistance available, so that our
implementation can scale with faster processors
if needed.
Based on the results of all the algorithms
described and pictured above, we end up
with a combination of functions being handled
by the VGA subsystem and functions being
handled by the host CPU. The outcome is
that the viewer is presented with the best
possible video quality despite any performance
limitations that may be present in the system.
Scaling
If it is necessary for the host CPU to
provide video image scaling (either up-scaling
only, down-scaling only, or both), a series
of tests is run to determine what level
of CPU processing power is available to
handle it.
We have a number of scaling algorithms
at our disposal, each of which has increasingly
better image quality and increasingly higher
CPU utilization requirements. Based on tests
of how much CPU processing power is available
, we select the appropriate algorithm to
use.
In such cases, we perform all of the scaling
tasks in software and simply deliver pre-scaled
video images to DirectDraw for display on
the VGA device. This bypasses the poor quality
scaling of the VGA subsystem as well as
the basic scaling algorithm used by the
DirectDraw HEL, delivering higher quality
video to the viewer.
De-interlacing
If it is necessary for the host CPU to
provide video de-interlacing, a series of
tests is run to determine what level of
CPU processing power is available to handle
it.
Since there is only a finite amount
of CPU processing power available on a given
computer, preference will be given to scaling
over deinterlacing. A poorly combined frame
that mixes two high-quality fields is more
visually pleasing than a well-combined frame
composed of poor quality fields.
Here again we have a number of algorithms
at our disposal, each of which has increasingly
better image quality and increasingly higher
CPU utilization requirements. Based on tests
of how much CPU processing power is available
to us, we select an appropriate de-interlacing
algorithm to use.
Surface flipping
Surface flipping capability is the most
difficult to detect and compensate for.
At this time there is very little that can
be done, other than to make some broad assumptions
about performance, and respond accordingly.
Our range of available responses, however
is fairly broad and permits us to custom-fit
a surface flipping strategy to the given
VGA subsystem.
Compensating for Timing Issues
As mentioned previously, a lot relies on
the timing of the Flip( ) function, how
quickly it completes its work and how quickly
it reports completion to an application
checking via the GetFlipStatus( ) function.
On VGA platforms that are completely unknown,
the best way to ensure that the flips are
complete is to enforce a minimum delay between
calling the Flip( ) function and writing
new data into a surface. This is done by
making an assumption that it cannot take
longer than 1/60th of a second to display
a field, so as long as we wait one full
1/60th of a second before writing into a
surface, we will not experience video tearing.
However, waiting a full 1/60th of a second
before writing into a surface, plus the
time is takes to perform the decoding into
a surface, makes it very difficult to display
smooth motion video in real time on all
but the fastest processors.
So, there are a number of techniques that
can be used to determine how long to wait
before writing into a surface. Our default
is to calculate the "safest" delay time
based on certain system parameters for initial
use. Through testing and evaluation by a
trained technician, we can then select the
most appropriate setting for long-term use,
if so desired.
Compensating for Image Quality Issues
When it isn't possible to know how a given
VGA subsystem decodes video data into surfaces,
or when we do know that it generally doesn't
perform this function well, we can apply
one of several device-specific "Flip Modes."
Again, our selection of flip mode is based
upon an evaluation of the VGA adapter's
capabilities, available CPU and memory resources.
While many of the Sonic flip modes remain
proprietary, the following examples will
provide a general idea of how we apply this
technology to produce the best quality video
playback in a given environment.
- Simple Flip - In cases where the VGA
adapter is simply too slow to permit sophisticated
image quality improvement techniques,
we simply fill the surfaces with frame
data and use the default DirectDraw Flip(
) command to drive the display as quickly
as possible.
- Pseudo Flip - If the VGA adapter (or
the operating system) doesn't support
the use of overlay surfaces at all, we
can convert the video from its native
YUV color space into RGB data (which the
VGA system expects) and write it directly
into the adapter's display memory.
- Interlaced Flip - Some VGA adapters
support multiple parallel surfaces to
be combined (interlaced) in hardware.
In such a case, we can fill two surfaces
simultaneously and take advantage of the
VGA adapter's interlacing ability to produce
a very high-quality output.
- Averaged-Field Deinterlaced Flip - Lower
quality than our Bob and Weave implementations,
this mode deinterlaces fields into frames
through simple line-averaging. It is applicable
in situations where CPU resources are
limited and can work in a wider range
of platforms than other modes.
- Software Deinterlaced Flip - If CPU
resources permit, we can also perform
all field deinterlacing and scaling entirely
in software and deliver completed, sized
frames to the surfaces, thereby sidestepping
entirely the particular limitations of
the VGA adapter. While this method requires
the most CPU loading, it can produce the
highest quality display possible.
The main point to be drawn from this discussion
is that the CinePlayer VGA Independent technology
is intelligently adaptive: It can analyze
the nature of its environment and pick a
best-fit operational profile that transparently
delivers the highest quality experience
to the viewer. If the VGA subsystem offers
high-quality hardware support, we will use
it to best advantage. Whenever the VGA subsystem
doesn't measure up, we can preprocess the
data we give it in order to minimize the
detrimental effects.
It should be fairly obvious that VGA Independence
does not replace the VGA subsystem. What
may not be so obvious are the other areas
where VGA Independence cannot compensate
for or correct VGA subsystem limitations.
For instance, when he VGA subsystem itself
simply can't draw pixels or refresh the
computer screen fast enough, there's very
little we can do.
Bugs
What may be only slightly less obvious
is that VGA Independence does not compensate
for bugs in VGA subsystems (chips, boards,
drivers, etc.). These bugs do exist and
do impact motion video playback. There are
even some times when they do not affect
any other function of the VGA subsystem,
and only impact motion video. VGA Independence
cannot automatically predict and compensate
for these bugs, it can simply try to do
its best in spite of them.
We try to understand and compensate for
bugs in VGA subsystems when it is not possible
for the VGA subsystem manufacturer to correct
the bug (or correct the bug as quickly as
we might be able to compensate for it).
However, it should be understood that this
is all "after-the-fact" activity when a
performance problem is reported; it cannot
be anticipated ahead of time.
CPU, RAM and VRAM
As mentioned throughout this paper, Software
CinePlayer VGA Independence requires a considerable
degree of resource support from the host
system. Specifically, a 350 MHz Pentium
II class central processor is required for
minimal software DVD player functionality
(slower systems can still take advantage
of the Sonic Hardware CinePlayer solution).
Processors from other manufacturers (350
MHz and higher AMD, 400 MHz and higher Cyrix,
etc.) are also supported. Typically, a system
must also have more than 32 MegaBytes of
RAM, in order to support Software CinePlayer DVD playback at full frame rates.
Finally, the VGA adapter, itself, must
have at least 3.1 MegaBytes of video or
display RAM. This is the memory type used
for the preparation of overlay surfaces.
This must be surplus display memory beyond
whatever is required to contain the main
computer display. If there isn't enough
video RAM to decode multiple frames into,
CinePlayer certainly cannot produce seamless
video playback.
Display Write Speed
We noted that it's possible for a VGA subsystem
to simply not have the performance capabilities
necessary to display motion video. As mentioned
at the beginning of this paper, motion video
can require on average up to 20 MB/sec of
data transfer speed simply to display the
primary video. For DVD the data transfer
rate requirements increase to handle sub-picture
and Closed Caption text, in addition to
the buffering of future video frames. If
the VGA subsystem cannot receive data at
this rate, no amount of CPU compensation
will help. The data will never get to the
display fast enough.
Display Update Speed
It is also possible for a VGA display device
to be unable to update surfaces fast enough.
As described above in the Surface Flipping
sections, the 30 frames of video that need
to be displayed each second consist of 2
fields. The effective result is that the
display surfaces need to be updated 60 times
each second. This means that the routine
responsible for flipping the surfaces needs
to perform its task in less than 1/60th
of a second. Some low-cost VGA subsystems
can perform this task in 1/30th (or even
1/50th of a second), but not fast enough
for smooth, high-quality motion video display.
VGA Independence cannot completely compensate
for this either.
Advanced Features
VGA Independence is designed specifically
to not rely on special features of a VGA
subsystem. Advanced features such as hardware
Motion Compensation acceleration, hardware
IDCT acceleration, hardware sub-picture
decoding and alpha blending are all unique
features to specific VGA subsystems. By
our definition at the start of this paper,
supporting such advanced VGA subsystem features
is contrary to the purpose of VGA Independence.
Because of the benefits they represent,
we will continue to implement support for
the advanced features of various VGA subsystems,
both currently on the market and those to
be introduced in the future. But it is important
to note that these implementations must
be done for each new VGA subsystem, and
that such activity can't be conducted in
any "independent" manner.
As the Windows OS continues to evolve,
it is expected that more and more of these
advanced features will become standardized.
When that happens, we can move toward general
implementation of these features, and have
them work on VGA subsystems that we have
not specifically tested.
Flexibility to explore
new VGA platforms
As new VGA devices become available to
PC OEMs, they can install our product on
their platforms and evaluate our performance
without us having any prior experience with
that new VGA device.
If the performance is satisfactory, the
PC OEM can begin shipping as soon as is
practical for them. If there are unique
features that need to be supported, those
can be added at any time in the future without
hampering basic usability.
Flexibility to switch
from old to new drivers
In many cases, PC OEMs ship a version of
product or drivers that has fallen behind
the most current release. This often happens
when selling to corporate customers with
IT departments that prefer known and stable
products they can comfortably support instead
of the latest, greatest feature set.
In cases like this, some features of the
VGA device may not be accessible in the
current driver set, but will become available
in a new driver set. With the implementation
of VGA Independence, host-based routines
can be used for the current version of the
product, to be replaced by newer, specific
routines when the VGA device is updated.
All without having to change or update the
DVD product.
Flexibility to sell
the product with the least restrictions
Retailers are able to sell our product
to a larger number of customers, with fewer
restrictions on which VGA platforms work
with it. If a new VGA platform becomes available,
customers can still purchase and use our
product without having to wait for us to
obtain, characterize, and support the unique
capabilities of that device. When such unique
support is available, it will enhance the
performance of the product, not just enable
it.
When end users buy a new VGA card to install
in their system, or update a driver from
a manufacturer's Web site, it is possible
that enough changes will occur that the
previous settings for DVD playback no longer
apply.
With VGA Independence, the host-based routines
are able to automatically detect and correct
for the problems described in this paper.
Should such problems be introduced into
an otherwise working computer system, the
host-based routines will be able to compensate
and the end-user will be able to continue
enjoying DVD playback on their new VGA device.
In the competitive marketplace of VGA display
system technology, developers and manufacturers
are continually working to improve and position
their products. As a developer of software
DVD and video solutions, Sonic can and
will continue to devote resources to supporting
these new technologies as quickly as they
can be perfected.
But through its pursuit of VGA independent
decoding and display technologies, Sonic
is able to ensure the best possible quality
in video playback, regardless of the particular
VGA subsystem in use. This approach provides
the greatest benefits to our OEM customers,
Independent Hardware Vendors and end-users
and establishes Software CinePlayer as the
premiere DVD solution for most any environment.
|