the stream starts (I see it in the Wowza log and also in the StreamManager web interface)
the VLC starts to play but it stops after 3-4 seconds
if I press play button in VLC one more time, the video plays nicely in VLC without any problems
What should I do in order for the video to play properly in VLC from the first attempt? I guess there is some kind of delay I should implement somewhere. But I don’t know where: server side (in some config files or in the code) or at the player (VLC) level.
I would suggest you sniff traffic out of VLC to understand why it fails. I guess it could be related to HLS design, which requires at least 3 chunks in the playlist. At the moment you create it, you won’t have those chunks available (depending how long you have the chunks to be set, it’s the time you’ll have to wait)
Not all players process HLS the same. IPAD won’t play if there’s no 3 chunks in the list. VLC might start, but when request the manifest again, there’s nothing new, so it stops.
Technically speaking, as HLS requires those 3 chunks per definition of a live stream, starting the stream on first connection will require more than just a delay, but a checking if the manifest received is good enough to start a live playback
I think you are running into the same limitation that iOS devices have trying to playback cupertino streams that has just been started, a requirement for 3 chunks in the case of iOS. You might cupertinoPlaylistChunkCount to “1”, but that is probably not a good idea for iOS
Finally I’ve found a solution to this issue and I would like to share it here.
I’ve just added the following code to my example above. That delay allowed Wowza to prepare the cupertino chunks in order for the VLC to play smooth. It is a little bit of delay when the user first accesses the url in VLC, but at least it works.
This is exactly the same quick fix that I’m forced to use right now. However Thread.sleep() is not really safe to use in onHTTPSessionCreate, as reported in another forum discussion.
If you can’t handle all this in the client, another solution would be to have a pre-roll stream that is always up and running (like a local file in a loop for eg.). When a user connects and demands a stream that is not yet started the server will play the pre-roll video while your actual stream starts. When the other stream is live the server switches without the client having to disconnect/reconnect. You can do all this by implementing a stream listener.
One more thing, in your example you should at least check if the stream is already started before sleeping.