commit cd62f9d557 missing the comment about build
Reviewed-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Need to check malloc fail before using it, so adjust the location
in the code.
Reviewed-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Script to download and test ossfuzz testcases
This also includes a list of such testcases.
I intend to subsequently fill this list with the cases we have fixed in the past
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
when the last offsets in the stco atom are close to 4GB, the addition of
the moov atom size can overflow, causing corruption near the end of the
mp4 file.
this patch upgrades all stco atoms to co64 when such an edge case is
detected. in order to accomplish this, the implementation was changed to
walk the atom tree, instead of searching for the strings 'stco'/'co64'.
this was required since when an stco atom is changed to co64, its size
changes, and the sizes of all containing atoms (moov, trak, etc.) have
to be updated as well.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1. validate the moov size before checking for cmov atom
2. avoid performing arithmetic operations on unvalidated numbers
3. verify the stco/co64 offset count does not overflow the stco/co64
atom (not only the moov atom)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The last workaround is not sufficient to make oss fuzz work with the iterate API
as it did not provide a FFmpeg that external libs can be linked to.
This patch does not fully restore the pre iterate functionality. My attempts to
do this have so far failed.
The problem with this solution is that it renders the fuzzers virtual system
ffmpeg (libs) non functional. Which differs from a real system compared to the
virtual system tested by the fuzzer.
It should theoretically not matter as the system ffmpeg wouldnt be used.
But with more cases being fuzzed we likely will hit a case where a external
lib is involved and it does matter ...
Working around this may be possible with weak symbols but so far my attempts
failed
Alternatively multiple ffmpeg could be built, this becomes messy though
quickly as they need to be all linked together. That is we need a FFmpeg
that has the iterate API modified so it can work with the resources
available to ossfuzz. And at the same time we need a ffmpeg that has
its full functionality for any external libs which use ffmpeg and are
used by ffmpeg.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A few days ago ossfuzz stoped testing new FFmpeg as it run out of diskspacee
https://oss-fuzz-build-logs.storage.googleapis.com/index.html
An alternative would be to revert the API.
This changes for example
-rwxr-x--- 1 michael michael 144803654 May 14 12:54 tools/target_dec_ac3_fixed_fuzzer*
to
-rwxr-x--- 1 michael michael 30333852 May 14 12:51 tools/target_dec_ac3_fixed_fuzzer*
Which should massively decrease space requirements
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avdevice_register_all() is still required to register devices into
lavf (this is required due to lavd being somewhat of a hack).
Signed-off-by: Josh de Kock <josh@itanimul.li>
The toolchain for this target is unmaintained since many years.
While it has been continuously build tested on fate, it hasn't
actually been tested at runtime since many, many years (and back
then, only a few codecs in libavcodec were tested).
So far, keeping support for it has been mostly effortless, but
the compiler does seem to have issues with dllimported data symbols,
ending up as internal compiler errors in some cases. Instead of
jumping through further hoops to work around that, just remove the
target.
Signed-off-by: Martin Storsjö <martin@martin.st>
