In file included from gstrtpL16depay.h:27:0,
from gstrtp.c:73:
gstrtpchannels.h:154:33: error: 'channel_orders' defined but not used [-Werror=unused-const-variable]
static const GstRTPChannelOrder channel_orders[] =
It's not enough to have timeout or event based SPS/PPS information sent
in RTP packets. There are some scenarios when key frames may appear
more frequently than once a second, in which case the minimum timeout
for "config-interval" of 1 second for sending SPS/PPS is not sufficient.
It might also be desirable in general to make sure the SPS/PPS is
available with every keyframe (packet loss aside), so receivers can
actually pick up decoding immediately from the first keyframe if
SPS/PPS is not signaled out of band.
This patch adds the possibility to send SPS/PPS with every key frame. This
mode can be enabled by setting "config-interval" property to -1. In this
case the payloader will add SPS and PPS before every key (IDR) frame.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
This way we can use -1 as special value, which is nicer than MAXUINT.
This is backwards compatible even with the GValue API, as shown by
a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
Actual code is checking for a NULL terminator and a ';' terminator,
for backward compat, in a chained way that cause all events being rejected.
The proper condition is to reject the events when terminator isn't
in ['\0', ';'] set.
https://bugzilla.gnome.org/show_bug.cgi?id=758151
* use g_list_free_full(), don't iterate elements maually when freeing
* call gst_rtp_*_pay_clear_packet(), don't duplicate its code
* use gst_buffer_unref() to clarify that it is buffers being released,
instead of refering directly to gst_mini_object_unref()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=755277
Use constantDuration to calculate the timestamp of non-first AU in the
RTP packet.
If constantDuration is not present in the MIME parameters, its value
must be calculated based on the timing information from two consecutive
RTP packets with AU-Index equal to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=747881
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the video tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
GstRTSPMedia uses this classification to detect the real payloader
inside a dynpay bin and asserts if it doesn't find it, therefore
it is required
https://bugzilla.gnome.org/show_bug.cgi?id=753325
Initialize the PT to the default value of the codec and check if
it is still the default before declaring the pt to be dynamic or
not when setting the caps.
Also use the PT constants from the rtp lib when possible
https://bugzilla.gnome.org/show_bug.cgi?id=747965
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
