XviD-24012003-1 (unstable)

[Koepi]

Hi folks,

a new unstable developer XviD build is up.

Changelog:

XviD-24012003-1:
- Fresh CVS checkout.
- Chroma ME in bframes, too.

Additionally, GomGom removed his GMC reporting code - GMC+bframes should work again (no oversized files). MMX'ed simple IDCT compiled in, refdivx' lumi masking code, ICL7-optimized compile,...

Have fun!

Regards
Koepi

[mikeson]

Great!! :)

Many thanks Koepi & XviD developers for this new build!

[nexus]

Great news!

testing..... :-)


--
nexus

[Selur]

Cool,.. :D

[Siku]

Thanks for a new build Koepi, I'm going to test it right a way! :D

[The Link]

For me there´s still the issue with the file size (too big) when using b-frames alone or b-frames + other features. When I just use I and P-frames (without anything enabled) it hits filesize on the point!

Regards,

The Link

edit: typo

[CruNcher]

Thx koepi great work but refdivx Lumimasking when activated crashs anybody experience the same problem ?

[Franko30]

Oversized here, too.

Used the standard settings (Linear CC) together with two B-Frames.

Desired Filesize 330008

Resulting Filesize 355720

First Pass Size 356377

Hmmm - too bad, back to Koepi's Dec. 03rd 2002 build... :(

Franko30

[terwin]

There is also an other problem. If I use bframes the maximum i-frame intervall isn't considered again.

cu terwin

[iago]

@Koepi,

Thanks for the new build man! It had been a while and I'd really missed your binaries! ;)

Currently doing a plain encode of "The Wall" (the crappy PAL version) with only I-P frames in the YV12 colourspace, so I haven't got any problems with the new binary yet! :D

regards,
iago

[Teegedeck]

...but the good news is, 2nd passes are not as massively oversized as before! :)

[sillKotscha]

Originally posted by Teegedeck
...but the good news is, 2nd passes are not as massively oversized as before! :)

hmm, that's not true, at least for me ;(

753491 KB turned out 995MB - hoppala :D

settings:


- first-h.263 (ultra-high), second-new modulatedHQ (ultra-high)
- quants: defaults
- bframes: max3, ratio 150, offset 100
- use chroma enabled
- payback proportinally
- credits: I/P-frame quant 20

regards sill

[iago]

Originally posted by sillKotscha
753491 KB turned out 995MB - hoppala :D :D Remember, it says "unstable" man! :D

[Teegedeck]

Originally posted by sillKotscha
hmm, that's not true, at least for me ;(



Yeah, well, maybe. :D But, man, you got to think positive and give it the benefit of the doubt.

[sillKotscha]

no doubt here, I'll always think positive - as it is stated 'unstable' I'd like to test it - and if I wouldn't test I wouldn't know ;)

the positive feedback - 995MB looked so incredible!!! :D

sound it like a complain?? - by no mean guys...

cheers Sill

[Iznogoud]

Best idea was to start a new thread, thanks for that :cool:

[Shayne]

Just using I n P here too.

Are people really finding a quality boost with B Frames now, last time i tested picture crispness was less?

Thanks for the new release, getting excellent results from Koepi's Jan 15 build and YV12. Definitely back up to snuff again.

[ookzDVD]

Just test with "very small" clip, Shrek's Duloc song ;)
it's 1min 04sec long.
With B-Frame(3/100/200), Qpel, ChromaME, GMC all are enabled.

1st-pass : 10240KB, Target : 5120KB, 2nd-pass : 8332KB.

Still oversize.

[Tester]

I've the same problem in this build (also with 03.01.2003 and 24.01.2003 build)

chroma motion and b-frames activated
using internal linear curve scaling (of course)


target size 1.285.000 k, the result was 1.594.500 k

[Franko30]

Hi,

maybe it would be possible to calculate a formula that considers the B-frame settings, movie length etc. and calculates the Filesize we have to aim for in order to get the desired filesize? :D :D

:stupid:

Anyone better in maths than I am?

OK - forget this post - I just couldn't resist...


Franko30

[Teegedeck]

BTW, finally our DivX-friends have updated their software, too.

Main improvements include a new API, an interlaced mode, a maximum bitrate, several passes instead of just two possible, unknown GMC-improvements (2 warppoints?) removal of features that never worked:rolleyes: plus minor bugfixes (still not the MPEG-quant-rounding bug?).

Nothing too exciting in DivX5.03 but they let well sound it like a technological breakthrough. The guy that wrote the changelog deserved his money. More than 20 lines in my browser just to explain the benefits of having a maximum bitrate??? :D

I think we can live with XviD's temporary bugs all the better after reading this. The thread to discuss DivX5.03 is here (http://forum.doom9.org/showthread.php?s=&threadid=43986)

[wing1]

bug report: playback issue

xvid builds up to Koepi's Dec.09.2002 & uManiac's Nov.29.2002 -> playback fine using DX50(4cc) at encode and Divx5.02 decoder.

all builds after the dates mentioned returned Green video. However, ffdshow and xvid decoders are functioning correctly. Is this a compatibility issue with Divx5.02 side?

[kilg0r3]

anyone tried encoding with external curve scaling?

[Siku]

I think that the oversize problem comes with B-frames(?). I encoded two clips with latest Koepi's build:

1)With Chroma motion, B-frames 3/150/100, Lumi masking and Alt. Curve Medium/100/150, strenght 50% in automatic minimum relative quality.
2)Same settings as above but without Chroma motion.

And both encodes had the oversize problem.

Next I'm going to make some encodes with latest DivX, let's see if it gives better results, though I don't really believe that it can beat XviD. Well, we'll see about that... :)

Regards,
Siku

[digitize]

Originally posted by Siku
I think that the oversize problem comes with B-frames(?). I encoded two clips with latest Koepi's build:

1)With Chroma motion, B-frames 3/150/100, Lumi masking and Alt. Curve Medium/100/150, strenght 50% in automatic minimum relative quality.
2)Same settings as above but without Chroma motion.

And both encodes had the oversize problem.


Hmm I haven't played around with the latest builds too much, but I don't think it's b/c of b-frames (which are made to be more effecient than p-frames). But even if it was, Siku, wouldn't it make sense to make a test encode w/out b-frames if you thought it was b-frames that bloated the file size...?

[The Link]

... Siku, wouldn't it make sense to make a test encode w/out b-frames if you thought it was b-frames that bloated the file size...?

As I wrote in my post: Without b-frames XviD hit the filesize on the point.

Regards,

The Link

[Siku]

OK, I'll make same some tests without B-frames. I would like to use B-frames because I've got pretty good results with B-frames (in fact, I've always used B-frames). So, maybe it's time to do some encodes without B-frames and with QPel and GMC (I've never tested GMC so far).
I'll try something new this time. :)

Regards,
Siku

[kilg0r3]

i am not entirely sure here, but it seems as if the above mentioned switch is not taken into account. if i understand its function, it should prevent the encoder to put a bframe directly after an iframe, which would then be refernced by the preceeding bframe. right? this, however is just the sequence i encountered in the stats file of the last test clip. i used koepi's statsviewer for this.

btw, external scaling doesn't work either

[AmiRage]

Originally posted by The Link
Without b-frames XviD hit the filesize on the point.
Same here ... "everything" is fine with B frames disabled.

BTW: Where can I find older, unstable Koepi builds? Is there an archive or are they still somehow available on the homepage?

EDIT: Thanks, kilg0r3! :)

[kilg0r3]

@ amirage
go (http://www.mynetcologne.de/~nc-allgeife8/)

[SiXXGuNNZ]

Originally posted by kilg0r3
@ amirage
go (http://www.mynetcologne.de/~nc-allgeife8/)

thanks for the link, I have been looking for it :D

what is the reccomended build?

I seem to get great looking video with the october build, but would love to try out a newer build with the newer features in it :D

[ErMaC]

Does the first pass workaround work with this latest koepi build? (using the uManiac 1301 build for 1st pass, replace with newest Koepi for 2nd pass) The b-frame=oversize is a big issue for me.

[iago]

uManiac's "XviD.Alpha.13.01.2003.1500" build hits the right target size with b-frames (2/100/200) in my couple of short tests here.

[Teegedeck]

And, looking at the changelong, it seems to use simple IDCT, am I right? Let's give it a whirl.

iago, have you got yourself a new mainboard, now? Good to see you here, again.

[Tueurne]

oversize in external too

[sillKotscha]

huge changelog concerning XviD.Alpha.26.01.2003.1100 by Umaniac

[http://umaniac.leffe.dnsalias.com/alpha/alpha.html]

it's time to test :D

regards Sill

[iago]

Originally posted by Teegedeck
iago, have you got yourself a new mainboard, now? Good to see you here, again. O/T

@Teegedeck,

Yes, after that mainboard disaster I had, I finally got my system working again with a "downgrade" to a shitty motherboard with no AGP slot and only 8mb Trident Blade 3D onboard video! Great, isn't it (especially when accompanied with a Celeron 900 and 256mb SDRAM)?! :D

That's why I don't comment on visual quality but talk about only the technical aspects of things lately! :D

regards,
iago

[Teegedeck]

:D Well, I'm still stuck with a Celeron 466 (128 MB RAM) that has to be rebooted like every 6 hours...

uManiac's server has got unbearably slow over the last couple of weeks; I'll have to give his build a miss if it continues like that...:rolleyes:

EDIT: Hey, we could have a who's-got-the-slowest-PC competition over here. [EDIT: I am joking.] Would be a change from who-gets-most-fps... Tho I got a feelin' that some of the developers could well have chances winning this one.

[sillKotscha]

I think oversized problems are almost gone :)

did a short test [7500frames of 'Signs'], target 758644 KB
- DivX[5.03] = 36,5 MB
- Xvid[latest Umaniac] = 37,2 MB

encoder(s) set to defaults (except xvid's b-frames turned on [2/100/200]) - DivX, original 2pass_encoding. I've used this simple script, along with avisynth_2.5 ...


LoadPlugin("[~]\mpeg2dec3.dll")
LoadPlugin("[~]\BicublinResize.dll")
mpeg2source("[~]\VTS_01_1.d2v")
crop(12,12,696,552)
BicublinResize(528,288,0.5,0.75)


in terms of quality I can't see any differernce [developers will definitively argue the converse, I guess :cool: ] !!

@Teegedeck: I won't talk about speed :D

regards Sill

[kilg0r3]

for probabely faster downloads of umaniac's latest instant build go to where (http://www.mynetcologne.de/~nc-allgeife8/) i sent amirage.

[iago]

Originally posted by Teegedeck
Hey, we could have a who's-got-the-slowest-PC competition over here. [...] Would be a change from who-gets-most-fps... Tho I got a feelin' that some of the developers could well have chances winning this one. LOL! Yeah, I'm absolutely for this competition! :D

I'm sure Koepi will run for championship too! :D
(Hey, man, where have you been lately btw?! ;))

Well, back to topic, I'm currently running some 1pass q2 tests with the latest uManiac build with all the fancy options enabled, and everything seems to go fine so far.

regards,
iago

edit - but qpel smearing still seems to be there when decoding with libavcodec

edit2 - so does the greenish color artifacts

[Mango Madness]

the slower the computer, the more optimizations must be made ;)

Good times ahead, testing umaniac's latest build and divx 5.0.3. I'm seeing some good FPS on both fronts and almost hitting realtime with divx (would be the first time this machine has done that).

[kilg0r3]

so does the greenish color artifacts

whoops, havn't heard of these. where did you mention them?

[Koepi]

Well, well, I have a faster machine now, I'm not the "back light" anymore :)

Duron1.3GHz, new MoBo (KT266A chipset, ufortunately didn't POST after the 2nd boot anymore - should have it back in 2 days)... in some days even DDR RAM instead of SDRam.

So my machine is usable for encoding again ;)

I'm currently testing latest CVS but I doubt it'll work out. If it does, I'll put the binary online. You need a newer libavcodec to decode qpel xvid's [simple idct is mandatory for it too] correctly.

Regarding the question where I am the last time, I have a job now which takes up much of my time, but at least I get to few money ;) [hm. better having some money than having no money at all, right?]

Ok, so far a status update from my side - have fun & enjoy! :)

Best regards
Koepi

[NiTroGen]

Originally posted by iago
Well, back to topic, I'm currently running some 1pass q2 tests with the latest uManiac build with all the fancy options enabled, and everything seems to go fine so far.
There is still this problem with the stats file; almost every b-frame is reported as delay, skipped and pad. I've attached an example of a stats file and its report of StatsViewer.

[peaudepailles]

Hi all,

I've been doing some tests with Koepi's lastest build and got oversized files each time using the fallowing settings :

first pass:

*h263
*only bf 3/100/200
or bf 3/100/200 +GMC
or bf 3/100/200 +GMC +qpel
second pass:

*Min/Max I-frame quantizer: 2 - 4
*Min - Max P-frame quantizer: 2 - 8.
*payback proportionaly

Well total encode or part of film are oversized but thats something you already know.

But using the same settings with Koepi 03/01/2003:

only bf: desired files size +/- 1MB
bf + GMC: The same
bf +GMC + qpel: the same
(Both with total encode or part film)

Dont know if it is known anyway

Thanks to THE Team ;)

Peaudepailles.

[ookzDVD]

uManiac's XviD.Alpha.26.01.2003.1500.exe,
is still have oversize problem.

[Tester]

Originally posted by ookzDVD
uManiac's XviD.Alpha.26.01.2003.1500.exe,
is still have oversize problem.

I can only confirm this:

spiderman: (bframes, chroma motion)
target size: 1 285 000 k
final size: 1 600 000 k

additionalley, this build seems to be very slow, only 12-13 fps on my athlon 2000+, someone other experienced this?