If you look at low cost (~$10 to $20 at quantities) fix-point DSPs (TI C5416
for example), they don't have a lot of on-chip RAM. 5416 has 128k, which is
already a lot. Of cause you can use external RAM, but this not only will
increase cost and board space, but will also degrade performance a lot. Many
of the speed-enhancing tricks only work with on-chip memory. Once you go off
chip, you lost a few memory and data buses.
Kam
-----Original Message-----
From: Mercier, Dave [mailto:dmercier@ea.com]
Sent: Tuesday, January 16, 2001 5:31 AM
To: ''
Subject: RE: [vorbis] questions
We haven't attempted to create an embedded version, but we did examine some
of these issues when seeing if it could be used in video games. I'll state
here that I didn't actually do the work, I'm just relaying the results
of
our research.
What we found was that the biggest problem was not the MIPS required
(although that's always an issue too). The biggest problem was the memory
footprint required. Apparently as of beta 2, it required about 1 megabyte of
memory to perform decoding. We reduced that to about 500k by using shorts in
the codebook expansion instead of ints. Of that 500k, about 250k could be
shared among all instances if they used the same code book (they will be the
same if using the same Vorbis encoding mode with the same encoder), and
another 250k was required per instance.
Compared to MP3, that is a lot of memory use. I think MP3 only requires a
fraction of that amount of memory, and there is no such issue as separate
code books. Of course Vorbis is superior in regards to compression, but it's
an interesting observation nonetheless - perhaps the creators of MP3 saw
memory footprint as an issue and designed that into it.
I would be interested to hear if our figures are about right or way off base
by anyone who knows better. Things may have changed since beta 2/3, or we
may be overlooking some simple optimizations to the memory footprint. I know
for our case (video games), we can't really afford that much memory use - it
kind of defeats the purpose of the compression for us.
So if your embedded device doesn't have much memory, and I think many
don't
have that much (I'm not an expert on them), it may be a problem getting
Vorbis implemented on them. I'm sure there are lots where it would fit
though, and maybe there is a way to deal with looking through the code books
on the fly instead of pre-decoding them.
Thanks,
Dave.
-----Original Message-----
From: Tom Uban [mailto:uban@ubanproductions.com]
Sent: Monday, January 15, 2001 1:13 PM
To: vorbis@xiph.org
Subject: [vorbis] questions
Has anyone made an attempt to create an embedded version yet?
Is there a plan to have embedded examples as part of the open source?
If I want to create four independent decode streams, is there any
decode work which can be shared, or is it going to be four times the
work?
How many MIPS does it take to decode a single stream?
--tnx
--tom
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
