GNOME Bugzilla – Bug 762620
Playback stutters with avdec_h264 via glimagesink on OSX (gst_gl_context_is_shared() returning FALSE)
Last modified: 2016-02-26 14:05:20 UTC
Created attachment 322251 [details] *:6 debug logs When launching the following pipeline: gst-launch-1.0 filesrc location=/PATH/TO/claudia_aac.mov ! qtdemux name=mux mux.video_0 ! avdec_h264 ! videoconvert ! glupload ! glimagesink we get a few corrupt frames, and then playback stutters heavily. Debug logs are attached, once for gl*:6, and once for *:6. The same pipeline would play back smoothly using vtdec_hw instead of avdec_h264 (also not showing corrupt frames in the beginning) File to play back: https://www.dropbox.com/s/gwgzsx8t5bvrnyi/claudia_h264.mov?dl=0
Created attachment 322252 [details] gl*:6 logs
Try this: gst-launch-1.0 filesrc location=/PATH/TO/claudia_aac.mov ! qtdemux name=mux mux.video_0 ! avdec_h264 output-corrupt=false ! videoconvert ! queue max-size-buffers=2 ! glupload ! glimagesink Adding a queue means the decoder isn't stuck waiting for frame display before it can start decoding the next frame.
Thanks, but your modified launch line yields exactly the same results: a few corrupted frames, and stuttering, with this morning's build. I'll try to bisect gst-plugins-bad today and provide more information then.
I managed to bisect gst-plugins-bad: 11fb4fff80b63b9d67a731d4bb238b6c0a29d774 is the first bad commit commit 11fb4fff80b63b9d67a731d4bb238b6c0a29d774 Author: Matthew Waters <matthew@centricular.com> Date: Thu Jan 7 14:08:39 2016 +1100 glsyncmeta: only flush with a shared context The wait code will flush for us for single context pipelines.
Thanks! commit abec124f6946e9fe0635dc53d729b3c2d92be9a9 Author: Matthew Waters <matthew@centricular.com> Date: Fri Feb 26 08:34:11 2016 +1100 glcontext: add a method to add a context to another share group Intended for use with wrapped contexts that are created shared with gst's gl contexts in order to manage the internal sharegroup state correctly. e.g. with caopengllayer (which is used in glimagesink and caopengllayersink on OS X), we create a CGL context from the gst context and the sharing state was not being correctly set on either GL context and gst_gl_context_is_shared() was always returning FALSE. With 11fb4fff80b63b9d67a731d4bb238b6c0a29d774 only flushing with multiple shared contexts, the required flush was not occuring causing screen corruption or stuttering. Note: this didn't affect GST_GL_API=opengl pipelines https://bugzilla.gnome.org/show_bug.cgi?id=762620
Thanks, Matthew!