510057 - Add support for accelerated full-screen video

Status: RESOLVED DUPLICATE of bug 555839

(Core :: Graphics, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

In order to have performant fullscreen video we are going to need to use opengl/directx.

Support for older graphics chips will be trickier but on something modern we can use just use one texture per plane and do the rgb -> yuv conversion in a pixel shader.

Comment 1

[Joe Drew (not getting mail)]

Also interesting will be other OS-level primitives for doing the YUV->RGB quicker than in straight software, especially for non-programmable hardware.

Comment 2

[Bas Schouten (:bas.schouten)]

Attachment: Initial simple fullscreen video implementation

I included a patch which offers limited initial support. It does the following:

- Add a fullscreen attribute, when set to true, video is displayed fullscreen OGL accelerated.
- No controls are available in fullscreen.
- When any keypress is detected switch back to normal view.

The performance seems a bit disappointing. On my powerful ATI graphics card on Vista, the GL rendering calls seem to cause more extra CPU usage than expected for some reason. I could be doing something wrong, or poor ATI driver functionality for OGL.

Comment 3

[Bas Schouten (:bas.schouten)]

(In reply to comment #2)
> Created an attachment (id=404037) [details]
> Initial simple fullscreen video implementation
> 
> I included a patch which offers limited initial support. It does the following:
> 
> - Add a fullscreen attribute, when set to true, video is displayed fullscreen
> OGL accelerated.
> - No controls are available in fullscreen.
> - When any keypress is detected switch back to normal view.
> 
> The performance seems a bit disappointing. On my powerful ATI graphics card on
> Vista, the GL rendering calls seem to cause more extra CPU usage than expected
> for some reason. I could be doing something wrong, or poor ATI driver
> functionality for OGL.
I forgot to add in there, this is currently windows only, some context selection code and the correct libraries need to be added for other OS.

Comment 4

[Christopher Blizzard (:blizzard)]

Sorry, just wondering does this mean that using the GL accel that you're actually more CPU vs. the non-accel path?

Comment 5

[Bas Schouten (:bas.schouten)]

(In reply to comment #4)
> Sorry, just wondering does this mean that using the GL accel that you're
> actually more CPU vs. the non-accel path?

Not really. I haven't tested. But it was still quite playable with GL accel fullscreen. I'd expect software fullscreen to be much worse. I was just meaning to say I would expect virtually no CPU overhead from drawing the quad on the screen(which is what I usually get with a single quad when doing Direct3D). But there was quite some overhead, more than I expected.

Comment 6

[Stuart Parmenter]

probably big wins by sending YUV to hardware

Comment 7

[Bas Schouten (:bas.schouten)]

Attachment: Limited fullscreen accelerated video implementation

I attached the current working full screen accelerated video implementation. It works with controls. But it doesn't display the poster image, nor the context menu when you right-click it. There's a small redraw issue with the top of the volume slider when it extends. Not sure what the cause of this is. Performance is reasonable with hardware acceleration. In fullscreen it might get a bit slow when stalling on the video, see bug 520614 for the reason.

Comment 8

[Dão Gottwald [:dao]]

Is this a duplicate of bug 555839 now?