BGRA for omxh264enc and omxh264dec

Tue Feb 23 12:43:51 UTC 2016

Hi Sebastian.

See replies further down.

On Tue, Feb 23, 2016 at 10:14 AM, Sebastian Dröge <sebastian at centricular.com
> wrote:

> On Mo, 2016-02-22 at 16:30 +0100, Peter Maersk-Moller wrote:
> > Hi Sebastian.
> > Seems you wrote most of the omx modules.
> > Is it possible to extend omxh264enc and omxh264dec to accept
> > respectively provide BGRA in addition to the RGBA format they already
> > support?
> > Such an addition can make a big difference on the RasPi platform in
> > case BGRA is needed due to the high penalty one has to pay when
> > converting from RGBA to BGRA. As far as I can see, the hardware
> > encoder/decoder on the RasPi supports BGRA in addition to the
> > selected RGBA format.
> > I420 may also be useful.
>
> I420 is already supported, no?
>

My mistake. So far it seems I420 is the only one that works.
Testing the following pipeline:

gst-launch-1.0 -v videotestsrc is-live=1 ! 'video/x-raw,format='$format !
omxh264enc ! fakesink

with these formats :I420 YV12 YUY2 UYVY AYUV RGBx BGRx xRGB xBGR RGBA BGRA
ARGB ABGR RGB BGR Y41B Y42B YVYU Y444 v210 v216 NV12 NV21 NV16 NV61 NV24
GRAY8 GRAY16_BE GRAY16_LE v308 RGB16 BGR16 RGB15 BGR15 UYVP A420 RGB8P YUV9
YVU9 IYU1 ARGB64 AYUV64 r210 I420_10LE I420_10BE I422_10LE I422_10BE
Y444_10LE Y444_10BE GBR GBR_10LE GBR_10BE NV12_64Z32 A420_10LE A420_10BE
A422_10LE A422_10BE A444_10LE A444_10BE

Then only format that works is I420.

Shouldn't 'gst-inspect-1.0 omxh264enc' report that the only format it takes
is I420?

The format RGB16 with the above pipeline reports :

ERROR:gstomxvideoenc.c:1072:gst_omx_video_enc_set_format: code should not
be reached

while all the other formats reports:

ERROR: from element /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
Internal data flow error.

When using this pipeline:

gst-launch-1.0 -v videotestsrc is-live=1 ! 'video/x-raw,format='$format !
videoconvert ! omxh264enc ! fakesink

the following formats works (*but gets converted to I420 by videoconvert*):

I420, YV12, NV12, NV21, A420, YUV9, YVU9, I420_10LE, I420_10BE, NV12_64Z32,
A420_10LE, A420_10BE,

while the rest does not producing this error:

ERROR:gstomxvideoenc.c:1072:gst_omx_video_enc_set_format: code should not
be reached

>
> For the other formats, adding support for them would definitely be a
> good idea. Can you file a bug for this, ideally with a patch?
>

I can. Is the above description enough for the bug report?

For the patch, can you point to the code where you detect hardware
capabilities before reporting it for the sink pad of omxh264enc ?
Is the code in omxh264enc prepared for reporting multiple sink
capabilities, or just one. Not sure I know how to extend the code to report
multiple capabilities. When done, I can try to look into how to make the
hardware encoder accept other formats than I420 as it should be able to.
Maybe it needs some of these *broadcom tunnels* for conversion that some of
the encoding examples for BCM2835/2836 shows.

Best regards
Peter Maersk-Moller

> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.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/20160223/35995b48/attachment-0001.html>