GNOME Bugzilla – Bug 163159
[videobox] plugin segfault (gst-plugin 0.8.7)
Last modified: 2005-01-19 17:15:14 UTC
Summary: videobox plugin segfault in gst-plugin 0.8.7 Name: David Wm. Parr e-mail: dparr@inspireworksinc.com Date: 01/05/2005 ----------------------------------------------------------- Defect Description ----------------------------------------------------------- The 'videobox' plugin is causing a segmentation fault using the following gstreamer/plugin versions (see below). It worked correctly in the previous versions (also listed below) I did compile gstreamer and plugins with compiler switches '-O0 -g' to disable optimizations and enable debug information Note that when segmentation fault is trapped in gdb, I am able to see diagnal lines (positive slope) streaked across the image of the same width (10) and color (1=green) that I had specified for the videobox plugin. I appologize if the information below is incomplete or too verbose; this is the first defect that I have submitted for any linux project, but have been developing software for years; I would greatly appreciate any suggestions to increase the clarity of the defect, as I have identified many other segmentation faults in other plugins that I would also like to submit, but am testing the waters (and the process) here. Also, how can I attach files to the bug report instead of having to put supplemental materials inline in the description? Example: I have a trace file the following command (but did not send as don't know how to attach to defect) gst-launch --gst-debug-level=5 --gst-debug-no-color ----------------------------------------------------------- Current Versions (causes segmentation fault; built from source) ----------------------------------------------------------- gstreamer-0.8.8 gst-ffmpeg-0.8.3 gst-plugins-0.8.7 ----------------------------------------------------------- Previous Versions (videobox worked correctly; built from source) ----------------------------------------------------------- gstreamer-0.8.7 gst-plugins-0.8.6 gst-ffmpeg-0.8.2 ----------------------------------------------------------- Platform: Linux (Mandrake 10.1 distribution) Computer: Intel x86 ----------------------------------------------------------- ----------------------------------------------------------- Sample command line ----------------------------------------------------------- gst-launch filesrc location=MOV00053.MPG ! \ mpegdemux name=demux \ demux.video_00! \ mpeg2dec ! \ videobox left=-10 right=-10 top=-10 bottom=-10 fill=1 ! \ ffcolorspace ! \ ximagesink ----------------------------------------------------------- Attached files: videobox.segfault.debug.trace.txt - generated using gst-launch options '--gst-debug-level=5 --gst-debug-no-color' on above sample command line videobox.segfault.gdb.back.trace.txt - gdb backtrace; never have done this before; got the trace, but missing most of the symbols; will redo if you have suggestions. Compiled with '-g -O0', added most of the source file directories to the gdb command line ----------------------------------------------------------- ----------------------------------------------------------- Command line used to obtain gdb stack trace (run from directory /home/dparr/gst/gstreamer-0.8.8/tools) ----------------------------------------------------------- gdb --directory /home/dparr/gst/gstreamer-0.8.8/gst \ --directory /home/dparr/gst/gstreamer-0.8.8/gst/autoplug \ --directory /home/dparr/gst/gstreamer-0.8.8/gst/elements \ --directory /home/dparr/gst/gstreamer-0.8.8/gst/indexers \ --directory /home/dparr/gst/gstreamer-0.8.8/gst/parse \ --directory /home/dparr/gst/gstreamer-0.8.8/gst/schedulers \ --directory /home/dparr/gst/gstreamer-0.8.8/gst/registries \ --directory /home/dparr/gst/gstreamer-0.8.8/libs/gst/bytestream \ --directory /home/dparr/gst/gstreamer-0.8.8/libs/gst/control \ --directory /home/dparr/gst/gstreamer-0.8.8/libs/gst/dataprotocol \ --directory /home/dparr/gst/gstreamer-0.8.8/libs/gst/getbits \ --directory /home/dparr/gst/gstreamer-0.8.8/tools \ --directory /home/dparr/gst/gst-plugins-0.8.7/gst/videobox \ --args \ ./gst-launch filesrc location=~/media.samples/MOV00053.MPG ! \ mpegdemux name=demux \ demux.video_00! \ mpeg2dec ! \ videobox left=-10 right=-10 top=-10 bottom=-10 fill=1 ! \ ffcolorspace ! \ ximagesink ----------------------------------------------------- GDB BACKTRACE ----------------------------------------------------- (gdb) r Starting program: /home/dparr/gst/gstreamer-0.8.8/tools/gst-launch filesrc location=/home/dparr/media.samples/MOV00053.MPG \! mpegdemux name=demux demux.video_00\! mpeg2dec \! videobox left=-10 right=-10 top=-10 bottom=-10 fill=1 \! ffcolorspace \! ximagesink Detaching after fork from child process 23843. Detaching after fork from child process 23845. Detaching after fork from child process 23848. Detaching after fork from child process 23851. Detaching after fork from child process 23852. RUNNING pipeline ... Program received signal SIGSEGV, Segmentation fault. 0x4063ade5 in ?? () (gdb) i threads (gdb) bt
+ Trace 54209
Created attachment 35573 [details] gst debug trace of videobox segfault
See referenced video file used to demonstrate segmentation fault (MOV00053.MPG) at http://www.inspireworksinc.com/public/dparr/gst-defects/163159/. This is a home movie (I don't have many sample videos to work with yet).
Regarding stack trace (segmentation fault still exists - additional details below): it turned out (as Benjamin Otte suggested), that I was debugging ./gst-launch from my build directory instead of ./.libs/lt-gst-launch-0.8. After I made that change, the stack trace came together. The following was the back trace from debugging './tools/.libs/lt-gst-launch-0.8' off of my build directory. The segmentation fault occurred on the second video buffer in the ffmpeg avcodec code within ffcolorspace plugin. I am not familiar with whats going on here, but my impression is that the media type 'video/x-raw-yuv' (videobox src) is being converted to 'video/x-raw-rgb' (ximagesink sink). As I assume that this is a common conversion, I would guess (and that's all that it is) that the problem would be in farther upstream in the pipeline (videobox plugin or gstreamer main code). (gdb) r Starting program: /home/dparr/gst/gstreamer-0.8.8/tools/.libs/lt-gst-launch-0.8 filesrc location=/home/dparr/media.samples/MOV00053.MPG \! mpegdemux name=demux demux.video_00\! mpeg2dec \! videobox left=-10 right=-10 top=-10 bottom=-10 fill=1 \! ffcolorspace \! ximagesink [Thread debugging using libthread_db enabled] [New Thread 1078454208 (LWP 18665)] RUNNING pipeline ... Program received signal SIGSEGV, Segmentation fault.
+ Trace 54351
Thread 1078454208 (LWP 18665)
660x4? What are the dimensions of this video?
The video dimensions are 640x480 (see MOV00053.MPG at http://www.inspireworksinc.com/public/dparr/gst-defects/163159/) If I remove [videobox] plugin from pipeline, I can see the correct 640x480 dimensions as it's converted from media type 'video/x-raw-yuv' to 'video/x-raw-rgb' in the [ffcolorspace] plugin at /home/dparr/gst/gst-ffmpeg-0.8.3/gst-libs/ext/ffmpeg/libavcodec/imgconvert.c:1982. If I add back [videobox] plugin to pipeline, the dimensions distort to 660x500 at the same source file location
As I stepped through the code more, the above dimensions seem correct. If the original video is 640x480 and I requested that the videobox add an additional border of size 10 on all edges, then the dimensions that are passed from videobox to ffcolorspace should be (640+2*10) x (480+2*10) == 660x500, exactly what I was observing. It was not a "distort"ion as in last comment. The problem is not yet solved, but maybe a bit closer?
PROBLEM: The U & V row strides are different between the YUV420P format generated by [videobox] (rowstride=330) and the YUV420P format used by [ffcolorspace] (rowstride=332). I don't know which is correct (conforms to the YUV420P format). Is the fix to correct the encoding of [videobox] or the decoding of [ffcolorspace] ? The simple fix is to change /home/dparr/gst/gst-ffmpeg-0.8.3/ext/ffmpeg/gstffmpegcodecmap.c:2267 from: stride2 = ROUND_UP_4 (w2); to: stride2 = w2; However, I believe this is incorrect as this only works with [videobox] borders of width 10; if you change to other or odd size borders, the calculations are again incorrect. Also - need more information on the X/Y chroma shift that is used in the calculation; It would be a shame to fix YUV420 and then accidentally break all of the 7 other formats processed by the same code Assumptions: original video dimensions 640x480; videobox attempts to place a 10 pixel border all around, enlarging the dimensions of the frames passed to [ffcolorspace] to 660x500 [videobox] See gst_video_box_i420() in /home/dparr/gst/gst-plugins-0.8.7/gst/videobox/gstvideobox.c Y (660 x 500) U (330 x 250) V (330 x 250) [ffcolorspace] See gst_ffmpeg_avpicture_fill() in /home/dparr/gst/gst-ffmpeg-0.8.3/ext/ffmpeg/gstffmpegcodecmap.c Y (660 x 500) U (332 x 250) V (332 x 250)
Another example: If [videobox] was not in the picture, and a 640x480 image was formatted at YUV420P, it seems clear that the color planes should have the following dimensions: Y = 640x480 U = 320x240 V = 320x240 But what if it had been 641x480 image ? Y = 641x480 (or should it be 2-byte or 4-byte aligned to 642 or 644 ??) U = 320x480 (or should it have been 320, 322 ???) V = 320x480 (or should it have been 320, 322 ???) There must be a specification somewhere for the YUV420 color scheme that defines how to derive the dimensions of U & V planes when the Y play has odd dimensions. It must also say whether/not the dimensions need to be aligned to 1/2/4-bytes. Then the allocation and population of the YUV420 buffer can be made the same in [videobox] and [ffcolorspace]
See videotestsrc for how to calculate rowstrides and sizes for odd YUV sizes. As a general rule, the Y size is rounded up to a multiple of the subsampling of U and V, and then rowstrides are calculated and rounded up to a multiple of 4 bytes. Vertical sizing rules may have a few exceptions.
I believe this is fixed in CVS now. Please re-open the bug if it is not. 2005-01-19 Tim-Philipp Mueller <tim at centricular dot net> * gst/videobox/gstvideobox.c: (gst_video_box_copy_plane_i420), (gst_video_box_i420), (gst_video_box_chain): Fix row strides for I420 (fixes #163159) Cheers -Tim
Marking fixed on Tim's request.