Scan a bit into the data when checking for dts frames instead
of expecting the frame sync to be right at the start of the
data. This is needed for some dts-disguised-as-pcm-in-wav files.
See #413942.
Make jpeg typefinder check more than just the first two bytes
plus Exif or JFIF marker. This allows us to report MAXIMUM
probability in cases where there's no Exif or JFIF marker,
making typefinding stop early. Also extract width and height,
because we can.
Fix typo that made the AC-3 typefinder not actually check for a
second frame, but rather compare the sync point found to itself,
which resulted in the AC-3 typefinder reporting an overly optimistic
MAXIMUM or VERY_LIKELY probability when it found a possible frame
sync.
This adds code to calculate the level for a given AAC stream and export
it in the stream caps. For AAC LC streams, the level is calculated
according to the definition under the AAC Profile. For other streams,
the definition under the Main Profile is used.
HE-AAC support is still to be done, and is dependent on detecting the
presence of SBR and PS in the stream.
Level is added as a field of type string because that's the way it's
done in H.264 caps as well. There are only a few possible levels, so
not using a numerical type is not too painful in this case, and
consistency is nice.
Fixes#613589.
This looks at the AAC profile for ADTS streams and adds the profile as a
string in the corresponding caps.
Profile is the actual profile, base-profile denotes the minimum codec
requirements to decode this stream. In this case they're always the
same, but they may differ e.g. in case of certain HE-AAC streams that
can be partially decoded by LC decoders (with loss of quality of course)
if no suitable HE-AAC decoder is available.
Fixes#612312.
Make AC-3 typefinder use the DataScanCtx stuff so we don't have to
do gst_type_find_peek() in the inner loop all the time. Also return
when we've suggested AC3 caps, instead of continuing with the loop.
Add PNM typefinder, so we can remove the one that's in the PNM plugin
in -bad (which btw uses different/wrong media types that don't match
the ones used by gdkpixbufdec) and people don't make fun of us for
loading image decoders when typefinding and playing back audio files.
* memcmp is expensive and was being abused, reduce calling it by checking
the first byte.
* iterating one byte at at time over 64 kbites introduces a certain overhead,
therefore we now do it in chunks of 1024 bytes
And I do mean over 300 times. The average instruction call per mxf_type_find
was previously 785685 and it's now down to 2458 :)
Disable headerless flac typefinder as long as it happily typefinds anything
including /dev/urandom as flac and as long as it's not particularly useful
given that such streams don't really exist in the wild.
Also fix up some comments so that gtk-doc doesn't complain about them.
This is a standard Midi file format that should be supported by
all Midi decoders and also has the mimetype audio/mid according to
the Midi specification homepage.
Fixes bug #594094.
Its purposes is mainly to avoid false positives (e.g. mp3 typefinder
reporting a 20% probability and somesuch). Won't be registered if
the gio plugin has been disabled via ./configure --disable-gio.
There are flac-in-ogg files without the usual flac packet framing
and these files just have a 4-byte fLaC ID packet as first packet.
We need to recognise the type just from these four bytes if we
want oggdemux to recognise these streams correctly.
Differentiate subtitle streams and lyrics/cracktastic/complex streams via
the category string in the headers. This seems like a useful distinction
to make, and also seems more future-proof. See #525743.
mp3_type_find could suggest already when only a single valid header
was found, if it ran out of data before the end of the next frame.
Therefore, ignore the last found frame if it was incomplete.
Fixes bug #579692.
The flac frame header typefinder overstates the likelihood of a match, leading
to false positives with e.g. aac streams and PDF files. Reduce probabilty
returned from LIKELY to POSSIBLE for the frame header matchin code.
Fixes#574939.
Detect more variations and also bail out in more cases where the values
don't make sense. Furthermore, add width/height and bpp to the caps,
because we can.
Use scan context for initial peek as well. Peek 6 bytes in the initial
peek rather than 5 bytes, to match the length of the memcmp we're doing
on that data later. Return immediately when we found caps from looking
at the beginning of the data - no point in continuing to scan the next
64kB for something matching a frame header.
