GNOME Bugzilla – Bug 658259
segfault when cross compiled for windows with mingw64
Last modified: 2013-07-17 22:04:34 UTC
when i cross compiled gst-ffmpeg with mingw64 on rhel-6 it's compile without any kind of error message. however it's always failed with segfault when try to use the compiled code on windows. i've got a conversation with libav people without too much success. it seems the libav working properly (when i only build libav ffplay can play the same file which is crash in gstreamer). here is our discussion: http://lists.libav.org/pipermail/libav-tools/2011-August/000042.html their questions: Does gst-ffmpeg provide it's own get_buffer implementation? Does it return 16-byte aligned buffers and strides?
anyway there was a lots of problem with the 0.7.1 release of libav when build on windows (ie. can't be build for windows). the current trunk however build (and even the version before the rename). it'd be useful to update gst-ffmpeg's libav to the latest git of libav. may be it's solve a lot's of problems. and i'd be happy to test it...
> it'd be useful to update gst-ffmpeg's libav to the latest git of libav. may be > it's solve a lot's of problems. and i'd be happy to test it... Was updated in git recently.
the git version still can't be linked on windwos (while libav can be linked) because of it seems do not add bz2 and pthreads' windows .dll to the link list. if it's recognized bz2 during configure than it'd have to add to the link params -lbz2. and if i do not called with --enable-w32threads (and configure find pthreads) then it'd have to be linked with -lpthreadGC2 same as in libav. ---------------------- CCLD libgstffmpeg.la *** Warning: Linking the shared library libgstffmpeg.la against the *** static library ../../gst-libs/ext/libav/libavformat/libavformat.a is not portable! *** Warning: Linking the shared library libgstffmpeg.la against the *** static library ../../gst-libs/ext/libav/libavcodec/libavcodec.a is not portable! *** Warning: Linking the shared library libgstffmpeg.la against the *** static library ../../gst-libs/ext/libav/libavutil/libavutil.a is not portable! Creating library file: .libs/libgstffmpeg.dll.a../../gst-libs/ext/libav/libavformat/libavformat.a(matroskadec.o): In function `matroska_decode_buffer': /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavformat/matroskadec.c:979: undefined reference to `_BZ2_bzDecompressInit@12' /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavformat/matroskadec.c:988: undefined reference to `_BZ2_bzDecompress@4' /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavformat/matroskadec.c:991: undefined reference to `_BZ2_bzDecompressEnd@4' ../../gst-libs/ext/libav/libavcodec/libavcodec.a(pthread.o): In function `worker': /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavcodec/pthread.c:137: undefined reference to `_pthread_mutex_lock' /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavcodec/pthread.c:144: undefined reference to `_pthread_cond_wait' /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavcodec/pthread.c:152: undefined reference to `_pthread_mutex_unlock' /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavcodec/pthread.c:157: undefined reference to `_pthread_mutex_lock' /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavcodec/pthread.c:142: undefined reference to `_pthread_cond_signal' /builddir/build/BUILD/gst-ffmpeg/gst-libs/ext/libav/libavcodec/pthread.c:148: undefined reference to `_pthread_mutex_unlock' ----------------------
and even if build the latest git with: --enable-w32threads --disable-muxer=matroska --disable-demuxer=matroska to disable the above problems i'm still got a dll which cause immediately segfault which is in the #c0 :-(
AFAICT, your answers are: Yes Yes and no. I take the second part of the second question to imply that ffmpeg requires strides to be multiples of 16 ? They are only multiple of 4 with gst-ffmpeg.
then it's a bug according to: http://lists.libav.org/pipermail/libav-tools/2011-August/000045.html and http://lists.libav.org/pipermail/libav-tools/2011-August/000047.html
It's fixed in 0.11, not entirely fixable in 0.10 afaik.
huuhhh what does it means? i can't expect any working gst-ffmpeg release on windows in this year??? an dirty hack?
Strides are fixed and implicit in 0.10, so whether they are a multiple of 16 and rows are suitably aligned will depend on the width of the video and the original alignment of the buffer (which should be ok by default, at least on *nix, but this part is configurable).
From looking at the code, I think we can fix it fine in gst_ffmpeg_avpicture_fill from gstffmpegutils.c. Unless some other code, elsewhere in gstreamer, relies on the same math to match strides ? AFAICS, the code in _fill sets up strides, then the size it calculates is used to allocate a buffer, so bumping strides to multiples of 16 would in turn allocate the right amount of memory, and hopefully all code would heed the plane pointers instead of relying on the math.
i'd be happy to test a patch:-)
> Unless some other code, elsewhere in gstreamer, relies on the > same math to match strides ? See stuff in libgstvideo
Ah, fair enough. A quick test shows some stuff working, and some stuff not working. The videos that work probably has a nice size in the first place. I guess the 16 alignment of line starts is for SIMD. Disabling SIMD on Windows would probably fix it, at the cost of speed :P
is there any simple way to disable simd and test the cost of it? or would it be too difficult to fix the 16 alignment?
Reconfigure ffmpeg with a number of options, the list of which may be found by running gst-libs/ext/libav/configure --help. Look for --disable-asm and see the couple dozen options below it. Then rebuild/reinstall/test.
ok for the #c3 i create a separate bz #658802. and of course --disable-asm works. but really this's the only option to make gst-ffmpeg on windwos to disable all assembly code (and loose speed)?
Could you retest with GStreamer 1.0 as per git master please. I believe this is mostly obsolete (minus any build problems which may or may not be GStreamer-related). It's also been updated to libav 0.9.
Actually, the windows video sinks probably still need to be updated to handle the strides stuff nicely.
Levente, is this still an issue with current 1.x ?
(In reply to comment #18) > Actually, the windows video sinks probably still need to be updated to handle > the strides stuff nicely. d3dvideosink in git master does this now, DirectDraw is deprecated and not ported anyway. Closing unless someone can reproduce it with 1.1+
we haven't been ported to 1.x. and just a few weeks ago drop again d3d and switch back to directdraw in 0.10 since on some system it's segfault. i hope it'll work with 1.x but we need to port not just our code but at the same time gstreamer-java and jna too to 1.x and java7 which is a rather large work not to mention it'd have to work on rhel6 too where libffi (for jna) and glib (for gstreamer) are too old so we've to some should have to solve this too... currently there is no way to use 1.x on rhel6 (which is the latest enterpise release:-()