[vorbis-dev] voribs_analysis() question

[Michael Smith]

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

It will be input-specific to some extent, but it probably wouldn't change
much. Some experimentation should give you a good idea of how much overlap
would be needed. I would suspect as little as 2-3 blocks would be
sufficient (however, this might increase significantly in the presence of
short blocks - currently an eight of the size of long blocks).

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

It's actually both, though I meant libvorbis internally. The application
can specify the two (long, short) block sizes - they're powers of two,
limited to a lower size of 64 (I think), and an upper of 64k. However, you
don't generally want to change these (application level software will
probably never do so). The encoder uses (at the moment) sizes of 2048 and
256, I think. 

It switches between these in an input-dependent manner (in fact, this is
what causes the biggest problem for your purposes - the blocksize decision).

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

I would think that the only data structure you'd have any real need to
transfer between your nodes would be ogg_packet. That's packed into a
vorbis_page for transmission, which isn't what you want - but the data
structure for a vorbis_packet is very simple, and not likely to change.
There's aren't generally functions to pack the internal datastructures of
libvorbis, of course.

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

Really, the main problem isn't performance or library building - it's
portability. There are C compilers available for far more platforms than
C++ compilers. This DOES include platforms (like DSPs) for which a
libvorbis port would be useful.

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.