When a pipeline is in GST_STATE_READY, "sync-message::need-context" is not emitted for GstGL.
Submitted by ChangSeok Oh
Link to original bug (#757933)
Description
This issue is found while testing yoon's experimental webkit branch implementing GstGL support along with threaded compositor in webkitgtk+.
https://github.com/ryumiel/webkit-experimental/tree/threaded-compositor-wip
It works fine in overall, but there is some issues related with gstreamer.
How to reproduce.
- Play a video and watch it completely.
- Replay it in 60 secs.
When replaying a video, an unknown xwindow shows up of which name is "OpenGL renderer". I have investigated it for a while, I found it was created by gstreamer if no gl context is passed from the outside to the gstreamer at beginning of the gst pipeline.
Of course webkit create a GstGL context and passes it to gst when listening the "sync-message::need-context" signal from gstreamer.
The problem is that the singal is only emitted when the pipeline is in GST_STATE_NULL, but not in GST_STATE_READY. I don't know why.
WebKit changes the pipeline state to GST_STATE_READY when receiving GST_MESSAGE_EOS, and then changes it again to GST_STATE_NULL after 60 secs. As I heard, this is due to better performance for replaying video.
Anyway if replaying video is triggered in the 60secs, the need-context signal is not emitted so webkit can not create and pass a GstGL context for the new gst pipeline and then it eventually leads gstreamer to create its own xwindow along with a gl context. Replaying after 60secs is no problem.
So I think the best fix for this issue is that gstreamer emits "sync-message::need-context" even in GST_STATE_READY so that it gives an application a chance to create a gstgl context.
Any idea?
I'trying to make a test case for you though, I'm not a gst expert. So don't believe me. :P (Of course, I'll provide you one if it is ready.)