[CELT-dev] Scanning the compressed celt for an artifact

[Benjamin M. Schwartz]

On 07/17/2011 06:14 PM, Andrew Lentvorski wrote:
> Since CELT's latency is a known
>> constant, you could just look at packet numbers to determine the rest of
>> the system's latency.  Alternatively, you could just send pre-encoded
>> packets with known contents.
> 
> Um, you folks who develop CELT really are myopic about always being on
> enormous machines with huge storage, RAM, etc. ;)

Pre-encoded packets can be 2 or 3 bytes each, and you only need two to
create a boundary.  However, it seems that you expect the problem is
before the encoder, in which case this would indeed not be a very helpful
exercise.

> After examining the CELT streams a bit, I'm probably just going to flag
> significant compressed stream *length* changes.  It seems that if you feed
> in a sine wave the packet length settles to a fairly constant number +- a
> little.  When you shift that frequency, there is a sudden jump in the
> packet length which then settles down again.

That sounds like a good plan.  Note that the encoder's behavior in this
regard is not guaranteed; you might (rarely) get a spike even without a
big change in the input.

> And, while I was being a bit flippant about CELT developers focusing on
> large machines, if folks want CELT adoption, pushing at the embedded
> people is the way to do it.

The development has very much kept the embedded market in mind.

> Being able to store things like sound effects
> in compressed form and expand them with *low latency* is a big deal

That's probably why the most famous sound sound effect library I know of
(FMOD) now uses CELT.

> The other side of that is that there exist *no* useful hardware encoder
> chips for MP3 or Ogg.  CELT + low end microcontroller is way cheaper than
> the only chips that currently exist (presumably the MP3 license causes
> this).

That's good to know.  If you find an especially cheap/small/slow
microcontroller on which CELT works well, we'd certainly like to hear
about it.

I was curious about "MP3 encoding chips" though ... and indeed it looks
like most of them are just DSPs and some MP3 firmware, even the one you
linked to.  Analog Devices does this explicitly: You get the firmware free
(http://www.analog.com/en/processors-dsp/blackfin/bf_mp3_encoder/processors/product.html)
and then you buy an ADSP-BF* (min of ~$6.26) to run it on.

--Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.xiph.org/pipermail/opus/attachments/20110717/1e6efa95/attachment-0002.pgp