Each FLAC metadata block starts with a flag denoting whether it is the
last metadata block. The existing flacparse code moves any existing
VORBISCOMMENT block to immediately follow the STREAMINFO block without
changing any block's last-metadata-block flag. If no VORBISCOMMENT block
exists, it created one with the last-metadata-block flag set to true.
This results in gstflacdec sometimes giving bad headers to libflac when
trying to play perfectly valid FLAC files depending on the file's
metadata ordering. Depending on the contents of the other metadata
blocks, current versions of libflac may or may not return
FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER when given this broken
metadata. This is most noticeable with files that have a large cover art
image attached where VORBISCOMMENT is the very last metadata block with
no PADDING afterwards.
This patch changes that behavior so that:
1. For FLAC files that already have a VORBISCOMMENT block, the metadata
order is preserved.
2. For FLAC files that do not have a VORBISCOMMENT block, the generated
dummy VORBISCOMMENT is placed immediately after STREAMINFO and
inherits the last-metadata-block flag from STREAMINFO.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/484
After a CAPS event, in theory a new stream can start and it might start
with the FLAC headers again. We can't detect FLAC headers in the middle
of the stream, so we drain the parser to be able to detect either FLAC
headers after the CAPS event or the continuation of the previous stream.
This fixes for example
gst-launch-1.0 audiotestsrc num-buffers=200 ! flacenc ! c. \
audiotestsrc num-buffers=200 freq=880 ! flacenc ! c. \
concat name=c ! rtpgstpay ! udpsink host=127.0.0.1 port=5000
gst-launch-1.0 udpsrc multicast-group=127.0.0.1 port=5000 \
caps=application/x-rtp,media=application,clock-rate=90000,encoding-name=X-GST ! \
rtpgstdepay ! flacparse ! flacdec ! audioconvert ! pulsesin
Otherwise baseparse will incrementally send us bigger buffers until the
full header size is reached, which is not only pointless but also means
that baseparse will reallocate and copy into a bigger buffer for every
input buffers. In pull mode that's done in 64kb increments, in push mode
usually in much smaller increments, causing a lot of overhead for
example when parsing high-quality coverart.
This breaks gst-validate on the build server (though not locally),
and a unit test, and I can't run unit tests right now for some
unrelated reason.
This reverts commit 0747b56f8e.
This reverts commit 4065fcb80a.
flacparse should not push tags by itself, the base class is going to do that
while properly merging in upstream tags. It just didn't because of a bug in
the base class, which was hidden by this commit.
https://bugzilla.gnome.org/show_bug.cgi?id=763553
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
flac contains the sample offset in the frame header, so after a seek
without index flacparse will know the exact position we landed on and
timestamp buffers accordingly. It only set the pts though, which means
the baseparse-set dts which was set to the seek position prevails, and
since the seek was based on an estimate, there's likely a discrepancy
between where we wanted to land and where we did land, so from here on
that dts/pts difference will be maintained, with dts possibly multiple
seconds ahead of pts, which is just wrong. The easiest way to fix this
is to just set both pts and dts based on the sample offset, but perhaps
parsed audio should just not have dts set at all.
https://bugzilla.gnome.org/show_bug.cgi?id=752106
The parser can accept input that is not completely specified. Use the
ACCEPT_INTERSECT flag on the sinkpad to tweak the acceptcaps function to
check for intersection only. This allows us to proxy downstream
constraints while still allowing non-subset caps as input.
We can then also remove the appended template caps workaround.
Make a unit-test to check the new feature.
This reverts commit 26040ee38c
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=705024
