Cvs 2002-02-27

[Ripe73]

maybe you could try lo/hi 25/25,

The Low% is how much bits will be taken from the bitrate under average bitrate and 25% will make this lowmotionscene worse i think,i used 10%.

I dont know.

[kastro68]

decided to remove my comment

[Ripe73]

Is it possible to disable this Curve compression?
etc
Low:0% High:0% to see if it will be better.

[sierrafoxtrot]

okay ... here's kind of what i've pieced together (somebody correct me if i'm wrong).

if you set curve compression for hi-pass at 25%, whenever a frame is above average, the bitrate gets lowered by some proportion <insert funky math soemthing*0.25>.

when the bitrate for a frame falls below the average bitrate, the specified percentage gets *added* to it. i mean, why would we subtract bits from an already small frame, it would only makes things worse right?

so therefore, for simplicities sake, the % value of hi gets subtracted from higher-than-average frames and the leftover is added to frames which are smaller than average.

<insert sheepish expression> is this correct?

-h, koepi, nic?

cheers.

EDIT:

@koepi, i found this on the CVS 2002-02-26 thread ... is the math right? i thought that curve correction should *add* bits to to the smaller frames with leftovers subtracted from larger frames? or (according to what you posted below) does curve correction just favour frames close to the average size whilst whittling quality away from the high and low frames?

this is doing my head in ....

-----------------------------------------------------------
Nope, you have to think more like:

800 - ((800 * scalefactor) - (800 * scalefactor) * 1-low%)
1200 + ((1200 * scalefactor) - (1200 * scalefactor) * 1+ high%)

e.g.

800 -((800 * 0.8) - (800 * 0.8) * 1-0.15) = 800 - ((800 * 0.8) - (800 * 0.8)* 0.85))) = 800 - ((640)-(640)*0.85)) = 800 - 96 = 704

1200 +((1200 * 0.8)-(1200 * 0.8) * (1+0.25)) = 1200 +((1200*0.8)- (1200*0.8) * 1.25) = 1200 + (- 240) = 960

instead of

800 * 0.8 = 640
1200 * 0.8 = 960
... (scalefactor 0.8 and high% of 25 is a break even point in our example it seems )

Those formulars aren't correct in any way but give you an idea how it works (hopefully).

So huge frames get more bits "taken away" as smaller frames if setup with low% = 15 and high% = 25.

Regards,
Koepi


__________________

[Koepi]

No, we need to reduce the size, that's the main idea.
But we reduce LESS on smaller frames and MORE on bigger frames.

(if low% < high%)
OR
we don't smoother the effect

(if low%=high%=0 )
...

etc

I hope this helps.

[Franko30]

Originally posted by Koepi
No, we need to reduce the size, that's the main idea.
But we reduce LESS on smaller frames and MORE on bigger frames.

(if low% < high%)
OR
we don't smoother the effect

(if low%=high%=0 )
...

Weeeeeellll, let's get this straight:

If you say "we need to reduce the size" then your reference is the Quant 2 expected filesize of the first pass and this has to be "scaled" so it fits the desired filesize and during that process more bits are taken from bigger frames and less bits from smaller frames so we can end up with the desired filesize. Right?

Your example "or we don't smoother the effect (if low%=high%=0 )" doesn't mean anything to me (can't figure out what you mean)

I guess it would really be easier if we all had used Nandub before - wouldn't it?

Frank

[Koepi]

A ig "yupp".

With "smoother the effect" I meant the "curve smoothing"-effect. (Think without the payback delay, every frame would directly get scaled down to the available bitrate...).

Regards,
Koepi

P.S.: still have to take a look at Foxer's implementation, maybe I'm wrong with what I tell. This smoothing can be done in more than one way....

[Nic]

Just implemented working Post-processing (YaY!)

With the deringing filter (which DivX4a50 had in the source code, but not turned on The image is gorgeous(!!!), however,
1) it still may not be a perfect implementation
2) my first algorithm works better than it on real low bitrate material.
3) if you want de-ringing (on Y,U & V) then you better have a quick comp (my Duron 800 has quite a bit of trouble! - (So that might countr koepi out!)
4) Haven't updated the interface yet

So, it will take till the weekend, (im down at the Ministry of Sound tomorrow & probably going out Friday too), but im well on my way.

Take Care,
-Nic

[Koepi]

That's very nice to hear Nic! Thanks for the good work

Maybe it didn't got switched on in ODivX because it's so slow... some of our optimisation gurus could jump in there I guess

Best regards,

Cheers!

Koepi

[Teegedeck]

*sigh* I'm a bit afraid to ask: The code of these filters isn't under GPL, is it?

[EDIT:] Just realized that I've turned into an old spoil-sport today! Thanks, Nic! The pace of things really isn't slowing down a bit. What will be next?

[Franko30]

Hi again,

VirtualDub just crashed at the end of a 2nd pass I ran in the job queue. I did it on my Athlon PC Win98 (see signature) with Debugview running in the background with log to file, so I can give you the last lines of the output:

credits started in line 00174302

00174302 9840.08307920 [Virtuald] 2nd-pass: quant:16 type:.h263 inter stats1:1173 scaled:13043 actual:1260 overflow:8777 credits
00174303 9840.13931200 [Virtuald] 2nd-pass: quant:16 type:.h263 inter stats1:2264 scaled:13043 actual:2313 overflow:19483 credits
00174304 9840.20611920 [Virtuald] 2nd-pass: quant:16 type:.h263 inter stats1:1830 scaled:13043 actual:1813 overflow:30689 credits
(...)
00175355 9900.89632080 [Virtuald] 2nd-pass: quant:16 type:.h263 inter stats1:3096 scaled:13043 actual:3096 overflow:11170889 credits
00175356 9900.94344160 [Virtuald] 2nd-pass: quant:16 type:.h263 intra stats1:14703 scaled:13043 actual:14703 overflow:11169205 credits
00175357 9900.94346000 [Virtuald] 2nd-pass: quant:1 type:mpeg4 intra stats1:14703 scaled:13043 actual:-2092130304 overflow:2103312528 credits

Please note that
a) the overflow keeps building up more and more
b) the last frame before the crash switched to MPEG quantization - although h263 was to be used...

The settings as follows:

Koepibuild of today XviD-27022002-1
search precision 6
H263 only
min max KF 10-300
"normal quant" 1-10
no luma masking
I-Frame quant lock 1-5 with smoothing enabled
credits settings I and P Quant 16
bitratepayback 240
curve compression 25 high 15 low

After restarting the system I started the whole process again from first pass - and in the morning I'll know if I could reproduce the crash.

My afternoon encoding of Voyager turned out perfect with these binaries and settings - but I didn't use credits on that.

Frank

P.S.: A big "two thumbs up" and "Thanks!" for post processing.

[Koepi]

That's the error I reported before.
It seems the file doesn't get opened correctly or something.

You can avoid this by opening the stats-file from first pass via that dialog in the codec setup _after_ setting encoding mode to "2nd pass - Int". (So no job processing without crash possible this time...)

Sorry I wasn't clear enough

Thanks for your continously testing our stuff

Regards,
Koepi

[rui]

I just finished a VERY GOOD 1 cd rip from the movie Platoon.
The final filesize, with audio, was 698 MB. No big problem. I admit i was expecting to it 700MB exactly, but maybe my Gnot configurations weren't the best in calculating the video size.

My settings were:
Latest Koepi's buid
search precision 5
H263 for first pass, Modulated quantization for 2 pass
min max KF 10-300
"normal quant" 1-31
no luma masking
I-Frame quant lock 2-6 with smoothing enabled
credits settings I and P Quant 31
bitratepayback 240
curve compression 25 high 15 low.

I haven't found any bugs with this build. Hope that the bug that Koepi mentioned doesn't show is ugly head around here

[saVe]

i have experienced some VERY strange things with nic's build from 27/02/2002. i captured some really useless stuff from tv source using huffyuv, about 5 minutes of crap, and tested.

my settings:
always 2pass, 2nd pass internal, expected size 21 mb, no credits, h263

test 1: curve compression high 25 low 15, i-frame restricted to 2-5, smooth quant enabled, everything else is default
-> size 8 mb

test 2: curve compression high 15 low 25, i-frame restricted to 2-5, smooth quant enabled, rest default
-> size completely on target

test 3: curve compression high 25 low 15, i-frame not restricted(1-31), smooth qunat enabled, rest default
-> size 8 mb

test 4: curve compression high 25 low 15, i-frame restricted to 2-5, smooth quant enabled, rest default
-> size 18 mb

the problem is i want to use the cc like in 1, 3 and 4. first i thought my settings for i-frames were to aggressive but that would have produced an oversized file, relating to what i learned in older threads . so i don't really understand what's going wrong here. it seems as if the codec used the highest quant possible instead of the lowest in order to get an exact filesize. is there something really stupid i am missing?

P.S. before koepi asks: i reopened the stats file manually everytime AFTER selecting second pass

[rui]

Originally posted by Koepi
That's the error I reported before.
It seems the file doesn't get opened correctly or something.

You can avoid this by opening the stats-file from first pass via that dialog in the codec setup _after_ setting encoding mode to "2nd pass - Int". (So no job processing without crash possible this time...)

Sorry I wasn't clear enough

Thanks for your continously testing our stuff

Regards,
Koepi

Strange thing. Like I said above, I just made a successful rip using Vdub's job processing. No problem whatsoever.

[Sygma21]

May I have some explanations about curve compression settings ?

[Koepi]

Read the new XviD Options Explained, Sygma.

Regards,
Koepi

[Sygma21]

THX Koepi

I update my traduction ASAP.

Regards

[sierrafoxtrot]

found a workaround for the vDub job control crash ... just use notepad to whip up <movie>.stats that way all the parameters are fulfilled without everything nosediving at the beginning of 2nd pass!

@rui eh? seems like this bug is pretty random. lucky you, in any case ...

[-h]

Re: 2nd pass crash. Sounds like a bug that has been introduced? Odd really..

I'll have a play tonight anyway.

-h