GStreamer VA-API Plug-In Update Adds New Features

[kokoko3k]

I don't know if this thing is working at all.
i made a simple 720p .mp4 file with an h264 inside and put it into /tmp/video.mp4
then, in firefox i went to file:///tmp/video.mp4 and clicked on it.
It started playing and the cpu usage wasn't that bad:

# top -b|grep -i fire
24156 root      20   0 1404708 325856 112752 S  12,9  6,4   0:07.75 firefox
24156 root      20   0 1404708 325868 112752 S  11,0  6,4   0:08.08 firefox
24156 root      20   0 1404708 326248 112752 R  11,0  6,4   0:08.41 firefox
24156 root      20   0 1404708 324432 112752 R  11,0  6,4   0:08.74 firefox
24156 root      20   0 1404708 324700 112752 S  10,6  6,4   0:09.06 firefox
24156 root      20   0 1404708 325232 112752 S  10,6  6,4   0:09.38 firefox
24156 root      20   0 1345640 318492 112908 R  20,6  6,3   0:10.00 firefox

firefox also reported in the console:

libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0

I i decided to test without vaapi acceleration and uninstalled gst-vaapi.
This time firefox didn't reported anything in the console, but still the cpu usage was about the same:
# top -b|grep -i fire

24887 root      20   0 1272800 330908 109036 S  12,8  6,5   0:04.39 firefox
24887 root      20   0 1283300 314076 109632 R  24,6  6,2   0:05.13 firefox
24887 root      20   0 1297868 315444 109664 S  18,6  6,2   0:05.69 firefox
24887 root      20   0 1297868 312756 109720 S  19,9  6,2   0:06.29 firefox
24887 root      20   0 1298060 311700 109720 S  18,3  6,1   0:06.84 firefox
24887 root      20   0 1296652 309784 109720 S  20,0  6,1   0:07.44 firefox

...meh

[drSeehas]

... 114% of CPU ...

LOL
How do you achieve more than 100%?

[89c51]

...meh

Maybe try with a 1080p file.

[profoundWHALE]

LOL
How do you achieve more than 100%?

Simple. I have 4 cores. A program with multi-threading can use about 98% of all of them due to the 4-8% CPU the OS needs regardless.
So:
Core 0: 94%
Core 1: 98%
Core 2: 100%
Core 3: 100%

So that one program used 392%

In Linux (using top), if you're running 3 programs and they all say 100%, then you know they aren't multi-threaded.
Windows works the other way around. If you're running 3 programs and they all say 25%, then you know they aren't multi-threaded.

[profoundWHALE]

I don't know if this thing is working at all.
i made a simple 720p .mp4 file with an h264 inside and put it into /tmp/video.mp4
then, in firefox i went to file:///tmp/video.mp4 and clicked on it.
It started playing and the cpu usage wasn't that bad:

# top -b|grep -i fire
24156 root      20   0 1404708 325856 112752 S  12,9  6,4   0:07.75 firefox
24156 root      20   0 1404708 325868 112752 S  11,0  6,4   0:08.08 firefox
24156 root      20   0 1404708 326248 112752 R  11,0  6,4   0:08.41 firefox
24156 root      20   0 1404708 324432 112752 R  11,0  6,4   0:08.74 firefox
24156 root      20   0 1404708 324700 112752 S  10,6  6,4   0:09.06 firefox
24156 root      20   0 1404708 325232 112752 S  10,6  6,4   0:09.38 firefox
24156 root      20   0 1345640 318492 112908 R  20,6  6,3   0:10.00 firefox

firefox also reported in the console:

libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0

I i decided to test without vaapi acceleration and uninstalled gst-vaapi.
This time firefox didn't reported anything in the console, but still the cpu usage was about the same:
# top -b|grep -i fire

24887 root      20   0 1272800 330908 109036 S  12,8  6,5   0:04.39 firefox
24887 root      20   0 1283300 314076 109632 R  24,6  6,2   0:05.13 firefox
24887 root      20   0 1297868 315444 109664 S  18,6  6,2   0:05.69 firefox
24887 root      20   0 1297868 312756 109720 S  19,9  6,2   0:06.29 firefox
24887 root      20   0 1298060 311700 109720 S  18,3  6,1   0:06.84 firefox
24887 root      20   0 1296652 309784 109720 S  20,0  6,1   0:07.44 firefox

...meh

Here's your problem: You are using Firefox to open it. Web browsers are pretty awesome, but to do the same thing as a normal video player it requires more CPU, period. I know this because I had a Pentium 4 computer whose GPU died, and I could still watch 720p h.264 video in VLC (if I disable a few things) However, I couldn't even watch 480p video properly on youtube, heck, it was choppy when watching 360p! Using YTO (when it was still free not saying it's not worth paying for but anyways) I copied the download link address under the video and was able to watch 720p and stream it better using a media player on the desktop.

[89c51]

Is the screen flickering something to be expected when clock speeds (or whatever that is) change or is there something wrong with the r600 driver.

[liam]

I don't know if this thing is working at all.
i made a simple 720p .mp4 file with an h264 inside and put it into /tmp/video.mp4
then, in firefox i went to file:///tmp/video.mp4 and clicked on it.
It started playing and the cpu usage wasn't that bad:

# top -b|grep -i fire
24156 root      20   0 1404708 325856 112752 S  12,9  6,4   0:07.75 firefox
24156 root      20   0 1404708 325868 112752 S  11,0  6,4   0:08.08 firefox
24156 root      20   0 1404708 326248 112752 R  11,0  6,4   0:08.41 firefox
24156 root      20   0 1404708 324432 112752 R  11,0  6,4   0:08.74 firefox
24156 root      20   0 1404708 324700 112752 S  10,6  6,4   0:09.06 firefox
24156 root      20   0 1404708 325232 112752 S  10,6  6,4   0:09.38 firefox
24156 root      20   0 1345640 318492 112908 R  20,6  6,3   0:10.00 firefox

firefox also reported in the console:

h
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_0_33
libva info: va_openDriver() returns 0

I i decided to test without vaapi acceleration and uninstalled gst-vaapi.
This time firefox didn't reported anything in the console, but still the cpu usage was about the same:
# top -b|grep -i fire

24887 root      20   0 1272800 330908 109036 S  12,8  6,5   0:04.39 firefox
24887 root      20   0 1283300 314076 109632 R  24,6  6,2   0:05.13 firefox
24887 root      20   0 1297868 315444 109664 S  18,6  6,2   0:05.69 firefox
24887 root      20   0 1297868 312756 109720 S  19,9  6,2   0:06.29 firefox
24887 root      20   0 1298060 311700 109720 S  18,3  6,1   0:06.84 firefox
24887 root      20   0 1296652 309784 109720 S  20,0  6,1   0:07.44 firefox

...meh

Try this method:

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.

[arokh]

I have an Intel NUC D54250WYK that i use for HTPC. Normally I use XBMC to play movies and that works great. The box has a Haswell core i5-4250U with HD5000 GPU. Seeing as the latest gst-vaapi release supports MVC 3D decoding I'm really anxious to get a gstreamer based movie player going.
Only problem is that when I try to play a movie it fails with the "intel_do_flush_locked no such file or directory" error. This happen with pretty much every media file I have (mostly mkv/h264).
Anyone else seeing this? Do you have an intel card working with gstreamer media players?
Driver stack:
Kernel 3.16-rc7
Mesa 10.3 git
libva and libva-intel-driver from git
libdrm 2.4.56
xf86-video-intel git
x.org 1.16.0
Tried stable versions of every component in the stack as well with the same result. No special xorg.conf options, no nothing.