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
Tell GstBaseParse the duration in samples instead of time, so that
a duration query in DEFAULT format will return the correct number
of samples without rounding errors. Baseparse will convert this
into time itself when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=650785
Also add a format flag to signal baseparse that subclass/format can provide
(parsed) timestamp rather than an estimated one. In particular, such "strong"
timestamp then allows to e.g. determine duration.
Thanks to Felipe Contreras for the suggestion. This is partially
based on his patches and makes flacparse more than 3.5 times faster.
Looking for valid frame headers is unlikely to give false positives
because every frame header is at least 9 bytes long, contains a
14 bit sync code and a 8 bit checksum over the first 8 bytes.
Fixes bug #631200.
The first newsegment event will be send by the first call to
gst_base_parse_push_buffer() if necessary, posting the tags
before that is not a good idea. Instead do it from the
GstBaseParse::pre_push_buffer vfunc.
This is optional because it's a quite expensive operation and it's very
unlikely that a non-frame is detected as frame after the header CRC check
and checking all bits for valid values. The overall frame checksums are
mainly useful to detect inconsistencies in the encoded payload.
When called from the GST_FLAC_PARSE_STATE_HEADERS case,
gst_flac_parse_hand_headers() does a gst_buffer_set_caps() on a buffer
with refcount > 1. This change handles this case by making the buffer
metadata_Writable.
https://bugzilla.gnome.org/show_bug.cgi?id=614037
