Otherwise ssrc changes via rtpsession's (deprecated!) internal-ssrc property
are not possible anymore. rtpsession was now patched to only suggest an ssrc
if it makes sense to do so.
In 2.0 we should get rid of all the properties that are also negotiated via
caps, the code and behaviour is too confusing otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=749581
According to this section of the rfc.
https://tools.ietf.org/html/rfc5506#section-3.4.2
The validation should be updated to accept more types of RTCP
packages, with this mask change feedback packages will be also
accepted.
Change-Id: If5ead59e03c7c60bbe45a9b09f3ff680e7fa4868
Micro-optimisation: if the buffer consist of just one memory, we
know we have already mapped that memory to read the headers, so
no need to map it another time to get to the payload data, we
can just set up the payload data details right there and then
and avoid another map call in gst_rtp_buffer_get_payload().
Adds up when receiving RTP-payloaded raw video which can easily
be thousands of packets per frame.
Implement a chain_list function, which avoids lots of locking
compared to the default fallback implementation in GstPad.
We may also want to do some more sophisticated timestamp
tracking here at some point, but for now leave it up to the
jitterbuffer and/or subclasses (in case buffers in the
buffer list have no timestamp set on them, there may only
be a timestamp for the whole list on the first buffer).
This provides the exact same behaviour as the default
fallback implementation.
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.
This reverts commit e39fbe6b7e.
Looks like we need to pass the full .la file after all in a setup
with libtool, or it might not find the library, e.g. like
ERROR: can't resolve libraries to shared libraries: gstfft-1.0
Conflicts:
gst-libs/gst/audio/Makefile.am
gst-libs/gst/pbutils/Makefile.am
Also see https://bugzilla.gnome.org/show_bug.cgi?id=603710
Most payloaders set/send their own output format from the setcaps
function, so if we don't get input caps, things probably wont' work
right, even if the input format is fixed (as in the case of the mpeg-ts
payloader for example).
https://bugzilla.gnome.org/show_bug.cgi?id=683428
Allocate header, payload and padding in separate memory blocks in
gst_rtp_buffer_allocate().
don't use part of the payload data as storage for the extension data but store
it in a separate memory block that can be enlarged when needed.
Rework the one and two-byte header extension to make it reserve space for the
extra extension first.
Fix RTP unit test. Don't map the complete buffer or make assumptions on the
memory layout of the underlaying implementation. We can now always add extension
data because we have a separate memory block for it.
Add support RTP buffers with multiple memory blocks. We allow one block for the
header, one for the extension data, N for data and one memory block for the
padding.
Remove the validate function, we validate now when we map because we need to
parse things in order to map multiple memory blocks.
RTCP header can be (2^16 + 1) * 4 bytes long, so when validating a bogus
packet it was possible to get a 16bit overflow resulting in a length of 0.
This would put the gst_rtcp_buffer_validate_data function in a endless loop.
https://bugzilla.gnome.org/show_bug.cgi?id=667313
gst_basertppayload -> gst_base_rtp_payload
Add pts/dts support in the depayloader
Remove old timestamp code
Add a default getcaps function so subclasses can chain up to it instead of
relying on the return value of the getcaps function.
Without the perfect timestamp machinery, the RTP timestamp can be
computed directly from the running time of a buffer, but the perfect
timestamp patch broke that assumption. This patch restores it by
having the first perfect timestamp be the running time of that buffer
and counting from there.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=654434
... which allows adding additional packets and may be needed to counteract
the shrink that implicitly occurred during a map/unmap cycle when adding
a previous packet.
Use the caps event instead of the setcaps function to configure caps.
Use a default event handler for the base rtp payloader instead of the awkward
way of handling the return value.
