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

Edouard Gomez ed.gomez at free.fr
Mon Dec 1 21:34:08 CET 2003

Michael Militzer (michael at xvid.org) wrote:
> 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).

Yes that's exactly why i do a RFC so at least we all agree on
something, simple or smart but for which we _all_ agree now.
> 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.

The usual communication chain problem... announcements are clear (or not
;-) ) but the more intermediates/links are done, the more information is
lost :-(

> 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? ;-)

we are doing beta releases ATM, that's exactly what their purpose is.
> 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.

I'd even say a  bit more about these profiles. The profile  Id is set to
0x00 for all  divx profiles but this value is  a reserved code according
to the -2 2001 standard.

I also propose  to move the profile logic from vfw  to xvidcore where it
belongs to.

small ps:  where can i  find a complete  and up2date description  of the
           visual profiles ?

> 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?

I  did not  have  any  problem such  as  this one  during  my tests  and
transcode users did not complain on  IRC neither. I'll have a look but i
doubt there is such a big/huge bug left.

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

syskin commited something  concerning interlacing this afternoon (fixing
the completly artefacted blocks problem). See if it's right now.

IIRC, sysKin and I had a discussion on IRC about interlacing support for
bframes  long   ago.  I  even   remember  some  commits   following  the
discussion. Michael,  you should check  the sources, perhaps  support is
already included  and the only  bug was a  wrong stride value  (fixed by
today's patch)

On another topic:
>From  reports  on  doom9,  i  think  most  commits  will  be  win32  gui
thingies. I propose  to put back frontends to their  own module. I don't
want to do a core release for every single frontend tweaking/fix.

Edouard Gomez

More information about the XviD-devel mailing list