- 31 Dec, 2019 5 commits
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Zhao Zhili authored
The option is deprecated and ignored by buffersrc.
-
Michael Niedermayer authored
These are checked for early in avcodec_open2() and do not really test the decoder but instead waste resources which could be better spend fuzzing the actual decoder Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Zhao Zhili authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Zhao Zhili authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 30 Dec, 2019 4 commits
-
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
Marton Balint authored
Since 648b8cca and c991e9cd timestamps were not set properly. Signed-off-by: Marton Balint <cus@passwd.hu>
-
Paul B Mahol authored
-
Zhao Zhili authored
-
- 29 Dec, 2019 13 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Zhong Li authored
Signed-off-by: Zhong Li <zhongli_dev@126.com>
-
Zhong Li authored
Signed-off-by: Zhong Li <zhongli_dev@126.com>
-
Zhong Li authored
Signed-off-by: Zhong Li <zhongli_dev@126.com>
-
Andreas Rheinhardt authored
When a Matroska Block is only stored in compressed form, the size of the uncompressed block is not explicitly coded and therefore not known before decompressing it. Therefore the demuxer uses a guess for the uncompressed size: The first guess is three times the compressed size and if this is not enough, it is repeatedly incremented by a factor of three. But when this happens with lzo, the decompression is neither resumed nor started again. Instead when av_lzo1x_decode indicates that x bytes of input data could not be decoded, because the output buffer is already full, the first (not the last) x bytes of the input buffer are resent for decoding in the next try; they overwrite already decoded data. This commit fixes this by instead restarting the decompression anew, just with a bigger buffer. This seems to be a regression since 935ec5a1. A FATE-test for this has been added. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
Andreas Rheinhardt authored
This test tests that demuxing ProRes that is muxed like it should be in Matroska (i.e. with the first header ("icpf") atom stripped away) works; it also tests bz2 decompression as well as the handling of unknown-length clusters. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
James Almer authored
Fixes fate-source Signed-off-by: James Almer <jamrial@gmail.com>
-
- 28 Dec, 2019 16 commits
-
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Carl Eugen Hoyos authored
Fixes ticket #8447.
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Michael Niedermayer authored
This allows integrating box blur style filters in geq. Without this computing the mean of an area in geq would have been excessivly slow Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Reviewed-by: "mypopy@gmail.com" <mypopy@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: memleaks Fixes: 19471/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1IMAGE_fuzzer-5688035714269184 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
All authors who have code in this under GPL agreed. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: out of array read Fixes: 19327/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ATRAC9_fuzzer-5679823087468544 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Lynne <dev@lynne.ee> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: out of array read Fixes: 19331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5644115983466496 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: division by 0 Fixes: 19123/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMAV2_fuzzer-5655493121146880 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
video is allocated before parameters like bpp are read. Fixes: out of array access Fixes: 19084/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5718556033679360 Fixes: 19465/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IFF_ILBM_fuzzer-5759908398235648 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 27 Dec, 2019 2 commits
-
-
Andriy Gelman authored
Fixes #8079 During initialization of a v4l2m2m device, the configured pix_fmt can be different to the pix_fmt of the encoder (i.e. avctx->pix_fmt). For example on the Odroid XU4: ./ffmpeg -f lavfi -i yuvtestsrc -codec:v h264_v4l2m2m out.h264 will configure the v4l2 encoder to pix_fmt nv21, whereas the input frames will be yuv444p. This commit checks that the configured v4l2 pix_fmt on device is the same as avctx->pix_fmt. If they are different the initialization fails and an error is returned. Tested on RPI4 and Odroid XU4. Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-