BGRA for omxh264enc and omxh264dec

[Sebastian Dröge]

On Di, 2016-02-23 at 13:43 +0100, Peter Maersk-Moller wrote:
> 
> > 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?

As said in the previous mail, it support I420 *and* NV12 currently.
It's just that on the RPi the encoder only supports I420 and nothing
else.

So what it should do is to report I420 and NV12 in general, and in the
RPi specific gstomx.conf you would override the pad template to only
list I420.

> > 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.

There is no hardware capability probing API for this (or it's not
implemented anywhere in a meaningful way). The code I showed you is
where the format specific handling is, the other changes would be for
the pad templates which would just be hardcoded... in code with a
default and in the gstomx.conf for the RPi.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160223/dd6f55cd/attachment.sig>