connection setup times seem to matter when measuring the download
rate of different streams. Streams with longer fragments have a
*relatively* lower connection setup time and achieve higher bitrates.
Using the average seems unfair here, so use each stream's measured bitrate
to select its best quality option.
We need to cancel the downloader for each stream before joining the main download task, otherwise
the download task will block until all the stream tasks finish.
There is no way to know if a live stream is really finished, so try to reload the manifest and check if there are more fragments to download. Else just let know it's the EOS.
Live streams force the demuxer to keep reloading the Manifest from
time to time, as the new fragments are being added as they are recorded.
The demuxer should also try to keep up and detect when it had to skip
fragments, marking the discont flag when that happens.
Curiously, the spec doesn't seem to mention when/how a live stream is supposed
to end, so keep trying downloads until the demuxer errors out.
Use pad tasks to download data and an extra task that gets the earlier
buffer (with the smallest timestamp) and pushes on the corresponding
pad.
This prevents that the audio stream rushes ahead on buffers as its
fragments should be smaller
When connection-speed changes, signal that we might need a bitrate
switch. During the switch, a new pad group is added and the old one
is drained and removed.
New pads also need to push newsegments before starting to stream
This speed limits the maximum bitrate of streams. Currently it
is only read when starting the pipeline, but it should be used
for switching bitrates during playback to adapt to network
changes.
mssdemux should set the streams it has exposed as active so that
the manifest won't use the non-active streams to compute total bitrates
or providing fragments
When the stream can't have its caps detected, better not to expose it.
If no streams are known, signal an error about no playable streams to
the application
Adds basic handling for seek in time events. Needs to cooperate
with the downstream qtdemux so that it forwards the seeks and
the corresponding newsegments
This is important for downstream to properly timestamp the samples
The default value is 10000000, but this can be set in the stream
or at the top-level manifest entry
Keep a ref on pad to prevent it being unreffed while the mssdemux
streams are still using it. Also reset the element when going to
ready instead of when going to null.
Use shorter names for the MSS manifest helper structure and functions.
Also continues the implementation of the stream fetching and pushing loop.
Now it uses the base url correctly and already fetches and pushes the fragments
downstream
