[gst-devel] stride

[Thomas Vander Stichele]

Hi,

> I ran into this same problem with gdkpixbuf last week - it decodes images
> and tells you the rowstride it has used. I ended up putting a note about it
> in ds' 0.9 changes file, because adding a rowstride means redefining our
> video-frame buffers in an incompatible way - I think it's too incompatible a
> change to make in 0.8

Yeah, I noticed while grepping.

> > - do we have an explicit or implicit definition of how data should be
> > laid out in both RGB and YUV ?
> 
> At the moment, the exact (packed) layout is implicit in the rgb+width+etc/yuv+format caps settings.

But what do the implicit settings imply ? :) videotestsrc is outputting
data with rowstride in some cases; videotestsrc with video/x-raw-rgb,
bpp=16, width=3, height=2 will give you data buffers of the same size as
with width=4.
(Try

gst-launch -v videotestsrc ! video/x-raw-rgb,bpp=16,width=3,height=2 !
fakesink

and
gst-launch -v videotestsrc ! video/x-raw-rgb,bpp=16,width=4,height=2 !
fakesink)

Which is also how ximagesink accepts the data (not sure yet if this is
by accident or if this really is a standard way of aligning data to
multiples of 4 bytes).  For YUV it's of course more complicated.

Meanwhile, videoscale doesn't use an implicit rowstride at all, causing
the image to be completely warped when displaying video in 16bpp with
odd width.

So does anyone know what the implied stride is for all colorspaces ? And
if it's ok to fix videoscale ?


> > - videotestsrc implicitly seems to output data with rowstride in my
> > particular test case.  Can we trust videotestsrc to be doing the correct
> > thing or should I doublecheck it for all cases ?
> 
> I'm not sure what that means? Do you mean "with rowstride = width * bytes-per-pixel" ?

Like I said, videotestsrc seems to fill image lines to match the
implicit rowstride, NOT the width of the video it's outputting.

> > - should rowstride be part of the caps (at least in cases where the
> > rowstride is not the one that you would implicitly assume) ?
> 
> I think it should, but we need to think about which elements will transform
> rowstride etc first.

transforming could be done directly in videoscale IMO, as well as in
colorspace.


> > - Is it ok to make colorspace and videoscale elements to handle
> > rowstride correctly ?
> 
> I don't think we should in 0.8

Look at it this way - when it works now it's because you happen to be
transforming video where rowstride == width * bytesperpixel, or where a
downstream element is already doing rowstride stuff without telling you
so.  So it's a bug that can be fixed compatibly in 0.8 IMO.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Another Love Song
That is written
Still nothing said
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/