The problem is, AFAIK exeDSP is linked with samsung's own libavcodec (stripped down, outdated and not very well optimized version). I guess loading secondary libavcodec.so from inside exeDSP will be out of the question, due to conflicting dynamic dependencies /duplicate symbol references etc.
Maybe one can use a little different approach: some kind of external app (running as separate process) for decoding audio formats which are not supported nativelly on Tv. It may exchange audio data / audio buffers with exeDSP code through pipes, or possibly through IPC shared memory. Such an app can be linked with it's own versions of libavcodec/libdca/libwhatever with no problems. Please let me know what you think.
Attached the sample app (api-rawdts-decode) bin & source. This is very simple thing, it just decodes typical fixed-length (2013 bytes ?) dts packets to pcm, stdin/stdout can be used as input and output. It does dts decoding in real time with ca 22-25% CPU utilization. Result is raw pcm stream, i.e. 2-ch 16bit low-endian headerless format directly playable by my external sound card like this:
Code: Select all
cat audio.dts | api-rawdts-decode - - | aplay -f dat
Code: Select all
cat audio.dts | ffmpeg -f dts -i - -acodec pcm_s16le -ac 2 -f s16le - | aplay -f dat
I'll try to attach ffmpeg binary precompiled for Tv CPU, completed with source patches. Now let's check if sourceforge forum will accept 6+ MB attachment