"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
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
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.
Collect buffers to send out in buffer lists instead of
pushing out single buffers one at a time. For HD video
each frame might easily add up to a couple of thousand
packets, multiply that by the frame rate and that's a
lot of push() and sendmsg() calls per second.
A good reason to push out buffers as early as possible is
latency, so we don't accumulate the whole frame in a single
buffer list, but instead push it out in a few chunks, which
is hopefully a reasonable compromise.
Make sure that if AYUV is received it will detect that it can produce
both RGB and YUV formats
Signed-off-by: Ravi Kiran K N <ravi.kiran@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=725248
Probe supported formats in order of desirability rather than in
what order they may happen to be in the formats bitmask. Fixes
accidentally exposure of 8-bit formats in caps before 16-bit formats
(in case where U16 was not supported S8 might be listed before S16).
https://bugzilla.gnome.org/show_bug.cgi?id=706884
The code would previously crash trying to insert a NULL string
into a hash table.
It does seem a little broken that indexing is done by MIME type
and not by index though, unless the spec says there cannot be
two parts with the same MIME type.
https://bugzilla.gnome.org/show_bug.cgi?id=659573
