Incomming buffer is only pushed on the adapter at the end of the
handle_buffer function. But duration/timestamp of this buffer is already
taken into account for the current data in the adapter. This leads to
wrong rtp timestamps and extra latency.
Put a DISCONT event on the next output buffer when the input buffer had a
DISCONT.
Make sure we clear our adapter and reset our state before going to PAUSED.
Free the qtables.
Fixes#626869
Although the spec says that the clock-rate should always be 90000, some rtsp
servers send different clock-rates so we must accept then in order to handle
those streams too.
When we can't find any channel or encoding-params on the caps for dynamic
payload types, set the default number of channels to 1, as the spec says we
should.
See #623209
When parsing the number of channels, use the encoding-params property from the
RTP caps because that is where we can find the channels according to the spec.
Fall back to the channels property in the caps when needed.
Fixes#623209
G729 packets may only occur intermittently (e.g. cn packets), and as such
do not allow for perfect-rtptime calculating rtp times based on frame or byte
count. In particular, do not use rtp audio base payloader as base class, but
rather base payloader directly.
Even though we don't use delivery-method in our payloader, older versions of
the theora payloader in gstreamer required it. As such we need to keep this
around in the caps for backwards-compatibility.
This reverts part of 49463a37cbFixes#618940
When we calculate the frame duration, we need to use the amount of
frames in the _previous_ packet, not the current packet. The frame duration is
needed to correctly de-interleave interleaved streams. This fixes the case where
there are a variable number of frames in a packet.
Fixes#620494
It probably will not be in the final RFC as it is not in RFC 5215 for Vorbis.
If there is a configuration specified, assume it is in-line and if nothing is
specified, assume it is in-band.
https://bugzilla.gnome.org/show_bug.cgi?id=618386
Don't blindly add the durations of incomming buffers to the total queued
duration because it might be invalid. Mark the total queued duration invalid
when we receive an invalid incomming timestamp because that's when we lose track
of the total queued duration.
Fixes#618324
