[vorbis-dev] merging monty's branch

[Segher Boessenkool]

Monty wrote:
> 
> Hi folks,
> 
> I'm doing a merge of my current branch onto the mainline (for testing)
> today.  I believe it to be stable.  Just a little more vorbisfile

*applaud*

> testing.  After the merge, I have a few more patches to apply, then
> onto cascading/coupling.

hurray!

> New stuff:
> 
> Floor backend 1 and residue backend 1; both are present, but the
> mainline modes won't use either yet.  Naturally, both are enabled for
> decoding future streams that use them.
> 
> Floor 1 is a piecewise linear approximation of the spectral envelope.
> Advantages: more stable local spectral behavior (no more spreading
> stereo image at lower bitrates), more control over tuning specific
> error characteristics.  Disadvantages: it takes more bits than LSP,
> but not by an absurd margin (20%-30% premiun).

Another advantage: it can fit more closely to the calculated (by psy)
floor, so the psy can be tuned to be a little less pessimistic, so this
can save quite some bits in the residue.

> Residue 1: Same as residue 0, but uninterleaved.  The advantages are
> that this is faster and allows one to more easily exploit
> adjacent-line structure in the MDCT, assuming that that's what the
> codebook model wants to do.

Is there any plan to interleave channel 0 and channel 1?  This could
reduce bitrate somewhat (5-15% in testing), more once we introduce
interchannel redundancy into the psy model.

> Vorbisfile optimizations; I took HB's optimization patch, fixed a few
> infinite loop problems in it, and then decided to go a little nuts
> eliminating unneeded machine initializations and decoding work.  The
> end result is that ov_open (and friends), ov_raw_seek and
> ov_pcm_seek_page are more than 100x faster (and even faster than that
> on a network file system), and the other seek functions (that do
> actually require some internal background PCM decode to get sample
> boundaries right) are a shade under 2x faster (again, much larger
> margin on distributed file systems).

Kudos to the both of you!

> I also added an ov_test() function as a fast partial open that
> verifies the vorbis-ness of a file (and loads the headers for
> perusal), but doesn't seek to learn the chain structure or total
> length.  A partially open file can then be fully opened using
> ov_test_open().
> 
> Libvorbis now has an official vorbis_packet_blocksize() function to
> learn the block size of a packet without decoding it. Libogg also has
> one new function, ogg_stream_packetpeek(), which fetches the next
> packet in a logical stream without removing it from the stream head.
> 
> None of these changes should affect binary compatability with prebuilt
> applications.

One can only hope... ;-)

Cheers && happy hacking && more applaud etc.,

Segher

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