Commit graph

1403 commits

Author SHA1 Message Date
Stéphane Cerveau
0429c24637 meson: update glib minimum version to 2.56
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>
2020-10-15 18:21:54 +02:00
Mathieu Duponchelle
5fb5abc8a8 rtpst2022-1-fecenc: fix input seqnum check
We need to cast the incremented last seqnum to guint16 for
consistent checks on wraparound

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/770>
2020-10-14 14:30:34 +02:00
Sebastian Dröge
6a84dc4146 rtpst2022-1-fecenc: Don't unconditionally use GLib 2.60 APIs
g_queue_clear_full() in this case.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/768>
2020-10-09 09:31:27 +03:00
Mathieu Duponchelle
591af0f38a rtpmanager: implement SMPTE 2022-1 FEC encoder
+ improve integration of FEC encoders in rtpbin

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/753>
2020-10-08 22:22:18 +00:00
Mathieu Duponchelle
cff42d4c26 rtpmanager: implement SMPTE 2022-1 FEC decoder
+ improve integration of FEC decoders in rtpbin

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/753>
2020-10-08 22:22:18 +00:00
Olivier Crête
7c9a5e86fe rtpfunnel: Also forward custom sticky event
This is useful to track metadata about each group of packets

Also include a unit test

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/666>
2020-10-06 20:57:49 +00:00
Nicolas Dufresne
345f74b09d rtpbin: Remove the rtpjitterbuffer with the stream
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>
2020-09-24 09:54:05 -04:00
Nicolas Dufresne
ecc110ca8b rtpbin: Cleanup dead code
The rtpjitterbuffer is now part of the session elements, we no longer need
to do the ref_sink dance when signalling it. It is already owned by the bin
when signalled. Also, the code that handles generic session elements already
handle the ref_sink() calls since:

03dc22951b

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/735>
2020-09-23 15:48:24 -04:00
Sebastian Dröge
e4ce9887cd rtpmanager: Improve readability of "stats" docs by making the fields an actual list
Otherwise they end up all in the same line one after another.

Also add docs for the "avg-jitter" stats field of the jitterbuffer.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/698>
2020-08-13 07:24:17 +00:00
Tim-Philipp Müller
10f07e84a5 rtpfunnel: protect internal srccaps with lock
These are modified from sink pad event handlers, so
could be accessed from multiple threads at the same
time.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/681>
2020-07-28 07:08:04 +00:00
Havard Graff
f5fc34ae83 rtpfunnel: copy caps before sending them in a caps-event
Reason being we don't want downstream to own a ref to our
internal caps.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/681>
2020-07-28 07:08:04 +00:00
Mathieu Duponchelle
aa34c29d3b rtpmanager: fix various documentation issues
Improper naming of properties, improper links, misc

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/684>
2020-07-27 13:51:15 +00:00
Tim-Philipp Müller
913e17e19e rtpmanager: fix "redefinition of typedef RTPTWCCManager" compiler warning
G_DECLARE_FINAL_TYPE includes this typedef as well.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/675>
2020-07-20 18:20:59 +01:00
Havard Graff
57eebe8b05 rtpstats: guard against division by zero
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/646>
2020-06-26 15:29:25 +00:00
Havard Graff
e45cc475bd rtptwcc: fix pruning of ack'ed twcc-packets
Fixes #750

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/645>
2020-06-26 12:53:07 +01:00
Sebastian Dröge
f8196e06d5 Revert "rtpjitterbuffer: Avoid deadlock on flush"
This reverts commit 54810bf44f

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/620>
2020-06-10 16:31:06 +00:00
U. Artie Eoff
bf0842aa0c rtpjitterbuffer: g_queue_clear_full introduced in glib 2.60
Define g_queue_clear_full if glib < 2.60.

Fixes #747

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/619>
2020-06-09 13:09:20 -07:00
Thibault Saunier
29a661d4a4 rtpsession: Make internal-ssrc as show default for doc 2020-06-09 11:45:13 -04:00
Nicolas Dufresne
5b2ad31583 rtptimerqueue: Fix leak on timer collision
While the caller should make sure this does not happen, make sure timer
collision are not silently ignored and leaked.

Fixes #726

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/616>
2020-06-08 17:54:53 -04:00
Nicolas Dufresne
b4f421e9aa rtpjitterbuffer: Keep JBUF lock while processing timers
Until now, do_expected_timeout() was shortly dropping the JBUF_LOCK in order
to push RTX event event without causing deadlock. As a side effect, some
CPU hung would happen as the timerqueue would get filled while looping over
the due timers. To mitigate this, we were processing the lost timer first and
placing into a queue the remainign to be processed later.

In the gap caused by an unlock, we could endup receiving one of the seqnum
present in the pending timers. In that case, the timer would not be found and
a new one was created. When we then update the expected timer, the seqnum
would already exist and the updated timer would be lost.

In this patch we remove the unlock from do_expected_timeout() and place all
pending RTX event into a queue (instead of pending timer). Then, as soon as
we have selected a timer to wait (or if there is no timer to wait for) we send
all the upstream RTX events. As we no longer unlock, we no longer need to pop
more then one timer from the queue, and we do so with the lock held, which
blocks any new colliding timers from being created.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/616>
2020-06-08 17:54:53 -04:00
Edward Hervey
54810bf44f rtpjitterbuffer: Avoid deadlock on flush
When a GST_EVENT_FLUSH_START reaches the jitterbuffer, there is a chance that
our task is currently blocking waiting for a timer.

There was two problems:
* That wait wasn't checking for flushing situations
* The flushing handling wasn't waking up that conditional (to check whether it
should abort)

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/608>
2020-06-08 13:34:26 +02:00
Mathieu Duponchelle
f63299ff2f plugins: uddate gst_type_mark_as_plugin_api() calls 2020-06-06 00:42:25 +02:00
Sebastian Dröge
e527eb3e4c rtpbin: Initialize uninitialized variable correctly
`last_out` would be used uninitialized if the element has no `set-active`
signal. Initialize it to -1 as that's what the "default" value is
further below.

CID 1455443

Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/727

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/613>
2020-06-05 11:49:17 +03:00
Thibault Saunier
6f0f41fef0 doc: Fix wrong link to GString in rtpjitterbuffer 2020-06-03 22:44:09 -04:00
Mathieu Duponchelle
37c619f995 plugins: Use gst_type_mark_as_plugin_api() for all non-element plugin types 2020-06-03 22:44:09 -04:00
Sebastian Dröge
7b22397cf5 rtpjitterbuffer: Properly free internal packets queue in finalize()
As we override the GLib item with our own structure, we cannot use any
function from GList or GQueue that would try to free the RTPJitterBufferItem.
In this patch, we move away from g_queue_new() which forces using
g_queue_free(). This this function could use g_slice_free() if there is any items
left in the queue. Passing the wrong size to GSLice may cause data corruption
and crash.

A better approach would be to use a proper intrusive linked list
implementation but that's left as an exercise for the next person
running into crashes caused by this.

Be ware that this regression was introduced 6 years ago in the following
commit [0], the call to flush() looked useless, as there was a g_queue_free()
afterward.

Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>

[0] 479c7642fd

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/573>
2020-04-22 10:28:30 -04:00
Havard Graff
981d0c02de rtpjitterbuffer: don't use RTX packets in rate-calc and reset-logic
The problem was this:

Due to the highly irregular arrival of RTX-packet the max-misorder variable
could be pushed very low. (-10).

If you then at some point get a big in the sequence-numbers (62 in the
test) you end up sending RTX-requests for some of those packets, and then
if the sender answers those requests, you are going to get a bunch of
RTX-packets arriving. (-13 and then 5 more packets in the test)

Now, if max-misorder is pushed very low at this point, these RTX-packets
will trigger the handle_big_gap_buffer() logic, and because they arriving
so neatly in order, (as they would, since they have been requested like
that), the gst_rtp_jitter_buffer_reset() will be called, and two things
will happen:
1. priv->next_seqnum will be set to the first RTX packet
2. the 5 RTX-packet will be pushed into the chain() function

However, at this point, these RTX-packets are no longer valid, the
jitterbuffer has already pushed lost-events for these, so they will now
be dropped on the floor, and never make it to the waiting loop-function.

And, since we now have a priv->next_seqnum that will never arrive
in the loop-function, the jitterbuffer is now stalled forever, and will
not push out another buffer.

The proposed fixes:
1. Don't use RTX in calculation of the packet-rate.
2. Don't use RTX in large-gap logic, as they are likely to be dropped.
2020-04-16 17:06:31 +02:00
Aaron Boxer
3b65663846 rtpbin: make warning messages more meaningful 2020-03-31 15:51:27 -04:00
Nicolas Pernas Maradei
ce0fb9bd29 rtpsession: rename RTCP thread
RTP session starts a new thread for RTCP and names it
"rtpsession-rtcp-thread" which happens to be longer than the maximum 16B
allowed by pthread_setname_np and causes the naming to fail.
See docs for more details.

This commit simply shortens the thread's name so it can actually be set.
2020-03-31 13:34:07 +02:00
Havard Graff
3368ed44a3 rtpjitterbuffer: create specific API for appending buffers, events etc
To avoid specifying a bunch of mystic variables.
2020-03-31 10:02:57 +00:00
Havard Graff
818b38ebdd rtpjitterbuffer: fix waiting timer/queue code
Changing the types from boolean to guint due to the ++ operand used on
them, and only call JBUF_SIGNAL_QUEUE after settling down,
or else you end up signaling the waiting code in chain() for every buffer
pushed out.
2020-03-30 22:32:21 +02:00
Xavier Claessens
6e1758d509 Fix usage of C99
It's 2020, way too early for that, let's stick to C89 for now.
2020-03-23 21:32:04 -04:00
Havard Graff
a710bda1ab rtptimerqueue: remove ->num from the timer
This concept was only used by the "multi"-lost timer, and since that
one is not around any longer, the "num" concept is superfluous.
2020-03-20 13:17:20 +00:00
Havard Graff
f1ff80ced0 rtpjitterbuffer: remove the concept of "already-lost"
This is a concept that only applies when a buffer arrives in the chain
function, and it has already been scheduled as part of a "multi"-lost
timer.

However, "multi"-lost timers are now a thing of the past, making this
whole concept superflous, and this buffer is now simply counted as "late",
having already been pushed out (albeit as a lost-event).
2020-03-20 13:17:20 +00:00
Havard Graff
5dacf366c0 rtpjitterbuffer: immediately insert a lost-event on multiple lost packets
There is a problem with the code today, where a single timer will
be scheduled for a series of lost packets, and then if the first packet
in that series arrives, it will cause a rescheduling of that timer, going
from a "multi"-timer to a single-timer, causing a lot of the packets
in that timer to be unaccounted for, and creating a situation in where
the jitterbuffer will never again push out another packet.

This patch solves the problem by instead of scheduling those lost packets
as another timer, it instead asks to have that lost-event pushed straight
out.

This very much goes with the intent of the code here: These packets are
so desperately late that no cure exists, and we might as well get the
lost-event out of the way and get on with it.

This change has some interesting knock-on effect being presented in
later commits. It completely removes the concept of "already-lost", so
that is why that test has been disabled in this commit, to be
removed later.
2020-03-20 13:17:20 +00:00
Havard Graff
2fa7e6a6d4 rtpjitterbuffer: refactor lost_timeout code
Split it up in code related to the timer, (do_lost_timeout) and code
to insert a lost-item/event and update private jitterbuffer-variables.
2020-03-20 13:17:20 +00:00
Havard Graff
4046970b01 rtptwcc: make RTPTWCCManager a GObject 2020-03-04 16:48:04 +01:00
Havard Graff
026223cde2 rtpjitterbuffer: fix stalling when resetting timers
When calling gst_rtp_jitter_buffer_reset you pass in a seqnum.

This is considered the starting-point for a new stream.

However, the old behavior would unref this buffer, basically lying to
the thread that is pushing out buffers saying that it can expect
this buffer, when it would never arrive. The resulting effect being no
more buffer pushed out of the jitterbuffer, and it would buffer
incoming data indefinitely.

By instead inserting the buffer in the gap_packets queue, the _reset()
function will take responsibility for using that as the first buffer
of the new stream.

Fixes #703
2020-03-04 12:55:52 +01:00
Nirbheek Chauhan
42e7864e90 rtpjitterbuffer: Don't use glib format modifiers with sscanf
We do not have a way to know the format modifiers to use with string
functions provided by the system. G_GUINT64_FORMAT and other string
modifiers only work for glib string formatting functions. We cannot
use them for string functions provided by the stdlib. See:
https://developer.gnome.org/glib/stable/glib-Basic-Types.html#glib-Basic-Types.description

```
../gst/rtpmanager/gstrtpjitterbuffer.c: In function 'gst_jitter_buffer_sink_parse_caps':
../gst/rtpmanager/gstrtpjitterbuffer.c:1523:32: error: unknown conversion type character 'l' in format [-Werror=format=]
           || sscanf (mediaclk, "direct=%" G_GUINT64_FORMAT, &clock_offset) != 1)
                                ^~~~~~~~~~
In file included from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib/gtypes.h:32,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib/galloca.h:32,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/glib-2.0/glib.h:30,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/gstreamer-1.0/gst/gst.h:27,
                 from /home/nirbheek/cerbero/build/dist/windows_x86/include/gstreamer-1.0/gst/rtp/gstrtpbuffer.h:27,
                 from ../gst/rtpmanager/gstrtpjitterbuffer.c:108:
/home/nirbheek/cerbero/build/dist/windows_x86/lib/glib-2.0/include/glibconfig.h:69:28: note: format string is defined here
 #define G_GUINT64_FORMAT "llu"
                            ^
../gst/rtpmanager/gstrtpjitterbuffer.c:1523:32: error: too many arguments for format [-Werror=format-extra-args]
           || sscanf (mediaclk, "direct=%" G_GUINT64_FORMAT, &clock_offset) != 1)
                                ^~~~~~~~~~
```

See also: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/379
2020-02-26 19:05:24 +05:30
Sebastian Dröge
3998b7cb4c rtpjitterbuffer: Include string.h for memcpy() / memset()
Usually something else is pulling it in somehow already, but not on
Windows.
2020-02-25 09:07:47 +00:00
Håvard Graff
fdf002d069 rtpsession: fix crash when no extension-header present for twcc 2020-02-24 13:06:27 +00:00
Matthew Waters
1326fcdbcc rtpbin: fix typo setting max-dropout/misorder-time
we were setting the max-dropout-time to the value of the
max-misorder-time which by default has a factor of 30 difference in
value.
2020-02-20 13:46:06 +11:00
Havard Graff
63ae338c24 rtpjitterbuffer: don't use the timer-object after JBUF_UNLOCK
It could have been freed (rtp_timer_free) in the meantime.
2020-02-17 15:04:45 +01:00
Havard Graff
1df706448c rtpmanager: Google Transport-Wide Congestion Control RTP Extension
Generating and parsing the RTCP-messages described in:
https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
2020-02-14 10:09:02 +00:00
Håvard Graff
9ba9837058 rtpfunnel: various cleanups
* Organize GstRtpFunnelPad and GstRtpFunnel separately
* Use G_GNUC_UNUSED instead of (void) casts
* Don't call an event "caps"
* Use semicolons after GST_END_TEST (helps gst-indent)
2020-02-14 10:08:05 +00:00
Mikhail Fludkov
57b0522cd7 rtpptdemux: set payload to caps inside gst_rtp_pt_demux_get_caps
Refactoring to remove duplicate code and add test
2020-02-11 18:39:22 +00:00
Stian Selnes
629b71ac9c rtpptdemux: Fix debug to use GST_DEBUG_OBJECT 2020-02-11 18:39:22 +00:00
Mikhail Fludkov
851a2b7925 rtpbin: use max-streams on rtpssrcdemux
The proper way of capping on max-streams is to do it in rtpssrcdemux.
This patch uses the newly introduced property on rtpssrcdemux. Previous
behavior would not prevent rtpssrcdemux spawning new pads for every new
ssrc and potentialy causing performance trouble during teardown.
2020-02-11 15:12:07 +01:00
John Bassett
16d750bc01 rtpssrcdemux: Handle RTCP APP packets
Fix crash when processing RTCP APP packets.
2020-02-11 15:12:07 +01:00
John Bassett
5800950a2d rtpssrcdemux: Bad RTP/RTCP packet is not fatal
When used for processing bundled media streams within rtpbin the rtpssrcdemux element may
receive bad RTP and RTCP packets, these should not be treated as a fatal error.
2020-02-11 15:10:12 +01:00