GNOME Bugzilla – Bug 793224
gl: context persistence issue
Last modified: 2018-02-09 08:59:34 UTC
I have an issue where my custom playbin video sink (glupload ! glcolorconvert ! appsink) loses its context when the video chain is removed from playsink while the whole pipeline goes to READY. So rendering works fine on first run, the app handles the need-context message fine. On second run the gl elements try a context query, that fails. Then they try to post a need-context message but they have no bus associated yet, so that fails. Then a new display is created from gst_gl_ensure_element_data() and it's for the wrong platform (egl vs wayland). But even with all those failures, somehow rendering works if the pipeline goes to PLAYING again. On third run rendering fails. As a workaround I can manually set the context on the video sink before going to PAUSED on second and following runs but shouldn't the gl context be automatically reused from the persistent element context?
(In reply to Philippe Normand from comment #0) > I have an issue where my custom playbin video sink (glupload ! > glcolorconvert ! appsink) loses its context when the video chain is removed > from playsink while the whole pipeline goes to READY. > > So rendering works fine on first run, the app handles the need-context > message fine. On second run the gl elements try a context query, that fails. > Then they try to post a need-context message but they have no bus associated > yet, so that fails. Then a new display is created from > gst_gl_ensure_element_data() and it's for the wrong platform (egl vs > wayland). wayland only works with egl. Do you mean glx vs egl or x11 vs wayland ? There's also an issue of terminology. When you say GL context, do you mean the GStreamer GL context created internally or an application provided GL context (they are not the same thing). I think the key thing here is that 'there is not bus associated yet' which sounds problematic. Is the lack of a bus a playsink/playbin or an application issue. > But even with all those failures, somehow rendering works if the pipeline > goes to PLAYING again. 'somehow'? > On third run rendering fails. How exactly? > As a workaround I can manually set the context on the video sink before > going to PAUSED on second and following runs but shouldn't the gl context be > automatically reused from the persistent element context? The GL context is not a persistent resource so will be destroyed and recreated on pipeline shutdown/restart which is also true if playsink sets the video sink to NULL. GstContext's are also removed from elements when set they are set to NULL (or READY). I can't remember which. I think in order to debug this in any sort of capacity, some logs are needed. e.g. GST_DEBUG=3,gl*:7,*CONTEXT*:7
(In reply to Matthew Waters (ystreet00) from comment #1) > (In reply to Philippe Normand from comment #0) > > I have an issue where my custom playbin video sink (glupload ! > > glcolorconvert ! appsink) loses its context when the video chain is removed > > from playsink while the whole pipeline goes to READY. > > > > So rendering works fine on first run, the app handles the need-context > > message fine. On second run the gl elements try a context query, that fails. > > Then they try to post a need-context message but they have no bus associated > > yet, so that fails. Then a new display is created from > > gst_gl_ensure_element_data() and it's for the wrong platform (egl vs > > wayland). > > wayland only works with egl. Do you mean glx vs egl or x11 vs wayland ? > The latter > There's also an issue of terminology. When you say GL context, do you mean > the GStreamer GL context created internally or an application provided GL > context (they are not the same thing). > The application provided GL context > I think the key thing here is that 'there is not bus associated yet' which > sounds problematic. Is the lack of a bus a playsink/playbin or an > application issue. > I don't think it's an application issue ;) Upon EOS I sent the playbin state to READY and to PLAYING again. > > But even with all those failures, somehow rendering works if the pipeline > > goes to PLAYING again. > > 'somehow'? > It's strange because the GL app context remains valid for two runs and not more, I don't have an explanation for this yet. > > On third run rendering fails. > > How exactly? > I can see a scrambled frame for half a second and then the rendering area goes black although the pipeline runs until EOS. > > As a workaround I can manually set the context on the video sink before > > going to PAUSED on second and following runs but shouldn't the gl context be > > automatically reused from the persistent element context? > > The GL context is not a persistent resource so will be destroyed and > recreated on pipeline shutdown/restart which is also true if playsink sets > the video sink to NULL. Ok so the GL app context should be requested again at restart then? > GstContext's are also removed from elements when > set they are set to NULL (or READY). I can't remember which. > Non-persitent GstContexts are removed when the element goes to NULL. > I think in order to debug this in any sort of capacity, some logs are > needed. e.g. GST_DEBUG=3,gl*:7,*CONTEXT*:7 Ok I'm attaching a log file, the video played is 6 seconds long and 3 playback attempts are made.
Created attachment 367978 [details] bzip2 log file
With va-api enabled the second run has scrambled rendering, I can upload a screencast if needed.
This sounds like a dupe of bug 757933
*** This bug has been marked as a duplicate of bug 757933 ***