#1440 closed defect (fixed)
RC BS1+2: Crash while Video Playback (Windows)
| Reported by: | SF/florob | Owned by: | SF/ender |
|---|---|---|---|
| Priority: | blocker | Component: | Engine: Sword1 |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
With Broken Sword 1 + 2 Sould Out version ScummVM's current CVS crashes at some fixed points under WinXP for me. In BS1 it crashes in the intro when the balons fly in the screen and in BS2 when george falls in the chair. When these frames are skipped it doesn't crash when it would normally, but some frames later (BS1 shortly before the clown runs away). console output: WARNING: fnPlaySequence(4) called! Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Ticket imported from: #892827. Ticket imported from: bugs/1440.
Change History (17)
comment:1 by , 21 years ago
comment:2 by , 21 years ago
I'm not perfectly true I have but I think when they are "missencoded" it would be the fault of mencoder. I also thought it might be a bug in Sid mencoder-686 package but why would he always convert those frames wrong? Also I thin an SDL Parachute is not the way ScummVM should answer to missencoded files. But i don't really think mine are.
comment:3 by , 21 years ago
Try encoding at a different bitrate, to see if it helps. I was unable to reproduce the problem with the Broken Sword 1/2 cutscenes which I encoded at 2400kb. But I reproduced the error with the Broken Sword 1 demo cutscenes which I encoded at default bitrate. A back trace is below: 0x0052095a in Sword1::AnimationState::plotYUV(short*, int, int, unsigned char* const*) ( this=0x264c378, lut=0x2ff0020, width=640, height=400, dat=0x26517b0) at sword1/animation.cpp:269 269 ptr[linepos ] = lut[i + dat [0][ ypos ]]; (gdb) bt #0 0x0052095a in Sword1::AnimationState::plotYUV(short*, int, int, unsigned char* const*) ( this=0x264c378, lut=0x2ff0020, width=640, height=400, dat=0x26517b0) at sword1/animation.cpp:269 #1 0x00520b29 in Sword1::AnimationState::decodeFrame() (this=0x264c378) at sword1/animation.cpp:342 #2 0x00520c7a in Sword1::MoviePlayer::play(char const*) (this=0x22fc20, filename=0x50455a "intro") at sword1/animation.cpp:397 #3 0x00504629 in Sword1::Logic::fnPlaySequence (Sword1::Object*, int, int, int, int, int, int, int) (this=0x14a2908, cpt=0x0, id=0, sequenceId=4, d=0, e=0, f=0, z=0, x=0) at sword1/logic.cpp:937
comment:4 by , 21 years ago
It works encoded at 2400kb, but I leave this open 'cause I think it is not a good behavior to crash. But you can close it if you want to.
comment:5 by , 21 years ago
Closing this, as we are not supporting self-encoded cutscenes. (Feel free to submit a patch to fix the bug, however).
comment:6 by , 21 years ago
| Owner: | set to |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
comment:8 by , 21 years ago
| Owner: | removed |
|---|---|
| Resolution: | wontfix |
| Status: | closed → new |
comment:9 by , 21 years ago
| Summary: | BS1+2: Crash while Video Playback → RC BS1+2: Crash while Video Playback (Windows) |
|---|
comment:10 by , 21 years ago
This appears to only occur under Windows. I'm testing on a Mac now just to be sure.
comment:11 by , 21 years ago
| Priority: | normal → blocker |
|---|
comment:12 by , 21 years ago
Confirmed this to be a Windows only bug. Increasing priority as Release Critical.
Unfortunatly, I have no idea at all how to fix it :P
comment:13 by , 21 years ago
I don't understand why it only happens with Windows, and I don't understand exactly what's happening, but it should be pretty easy to work around. The end result, and thus the direct cause of the crash, is an out-of-bounds access to the YUV-to-RGB lookup table.
I changed the code in plotYUV() to:
int u = (dat[1][cpos] + ROUNDADD) >> SHIFT; int v = (dat[2][cpos] + ROUNDADD) >> SHIFT; if (u >= BITDEPTH) u = BITDEPTH - 1; if (v >= BITDEPTH) v = BITDEPTH - 1; int i = ((v * BITDEPTH) + u) * 256; // int i = ((((dat[2][cpos] + ROUNDADD) >> SHIFT) * BITDEPTH) + ((dat[1][cpos] + ROUNDADD) >> SHIFT)) * 256;
Since I don't actually know which of the dat[] buffers contain Y, U and V, I'm not sure if my variable names make sense, and it'd be nicer if the code didn't explicitly have to test for overflow... but you get the idea.
As I said, I have no clue why the problem doesn't happen on every platform.
comment:14 by , 21 years ago
Please note that when I said that I changed the code, I meant in my local copy of it. I haven't committed any such changes to CVS.
comment:15 by , 21 years ago
*nods*
Roever just made a slightly difference fix which is now applied to CVS (head and branch). Closing bug.
comment:16 by , 21 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:17 by , 6 years ago
| Component: | → Engine: Sword1 |
|---|
Are you sure you encoded the cutscenes correctly ? I get no crashes in those cutscenes when using latest ScummVM CVS under Windows XP. There were a few cutscenes fixes recently but just for some issues with end of cutscenes and 640 x 480 cutscenes.