GNOME Bugzilla – Bug 734606
gst_video_frame_map_id: assertion 'GST_IS_BUFFER (buffer)' failed and a memory usage (leak?) issue
Last modified: 2014-08-13 15:46:06 UTC
Created attachment 283075 [details] test program I'm trying to get video frames as raw RGB data. Method 1 (using gdkpixbufsink) works but when the the pixel data is being read in any way the program eats about 400MB RAM per second! So after processing a few minutes of video the memory is full and the program SEGFAULTs. Method 2 (using appsink callbacks) doesn't work either. Decoding PNG's did work that way but if I provide a video file as input source the program quits after a few video frames with this messages: -------------------------------------------------------------------------------- ** (test:4514): CRITICAL **: gst_video_frame_map_id: assertion 'GST_IS_BUFFER (buffer)' failed Warning: could not copy metadata Warning: Internal GStreamer error: code not implemented. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. (test:4514): GStreamer-CRITICAL **: gst_pad_push: assertion 'GST_IS_BUFFER (buffer)' failed Error: Internal data stream error. -------------------------------------------------------------------------------- Maybe I'm doing something wrong? Please take a look at the program attached. You can switch between the two issues by commenting in/out the "#define BUG2" line at the top of the file. Please note the fixed video format of the input file and edit it if your video input source has a different format. Tested on Windows with gstreamer 1.4.0 and Linux gstreamer 1.2.0 with equal results.
Don't unref the buffer that you get with gst_sample_get_buffer(). You don't own the reference to it.
Oops, thank you very much!!! Now it works. Seems I misunderstood the API docs. Did you also take a look at Method 1 (gdkpixbufsink)?
gdkpixbufsink should work fine too. You have to check though if it posts messages with the pixbuf on the pipeline bus for every single frame. By default it does that (post-messages=true), so perhaps you want to disable that if you do more than just preroll the pipeline. Instead, just get a snapshot GdkPixbuf via the "pixbuf" property when you need a snapshot (unless you actually do want every single frame, but in that case an appsink with RGB caps might be better).
gdkpixbufsink works fine too, the problem is somewhere in that loop with the C++ iterators. If you comment that out but keep all the other code still there (including filling your image class with the gdkpixbuf data) there is no leak. I would say this is not a bug in GStreamer but elsewhere.
(In reply to comment #3 by Tim-Philipp Müller) I want every single frame so appsink is the better choice as you say. gdkpixbufsink was my first attempt and I wondered why there's so much memory usage. (In reply to comment #4 by Sebastian Dröge (slomo)) Yes I thought that too but if you do it the other way around (comment out the gstreamer part) there's also no memory leak. The problem occurs only in combination. That's a really strange behaviour!(In reply to comment #3)