If there is an external source which is about to timeout and be removed
from the source hashtable and we receive feedback RTCP packet with the
media ssrc of the source, we unlock the session in
rtp_session_process_feedback before emitting 'on-feedback-rtcp' signal
allowing rtcp timer to kick in and grab the lock. It will get rid of
the source and rtp_session_process_feedback will be left with RTPSource
with ref count 0.
The fix is to grab the ref to the RTPSource object in
rtp_session_process_feedback.
https://bugzilla.gnome.org/show_bug.cgi?id=795139
These are the sources we send from, so there is no reason to
report receive statistics for them (as we do not receive on them,
and the remote side has no knowledge of them).
https://bugzilla.gnome.org/show_bug.cgi?id=795139
Whenever got new moov or new stream-start,
demux will try to expose new pad by following rule.
Comparing stream-id in the current moov with previous one, then
* If matched stream-id is found from previous one,
reuse existing pad (most common case)
* Otherwise, expose new pad with new stream-start
* No more used stream will be freed
https://bugzilla.gnome.org/show_bug.cgi?id=684790
Whenever demux got moov, demux will create new stream. Only exception is
duplicated track-id in a moov box. In that case the first stream
will be accepted. This patch is pre-work for rework of moov handling.
https://bugzilla.gnome.org/show_bug.cgi?id=684790
Supports CEA 608 and CEA 708 CC streams
Also supports usage in "Robust Prefill" mode if the incoming caption
stream is constant (i.e. there is one incoming CC buffer for each
video frame).
https://bugzilla.gnome.org/show_bug.cgi?id=606643
ULP FEC, as defined in RFC 5109, has the protected and protection
packets sharing the same ssrc, and a different payload type, and
implies rewriting the seqnums of the protected stream when encoding
the protection packets. This has the unfortunate drawback of not
being able to tell whether a lost packet was a protection packet.
rtpbasedepayload relies on gaps in the seqnums to set the DISCONT
flag on buffers it outputs. Before that commit, this created two
problems:
* The protection packets don't make it as far as the depayloader,
which means it will mark buffers as DISCONT every time the previous
packets were protected
* While we could work around the previous issue by looking at
the protection packets ignored and dropped in rtpptdemux, we
would still mark buffers as DISCONT when a FEC packet was lost,
as we cannot know that it was indeed a FEC packet, even though
this should have no impact on the decoding of the stream
With this commit, we consider that when using ULPFEC, gaps in
the seqnums are not a reliable indicator of whether buffers should
be marked as DISCONT or not, and thus rewrite the seqnums on
the decoding side as well to form a perfect sequence, this
obviously doesn't prevent the jitterbuffer from doing its job
as the ulpfec decoder is downstream from it.
https://bugzilla.gnome.org/show_bug.cgi?id=794909
This reverts commit af273b4de9.
While RFC 3264 (SDP) says that sendonly/recvonly are from the point of view of
the requester, the actual RTSP RFCs (RFC 2326 / 7826) disagree and say
the opposite, just like the ONVIF standard.
Let's follow those RFCs as we're doing RTSP here, and add a property at
a later time if needed to switch to the SDP RFC behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=793964
After a CAPS event, in theory a new stream can start and it might start
with the FLAC headers again. We can't detect FLAC headers in the middle
of the stream, so we drain the parser to be able to detect either FLAC
headers after the CAPS event or the continuation of the previous stream.
This fixes for example
gst-launch-1.0 audiotestsrc num-buffers=200 ! flacenc ! c. \
audiotestsrc num-buffers=200 freq=880 ! flacenc ! c. \
concat name=c ! rtpgstpay ! udpsink host=127.0.0.1 port=5000
gst-launch-1.0 udpsrc multicast-group=127.0.0.1 port=5000 \
caps=application/x-rtp,media=application,clock-rate=90000,encoding-name=X-GST ! \
rtpgstdepay ! flacparse ! flacdec ! audioconvert ! pulsesin
gst_qt_mux_can_renegotiate () gets called everywhere following
that pattern:
return gst_qt_mux_can_renegotiate (ref(self));
This means the reference must be released both in the success
and failure cases, it was only done in the success case.
It can happen during teardown that the reference context becomes NULL.
In that case, trying to send the fragment-opened-closed message would
lead to a crash.
Corrupted files could potentially have multiple cdat/cdt2 atoms in
a sample entry, which is unclear how to handle.
Ignore repeated ones.
CID #1434162
CID #1434159
The code responsible for creating retransmitted buffers
assumed the stored buffer had been created with
rtp_buffer_new_allocate when copying the extension data,
which isn't necessarily the case, for example when
the rtp buffers come from a udpsrc.
https://bugzilla.gnome.org/show_bug.cgi?id=794958
Similar to the get-session and get-internal-session signals,
we expose a get-storage signal in addition to the
get-internal-storage signal to give access to the actual
element for applications that need to set properties on the
element, in particular "size-time"
https://bugzilla.gnome.org/show_bug.cgi?id=794910
With this the muxer is not set to NULL after each segment but instead
only flush events are sent to it to reset the EOS state.
As a result, the muxer will keep stream state and e.g. mpegtsmux will
keep the packet continuity counter continuous between segments as needed
by hlssink2.
https://bugzilla.gnome.org/show_bug.cgi?id=794816
The value stored in cenc_aux_sample_count wasn't in sync with the
parsing code that followed which checks whether all entries are
valid and present.
Only write the actual sample count when we know for sure.
CID #1427087
This exposes a new property, mtu, which is used to determine the
initial size of buffers from the buffer pool. If received data
exceeds this, the element gracefully handles that in a manner similar
to what we had previously: a large memory gets filled and reallocated
at the next call to "fill".
The default size is set to 1500, which should cover most use cases.
With contributions from Mathieu Duponchelle <mathieu@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=772841
Optimize GstUdpSrc for cache performance.
Move the hot properties, which are used by the read function, to the top:
@used_socket, @addr, @cancellable, @skip_first_bytes, @timeout,
@retrieve_sender_address.
Remove the unused property @ttl.
Where needed reorder so that holes are avoided (the 64-bit @timeout)
https://bugzilla.gnome.org/show_bug.cgi?id=772841
