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

[Michael Niedermayer]

On Tue, Oct 27, 2009 at 02:02:01AM +0100, Stefano Sabatini wrote:
> 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

>  swscale.h |   10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 9f55e1e0b67eb4a975e6dffac8959dde68d269ec  sws-document-slice-ordering.patch
> Index: libswscale/swscale.h
> ===================================================================
> --- libswscale/swscale.h	(revision 29797)
> +++ libswscale/swscale.h	(working copy)
> @@ -135,8 +135,16 @@
>  /**
>   * Scales the image slice in srcSlice and puts the resulting scaled
>   * 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.
> + * rows in an image.
>   *
> + * Slices have to be provided in sequential order, either in
> + * top-bottom or bottom-top order. 

> The assumed direction for each
> + * image depends on the first slice provided. If the first slice
> + * corresponds to a top slice then it is assumed the top-bottom order,
> + * if it corresponds to a bottom slice is assumed the bottom-top
> + * order, otherwise the function will not draw anything and will return
> + * 0.

this documents how the current implementation handles cases that have
undefined behavior.
swscale does not gurantee that it will identify slice order like you
document nor does it gurantee that it draws nothing nor that it will
return 0.
If slices come in any order different from sequential, consecutive from
top->bottom/bottom->top then the behavior is undefined. It might as well
scale the image correctly or format your disk.

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

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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-devel/attachments/20091027/17dd7640/attachment.pgp>