Cvs 2002-02-27 [Archive]

rui

27th February 2002, 15:16

By the way...

Why isn't the modulated quantization option already placed in the codec by default? Like me and Franko30 (right, Franko30? ;), i believe that there are out there lots of users who like it too.
And the other options are still there for the ones that don't like the modulated quantization.

Then, poor Koepi wouldn't have to read the anoying screams from guys like me asking for a new mod of the latest build :D

Nic

27th February 2002, 15:18

Thats a good question? It does seem a beneficial modification.

@h: whats stopping you from submitting Koepi's current code to the CVS and then adding mod's to that?

-Nic

Koepi

27th February 2002, 15:28

There's going to be an API change from Isibaar ("soon" *lol*), which incorporates the framebased quant type modulation.

Btw., there is still some serious bug within the actual builds.

Directly after first pass started a second pass and got horrible scales/quantizers.
(e.g., filesize already reached was half size of the overflow.... it used less bits than the sound!)
Looked like the "scaled to" variable got stuck within the range 1079-1082 (always fluctuating in that range), and the actual frames got something like 100 bytes, 500 bytes,... totally wrong.

Stopped that, checked my values, started again - now it looks ok....

thats so weird and annoying :-(

Regards,
Koepi

Franko30

27th February 2002, 15:37

Originally posted by rui

Why isn't the modulated quantization option already placed in the codec by default? Like me and Franko30 (right, Franko30? ;), i believe that there are out there lots of users who like it too.

Just returned from lunch (I had to pay myself - it's a hard life being a "user" ;)). And my "clients" - future tenants of a a shop I have for lease here - just didn't show up...

Adding quant modulation to the code would be nice; although I'm going back to h263 only, as stated in my post to the CVS 2002-02-26 thread.

Now it's time to download the newest fixed builds and encode a few more movies.

Cheers

Franko

rui

27th February 2002, 16:25

Humm... i thought that you were going back to H.263 for 1 cd rip's only.

Hope i'm not alone in this Modulated cruzade ;)

Franko30

27th February 2002, 16:33

Originally posted by rui
Humm... i thought that you were going back to H.263 for 1 cd rip's only.

Hope i'm not alone in this Modulated crusade ;)

Well, I mainly do 1 CD encodings - only for movies longer than about 125 min. I go for two CD encodings.

But you're not alone, I guess a lot of other people like Quant Modulation, too ;) . And I would be using it still - if I would do DVD backups. But my source material just looks better with h263 only.

Frank

Koepi

27th February 2002, 16:52

I#ve to agree there, for more noisy sources like TV captures it's unlikely that quant type modulation looks as good as for DVD encodings...

Regards,
Koepi

P.S.: you're definatly not alone, since I like quant_type modulation and use it all the time....

P.P.S.: I'm doing a third encoding with the new build and that bug I experienced seems to be gone. Dunno where it came from, maybe wrong values in the registry for the first time after installing... (hopefully)

rui

27th February 2002, 16:59

Man, you lifted a weight from my shoulders (for both reasons) :)

Koepi

27th February 2002, 18:29

I ran once more into the second pass trouble.

I solved it by using the open-dialog for the stats-file... Seems like the error is located there, some filehandle not cleaned up or something...

Regards,
Koepi

Ripe73

27th February 2002, 19:44

HI!

Encoded Blade Runner AGAIN!!!
With XVID2702 nic's both passes(INT.) with the same build.
Settings
576*240 Soft Bicubic with T.Smoother 2,1 before resize
M.Search:6
H:263
MainQ Min:1 Max:6
I-Frame Min:2 Max:4
S.Quantizer: ON
No L.Masking
No Creditfunction(encoded manual Q:16)
Payback:240 C.Compress High:25% Low:10%
First pass size:718 LOL
DivX DSfilter

Well i dont have any luck with this movie it look worse and blocky as hell in some scenes(Low motion).I have better result with this movie in the builds with no Curve compression even with out T.Smoother.

Is there something to try?

I can send a clip or some pic's if you want
But the filesize was very good 50KB oversized :D

sierrafoxtrot

27th February 2002, 19:58

@ripe73

maybe you could try lo/hi 25/25, don't know ... might work to allocate more bitrate to dark scenes so there'll be less blockiness?

worth a try ...

Ripe73

27th February 2002, 20:04

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

27th February 2002, 20:07

decided to remove my comment

Ripe73

27th February 2002, 20:11

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

sierrafoxtrot

27th February 2002, 20:14

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

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

27th February 2002, 20:44

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

27th February 2002, 20:55

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):confused:

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

Frank

Koepi

27th February 2002, 21:03

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

27th February 2002, 21:21

Just implemented working Post-processing :) (YaY!)

With the deringing filter (which DivX4a50 had in the source code, but not turned on :confused: 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

27th February 2002, 21:34

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

27th February 2002, 21:56

*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

27th February 2002, 23:07

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

27th February 2002, 23:44

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

27th February 2002, 23:50

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

28th February 2002, 00:21

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

28th February 2002, 00:50

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

Sygma21

28th February 2002, 00:53

May I have some explanations about curve compression settings ?

Koepi

28th February 2002, 01:09

Read the new XviD Options Explained, Sygma.

Regards,
Koepi

Sygma21

28th February 2002, 01:15

THX Koepi :)

I update my traduction ASAP.

Regards

sierrafoxtrot

28th February 2002, 01:38

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

28th February 2002, 02:07

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

I'll have a play tonight anyway.

-h

Foxer

28th February 2002, 08:54

I am thinking of modifying the current asymmetric curve compression error distribution to something a little less linear in addition to adding 'limited' encoding for target sizes which are larger than the first pass.

The way I have it working atm, is say you have 15% low and 25% high. With this, there's about 2.5% unused bandwidth and it currently scales all results by about 1.0256 to get the the desired size.

The way I am thinking of changing it to is instead of it scaling both high and low the same way, scale smaller frames with 2 * high% / (low% + high%) of the scale and larger frames with 2 * low% / (low% + high%) of the scale.

This way makes it lean more toward the less compressed area but it will produce a small bug, if you want to call it that, when the uncompressed framesize is very close to the average framesize.

With 15/25, a framesize just below the average framesize will end up being larger than a framesize that is just above it.

Now, the limited support for encoding videos which are larger than the first pass will currently act a little funny because quant1 framesizes are HUGE in comparison to quant2 so the root overflow has a little trouble dealing with such blows and usually over compensates and the quantizer choice error correction doesn't compensate enough since according to the current quantizer choice formula, there was only a small error in it's choice but in truth, the resulting framesize was 5 to 10 times what it expected.

rui

28th February 2002, 11:44

Regarding the 2 pass bug.

I just can't reproduce that bug. (sad for one side but very happy for the other :D )

I just encoded, in Vdub job processing, two small tests. One is a movie trailer, and the other is a chapter from another movie.
Both with 1 pass, then second pass. None of the two gave me any problems, both files came out o.k, almost with the size i wanted.

What can I say, i am a lucky man. :D

sierrafoxtrot

28th February 2002, 11:58

:mad: i seem to be getting overflows like nobody's business, i was using koepi's 27-02-2002 build with symmetric curve correction and Mod Quants. it crashed halfway through 2nd pass, but that's all at home ATM.

i'm trying a vob from amores perros (at work now), hopefully i can reproduce the problem and post debugview's log.

BTW it shouldn't be a problem if i use the stats file from any of the older builds from either koepi or nic for testing right? i mean, as long as i've set 1st pass quant type to H263, i can get away with H263 or Modulated 2nd pass?

ture/false?

cheers.

:p

rui

28th February 2002, 12:36

Originally posted by sierrafoxtrot
i mean, as long as i've set 1st pass quant type to H263, i can get away with H263 or Modulated 2nd pass?

:p

This is like I allways do. Choose first H.263 and then Modulated.

tangent

28th February 2002, 15:25

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

I tried this, but it still doesn't solve the problem for me. 2nd pass always crashes when i queue the first and second pass together in VirtualDub.

sierrafoxtrot

28th February 2002, 16:13

@all

just finished testing some params.

source: 1st vob from amores perros (26min 42sec)
1st pass (with nic's 27-02-2002 compile)
H263
m search 5
credits (10% till end of vob) I 20 P 20

2nd pass
inter 1-10
intra 1-4 smooth quant enabled
motion search 5
desired size: 212600

with nic's 27-02-2002
h263 asymmetric Hi 1 Lo 1 Payback 1 size: 213896
h263 asymmetric Hi 25 Lo 1 Payback 240 size: 213698
h263 asymmetric Hi 25 Lo 15 Payback 240 size: 212304

with koepi's 28-02-2002
Mod asymmetric Hi 1 Lo 1 Payback 1 size: 213894
Mod asymmetric Hi 25 Lo 1 Payback 240 size: 213696
Mod asymmetric Hi 25 Lo 15 Payback 240 size: 212462

so at least the filesize issue seems to be okay. i'll report back later with image quality (it's difficult to properly scrutinise several clips when your boss is lurking ;) )

BTW, the bug with 2nd pass crashing seems to be gone (on this comp anyway). don't know whether it's due to koepi's new build, or something else. i'm running w2k sp2 here at work, but at home, no sp2. could that be it?

anyway ... stay tuned. :)

EDIT: okay, managed to grab some pics for a quick compare. with koepi's build, the details are very much more apparent, and there's not a lot of blockiness. overall, i found hi/lo 25/1 to be pretty pleasing to the eye, but then again, with my settings i was encoding at over 1000kb/sec, and most things would look good.

for nic's compile of -h and foxer's code, using H263, everything was slightly blurrier, although i can't say much about macroblocks because the quality is amazing for both builds.

on the whole for asymmetric curve compression, i find hi at 25 and lo at less than 10 gives me nicer pictures for most movies, unless they're really motion rich. i find setting low at 15 takes away too mch from the smaller frames, everything gets blocky.

maybe what i should've done was encode at a lower bitrate, and make things more rigorous for the codec and let it exaggerate any effects of curve compression. might do that tomorrow ... LoL

@rui: just borrowed the replacements from a mate and might try encode a 1CD rip of that, it should be interesting ... :D

rui

28th February 2002, 17:59

Originally posted by sierrafoxtrot

so at least the filesize issue seems to be okay. i'll report back later with image quality (it's difficult to properly scrutinise several clips when your boss is lurking ;) )

LOL :D

By the way, i noticed that a lot of people that hang around here work, and use their working machines to do some test. One of this days i will make a thread so we can compare our boss's machines that we use to encode.
Mine is a shity P2-350 :(
It's more than time to upgrade, right? But i just can't convince him to do that :(

Originally posted by sierrafoxtrot

@rui: just borrowed the replacements from a mate and might try encode a 1CD rip of that, it should be interesting ... :D

GREAT. Please post your results here. I used a resolution of 576xXXX, on my 1 cd try. For the 2 cd, i used 608xXXX. But that was with the older builds. Maybe this new ones can get better results.

Franko30

28th February 2002, 20:21

Originally posted by tangent
2nd pass always crashes when i queue the first and second pass together in VirtualDub.

Sorry to post so late on an (already a little old) issue - my Internet access gateway was down due to a defect harddisc, then, as we were at it, we installed Astaro Security Linux...

Well:

My encodings went fine (3 movies, 2 Voyager episodes) except "A midsummernight's dream" on which (now for the second time) the VirtualDub crash occurs at the end (5 min. to go) of the second pass - leaving the output file unusable (even after re-derive keyframe flags in VirtualDub).:confused:

I'll keep on trying - maybe it only happens on very long credits like in the above mentioned movie? Or only with both credits quants set to 16? Maybe 12 would work and what would that mean? (For what happened, see my earlier post explaining the crash)

If only Nic's page could be reached, so I could try his build to compare...

Frank