GNOME Bugzilla – Bug 162905
SEGV when using ffenc_msmpeg4
Last modified: 2005-01-17 13:36:25 UTC
A simple program that triggers the bug will be attached.. I couldn't so far find a reliable way to reproduce the SEGV, except the test program. Using gst-launch, I couldn't reproduce the problem, either. The v4l device used is a Logitech Sphere, driven by Luc Saillards pwc.ko.
Created attachment 35415 [details] test case, gdb and valgrind logs
Please attach the logs as simple text files, file-roller can't open it or can't detect the type.
Created attachment 35614 [details] GDB backtrace
Created attachment 35615 [details] valgrind log
Created attachment 35616 [details] Sample application to trigger the bug
I fixed a possible crasher in v4lsrc related to this, please retry with CVS. Also, I'd like to know the caps set between elements (filtered caps doesn't always work). You can use notify::caps on GstPad objects for this.
Created attachment 35621 [details] Debug log with --gst-debug-level=5 --gst-debug-no-color Retried the application with current CVS gst-plugins and gst-ffmpeg (and gstreamer CVS), and it is still there. Sorry for sending such a big thing, at the moment I'm not in a position to filter out unwanted output :/ I'll try to come up with a test case that does not involve v4lsrc though - that should make it easier to reproduce the problem.
gst-launch -v videotestsrc ! video/x-raw-yuv,width=\(int\)320,height=\(int\)240,framerate=\(double\)10 ! videoscale ! video/x-raw-yuv,width=\(int\)640,height=\(int\)480 ! ffmpegcolorspace ! ffenc_msmpeg4 ! asfmux ! filesink location=test.asf This produces the same segfault for me. If I take the videoscale, the filtered caps and one ffmpegcolorspace out, it does not segfault in ffenc_msmpeg4, but does at the end, when I press Ctrl-c (that's prolly a different bug).
Reducing size also makes it work. Seems like an overflow in ffmpeg. Also try increasing the buffer-size property on ffenc_msmpeg4.
Tried, didn't work. Set it to everything from the default to 20 times the default, and in all cases I got a SEGV.
Funny, because if you set s/640/320/ and s/480/240/, it works fine. I'll need to dig closer into this...
I'm having the same problem.. Other testcases: 1) videotestsrc ! video/x-raw-yuv,width=\(int\)640,height=\(int\)480,framerate=\(double\)10 ! ffenc_msmpeg4 ! identity loop-based=true ! filesink location="file.avi" 2) videotestsrc ! video/x-raw-yuv,width=\(int\)640,height=\(int\)480,framerate=\(double\)10 ! ffenc_msmpeg4 ! identity loop-based=true ! fakesink 3) videotestsrc ! video/x-raw-yuv,width=\(int\)640,height=\(int\)480,framerate=\(double\)10 ! ffenc_msmpeg4 ! identity loop-based=false ! filesink location="file.avi" 4) videotestsrc ! video/x-raw-yuv,width=\(int\)640,height=\(int\)480,framerate=\(double\)10 ! ffenc_msmpeg4 ! identity loop-based=false ! fakesink (1) segfaults (2) works (3) works (4) works
I've found that adding a gst_buffer_ref(outbuf) to gstffmpegenc.c:..chain_video fixes the problem.. but i don't think it's a good fix :) I'm not a gst guru so i hope someone can help here.. I've also tried with different encoders: ffenc_mpeg4 segfaults ffenc_msmpeg4 segfaults ffenc_msmpeg4v1 segfaults ffenc_msmpeg4v2 segfaults ffenc_h263 don't know (there's a different segfault here) ffenc_h263p works ffenc_mjpeg works ffenc_wmv1 segfaults ffenc_wmv2 segfaults ffenc_ffv1 don't know (there's a different segfault here) ffenc_h261 works ffenc_flv segfaults ffenc_mpeg1video works ffenc_mpeg2video works All the segfaults are on the second call of the chain function. Maybe they want to mantain a copy of the buffer to do motion estimation?
How about if you keep a reference to the frame, like you're doing with gst_buffer_ref(), and release that on the next call to chain()? It's kinda hacky but would work...
I've done something different and it seems to work.. Patch, test case, valgrind output attached.
Created attachment 36087 [details] [review] use a single cache buffer to do media encoding
Created attachment 36088 [details] test case
Created attachment 36092 [details] valgrind output
There are two memory leaks detected by valgrind but i don't think this is my ffenc_ fault. There are also a lot of errors in MPV_common_end :/ I've tried ffenc_msmpeg4[v1,2,3] and ffenc_mpeg4 and now they work!
The memleaks are inside avimux, nice catch - fixed in CVS. As for the patch, you use gst_buffer_copy(), can you try gst_buffer_ref() instead? That should prevent unneeded data copying. The free errors in libavcodec are known, I don't really know how bad they are or what the exact problem is. We should fix that at some point, but it's not bad, I think.
changed patch as requested.
Created attachment 36094 [details] [review] don't copy buffers, just create, ref, unref
Done, thnx.
I still have the segfault with the gst-launch pipeline I postead earlier, even after updating to gst-ffmpeg CVS (verified that the fix is in there). Backtrace looks the same as before.
I don't think any of the above patch is usefull :/ I'm going to make them obsolete.. It seems that removing "ffmpegenc->context->flags |= CODEC_FLAG_EMU_EDGE;" make ffenc works!! wtf is CODEC_FLAG_EMU_EDGE ?? is it required? algernon, can you test it ? tnx!
This seems to fix the problem for me, at least, the gst-launch pipelines - the segfault disappears. (There are other problems now, with v4lsrc, but that's probably a different bug)
EMU_EDGE is, in the decoding process, used to emulate frame boundaries. Without it, we need blocks around the actual image for border-block neighbour-block processing, which makes the image 2x16 pixels larger (with blackness). I don't know what its function is in encoding. Can you give a valgrind log of a small gst-launch pipeline to make sure there's no more invalid memory accesses?
Created attachment 36134 [details] valgrind log This is a valgrind log of a commandline that segfaulted on me earlier. Using gst-ffmpeg CVS (sans the latest revision of gstffmpegenc.c; with the EDGE stuff commented out).
Did it myself too, valgrind is 100% clean here (w/o asfmux). Marking fixed.