GStreamer on TI DaVinci and OMAP
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.
Here is a bad example pipeline for 720P playback:
# gst-launch filesrc location=./davincieffect.264 ! TIViddec2 engineName=decode codecName=h264dec ! TIDmaiVideoSink displayStd=v4l2 displayDevice=/dev/video2 videoStd=720P_60 videoOutput=COMPONENT resizer=FALSE accelFrameCopy=TRUE
Here is a better pipeline that uses a "queue" element as described above:
# gst-launch filesrc location=./davincieffect.264 ! TIViddec2 engineName=decode codecName=h264dec ! queue max-size-buffers=2 max-size-time=0 max-size-bytes=0 ! TIDmaiVideoSink displayStd=v4l2 displayDevice=/dev/video2 videoStd=720P_60 videoOutput=COMPONENT resizer=FALSE accelFrameCopy=TRUE
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:
# gst-launch filesrc location=./davincieffect.264 ! TIViddec2 engineName=decode codecName=h264dec numOutputBufs=18 ! queue max-size-buffers=2 max-size-time=0 max-size-bytes=0 ! TIDmaiVideoSink displayStd=v4l2 displayDevice=/dev/video2 videoStd=720P_60 videoOutput=COMPONENT resizer=FALSE accelFrameCopy=TRUE
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!!
|Item ID||Associated Item||Comment|
|No Associated Items Found|