gst_omx_video_enc_set_format: code should not be reached

[Peter Maersk-Moller]

Hi Sebastian

Se replies in-line.

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

> On Mo, 2016-02-22 at 22:55 +0100, Peter Maersk-Moller wrote:
> > Hi.
> > Trying to use omxh264enc (1.2.0 with GStreamer 1.6.3) I see, using
> > gst-inspect-1.0 that the module sink capabilities are reported as:
> >   video/x-raw
> >                   width: [ 1, 2147483647 ]
> >                  height: [ 1, 2147483647 ]
> >               framerate: [ 0/1, 2147483647/1 ]
> > Apparently, it does not set limits for format. However it appear that
> > the modules will only accept I420. Using the following pipeline, it
> > works.
>


> The template caps are supposed to be configured by the gstomx.conf to
> be exactly what *your hardware* supports.


As it does not report any formats (and only works for I420), can we agree
that we have a bug here?
My platform is a standard Raspberry Pi2 Model B with latest updated
Raspian.


> Even if the gstomxh264enc.c
> code had support for various other formats, it would still depend on
> what your hardware can handle in the end.
>

Obviously. That goes without saying.


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

Works. RGB, BGR, ARGB, ABGR, RGBA, BGRA does not.
I believe at least some of them ought to work. Don't you?

> However if the format is replaced with ne of the following formats:
> > RGB, BGR, ARGB, ABGR, RGBA, BGRA, I get this message:
> > ERROR: from element
> > /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data
> > flow error.
> > Additional debug info:
> > gstbasesrc.c(2943): gst_base_src_loop ():
> > /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:
> > streaming task paused, reason not-negotiated (-4)
> > Now if the videoconvert module is add using this pipeline
> > gst-launch-1.0 -v videotestsrc is-live=1 ! \
> > 'video/x-raw,format=BGRA' ! queue ! omxh264enc ! fakesink
> > I get the error message:
> > gst_omx_video_enc_set_format: code should not be reached
> > Is this a feature or a bug? I would expect that the module at least
> > inform, using gst-inspect, that it has limitations wrt. formats. But
> > it would be nice if BGRA (and others) could be supported given the
> > hefty penalty one has to pay if using videoconvert module on the PI
> > platform.
>
> It should probably not run into the assertion but error out cleanly. Do
> you want to provide a patch for that? :)
>

I can try to look into it, but even if I find the error and a solution, I
wouldn't know how to submit a patch to the project. SO far I have just
found bugs and documented how to reproduce them.

Apparently there are many ways/methods (and libraries) to interface to the
BCM2835/BCM2836 hardware encoders, and some of them are getting obsolete or
left behind maintenance wise. Do you have a link to the documentation *you*
used for interfacing to the encoders/decoders to make it a little bit
easier to find the bug and create a patch?

Currently I'm using MMAL writing a modified version of RaspVidYUV (a
variant of RaspiVid as used for rpicamsrc) to output various formats as a
GStreamer shmsink able to interface to GStreamer shmsrc. It works fine and
will be release for free. Just an example og using another library/layer
than used the one used for gst-omx package,

Best regards
Peter Maersk-Moller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160223/7e5c364c/attachment.html>