GStreamer on TI DaVinci and OMAP

NotesOnDM365Performance

720P Playback on DM365

If you experience degraded 720P playback performance on DM365, you may be able to improve it with a pipeline modification. If your pipeline is not set-up correctly, you may only see about 20fps when playing H.264, or 23fps when playing MPEG4.

The key to better performance is to put a GStreamer "queue" element in-between the video decoder and the video sink. This will cause the video sink to run in a separate thread, instead of running in lock-step with the decoder.

In general, max-size-buffers should be set to one less than the number of display buffers for best results. We have three display buffers, so we specified "2" above.

If you are using the "decode_elementary.sh" or other scripts to play video, note that the queue element is not used, as these scripts are generic across all platforms and are only meant to give simple pipeline examples.

Special Note on H.264 Decoding

When using the H.264 decoder, the codec may require additional buffers to be allocated. The number of buffers allocated by the video decoder is specified using the "numOutputBufs" property on the decoder. Below is a pipeline that demonstrates how to use this property:

In this case we are using 18 buffers, as perscribed by the DVSDK's "decode" demo for DM365. As before, this adjustment is not done by the simple "decode_*.sh" scripts. If enough buffers are not allocated, you may see an error like

ERROR: from element /GstPipeline:pipeline0/\GstTIViddec2:tividdec20: failed to get a free contiguous buffer from BufTab

Still Not Quite Realtime

With the modifications above, you will still probably see about 28.5fps for H.264 playback and 29.5fps for MPEG4 playback. This is really close to real-time playback, but not quite. When playing back audio/video clips like .AVI or .MP4 files, GStreamer will drop video frames occasionally to make up for this. Real-time performance could potentialy be achieved by creating a real-time thread in the TIDmaiVideoSink that prioritizes the display thread higher than the video decode thread. If you feel ambitious enough to make this change, or have a better solution, please share!!