[vorbis-dev] voribs_analysis() question

[Michael Smith]

At 05:58 PM 12/8/00 -0500, you wrote:

>However, as has been briefly alluded on this list before, there is global
>state that is shared between all vorbis_block instances.  Specifically,
>vorbis_block contains a pointer to the stream's vorbis_dsp_state, which in
>turn, has a pointer to the stream's vorbis_info.

Yes. The encode process (this is not true for decode - you can decode a
block independently of the rest) is stateful. This state is, as you've
surmised, stored is vorbis_dsp_state. vorbis_info is essentially static
storage, it does not change during encode/decode. This isn't just a hack -
the encoder is naturally stateful, something which is pretty fundamental to
the encoder design.

>My question is: is there a way to "simulate" the global state?  Given that
>I want to split vorbis_blocks across multiple processors, I'll likely also
>have to give them their own local vorbis_dsp_state instead of one big
>shared one (it *looks* like the underlying vorbis_info is *not* modified
>during the encoding process; so keeping the one global vorbis_info should
>be ok -- please correct me if I'm wrong).
>
>Is this possible?  Assumedly, having the vorbis_dsp_state maintained from
>block to block is there for some specific voodoo in the encoding
>algorithm.  Is there a way to "fake" this with multiple copies of the
>dsp_state?

No. The most obvious thing is the short block decision code. That's used
for pre-echo control. The decision on whether to use a short block is
dependent not only on the current samples, but on previously encoded
samples as well. In fact, the decision depends partially on whether the
previous block was encoded as short or long. 

So this decision could, potentially, propogate through an unlimited number
of blocks. Which means your idea can't work with 100% success. However,
this doesn't mean it's impossible. It just means that the output may
sometimes be different from the non-parallel output, but with a sufficient
overlap (one block wouldn't be enough, in my opinion), you can get
arbitrarily close. Although differences are possible, they become
increasingly unlikely.

>
>For example, could I have each processor do 50 blocks, but actually give
>each processor *51* blocks (each set of 51 sharing a single dsp_state)?
>Ignoring processor 0, because the first 50 blocks will be processed
>exactly as they are in serial, it would look like this:

As I explained above, this won't always work, and you'll need a larger
overlap, but it should be doable. However, units of 'blocks' are...
impractical, since the size of the blocks is determined by the encoding
process. You'd need a better way to share out the data.

>
>As a sidenote question, why is the _P_mapping stuff used in libvorbis
>instead of virtual functions on a C++ class?  It seems that you've
>effected the same thing, except in C.  Just curious...

Because, though C++ is becoming more and more widely available, good C
compilers are still much more widely available. I've used platforms in the
last year which have C compilers, but not C++ compilers. 

Unfortunately, though C++ can be a nice language, it's a pretty bad choice
for a low-level highly portable library like libvorbis.

Michael

--- >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-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.