gst-omx on Tegra 3

[Erwin Rol]

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?

- Erwin