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
When chain method was called after gst_uri_downloader_stop and before state has been changed to NULL, execution was blocking on g_mutex_lock.
Conflicts:
gst-libs/gst/uridownloader/gsturidownloader.c
When downloading and cancelling quickly the uridownloader object and the
element using it could miss the cancelled window and the uridownloader
would fetch the wrong URI and block on subsequent fetches.
This was also problematic when stopping elements, while one task would
call the cancel, another element thread could issue a new fetch_uri. As
the cancel state isn't 'permanent' this fetch_uri would block and
prevent the whole element from stopping and going to NULL.
This patch makes the 'cancelled' state permanent until a
gst_uri_downloader_reset is called. This way the element knows the
window where the uridownloader isn't active and only reactivate it when
ready.
prepare_func will allocate a new buffer to replace the original
one. Instead of using gst_buffer_replace (which causes an extra
refcount increment on the new buffer), we just unref the original
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=699786
