<div dir="ltr">Sebastien,<div><br></div><div>Thank you very much for the reply. It was helpful, but of course it raises more questions. :)</div><div><br></div><div>Maybe it would be more clear if I explain what I'm trying to do and someone could point out problems / make suggestions.</div><div><br></div><div>1. I'm using Android on a Compulab Utilite iMX6 platform.</div><div>2. I'm currently using Gstreamer as a general way to decode video files - I want to retain this.</div><div>3. I am adding support for hardware decode of H264 stream - <b>low latency is important.</b></div><div>4. When I use the iMX6 hardware decode path in Gstreamer I get 8+ frames of latency:</div><div> decoder = gst_element_factory_make ("amcviddec-omxfreescalestdvideodecoderavcv3hwbased", "decoder");</div><div>5. I googled for other people with similar issues and came across suggestions like this: (effectively "set nReorderEnable=false if your stream doesn't use B frames"):</div><div> <a href="https://community.freescale.com/thread/304322" target="_blank">https://community.freescale.com/thread/304322</a></div><div><br></div><div>So I went down the path of changing vpudec.c to change nReorderEnable=false etc...<b>I think this may be where my mistake was as I'm realizing that this may not work on Android</b>. Similarly I found the imxvpuapi library as a way to achieve the same thing, but again I'm now thinking this isn't for Android. </div><div><br></div><div>Basically I want to retain gstreamer for my general video file playback needs and I also want to come up with a way to decode a live H264 stream with low latency. It is OK for the low latency decode to be "tied" to the iMX6 platform. <b>I now think that using OpenMax IL directly (with the caveat you mentioned) is probably my best option</b>. </div><div><br></div><div>Does that seem right? </div><div> </div><div><br></div><div>Steve</div><div> </div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 10:55 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"><span class="">On Mo, 2014-10-06 at 10:47 -0600, Stephen Webb wrote:<br>
> I'm trying to understand how these things fit together / relate to each<br>
> other. I'm afraid that I may not know enough to even ask intelligent<br>
> questions at this point, so if someone can point me to documentation or<br>
> other resources tat would help, that would be great.<br>
><br>
> My current questions:<br>
><br>
> 1. How do gstreamer and openmax relate to each other? Is it best to think<br>
> of gstreamer as a replacement/alternative to Openmax? A replacement for<br>
> the OpenMax AL? They both seem to do a lot of the same things.<br>
<br>
</span>GStreamer is a bit like OpenMAX AL and OpenMAX IL together, but has an<br>
even broader scope than those too.<br>
<br>
GStreamer can use OpenMAX IL via gst-omx (so you can use e.g. hardware<br>
codecs that have an OpenMAX IL API in GStreamer pipelines). In theory<br>
you could also implement the OpenMAX IL and AL API on top of GStreamer.<br>
<span class=""><br>
> 2. I was under the impression that OpenMax was the standard way to get<br>
> multimedia support on Android - as in it is required in some way when doing<br>
> multimedia work on Android (specifically when any low level hardware access<br>
> comes into play). Having dug in and looked around a fair amount, I don't<br>
> see much mention of OpenMax - it doesn't seem so central at all.<br>
<br>
</span>OpenMAX IL is not public API on Android but many devices use it (but you<br>
shouldn't use it directly unless you target exactly a specific device),<br>
OpenMAX AL is public API on Android but last time I looked only<br>
supported MPEG TS.<br>
<br>
The public API for accessing codecs on Android is the Java<br>
android.media.MediaCodec API, which is supported by the GStreamer<br>
androidmedia plugin.<br>
<span class=""><br>
> 2. I found the imxvpuapi project. If this works on Android this seems<br>
> like exactly what I need.<br>
> a. Does it work on Android?<br>
> b. With the only dependency being libfslvpuwrap / vpu_wrapper.h this<br>
> appears to interface directly with the freescale vpu driver (no OMX, no<br>
> gstreamer). Is this right? Does this work on Android? If so, am I<br>
> confused about how Android locks things down and doesn't allow applications<br>
> to get low level hardware access?<br>
<br>
</span>I don't know any answers for this one, but you're constraining yourself<br>
to iMX based devices then in any case :)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Sebastian Dröge, Centricular Ltd - <a href="http://www.centricular.com" target="_blank">http://www.centricular.com</a><br>
Expertise, Straight from the Source<br>
</font></span><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>