If connection speed is set, playlist according
to connection speed is selected as current playlist.
Problem is that the current variant of main playlist still
points to previously set variant.
If previously set variant doesn't correspond to current
playlist, then it causes unnecessary change of playlist
to the same playlist after first fragment is downloaded,
because of not updated current variant.
To fix this, we need to make sure that current variant
of main playlist corresponds to the current playlist
https://bugzilla.gnome.org/show_bug.cgi?id=758946
Don't jump backward to 3 files from the end of the playlist
when switching variants - it just means we downloaded
fragments fast and caught up to the end of the playlist.
Disable that by treating a variant switch as a playlist
update, not a restart due to a seek or so.
If the stream is discont, we must provide a timestamp in any case. Elements
like tsdemux are not going to output anything if we give a NONE timestamp
after a discont.
Also marking a stream as discont if a playlist change was not successful would
lead to the above situation, but in that case we are not required at all to
mark the stream discont as we're still at the old playlist.
commit da5c41930c removed the two uses of the
new value of data:
channels = opus_packet_get_nb_channels (data);
bandwidth = opus_packet_get_bandwidth (data);
Since then, data isn't being used between incrementing it by packet_offset
and going out of scope. Removing this uneeded statement.
The scene graph can be initialized when the we receive window handle change
notification and so we will not receive a scenegraph initialization
notification. Initialize ourself in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=758337
The result of the two expressions will be promoted to guint64 anyway,
perform all the arithmetic in 64 bits to avoid potential overflows.
CID 1338690, CID 1338691
sample_rate might be used uninitialized if !sink_caps is TRUE. Initialize
it to the default used in gst_codec_utils_opus_parse_caps () when there is
no rate defined in the caps.
CID 1338695
There is a possibility that the _get_caps impl will be called with the
feature in the filter caps which when interecting with the template,
will return EMPTY and therefore fail negotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=757854
It's for the upstream element driving the pipeline to
handle seeks and send flush events or not, filters
should not interfere here, otherwise downstream pads
could be flushing before upstream pads are flushing,
which can result in GST_FLOW_ERROR being sent instead
of GST_FLOW_FLUSHING when trying to forward sticky
events at just the wrong moment.
No need to use G_GINT64_FORMAT for potentially negative values of
GstClockTimeDiff. Since 1.6 these can be handled with GST_STIME_FORMAT.
Plus it creates more readable values in the logs.
https://bugzilla.gnome.org/show_bug.cgi?id=757480
We always require the channel-mapping-field. If it's 0 we require nothing
else, otherwise we need channels, stream-count and coupled count to be
available.
oggdemux is outputting the meta now, and only outputs if it should really
apply to the current buffer. Previously we would skip N samples also if we
started the decoder in the middle of the stream.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
It is doing the wrong thing because of the Opus pre-skip: while the timestamps
are shifted by the pre-skip, the granule positions are not shifted.
oggmux is doing the right thing here already.
https://bugzilla.gnome.org/show_bug.cgi?id=757153
