[gst-devel] stride

[Jan Schmidt]

<quote who="Thomas Vander Stichele">
> The problem I was having was that a video was being scaled to 1015x432. 
> Now when ximagesink was allocating buffers for this, the XShmCreateImage
> call gives you back a bytes_per_line property (which is video stride),
> and expecting it to be respected.  However, GStreamer was not feeding
> ximagesink data respecting the rowstride.

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

> - 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.

> - 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" ?

> - 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.

> - is it ok for ximagesink at runtime to figure out the rowstride, add it
> to the caps, and renegotiate its link ?
> - If we add it to the caps, should we add 3 of them for YUV data ?

Don't know, and don't know.

> - Is it ok to make colorspace and videoscale elements to handle
> rowstride correctly ?

I don't think we should in 0.8

J.
-- 
Jan Schmidt                                  thaytan at mad.scientist.com

I came for the quality. I stayed for the freedom. -- Sean Neakums