We now calculate the actual bitrate using the download speed/size and
then switch directly to the variant that matches our bandwidth the
most.
It will also be able to handle any use case where some of the
variants are not available, and would skip them and go to the next
possible variant.
Conflicts:
gst/hls/gsthlsdemux.c
This also will fix the issue of having the current position different
from the actual position of the first buffer in the queue in case
the caching caused a resync of the sequence number.
Conflicts:
gst/hls/gsthlsdemux.c
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.
Previously hlsdemux wasn't sending out any newsegment.
Here we push a GST_FORMAT_TIME newsegment, and whenever possible we
try to indicate the proper start time.
This allows downstream elements to relay the start/time values properly
to the sinks, allowing better stream switching.
When switching bitrates, we might end up switching to a different
media-type (like from aac to/from mpeg-ts).
For this switch to behave properly in decodebin2, this patch adds:
* dynamic source pads (which will be added/removed whenever a stream
media type changes
* re-checking the fragment media type whenever we switch to a different
playlist
