The current SVN appears to crash 50% of the time - right after pressing the record button (Maybe something isn't being initialized?). If it doesn't immediately crash, it seems to work fine.
When it does work, stopping and restarting gives you the same 50% chance of a crash.
The backtraces show that the crash always occurs in the same spot. I can see that it's crashing in the inline assembly YSCALEYUV2YV12X function, but I don't have a clue as to what the parameters would normally look like:
#0 0x00000000007c5534 in swScale_MMX (c=0x2aaaaab1ec80, src=0x407fef50,
srcStride=0x2aaaaab0a580, srcSliceY=0, srcSliceH=144, dst=0x407fef30,
dstStride=0x2aaaaab0a6a0) at swscale_template.c:944
#1 0x00000000007bbf31 in sws_scale (c=0x2aaaaab21990,
srcParam=<value optimized out>, srcStride=0x2aaaaab229e8, srcSliceY=96,
srcSliceH=-192, dstParam=<value optimized out>, dstStride=0x2aaaaab0a6a0)
at swscale.c:2466
#2 0x000000000042dfa1 in xvc_ffmpeg_save_frame (fp=<value optimized out>,
image=0xcd4f40) at xtoffmpeg.c:1594
#3 0x000000000041d39b in commonCapture (capfunc=SHM) at capture.c:990
#4 0x000000000042223c in do_record_thread () at gnome_ui.c:513
#5 0x00002ad11a61f3ca in start_thread () from /lib/libpthread.so.0
#6 0x00002ad11abd455d in clone () from /lib/libc.so.6
#7 0x0000000000000000 in ?? ()
Thanks for all your work on this,
J
Logged In: YES
user_id=782084
Originator: NO
what kind of machine are you running this on?
Logged In: YES
user_id=782084
Originator: NO
also, what gcc version are you using?
Logged In: YES
user_id=210111
Originator: YES
It's running on an AMD Athlon64 X2 4400 dual-core CPU, using GCC 4.1.2.
Linux pluto 2.6.17.13-jjl #1 SMP PREEMPT Mon Oct 30 16:24:21 CST 2006 x86_64 GNU/Linux
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Logged In: YES
user_id=782084
Originator: NO
alright,
can you try with the latest ffmpeg version?
To do this, you would:
- cd /var/tmp/ (or somewhere similar)
- checkout ffmpeg svn: svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg
- cd <xvidcap-src-dir>
the next step depends on whether you have a tarball or an svn checkout of xvidcap.
- tarball: mv ffmpeg ffmpeg.orig
- svn: rm ffmpeg
then:
- ln /var/tmp/ffmpeg ffmpeg
- make distclean
- ./autogen.sh --prefix=/var/tmp/xvidcap
- make
- make install
- /var/tmp/xvidcap/bin/xvidcap
Logged In: YES
user_id=782084
Originator: NO
this kinda looks like this:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-March/053697.html
If so, it needs fixing in libav*
I can hardly go back to img_convert because that is deprecated and would also mean I would need to remove the rescale feature again.
Logged In: YES
user_id=782084
Originator: NO
btw. bug # 1668901 closed as duplicate of this one
Logged In: YES
user_id=782084
Originator: NO
Please try this:
- in alread configured source tree ...
- apply this fix to <xvidcap-src-dir>/ffmpeg/libswscale/swscale_template.c
-------------- next part --------------
Index: libswscale/swscale_template.c
===================================================================
--- libswscale/swscale_template.c (revision 22381)
+++ libswscale/swscale_template.c (working copy)
@@ -3168,14 +3168,16 @@
}else{
for(i=0; i<vLumFilterSize; i++)
{
- lumMmxFilter[4*i+0]= (int32_t)lumSrcPtr[i];
+ lumMmxFilter[4*i+0]= (uintptr_t)lumSrcPtr[i];
+ lumMmxFilter[4*i+1]= (uintptr_t)lumSrcPtr[i] >> 32;
lumMmxFilter[4*i+2]=
lumMmxFilter[4*i+3]=
((uint16_t)vLumFilter[dstY*vLumFilterSize + i])*0x10001;
}
for(i=0; i<vChrFilterSize; i++)
{
- chrMmxFilter[4*i+0]= (int32_t)chrSrcPtr[i];
+ chrMmxFilter[4*i+0]= (uintptr_t)chrSrcPtr[i];
+ chrMmxFilter[4*i+1]= (uintptr_t)chrSrcPtr[i] >> 32;
chrMmxFilter[4*i+2]=
chrMmxFilter[4*i+3]=
((uint16_t)vChrFilter[chrDstY*vChrFilterSize + i])*0x10001;
------------------------------
- cd <xvidcap-src-dir>/ffmpeg
- make
- cd ..
- touch src/xtoffmpeg.c
- make install
then please post your success or failure here.
Logged In: YES
user_id=210111
Originator: YES
Sorry I haven't posted here in so long - but when I upgraded to the latest ffmpeg it completely removed the ability for me to capture in any movie format. I thought I had screwed up, and it got dropped to the back burner.
Tonight, I re-checked out the entire SVN and see that you have upgraded trunk to use ffmpet 8813 also. It gives me the same problem: Doesn't seem to recognize any of codec libraries are available, whereas previous versions did.
-----------------------------
make-ing prerequisite ffmpeg libraries
install prefix /usr/local
source path /data/install/xvidcap/trunk/ffmpeg
C compiler gcc
make make
.align is power-of-two no
ARCH x86_64 (generic)
big-endian no
MMX enabled yes
CMOV enabled no
CMOV is fast no
gprof enabled no
debug symbols yes
strip symbols yes
optimize yes
static yes
shared no
postprocessing support no
software scaler enabled yes
video hooking yes
Imlib2 support yes
FreeType support yes
network support yes
IPv6 support yes
threading support pthreads
SDL support yes
Sun medialib support no
AVISynth enabled no
liba52 support no
liba52 dlopened no
libdts support no
libfaac enabled no
libfaad enabled no
faadbin enabled no
libgsm enabled no
libmp3lame enabled yes
libnut enabled no
libogg enabled no
libtheora enabled no
libvorbis enabled no
x264 enabled no
XviD enabled no
zlib enabled yes
AMR-NB float support no
AMR-NB fixed support no
AMR-WB float support no
AMR-WB IF2 support no
-------------------------------------
Not sure why, since I have all the required lives and dev packages installed (as evidenced by it compiling with the old ffmpeg. Seems like the ffmpeg guys broke something.
Logged In: YES
user_id=782084
Originator: NO
the thing with SVN is that the code in there is currently inconsistent, very probably broken (see my latest post in the announcements forum)
I recommend you take the 1.5rc1 version, possibly apply the patch for bug # 1656983, then this one to the bundled ffmpeg (the one from xvidcap 1.5rc1 should be fine).
Logged In: YES
user_id=782084
Originator: NO
Any news on this one? If the fix works, I'd like to upgrade the bundled ffmpeg to 8195 and head for rc2.
setting this to "pending" and will go ahead with that plan, if this times out.
Logged In: YES
user_id=210111
Originator: YES
I thought I had posted this a while back, but I must have never submitted:
Unfortunately, it does not seem to have made any difference in the frequency of the segfaults.
Additionally, I notice the following error when compiling the 8133 ffmpeg - though it doesn't halt the xvidcap compilation.
make[1]: Entering directory `/data/install/xvidcap/trunk/ffmpeg-svn8133/vhook'
gcc -I"/data/install/xvidcap/trunk/ffmpeg" -I"/data/install/xvidcap/trunk/ffmpeg" -I"/data/install/xvidcap/trunk/ffmpeg"/libavutil -I"/data/install/xvidcap/trunk/ffmpeg"/libavcodec -I"/data/install/xvidcap/trunk/ffmpeg"/libavformat -I"/data/install/xvidcap/trunk/ffmpeg"/libswscale -fPIC -fomit-frame-pointer -pthread -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -O3 -DHAVE_AV_CONFIG_H `imlib2-config --cflags` `freetype-config --cflags` -c -o imlib2.o imlib2.c
In file included from /data/install/xvidcap/trunk/ffmpeg/libavformat/framehook.h:29,
from imlib2.c:94:
/data/install/xvidcap/trunk/ffmpeg/avcodec.h:2429: warning: 'ImgReSampleContext' is deprecated
/data/install/xvidcap/trunk/ffmpeg/avcodec.h:2432: warning: 'ImgReSampleContext' is deprecated
In file included from imlib2.c:106:
/usr/include/Imlib2.h:108: error: expected ')' before '*' token
/usr/include/Imlib2.h:109: error: expected ')' before '*' token
/usr/include/Imlib2.h:110: error: expected ')' before 'colormap'
/usr/include/Imlib2.h:111: error: expected ')' before 'drawable'
/usr/include/Imlib2.h:112: error: expected ')' before 'mask'
/usr/include/Imlib2.h:137: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/Imlib2.h:138: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/Imlib2.h:139: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imlib_context_get_colormap'
/usr/include/Imlib2.h:140: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imlib_context_get_drawable'
/usr/include/Imlib2.h:141: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imlib_context_get_mask'
/usr/include/Imlib2.h:170: error: expected ')' before '*' token
/usr/include/Imlib2.h:171: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
/usr/include/Imlib2.h:209: error: expected ')' before '*' token
/usr/include/Imlib2.h:211: error: expected ')' before '*' token
/usr/include/Imlib2.h:214: error: expected ')' before 'pixmap'
/usr/include/Imlib2.h:240: error: expected ')' before 'mask'
/usr/include/Imlib2.h:243: error: expected ')' before '*' token
/usr/include/Imlib2.h:246: error: expected ')' before 'mask'
/usr/include/Imlib2.h:256: error: expected ')' before 'mask'
imlib2.c: In function 'Release':
Logged In: YES
user_id=210111
Originator: YES
Spent all day yesterday rebuilding my system from scratch (went from Edgy to Feisty herd 5 for testing purposes). I'll re-compile and test to make sure the symptoms are still the same/existing.
Sorry I haven't had more time to work on this from my end; I don't like to throw bugs out and not help troubleshoot: I've just been crazy busy for... as long as I can remember now. :)
-J
Logged In: YES
user_id=782084
Originator: NO
good.
have just managed to compile on the only AMD64 machine I can use (HP test drive machine) where I cannot reproduce the problem because running "xvidcap --gui no --mf --auto --file test.avi" gives me a memory corruption I cannot reproduce here. Maybe related to SLES 10?!?
Can I log on to a machine of yours?
Also note that I am using ffmpeg svn 8195 locally, now which has the proposed ffmpeg fix included.
Logged In: YES
user_id=210111
Originator: YES
Recompiled (from completely new SVN checkout) after installing this machine clean. Still have the problem when run against ffmpeg-8133 from the xvidcap svn:
I'll check out 8195 and see what I get.
***** first two attempts crashed immediately after pressing record:
evil@pluto:~$ xvidcap
swscale AAAAB000 AAAAB000 AAAAB000 -> AC001140 AC007D40 AC009840
sws Strides:768 768 768 -> 192 96 96
Segmentation fault (core dumped)
evil@pluto:~$ xvidcap
swscale AAAAB000 AAAAB000 AAAAB000 -> AC001070 AC007C70 AC009770
sws Strides:768 768 768 -> 192 96 96
Segmentation fault (core dumped)
***** The third times the charm... this one started working... but hung when I hit stop - not sure if that's a related bug or not, but seems to do it everytime.
evil@pluto:~$ xvidcap
swscale AAAAB000 AAAAB000 AAAAB000 -> E0B9F0 E125F0 E140F0
sws Strides:768 768 768 -> 192 96 96
swscale AAAAB000 AAAAB000 AAAAB000 -> E0B9F0 E125F0 E140F0
sws Strides:768 768 768 -> 192 96 96
swscale AAAAB000 AAAAB000 AAAAB000 -> E0B9F0 E125F0 E140F0
sws Strides:768 768 768 -> 192 96 96
....
***** Here are another couple of failures and a success:
evil@pluto:~$ xvidcap
[mpeg4 @ 0xa43770]removing common factors from framerate
swscale AAAAB000 AAAAB000 AAAAB000 -> AC008900 AC00F500 AC011000
sws Strides:768 768 768 -> 192 96 96
Segmentation fault (core dumped)
evil@pluto:~$ xvidcap
[mpeg4 @ 0xa43770]removing common factors from framerate
swscale AAAAB000 AAAAB000 AAAAB000 -> FC22B0 FC8EB0 FCA9B0
sws Strides:768 768 768 -> 192 96 96
swscale AAAAB000 AAAAB000 AAAAB000 -> FC22B0 FC8EB0 FCA9B0
sws Strides:768 768 768 -> 192 96 96
....
Logged In: YES
user_id=210111
Originator: YES
ffmpeg-8195 does appear to correct this bug.
Unfortunately, I mis-diagnosed the "hang on stop" symptom I mentioned earlier. Under Kubuntu Fiesty herd 5, the program actually hangs after capturing only a few frames.
I'll submit that as a separate bug though; if you've updated SVN to 8195, we can consider this one closed.
Logged In: YES
user_id=782084
Originator: NO
will bump ffmpeg to 8195 in svn asap and close this, then.
Logged In: YES
user_id=782084
Originator: NO
have I mentioned SF svn service sucks, yet?
Still haven't been able to commit all the files from the ffmpeg update. Will open a SF ticket again.
Logged In: YES
user_id=782084
Originator: NO
worked around the svn issue by replacing the bundled ffmpeg completely with an external svn reference that is automatically checked out with xvidcap (tarball will, of course, still have ffmpeg). This will make xvidcap much leaner on SF svn and hopefully save me from problems in the furture. Of course, that means I can no longer just patch the bundled ffmpeg files but need to patch upstream (which can be a lengthy process) or apply patches after checkout.
Anyhow, should be fixed now.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).