GitLab

https://bugzilla.gnome.org/show_bug.cgi?id=732144

Decoder complains about "notification: Invalid mode encountered.
The stream is corrupted" though, even if it works, so there's
probably something wrong with the generated codec headers.

Speex in FLV is always mono @ 16kHz, see
http://download.macromedia.com/f4v/video_file_format_spec_v10_1.pdf
section E.4.2.1: "If the SoundFormat indicates Speex, the audio is
compressed mono sampled at 16 kHz, the SoundRate shall be 0, the
SoundSize shall be 1, and the SoundType shall be 0"

Also see https://bugzilla.gnome.org/show_bug.cgi?id=683622

Enables playback for files with DTS audio tracks.
Also add an extra AC-3 variant fourcc from Nero

Change function pointers to NULL while holding the lock to avoid
race conditions

https://bugzilla.gnome.org/show_bug.cgi?id=701110

Implement 3 different cases for handling the SR:

 1) we don't have enough timing information to handle the SR packet and
    we need to wait a little for more RTP packets. In that case we keep
    the SR packet around and retry when we get an RTP packet in the
    chain function.

 2) the SR packet has a too old timestamp and should be discarded. It is
    labeled invalid and the last_sr is cleared.

 3) the SR packet is ok and there is enough timing information, proceed
    with processing the SR packet.

Before this patch, case 2) and 1) were handled in the same way,
resulting that SR packets with too old timestamps were checked over and
over again for each RTP packet.

They all seem a bit pointless though.

https://bugzilla.gnome.org/show_bug.cgi?id=731324

Otherwise we will parse it over and over again without ever
getting past it.

https://bugzilla.gnome.org/show_bug.cgi?id=731533

"have-ns-view" and the "embed" property was kept in 0.10 for
backwards compatibility but it's no longer used in favor of
the GstVideoOverlay interface

https://bugzilla.gnome.org/show_bug.cgi?id=703753

It will crash with latest GLib GIT and was never supposed to work before
either.

We know the buffer will stay valid and we will also not
modify the buffer, we just want to send out the data.

This way the app can choose different parameters for each stream.

This patch adds supports for the incoming key management parameters for
encryption and authentication key lengths.

It also adds a new signal request-rtcp-key that allows the user to
provide the crypto parameters and key for the RTCP stream.

https://bugzilla.gnome.org/show_bug.cgi?id=730473

Use a different variable name to make it clear that we are calculating
the header size.
Correctly check that we have enough bytes to read the header bits. We
were checking if there were 5 bytes available in the header while we
only needed 3, causing the packet to be discarded as too small.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=723595

Similarly to what we did with the DELTA_UNIT flag, this patch
propagates the DISCONT flag to the first RTP packet being used to transfer a
DISCONT buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=730563

Downstream elements may be interested knowing if a RTP packet is the start
of a key frame (to implement a RTP extension as defined in the
ONVIF Streaming Spec for example).

We do this by checking the GST_BUFFER_FLAG_DELTA_UNIT flag we receive from
upstream and propagate it to the *first* RTP packet outputted to transfer this
buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=730563

Propagate the DISCONT flag to the first RTP packet being used to transfer
a DISCONT buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=730563

Propagate the DISCONT flag to the first RTP packet being used to transfer
a DISCONT buffer.

https://bugzilla.gnome.org/show_bug.cgi?id=730563

Pre-allocate buffer list of the right size to avoid re-allocs.
Avoid plenty of double runtime cast checks and re-doing the
same calculation over and over again in rtp_vp8_calc_payload_len().
Only call gst_buffer_get_size() once.

To avoid re-allocs.

To avoid unnecessary re-allocs.