[XviD-devel] [RFC] kthresholding in 2pass2

[Edouard Gomez]

Hello,

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
kthreshold/kfreduction.

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.

eg:
sequence @25fps
IIII

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:
IPPIPIPPI

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