Hei everyone,
the documentation to the gstreamer Plugin colorspace converter (mfw_ipucsc) is really medium rare , my issue: Is there any chance, to get a RGB888 instead of this useless RGB565 16bit format through the hardware? Better would be an ARGB output in 32bit.
The gst-inspect only show's this one option and a single presentation sheet shows the 565 option.
Since i've to use an OV10360 Imager I've got only NV12 (or I420) raw data. I've need to use them as OpenGL texture data and therefore in real time RGB. Needless to say that the conversion shouldn't touch the processor.
Thank's a lot
解決済! 解決策の投稿を見る。
IPU can support I420 to 32bit RGB888, but currently, the ipucsc plugin not support this convert.
So currently no support for it.
IPU can support I420 to 32bit RGB888, but currently, the ipucsc plugin not support this convert.
So currently no support for it.
I use the gstreamer plugin to convert CS, but the mfw_ipucsc module just support 16bpp with RGB,
any schedule to support 32bpp for RGB CS ???
I don't think that this will happen. The Module don't have all the features presented by the IPU, just the ones that are needed to run the evalkits and their displays. You'll need to use the IPU as presented in the IPUV3 Users Guide chapter 1.5: mxc_ipu_lib_task_init(), task_update() (repeating) and task_uninit().
To prevent cpu-memcopys I recommend mfw_new_hw_buffer() to get physical Handles for the IPU-Side.
bad news, i need a common API like gstreamer with 32bpp to apply my case.....thanks all the same
You can keep forwarding and develop their IPU Plugin for your needs, by adding the cases that you are missing. Its just about the naming conventions of gstreamer formats and ipu formats, that can be also found in mxc_ipu.hl.c, which is directly used by the plugin. Since Gstreamer emerged to more comfortable format-id's from version 1 to version 2 I recommend using version 2. Just add the cases in the pad-negotiation inside and the pad capabilities at the beginning. Using the IPU inside your own plugins can help to increase speed, since the task-handler of gstreamer can make less unappropriate decissions, this works fine for me, especially for RGB 24- or 32-bit real-time needs.