Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Software

VP8 Codec Coming To FFmpeg 218

Jim Buzbee writes "Interested in Google's VP8 codec? Well, so were the FFmpeg guys, so they went ahead and wrote their own native decoder in only 1,400 lines of unique code. They were able to keep the line-count low by relying on heavy reuse from the existing H.264 codebase."
This discussion has been archived. No new comments can be posted.

VP8 Codec Coming To FFmpeg

Comments Filter:
  • Re:Hmmm... (Score:4, Informative)

    by Nerdfest ( 867930 ) on Monday June 28, 2010 @08:27AM (#32715188)
    Just that is enough. That alone is enough in some cases to even outweigh some disadvantages.
  • I am quite aware that this isn't any sort of definitive proof of VP8 being derivative

    You misunderstand patent law. Patent law does not require that proof that VP8 is a derivative of H.264. Patent law only requires proof that VP8 uses processes and techniques that are substantially similar to those claimed in the patents for H.264.

    OTOTH, in any lawsuit involving those patents, the H.264 patent holders will have to prove that those claims are novel (no prior art) and that even if they were novel, that were not already obvious to someone skilled in the art. And since we're talking about Google, I'm pretty sure they won't have any trouble hiring competent legal counsel should such a lawsuit be brought.

  • wtf slashdot! (Score:2, Informative)

    by Anonymous Coward on Monday June 28, 2010 @08:48AM (#32715316)

    Jesus, do some investigation.

    The ffmpeg VP8 implementation doesn't use a single function from their H.264 support. Not a single one!

    There was some arm-waving speculation that it could use something in common made by people other than the ones actually doing the work. The code they are comparing includes a f@$@# encode. The full ffmpeg VP8 implementation is ~2740 lines. The VP3/Theora implementation which shares no codec functions is 2500 lines.

  • Re:Length (Score:1, Informative)

    by Anonymous Coward on Monday June 28, 2010 @08:56AM (#32715378)

    Sure does. The people using the free codec are in violation, not Google.

  • Re:Hmmm... (Score:5, Informative)

    by BZ ( 40346 ) on Monday June 28, 2010 @08:57AM (#32715386)

    > Can the same be said of VP8?

    Not yet. Of course the format is less than 2 months old, and there _were_ several hardware companies who committed to implementing support for it at launch.

    Also, note that mobile phones don't support "hardware decoding of H.264". They support hardware-acceleration of operations needed to decode a particular profile of H.264: the Basic profile. The one that has lower quality output than VP8 does.

    So if you start bringing the hardware accel issue into the picture, then your quality metrics are suddenly in VP8's favor...

    All of which is to say that the situation is complicated. ;)

  • by BZ ( 40346 ) on Monday June 28, 2010 @09:02AM (#32715420)

    > requires proof that VP8 uses processes and techniques that are substantially similar to
    > those claimed

    Not even that. To be infringing, you have to be subject to _all_ the claims of the patent. "substantially similar" is not enough if there is one particular claim that doesn't apply to you.

    A common way of working around a patent is to pick a particular claim from the patent and make sure that your work is not covered by that claim.

    http://lists.xiph.org/pipermail/theora/2010-April/003769.html [xiph.org] has a pretty good summary of the state of the patent situation for H.264. Especially note the paragraph starting "It doesn't have to be this way".

  • Re:Hmmm... (Score:5, Informative)

    by tepples ( 727027 ) <tepples.gmail@com> on Monday June 28, 2010 @09:25AM (#32715566) Homepage Journal
    "Hardware decoding" on these ARM-based devices usually doesn't mean H.264 is implemented directly in silicon. A lot of these codecs with "hardware support" are implemented either on a secondary CPU optimized for digital signal processing, which might even be a GPU running shaders. It isn't expected to be too difficult to port VP8 decoders to these DSPs because, as the article points out, VP8 is so similar to H.264's baseline profile that it has been called H.264 with the patent numbers filed off.
  • Re:Hmmm... (Score:2, Informative)

    by Anonymous Coward on Monday June 28, 2010 @09:30AM (#32715606)

    No, and it never will. Apple's support for "open standards" is limited to only support for such standards when they depend on proprietary formats like AAC, mp3, h.264, etc. No support for Vorbis, Theora, VP8 or anything that can be implemented freely without a patent license. You wouldn't want free software to be able to compete, would you?

    MP3, AAC and H.264 are not proprietary. They are maintained by international standards bodies and developed by consensus.

    This does not mean that they are free, Free, or GPL compatible and these would be genuine complaints but you weaken them by using the inaccurate complaint that they are proprietary.

  • To be infringing, you have to be subject to _all_ the claims of the patent.

    Where did you get that information? As I always understood it, only one claim of a patent has to read on a product for the product to infringe, but all elements of that claim have to be present for that one claim to succeed

  • Re:1400 LOC? (Score:3, Informative)

    by Machtyn ( 759119 ) on Monday June 28, 2010 @10:06AM (#32716024) Homepage Journal
    It is fairly well known that the more lines of code the more prone to errors the code base can be. Therefore, the fewer lines of code, the less chance there is that a coding error will occur. If there is an error, it is easier to find than by perusing a 10k LOC or a 1000k LOC codebase.
  • Yep. One claim is all that is needed for a product to infringe, but all elements of that claim must apply in order for that claim to succeed.

    As BZ is trying to say, a common workaround is to make your product so that one or more elements of each claim do not apply. This is not necessarily an easy thing to do however; it depends on how broad or narrow the given patent(s) is/are.

    BTW--I am not a lawyer and this is not legal advice.

  • Re:Hmmm... (Score:5, Informative)

    by fuzzyfuzzyfungus ( 1223518 ) on Monday June 28, 2010 @10:55AM (#32716626) Journal
    It should be noted that the MPEG-LA specifically does not "take on the responsibility and risk for future patent infringement lawsuits". Your MPEG-LA license covers only MPEG-LA patent pool patents, it does not constitute any sort of promise that these patents are the only ones required to implement the spec, nor does it offer indemnification in the event that you are sued over your implementation of the standard for which you purchased an MPEG-LA license.

    Paying your protection money to them does ensure than none of the MPEG-LA members will sue you(at least over any patent that they have contributed to the MPEG-LA pool for the technology in question); but it confers no protection against any nonmember with a patent that they believe is being infringed upon(given that this group includes a little old mom 'n pop operation they call "AT&T" this isn't exactly a theoretical risk)...
  • by Svartalf ( 2997 ) on Monday June 28, 2010 @11:11AM (#32716812) Homepage

    Actually, no, it's not prima facie evidence of anything other than the person that filed the application either got a rubber-stamp or was able to out-argue the examiner. Nothing more, nothing less.

    As an example thereof, I need only point to any number of Amazon's patents, including the one they just got in this last month.

    Having filed for a patent before in the past, I can assure you that while that what you say is supposed to be a requirement, even if you meet the criteria, you can have a protracted paper fight with an examiner that flipped a coin and decided to invalidate your patent- and then go looking for "patents" that "anticipate" your invention's specification, even though the guy/gal didn't do their homework and came back with a rejection that looks like the they were smoking magic mushrooms when they did the examination of your patent.

    Patents are nothing of what many make them out to be in this day and age.

  • Re:Hmmm... (Score:3, Informative)

    by hitmark ( 640295 ) on Monday June 28, 2010 @11:16AM (#32716894) Journal

    funny enough, vorbis is big in gaming. The various versions of the unreal engine have been using it for music, iirc.

  • by Anonymous Coward on Monday June 28, 2010 @11:58AM (#32717370)

    VP8 is codec number 8 of a series of On2 codecs that goes way back before H.264. Google On2 and see for yourself. On2 began marketing VP3 in 1999.

    Alternative method:

    H.264 is the latest codec in a series that goes back to before On2 existed. H.261 was standardized in 1988.

  • by bonch ( 38532 ) on Monday June 28, 2010 @12:37PM (#32717896)

    VP8 has already been dissected [multimedia.cx] and determined to be a bad video codec that likely steps on several H.264 patents. Note that Google isn't providing any legal protection for using this codec.

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Working...