libvlc_new lock

[d3x0r]

Every once in a while, I'll create a new surface, create a new vlc_inst on it, and the libvlc_new() will never return.

this is the sort of line I'm passing to libvlc_init

--verbose=2 -I dummy --ignore-config --no-osd --noaudio --no-skip-frames --plugin-path=e:\tools\vlc-0.9.6\plugins --file-caching=0 --vmem-data=14311312 --vmem-width=165 --vmem-height=152 --vmem-pitch=-660 --vmem-chroma=RV32 --vmem-lock=1866019952 --vmem-unlock=1866020448 --vout=vmem

I am simultaneously playing other videos on other surfaces, it's not near the end, when they're closing, just in the middle of 1 maybe 2, maybe 10 others playing... and if I keep them playing, hitting each start button to start a new video, it may take 15-20 restarts to get one that hangs...

Seems like a awful lot of work to attach a whole vlc instance to a surface... wouldn't just a player attachment be more reasonable? I could then use the same sort of instance to run multiple players? but I guess really you end up with only one player per instance? I'm getting confused thinking about this on my own so much..

[d3x0r]

I was going to retract some, and say, mostly it's when I run under visual studio in debugging mode... but after I cleaned up some of my logging, the problem returned just a prevailantly without running in the debugger... there's no identifiable consistancy about when I can't create a libvlc_new() instance.

[Beardless2]

I too have these problems in both VB and Delphi in every version of vlc so far (including 0.9.8a)

I dynamically create 2 or 3 vlc when a application starts up, and sometimes its fine....but more often than not the app will freeze when it is creating one of the vlc's. However a more troublesome problem i have is shutting down the app, as nearly everytime i do this the app will freeze and i will have to kill it in task manager! something doesn't right in the create and destroy routines - for multiple vlc anyway.

[d3x0r]

Yeah shutdown has occasionally been a bother... I do go through all players and issue stops, and then release all before exiting, and usually as long as I clean everything well, exit happens alright... sometimes, though, exit goes too far and some threads are not shut down correctly... The bigger issue was that the player release needs to be the same thread as the creator (at least if it is, you have less of a chance of locking up)...

Actually for all of my players, I am creating a thread, that creates the instance, player, etc, does the start, waits for the finish, then cleans up everthing when completed. Definatly if all the videos play to completion before exiting, I have 0 problems... other than the occasional deadlock on libvlc_new()

[Beardless2]

i think your right - issuing stops before destroying the vlcs seems to make it more stable when closing an app.

Its still hangs occasionally, but no where near as much.

Problems i still have is i can create 3/4 vlcs on start up no problem, then when i set them all going (i.e. on a button click event) the first 2 start fine, but the 3rd or 4th will hang which in turn hangs the entire program. Do you do a DoEvents / Process messages / Sleep(1000) etc to allow vlc to do things in the back ground in other threads after each call to vlc? (i.e. play / stop etc)

[ericlee26]

Hi all,

I have the problem of VLC hang too.

I used VS2005 and created a win32 application. I used the concept of sample codes from http://wiki.videolan.org/LibVLC_Tutorial.

I will set a timer to let Vlc play and stop periodically.

Sometimes, my program hangs in libvlc_media_player_stop (mp, &ex).

When I trace VLC source codes, I found it hangs at GetMessage, EventThread() in modules/video_output/msw/events.c.

I found that if i do not let Vlc get any message (including Mouse, Keyboard), VLC will "not hang" any more.

Could someone help me? I will appreciate very much.

PS. VLC VERSION: 0.9.8a

[Beardless2]

Hi,

Please can a developer take a look at these issues? I can confirm vlc seems to itermittently hang on libvlc_new and libvlc_media_player_stop calls to the dll?

Chris

[d3x0r]

In the case of the vs2005 application, windows is really really sensitive about the right thread getting messages associated with window handles... are you sure you're dispatching the _stop with the same thread you created the player with?

[Beardless2]

Yes - everything is in one thread (the main app) from my end.

Its more of a problem when i have 4 vlcs in the app all play videos, and then i cycle them and stop them all, it will normally fail on the 2nd or 3rd stop command.

This is the Delphi code but its the same for VB, where MediaPlayer is a wrapper class for libvlc_media_player

procedure TMainForm.ButtonStopClick(Sender: TObject);
Var
i : integer;
Begin
For i := 1 to NumVLC do
MediaPlayer.Stop;
End;

[erj]

When I trace VLC source codes, I found it hangs at GetMessage, EventThread() in modules/video_output/msw/events.c.

I found that if i do not let Vlc get any message (including Mouse, Keyboard), VLC will "not hang" any more.

Could someone help me? I will appreciate very much.

PS. VLC VERSION: 0.9.8a

Eric,

How did you find the location of this and how did you keep messages from getting to VLC? I don't suppose you have any quick test code for this situation.

I am experiencing the same freezing issue. Since I don't care about any of the keyboard / mouse functionality of the player window I was looking at this as an option but am not sure how to keep these messages from getting through. I even went so far as to remove the GetMessage() looping code from the EventThread() in events.c changing it to:

Code: Select all

while( vlc_object_alive (p_event) ) { // Sleep to keep thread from being greedy Sleep( 20 ); } /* End Main loop */

but still experienced freezes.

Thank you in advance,
Ehren

[erj]

Continuing my investigation I did find that we are locking up in our event loop in the directx / direct3d events.c. On a vlc_mediaplayer_stop I traced through the code and found that we successfully enter CloseVideo() in direct3d.c. We perform our vlc_object_kill and we send off our dummy PostMessage to wake up the event thread. However when we vlc_thread_join() on the event thread we never return. It seems like our loop in the event thread gets stuck.

In trying to fix this issue I tried changing our GetMessage() call to a PeekMessage() call in case we were just never receiving a message to quit. However, this also locked up. Looking at the documentation for PeekMessage and GetMessage it seems like the first call they make is to dispatch incoming sent messages which could call SendMessage which can create a thread lock situation if a child window and parent window exist in different threads.

There are some discussions on this:
http://www.eggheadcafe.com/software/asp ... ow-in.aspx
http://www.microsoft.com/communities/ne ... &sloc=&p=1

If this is causing the lockup I don't really know how the issue can be fixed without allowing the client to create the directx windows in the application main thread and passing them to the vout.

[Beardless2]

good work on the invesigation - giving a bump so this can get noticed

[Beardless2]

anyone know of any progress on this?

Looking at some debug code i notice when Libvlc_new does return successfully, it loads the libhotkeys_plugin.dll ok, but when it doesn't return its doesn't get to this point.....

[erj]

In continuation of my last post, after changing some stuff around so that vlc's direct3d windows are created in the same thread as the parent window it seems to get rid of the lockups. However, the code to do this is kinda messy and I don't know enough about win32 to do it differently (better / cleaner).

What I did is this:

In events.c:
- Defined a new message type

Code: Select all

#define WM_VLCWND_ASYNC (WM_USER + 5)

- Changed EventThread()

Code: Select all

void* EventThread( vlc_object_t *p_this ) { event_thread_t *p_event = (event_thread_t *)p_this; MSG msg; POINT old_mouse_pos = {0,0}, mouse_pos; vlc_value_t val; unsigned int i_width, i_height, i_x, i_y; HMODULE hkernel32; /* Initialisation */ p_event->p_vout->pf_control = Control; p_event->b_ready = FALSE; p_event->p_vout->p_sys->hparent = vout_RequestWindow( p_event->p_vout, &p_event->p_vout->p_sys->i_window_x, &p_event->p_vout->p_sys->i_window_y, &p_event->p_vout->p_sys->i_window_width, &p_event->p_vout->p_sys->i_window_height ); #ifndef UNDER_CE /* Set power management stuff */ if( (hkernel32 = GetModuleHandle( _T("KERNEL32") ) ) ) { ULONG (WINAPI* OurSetThreadExecutionState)( ULONG ); OurSetThreadExecutionState = (ULONG (WINAPI*)( ULONG )) GetProcAddress( hkernel32, _T("SetThreadExecutionState") ); if( OurSetThreadExecutionState ) /* Prevent monitor from powering off */ OurSetThreadExecutionState( ES_DISPLAY_REQUIRED | ES_CONTINUOUS ); else msg_Dbg( p_event, "no support for SetThreadExecutionState()" ); } #endif if ( p_event->p_vout->p_sys->hparent ) { PostMessage( p_event->p_vout->p_sys->hparent, WM_VLCWND_ASYNC, (WPARAM) &CreateChildWindowsProc, (LPARAM) p_event ); while ( !p_event->b_ready ) { msleep( 20000 ); } /* Signal the creation of the window */ vlc_thread_ready( p_event ); while( vlc_object_alive (p_event) ) { msleep( 50000 ); } /* clear the changes formerly signaled */ p_event->p_vout->p_sys->i_changes = 0; SetWindowLongPtr( p_event->p_vout->p_sys->hwnd, GWLP_USERDATA, NULL ); SetWindowLongPtr( p_event->p_vout->p_sys->hvideownd, GWLP_USERDATA, NULL ); SetWindowLongPtr( p_event->p_vout->p_sys->hparent, GWLP_USERDATA, NULL ); PostMessage( p_event->p_vout->p_sys->hparent, WM_VLCWND_ASYNC, (WPARAM) &DeleteChildWindowsProc, (LPARAM) p_event->p_vout->p_sys->hwnd ); p_event->p_vout->p_sys->hwnd = NULL; if( p_event->p_vout->p_sys->hfswnd ) { PostMessage( p_event->p_vout->p_sys->hparent, WM_VLCWND_ASYNC, (WPARAM) &DeleteChildWindowsProc, (LPARAM) p_event->p_vout->p_sys->hfswnd ); p_event->p_vout->p_sys->hfswnd = NULL; } if( p_event->p_vout->p_sys->hparent ) vout_ReleaseWindow( p_event->p_vout, (void *)p_event->p_vout->p_sys->hparent ); } else { if( DirectXCreateWindow( p_event->p_vout ) ) p_event->b_dead = true; /* Signal the creation of the window */ vlc_thread_ready( p_event ); /* Main loop */ /* GetMessage will sleep if there's no message in the queue */ while( vlc_object_alive (p_event) && GetMessage( &msg, 0, 0, 0 ) ) ...

- Added message callback handlers

Code: Select all

/***************************************************************************** * CreateChildWindowsProc: callback procedure to setup windows in case of * specified parent window. ***************************************************************************** * We need to create child windows in the same thread as parent to ensure * we don't get arbitrary locks when stopping video threads. *****************************************************************************/ static long FAR PASCAL CreateChildWindowsProc( HWND hWnd, UINT Msg, ULONG_PTR dwData, LRESULT lResult ) { event_thread_t * p_event = (event_thread_t *) dwData; DirectXCreateWindow( p_event->p_vout ); p_event->b_ready = TRUE; return 0; } /***************************************************************************** * DeleteChildWindowsProc: callback procedure to remove windows. ***************************************************************************** * We need to destroy child windows in the same thread as parent to ensure * we don't get arbitrary locks when stopping video threads. *****************************************************************************/ static long FAR PASCAL DeleteChildWindowsProc( HWND hWnd, UINT Msg, ULONG_PTR dwData, LRESULT lResult ) { HWND myHwnd = (HWND) dwData; if( myHwnd && IsWindow( myHwnd ) ) { DestroyWindow( myHwnd ); } return 0; }

In my code:
- Added message handler for vlc messages

Code: Select all

LRESULT CVLCTest::OnVlcAsync(WPARAM wParam, LPARAM lParam) { SENDASYNCPROC proc_async = (SENDASYNCPROC) wParam; proc_async(0, 0, (ULONG_PTR)lParam, 0); return 0; }

Pretty much what I am doing is posting messages to my program to create the windows in the main application thread. Like you can see above it is a complete mess but it does solve the issues of locking up. Someone who is better with win32 programming can probably figure out what the issue with the locking condition but the above does fix the issue.

[d3x0r]

My player, surface, and all commands to that surface are in the same thread. While it is very true that your display surface, and all commands you do to the video player must be in the same thread, this does not overcome the occasional libvlc_new() never return lockup... I should investigate this more and check how far it does get... need to seperate the logs too - maybe it's stderr that's locking or something.

[erj]

My code above refers to the issue of calling the libvlc_mediaplayer_stop() command, not the libvlc_new().

In regards to the stop(), how you thread you application is irrelevant unfortunately...has to do with how the DirectX / Direct3D / WindowsGL drivers work. What happens is that they start an event thread to handle window message processing (events.c). This creates child windows that it places in the passed in hwnd (setdrawable()). So, the way it is written the child window will always be in a separate thread from the parent window.

What my hacky code above does it to move the video_output plugin window creation back to the main application thread by having the plugin do a PostMessage() to the thread of the hwnd. Problem is that you then have to implement that callback process in your own code to call the creation code. The way I did it in my code was to pass the function pointer and the p_event object to PostMessage(). That way the DirectXCreateWindow() is called from the application thread instead of its own thread.

[ivoire]

Could you try with the git version of vlc as a lot of rework has been done.

[Beardless2]

Hi - Happy to try the latest version but with the nightly builds being down at the moment, would it be posible for you to post a link to the latest exe? (sorry im not very good with GIT - unless you can walk me through it?....)

[Rémi Denis-Courmont]

The nightly builds are offline due to an hardware failure. You have to build yourself.

[Rémi Denis-Courmont]

With neither logs nor stack traces, we won't get far.

[Beardless2]

sorry remi - i dont know how to build vlc myself, any idea when the nighties server might be back up? or can u email me a compiled v1.0.0 exe?

[Rémi Denis-Courmont]

Nightlies are not much suited for tracing anyway. And no, I don't build windows binaries.

[Beardless2]

ok i have tested with vlc 1.0.0 GIT and the libvlc_new and libvlc_media_player_stop locks appear to have been fixed.

However, when i play a video they always open in a separate window with "VLC (Direct3d Output)" on the caption instead of the windows handle i gave it.

i fixed this by using the libvlc_media_player_set_hwnd call instead of the libvlc_media_player_set_drawable (guessing it is now deprecated?)

So all is good i would say except there does not appear to be a libvlc_media_player_get_hwnd function for libvlc in the documentation?

[Rémi Denis-Courmont]

No there is no get_hwnd. We could add it if needed. But the application gaves the handle, so it probably knows what the handle is already.

[Beardless2]

i would say if it is not too much work then please add it as for me get and set functions should really go together.

My vlc's are placed onto docking windows and whenever i dock/undock them, the handle of the window changes and so vlc stops playing. To get around this problem i compare the handle currently assigned to vlc (using libvlc_media_player_get_drawable) to the to the new handle of my docking window and if they are different i call the libvlc_media_player_set_hwnd and restart the video again.

Im sure there may well be another way but using the get function to return the handle seemed easiest to me.