Opened 20 years ago

Closed 20 years ago

Last modified 5 years ago

#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 Kirben, 20 years ago

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.

comment:2 by SF/florob, 20 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 Kirben, 20 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 SF/florob, 20 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 SF/ender, 20 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 SF/ender, 20 years ago

Owner: set to SF/ender
Resolution: wontfix
Status: newclosed

comment:7 by Kirben, 20 years ago

Re-opening, as it occurs with official BS1 cutscene pack too.

comment:8 by Kirben, 20 years ago

Owner: SF/ender removed
Resolution: wontfix
Status: closednew

comment:9 by SF/ender, 20 years ago

Summary: BS1+2: Crash while Video PlaybackRC BS1+2: Crash while Video Playback (Windows)

comment:10 by SF/ender, 20 years ago

This appears to only occur under Windows. I'm testing on a Mac now just to be sure.

comment:11 by SF/ender, 20 years ago

Priority: normalblocker

comment:12 by SF/ender, 20 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 eriktorbjorn, 20 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 eriktorbjorn, 20 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 SF/ender, 20 years ago

*nods*

Roever just made a slightly difference fix which is now applied to CVS (head and branch). Closing bug.

comment:16 by SF/ender, 20 years ago

Owner: set to SF/ender
Resolution: fixed
Status: newclosed

comment:17 by digitall, 5 years ago

Component: Engine: Sword1
Note: See TracTickets for help on using tickets.