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."
I'm too busy to look up the details exactly, but two possibilities:
1. The container, as well as the codecs, are potentially patent-encumbered, so it's easier to steer clear.
2. The container isn't part of the patent concern, but there are companies who aren't sure of that (see #1). So it's easier to get adoption if they steer clear.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
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.
VP8 isnt a standard.
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.
Instead, VP8 is a "here is the source" codec.
It isnt the FORMAT that is patented, but instead the METHODOLOGY.
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." Have a look at the H.264 patents and you will find that most of them deal specifically with efficient methods of doing something well understood (efficient arithmetic encoding, efficient huffman encoding, efficient golumb coding...)
"His name was James Damore."
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.
I think that one of the features of Silverlight was that it was possible to write a codec in c# and it was fast enough to process video, so that could be an interesting task for someone with enough time: Testing what performs better, decoding vp8 in flash or silverlight, without native support in neither platform
What the fuck are you talking about? Take a good hard look at the codecs supported by the big three browsers. Even before Chrome's announcement, there wasn't a single column that was green all the way down. This fragmentation started long before Chrome removed h.264 support.
ffmpeg has an independent implementation of the decoder, but for the encoder you are correct.
Some people seem to be having trouble with this concept, so I'll use a little analogy.
I can patent a sorting method.. lets call it RockoonSort(). I can develop a compression algorithm that requires sorting and use my sorting method in it.
I cannot patent sorting itself, so you could go ahead and avoid my patent by using qsort(), heapsort(), mergesort(), bogosort(),
All of these video codecs use arithmetic coding, and many of the various algorithms that implement it are covered by patents. They all do the same thing, and quite a few are even functionally interchangeable (for a given input, the exact same output) but are none-the-less owned by different folks (hello IBM.)
This all boils down to methods of doing it efficiently. Using a particular kind of lookup table to avoid an expensive division? Well thats owned by someone (hello MPEG-LA) but using the expensive division is out of patent now and everyone can go ahead and do it that way (ie, slowly.) Patents on doing it without multiplications? Yep. Doing it with binary trees? Yep. Doing multiple symbols in in parallel? Yep.
Even if you accept that the reference does not violate anyones IP, you cannot accept that changes to the reference for efficiency or even porting reasons (for hardware without specific capabilities) will also keep you free and clear.
"His name was James Damore."
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.
The video tag always meant, that we should be able to assume the most widely used codec was in place.
Erm, no. The video tag always meant that we could assume that at least the codec specified in the standard itself (ie, Theora before Apple's bitchfest) was in place. It never was a popularity competition, and now that Apple managed to remove Theora from the standard and no particular codec is specified, it's all as it was before the days of Flash: a random coin toss as to whether it'll work or not, regardless of which codec(s) you use.
Instead killing off the video tag means we are LOCKED INTO h.264 in a way that would not have been true if the video tag really took off. It means we are LOCKED INTO flash players in a way that would not have been true if the video tag took off.
Don't like h.264? Then you of all people should be more angry at Google than I am, because they ensured the marginalization of WebM and VP8.
No, he should be angry at Apple, as without them there would have been a specific codec we could've relied upon even if all others were missing, one codec whose support would be universal among all HTML5-compliant browsers and devices, Ogg Theora. Instead, we get a return of "guess the codec" which, unlike what all the h.264 apologists try to claim, was pretty damn far from being universally supported even before Google's decision.
No problem is insoluble in all conceivable circumstances.
Ah, revisionism. The video tag was at no point "Theora only", as you claim, Theora was suggested as a baseline. That is you could use H.264 or whatever else as you please, just as long as you had the ability to play Theora at all. Apple basically said, "we are not doing that no matter what", and it was dropped because an unimplemented standard is pointless.
Analogies don't equal equalities, they are merely somewhat analogous.
Ah, revisionism. The video tag was at no point "Theora only", as you claim, Theora was suggested as a baseline.
Whoa there, you are responding to the wrong person. I never claimed that, I merely accepted what Draek said at face value. Correct him if you must correct someone.
The fact that Apple said "we are not doing that" simply goes back to my point that they noted people would not use a codec that didn't already have wide support. They also pointed out the madness of having to require a codec that had zero hardware support.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The relevant standards bodies have no interest in something like VP8.
SMPTE is an individual membership organization. I'm sure if an individual brought VP8 before SMPTE for standardization it would happen. SMPTE has a mixture of broadcast vendors and broadcast users of all kinds. There are some folks in SMPTE who are from companies with compression IP, but there are also plenty of other vendors represented in SMPTE that don't.
Of course, it would take time (like when SMPTE Standardized Windows Media Video as VC-1), but the result will be a well-defined specification that achieves interoperability.
Feel free to join SMPTE, show up at committee meetings, and do some standardization!