GNOME Bugzilla – Bug 747902
sink: wayland: retain additional buffers after video rendering
Last modified: 2015-05-18 13:48:53 UTC
When playing http://samples.mplayerhq.hu/V-codecs/h264/NeroAVC.mp4 in wayland, using vaapisink there are some glitches when passing the mouse above the video. The following patch fixes it. The patch was posted originally in bug #705821
Created attachment 301614 [details] [review] sink: wayland: retain additional buffers after video rendering After wl_buffer is commited to Wayland server, it is kept using until next buffer is commited. We would retain 3 buffers after video rendering in media side: - one buffer for the one is used as texture in wayland compositing (front buffer) - one buffer for the one just committed (back buffer) - one buffer additional when wayland compositing is slower than media side Change-Id: I66ece1430a25a4864b6bd432e804a42af7fb7bcd Signed-off-by: Víctor Manuel Jáquez Leal <vjaquez@igalia.com>
Relevant discussion in bug #705821 (Gwenole Beauchesne from comment #26) > Review of attachment 259637 [details] [review] [review]: > > If the VA render mode is incorrectly set from the driver to match overlay or > textured mode, then this certainly has to be fixed on the driver side. Next, > if the gst_vaapi_window_wayland_sync() mechanism doesn't work properly, this > probably ought to be fixed there. We already keep one buffer in overlay, and > this should be enough. (In reply to Zhao, Halley from comment #30) > (In reply to comment #26) > this patch has few to do with overlay, but retains more video frame after it > is committed to wayland server. > in theory, one buffer seems not sufficient for overlay: the kept one buffer > can be treated as back buffer of overlay, we haven't ref the one for front > buffer of overlay yet.
Implementation details need to go into the Wayland specific renderer. Michael's patch is better here. We can reject this one, as it was initially. Thanks.
(In reply to Gwenole Beauchesne from comment #3) > Implementation details need to go into the Wayland specific renderer. > Michael's patch is better here. We can reject this one, as it was initially. > Thanks. I've a branch without this patch, but the ones in bug #747492 and bug #705821 and they doesn't fix the playback of: $ gst-play-1.0 http://samples.mplayerhq.hu/V-codecs/h264/NeroAVC.mp4 --videosink="vaapisink display=3" But adding this patch, it gets fixed. Though, I do agree that this issue is Wayland specific and shall not be done in vaapisink.
Afaik, this is because vaapisink is releasing the frame on wl_surface_frame... instead of wl_buffer_release as it should. The patch on bug #747492 may already have fixed it.
As comment #5 this behavior looks already fixed since the last patches in wayland backend.