4 ms·
But not free, and thus they aren't truly FOSS... > In countries where patents on software algorithms are upheld, vendors and commercial users of products that
by k3n 13y ago
But not free, and thus they aren't truly FOSS...
> In countries where patents on software algorithms are upheld, vendors and commercial users of products that use H.264/AVC are expected to pay patent licensing royalties for the patented technology that their products use. [...] All other royalties remain in place, such as royalties for products that decode and encode H.264 video.
1. http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Controversies http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Controversies
edit: s/free/not free/
- anon1385 13y agoBy that logic Linux isn't truly FOSS either since it no doubt infringes on many software patents and users of Linux have been sued over patents[1]. This is one of the main problems with software patents: they are so broad and numerous that it's impossible to write non-trivial software without infringing on something without even realising it. [1] http://www.digitaltrends.com/computing/google-fined-5-million-in-linux-patent-case/ http://www.digitaltrends.com/computing/google-fined-5-millio...
- ergo14 13y agosued - sucessfully? ;-)
- bad_user 13y agoThere's a difference between willful and non-intentional infringement. If you use H.264 and you get sued by MPEG LA, you can be damn sure that they'll win and that you'll pay up a fortune for it. On the other hand, patents really aren't so broad and those that are can be and have been overturned in court for being too general - with exceptions of course, of which you hear because they are so outrageous (like Amazon's 1-click patent). In reality, it's really hard to prove that something is infringing on a patent, if the infringement wasn't intentional. In the Oracle versus Google case, Oracle was hoping they'd get Google with copyright infringement (of APIs no less), the patents involved being just in case the copyright infringement claims wouldn't work. Google won on all fronts. The reason for why threats of patents infringement are so dangerous is because few companies are willing to make a stand and would rather settle.
- mietek 13y agoIt's not clear whether VP8 is patent-free, and it has other issues. http://x264dev.multimedia.cx/archives/377 http://x264dev.multimedia.cx/archives/377 Addendum C: Summary for the lazy VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It’s not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved. VP8, as an encoder, is somewhere between Xvid and Microsoft’s VC-1 in terms of visual quality. This can definitely be improved a lot. VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much; VP8 as a whole is similar in complexity to H.264. With regard to patents, VP8 copies too much from H.264 for comfort, no matter whose word is behind the claim of being patent-free. This doesn’t mean that it’s sure to be covered by patents, but until Google can give us evidence as to why it isn’t, I would be cautious. VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it’s a big upgrade with regard to patent-free video formats. VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoder’s interface is lacking in features and buggy. They aren’t even ready to finalize the bitstream format, let alone switch the world over to VP8. With the lack of a real spec, the VP8 software basically is the spec–and with the spec being “final”, any bugs are now set in stone. Such bugs have already been found and Google has rejected fixes. Google made the right decision to pick Matroska and Vorbis for its HTML5 video proposal.
- BitMastro 13y agohttp://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html http://blog.webmproject.org/2013/03/vp8-and-mpeg-la.html
- ZeroGravitas 13y ago> VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much; VP8 as a whole is similar in complexity to H.264. Funny that he himself wrote a ffmpeg VP8 decoder that was between 25 and 33% faster than the libvpx decoder, which had already been improved from when he reviewed it. He said at the time it was faster than ffh264 even with more work to be done. http://x264dev.multimedia.cx/archives/499 http://x264dev.multimedia.cx/archives/499 Some recent Google tests suggests that the two ffmpeg decoders basically are the same speed when using one core (2% advantage to VP8) which rises to a 32% advantage to VP8 when using 8 cores. http://downloads.webmproject.org/ietf_tests/vp8vsh264-decodetime.txt http://downloads.webmproject.org/ietf_tests/vp8vsh264-decode...