Re: MPEG 4-SA for audio compression?

From: John Lazzaro (lazzaro@cs.berkeley.edu)
Date: Thu Apr 20 2000 - 16:15:24 EDT


> Now my question: Are there any audio coding (even just speech coding)
> systems already being developed and does anyone know, where I can find some
> references, examples or reviews?

No direct answer to your question, but on the decoder side at least, the
last few months of sfront has been about moving towards handling streaming
decoding of .mp4 files that use SA_access_units. The release a few months
ago was the first to handle SA_access_units at all, but since it compiled
them into the sa.c file, it was only good for checking out the quality
of the coded file, not for actually streaming it. The release a few
days ago includes a control driver that acts as a streaming file decoder
(fstr), which basically is proof of concept for the control driver having
all the functionality to do streaming decoding from the input side.

But neither of these is quite where you want to be -- you want to
do this:

sfront -aout linux -cin sstr -bit http://www.cs.berkeley.edu/~lazzaro/sample.mp4

and have sfront

[1] Read the start of the MP4 file and compile up the SAOL program
[2] Invoke gcc and the ./sa file, handing it the open file
[3] Have the (currently fictitious) sstr control driver read the
    rest of the file and put the SA_access_unit data into the engine
    at the right time.

At this point, making a custom sfront that does what I describe above,
just for Linux, is a few weeks of work -- the fstr control driver has
done all of the hard work on the MP4 decoding side, what's left is
handling the network end. It's not quite possible yet to do it with
no changes to the sfront source code proper -- a bit of custom hacking
in the sfront/src/sfmain.c file will be needed to handle HTTP -bit
arguments, and to throw the processes to compile and run the executable.
But its close enough that if there was a Linux user who wanted to do it,
its quite doable ...

I can't say my focus right now is on doing that, though -- the next
big set of issues seem to be about reworking the audio driver API and
the core engine to handle graceful degrading when real-time constraints
get violated (i.e. the SAOL program is too complex for the CPU), and
other real-time issues associated with it (including implementing the
cpuload standard name) -- these sorts of issues are what's holding
sfront back from being stage-worthy at this point, and also need to
be solved for high-quality streaming anyways ...

                                                                --jl



This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:38 EST