After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749439 - bayer2rgb: add support for 24-bit RGB/BGR output
bayer2rgb: add support for 24-bit RGB/BGR output
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 751035 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-05-15 16:06 UTC by Hamdi Rakkez
Modified: 2018-11-03 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hamdi Rakkez 2015-05-15 16:06:17 UTC
Why, unlike Gstreamer-0.10, Gstreamer-1.0 does not deliver a RGB image format ?
Comment 1 Marcin Kolny (IRC: loganek) 2015-06-10 19:28:53 UTC
Hi,
It seems, you've chosen wrong "product" when you filed this bug. It's probably GStreamer, not gstreamermm related bug.
Let me set this field to GStreamer.
Comment 2 Nicolas Dufresne (ndufresne) 2015-06-16 13:04:52 UTC
*** Bug 751035 has been marked as a duplicate of this bug. ***
Comment 3 Tim-Philipp Müller 2015-06-16 13:13:18 UTC
1.0 bayer2rgb delivers the exact same RGB formats as 0.10 bayer2rgb, so could you please explain what difference there is?
Comment 4 Hamdi Rakkez 2015-06-16 13:27:37 UTC
No it's not the same.
bayer2rgb in gstreamer-1.0 delivers xRGB, RGBx and others but not an RGB format.

The difference is that a RGBx frame pixel needs 4 bytes to be represented in the memory and RGB or BGR format is only on 3 bytes/pixel.

The different is huge when you are using gstreamer on a limited resources embedded system.

Do you get the difference now ?
Comment 5 Tim-Philipp Müller 2015-06-16 13:37:09 UTC
I understand the difference between RGBx and RGB, yes.

What I don't understand is the claim that bayer2rgb in 0.10 supported this and in 1.x it doesn't:

$ gst-inspect-0.10 bayer2rgb
...
Plugin Details:
  Name:			bayer
  Description:		Elements to convert Bayer images
  Filename:		/usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstbayer.so
  Version:		0.10.23
...
Pad Templates:
...
  SRC template: 'src'
    Availability: Always
    Capabilities:
      video/x-raw-rgb
                    bpp: 32
                  depth: 24
...
      video/x-raw-rgb
                    bpp: 32
                  depth: 24
...
      video/x-raw-rgb
                    bpp: 32
                  depth: 24
...
      video/x-raw-rgb
                    bpp: 32
                  depth: 24
...
      video/x-raw-rgb
                    bpp: 32
                  depth: 32
...
      video/x-raw-rgb
                    bpp: 32
                  depth: 32
...
      video/x-raw-rgb
                    bpp: 32
                  depth: 32
...
      video/x-raw-rgb
                    bpp: 32
                  depth: 32

What you are asking for used to be bpp=24,depth=24 in 0.10.

It's a reasonable thing to ask for of course, I just don't understand the 0.10 claims.
Comment 6 Hamdi Rakkez 2015-06-16 13:46:52 UTC
Ok man can you forget about the 0.10 claim and focus on the problem here.
Thanks.

And since I don't need the x whatever it is Alpha or anything else, why am I forced to deliver it in the output of the bayer2rgb element ?

My CPU is limited and every byte counts here.
Comment 7 Tim-Philipp Müller 2015-06-16 13:51:52 UTC
Ok man, retitling bug accordingly. Are you going to work on a patch?
Comment 8 Hamdi Rakkez 2015-06-16 13:55:07 UTC
Yes that's the right title.

Yes a patch is perfect since I am using YOCTO project.

But for now I could change the gstbayer2rgb.c and remake install the plugin.
Comment 9 Nicolas Dufresne (ndufresne) 2015-06-16 14:39:12 UTC
(In reply to Hamdi Rakkez from comment #8) 
> Yes a patch is perfect since I am using YOCTO project.

Small clarification here, Tim is asking if we can expect *you* to provide a patch ? Patches are expected to be attach to the associated bug. We will then proceed with a code review. If there is something to fix, you will have to resubmit your patch with the modification requested. When it's ready, we will merge it as part of the upstream project (with your name on it of course) and close this bug.
Comment 10 Nicolas Dufresne (ndufresne) 2015-06-16 14:42:32 UTC
A small warning here about CPU usage. It is clear the RGB will consume more then the padded RGBx (and variants). The reason is that you will need more instructions (more load and store operations) to read and write pixels. So the gain is in fact on memory (25%). This feature makes a lot of sense if this is the constraint on your platform.
Comment 11 Hamdi Rakkez 2015-06-16 14:53:11 UTC
You mean RGB will consume less then the padded RGBx (and variants).

And yeah okay I will win in memory.

I've tried to modify gstbayer2rgb.c so it can deliver 24bit-RGB but I'm getting a bizarre output every time.

And since I am new to gstreamer programming why can't you fix this problem and provide a patch so whomever wants to use this format will find it without any struggle.

And if you think it is not that hard to do it, It will be great if you fix this.

Thank you both.
Comment 12 Nicolas Dufresne (ndufresne) 2015-06-16 15:00:47 UTC
Don't turn my comment wrong, it will most likely use *more* CPU. Quick profiling show that memory operation (load/store) are part of the bottleneck. You need 3 store operations per pixels in RGB, and only 1 for RGBx. For that, you need to be aware the RGBx buffers are aligned, you you can address as an array of uint32. This is not the case for RGB, so you can only grab uint8.

I don't have any use for that element myself, that just how Open Source works. People bring their use cases, add code to fulfill it. Maintainers review, and when happy merge and maintain. Doing the later maintenance of your code and use case isn't a small thing.
Comment 13 Hamdi Rakkez 2015-06-16 15:24:38 UTC
Okay Thanks Nicolas.

I will compare RGB and RGBx CPU performance and I will come back to you.

And I will upload a patch when I am done.
Comment 14 GStreamer system administrator 2018-11-03 13:35:30 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/254.