Message ID | CAKkUsvyDpQ-=ktUcq2d1-4X6ieqh6KZhG1GBznitKdap8c11FA@mail.gmail.com |
---|---|
State | New |
Headers | show |
On Fri, Sep 06, 2019 at 01:11:50PM +0200, Pascal Massimino wrote: > Michael, > > On Thu, Sep 5, 2019 at 6:20 PM Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > On Wed, Sep 04, 2019 at 07:43:15AM +0200, Pascal Massimino wrote: [...] > > > > i would guess its not a known chunk but rather hits the default > > is that just a bunch of 0 or 0xFF bytes ? > > detecting before we read into the end feels more robust if > > we can simply detect the "junk" > > > > As i mentioned in the description, a possibly more robust solution would be > just stopping the loop as soon as 'chunk_size' bytes have been consumed > (leading to *got_frame = 1) and no more. This current patch is minimalist, > though. well, which solution do you prefer ? thx [...]
Michael, On Fri, Sep 6, 2019 at 6:21 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > On Fri, Sep 06, 2019 at 01:11:50PM +0200, Pascal Massimino wrote: > > Michael, > > > > On Thu, Sep 5, 2019 at 6:20 PM Michael Niedermayer > <michael@niedermayer.cc> > > wrote: > > > > > On Wed, Sep 04, 2019 at 07:43:15AM +0200, Pascal Massimino wrote: > [...] > > > > > > > i would guess its not a known chunk but rather hits the default > > > is that just a bunch of 0 or 0xFF bytes ? > > > detecting before we read into the end feels more robust if > > > we can simply detect the "junk" > > > > > > > As i mentioned in the description, a possibly more robust solution would > be > > just stopping the loop as soon as 'chunk_size' bytes have been consumed > > (leading to *got_frame = 1) and no more. This current patch is > minimalist, > > though. > > well, which solution do you prefer ? > the one in the patch is fine. skal/ > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Mon, Sep 09, 2019 at 11:13:53AM +0200, Pascal Massimino wrote: > Michael, > > On Fri, Sep 6, 2019 at 6:21 PM Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > On Fri, Sep 06, 2019 at 01:11:50PM +0200, Pascal Massimino wrote: > > > Michael, > > > > > > On Thu, Sep 5, 2019 at 6:20 PM Michael Niedermayer > > <michael@niedermayer.cc> > > > wrote: > > > > > > > On Wed, Sep 04, 2019 at 07:43:15AM +0200, Pascal Massimino wrote: > > [...] > > > > > > > > > > i would guess its not a known chunk but rather hits the default > > > > is that just a bunch of 0 or 0xFF bytes ? > > > > detecting before we read into the end feels more robust if > > > > we can simply detect the "junk" > > > > > > > > > > As i mentioned in the description, a possibly more robust solution would > > be > > > just stopping the loop as soon as 'chunk_size' bytes have been consumed > > > (leading to *got_frame = 1) and no more. This current patch is > > minimalist, > > > though. > > > > well, which solution do you prefer ? > > > > the one in the patch is fine. ok, will apply thx [...]
On Tue, Sep 10, 2019 at 5:12 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > On Mon, Sep 09, 2019 at 11:13:53AM +0200, Pascal Massimino wrote: > > Michael, > > > > On Fri, Sep 6, 2019 at 6:21 PM Michael Niedermayer > <michael@niedermayer.cc> > > wrote: > > > > > On Fri, Sep 06, 2019 at 01:11:50PM +0200, Pascal Massimino wrote: > > > > Michael, > > > > > > > > On Thu, Sep 5, 2019 at 6:20 PM Michael Niedermayer > > > <michael@niedermayer.cc> > > > > wrote: > > > > > > > > > On Wed, Sep 04, 2019 at 07:43:15AM +0200, Pascal Massimino wrote: > > > [...] > > > > > > > > > > > > > i would guess its not a known chunk but rather hits the default > > > > > is that just a bunch of 0 or 0xFF bytes ? > > > > > detecting before we read into the end feels more robust if > > > > > we can simply detect the "junk" > > > > > > > > > > > > > As i mentioned in the description, a possibly more robust solution > would > > > be > > > > just stopping the loop as soon as 'chunk_size' bytes have been > consumed > > > > (leading to *got_frame = 1) and no more. This current patch is > > > minimalist, > > > > though. > > > > > > well, which solution do you prefer ? > > > > > > > the one in the patch is fine. > > ok, will apply > thx > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If you drop bombs on a foreign country and kill a hundred thousand > innocent people, expect your government to call the consequence > "unprovoked inhuman terrorist attacks" and use it to justify dropping > more bombs and killing more people. The technology changed, the idea is > old. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
From 5c3a8878cce7e2920c39e58a0b57872d8c96b511 Mon Sep 17 00:00:00 2001 From: Pascal Massimino <pascal.massimino@gmail.com> Date: Wed, 28 Aug 2019 09:41:42 +0200 Subject: [PATCH] avcodec/webp: fix decoding for trailing junk some bitstream have trailing junk, despite being valid webp data. In case of apparent error, abort the loop and let *got_frame decide whether this is an error or not. fixes trac #8107 (/#7612) Another possibility would be turning the loop into: while (!*got_frame) {...} --- libavcodec/webp.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 077bb06f85..c6d0206846 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -1412,8 +1412,11 @@ static int webp_decode_frame(AVCodecContext *avctx, void *data, int *got_frame, return AVERROR_INVALIDDATA; chunk_size += chunk_size & 1; - if (bytestream2_get_bytes_left(&gb) < chunk_size) - return AVERROR_INVALIDDATA; + if (bytestream2_get_bytes_left(&gb) < chunk_size) { + /* we seem to be running out of data, but it could also be that the + bitstream has trailing junk leading to bogus chunk_size. */ + break; + } switch (chunk_type) { case MKTAG('V', 'P', '8', ' '): -- 2.23.0.187.g17f5b7556c-goog