Blank white screen with VLCKit

[laserbeak]

Hi,

I've finally got this all buillt on OS X 10.6.5 x86_64 from the git archive, and I've compiled the Examples/test program. It kind of works, but I'm only getting audio no video, just a blank white area where the View should be.

Is this a problem with git using the latest bleeding-edge version? If so, how do I build an earlier known good version. I looked at the git tags, and it seems the last version tagged was 1.1.0, that doesn't seem right.

Can anyone offer any help?

Thanks

[rogerdpack]

any error messages?

[Technologicat]

I've finally got this all buillt on OS X 10.6.5 x86_64 from the git archive, and I've compiled the Examples/test program. It kind of works, but I'm only getting audio no video, just a blank white area where the View should be.

I'm experiencing the same problem. Same OS X version and architecture.

Reproducable both in the test app and in Lunettes. Both show only white in the video area. Could be a problem in VLCKit or some Mac-specific part of the core?

any error messages?

In my case at least, nothing in Console. Just a "<VLCmedia 0x1002ecba0> file://localhost/..." when the video file is opened.

When exiting, the test app logs an assertion failure saying "You released the media player before ensuring that it is stopped", but obviously this has nothing to do with the present problem.

Has anyone else run into this? Any ideas how to debug further?

[Technologicat]

Update. I ran the test app in the Xcode debugger. I may have found the problem. A parameter gets corrupted during initialization.

Yesterday's HEAD from git. Tracing in:

Code: Select all

#0 0x10014aeab in var_SetAddress [inlined] at vlc_variables.h:275 #1 0x10014aeab in libvlc_media_player_set_nsobject at media_player.c:842 #2 0x100011db4 in -[VLCMediaPlayer setDrawable:] at VLCMediaPlayer.m:256 #3 0x100013d8c in -[VLCMediaPlayer(Private) initWithDrawable:] at VLCMediaPlayer.m:731 #4 0x1000118fa in -[VLCMediaPlayer initWithVideoView:] at VLCMediaPlayer.m:194 #5 0x100000f67 in -[Controller awakeFromNib] at Controller.m:28

The setDrawable accessor calls libvlc_media_player_set_nsobject(). The pointers instance and aDrawable are valid at this point. The function libvlc_media_player_set_nsobject() passes on the drawable information (here's the whole function; __APPLE__ is defined):

Code: Select all

void libvlc_media_player_set_nsobject( libvlc_media_player_t *p_mi, void * drawable ) { assert (p_mi != NULL); #ifdef __APPLE__ var_SetAddress (p_mi, "drawable-nsobject", drawable); #else (void) p_mi; (void)drawable; #endif }

Again, the pointers p_mi and drawable are valid. Note that we also pass in a const char* "drawable-nsobject" denoting the name of the VLC property (for lack of a better name) that is being set.

The function var_SetAddress() (in vlc_variables.h) is simple enough:

Code: Select all

static inline int var_SetAddress( vlc_object_t *p_obj, const char *psz_name, void *ptr ) { vlc_value_t val; val.p_address = ptr; return var_SetChecked( p_obj, psz_name, VLC_VAR_ADDRESS, val ); }

Tracing into the var_SetChecked() line, the call stack changes to:

Code: Select all

#0 0x10014f448 in dyld_stub_var_SetChecked #1 0x100011db4 in -[VLCMediaPlayer setDrawable:] at VLCMediaPlayer.m:256 #2 0x100013d8c in -[VLCMediaPlayer(Private) initWithDrawable:] at VLCMediaPlayer.m:731 #3 0x1000118fa in -[VLCMediaPlayer initWithVideoView:] at VLCMediaPlayer.m:194 #4 0x100000f67 in -[Controller awakeFromNib] at Controller.m:28

The dyld_stub_ prefix sounds like something is getting dynamically loaded at this point...

Stepping in again, we get:

Code: Select all

#0 0x1000bb890 in var_SetChecked at variables.c:710 #1 0x100011db4 in -[VLCMediaPlayer setDrawable:] at VLCMediaPlayer.m:256 #2 0x100013d8c in -[VLCMediaPlayer(Private) initWithDrawable:] at VLCMediaPlayer.m:731 #3 0x1000118fa in -[VLCMediaPlayer initWithVideoView:] at VLCMediaPlayer.m:194 #4 0x100000f67 in -[Controller awakeFromNib] at Controller.m:28

Now something weird happens. The parameter psz_name gets corrupted before the actual function body of var_SetChecked() is entered. It looks like there's something going on behind the scenes. Thus, var_SetChecked() never gets the information that it was the "drawable-nsobject" that the caller wanted to set. The line

Code: Select all

p_var = Lookup( p_this, psz_name );

then returns NULL, and the drawable pointer never reaches the player. I suspect this is causing the blank white video output.

The code being run at this point is the following. C and disassembly provided. I've added numbers at the beginning of the C lines, corresponding to the numbers at the end of the lines in the disassembly.

Code: Select all

3 | int var_SetChecked( vlc_object_t *p_this, const char *psz_name, 2 | int expected_type, vlc_value_t val ) 1 | { 4 | int i_ret = VLC_SUCCESS; | variable_t *p_var; | vlc_value_t oldval; | | // ...etc...

Disassembly:

Code: Select all

0x00000001000bb890 <+0000> push %rbp <--- 1, beginning of call 0x00000001000bb891 <+0001> mov %rsp,%rbp 0x00000001000bb894 <+0004> push %r15 0x00000001000bb896 <+0006> push %r14 0x00000001000bb898 <+0008> push %r13 0x00000001000bb89a <+0010> push %r12 0x00000001000bb89c <+0012> push %rbx 0x00000001000bb89d <+0013> sub $0x38,%rsp 0x00000001000bb8a1 <+0017> mov %edx,%ebx 0x00000001000bb8a3 <+0019> mov %rsi,-0x60(%rbp) <--- 2, executing this instruction corrupts psz_name 0x00000001000bb8a7 <+0023> mov %rdi,%r14 <--- 3, now psz_name is corrupt but other parameters are fine 0x00000001000bb8aa <+0026> mov %rcx,-0x50(%rbp) <--- 4, function body entered 0x00000001000bb8ae <+0030> test %r14,%r14 0x00000001000bb8b1 <+0033> je 0x1000bba34 <var_SetChecked+420>

Specifically speaking, on the line marked "2", the memory address that psz_name points to gets changed. Originally it is, for example, 0x1001505d1, and after the line it becomes 0x7fff5fbfef20 (both actual numbers from a debug trace). According to the debugger, the new address contains garbage data (random-looking bytes).

Forcing the original address back using the debugger causes EXC_BAD_ACCESS, so I assume a remapping is indeed supposed to take place - but for some reason, it fails to work properly.

The question now is, what exactly happens here? I built the VLC library from these exact sources, so it can't be a version mismatch between the headers and the lib. A bug in the optimizer is not possible, either, since this is a debug build.

So, I guess this boils down to two possibilities:

• My build of VLC is still somehow broken (but how?)
• Something has changed in OS X 10.6.5, causing the breakage.

Any suggestions?

[sculi2000]

I'm experiencing the same thing and I'm giving it a go on trying to fix it. It's a bit daunting as I'm just looking at the VLC codebase for the first time. A sense of adventure seems essential. As does a sense of humor.

The first thing I can tell you is I'm not sure why you were seeing what you were seeing, but var_SetChecked() gets the correct info in my build. And I'm still getting the white screen of sadness like yourself, so it doesn't seem to have anything to do with drawable-nsobject corruption.

I was cautiously optimistic that by enabling verbose logging it would point me somewhere...anywhere...but there were no errors to be found. Does anyone have any idea when this bug was introduced? Seems like a reasonable way to attack this is to figure out which commit to the main branch caused this problem. Once that commit is identified, there would be some context to figure out how that commit might have affected the video output for the Mac.

[Technologicat]

I'm experiencing the same thing and I'm giving it a go on trying to fix it.

Nice.

It's a bit daunting as I'm just looking at the VLC codebase for the first time. A sense of adventure seems essential. As does a sense of humor.

Yeah :)

The first thing I can tell you is I'm not sure why you were seeing what you were seeing, but var_SetChecked() gets the correct info in my build. And I'm still getting the white screen of sadness like yourself, so it doesn't seem to have anything to do with drawable-nsobject corruption.

Ok, I might be doing something wrong...

I was cautiously optimistic that by enabling verbose logging it would point me somewhere...anywhere...but there were no errors to be found. Does anyone have any idea when this bug was introduced? Seems like a reasonable way to attack this is to figure out which commit to the main branch caused this problem. Once that commit is identified, there would be some context to figure out how that commit might have affected the video output for the Mac.

Sounds like a good strategy.

In another thread, j-b suggested that this might have something to do with the vout changes in 1.2-git (compared to 1.1.x). I haven't heard anything more specific, so I suppose no one knows at the moment.

I'm interested in getting this working, too, so that I could try my new IVTC filter (which works at least on Linux) on the Mac. I'm also new to the VLC codebase - I'm familiar with the deinterlacer module and some PTS computation stuff (which I needed to develop my filter and add repeat_pict support to the deinterlacers), but basically that's it.

[sculi2000]

Well I'm not sure how successful my strategy is going to be. I've been working backwards and it seems as if the daily VLC code snapshots have had this bug all the way back to Nov. 9th 2010. Prior to Nov. 9th, there was at least 7 or 8 weeks (maybe longer...I stopped checking around early September code snapshots) that the VLC code snapshots wouldn't build on the Mac at all because in the modules/video_outputs folder, the macosx.m implementation referenced opengl.h and opengl.h wasn't included in the daily code snapshots. To work, the build would have also needed to compile opengl.c (which wasn't in the code snapshots as well), but opengl.c wasn't included in any of the Makefiles. I'm assuming that the changes in the core happened during this time of build failure-dom. And since the builds failed for such a long time, it might prove to be a challenge to nail the one day that introduced the white bar bug.

In short, VLC 1.2 builds on the Mac have been hosed for a long, long time. Either by build failures or bugs. I'd read that the Mac version of VLC was suffering from a lack of resources, but man...I had no idea it was this bad.

Still determined to fix this problem, but now not feeling nearly as optimistic.

[sculi2000]

I believe I have got this narrowed down. Using the daily code snapshots that the VLC team makes available, my test app works with the November 8th snapshot (after I added a 1.5.5 version of opengl.h and opengl.c in modules/video_output) and doesn't work with the November 9th snapshot (which already had opengl.h and opengl.c in modules/video_output).

I diff'd the opengl.h that I was using from 1.5.5 with the one that was in the Nov. 9th daily code snapshot and they were very different. This was true of opengl.c as well. It seems reasonable to conclude at this point that the bug is somewhere in opengl.{h,c}.

Unfortunately, I'm not terribly familiar with OpenGL so it's hard to spot something that doesn't look right. Technologicat...do you have any experience with OpenGL?

[Technologicat]

Unfortunately, I'm not terribly familiar with OpenGL so it's hard to spot something that doesn't look right. Technologicat...do you have any experience with OpenGL?

No, I'm not familiar with OpenGL, either.

Maybe we should post about the issue on the vlc-devel mailing list (http://mailman.videolan.org/listinfo/vlc-devel)? Many devs don't read the forums, so it might help if we bring this to their attention (especially now that you've tracked down the misbehaving module). Do you want to post, or should I?

(Also, I suppose the Nov 9th snapshot is incompatible with opengl.[ch] from 1.5.5?)