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 747902 - sink: wayland: retain additional buffers after video rendering
sink: wayland: retain additional buffers after video rendering
Status: RESOLVED OBSOLETE
Product: gstreamer-vaapi
Classification: Other
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
Depends on:
Blocks: 748634
 
 
Reported: 2015-04-15 10:42 UTC by Víctor Manuel Jáquez Leal
Modified: 2015-05-18 13:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sink: wayland: retain additional buffers after video rendering (3.70 KB, patch)
2015-04-15 10:43 UTC, Víctor Manuel Jáquez Leal
none Details | Review

Description Víctor Manuel Jáquez Leal 2015-04-15 10:42:59 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
Comment 1 Víctor Manuel Jáquez Leal 2015-04-15 10:43:03 UTC
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>
Comment 2 Víctor Manuel Jáquez Leal 2015-04-15 10:46:18 UTC
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.
Comment 3 Gwenole Beauchesne 2015-04-17 09:26:31 UTC
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.
Comment 4 Víctor Manuel Jáquez Leal 2015-04-17 10:31:24 UTC
(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.
Comment 5 Olivier Crête 2015-04-17 15:32:15 UTC
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.
Comment 6 Víctor Manuel Jáquez Leal 2015-05-18 13:48:53 UTC
As comment #5 this behavior looks already fixed since the last patches in wayland backend.