Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Google Media Mozilla News

VP8 Decoder Implemented In Flash Using Alchemy 94

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."
This discussion has been archived. No new comments can be posted.

VP8 Decoder Implemented In Flash Using Alchemy

Comments Filter:
  • by Rockoon ( 1252108 ) on Friday January 14, 2011 @01:18PM (#34879774)
    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...)
  • by Rockoon ( 1252108 ) on Friday January 14, 2011 @02:20PM (#34880698)

    Except that the method is the format. Without the format conversion, all you have are semi-random bits.

    Not a programmer, are you? You do realize that there is more than one way to implement something identical, right? No? Yeah... thats how I know that you arent a programmer.

    That DOES NOT MAKE IT NONSTANDARD.

    Nobody said that it did. You, however, seem to think that source code makes a standard.

    Plus, I suspect that you're wrong. There are several implementations of the standard.

    If they are not identical, then only one of which is owned by Google and as such only one of which is covered by Googles "we wont sue you, unless.." terms.

    The other could contain patented algorithms not owned by Google and STILL DECODE THE SAME STREAMS.

    Do you not understand that?

    You use a lot of words and have only managed to display your ignorance.

    Comming from someone that doesnt know what patents cover (WebM is not patented, although might be in the future, but the VP8 algorithms ARE patented .. the ALGORITHMS, not the format.)
    Dont be such an ignorant rude fuck, asshole, especially when you dont have a fucking clue what you are talking about.

  • by makomk ( 752139 ) on Friday January 14, 2011 @03:11PM (#34881358) Journal

    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.

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Working...