A bit long, but hopefully worthwhile...
Question 1. A couple thoughts on how you could make this happen.
Jean-Michel's suggestion to add the common speex-base.l64P to the linker
cmd file should work, but I'll suggest 2 alternatives.
A. You _should_ be able to create a single "multi-codec" package,
which implements both ISPHENC and ISPHDEC. We don't have an example of
this, but you'd basically mash the sphdec_copy and sphenc_copy codecs
into a single "package", continuing to generate 2 libraries (plus the
common one), and in the package.xs file, that single package's getLibs()
function might look something like this (not tested):
function getLibs(prog)
{
var name = "";
var decname = "lib/speexdec.a" + prog.build.target.suffix;
var encname = "lib/speexenc.a" + prog.build.target.suffix;
/* assuming you only support C64P devices - great if you support
more, though! */
if (prog.build.target.isa == "64P") {
/* always link this */
var name = "lib/speex-base.a" + prog.build.target.suffix;
if (this.ISPEEXDEC.$used) {
name += ";" + decname;
}
if (this.ISPEEXENC.$used) {
name += ";" + encname;
}
/* return the library name: name.a<arch> */ print(" will link with " +
this.$name + ":" + name); }
return (name); }
In this way, your package would only contribute the speex decoder or
encoder library if it was configured into the server ($used). And no
messy "add this library to your server's linker command file... but only
if your config script has one or both of the speex codecs" to document.
A disadvantage, perhaps, is that you bind the distribution/upgrade of
your decoder lib to the encoder lib - meaning a fix to one, requires a
re-release of both.
B. A second approach would be to _not_ bind the encoder to the
decoder, keep them separated, and introduce a 3rd package, one that both
depend on. Your third package would implement a getLibs() which
returned the "speex-base.l64P" file. You can achieve this dependency by
using the "requires" keyword in your encoder and decoder's package.xdc
file. For example, if speex-base.l64P is in the
"mycompany.codecs.speex-common" package, you could add the following
line to the speex encoder _and_ decoder's package.xdc file:
requires mycompany.codecs.speex-common;
This will cause the mycompany.codecs.speex-common package (including
it's getLibs()) to be pulled in anytime the speex enc or dec codecs are
used.
Question 2. The good news is you get this for free-ish. The libraries
which get linked into your Server is auto-generated by your
configuration (.cfg) script. This is one of the motivations for
auto-generating the linker command file containing the list of libraries
(.xdl file). If you don't have any video decoders, you won't link in
video.a64P; you don't have to do anything. (And related to Question 1
above, that's why I'm not a fan of "add the lib to your link.cmd file" -
while it'll work, it's not in the spirit of the "you don't have to
manually maintain the list of libraries".)
Another thing to consider when minimizing footprint is to be sure to use
the "release" libraries - that is, in your server's package.bld, be sure
_not_ to configure this:
Pkg.attrs.release = "debug";
-----------------------------
And finally a quick word of caution for everyone when creating your own
packages. Every package, codec or otherwise, must have a globally
unique package name. By convention, the name of the package typically
begins with a company name, followed by whatever naming convention you
want to follow in your company. I'm flagging it because I think
Jean-Michel's recommendation for creating your own, new package is what
most folks do - take an existing example (e.g. codecs.sphdec_copy) and
rename the last name part (e.g. --> codecs.speexdec).
While this works fine in isolation, if everyone does this, integration
of packages between companies becomes impossible. There will be a dozen
"codecs.mp3dec" packages out there - which will be "a bad thing" when it
comes time to integrate a cross-company solution.
That's it - thanks for listening. :)
Chris
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, January 09, 2007 1:35 PM
To: Jean-Michel Mercier;
[email protected]
Subject: Re: Merging enc and dec codecs
Thanks Jean-Michel for your help, I will do what you suggested;
actually I had already planned doing what you suggested before
posting but I didn't know the specifics; your explanation
clearified a lot of the grayed areas for me. Before I go off and
take on this task, I want to ask a couple additional questions:
1) Let use your example below: let's say I build the CE server
with both the speexenc.l64 and the speexdec.l64 codecs and link
in the speex-base.l64 library. When I run the CE server and
instantiate the speexenc and speexdec codecs, they should run fine
using that same library (assuming no data contention in the
library from simultaneous acces), correct?
2) This relates to the other post I submitted (small footprint
CE server - thanks for your response on that and I understand your
explanation of repartitioning the my custom board's available
DDR to fit my CE memory requirements): is there a way to just
specify such that only the SPHENC/SPHENC related resources all
built into the server; I want to reduce the memory requirement
for my custom CE server and not include the other part of the
VISA APIs (video, image, audio); this way, I have a compact
CE server. If it is possible, can you or anyone else please let
me know what file(s) I need to edit to exclude them.
Thanks!
Regards,
Andy Ngo
----- Original Message ----
From: Jean-Michel Mercier <[EMAIL PROTECTED]>
To: Andy Ngo <[EMAIL PROTECTED]>;
[email protected]
Sent: Tuesday, January 9, 2007 9:53:03 AM
Subject: Re: Merging enc and dec codecs
Andy,
SPHENC/SPHDEC are not actual codecs. They are abstract
decription of
the model of codec API that you have to implement.
You will have to create actual wrapper for your encoder and
decoder, let's call them
SPEEXENC and SPEEXDEC.
This as xDAIS/xDM wrappers above your actual library.
Anyhow I would implement SPEEXENC into speexenc.l64 (without
merging
speex-base), SPEEXDEC into speexdec.l64. You would use them into
the XDC
definition of your server. Then add speex-base.l64 into your
LINK.CMD file
for your server. But that more a matter of preference than an
actual defined
rule. May be Chris can comment on that.
> and couldn't figure
> out which file to edit so that it will link the Speex library
with the codec during the build
because this is would be done (in my choice) at server level in
LINK.CMD
You don't have a way in a (codec) library to declare a
dependency to another
library and expect the tools to find it automatically. So
development environement
such as C# (or old Turbo Pascal) lets you declare libs (units)
you are depending
on so that they are automatically searched by the linker. In C
you have to provide
at least all the lib into which the linker search for symbols.
> the makefile is automatically
Mostly all codec and server build mecanism is driver by XDC
files which
then generates makefiles and usefull files.
So in conclusion a short path looks like:
- copy all
/dvevm_1_10/codec_engine_1_02/examples/codecs/sphdec_copy
into /dvevm_1_10/codec_engine_1_02/examples/codecs/speexdec
- rename modules, files, symbols in soure code, xdc files, ...
in order to build
a new codec library named speexdec.l64 which includes a
definition of
the SPEEXDEC algorithm.
- If you want to try, build it, build the depending server (add
the declaration
of speexdec into its configuration files), modify sample code
to instantiate
"speexdec" instead of "speechdec_copy" and tryout the sample
=> once this is done you made probably the more complex stuff
- now modify C source code of SPEEXDEC class to make call to
your
speexdec-base.l64 API
- add "-l speex-base.l64" to your LINK.CMD
- rebuild and you should be able to truly decode speex data now.
Hope this helps.
Regards,
Jean-Michel.
----- Original Message -----
From: Andy Ngo <mailto:[EMAIL PROTECTED]>
To: Jean-Michel Mercier <mailto:[EMAIL PROTECTED]> ;
[email protected]
Sent: Tuesday, January 09, 2007 6:03 PM
Subject: Re: Merging enc and dec codecs
Jean-Michel,
Thanks for the response. I kinda understand what you
are saying. So let's say I have the source
code for the Speex library, which has both the API for
decode and encode; so let's say I want
to use SPHENC and SPHDEC as wrappers to access the API
in the Speex library. How do I
add/compile/link the library to both SPHENC and SPHDEC?
Do I add the Speex source code
to the SPHENC codec "AND" to the SPHDEC codec? Would
that be redundant and create
"symbol already defined" errors since the Speex library
code is linked twiced?
On a related note, let's say I have a precompiled Speex
library that I compiled under CCS 3.2
already; how do I link it to the SPHENC or SPHDEC? For
example, I look at the different
files in
/dvevm_1_10/codec_engine_1_02/examples/codecs/sphdec_copy and couldn't
figure
out which file to edit so that it will link the Speex
library with the codec during the build; the
makefile is automatically generated so I can't touch
that; the only file that seems to make sense
is the package.bld, which shows how to add c modules to
be built to into the package libary.
Please advise. Thanks.
Regards,
Andy Ngo
----- Original Message ----
From: Jean-Michel Mercier <[EMAIL PROTECTED]>
To: Andy Ngo <[EMAIL PROTECTED]>;
[email protected]
Sent: Tuesday, January 9, 2007 5:20:35 AM
Subject: Re: Merging enc and dec codecs
Andy,
You don't specifically need to link your codec to the
existing servers
unless you want to simultaneously use the other codecs
with your
speex codec.
As far as you are goind to make change to servers
(Welcome to
the World of DV SDK and XDC!), it is now up to you to
make your
own combination of codecs into servers with regard to
your application
needs.
What is clear is that each codec must have its own API
in the appropriate class.
So if your base Speex codec have a single library for
both encode
and decode, you will any how have to wrap the encoder
into a SPHENC
class and the decoder into a SPHDEC.
I don't remind seeing anything that prevent you
implementing the
2 classes into a single library. What is important is
that instanciation
and control should remain separate to respect the xDM
specifications.
Then you can build the server(s) that you need. As an
application can talk
simultaneously to a single server, you must make either
separates
(half-duplex) encode and decode servers or a
(full-duplex) encode+decode
server.
Hope this helps.
Regards,
jean-michel.
----- Original Message -----
From: Andy Ngo <mailto:[EMAIL PROTECTED]>
To:
[email protected]
Sent: Thursday, January 04, 2007 9:50 PM
Subject: Merging enc and dec codecs
I'm trying to implement the open-source Speex
codec (www.speex.org <http://www.speex.org/> ) into a Code Engine
Server. The Speex library has both
the encoding and decoding support functions.
Does that mean I have to link the library to the CE enc codec and also
to the CE dec
codec? I want to save memory resources and
possibly share global state data in the library between the enc and dec
codecs; is
there a way to combine both the enc and dec
codecs into one?
By the way, I'm new to the CE API so I have a
huge learning curve; I've read through the documents and looked at the
codec
examples and it's still a little foreign to me.
I have built the Speex library for a TMS320 5510 DSP before, can I just
link the library
with a CE codec or do I have to massage the
Speex source into the CE API method and rebuild it?
Thanks,
Andy
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
