Richard, all,
we ended up modifying a few classes in the OSMF’s HTTP streaming managing code. A quick hint for the solution (sorry for my terrible English).
Let’s assume that the encoder has a huge available bandwidth and has no problems during the streaming; thus, if the fragments’ duration is set to 4 seconds, the encoder (and Wowza) will write a new fragment each 4 seconds.
The client starts playing the stream: it will ask for the manifest, choose the right playlist (based on the current available bandwidth), open the playlist_b.abst and get the current available fragments list. It will then start getting the fragments one after another and reload a new copy of the playlist.abst file when it reaches (or approaches) the end of the fragments list.
Now, suppose that for whatever reason the player has a network problem which reduces the available bandwidth. It will load the fragments with a much lesser speed; if its available bandwidth is lower than the fragments’ one it will start to accumulate delay.
If the delay grows enough the player could be downloading a fragment, say the last element in the last downloaded playlist*.abst with ID 100, then download a new playlist.abst. Wowza answers with a playlist starting from the first available fragment in the current window, say with the ID 105.
The player checks if the packet “105” is the next playable one (if its start time copes well with the last played fragment’s end time and if the ID is consecutive); this check fails (because the new ID is higher than the last played fragment’s one, but the start time is much later than the end time) and begins with the playlist.abst loading loop, “hoping” to receive “the next fragment” (which in a live streaming scenario will fail again and again).
The idea is simple: when this check fails there will be no available fragment. We’ll add the following check:
-
has the quality switched (–> our bandwidth has changed)? if so pick the first available fragment and start from there
-
if not, ask for the next ID (the fragment immediately after the one you played) even if it’s not present in the fragments list.
This is a very naif approach and it’s not guaranteed as working; however, if you provide a larger value for sanjoseMaxChunkCount than the one for sanjosePlaylistChunkCount, this trick could work.
What do you think?
Regards,
Leonardo