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.

Problems of GStreamer on DaVinci TMS320DM6446

Other Parts Discussed in Thread: TMS320DM6446

Dear All, I am trying to play some audio/video files on DaVinci TMS320DM6446 board using GStreamer released by TI (http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100). Now the project "GStreamer for DaVinci" is hosted and maintained by Z3 Technology, and I download and build the latest release of GStreamer for DaVinci TMS320DM6446 in http://www.z3technology.com/DaVinci%5FGStreamer. I am able to play MP3, MP2, WMA file with GStreamer successfully. But I can't play the following type of files successfully: AAC file: Three AAC files OK davincieffect.aac in DVSDK 1.3 failed. MP4 file with AAC audio: Use qtdemux to demux video and audio streams. Can't play video+audio and audio only Can play some MP4 files with video only, and play others will cause "can't find a pool fits 691202 bytes" error". I have tried changed the parameters of cmemk.ko module, but it seems not having enough memory. WMV file: Play video only will cause segmentation fault Can play audio only (WMA). I don't know why i can't play above type of files, but I guess there are two possible reasons: 1. use unsuitable files 2. In http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100, TI claimed that GStreamer for Davinci TMS320DM6446 is tested successfully on DVEVM 1.2, but we use DVSDK 1.3 to test. Therefore, would you please give me the suitable test clips or some supports for this issue. Thank You. Eric Wang.
  • Hi Eric,

    Unfortunately, GStreamer port is not part of the official DVSDK software release and hence it does not get updated or tested with every DVSDK release (although I agree this would be nice); it was ported to DVSDK 1.20 and offered as a potential solution for our customer base to consider (better than not offering any such solution at all).  Unfortunately, this means that the customer should take this solution (based on DVSDK 1.20) as-is and make any necessary adjustments (e.g. port to DVSDK 1.30) themselves.

    My recommendation would be to go back to DVSDK 1.2 and test with that and start slowly porting to DVSDK 1.30.  I believe the Linux drivers are quite different, hence this is a potential place to start debugging (or comparing DVSDK releases).

     

  • Hi Juan Gonzales,

    Thanks for your replying. I will try to test on DVSDK 1.20 first, and would you please give me the suitable test clips which have tested successfully on DVSDK 1.20 ?

     Thank You.

  • Juan,

    I agree with your statement that it would be nice. As a potential volume customer of devinci components, this is more than just an annoyance though.

    What is the officially sanctioned TI demux package? What are most customers doing about this?  This seems like such an essential piece of any media decoder that it would be under the TI/Montavista development and support window. Do you know if there is any plans to make it so?  Having such a widely used, and apparently essential,  package break because an underlying API was changed seems like a fatal flaw in the release process and highlights the problem with Open Source that the business unit managers lose sleep over.  Is there a TI plan to both help fix the Davinci G-Streamer, to pull it (or an equivalent package) under the Montavista umbrella, and then to better control releases that affect existing APIs so something like this will not happen again, or is this just an accepted part of the Linux world?

  • There are a few third parties that may be able to help with Gstreamer port for a fee.  Z3 technoligies (the host of this project under GIT) is probably a good starting point.  Please understand that this is an open source community supported project. 

    We at TI certainly are certainly interested in this type of feedback from our customers.  we are not a software house, but do understand the importance of software and do our best to engage our 3rd party network to meet those needs; however, we are always glad to receive feedback from customers to help us plan for better customer experience in the future.

  • Thanks Juan,  I have contacted Z3Technology and am in the process of contacting several other s in the TI ecosystem as well.  The few that do this, appear to have very expensive proprietary demux framework solutions. I will also have someone look closer to see if we could get the Gstreamer to work with the new APIs, or like your earlier suggestion, go back a level for now.

    If any other member of this forum has a suggestion for both a short-term tactical proof-of-concept solution that would allow us to to demo a MP4 or AVI as well as a longer term production solution, please leave a post or contact me. ... thanks

  •  I am trying to run video files using gstreamer-ti for
    da-vinci.   But i always encounter problem of VIDDEC_proces returing
    value of -1 saying the XDM_CORRUPTED DATA and XDM_UNSUPPORTEDPARAM.


             The Media files is avi format which contains mpeg4 video and
    mp3 audio files. The command i use ./test_AVI.sh ./<media>.avi command
    as in the Readme.txt .



           So i am asking the following questions


                    1) Is there any dependies on  demuxers  for
    seperating audio and video.

                    2) What  does XDM_CORRUPTEDDATA  means ? and how does
    the codec check the condtion ?

  • I take it you are using either DVSDK 1.20 or have appropriately ported to DVSDK 1.30; if so, then the next thing I would check in to make sure the DSP codec server I am using with GStreamer supports the MPEG4 video and MP3 audio.  I believe by default, the DVSDK DSP codec server supports AAC audio and not MP3 (but I am not familiar enough with GStreamer port to know if there is a separate DSP codec Server for it), hence this is a place to start looking.

  • I am also encountering porting issues with gstreamer and DVSDK 1.3.  Are there any solutions at this point or should I go back to DVSDK 1.2?

     

    Thanks

     

  • Hi all,

    I have been too busy to keep an eye on this thread and provide some more info :(

    Juan and all, there is a new gstreamer project for support most Davinci and OMAP parts that's is being developed by TI and RidgeRun and supported commercially by RidgeRun. Even if you don't need the commercial support, the project is a lot more alive than the other previous gstreamer ports and has more capabilities and way better performance. The releases are being formally tested by TI and RidgeRun with latest DVSDKs and for bugs or issues there is bug tracker and IRC channel available.

    The project is not official yet (meaning it hasn't been officially presented), but will save you guys some pain. Please visit gstreamer.ti.com

    Regards,

    Diego Dompe

    RidgeRun Engineering

  • Diego,

    Thank you for the update; we have been aware (and have suggested an upcoming new and improved gstreamer in some posts), but were waiting for the official launch.  From everything I have heard, this version should be much more robust and better quality as it was developed from the ground up with detail to software arcchitecture and compatibility with codec engine roadmap, as opposed to quick ports that are only compatiable with one DVSDK version (as we have seen with many gstreamer ports in the past).  I am really excited to have this solution for our customers

  • Hi everyone .

    I download the gst-ti-plugin-full-0.99.00.tar.gz from https://gstreamer.ti.com.

    But when I compile the ti_build , the compile failed with the following
    errors:
    ----------------------------------------------------------------------------
    libtool: link: link -dump -symbols
    .libs/libgstticodecplugin_la-gstticodecplugin.o
    .libs/libgstticodecplugin_la-gsttiauddec.o
    .libs/libgstticodecplugin_la-gsttiauddec1.o
    .libs/libgstticodecplugin_la-gsttividdec.o
    .libs/libgstticodecplugin_la-gsttividdec2.o
    .libs/libgstticodecplugin_la-gsttiimgenc1.o
    .libs/libgstticodecplugin_la-gsttiimgdec1.o
    .libs/libgstticodecplugin_la-gsttidmaibuffertransport.o
    .libs/libgstticodecplugin_la-gstticircbuffer.o
    .libs/libgstticodecplugin_la-gsttidmaivideosink.o
    .libs/libgstticodecplugin_la-gstticodecs.o
    .libs/libgstticodecplugin_la-gstticodecs_platform.o
    .libs/libgstticodecplugin_la-gsttiquicktime_aac.o
    .libs/libgstticodecplugin_la-gsttiquicktime_h264.o | | /bin/sed 's/.* //' |
    sort | uniq > .libs/libgstticodecplugin.exp
    ../libtool: eval: line 798: syntax error near unexpected token `|'
    ../libtool: eval: line 798: `link -dump -symbols
    .libs/libgstticodecplugin_la-gstticodecplugin.o
    .libs/libgstticodecplugin_la-gsttiauddec.o
    .libs/libgstticodecplugin_la-gsttiauddec1.o
    .libs/libgstticodecplugin_la-gsttividdec.o
    .libs/libgstticodecplugin_la-gsttividdec2.o
    .libs/libgstticodecplugin_la-gsttiimgenc1.o
    .libs/libgstticodecplugin_la-gsttiimgdec1.o
    .libs/libgstticodecplugin_la-gsttidmaibuffertransport.o
    .libs/libgstticodecplugin_la-gstticircbuffer.o
    .libs/libgstticodecplugin_la-gsttidmaivideosink.o
    .libs/libgstticodecplugin_la-gstticodecs.o
    .libs/libgstticodecplugin_la-gstticodecs_platform.o
    .libs/libgstticodecplugin_la-gsttiquicktime_aac.o
    .libs/libgstticodecplugin_la-gsttiquicktime_h264.o | | /bin/sed 's/.* //' |
    sort | uniq > .libs/libgstticodecplugin.exp'
    make[5]: *** [libgstticodecplugin.la] Error 1
    make[4]: *** [all] Error 2
    make[3]: *** [all-recursive] Error 1
    make[2]: *** [all] Error 2
    make[1]: *** [ticodecplugin] Error 2
    make: *** [ti_build] Error 2
    -----------------------------------------------------------------------------
    My board is DM355 EVM from spectrum.

    The following is my dvsdk version:

    dvsdk_1_30_01_41
    bios_5_31_08
    biosutils_1_00_02
    dsplink_140-05p1
    codec_engine_2_00_01
    biosutils_1_00_02
    cmem_2_00_01
    framework_components_2_00_01
    dm355_codecs_1_12_003
    xdais_6_00_01
    xdc_3_00_06
    dmai_1_16_00_03

    The MVL version is 4.0.1.
    Thanks and regards,



    ddompe said:

    Hi all,

    I have been too busy to keep an eye on this thread and provide some more info :(

    Juan and all, there is a new gstreamer project for support most Davinci and OMAP parts that's is being developed by TI and RidgeRun and supported commercially by RidgeRun. Even if you don't need the commercial support, the project is a lot more alive than the other previous gstreamer ports and has more capabilities and way better performance. The releases are being formally tested by TI and RidgeRun with latest DVSDKs and for bugs or issues there is bug tracker and IRC channel available.

    The project is not official yet (meaning it hasn't been officially presented), but will save you guys some pain. Please visit gstreamer.ti.com

    Regards,

    Diego Dompe

    RidgeRun Engineering

     

  • I believe this port will be supported by the open source community, with additional services provided by RidgeRun for a fee.  I noticed there is a forum section at https://gstreamer.ti.com; have you tried posting there?  I notice there is nothing there yet, but this is likely because this project has not been officially annouced yet.

  • The gstreamer.ti.com was announced on the Davinci open source list (and probably elsewhere as well) last Friday.

    Chase Maupin said:

    All,

    GStreamer is an open-source multimedia pipeline engine. TI is pleased to announce that we have created a plugin for GStreamer that contains several elements to enable the use of TI hardware with GStreamer. This includes elements to use the DSP or other hardware accelerators to encode and decode audio, video, and images. This is a base port to enable developers to use GStreamer on their embedded devices to allow for a more multimedia rich offering. The code has been designed to be highly portable between TI processors. We currently support the following processors:

    - DM644x

    - DM355

    - DM6467

    - OMAP3

    On those processors we support playback of elementary streams as well as transport streams, AVI files, and mp4 streams. As new processors are released we are adding their support to the GStreamer implementation.

     

    We have partnered with RidgeRun for support. The support model is that customers can use open-source resources to solve problems but if they need more detailed help, custom features, or help in productizing their offering they can buy a support contract from RidgeRun.

    The project is hosted on a GForge server at

     

    http://gstreamer.ti.com. There is an initial 0.99.00 release available at that site which will support decoding of audio, video, and images as well as the encoding of images. Support for encoding of audio and video is in the development trunk of the repository but has not yet been fully tested. For more information on this project please visit http://gstreamer.ti.com

    What's coming:

    1. Support for DM357

    2. Support beagleboard (using Arago/OpenEmbedded) 3. New release with tested audio/video encoders

     

    Sincerely,

    Chase Maupin

     

     

    This being said, in addition to the forums on the gstreamer.ti.com site you may want to try the Davinci Linux Open Source List.

  • I solved this problem.

    I found that   libtool 1.5.8 works well , but libtool 2.2.2 and later will pops the error message.

    So , I installl libtool 1.5.8 on my host machine , and compile the ti_build successfully.

     

    yangsb said:

    Hi everyone .

    I download the gst-ti-plugin-full-0.99.00.tar.gz from https://gstreamer.ti.com.

    But when I compile the ti_build , the compile failed with the following
    errors:




    Hi all,

    I have been too busy to keep an eye on this thread and provide some more info :(

    Juan and all, there is a new gstreamer project for support most Davinci and OMAP parts that's is being developed by TI and RidgeRun and supported commercially by RidgeRun. Even if you don't need the commercial support, the project is a lot more alive than the other previous gstreamer ports and has more capabilities and way better performance. The releases are being formally tested by TI and RidgeRun with latest DVSDKs and for bugs or issues there is bug tracker and IRC channel available.

    The project is not official yet (meaning it hasn't been officially presented), but will save you guys some pain. Please visit gstreamer.ti.com

    Regards,

    Diego Dompe

    RidgeRun Engineering

     

    [/quote]

     

  • When I finished compiling the gstreamer project , I tried to run the demo on my EVM.

    First , I run ./loadmodules.sh

    Second , I run the decode_avi.sh :  ./decode_avi.sh -f star.avi

    The gstreamer failed with the following errors:

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

    gst-inspect TIViddec2                                                         
                                                                                  
    (gst-inspect-0.10:1105): GStreamer-WARNING **: Failed to load plugin '/opt/gstr
    eamer/lib/gstreamer-0.10/libgstticodecplugin.so': /opt/gstreamer/lib/gstreamer-
    0.10/libgstticodecplugin.so: undefined symbol: MP4VENC_TI_IMP4VENC            
    ERROR: Failed to execute 'gst-inspect TIViddec2'                              

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

    Anyone could give me some advice ?

    Best regards

     

  • If you are running gst on DM6446 (DVSDK 1.30) then you should be using TIViddec not TIViddec2.  Refer readme.txt for element name and its corresponding xDM version. e.g TIViddec is for xDM 0.9 codec (which is inlcuded in DVSDK 1.3 - dm6446).

    Thanks - Brijesh Singh

  • Hi Brijesh,

    Even I am running the encode_elementary.sh from the gst release version 1.00 & getting following errors.

    I have DVSDK version : dvsdk_1_40_00_28       &    Platform : DM6467

    /opt/gstreamer_demo/dm6467# ./encode_elementry.sh -f D1_720x480_Tractor_420P.yuv -o out.264 -v
    gst-inspect filesrc
    gst-inspect TIVidenc1
    *********** Pipeline Settings *************
    platform               = dm6467
    source                 = filesrc
    source_args            = location=D1_720x480_Tractor_420P.yuv
    encoder_plugin         = TIVidenc1
    encoder_plugin_args    = codecName=h264enc engineName=encode contiguousInputFrame=FALSE iColorSpace=Y8C8 resolution=720x480 contiguousInputFrame=FALSE


    gst-launch --gst-debug-no-color --gst-debug=TI*:2 filesrc location=D1_720x480_Tractor_420P.yuv ! TIVidenc1 codecName=h264enc engineName=encode contiguousInputFrame=FALSE iColorSpace=Y8C8 resolution=720x480 contiguousInputFrame=FALSE ! filesink location=out.264
    Setting pipeline to PAUSED ...
    Pipeline is PREROLLING ...
    0:00:00.467631677  1205    0x81f70 WARN             TIVidenc1 gsttividenc1.c:1695:gst_tividenc1_frame_duration: framerate not specified; using 29.97fps
    0:00:00.878941246  1205    0x81f70 ERROR            TIVidenc1 gsttividenc1.c:1422:gst_tividenc1_encode_thread: Failed to execute CCV job

    0:00:00.879788808  1205    0x81f70 ERROR         TICircBuffer gstticircbuffer.c:492:gst_ticircbuffer_data_consumed: when circular buffer is created with fixedBlockSize=TRUE consumers must always consume an entire window at a time
    Pipeline is PREROLLED ...
    Setting pipeline to PLAYING ...
    New clock: GstSystemClock
    Got EOS from element "pipeline0".
    Execution ended after 6639912 ns.
    Setting pipeline to PAUSED ...
    Setting pipeline to READY ...
    Setting pipeline to NULL ...
    FREEING pipeline ...

    Your help would be greatly appreciated.

    Thanks,

    Manoj