search

kim42083 / webm

Automatically exported from code.google.com/p/webm
0 stars 0 forks source link

ffmpeg x64 libvpx crash #366

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
x64 builds of ffmpeg from here
http://ffmpeg.zeranoe.com/builds/
crash.  While 32 bit builds are ok.

Example command line
ffmpeg -y -loglevel 20 -threads 8 -pass 2 -profile 0 -level 217 -qmin 1 -qmax 
51 -slices 4 -rc_lookahead 16 -skip_threshold 0 -keyint_min 0 -g 250 -r 29.970 
-s 640x360 -i bear.640x360_30Hz_P420.yuv -vcodec libvpx -b 800000 -f matroska 
bear_tmp_0.mkv

Original issue reported on code.google.com by fbarch...@google.com on 11 Sep 2011 at 6:21

GoogleCodeExporter commented 9 years ago

Original comment by iss...@webmproject.org on 11 Sep 2011 at 6:30

GoogleCodeExporter commented 9 years ago 
Appears to be an old vpx release.  Perhaps the solution is for OP to try an 
up-to-date release.

Original comment by matthewj...@google.com on 12 Sep 2011 at 3:14

GoogleCodeExporter commented 9 years ago 
Can you provide a backtrace?

Original comment by rbul...@google.com on 12 Sep 2011 at 6:23

GoogleCodeExporter commented 9 years ago 
Re old release.
Can you try a mingw-64 build with latest libvpx/ffmpeg source?

Re callstack
Using
http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-git-6fc1299-win64-static.7z

Unhandled exception at 0x00c292b2 in ffmpeg.exe: 0xC0000005: Access violation 
writing location 0x00000000000002a0.

Callstack not useful:
>   ffmpeg.exe!0000000000c292b2()   
    [Frames below may be incorrect and/or missing, no symbols loaded for ffmpeg.exe]    
    0000000003a2f2e0()  
    0000000003a4f7e0()  
    0000000003a2f2e0()  
    0000000004265550()  
    00000000000002a0()  
    0000000003a4f7e0()  
    0000000003a2f2e0()  
    0000000003a30dd0()  
    ffmpeg.exe!0000000000c15b96()   
    ffmpeg.exe!0000000000bdfc06()   
    ffmpeg.exe!0000000000bbbb03()   
    ffmpeg.exe!0000000000bb9c45()   
    ffmpeg.exe!0000000000baf146()   
    ffmpeg.exe!0000000000bb0b7d()   
    ffmpeg.exe!0000000000792906()   
    ffmpeg.exe!00000000004f6a80()   
    ffmpeg.exe!0000000000403fcb()   
    ffmpeg.exe!00000000004079c1()   
    ffmpeg.exe!0000000000e833e2()   
    ffmpeg.exe!00000000004013e0()   
    ffmpeg.exe!0000000000401538()   
    kernel32.dll!000000007718f33d()     
    ntdll.dll!00000000773c2cc1()    

This is the function that crashes
0000000000C29280  push        rbp  
0000000000C29281  mov         rbp,rsp 
0000000000C29284  push        rdi  
0000000000C29285  push        rsi  
0000000000C29286  push        rdx  
0000000000C29287  push        rcx  
0000000000C29288  push        r8   
0000000000C2928A  push        rsi  
0000000000C2928B  push        rdi  
0000000000C2928C  mov         rdi,qword ptr [rbp-18h] 
0000000000C29290  mov         rax,qword ptr [rbp-20h] 
0000000000C29294  mov         rsi,qword ptr [rbp-8] 
0000000000C29298  movsxd      rdx,dword ptr [rbp-10h] 
0000000000C2929C  movsxd      rcx,dword ptr [rbp-28h] 
0000000000C292A0  pxor        mm7,mm7 
0000000000C292A3  movd        mm0,dword ptr [rsi] 
0000000000C292A6  movd        mm1,dword ptr [rax] 
0000000000C292A9  punpcklbw   mm0,mm7 
0000000000C292AC  punpcklbw   mm1,mm7 
0000000000C292AF  psubw       mm0,mm1 
0000000000C292B2  movq        mmword ptr [rdi],mm0   <--------- here
0000000000C292B5  movd        mm0,dword ptr [rsi+rdx] 
0000000000C292B9  movd        mm1,dword ptr [rax+rcx] 
0000000000C292BD  punpcklbw   mm0,mm7 
0000000000C292C0  punpcklbw   mm1,mm7 
0000000000C292C3  psubw       mm0,mm1 
0000000000C292C6  movq        mmword ptr [rdi+rcx*2],mm0 
0000000000C292CA  movd        mm0,dword ptr [rsi+rdx*2] 
0000000000C292CE  movd        mm1,dword ptr [rax+rcx*2] 
0000000000C292D2  punpcklbw   mm0,mm7 
0000000000C292D5  punpcklbw   mm1,mm7 
0000000000C292D8  psubw       mm0,mm1 
0000000000C292DB  movq        mmword ptr [rdi+rcx*4],mm0 
0000000000C292DF  lea         rsi,[rsi+rdx*2] 
0000000000C292E3  lea         rcx,[rcx+rcx*2] 
0000000000C292E7  movd        mm0,dword ptr [rsi+rdx] 
0000000000C292EB  movd        mm1,dword ptr [rax+rcx] 
0000000000C292EF  punpcklbw   mm0,mm7 
0000000000C292F2  punpcklbw   mm1,mm7 
0000000000C292F5  psubw       mm0,mm1 
0000000000C292F8  movq        mmword ptr [rdi+rcx*2],mm0 
0000000000C292FC  pop         rdi  
0000000000C292FD  pop         rsi  
0000000000C292FE  mov         rsp,rbp 
0000000000C29301  pop         rbp  
0000000000C29302  ret              

RAX = 0000000004265550 RBX = 0000000003A2F920 
RCX = 0000000003A2F2E0 RDX = 0000000003A4F7E0 
RSI = 0000000003A2F2E0 RDI = 00000000000002A0 
R8  = 0000000003A2F2E0 R9  = 0000000003A305F0 
R10 = 0000000003A30298 R11 = 0000000000810000 
R12 = 0000000000000000 R13 = 0000000003A3ED20 
R14 = 0000000000000000 R15 = 00000000042C57B8 
RIP = 0000000000C292B2 RSP = 000000000022D0B8 
RBP = 000000000022D0F0 EFL = 00010204 

00000000000002A0 = ???????????????? 

With this command line
ffmpeg -y              -threads 8 -pass 1 -profile 0 -vp8flags altref -speed 1 
-quality good -qmin 0 -qmax 63 -slices 4 -rc_lookahead 16 -skip_threshold 0 
-keyint_min 0 -g 250 -r 29.970 -s 640x360 -i bear.640x360_30Hz_P420.yuv -vcodec 
libvpx -b 800000 -f matroska bear_tmp_0.mkv

Original comment by fbarch...@google.com on 12 Sep 2011 at 9:38

GoogleCodeExporter commented 9 years ago 
Win64 has a different calling ABI than unix64, so I can't do anything with this 
bug until I get access to a Win64 box. Can you get me a backtrace with debug 
symbols?

Original comment by rbul...@google.com on 13 Sep 2011 at 4:30

GoogleCodeExporter commented 9 years ago 
I dont have mingw-64 installed.  James?

Original comment by fbarch...@google.com on 15 Sep 2011 at 10:26

GoogleCodeExporter commented 9 years ago

Original comment by rbul...@google.com on 19 Sep 2011 at 5:18

GoogleCodeExporter commented 9 years ago 
The crash comes in some logging when parameters are passed to incorrect formats 
due to:
 warning: unknown conversion type character 'z' in format
 warning: too many arguments for format

As noted on the mingw-w64 mailing list [1] this can be worked around by 
defining __USE_MINGW_ANSI_STDIO=1. The first warning will remain, but no crash 
will occur.

[1]: 
http://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg00400.html

Original comment by jz...@google.com on 24 Sep 2011 at 8:15

GoogleCodeExporter commented 9 years ago 
This is an issue with the mingw-w64 builds of ffmpeg. It can be addressed as 
mentioned so you might call it an ffmpeg configure bug.

Original comment by jz...@google.com on 12 Oct 2011 at 9:17

GoogleCodeExporter commented 9 years ago 
It can be addressed... but has it?
Its cross built from linux, so unclear if __USE_MINGW_ANSI_STDIO=1 is viable 
work around.
Would it not be easily avoided in vp8 by using different formatting?

Original comment by fbarch...@chromium.org on 13 Oct 2011 at 8:21