[Bug 748405] glimagesink: balance change_state bufferpool/other_context ref/unref

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from Matthieu Bouron <matthieu.bouron at collabora.com> ---
(In reply to Matthew Waters from comment #7)
> (In reply to Matthieu Bouron from comment #4)
> > There is another issue with the following pipeline:
> > 
> > videotestsrc ! glupload ! glcolorconvert ! gltransformation ! insertbin !
> > glimagesink
> > 
> > Adding an identity element to insertbin and then going to the READY state is
> > causing the original glwindow not to be destroyed and the glcontext is not
> > deactivated/freed.
> > The log shows that all glbufferpools have been deactivated.
> 
> Going to READY from what state?  >=PAUSED or NULL?
> Have all the pools been freed?

The scenario is having the pipeline PLAYING, then adding an identity element to
the insertbin. At this point everything work. then setting the pipeline to
READY does not destroy the glwindow (as the gstglcontext is held).

The issue is triggered by the original patch i linked to the bug. Having the
pool in glimagesink freed in PAUSED=>READY + othercontext freed in
PAUSE=>READY.

[...]
> 
> Does it occur without glimagesink?
> Does it occur without 'glupload ! glcolorconvert ! gltransformation'?

I haven't tested without glimagesink and the minimal scenario to trigger the
bug is having glupload ! glcolorconvert ! gltransformation. If gltransformation
is not in the pipeline the issue is not there.

> By 'there' you mean on screen visible or just sticking around as a result of
> some ref still being held?

It's a visible window sticking around as a result of some ref still being held.
The original gstglcontext is not unreffed (ie: the log does not show "activate:
0"). All the gl pools are deactivated.

(In reply to Matthew Waters from comment #8)
> Created attachment 302412 [details] [review]
> glimagesink: unref the pool at the correct time
> 
> The pool is currently unreffed in GstBaseSink::stop () which is called on
> READY->NULL so the context is still be alive through the pool when changing
> down to READY.

Is there a difference with the original patch I linked to the bug ?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.