GNOME Bugzilla – Bug 743334
videoaggregator crash when work with filesrc
Last modified: 2015-01-26 09:26:04 UTC
gst-plugins-bad version tested : d825239b(lastest) 1200f2(earlier, also crash) videotestsrc ! glvideomixer ! glimagesink works OK but load raw frame through filesrc crash gstvideoaggregator dump file : gst-launch-1.0 videotestsrc num-buffers=100 ! video/x-raw,format=YV12,width=320,height=240 ! filesink location=320_240.yv12 load through filesrc crash : gst-launch-1.0 filesrc location=320_240.yv12 blocksize=115200 do-timestamp=1 ! video/x-raw,format=YV12,width=320,height=240,framerate=1/1 ! glvideomixer ! glimagesink (filesrc ! glimagesink works, only crash when glvideomixer inside) crash at gst_videoaggregator_fill_queues line 969 seems the buf which will be unref already has refcount=0 {mini_object = {type = 0, refcount = 0, lockstate = -1, flags = 4294967295, copy = 0xffffffff, dispose = 0xffffffff, free = 0xffffffff, n_qdata = 4294967295, qdata = 0xffffffff}, pool = 0xffffffff, pts = 18446744073709551615, dts = 18446744073709551615, duration = 18446744073709551615, offset = 18446744073709551615, offset_end = 18446744073709551615} backtrace as gst_mini_object_unref (mini_object=0x96a4e80) at ../../gst/gstminiobject.c:446
+ Trace 234573
What happens if you put a videoparse in between filesrc and glvideomixer ? i.e filesrc ! videoparse format=yv12 width=320 height=240 ! glvideomixer ... Also, does the same thing happen with compositor? And could you attach a small sample file to test with please.
Created attachment 295406 [details] vidotestsrc generated 320x240 yv12 raw 1 frame (In reply to comment #1) > What happens if you put a videoparse in between filesrc and glvideomixer ? > > i.e filesrc ! videoparse format=yv12 width=320 height=240 ! glvideomixer ... > I run as gst-launch-1.0 filesrc location=320_240.yv12 blocksize=115200 do-timestamp=1 ! videoparse format=yv12 width=320 height=240 framerate=100/1 ! glvideomixer ! glimagesink interesting, it didn't crash, does this mean this is problem in filesrc ? gstreamer version I tested : 9494b69 and ee3db74, both videoparse inside works, both crash when videoparse not inside > Also, does the same thing happen with compositor? yes, crash at same line ,also tested with fakesink > > And could you attach a small sample file to test with please. attachment is the raw frame data created by videotestsrc, but I think any binary can be used as input (like /dev/urandom )
(In reply to comment #2) > Created an attachment (id=295406) [details] > vidotestsrc generated 320x240 yv12 raw 1 frame > > (In reply to comment #1) > > What happens if you put a videoparse in between filesrc and glvideomixer ? > > > > i.e filesrc ! videoparse format=yv12 width=320 height=240 ! glvideomixer ... > > > > I run as > > gst-launch-1.0 filesrc location=320_240.yv12 blocksize=115200 do-timestamp=1 ! > videoparse format=yv12 width=320 height=240 framerate=100/1 ! glvideomixer ! > glimagesink > > interesting, it didn't crash, does this mean this is problem in filesrc ? > > gstreamer version I tested : 9494b69 and ee3db74, > both videoparse inside works, > both crash when videoparse not inside No, it means that filesrc is not providing the size of buffer that compositor/glvideomixer/'any other video element' wants. Which is what videoparse is fixing up for you. The convention with GStreamer is one buffer == one video frame which may have not been true by the buffers output by filesrc. Marking as invalid for this reason.
The problem is with your pipeline. You need to use a videoparser in this case. However, glvideomixer should also not crash, but error out! commit 21168dd1996c5c668ec4e7a709a6d2991455b7c8 Author: Tim-Philipp Müller <tim@centricular.com> Date: Mon Jan 26 09:22:23 2015 +0000 videoaggregator: fix crash when receiving buffer without timestamps Unset out buffer in clip function when we unref the buffer to be clipped, otherwise aggregator will continue to use the already- freed buffer. Fixes crash when buffers without timestamps are being fed to aggregator. Partly because aggregator ignores the error flow return. https://bugzilla.gnome.org/show_bug.cgi?id=743334