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

[Christoph Lampert]

Hi,

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
flashing. 

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
be masked. 
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
generation. 

gruel 


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
> 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
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>