Yes, I was tracking another bug and the small test file I generated
to test with improbably just happened to trigger this, with a second
and last frame of 1615 bytes.
https://bugzilla.gnome.org/show_bug.cgi?id=656649
This will ensure a logically new buffer does not keep flags from
a previous use of that buffer (eg, DISCONT would be set on the first
buffer, and mistakenly kept when reused).
https://bugzilla.gnome.org/show_bug.cgi?id=653709
Some drivers are buggy are will change the current format when
processing VIDIOC_TRY_FMT. Save and restore the current format
to ensure the format is kept unchanged.
https://bugzilla.gnome.org/show_bug.cgi?id=649067
Use the fraction compare utility to compare function, not the
handcrafted one. The handcrafted one is buggy as it doesn't take into
account rounding error. For example comparing a framerate of 20/1 on a
camera configured as 30/1 fps would yield true: 1 == (1 * 20)/30 and not
re-configure the camera. Fixes#656104
This adds support for various compressed formats (AC3, E-AC3, DTS and
MP3) payloaded in IEC 61937 format (used for transmission over S/PDIF,
HDMI and Bluetooth).
The acceptcaps() function allows bins to probe for what formats the sink
being connected to support. This only works after the element is set to
at least READY.
If the underlying sink changes and the format we are streaming is not
available, we emit a message that will allow upstream elements/bins to
block and renegotiate a new format.
This exposes the source output index of the record stream that we open
so that clients can use this with the introspection if they want (to
move the stream, for example).
We need to keep the lock held because we don't want a push before the "new-ssrc-pad"
handler has completed. But we may want to push an event from inside that handler, hence
the recursive mutex.
https://bugzilla.gnome.org/show_bug.cgi?id=650916
Some h264 payloaders are unfortunately buggy and don't correctly set the
E bit in FU-A NAL when they have ended. Work around this by assuming
such a fragmentation unit has ended when there was no packet loss and a
new NAL is started
When pushing out buffers over S/PDIF or HDMI, IEC 61937 payloading
requires each buffer to contain 6 blocks from each substream. This adds
code to collect all the frames needed to meet this requirement before
pushing out a buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=650313
Using the current RTCP interval to timeout SSRC collision can lead to
collisions being timed out immediately if a BYE packet is sent because
it is sent immediately, so the interval is 0. This is not what we
want. So just set a static 10 times the default RTCP interval, it
should be enough
https://bugzilla.gnome.org/show_bug.cgi?id=648642
... which is particularly needed when merging NAL units, where not resetting
would lead to output of an older (pre-flush) AU (with unintended timestamp).
Current matroska demux calculates the pixel aspect ratio only if both
DisplayHeight and DisplayWidth are set, but it is legal to use only
one variable if the other is equal to PixelWidth or PixelHeight, at
least the mkclean utility is doing that. So this makse mkcleaned
files play correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=654744
A missing sys/param.h include results in:
/usr/include/sys/proc.h:64: error: 'MAXLOGNAME' undeclared here (not in a
function)
/usr/include/sys/proc.h:285: error: 'MAXCOMLEN' undeclared here (not in a
function)
when compiling goom on openbsd/ppc. We can just remove the two sys/ includes
here, they are not needed for anything.
https://bugzilla.gnome.org/show_bug.cgi?id=654749
... introduced when shuffling around code for the async implementation
by setting state of source (and udp sources) in _play before downstream
flushing is undone.
The gst_base_parse_set_frame_rate call was predicated on a change to
sample rate, duration or profile. However, the block count per frame can
also change between packets, which would result in incorrect buffer
durations.
