currently, the layer number is at the beginning of the .model file,
so we have to scan twice in python script, the first scan to get the
layer number. Only one scan needed after put the layer number at the
end of .model file.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
wavelets allow significant size expansion and they are also not
very fast.
Fixes: Timeout
Fixes: 16480/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5659892689403904 (108sec -> 17ms)
Fixes: 16480/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5749422717140992 (big ->15sec)
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
conv2d with dilation > 1 generates tens of nodes in graph, it is not
easy to parse each node one by one, so we do special tricks to parse
the conv2d layer.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
Fixes: Timeout (12sec ->2sec)
Fixes: 16125/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSRLE_fuzzer-5650846364205056
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should reduces the number of uninteresting timeouts encountered
A single threshold for all codecs did not work
Fixes: 13979/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-5629872380051456 (14sec -> 4sec)
Fixes: 14709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5704215281795072 (179sec -> 7sec)
Fixes: 16296/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HNM4_VIDEO_fuzzer-5756304521428992 (108sec -> 9sec)
Fixes: 15620/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GIF_fuzzer-5657214435459072 (26sec -> 26ms)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch avoids a read past the end of the input buffer in memcpy since the size
of the received zmq message is recv_buf_size - 1.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
since tf.pad is enabled, the conv2d(valid) changes back to its original behavior.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
Fixes: memleak
Fixes: part of 15529/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVPX_VP8_fuzzer-5140143700180992
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For example, given TensorFlow model file espcn.pb,
to generate native model file espcn.model, just run:
python convert.py espcn.pb
In current implementation, the native model file is generated for
specific dnn network with hard-code python scripts maintained out of ffmpeg.
For example, srcnn network used by vf_sr is generated with
https://github.com/HighVoltageRocknRoll/sr/blob/master/generate_header_and_model.py#L85
In this patch, the script is designed as a general solution which
converts general TensorFlow model .pb file into .model file. The script
now has some tricky to be compatible with current implemention, will
be refined step by step.
The script is also added into ffmpeg source tree. It is expected there
will be many more patches and community needs the ownership of it.
Another technical direction is to do the conversion in c/c++ code within
ffmpeg source tree. While .pb file is organized with protocol buffers,
it is not easy to do such work with tiny c/c++ code, see more discussion
at http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244496.html. So,
choose the python script.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
This should reduce the amount of timeout issues overall
Fixes: Timeout (34->10sec)
Fixes: 14682/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV2_fuzzer-5728608414334976
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
This allows fuzzing decoders with the same codec_id
We also avoid register all to allow the linker to prune unused sections and symbols
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The header is not always available in the docker build environment
Suggested-by: Kostya Serebryany
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '3e105d08848162b90d886bde59c010d4b0362a4b':
build: Move entries related to building TOOLS to a subdirectory Makefile
Merged-by: James Almer <jamrial@gmail.com>
* commit '233d50b275dd7cf6cc0656851e670e1b2dfba56f':
qt-faststart: Do not try to use fancy 64-bit seeking functions on mingw32ce
Merged-by: James Almer <jamrial@gmail.com>
Name and purpose are more appropriate there since the code isn't
an ideal example.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. The stagefright "API" is not public, and the
MediaCodec API is the proper way to do this.
Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.
[1] http://stackoverflow.com/a/29362353/3115956
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '30a041887f89cd97c372ad6a516da6e012f2c88b':
ismindex: Calculate the pts duration of trun atoms, not the dts duration
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Since the duration is compared to the tfra durations/intervals which
are expressed in pts, calculate that here as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
The comments/header of the file are taken from qemu, they provide some
basic documentation
The code from the examples
Ive no means to test this except uploading to coverity for FFmpeg, so each
commit should stay simple, making it easy to revert.
Also please help making this a useful and effective file by contributing
changes/code to it and reviewing contributions.
I am happy to upload changes but i cannot really maintain this (alone) as
i cannot test changes.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Supraja Meedinti <supraja0493@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '470c9db11ff2c3249e995e7ba68e87bb81bf778c':
sidxindex: Remove parsing that isn't necessary any longer
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5cf6bda6e2eae496e8eb2bb06c96852d59a58b8a':
sidxindex: Don't adjust the Period start time depending on the track start time
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When we don't adjust the Period start time, we don't need to
parse the earliest_presentation_time from the sidx boxes either.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was only necessary to get playback to start with dash.js 1.2.0,
it has been fixed in the git version.
The previous behaviour was incorrect - the Period's start time
is irrespective of the actual first timestamp of the contents
within the period. The Period start time only says when, within the
global timeline, this particular piece should start to be played
back.
Signed-off-by: Martin Storsjö <martin@martin.st>
