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

[Michael Militzer]

Hi,

just a short comment: IIII sequences occur when there's simply too much
changing in a scene (e.g. high motion + camera movement), so the scene-
detection works as it should. Usually it should indeed be safe to lower
the quality of the first I-frames in such IIII sequences without noticable
quality loss, however this all is a seldom case and the gain is pretty
small so I usually didn't take the risk and didn't use this option when I
was encoding something myself. I'm unsure about IPPI sequences - the big
risk from bad looking key-frames is that following frames predict from
them which might lead to a longer lasting deterioration of quality. So
I'd better not reduce the bits for these I-frames then. But after all,
it's just an option, so the user can and should decide what he likes best,
we just have to make sure that the default values are somewhat save, so
I'd say that this special keyframe handling should be switched off by
default (at least for IPPI sequences).

On another topic but related to 2pass: I've been reading the doom9
comments today and have noticed some things where we might need to react:

1) beta1 doesn't play on standalones - maybe out of the same reason why
fdam crashes when I tried to decode some dev-api-4 content. While I see
that both Ed and Koepi made it clear in their announcements that beta1 is
most likely not compliant due to not-yet-fixed bugs, I have the feeling
that many people over at doom9 seem not aware of this.

2) Lot of questions popped up about which profile to choose for standalone
decoder compliance (or which profile to choose to limit the bitrate to
4000 etc.) - I think we should make it crystal clear that beta1 does not
garantuee profile compliance due to missing VBV compliance. I mentioned
the missing VBV compliance already on the team-list, but noone seemed to
care (and I failed to do something about it myself as well). Nonetheless
I want to point this out again here: Without VBV compliant rate-control,
XviD streams won't be compliant to _any_ profile. They _might_ be
compliant, but we can't garantuee it, so if the streams play in stand-
alone devices without any problems, that's just luck - and we don't
really want to rely on luck, right? ;-)

3) Because of 2), we have to remove the DivX profile options asap. The
DivX chaps might be tolerant enough to let us create DivX profile
compliant streams (and add the DivX profile options to our GUI), but if
the streams that we're advertising as DivX compliant actually aren't DivX
compliant, I think they won't find this that funny anymore. So I think
we should _at least_ remove the DivX options from the GUI until we
actually are in compliance.

4) Someone (LigH iirc) reported that 2pass wouldn't work without b-frames
and showed a graph that should prove that all frames were simply quantized
with quant 31? Is there any truth in this report or did I just
misinterprete it?

5) As people also noticed: interlaced encoding doesn't work. That's true,
we know this and it's no simple thing to fix (because iirc the interlaced
encoding support is missing for b-frames, qpel and GMC and the interlaced
code that was present for the simple profile options is broken meantime).
So I suggest to simply remove the option from the GUI, maybe also mark it
as not working in the API, because I fear this won't be fixed that soon.

bye,
Michael

Quoting Edouard Gomez <ed.gomez at free.fr>:

> Christoph Lampert (chl at math.uni-bonn.de) wrote:
> > 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? 
> 
> It's always happening in flashing  situations. Trailers are good at that
> as Hollywood uses to do <1s shots of different movie parts to stress the
> audience and give a higher rhythm at their Trailer.
> 
> However the  first example i  gave is completly theoretical,  the second
> one can happen in real cases.
> 
> > 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.
> 
> exactly that ype of sequences, flashes, color inversions, strong cops
> lights.
> 
> > 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.
> 
> For this time, I don't plan any BIG change in twopass, it's just a small
> adjustment i would like to do. I think we should simply how to apply bit
> allocation reduction with some kind of smart decision (not a simple bits
> -= distance*step_reduction, which  IMO is non sense if  we don't look at
> the  ivop burst  duration  versus  frame rate,  and  importance of  each
> iframe insde the burst)
> 
> Moreover, all  this is  very hypothetical and  doesn't happen  so often.
> 
> > 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.
> 
> <out of topic>
> I appreciate  scene changes  ivops because they  are very good  at one
> thing: avoid  scene mixage  for the few  frames surrounding  the scene
> change. An ivop creates a clear cut.
> 
> It's like  some nasty scene mixage  when using bframes  w/o the closed
> gov option. When we have this sequence:
> 
> In Display order
> ... whatever frames ... PPBBI...... whatever type of frames
>         scene 1             |        scene 2
> 
> In this  case, the last bframes  are a ugly  mix of old scene  and new
> scene. I had some reports about  that on transcode ML or transcode IRC
> channel, i  don't remember exactly.  That's why in the  frontends i've
> written for  devapi4^W1.0.0 i  use closed_gop as  default to  insert a
> Pframe right before the scene changes so no scene mixage happens.
> </out of topic>
> 
> -- 
> Edouard Gomez
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>