Slashdot Mirror
VP8 Decoder Implemented In Flash Using Alchemy
An anonymous reader writes "Mozilla's Chris Double has an interesting post on his blog about a port of the VP8 decoder to Flash. He writes, 'Ralph Hauwert has been posting on twitter about work he's done on getting WebM decoding to work by compiling the libvpx source code using Adobe's Alchemy technology. Alchemy is a research project that allows compilation of C and C++ libraries into code that runs on the ActionScript virtual machine used by Flash.' Of course, it's very slow and Adobe says that they'll bring native VP8 support to Flash in due course, but implementing a VP8 decoder in ActionScript is an interesting project nonetheless."
MPEG4/h264 vs. VP8 comparison (h264 slightly better): http://compression.ru/video/codec_comparison/h264_2010/vp8_vs_h264.html
HE-AACplus vs. Vorbis (HEAAC wins): http://listening-tests.hydrogenaudio.org/sebastian/mf-48-1/results.htm
WebP vs. JPEG (WebP wins): http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
I just implemented Google Chrome in Flash using Alchemy. Next I'm going to implement Flash in Flash using Alchemy. Then Alchemy in Flash using Alchemy. All on my Amiga console!
Some drink at the fountain of knowledge. Others just gargle.
http://lachy.id.au/log/2010/05/webm under "Benefits of Matroska" describes the seeking issues in some detail. The summary is that ogg requires you to read more separate bits to seek correctly, and each separate bit ends up having to be a separate HTTP request in the context of web streaming. So your latency starts to bite you when seeking. It's not an issue if you don't have to seek or if you have the whole file already. But for the youtube use case, neither is true, typically.
I take issue with the HEAACplus vs Vorbis comparison you chose.
At the sort of bitrates that are actually used in streaming HD video all lossy encoders are essentially transparent, even old war horses like MP3. Performance at lower bitrates is academic at best. Vorbis beats all comers in the 80-96kbps range, and HEAACplus beats all comers under 64kbps, but neither is relevant to HD streaming video.
Google has had a year to submit VP8 to a standards organization, but hasn't done so, so its Googles fault that it isnt even on the road to being a standard.
The relevant standards bodies have no interest in something like VP8. VP8 is designed not to be patent-encumbered, whereas standards bodies like the MPEG group aim to create video codecs that are as technically advanced as possible and that are encumbered by as many of their members' patents as possible. (The patent encumbrance isn't just a side-effect of wanting the best codec possible - member organisations deliberately try and make sure that their patents are an unavoidable requirement of implementing the standard, because they directly benefit from this.)
Standards bodies are not a panacea, and they have known issues. This is one of those issue.
Essentially, ONLY that reference implementation is owned by Google. Make a change that accelerates decoding (while remaining compatible) and you might just land smack dab in the middle of not "free."
That's true of basically everything in the software industry, including h.264 itself. Remember that the h.264 patent consortium does not even guarantee it owns every patent that affects h.264, let alone patents covering particular implementations. It's still better than h.264 though - that's designed so that you can't write a compliant decoder or encoder at all without infringing patents, because the specification was written by the patent owners.