gstreamer-ti looks for combos in current directory


My build of Angstrom Stable/2009 and gstreamer-ti runs fine but I need
to run my applications (gst-launch) in /usr/share/ti-codec-combos.
The recipes I am using (latest stable) are supposed to have the fix for this.

gst-launch filesrc location=monster.mp4 ! typefind ! qtdemux name=demux demux.video_00 ! typefind ! TIViddec2 ! xvimagesink

--gst-debug=*:2 gives the following as the first error when run from
any other directory
"could not open codec engine "decode"

Has anyone been able to run in other directories?

TI tools I am using are the recommended versions (dspbios-5.33.02,
cgt-6.0.16 and xdctools-3.10.03).
The codec combos are from the omap3530 DVSDK. (3.16)


No, could you please file a bug for that at ?




Found the fix here.
In the section "Advanced: overwriting fields, creating multiple engines"

Needed tor reverse the previous patch 263 and apply the attached patch.

When you call createFromServer the path you give is relative to
package, not the filesystem one. For that you need to set
"engine.server" to the desired full filesystem path.
This is what the attached patch does.


codec_combo_directory_fix.patch (1.82 KB)

Nice! I haven't got an answer for that one yet.



Please post this patch on the patch tracker. That
way it can be reviewed for how to integrate this into the repository.
We will need to work out how to make this work for both Angstrom
builds as well as others but this patch will provide a good reference


Hi Chase

I have submitted the patch.

Btw the patch forces gstreamer to look into a hard-coded installation
directory of the codec combo server. The installation depends on how
we install the codec-combo.
The OE stable branch recipies install codec combos to
/usr/share/ti-codec-combos, whereas the dev branch recipies use
So this patch has to be modified even between Angstrom builds.

Anyone knows if there is a method of determining the codec-combo
installation path?

Otherwise we could define an ENV variable which gstreamer-ti can use.


I think we should decide on a single path (We already did, but Brijesh was a little too enthusiastic with his changes :)), env vars won't do much good, we want applications to "just work" without the user needed to set a gazillion env vars.