I think I have provided all the information required [http://wiki.videolan.org/Report_bugs] that is applicable to this case. Please indicate any additional information that might be needed.
Attaching to process 4340[New Thread 4340.0x144][New Thread 4340.0x574][New Thread 4340.0x13ec][New Thread 4340.0x1110][New Thread 4340.0x1754][New Thread 4340.0x1200][New Thread 4340.0xd98][New Thread 4340.0x7b0][New Thread 4340.0x13e4][New Thread 4340.0x14d4][New Thread 4340.0x120c][New Thread 4340.0x1454][New Thread 4340.0x136c][New Thread 4340.0x644][New Thread 4340.0x464]Reading symbols from C:\gcc\repos\vlc-2.2.2\vlc.exe...done.warning: Could not load shared library symbols for C:\Program Files\NVIDIA Corporation\CoProcManager\_etoured.dll.Do you need "set solib-search-path" or "set sysroot"?0x0000000077250591 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dllContinuing.[Thread 4340.0x464 exited with code 0]gdb: Target exception STATUS_INTEGER_DIVIDE_BY_ZERO at 0x52ef5676Program received signal SIGFPE, Arithmetic exception.[Switching to Thread 4340.0x644]0x0000000052ef5676 in transcode_video_encoder_init ( p_stream=p_stream@entry=0x28fb420, id=id@entry=0x3ba3420) at ../../../extras/package/win32/../../../modules/stream_out/transcode/video.c:551(gdb) bt[#0](https://code.videolan.org/videolan/vlc/-/issues/0) 0x0000000052ef5676 in transcode_video_encoder_init (p_stream=p_stream@entry=0x28fb420, id=id@entry=0x3ba3420) at ../../../extras/package/win32/../../../modules/stream_out/transcode/video.c:551[#1](https://code.videolan.org/videolan/vlc/-/issues/1) 0x0000000052ef5fac in transcode_video_process (p_stream=p_stream@entry=0x28fb420, id=id@entry=0x3ba3420, in=0x0, out=out@entry=0x631fd48) at ../../../extras/package/win32/../../../modules/stream_out/transcode/video.c:884[#2](https://code.videolan.org/videolan/vlc/-/issues/2) 0x0000000052ef15b0 in Send (p_stream=0x28fb420, id=0x3ba3420, p_buffer=<optimized out>) at ../../../extras/package/win32/../../../modules/stream_out/transcode/transcode.c:661[#3](https://code.videolan.org/videolan/vlc/-/issues/3) 0x000000005759a6c2 in sout_InputSendBuffer (p_input=0x3b61140, p_buffer=p_buffer@entry=0x3b5d050) at ../../extras/package/win32/../../../src/stream_output/stream_output.c:233[#4](https://code.videolan.org/videolan/vlc/-/issues/4) 0x0000000057535e18 in DecoderPlaySout (p_sout_block=0x3b5d050, p_dec=0x3c05540) at ../../extras/package/win32/../../../src/input/decoder.c:1501[#5](https://code.videolan.org/videolan/vlc/-/issues/5) DecoderProcessSout (p_block=0x0, p_dec=<optimized out>) at ../../extras/package/win32/../../../src/input/decoder.c:1556[#6](https://code.videolan.org/videolan/vlc/-/issues/6) DecoderProcess (p_block=<optimized out>, p_dec=<optimized out>) at ../../extras/package/win32/../../../src/input/decoder.c:1787[#7](https://code.videolan.org/videolan/vlc/-/issues/7) DecoderThread (p_data=0x3c05540) at ../../extras/package/win32/../../../src/input/decoder.c:909[#8](https://code.videolan.org/videolan/vlc/-/issues/8) 0x0000000057593d72 in vlc_entry (p=0x3b9a780) at ../../extras/package/win32/../../../src/win32/thread.c:473[#9](https://code.videolan.org/videolan/vlc/-/issues/9) 0x000007fefd6e415f in srand () from C:\Windows\system32\msvcrt.dll[#10](https://code.videolan.org/videolan/vlc/-/issues/10) 0x000007fefd6e6ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll[#11](https://code.videolan.org/videolan/vlc/-/issues/11) 0x0000000076ff59ed in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll[#12](https://code.videolan.org/videolan/vlc/-/issues/12) 0x000000007722c541 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll[#13](https://code.videolan.org/videolan/vlc/-/issues/13) 0x0000000000000000 in ?? ()Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Do you mean that the 2.2.1 Windows 64 release corresponds to branch where the change in the way frame rates are managed in transcoding that was committed in Nov 2014, had not been merged?
Is the commit already merged? Shall next release have the issue corrected?
with 2.2.2 and 3.0.0 from the nightly build server
it seems that 2.1.5 is the last build it worked.
couldn't check 2.1.6 as there is no win64 installation on the server.
and it's not working on 2.2.0
with 2.2.2 and 3.0.0 from the nightly build server
it seems that 2.1.5 is the last build it worked.
couldn't check 2.1.6 as there is no win64 installation on the server.
and it's not working on 2.2.0
Same here on windows 10 x64. Public builds 2.2.1/2.2.2 not working and 2.1.5 works just fine. Any progress on this?
I have the same problem on two different computers (both Windows 7 x64 German, both NVidia graphic cards with different GPUs). Just some additional information on this:
When screen recording is done just using RAW-format (without any compression), it works. The recorded video can be converted afterwards using VLC and using the preferred compression without any problem. I was using the screen-left option set to -1920 any time VLC crashed.
Hello,
We are experiencing the same problem here on several VLC versions, including 2.2.3.
Crashes at each attempt on both 32bits and 64bits windows 7 installations.
It looks like the bug was identified as a "divided by zero" exception ?
Is there anything I could provide that would help to get this fixed ?
Thanks !
BTW, Ihave just tested the nightly build /build/win64/vlc-3.0.0-20160522-0401, and I do not met the issue anymore.
But in /build/win64/vlc-2.2.0-20160501-0302 still have the same issue.
Is there anychance that the fix will be implemented in the 2.2 serie?
Not sure what you mean by a backtrace. GDB stuff such as the one provided a few posts ahead by ssbssa ?
ssbssa pointed an issue with fps being 0 and used in a division:
id->i_output_frame_interval = id->p_encoder->fmt_in.video.i_frame_rate_base * CLOCK_FREQ / id->p_encoder->fmt_in.video.i_frame_rate;
where id->p_encoder->fmt_in.video.i_frame_rate is zero.
Indeed in the verbose logs I get I have the following maessage (v 2.2.3) :