Commit graph

1150 commits

Author SHA1 Message Date
Tim-Philipp Müller
db688c5504 docs: fix typos 2018-05-23 13:14:27 +01:00
Tim-Philipp Müller
5b8e775d1c rtpvrawpay: don't use buffer lists if everything fits into one buffer
People might use very large mtu sizes where every payload
fits into a single output packet.

https://bugzilla.gnome.org/show_bug.cgi?id=795758
2018-05-05 16:32:59 +02:00
Xavier Claessens
edd9c8f6b8 Meson: Generate pc file for all plugins in good
https://bugzilla.gnome.org/show_bug.cgi?id=794568
2018-04-25 11:07:06 +01:00
Mathieu Duponchelle
90f5ae8f45 ulpfecdec: output perfect seqnums
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
2018-04-19 18:17:39 +02:00
Sebastian Dröge
ed2ccb1a60 rtp: Fix compilation with non-C99 compilers
By moving variable declarations out of loop headers.
2018-03-20 12:08:28 +02:00
Tim-Philipp Müller
56577236f8 rtpulpfecdec: fix build with older gcc
As on Ubuntu Trusty.

https://bugzilla.gnome.org/show_bug.cgi?id=794493
2018-03-19 18:39:08 +00:00
Tim-Philipp Müller
47ff21ea3b rtpulpfec: fix unconditional use of __attribute__ ((packed))
Fix compilation with MSVC. We still assume that attribute
is supported by all other relevant compilers, which seems
to be the case since we haven't had any complaints about
similar code in rtpsbcpay.
2018-03-17 20:29:35 +00:00
Tim-Philipp Müller
65ede0b565 rtpulpfec: don't use non-portable notation for 64-bit int constants
Use GLib macro instead, even if it's a bit unwieldy.
2018-03-17 13:04:47 +00:00
Tim-Philipp Müller
c21765e88e rtpulpfecdec: don't use __builtin_ctzll unconditionally
Fixes build with MSVC, and possibly other compilers too.
2018-03-17 12:55:57 +00:00
Tim-Philipp Müller
7b74816f07 rtp: fix another debug log printf format warning on 32-bit systems
rtpulpfeccommon.c:432:27: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘guint64 {aka long long unsigned int}’

https://bugzilla.gnome.org/show_bug.cgi?id=793732
2018-02-27 13:13:49 +00:00
Mathieu Duponchelle
3a754d51e0 FEC elements: document, remove irrelevant properties
The ulpfecenc "mux-seq" and "ssrc" properties were initially added
because the element did more than implement ULPFEC. As it was
decided that FLEXFEC would be implemented in a separate element,
both properties are now unneeded and confusing.

Change the default for the ulpfecenc multi-packet property,
as it is expected that most users of this element will be protecting video
streams.

Change the default property for the rtpredenc allow-no-red-blocks
property, as it should also be its default mode of operation.

https://bugzilla.gnome.org/show_bug.cgi?id=793843
2018-02-26 16:41:12 +01:00
Mathieu Duponchelle
efb4ee1919 rtpgstdepay: do not warn when caps were not yet received
It is expected that when connecting to a stream that has
already started, the caps will only arrive at the interval
specified on rtpgstpay, we shouldn't be warning as this is
a normal mode of operation.

https://bugzilla.gnome.org/show_bug.cgi?id=793798
2018-02-24 20:06:54 +01:00
Arnaud Bonatti
e3a3d4fb76 rtpulpfec: fix debug log printf format warning on 32-bit platforms
https://bugzilla.gnome.org/show_bug.cgi?id=793732
2018-02-23 10:02:23 +00:00
Tim-Philipp Müller
427033591c docs: hook up new RTP FEC elements
https://bugzilla.gnome.org/show_bug.cgi?id=792696
2018-02-22 15:56:49 +00:00
Tim-Philipp Müller
51177004d3 rtp: dist new header files
Fixes make distcheck
2018-02-21 20:45:31 +00:00
Tim-Philipp Müller
3789afd491 rtp: fec: fix build with gstreamer debug log system disabled 2018-02-21 19:01:15 +00:00
Mikhail Fludkov
d5ad50bd61 rtp: Implement ULPFEC (RFC 5109)
We expose a set of new elements:

* ULPFEC encoder / decoder
* A storage element, which should be placed before jitterbuffers,
  and is used to store packets in order to attempt reconstruction
  after the jitterbuffer has sent PacketLost events
* RED encoder / decoder (RFC 2198), these are necessary to
  use FEC in webrtc, as browsers will propose and expect ulpfec
  packets to be wrapped in red packets

With contributions from:

Mathieu Duponchelle <mathieu@centricular.com>
Sebastian Dröge <sebastian@centricular.com>

https://bugzilla.gnome.org/show_bug.cgi?id=792696
2018-02-21 14:15:22 +01:00
Alban Bedel
4e7ce28623 rtpvorbisdepay: fix unbounded memory usage
All received configurations are parsed and added to a list, this lead
to an unbounded memory usage. As the configuration is resent every
second this quickly lead to a large memory usage.

Add a check to only add the config if it is not already available in
the list. This fix only handle the typical case of a well behaved
stream, a malicious server could still send many useless
configurations to raise the client memory usage.
2018-02-14 18:04:56 +00:00
Justin Kim
dabeed52a9 rtph264depay: update output caps regardless format
`codec_data` should be transfered if any information of
SPS/PPS is changed.

https://bugzilla.gnome.org/show_bug.cgi?id=790000
2018-02-01 10:09:20 +00:00
Tim Allen
db07fc7e85 rtp: add L8 audio support 2017-12-24 13:19:56 +01:00
Tim-Philipp Müller
c8ff205089 rtph265depay: don't insert SPS/PPS inline for hvc1 output
Only for byte-stream or hev1. For hvc1 the SPS/PPS are in the
caps as codec_data field and in this case they shouldn't be in
the stream data as well. The output caps should be updated with
the new codec_data if needed, for hvc1.
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
8da79ca824 rtph265depay: store negotiated output format as enum
We keep the boolean byte_stream around since it's nicer for
readability and most of the code just cares about byte_stream
or not. This is useful for future-proofing the code for when
we add support for hev1 output as well.
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
46861027b9 rtph265depay: add support for hvc1 as output format 2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
b84201bf81 rtph265pay: don't add trailing zeros to VPS/PPS/SPS
This would happen if input is byte-stream with four-byte
sync markers instead of three-byte ones. The code that
scans for sync markers will place the start of the NALU
on the third-last byte of the NALU sync marker, which
means that any additional zeros may be counted as belonging
to the previous NALU instead of being part of the next sync
marker. Fix that so we don't send VPS/SPS/PPS with trailing
zeros in this case.

See https://bugzilla.gnome.org/show_bug.cgi?id=732758
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
311b9895ba rtph265depay: assemble AUs into downstream-allocated memory
When merging NALs into AUs, use downstream-provided allocator
to allocate memory and copy NALs directly into that memory when
assembling them.
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
2d0ea4d381 rtph265depay: try to negotiate an allocator with downstream 2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
528b7e01f1 rtph265depay: simplify buffer accumulation control flow
There is no difference between pushing out a buffer directly
with gst_rtp_base_depayload_push() and returning it from the
process function. The base class will just call _depayload_push()
on the returned buffer as well.

So instead of marshalling buffers through three layers and back,
just push them from one place in handle_nal() and always return
NULL from the process vfunc. This simplifies the code a little.

Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
for clarity. Push sounds like it means being pushed out, whereas
it might just be pushed into an adapter.

This change has the side-effect that multiple NALs in a single STAP
(such as SPS/PPS) may no longer be pushed out as a single buffer if
we output NALs in byte-stream format (i.e. not aggregate AUs), but
that shouldn't really make any difference to anyone.
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
289882497a rtph265depay: fix crash with empty sprops-parameters
https://bugzilla.gnome.org/show_bug.cgi?id=780040
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
0580efc6a6 rtph265depay: minor clean-up
Declutter caps update code a bit.
2017-11-23 09:36:15 +01:00
Philip Craig
ec11b228a4 rtph264pay: don't add trailing zeros to PPS/SPS
This would happen if input is byte-stream with four-byte
sync markers instead of three-byte ones. The code that
scans for sync markers will place the start of the NALU
on the third-last byte of the NALU sync marker, which
means that any additional zeros may be counted as belonging
to the previous NALU instead of being part of the next sync
marker. Fix that so we don't send SPS/PPS with trailing
zeros in this case.

https://bugzilla.gnome.org/show_bug.cgi?id=732758
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
f3e4df72a1 rtph264depay: assemble AUs into downstream-allocated memory
When merging NALs into AUs, use downstream-provided allocator
to allocate memory and copy NALs directly into that memory when
assembling them.
2017-11-23 09:35:59 +01:00
Tim-Philipp Müller
b6f13ce4e9 rtph264depay: try to negotiate an allocator with downstream 2017-11-23 09:35:59 +01:00
Tim-Philipp Müller
44f70445b6 rtph264depay: minor clean-up
Declutter caps update code a bit.
2017-11-23 09:27:22 +01:00
Edward Hervey
50c3733a89 rtpmpvpay: Don't create empty buffer list
If there's nothing to send, just return
2017-11-10 15:51:05 +01:00
Youness Alaoui
593615de46 rtpg722pay: Add encoding-params to the src caps template
The G722 payload only accepts G722 audio with channels=1, so it must
specify the encoding-params=1 in its src caps, otherwise it causes issues
with farstream which thinks it supports 2 channels G722 and when
confronted with a remote that has G722/8000/2, it will negotiate it
and error out with a not-negotiated when the caps don't intersect
at runtime.

https://bugzilla.gnome.org/show_bug.cgi?id=789878
2017-11-03 17:20:31 -04:00
Sebastian Dröge
263494f9c7 rtpsbcdepay: Fix potential NULL pointer dereference
CID 1418864
2017-10-07 14:06:38 +03:00
Sebastian Dröge
58f0eabd61 sbcdepay: Add property to ignore input timestamps
This then just counts samples and calculates the output timestamps based
on that and the very first observed timestamp. The timestamps on the
buffers are continued to be used to detect discontinuities that are too
big and reset the counter at that point.

When receiving data via Bluetooth, many devices put completely wrong
values into the RTP timestamp field. For example iOS seems to put a
timestamp in milliseconds in there, instead of something based on the
current sample offset (RTP clock-rate == sample rate).

https://bugzilla.gnome.org/show_bug.cgi?id=787297
2017-09-28 14:15:12 +03:00
Ponnam Srinivas
c0622addf6 rtph265depay: Fix Memory leak in error case
https://bugzilla.gnome.org/show_bug.cgi?id=787937
2017-09-26 11:09:53 +03:00
Tim-Philipp Müller
6f9cb1716a rtph265depay: fix keyunit detection
https://bugzilla.gnome.org/show_bug.cgi?id=787254
2017-09-05 13:56:18 +01:00
Arun Raghavan
301e8d558e rtpsbcpay: Fix some tabs that crept in somehow 2017-08-29 22:12:35 +05:30
Arun Raghavan
e6b6583a5e rtpsbcpay: Fix compile error 2017-08-14 17:39:15 +05:30
Jochen Henneberg
f641ac60e3 rtpsbcpay: fix if buffer size exceeds MTU
The plugin queued buffer data if not all buffer data fit
into a single RTP packet. Now RTP packets are pushed as long
as enough data is available.
2017-08-14 16:56:17 +05:30
Yasushi SHOJI
c7f42cc3bc rtpgsmpay: fix accidental garbage data before actual payload
Do not allocate payload size outbuf if appending payload buffer.

The commit 137672ff18 attached payload
to the output buffer but forgot to remove payload allocation.  That
effectively doubled payload size and add zero'ed or random bytes.

Makes the following pipeline work again:

gst-launch-1.0 -v audiotestsrc wave=2 ! gsmenc ! rtpgsmpay ! rtpgsmdepay ! gsmdec ! autoaudiosink

https://bugzilla.gnome.org/show_bug.cgi?id=784616
2017-07-09 13:21:23 +01:00
Tim-Philipp Müller
18b53c2236 rtph265depay: fix caps leak 2017-06-02 11:30:15 +01:00
Tim-Philipp Müller
a68a7fb65d rtph264depay: simplify buffer accumulation control flow
There is no difference between pushing out a buffer directly
with gst_rtp_base_depayload_push() and returning it from the
process function. The base class will just call _depayload_push()
on the returned buffer as well.

So instead of marshalling buffers through three layers and back,
just push them from one place in handle_nal() and always return
NULL from the process vfunc. This simplifies the code a little.

Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
for clarity. Push sounds like it means being pushed out, whereas
it might just be pushed into an adapter.

This change has the side-effect that multiple NALs in a single STAP
(such as SPS/PPS) may no longer be pushed out as a single buffer if
we output NALs in byte-stream format (i.e. not aggregate AUs), but
that shouldn't really make any difference to anyone.
2017-06-01 17:32:17 +01:00
Tim-Philipp Müller
a9f9166004 rtpopusdepay: minor perf improvements
Use the ::process_rtp_packet() vfunc to avoid mapping the
RTP buffer twice.

gst_rtp_buffer_get_payload_buffer() returns a new sub-buffer
which will always be writable, so no need to make it writable.
2017-05-24 16:41:45 +01:00
Tim-Philipp Müller
f9a740b319 rtp: opus: use existing utility funcs for copying/dropping metas
We had our own copies of those while the code was in -bad, but now
we can use the existing utility functions instead of re-implementing
them.
2017-05-24 16:18:01 +01:00
Tim-Philipp Müller
4a28e649c3 rtp: cache meta tag quarks and add more utility functions for metas
Every g_quark_from_static_string() is a hash table lookup serialised
on the global quark lock in GLib. Let's just look up the two quarks
we need once and cache them locally for future use. While we're at it,
add new utility functions for the two most commonly used tags
(audio + video). Make first argument a gpointer so we don't have to
cast and make the code ugly. These are used for logging purposes
only anyway.
2017-05-24 13:32:10 +01:00
Nicolas Dufresne
b68d936ae0 Remove plugin specific static build option
Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.
2017-05-16 14:41:19 -04:00
Tim-Philipp Müller
e7e7f26200 rtph264depay: don't insert SPS/PPS inline for AVC output
SPS/PPS are in the caps in this case and shouldn't be in
the stream data.
2017-04-24 17:29:37 +01:00