The VideoLAN Forums

Hi,

I prepare an App for tvOS using VLCKit. During testflight beta (about 30 people testing) I often get reports about poor playback performance, jittering video and audio and in worst case playback freezes.
What I found while inspecting the issues was:

Live-TV stream URL is reported as libvlc_media_type_file, not as libvlc_media_type_stream
This is not as expected, as the URL is looking like http://192.168.0.11:8001/1:0:19:283D:3FB:1:C00000:0:0:0:
This does not look like a file to me. VLCKit is just forwarding the media type info it receives from libVLC. Not sure, whether this could make a difference in playback performance and position changes are not available as expected, but this simply does not look correct.

several threads created through playback don't get released/joined
With the Debug navigator in Xcode I saw, that when I open a video for playback, I wait until playback has been started, then I stop playback and close the stream, the instance - whatever I can manually close and also I make sure the dealloc method of the mediaplayer gets invoked (setting myviewcontroller.mediaplayer to nil), some threads do not get released. Performing this multiple times (like zapping through the stations) more and more threads get into a deadlock state.
Research results are, that threads are waiting at _pthread_cond_wait(...), which in this case is called in vlc/src/playlist/thread.c Line 497. I took many stack backtraces (lldb: bt all) and at least one threads is getting locked there, sometimes multiple ones.
Another thread is deadlocked in [VLCEventManager startEventLoop](self=<unavailable>, _cmd=<unavailable>) + 296 at VLCEventManager.m:154, even the event manager should already have been released. (This might be VLCKit specific but not sure, VLCKit is just a wrapper around libVLC).

I finally was able to catch a stack backtraces during playback freeze
During these freezes, sometimes I can still close the player. For clsoing I stop playback, poll up to 1000 times with usleep(1000) waits, until the media property is changing to stopped before I actually try to release all items (media = nil, mediaplayer = nil, etc...). In case of freezes, I run into a timeout and try to close the player anyway. Unfortunately this leaves the stream open (which stops my STB to go to deep sleep power mode). When I then open a new player it works, often with jitters. But sometimes playback of the stream does not start or the App is not responsive at alland requires to a force quit.

Now just let me share the stack backtraces - Xcode is a bit buggy there.

1st backtrace before any player has been created. I use several threads to receive the XML information about Bouquets, TV stations, EPG Info etc. but all of these tasks should be completed already. 2nd backtrace after creating one player, watched playback for a few seconds, then close the player: 3rd backtrace later after multiple creations and releasings of media player, current playback freezing: I wanted to add a screenshot, but this is not available in this forum. The screenshot shows the numerous threads still opened. A few are really busy with stream decoding and playback, but more and more a idling. I once have seen, the app has created about 60 threads, and only 15 got released. Overall about 20 idling threads created by libVLC- after just 3 mediaplayer open & close cycles. Imagine to zap through 20 TV stations... would result in about 50+ idling threads that do not get stopped/joined.

Now I just was able to catch a backtrace while the playback freezed. I hope this helps to spot the deadlock.

Just for reference: I have created a ticket in trac: https://trac.videolan.org/vlc/ticket/16663

I just have seen the dead lock again.
Aside to the stack backtrace I inspect the locations, where the threads are waiting:

--> Thread 6 and Thread 7: thread.c:497 with p_sys = (playlist_private_t *)NULL

--> Thread 8: decoder.c:2175 with p_owner = (input_thread_t *)0x00000001247c37c0
p_owner->lock = (vlc_mutex_t) Dump: --> Thread 9: decoder.c:1488 with p_owner = (input_thread_t *)0x00000001247c37c0 (same as in Thread 8 )

--> Thread 10: decoder.c:816 with p_owner = (input_thread_t *)0x00000001247c5020


--> Thread 13: control.c:189 with ctrl->lock could be the same as in Thread 10.
Actually - this thread hangs in vlc_cond_timedwait:291 with p_condvar = (vlc_cond_t *)NULL and p_mutex = (vlc_mutex_t *)NULL,

I don't know, what the problem is, but at least it looks like a problem to me, that pointers passed as arguments or returned by external call are not checked for NULL. This usually is a flaw, considering, this value is never NULL - but in my case it is.

I hope this helps.

One more stack backtrace all during a freeze of playback:

one more

Well, I just built TVVLCKit with the sources from Dec 28th 2015.
It uses libVLC commit from Dec. 8th
I had to fix some issues in VLCKit and vlc, but at the end it works and the result is much better than building from HEAD.
I will keep it this build at a safe place

But maybe this can help you to find the cause for the issues, since it has been introduced since then.