• Not Answered

DM365 H.264 decoding error: "could not decode stream" / "Unable to decode frame with timestamp"

Hi,

 

I'm using a DM365 with TI's GStreamer plugin on DM365. I've managed to verify that the video output works correctly and that my GStreamer compile works by running the following pipeline:

gst-launch videotestsrc ! TIDmaiVideoSink videoOutput=DVI videoStd=720P_60 accelFrameCopy=true

However, when comes the time to start decoding content using the H.264 codec I get nothing on the screen. I do get errors in the gstreamer output but I've been unable to figure out the cause. Can somebody point me in the right direction please?

Command I run:

CE_DEBUG=3 gst-launch --gst-debug=TI*:9 filesrc location=/mnt/tron-tlr1_h480p.mov ! qtdemux name=demux demux.video_00 ! queue ! dmaidec_h264 ! TIDmaiVideoSink videoOutput=DVI videoStd=720P_60 accelFrameCopy=true

Output (trunkated to provide relevant sections, error is in bold):
[...]
0:00:01.913460180  1020    0x5f748 LOG            TISupportH264 gsttisupport_h264.c:547:gst_h264_sps_pps_calBufSize: sps=1
0:00:01.914322180  1020    0x5f748 LOG            TISupportH264 gsttisupport_h264.c:571:gst_h264_sps_pps_calBufSize: pps=1
0:00:01.915484597  1020    0x5f748 LOG            TISupportH264 gsttisupport_h264.c:483:gst_h264_get_sps_pps_data:   - sps[0]=20
0:00:01.916390847  1020    0x5f748 LOG            TISupportH264 gsttisupport_h264.c:500:gst_h264_get_sps_pps_data:   - pps[0]=4
0:00:01.917362805  1020    0x5f748 DEBUG          TISupportH264 gsttisupport_h264.c:326:h264_init: Parser initialized
0:00:01.918258930  1020    0x5f748 DEBUG              TIDmaidec gsttidmaidec.c:915:gst_tidmaidec_configure_codec:<dmaidec_h2640> creating input circular buffer
@2,134,209us: [+0 T:0x4186f490 S:0x4186eb34] OM - Memory_alloc> Enter(0x6d500)
@2,134,461us: [+0 T:0x4186f490 S:0x4186eaec] OM - Memory_contigAlloc> Enter(size=447744, align=-1, cached=FALSE, heap=FALSE)
@2,134,922us: [+4 T:0x4186f490 S:0x4186eaec] OM - Memory_contigAlloc> CMEM_alloc(447744) = 0x44427000.
@2,135,240us: [+4 T:0x4186f490 S:0x4186eaec] OM - Memory_contigAlloc> CMEM_getPhys(0x44427000) = 0x84d05000.
@2,135,457us: [+1 T:0x4186f490 S:0x4186eaa4] OM - Memory__addContigBuf> Enter(virtAddr=0x44427000, size=447744, physAddr=0x84d05000)
@2,135,679us: [+1 T:0x4186f490 S:0x4186eaa4] OM - Memory__addContigBuf> creating new contigBuf object
@2,135,862us: [+0 T:0x4186f490 S:0x4186ea8c] OM - Memory_alloc> Enter(0x10)
@2,136,068us: [+0 T:0x4186f490 S:0x4186ea8c] OM - Memory_alloc> return (0x917f8)
@2,136,426us: [+1 T:0x4186f490 S:0x4186eaa4] OM - Memory__addContigBuf> returning: cb->phys=0x84d05000, cb->size=447744, cb->virt=0x44427000
@2,136,654us: [+0 T:0x4186f490 S:0x4186eaec] OM - Memory_contigAlloc> return (0x44427000)
@2,136,851us: [+0 T:0x4186f490 S:0x4186eb34] OM - Memory_alloc> return (0x44427000)
@2,137,043us: [+0 T:0x4186f490 S:0x4186eb14] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x44427000, size=4)
@2,137,232us: [+1 T:0x4186f490 S:0x4186eb14] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x44427000, size=4)
@2,137,419us: [+1 T:0x4186f490 S:0x4186eb14] OM - Memory__getPhysicalAddress> found in cb(Sc=0x44427000, Ec=0x44494500, Ss=0x44427000, Es=0x44427004, PSc=0x84d05000)
@2,137,611us: [+1 T:0x4186f490 S:0x4186eb14] OM - Memory__getPhysicalAddress> returning physAddr=0x84d05000
@2,137,784us: [+0 T:0x4186f490 S:0x4186eb14] OM - Memory_getBufferPhysicalAddress> return (0x84d05000)
@2,137,972us: [+2 T:0x4186f490 S:0x4186eb4c] ti.sdo.dmai - [Buffer] Alloc Buffer of size 447744 at 0x44427000 (0x84d05000 phys)
0:00:01.923324263  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:934:gst_tidmaidec_configure_codec:<dmaidec_h2640> Leave
0:00:01.924763805  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1446:gstti_dmaidec_circ_buffer_push:<dmaidec_h2640> Entry
0:00:01.925928055  1020    0x5f748 DEBUG              TIDmaidec gsttidmaidec.c:1462:gstti_dmaidec_circ_buffer_push:<dmaidec_h2640> Pushing a buffer of size 33328, circbuf is currently 0
0:00:01.927023347  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1402:validate_circBuf_space:<dmaidec_h2640> Entry
0:00:01.927942139  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1430:validate_circBuf_space:<dmaidec_h2640> Leave
0:00:01.929464597  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1505:gstti_dmaidec_circ_buffer_push:<dmaidec_h2640> Leave
0:00:01.930476513  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1525:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Entry
@2,146,534us: [+0 T:0x4186f490 S:0x4186ead4] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x44427000, size=4)
@2,146,798us: [+1 T:0x4186f490 S:0x4186ead4] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x44427000, size=4)
@2,147,006us: [+1 T:0x4186f490 S:0x4186ead4] OM - Memory__getPhysicalAddress> found in cb(Sc=0x44427000, Ec=0x44494500, Ss=0x44427000, Es=0x44427004, PSc=0x84d05000)
@2,147,212us: [+1 T:0x4186f490 S:0x4186ead4] OM - Memory__getPhysicalAddress> returning physAddr=0x84d05000
@2,147,388us: [+0 T:0x4186f490 S:0x4186ead4] OM - Memory_getBufferPhysicalAddress> return (0x84d05000)
@2,147,574us: [+2 T:0x4186f490 S:0x4186eb0c] ti.sdo.dmai - [Buffer] Set user pointer 0x44427000 (physical 0x84d05000)
(gst-launch-0.10:1020): GStreamer-CRITICAL **: gst_debug_log_valist: assertion `category != NULL' failed
0:00:01.934105222  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:88:gst_tidmaibuffertransport_get_type: initialized get_type
0:00:01.935193889  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:104:gst_tidmaibuffertransport_class_init: begin class_init
0:00:01.936144680  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:110:gst_tidmaibuffertransport_class_init: end class_init
0:00:01.937206680  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:210:gst_tidmaibuffertransport_new: end new
0:00:01.938184014  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1598:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Leave
0:00:01.939125347  1020    0x5f748 DEBUG              TIDmaidec gsttidmaidec.c:1600:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Returning a buffer 0x546d0
0:00:01.940117764  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1679:decode:<dmaidec_h2640> Entry
0:00:01.941149305  1020    0x5f748 DEBUG              TIViddec2 gsttividdec2.c:225:gstti_viddec2_process: invoking the video decoder, with 33360 bytes (0x44427000, 0x44091000)
@2,157,134us: [+0 T:0x4186f490 S:0x4186e0e4] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_process> Enter (handle=0x7de60, inBufs=0x4186e234, outBufs=0x4186e228, inArgs=0x4186ea98, outArgs=0x4186e2f8)
@2,157,582us: [+5 T:0x4186f490 S:0x4186e0c4] CV - VISA_enter(visa=0x7de60): algHandle = 0x8efe8
@2,157,830us: [+0 T:0x4186f490 S:0x4186e0b4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x8efe8)
@2,158,046us: [+0 T:0x4186f490 S:0x4186e07c] ti.sdo.ce.osal.SemMP - Entered SemMP_pend> sem[0x68a30] timeout[0xffffffff]
@2,158,277us: [+0 T:0x4186f490 S:0x4186e07c] ti.sdo.ce.osal.SemMP - Leaving SemMP_pend> sem[0x68a30] status[0]
@2,158,516us: [+0 T:0x4186f490 S:0x4186e0c4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit
@2,189,079us: [+5 T:0x4186f490 S:0x4186e0cc] CV - VISA_exit(visa=0x7de60): algHandle = 0x8efe8
@2,189,367us: [+0 T:0x4186f490 S:0x4186e0bc] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x8efe8)
@2,189,610us: [+0 T:0x4186f490 S:0x4186e09c] ti.sdo.ce.osal.SemMP - Entered SemMP_post> sem[0x68a30]
@2,189,848us: [+0 T:0x4186f490 S:0x4186e09c] ti.sdo.ce.osal.SemMP - Leaving SemMP_post> sem[0x68a30]
@2,190,286us: [+0 T:0x4186f490 S:0x4186e0cc] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit
@2,190,522us: [+0 T:0x4186f490 S:0x4186e0e4] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_process> Exit (handle=0x7de60, retVal=0xffffffff)
@2,190,730us: [+2 T:0x4186f490 S:0x4186e134] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret -1 inId 0 inUse 0 consumed 33360
@2,190,941us: [+2 T:0x4186f490 S:0x4186e134] ti.sdo.dmai - [Vdec2] VIDDEC2_process() non-fatal error 0x44
0:00:01.976431972  1020    0x5f748 WARN               TIViddec2 gsttividdec2.c:239:gstti_viddec2_process:<dmaidec_h2640> warning: Unable to decode frame with timestamp 0:00:00.000000000
WARNING: from element /GstPipeline:pipeline0/dmaidec_h264:dmaidec_h2640: Could not decode stream.
Additional debug info:
gsttividdec2.c(239): gstti_viddec2_process (): /GstPipeline:pipeline0/dmaidec_h264:dmaidec_h2640:
Unable to decode frame with timestamp 0:00:00.000000000
0:00:01.983495972  1020    0x5f748 DEBUG              TIViddec2 gsttividdec2.c:243:gstti_viddec2_process: Freeing buffer because of bit error on the stream
0:00:01.984464597  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1353:gstti_dmaidec_circ_buffer_flush:<dmaidec_h2640> Entry
0:00:01.985539514  1020    0x5f748 DEBUG              TIDmaidec gsttidmaidec.c:1377:gstti_dmaidec_circ_buffer_flush:<dmaidec_h2640> Flushing 33360 bytes from the circular buffer, 0 remains
0:00:01.986563222  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1380:gstti_dmaidec_circ_buffer_flush:<dmaidec_h2640> Leave
0:00:01.987482597  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:138:gst_tidmaibuffertransport_finalize: begin finalize
0:00:01.988319014  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:170:gst_tidmaibuffertransport_finalize: calling Buffer_delete()
0:00:01.989177014  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:179:gst_tidmaibuffertransport_finalize: end finalize
0:00:01.990197430  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1525:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Entry
0:00:01.991163763  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1598:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Leave
0:00:01.992063055  1020    0x5f748 DEBUG              TIDmaidec gsttidmaidec.c:1600:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Returning a buffer (nil)
0:00:01.993020763  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:2047:gst_tidmaidec_chain:<dmaidec_h2640> Leave
0:00:01.995314680  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1982:gst_tidmaidec_chain:<dmaidec_h2640> Entry
0:00:01.996287389  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1446:gstti_dmaidec_circ_buffer_push:<dmaidec_h2640> Entry
0:00:01.997233305  1020    0x5f748 DEBUG              TIDmaidec gsttidmaidec.c:1462:gstti_dmaidec_circ_buffer_push:<dmaidec_h2640> Pushing a buffer of size 212, circbuf is currently 0
0:00:01.998460930  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1402:validate_circBuf_space:<dmaidec_h2640> Entry
0:00:01.999395138  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1430:validate_circBuf_space:<dmaidec_h2640> Leave
0:00:02.000406388  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1505:gstti_dmaidec_circ_buffer_push:<dmaidec_h2640> Leave
0:00:02.001317055  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1525:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Entry
@2,217,257us: [+0 T:0x4186f490 S:0x4186ead4] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x44427000, size=4)
@2,217,537us: [+1 T:0x4186f490 S:0x4186ead4] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x44427000, size=4)
@2,217,750us: [+1 T:0x4186f490 S:0x4186ead4] OM - Memory__getPhysicalAddress> found in cb(Sc=0x44427000, Ec=0x44494500, Ss=0x44427000, Es=0x44427004, PSc=0x84d05000)
@2,217,954us: [+1 T:0x4186f490 S:0x4186ead4] OM - Memory__getPhysicalAddress> returning physAddr=0x84d05000
@2,218,223us: [+0 T:0x4186f490 S:0x4186ead4] OM - Memory_getBufferPhysicalAddress> return (0x84d05000)
@2,218,436us: [+2 T:0x4186f490 S:0x4186eb0c] ti.sdo.dmai - [Buffer] Set user pointer 0x44427000 (physical 0x84d05000)
0:00:02.003687263  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:192:gst_tidmaibuffertransport_new: begin new
0:00:02.004590971  1020    0x5f748 LOG     TIDmaiBufferTransport gsttidmaibuffertransport.c:210:gst_tidmaibuffertransport_new: end new
0:00:02.008793555  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1598:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Leave
0:00:02.009717847  1020    0x5f748 DEBUG              TIDmaidec gsttidmaidec.c:1600:__gstti_dmaidec_circ_buffer_peek:<dmaidec_h2640> Returning a buffer 0x54740
0:00:02.010674638  1020    0x5f748 LOG                TIDmaidec gsttidmaidec.c:1679:decode:<dmaidec_h2640> Entry
0:00:02.011666263  1020    0x5f748 DEBUG              TIViddec2 gsttividdec2.c:225:gstti_viddec2_process: invoking the video decoder, with 244 bytes (0x44427000, 0x44091000)
@2,227,676us: [+0 T:0x4186f490 S:0x4186e0e4] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_process> Enter (handle=0x7de60, inBufs=0x4186e234, outBufs=0x4186e228, inArgs=0x4186ea98, outArgs=0x4186e2f8)
@2,227,964us: [+5 T:0x4186f490 S:0x4186e0c4] CV - VISA_enter(visa=0x7de60): algHandle = 0x8efe8
@2,228,178us: [+0 T:0x4186f490 S:0x4186e0b4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x8efe8)
@2,228,382us: [+0 T:0x4186f490 S:0x4186e07c] ti.sdo.ce.osal.SemMP - Entered SemMP_pend> sem[0x68a30] timeout[0xffffffff]
@2,228,611us: [+0 T:0x4186f490 S:0x4186e07c] ti.sdo.ce.osal.SemMP - Leaving SemMP_pend> sem[0x68a30] status[0]
@2,228,842us: [+0 T:0x4186f490 S:0x4186e0c4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit
@2,240,213us: [+5 T:0x4186f490 S:0x4186e0cc] CV - VISA_exit(visa=0x7de60): algHandle = 0x8efe8
@2,240,506us: [+0 T:0x4186f490 S:0x4186e0bc] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x8efe8)
@2,240,878us: [+0 T:0x4186f490 S:0x4186e09c] ti.sdo.ce.osal.SemMP - Entered SemMP_post> sem[0x68a30]
@2,241,145us: [+0 T:0x4186f490 S:0x4186e09c] ti.sdo.ce.osal.SemMP - Leaving SemMP_post> sem[0x68a30]
@2,241,357us: [+0 T:0x4186f490 S:0x4186e0cc] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit
@2,241,547us: [+0 T:0x4186f490 S:0x4186e0e4] ti.sdo.ce.video2.VIDDEC2 - VIDDEC2_process> Exit (handle=0x7de60, retVal=0xffffffff)
@2,241,753us: [+2 T:0x4186f490 S:0x4186e134] ti.sdo.dmai - [Vdec2] VIDDEC2_process() ret -1 inId 0 inUse 0 consumed 244
@2,241,962us: [+2 T:0x4186f490 S:0x4186e134] ti.sdo.dmai - [Vdec2] VIDDEC2_process() non-fatal error 0x44
0:00:02.027444055  1020    0x5f748 WARN               TIViddec2 gsttividdec2.c:239:gstti_viddec2_process:<dmaidec_h2640> warning: Unable to decode frame with timestamp 0:00:00.083416750
WARNING: from element /GstPipeline:pipeline0/dmaidec_h264:dmaidec_h2640: Could not decode stream.
Additional debug info:
gsttividdec2.c(239): gstti_viddec2_process (): /GstPipeline:pipeline0/dmaidec_h264:dmaidec_h2640:
[...]
My kernel boot arguments are as follow:
console=ttyS0,115200n8 mem=54M root=/dev/ram0 rw initrd=0x82000000,8M earlyprintk=ttyS0,115200n8 davinci_enc_mngr.ch0_output=DVI davinci_enc_mngr.ch0_mode="720P-60" video=davincifb:vid0=OFF:vid1=OFF:osd0=OFF davinci_display.cont2_bufsize=6291456 vpfe_capture.cont_bufoffset=6291456 vpfe_capture.cont_bufsize=6291456
And the cmem is loaded as follow:
modprobe cmemk phys_start=0x84200000 phys_end=0x88000000 pools=1x524288,1x81920,2x8192,6x4096,8x96,64x56,1x2938880,4x675840,1x75840,4x1548288,1x33077952,15x1253376
This is all built using DVSDK 3.10.00.19.
Thank you in advance for any assistance you can provide,

Pierre-Luc

18 Replies

  • Pierre,

    If I see the error code, 0x44 , it means unaligned picture buffer. (Please see section 3.6 of decoder user guide for error codes). Can you please check  if the output buffer being sent to codec is is 8 bytes aligned?

    regards

    Yashwant

  • In reply to Yashwant Dutt:

    Yashwant,

    After posting I've figured out what 0x44 meant. However I've not yet figured out where the picture buffer is allocated or who's actually allocating it. Any pointers on which specific buffer you are referring to and how it gets allocated would greatly help me.

    I'll of course keep digging into this and will post here if I find out anything.

    Thanks,

    Pierre-Luc

  • In reply to Pierre-Luc Simard:

    Pierre,

    Could you tell me where you got the gstreamer plugins from. This doesn't look like the standard set, instead it looks like it is from some development branch.

    COuld you try the code at -

    http://gstreamer.ti.com -> click on SVN at the left of the page and checkout the trunk version.

     

    - Prashant.

  • In reply to Prashant N:

    Pershant,

    Thanks for your suggestion. I did try the trunk of TI's gstreamer plugin SVN repo and I had issues with it. It was a couple of weeks ago and I do not have the log handy to show what exactly the problem was. It's by looking at the Makefile for the plugin in RidgeRun SDK for the leopardboard that I came to use the DDOMPE branch from TI's SVN repo that did provide something that came closer to working. I'll rebuild using the trunk and post the result here.

    Thanks again,

    Pierre-Luc

     

  • In reply to Pierre-Luc Simard:

    Moving to the trunk of the SVN repository from gstreamer.ti.com did provide positive result. Now video playback does work but decodes at about 1 or 2 frame per second and also displays artifacts on the screen. Here are the pipeline I use and the result:

    gst-launch videotestsrc !  TIDmaiVideoSink videoOutput=DVI videoStd=720P_60 accelFrameCopy=true

    Correct test pattern at good framerate.

     

    gst-launch videotestsrc ! video/x-raw-yuv, format=\(fourcc\)UYVY, width=720, height=480 ! TIDmaiVideoSink videoOutput=DVI videoStd=720P_60 accelFrameCopy=true

    Test pattern at about one frame per second.

    gst-launch filesrc location=/mnt/trailer_720p.mov ! qtdemux name=demux demux.video_00 ! queue ! TIViddec2 numOutputBufs=18 ! TIDmaiVideoSink videoOutput=DVI videoStd=720P_60 accelFrameCopy=true

    and

    gst-launch filesrc location=/mnt/trailer_720p.mov ! qtdemux name=demux demux.video_00 ! queue ! TIViddec2 numOutputBufs=18 ! queue ! TIDmaiVideoSink videoOutput=DVI videoStd=720P_60 accelFrameCopy=true

    and

    gst-launch filesrc location=/mnt/trailer_720p.mov ! qtdemux name=demux demux.video_00 ! queue ! TIViddec2 numOutputBufs=18 ! TIDmaiVideoSink videoOutput=COMPONENT videoStd=720P_60 accelFrameCopy=true

    Give the following warning and provides the video output described a the beginning of this message
    WARNING: from element /GstPipeline:pipeline0/GstTIDmaiVideoSink:tidmaivideosink0: A lot of buffers are being dropped.
    Additional debug info:
    gstbasesink.c(2572): gst_base_sink_is_too_late (): /GstPipeline:pipeline0/GstTIDmaiVideoSink:tidmaivideosink0:
    There may be a timestamping problem, or this computer is too slow.
    I'm affraid I do not know what to try next. Any suggestion is greatly appreciated.

     

  • In reply to Pierre-Luc Simard:

    Pierre,

    Seems like you are trying running gst pipeline on DVSDK 3.10, is this correct ? If so, may i recommend you two methods to get zero copy support on DM365 to boost the performance.

    1) Switch to using DVSDK 4.0 GA release [1] - gst-ti trunk has been recently updated for zero copy support and DVSDK 4.0 comes prebuilt with gstreamer-ti plugin. This is most easiest path for you to evaluate your use case before migrating your application to DVSDK 4.0.  I just ran the below pipeline for your use case and don't see any frame drops - i can play big buck bunny at 30fps.

    gst-launch filesrc location=trailer_720p.mov ! qtdemux name=demux demux.video_00 ! queue ! TIViddec2 padAllocOutbufs=TRUE ! TIDmaiVideoSink videoStd=720P_60 videoOutput=component numBufs=5 hideOSD=true max-lateness=300000000 render-delay=300000000 -v

    [1] http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/latest/index_FDS.html

    Also Software Developers Guide in DVSDK has pipeline for mp4 (h264 + aac) decode.

    2)  If you want to use DVSDK 3.10, then do these steps

       a)  Download the kernel from arago staging branch, see special note section in README.txt https://gstreamer.ti.com/gf/project/gstreamer_ti/scmsvn/?action=browse&path=/*checkout*/trunk/gstreamer_ti/README.TXT. This will ask you to clone a branch which contains the gstreamer specific patches.

       b) Follow the recommendation from https://gstreamer.ti.com/gf/project/gstreamer_ti/tracker/?action=TrackerItemEdit&tracker_item_id=1208&start=175 to apply gst-ti plugins and dmai patches. Also pay special attention in kernel boot args for DM365 in gstreamer README.txt.

    I would recommend #1 option at this point of time.

    Thanks

    Brijesh

     

     

     

  • In reply to Brijesh Singh:

    Brijesh,

    Thanks for the quick answer. I will upgrade to the DVSDK 4.0 and will post the result here. However do you know if DVSDK 4.0 comes in .tar.gz format instead of the self extracting installer (.bin)? The self installer makes it a lot harder to remove script the install of the all the dev tools require to build the platform.

    Thanks again,

    Pierre-Luc

  • In reply to Pierre-Luc Simard:

    Pierre-Luc,

    Going forward, we will not have .tar.gz format for (DV)SDK installers. Please download .bin file for your platform and this version of DVSDK comes with dev tools required for builds. If this is the first time you are using DVSDK 4.0, then i would recommend reading Software Developers Guide to get more familiar with DVSDK. As stated in SDG, run the setup script to setup the environment on your ubuntu host machine. And it has instruction for how to compile GStreamer or Qt applications.

    Thanks

    Brijesh 

  • In reply to Brijesh Singh:

    Brijesh,

    Moving to DVSDK 4.00 brings its own lot of problems. Still I've managed to rebuilded everything using DVSDK 4.00.00.22 but now cmemk refuses to allocate memory.

    It loads fine:

    modprobe cmemk phys_start=0x83c00000 phys_end=0x88000000 pools=1x16539648,1x4841472,4x1843200,14x1646592,1x282624,1x176128,1x147456,1x69632,1x61440,1x32768,2x20480,1x16384,1x12288,4x8192,69x4096,11x1645056

     

    outputs:

     

    [  523.540000] CMEMK module: built on Nov  2 2010 at 11:25:32

    [  523.560000]   Reference Linux version 2.6.32

    [  523.560000]   File /mnt/hgfs/user/Projects/ng100/buildroot/output/build/ti-dvsdk-dm365-4.00.00.22/linuxutils_2_25_05_11/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.c

    [  523.600000] allocated heap buffer 0xc5000000 of size 0x38000

    [  523.630000] cmemk initialized

    But as soon as I run a gst-pipeline I get the following:

     

    [  570.030000] CMEMK Error: Failed to find a pool which fits 28672

    [  570.090000] CMEMK Error: get_phys: Unable to find phys addr for 0x00000000

    [  570.100000] CMEMK Error: get_phys: get_user_pages() failed: -14

    [  570.110000] CMEMK Error: GETPHYS: Failed to convert virtual 0x0 to physical.

    [  570.120000] CMEMK Error: get_phys: Unable to find phys addr for 0x00000000

    [  570.120000] CMEMK Error: get_phys: get_user_pages() failed: -14

    [  570.130000] CMEMK Error: FREE: Failed to convert virtual 0x0 to physical

    pipeline I ran:
    gst-launch filesrc location=/mnt/trailer_720p.mov ! qtdemux name=demux demux.video_00 ! queue ! TIViddec2 numOutputBufs=18 ! TIDmaiVideoSink videoOutput=DVI videoStd=720P_60 accelFrameCopy=true
    The GStreamer output gives:
    CMEM Error: getPool: Failed to get a pool fitting a size 28672
    CMEM Error: getPhys: Failed to get physical address of 0
    CMEM Error: free: failed to free 0
    Setting pipeline to PAUSED ...
    Pipeline is PREROLLING ...
    ERROR: from element /GstPipeline:pipeline0/GstTIViddec2:tividdec20: failed to create video decoder: h264dec
    Additional debug info:
    gsttividdec2.c(1360): gst_tividdec2_codec_start (): /GstPipeline:pipeline0/GstTIViddec2:tividdec20
    ERROR: pipeline doesn't want to preroll.
    Setting pipeline to NULL ...
    Freeing pipeline ...
    I'm a bit surprised as I would not have expected cmem to change from DVSDK 3.10 to DVSDK 4.0. Any idea of what could have caused the issue? 
    Thanks,

     

  • In reply to Pierre-Luc Simard:

    HI Pierre-Luc,

    Have you run the loadmodules.sh file in /usr/share/ti/gst/dm365 on the target filesystem prior to running your pipeline, as described in the Software Developers' Guide? Make sure you do (as opposed to running your own loadmodules.sh), since DVSDK 4.00.00.22 comes with new platinum H264 codecs which have different CMEM  memory requirements then before, and require an extra buffer of size 28672 in a separate pool to function correctly.

    Best regards,

    Vincent