qtdemux only added the whole stsd atom as 'codec_data'
in its output caps for SVQ3. This patch makes it add
the SEQH (inside a SMI atom) and a gamma field (taken
from the gama atom) if available.
Fixes#587922
* gst/qtdemux/qtdemux_fourcc.h: Add new fourccs for use by the mj2
unpacker.
* gst/qtdemux/qtdemux.c (qtdemux_parse_trak): Unpack JPEG2000 component
mapping and channel definitions from the jp2h header. Will add
component-map and channel-definitions elements to the caps if the
component maps or channel definitions are nonstandard, where standard
order means RGB, 444 packed YUV, or greyscale, with no alpha channel.
Fixes#598915.
No need to maintain our own genre table in qtdemux. The genres are
identical to the ID3 genres, so we can just use libgsttag's
gst_tag_id3_genre_get() to look them up.
For calculating the durations of each sample, we are supposed to add each
duration modulo 1<<32 so make the elapsed time counter a uint32.
Fixes#595942
If it looks like we would be allocating a silly size for our sample
index, just bail out instead of trying to allocate it. Helps with
broken or fuzzed files where we might end up trying to malloc a
couple of hundred MBs otherwise.
Make sure we don't read beyond the atom boundary. Note that the code
behaves slightly differently in the corner case where there is not
enough atom data for the specified number of samples (n_samples_time)
in the atom, but still enough data to fill the pre-allocated index of
n_samples entries: before we would just stop parsing the stts data
and continue, whereas now we will likely error out. This should not
be a problem in practice though. We could maintain the old behaviour
by doing reads with a size check inside the loop if needed.
Use GstByteReader to parse stsz and stsc chunks, and check size of
available data before parsing it, instead of blindly assuming there
will be enough data. Fixes crashes with some fuzzed/broken files.
3GPP specs define a number of tags along with precise layout. While these
are normally expected to be found in a container whose major brand is a
3GPP brand, this may also happen when a 3GPP brand is only mentioned as a
compatible brand. Apply some checks, heuristic and fallbacks to extract
such tags as well.
Once buffering has started (with an mdat atom), continue buffering
until moov atom is reached, which handles cases with multiple
mdat atoms. Also keep adapter/offset better in sync with upstream
and fix some debug statements. Fixes#587426.
This reverts commit 5503a59a57.
Reverting this since it causes regressions with a lot of sample files
I have, all of which worked fine with the last -good release (#586891).
Whenever we alloc something based on a user-supplied size, we should
really use g_try_new(), otherwise we can easily be made to abort by
passing a ridiculously large number to us for allocing. Fixes
problems with some fuzzed files.
Check the possibly 64-bit atom size more carefully before casting it
to an int and passing it to gst_pad_pull_range(), otherwise we might
end up pulling 0 bytes, getting an empty buffer as requested and
dereferencing not available data whilst thinking we actually asked
for and got 0x1000000000000 bytes. Similar fix for push mode operation
where neededbytes ends up being 0 bytes, which makes us assert. Fixes
crash with broken or fuzzed file (NB #122378).
When there are less timestamps that there are samples, fill up the sample table
with the last know timestamp. This situation can happen when the last sample
does not decode and doesn't need a timestamp. We however calculate the total
track length using the last sample timestamp so we need to have something
sensible in there.
Fixes#585056
in24 samples are normally big-endian but an enda box can change this to
little-endian. Recurse into the in24 box and find the enda box so that we get
the endianness right.
Fixes#582515
If the codec is actually something else (e.g. mjpeg) change the caps to
match when parsing the ESDS atom.
Also, for AAC, override rate and channels with correct values read from
ESDS, since the rate/channels values elsewhere are often wrong.
Some clips (trailers) may have (length-wise) unbalanced streams,
which stalls the pipeline if seeking into that region.
Additional stream synchronization can handle this, as well as
sparse (subtitle) streams (at some later time ?)
Cater for DELTA_UNIT flag on buffers, keep track of current
position, remove and warn about edit lists if any (as those
as are de facto discarded anyway), add some debug statements
and indent fixes.
stps atoms contain "partial sync" information, which means that it's
a sync point where pts != dts. This is needed to properly handle
MPEG2, H.264, Dirac, etc., in quicktime.
