Re: [Wikitech-l] VP8 freed!
This is pretty far off topic, but letting fud sit around is never a good idea. On Thu, May 20, 2010 at 2:08 AM, Hay (Husky) hus...@gmail.com wrote: http://x264dev.multimedia.cx/?p=377 Apparently the codec itself isn't as good as H264, and patent problems are still likely. It's better than Theora though. You should have seen what VP3 was like when it was handed over to Xiph.Org. The software was horribly buggy, slow, and the quality was fairly poor (at least compared to the current status). Jason's comparison isn't unfair but you need to understand it for what it is— he's comparing a very raw, hardly out of development, set of tools to his own project— which is the most sophisticated and mature video encoder in existence. x264 contains a multitude of pure encoder side techniques which can substantially improve quality and which could be equally applied to VP8. For an example of the kinds of pure encoder side improvements available, take a look at the most recent improvements to Theora: http://people.xiph.org/~xiphmont/demo/theora/demo9.html Even given that, VP8's performance compared to _baseline profile_ H.264 is good. Jason describes it as relatively close to x264’s Baseline Profile. Baseline profile H.264 is all you can use on the if you actually want to be compatible with a great many devices, including the iphone. There are half research codecs that encode and decode at minutes per frame and simply blow away all of this stuff. VP8 is more computationally complex than Theora, but roughly comparable to H.264 baseline. And it compares pretty favourably with H.264 baseline, even without an encoder that doesn't suck.This is all pretty good news. On the patent part— Simply being similar to something doesn't imply patent infringement, Jason is talking out of his rear on that point. He has no particular expertise with patents, and even fairly little knowledge of the specific H.264 patents as his project ignores them entirely. Codec patents are, in general, excruciatingly specific — it makes passing the examination much easier and doesn't at all reduce the patent's ability to cover the intended format because the format mandates the exact behaviour. This usually makes them easy to avoid. It's easy to say that VP8 has increased patent exposure compared to Theora simply by virtue of its extreme newness (while Theora is old enough to itself be prior art against most of the H.264 pool), but I'd expect any problems to be in areas _unlike_ H.264 because the similar areas would have received the most intense scrutiny. ... and in any case, Google is putting their billion dollar butt on the line— litigation involving inducement to infringe on top of their own violation could be enormous in the extreme. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VP8 freed!
On Thu, May 20, 2010 at 06:28, Gregory Maxwell gmaxw...@gmail.com wrote: This is pretty far off topic, but letting fud sit around is never a good idea. Sure, VP8 looks very interesting. I hope it takes off and we get a good enough patent-free codec that's more modern than Theora. On the patent part— Simply being similar to something doesn't imply patent infringement, Jason is talking out of his rear on that point. He has no particular expertise with patents, and even fairly little knowledge of the specific H.264 patents as his project ignores them entirely. I don't know anything about the patents involved, but his comments in e.g. the Intra Prediction section are very specific, he cites H.264’s spatial intra prediction is covered in patents. He's clearly done some research and is pointing out a very specific patent-covered feature in H.264 that's very similarly implemented in VP8. Google is putting their billion dollar butt on the line— litigation involving inducement to infringe on top of their own violation could be enormous in the extreme. They're already paying the H.264 patent fees, any infringements of those are likely to involve a few million dollars/year of patent fees. Not their billion dollar butt. Hardly putting their butt on the line, that would be promising to cover any downstream patent infringement. Which they're explicitly not doing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] VP8 freed!
On 20/05/10 16:28, Gregory Maxwell wrote: Codec patents are, in general, excruciatingly specific — it makes passing the examination much easier and doesn't at all reduce the patent's ability to cover the intended format because the format mandates the exact behaviour. I always assumed there would be patents on the software processes for encoding and decoding. It seems to me that you could patent novel parts of an encoder, even if the format is 20 years old. Then you could sue anyone who tried to build an encoder using similar techniques. I would have trouble believing that all of the companies involved are too benevolent to try this. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] speed of Vector in en.wikipedia
2010/5/20 Amir E. Aharoni amir.ahar...@mail.huji.ac.il: Are there any more precise measurements? Are there proper bugs reports about it? (I searched Bugzilla for Vector slow and didn't find anything.) There are no bugs in Bugzilla for this, currently. I will dive into this and find out where the slowness is coming from (could be a lot of different things), but I'm quite busy at the moment and spending any work time I do get on fixing bugs, so it'll take some time before I get around to this. If anyone else feels like analyzing what the slow parts are (I recommend Firebug's net panel as one tool for investigating this), by all means go ahead and post your findings here. Roan Kattouw ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] js2 extensions / Update ( add-media-wizard, uploadWizard, timed media player )
Helder Geovane wrote: I would support a url flag to avoid minification and or avoid script-grouping, as suggested by Michael Dale, or even to have a user preference for enable/disable minification in a more permanent way (so we don't need to change the url on each test: we just disable minification, debug the code and then enable it again) I like the idea of a user preference. This way you don't constantly have to add debug to the url, its easy to tests across pages and is more difficult for many people to accidentally invoke it. Committed support for the preference in r66703 --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] speed of Vector in en.wikipedia
For others interested, it's now been filed in bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=23612 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
