Comment 27 for bug 1424201

(In reply to Jean-Yves Avenard [:jya] from comment #11)
> (In reply to Tony Houghton from comment #9)
> > > You're much better off using ffmpeg
> >
> > Only in versions of ffmpeg that support VDPAU and VAAPI. I'd be very happy
> > for Firefox to use that route to gain GPU acceleration.
>
> This is irrelevant to what ffmpeg does, nor if it was compiled to support
> either vaapi or vdpau. Compiling FFmpeg with vdpau or vaapi support won't
> automagically make applications using ffmpeg start using hardware
> acceleration unfortunately.

I know that, but doesn't ffmpeg provide some sort of API wrapper so that if you're already using it for software decoding it's easier to adapt your code for acceleration instead of starting again from scratch? And even if not, its demuxers and audio decoders should still be useful alongside VDPAU/VAAPI.

> The P in VDPAU stands for Presentation. The only way you can paint an image
> decoded with VDPAU is to *P*resent it directly using VDPAU. It can't be
> rendered the way all the other images are typically painted.
> VAAPI is similar (There's also the issue that an entire generation of intel
> GPUs are buggy)

That's just one type of GPU, there are many others that could be supported without that sort of hardware/driver problem.

> We do not have a VDPAU compositor (nor a OpenGL-VAAPI), so we currently have
> no other options but copying the decoded image out of the GPU memory into a
> software surface (which is exactly what the vaapi gstreamer plugin does).
>
> Doing so almost always annihilate any benefits, as copying the image back
> from the GPU is typically slow (and even more so with nvidia devices)
>
> To make things worse, at this stage, firefox on linux doesn't have hardware
> accelerated compositor either (OpenGL isn't enabled by default).

But OpenGL can be enabled, and Firefox's support for WebGL on Linux seems quite good. Seeing as you can use an accelerated surface for WebGL canvases, is it really that much harder to set one up for video elements so you can use VDPAU or VAAPI effectively?

I really can't agree that we're better off with software-only ffmpeg and that you shouldn't make every effort with GPU decoding. I've experienced that even some very recent generation desktop CPUs (eg Core i3 @ 3GHz) can't maintain the proper frame rate with some HD video. And 4K videos are already appearing on youtube. (Although we'd presumably have to wait for Firefox's DASH support for these).

> We won't be using FFmpeg's hwaccel layer to access vaapi or vdpau (it's only
> a helper)
>
> (BTW, AMD's own XvBA is perfectly documented)

Nevertheless, there seems to be something blocking its adoption. But I think there was talk of exposing it via VAAPI if and when it does get supported properly, anyway.