October 2006 - ffmpeg-devel - lists.ffmpeg.org

DECLARE_ALIGNED_16 not honoured correctly in MinGW
by slhomme＠divxcorp.com 07 Nov '06

07 Nov '06

Hi, We are encountering a crash when calling DrFFMPEG from DrDivX on Windows. The crash occurs when decoding WMA content. After some investigation it appears that this declaration in wmadec.c doesn't produce what it's supposed to do: DECLARE_ALIGNED_16(FFTSample, output[BLOCK_MAX_SIZE * 2]); When the DLL (could be libavcodec) is called from MSVC code 'output' is not aligned to 16 bits (0x01F36D28 in this case for example). And it crashes the SSE code used later. But it works fine when everything is built with MinGW. It appears that gcc assumes the stack is already aligned a certain way when it does the alignment of this variable in the stack. And this is not true when the stack is given by MSVC code. Now I understand there's no support for MSVC here, but on the other hand libavcodec is a library, no matter how it's being called. Plus the bug is not in MSVC (who has the right to do whatever they want with the stack) but in gcc. So my question is: does anybody know a way to make gcc behave correctly in such case ? The other possibility I see to avoid the crash in my case is to add a test in ff_imdct_calc_sse() and vector_fmul_add_add_sse() to use the C code if one of the parameter passed is not aligned as it should. (I could make the patch if the solution is OK) Thanks Steve

5 7

Streaming from camera segfaults on Ubuntu Dapper
by Timo.Rantalaiho＠iki.fi 06 Nov '06

06 Nov '06

Hello, I'm trying to stream video from a Logitech Quickcam 8000 that I had working with older machine, Linux version and ffmpeg some years ago. ffmpeg crashes right away in a segmentation fault. This happens both with the package coming with Dapper (0.cvs20050918-) and with the Subversion snapshot I just build. Below are the details. Linux toro 2.6.15-27-686 #1 SMP PREEMPT Sat Sep 16 02:13:27 UTC 2006 i686 GNU/Linux thrantal at toro:~/downloads/ffmpeg$ ./ffserver & [1] 26614 thrantal at toro:~/downloads/ffmpeg$ ffserver started. thrantal at toro:~/downloads/ffmpeg$ thrantal at toro:~/downloads/ffmpeg$ gdb ./ffmpeg_g GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) r -an http://localhost:8090/feed1.ffm Starting program: /home/thrantal/downloads/ffmpeg/ffmpeg_g -an http://localhost:8090/feed1.ffm FFmpeg version SVN-r6624, Copyright (c) 2000-2006 Fabrice Bellard, et al. configuration: libavutil version: 49.0.1 libavcodec version: 51.16.0 libavformat version: 50.5.0 built on Oct 10 2006 15:00:07, gcc: 4.0.3 (Ubuntu 4.0.3-1ubuntu5) 127.0.0.1 - - [Tue Oct 10 15:16:26 2006] "GET /feed1.ffm HTTP/1.0" 200 4165 [video4linux2 @ 0x8348fa0][7]Capabilities: 5000001 The V4L2 driver changed the video from 352x240 to 320x240 Input #0, video4linux2, from '': Duration: N/A, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 320x240, 13823 kb/s, 15.00 fps(r) Input #1, audio_device, from '': Duration: N/A, bitrate: N/A Stream #1.0: Audio: pcm_s16le, 22050 Hz, mono, 352 kb/s Output #0, ffm, to 'http://localhost:8090/feed1.ffm': Stream #0.0: Audio: mp2, 22050 Hz, mono, 64 kb/s Stream #0.1: Video: msmpeg4, yuv420p, 352x240, q=3-31, 256 kb/s, 15.00 fps(c) Stream mapping: Stream #1.0 -> #0.0 Stream #0.0 -> #0.1 [msmpeg4 @ 0x83e18dc]removing common factors from framerate Press [q] to stop encoding Program received signal SIGSEGV, Segmentation fault. 0xb7ecb9dc in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7ecb9dc in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0x080b435c in v4l2_read_packet (s1=0x8456070, pkt=0x8516000) at v4l2.c:313 #2 0x08062bbb in av_read_frame_internal (s=0x8456070, pkt=0xbfad8028) at utils.c:551 #3 0x0805e774 in main (argc=3, argv=0x8456f80) at ffmpeg.c:1902 (gdb) disass $pc-32 $pc+32 Dump of assembler code from 0xb7ecb9bc to 0xb7ecb9fc: 0xb7ecb9bc <__memcpy_chk+12>: pop %es 0xb7ecb9bd <__memcpy_chk+13>: add %cl,0x244c8bf6(%ecx) 0xb7ecb9c3 <memcpy+3>: or $0x89,%al 0xb7ecb9c5 <memcpy+5>: clc 0xb7ecb9c6 <memcpy+6>: mov 0x4(%esp),%edi 0xb7ecb9ca <memcpy+10>: mov %esi,%edx 0xb7ecb9cc <memcpy+12>: mov 0x8(%esp),%esi 0xb7ecb9d0 <memcpy+16>: cld 0xb7ecb9d1 <memcpy+17>: shr %ecx 0xb7ecb9d3 <memcpy+19>: jae 0xb7ecb9d6 <memcpy+22> 0xb7ecb9d5 <memcpy+21>: movsb %ds:(%esi),%es:(%edi) 0xb7ecb9d6 <memcpy+22>: shr %ecx 0xb7ecb9d8 <memcpy+24>: jae 0xb7ecb9dc <memcpy+28> 0xb7ecb9da <memcpy+26>: movsw %ds:(%esi),%es:(%edi) 0xb7ecb9dc <memcpy+28>: repz movsl %ds:(%esi),%es:(%edi) 0xb7ecb9de <memcpy+30>: mov %eax,%edi 0xb7ecb9e0 <memcpy+32>: mov %edx,%esi 0xb7ecb9e2 <memcpy+34>: mov 0x4(%esp),%eax 0xb7ecb9e6 <memcpy+38>: ret 0xb7ecb9e7 <memcpy+39>: nop 0xb7ecb9e8 <memcpy+40>: nop 0xb7ecb9e9 <memcpy+41>: nop ---Type <return> to continue, or q <return> to quit--- 0xb7ecb9ea <memcpy+42>: nop 0xb7ecb9eb <memcpy+43>: nop 0xb7ecb9ec <memcpy+44>: nop 0xb7ecb9ed <memcpy+45>: nop 0xb7ecb9ee <memcpy+46>: nop 0xb7ecb9ef <memcpy+47>: nop 0xb7ecb9f0 <memcpy+48>: push %ebp 0xb7ecb9f1 <memcpy+49>: mov %esp,%ebp 0xb7ecb9f3 <memcpy+51>: sub $0xc,%esp 0xb7ecb9f6 <memcpy+54>: mov %esi,0x4(%esp) 0xb7ecb9fa <memcpy+58>: mov 0x10(%ebp),%esi End of assembler dump. (gdb) info all-registers eax 0x8456f80 138768256 ecx 0x13ef4 81652 edx 0x8457010 138768400 ebx 0x84f53d0 139416528 esp 0xbfad793c 0xbfad793c ebp 0x8456070 0x8456070 esi 0xb7e04c30 -1210037200 edi 0x8516000 139550720 eip 0xb7ecb9dc 0xb7ecb9dc <memcpy+28> eflags 0x10206 66054 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 st0 0 (raw 0x00000000000000000000) st1 0 (raw 0x00000000000000000000) st2 0 (raw 0x00000000000000000000) st3 0 (raw 0x00000000000000000000) st4 1160482587544901 (raw 0x403183ee7d0cc1a8a000) st5 0 (raw 0x00000000000000000000) st6 0 (raw 0x00000000000000000000) ---Type <return> to continue, or q <return> to quit--- st7 0 (raw 0x00000000000000000000) fctrl 0x37f 895 fstat 0x4032 16434 ftag 0xffff 65535 fiseg 0x73 115 fioff 0x805ea99 134605465 foseg 0x7b 123 fooff 0x8457660 138770016 fop 0x5d8 1496 xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, ---Type <return> to continue, or q <return> to quit--- 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} mxcsr 0x1f80 8064 mm0 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm1 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} ---Type <return> to continue, or q <return> to quit--- mm2 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm3 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm4 {uint64 = 0x83ee7d0cc1a8a000, v2_int32 = {0xc1a8a000, 0x83ee7d0c}, v4_int16 = {0xa000, 0xc1a8, 0x7d0c, 0x83ee}, v8_int8 = {0x0, 0xa0, 0xa8, 0xc1, 0xc, 0x7d, 0xee, 0x83}} mm5 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm6 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} mm7 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} (gdb)

4 10

[PATCH] mov muxer vfr
by baptiste.coudurier＠smartjog.com 03 Nov '06

03 Nov '06

Hi Here is a patch that make mov muxer being able to create vfr streams. Packet duration is computed from dts difference. I think it is a bit ugly so if anyone see a cleaner way to do it.. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312

5 18

mp3lame : more --as-needed woes
by seandarcy2＠gmail.com 03 Nov '06

03 Nov '06

Building today's svn - 6834, configure dies looking for lame, from config.err: gcc -Wl,--warn-common -Wl,--as-needed -pthread -o /tmp/ffmpeg-conf-9929-7135-22245 /tmp/ffmpeg-conf-2682-7135-369.o -lm -lz -ldts -lm -lgsm -lmp3lame -lm /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/libmp3lame.so: undefined reference to `sqrt' /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/libmp3lame.so: undefined reference to `floor' /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/libmp3lame.so: undefined reference to `ceil' /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../lib64/libmp3lame.so: undefined reference to `tan' .......................... Notice libm _follows_ libmp3lame, so as-needed should be able to use it. ??? [ this may be a dup. An earlier message never showed up. If so, sorry. ] sean

7 11

Call for volunteers to write NUT de/muxer for libavformat
by ods15＠ods15.dyndns.org 02 Nov '06

02 Nov '06

Subject pretty much says it all. A NUT de/muxer in libavformat is currently the major bottleneck for starting to advertise NUT. There are still complaints on the readability of the spec. Rich and I have been working on an informative "introduction" document which IMO gives the starting knowledge necessary to understand the spec. I might be completely wrong on this, but we cannot know until someone who has no previous knowledge on NUT steps in and tells us what trouble he runs into. Any volunteers? Please sign up to nut-devel at mplayerhq.hu and inform us... - ods15

7 16

Re: Re: Re: mjpeg with trellis quant segaults ... to be expected
by karl.h.beckers＠gmx.net 02 Nov '06

02 Nov '06

> the indention of the new code is wrong, the patch has random linebreaks > in the midde (=its malformed and not applyable) > besides checking for this in the innermost loop is not acceptable > this can and should be checked during init or trellis quant should be > changed to support mjpeg Michael, I only sent the diff to highlight the issue not to suggest that this should be the fix or applied as a patch. I'm also all with you about adding the feature (though that won't be me ;S), but then, if the encoders are not required to put a value there (or perhaps they are and mjpeg just doesn't comply) the code shouldn't rely on it being filled. Anyway, perhaps the attached bit is more agreeable as a quickfix. Cheers, Karl.

3 2

seek with duration for cutting: broken or changed?
by lists＠rooseveltmedia.com 02 Nov '06

02 Nov '06

The following command used to work to cut a specific segment out of a video file on some FC3 machines I'm using with an old version of ffmpeg (still does work): ffmpeg -acodec copy -vcodec copy -i fullvideo.avi -ss 60 -t 120 choppedvideo.avi But it doesn't work anymore with Fedora Core 5 on a 64-bit machine running today's SVN copy of ffmpeg. (Also doesn't work with freshrpms latest ffmpeg rpm, either.) I believe what it's doing is seeking, but the duration is completely ignored. It just returns the rest of the file from where the seek took it. The resulting file is also a little "chirpy" -- the audio video sync is messed up somehow. If I take out the "-acodec copy" and "-vcodec copy" options, it performs correctly, except it re-encodes the video instead of just copying the data bit by bit with no reprocessing (which is much faster). That is, the seek and duration params work as they should, but it re-encodes rather than giving a direct stream copy. I'd like to get back to having seek and duration work while doing a direct stream copy. Anyone know why this has happened? Did the seek or duration options change? Why would copying vs. reencoding matter? Cyrus

3 7

[PATCH] MJPEG wrongly displayed with vertical YUV422
by Eric.Piel＠tremplin-utc.net 02 Nov '06

02 Nov '06

(please CC: me as I'm not subscribed to this mailing list) Hello, ffmpeg doesn't handle the mjpeg files with a "vertical" YUV422. Here is an example: * A fine video: http://pieleric.free.fr/ffmpeg/sevilla-mjpeg-yuv422h.avi (directly from my camera) * Mostly same video which "ffplay" displays with wrong colors: http://pieleric.free.fr/ffmpeg/sevilla-mjpeg-yuv422v.avi (lossless rotation of the previous file) (both files are 9 Mb) Actually there is even a comment in mjpeg.c which explains the problem : /* XXX: not complete test ! */ The test "switch((s->h_count[0] << 4) | s->v_count[0]) {" needs to also handle 0x12. Like 0x21, it's also YUV422 but this one is "vertical". The problem is that there is currently no PIX_FMT_* in ffmpeg which corresponds to this coding. So here is a patch (against SVN 5414) to add the support for this format. It adds the types PIX_FMT_YUV422VP and PIX_FMT_YUVJ422VP. With this patch I can correctly display both videos :-) Let me know if that's the right way to fix the bug. Also, I've added PIX_FMT_YUV*422VP to the minimum of places as possible, maybe I forgot some places... Eric PS: If anyone is interested I can provide my script to do lossless rotation on mjpeg movies ;-)

6 24

[PATCH] macro redefinition warning fix
by diego＠biurrun.de 01 Nov '06

01 Nov '06

Here's a fix for the following warning: ppc/mpegvideo_altivec.c:34:1: warning: "SWAP" redefined In file included from ppc/../dsputil.h:33, from ppc/mpegvideo_altivec.c:26: /Users/diegobiurrun/src/ffmpeg/libavutil/common.h:201:1: warning: this is the location of the previous definition I renamed the SWAP macro to SWAP_ALTIVEC. Probably a better solution would be to rename the SWAP macro in libavutil/common.h to FFSWAP. Thoughts? Diego

1 2

[PATCH] Support for bgr15/16 on imgconvert.c
by reynaldo＠opendot.cl 01 Nov '06

01 Nov '06

Hi there Currently imgconvert doesn't have support for bgr15/16, seemed easy to add some so here is a patch, hope to get some comments from you. Reynaldo

2 3