[FFmpeg-devel] [PATCH]Fix progressive jpgs with weird pix_fmts

[Michael Niedermayer]

On Thu, Jan 12, 2012 at 10:48:18PM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> On Saturday 07 January 2012 03:21:36 pm Michael Niedermayer wrote:
> > On Sat, Jan 07, 2012 at 12:26:29PM +0100, Carl Eugen Hoyos wrote:
> > > On Saturday 07 January 2012 03:27:52 am Michael Niedermayer wrote:
> > > > On Sat, Jan 07, 2012 at 03:17:36AM +0100, Carl Eugen Hoyos wrote:
> > > > > On Saturday 07 January 2012 02:59:06 am Michael Niedermayer wrote:
> > > > > > > Attached fixes the samples from ticket #892 for me.
> > > > > > >
> > > > > > > Please comment, Carl Eugen
> > > > > >
> > > > > > reset upscale* otherwise this is possibly exploitable if the width
> > > > > > or height or "pix_fmt" changes
> > > > >
> > > > > As in attached?
> > > >
> > > > not enough
> > > >
> > > > 1st frame sets upscale_h
> > > > 2nd frame changes width/height and branches via -1 from
> > > >  ff_mjpeg_find_marker to the_end
> > >
> > > Iiuc, width/height can only be set in ff_mjpeg_decode_sof(), so new patch
> > > resets the value at the beginning of this function.
> > >
> > > > also wherever the variables are reset i suggest that a av_assert0 is
> > > > added to make sure the pixel format matches the expectation that is
> > > > theres enough space for chroma
> > >
> > > I don't understand:
> > > If the variables are reset (to 0), the code that may overwrite chroma /
> > > corrupt memory is not called, the variables are set together with the
> > > pix_fmt.
> > >
> > > Only s->ls change the pix_fmt later, upscale now also gets reset in this
> > > case.
> > 
> > my concern is if the code is changed in the future. A new code path
> > could be added that changes width/height and forgets reseting these
> > variables
> 
> Thank you for the explanation.
> 
> New patch attached.
> 
> Please comment, Carl Eugen

LGTM

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120112/d0854b82/attachment.asc>