After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770996 - Choppy video when using vaapi on radeon 6850.
Choppy video when using vaapi on radeon 6850.
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-09-07 09:28 UTC by barz621
Modified: 2016-09-07 13:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vaapi fail (62.88 KB, text/plain)
2016-09-07 12:15 UTC, barz621
Details

Description barz621 2016-09-07 09:28:16 UTC
I have gstreamer-vaapi 1.8.3 installed and libva is configured with LIBVA_DRIVER_NAME=r600.

When i play a video (used 1080p mp4) with gst-play 1.0 on X it runs smoothly but when i do the same in wayland (weston) using --videosink waylandsink i get choppy playback.

Also on X and wayland when i use apps written in EFL (ie terminology) i also get the choppy playback problem.
Comment 1 Víctor Manuel Jáquez Leal 2016-09-07 10:03:11 UTC
Thanks for reporting this.

When waylandsink or xvimagesink is used, each frame is copied, so depending on your hardware and the frame size, you may experience that choppiness. I guess you can verify it with your CPU load.

I would recommend you to use vaapisink to avoid memcopies.

Besides, for release 1.10, the support for vdpau-va bridge drier is going to be deprecated because it is not maintained anymore.

I'm going to close this bug as "not a bug", since as far I understand, that is the expected behavior.  If you think this is a bug that needs to be addressed in gstreamer-vaapi, please reopen it.
Comment 2 barz621 2016-09-07 10:26:39 UTC
The CPU load on wayland using waylandsink is not that much. And my machine is powerful enough (i7 3770 12gb ram) i believe to handle stuff like that. Tested with 480p 720p and 1080p videos.

On X xvimagesink gives me choppy video testing with 480 to 1080p.

So there seems something is off here.

Also vaapisink doesn't work on wayland. You also mention vdpau and i have removed everything vdpau related on my system.
Comment 3 Víctor Manuel Jáquez Leal 2016-09-07 11:16:21 UTC
What vaapi driver are you using? libva-mesa-driver or libva-vdpau-driver??

Consider that, in this scenario, frames are moved from GPU's memory to the CPU's memory and that's costly too.

(In reply to barz621 from comment #2)

> Also vaapisink doesn't work on wayland. You also mention vdpau and i have
> removed everything vdpau related on my system.

Odd. In Intel used to work. Perhaps is not the case of radeon's backend.

If you can perf the pipeline to see what's the bottleneck, we would find the responsible, and I suspect is a driver thing.
Comment 4 barz621 2016-09-07 11:33:54 UTC
I am using libva-mesa-driver 12.0.2. 

This is the error i get on Weston when i try to use vaapisink.

gst-play-1.0 --videosink vaapisink Videos/sintel_trailer-48 0p.mp4 Press 
'k' to see a list of keyboard shortcuts. Now playing 
/home/toliz/Videos/sintel_trailer-480p.mp4 libva info: VA-API version 
0.39.2 libva info: va_getDriverName() returns 0 libva info: User 
requested driver 'r600' libva info: Trying to open 
/usr/lib/dri/r600_drv_video.so libva info: Found init function 
__vaDriverInit_0_39 libva info: va_openDriver() returns 0 Redistribute 
latency... Redistribute latency... Redistribute latency... ERROR 
Internal error: could not render surface for 
file:///home/toliz/Videos/sin tel_trailer-480p.mp4 ERROR debug 
information: gstvaapisink.c(1434): gst_vaapisink_show_frame_unlocked
 (): 
/GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstVaapiSink:vaapisink 
0
Reached end of play list.


Can you explain me how to perf the pipeline and how to pinpoint that it is a driver issue?
Comment 5 Víctor Manuel Jáquez Leal 2016-09-07 11:54:04 UTC
(In reply to barz621 from comment #4)
> I am using libva-mesa-driver 12.0.2. 

Ok. Be aware that mesa drivers are work in progress, not a full feature implementation.

> This is the error i get on Weston when i try to use vaapisink.
> 
> gst-play-1.0 --videosink vaapisink Videos/sintel_trailer-48 0p.mp4 Press 
> 'k' to see a list of keyboard shortcuts. Now playing 
> /home/toliz/Videos/sintel_trailer-480p.mp4 libva info: VA-API version 
> 0.39.2 libva info: va_getDriverName() returns 0 libva info: User 
> requested driver 'r600' libva info: Trying to open 
> /usr/lib/dri/r600_drv_video.so libva info: Found init function 
> __vaDriverInit_0_39 libva info: va_openDriver() returns 0 Redistribute 
> latency... Redistribute latency... Redistribute latency... ERROR 
> Internal error: could not render surface for 
> file:///home/toliz/Videos/sin tel_trailer-480p.mp4 ERROR debug 
> information: gstvaapisink.c(1434): gst_vaapisink_show_frame_unlocked
>  (): 
> /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstVaapiSink:vaapisink 
> 0
> Reached end of play list.

You can run the pipeline with --gst-debug=vaapi*:6 to figure out what is failing.

My bet is that vaGetSurfaceBufferWl() is not implemented in radeon mesa backend.

> Can you explain me how to perf the pipeline and how to pinpoint that it is a
> driver issue?

you can start with the script gst-plot-timeline.py that comes in gstreamer source code. Also check this slides 

http://www.slideshare.net/LuisLopez235/improving-gstreamer-performance-on-large-pipelines-from-profiling-to-optimization
Comment 6 barz621 2016-09-07 12:15:30 UTC
Created attachment 334981 [details]
vaapi fail

This is with --gst-debug=vaapi*:6
Comment 7 Víctor Manuel Jáquez Leal 2016-09-07 12:22:28 UTC
(In reply to barz621 from comment #6)
> Created attachment 334981 [details]
> vaapi fail
> 
> This is with --gst-debug=vaapi*:6

Yep, it is what I expected:

0:00:00.558414290 [333m 5138[00m 0x7fc2ac14fe30 [37mDEBUG  [00m [00m               vaapi gstvaapiutils.c:53:vaapi_check_status:[00m vaGetSurfaceBufferWl(): the requested function is not implemented
Comment 8 barz621 2016-09-07 12:40:20 UTC
Ok. Since it is an implementation issue i just have to wait.

However i have a question. How can the choppy video i get when apps use gstreamer as a backend on X be fixed. Is there a way to force gstreamer to use vaapisink with a env var or it is something the toolkit has to take care of.
Comment 9 Víctor Manuel Jáquez Leal 2016-09-07 13:08:38 UTC
(In reply to barz621 from comment #8)
> Ok. Since it is an implementation issue i just have to wait.
> 
> However i have a question. How can the choppy video i get when apps use
> gstreamer as a backend on X be fixed. Is there a way to force gstreamer to
> use vaapisink with a env var or it is something the toolkit has to take care
> of.

I don't know if I understand you question correctly, but you can force vaapisink  when using playbin with the property "video-sink".
Comment 10 barz621 2016-09-07 13:35:21 UTC
Ok.As it seems EFL uses a custom sink and i have no idea how this works. 

https://git.enlightenment.org/core/efl.git/tree/src/modules/emotion/gstreamer1

So possibly no way to make it use vaaapi. :/

Thanks for the help.
Comment 11 Víctor Manuel Jáquez Leal 2016-09-07 13:47:38 UTC
(In reply to barz621 from comment #10)
> Ok.As it seems EFL uses a custom sink and i have no idea how this works. 
> 
> https://git.enlightenment.org/core/efl.git/tree/src/modules/emotion/
> gstreamer1
> 
> So possibly no way to make it use vaaapi. :/

Even less with mesa radeon backend. With intel's would be better.

> 
> Thanks for the help.

No problem.