XviD-19062003-1

[Koepi]

Aloha,

a whole month without a new build, amazing XviD's getting somewhat stable I think (I'd nearly say sorry for the delay, but I wanted to test that build a little before releasing it. It works absolutely fine for me.)

XviD-19062003-1:
- CVS update.
- sysKin's new i/p/b-decision. New thresholds: -40 disables bframes, +90 produces only bframes
- sysKin's new VHQ fixes.

There are some features in which I already forgot etc., but you can read most of them in the CVS changelog at umaniac's

Please do some testing like you did with the last build, the PSNR-tables were pretty impressive.

Find the build clicking on the "www"-botton below this post or use the link in my signature.

Best regards
Koepi

[The Edge]

Cheers Koepi.
I can almost smell stable XviD 1.0
Will test tonight.


Bren

[JagPanzer]

Aloha!

Thank you, thank you, thank you...

It's time to do some tests now...

[Koepi]

A first observation:

bframe-settings: 2/150/75/0 seem to give impessing results (currently compressing 1GB 1st pass to 650mb 2nd pass at average quant <2.5 ).

Just as a hint.

regards
Koepi

[kaitsuburi]

Thank you Koepi!

Just finished a quick 2-pass encode of "The Flight of the Osiris" -- worked like a charm. The quality is awesome!

-kaitsuburi

[Garfield]

Thanks Koepi, another update of our favorite toy


I just have a few dumb questions :

-40 disables bframes, +90 produces only bframes

Does that mean that 90 is the highest treshold value ?

sysKin's new VHQ fixes.

So now it is safe, stable and good in any mode for sure ? ()

[Koepi]

You can add higher values as well, but you won't notice much difference. That comment is there to make the new range clear.

It was safe before to use VHQ, it didn't break anything (badly). It should be safer now, only tests will show (I use vhq 4 [or 0 when i'm in a hurry] without problems).

Regards
Koepi

[kilg0r3]

1.)
anything new about trellis quant (don't quite remeber what the problem was)? The changelogs at umaniac's do not contain all insta builts, seems to me, at least.

Sorry, it's very hot in here ... praying for a nice thunderstorm ...

2.)
Something from the mpeg2-quality thread

originally posted by trbarry And I don't know if it is my imagination or not, but it does seem that it's not really possible with Xvid anymore to get really detailed high bit rate HDTV encodings. But I've wondered this before and found it was just me, screwing up my encoding parameters, so maybe it is again. But something does seem different recently.

[sh0dan]

Looking good!

Minor stuff: The text displayed, when hovering over VHQ mode should probably be updated (as quality doesn't decrease with VHQ > 1). Or am I mistaking?

[Koepi]

Oops, update needed there indeed

Thanks for pointing that out

Trellis quant is still the same code as in my last build, nothing changed there.

regards
Koepi

[Selur]

1st thx for the build
2nd since latest changelog just came:

23.6.2003 17:40:
U xvidcore/src/motion/motion_est.c (rev.1.71) syskin:
- ugly bugs fixed, R-D works better now
U xvidcore/src/motion/motion_est.h (rev.1.9) syskin:
- ugly bugs fixed, R-D works better now

I wonder if you could update to XviD-19062003-2, so we might even test a bit more with R-D


Cu Selur

[Koepi]

Those bugfixes are the same as in my build, the only thing that _may_ have changed is thresholds for bframes-decision... which is just a bit more of testing IMO as sysKin tends to optimize with single sources and not different ones Just kidding, I still think it's worth to test the difference on _many more_ sources.

regards
Koepi

[Selur]

Oh,.. if those fixes are included I'm happy
Thx for the info

Cu Selur

[Teegedeck]

Hello Koepi,

thanks for the new build (and many thanks to sysKin for his work, too!)!

First impressions of an encoding with your build, compared against an identical encoding performed with uManiac's CVS-checkout from 11th, are very positive. Considerably less blocks in a 'too-low-bitrate' encoding. May not be too low, soon.

Anyway, one thing I wanted to ask: Do you still have that tweaked lambda-value in your build? I'd thought sysKin said something of the sort 'VHQ isn't there for saving space anymore'?

[Selur]

and a little questions about "+90 produces only bframes":

Does this mean "maximum Bframes" will not be respected and there'll be no more Pframes ?

What if "maximum bframes" is set to zero ?
- Will the bframe threshold still produce 'only bframes'?

How is the bframe threshold scaled?
(I mean earlier it was scaled in percent (as far as I know), but how is it scaled now? )

Cu Selur

[plazz2000]

What is happening with GMC? Will it be fixed for 1.0?

[Koepi]

Selur:

take a test sequence of 20 frames and find out for yourself (and report back here of course). I don't think the new ipb-decision will mess up that badly. it will be more like closed GOP.

plazz2k:
This thread is about this actual build. So please stay on-topic. I think skal and gruel have some nice GMC code at hands in dev-api-4(=will become 1.0), but it's not backported. Don't expect much efficiency out of GMC though.

Teegedeck:
that#s a good question - all the file-circling and updating make it impossible to track every change. It's very likely that I have other values in the sources now (sysKin's tweaks ). I'll go and check that - later, tomorrow.

Regards
Koepi

[Teegedeck]

Whatever lambda, the results are great! Closer examination just reinforces my first impression: A good quality boost, again! This may be the breakthrough for B-frames that should prompt even anime-encoders to switch them on, finally.

[Selur]

did a smal 30frame sequnce.
(monotone scene someone speaking, no backround action)

Does this mean "maximum Bframes" will not be respected and there'll be no more Pframes ?

No, "maximum bframes" (in a row) will still be respected, so a 30frame sequence could turn up with 1 Ifram, 15 Pframes and 14bframes (if max bframe is set to 1)

But what confuses me is that if I set "maximum bframes" to 10 and threshold to +90, I still ed up with 1 Iframe, 12 pframes and 17 bframes,.. (thought "DX50 copatibility" caused this, but disabling it, didn't change the distribution)

What if "maximum bframes" is set to zero ?
- Will the bframe threshold still produce 'only bframes'?

If "maximum bframes" is set to zero, no bframes will be produced.

How is the bframe threshold scaled?

No clue,.. especially since I can't say: "+90 produces only bframes"

Cu Selur

Ps.: got the distribution infos from statsview,..
(hope that's okay)

[sysKin]

Hi,
Since I'm here, instead of learning for tommorow:

About 'max bframes' - the statement "will produce only bframes" means that the decision itself will always say 'B' or 'I'. After the 'max' has been reached, B turns to P anyway. 'Max' is always respected.
But the statement is not 100% true anyway, because every next b-frame has its threashold decreased by 20. If you always want 10 bframes in a row, the threshold will have to be 90+9*20 = 270 ))

In any case, threshold above 40..60 will just remove any smartness of the decision. If you want to experiment, go for +/- 10 first.

About lambdas and VHQ: VHQ still decreases filesize. It wasn't the case in the last build becuase of the bugs. Lambda is still 1.00 , I don't think changing it will have any big effect (on constant-bitrate/constant-filesize. It will have effect on constant quant, but that's not what we do*)

I have a favour to ask - could you please check the new keyframe-decision? Does it miss any scenechangs? If yes, are the scenes dark or bright?
Does it put any unexpected keyframes, which hasn't been there in last build**?

Thanks,
Radek

* well, if you do 'compressability test', you care about constant quantizer result. Another prove that compressability value just stopped showing anything after divx3.11.

** like at the beginning, or in the middle, of any fade