[XviD-devel] [RFC] kthresholding in 2pass2
chl at math.uni-bonn.de
Mon Dec 1 17:45:54 CET 2003
wow, this sounds all very scientific ;-)
Unfortunately, I don't know anything about sequences of several I-frames
in a row. So, as usual, I start asking stupid questions:
When do such IIIII or IPIPPIPP sequences occur? Is it a "missing feature",
because XviD detects scenechanges where there isn't one? Or is the image
content really changing that much and often?
The only occurance I found was a TV series where from time to time there
were short shots with every alternate frame _inverted_ to express
some telekinetic action that wouldn't have been noticed by the viewer
(100 points to who can tell me the series and who the character/actress
with telekinetic powers was, together with what famous NBC series she
stars in now). So there, the changes were real, and spending fewer bits
on all but last I-frame would hardly have been noticed because of all the
The bigger problem I see if _not_ the sequence is really changing, but
only XviD creates too many I-VOPs. Because then, the viewer might follow
some action and concentrate on elements which for real scene changes would
Could within min_keyframe_interval maybe the percentage of MBs be raised
which are needed to classify a frame as I-VOP.
As far as I know, even at scenechanges, I-frames usually don't save bits,
anyway, at least not many, but are mainly as keyframes for index
On Mon, 1 Dec 2003, Edouard Gomez wrote:
> I'm about fixing kthresolding in 2pass2.
> 1/ My first error was to keep an old name that was not meant to be
> kthresholding at first, so min_key_frame_interval is not what it
> means. It's really kfthreshold. My patch will fix that.
> 2/ Now i'm also going to change the logic behind this setting. At this
> moment kfreduction represents the frame step penalty for iframes below
> the min_key_frame_interval. 20% is clearly too much.
> The number frame steps of penalty to apply is computed thx to the next
> iframe distance, which i think is wrong, because that doesn't take care
> of ivops burts. Old code from vfw did the same, slightly differently
> but did the same.
> THE QUESTION:
> So now i would like that you express what you think about
> MY OPINION:
> Playing with iframe bit allocation is really dangerous for quality.
> As long as iframes are really consecutive, we can safely play with its
> bit allocation because next frames don't depend on its quality. But old
> code and current code, jumps accros ivops to detect next iframes, so we
> end up lowering the bit allocation of frames being references.
> sequence @25fps
> This type of ivops sequence is the typical case where it should be fine
> to cut bits from the first 3 ivops because:
> - iframes will reach 100% of allocatable bitrate in a very small
> amount of time (it's 25fps, and the burst is only 4 frames)
> - all iframes are consecutive
> But this is mostly a theoretical case. Reality looks much more like:
> Basically, xvid is on the edge of i/p decision for each frame and most
> of the time distance>=2 is enough to trigger an iframe. But here,
> removing bits from their allocation impacts greatly on the P frames, as
> they were probably choosen P type for only one reason:
> - pass1 is done at quant2 and helps a lot in having clean MBs to
> predict from accuratly in most cases.
> And because of the i/p tight decisions, we end with a frame sequence
> that is no more so short. So playing with bits removing may end being
> really noticeable during viewing.
> So i see kfthresholdding as a very very dangerous parameter for quality.
> Should we consider the kthreshold limit as a sliding window size, as a
> simple distance (old/current case)... I'm really short on ideas.
> I just would like to fix once for all. So all opinions are welcome.
> Edouard Gomez
> XviD-devel mailing list
> XviD-devel at xvid.org
More information about the XviD-devel