[Tremor] running memory size is not predictable?

[Michael Smith]

On 10/14/05, Park Jin Soo <jinsp at mcubeworks.com> wrote:
>
> Is it possible to predict the maximum size of running memory in tremor?

Not really.

>
> For example, in vorbis_staticbook_unpack(),
> s->lengthlist is allocated as bellow,
>
>   s->entries=oggpack_read(opb,24);
> ...
>     s->lengthlist=(long
> *)_ogg_malloc(sizeof(*s->lengthlist)*s->entries);
>
> This seems to mean that the size can be 16777215 * sizeof(long) bytes!!!???
> In this way, the predicted value for running memory is too large.
> Are there any other restrictions to memory size in spec. or encoder?
> How can I predict the exact and proper limit of running memory?

One of the "problems" (and also a great strength for other reasons)
with the current vorbis spec is that it's extremely flexible.
Unfortunately, that does mean that various things are essentially
unbounded (or have extremely large bounds, like this one here).

We've been planning to work on a "portable profile" (or whatever we
end up calling it) for vorbis, which is what we'd expect embedded
implementations to be able to decode. This would put various limits on
what is permitted, so that a useful upper limit on memory and cpu
usage can be established. We haven't done this work yet, though - one
of the limitations of being a non-profit volunteer-run organisation is
that it's often hard to get "boring" work like this done.

Obviously, this is primarily useful for those people making embedded
devices supporting vorbis, so it'd be extremely useful to have
feedback and assistance from some of these people, so that we can make
the limits sensible and usable, but none of the people working on
these things have offered to help - instead, each implementation is
presumably using its own ad-hoc limits, which no doubt differ widely,
and often cause files which ARE completely reasonable (and which
should be decoded by embedded implementations) to be rejected by some
hardware players - not a good situation!

Mike