hlsdemux: Invalid timestamps generated for live streams and otherwise broken for live streams

Submitted by Sebastian Dröge @slomo

Link to original bug (#724983)

Description

a) Currently hlsdemux generates timestamps by summing all the fragment durations in the playlist. Only that this will lead to invalid timestamps because the playlists are like a ringbuffer, only having a few fragments and not all since the beginning of time. We could keep all fragments around forever or try to assign a timestamp to the beginning of the playlist by looking at the sequence numbers of the fragments, but this is going to fail once we e.g. switch from one bitrate to another. Also it will fail if after a playlist update we have no old fragments around... we can't know how much gap there was in between.

b) If we pause the pipeline, we will lack behind... and can easily get to a point where all fragments have disappeared already. We need to resync then, and probably always resync whenever we unpause.

c) Due to us and the sender having different clocks, we will run out of sync at some point. Either being in the future for the sender (downloading fragments that don't exist yet) or too far in the past (downloading fragments that disappeared already). We need some resync logic for that. Probably rather unlikely case as it requires a lot of clock drift and everybody using HLS for such long-term live streaming doesn't deserve something else ;)

a) and b) definitely need to be fixed, c) would be bonus if someone is bored :)