On 05-07-2019 10:15 AM, Gyan wrote:
On 05-07-2019 07:32 AM, greg Luce wrote:
If the joined version is preferred it's been submitted at
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245662.html
Pinging. Would it be possible to get one of these two versions
applied, if no other changes
If hw_frames_ctx exists when calling ff_decode_get_hw_frames_ctx, it
is allowed to be recreated instead of just return.
Move hw_frames_ctx check outside ff_decode_get_hw_frames_ctx, and check
in relevant code.
Signed-off-by: Linjie Fu
---
libavcodec/decode.c | 2 +-
libavcodec/dxva2.c | 8
VP9 allows resolution changes per frame. Currently in VAAPI, resolution
changes leads to va context destroy and reinit. This will cause
reference frame surface lost and produce garbage.
As libva allows re-create surface separately without changing the
context, this issue could be handled by only
lör 2019-07-06 klockan 18:34 +0200 skrev Michael Niedermayer:
> On Sat, Jul 06, 2019 at 02:34:34PM +0200, Tomas Härdin wrote:
> > lör 2019-07-06 klockan 00:08 +0200 skrev Michael Niedermayer:
> > > As we are already off topic, heres an example to test static
> > > analysis, does this trigger
Am 06.07.19 um 22:10 schrieb Michael Niedermayer:
> On Sat, Jul 06, 2019 at 09:39:32PM +0200, Thilo Borgmann wrote:
>> Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
>>>
>>>
>>> On 21.06.2019, at 00:47, Michael Niedermayer wrote:
>>>
Fixes: signed integer overflow: 65313 * 65313 cannot be
On Sat, Jul 06, 2019 at 09:39:32PM +0200, Thilo Borgmann wrote:
> Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
> >
> >
> > On 21.06.2019, at 00:47, Michael Niedermayer wrote:
> >
> >> Fixes: signed integer overflow: 65313 * 65313 cannot be represented in
> >> type 'int'
> >> Fixes:
> >>
Am 21.06.19 um 09:00 schrieb Reimar Döffinger:
>
>
> On 21.06.2019, at 00:47, Michael Niedermayer wrote:
>
>> Fixes: signed integer overflow: 65313 * 65313 cannot be represented in type
>> 'int'
>> Fixes:
>> 15290/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5738074249625600
Thanks Michael,
Could you please also apply the patch [PATCH] set AVFrame
decode_error_flags in case of decoding error by h264dec
It is the code that uses those flags.
Thanks
Amir
On Sat, Jun 29, 2019 at 11:35 AM Michael Niedermayer
wrote:
> On Fri, Jun 28, 2019 at 02:21:18AM -0700, Amir
Michael hey,
Could you please apply this patch as well.
Thanks
On Fri, Jun 21, 2019 at 9:15 AM Amir Pauker wrote:
> set AVFrame decode_error_flags in case h->slice_ctx->er.error_occurred is
> set
> after the call to ff_h264_execute_decode_slices. This allows the user to
> detect
> concealed
On Wed, Jun 19, 2019 at 11:54:22PM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -346039050 * 8 cannot be represented in type
> 'int'
> Fixes:
> 15283/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5692700268953600
>
> Found-by: continuous fuzzing process
>
On Wed, Jun 19, 2019 at 11:54:21PM +0200, Michael Niedermayer wrote:
> Fixes: left shift of 72 by 26 places cannot be represented in type 'int'
> Fixes:
> 15279/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5700665621348352
>
> Found-by: continuous fuzzing process
>
On Fri, Jun 21, 2019 at 12:47:20AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 41582592 * 256 cannot be represented in type
> 'int'
> Fixes:
> 15296/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5739558227935232
>
> Found-by: continuous fuzzing process
>
On Wed, Jun 19, 2019 at 11:54:20PM +0200, Michael Niedermayer wrote:
> Fixes: left shift of negative value -6
> Fixes:
> 15275/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5742361767837696
>
> Found-by: continuous fuzzing process
>
On 7/6/2019 1:59 PM, Andreas Rheinhardt wrote:
> This commit fixes an overflow introduced in a569a7b3 that affected EBML
> elements that the Matroska demuxer doesn't want to parse like CRC-32
> elements. The return value of avio_skip (the new position on success or
> an AVERROR on failure) has
This commit fixes an overflow introduced in a569a7b3 that affected EBML
elements that the Matroska demuxer doesn't want to parse like CRC-32
elements. The return value of avio_skip (the new position on success or
an AVERROR on failure) has been assigned to an integer which meant that
new positions
On Sat, Jul 06, 2019 at 02:34:34PM +0200, Tomas Härdin wrote:
> lör 2019-07-06 klockan 00:08 +0200 skrev Michael Niedermayer:
> > As we are already off topic, heres an example to test static
> > analysis, does this trigger undefined behavior by executing the memcpy
> > for some user input ?
> >
>
Several checks (e.g. when the size of the input packet is too small)
simply used "goto fail", but didn't set the return value appropriately
for an error.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/truehd_core_bsf.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
The truehd_core bitstream filter decreases the sizes of the
major_sync_info structure (if present), of the
substream_directory and of the substreams themselves. As a consequence,
there is enough space available in front of the actual substream data
for the new header, so that one only needs to
1. The loop counter of the substream_directory loop is always less than
the number of substreams, yet within the loop it is checked whether it
is less than FFMIN(3, s->hdr.num_substreams), although the check for < 3
would suffice.
2. In case the packet is a major sync packet, the last two bytes of
Words of 16 bit are the unit for TrueHD's size and offset fields;
in particular the sizes of the high-level structures of TrueHD are
always a multiple of a byte; yet truehd_core unnecessarily used
bit offsets at several places. This has been changed.
Signed-off-by: Andreas Rheinhardt
---
If truehd_core strips Atmos data away, three parts of the output differ
in size compared to the input access unit: a) The major_sync_info block
if the extra_channel_meaning_data is present, as the newly written
output never contains said block; b) the substream_directory (because
entries relating
The most serious bit of the substream_info header field (in a mayor sync
packet) indicates whether a 16-channel presentation is present in the
bitstream. If set, the extended_substream_info header field contains
information about the 16-channel presentation. This presentation always
uses substream
lör 2019-07-06 klockan 00:08 +0200 skrev Michael Niedermayer:
> As we are already off topic, heres an example to test static
> analysis, does this trigger undefined behavior by executing the memcpy
> for some user input ?
>
> void f(unsigned bigint a) {
> bigint i;
> for (i = 2;
Signed-off-by: Michael Niedermayer
---
libavcodec/dnxhd_parser.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/dnxhd_parser.c b/libavcodec/dnxhd_parser.c
index 7c16e251a4..f657af8f41 100644
--- a/libavcodec/dnxhd_parser.c
+++ b/libavcodec/dnxhd_parser.c
@@ -81,8 +81,6 @@ static
Fixes: out of array access
Fixes:
15522/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DNXHD_fuzzer-5747756078989312
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/parser.c | 3 +++
1
Signed-off-by: Michael Niedermayer
---
libavcodec/dnxhd_parser.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/dnxhd_parser.c b/libavcodec/dnxhd_parser.c
index f657af8f41..31a3158fea 100644
--- a/libavcodec/dnxhd_parser.c
+++ b/libavcodec/dnxhd_parser.c
@@ -88,6 +88,10 @@
This allows testing parsers with a wider range of input packet sizes.
Which is important and usefull for regression testing, some of our
parsers in fact to not work if the packet size is changed from 1024
Signed-off-by: Michael Niedermayer
---
libavformat/ac3dec.c | 6 ++
Fixes: out of array access
Fixes:
15522/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DNXHD_fuzzer-5747756078989312
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/dnxhd_parser.c | 3 ++-
28 matches
Mail list logo
