Did you actually read the article?

Did you actually read the article?

> the hardware acceleration support is purely a function of the decoder library. (E.g. OMAP3 accelerated Theora works just fine without gstreamer)

So, you're saying that libtheora itself supports OMAP3-accelerated decoding, so that any frontend to libtheora gets that feature "for free"?

> HTML5 video tag is not just a dumb player embedded in a browser

The YouTube HTML5 player does things that the old "embedded dumb players" never could, such as: JavaScript play / pause / seek controls, pop-up menus and "drop-up" menus (like drop-down but upside-down) overlayed on the video, text annotations overlayed on the video, picture-in-picture seek-point previews (when dragging the seek bead) overlayed on the video, etc. And it seems to works just fine in QtWebKit with GStreamer.

> This is easy to demonstrate as not true.

Well, it depends on what features are important to you. For the features I care about, QtWebKit supports them better.

> or its only fast in a limited subset of cases where you can't tell the difference between compliance and not

Maybe that's what it's doing — but that's just fine for the user as long as the the common cases that need to be fast are fast. (It's sufficient for everything I currently use HTML5 video for to support the case where there's just scaled-up video playing back with no overlays or with a few fully opaque overlays, and QtWebKit handles this just fine.)

> but only if you're using GL rendering, which may be disabled on your system because your GL support is slow or broken.

Well, it works fine for compositing in KWin (except that there are a few effect plugins that can't be enabled), and for all Linux-native OpenGL games that I've tried (Torus Trooper, No Gravity, Tux Racer and Extreme Tux Racer), but it didn't work for WebGL apps in Firefox. I don't know why…

Anyway, nothing you might say can change the fact that, when running on hardware like mine, QtWebKit is the only browser engine for Linux that gives an acceptable user experience for playing HTML native video. And I can hardly believe that it's a coincidence that the one that gives the best user experience is also the one that uses GStreamer.

> Patent infringement doesn't just end at the boundary of what you distribute.

I won't believe that unless you cite case law supporting it. For one thing, it would imply that any software that uses the POSIX virtual filesystem API (open(2), stat(2), etc.) infringes Microsoft's VFAT patent, because the Linux kernel (or at least older versions of it, which are still out there) violates the VFAT patent. For another thing, that would mean that all software written for the OpenSSL API (even when in source form) was infringing the RSA patent before it expired. And in general (as I said here), if you take that line of reasoning to its logical conclusion, then any software that's written against any external API must infringe all patents that might potentially be infringed by any possible implementation of that existing API. For example,

> It's also worse from the perspective of bringing about a world where non-patented formats are widely offered by being incompatible with them.

Well in that case, it's bad that the Mozilla software stack is FLOSS, because people might fork it to add support for the patented codecs.

And also, if Mozilla did adopt GStreamer, then they could whitelist a few unencumbered codecs and exclude all the rest — as I said here, they probably should do that anyway for security reasons (that is, to shrink the attack surface).