Buffers would always start with timestamp 0 and we'd start streaming
from the first buffer, but live streams always start streaming from
the last fragment - 3 fragments in the playlist, which makes its
timestamp, as returned by get_next_fragment, be whatever position
they had in the playlist. This makes sure the position correctly
reports the position of the buffer in the playlist, and added a shifting
variable to allow seeking in the middle of fragments.
In some networks, especiall in 3G, a fragment download or playlist
update may fail. We allow for up to 3 consecutive failures, while using
the rfc's specs for retry delays before considering that there was an
error on the stream.
Fixes interesting race conditions that cause crashes in decodebin2
because pads are added/removed from child elements although they
should be in READY state already.
We should stop the update thread in PAUSED state and avoid fetching
new fragments when the queue is not empty. The queue should always be
empty since we push data into a queue. Also, in totem, if we seek and
pause the stream while it's buffering, then the state will stay playing
for some reason, so it's best not to continue fetching fragments forever.
This is to ensure that we reset the accumulate segment on the sinks
so if we start with audio only then switch to audio+video, then both
sinks will have the same segments and will be synchronized.
If we cancel the fetch and call the stop_fetcher, which holds the lock,
when it sets the fetcher's state to NULL, it might send an error
on the bus. In that case, we must ignore it, otherwise it will try
to take the lock and will block forever.
When caching fragments, if we set the current playlist to main, then
it will always think it's a live stream (no endlist in it) so it will
force the redownload of the main playlist after every seek, which is
unnecessary. Also, it causes a race condition where a seek migh happen
during that redownload, and we'll think we're trying to seek a live pipeline.
first pause the task, then stop all fetchers, then stop the update thread
then pause the task again, since it might have been restarted by
another thread in the meantime
The task function uses GST_TASK_WAIT which does a g_cond_wait giving it
the GST_OBJECT_GET_LOCK of the task. The mutex gets locked when
g_cond_wait returns, so if we don't lock/unlock it, it will
stay locked forever, preventing the task from ever finishing.
We shouldn't lock the task object lock, so let's remove the GST_TASK_WAIT
and make the task pause instead if there are no buffers in the queue.
