[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vorbis-dev
Subject:    Re: [Vorbis-dev] Short block encode computation time.
From:       xiphmont () xiph ! org
Date:       2007-01-09 2:37:09
Message-ID: 806dafc20701081837j620141fbo683b694e0213cc6c () mail ! gmail ! com
[Download RAW message or body]

On 12/21/06, Doron Veltzer <veltzerdoron@gmail.com> wrote:

> I'm interested in low-latency streaming of small packets of audio captured
> from a sound card.
> I want to focus on the compression computational time (not the transport). I
> have several questions regarding Vorbis :
>
> (1) Vorbis supports block sizes down to 64 samples according to the spec.
> Can I encode, frame, and transport blocks of this size?

Yes.  Using Ogg for it, though, will impose a fairly high overhead for
single packets this small.

> Will the performance
> of a standard vorbis encoder using short sample blocks differ significantly
> from performance with the longer block lengths usually used?

Gods, yes.  In a normal encoder setup using block sizes of 256/2048,
the short blocks are typically only 1/4-1/2 the size of the long
blocks.  So, using only short blocks will incur a compression
performance penalty of 2x to 4x and probably cause nasty blocking
artifacts in pure tones.

> (2) Are such short block lengths compatible with Managed Bitrate modes?

The algorithms are compatable.

> (3) What computation time can I expect  in encoding a 64-sample block?
> 128-sample? (Ordinary, modern P4 platform.)

Dunno, never measured it.

> (4) What are the main sources of computational time in encoding a short
> block?

Frame analysis  The coding itself takes practically no time at all..

> (5) How much of the overall compression is due to perceptual encoding?

80-ish %.

> How
> much due to entropy encoding (huffman)?

20-ish %  It depends alot on how you look at it.

Monty
_______________________________________________
Vorbis-dev mailing list
Vorbis-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/vorbis-dev
[prev in list] [next in list] [prev in thread] [next in thread]