On Tue, 9 Aug 2016 22:36:05 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
.... ain't gonna work with the current code-base of either xulrunner (firefox and ice* types) or webkit (chrome, midori, qupzilla). darn.
the reason for webkit is: although gstreamer supports vdpau and vaapi, and even can be activated to do hardware-accelerated decode, webkit (at least as best i can find) the gtk+ variant then targets *opengl* as the output rendering engine, rather than asks VAAPI / VDPAU to handle it directly on the webkit engine's behalf.
Background: the website may need to do transformations on the data, read the data, or overlay several dozen layers of ads on top of the video, each with different clicky reactions.
Thus, a web browser outputting to a hw video layer would be non-compliant, as it would in most cases prevent those things (and especially for the ads, we can't have that, can we?).
So, you can't expect it to be mainlined in any popular browser, even if you develop such. It would break some sites, and block ads on others.
(plug: Fifth, my browser, is happily non-compliant, as it replaces all HTML5 video blocks with "download" and "stream" buttons, the stream button calling whatever video player you want. Similar to the FF extension mentioned ITT)
- Lauri