• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 311 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L138 H264 Decode Freeze with framerate supplied:

Michael Williamson
Expert 1975 points
Other Parts Discussed in Thread: OMAP-L138

Hi,

We are using an OMAP-L138 to decode an H264 video stream that was encoded at 24 FPS.  When we run the stream with the following gstreamer sequence, it plays through, but the framerate is running faster than the encoded video (see dmaiperf text following gst command).  If we modify the gstreamer command to add a "framerate=24/1" arguement to the TIViddec2 element, we get the right framerate, but about halfway through the stream the display locks up, though the pipeline seems to run through completion.  It always locks at the same point in the video and is quite reproducible.  Any suggestions?  

It also seems that the framerate should be correctly time-synced without any hints passed via command line.  Is there something that needs to be done to properly sync the codec engine time?

-Mike

-----------------------------------

#!/bin/sh

gst-launch filesrc location=$1 ! qtdemux name=demux demux.video_00 ! typefind ! queue ! TIViddec2 ! dmaiperf print-arm-load=TRUE engine-name=codecServer ! TIC6xColorspace engineName=codecServer ! queue ! tidisplaysink2 -v video-standard=auto display-output=LCD mmap-buffer=true

(dmaiperf output)
Timestamp: 7:15:40.963050454; bps: 11933067; fps: 25; CPU: 100; DSP: 82; mem_seg: DDR2; base: 0xc33c56e0; size: 0x20000; maxblocklen: 0x13058; used: 0xcfa8; mem_seg: DDRALGHEAP; base: 0xc3600000; size: 0xa00000; maxblocklen: 0x418400; used: 0x5e72d8; mem_seg: IRAM; base: 0x11800000; size: 0x20000; maxblocklen: 0x10000; used: 0x10000; mem_seg: L3_CBA_RAM; base: 0x80000000; size: 0x10000; maxblocklen: 0x10000; used: 0x0; 
INFO:
Timestamp: 7:15:41.969770914; bps: 13283499; fps: 28; CPU: 55; DSP: 86; mem_seg: DDR2; base: 0xc33c56e0; size: 0x20000; maxblocklen: 0x13058; used: 0xcfa8; mem_seg: DDRALGHEAP; base: 0xc3600000; size: 0xa00000; maxblocklen: 0x418400; used: 0x5e72d8; mem_seg: IRAM; base: 0x11800000; size: 0x20000; maxblocklen: 0x10000; used: 0x10000; mem_seg: L3_CBA_RAM; base: 0x80000000; size: 0x10000; maxblocklen: 0x10000; used: 0x0; 
INFO:
Timestamp: 7:15:43.001367455; bps: 12514451; fps: 27; CPU: 14; DSP: 87; mem_seg: DDR2; base: 0xc33c56e0; size: 0x20000; maxblocklen: 0x13058; used: 0xcfa8; mem_seg: DDRALGHEAP; base: 0xc3600000; size: 0xa00000; maxblocklen: 0x418400; used: 0x5e72d8; mem_seg: IRAM; base: 0x11800000; size: 0x20000; maxblocklen: 0x10000; used: 0x10000; mem_seg: L3_CBA_RAM; base: 0x80000000; size: 0x10000; maxblocklen: 0x10000; used: 0x0; 
INFO:
-------------------------------
modified gstreamer line

#!/bin/sh

 

gst-launch filesrc location=$1 ! qtdemux name=demux demux.video_00 ! typefind ! queue ! TIViddec2 framerate=24/1 ! dmaiperf print-arm-load=TRUE engine-name=codecServer ! TIC6xColorspace engineName=codecServer ! queue ! tidisplaysink2 -v video-standard=auto display-output=LCD mmap-buffer=true

 

  • 0
    TI__Expert 5680 points

    Mike,

    I believe your original stream is not providing correct fps information to the qtdemux and because of that TIViddec2 is defaulting to 30fps. Typically demuxer provide all the metadata informations (like codec mime type, framerate, profiling etc) and if some of these information is missing then decoder defaults to its pre-defind value and using framerate property in decoder element can help you to correct the timestamp on outgoing buffer. But this change may cause problem because decoder only fixes the timestamp of outgoing buffer and does not communicate this correction to master gstreamer clock (which may be assuming different timestamp value) and can cause AV sync and lockup issue. In summary if demuxer is not providing timestamp information then there is something wrong with your encoded stream meta data information.  Run the below pipeline to verify if demuxer is providing the framerate info

    1) gst-launch filesrc location=sample.mp4 ! typefind ! qtdemux name=demux demux.video_00 ! typefind ! fakesink silent=true -v

    In cap negotation you must see the framerate info, if you don't get the framerate then we will end up default to 30000/1001. And you can correct this using two methods

    a) use parser element to see if it can extract the addition meta data from the stream. e.g

      gst-launch filesrc location=sample.mp4 ! typefind ! qtdemux name=demux demux.video_00 ! typefind ! h264parse ! fakesink silent=true -v

    b) Or use videorate element to set the new framerate information

     gst-launch filesrc location=sample.mp4 ! typefind ! qtdemux name=demux demux.video_00 ! typefind ! TIViddec2 ! videorate ! 'video/x-raw-yuv, framerate=24/1' ! fakesink silent=true -v

    HTH.

    Thanks

    Brijesh

  • 0 in reply to Brijesh Singh
    Expert 1975 points

    That was it!  Thanks Brijesh!

    -Mike