Gizmodo 
Enter your username and password.
-
posts about #videocodecs more → Windows 7 Might Block Third-Party Video Codecs
Giz Explains: Every Video Format You Need to Know
Tip your editors:
tips@gizmodo.com
Editorial Director:
Brian Lam | Email | Twitter
Editor:
Jason Chen
Email | AIM | Twitter
Features Editor:
Wilson Rothman
Email | Twitter
Senior Contributing Editors:
Jesus Diaz
Email | AIM | Twitter
Mark Wilson, Reviews
Email | AIM | Twitter
Contributing Editors:
Matt Buchanan
Email | AIM | Twitter
Adam Frucci
Email | Twitter
Sean Fallon
Email | Twitter
Jack Loftus
Email | Twitter
John Herrman
Email | Twitter
Dan Nosowitz
Email
Chris Mascari
Email
Danny Allen
Email | Twitter
Rosa Golijan
Email | Twitter
Chris Jacob
Email
Columnist:
Brendan I. Koerner
Interns:
Don Nguyen
Email
Kyle VanHemert
Email
Comment Intern:
Nick Ellenoff | Email
Comment Account Questions:
Comments@gizmodo.com
| posts about #videocodecs more → |
Windows 7 Might Block Third-Party Video Codecs |
Giz Explains: Every Video Format You Need to Know |
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