XviD-1.1.0-Beta1

[Koepi]

Ahoy,

the announcement on xvid.org is still missing but will be there anytime soon - XviD 1.1.0 Beta1 is available.

XviD-1.1.0-Beta1-16012005:
- {core}: Rate-Distortion mode decision for bvops.
- {core}: Two new postprocessing functions, brightness and deringing.
- {core}: VBV support in 2pass mode
- {core}: Overal encoder speedup, especially for b-frames and all vhq modes.
- {core}: Overal speedup of the decoder, merging decoding steps together
in order to save significant memory bandwidth, enabled mmx
qpel support that was misteriously disabled in 1.0.x. All optimizations
could lead to a 25% speedup, and something closer to 12% in average.
- {core}: Fixes to the CBR/ABR rate controller, it should work much better with
bvops now.
- {core}: Fix to the 2pass2 code that could cause doubling the overflow.
- {dshow}: Support for brightness control.
- {vfw}: Many small improvements.

Please head over to www.koepi.org and test the new binary and report errors! :)

Cheers
Koepi

[CruNcher]

Jep finaly :)

[Enigmax]

Santa Claus could bring you an official beta release

:rolleyes:
Koepi = Santa Claus
:) :) :) :) :)

Greetings

[PlazzTT]

Great! Thanks Koepi!

Is the date on that change log above correct? November?

[Koepi]

Oops, of course not. I didn't properly change the numbers in the releasenotes, sorry. Uploading fixed build, should be available now.

Cheers
Koepi

[CruNcher]

Koepi i think you should also credit the changes that aren't Windows Build specific.


+ Brand new PowerPC port by Christoph Naegeli
(MacOSX users may be interested by the Quicktime component,
have a look at http://people.ee.ethz.ch/~naegelic/index.php)

+ Brand new amd64 Linux 64bit port by Andre Werthmann

+ Out of the box yasm support (Required by the amd64 port, see:
http://www.tortall.net/projects/yasm/)

+ More ELF friendly assembly code for the ia32/amd64 ports
(functions are declared as functions, and their size is also written to the resulting object files)

[Koepi]

Well, that's in the sources, ok, but it's not affecting the windows build at all, that's why I left that stuff away. Who's on linux or has a PowerPC or x86-64 will read the source code release notes anyway... :)

Regards
Koepi

[Sharktooth]

This time it is a straight-from-CVS build.
Is there a hope to see the (in)famous strict/loose curve scaling option again in future builds?

[Koepi]

If I find the time I'll try to merge foxer's code again, yes. This can take some time though.
(So do you like strict scaling better than loose scaling?)

Cheers
Koepi

[IgorC]

Celtic D compilations are faster on intel CPU (sse2)than Koepi´s .
will be there a new compilation from Celtic?

P.S. great work!

[Sharktooth]

@Koepi: yep, i'd like to choose loose or strict coz i think they are both usefull, depending on the source material.

@IgorC: yes C_D constantly compiles xvid builds. So it's a matter of days (or maybe hours?) :)

[celtic_druid]

I'll put up some new builds later (been busy today), however the biggest change between this and my last build is the bitstream version, everything else is basically identical other than some cosmetic, header, etc. changes.

[Plub]

Xvid doens't show up in my the list in virtualdub after i installed it.
I can change the propetries via the startmenu, which works, but doens't change anything -_-
//edit: i deinstalled and reinstalled it several times, now it works

[Dams]

Nice work as usual Koepi !

Is this build can be called "stable" as I use only VBV for my home standalone player (Keyplug 4810) , because I don't use any "pro" feature like BF or other things like this ?

Is VBV before this build , worked only on first pass ?? (- {core}: VBV support in 2pass mode )

I use actualy Nic build 13/12/04 compiled 8.1 Intel

Ps : I've got an Duron 1.6@2.2 Ghz

[Leak]

Originally posted by Koepi
XviD 1.1.0 Beta1 is available.
Ahem... w00t! :D

np: Zorn - Nachtbus (The City's Collapsing (But Not Tonight))

[jk888]

qpel wasn't working before?!? Would this be the reason why Xvid did poorly on Doom9's codec shootout? Well not exactly "poorly" but I was expecting better results after the 1.1 releases.

[Nazgul]

Originally posted by jk888
qpel wasn't working before?!? Would this be the reason why Xvid did poorly on Doom9's codec shootout? Well not exactly "poorly" but I was expecting better results after the 1.1 releases.

It doesn't sound like Qpel itself was disabled, just some mmx optimizations for Qpel that would've helped the speed. Unless I'm reading the changelog wrong.

[superdump]

It's official now, the release and full changelog has been posted at XviD.org (http://www.xvid.org/). Hopefully the new improvements prove worthwhile for your use. :) Enjoy the new version people!

[Prettz]

Are these changes compared to the 1.1.-127 build, or just compared to the 1.0.3 builds?

Also, the 1.1.-127 builds produced awesome encodes for me, so this version should be the same.

[CQ]

celtic druid what's the diference between the icl7.0 and icl8.1 versions? Its the software that compiles it or what :rolleyes: ?

[Shinobu]

kooooool, i'm going to test it, but not multi thread support to bad for those how use dual cpu like me....

keep up your good job, thanks

++

[mikeX]

Originally posted by CQ
celtic druid what's the diference between the icl7.0 and icl8.1 versions? Its the software that compiles it or what :rolleyes: ?

ICL refers to the Intel C compiler that he is using to compile XviD. Some time ago, it was reported that icl8.1 favored Intel cpus more than AMD ones, disabling certain optimisations that normally were also available for AMD. That's why icl7.0 is still widely used (I think that's what Koepi is using as well).

[ChronoCross]

Originally posted by jk888
qpel wasn't working before?!? Would this be the reason why Xvid did poorly on Doom9's codec shootout? Well not exactly "poorly" but I was expecting better results after the 1.1 releases.

you should probably re-read the quality report off dooom9.org.

Xvid 1st in speed
Xvid 3rd in quality. It got beat by the two h.264 AVC codecs in developement by nero digital. other than that it's the best codec out there and in my opinion there was hardly any difference between xvid and the H.264 codecs.

[CQ]

Originally posted by mikeX
ICL refers to the Intel C compiler that he is using to compile XviD. Some time ago, it was reported that icl8.1 favored Intel cpus more than AMD ones, disabling certain optimisations that normally were also available for AMD. That's why icl7.0 is still widely used (I think that's what Koepi is using as well).

Thanks! It's so clear for me now! :)

[Ezhihua]

:devil: :devil:
thanks

I just have a problem.

is it for windows2K/XP/2003?
however when I launch the tools in win2K,such as cal.exe,they crash!

Are they packed by upx?it seems that the problem caused by compressing.

excuse for my poor english....:sly:

[IgorC]

in fact i tested Celtic and Koepi compilations. maybe Celtic compilation approx. 0.317 % is faster (very liitle difference and there is possibility of error) so the speed is iqual for all compilations.

[Blue_MiSfit]

Originally posted by ChronoCross
you should probably re-read the quality report off dooom9.org.

Xvid 1st in speed
Xvid 3rd in quality. It got beat by the two h.264 AVC codecs in developement by nero digital. other than that it's the best codec out there and in my opinion there was hardly any difference between xvid and the H.264 codecs.

I find that for AVS/Virtual Dub encoding ( my favorite method ), there is nothing better than XviD. ND AVC is obviously an option, VP6 doesn't come close IMHO. DivX is always a step or 10 behind, and the experimental codecs x264 and snow are amazing yet still not "complete" enough for me to use all the time.

XviD is so customizable, dependible, understandable, fast, and bug free that I really find no reason to constantly use anything else. :)

A little OT I realize, but I was inspired

more on topic, the additions to XviD in 1.1 are awesome. VHQ for b-frames really helps boost compressibility especially in cartoon content for me. Good to see we have a friendly kopei release of the 1.1 tree to play with, not that there's much difference between it and Celtic-Druid's nightlies IMHO :)

~misfit

[peteag]

Is XviD full featured (now): 4MV, splines, etc. in the decoder and the encoder???

newbie-question, I know.

[LiFe]

Originally posted by ChronoCross
you should probably re-read the quality report off dooom9.org.

Xvid 1st in speed
Xvid 3rd in quality. It got beat by the two h.264 AVC codecs in developement by nero digital. other than that it's the best codec out there and in my opinion there was hardly any difference between xvid and the H.264 codecs.

Nero has two codecs, one ASP and one AVC. ASP gave xvid a sore run for it's money (from what I read) and AVC out did it a little. Keep in mind there are still a few AVC features they need to add, and then overall tweaking to be done.

[Leak]

Originally posted by LiFe
Nero has two codecs, one ASP and one AVC. ASP gave xvid a sore run for it's money (from what I read) and AVC out did it a little. Keep in mind there are still a few AVC features they need to add, and then overall tweaking to be done.

Nope - what Doom9 tested were the AVC Main Profile and AVC Hi Profile codecs; Nero's MPEG4 ASP codec wasn't even looked at.

Well, AVC beating MPEG4 ASP - who'da thunk? :D

[b0b0b0b]

congrats on the beta release, dling to test now

[peteag]

Think fully exhausted ASP- and AVC-Codecs are not comparable, because these are two extremely different technologies. At the moment, nero's AVC-implementation isn't that better that our new XviD-release and it can't hold the promises of what the AVC-standard has expected to be. There's a lot of time to invest.

I like XviD very well because it's a technologie which is also not finished in implementation, so there's still a place for ASP beside AVC. Look some years ago. The "holy DivX4 - The incredible MPEG4-Codec". Look now. XviD compared to DivX4 ... :p !!!

So, the time and the hard work of the developers of XviD and some other people, who made these wondeful free avaiable releases, has to be honored. But how? My Way -> USE THIS CODEC WITHOUT SPOTTING ABOUT IT'S QUALITY COMPARED TO MUCH NEWER TECHNOLOGIES !!!

Without these great guys you wouldn't have anything to encode your full-lenght-movies to a single CD in that quality.

Great job guys!

[Yong]

Keep the good work, XviD developers.:)

[jk888]

You're right you can't even begin to compare AVC and Xvid, because AVC freaking destroys Xvid for quality. On a 10 point scale I give Nero AVC 10 and Xvid 5. Yeah it's that much better.

I had a 2 & 1/2 hour movie with lots of dark + grey + foggy scenes and changing special effects (Japanese movie Casshern). I wanted to encode it into 2 CDs with Xvid, and the quality looked like crap, especially on the grey or foggy scenes.

Then 1 month later I read Doom9's codec shoot-out and then tried using AVC. I used the same movie with the exact same avs script, and WOW!!! The difference was unbelievable! I'm talking sharp! All the dark and foggy scenes were crystal clear!

I don't know how good AVC will become in the future, but right now it's a hands down winner already.

It's great for a new release of Xvid and thumbs up for everyone's hard work, but this time, after 1.5 years of using Xvid I decided I don't need to download the new version. Thx Xvid for giving me great encodes for the past year, please don't be offended now that I'm moving on to the future: AVC.

[OMINUS]

Originally posted by jk888
You're right you can't even begin to compare AVC and Xvid, because AVC freaking destroys Xvid for quality. On a 10 point scale I give Nero AVC 10 and Xvid 5. Yeah it's that much better.

I had a 2 & 1/2 hour movie with lots of dark + grey + foggy scenes and changing special effects (Japanese movie Casshern). I wanted to encode it into 2 CDs with Xvid, and the quality looked like crap, especially on the grey or foggy scenes.

Then 1 month later I read Doom9's codec shoot-out and then tried using AVC. I used the same movie with the exact same avs script, and WOW!!! The difference was unbelievable! I'm talking sharp! All the dark and foggy scenes were crystal clear!

I don't know how good AVC will become in the future, but right now it's a hands down winner already.

It's great for a new release of Xvid and thumbs up for everyone's hard work, but this time, after 1.5 years of using Xvid I decided I don't need to download the new version. Thx Xvid for giving me great encodes for the past year, please don't be offended now that I'm moving on to the future: AVC.


good for you 888 that you can now make superb movies with avc
although i think you are a little excessive about the quality gap between xvid and avc

anyway you made your point,now pls let the rest of us enjoy this new release of xvid-if we are making mistake because we still use it well i will find this out by mysfelf not from you

cheers lad

[suspiciousBob]

I'm getting slightly undersized files with XviD-1.1.0-Beta1

Source is r2 dvd of bbc's porridge, pal, 25fps, interlaced

LoadPlugin("C:\PROGRA~1\GORDIA~1\DGdecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\decomb.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\UnDot.dll")
mpeg2source("D:\Encoding Storage\Porridge 1x01\P 1x01.d2v")
crop(16,2,692,572)
FieldDeinterlace(blend=false)
BicubicResize(640,496,0,0.5)
Undot()

2bframes, vhq for bframes too, packed bitstream, ultra high/wide search, chroma motion, turbo, 250 to kf

aiming for 194MB, getting 192MB

the same kind of 2-3 MB undersize is apparent on all 6 episodes encoded.

[Koepi]

Can you please post:

- no. of frames for the encode
- entered "desired kbytes" (or bitrate)
- resulting kbytes(!) (MBs are calculated by the OS and therefore not really reliable. A size difference of i.e. 600kb can be the difference in shown 192/194MB due to rounding taking place)

Cheers
Koepi

[suspiciousBob]

43172 frames (28m46s)
average bitrate: 943kbps, aiming for filesize of 198715 KB
final avi size: 200,433,664 bytes (195736 KB)

[Sergei_Esenin]

Originally posted by jk888
You're right you can't even begin to compare AVC and Xvid, because AVC freaking destroys Xvid for quality. On a 10 point scale I give Nero AVC 10 and Xvid 5. Yeah it's that much better.

Not if you want to use high bitrates and know how to tweak the settings for high bitrates, in which case Nero AVC smoothes out the detail too much compared to XviD with a custom matrix, VHQ at max, etc. Until Nero gives more control over the encoding matrix etc. it won't match XviD at high bitrates or fixed low quantizers.

[obieobieobie]

Very nice. Going to play around with it.

Btw, "misteriously" must be a typo. The correct word is "mysteriously". :)

[gotaserena]

ASP gave xvid a sore run for it's money

Am I the only one who finds the phrase above funny (regardless of its accuracy)? :D

[len0x]

Are there any plans for doing VBV for single pass mode?

[Koepi]

Originally posted by len0x
Are there any plans for doing VBV for single pass mode?

AFAIK noone's working on this (and I lack the time to look into it).
Sorry for the bad news. Maybe someone feels motivated to do so though? ;)

Cheers
Koepi

[Sharktooth]

Uhm... i think it's quite difficult to implement VBV for a 1pass encode... the results will be suboptimal and the average bitrate could be completely screwed up.

[len0x]

But for fixed quantizer encoding we don't really care about average bitrate...

[Sharktooth]

Well, yes coz the encode must respect the "max bitrate" for that profile...
So if a fixed quantizer encode exceeds a xxxx bitrate the VBV should lower it to respect the profile...
IMHO 1pass with VBV is useless.

[len0x]

There are quite a few ppl doing quality based encoding, so standalone support would be beneficial for them.

As for me - I like comp test result (i.e. quant=2 encoding) to be as close as possible to the two pass encoding, while VBV for two passes can change result of comp test quite a lot in some cases...

[Sharktooth]

Uhm... with 1 pass VBV i think it will be "out of target" anyways.
That's maybe why DivX does the first pass at constant bitrate instead of constant Q....

[_rEuTeL_]

I'm experiencing a small bug with the brightness slider

after I've decoded something, the slider seems to have moved slightly, resulting in a brighter (too bright) playback
nothing serious, but annoying nonetheless :p

[suspiciousBob]

Originally posted by _rEuTeL_
I'm experiencing a small bug with the brightness slider

after I've decoded something, the slider seems to have moved slightly, resulting in a brighter (too bright) playback
nothing serious, but annoying nonetheless :p I also see this.