In live streaming, buffers sent by souphttpsrc are pushed to the live
adapter. The buffers in the adapter are sent out of mssdemux when it
is greater than 4096 bytes.
Occasionally, when seeking in live streams, if seek occurs just
after the last data chunk was received, and if this data chunk is
smaller than 4096 bytes, it will be kept in the live adapter.
This remaining data in the live adapter will be erroneously prepended
to the new data that is downloaded after seek and pushed out.
When qtdemux receives this data, since it does not start with
a moof box, it is impossible to demux the fragment, and bogus
size error will occur.
Clear out the live adapter on seek so that no unnecessary remaining
data is pushed out together with the new fragment after seeking.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1345>
When a MSS server hosts a live stream the fragments listed in the
manifest usually don't have accurate timestamps and duration, except
for the first fragment, which additionally stores timing information
for the few upcoming fragments. In this scenario it is useless to
periodically fetch and update the manifest and the fragments list can
be incrementally built by parsing the first/current fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=755036
Allows seeking through the available fragments that are still available
on the server as specified by the DVRWindowLength attribute in the
manifest.
https://bugzilla.gnome.org/show_bug.cgi?id=774178
Adaptive demuxers need to start downloading from specific positions
(fragments) for every stream, this means that all streams can snap-seek
to a different position when requested. Snap seeking in this case will
be done in 2 steps:
1) do the snap seeking on the pad that received the seek event and
get the final position
2) use this position to do a regular seek on the other streams to
make sure they all start from the same position
More arguments were added to the stream_seek function, allowing better control
of how seeking is done. Knowing the flags and the playback direction allows
subclasses to handle snap-seeking.
And also adds a new return parameter to inform of the final
selected seeking position that is used to align the other streams.
https://bugzilla.gnome.org/show_bug.cgi?id=759158
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.
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.
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
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
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
