gst-omx on Tegra 3

[Sebastian Dröge]

On Mi, 2014-02-26 at 11:52 +0100, Erwin Rol wrote:
> On 25-2-2014 20:03, Sebastian Dröge wrote:
> > On Di, 2014-02-25 at 19:45 +0100, Erwin Rol wrote:
> >> Hey all,
> >>
> >> I have some problems getting gst-omx for Tegra 3 to work acceptably fast.
> >>
> >> With the following pipeline I tested the speed;
> >>
> >> gst-launch-1.0 filesrc
> >> location=/ads/data/current/movies/sintel_trailer-720p.mp4 ! qtdemux !
> >> h264parse ! omxh264dec ! progressreport ! fakesink
> >> [...]
> >> The CPU load seems to be really high for some unidentified thread;
> >> [...]
> >> Any idea what I am doing wrong? The decoding really seems to be done in
> >> hardware since apart from the omx h264 decoder there is no other h264
> >> decoder on this system. So I am a bit surprised by the high CPU load,
> >> and the poor performance.
> > 
> > So as this thread got no name it is most likely a thread created not by
> > GStreamer. You should check e.g. with gdb which threads are running and
> > what they are doing. Maybe it's a thread running by the OpenMAX IL
> > implementation of NVIDIA, and it's doing stuff because the decoder was
> > not configured correctly. But without understanding what this thread is
> > doing at all this is just guessing.
> > 
> > Running inside a profiler should also help you to find the place where
> > all the CPU is spent.
> 
> I used GDB to check the high CPU thread and it always seems to be in
> NvRmSurfaceRead (from closed source nVidia lib) or memcpy.
> 
> I found this online;
> https://gitorious.org/nvtegra-gst/gstomx/source/f9c9422b75d5fc5620adca792761eaf0f40845ed:gst-openmax/omx/gstomx_base_videodec.c
> 
> and they have some special cases for tegra. Maybe the high CPU load
> comes from some software surface/color conversion? Would that be a
> plausible explanation?

So yeah, you have to implement such a special code path in gst-omx then.
As it looks the default behaviour with the normal OMX API is that the
NVIDIA OpenMAX IL implemention memcpys all the data... which you of
course don't want.

For implementing that, see the EGLImage code path that is currently
there for the RPi. Something like that but probably a bit simpler
because no second OMX component is required in your case AFAIU.

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- 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: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20140228/96edc607/attachment.pgp>