Updating of codec_data in the caps is important to propagate changes
in sps/pps/vps via NALs. Without this, downstream does not renegotiate
when upstream changes resolution.
The comment referring to rtph264pay is from 2015 and is out of date.
rtph264pay stopped doing that in 2017 with commit
dabeed52a9
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1011>
On Windows with MSVC, jpeg_header_size would end up 2 bytes larger
than it should be. This then leads to the first 2 bytes of the
actual jpeg image data to be dropped, because we think those
belong to the header, which results in an undecodable image when
reconstructed in the depayloader.
What happens is that when the compiler evaluates
jpeg_header_size = mem.offset + read_u16_and_inc_offset_by_2(&mem);
it actually uses the mem.offset value after it has been increased
by the function call on the right hand size of the equation.
From section 6.5 of the C99 spec:
3. The grouping of operators and operands is indicated by the syntax [74].
Except as specified later (for the function-call (), &&, ||, ?:, and
comma operators), the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/889
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/999>
gst_rtp_sbc_pay_flush_buffers() is a misleading name. A better name would
be gst_rtp_sbc_pay_drain_buffers(), because that's what it does, it drains
any leftover queued data and pushes it downstream. "Flushing" in GStreamer
typically means to throw away any queued data and not process/push it
downstream.
Signed-off-by: Michal Dzik <michal.dzik@streamunlimited.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/700>
GstAdapter must be flushed in some cases (flush, new segment, state change)
Without it, it may, for example, push some leftover buffer from old
segment in new segment. This, in general, breaks timestamps.
See GstAdapter documentation for more.
Signed-off-by: Michal Dzik <michal.dzik@streamunlimited.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/700>
Similar to rtpvp8depay, when packet loss occurs, the depayloader
starts waiting for a keyframe.
We try to only stop waiting when all the packets for the new keyframe
have been received, by only resetting waiting_for_keyframe when
encountering the first packet of a keyframe, this is slightly
fragile because there is no bit that explicitly marks the start
of an access unit, so we rely on the existing picture_start
detection code.
As a consequence, the property is only meaningful when outputting
access units, and is ignored when outputting NALs directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/834>
- Fix start and end of picture to support multiple layers. Start of
picture is the first packet of the base layer, while end of picture
is when the marker bit is set (last packet of the enhancement
layers).
- All "layers" (aka "frames") of a picture are pushed downstream in a
single buffer when picture is complete.
- Forgive SID=0 for enhancement layers (invalid, but Chrome and
Firefox sends it)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/773>
This is ad adaptation of a Pexip patch for dealing with spurious
GstRTPPacketLost events caused by lost ulpfec packets: as FEC packets
under that scheme are spliced in the same sequence domain as the media
packets, it is not generally possible to determine whether a lost packet
was a FEC packet or a media packet.
When upstreaming pexip's ulpfec patches, we decided to drop all lost
events at the base depayloader level, and where the original patch
from pexip was making use of picture ids and marker bits to determine
whether a packet should be forwarded, this patch makes use of those
to determine whether they should be dropped instead (by removing their
might-have-been-fec field).
Spurious lost events coming out of the depayloader can cause the
decoder to stop decoding until the next keyframe and / or request a new
keyframe, and while this is not desirable it makes sense to forward
that information when we have other means to determine whether a lost
packet was indeed a FEC packet, as is the case with VP8 / VP9 payloads
when they carry a picture id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/769>
The AVC codec_data has a flaw that it can only accomodate
31 SPS headers, even though H.264 can have 32, and 255 PPS,
when there can be 256 in H.264. When streaming RTP some
clients like to cycle through SPS/PPS ids when changing
configuration and can eventually accumulate a full set.
In that case, we have no choice but to discard one (oldest)
entry, or else the count written into the codec_data is wrong
and downstream decoding failures ensue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/775>
Add property to set the initial value for picture-id. RFC7741 says
that picture-id MAY be initialized to a random value, thus it's also
valid to simply set it to a fixed initial value. A fixed value is very
useful for testing.
Default behavior is not changed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/728>
If we have not received a FU with a start bit set, any subsequent FU
data is not useful at all and would result in an invalid stream.
This case is constructed from multiple requirements in
RFC 3984 Section 5.8 and RFC 7798 Section 4.4.3. Following are excerpts
from RFC 3984 but RFC 7798 contains similar language.
The FU in a single FU case is forbidden:
A fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the
Start bit and End bit MUST NOT both be set to one in the same FU
header.
and dropping is possible:
If a fragmentation unit is lost, the receiver SHOULD discard all
following fragmentation units in transmission order corresponding to
the same fragmented NAL unit.
The jump in seqnum case is supported by this from the specification
instead of implementing the forbidden_zero_bit mangling:
If a fragmentation unit is lost, the receiver SHOULD discard all
following fragmentation units in transmission order corresponding to
the same fragmented NAL unit.
A receiver in an endpoint or in a MANE MAY aggregate the first n-1
fragments of a NAL unit to an (incomplete) NAL unit, even if fragment
n of that NAL unit is not received. In this case, the
forbidden_zero_bit of the NAL unit MUST be set to one to indicate a
syntax violation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/730>
gst_buffer_map () results in memcopying when a GstBuffer contains
more than one GstMemory.
This has quite an impact on performance on systems with limited amount
of resources. With this patch the whole GstBuffer will not be mapped at
once, instead each individual GstMemory will be iterated and mapped
separately.
There is a use-case for a server to re-payload opus going through it.
Problem was that the payloader requires channels in the caps, but
this is not something the depayloader can parse out of the stream, meaning
caps-negotiation would fail.
Removing the requirement of channels in the template-caps fixes this.
gst_buffer_map () results in memcopying when a GstBuffer contains
more than one GstMemory and when AVC (length-prefixed) alignment is used.
This has quite an impact on performance on systems with limited amount of
resources. With this patch the whole GstBuffer will not be mapped at once,
instead each individual GstMemory will be iterated and mapped separately.
