lör 2023-08-12 klockan 13:31 -0700 skrev p...@sandflow.com:
> From: Pierre-Anthony Lemieux <p...@palemieux.com>
>
> Intended to replace
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230802000135.26482-3-mich...@niedermayer.cc/
> with a more accurate block decoding magnitude bound.
>
> ---
> libavcodec/jpeg2000htdec.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> index 2c4cea5dd9..a7329206de 100644
> --- a/libavcodec/jpeg2000htdec.c
> +++ b/libavcodec/jpeg2000htdec.c
> @@ -572,6 +572,14 @@ static int
> jpeg2000_decode_ht_cleanup_segment(const Jpeg2000DecoderContext *s,
>
> const uint8_t *vlc_buf = Dcup + Pcup;
>
> + /*
> + * Bound on the recision needed to process the codeblock. The
> number of
precision
> + * decoded bit planes is equal to at most cblk->zbp + 2 since
> S_blk = P if
> + * there are no placeholder passes or HT Sets and P = cblk->zbp.
> See Rec.
> + * ITU-T T.814, 7.6.
> + */
> + int maxbp = cblk->zbp + 2;
> +
> /* convert to raster-scan */
> const uint16_t is_border_x = width % 2;
> const uint16_t is_border_y = height % 2;
> @@ -590,6 +598,12 @@ static int
> jpeg2000_decode_ht_cleanup_segment(const Jpeg2000DecoderContext *s,
> goto free;
> }
>
> + /* do we have enough precision, assuming a 32-bit decoding path
> */
> + if (maxbp >= 32) {
> + return AVERROR_INVALIDDATA;
> + goto free;
> + }
Why not move this check to just after maxbp is declared? That way a
bunch of allocations are avoided
The rest of the patch looks fine, though I haven't studied the HT spec
deeply. The +2 on maxbp is familiar.
/Tomas
_______________________________________________
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".
