Why vista will suck!

[dirio49]

Sorry for the long post, just thought it was interesting :)



A Cost Analysis of Windows Vista Content Protection
===================================================

Peter Gutmann, pgut001@cs.auckland.ac.nz
http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt
Last updated 23 December 2006

Executive Summary
-----------------

Windows Vista includes an extensive reworking of core OS elements in order to
provide content protection for so-called "premium content", typically HD data
from Blu-Ray and HD-DVD sources. Providing this protection incurs
considerable costs in terms of system performance, system stability, technical
support overhead, and hardware and software cost. These issues affect not
only users of Vista but the entire PC industry, since the effects of the
protection measures extend to cover all hardware and software that will ever
come into contact with Vista, even if it's not used directly with Vista (for
example hardware in a Macintosh computer or on a Linux server). This document
analyses the cost involved in Vista's content protection, and the collateral
damage that this incurs throughout the computer industry.

Executive Executive Summary
---------------------------

The Vista Content Protection specification could very well constitute the
longest suicide note in history.

Introduction
------------

This document looks purely at the cost of the technical portions of Vista's
content protection. The political issues (under the heading of DRM) have been
examined in exhaustive detail elsewhere and won't be commented on further,
unless it's relevant to the cost analysis. However, one important point that
must be kept in mind when reading this document is that in order to work,
Vista's content protection must be able to violate the laws of physics,
something that's unlikely to happen no matter how much the content industry
wishes it were possible. This conundrum is displayed over and over again in
the Windows content-protection specs, with manufacturers being given no hard-
and-fast guidelines but instead being instructed that they need to display as
much dedication as possible to the party line. The documentation is peppered
with sentences like:

"It is recommended that a graphics manufacturer go beyond the strict letter
of the specification and provide additional content-protection features,
because this demonstrates their strong intent to protect premium content".

This is an exceedingly strange way to write technical specifications, but is
dictated by the fact that what the spec is trying to achieve is fundamentally
impossible. Readers should keep this requirement to display appropriate
levels of dedication in mind when reading the following analysis [Note A].

Disabling of Functionality
--------------------------

Vista's content protection mechanism only allows protected content to be sent
over interfaces that also have content-protection facilities built in.
Currently the most common high-end audio output interface is S/PDIF
(Sony/Philips Digital Interface Format). Most newer audio cards, for example,
feature TOSlink digital optical output for high-quality sound reproduction,
and even the latest crop of motherboards with integrated audio provide at
least coax (and often optical) digital output. Since S/PDIF doesn't provide
any content protection, Vista requires that it be disabled when playing
protected content. In other words if you've invested a pile of money into a
high-end audio setup fed from a digital output, you won't be able to use it
with protected content. Similarly, component (YPbPr) video will be disabled
by Vista's content protection, so the same applies to a high-end video setup
fed from component video.

Indirect Disabling of Functionality
-----------------------------------

As well as overt disabling of functionality, there's also covert disabling of
functionality. For example PC voice communications rely on automatic echo
cancellation (AEC) in order to work. AEC requires feeding back a sample of
the audio mix into the echo cancellation subsystem, but with Vista's content
protection this isn't permitted any more because this might allow access to
premium content. What is permitted is a highly-degraded form of feedback that
might possibly still sort-of be enough for some sort of minimal echo
cancellation purposes.

The requirement to disable audio and video output plays havoc with standard
system operations, because the security policy used is a so-called "system
high" policy: The overall sensitivity level is that of the most sensitive data
present in the system. So the instant any audio derived from premium content
appears on your system, signal degradation and disabling of outputs will
occur. What makes this particularly entertaining is the fact that the
downgrading/disabling is dynamic, so if the premium-content signal is
intermittent or varies (for example music that fades out), various outputs and
output quality will fade in and out, or turn on and off, in sync. Normally
this behaviour would be a trigger for reinstalling device drivers or even a
warranty return of the affected hardware, but in this case it's just a signal
that everything is functioning as intended.

Decreased Playback Quality
--------------------------

Alongside the all-or-nothing approach of disabling output, Vista requires that
any interface that provides high-quality output degrade the signal quality
that passes through it. This is done through a "constrictor" that downgrades
the signal to a much lower-quality one, then up-scales it again back to the
original spec, but with a significant loss in quality. So if you're using an
expensive new LCD display fed from a high-quality DVI signal on your video
card and there's protected content present, the picture you're going to see
will be, as the spec puts it, "slightly fuzzy", a bit like a 10-year-old CRT
monitor that you picked up for $2 at a yard sale. In fact the spec
specifically still allows for old VGA analog outputs, but even that's only
because disallowing them would upset too many existing owners of analog
monitors. In the future even analog VGA output will probably have to be
disabled. The only thing that seems to be explicitly allowed is the extremely
low-quality TV-out, provided that Macrovision is applied to it.

The same deliberate degrading of playback quality applies to audio, with the
audio being downgraded to sound (from the spec) "fuzzy with less detail".

Amusingly, the Vista content protection docs say that it'll be left to
graphics chip manufacturers to differentiate their product based on
(deliberately degraded) video quality. This seems a bit like breaking the
legs of Olympic athletes and then rating them based on how fast they can
hobble on crutches.

Beyond the obvious playback-quality implications of deliberately degraded
output, this measure can have serious repercussions in applications where
high-quality reproduction of content is vital. For example the field of
medical imaging either bans outright or strongly frowns on any form of lossy
compression because artifacts introduced by the compression process can cause
mis-diagnoses and in extreme cases even become life-threatening. Consider a
medical IT worker who's using a medical imaging PC while listening to
audio/video played back by the computer (the CDROM drives installed in
workplace PCs inevitably spend most of their working lives playing music or
MP3 CDs to drown out workplace noise). If there's any premium content present
in there, the image will be subtly altered by Vista's content protection,
potentially creating exactly the life-threatening situation that the medical
industry has worked so hard to avoid. The scary thing is that there's no easy
way around this - Vista will silently modify displayed content under certain
(almost impossible-to-predict in advance) situations discernable only to
Vista's built-in content-protection subsystem.

Elimination of Open-source Hardware Support
-------------------------------------------

In order to prevent the creation of hardware emulators of protected output
devices, Vista requires a Hardware Functionality Scan (HFS) that can be used
to uniquely fingerprint a hardware device to ensure that it's (probably)
genuine. In order to do this, the driver on the host PC performs an operation
in the hardware (for example rendering 3D content in a graphics card) that
produces a result that's unique to that device type.

In order for this to work, the spec requires that the operational details of
the device be kept confidential. Obviously anyone who knows enough about the
workings of a device to operate it and to write a third-party driver for it
(for example one for an open-source OS, or in general just any non-Windows OS)
will also know enough to fake the HFS process. The only way to protect the
HFS process therefore is to not release any technical details on the device
beyond a minimum required for web site reviews and comparison with other
products.

[dirio49]

Elimination of Unified Drivers
------------------------------

The HFS process has another cost involved with it. Most hardware vendors have
(thankfully) moved to unified driver models instead of the plethora of
individual drivers that abounded some years ago. Since HFS requires unique
identification and handling of not just each device type (for example each
graphics chip) but each variant of each device type (for example each stepping
of each graphics chip) to handle the situation where a problem is found with
one variation of a device, it's no longer possible to create one-size-fits-all
drivers for an entire range of devices like the current
Catalyst/Detonator/ForceWare drivers. Every little variation of every device
type out there must now be individually accommodated in custom code in order
for the HFS process to be fully effective.

If a graphics chip is integrated directly into the motherboard and there's no
easy access to the device bus then the need for bus encryption (see
"Unnecessary CPU Resource Consumption" below) is removed. Because the
encryption requirement is so onerous, it's quite possible that this means of
providing graphics capabilities will suddenly become more popular after the
release of Vista. However, this leads to a problem: It's no longer possible
to tell if a graphics chip is situated on a plug-in card or attached to the
motherboard, since as far as the system is concerned they're both just devices
sitting on the AGP/PCIe bus. The solution to this problem is to make the two
deliberately incompatible, so that HFS can detect a chip on a plug-in card vs.
one on the motherboard. Again, this does nothing more than increase costs and
driver complexity.

Further problems occur with audio drivers. To the system, HDMI audio looks
like S/PDIF, a deliberate design decision to make handling of drivers easier.
In order to provide the ability to disable output, it's necessary to make HDMI
codecs deliberately incompatible with S/PDIF codecs, despite the fact that
they were specifically designed to appear identical in order to ease driver
support and reduce development costs.

Denial-of-Service via Driver Revocation
---------------------------------------

Once a weakness is found in a particular driver or device, that driver will
have its signature revoked by Microsoft, which means that it will cease to
function (details on this are a bit vague here, presumably some minimum
functionality like generic 640x480 VGA support will still be available in
order for the system to boot). This means that a report of a compromise of a
particular driver or device will cause all support for that device worldwide
to be turned off until a fix can be found. Again, details are sketchy, but if
it's a device problem then presumably the device turns into a paperweight once
it's revoked. If it's an older device for which the vendor isn't interested
in rewriting their drivers (and in the fast-moving hardware market most
devices enter "legacy" status within a year of two of their replacement models
becoming available), all devices of that type worldwide become permanently
unusable.

The threat of driver revocation is the ultimate nuclear option, the crack of
the commissars' pistols reminding the faithful of their duty [Note B]. The
exact details of the hammer that vendors will be hit with is buried in
confidential licensing agreements, but I've heard mention of multimillion
dollar fines and embargoes on further shipment of devices alongside the driver
revocation mentioned above.

Decreased System Reliability
----------------------------

"Drivers must be extra-robust. Requires additional driver development to
isolate and protect sensitive code paths" -- ATI.

Vista's content protection requires that devices (hardware and software
drivers) set so-called "tilt bits" if they detect anything unusual. For
example if there are unusual voltage fluctuations, maybe some jitter on bus
signals, a slightly funny return code from a function call, a device register
that doesn't contain quite the value that was expected, or anything similar, a
tilt bit gets set. Such occurrences aren't too uncommon in a typical computer
(for example starting up or plugging in a bus-powered device may cause a small
glitch in power supply voltages, or drivers may not quite manage device state
as precisely as they think). Previously this was no problem - the system was
designed with a bit of resilience, and things will function as normal. In
other words small variances in performance are a normal part of system
functioning. Furthermore, the degree of variance can differ widely across
systems, with some handling large changes in system parameters and others only
small ones. One very obvious way to observe this is what happens when a bunch
of PCs get hit by a momentary power outage. Effects will vary from powering
down, to various types of crash, to nothing at all, all triggered by exactly
the same external event.

With the introduction of tilt bits, all of this designed-in resilience is
gone. Every little (normally unnoticeable) glitch is suddenly surfaced
because it could be a sign of a hack attack. The effect that this will have
on system reliability should require no further explanation.

Content-protection "features" like tilt bits also have worrying denial-of-
service (DoS) implications. It's probably a good thing that modern malware is
created by programmers with the commercial interests of the phishing and spam
industries in mind rather than just creating as much havoc as possible. With
the number of easily-accessible grenade pins that Vista's content protection
provides, any piece of malware that decides to pull a few of them will cause
considerable damage. The homeland security implications of this seem quite
serious, since a tiny, easily-hidden piece of malware would be enough to
render a machine unusable, while the very nature of Vista's content protection
would make it almost impossible to determine why the denial-of-service is
occurring. Furthermore, the malware authors, who are taking advantage of
"content-protection" features, would be protected by the DMCA against any
attempts to reverse-engineer or disable the content-protection "features" that
they're abusing.

Even without deliberate abuse by malware, the homeland security implications
of an external agent being empowered to turn off your IT infrastructure in
response to a content leak discovered in some chipset that you coincidentally
happen to be using is a serious concern for potential Vista users. Non-US
governments are already nervous enough about using a US-supplied operating
system without having this remote DoS capability built into the operating
system. And like the medical-image-degradation issue, you won't find out
about this until it's too late, turning Vista PCs into ticking time bombs if
the revocation functionality is ever employed.

Increased Hardware Costs
------------------------

"Cannot go to market until it works to specification... potentially more
respins of hardware" -- ATI.

"This increases motherboard design costs, increases lead times, and reduces
OEM configuration flexibility. This cost is passed on to purchasers of
multimedia PCs and may delay availability of high-performance platforms" --
ATI.

Vista includes various requirements for "robustness" in which the content
industry, through "hardware robustness rules", dictates design requirements to
hardware manufacturers. For example, only certain layouts of a board are
allowed in order to make it harder for outsiders to access parts of the board.
Possibly for the first time ever, computer design is being dictated not by
electronic design rules, physical layout requirements, and thermal issues, but
by the wishes of the content industry. Apart from the massive headache that
this poses to device manufacturers, it also imposes additional increased costs
beyond the ones incurred simply by having to lay out board designs in a
suboptimal manner. Video card manufacturers typically produce a one-size-
fits-all design (often a minimally-altered copy of the chipset vendor's
reference design), and then populate different classes and price levels of
cards in different ways. For example a low-end card will have low-cost,
minimal or absent TV-out encoders, DVI circuitry, RAMDACs, and various other
add-ons used to differentiate budget from premium video cards. You can see
this on the cheaper cards by observing the unpopulated bond pads on circuit
boards, and gamers and the like will be familiar with cut-a-trace/resolder-a-
resistor sidegrades of video cards. Vista's content-protection requirements
eliminate this one-size-fits-all design, banning the use of separate TV-out
encoders, DVI circuitry, RAMDACs, and other discretionary add-ons. Everything
has to be custom-designed and laid out so that there are no unnecessary
accessible signal links on the board. This means that a low-cost card isn't
just a high-cost card with components omitted, and conversely a high-cost card
isn't just a low-cost card with additional discretionary components added,
each one has to be a completely custom design created to ensure that no signal
on the board is accessible.

This extends beyond simple board design all the way down to chip design.
Instead of adding an external DVI chip, it now has to be integrated into the
graphics chip, along with any other functionality normally supplied by an
external chip. So instead of varying video card cost based on optional
components, the chipset vendor now has to integrate everything into a one-
size-fits-all premium-featured graphics chip, even if all the user wants is a
budget card for their kids' PC.

Increased Cost due to Requirement to License Unnecessary Third-party IP
-----------------------------------------------------------------------

"We've taken on more legal costs in copyright protection in the last six to
eight months than we have in any previous engagement. Each legal contract
sets a new precedent, and each new one builds on the previous one" -- ATI.

Protecting all of this precious premium content requires a lot of additional
technology. Unfortunately much of this is owned by third parties and requires
additional licensing. For example HDCP for HDMI is owned by Intel, so in
order to send a signal over HDMI you have to pay royalties to Intel, even
though you could do exactly the same thing for free over DVI. Similarly,
since even AES-128 on a modern CPU isn't fast enough to encrypt high-bandwidth
content, companies are required to license the Intel-owned Cascaded Cipher, an
AES-128-based transform that's designed to offer a generally similar level of
security but with less processing overhead.

The need to obtain unnecessary technology licenses extends beyond basic
hardware IP. In order to demonstrate their commitment to the cause, Microsoft
have recommended as part of their "robustness rules" that vendors license
third-party code obfuscation tools to provide virus-like stealth capabilities
for their device drivers in order to make it difficult to interfere with their
operations or reverse-engineer them. Vendors like Cloakware and Arxan have
actually added "robustness solutions" web pages to their sites in anticipation
of this lucrative market. This must be a nightmare for device vendors, for
whom it's already enough of a task getting fully functional drivers deployed
without having to deal with adding stealth-virus-like technology on top of the
basic driver functionality.

Unnecessary CPU Resource Consumption
------------------------------------

"Since [encryption] uses CPU cycles, an OEM may have to bump the speed grade
on the CPU to maintain equivalent multimedia performance. This cost is
passed on to purchasers of multimedia PCs" -- ATI.

In order to prevent tampering with in-system communications, all communication
flows have to be encrypted and/or authenticated. For example content to video
cards has to be encrypted with AES-128. This requirement for cryptography
extends beyond basic content encryption to encompass not just data flowing
over various buses but also command and control data flowing between software
components. For example communications between user-mode and kernel-mode
components are authenticated with OMAC message authentication-code tags, at
considerable cost to both ends of the connection.

[dirio49]

In order to prevent active attacks, device drivers are required to poll the
underlying hardware every 30ms to ensure that everything appears kosher. This
means that even with nothing else happening in the system, a mass of assorted
drivers has to wake up thirty times a second just to ensure that... nothing
continues to happen. In addition to this polling, further device-specific
polling is also done, for example Vista polls video devices on each video
frame displayed in order to check that all of the grenade pins (tilt bits) are
still as they should be [Note C].

On-board graphics create an additional problem in that blocks of precious
content will end up stored in system memory, from where they could be paged to
disk. In order to avoid this, Vista tags such pages with a special protection
bit indicating that they need to be encrypted before being paged out and
decrypted again after being paged in. Vista doesn't provide any other
pagefile encryption, and will quite happily page banking PINs, credit card
details, private, personal data, and other sensitive information, in
plaintext. The content-protection requirements make it fairly clear that in
Microsoft's eyes a frame of premium content is worth more than (say) a user's
medical records or their banking PIN.

In addition to the CPU costs, the desire to render data inaccessible at any
level means that video decompression can't be done in the CPU any more, since
there isn't sufficient CPU power available to both decompress the video and
encrypt the resulting uncompressed data stream to the video card. As a
result, much of the decompression has to be integrated into the graphics chip.
At a minimum this includes IDCT, MPEG motion compensation, and the Windows
Media VC-1 codec (which is also DCT-based, so support via an IDCT core is
fairly easy). As a corollary to the "Increased Hardware Costs" problem above,
this means that you can't ship a low-end graphics chip without video codec
support any more.

The inability to perform decoding in software also means that any premium-
content compression scheme not supported by the graphics hardware can't be
implemented. If things like the Ogg video codec ever eventuate and get used
for premium content, they had better be done using something like Windows
Media VC-1 or they'll be a non-starter under Vista or Vista-approved hardware.
This is particularly troubling for the high-quality digital cinema (D-Cinema)
specification, which uses Motion JPEG2000 (MJ2K) because standard MPEG and
equivalents don't provide sufficient image quality. Since JPEG2000 uses
wavelet-based compression rather than MPEG's DCT-based compression, and
wavelet-based compression isn't on the hardware codec list, it's not possible
to play back D-Cinema premium content (the moribund Ogg Tarkin codec also used
wavelet-based compression). Because *all* D-Cinema content will (presumably)
be premium content, the result is no playback at all until the hardware
support appears in PCs at some indeterminate point in the future. Compare
this to the situation with MPEG video, where early software codecs like the
XingMPEG en/decoder practically created the market for PC video. Today, thanks
to Vista's content protection, the opening up of new markets in this manner
would be impossible.

The high-end graphics and audio market are dominated entirely by gamers, who
will do anything to gain the tiniest bit of extra performance, like buying
Bigfoot Networks' $250 "Killer NIC" ethernet card in the hope that it'll help
reduce their network latency by a few milliseconds. These are people buying
$500-$1000 graphics and sound cards for which one single sale brings the
device vendors more than the few cents they get from the video/audio portion
of an entire roomful of integrated-graphics-and-sound PCs. I wonder how this
market segment will react to knowing that their top-of-the-line hardware is
being hamstrung by all of the content-protection "features" that Vista hogties
it with?

Unnecessary Device Resource Consumption
---------------------------------------

"Compliance rules require [content] to be encrypted. This requires
additional encryption/decryption logic thus adding to VPU costs. This cost
is passed on to all consumers" -- ATI.

As part of the bus-protection scheme, devices are required to implement
AES-128 encryption in order to receive content from Vista. This has to be
done via a hardware decryption engine on the graphics chip, which would
typically be implemented by throwing away a rendering pipeline or two to make
room for the AES engine.

Establishing the AES key with the device hardware requires further
cryptographic overhead, in this case a 2048-bit Diffie-Hellman key exchange.
In programmable devices this can be done (with considerable effort) in the
device (for example in programmable shader hardware), or more simply by
throwing out a few more rendering pipelines and implementing a public-key-
cryptography engine in the freed-up space.

Needless to say, the need to develop, test, and integrate encryption engines
into audio/video devices will only add to their cost, as covered in "Increased
Hardware Costs" above, and the fact that their losing precious performance in
order to accommodate Vista's content protection will make gamers less than
happy.

[dirio49]

Final Thoughts
--------------

"No amount of coordination will be successful unless it's designed with the
needs of the customer in mind. Microsoft believes that a good user
experience is a requirement for adoption" -- Microsoft.

"The PC industry is committed to providing content protection on the PC, but
nothing comes for free. These costs are passed on to the consumer" -- ATI.

At the end of all this, the question remains: Why is Microsoft going to this
much trouble? Ask most people what they picture when you use the term
"premium media player" and they'll respond with "A PVR" or "A DVD player" and
not "A Windows PC". So why go to this much effort to try and turn the PC into
something that it's not?

In July 2006, Cory Doctorow published an analysis of the anti-competitive
nature of Apple's iTunes copy-restriction system ("Apple's Copy Protection
Isn't Just Bad For Consumers, It's Bad For Business", Cory Doctorow,
Information Week, 31 July 2006). The only reason I can imagine why Microsoft
would put its programmers, device vendors, third-party developers, and
ultimately its customers, through this much pain is because once this copy
protection is entrenched, Microsoft will completely own the distribution
channel. In the same way that Apple has managed to acquire a monopolistic
lock-in on their music distribution channel (an example being the Motorola
ROKR fiasco, which was so crippled by Apple-imposed restrictions that it was
dead the moment it appeared), so Microsoft will totally control the premium-
content distribution channel. Not only will they be able to lock out any
competitors, but because they will then represent the only available
distribution channel they'll be able to dictate terms back to the content
providers whose needs they are nominally serving in the same way that Apple
has already dictated terms back to the music industry: Play by Apple's rules,
or we won't carry your content. The result will be a technologically enforced
monopoly that makes their current de-facto Windows monopoly seem like a velvet
glove in comparison.

Overall, Vista's content-protection functionality seems like an astonishingly
short-sighted piece of engineering, concentrating entirely on content
protection with no consideration given to the enormous repercussions of the
measures employed. It's something like the PC equivalent of the (hastily
dropped) proposal mooted in Europe to put RFID tags into high-value banknotes
as an anti-counterfeiting measure, completely ignoring the fact that the major
users of this technology would end up being criminals who would use it to
remotely identify the most lucrative robbery targets.

The worst thing about all of this is that there's no escape. Hardware
manufacturers will have to drink the kool-aid (and the reference to mass
suicide here is deliberate [Note D]) in order to work with Vista: "There is no
requirement to sign the [content-protection] license; but without a
certificate, no premium content will be passed to the driver". Of course as a
device manufacturer you can choose to opt out, if you don't mind your device
only ever being able to display low-quality, fuzzy, blurry video and audio
when premium content is present, while your competitors don't have this
(artificially-created) problem.

As a user, there is simply no escape. Whether you use Windows Vista, Windows
XP, Windows 95, Linux, FreeBSD, OS X, Solaris (on x86), or almost any other
OS, Windows content protection will make your hardware more expensive, less
reliable, more difficult to program for, more difficult to support, more
vulnerable to hostile code, and with more compatibility problems.

Here's an offer to Microsoft: If we, the consumers, promise to never, ever,
ever buy a single HD-DVD or Blu-Ray disc containing any precious premium
content [Note E], will you in exchange withhold this poison from the computer
industry? Please?

Acknowledgements
----------------

This document was put together with input from various sources, including a
number that requested that I keep their contributions anonymous (in some cases
I've simplified or rewritten some details to ensure that the original,
potentially traceable wording of non-public requirements docs isn't used).
Because it wasn't always possible to go back to the sources and verify exact
details, it's possible that there may be some inaccuracies present, which I'm
sure I'll hear about fairly quickly. No doubt Microsoft (who won't want a
view of Vista as being broken by design to take root) will also provide their
spin on the details.

In addition to the material present here, I'd be interested in getting further
input both from people at Microsoft involved in implementing the content
protection measures and from device vendors who are required to implement the
hardware and driver software measures. I know from the Microsoft sources that
contributed that many of them care deeply about providing the best possible
audio/video user experience for Vista users and are quite distressed about
having to spend time implementing large amounts of anti-functionality when
it's already hard enough to get things running smoothly without the
intentional crippling. I'm always open to further input, and will keep all
contributions confidential unless you give me permission to repeat something.
If you want to encrypt things, my PGP key is linked from my home page,
http://www.cs.auckland.ac.nz/~pgut001.

Sources
-------

Because this writeup started out as a private discussion in email, a number of
the sources used were non-public. The best public sources that I know of are:

"Output Content Protection and Windows Vista",
http://www.microsoft.com/whdc/device/stream/output_protect.mspx, from WHDC.

"Windows Longhorn Output Content Protection",
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05006_WinHEC05.ppt,
from WinHEC.

"How to Implement Windows Vista Content Output Protection",
http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/MED038_WH06.ppt,
from WinHEC.

"Protected Media Path and Driver Interoperability Requirements",
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05005_WinHEC05.ppt,
from WinHEC.

An excellent analysis from one of the hardware vendors involved in this comes
from ATI, in the form of "Digital Media Content Protection",
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05002_WinHEC05.ppt,
from WinHEC. This points out (in the form of PowerPoint bullet-points) the
manifold problems associated with Vista's content-protection measures, with
repeated mention of increased development costs, degraded performance and the
phrase "increased costs passed on to consumers" pervading the entire
presentation like a mantra.

(Note that the crypto requirements have changed since some of the information
above was published, for example SHA-1 has been deprecated in favour of
SHA-256 and SHA-512, and public keys seem to be uniformly set at 2048 bits in
place of the mixture of 1024-bit and 2048-bit mentioned in the presentations).

In addition there have been quite a few writeups on this (although not going
into as much detail as this document) in magazines both online and in print,
one example being PC World's feature article "Will your PC run Windows
Vista?", http://www.pcw.co.uk/articles/print/2154785, which covers this in the
appropriately-titled section "Multimedia in chains". Audience reactions at
WinHEC are covered in "Longhorn: tough trail to PC digital media" published in
EE Times (http://www.eetimes.com/issue/fp/showArticle.jhtml?articleID=162100180),
unfortunately you need to be a subscriber to read this but you may be able to
find accessible cached copies using your favourite search engine.

Footnotes
---------

Note A: I'll make a prediction at this point that, given that it's trying to
do the impossible, the Vista content protection will take less than a day to
bypass if the bypass mechanism is something like a driver bug or a simple
security hole that applies only to one piece of code (and can therefore be
quickly patched), and less than a week to comprehensively bypass in a
driver/hardware-independent manner. This doesn't mean it'll be broken the day
or week that it appears, but simply that once a sufficiently skilled attacker
is motivated to bypass the protection, it'll take them less than a day or a
week to do so.

Note B: I see some impressive class-action suits to follow if this revocation
mechanism is ever applied. Perhaps Microsoft or the content providers will
buy everyone who owns a device that inadvertently leaks content and is then
disabled by the revocation process replacement hardware for their system.
Some contributors have commented that they can't see the revocation system
ever being used because the consumer backlash would be too enormous, but then
the legal backlash from not going ahead could be equally extreme. For anyone
who's read "Guns of August", the situation seems a bit like pre-WWI Europe
with people sitting on step 1 of enormously complex battle plans that can't be
backed out of once triggered, no matter how obvious it is that going ahead
with them is a bad idea. Driver revocation is a lose/lose situation for
Microsoft, they're in for some serious pain whether they do or they don't.
Their lawyers must have been asleep when they let themselves get painted into
this particular corner.

An entirely different DoS problem that applies more to HDMI-enabled devices in
general has already surfaced in the form of, uhh, "DVI amplifiers", which take
as input an HDMI signal and output a DVI signal, amplifying it in the process.
Oh, and as a side-effect they just happen to remove the HDCP protection.
These devices are relatively simple to design and build using off-the-shelf
HDMI chips (I know of hardware hackers who have built their own protection-
strippers using chip samples obtained from chip vendors. If you have the
right credentials you can even get hardware evaluation boards designed for
testing and development that do this sort of thing).

Now assume that the "DVI amplifier" manufacturer buys a truckload of HDMI
chips (they'll want to get as many as they can in one go because they probably
won't be able to go back and buy more when the chip vendor discovers what
they're being used for). Since this is a rogue device, it can be revoked...
alongside hundreds of thousands or even millions of other consumer devices
that use the same chip. Engadget have a good overview of this scenario at
http://www.engadget.com/2005/07/21/the-clicker-hdcps-shiny-red-button/.

Note C: We already have multiple reports from Vista reviewers of playback
problems with video and audio content, with video frames dropped and audio
stuttering even on high-end systems. Time will tell whether this problem is
due to immature drivers, or has been caused by the overhead imposed by Vista's
content protection mechanisms interfering with playback.

Note D: The "kool-aid" reference may be slightly unfamiliar to non-US readers,
it's a reference to the 1978 Jonestown mass-suicide in which Jim Jones'
followers drank Flavor Aid laced with poison in order to demonstrate their
dedication to the cause. In popular usage the term "kool-aid" is substituted
for Flavor Aid because it has more brand recognition.

Note E: If I do ever want to play back premium content, I'll wait a few years
and then buy a $50 Chinese-made set-top player to do it, not a $1000 Windows
PC. It's somewhat bizarre that I have to go to Communist China in order to
find vendors who actually understand the consumer's needs.

A reductio ad absurdem solution to the "premium-content problem", proposed by
a Slashdot reader, is to add support to Windows Vista for a black-box hardware
component that accepts as input encrypted compressed premium content and
produces as output encrypted (or otherwise protected) decoded premium content.
In other words, move the entire mass of hardware, driver, and software
protection into a dedicated black box that's only used in media PCs where it's
(arguably) required.

Now compare this add-on black box to the canonical Chinese-made $50 media
player. Why would anyone buy the black box (which will almost certainly cost
more than $50) when they can buy a complete dedicated media play that does the
same thing and more?

[Guest]

Next time, please just post the source link.

[dirio49]

Sorry, :o .
Now I know for next time. :)

[wmansir]

My FUD waders only go up to my knees, I think I need hip waders for this article.

[foxyshadis]

Next time, please just post the source link.

Merlin already did yesterday, anyway: http://forum.doom9.org/showthread.php?t=119731

[zambelli]

FYI, Dave Marsh of Microsoft posted a detailed rebuttal to that document here:
http://windowsvistablog.com/blogs/windowsvista/archive/2007/01/20/windows-vista-content-protection-twenty-questions-and-answers.aspx

I'm posting this just as an FYI, not advocating either side of the argument, so please don't send your comments on either article to me. :)

[unmei]

Thanks zambelli - i knew the posted article but probably wouldn't have stumbled over the answer you linked by myself anytime soon.

[JohnnyMalaria]

For many people who will use Vista, these DRM issues are meaningless.

I, for one, couldn't care less about using my PC as the hub of a home entertainment system, let alone be concerned about whether I can watch HD on an HD display.

If I should ever get an HD TV (most unlikely until they are the only option), I'd get a HD DVD player to watch movies, not my PC. And, guess what, that HD DVD player will have a whole bunch of DRM controls, too.

A computer is a tool. That's all. Because one facet of that tool may make some tasks harder than others, doesn't mean the whole toolbox will suck.

IMHO, the University of Auckland should discipline that "researcher" for "publishing" such a biased and sensationalist "article".

[Jim Ford]

My FUD waders only go up to my knees, I think I need hip waders for this article.

Very, very droll! Well worth wading through the previous postings to get to this!

Jim Ford

[dragongodz]

shouldnt this really be in the "pc hardware and software" section ?

IMHO, the University of Auckland should discipline that "researcher" for "publishing" such a biased and sensationalist "article".
hmmm and what should MS do to Dave Marsh then for replying with a spin and wrong information reply then ?

Will Windows Vista content protection features increase CPU resource consumption?

Yes. However, the use of additional CPU cycles is inevitable, as the PC provides consumers with additional functionality.
spin. this is not additional functionality for consumers but business, ie. protected content providers. even if you do not use any protected content your cpu consumption is still going to be increased by the check process sitting in the background running anyway.

Will the Windows Vista content protection board robustness recommendations increase the cost of graphics cards and reduce the number of build options?

Everything was moving to be integrated on the one chip anyway and this is independent of content protection recommendations. Given that cost (particularly chip cost) is most heavily influenced by volume, it is actually better to avoid making things optional through the use of external chips. It is a happy side effect that this technology trend also reduces the number of vulnerable tracks on the board.
spin and/or wrong information. ATI have already said it will increase cost.

i would suggest people also read the comments after the rebuttal. yes theres a lot and some are plain silly but there are ones that take apart the rebuttal aswell showing where its wrong.

[wmansir]

The only thing that interests me is if Vista's DRM impacts other processes when no protected content is present. Does anyone have any PROOF of that?

[KoD]

If you're reading the "Output Content Protection and Windows Vista" from WHDC (http://www.microsoft.com/whdc/device/stream/AVstream.mspx), it says that Vista will chose the most restrictive policy amongst those that it has to conform to at one moment. So, if you're playing one of your encodes with 6ch AC3 through S/PDIF and you feel the urge to put a HDVD disc in, Vista will suddenly switch S/PDIF to 2ch stereo. Same thing goes if you're watching some internet video or any other non "premium content" and you suddenly have to play "premium content" in paralel. The restrictions imposed by the "premium content" playback get enforced even on the non-premium content playback. More inside.

[Die*wrek*show]

Does anyone know if any drm or related features were included in xp's sp2?

[Doom9]

hmmm and what should MS do to Dave Marsh then for replying with a spin and wrong information reply then ?give him a medal for sugarcoating what is essentially letting down your pants and bending over? Microsoft isn't exactly known for playing nice, but instead of telling the MPAA on how movies are to be played on their operating system, they re-engineered the whole thing to conform to the MPAA's wishes. If only Microsoft were as accomodating in other areas (source code? sure go ahead and sure you can use it to create custom windows builds.... full API documentation (remember the EU ruling), etc.
I'm sure I'm not the only one who'd have liked to see the MPAA's reaction if Microsoft flat out refused to change Windows in any way for media playback. After all, HD DVDs and Blu-ray discs play just fine in XP, so those additional mechanisms are all but a necessity, let alone a necessary evil - the MPAA might have rattled their saber, but in the end they'd have to accept the inevitable.. being locked out from millions of machines simply is not an option.

[Sharktooth]

Absolutely. And i think they wouldnt even sell HD media at all with the current standalone players prices...

[hsoftwaremaster]

Vista indeed sucks, 15 GB of free desk space for an operating system? come on Always remember the meaning of "operating system": A thin THIN light weight environment for you programs to run on. A hosting environment not a beast to eat all my resources!

I'll stick with XP with SP 2

[foxyshadis]

Vista indeed sucks, 15 GB of free desk space for an operating system? come on Always remember the meaning of "operating system": A thin THIN light weight environment for you programs to run on. A hosting environment not a beast to eat all my resources!

I'll stick with XP with SP 2

True, and you can't really get much thinner or lighter than DOS 2.0. What, you aren't using that? Oh, then you might want to be a little more cogent in your arguments in the future.

[wmansir]

I don't think MS has as much sway with the media companies as people think. In the consumer electronics marketplace they are a small player trying to grow, far from a dominate force. If you look at only Media Center PCs (that are actually used as media centers, not just sold with XP MCE or Vista Premium), then it is an incredibly small install base. In the digital music arena, Apple is undisputed king with $2+ Billion in established revenue, yet even they are not bold enough to lay down an ultimatum on DRM. Jobs recent suggestion to abolish DRM seemed designed more to distract from and defend it's Fairplay monopoly than put forth a serious proposal.

If Vista didn't support HDCP then I'll grant that it just might give some companies added pause before they switch the ICT flag on. Given the current situation they will still get plenty of blowback from the millions without full HDCP support in their living rooms now. But I very much doubt it would make them abandon HDCP all together.

[Isochroma]

Here are the performance numbers:

Windows XP vs. Vista: The Benchmark Rundown (http://isochroma.com/Testfiles/Misc/doom9/Vista/Windows%20XP%20vs.%20Vista%20-%20The%20Benchmark%20Rundown.htm)

25% speed loss for video compression.

[hsoftwaremaster]

True, and you can't really get much thinner or lighter than DOS 2.0. What, you aren't using that? Oh, then you might want to be a little more cogent in your arguments in the future.

If Dos2.0 can support the software I run today, Yes I would love to use it :)

[zambelli]

Here are the performance numbers:
Windows XP vs. Vista: The Benchmark Rundown (http://isochroma.com/Testfiles/Misc/doom9/Vista/Windows%20XP%20vs.%20Vista%20-%20The%20Benchmark%20Rundown.htm)
25% speed loss for video compression.
... in their particular benchmark, which, you'll notice, includes MPEG-2 decoding as a part of the "video compression" test. I already questioned the methodology of that particular benchmark. If they want to benchmark "video compression", they should be using an uncompressed source, not transcoding from one format to another because that includes a slew of components in the process that aren't really targeted by the benchmark.

In my experience with WMV encoding, Vista is about 1-2% slower on the same hardware with the same encoding software, though I've also seen it go faster in a few tests.

[celtic_druid]

Most people would be encoding from DVD or TS sources though which would be MPEG-2. How many people compress from raw sources? I would imagine that the point of such tests is to perform tasks that readers perform.

[zambelli]

Most people would be encoding from DVD or TS sources though which would be MPEG-2. How many people compress from raw sources? I would imagine that the point of such tests is to perform tasks that readers perform.
Then it can't be called simply "encoding". "Transcoding" would be a more appropriate title. Transcoding consists of decoding + encoding. Their benchmark description only mentions the encoder software, but doesn't indicate what MPEG-2 decoder they used. Theoretically the bottleneck could've been in the MPEG-2 decoding part of the process, so it's unfair to say "encoding is slower" if they never took decoding out of the equation to prove that.

[celtic_druid]

If they are testing AutoGK, then the conclusion is that encoding a DVD with AutoGK is slower under Vista than XP. Who cares if you are actually transcoding or if it was the MPEG-2 decoder that was the cause (could also be AVISynth). The fact remains that as a consumer, using AutoGK is slower under Vista (according to that article).

My concern would be with the length of the source. A 182 MB VOB can't have been very long.

If you really need your PC to finish huge encoding, transcoding or rendering
Remember the audio encoding was from a PCM source.

So what is it exactly which you object? Just the "Xvid 1.2 Video Encoding" title?

So please do test encoding a raw source with xvidencraw and see if there really is any speed difference. But at the end of the day, I can't see it makes any difference. Decode to raw under XP, reboot to Vista and encode?

[zambelli]

So what is it exactly which you object? Just the "Xvid 1.2 Video Encoding" title?
I'm objecting to the fact that they're not disclosing other details of their test setup, such as which MPEG-2 decoder they're using. Was it even the same decoder? We don't know. How can we trust the benchmark if only half of it is known?

So please do test encoding a raw source with xvidencraw and see if there really is any speed difference. But at the end of the day, I can't see it makes any difference. Decode to raw under XP, reboot to Vista and encode?
Would it make a difference if it turned out that 2 entirely different MPEG-2 decoders were used in their benchmarks? Of course it would. I'm not saying that's the case - I'm merely saying that the video benchmarks should be taken with a big grain of salt because half of the benchmark process is completely unknown.

If you can point me to a particular build of XviD you'd like me to test, I can certainly kick off a few encoding jobs on any of my test machines - they're all dual boot XP-Vista.

[celtic_druid]

AutoGK uses dgdecode, so this would be the same setup on both machines. Main Concept's encoder I guess is dshow based? Maybe it always uses their MPEG-2 decoder? Otherwise I guess there could have been different decoders used.

I guess if you wanted to test, then xvidcore from: http://tirnanog.fate.jp/mirror/XviD/xvid.cvs.head.MTK.2006.12.20.7z with squid_80's encraw build. Benching VfW encoding would I guess also be worthwhile.

http://tirnanog.fate.jp/mirror/XviD/xvid.cvs.head.MTK.2006.12.08.7z
would have been the exact build used in the test though. You could also just install AutoGK.

As I said the thing that worries me about their test is that they were using only 2min sources. For a source that short you would need to run it multiple times. With a full length source things would average out more.

There is also an older 64bit build if you wanted to test XP x64 vs. Vista x64.

[Manao]

Theoretically the bottleneck could've been in the MPEG-2 decoding part of the process, so it's unfair to say "encoding is slower"A raw video has a much higher probability of been the bottleneck, whatever the OS, so I don't see your point. If you really want to test encoding only, you must use the fastest possible source. And most often than none, the fastest available source is a mpeg2 file, because the bandwidth required for uncompressed video is too much.

If the mpeg2 decoders were different, indeed your point would be valid. Otherwise, it is not.

[foxyshadis]

It could just as easily by DXVA enabled on XP and disabled on Vista in the beta drivers. Who knows, you'll never find out unless you email and ask for more details on the methodology.

[zambelli]

It could just as easily by DXVA enabled on XP and disabled on Vista in the beta drivers. Who knows, you'll never find out unless you email and ask for more details on the methodology.
Actually, DXVA decoding can only be used when rendering the video to VMR or EVR. You couldn't use it in a decoder-to-encoder pipeline.

[Isochroma]

Your statement is giving me some awful ideas zambelli! Maybe it could!

All we need to do is, after the frame has been sent to the gfx. card for rendering, read back its framebuffer memory using the agp/pcie bus, and voila! juicy hardware-decoded frames in main memory.

Thus the title of this thread is really pertinent: Vista will have to suck, that is: vista will have to suck hardware-decoded frames back thru the agp/pcie bus to be able to equal the speed of XP in decode.

[zambelli]

Thus the title of this thread is really pertinent: Vista will have to suck, that is: vista will have to suck hardware-decoded frames back thru the agp/pcie bus to be able to equal the speed of XP in decode.
Who says decoding is slower on Vista?

[migrena]

Theoretically the bottleneck could've been in the MPEG-2 decoding part of the process
actually it was you who said that slower encoding speeds in that test may be caused by slower decoding
if the reason of such decreased encoding speed is not decoder then its true that encoding is slower
if the former is true then the question is why there is such difference in decoding between xp and vista with the same decoder? or do we need specially designed decoders to be able to get at least comparable decoding speeds?

[zambelli]

if the former is true then the question is why there is such difference in decoding between xp and vista with the same decoder? or do we need specially designed decoders to be able to get at least comparable decoding speeds?
The decoding could be slower for a number of reasons, the simplest one being that they used a different DShow decoder on XP than Vista. :) My point is that we don't know because they didn't tell us about that part.

[zambelli]

I guess if you wanted to test, then xvidcore from: http://tirnanog.fate.jp/mirror/XviD/xvid.cvs.head.MTK.2006.12.20.7z with squid_80's encraw build. Benching VfW encoding would I guess also be worthwhile.
Thanks. I went ahead and did exactly that. Here are the results:
http://forum.doom9.org/showthread.php?p=955067#post955067

As I said the thing that worries me about their test is that they were using only 2min sources. For a source that short you would need to run it multiple times. With a full length source things would average out more.
Yeah, I agree that longer sources would've made for a more authoritative benchmark. I ran my test on a 1 minute long 720p source, knowing that will take at least 4 minutes to encode.

[celtic_druid]

As I said though AutoGK would mean that dgdecode was the MPEG-2 decoder and it would be the same version used in both cases.

A 1 minute source is even worse. For that you would need to run it say 3 times.

What I think would be best is to run AutoGK on a full DVD source and see if there is any significant time difference between the two OS'.

[zambelli]

As I said though AutoGK would mean that dgdecode was the MPEG-2 decoder and it would be the same version used in both cases.

A 1 minute source is even worse. For that you would need to run it say 3 times.

What I think would be best is to run AutoGK on a full DVD source and see if there is any significant time difference between the two OS'.
I just repeated the test with 20-minute long MPEG-2 source and DGDecode. The result was the same as the first time around:

http://forum.doom9.org/showthread.php?p=955509#post955509

[wmansir]

I really don't buy the 25% slower number, but unfortunately my upgrade to Vista was in large part due to a concurrent CPU/MB upgrade. In reinstalling XP (multiple times) I found it couldn't import my MS Dynamic Disk RAID due to a system error, something Vista did without any issues.

[shevegen]

25% sounds too much?
Then what do you expect?

I mean... for having vista on a faster, better machine, I'd think it would be supernatural that it goes faster.
But why would XP perform better than Vista anyway, other than that its some
weird "design choices" that seems to imply "buy a faster machine dude!"?

[zambelli]

25% sounds too much?
Then what do you expect?
Well, yeah, it does in the context of encoding. Encoding is a fairly closed process, very CPU intensive, with very little interaction with the OS once it gets going. It wouldn't make sense that it would be 25% slower in itself, unless serious changes were made in elementary OS operations such as memory management.
There are certainly applications that will be slower on Vista than on XP for one reason or another: depending on legacy APIs that are now emulated (i.e. DirectSound) or shimmed, performing operations that are now handled differently beneath the covers, performing operations that involve many OS components, etc. But video encoding - that's mostly just math functions and memory allocation - shouldn't be all that affected.

[Manao]

The same is true for decoding. Yet, you blame the decoding part for being the reason of the slowdown. You say the filter may be different, but you know it's not likely - or rather, you didn't do the simple test that would clear the issue once and for all ( diretshowsource + avisynth ).

So, though decoding/encoding is mostly number crunching, at the moment, what we can say is that something that has nothing to do with the decoding/encoding part is slowing thing down. And that's disturbing because 25% slowdown for something as heavily CPU intensive as a decoding/encoding is insane.

[zambelli]

The same is true for decoding. Yet, you blame the decoding part for being the reason of the slowdown. You say the filter may be different, but you know it's not likely - or rather, you didn't do the simple test that would clear the issue once and for all ( diretshowsource + avisynth ).
I didn't blame it on decoding - I merely concluded that it's not in the encoding part. So far I've only proven that encoding alone is not slower on Vista. I'll run the DirectShow decoding test if I have time next week, but if you have any objections to the way I'm performing tests, you're more than free to run your own tests. That's exactly what I did when I looked at TH's article and thought there was something flawed in their test setup. I'm not looking to prove either OS is faster than the other - I'm just trying to shed light on what seemed to me an erroneous benchmark.

[wmansir]

25% sounds too much?
Then what do you expect?

I mean... for having vista on a faster, better machine, I'd think it would be supernatural that it goes faster.
But why would XP perform better than Vista anyway, other than that its some
weird "design choices" that seems to imply "buy a faster machine dude!"?

I went from a 2Ghz Tbred to a 2.66 Ghz Pentium D. From all the benchmarks I read before the upgrade I expected my encoding speed to just about double. If my hardware gave me about a 2x increase, but Vista had a 20-25% performance penalty than I shouldn't have come close to a 2x speed increase after my hardware/OS upgrade, but 2x is almost exactly what I got. That's why I think a 25% decrease sounds too large.

Of course the only way to really tell is if I boot into XP and run tests on the same hardware. I'll probably give it a try when I get some free time.

Also, I'm not really a big cheerleader for Vista. It's a worthy upgrade mostly for stability and security reasons, but it's not anything amazing like MS and others would have people think. Honestly, if it wasn't for my RAID issue I would have stuck with XP at least until most of the HW Driver and software compatibility issues were worked out.

[Manao]

you're more than free to run your own testsI don't have Vista, so I definitely can't test.
if you have any objections to the way I'm performing testsYour tests are valid - well, not the one with the raw video file, but at least it was good to know that Vista doesn't slow down disk accesses.

But your tests don't explain what is happening. They only concluded that Vista allows to crunch numbers as efficiently as XP.

There's a lot more to encoding than crunching numbers. Encoders - well 'professionnal' ( nero/mainconcept like ) encoders - aren't made around the model of ffmpeg/mencoder/x264. They heavily rely on DirectShow. And thus DirectShow performance must be accounted for when doing encoding tests.

Personnally, from all the tests that were done ( TH's and your's ), I can only conclude that DirectShow perfomance has dropped. And not just by 25%, because, as you said, encoding is mostly a number crunching operation, and DirectShow doesn't have a lot of opportunities to slow that down.

I don't have the means to prove the contrary, but you have. Seeing how you defended Vista against unwarranted attacks previously, will you defend it now, or accept my conclusion ?

[migrena]

could it be that TH used different (older) build of vista? some unfixed bugs in older versions might be the reson

or maybe "Media Foundation Protected Pipeline" gets in the way in TH tests like in this (http://www.miraesoft.com/karel/2006/12/25/cost-analysis-of-windows-vista-content-protection/#comment-1255) case? (from Peter Gutmann article)

[jeffy]

could it be that TH used different (older) build of vista? some unfixed bugs in older versions might be the reson

or maybe "Media Foundation Protected Pipeline" gets in the way in TH tests like in this (http://www.miraesoft.com/karel/2006/12/25/cost-analysis-of-windows-vista-content-protection/#comment-1255) case? (from Peter Gutmann article)
http://www.tomshardware.com/2007/01/29/xp-vs-vista/page3.html
OS Windows Vista Enterprise, Build 6000.16386.061101-2205

[JohnnyMalaria]

Personnally, from all the tests that were done ( TH's and your's ), I can only conclude that DirectShow perfomance has dropped. And not just by 25%, because, as you said, encoding is mostly a number crunching operation, and DirectShow doesn't have a lot of opportunities to slow that down.

I don't have the means to prove the contrary, but you have. Seeing how you defended Vista against unwarranted attacks previously, will you defend it now, or accept my conclusion ?

I don't accept your conclusion :p

One of our apps is built around DirectShow. Some early head-to-head benchmarking for XP Pro SP2 vs. Vista Ultimate (32-bit RTM) yielded about a 7% performance reduction for Vista. BUT, Aero was active and, looking at Task Manager, Aero was using about 5% of the CPU. (The more windows you have open, the more Aero has to do.)

I will be running more tests soon with Aero disabled (like for TH's tests).

I haven't seen anything to suggest that DirectShow itself performs worse on Vista. However, DirectShow apps that also provide audio playback WILL suffer on Vista unless the app is Vista-aware and permits non-DirectSound audio rendering. (DirectSound on Vista is wholly software based - no hardware acceleration - it imposes a significant performance penalty.....)

[ron spencer]

actually windows 2000 smokes em all....put that on a dual core 3.4 ghz for just video encoding and/or digitial editing and it is sooooooo fast, the way an OS should be; no overhead, no Aeroeo (whatever it is) nonsense. Just speed speed speed.....