[Bug 757933] When a pipeline is in GST_STATE_READY, "sync-message::need-context" is not emitted for GstGL.

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from ChangSeok Oh <changseok at gnome.org> ---
(In reply to Matthew Waters from comment #1)
> The need-context message is not sent because glimagesink doesn't need the GL
> context when only going back to READY.  
oh.. there is a miscommunication. I am not talking that the message does not
happen when PLAYING -> READY. When replaying i,e READY -> PLAYING, the message
is expected to happen if gst does not have a gl context.

> It keeps the application provided GL context until the state drops to NULL.
O.K. I think this is a root cause. You mean the given gl context should be
alive in READY state unless it goes back to null state, right?
As my investigation, when webkit received the GST_MESSAGE_EOS and the state
changed from PLAYING to READY, the glimagesink already lost the provided gl
context. so when replaying(READY -> PLAYING), the sink had null for gl context
so it created its own one. Let me look into this, who destroys the gl context
even in READY and actually when it happens.

>  Currently the other requirement [0] for the window to never appear is that you must have a connection to the "client-draw" signal on glimagesink (which won't disappear on state changes).
Yes, the connection is established here.
https://github.com/ryumiel/webkit-experimental/blob/threaded-compositor-wip/Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp#L701

> 
> If webkit changes the GL context it needs to set on the gstreamer pipeline,
> it needs to 1. call gst_element_set_context explicitly or 2. Drop down to
> NULL.
Good to know. However, I don't think webkit changes the gl context for video
when replaying.

Thanks.

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