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

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

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

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

[  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

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.

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

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