[FFmpeg-devel] [PATCH] Document slice ordering assumption done by sws_scale()

[Stefano Sabatini]

On date Monday 2009-10-26 21:13:44 -0200, Ramiro Polla encoded:
> On Mon, Oct 26, 2009 at 9:01 PM, Stefano Sabatini
> <stefano.sabatini-lala at poste.it> wrote:
> > as in subject.
> 
> > Index: libswscale/swscale.h
> > ===================================================================
> > --- libswscale/swscale.h	(revision 29797)
> > +++ libswscale/swscale.h	(working copy)
> > @@ -137,6 +137,12 @@
> >   * slice in the image in dst. A slice is a sequence of consecutive
> >   * rows in an image. Slices can be bottom to top or top to bottom.
> >   *
> > + * Slices have to be provided in sequential order,
> 
> > either in
> > + * top-bottom or bottom-top order.
> 
> This is already written right above it.

Yes, but that was far from being complete.

> > The assumed direction for the whole
> > + * image
> 
> IMO this should better be "for each image"

Fixed.
 
> > depends on the value of srcSliceY provided when drawing the
> > + * first slice, if it is 0 it is assumed top-bottom order, otherwise
> > + * bottom-top order.
> 
> That's not entirely right. It is assumed top-bottom if srcSliceY is 0,
> and bottom-top if srcSliceY + slice height == image height or
> something like that.
> 
> Anyways I think this is a hack, and instead of documenting the hack we
> should let the user specify the slice direction somehow.

I don't know, I don't find it so bad, especially considering that the
alternative (fiddling with the swscale context or passing a flag at
each sws_scale invokation) doesn't look either so good.

Anyway patch updated, maybe it's more clear now.

Regards.
-- 
FFmpeg = Foolish Frightening Meaningless Programmable Extroverse Gospel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sws-document-slice-ordering.patch
Type: text/x-diff
Size: 1027 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091027/f7acb00d/attachment.patch>