Gizmodo 
Enter your username and password.
Tip your editors:
Editorial Director:
Brian Lam | | Twitter
Editor:
Jason Chen
| AIM | Twitter
Features Editor:
Wilson Rothman
| Twitter
Senior Contributing Editors:
Jesus Diaz
| AIM | Twitter
Mark Wilson, Reviews
| AIM | Twitter
Contributing Editors:
Matt Buchanan
| AIM | Twitter
Adam Frucci
| Twitter
Sean Fallon
| Twitter
Jack Loftus
| Twitter
John Herrman
| Twitter
Dan Nosowitz
Chris Mascari
Kat Hannaford
| Twitter
Rosa Golijan
| Twitter
Chris Jacob
Columnist:
Brendan I. Koerner
Interns:
Don Nguyen
Kyle VanHemert
Comment Account Questions:
Original material is licensed under a Creative Commons License permitting non-commercial sharing with attribution.
03/26/09
But if I can't use ffdshow in those in Win 7... forget it. It's no longer useful as an OS to me.
03/26/09
If this turns out to be some method of protecting users from potentially hazardous codecs, I say forget it. There's no need to nanny people in such a fashion.
03/26/09
Boohoo, when I play a video back it uses a built in codec that works and I can't alternately choose to render it with a third party codec that does exactly the same thing...? Can someone explain to me why I should care? What compelling reason is there for me to say "I want to view h.264s with a third party codec that I install instead of the built in one"?
This isn't forcing a user to use IE over Firefox, where there may be a clear user preference or reason to provide options.
I have no knowledge or information about this, but I wonder if baking certain codecs right in is part of a performance movement... If it were a requirement to be able to decode h.264 video on a low end netbook I could see all corners being cut to boost performance, even at the cost of some flexibility.
03/26/09
03/26/09
03/26/09
03/26/09
03/26/09
RTFA fail. on myself. ouch.
11/20/08
You've got the wrong terminology there buddy. Part 2 of the MPEG-1 specification is indeed for video and part 3 is for audio, but part 3 and layer 3 are not the same. The MPEG-1 Part 3 audio specification includes three layers of audio formats, layers 1, 2 and 3 â each one building upon the other. Thus, layer 3 includes all the elements of layers 1 and 2 plus some new stuff. This is actually a bit inefficient because of the layering, but it was ultimately decided to implement the specification in this manner to allow for the greatest compatibility. The OGG audio codec is actually very similar to MP3, just without the layer 1 and 2 compatibility â hence it is marginally better than MP3.
11/20/08
11/20/08
11/20/08
11/20/08
11/20/08
11/20/08
Pretty Cool
Poetically Curvacious
Perfectly Capable
Perversely Corrupt
Pleasant Company
I could go on but I'm sure you've heard, or read enough already.... ;)
11/20/08
11/20/08
11/20/08
11/20/08
11/20/08
11/20/08
MKV has nothing to do with your encoding/transcoding times. It's just a wrapper, or container. What governs your computational time is what's inside that wrapper. Admittedly, most MKV files on the web contain heavily compressed H264 video streams, which are very resource-intensive. But, that's not MKV's fault. If the MKV file were to contain an equivalently long and resolutioned MPEG-2 stream, it would be much faster to convert.
11/20/08
11/20/08
11/20/08
11/20/08
Also, they are usually at a better quality than those shabby .avi's (of course, all my .mkv's usually say 720p so that's probably why xD)
Oh, also. VLC laughs at those codecs! In a smug, french way. No-ho-ho-ho!
11/20/08