After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 563651 - gst-ffmpeg crashes under windows
gst-ffmpeg crashes under windows
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.21
Other Windows
: High critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-08 07:46 UTC by Etienne Barbier
Modified: 2009-05-30 18:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Etienne Barbier 2008-12-08 07:46:27 UTC
Running this pipeline raises an exception in gst-ffmpeg dll (access violation):

gst-launch-0.10 -v videotestsrc ! ffenc_mpeg4 ! rtpmp4vpay send-config=true ! udpsink port=5004

This works fine with previous versions (before gst-ffmpeg-0.10.5)
Comment 1 Sebastian Dröge (slomo) 2008-12-08 12:40:17 UTC
Thanks for taking the time to report this bug.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 2 Etienne Barbier 2008-12-08 14:00:38 UTC
Here is the stack trace:

LIBGSTFFMPEG! ff_fdct_sse2 + 179 bytes
LIBGSTFFMPEG! dct_quantize_trellis_c + 129 bytes
LIBGSTFFMPEG! dct_quantize_trellis_c + 26331 bytes
LIBGSTFFMPEG! avcodec_default_execute + 85 bytes
LIBGSTFFMPEG! MPV_encode_picture + 3582 bytes
LIBGSTFFMPEG! avcodec_encode_video + 133 bytes
gst_ffmpegenc_chain_video(_GstPad * 0x039010d8, _GstBuffer * 0x03903328) line 645 + 45 bytes
LIBGSTREAMER-0.10! 10026538()

I found something strange however. Using the debug dll of libgstreamer makes it working. I had to run the pipeline with the release dll of libgstreamer instead to reproduce the bug - hence there is no stack trace for libgstreamer call. I have recompiled the libgstreamer dll in release mode to make sure it was not corrupted somehow ... same result.

Hope this helps ...
Comment 3 Damien Lespiau 2008-12-25 22:58:37 UTC
I have more input on this:

Latest gst-ffmpeg segfaults on almost every SSE2 intruction with 16-bytes memory access. Somehow mingw32 gcc does not honour 16-bytes alignement and it seems to be a known bug.

eg.
0x0120904d <put_h264_qpel8or16_hv_lowpass_sse2+221>:    movdqa %xmm6,(%ecx)
with 
ecx            0x237f638

that just can't work.

I have a few pointers for further investigation:

This site is dedicated to building ffmpeg on windows
http://ffmpeg.arrozcru.org/

People with the same symptoms as we have suggest adding -fno-common to go around a gcc/binutil bug:
http://ffmpeg.arrozcru.com/forum/viewtopic.php?f=1&t=906

more specificaly, this bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

However adding -fno-common to the internal ffmpeg does not help and I still get plenty of segfaults. I wonder if the way ffmpeg is linked to libgstffmpeg.dll (it shouldn't but well...)

for the record, my last try tonight (which still does not work) was done with:
./configure --disable-vhook --disable-ffserver --disable-ffplay --enable-postproc --enable-swscale --enable-gpl --enable-static --disable-shared --disable-encoder=flac --disable-decoder=cavs --disable-protocols --disable-devices --disable-network --enable-cross-compile --target-os=mingw32msvc --arch=i586 --cross-prefix=i586-mingw32msvc- --enable-memalign-hack --extra-cflags="-fno-common" --disable-ffmpeg
Comment 4 Damien Lespiau 2008-12-26 15:32:55 UTC
a bit more about this bug:

I suspect that very few people have actually *tested* gst-ffmpeg 0.10.5 / 0.10.6 on windows. As for me, I only made them compile.

I used to cross-compile gst-ffmpeg for windows on my linux box with:
i586-mingw32mvsc-gcc 3.4.5 (debian package)
i586-mingw32mvsc binutils 2.17.50 (debian package)

FAIL. The resulting gst-ffmpeg has SSE2 unaligned memory accesses.

So I tried a very different approach:
- compile ffmpeg DLLs *on windows* following this wiki: http://ffmpeg.arrozcru.com/wiki/index.php?title=Main_Page
- used ffmpeg r15986
- gcc 4.2.1-sjlj-2 and binutils 2.18.50-20080109-2
- patched ffmpeg to make it generate gcc import libraries (.dll.a)
- configured it with something very close to what gst-ffmpeg does
./configure --enable-gpl --enable-postproc --enable-swscale --disable-ffserver --disable-vhook --disable-protocols --disable-devices --disable-net
work --enable-shared --disable-static --enable-memalign-hack --extra-cflags="-fno-common" --disable-encoder=flac --disable-decoder=cavs
- then I configured gst-ffmpeg with --host=i586-mingw32msvc --with-system-ffmpeg (cross-compiling it and using the newly generated ffmpeg DLLs, tweaking the prefix in .pc flles)

and ... It works quite well!

Now, I'll try to narrow down what I was doing wrong among:
- gcc's version
- binutils' version
- which versions of gcc are affected by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216 (3.4.5 ? 4.2.x ? both ?)
- the fact that I was cross-compiling ffmpeg
- the fact that libgstffmpeg.dll wraps a static ffmpeg
- the SVN revision used
Comment 5 Sebastian Dröge (slomo) 2008-12-26 17:48:31 UTC
IIRC gcc before 4.3 had problems with memory alignment for stack addresses with SSE. Do you still have this problem when compiling with gcc 4.3?
Comment 6 Tobias Mueller 2009-05-30 15:07:04 UTC
Damien, any chance you can answer the question in comment #5?
Comment 7 Damien Lespiau 2009-05-30 16:39:26 UTC
Unfortunately no. I don't have access to a windows box anymore, and not currently working on this.
Comment 8 Tobias Mueller 2009-05-30 18:32:00 UTC
Hey Damien,
thanks for your timely feedback.

I think we should close this bug as INCOMPLETE then. However, if you should encounter this bug again, please reopen.