Doing so prevents us dropping buffers in the rare, but possible, situations,
when the stream changes SSRC and new sequence numbers does not differ
much from the last sequence number from previous SSRC. For example:
ssrc - 0xaaaa 101,102,103,104 ssrc - 0xbbbb 102, 103, 104, 105...
In the scenario above we don't want to drop the first 3 packets of
0xbbbb stream.
https://bugzilla.gnome.org/show_bug.cgi?id=764459
Depayloaders will look at rtpbuffer->buffer for the discont flag.
When we set the discont flag on a buffer in the rtp base depayloader
and we have to make the buffer writable, make sure the rtpbuffer
actually contains the newly-flagged buffer, not the original input
buffer. This was introduced with the addition of the process_rtp_packet
vfunc, but would only trigger if the input buffer wasn't flagged
already and was not writable already.
When we detect a discont and the input buffer isn't already flagged
as discont, handle_buffer() does a gst_buffer_make_writable() on the
input buffer in order to set the flag. This assumed it had ownership
of the input buffer though, which it didn't. This would still work
fine in most scenarios, but could lead to crashes or mini object
unref criticals in some cases when a discont is detected, e.g. when
using pcapparse in front of a depayloader. This problem was
introduced in bc14cdf529.
Use the object lock to protect the internal segment when updating
against access from getting the stats property.
Fix a critical in gst-inspect or when retrieving the stats
before any segment has arrived by checking whether the
segment has been initted..
There was a confusion, six depayloaders where passing through the
timestamp while the base class was re-timestamping to running
time. This inconstancy has been unnoticed has in most use cases
the incoming segment is [0, inifnity] in which case timestamps are
the same as running time. With DTS/PTS shifting added (to avoid
negative values) and pcapparse sending a different segment this
started being an issue.
https://bugzilla.gnome.org/show_bug.cgi?id=753037
When there is no clock_base provided, the start position is
set to 0 instead of the original segment start value. This
would break synchronization if start was not 0.
https://bugzilla.gnome.org/show_bug.cgi?id=752228
Add process_rtp_packet() vfunc that works just like the
existing process() vfunc only that it takes the GstRTPBuffer
that the base class has already mapped (with MAP_READ),
which means that the subclass doesn't have to map it again,
which allows more performant processing of input buffers
for most RTP depayloaders.
https://bugzilla.gnome.org/show_bug.cgi?id=750235
Implement a chain_list function, which avoids lots of locking
compared to the default fallback implementation in GstPad.
We may also want to do some more sophisticated timestamp
tracking here at some point, but for now leave it up to the
jitterbuffer and/or subclasses (in case buffers in the
buffer list have no timestamp set on them, there may only
be a timestamp for the whole list on the first buffer).
This provides the exact same behaviour as the default
fallback implementation.
When generating segment, we can't assume the first buffer is actually
the first expected one. If it's not, we need to adjust the segment to
start a bit before.
Additionally, we if don't know when the stream is suppose to have
started (no clock-base in caps), it means we need to keep everything in
running time and only rely on jitterbuffer to synchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
Add support RTP buffers with multiple memory blocks. We allow one block for the
header, one for the extension data, N for data and one memory block for the
padding.
Remove the validate function, we validate now when we map because we need to
parse things in order to map multiple memory blocks.
