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.
Add a property and logic to send a GstNetworkMessage event containing
the message that was received from a client. This can be used to
implement simply bidirectional communication.
Add a property and logic to send a GstNetworkMessageDispatched
event upstream to notify that a buffer has been sent. This can be used
to keep track of what client received what buffers.
Add a property to handle GstNetworkMessage events. These events contain
a buffer that is sent on the socket to allow for simple bidirectional
communication.
In the case where the stream doesn't have a framerate set and the frames
don't have a duration set, we still want to use the clipping path to
make sure we don't push buffers outside of the segment.
The problem was the previous iteration was setting a duration of 2s, which
meant that any buffer which was less than 2s before the segment start would
end up getting pushed.
Instead, use a saner 40ms (25fps single frame duration) to figure out whether
the frame could be within the segment or not
Some servers incorrectly parse header names with strict case-sensitivity. For
compatibility with these systems change X-Sessioncookie to x-sessioncookie.
https://bugzilla.gnome.org/show_bug.cgi?id=758921
Otherwise we'll remove that element while keeping its buffering message in our
list, and because of that never ever report buffering 100% as that element
will always be at a lower percentage.
This fixes e.g. seeking over Period boundaries in DASH and various other
issues when buffering happens between group switches.
Also use a new mutex for protecting the buffering messages. The object lock is
already used by gst_object_has_as_ancestor() and we need to use it now for
checking if the buffering message sender has the to-be-removed element as
ancestor.
When we stop sending because we need more data, still keep a GSource
around to receive data from the clients.
Also handle read and write in the same go.
Any latency query before this will not get the correct latency so a new
latency query should be triggered once the audio sink know its own latency.
Without this the initial latency query from the pipeline arrives too early
sometimes and the resulting latency is too short.
https://bugzilla.gnome.org/show_bug.cgi?id=758911
Make sure that any access to the GstDecodeBin's decode_chain
field is protected using the EXPOSE_LOCK. Also add a simple
reference counter to the GstDecodeChain structure so that when
the type_found signal fires it can hold onto the decode chain
even while the EXPOSE_LOCK is not held. This should fix a
race condition if the type_found signal fires right in the
middle of a state change that messes with the same decode
chain.
https://bugzilla.gnome.org/show_bug.cgi?id=755260
Some Opus files found on the wild have 0 in the version field of the
OpusHead header, instead of the correct value of 1. The files still
play, don't make this error fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=758754
Commit ff6d1a2a25 changed sample's type from
gint to gsize (and renamed it to in_samples). gsize is an unsigned long,
which means it can never be a negative value and the check making sure that
in_samples is >= 0 is never going to be false. Removing it.
CID 1338689
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
