Prevent cluttering up the rtpsession, and keeping things localized.
Also write TWCC-seqnums for *all* streams in the session if configured by
caps.
A while back WebRTC was not doing TWCC for audio, basically breaking the
whole idea of a "transport-wide seqnuencenumber" applying for all bundled
streams. However, they have since fixed this, and now it no longers
makes sense to be able to single out certain payloadtypes for
use with TWCC, rather just including them all.
This also makes using RTX, RED, FEC etc much simpler, as it will apply
to them all as they enter the rtpsession.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/927>
This crash could happen at any time a RTP and RTCP buffer arrived
simultaneously in ssrcdemux.
The problem was that sticky-event arriving while the rtp and rtcp pads
were being set up could arrive just too late to be included in the initial
forwarding.
The fix checks if the stickies have been sent on the srcpad about to be
pushed on, and if not sends them. It also blocks any stickes from
being forwarded *prior* to this happening, to avoid them arriving on
the srcpad multiple times.
Since the test loops 1000 times, this will make running under valgrind
take forever, so use the RUNNING_ON_VALGRIND variable to detect we
are running under valgrind, and reduce the loop-count to 2 in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/992>
* Try to make variable and function names more clear.
* Add plenty of comments describing the logic step-by-step.
* Improve the logging around this, making the logs easier to read and
understand when debugging these issues.
* Revise the logic of packets that are actually beyond saving in doing
the following:
1. Do an optimistic estimation of which packets can still arrive.
2. Based on this, find which packets (and duration) are now hopelessly
lost.
3. Issue an immediate lost-event for the hopelessly lost and then add
lost/rtx timers for the ones we still hope to save, meaning that if
they are to arrive, they will not be discarded.
* Revise the use of rtx-delay:
Earlier the rtx-delay would vary, depending on the pts of the latest
packet and the estimated pts of the packet it being issued a RTX for,
but now that we aim to estimate the PTS of the missing packet accurately,
the RTX delay should remain the same for all packets.
Meaning: If the packet have a PTS of X, the delay in asked for a RTX
for this packet is always a constant X + delay, not a variable one.
* Finally ensure that the chaotic "check-for-stall" tests uses timestamps
that starts from 0 to make them easier to debug.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/952>
This code can be fragile, since it is very exacting in the timestamps
that it will accept. Add more logging so it's easier to debug issues
and figure out whether it's a bug in the calculation or something
wrong in the incoming buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/934>
While the standard is a bit vague about whether the padding,
extension and marker bits should be protected:
> The usage, by senders and receivers, of the following bits shall
> be defined by the associated video/audio transport standards:
It is obviously necessary and useful for some formats (eg VP8)
that those indeed be protected.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/839>
This will end up as a "received" packet, due to the code in
source_push_rtp, which will think this is a packet being received.
Instead drop the packet and hope that either:
1. Something upstream responds to the GstRTPCollision event and changes
SSRC used for sending.
2. That the application responds to the "on-ssrc-collision" signal, and
forces the sender (payloader) to change its SSRC.
3. That the BYE sent to the existing user of this SSRC will respond to
the BYE, and that we timeout this source, so we can continue sending
using the chosen SSRC.
The test reproduces a scenario where we previously would have sent
on a non-internal source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/817>
Due to us not properly acknowleding the time when the last RTX was sent
when scheduling a new one, it can easily happen that due to the packet
you are requesting have a PTS that is slightly old (but not too old when
adding the latency of the jitterbuffer), both its calculated second and
third (etc.) timeout could already have passed. This would lead to a burst
of RTX requests, which acts completely against its purpose, potentially
spending a lot more bandwidth than needed.
This has been properly reproduced in the test:
test_rtx_not_bursting_requests
The good news is that slightly re-thinking the logic concerning
re-requesting RTX, made it a lot simpler to understand, and allows us
to remove two members of the RtpTimer which no longer serves any purpose
due to the refactoring. If desirable the whole "delay" concept can actually
be removed completely from the timers, and simply just added to the timeout
by the caller of the API. But that can be a change for a another time.
The only external change (other than the improved behavior around bursting
RTX) is that the "delay" field now stricly represents the delay between
the PTS of the RTX-requested packet and the time it is requested on,
whereas before this calculation was more about the theoretical calculated
delay. This is visible in three other RTX-tests where the delay had
to be adjusted slightly. I am confident however that this change is
correct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/789>
This action signal will delegate to clear-ssrc onto the rtpssrcdemux element
associated with the session. This allow rtpbin users to clear pads and
elements for a specific ssrc that is known to no longer be in use. This
happens when a pad is reused in rtpsrc or ristsrc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/736>
In order to support the symbol g_enum_to_string in various
project using GStreamer ( gst-validate etc.), the glib minimum
version should be 2.56.0.
Remove compat code as glib requirement
is now > 2.56
Version used by Ubuntu 18.04 LTS
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/774>
Since !348, the jitterbuffer was only removed with the session. This restores
the original behaviour and removes the jitterbuffer when the stream is
removed. This avoid accumulating jitterbuffer objects into the bin when a
session is reused.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/735>
