[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