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

[Michael Niedermayer]

On Wed, Oct 28, 2009 at 11:51:16PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2009-10-27 11:19:21 +0100, Michael Niedermayer encoded:
> > 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.
> 
> OK, please check again.
> -- 
> FFmpeg = Faithful and Fundamental Multimedia Practical Elegant Goblin

>  swscale.h |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 63e85da162493fedba053214d0e623e4d542b3d7  sws-document-slice-ordering.patch

ok

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

There will always be a question for which you do not know the correct awnser.
-------------- 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/20091030/e5dd1ca4/attachment.pgp>