=> The codec off choice was x264.
It could be handled correctly only by mp4 or mkv
mkv won because mp4 was closed (like with xvid/divx some years before)

=> As to anime, the killer feature in mkv is variable framerate.
Lot of anime is mixed content, half film-half video.
Being able to produce a rip that mixes 30 and 24 fps is mandatory if you want remove interlacing an telecine
(that’s the same reason why Real was used before and is still in use)

Dude, the word is _seamless_, as in “has no seams”.

The Corecodec engines being tied to basic intruction sets on x86 and ARM is not so bad but it looks like dedicated graphic co-processors are the new hotness so I hope you have some plans there.

Seems like the videoplayer space for basic video playback on windows is over and will get consolidated – Microsoft is on the right path there IMO. A tonne of opportunities still exist right alongside with 3d video and machine video technologies merging with consumer video over the next few years. I guess thats stuff Ben Waggoner will have seen from MS research. I thought the X360 Natal video and the PS3 Augmented reality demos from E3 were pretty awesome.

I’m the video strategist on the Silverlight team, and wanted to offer a few details on some of the topics mentioned here.

First, why Silverlight doesn’t use the system codecs. It’s really about robustness, reliability, and portability. Since we have to go on mulitple platforms (Mac and Windows) and handle older machines (down to Windows 2000), there’s not going to be a system codec for at least something we support in most cases. Plus we need to incorporate the output of decoders back into our rendering pipeline; classic YUV overlays aren’t enough. So, by including our own decoders, we know that every copy of Silverlight is capable of the same playback, and we have a good idea of performance as well. And from a security perspecive, we want everything that happens inside the Silverlight managed code sandbox to not have any access to the underlying OS. If arbitrary native-code codecs could be used by Silverlight, there’s no way to know what a malfored bitstream could do to it.

We really want to have a “just works” experience for Silverlight, and also make sure that the same version provides exactly the same functionality on every supported Mac and Windows system, and also keep things easy for Moonlight to implement.

However, there’s another extensibility model in Silverlight that could be very interesting for CoreCodec: MediaStreamSource. This allows MediaFoundation style splitters (demuxers for file format and protocol support) and filters (decoders). So, it’d actually be pretty straightforward to add Matroska support to a Silverlight Player. In the case where the MKV uses the native codecs (VC-1, WMA, H.264, and AAC), the built-in versions can be used. But if another codec is used (like E-AC3 mentioned above), a MSS using the Raw AV pipeline can be used to decode that to PCM (audio) or RGBA or YV12 (video). Silverlight can easily handle the rendering of captions, menus, etcetera, based on the metadata in the MKV file.

Smooth Streaming is implemented almost entirely in managed code using MSS; that managed code handles everything from requesting chunks of video through the networking stack to handing off the final demuxed elementary streans to the decoder. So we’re comfortable using MediaStreamSource for our premier media technology.

http://msdn.microsoft.com/en-us/library/system.windows.media.mediastreamsource_members(VS.95).aspx

Non-certified devices like the JVC XV-PB1 mentioned in this article cannot play all old DivX files and will not work with the Warner Brothers’ website. Those are just a couple reasons to look for the genuine DivX logo instead of “matroska support” or “avi support” on the box.