Internet Archive has been serving h264 to maximize power advantage of HW decode on mobile; would like some sort of announcements from large players before they can begin encoding to vp8/9 by default.
No big players are shipping with GPU acceleration of codec work. Super long pipelines are not compatible with parallelism used in gpu (gpu needs 1000 tasks at once to saturate buses). Video decoding cannot be broken into that many parallel task.
can gpu be used for hardware accel of post processing? Interesting; nobody doing it now.
Idea: use a fraction of the GPU to off-load some work, without paying the power cost of the GPU being utilized 100%. Unclear if the power architectures actually give a win here. (examples of where this could be used: remove noise before compression, add it back in post-proc on the client).
are there products out there that take a video in and emit VP8? bitstream using HW? There are hobbyist projects out there based on ARM SoCs?, and Big Player(tm) stuff, but not really a market in the middle.
chrome has a gif redrawing bug that triggers redraw for all gifs on page, even if not displayed https://code.google.com/p/chromium/issues/detail?id=285356
vp8 decoders are becoming stable enough that it is safe to say that if your video works in libvpx, it's likely to work in the hardware decoder
Most codec HW ships by ticking a "1080p @ 60fps" check-box; in reality measured in macroblocks per second, sometimes can even split that budget across multiple streams!
To see whether HW compositing is in effect in firefox: about:support
Mozilla is looking at hardware decode, but firefox os hardware does not have vp8 decoders in hardware (qualcomm chips, not sure which; some do have the hardware). Unclear where the resources would come from.
Celt OPUS encoder is substantially faster than vorbis encoder, but decoder is slower.
libav is doing an independent implementation of opus decoder, supported by mozilla
vbr opus should show substantial performance improvement in 1.1 over 1.0