Re: Dynamic Change Parameters..

[email protected] wrote:
> Again, a toplevel application has very little business making ths
> decision.  Keyframes are generated for only two reasons: The max
> interval between keyframes has passed, or a keyframe would require
> fewer bits than a P frame.  Only the theora internals have any way of
> knowing this information.  A Keyframe (I frame) and a P frame will
> have the same distortion characteristics.  A keyframe is not higher
> quality than P frame, just (usually) bigger and allows seeking.

You can also do it for subjective reasons: inserting a keyframe at scene
changes prevents one scene from bleeding into the next. Additionally,
spending extra bits to boost the quality of a frame you intend to use
for long-term prediction (Theora's golden frames) has been shown to
sometimes reduce overall bitrate due to better prediction. Obviously
this can only be done at a scene change without introducing popping
artifacts, but it is probably worth experimenting with detecting scene
changes explicitly and biasing towards coding a keyframe, even if it
will use more bits. Otherwise, at typical internet streaming resolutions
and bitrates, it turns out to be almost always better to code as a P
frame, even at scene changes, and all your keyframes will be placed due
to hitting the maximum keyframe interval (changing the bias depending on
how close you are to this limit is also probably a good idea). A number
of codecs make their keyframe decisions almost exclusively based on
scene change detection.

But the real issue here has nothing to do with keyframes, but the
ability to dynamically adapt the target encoder quality (or bitrate, or
whatever) from the application level. theora-exp started down the lines
of defining an API for this, but the feature itself was never really
implemented. The API is easy (it's just a new TH_ENCCTL code), but this
definitely needs to be built into Thusnelda's new rate control in some
form. Coupled with some simple R-D statistics reporting, this would
allow external two-pass rate allocation, which is a feature we've long
been lacking.