TI E2E Community
DM365 H.264 decoding error: "could not decode stream" / "Unable to decode frame with timestamp"
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
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?
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.
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.
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.
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
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
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
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  - 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
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 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.
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.
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
[ 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
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.
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:
I am correct? in assuming this.
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.
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?
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.
To answer your questions:
1. Have you tried playing demo pipeline listed in SDG ? Yes I did. The result are as follow:
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 bufferAdditional 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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.