[vorbis-dev] voribs_analysis() question

[Jeff Squyres]

On Sat, 9 Dec 2000, Michael Smith wrote:

> 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.

That's pretty much what I figured.  Thanks for the confirmation.

> >My question is: is there a way to "simulate" the global state?  Given that
> >[snipped]
> >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.

Good to know.

> 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.

Gotcha.  Doing >1 blocks overlap is easy.  Any suggestions on a "beyond
this number of blocks, the law of diminishing returns is in effect" value,
or would this be pretty much guaranteed to be input-specific?

This is a bummer, though -- it would certainly be nice to be able to
generate diff-able parallel and serial output.  But I understand the
fundamental nature of the problem.  :-\

> >[snipped overlap explanation]
>
> 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.

Clarification: do you mean that the upper-level application is responsible
for the size of blocks (i.e., how much you read from the input)? If so,
this is not a problem, since I'm writing an application, not a library --
hence, *I* would be responsible for the block size.

Unless you mean that something inside libvorbis is adjusting the size of
the blocks...?

This does allude to one unfortunate side-effect of my application:
particularly when dealing with multiple machines (as opposed to shared
memory/threads), I have to pack up the vorbis/ogg data structures and send
them to the remote nodes.  Meaning that I have to dive into libvorbis and
libogg .h files to get specific structs and write packing routines for
them.  Icky, and sensitive to changes by the vorbis developers, but
unfortunately necessary.

Is there a better way?  Are there library functions to
pack/stream/whatever vorbis_blocks and/or other data structs?  I would
kidna doubt it, since (for example) I would only want to send the
vorbis_dsp_block once for a given group of vorbis_blocks to a single
remote node for effenciency reasons.  Such optimizations would likely be
incompatible with the goals of a standardized libvorbis and libogg.  Any
other suggestions?

> [snipped sidenote C++ question]
>
> 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.

True.  Indeed, building .a and .so libraries that contain C++ (particuarly
templates) is just as portable-problematic as building C .a and .so
libraries (if not more so, because of the "template problem"), and
libtoolfrequently doesn't handle it properly (it does for current versions
g++, though, since the procedure is the same as for gcc).  It's too bad; I
certainly hope this gets better.

Second sidenote: I used C++ extensively in my application so far, even
though I know that some people don't have C++ compilers.  The rationale
here is as follows:

a) they can get g++ and use that.
b) the lower layers libvorbis et al. can be compiled with a decent
   underlying C compiler; the top-level [C++] application doesn't care,
   and isn't too much of a target for the same kind of optimizations that
   you worry about for number-chunking codes.
c) it's an application, hence, even thought I used the STL (i.e.,
   templates), I don't have to worry about building .a/.so files, so
   building is still portable.

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

--- >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.