The `reuse` property end up setting the SO_REUSEADDR socket option for
the UDP socket. This setting have surprising effects.
On Linux systems the man page (`socket(7)`) states:
```
SO_REUSEADDR
Indicates that the rules used in validating addresses supplied
in a bind(2) call should allow reuse of local addresses. For
AF_INET sockets this means that a socket may bind, except when
there is an active listening socket bound to the address.
```
But since UDP does not listen this ends up meaning that when an
ephemeral port is allocated (setting the `port` to `0`) the kernel is
free to reuse any other UDP port that has `SO_REUSEADDR` set.
Tests checking the likelyhood of port conflict when using multiple
`udpsrc` shows port conflicts starting to occur after ~100-300 udpsrc
with port allocation enabled. See issue #3411 for more details.
Changing the default value of a property is not a small thing we risk
breaking application that rely on the current default value. But since
the effects of having `reuse` default `TRUE` on can also have damaging
and hard-to-debug consequences, it might be worth to consider.
Having `SO_REUSEADDR` enabled for multicast, might have some use cases
but for unicast, with dynamic port allocation, it does not make sense.
When not using an multicast address we will disable port reuse if the
`port` property is set to 0 (=allocate) and warn the user that we did
so.
Closes#3411
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7841>
The gst_dep.get_variable('libexecdir') may fail in some scenarios
(e.g. building a module alone inside an uninstalled devenv) and
it shouldn't really be reached in the first place if docs are
disabled via options.
Also to avoid confusing meson messages when cross-compiling or
doing a static build.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7818>
Previously the wrapping of the 24-bit reference time was not handled
correctly when transforming it into GstClockTime. Given the unit of 64ms
the span that could be represented by 24 bits is 12 days and depending
on the start value we could get a wrapping problem anytime within this
time frame. This turned out to be particularly problematic for the GCC
algorithm in gst-plugins-rs which tried to evict old packages based on
the "oldest" timestamp, which due to wrapping problems could be in the
future. Thus, the container managing the packets could grow without
limits for a long time thereby creating both CPU and memory problems.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7527>
If a stream has an 'irregular' frame rate (e.g. metadata) RTCP SR
may be generated way too early, before the RTPSource has received
the first packet after Latency was configured in the pipeline.
We skip such RTPSources in the RTCP generation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7740>
Some servers (e.g. Axis cameras) expect the client to propose the encryption
key(s) to be used for SRTP / SRTCP. This is required to allow re-keying so
as to evade cryptanalysis. Note that the behaviour is not specified by the
RFCs. By setting the 'client-managed-mikey-mode' property to 'true', rtspsrc
acts as follows:
* For a secured profile (RTP/SAVP or RTP/SAVPF), any media in the SDP
returned by the server for which a MIKEY key management applies is
elligible for client managed mode. The MIKEY from the server is then
ignored.
* rtspsrc sends a SETUP with a MIKEY payload proposed by the user. The
payload is formed by calling the 'request-rtp-key' signal for each
elligible stream. During initialisation, 'request-rtcp-key' is also
called as usual. The keys returned by both signals should be the same
for a single stream, but the mechanism allows a different approach.
* The user can start re-keying of a stream by calling SET_PARAMETER.
The convenience signal 'set-mikey-parameter' can be used to build a
'KeyMgmt' parameter with a MIKEY payload.
* After the server accepts the new parameter, the user can call
'remove-key' and prepare for the new key(s) to be served by signals
'request-rtp-key' & 'request-rtcp-key'.
* The signals 'soft-limit' & 'hard-limit' are called when a key
reaches the limits of its utilisation.
This commit adds support for:
* client-managed MIKEY mode to srtpsrc.
* Master Key Index (MKI) parsing and encoding to GstMIKEYMessage.
* re-keying using the signals 'set-mikey-parameter' & 'remove-key' and
then by serving the new key via 'request-rtp-key' & 'request-rtcp-key'.
* 'soft-limit' & 'hard-limit' signals, similar to those provided by srtpdec.
See also:
* https://www.rfc-editor.org/rfc/rfc3830
* https://www.rfc-editor.org/rfc/rfc4567
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7587>
Move RB info from receiver reports into the internal source that the RR
are about, and deprecate (but retain) the old mapping where each
external source has only a single RB entry in the rtp statistics.
The old method is broken if a remote peer uses a single ssrc to send
receiver reports for more than one of our internal sources, other
as multiple RB in a single packet, or alternate RB in different reports.
In each case only the most recent entry was kept, overwriting data for
other internal sources.
In multicast scenarios each internal source may receive multiple
receiver reports from different peers. To support that, all received
RR's are now stored into a hash table indexed by the sender's SSRC,
and all RRs are placed into an array when generating statistics, so
that the information from all peers is retrievable.
The current deficient behaviour (adding RB info into non-internal RTPSources) is
deprecated but kept in order to be backward compatible, and retained
that way in the generated statistics structure.
Refs
[1] https://tools.ietf.org/html/rfc3550#section-6.4.1
Based on a patch by Fede Claramonte <fclaramonte@twilio.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7424>
A zero-sized box is not really a problem and can be skipped to look at any
possibly following ones.
BMD ATEM devices specifically write a zero-sized bmdc box in the sample
description, followed by the avcC box in case of h264. Previously the avcC box
would simply not be read at all and the file would be unplayable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7564>
This notably follow the way we order the template and keeps the
format:Interlaced caps at the end. This change also fixes
an early skip check, that would skip if a driver only supports
alternate interlacing for a specific format. It also fixes
a bug where only the last resolution of a discrete frame size
was allowed to use format:Interlaced. Finally, similar to template
caps code, simplify the caps for earch featurs, making the debug output
manageable and (marginally) improve negotiation speed.
This change will make it easier to introduce memory:DMABuf.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7540>
In qml6glsrc, we capture the application by copying the back buffer into
our own FBO. The afterRendering() signal is too soon as from the apitrace, the
application has been rendered into a QT internal buffer, to be used as a cache
for refresh.
Use afterFrameEnd() signal instead. This works with no delay on GLES. With GL
it seems to reduce from 2 to 1 frame delay (this may be platform specific). A
different recording technique would need to be used to completely remove this
delay.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7351>
Timestamps are untouched by default, but the new mode can now be enabled to replace RTP timestamps
with ones generated from the buffer PTS. Making it an enum in case different modes are needed in the future.
That allows for a rtpjitterbuffer to do proper drift compensation, so that the stream coming out of gst-rtsp-server
is not drifting compared to the pipeline clock and also not compared to the RTCP NTP times.
Most of the code is borrowed from rtpbasepayload, as it's exactly its behaviour which I wanted to bring here.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7526>
Valgrind complains about uninitialized memory used in an ioctl
Syscall param ioctl(VKI_V4L2_G_TUNER).reserved points to uninitialised byte(s)
at 0x719294F: ioctl (ioctl.c:36)
by 0x3126A817: gst_v4l2_fill_lists (v4l2_calls.c:185)
by 0x3126A817: gst_v4l2_open (v4l2_calls.c:589)
by 0x3123F1C2: gst_v4l2_device_provider_probe_device (gstv4l2deviceprovider.c:122)
by 0x3123F648: gst_v4l2_device_provider_device_from_udev (gstv4l2deviceprovider.c:301)
by 0x3123F998: provider_thread (gstv4l2deviceprovider.c:395)
by 0x796FA50: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.4)
by 0x710CAC2: start_thread (pthread_create.c:442)
by 0x719DA03: clone (clone.S:100)
Address 0x44008a34 is on thread 11's stack
in frame #1, created by gst_v4l2_open (v4l2_calls.c:524)
Uninitialised value was created by a stack allocation
at 0x3126A024: gst_v4l2_open (v4l2_calls.c:524)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6144>
