BIK videos are (likely) broken about gemrb HOT 19 CLOSED

Currently not testable easily, due to SetOptions / #29.

from gemrb.

Listing works, the start too (files found), just nothing at all is drawn. Much easier to investigate now.

from gemrb.

nothing was event attempted to be drawn, since the BIKPlayer never sets validVideo to true.

--- a/gemrb/plugins/BIKPlayer/BIKPlayer.cpp
+++ b/gemrb/plugins/BIKPlayer/BIKPlayer.cpp
@@ -206,7 +206,8 @@ bool BIKPlayer::Open(DataStream* stream)
        if (memcmp( header.signature, BIK_SIGNATURE_DATA, 4 ) == 0) {
                if (ReadHeader()==0) {
                        sound_init( core->GetAudioDrv()->CanPlay());
-                       return video_init() == 0;
+                       validVideo = video_init() == 0;
+                       return validVideo;
                }
        }
        return false;

Doing that made the sound play, but the videos with the subs crashed in subs, so two things to look deeper into. No more time today though.

from gemrb.

Some more progress, it's not drawn due to an invalid buffer (size 0,0), which then screws up the offsets. CopyPixels gets called just about three times, but that could be a side-effect of debugging, since it causes lag that the plugin tries to compensate.

from gemrb.

Ah, we're not setting the player height and width. With that out of the way, I get a proper frame drawn now and then. The mouse isn't disabled properly, as I get both crashes (in nondebug mode) with the buttonstates and I can hear the chance button feedback sound. So more to drill into and fix.

from gemrb.

I'm not sure what you mean about the mouse/buttons. the player window doesn't have any buttons on it and we don't want to disable the mouse. Assuming the video and window have the same dimensions all mouse input should be directed toward the MoviePlayerControls instance and all but mouse down (which stops the video) are discarded.

from gemrb.

It's on mouse move, the tracking assert. The button clicking is even simpler to reproduce, since you can just continue clicking where the play button was and the video will restart whenever you do.

from gemrb.

oh I forgot you were playing them from the video list rather than the initial launch

I don't know if it helps, but i pushed cf17603

from gemrb.

It helps in the sense that now it asserts as soon as you move the mouse. Interestingly enough, this doesn't happen for bg2 videos.
The assert is the IsVisible one in Window::DispatchEvent. The first one or two superviews are visible, but the last/top isn't, so the whole thing reduces to false.

Is there a good way to find which views are in play? Besides guessing through their frame dimensions. Just from the count it seems like the event isn't even going to the movie window, but still the one underneath.

from gemrb.

The best way I can think of is to activate a breakpoint in View::SubviewAt at return v once you hit one at target = SubviewAt(ConvertPointFromScreen(screenPos), false, true)

I probably should have added some visual debugging aides for this long ago like i did with the text stuff.

It is easy to tell if it is the movie window or not tho: dump window->contentView->subviews and see if that list contains MoviePlayerControls (or log the address when the window is created in Interface::PlayMovie).

I agree, it does sound like its somehow being dispatched to the window beneath. SetCutSceneMode hides the gui so maybe that is how things are becoming invisible, maybe we aren't checking window visibility before dispatching events to it?

from gemrb.

I compared pointers and it's true, no controls, it must be the old window. Then I noticed bg2 still has a duplicate script for this, not using the one in guiopt as iwd2 and got sidetracked in some cleanup.

But it probably won't matter for this, even if they all end up using the same script code. Trying a playmovie right on load of onload of start.py produces the same results — only some frames now and then. At least it doesn't crash there.

from gemrb.

Looking deeper into BIK internals yielded nothing. I also tried disabling the gamewindow blacking and movie control creation, but nothing relevant changed.

A different CopyPixels is used than for MVE, so I can only conclude something opaque goes wrong there or that we're using SDL_DisplayYUVOverlay badly. Creation of the overlay looks fine. RenderOnDisplay too, even with the extra blit enabled. I don't think anything per se is wrong in the BIK player any more, as I can still get a proper frame drawn now and then by badly reproducible means like minimising and restoring the window.

from gemrb.

I can install IWD2 later and have a look.

my initial thought is something funny SDL does if you do something like SDL_DisplayYUVOverlay followed by a SDL_BlitSurface to the display buffer. I'll have to checkout master and verify our usage of SDL_DisplayYUVOverlay

from gemrb.

still haven't downloaded IWD2, but I'm hopeful that fixes things

from gemrb.

It crashes now in SwapBuffers due to memory corruption. I'll check with valgrind later.

from gemrb.

maybe it's through the cast and the involved constructor (calling Clear()): VideoBuffer doesn't have a buffer member, only SDLSurfaceVideoBuffer does. So vb has random garbage in that member. Not that RenderOnDisplay uses it (vb->RenderOnDisplay is where it crashes).

Valgrind shuts down a call earlier than gdb:

==11660== Jump to the invalid address stated on the next line
==11660== at 0x0: ???
==11660== by 0x50213BD: GemRB::Video::SwapBuffers(int) (Video.cpp:132)
==11660== by 0x4FE5B07: GemRB::MoviePlayer::Play(GemRB::Window*) (MoviePlayer.cpp:78)
==11660== by 0x4FB1B47: GemRB::Interface::PlayMovie(char const*) (Interface.cpp:2887)
==11660== by 0x125D4029: GemRB_PlayMovie(_object*, _object*) (GUIScript.cpp:4258)
==11660== by 0x128AB0A0: PyEval_EvalFrameEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11660== by 0x12A1216B: PyEval_EvalCodeEx (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11660== by 0x129665BF: ??? (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11660== by 0x128FE552: PyObject_Call (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11660== by 0x12A11596: PyEval_CallObjectWithKeywords (in /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0)
==11660== by 0x125EAC9B: bool GemRB::CallPython<int, &(int GemRB::noop(_object*))>(_object*, _object*, int*) (PythonCallbacks.h:47)
==11660== by 0x125E9CED: GemRB::CallPython(_object*, _object*) (PythonCallbacks.h:67)
==11660== Address 0x0 is not stack'd, malloc'd or (recently) free'd

from gemrb.

The last commit fixed this, the video plays again, but the same way — audio only and sometimes a frame sneaked in.

from gemrb.

Can confirm it renders now. 👍

The ones with subtitles still crash though, I'll look into it. They never worked before though, but aren't fatal in master.

from gemrb.

Ah, it's not related to BIK at all, also MVE crashes. Time for a separate bug.

from gemrb.