Alex Zambelli

DirectShow isn't explicitly mentioned, though yes, you could certainly use DirectShow to, say, implement a native Smooth Streaming source filter for Windows Media Player. We enable this scenario through the availability of the Smooth Streaming Client Porting Kit, but it's up to the developers to decide whether they want to use DirectShow, Media Foundation, WM Format, QuickTime, or any other media API to implement the client component. Note that I didn't mention any of those by name either. But I get your point - I could've been more precise.

DirectShow is not the only way to implement native media apps on Windows. Media Foundation (MF) is the newer, modern media API. That's what WMP uses primarily these days.

The focus of the Microsoft Media Platform is on streaming video. It's not meant to address local capture/encode/decode/playback (e.g. AVCHD acquisition) scenarios, but its goal is to enable over-the-top scenarios.

It's seriously anaglyph only if you watched the first 4 minutes of the video. Fast forward to 4:15 to see the part about 3DTV support.

 

Check out my blog for full details on the demo:  http://alexzambelli.com/blog/2010/04/16/smooth-streaming-3d-shown-at-nab/

The multi-bitrate content that's adaptively streamed is all pre-encoded, so the server isn't doing any "resampling" on the fly. The other big difference about adaptive streaming from the way live streams are being delivered, and Eric talks about this in the video, is that adaptive streaming is done using regular HTTP downloads from regular HTTP servers. Windows Media Services isn't involved in adaptive streaming at all. The adaptive video streams are delivered as a series of small files, which the Olympics player then concatenates into a single, uninterrupted stream. It's during this process that the player can decide whether to fetch bigger (higher quality) or smaller (lower quality) chunks to match the user's bandwidth.

Encoding resolution and bitrate are related in this case. The lower the bitrate - the lower the resolution. This is done in order to work around an inherent property of compressed digital video - macroblocking. Because VC-1 video is compressed in 16x16 macroblocks, insufficient bitrate for a given resolution can lead to obvious blocking artifacts in decoded video. The easiest way to avoid this is to lower the resolution whenever the bitrate is deemed insufficient to produce "block-free" video. It's still nearly impossible to entirely avoid blocking (after all, not all video is equally complex - just compare swimming action to chess action), but changing the resolution proportionally to the bitrate helps minimize it.