GNOME Bugzilla – Bug 724816
GstGLContext : Memory leak
Last modified: 2016-06-10 07:21:06 UTC
The GstGlContext isn't released correctly, and this behavior can cause multiple bugs, and of course memory saturation. Note : The following has been tested with the SW decoder and it worked. Attached : a test program. video sample : http://www.auby.no/files/video_tests/h264_1080p_hp_4.1_10mbps_dts_unstyled_subs_monsters.mkv Mailing list discussion : http://gstreamer-devel.966125.n4.nabble.com/Multiple-pipeline-with-OpenGL-and-vaapi-elements-td4665379.html#a4665399
commit 41de8900b8323696d0b434096d56eab0321d2256 Author: Matthew Waters <ystreet00@gmail.com> Date: Fri Feb 21 15:25:22 2014 +1100 filter: free our data plugs some memory leaks https://bugzilla.gnome.org/show_bug.cgi?id=724816
The following cases aren't solved : gst-launch-1.0 gltestsrc ! glcolorscale ! glimagesink -e gst-launch-1.0 filesrc location=file ! matroskademux ! h264parse ! vaapidecode ! glcolorscale ! videoconvert ! xvimagesink -e The following case is solved : gst-launch-1.0 videotestsrc ! glcolorscale ! videoconvert ! xvimagesink (ans subcase : gst-launch-1.0 filesrc location=file ! matroskademux ! h264parse ! avdec_h264 ! glcolorscale ! videoconvert ! xvimagesink -e )
Additional information : The following pipeline filesrc location=file ! matroskademux ! h264parse ! avdec_h264 ! glcolorscale ! videoconvert ! xvimagesink -e still generate the segmentation fault : Maximum number of clients reached. Test application : http://pastebin.com/H6cZqUpp Observations : As said previously, the GstGlContext is CORRECTLY released in this case, but the display may be still open after this release.
This fixes the gltestsrc ! glcolorscale ! glimagesink case for me (and all subcases) commit 7ab354d645251d1a51c967979c4a8f8bfdbdd93f Author: Matthew Waters <ystreet00@gmail.com> Date: Sun Feb 23 01:32:23 2014 +1100 fixup a memory leak of the context in the GLTextureUploadMeta path gst_structure_get returns a reference to the object and we asked for another with gst_object_replace. https://bugzilla.gnome.org/show_bug.cgi?id=724816 As for the vaapidecode ! glcolorscale case, See https://bugzilla.gnome.org/show_bug.cgi?id=724957 I haven't looked at the display not being released yet.
Great job, all cases are solved on my side too. I'm closing this bug, and created a new one for the Display hanlde (just to be more clear).
Hi, I'm experiencing this again with GStreamer 1.8.1. I have an application where I change between IP camera streams using the following pipeline: gst-launch-1.0 rtspsrc location=<> latency=0 ! rtph264depay ! h264parse ! queue ! vaapidecode ! glupload ! glcolorconvert ! gltransformation ! glimagesink Everything works great, except that memory accumulates after each camera change and after a while I get "Maximum number of clients reached". I cannot see the change you have done previously, of course this is an old thread and the GL stuff has changed since. Any ideas? Please let me know if you need additional information. I'm using Qt 5.5 for my application and atm I'm also using QtGStreamer 1.2. for pipeline construction (need to opt out of that, just haven't done that yet). Thanks!
This is an old bug, please open a new bug with your issue.