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

saVe

28th February 2002, 20:35

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

nic's page works for me...

kastro68

1st March 2002, 11:32

Try Virtual Dub 1.4.8

Nic

1st March 2002, 11:41

Bladerunner is a complete nightmare of a movie to do ! The quality of the film it was converted from was ever so poor....

....Good luck with it :)

-Nic

Franko30

1st March 2002, 12:51

Originally posted by saVe

nic's page works for me...

Nope - not yesterday and not today - 404 page not found...

Frank

Nic

1st March 2002, 13:06

www.freewebz.com/xvid

should be absolutley fine :) Please check for me

However,
xvid.stormpages.com is unreachable....
....but so is www.stormpages.com at present!!!!

Cheers,
-Nic

Koepi

1st March 2002, 13:06

http://www.freewebz.com/xvid/

works :)

Regards,
Koepi

Ripe73

1st March 2002, 13:08

Bladerunner is a complete nightmare of a movie to do ! The quality of the film it was converted from was ever so poor....

Yepp,i finally did it on 2cd's 640*xxx this movie compress good but it need lots of bitrate to look okay it still not the best rip but i dont want to spend more time on it and have seen it so many times now and i think i never will see it again:)
But i have to say it looks better with no Divx DSfilter.

Franko30

1st March 2002, 13:19

Juchei und Juhu!

"A midsummernights Dream" produced the end credits crash for the third time. This time I tried credits quant 13.
Well, now that I have the alternative download address (forgot he had two) of Nic, I'm going to try his binaries - or do they have the same bug?

Should I encode this movie without end credits settings?

After Lunch I'll have a look if anybody answered.

Frank

Koepi

1st March 2002, 13:26

It has the same bug as I just included the modulated quant_type again, which doesn't do aynthing to the credist or scaling stuff...

But you might give it a try. Might be that my debug-variable gets an overflow and thus crashes vdub...

Regards,
Koepi

sierrafoxtrot

1st March 2002, 13:30

@koepi

hi. finally encoded a whole movie last night (swingers). quality was brilliant, with the exception of a couple of dark-ish scenes. thing is, i noticed in debugView that the the number of frames exceeds that of the movie (??) and i get massive overflows (last was 515550) the moment VDub gets to the credits section (const quant).

thanks again for the stonking quality throughout!:D

Koepi

1st March 2002, 13:34

Those overflow "errors" are inspected and thought about.

The debugview frame# have _nothing_ to do with the real frame numbers. If you do a first and a second pass without closing debugview or clear the display you'll notice that the start frame is _way_ higher than 0 ;)

Regards,
Koepi

-h

1st March 2002, 13:35

Fixes are coming "soon" (inside an hour). It'll actually be tested for once :)

Of course that doesn't guarantee that it'll work for everyone..

-h

tangent

1st March 2002, 14:27

Originally posted by kastro68
Try Virtual Dub 1.4.8
I did. I just tried to encode 2 other movies, Gladiator and Blade and they turned out okay. Matrix is the one crashing on me after 97% of the second pass.

kastro68

1st March 2002, 16:28

Can't help you there, it might be the credits though.

Hey, you use Ogg Vorbis audio for your Xvid encodes? It is fine if i don't fast forward, or rewind...but when I do the audio goes out of sync.

tangent

1st March 2002, 18:31

No problems with sync (i'm using Ogg container), but playback seems a little more jerky than DivX4

philippas

1st March 2002, 23:42

I just finished Saving Private Ryan ,with Koepi's build 28-02-02, and i have to say the quality is very good.
But the film got oversized by 9mb. The calculated size was 1334mb and i got 1343mb(the size is for 2x800mb cd's with 192 vorbis audio). I used H.263 quantization for both passes Quant lock 1-5, ultra6, and curve comp =10%,10% and min-max kf = 10-250.
EDIT: credits where encoded with constant quant = 8

Anyone else got oversized movies?

saVe

1st March 2002, 23:51

a LITTLE oversized: only about 50 mb....

maybe it was my fault after all because my settings were too strict :(
who cares, quality is close to perfect, so i'll go get some 90 min cdr's ;)

saVe

1st March 2002, 23:54

damn! shame on me!

i forgot that i merged the sound already, so my file is undersized... the quality is even more imressive when you take this into account! ;)

(note to myself: next time think before posting ;))

Teegedeck

2nd March 2002, 01:55

@Foxer: Is there no minimum bitrate of any kind implemented? When I use lower CC values than 20, some small frames get scaled down to 0 or even -1. Naturally this adds to overflow...

Foxer

2nd March 2002, 03:31

@Teegedeck

ATM there is no minimum bitrate other than low% of average framesize but that could be implemented.

There was a problem in my asymmetric curve compression prepass code (forgot to reset the framenumber to zero lol) so it messed up if credits were set up.

I apologize.

-h is getting ready to upload a new vfw with the fixes we've found to date and keyframe boost, and it works fine with credits enabled heheh :)

Neo Neko

2nd March 2002, 05:49

Hey Koepi, -h.
What's up Nic I have not spoken with you for a while. :)

Got a question for you guys. I have been downloading all the new Xvid compiles off of Nic's page as they have been comming up. But the one for 2-27-2002 is giving me real problems. When I install it all captures and encodes that I had done previously are fine. But any encodes done after the install with either XVID or Divx are extremely messed up. I have tried changing all the settings I could and still no luck. I tried un-installing XVID, Divx, all related registry entries, and any stray files on the HD. But even then after a re-install of Divx, encoding was still incorrect. I had ghosted my system right before the first install of that codec so I was able to recover from there. I installed it on my once again clean system and boom the exact same problem. It can be and has been reproduced on my system at least.

What's happening is this. There is a diagonal section of the frame from the top left to bottom right corners where the frame is displayed correctly. The bottom left and upper right corners are split in half, swapped, and rotated. On top of this every other scan is displayed in greyscale and the others in full color. I did not think to do a frame capture at the time but I have gimped a recreation from memory. http://interface.darktech.org/files/xvid.gif

Like I said this happens with both Divx4 and Xvid after the 27-2-02 compile is installed.

-h

2nd March 2002, 06:08

Sounds like a misreported stride, which is symptomatic of having resolutions not multiples of 8 or 16 (the only safe resolutions for XviD).

If you're using resolutions which are only a multiple of 4, they should still be playable using the DivX4 decoder. Below 4, however, nothing can decode an XviD stream properly it seems. We still have work to do with padding..

If it's an actual core bug, can you upload a sample clip that I can scare the core guys with? :)

-h

Klumsy

2nd March 2002, 14:21

okay, i encoded Tigerland twice, usind Koepi's binaries.
First I used the 2002-02-25, then 2002-02-28.

I used the same settings, but in the newer build, I used 15%/25% for curve compression, payback: 720 frames.

Resolution 720*384 sharp bicubic, no filters
Credits 140473-145294 @ 15%
Desired Filesize: 1342114
Motion search precision: 6
Quantizer: MPEG/Modulated
Max KF intervall: 250
Min/Max Quant: 1/31
Smooth quantizer fluctuation enabled

25feb: 1342364kb
27feb: 1308518kb

so with asynchronic curve compression it's ~34MB undersized.
and the quality has been lowered, especially in dark scenes
where i get more macroblocks now.

I will try Koepi's latest build, 2002-03-02 now.