There's been a lot of talk recently about Google's announcement that Chrome would no longer be supporting H.264 as a web video codec, making room for WebM, their own open source, royalty free codec called VP8. Many are unhappy with this news, since it will make it initially more difficult to publish a video on the web that is viewable in any browser on any computer. Many browsers are already supporting VP8, and others using Safari and IE will have to install plugins for the content to be available. There is speculation that web video publishers may turn back to Flash in the interim while VP8 support becomes more universal. But Flash is clunky on mobile devices, and there's been a big push for HTML5.
Aside from compatibility issues, we are also concerned about quality. So, I decided to load VP8 on our computers, and check it out. Here are the results of my preliminary test, using comparable settings in both codecs.
H.264, 1000kbps, Multi-Pass, 1.7MB
VP8, 1000kbps, 2-Pass, 3.1MB
The differences are extremely slight. It looks like VP8's color is a little richer, with slightly fewer compression artifacts, but really it's nothing drastic. VP8 is almost twice as large at H.264, which was surprising.
2 comments:
My tests for an 1920x1080 video of 3 mins length, at the same picture quality, half file size for VP8 (and thus half bitrate). Also it took a lot less time to encode VP8.
Your figures don't make sense: both 1000K yet different size? How's that? You mean u set ur compressor at 1000K. Did you take a look at what bitrate the video is actually encoded at?
And please stop pushing HTML5 as having anything to do with video.
On OSX in Safari you have the same old shitty Quicktime Player disguised with a new skin and no logo and no right click, playing the same shitty way, this time embeded using the video tag (wow, just another object/namespace/video tag). On Internet Explorer, it's the same Windows Media Player disguised with a skin, no right click, etc. same story, with the same way of playing video via Windows Codecs. Etc. HTML5 video tag. It has more to do with these companies trying to push their player up down our throats, than it has to do with freedom and standards.
Thanks for your comment, and sorry for the confusion.
I was indeed indicating 1000kbps (kb per second), not 1000kb (file size). This was the exact data rate (bitrate) set using MPEG Streamclip's H.264 and VP8 compression settings. Hence my surprise to find the process yielded different file sizes when the only thing I changed in my compression settings was the compression codec. I'm curious to find out if anyone else has noticed this (or can offer an explanation).
Also I feel it's important to mention that I am not pushing HTML5. I have observed "a push" for HTML5 because of Apple's refusal to make its devices compatible with Flash. I don't believe I claimed anything one way or the other about "freedom or standards," but I agree with your comment.
As video content creators publishing to the web, it is extremely important to be aware of how websites that display our videos are built. And in that sense, I feel it has everything to do with video.
Thanks again for reading and sharing your thoughts!
Post a Comment