The performance category is meant to be used to audit codepaths that lead to bad
performance (e.g. copies, conversion that can be avoided).
Remove the event category which is not used.
For vbr audio streams we need to use the number of blocks to calculate the
timestamps.
When the allocation of additional index memory fails, don't throw away what
we had before.
Various cleanups.
Implement scanning of the file when we can parse the index.
Some refactoring of common code.
Cleanups and comments.
Remove some reimplemented code.
Remove index massage code and put a FIXME where we should do something
equivalent later.
Remove some duplicate counters.
Be smarter when updateing the current the timestamp and offset in the stream
because we can reuse previously calculated values when simply go forward one
step.
Correctly set metadata on outgoing buffers.
Add a new function and datastructure to parse and hold the index entries on a
per stream base. Also avoid doing too much work trying to figure out the
timestamps and durations as we can trivially do that later.
Less information in the entries makes them 2 times smaller and not doing too
much work makes this code about 12 times faster than the regular case.
Hook in the new function alongside the existing function for comparison until
the rest of the code is updated to handle the new index datastructure.
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.
