This affects the pt, ssrc, seqnum-offset and timestamp-offset properties. If
they were set from a property, or we configured caps before, we try to use
that value for them. Even if the first structure of the downstream caps
specifies a different value, we check if the value is supported by other
structures.
Only if all this fails, we use the values given by downstream in the first
structure, i.e. if no properties were set and these are the first caps we
negotiate or downstream does not support our values.
By doing this we ensure that we don't spuriously change ssrcs or other fields
in the middle of the stream (and also consider property values more). Ssrc
changes would currently happen after sending an RTX packet (thus creating a
new internal source inside the rtpsession), and then renegotiating the
payloader (which then gets the RTX ssrc from rtpsession).
https://bugzilla.gnome.org/show_bug.cgi?id=749581
When generating segment, we can't assume the first buffer is actually
the first expected one. If it's not, we need to adjust the segment to
start a bit before.
Additionally, we if don't know when the stream is suppose to have
started (no clock-base in caps), it means we need to keep everything in
running time and only rely on jitterbuffer to synchronize.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Previously the sequence number kept track of by GstRTPBasePayload would
only be set when going from READY to PAUSED state. This meant that a
downstream element that attempted to configure a basepayloader by
setting seqnum-offset e.g. in its sinkpad's caps template would have
trouble configuring the basepayloader. The reason was that the caps
event which arrives with the desired value for seqnum-offset did not
arrive at the basepayloader until caps negotiation took place,
significantly later than the transition from READY to PAUSED.
The result after this patch is that the default value for the
seqnum-offset property, or later set values for this property, will take
effect when going from READY to PAUSED like before. In addition the an
arriving caps event will also affect the basepayloaders configured
sequence number as the event arrives.
The payload type field in an RTP packet header is 7 bits wide, hence the
boundary values ought to be 0x00 and 0x7f, not the previously stated
values 0x00 and 0x80.
* Change running time type to guint64
* Use GST_CLOCK_TIME_NONE() to check for invalid timestamps
* Name variables so ns-based and hz-based timestamps are evident
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719383
The payload type can't be between 72 and 76 because with the marker bit set,
this could be mistaken for an RTCP packet then. We do a relaxed check and
only refuse 72-76 when the marker bit is set. The effect is that when
we try to map an RTCP packet as an RTP packet, we will certainly fail.
The function gst_rtp_buffer_get_payload can not be used in Python
because it lacks necessary length parameter. This patch adds a new
function, gst_rtp_buffer_get_payload_bytes, to use from Python
bindings. The new function has the advisory "Rename to:" annotation
so it can replace the gst_rtp_buffer_get_payload whan creating
bindings.
The function gst_rtp_buffer_get_extension_bytes is also added. It wraps
gst_rtp_buffer_get_extension_data which doesn't work in Python due to
incomplete annotation and because it returns the length as number of
32-bit words.
https://bugzilla.gnome.org/show_bug.cgi?id=698562
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
