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 738069 - waylandsink: avoid render twice the same buffer
waylandsink: avoid render twice the same buffer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.3
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-10-07 08:47 UTC by Benjamin Gaignard
Modified: 2014-11-08 14:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
waylandsink: do not render twice the same buffer (1.31 KB, patch)
2014-10-07 08:47 UTC, Benjamin Gaignard
none Details | Review

Description Benjamin Gaignard 2014-10-07 08:47:37 UTC
Created attachment 287933 [details] [review]
waylandsink: do not render twice the same buffer

Do not try to render a buffer that is already being rendered.

This happens typically during the initial rendering stage as the first
buffer is rendered twice: first by preroll(), then by render().
This commit avoids this assertion failure:
  CRITICAL: gst_wayland_compositor_acquire_buffer: assertion
  'meta->used_by_compositor == FALSE' failed
Comment 1 Nicolas Dufresne (ndufresne) 2014-10-07 15:04:25 UTC
Since the first time I heard about this, I still think BaseSink and/or VideoSink should not do that. Want to propose a fix on the base class instead ?
Comment 2 Benjamin Gaignard 2014-10-07 15:30:57 UTC
Putting that in BaseSink or VideoSink worry me... maybe some sinks could need/accept to receive the same buffer twice ? I think that could have unwanted side effects.

In this case is really needed to not send the same buffer twice to the Wayland compositor.
Comment 3 Tim-Philipp Müller 2014-10-07 15:36:20 UTC
It would have to be strictly on an opt-in basis (not to get the preroll buffer again in render).
Comment 4 Nicolas Dufresne (ndufresne) 2014-10-07 16:08:32 UTC
(In reply to comment #3)
> It would have to be strictly on an opt-in basis (not to get the preroll buffer
> again in render).

I never got the rational of doing this, maybe there is a good reason ?
Comment 5 Tim-Philipp Müller 2014-10-07 16:24:23 UTC
The default behaviour for this can't just be changed, so it doesn't really matter ;)

It makes sense for some scenarios / sinks / APIs and less for others. It's easy enough to work around for APIs that don't deal with this well.
Comment 6 George Kiagiadakis 2014-10-11 15:40:43 UTC
I think it makes sense to work it around in waylandsink, so I have committed it. I knew about this bug and I meant to fix it myself, I just gave it very low priority because it was harmless.

commit 23bb5f53196773139e138a67a4ed2ee2dedc9aa9
Author: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Date:   Tue Oct 7 10:37:33 2014 +0200

    waylandsink: do not render twice the same buffer

    Do not try to render a buffer that is already being rendered.
    This happens typically during the initial rendering stage as the first
    buffer is rendered twice: first by preroll(), then by render().
    This commit avoids this assertion failure:
      CRITICAL: gst_wayland_compositor_acquire_buffer: assertion
      'meta->used_by_compositor == FALSE' failed

    https://bugzilla.gnome.org/show_bug.cgi?id=738069

    Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
    Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>