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. 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 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
signature.asc
Description: PGP signature
_______________________________________________ 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".
