Set partial pixel to be transparent in video

[Peter Maersk-Moller]

Hi Sean.

See commets inline.

On Mon, Sep 26, 2016 at 6:50 PM, Sean <csosmo at hotmail.com> wrote:

> Hi, Peter,
> Thanks for pointing out the "byte-ordering" of RGBA in Gstreamer. However,
> if we don't care the performance and only care the correctness. I think the
> following implement should work in myelement (i. e. writing the 4th byte of
> each pixel):
>
>     for (int i  = 0; i < 240; i++) {
>       for (int j = 0; j < 640; j++)
>       info.data[(i*640+j)*4-1] = 0x0;
>     }
>

Not quite. When i and j are 0, you get info.data[-1].
Furthermore I don't know the type of info.data. If it not a byte array,
you  will get it terribly wrong. So something like this:

  u_int8_t* p = ((u_int8_t*)&info.data[0])+3;
  for (int i = 0; i < 240 ; i++) {
    for (int j = 0 ; j < 640 ; j++) {
      *p = 0x0;
      p += 4;
    }
  }

  If that doesn't work, then maybe the format in info.data isn't RGBA
byte-order. Then you could try add 0, 1 or 2 until it worked. That would
tell you here the alpha is placed.


>
> However, the result is the same (i.e. the pixel at (row,col)=(0,4), (0,8)
> (0,12)...... become a GREEN pixel). Is it related to the "stride" value? If
> yes, how would I get stride information? I checked "GstMapInfo" which
> doesn't have stride information?
>

Setting something to 0 should not produce green. However you have not
explained how you get to see the pixel is green. So how do you get to see
that. Maybe you should show your working pipeline for testing this. Are you
determining that you see green after encoding it and then displaying it
using a player? So what is your pipeline and how do you see it is green?
You can not reliably test a pixel value by sending it through an encoder.

If I slightly modify your pipeline to this moving the videoconvert and
specifying I420 for input to x264enc:

  gst_launch -v videotestsrc ! video/x-raw,format=RGBA,width=640,
height=480 ! myelement ! videoconvert ! video/x-raw,format=I420 ! x264enc !
mpegtsmux ! filesink location=test.ts

Then what would you expect to see?  What would you expect a RGB pixel with
alpha set to zero to be converted and encoded as? Again you can not test a
pixel value reliably by sending it through an encoder.

By the way your original example pipeline would convert video from RGBA to
YUV 4:4:4 *BEFORE* entering you element. And YUV 4:4:4 is definitely not
RGBA. So your green might very well be a result and indicator of an invalid
YUV value. Not all 2^24 possible YUV values are valid.

The stride value is the number of bytes between the first pixel in row 0
and the first pixel in row 1. If the format is RGBA, then the stride value
is 4 times the width. If is 24 bit RGB, then it is 3 times the width unless
it is RGB in 32 bit.

*However* the stride I used in my example was the number of bytes between
the last pixel in first row you wanted to apply a zero alpha value to and
the first pixel in the next row you wanted to apply the zero alpha setting
to. If you wanted to apply zero alpha to all pixels in first and second row
up to some number, then stride would be zero. I just provided code for the
general example and if you for a specific subset set startcol=1 and
endcol=640, then it will also work.

>
> Thanks.
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.
> n4.nabble.com/Set-partial-pixel-to-be-transparent-in-
> video-tp4679769p4679799.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160927/297434ed/attachment-0001.html>