GStreamer VA-API Plug-In Update Adds New Features

[gbeauche]

For me it doesn't crash. Quality isn't good. At least not consistent. I see some artifacts and its blur some times.

Bad:


Good:


+ a flickr on the screen each time i start a video.

Need to test more though. gst-play-1.0 is broken also.

Bad vs. good refers to what?

Note: current Firefox implementation (from 31.0 sources) doesn't care of tracking GstVideoAlignment changes. A better approach would be to use GstVideoMeta and GstVideoCropMeta. Anyway, real performance improvements could only be obtained through Firefox changes. At least, there is no reason gst-vaapi should crash or hang, which was fixed.

[gbeauche]

In case anyone that can do something reads here.

The quality issue is that when changing to the big player it doesn't use the 720p resolution but a smaller one. And when using the small player the quality is shit. Might has to do with scaling of the video or something. Not sure if this is a gst-vaapi issue or a youtube one.

AFAICS, 360p is used by default. 720p is the maximum without MSE support in Firefox at this time.

[89c51]

An indication of CPU usage without the current CPU frequency is kind of useless you know. It could be 54% of CPU @ 774 Mhz vs. 114% of CPU @ 1.8 Ghz, that's not quite the same.

while playing BBB in 720p in youtube


while playing a simpsons 1080p trailer with gst-play-1.0 (which sometimes works sometimes it doesn't)



Thanks for your work.

[89c51]

Bad vs. good refers to what?

Refers to quality. I think its obvious in the pics.

[gbeauche]

while playing BBB in 720p in youtube


while playing a simpsons 1080p trailer with gst-play-1.0 (which sometimes works sometimes it doesn't)



Thanks for your work.

Firefox will not use hardware accelerated rendering and requires the decoded frames to be transferred to their own buffers. i.e. reading every single frame from GPU memory is necessary. If you want to compare Firefox behaviour's to the "optimal" one, you could probably use gst-launch-1.0 uri=file:///path/to/Video.mp4 video-sink="ximagesink" (similar to firefox behaviour), vs. gst-launch-1.0 uri=file:///path/to/Video/mp4 video-sink="vaapisink" (the default).

Yes, we have NV12 -> I420 (HW accelerated through GPU memory) -> read back to I420 buffer -> I420 to RGB32 conversion through SSE2 code it seems. Not the fastest pipeline, but patches are welcome for Firefox.

[liam]

There are actually four and all are pretty similar:

VDPAU - Decode only. Designed by nvidia. Currently supported by radeon, nouveau, nvidia drivers.
VA-API - Encode and Decode. Designed by Intel. Currently supported by intel driver.
OpenMAX - Encode and Decode. Multi-platform Khronos standard. Currently supported by radeon driver.
XvBA - Decode only. Designed by AMD. Currently supported by catalyst driver.

The main difference is who designed them. They tend to be somewhat tailored to the designer's hardware.

Intel will do their own thing but is there any reason why the other (open)drivers don't get behind openMAX for both encode and decode? The standard looks very complete with regards to hardware media acceleration, in general, but, likewise, pretty complicated.

[89c51]

Firefox will not use hardware accelerated rendering and requires the decoded frames to be transferred to their own buffers. i.e. reading every single frame from GPU memory is necessary. If you want to compare Firefox behaviour's to the "optimal" one, you could probably use gst-launch-1.0 uri=file:///path/to/Video.mp4 video-sink="ximagesink" (similar to firefox behaviour), vs. gst-launch-1.0 uri=file:///path/to/Video/mp4 video-sink="vaapisink" (the default).

Yes, we have NV12 -> I420 (HW accelerated through GPU memory) -> read back to I420 buffer -> I420 to RGB32 conversion through SSE2 code it seems. Not the fastest pipeline, but patches are welcome for Firefox.

I was just comparing non vaapi vs vaapi in firefox. I was getting around 60% CPU without and around 40% with. Hence my comment on not seeing much improvement in CPU usage with vaapi. Thanks for the info.

The screen flickering upon starting a video is the annoyance that remains then.

[89c51]

BTW does anyone know if gst-omx is considered production ready for r600 drivers?

[89c51]

Also i sometimes get this and a black screen in Youtube.

Jul 29 23:14:54 mainland kernel: [drm:radeon_uvd_cs_msg] *ERROR* No more free UVD handles!
Jul 29 23:14:54 mainland kernel: [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

[89c51]

The flickering happens when going from:

Jul 30 00:08:52 mainland kernel: switching from power state:
Jul 30 00:08:52 mainland kernel:         ui class: performance
Jul 30 00:08:52 mainland kernel:         internal class: none
Jul 30 00:08:52 mainland kernel:         caps:
Jul 30 00:08:52 mainland kernel:         uvd    vclk: 0 dclk: 0
Jul 30 00:08:52 mainland kernel:                 power level 0    sclk: 10000 mclk: 15000 vddc: 950 vddci: 950
Jul 30 00:08:52 mainland kernel:                 power level 1    sclk: 60000 mclk: 100000 vddc: 1100 vddci: 1100
Jul 30 00:08:52 mainland kernel:                 power level 2    sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100
Jul 30 00:08:52 mainland kernel:         status: c

to

Jul 30 00:08:52 mainland kernel: switching to power state:
Jul 30 00:08:52 mainland kernel:         ui class: none
Jul 30 00:08:52 mainland kernel:         internal class: uvd
Jul 30 00:08:52 mainland kernel:         caps: video
Jul 30 00:08:52 mainland kernel:         uvd    vclk: 54000 dclk: 40000
Jul 30 00:08:52 mainland kernel:                 power level 0    sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100
Jul 30 00:08:52 mainland kernel:                 power level 1    sclk: 30000 mclk: 100000 vddc: 950 vddci: 1100
Jul 30 00:08:52 mainland kernel:                 power level 2    sclk: 77500 mclk: 100000 vddc: 1150 vddci: 1100
Jul 30 00:08:52 mainland kernel:         status: r

Also if you play a video on YT and then replay it it looks pixelated.