theora - May 2011 - CPU saving way to lower quality of Theora stream

Hi,

is there a good concept to lower the quality of a Theora stream without 
completely reencoding it?
For example to make a lower bitrate stream out of a higher bitrate 
stream on the fly on some sort of proxy server. I am thinking about 
something like requantization.

If you think requantization is also the best (or the only) option for 
Theora please let me know.

Kind regards,
Franz

On 05/17/2011 06:08 PM, fboehm wrote:
> is there a good concept to lower the quality of a Theora stream without 
> completely reencoding it?
I think the correct answer is "no".  You're probably better off
just
completely re-encoding in your proxy.
> If you think requantization is also the best (or the only) option for 
> Theora please let me know.
Requantization is a very interesting idea, and if you pursue it I would
certainly like to see the results.  However, I see a few major issues:

1. Drift.  If you simply reduce the quality of each frame independently,
the errors will accumulate over time.  A typical Theora stream can have
256 consecutive P-frames, so in the worst case the accumulated error can
be 256 times the per-frame error, meaning some parts of the frame might be
totally wrong colors.

2. Scaling.  When reducing bitrate, you will usually get the best quality
by reducing the resolution before re-encoding (scaling down the video).
Scaling is impossible without a complete re-encode.  Scaling saves encoder
CPU time*, so it might be faster and higher quality than any
requantization approach.

3. Suboptimal quantization.  Quantization in modern encoders is not nearly
as simple as in the classic MPEG encoders of the 1990s.  The libtheora
encoder has had years of work put into its quantizer/tokenizer to make
psychovisually optimal quantization decisions.  A simple requantizer is
unlikely to do anywhere near as well.

In summary, you're probably better off just decoding and re-encoding.

If you're committed to requantization, I wish you luck.  You might also
want to consider a different approach, in which you run the complete
encoder as usual, but copy the motion vectors and block modes from the
input.  This could save CPU time by eliminating MV search and mode
decision, and it avoids the problem of drift.

Incorporating scaling into such a model is harder, but perhaps you can see
how it might be extended for scaling by a factor of 2.

--Ben

*: Scaling costs CPU time in the scaler, but saves CPU time in the
encoder.  These can run in separate threads, so if you have multiple CPUs
you can run them in parallel, saving wall-clock time.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url :
http://lists.xiph.org/pipermail/theora/attachments/20110517/846cff23/attachment.pgp

--- On Wed, 18/5/11, fboehm <fboehm at aon.at> wrote:
> From: fboehm <fboehm at aon.at>
> Subject: [theora] CPU saving way to lower quality of Theora stream
> To: theora at xiph.org
> Received: Wednesday, 18 May, 2011, 8:08 AM
> Hi,
> 
> is there a good concept to lower the quality of a Theora
> stream without 
> completely reencoding it?
<snip>
> Franz
What about bitrate peeling[1]?


[1] http://en.wikipedia.org/wiki/Bitrate_peeling
--
tom_a_sparks "It's a nerdy thing I like to do"
Please use ISO approved file formats excluding Office Open XML -
http://www.gnu.org/philosophy/no-word-attachments.html
3 x (x)Ubuntu 10.04, Amiga A1200 WB 3.1, UAE AF 2006 WB 3.X, Sam440 AOS 4.1