Re: [Mjpeg-users] mpeg2enc current cvs segfault ?
On Fri, Nov 07, 2003 at 04:20:13PM +0100, Bernhard Praschinger wrote: Hallo Has anyone tried the current cvs mpeg2enc lately? I pulled the current cvs on Nov. 4 because I wanted to see for myself how well the new no B frames please option worked. But my copy of mpeg2enc compiled from the source I pulled that day takes a segfault while it's processing the first frame (field?). Here is a gdb backtrace on the corefile that dumps when it segfaults: Just check out the CVS, and compiled it, works well. The binary was compiled with gcc 2.95.3, and all I did for the test binary was ./configure ; make. I let it select all it's options. The system is a P4 celeron (properly detected by configure) chip. But I use (GCC) 3.3.1 Maybe there a problems hidden with the latest changes in the ASM part. I get the same result even if I use gcc 3.3.1 to compile it, and I pulled a fresh cvs just before compiling with 3.3.1. I did have to upgrade my gdb so it could understand gcc331's debugging symbols: Core was generated by `mpeg2enc.cvs.2003.11.04 -f 5 -n n -a 2 -V 230 -B 224 -S 8000 -b 9576 -q 10 -I 1'. Program terminated with signal 11, Segmentation fault. [symbol loading lines omitted] #0 quant_non_intra_sse (wsp=Cannot access memory at address 0xbfffebd0 ) at quantize_x86.c:309 309 mulps_m2r( *(mmx_t*)piqf[0], xmm2 ); --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2enc current cvs segfault ?
Hallo Has anyone tried the current cvs mpeg2enc lately? I pulled the It's all I ever use. I haven't used the release version in a couple years. CVS is more fun than Stable versions. To less surprises ;) Core was generated by `mpeg2enc.cvs.2003.11.04 -f 5 -n n -a 2 -V 230 -B 224 -S 8000 -b 9576 -q 10 -I 1'. Program terminated with signal 11, Segmentation fault. [a bunch of symbol loading messages, cut for brevity] #0 quant_non_intra_sse (wsp=0x41778008, src=0x41a7b008, dst=0x41aec008, q_scale_type=1, satlim=2047, nonsat_mquant=0x41b5d02c) at quantize_x86.c:309 309 mulps_m2r( *(mmx_t*)piqf[0], xmm2 ); I forgot to ask, wihch version of NASM do you use ? I have NASM version 0.98.35 compiled on Sep 23 2003 Using a Suse 9.0 System. The command line I was using to test this was the following: lav2yuv t.cut | mpeg2enc.cvs.2003.11.04 -M 0 -f 5 -n n -a 2 -V 230 -B 224 -S 8000 -b 9576 -q 10 -I 1 -G 54 -H -N 0.0 -X 200 -Q 4.0 -d -4 4 -2 4 -R 0 -o t.m2v Uh, -G to set the maximum GOP size looks very strange - a GOP size of 54 is *way* out of bounds for any format I know of that will be used in a hardware player. DVDs have a max of 18 for NTSC and 15 for PAL (I think that's right).I'm not sure a SVCD should be using a GOP size of 54 either... Seems not to be a problem. The other thing that jumped out was the use of '-M 0'. Try leaving that out and using the default of 1. That does not change anything. On my machine. It's a possibility but I think you may have uncovered a bug in the threading. Unlikely. ;) Because Andrew check that some weeks ago, where the multithreading code was broken. Could it be a memory problem ? On my machine mpeg2enc buffers 111 Frames. That is about 100MB auf hoffentlich bald, Berni the Chaos of Woodquarter Email: [EMAIL PROTECTED] www: http://www.lysator.liu.se/~gz/bernhard --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2enc current cvs segfault ?
On Fri, Nov 07, 2003 at 10:28:40AM -0800, Steven M. Schultz wrote: On Fri, 7 Nov 2003, Richard Ellis wrote: switch. Using gop length of 54 shrinks the resultant video size a wee bit due to fewer I frames. The command line is what I use for How little is 'wee' bit? There are other ways to shrink the video size :) It's been so long since I bumped up to -G 54 for timeshifting I don't remember, but when I tested it the reduction was worth enough to convince me that it was worth staying with. I'd have to run a test with/without to give you actual numbers, which I can do if you'd like. q_scale_type=1, satlim=2047, nonsat_mquant=0x40c5602c) at quantize_x86.c:309 309 mulps_m2r( *(mmx_t*)piqf[0], xmm2 ); The problem would seem to be in accessing the non intra quant tables. That would be related to -H perhaps. The other thing to try might be encoding to DVD format with f 8 . -Try the default -b (which is 7500 for DVD)s. There's obviously something weird going on with user specified SVCD creation - at least that's my hunch. Finding something which works (and I use the cvs version all the time for standard DVD and CVD creation) and then moving back up to find which option breaks things. Two new runs: lav2yuv t.cut | mpeg2enc.cvs.2003.11.04 -f 8 -V 230 -b 9576 -q 10 -o t.m2v lav2yuv t.cut | mpeg2enc.cvs.2003.11.04 -f 5 -V 230 -b 9576 -q 10 -o t.m2v Both dumped core, with the same gdb backtrace as before. I'm at a loss to explain it so far. And it does not seem to be localized to SVCD, as -f 8 did the same. Yes, it does look like something localized to my system, but I can't pin it down just yet. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2enc current cvs segfault ?
On Fri, Nov 07, 2003 at 07:24:08PM +0100, Bernhard Praschinger wrote: q_scale_type=1, satlim=2047, nonsat_mquant=0x41b5d02c) at quantize_x86.c:309 309 mulps_m2r( *(mmx_t*)piqf[0], xmm2 ); I forgot to ask, wihch version of NASM do you use ? I have NASM version 0.98.35 compiled on Sep 23 2003 Using a Suse 9.0 System. NASM version 0.98.20 compiled on Apr 18 2002 I need to upgrade NASM next and see if that fixes it. Could it be a memory problem ? On my machine mpeg2enc buffers 111 Frames. That is about 100MB I don't think so, never had any trouble with the released mpeg2enc nor with anything else, and it dumps core way too fast to have eaten 120meg of free swap space first in the process: total used free sharedbuffers cached Mem:516360 499800 16560 0 7988 294652 -/+ buffers/cache: 197160 319200 Swap: 240020 119904 120116 --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2enc current cvs segfault ?
On Fri, Nov 07, 2003 at 10:40:06AM -0800, Steven M. Schultz wrote: On Fri, 7 Nov 2003, Bernhard Praschinger wrote: Could it be a memory problem ? On my machine mpeg2enc buffers 111 Frames. That is about 100MB That's a possibility I suppose. The other thing that might cause a problem is a 'limit' set by 'limit datasize xxx' - if that's set too low then mpeg2enc won't be able to allocate enough memory. It's my own machine, I don't limit myself :) /videos/encode/Time_Shift ulimit -a core file size (blocks) unlimited data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes)unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 4096 virtual memory (kbytes) unlimited One other thing that comes to mind... Having multiple versions of mjpegtools on a system might cause the problem due to the libraries that get installed into /usr/local/lib. When building the new version I wonder if it's possible that the programs are linking against the older libs in /usr/local/lib instead of the newly compiled ones in the source tree. That can produce a program that looks ok but fails in strange ways. Yes, that can cause weird problems, but as far as I can tell, mpeg2enc cvs version is linking with it's intended lib: ldd mpeg2enc.cvs.2003.11.04 libmpeg2encpp-1.6.so.0 = /mnt/maxtor/rellis/video/mjpt-1.6.1.90/lib/libmpeg2encpp-1.6.so.0 (0x40015000) libstdc++.so.5 = /mnt/maxtor/rellis/gcc331/lib/./libstdc++.so.5 (0x4004) libpthread.so.0 = /lib/libpthread.so.0 (0x400b6000) libm.so.6 = /lib/libm.so.6 (0x400c7000) libgcc_s.so.1 = /mnt/maxtor/rellis/gcc331/lib/./libgcc_s.so.1 (0x400e3000) libc.so.6 = /lib/libc.so.6 (0x400ec000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) Yes, the locations are non-standard. libmpeg2encpp-1.6 is only created and used by the cvs mpeg2enc, I had to freshly move it over when I made the first cvs version a couple days ago. I've moved it plus mpeg2enc over for each new compile I've made. The released mpeg2enc does not link to it, and I think it's part of Andrew's restructuring of the code. ldd mpeg2enc libpthread.so.0 = /lib/libpthread.so.0 (0x40019000) libstdc++-libc6.1-2.so.3 = /usr/lib/libstdc++-libc6.1-2.so.3 (0x4002a000) libm.so.6 = /lib/libm.so.6 (0x40071000) libc.so.6 = /lib/libc.so.6 (0x4008d000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) I'll try to get a chance soon to test with an upgraded NASM and see if that cures it. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2enc current cvs segfault ?
On Fri, 7 Nov 2003, Richard Ellis wrote: It's been so long since I bumped up to -G 54 for timeshifting I don't remember, but when I tested it the reduction was worth enough to convince me that it was worth staying with. I'd have to run a test with/without to give you actual numbers, which I can do if you'd like. After we figure out what's going awry on your system I think we would be interested in the difference between a standard gop size of 15 or so and the 54. for producing smaller files and with clean sources the eliminate single coefficient option (-E, -E -10 is a moderate setting) will probably do just as well as a large GOP. Two new runs: lav2yuv t.cut | mpeg2enc.cvs.2003.11.04 -f 8 -V 230 -b 9576 -q 10 -o t.m2v lav2yuv t.cut | mpeg2enc.cvs.2003.11.04 -f 5 -V 230 -b 9576 -q 10 -o t.m2v Both dumped core, with the same gdb backtrace as before. I'm at a loss to explain it so far. And it does not seem to be localized to SVCD, as -f 8 did the same. Yes, it does look like something localized to my system, but I can't pin it down just yet. Did you install all of the cvs version or just pull out the mpeg2enc executable? I'm wondering if the problem is due to linking against the previously installed version's libraries. The linker seems to give preference to /usr/local/lib if a -L/usr/local/lib is used. Steven Schultz --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2enc current cvs segfault ?
On Fri, 7 Nov 2003, Richard Ellis wrote: It's my own machine, I don't limit myself :) I do - mainly as a safety measure to keep a runaway program from completely trashing the machine. Having multiple versions of mjpegtools on a system might cause the problem due to the libraries that get installed into /usr/local/lib. When building the new version I wonder if it's Yes, that can cause weird problems, but as far as I can tell, mpeg2enc cvs version is linking with it's intended lib: ldd mpeg2enc.cvs.2003.11.04 libmpeg2encpp-1.6.so.0 = /mnt/maxtor/rellis/video/mjpt-1.6.1.90/lib/libmpeg2encpp-1.6.so.0 (0x40015000) Yes, the locations are non-standard. libmpeg2encpp-1.6 is only created and used by the cvs mpeg2enc, I had to freshly move it over when I made the first cvs version a couple days ago. I've moved it plus mpeg2enc over for each new compile I've made. The released mpeg2enc does not link to it, and I think it's part of Andrew's restructuring of the code. Correct. At the moment only mpeg2enc links against the shared library. There are static (.a) libraries though tha are created and installed and those are the ones I had in mind. What's supposed to happen is that locally built versions (in the source tree) are used when building a new version but I have seen cases where previously installed versions would be used. I'm not convinced that's the problem in this case but it's about the only thing left that i can think of. I'm stumped (for now). Steven Schultz --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
