Chris Nuernberger wrote:
On Monday 13 May 2002 06:58 pm, you wrote:
I think we should have a directory under /usr/lib/ called codecs, and
then
Why do you care where it is ? We have LD_LIBRARY_PATH
I want the codecs to be self-registering;
I also want easy install and removal, thus I want them all in the same
directory.
Yes, but make the directory run-time configurable...
The plan was to have them all register themselves by inserting data into a
textfile in their current directory, wherever that may be. This data has:
vendorID
objectName
format[s]Input
format[s]Output
Preferably more than that. You would probably want input-output format
pairs (as not all codecs support the same outputs for a given input).
Secondly, you should probably also have a "cost" measure (I was thinking
of using the average no. of CPU clocks relative to some reference
codec). Finally, a "quality" measure, possibly a PSNR measurement - to
give an indication of how good the codec is.
This makes it possible to have a number of codecs - a fast but poor
quality codec for real-time applications, and a really good, slow codec
for off-line compression.
To maintain all of this, I was thinking of having an core library that
built and maintained the registry (possibly also benchmarked quality and
cost). The core would also be responsible for hooking together codec
chains for a given input, output, and cost measure...
A bit of extra effort, but well worth it.
The nicest codec interface I have used is that of rte
(http://zapping.sf.net/). Flexible, configurable, and really easty to
use. Also, the push/pull mechanism makes it possible to make relatively
cheap buffers for decoding ahead, and, can also interface very nicely to
v4l2's buffering system.
Then a program could, given an arbitrary stream and its format, see what
other formats it could convert that initial stream to (or more complicated
but still possible) find if, through a chain of three or four codecs, it
could end up with the desired result (remember that a codec could also
simply be image format conversion or scaling). Chris
As I said above, use a core library, that given an input, output, and
cost requirement, builds the desired codec chain, rather than
duplicating this functionality in each program.
As you may notice, I have thought long and hard about this - I have just
never had the time to sit down and do it. I also haven't managed to
think of effective ways to handle file sources and sinks (audio, video
and time information).
If you want any help working on this, send me some mail, and I will help
where needed.
-justin
