[FFmpeg-devel] [PATCH 1/2] libopenjpegdec: set max_lowres to UINT8_MAX

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sat Jul 21 12:11:30 CEST 2012


On Thu, Jul 19, 2012 at 01:29:47PM -0600, Michael Bradshaw wrote:
> On Thu, Jul 19, 2012 at 1:20 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Jul 18, 2012 at 09:51:44PM -0600, Michael Bradshaw wrote:
> >> Paul pointed out that OpenJPEG doesn't have a max lowres limit. See
> >> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-July/127906.html
> >>
> >> This removes the arbitrary limit.
> >>
> >> Thanks,
> >>
> >> Michael
> >
> >>  libopenjpegdec.c |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> bc2d62e1146b20a9da2d5cd1e86884081e7c0cd8  0001-libopenjpegdec-set-max_lowres-to-UINT8_MAX.patch
> >> From 643d6db4faf35b57b8d834d4dd1db90165ad257f Mon Sep 17 00:00:00 2001
> >> From: Michael Bradshaw <mbradshaw at sorensonmedia.com>
> >> Date: Wed, 18 Jul 2012 21:47:33 -0600
> >> Subject: [PATCH 1/2] libopenjpegdec: set max_lowres to UINT8_MAX
> >>
> >> OpenJPEG doesn't have a max limit, so don't enforce an arbitrary one.
> >>
> >> Signed-off-by: Michael Bradshaw <mbradshaw at sorensonmedia.com>
> >> ---
> >>  libavcodec/libopenjpegdec.c |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> >> index 5b5d27b..31fff7c 100644
> >> --- a/libavcodec/libopenjpegdec.c
> >> +++ b/libavcodec/libopenjpegdec.c
> >> @@ -388,7 +388,7 @@ AVCodec ff_libopenjpeg_decoder = {
> >>      .close            = libopenjpeg_decode_close,
> >>      .decode           = libopenjpeg_decode_frame,
> >>      .capabilities     = CODEC_CAP_DR1 | CODEC_CAP_FRAME_THREADS,
> >> -    .max_lowres       = 5,
> >> +    .max_lowres       = UINT8_MAX,
> >
> > this is possibly problematic
> >
> > lowres is in log2 units, a value of 255 would dwarf the act of
> > reducing a image the size of teh vissible universe with pixels as
> > small as subatomic particles down to a single pixel.
> > that alone wouldnt be a problem but a more realworld issue
> > is that lowres is used in the form of width >> lowres and shifts
> > become undefined when they exceed the number of bits of the shifted
> > field, thus i would suggest that the largest limit would be 31 or
> > possibly less.
> 
> Out of curiosity, are there any < 32 bit fields (i.e. shorts or chars)
> that get shifted by lowres? If so maybe 15 or 7 would be better (or
> up-casting said shifted fields).

C converts to the int type for doing arithmetic for types that fit into
it, so there is no issue there for the supported systems.


More information about the ffmpeg-devel mailing list