[BUG] Crash when playing FFv1 video too fast

[b-frame]

I've found a bug in VLC media player on Windows. Everytime I play a FFv1 video faster than the player can load / decode it, it crashes. It's reproduceable. Google found this old thread, where someone had the same probleme but didn't realize that it's a question of speed. So if you have a fast computer you'll probably never see vlc crash like this. I downloaded the file http://toenderup.de/ffv1.avi which has been uploaded by Rubi and I can perfectly reproduce it.

I was not able to send a crash report by the way. Since a few days vlc says, the FTP server isn't accessable:

---------------------------
Report sending failed
---------------------------
There was an error while connecting to the FTP server. Thanks a lot for the help anyway.
---------------------------
OK
---------------------------

So I looked for the crashdump file on my own and found it, but its size was only 3 Bytes. I guess it can't contain useful information.

OS: Windows Vista 32 bit
VLC version: 1.1.11
Intel Core 2 Duo E4700 2,6 GHz
AMD Radeon HD 5670

[Jean-Baptiste Kempf]

Hmm. Annoying. Does it play with ffplay faster?

[b-frame]

Stupid question: Could you give me an exact command line how to enable the ffplay-codec? I tried these two:

Code: Select all

vlc -vvv --codec ffplay ffv1.avi vlc -vvv --codec=ffplay ffv1.avi

In both cases, vlc still crashed and wrote this line into the log:

Code: Select all

avcodec debug: ffmpeg codec (FFMpeg Video 1) started

[Jean-Baptiste Kempf]

ffplay codecs? that means nothing.

[VLC_help]

I cannot replicate the crash with VLC 2.0.0-rc1

I tried with

Code: Select all

vlc --rate=32 ffv1.avi

no crash with my e7300

[b-frame]

Okay, now i realized that ffplay is a player and not a codec. So I downloaded and tried it. As there seems to be no option to speed up the playback in ffplay, I created a new, more complex ffv1 file which makes vlc crash even with 1.00x speed. (It has peak bitrates of > 180 MBit/s.) The Result: ffplay isn't able to play the file at normal speed (of course) but it doesn't crash and shows the video in slow motion. I wanted to upload the new file to the FTP-sample server, but I can't (or don't know how to) connect.

[b-frame]

I downloaded vlc 2.0 rc1 and it still crashes with the new file. The old file doesn't make it crash but I only see a black picture instead of the video.

[VLC_help]

Can you upload the problematic file to some file sharing service? Like to http://www.multiupload.com/

[b-frame]

Thank you for the link. Multiupload.com is currently not working but at least it gave me links to other filehosters. So here is the file:
http://www.fileserve.com/file/bZDMAng (265 MiB)

[VLC_help]

I'll check that file during weekend.

[VLC_help]

I tried with vlc-2.0.0-rc1-20120205-0203 using --rate=36 but I cannot get it to crash.

[b-frame]

Okay, I (re-)downloaded "vlc 2.0.0-rc1 Twoflower" version from http://download.videolan.org/pub/testin ... rc1/win32/. I'm not sure, whether this is the same version as "vlc-2.0.0-rc1-20120205-0203". I tested it both on Windows Vista and on Win XP. Here is the result:

Vista: The player doesn't really crash. It plays the video but you only get to see the first frame at best (all the other frames are dropped). When the time of the video is over, vlc still causes full cpu load on one core for a while (as if it catches up decoding the dropped frames). The memory behaviour of vlc is interesting during playback. First, vlc has a RAM consumption of about 6 MB. While the progress bar moves to the right, the memory consumption increases up to 170 MB. Then it decreases again to about 20 MB. Seems like vlc keeps dropped frames in memory until they're finally decoded after the playback time is over. When i set --rate=0.25, then I see more frames and the memory consumption reaches "only" about 60 MB peak. It is not possible to close vlc, before it's ready with this strange cleanup procedure.

XP: The player crashes like before and offers to send a bug report. This time, the bug report was succesful so it may help you. I submitted it at 18:27 in the time zone of Germany.

The VIsta computer is a real machine, whereas the XP system is simulated using VirtualBox. I can provide further details about the systems if you wish to, but I'm not sure whether this is relevant and don't wanna spam around.

[VLC_help]

You know GDB? Backtrace from the XP would be nice.

[b-frame]

Okay, this is the first time I used the GNU Debugger by command line. This is my output:

Code: Select all

Reading symbols from C:\Dokumente und Einstellungen\Administrator\Eigene Dateien \vlc-2.0.0-rc1\vlc.exe...(no debugging symbols found)...done. (gdb) run Starting program: C:\Dokumente und Einstellungen\Administrator\Eigene Dateien\vl c-2.0.0-rc1\vlc.exe [New Thread 1212.0x510] [New Thread 1212.0x528] [New Thread 1212.0x5f8] [New Thread 1212.0x618] [New Thread 1212.0x43c] [New Thread 1212.0x440] [New Thread 1212.0x19c] [New Thread 1212.0x494] [New Thread 1212.0x5b8] [New Thread 1212.0x2d4] [New Thread 1212.0x310] [New Thread 1212.0x428] [New Thread 1212.0x2cc] [New Thread 1212.0x2a0] [New Thread 1212.0x504] warning: SuspendThread failed. (winerr 5) Error in re-setting breakpoint -128: PC register is not available [New Thread 1212.0x780] [New Thread 1212.0x6c8] [New Thread 1212.0x140] [New Thread 1212.0x1b8] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1212.0x2a0] 0x03f6ad66 in wined3d!WineDirect3DCreateClipper () from C:\WINDOWS\system32\wined3d.dll

Hope it helps. If not, maybe you can tell me which additional parameters I should use to get more precise results.

[b-frame]

Looking at the GDB-output, i was wondering why the log talks about "wined3d". I know Wine is used on Linux systems to simulate WinAPI functions. If i remember correctly, VirtualBox also uses Wine to simulate DirectX API functions. So I got the idea of changing the video output method from "Standard" to "OpenGL", and *tatata* vlc doesn't crash any more. It behaves the same way as it does on Vista.