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.

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

  • 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

  • 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

  • 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.

  • 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

     

  • 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.

     

  • 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

     

     

     

  • 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

  • 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 

  • 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,

     

  • 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

  • Hello Vincent,

    DVSDK 4.00.00.22 does not come with the loadmodule.sh you're refering to. I think you are refering to the loadmodule.sh that comes from the Arago Project. In my case I think you are refering to this file specifically:

    http://arago-project.org/git/?p=arago-oe-dev.git;a=blob;f=recipes/ti/gstreamer-ti/dm365-evm/loadmodules.sh;h=c70bee1e3088603da2d8523958ef1119c0da3afc;hb=HEAD

    I am correct? in assuming this.

     

     

  • Hi Pierre-Luc,

    A copy of the file should be there on the target file system in DVSDK 4.00.00.22. If you don't have it, there may be something wrong in your installation. I'd suggest you move your existing targetfs directory to a safe place, and rerun the setup.sh script according to the Software Developers' Guide (SDG). It will reextract the file system and you can select to NFS mount it. On your host you should have a file named 'loadmodules.sh' in $(HOME}/targetfs/usr/share/ti/gst/dm365/ assuming you are placing the file system under $(HOME). This corresponds to /usr/share/ti/gst/dm365 on your target.

    Best regards,

    Vincent

  • Brijesh,

    I did manage to get playback going with the DVSDK 4.00 and the correct CMEM setting. The good news is that the video playback quality improved. However frames still get skipped and there's still an artifact on the screen. It's about 20 pixel wide on the entire left side of the screen. I've placed online a short video of what the output looks like so you can see what I'm talking about. 

    Of course adding debug log slows down the playback so I'm not entirely sure what they would show.

    Any advice on how to proceed from there?

    Regards,

    Pierre-Luc

     

     

  • Pierre-Luc,

    Have you tried playing demo pipeline listed in SDG ? DVSDK comes with one .mp4 file, do you see the similar artifacts on the screen?  I don't remember seeing any artifact while playing BBB trailer or even Davinci clip, but i can try again on Monday to confirm this. Make sure you are using the correct boot args. You can also use gstreamer.ti.com community forums to get helps from other folks.  

    Do you see this issue with BBB clip or any clips ? In addition to this, may be you could try dumping output of viddec2 in YUV file and verify whether its decoder issue vs sink. 

    Thanks

    Brijesh 

  • Brijesh,

    To answer your questions:

    1. Have you tried playing demo pipeline listed in SDG ? Yes I did. The result are as follow:

    • MPEG-4 video decode to 720P: Plays almost correctly. It skips a few times but does not present any artifact.
    • H.264 video decode to 720P: Skips more than the MPEG-4 stream but does not present artifacts
    • .MP4 file with H264 video and AAC audio content: Displays only a black screen. Since it's the only pipeline with audio I've tried I'm guessing the issue might be linked to it. Playing the same pipeline without the audio plays but skips a lot more than the straight H.264 file.

    2. DVSDK comes with one .mp4 file, do you see the similar artifacts on the screen? No There's no artifact with that file.

    3. Make sure you are using the correct boot args. My current boot args are as follow:

    "console=ttyS0,115200n8 mem=60M root=/dev/ram0 rw initrd=0x82000000,9M 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"

    I did not see any reference to boot args in the SDG. Where can I find the "correct" boot args?

    4. Do you see this issue with BBB clip or any clips ? Yes. I've also try a number of 720P H.264 videos from trailers.apple.com. They all refuse to play with the following error message:

    ERROR: from element /GstPipeline:pipeline0/GstTIDmaiVideoSink:tidmaivideosink0: Failed to put display buffer
    Additional debug info:
    gsttidmaivideosink.c(1649): gst_tidmaivideosink_render (): /GstPipeline:pipeline0/GstTIDmaiVideoSink:tidmaivideosink0

    This is new to me as with DVSDK 3.10 I could get any video to play (all be it badly). Now if the video is not of the exact screen resolution it simply refuses to play. I have no idea why this is. Any suggestions?

    5. In addition to this, may be you could try dumping output of viddec2 in YUV file and verify whether its decoder issue vs sink. 

    I've been unable to do it. For some reason the playback of yuv dump never display correctly on the DM365. I will try to get to the bottom of the issue and post any results I have here. However, come monday, if you can post specific pipeline to accomplish this on the DM365 it would be greatly appreciated.

    Cheers,

    Pierre-Luc

  • Brijesh,

    I must correct some of my answers regarding the visibility of the artifact. The artifact on the left side of the screen does appear in all playback. It is however less visible since a large portion of the video is white.

    1. Have you tried playing demo pipeline listed in SDG ? Yes I did. The result are as follow:

    • MPEG-4 video decode to 720P: Plays almost correctly. It skips a few times and DOES present the artifact  on the left of the screen. 
    • H.264 video decode to 720P: Skips more than the MPEG-4 stream and  DOES present the artifact on the left of the screen
    • .MP4 file with H264 video and AAC audio content: Changed board and now getting playback very similar to H.264 video only playback but with one exception. At some point in the playback (random moment) the playback freezes.

    2. DVSDK comes with one .mp4 file, do you see the similar artifacts on the screen? YES there's is an artifact with all files. The Artifact is visible on both the DVI and COMPONENTS output.

    Cheers,

    Pierre-Luc

  • Pierre-Luc,

    I just tried playing davinci effect and BBB 720P clip and don't see similar artifacts, are you using DM365 EVM or custom board ?  Can you please follow the SDG (at least once) to make sure you have ran setup.sh script as explained. This script will generate correct bootargs.

    My bootargs looks like this:

    console=ttyS0,115200n8 rw mem=48M video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K dm365_imp.oper_mode=0 davinci_capture.device_type=4 davinci_display.cont2_bufsize=6291456  vpfe_capture.cont_bufoffset=6291456 vpfe_capture.cont_bufsize=6291456 davinci_enc_mngr.ch0_output=COMPONENT davinci_enc_mngr.ch0_mode=480P-60  root=/dev/mmcblk0p2 rootwait ip=off

    and i ran this pipeline to play 720P video

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

    On your other comment about not able to play any other movie:

    Note that the above pipeline is optimized for 720P playback, and zero copy is support for only 720P resolution. If you clip resolution is less than 720P then paddAlloc will not work. And in that case you should remove padAllocOutbufs=true property. Can you please make use of gstreamer.ti.com forums to get faster response on gst-ti releated questions.

    Thanks

    Brijesh

  • Brijesh,

     

    Thanks for getting back to me. Following your advice I posted on the forum on gstreamer.ti.com. You can find the post here:

    https://gstreamer.ti.com/gf/project/gstreamer_ti/forum/?action=ForumBrowse&_forum_action=ForumMessageBrowse&thread_id=3910&forum_id=187

    I'm a bit stumped that it works on your end and not on mine. Can you explain why you use mem=48M? What's your CMEM configuration? 

    Based on your reply I've tried the following:

    'console=ttyS0,115200n8 initrd=0x82000000,9M mem=60M video=davincifb:vid0=OFF:vid1=OFF:osd0=OFF dm365_imp.oper_mode=0 davinci_capture.device_type=4 davinci_display.cont2_bufsize=6291456 vpfe_capture.cont_bufoffset=6291456 vpfe_capture.cont_bufsize=6291456 davinci_enc_mngr.ch0_output=DVI davinci_enc_mngr.ch0_mode="720P-60"'

    The main differences between your init and mine are:

    1. I'm booting from a RAM disk stored in NAND flash and you are booting from the MMC

    2. You're allocating 48M to linux and I'm allocating 60M. 

    As a reference I'm using the following CMEM configuration:

    modprobe cmemk phys_start=0x83C00000 phys_end=0x88000000 pools=1x16539648,1x4841472,4x1843200,14x1646592,1x282624,1x176128,1x147456,1x69632,1x61440,1x32768,2x20480,1x16384,1x12288,4x8192,69x4096 allowOverlap=1 phys_start_1=0x00001000 phys_end_1=0x00008000 pools_1=1x28672 

    Thanks,
    Pierre-Luc