On 7/23/19, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Tue, Jul 23, 2019 at 09:03:32AM +0200, Paul B Mahol wrote: >> On 7/23/19, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> > On Mon, Jul 22, 2019 at 08:20:54AM +0200, Paul B Mahol wrote: >> >> On 7/21/19, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> >> > On Sun, Jul 21, 2019 at 10:48:26AM +0200, Paul B Mahol wrote: >> >> >> On 7/21/19, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> >> >> > Fixes: Timeout (22 -> 7 sec) >> >> >> > Fixes: >> >> >> > 15173/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQX_fuzzer-5662556846292992 >> >> >> > >> >> >> > Found-by: continuous fuzzing process >> >> >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> >> >> > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> >> >> > --- >> >> >> > libavcodec/hqx.c | 4 ++++ >> >> >> > 1 file changed, 4 insertions(+) >> >> >> > >> >> >> > diff --git a/libavcodec/hqx.c b/libavcodec/hqx.c >> >> >> > index bc24ba91d1..8639d77a41 100644 >> >> >> > --- a/libavcodec/hqx.c >> >> >> > +++ b/libavcodec/hqx.c >> >> >> > @@ -471,6 +471,10 @@ static int hqx_decode_frame(AVCodecContext >> >> >> > *avctx, >> >> >> > void >> >> >> > *data, >> >> >> > avctx->height = ctx->height; >> >> >> > avctx->bits_per_raw_sample = 10; >> >> >> > >> >> >> > + if (avctx->coded_width / 16 * (avctx->coded_height / 16) * >> >> >> > + (100 - avctx->discard_damaged_percentage) / 100 > 8LL * >> >> >> > avpkt->size) >> >> >> > + return AVERROR_INVALIDDATA; >> >> >> >> >> >> Why just this change and not something better? >> >> > >> >> > What would you prefer exactly ? >> >> >> >> Something that works with pure black video. >> > >> > Can you share the failing video file ? >> > I thought theres a minimum size of 1 vlc code (2 bit seem the smallest) >> > per 16x16 block. But quite possibly i might have missed something >> > >> >> This is very disappointing. There is no freely available encoder for HQX. >> And the one who commits stuff need to make sure it does not introduce >> regressions. > > The reviewer just has to explain how the problem he speaks of can > occur.
No, its other way around. The patch author just has to explain how the problem he tries to solve is valid solution by given patch. > > If we look at decode_slice_thread() each slice reads data from a distinct > input area (this is checked to be distinct in the code). So even the > same black slice cannot reuse the same representation. > > decode_slice_thread calls decode_slice which calls decode_func > decode_func can be one of 4 implementations each reading at least > a minimum of 2 bit. so we have a minimum of 2 bits per macroblock > the calls happen at a granularity of 16x16 so theres a minimum of > 2 bits per 16x16 block. > Its very possible that i have missed some path or case in this > analysis. But we wont really move forward based on riddles. > If you know of a path/case where a frame can be encoded with > less input data just explain that case and ill adjust the > patch accordingly. Otherwise the patch is stuck as i dont > know what case you speak of For start, get a copy of HQX encoder, than we can talk more. > > PS: also there are no other return pathes in hqx_decode_frame() > all returns are error pathes so i dont see any shortcuts for > black frames which would bypass the minimum size > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Never trust a computer, one day, it may think you are the virus. -- Compn > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
