GNOME Bugzilla – Bug 749439
bayer2rgb: add support for 24-bit RGB/BGR output
Last modified: 2018-11-03 13:35:30 UTC
Why, unlike Gstreamer-0.10, Gstreamer-1.0 does not deliver a RGB image format ?
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.
*** Bug 751035 has been marked as a duplicate of this bug. ***
1.0 bayer2rgb delivers the exact same RGB formats as 0.10 bayer2rgb, so could you please explain what difference there is?
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 ?
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.
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.
Ok man, retitling bug accordingly. Are you going to work on a patch?
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.
(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.
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.
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.
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.
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.
-- 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.