[Theora-dev] Encoding paramaters...

[illiminable]

<002101c460ea$39fef340$0100000a at tiger> <40E6E0D4.4010208 at vt.edu>
Message-ID: <00b201c46120$2158c510$0100000a at tiger>


----- Original Message -----
From: "Timothy B. Terriberry" <tterribe at vt.edu>
To: "illiminable" <ogg at illiminable.com>
Sent: Sunday, July 04, 2004 12:37 AM
Subject: Re: [Theora-dev] Encoding paramaters...


> I guess I should answer these questions somewhere, since I seem to be
> asked them a lot lately. Hopefully Google will pick this reply up.
>

Thanks very much this has been very helpful... if you don't mind i'd like to
paraphrase some of this into a theora encoding with directshow tutorial i
have started, and will go online with the next release which includes the
theora encoder filter. I will also link to this post in the archive as a
reference and this will ensure it gets googled.

> >>>The fields i don't understand are quick_p.... what does this do ? What
> >>>implications does it have on the other parameters.
>
> It uses a hierarchical motion vector search instead of full search... it
> still falls back to full search if the vector returned by the
> hieararchical one is particularly bad. This should almost certainly be
> enabled by default.
>

That means nothing to me ! :) Is it safe to summarise that with this option
on, the encode will be faster but possibly of lower quality, ie it's a "near
enough is good enough" approach rather than a "find the absolute best"
approach ?

> keyframe_frequency_force will ALWAYS use a keyframe after N frames
> without one. keyframe_frequency is, however, the EXPECTED frequency of
> keyframes (e.g., the encoder tries to average one in N frames). They
> don't have to be equal, but it doesn't make any sense for the latter to
> be smaller than the former.
>

What is the maximum possible value for these two values ? And are they
required to be powers of two ?

> I should note that ALL of these options are specific to the encoder
> inherited from VP3. Some or all of them might not make sense in another
> encoder (e.g., the experimental one), and most of these things shouldn't
> be in the theora_info struct at all. This is one of the areas of the API
> that we want to change, so be warned.
>

Sure... noted.

Thanks again,

Zen.