We need a proper caps event from upstream with the full RTP caps as we can't
create caps ourselves from thin air. Fixes usage of rtpstreamdepay after e.g.
a filesrc or any other element that supports pull mode.
https://bugzilla.gnome.org/show_bug.cgi?id=753066
h264parse does the same, let's keep the behaviour consistent. As we now
include the codec_data inside the stream too here, this causes less caps
renegotiation.
The spec says:
When a picture parameter set NAL unit with a particular value of
pic_parameter_set_id is received, its content replaces the content of the
previous picture parameter set NAL unit, in decoding order, with the same
value of pic_parameter_set_id (when a previous picture parameter set NAL unit
with the same value of pic_parameter_set_id was present in the bitstream).
h264parse does the same and this fixes decoding of some streams with 32 SPS
(or 256 PPS). It is allowed to have SPS ID 0 to 31 (or PPS ID 0 to 255), but
the field in the codec_data for the number of SPS or PPS is only 5 (or 8) bit.
As such, 32 SPS (or 256 PPS) are interpreted as 0 everywhere.
This looks like a mistake in the part of the spec about the codec_data.
Need to check that the number of bytes we want to copy from the adapter
actually is available and handle the error case gracefully. This error
may happen if malformed packets are received and we don't have a
complete frame.
https://bugzilla.gnome.org/show_bug.cgi?id=752663
For more optimised RTP packet handling: means we don't
need to map the input buffer again but can just re-use
the mapping the base class has already done.
https://bugzilla.gnome.org/show_bug.cgi?id=750235
For more optimised RTP packet handling: means we don't
need to map the input buffer again but can just re-use
the map the base class has already done.
https://bugzilla.gnome.org/show_bug.cgi?id=750235
endpos variable does not correctly understand in the
4.6.3 GCC version. So compile error appears when we do
compile rtph261pay using jhbuild.
This patch is fixed the compile error in 4.6.3 GCC version.
https://bugzilla.gnome.org/show_bug.cgi?id=751985
Draft 16 of "RTP Payload Format for VP8" states in section 4.2 that:
R: Bit reserved for future use. MUST be set to zero and MUST be
ignored by the receiver.
https://bugzilla.gnome.org/show_bug.cgi?id=751929
gstrtph261pay.c: In function 'gst_rtp_h261_pay_class_init':
gstrtph261pay.c:1003:17: error: variable 'gobject_class' set but not used [-Werror=unused-but-set-variable]
GObjectClass *gobject_class;
Implementation according to RFC 4587.
Payloader create fragments on MB boundaries in order to match MTU size
the best it can. Some decoders/depayloaders in the wild are very strict
about receiving a continuous bit-stream (e.g. no no-op bits between
frames), so the payloader will shift the compressed bit-stream of a
frame to align with the last significant bit of the previous frame.
Depayloader does not try to be fancy in case of packet loss. It simply
drops all packets for a frame if there is a loss, keeping it simple.
https://bugzilla.gnome.org/show_bug.cgi?id=751886
We always pushed one buffer into the adapter, then handled exactly that one
buffer and flushed it from the adapter. Now also don't memcpy() the actual
payload but just attach the input buffer's data to the output buffer.
This code still needs some serious refactoring/rewriting.
Compiling (with gcc-4.9-20150603) produces an error because of an access beyond
the end of an array. This patch fixes the error by initializing the loop
control/array index variable (i) to 1 and returning i - 1 when a match is found.
Also, because the values stored in the array increase in value as the index
increases, the >= test unnecessary, so it is removed.
This depayloader clash with the standard one for H263p. It produces an
H263p stream with a modified header. It uses encoding-name that is the
same as H263p (H263-1998) though the resulting ES is not decodable or
parsable in GStreamer, making it unsuable in dynamic pipeline. This
patch unrank this specialized depayloader since it can only be used in
custom pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=739935
