<div dir="ltr"><div><div><div><div><div>Hi Sebastian.<br><br></div>That is exactly what is needed. So it can be done in HW.<br><br>Any remote chance this gets into a release in future not too distant future before practical realization of teleportation, hot fusion and singularity?<br><br></div><div>If not, what is the latest GStreamer version this works with and are there some instructions somehwree on how merge this with some version on gst-omx ?<br></div><div><br></div>I am preparing a release of Snowmix that will make simple and advanced 2D and 3D scriptable video mixing possible and practical on the Raspberry Pi 2 platform and I have all the other components necessary working pretty well and efficiently except it just can't fly unless I can find a way to convert a video stream to a RGBA frame stream without a crippling load on the CPU. The <b>omxcolorscale</b>, either as an independent module or buit-in within the omxXXXXdec module, is all that is needed. Same for omxXXXXenc would be nice too, but converting from RGBA to I420 in software does not have same perfomance penalty as the other way around with current implementation for Raspberry Pi.<br><br>The release of Raspberry PI 3 with 30-100% more juice depending on what is measured, just makes it all more realistic to do serious video mixing on these low cost platforms.<br><br></div>I'm trying to read through the code, but would have no idea on how to add/merge it to/with current gst-omx sources. Not that I can't add code, just that I don't know all the internals og Gstreamer.<br><br></div>Best regards<br></div>Peter Maersk-Moller<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 9:06 AM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mo, 2016-03-14 at 05:39 +0100, Peter Maersk-Moller wrote:<br>
> Hi Sebastian.<br>
><br>
> Looking into the to the problem of converting and/or resize I420 or<br>
> NV12 output from the omxh264dec (and others), there seem to be ways<br>
> to both convert to other raw formats as well as perhaps resize the<br>
> output all using the GPU.<br>
><br>
> The OpenMAX Il-component video_splitter (input port 250, output ports<br>
> 251-254 - only one is needed) can take input as I420 and output as<br>
> OMX_COLOR_Format32bitARGB8888 or OMX_COLOR_Format32bitBGRA8888 (one<br>
> of which I believe is called a byte stream of R, G, B and A bytes<br>
> (RGBA)) and possibly OMX_COLOR_Format24bitRGB888 or<br>
> OMX_COLOR_Format24bitBGR888 (one of which is believed to be RGB). I'm<br>
> not sure it can do both RGB(A) and BGR(A).<br>
><br>
> Anyway, it should be possible to connect the encoder's port 131 to<br>
> the video_splitter's port 250, set the splitter port 250 format to<br>
> I420, perhaps provide buffers for this, set the splitter port 251 to<br>
> RGBA or RGB and feed it data buffers from downstream (perhaps shm)<br>
> for zero-copying. An of course the video_splitter component has to be<br>
> started and prepared for state chage etc.<br>
><br>
> For video resizing (and conversion) the OpenMAX image component<br>
> resize can take I420 input on port 60 AND scale AND convert to image<br>
> formats such as RGBA and RGB (I am 95% sure) and output these to<br>
> output port 61 on data buffers from downstreams (perhaps shm).<br>
><br>
> All this of course applies to the other omxXXXdec modules.<br>
><br>
> The same should be possible for the input for omxh264enc and the<br>
> other encoders in a way so the encoders can take I420/RGB/RGBA at any<br>
> size and the decoders can output I420/RGB/RGBA at any size.<br>
><br>
> The "any size" may be to take it to far. There are some restrictions<br>
> for either the encoder and the decoder. For one of them, the width<br>
> and height must both be even numbers and for the other, both must be<br>
> a multipla of 16. I just don't know if you can link OpenMAX video<br>
> modules to OpenMAX image modules. At least some timing may be set and<br>
> controlled out-of-band when going over an image module .... perhaps.<br>
><br>
> I tried looking to the GStreamer code, but I can't really see where<br>
> to add the functionality and I am still struggling with the very<br>
> poorly documented OpenMAX examples and docs.<br>
><br>
> I hope this is worth looking at. Especailly converting from I420 to<br>
> RGBA for is nearly impossible on the Pi-platform for 720p and quite<br>
> impossible for 1080p with the current gstreamer version, conversion<br>
> alone take a lot of CPU not really present.<br>
><br>
> Does it help to open a ticket for an improvement?<br>
<br>
</div></div>Here's a ticket with an (outdated) patch that integrates the resize<br>
component via tunneling into the decoder:<br>
<a href="https://bugzilla.gnome.org/show_bug.cgi?id=722686" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=722686</a><br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a><br>
<br>
</div></div><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>