• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 298 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Unable to recreate gstreamer results found with default NFS target filesystem in DVSDK 4.0

BrandonAzbell
Guru 64510 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

I have been unable to recreate the functional results when using the following gstreamer pipeline after recompling the gstreamer plugin for DMAI and CodecEngine on the OMAP-L138 with DVSDK 4.0.  Let me explain.

If I go through the out-of-box procedure using a NFS mounted filesystem for the target (OMAP-L138), I am able to go to the following directory in the target filesystem, invoke the ./loadmodules.sh and then execute the following gstreamer pipeline with working results.

/usr/share/ti/gst/omapl138

gst-launch filesrc location=/usr/share/ti/data/sounds/davincieffect.aac ! TIAuddec1 codecName=aachedec engineName=codecServer ! alsasink -v

 

However, there is no CodecServer image in the above directory.  Only the loadmodules.sh file is in that directory.  Yet, I am able to hear the AAC file played out the headset on the OMAP-L138 EVM.  Where is gst-launch finding cs.x64P?

In contrast, when I recompile the gstreamer plugin with absolutely no changes to any file and copy the newly built libgstticodecplugin.so into

/usr/lib/gstreamer-0.10/libgstticodecplugin.so

When I perform this, the above gstreamer pipeline does not work.  I found a comment on the gstreamer.ti.com forum which indicates the cs.x64P needs to reside in the working directory of where the gst-launch is invoked.

My question is : Why doesn't that exist in the original NFS filesystem?

 

  • 0
    TI__Expert 5680 points

    Brad,

    Prebuilt gstreamer libs looks for codec server in /usr/share/ti/ti-codecs-server/cs.x64P directory. And this was done by exporting CODEC_SERVER before building gstreamer-ti plugin.

    # export CODEC_SERVER  = "/usr/share/ti//ti-codecs-server/cs.x64P"

    And Since the top label DVSDK makefile is not exporting this variable hence the newly build plugin is looking for cs.x64P in current working directory. Here you have two options.

    1)   Update makefile to export CODEC_SERVER before executing make from gst-ti. I agree its bug and will get fixed in next DVSDK release.

    2) cd /usr/share/ti/ti-codecs-server/ directory and run your pipeline from there.

    Let me know if this helps.

    Thanks

    Brijesh

     

  • 0 in reply to Brijesh Singh
    TI__Guru 64510 points

    Thank you for confirming what I have observed.

    Which DVSDK release will have this addressed and do you have a timeframe of when to expect it?

  • 0 in reply to BrandonAzbell
    TI__Expert 5680 points

    Brad,

    I'll submit bug report for this and will target fixing in DVSDK 4.01 release (tentatively will be available in Mid of Jan'11).

    Thanks

    Brijesh