16.7ms in the life : Musing

Thoughts on software complexity

Peter Rosser — Sat, 03 Jun 2006 07:06:00 GMT

If you've ever tried to create a software application of any decent size, you have probably realized that what works with small tools more often than not does not scale well to larger sizes. There are whole books written about how to scale up and out, new languages and technologies invented to help manage it, and millions of dollars in educational budgets spent every year to achieve that elusive goal.

And yet, the landscape is still rife with examples of poorly designed software.

A significant part of the problem is not that engineers are not smart enough--it's that we outsmart ourselves. The conventional wisdom is that humans can store 7 ± 2 primitives (e.g. numbers) on the top stack of short-term memory. The number skews higher for strongly associative items, and vice versa. We can store fewer abstract items, often only 2 or 3 at a time. The issue is not one of comprehension, it's one of focused retension. When the number of data items in a class exceeds our capacity to retain them at once, the brain tends to move the perceived "less important" fields/properties into peripheral storage. This, I think, leads to not fully comprehending the interactions in the class. We engineers like to think of ourselves as intelligent, and that we can understand very complex ideas. This may be true, but it misses the point; the point of software engineering is to create reliable, performant, maintainable software. It is not to create complex applications.

Well, there's the problem, isn't it? In order to create the really cool applications, you must have complexity. It's simply unavoidable, especially given the advanced competition for consumer dollars. You can't very well create a next generation RPG that has realistic physics, with a "real" economy, kickass graphics and brutally smart AI without complexity.

Or can you?

Actually, I believe the answer is that you can, at least the bad kind of complexity that causes the pain. The key is differentiating between behavioral complexity and system complexity. Behavioral complexity is the aforementioned features like smart AI, or realistic physics. Those sorts of things are monstrously difficult to get right, but that's not what holds back the very large application development projects. The major cause for schedule slips, regressions, out-and-out bugs, and general angst is system complexity.

Before I go on, I'd like to define what I mean (yes, I do get to hijack words like this) by system complexity:

System complexity a property of a system that is directly proportional to the difficulty one has in comprehending the system at the level and detail necessary to make changes to the system without introducing instability or functional regressions.

In other words, the higher the system complexity, the harder it is to upgrade, maintain, and develop the system. Whether the system is a single class, an object library, an inheritance heirarchy, or an entire application, someone "schooled in the art" of software engineering should be able to understand it, given a reasonable time to examine the system. This ability should scale through the system. When one examines a particular object, it should be apparent without examining the private implementation details how to use it. From top to bottom, from bottom to top; the entire system should be accessible to the non-super-geniuses out there. What goes for good UI design also goes for good C++, C# and COM design: your target audience should be able to use it without extensive systems training.

System Complexity is what makes the Mythical Man Month true. It's what keeps that guy who wrote the accounting system from scratch in 1986 employed. It's what causes games, productivity applications, and even (some might say especially) large operating system projects to slip their schedules.

So what can you do about it? The first step to recovery is admitting you have a problem. Pedantic, but true. Getting back to the point I tried to make earlier about engineers--we like to think we are smart. Egos loom large in the software industry, and often with good reason. One of the smartest developers I have come across worked on a critical piece of the code for several years, and guarded his territory jealously. Make no mistake, this guy was brilliant--and he knew it. To make a long story short, when he left, the code he left behind was an engineering marvel [he says wryly] that no one else understood. Oh, we know what it does, but there's a crucial difference in understanding what something does, and grokking fully how it does it. Tracing execution paths through this code is difficult, and 1200-line methods named "Run" are common.

The author understood it all, or said he did, but my opinion is that he was fooling himself, too. Once you get a piece of the system working, after all, you don't need to touch that piece again unless the design changes, a bug is found, or something like that. Over time, though, people started to notice that even small fixes in this particular area would touch a dozen or more files, and churn lots of code. That's a symptom of high system complexity; he would go in to make the fix, then discover that 100 variables influenced the behavior, or the implementation in one area was strongly dependent on the implementation in another, or most often, both. But since the author had traveled this area so much, he was able to turn around the fixes in an acceptable timeframe, so he "got away" with it.

It's no surprise that when the author decided to move on to other things, as employees often do, that we had a tough decision to make. Do we maintain this code that's working? Do we refactor? In the end it came down to pragmatism and schedule: the problem was recognized, and we chose to refactor the system in measured stages, minimizing the risk to the product and getting back to a good, maintainable state.

That's all I have time for today... my build is done, so back to work I go. Windows Vista waits for no man!

Captioning Support Sucks

Peter Rosser — Sun, 19 Feb 2006 12:42:00 GMT

Looking back at the bugs we've fixed over the last several months, we certainly have had a good share of captioning issues, especially with regards to the size of the codebase compared to the "video" code. Surprisingly, we don't hear from users a ton when captions don't work properly, but maybe that's because a minority of the users actually use them in the first place. I'm not usually so negative, but I'm just annoyed at captioning today. The following is a poorly thought-out rant on the subject. ......(read more)

A Brief History of ATSC in Media Center

Peter Rosser — Fri, 03 Feb 2006 11:09:00 GMT

In the beginning there was NTSC in Freestyle (Media Center 2002), and it was good. Media Center supported the #1 market and proved that computers could do a great job recording television, pausing Live TV, and organizing recordings. With support for one tuner under our belt and an enthusiastic user base, we moved forward with Harmony (Media Center 2004) to a more mature, flexible and polished product that supported dual NTSC or PAL tuners, opening up the European, Asian and Australian marketplaces. A few intrepid souls figured out how to hack together ATSC support into Harmony using little-known interfaces and scarce hardware like the VBox 110.

Between the release of Harmony and Symphony (Media Center 2005), ATSC demand increased by leaps and bounds, though still smaller than the NTSC base by far. To this day, only a very small percentage of Media Center users actually use ATSC, although it's a matter of some discussion whether that number is small because the number of HDTVs is small, or because Media Center's support is... less than optimal. In any case, by the release of Symphony the user community was clamoring for ATSC support without hacks, and was disappointed when Symphony shipped without it. An update quickly followed, though, and Symphony Rollup 1 with HDTV Support was released as a free update through Windows Update and the Microsoft Download Center. The changes in Emerald (Rollup 2) and Diamond (Windows Vista) did/will not not substantively change the architecture of ATSC, so what we have today will more or less be the way it works for another couple of years.

••• design decisions

When we (speaking in generalities here, since I was not a member of the team at the time) first investigated how to include ATSC into the product, there were several major hurdles standing in the way. The first was a consequence of our decision to use the VMR (Video Mixing Renderer) instead of the deprecated Overlay Mixer for rendering video. Overlay rendering differs from mixing in the way that video is prepared for display. In overlay mode, the video is literally painted over the top of whatever else is being rendered. In mixing mode, "surfaces" with video or other graphics are blended together, either in software or hardware-accelerated, prior to rendering on the monitor. The advantage of mixing mode is greatly increased flexibility in what you can display at the cost of performance. It takes a lot more horsepower to process all those pixels, especially with alpha (transparency) and 3D effects. 99% of the video hardware on the market today uses a form of overlay mode, which drastically reduces the hardware requirements (e.g. no 3D hardware required), but hamstrings them when viewed side-by-side with the sort of effects you can get with mixing. The semi-transparent menus on top of video that you see in Media Center that give it such a cool look are just not possible with overlay mode. All that alpha blending and those 3D effects come at a hefty cost, though. Media Center has to work many times harder to get the video to the screen, even when no special effects are on-screen at the time. That, in a nutshell, is why Media Center requires not just an OK video card to shine. And a faster CPU. As a result of the increased power needed to render video, and with the hardware available to consumers in 2000-2002, it wasn't really feasible to offer HD with the first couple of releases.

Even if the video could keep up (which it could on higher-end systems, even in 2002), there was another difficulty: Guide data. The problem is that when you get multiple lineups (the term we use for the programming information associated with the set of channels available on a given medium in a geographical area), merging them into a single lineup and making it easy for the user is not an easy solution. The decision was made to punt it until demand was increased, and to stick with a simpler homogenous lineup, rather than the more advanced heterogeneous lineup that would be required to support both NTSC and ATSC on a single system. The market of people that have more than one TV provider is, after all, not that large, and we wanted to get it right for the most people we could.

••• support for ATSC gathers steam

A vocal minority of the user community, along with a large majority of the eHome TV product team, were not pleased with the lack of support. We got the funding to put ATSC in the product, as long as we could fit it into the schedule and without major risks to the architecture of Media Center's TV and PVR functionality. With compressed schedules the norm, and the development and testing staff already deeply into a bad work/life balance, many options were considered for getting ATSC out to users. What was finally implemented is a good first stab at doing it, with a few facets that are, um, less than what we'd like them to be. Since we did not have ATSC-specific listings available through our Guide data provider for many, many areas, we looked instead at reusing the data available from existing analog lineups via "mapping". Since ATSC channels are in a completely different format (like 13-1 or 9-5), and to avoid putting a new button on the remote (requiring a redesign), ATSC channels are renumbered in the UI. The scheduling/PVR conflicts were just ignored, leaving it up to the user to say "only record this channel", omitting support like "record this in HD if you can, but get it in SD if not". The end result was a pseudo-heterogeneous lineup support that we have today. You do get the additional ATSC lineup merged into your Guide, but the analog source is still required--you cannot have ATSC without NTSC today.

••• the current state of things

During First Run (the initial Media Center setup wizard), or TV Signal Setup, we detect whether you are in a region that supports ATSC, and then detect if you have a compatible ATSC card installed (or for Emerald, up to 2 ATSC cards). After configuring your SD tuner, ATSC is configured as an adjunct to the "primary" analog tuners. If you choose an analog, sans-STB (set-top box) cable lineup for your analog tuners, then that data is what's available to ATSC to map to its channels. The same goes for satellite or OTA (off-the-air/broadcast) lineups. Only with digital cable lineups do you usually get the full Guide data to assign to your ATSC channels.

To assign listings to the ATSC channels in the lineup, we run a heuristic match against the available channel metadata, and try to get a "best-fit" match for existing channels to the new ATSC channels. For example, if there is a channel "KOMO-DT" in the primary lineup, it can be matched to the known ATSC channel KOMO-DT on 4-1. In some areas, the match can't be made automatically, but you can go to the Guide settings (Settings-->TV-->Guide-->Edit Digital TV Listings) and manually associate the listings of an existing channel to the ATSC channel. Basically what you are doing is saying "this channel that exists on my "primary" lineup has identical programming to that ATSC channel". It works best with digital cable lineups because they carry all of the local OTA ATSC channels on their networks (due to Federal must-carry laws). To get the minor channels (where the "minor channel" > 1, e.g. KCTS-DT2 on 9-2 in Seattle), you have to add them to your lineup manually using Add Missing Channels, and then map them to listings using Edit Digital TV Listings.

The end result of all of this is a unified lineup that can be presented to the user in a single Guide grid. ATSC channels are assigned numbers like 1041 for channel 4-1, and slotted in where they fit best. If your primary lineup already has a channel 1041, we look for another block of numbers to put the ATSC channels. A side-effect of this is that if your primary lineup is changed--like if Comcast decides to add a channel 1000 to their lineup--the ATSC channel numbers may get reassigned to another empty block. Personally, I'd like to implement a better solution, but as I've said before, we Americans are unnaturally attached to our channel numbers. Most would just give you a blank look if you suggested that we don't even really need channel numbers at all. Not when you have a good enough search/filter mechanism, anyhow.

••• the days to come

For the Diamond release, we have announced support for OCUR (OpenCable Unidirectional Receiver) tuners, which will allow native tuning of digital cable signals, with CableCard support (for premium channels like HBO). This includes HDTV signals, which should be good news to most users. More people pay for TV service now than don't, and if you own a Media Center, you are about 20 times more likely to have cable or satellite service than not. Roughly. OCUR support probably means (definitely, for Diamond) that we won't be supporting heterogeneous lineups anytime soon, which is a shame, but hard to make a business case against. Why spend time and treasure on something that most people won't use, and could possibly destabilize the entire product? That's a little hyperbolic, but the onus is on the people who want the feature to justify it.

We announced a deal with DirecTV where we will directly support their newest STB in Media Center, just like--or very similar to--the OCUR does with digital cable. The field is finally opening up and we're getting to a point where we can offer our users very attractive options for "traditional" TV services. The European market, or more precisely, the non-U.S./S.Korea/Japan market, has already standardized (for the most part) on a fairly sensible broadcasting standard--DVB--which we are improving our support for with every release.

Non-traditional video services are also booming in popularity, with Online Spotlight partners offering more movies and other multimedia content for free (in many cases) or on an ala-carte basis, directly competing with PPV services offered by traditional TV providers. Apple has changed course on its "we'll never get into the PVR business" policy with iTunes video (and their toe-dip product Front Row, which is a pretty spiffy little QuickTime automation script), and The Market is scrambling all over itself to get on the bandwagon. Internet TV is coming, just as soon as we (as in "we the market", not necessarily "we at Microsoft") figure out what Internet TV is.

16.7ms = free software (a silly contest)

Peter Rosser — Fri, 06 Jan 2006 05:34:00 GMT

Sometimes being obtuse is it's own reward, but this time there's something in it for you if you know what "16.7ms" is referring to. I'm curious enough to see that I'm willing to shell out my own hard-earned cash to the first non-Microsoft employee that figures it out. Post your guesses to my Comments section, please.

Your choice of:

Perfect Dark Zero (Xbox 360)
Kameo (Xbox 360)
Project Gotham Racing 3 (Xbox 360)
Age of Empires III Collector's Edition (PC)
Dungeon Siege 2 (PC)
Fable The Lost Chapters (PC)

For the person who comes up with the most amusing, albeit incorrect, translation, I'll award a Windows Vista stainless steel tumbler!

...and just like that, we have a silly contest!

Update: We have a winner for the "real" definition (16.7ms == 1/60 second, the time for 1 field of interlaced NTSC/ATSC video), but I'll keep the silly side of it open until tomorrorow (1/6/2006) at 5 PM PST.

Update 2: Entries are now closed, thanks! I will be considering each and every one based on their merits, feed it through my ultra-advanced HumorSensor 5000, double-check the results with the IOC, and the UN Human Rights Commission, and present the results as soon as is humanly possible. Or I may just look 'em over and choose the one that makes me laugh. Either way, I'll let you know...

Windows Insomnia: Why Won't My Computer Go To Sleep?

Peter Rosser — Thu, 05 Jan 2006 08:18:00 GMT

One of the issues I am investigating for a fix relates to the auto-suspend feature in Windows. The way it's supposed to work is you set a time in the Power control panel (Control Panel --> Performance and Maintenance --> Power Options) that controls how long the computer waits until it goes into "standby" or "suspend". Whether that is S2 or S3 depends on your BIOS settings. What's going on with the bug I'm looking at is sometimes Windows will not suspend when it should, or indeed, ever, unless you close Media Center or manually select Standby.

This is pretty annoying, especially since my Media Center consumes about 200W while fully active (250-275W if engaged in HDTV playback), and only about 15W in S3 suspend. With electricity around $0.084 / kWh, that works out to $0.40 each day left unchecked. If I let it go all month, that's another $12, just because of this stupid bug (well, and because I'm lazy and forget to manually suspend... but I should not have to). Lame, lame, lame. Extrapolating to all of the customers affected by this issue, I can see it adding up to a big problem. Say only 250,000 users hit this (a low figure, I bet), that's $3,000,000 per month in wasted energy costs, based on the rates I pay. Yikes!

While I can fix this problem, I cannot fix all of the things that prevent computers from going into standby automatically, because they should really not be fixed, or because Windows software is not causing the problem in the first place. Several things can cause a computer to fail to go into standby, and figuring out exactly what is causing the problem can be very difficult.

So, what are the most common causes of Windows insomnia? In rough order of likelihood, here is my SWAG:

There is user activity. This usually means keyboard or mouse activity, but can be "simulated" by applications via SendKeys(), etc.
Windows is not configured to go into Standby automatically. Since it's not the default for most computers, this makes the list. Easy to fix.
An application tells Windows not to go into Standby automatically. Different from user activity simulation because this is what applications are supposed to do to prevent Standby. [ SetThreadExecutionState(state) ]
An application generates enough system activity (e.g. disk access, network access, CPU usage) that Windows does not consider the machine to be "idle" enough.
A hardware device driver prevents it.

Case 1 is very unlikely, since really the only applications that do this sort of thing are hacks/trainers/evil programs (and testing programs, if you want a legitimate example). Unless your computer is infected by malware, this is probably not the cause. Run a quality scanner to tell. For case 2, just set Control Panel setting.

For cases 3 and 4, troubleshooting gets trickier. For the average end-user who does not know how to use a Kernel Debugger like WinDbg or SoftICE, and does not have easy access to kernel symbols, figuring out who is keeping the computer up all night takes a little wanton process termination. Before you open up taskmgr and start gunning processes, though, there are a couple of things you can check:

Are you sharing any folders on the network? If a remote computer is connected to your machine and refreshes the connection (i.e. sends a command), the Server service will call KeInhibitSystemShutdown(), which does exactly what it sounds like it does: resets the system's idle timer. How do you tell if this is happening? An easy way is to pull up a command window (Start --> Run --> cmd) and type:

nbtstat -s

If you see any "IN" connections, they can keep you awake. Most well-behaved Windows applications will not needlessly refresh connections over the network, but others don't play that nicely. A ubiquitous example would be WMP or iTunes--both will scan network folders for changes if you add the path to your "watched folders" list. The best way to solve this problem is to fix the client side (the other computer), but if that's not possible, you can just deny access to that computer/user. In the worst case, you can stop the Server service (net stop server), but that prevents sharing altogether.
Check your Application and System event logs for errors or warnings. Often, exceptional situations will be reported there and can provide a clue to why Windows is not going into Standby.
Hardware (or more appropriately, drivers for hardware) can prevent Windows from entering standby, too. If you used to be able to go into standby, but cannot now, have you added or replaced hardware, or updated drivers? This can be tricky, too, since most people set their Standby timers for longer than is convenient to sit around and wait on, so failure to go into Standby can be missed for days or weeks.
To eliminate any remote networking cause, isolate your computer from the network (unplug the network cable!). Low-tech, but effective.

If you have eliminated network shares, suspicious event log entries, and hardware from causing the problem, the next thing to do is start killing processes and see which one (or if you're unlucky, which ones) are doing it. You need to first exclude those processes that are part of Windows itself, since terminating them is not very wise. An easy way to get a fairly complete list of the Windows processes is to boot into Safe Mode, press Start --> Run, and type:

tasklist >"%SystemDrive%\SysProcesses.txt"

A new file will be created on your system drive (usually C:) that contains the list of processes you shouldn't touch. Reboot back into normal Windows mode, log in, and:

Open the SysProcesses.txt file
Start taskmgr (right click on the taskbar and select Task Manager) and click the Processes tab.
Set your Standby timer to 1 minute (in the Power Options control panel)
Let 1 minute elapse. If the computer does not suspend, proceed to the next step.
Select a process not listed in the SysProcesses.txt file in taskmgr and kill it.
Go to step 4.

If you run out of processes to kill and the computer still won't go into Standby, it's time to start shutting down services in the Services console (Start --> Run --> services.msc). If you have stopped all of the services you possibly can, it's either a piece of hardware or one of the core Windows processes, and things are a bit tougher. To troubleshoot those, you need the help of a kernel-mode debugger.

Happy New Year!

Peter Rosser — Wed, 04 Jan 2006 21:58:00 GMT

Happy New Year!

It was a nice month, but the break is over and I've returned back to work. Christmas at the Rosser house was a low-key affair, mostly spend decompressing from hectic work schedules and enjoying family and friends' company. My daughter's 2nd Christmas, this year was the year she figured out the whole "presents are fun" thing, and we had a great time. We scheduled holiday-themed shows on our Media Center, and while they enjoyed the shows I (quietly, to myself) nitpicked the video quality and encoding bugs from my Comcast box. If you haven't seen them, our current pick-of-the-month show to watch is Creature Comforts on BBC America I'm told that it's been out quite a long time, but it's new to me. In case you haven't seen it, it's a Wallace & Grommit -style show where they take real(?) audio interviews of people and animate claymation animals to the soundtrack. The results are often hilarious, especially if you enjoy British humour.

It will probably be a couple of days before I catch up completely with the backlog of email and so forth, but I'm back on the job. We've got several DVB Radio and EPG issues under investigation presently, along with a couple of Standby/Resume bugs. The mood around the halls is pleasant, unlike the frantic activity from deadline pressure in November and December. A few new faces, a few old faces moved on to other teams, it's business as usual here in eHome. It's back to work, and back to fixing bugs.

Visual Studio 2005 Shipping on my Birthday

Peter Rosser — Tue, 01 Nov 2005 08:14:00 GMT

You know I'm a geek when something like that gives me even a little bit of a thrill. November 7th... not just an election day or my birthday, but also the VS2005 public ship day. ^_^. I'm installing it now on my primary and backup dev boxes at work now... sometimes the perks of working here are pretty nice. Mmm... generics.

One of my coworkers suggested I take another look at Managed C++ (during our conversation I expressed my "dismay" at the prior version's foibles), so I'll take a peek at that as soon as I have a spare cycle or two. It's pretty hard to get any free time with the painting at home and the heavy influx of QFE issues we always get post release, but I'm sure I'll manage.

Recording over 1394 (Firewire) in Media Center

Peter Rosser — Wed, 26 Oct 2005 09:26:00 GMT

There has been some recent effort to pry open the 1394 interface in various STBs (set-top boxes), most notably that of timmmoore's STB package that goes to extraordinary lengths to hook into Media Center's experience. The state of the world today, at least with Media Center, is that the "outside looking in" hooks of Tim's package are the only way to get that HD content off of digital cable and into Media Center.

Here's how his package works, in a nutshell. You install a couple of drivers that provide a software interface to the various commands you might expect to be available from an STB: channel changing, power toggle, etc. An application then runs in the notification area, or tray, and acts as an intermediary between Media Center and the STB drivers. When Media Center says "Change channel to 54", MyTray (Tim's tray application) listens in via a "hook" into Media Center and sends the channel-change command to the STB. When Media Center starts a recording, another hook lets MyTray know that's happened and MyTray sends a "start streaming video over 1394" command to the STB. When Media Center stops the recording, a similar event happens.

Physically, you connect your computer with the STB by plugging in a IEEE.1394 (Firewire) cable into each. If you have two STBs, you can daisy-chain them together. The traditional "IR" blaster for each STB is removed from the receiver so that it does not interfere with the commands sent over the 1394 connection.

There are a couple of significant downsides to doing it this way:

It's a lot harder to hook in from outside Media Center and try to figure out when channels are changing, recordings are starting or stopping, and in multi-tuner scenarios, which tuner/STB to use than it would be if Media Center could just treat the STB as a virtual tuner.
You still need an analog tuner for each STB you need to control. This may seem odd, but it's part of the reason this works. From Media Center's point of reference, it is still managing all of the recording and channel changing. The fact that the actual channel change is triggered by another application is unknown and unknowable within Media Center.
Since Media Center is still recording over the analog tuners, you end up with two copies of the same program. MyTray can be set to clean up the Media Center version once it knows its recording completed successfully (e.g. no 5C protection from the STB prevented the recording), but you still churn the disk more (2x more for non-HD shows).
Premium content like HBO is likely protected by the STB by the 5C standard, which MyTray does not support. Nor can it without obtaining a 5C certificate, which are pretty hard to get. The sticky parts for most interested parties are the unlimited liability clause you have to sign, and the certification process itself, which I hear is stringent.
MyTray is the product of a single developer, and one person alone cannot bring to bear the necessary development, testing, and packaging resources that bring a high polish to a product. A common saying that applies here is "90% of the work is in the last 10% of the project". Tim did a great job and some impressive detective work getting the app where it is, but getting that "shipping product" quality is a hard job to do all by yourself, working in your spare time.

I am personally using this at home right now, despite the downsides. The fact that I am willing to do this probably means I'm not alone, and in the few informal hallway conversations I've had about it there's a lot of interest in getting this sort of thing done natively in Media Center. There's not matching excitement about funding the cost of doing it, but there seldom is, when it comes down to it.

As Media Center becomes the default SKU for OEMs shipping Windows and our user base grows, there is a tremendous downward pressure on the unit cost of the machines. The first target for downsizing seems to be the tuners, since a fair number of those new Media Centers are being sold as "Tuner Ready" instead of "Tuners Inside". In my humble opinion, implementing a 1394 recording solution is the single best way to get broad market appeal while keeping hardware costs low. Everybody wins: we sell our Windows licenses, OEMs move more units, customers get reliable, scalable SD & HD recording, and the cable companies get their $10 a month from renting their STBs.

Consumers are used to paying the fee, and I think they would continue to do so. There's been a market for leasing otherwise expensive equipment for many years, and there's no reason to think that will change soon. When faced with a decision between $10 a month (or $20 for two STBs), or buying a $250 tuner (or two), a lot of people go for the monthly fee. After all, it takes over 2 years to amortize that, and with technology that seems like a good bet to me. Being on the bleeding edge is more comfortable if you can stay there on a lease. ^_^

Which brings me to the true point of my post: I want to hear how much this feature is wanted in the user community. Is it only wanted by the technically savvy, or do "average" users want it? I really want it, and I don't want this relegated to the "power user" or "enthusiast" bin, because that will result in, at most, a power toy implementation. If we can bring a full feature team to bear on this, I bet we could really make our users happy.

Just think, you could have everything Media Center gives you, plus VOD support (including Pay-Per-View, integrated into Media Center), and HDTV over digital cable. If I'm not mistaken, this could easily expand into satellite STBs, too, if they don't already support streaming over 1394.

I'm going to get back to tinkering with the Network Provider and 1394 tuner classdriver code some more... I'm all worked up with excitement now. ^_^

DRM in MCE Rollup 2

Peter Rosser — Fri, 21 Oct 2005 05:33:00 GMT

I was posting to TheGreenButton.com and thought I'd save myself typing the same thing again, since it's good info, even if I am restating/repackaging existing opinion. The following is a response to people who thought for some reason that Rollup 2 was applying DRM to things that it did not before:

Rollup 2 did not substansively change the way that we determine whether something should be copy protected or not; what it did was change some of the infrastructure of the underlying protection scheme. Basically we revved the DRM version and refined some of the business rules that determine what level of DRM a piece of content gets.

Whether something is protected by DRM depends on whether the broadcaster sends us CGMS/A (Copy Generation Management System / Analog) flags on Line21 of the analog signal. This is *not* the (in)famous "broadcast flag". If you want to know more about how CGMS/A works, there is plenty of material on the net. Another factor is Macrovision (software and/or hardware), or in Europe, the CP flag.

CGMS/A can set 4 different modes: CopyFreely (i.e. no protection), CopyOnce, CopyNoMore (i.e. it used to be CopyOnce, but you made a copy... so you don't get to copy it again), and CopyNever (no copies at all). Since our whole business is built around timeshifting content, we don't count the one stored version as a copy at all, though in CopyNever circumstances the license is generally good for only a limited time.

I'm not a big fan of DRM, but I do see the business need for it. Microsoft makes a big, inviting target for lawsuits if we even appear to be soft on protecting copy protected content. That doesn't make me happy, since it attempts to restrict what I can do with "my" content, and no matter how much I am told (and cerebrally understand) that it's not mine at all, but I'm just licensed to view it, I still persist in thinking of it as "mine". After all, I paid for it! As a consumer, I want complete freedom in what I do with my content. As a stockholder in Microsoft, I want to both protect from lawsuits and grow the consumer market, which seem to be opposing goals.

So what we have is a compromise: DRM. We have encryption technology strong enough to make it not worth cracking (by the time you have cracked it, you've spent more than it would have cost to just go out and buy another copy of the content... probably many hundred/thousand/million times). With the technology also comes the ability for us to open up windows to use the content in limited ways... hopefully the ways that consumers really want to use it. Of course, you can't just send copies around to everyone. But you CAN (or should, if it's working right) put the content on a portable device. Or make a DVD backup.

There's more to this than most people realize, though. Not only do companies like Microsoft and Apple have to guard against lawsuits, etc., but they have to make the studios and other content producers happy enough with the DRM solutions that they will go *farther* and give us more content in more flexible ways. Do you think that Comcast, DirecTV or EchoStar would agree to attach a digital tuner to a PC that can decode their signal without an ironclad guarantee that the content would not just end up on the net? They are terrified of that prospect... and with (arguably) good reason. DRM is what we need to open up PC-based solutions for all of our content. I don't want to pirate my Comcast Digital Cable feed... but I *do* want to watch it! In high-definition and on my Media Center. If the DRM gets out of my way, and lets me burn a DVD for my collection (hard drives are finite, after all), then I'm game. I don't care if I can't just post a video of some HBO movie on the internet. I don't really have the inclination anyhow.

I know there are a lot of folks out there who vociferously oppose DRM on principal. The "information should be free" crowd argues on the principal that you cannot own information, and content is just information. That isn't reality, though, and the courts and laws agree that people who create content can sell it. I won't pontificate further on that, but leave with a parting piece of information relating to the prior paragraph: if the "no DRM" crowd wins, we won't have lots of content with no DRM suddenly... what we'll have is broadcasters and content creators that won't have any reason to share their content. Hollywood will release it's next generation of DVD replacements, this time with something less laughable than CSS protection, and that'll be it. No PC viewing of digital content, just analog. Depressing to me...

</soapbox>

This is just my opinion... I'm not a policy setter, and not on any DRM or Copy Protection team. Fill in all the other disclaimers about my opinion not being my employer's, and all that. ;)

PC Video Outputs

Peter Rosser — Thu, 20 Oct 2005 20:38:00 GMT

I am seeing a pattern of confusion regarding S-Video and video resolutions with a lot of users in the community, so this posting is for those of you asking things like "why can't I get HD over S-Video" or similar questions.

If you want anything above 800x600, you have to use Component, VGA, or DVI/HDMI outputs. S-Video and Composite just don't support it. Even if you can select 1024x768, it's not going to be a good picture over S-Video or Composite.

Building on this, you cannot even get true widescreen resolutions through S-Video or Composite. Sure, you can letterbox it, or mess with the video timings and get whatever you like, but the bandwidth available over the connector just won't support good video quality at anything above 800x600. Any "wide aspect" video coming over one of those 2 connectors is going to be virtual/anamorphic or a custom timing that most hardware doesn't support.

In terms of video quality, here's the rundown, from best to worst:

DVI/HDMI (unless you need resolutions above 1920x1200, but that's another thread)
VGA
Component
S-Video (up to 800x600 only)
Composite (up to 800x600 only)