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
