Make sure the state of the parser is set to
collecting streams before chaining up to the
parent change_state() method, to close a
small window that can cause playback to
never commence.
Use GQueue instead of a GSList so we don't have to traverse
the whole list to append something every time. And it also
keeps track of the number of items in it for us.
Add a function to add filenames to the list of old files and
use it in more places, so that memory doesn't build up in
other modes either if no max_files limit is specified.
https://bugzilla.gnome.org/show_bug.cgi?id=766991
Technically we weren't leaking the memory, just storing it internally
and never using it until the element is freed. But we'd still use more
and more memory over time, so this is not good over longer periods
of time. Only keep track of files if there's actually a limit set,
so that we will prune the list from time to time.
https://bugzilla.gnome.org/show_bug.cgi?id=766991
Previously, seeking to position y where y is (strictly) within a keyframe
would seek to that keyframe both with SNAP_BEFORE and SNAP_AFTER,
where the latter is now adjusted to really snap to the next keyframe.
Rather amazingly (and equally unnoticed), keyunit seeking resulted in segments
where start != time (which is bogus for simple avi timeline). So, properly
adjust the segment (start) rather than fiddling with segment time (only).
... by using the original seek event's flags rather than the corresponding
segment flags, which do not have such counterpart flags (and
do no longer have them covertly sneaking in nowadays).
With Xiph codecs the stream header buffers are both in the caps and are
usually also at the beginning of each input stream, but it's perfectly
possible that the input stream does not have the stream header buffers
inline in the data. Matroskamux would drop the first N buffers assuming
they're stream headers, but this meant it would drop actual payload data
when the stream didn't contain the stream headers inline. Fix this by
only dropping leading buffers if they're flagged as stream headers. This
fixes issues with streams that are being tapped into after streaming
has started.
https://bugzilla.gnome.org/show_bug.cgi?id=749098
That is, whenever we go through start/stop we have to ensure that on the
next opportunity the buffers are reallocated again. Otherwise the
buffers might be NULL because the element was reused with the same
configuration as before (i.e. set_caps() wouldn't have reinited the
buffers).
https://bugzilla.gnome.org/show_bug.cgi?id=775898
Redirect on PLAY wasn't doing the necessary session cleanup. Fixed by
removing code from gst_rtspsrc_send that changed the state varable upon
encountering a redirect. Better to let the redirect handlers in
gst_rtspsrc_retrieve_sdp and gst_rtspsrc_play do their own
state-dependent cleanup.
https://bugzilla.gnome.org/show_bug.cgi?id=775543
When providing items with a seqnum, there is a (very small) probability
that an element with the same seqnum already exists. Don't forget
to free that item if it wasn't inserted.
And avoid returning undefined values when dealing with duplicate items
We can't simply assume that the length of the tag value as given
inside the stream is correct but should also check against the amount of
data we have actually available.
https://bugzilla.gnome.org/show_bug.cgi?id=775451
qtdemux.c: In function ‘qtdemux_parse_trak’:
qtdemux.c:10184:38: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 9 has type ‘gint {aka const int}’ [-Werror=format=]
GST_DEBUG_OBJECT (qtdemux, "Found jpeg: len %u, need %lu", len,
^
If an element queries the number of retransmission buffers pushed
*while* the push is still taking place (and before the object lock
is taken just after) it would end up with the wrong statistic
being reported.
Increment it just before the push, avoids races when getting statistics
https://bugzilla.gnome.org/show_bug.cgi?id=768723
