For someone that read the spec is clear the only *invalid*
data block type is 127. For the rest, its useful information.
Additionally. values 7-126 are currently reserved by the
spec so the situation might change in the future.
We are only interested on the first bit of the first
byte of the metadata block header to figure out whether
is marked as the last one. The shift makes it quite
clearer.
If we get anything from 7 to 126 as type when parsing
a metadata block header, we are likely dealing with a
FLAC stream version we don't fully understand. Issue
a warning if so.
Document function assumptions regarding the passed-on
type while at this.
As CRCs are calculated for the comparition already, we
might as well (cheaply) inform the user how the numbers
differ if a missmatched pair is found.
While at it:
Rephrase candidate-frame message to make more sense
Prevents downstream from receiving flushes for a seek only in
upstream. Those seeks are only to start reading from the right
offset when skipping or returning to qt atoms.
https://bugzilla.gnome.org/show_bug.cgi?id=758928
Avoid writing a negative number as a large positive
integer in an edit list when the first_ts is smaller
than the first_dts - which can happen when the first
packet received has a PTS but no DTS.
https://bugzilla.gnome.org/show_bug.cgi?id=759615
Don't increment running time from every buffer. The correct
logic to only increment when running time advances is a
little further down, so delete this left-over line.
Leverage response from gst_rtsp_connection_connect_with_response to
determine if the connection should be retried using authentication. If
so, add the appropriate authentication headers based upon the response
and retry the connection.
https://bugzilla.gnome.org/show_bug.cgi?id=749596
The string could exist but with a wrong format, in that case we still want
to reset the values of client_port_range.min and max like we do if there is
no string.
CID 1139593
We would queue 5 consective packets before considering a reset and a proper
discont here. Instead of expecting the next output packet to have the current
seqnum (i.e. the fifth), expect it to have the first seqnum. Otherwise we're
going to drop all queued up packets.
When working in push-mode, we attempt to push out everything currently
buffered in the adapter.
This has two pitfalls:
* We could stop earlier (the moment we get a non-ok or non-not-linked)
* We return the last combined flow return, which might be completely
different from the previous combined flow return
There might be multiple LOAS config in a row in a full frame. The first
one might be a multi-layer config (which we can't properly parse yet)...
but then followed by a valid (single-layer) one.
The code was previously skipping whole frames (instead of just the LOAS
config we failed to read) resulting in multiple frames (seen up to 6s in
some situation) being dropped before finally getting the configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758826
auds.blockalign is set once the first caps arrive. If
gst_avi_mux_stop_file() is called before this happens then auds.blockalign
is zero and gst_avi_mux_audsink_set_fields() cause a crash:
[...]
avipad->parent.hdr.rate = avipad->auds.av_bps / avipad->auds.blockalign;
[...]
https://bugzilla.gnome.org/show_bug.cgi?id=758912
It's not enough to have timeout or event based SPS/PPS information sent
in RTP packets. There are some scenarios when key frames may appear
more frequently than once a second, in which case the minimum timeout
for "config-interval" of 1 second for sending SPS/PPS is not sufficient.
It might also be desirable in general to make sure the SPS/PPS is
available with every keyframe (packet loss aside), so receivers can
actually pick up decoding immediately from the first keyframe if
SPS/PPS is not signaled out of band.
This patch adds the possibility to send SPS/PPS with every key frame. This
mode can be enabled by setting "config-interval" property to -1. In this
case the payloader will add SPS and PPS before every key (IDR) frame.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
