[FFmpeg-cvslog] r20552 - trunk/libavcodec/mjpegdec.c

[Michael Niedermayer]

On Sun, Dec 13, 2009 at 10:15:46PM +0100, Reimar D?ffinger wrote:
> Hello,
> I unfortunately missed the reply...
> 
> On Mon, Nov 23, 2009 at 07:44:41PM +0100, Michael Niedermayer wrote:
> > On Sun, Nov 22, 2009 at 01:10:36PM +0100, Reimar D?ffinger wrote:
> > > On Sun, Nov 22, 2009 at 12:26:26PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Nov 20, 2009 at 03:57:59PM +0100, Reimar D?ffinger wrote:
> > > > > On Fri, Nov 20, 2009 at 02:21:53PM +0100, Michael Niedermayer wrote:
> > > > > > I dont think this is correct
> > > > > > The test should be s->height % (s->v_max*8)
> > > > > > 
> > > > > > besides this the fliped code also looks suspect
> > > > > 
> > > > > Hmm. Does anyone actually have or can create a sample that should be flipped
> > > > > and where the height is not divisible by 8 or so?
> > > > 
> > > > you can just set flipped = 1 with a normal jpeg to test it i guess 
> > > 
> > > I'm not sure about that, at least I do not know whether the padding is
> > > on top or on bottom for the flipped image, and using a normal jpeg can
> > > only tell me how that is for normal JPEGs, but not those created as
> > > flipped by default I think?
> > > 
> > > > > Either way, I am quite confident that the check here should be exactly
> > > > > for the same thing as whatever is used for the flipping code.
> > > > 
> > > > i doubt (height / 3) % 8 is correct
> > > > example: height=25
> > > > height/3 == 8
> > > > actually written height= 48
> > > 
> > > And data[c] is incremented by
> > > s->v_scount[i] * (8 * s->mb_height - 1)
> > > lines, so all those 48 lines still fit in it even with EMU_EDGE.
> > 
> > hmm
> > 3 * (8 * 2 - 1) = 45
> > data->  0,0
> >         :
> >         0,45
> >         0,46
> >         0,47
> > after this
> >         0,0
> >         :
> > data->  0,45
> >         0,46
> >         0,47
> 
> I admit I completely fail to understand what the does, what v_count means etc. pp.
> However, could it be that the code should be
> > s->v_scount[i] * 8 * s->mb_height - 1
> instead of
> > s->v_scount[i] * (8 * s->mb_height - 1)

possible


> My point is just, that as long as we do not have to crop, if the picture fits in
> the one way it should also fit in flipped.
> So the only issue is when we have to decode more than the picture is high, but regardless
> of the value of v_scount that is always the case if the height is not a multiple of 8,
> or am I misunderstanding how the code works?

no, thats sounds correct, just keep in mind
1. interlacing
2. jpeg stores the "macroblock" size its not fixed 16x16

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20091214/0c61671f/attachment-0001.pgp>