<div dir="ltr"><div>Hi Sebastian<br><br></div>Se replies in-line.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 10:13 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Mo, 2016-02-22 at 22:55 +0100, Peter Maersk-Moller wrote:<br>
> Hi.<br>
> Trying to use omxh264enc (1.2.0 with GStreamer 1.6.3) I see, using<br>
> gst-inspect-1.0 that the module sink capabilities are reported as:<br>
>   video/x-raw<br>
>                   width: [ 1, 2147483647 ]<br>
>                  height: [ 1, 2147483647 ]<br>
>               framerate: [ 0/1, 2147483647/1 ]<br>
> Apparently, it does not set limits for format. However it appear that<br>
> the modules will only accept I420. Using the following pipeline, it<br>
> works.<br></span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>The template caps are supposed to be configured by the gstomx.conf to<br>
be exactly what *your hardware* supports.</blockquote><div><br></div><div>As it does not report any formats (and only works for I420), can we agree that we have a bug here?<br></div><div>My platform is a standard Raspberry Pi2 Model B with latest updated Raspian. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Even if the gstomxh264enc.c<br>
code had support for various other formats, it would still depend on<br>
what your hardware can handle in the end.<br></blockquote><div><br></div><div>Obviously. That goes without saying.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> gst-launch-1.0 -v videotestsrc is-live=1 ! \<br>
> 'video/x-raw,format=I420' ! queue ! omxh264enc ! fakesink<br></span></blockquote><div><br></div><div>Works. <span class="">RGB, BGR, ARGB, ABGR, RGBA, BGRA does not.<br></span></div><div><span class="">I believe at least some of them ought to work. Don't you?<br><br></span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> However if the format is replaced with ne of the following formats:<br>
> RGB, BGR, ARGB, ABGR, RGBA, BGRA, I get this message:<br>
> ERROR: from element<br>
> /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: Internal data<br>
> flow error.<br>
> Additional debug info:<br>
> gstbasesrc.c(2943): gst_base_src_loop ():<br>
> /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0:<br>
> streaming task paused, reason not-negotiated (-4)<br>
> Now if the videoconvert module is add using this pipeline<br>
> gst-launch-1.0 -v videotestsrc is-live=1 ! \<br>
> 'video/x-raw,format=BGRA' ! queue ! omxh264enc ! fakesink<br>
> I get the error message:<br>
> gst_omx_video_enc_set_format: code should not be reached<br>
> Is this a feature or a bug? I would expect that the module at least<br>
> inform, using gst-inspect, that it has limitations wrt. formats. But<br>
> it would be nice if BGRA (and others) could be supported given the<br>
> hefty penalty one has to pay if using videoconvert module on the PI<br>
> platform.<br>
<br>
</span>It should probably not run into the assertion but error out cleanly. Do<br>
you want to provide a patch for that? :)<br></blockquote><div><br></div><div>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.<br><br></div><div>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 <u>you</u> used for interfacing to the encoders/decoders to make it a little bit easier to find the bug and create a patch?<br><br></div><div>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,<br></div><div><br></div><div>Best regards<br></div><div>Peter Maersk-Moller<br></div><div><br></div></div><br></div></div></div>