[Ffmpeg-devel] [PATCH] fix jpegls unitialized data reading
Mon Dec 11 06:04:34 CET 2006
On Sun, Dec 10, 2006 at 11:48:10AM +0100, Michael Niedermayer wrote:
> On Sun, Dec 10, 2006 at 11:37:27AM +0100, Reimar D?ffinger wrote:
> > Hello,
> > On Sun, Dec 10, 2006 at 11:10:23AM +0100, Reimar D?ffinger wrote:
> > > On Sun, Dec 10, 2006 at 02:28:37AM +0100, Michael Niedermayer wrote:
> > > > > Sorry, yet another correction. init_get_bits should get the larger size,
> > > > > too, in case somebody adds thorough checking of get_bits limits e.g. for
> > > > > debugging purposes.
> > > >
> > > > hmm what about align_put_bits() ?
> > >
> > > No, the flush_put_bits already does that implicitly, that is not the
> > > problem (on thinking again, this might actually be a bug
> > > that causes too many bits to be written by the encoder).
> > > The problem is that due to escaping sometimes only 7 bits are
> > > read. So this means you might end up with exactly one bit left to write,
> > > i.e. get_bits_count(&gb) == size * 8 - 1, which means you overread by 7
> > > bits.
> > To be more precise:
> > As I understand the spec, the attached patch should give correct output,
> > there is nothing to suggest that the unescaped bitstream must be
> > byte-aligned.
> > Also, the previous code had the bug of giving the size to init_get_bits
> > in bytes instead of bits.
> > In difference to the other patches, this does change the regression test
> > checksum though, to dca9d700da7857217408c310c501b9bc
> looks ok, kostya?
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> Breaking DRM is a little like attempting to break through a door even
> though the window is wide open and the only thing in the house is a bunch
> of things you dont want and which you would get tomorrow for free anyway
More information about the ffmpeg-devel