News: XviD 1.1.0 beta 2

[buzzqw]

from mailing list

Hello!

This is XviD 1.1.0-beta2 release.

This release is the second beta of the 1.1 series. It is API/ABI
compatible with the previous beta release.

Changes since 1.1.0-beta1:

* xvidcore
- Fixed bug in GMC, and Cartoon modes.
- Improved VBV support
- Improved compliancy with DivX profiles.
- Added MPEG de/quantizer PPC support.
- Minor fixes for PPC colorspace functions.
- Improved Low bitrate quality.
- Fixed x86_64 interlaced support.
- Minor Motion Estimation adjustments.

* VFW frontend
- Improved compliancy with DivX profiles.

* DShow frontend
- Fixed resource leaking


The files are available in the download section of XviD.org:
http://www.xvid.org/downloads.html

-- The "XviD Team"

_____________________________________________
XviD-users mailing list
XviD-users@xvid.org
http://list.xvid.org/mailman/listinfo/xvid-users


When a fresh build to burn our cpu ?

BHH

EDIT: of course is already downlodable on Koepi site http://www.koepi.org/xvid.shtml

or a direct link

www.64k.it/andres/XviD-1.1.0-Beta2-04042005.exe

[dragongodz]

also from the main Xvid page with this release

As a sidenote, I would like to say to all XviD users that this is the last release I will ever prepare. It's been a long time I've been working in XviD, but everything ends one day or another... so I hope you appreciated the efforts I've put in XviD and I hope you'll enjoy the next releases prepared by the people who will decide to continue the XviD project. Farewell.

-- Edouard Gomez

so first sysKin leaves Xvid and now GomGom. :confused:

[Sharktooth]

Yup, sad news.
BTW, thanks to the xvid devs and builders for this (last?) release.

[obieobieobie]

How instrumental has he been in xvid's development? Primus motor? If so, is this it?

Edit: Just had to add a thank-you to all the xvid developers that has ever worked on the project. :)

[dragongodz]

there are still other devs and people submitting patches(check out the devs mailing list archive)so its not the end yet. maybe now Foxers strict scaling could be added as a full time option since it was apparently GomGom who rejected it as being inferior to loose scaling. that would be nice to see, something good coming out of this that is. :)

EDIT:
of course big thanks go to sysKin and GomGom for all the work they have done on Xvid over the years. ;)

[ChronoCross]

what's going on people? is everyone being snatched up to work on "pro" codecs? I'm interested to see where xvid goes from this point on but at this rate all the devs will get bought out. creepy thought indeed. but thanks to both syskin and gomgom for their work. it won't be the same without you guys

[Enigmax]

Thanks for your great work, XviD Team. :)

Greetings

[Teegedeck]

Thanks to GomGom for his work! BTW, we should not forget that only few developers are regularly present on the forum. Some, like the project's initiator Isibaar, shy away from the limelight. Let's feel a moment of silent gratitude to those quieter developers, please! :)

[Koti]

so I hope you appreciated the efforts I've put in XviD

Thanks guys, past and present, for all your work making one of the nicest video codecs [in my opinion].

To those who have moved on , may your success continue in your next adventure :)

[Enigmax]

Thanks to GomGom for his work! BTW, we should not forget that only few developers are regularly present on the forum. Some, like the project's initiator Isibaar, shy away from the limelight. Let's feel a moment of silent gratitude to those quieter developers, please!
O.K.
Thanks.

Greetings

[bond]

is it possible to make the best even better?


thanks a lot for this new xvid version!

and thanks to syskin and gomgom for all their great work on xvid and thanks to all the ones who also worked on it on the past and the ones who will continue working on that xvid stays what it is atm:
simply the best mpeg-4 asp codec existing :D

[*.mp4 guy]

Thank you Xvid devs for all your hard work and dedication. Its funny, but I have learned an amazing amount about many things while using xvid and other open source software.

[kurt]

thx for this release and for all the good work in XviD :)

[unskinnyboy]

What they all said ^^^ :D ..Long live XviD!

[Heini011]

uhm... the xvid.org page is blank and koepi.org is unavailable ??

[Chainmax]

Oh well, life happens. Good luck on whatever projects you undertake in the future Edouard :)

[ChronoCross]

Originally posted by Heini011
uhm... the xvid.org page is blank and koepi.org is unavailable ??


interesting. but koepi.org was up earlier but that is wierd that xvid.org is blank....perhaps someone should fix it =P

[video_magic]

Yes, I also say "Thankyou" to all who have worked on XViD, I appreciate the time and work you have done for us very much.

[Sharktooth]

Mirror: http://www.aziendeassociate.com/XviD-1.1.0-Beta2-04042005.exe

[IgorC]

Quality is just perfect for ASP, but Xvid decoder still recuries too much resources of CPU. (That´s why I prefer FFDSHOW)

Really good job.

http://www.free-codecs.com/ it says following ´XviD is the best currently available MPEG-4 video codec solution and additionally XviD is free software!´
Agree.

[Kagura]

Hopefully a new generation of coders can pick up the code to fill the massive void left by their departures. If I have some spare time, I'll try and see what I can come up with.

[Shinigami-Sama]

thanks to all past present futire and departed XVID coders
like everyone else has said
I think XVID will never be beat;n for quality expeasly for animated content :)
have fun in your new jobs mates :)

[namchik]

I hope this awesome codec will go on developing http://smileys.smileycentral.com/cat/36/36_1_32v.gif
coz death of xvid to my mind is a worse disaster than death of pope of Rome http://smileys.smileycentral.com/cat/36/36_1_50.gif

ps. I'm not a catholic http://smilies.sofrayt.com/fsc/smile1.gif

[Koepi]

Hm, the original is of course downloadable at www.koepi.org :p

XviD development will continue. SysKin and Edouard were quite inactive for the last few months, so the progress and fixes you see now are done by other developers already.

What does this mean?
XviD will continue - development won't stop. Current "main coders" are quite busy in real life though, so it'll develop at low speed like the past few months.
The improvements with this beta are very impressive, especially at low bitrates (movie to 1 cd encodes et al.). So the quality can raise a bit more, too.

As sad as it is to see two nice fellow developers parting, it doesn't mean the death of _this_ project.

Cheers
Koepi

[yaz]

after some short tests i must say it's xxxlent (again :) ) a big thx to the devels (again :) )

many thx
y

[Selur]

@koepi: is your side down ?
(or is it just my provider?)

Cu Selur

[Sharktooth]

koepi's site is down from yesterday.

[SeeMoreDigital]

Originally posted by Sharktooth
koepi's site is down from yesterday. Bummer!

I got a brief flash of the main page a few minutes ago... but then nothing :(


Cheers

[Ark]

Only a minor issue: in single and 2nd-pass mode the maximum bitrate setting close to the slider has too much "0". For ex. max bitrate for AS@L5 is 8000, but the value is actually 8000000, and so on for all values.

Btw, great work XviD team! ;)

[Enigmax]

Koepi, your site is down.

But the link from the binary works correctly:
http://www.koepi.org/XviD-1.1.0-Beta2-04042005.exe

Greetings

[TheUnforgiven]

anybody knows how "Improved Low bitrate quality" is achieved?

[SeeMoreDigital]

Originally posted by Enigmax
...But the link from the binary works correctly:
http://www.koepi.org/XviD-1.1.0-Beta2-04042005.exe Sadly... this link does not work for me either!

[namchik]

http://www.aziendeassociate.com/XviD-1.1.0-Beta2-04042005.exe
and
http://www.64k.it/andres/XviD-1.1.0-Beta2-04042005.exe
are working http://smilies.sofrayt.com/^/aiw/yes.gif

[Koepi]

Originally posted by TheUnforgiven
anybody knows how "Improved Low bitrate quality" is achieved?

- {core}: Rate-Distortion tables fix - logarithmic scales adopted correctly.
- {core}: Fix to the 2pass2 code / VBV buffer compliance.

Those are the main reasons for improved quality at low bitrate. if you don't use r-d though (no vhq/bvhq), there won't be much of the gain left ;)

I got a mail tonight from the site hosting company which i can't really decipher (it's croatian i believe), but from the look of it they experience some server trouble (www.vogon.hr is down, too). Let's hope they get online again soon.

Another link to the binary is this one: http://www.softpedia.com/get/Multimedia/Video/Codec-Packs-Video-Codecs/Koepi-XviD.shtml

Cheers
Koepi

[Sagittaire]

Originally posted by Koepi
- {core}: Rate-Distortion tables fix - logarithmic scales adopted correctly.
- {core}: Fix to the 2pass2 code / VBV buffer compliance.

Those are the main reasons for improved quality at low bitrate. if you don't use r-d though (no vhq/bvhq), there won't be much of the gain left ;)


certainely for Rate Distortion optimisation but not for VBV compliance. VBV is only buffer rate control for hardware player compliance ... use VBV don't improve quality. I think that VBV for high quant ("low bitrate") don't change anything for the Rate Control (high average quant encoding are generaly VBV compliant)

[DeepDVD]

It would be nice if someone could show some comparison pictures with the improvements.

greetz

[clsid]

How stable is this build compared to v1.0.3 final? Is the beta2 encoder ready enough for real-life usage or should it still be used for testing purposes only?

[TheCreamCrackerBoy]

Hello,

Just wanted to say "thank you" for the new version of the excellent XviD video codec (that, by the way, can hold movement scenes in a real better way than any other MPEG-4 codec that I know) and share the sad news of GomMom leaving the XviD prject. GomMom (and sysKin), thank you for all the efforts and good luck in your next challenges. God bless ya.

[]'s

The Cream Cracker Boy.

[SeeMoreDigital]

If I generate an 720x576 encode with B-VOP and VHQ (No GMC or Qpel) and play them back in stand-alone player incorporating a Sigma EM8551 chip-set, I see white flashes at the bottom of the frame during every scene change.

When I generate the encode again, without VHQ, there are no white flashes.

I've generated further tests with 1 to 5 B-VOP's, with and without packed bit-stream, AQ and PAR/DAR signalling.... All are fine, until VHQ is enabled.

Can anybody else confirm?


Cheers

[TripleA]

I do not often say stuff like this (or, indeed, much at all), but it's sometimes needed:

My most heart-felt thanks to everyone who ever contributed to making XviD the great piece of code it is. It is truly phenomenal and nothing I know of, open source or otherwise matches it.

Well, RM is better at extremely low bit-rates (~20Kbps) so far (pre-Beta 2) in my experience. And x264 is looking better all the time, but that's in the future still.

Anyway, thank you very much. And the best of luck to everyone. Those who moved on, and those still with us.

Now I have a few things to encode, if you'll excuse me...

[hajj_3]

koepi is there going to be a x64 version of the xvid codec, so that us windows xp pro x64 edition can take advantage of faster encoding?

i heard a rumor about this, wanted to know whether this was true, ifso when ?

[Koepi]

XviD x86_64 code is there, as there are some binaries -those are usually for linux so far to my knowledge.

I don't own an x86_64 machine, I don't have appropiate compilers. So I can't deliver something like that yet, soorry.

Cheers
Koepi

[hajj_3]

thanks for letting me know.

hope you can upgrade to a 64bit machine soon.

p.s your site dosent show 1.1.0 beta 2, still shows beta 1.

[Koepi]

Originally posted by hajj_3
p.s your site dosent show 1.1.0 beta 2, still shows beta 1.

That site is coming from your browser cache or proxy. The site is still down. (Hit Shift key while clicking on reload/refresh, this will try to fetch the site from the net and not from any caches.)

Cheers
Koepi

[guada 2]

Hello Koepi, :)

By using the script of Didée, I noted that the version beta 2 is improved.
But it is not stable. Whereas that of Koepi beta 1 controls better contours and the visual aspect of the image.
I believe sincerely that the options of version 1 is of a great support for the treatment of the codec xvid.

With this intention, I chose an extract of film of starwars 2/19.6 Mo with a bitrate of 151 kbps.
That is to say a final file of 1.97 Mo

Long life with the codec Xvid. ;)

Note: sorry for my english

[hajj_3]

error on windows xp pro x64:

when i go to "configure encoder" on the start menu i get

"error loading xvidfw.dll
the specified module cannot be found"


when i go to "configure decoder" on the start menu i get

"error loading xvid.ax
the specified module cannot be found"





hope you guys can make the next beta work with windows xp pro x64 properly, i can watch xvid movies, but cant configure it, havent tried encoding yet.

p.s i am using the final version of xp x64, its released to manufacturing, will be in shops in about 3 weeks. i have a AMD 64 3000+ socket 939 cpu.

[squid_80]

Originally posted by hajj_3
error on windows xp pro x64:

when i go to "configure encoder" on the start menu i get

"error loading xvidfw.dll
the specified module cannot be found"


when i go to "configure decoder" on the start menu i get

"error loading xvid.ax
the specified module cannot be found"


Probably because the start menu shortcuts are using the x64 version of rundll32.exe instead of the x86 version. If you edit the properties for the shortcuts and change system32 to syswow64 you might have more luck.

I did make a windows x64 version of xvid (encoding only, don't know of any 64-bit media players) but I need a new compiler to build a new release. There's copies of it floating around (you could try searching this forum for a start) but at this time I don't recommend using it since it's technically broken.

[Ice =A=]

As acknowledgement of gratitude and a kind of stimulus to the XviD-team:

This month there are comparisons of video codecs (by coincidence I presume) in several german computer print magazines (e.g. "Chip"). And even though the new-generation codec from Nero usually wins quality wise, Xvid allways is the close second, has the best time-vs-quality-ratio and is besides DivX (which comes in as third but is much slower) the only one who runs on stand allone DVD players.
So you obviously got an extremly positive evaluation right across the board!

Oh, on more thing: Microsoft's WMV9 is everywhere the clear looser and takes the last place! :) I actually like that! ;)

[hajj_3]

got it working.

in startmenu shortcuts:

change "c:\WINDOWS\system32\rundll32.exe xvid.ax,Configure"

to

"c:\WINDOWS\SysWOW64\rundll32.exe xvid.ax,Configure"

thanks alot.

by the way if you are looking for a 64bit media player use windows media player 10 which is on windows xp pro x64 final.

koepi, hope you can make next version have a modified installer, so you can get it to detect x64 and install properly for 64bit windows, if 32 bit xp then install like it currently does, bit annoying to have to change the shortcuts manually.

thanks guys !

[riggits]

Thanks to the XviD TEAM, you guys are amazing :D I'm also on the x64, but the new beta is worth dual-booting for :)
I'd like to compile Win32 binaries, but haven't the tools or know-how.. I've got some free time tho. WHat's a good compiler for the AMD64?
Thanks a million, guys! :D

[ckjnigel]

Thanks for the tips about Win X64. I do find it a boon to be able to do this work under that OS!

[Leo 69]

Yep, the improvements in low-bitrate conditions seem to be evident :D

We now can achieve almost DVD-quality at only 185 kbps.
I'm not joking here. Check this out - the clip is encoded in full DVD resolution (720x400)

Enjoy !

http://cp.people.overclockers.ru/cgi-bin/dl.pl?id=5809&filename=Xvid_185kbps.rar

:cool:

[TheCreamCrackerBoy]

Originally posted by Leo 69
Yep, the improvements in low-bitrate conditions seem to be evident :D

We now can achieve almost DVD-quality at only 185 kbps.
I'm not joking here. Check this out - the clip is encoded in full DVD resolution (720x400)

Enjoy !

http://cp.people.overclockers.ru/cgi-bin/dl.pl?id=5809&filename=Xvid_185kbps.rar

:cool:

Impressive!!!!

[COREiP]

Very Very Impressive!!!!!!

[ChronoCross]

Originally posted by Leo 69
Yep, the improvements in low-bitrate conditions seem to be evident :D

We now can achieve almost DVD-quality at only 185 kbps.
I'm not joking here. Check this out - the clip is encoded in full DVD resolution (720x400)

Enjoy !

http://cp.people.overclockers.ru/cgi-bin/dl.pl?id=5809&filename=Xvid_185kbps.rar

:cool:

well with all the details washed out I suppose you could call this DVD quality.....but anyway it looks nice in it's own right but not to my personal tastes.

[GolovachLena]

Are you all blind?! Or this is 1st april joke and i simple don't get it? The "quality" of this "masterpice" is quite terrible!

[Koepi]

Well, for 185kbps (look at the resolution again!) it's really quite good IMO.

(But no, I won't consider that DVD quality - maybe if I watch it over TV, but at a computer monitor it sure isn't. Still it's a good quality sample at that bitrate.)

Cheers
Koepi

[Sagittaire]

... lol

it's always the same thing: confusion between "low bitrate" and "high quant". Low quant (or high quality) can be "low bitrate" like "low motion" (250 Kbps for q2 720*576 ...) or "high bitrate" like "high motion" (10 Mbps for q2 720*576 ...)

Xvid_rules.avi is typically "low motion" : q7 for I,P 720*400 and 185 Kbps -> perhabs equivalence like q4 for I,P 576*320 ... try with beta 1 and compare: the result could not be visually very different than beta 2 ... :rolleyes:

IMO with your sample, MPEG2 with good encoder can probaly make the same quality perhabs with 300 Kbps ... :D

[Koepi]

It is low bitrate, and if you use vhq there will be a _significant_ difference between beta1 and beta2 at those quants already.

[Sagittaire]

In fact "low bitrate" do not mean anything (low bitrate but average quant could be very different)

IMO you must say "high quant" encoding ... and IMO q7 720*400 is not a very low quality encoding. In my metric test I use ~q8 with XviD (for I,P) for "streaming quality" (450 Kbps for 720*304 ... lol) and quality is not better visually or for metric.

I think that quality is very improved for very high quant encoding (perhabs q8 and more)

EDIT: high quant do not mean anything too if you don't precise matrix quant ... q8 with fox matrix and 1280*720*60 is very "high quality" for me ... lol

[namchik]

Leo 69
in spite the scene is not very dynamic, the quality for such bitrate is impressive for Mpeg4 ASP...

GolovachLena
LoL... :D

oh... no, no ... I'm not laughing at your post... just your nick http://img140.exs.cx/img140/5934/smile1.gif
for those who don't know, in Russian it means "dick-head" http://smilies.sofrayt.com/%5E/f/spinface.gif

[Leo 69]

Thanks for posting your impressions, guys. Although it's a static scene I've encoded, the whole 1h 30min average movie at such settings would go into only ~250 megs (video only) in that exact quality.

C'mon, Sagittaire, post some sample of yours at the same bitrate (or even lower, if you can :eek: ) but don't lower the res, plz. I'm very
anxious about this info you provided:

(250 Kbps for q2 720*576 ...)

Cheers

[Sagittaire]

Originally posted by Leo 69

C'mon, Sagittaire, post some sample of yours at the same bitrate (or even lower, if you can :eek: ) but don't lower the res, plz. I'm very
anxious about this info you provided:




Very simple with very static and very dark scene : in extreme situation (250 consecutive black frame like Kill Bill 2) the bitrate could be more low ... lol

Your encoding is very static and doesn't mean anything ... q7 H263 720*400 is a relative good quality with all source for beta 1 or beta 2 ...

If you want make real comparison up beta 1 and beta 2 sample and not only beta 2 sample ... :devil:

[Leo 69]

@ Sagittaire

My encoding is not dark at all so adaptive quantization doesn't play any major role here. And besides I'm not aiming at making any comparison between the betas. I'm seeing improvements with naked eye with this version. I only ask you to prove your claims concerning
this: "(250 Kbps for q2 720*576 ...)" and this: "IMO with your sample, MPEG2 with good encoder can probaly make the same quality perhabs with 300 Kbps ..." Post some short clip or something :)

And by the way how could that be, that WinRAR compressed the file so it became almost 50 kb shorter ? I know that it shouldn't be so :confused:

[Sagittaire]

but it's very simple ...
http://multimediacom.free.fr/Video/q2-low.avi

very very very static scene but only 200 Kbps for q2 in 720*528 ...

very very very impressive ... lol

[Leo 69]

Originally posted by Sagittaire
but it's very simple ...
http://multimediacom.free.fr/Video/q2-low.avi

very very very static scene but only 200 Kbps for q2 in 720*528 ...

very very very impressive ... lol

Your encoding sucks a lot, mate. You're good-for-nothing coder ;)
Bad bad joke actually..

[namchik]

Originally posted by Sagittaire
but it's very simple ...
http://multimediacom.free.fr/Video/q2-low.avi

very very very static scene but only 200 Kbps for q2 in 720*528 ...

very very very impressive ... lol

Hey, this is ridiculously unimpressive http://smilies.sofrayt.com/^/aiw/diablo.gif
I thought there would be a static scene with a little movement but not such a crapy bunch of screenshots!!!

Very very impressive http://smilies.sofrayt.com/%5E/a0/baby.gif :devil: 700 kilobytes for 3 different frames :mad:
Are you........????????? http://img81.exs.cx/img81/3492/angry5.gif Well... I'd better stop typing now coz I'd only insult you... :(

[Sagittaire]

Originally posted by namchik
Hey, this is ridiculously unimpressive http://smilies.sofrayt.com/^/aiw/diablo.gif
I thought there would be a static scene with a little movement but not such a crapy bunch of screenshots!!!

Very very impressive http://smilies.sofrayt.com/%5E/a0/baby.gif :devil: 700 kilobytes for 3 different frames :mad:
Are you........????????? http://img81.exs.cx/img81/3492/angry5.gif Well... I'd better stop typing now coz I'd only insult you... :(

lol ... static is static and my sample is a real 750 frames sample but anime with very static frame (with only lip motion in scene for example) can produce less bitrate for q2 720*576 ...

it's always the same thing ... confusion between "low bitrate" and "high quant". low bitrate can be "low quant" like "low motion" (250 Kbps for q2 720*400 ...) or "high quant" like "high motion" (250 Kbps for q20 720*400 ...)

Conclusion: "low bitrate" do not mean anything


-> boomrang effect : I'd better stop typing now coz I'd only insult you ... :devil:

[communist]

Originally posted by Sagittaire
certainely for Rate Distortion optimisation but not for VBV compliance. VBV is only buffer rate control for hardware player compliance ... use VBV don't improve quality. I think that VBV for high quant ("low bitrate") don't change anything for the Rate Control (high average quant encoding are generaly VBV compliant)
Well fluidity of playback could be called one aspect of quality too - so yes VBV does it part better now to improve on this for standalone / hardware players :)

[Didée]

@ Leo 69 & namchik:

Mates. Saggitaire is absolutely correct here with his opinion. (Although I could tear him into small pieces often enough - mainly when things come to quality metrics measurement and so ... think you know my opinion about metrics, Saggitaire, don't you :) ). But here I could not agree more. No motion, no residual, no data to code. Little motion, little residual, little data to code. Mpeg is just like that, and yes: a good mpeg-2 encoder could have done that scene posted at 300kbps probably quite well.

I have attached a small video @ 175kbps, in which I have put *zero effort*. I even used a so-called "high bitrate matrix" (the least likely thing to use for low bitrate encodings) because the encoder was just configured with it, and I was too lazy to change it. Still, that sniplet quality wise is worlds beyond what we have seen some posts above. And it was even done with the older beta-1 of XviD, which now all of a sudden seems so bad, since beta-2 was published ;)

Calm down boys. It's cheap, really.

[CruNcher]

i wan't to play with ya can i can i :D

http://cruncher.mufflastig.com/XviD/test/406kbps-anamorph.avi
720x420 1m 43s 2.35:1 :) best viewed with an AR capable filter or Players as Mplayer and VLC (prefered).

[Leo 69]

Originally posted by Didée


Calm down boys. It's cheap, really.

<Attachment pending>

Well, I didn't get angry at all :p It's all just fun, nothing more.. The purpose of my clip was to show what the codec is capable of at a very low bitrate, and though the scene is very calm, the
whole film (with action scenes & stuff) went only into 250 megabytes..
BTW, waiting for your low-bitrate attachment, Didee. Just curious
about what you have done.
(knowing your thorough mastery of Avisynth, I won't be very surprised to see some fantastic quality video ;) )

[Didée]

The filtering was lazy:

trim()
crop()
LTSMC()

Took me 30 secs to set it up. The last filter you don't know (yet), but it's somewhat similar to PixieDust.
Really, I didn't care. It's no pro stuff, really not. Just thrown something together in a breeze. It came out @ 175kbps, looks not bad for that, and is not even highly quantized. The most time went into getting a zipped video @ <208000 bytes ;) (btw, on my HD the ZIP is *exactly* 208000 bytes :D)

But somehow we're loosing the thread's focus, I feel ...

[GolovachLena]

Originally posted by Leo 69
[B]Thanks for posting your impressions, guys. Although it's a static scene I've encoded, the whole 1h 30min average movie at such settings would go into only ~250 megs (video only) in that exact quality.


Please enlight me some more. What target could be for such an experiment, considering its relatively high resolution? Don't think it could be too smart doing 185kbps encodes with 720 res for some pocket pc -- i can't see any benefits of it.

ps. to all russians in this forum: the choice of nickname was intentional :)

[namchik]

Originally posted by Sagittaire
lol ... static is static and my sample is a real 750 frames sample but anime with very static frame (with only lip motion in scene for example) can produce less bitrate for q2 720*576 ...

it's always the same thing ... confusion between "low bitrate" and "high quant". low bitrate can be "low quant" like "low motion" (250 Kbps for q2 720*400 ...) or "high quant" like "high motion" (250 Kbps for q20 720*400 ...)

Conclusion: "low bitrate" do not mean anything


-> boomrang effect : I'd better stop typing now coz I'd only insult you ... :devil:

Ok, sorry for my rudeness, but i only meant that the clip provided by Leo69 leaves a good impression of Xvid in terms of "size/quality" parameter and your clip was just a waste of time and traffic :(

GolovachLena, Leo69
use encoding "Windows-1251" if you can't see the text below ;) :
Ãîëîâà÷Ëåíà, Ëåî69!! Ìû æå çåìëÿêè ñðåäè áóðæóåâ... òàê äàâàéòå æèòü äðóæíî ;)

[Koepi]

I found this here: (http://forum.doom9.org/forum-rules.htm)

13) The official language is English. Outside the translator forum English is the only allowed language.

Not that I want to be a dickhead here, but I feel a little bit dis-advantaged by not understanding what you write there.

Cheers
Koepi

P.S.: as long as you don't insult each other it's fun to read this thread which went into "let's find samples which [every] codec copes well with" :p

[namchik]

Originally posted by Koepi
I found this here: (http://forum.doom9.org/forum-rules.htm)



Not that I want to be a dickhead here, but I feel a little bit dis-advantaged by not understanding what you write there.

Cheers
Koepi

P.S.: as long as you don't insult each other it's fun to read this thread which went into "let's find samples which [every] codec copes well with" :p

:) Yes, sir http://smileys.smileycentral.com/cat/36/36_18_4.gif
No more native language in this forum! http://smilies.sofrayt.com/%5E/g0/nodassent.gif

[GolovachLena]

Koepi, namchik wanted to tell me that i mustn's insult Leo69 'cos we're both russians and have to love each other :) But it's merely misunderstanding, perhaps due to my very imperfect english. I really didn't want to insult anyone.

[Leo 69]

Didee, why have you streched the video so much ? It's supposed to be
720x304 ,no ? Or I don't understand something :?: Besides it's too dark and even more static than my sample. And denoiser you've used last is FFT3DFilter, isn't it ? Anyway, it looks fine. Probably could be done even better with AVC, right ?

Cheers

[Didée]

I did not stretch anything. That's what is called "anamorphic encoding", as used in (mostly) all good mastered DVDs. Also the scene is not "too dark", it just _is_ that dark. The denoiser was not FFT3D, but another one currently being in development (ATM not well suited yet for clean sources, but doing white magic on helplessly noisy sources. Test: before (http://img156.exs.cx/img156/2999/01thenoise3hl.png)/after (http://img156.exs.cx/img156/3091/092xltsmc4au.png)). And lastly, the scene doesn't look fine, but crap. Look at the horrible floating on both people's faces - I had some weird ME settings from tests done lately still being set, and let them stay just how they were.

[dragongodz]

ok guys if you want to have a fight please take it outside. all this crap has got nothing to really do with Xvid 1.1.0 beta 2.

you can debate whats good, bad and ugly all you like but unless you are comparing the results of previous Xvid to this release its off topic and just filling this thread with garbage.

[Didée]

Right your are. But just for the argument: I was using a beta1 build, Leo was using beta2. Aren't we on topic, thus?
Besides, this is an announcement thread, look at the title. But what else do you want to announce, or even discuss, here? By now we do have realized that beta2 _is_ there, and that it is working flawlessly (miny-tiny issues there are, but not worth speaking of).
So we might as well stop talking, the thread be closed, a sticky made, and everything is good.

[dragongodz]

But just for the argument: I was using a beta1 build, Leo was using beta2. Aren't we on topic, thus?
was there 2 encoding of the same material with each that i missed ?

Leo claimed the new Xvid gave great results at low bitrate. then (eventually) Sagittaire said
If you want make real comparison up beta 1 and beta 2 sample and not only beta 2 sample
which as absolutly right. all the talk since then has not proven this beta is better or not but just gone on to be about still scenes encoding etc etc etc. so went off topic.

Besides, this is an announcement thread, look at the title. But what else do you want to announce, or even discuss, here?
i know it is an announcement thread, i made the second post in it with another announcement relevant to this release. i dont see that any test results or really even bugs NEED to go in this thread. though bugs i would atleast understand. :)

[IgorC]

http://www.aziendeassociate.it/cd///xvid-1.1.0-beta2-ICL7.0.exe - will be this compilation faster for SSE2 CPU?
it´s just post number 40000 in xvid forum. Coincidence

[neo_anderson]

i tried encoding dvd, with default settings, except i turned trellis off and also mpeg instead of h.263, and i enabled chroma optimizer , 1st pass went fine, but 2nd pass crashed! it happens all the time, does anyone has any fix for this?

[jon.schaffer]

Originally posted by neo_anderson
does anyone has any fix for this?
You do not give us enough elements to answer you.
All the settings you used give me perfect results... and I'm sure I'm not the one...
So the problem comes from elsewhere: either your part, or a software or hardware incompatibility?
What software do you use, what CPU, etc. ?

Err... just a guess. Did you hit "Load Defaults" after installing this new version and before setting xvid options and encoding your stuff?

[neo_anderson]

divx/nero digital avc encoding works fine on my pc, and as a matter of fact, i did hit load defaults before encoding, is it wrong? my specs are:
p4 2.4 ghz, 512 mb ram, geforce fx 5200
no viruses, no ram probs, no adwares!

[IgorC]

Originally posted by neo_anderson
divx/nero digital avc encoding works fine on my pc, and as a matter of fact, i did hit load defaults before encoding, is it wrong? my specs are:
p4 2.4 ghz, 512 mb ram, geforce fx 5200
no viruses, no ram probs, no adwares!

http://forum.doom9.org/showthread.php?s=&threadid=24924 it will help you. Last time I had a serious problem with Xvid it was in 2003.

[Heini011]

Hi,

@Koepi: your site is finally online again, but only with xvid 1.1 beta 1 no beta 2. and yes, i reloaded the page already..

greetings.

[Koepi]

@Heini011:

Thanks for the notification.

The site is online since a few hours again, but I still can't login currently to upload the updated pages again since that subsystem still isn't online/restored.

Cheers
Koepi

[neo_anderson]

well, i cannot post a log, coz i use the shutdown when done option, but here are my problems with xvid:

i am using xvid 1.1 beta 2 (installed after fully removing all xvid files from previous version, and also deleted settings file from gk folder)

i am using winxp sp2,p4 2.4 ghz, 512 mb ram, while encoding i disable screensavers, anti-viruses, etc.

i am having no viruses,ads, etc. and pc runs with no probs

so, when i use settings acc. to doom 9 guide, 1st pass runs for some time, then it aborts, and says warning frames counted differs from settings, and it all messes up!

so, i disabled trellis when using mpeg, and now 1st pass runs fine, but 2nd pass runs for about 0.5 hrs, gives me 200-300 mb corrupt file, and aborts!

settings are default, except trellis off, qpel on, b-vops on (2),chroma optimized enabled, packed bitstream on, use vhq for b-frames on, display encoding status off, and i use 2pass encoding, and dvd to xvid conversion, 2-cd good quality!

what am i doing wrong?

[Koepi]

Check your system temepratures while encoding please. This can also be a problem with memory. (Search in that direction please and you'll find plenty threads where I explained this issue).

Cheers
Koepi

[Sharktooth]

Originally posted by IgorC
http://www.aziendeassociate.it/cd///xvid-1.1.0-beta2-ICL7.0.exe - will be this compilation faster for SSE2 CPU?
it´s just post number 40000 in xvid forum. Coincidence
If you have a P4 it's preferable to use a ICL 8.x compile, but the gain is near to zero.

[neo_anderson]

i don't think there is any probs with memory or temperature, as there is no probs in doing long nero digital or divx encodes, and the pattern of crash is always the same, in the 2nd pass, so i think some settings are conflicting, but i don't know what! well, thanks for ur concern guys!

[Sharktooth]

Nic's xvid 1.1b2 binaries (ICL 8.1) are here: http://nic.dnsalias.com/xvid.html

[neo_anderson]

ok, i'll try nic's build tonite!

[Kagura]

Originally posted by neo_anderson
i don't think there is any probs with memory or temperature, as there is no probs in doing long nero digital or divx encodes, and the pattern of crash is always the same, in the 2nd pass, so i think some settings are conflicting, but i don't know what! well, thanks for ur concern guys!

Did you try running it on a different source? Does the problem persist? Is it codec related and not source related?

If that fails, run XviD on default. I've never used the doom9 guide on XviD settings so I can't say what's screwing up, but I'm pretty sure it shouldn't be something that changed from beta1 -> beta2. If the same error occurs on default, then report back.

[neo_anderson]

i have tried it on many dvd's but no luck! even autogk crashes or gives corrupt header avi file! i have also tried default settings, but no luck!could it be some other probs, i use lancos resize and mpeg quantisation, is this combo wrong?

[Sirber]

Koepi site is still down.

Mirror here (http://www.detritus.qc.ca/?section=download)

Sorry, but I can't put a direct EXE link coz of web server restrictions. Thanks.

[Sharktooth]

Originally posted by namchik
http://www.aziendeassociate.com/XviD-1.1.0-Beta2-04042005.exe
and
http://www.64k.it/andres/XviD-1.1.0-Beta2-04042005.exe
are working http://smilies.sofrayt.com/^/aiw/yes.gif

[Koepi]

Ok, _now_ my site is online again as it was before the crash :-)

http://www.koepi.org/

Cheers
Koepi

[Manao]

neo_anderson : since you're the only one to experience such crashes, it means that your system is the culprit. The fact that Nero's digital doesn't have any problem doesn't mean anything at all. Memory problems aren't deterministic.

I once bought some memory, and got xvid - and only xvid - crashing regularly for a week. The memory passed successfully several memory tests, and other programs didn't have any issue at all. Yet, after a week, I changed that memory, and xvid hasn't crashed since.

[Zep]

Originally posted by Koepi
Ok, _now_ my site is online again as it was before the crash :-)

http://www.koepi.org/

Cheers
Koepi

*FOR ME* beta 2 pass two is 23% slower than beta 1 pass two.
maybe the slow down is because of the better low bit rate code?


i ran it on a number of full encodes and then uninstalled
beta 2 and reinstalled beta 1 and tested etc...


then uninstalled beta 1 and reinstalled beta 2 and ran them
again to make sure and sure enough the slow down was back
on pass two. 23% average slower again.

settings for all runs were:

profile=unresrticted
Adaptive Quant = on
BVOP = on --> 2/1/2
BVOP sensitivity = 40
Q range 2 to 31 for i/p/b
overflow treatment = 20/20/20
Motion Search = Ultra
VHQ = mode decision
Chroma motion=off

everything else are the DEFAULT settings which i hit LOAD DEFAULTS
after each install of Xvid before changing the settings.

note: I'm on a AMD 64 3500+ OC to 2.7Ghz with a gig of
dual channel PC4000 running at 262Mhz

I noticed right off i was getting slow second pass as i was not
hitting 100+ FPS which i always do in beta 1 at a low rez of
624 x 352.


thanks

[ChronoCross]

are you really complaining about not getting 100fps? how bout we switch machines and you can encode at 4fps? and your right it's probably the new code that's making it a little slower. maybe some corrections to BVHQ.

[IgorC]

Comparing Beta2 with Fusion. Xvid is still faster approx. roughly 1,4-1,7 time (fusion insane quality vs Xvid best settings)

[neo_anderson]

Originally posted by Manao
neo_anderson : since you're the only one to experience such crashes, it means that your system is the culprit. The fact that Nero's digital doesn't have any problem doesn't mean anything at all. Memory problems aren't deterministic.

I once bought some memory, and got xvid - and only xvid - crashing regularly for a week. The memory passed successfully several memory tests, and other programs didn't have any issue at all. Yet, after a week, I changed that memory, and xvid hasn't crashed since.

Last night, i ran memtest86 for 5.5 hrs., and 0 errors! This is pretty weird, as other asp (DiVX) encoding, which obviously takes more time runs without errors, i think xvid would need more error resilience for me!

[zyrill]

You can't be serious, are you? You're saying XviD should compensate for obvious shortcomings of your system? :eek:

[ChronoCross]

Originally posted by neo_anderson
Last night, i ran memtest86 for 5.5 hrs., and 0 errors! This is pretty weird, as other asp (DiVX) encoding, which obviously takes more time runs without errors, i think xvid would need more error resilience for me!

remember this issue is only occuring on your system. it just means it's a problem with your system. whether it be overheating or just a poorly configured system (btw if your CPU is overclocked that may be causing it as well).

I personally think that you should stop posting about this complaint. there is no way to fix your problem as there are no other issues with it.

I suggest you try a straight vdubmod encode without using gknot/autogknot. if it still occurs then it's your system.

[Zep]

Originally posted by ChronoCross
are you really complaining about not getting 100fps? how bout we switch machines and you can encode at 4fps? and your right it's probably the new code that's making it a little slower. maybe some corrections to BVHQ.


ummmmm yeah because i do encodes that are under deadline.
How to I put this... speed is very important and i have to
hit a target size of 175 or 350 megs. You figure out the rest :)

My system is custom built for speed to hit 100 FPS and up until
beta 2 i was hitting my target speed.

So i want to try and determine if the speed hit gives
enough of a quality boost to justify the speed loss.
That is where i am at right now. With and average of 1000
bitrate i'm not seeing much of an improvement so i went back
to beta 1 hoping beta 3 can get the speed back and keep
the fixes. (cake and eat it too)

These are betas after all. Maybe a simple bug/oversight
in the new part of the code was missed.


thanks


Zep

[Zep]

Originally posted by neo_anderson
Last night, i ran memtest86 for 5.5 hrs., and 0 errors! This is pretty weird, as other asp (DiVX) encoding, which obviously takes more time runs without errors, i think xvid would need more error resilience for me!

run prime95 if you want to see if it is your CPU.

http://www.computerbase.de/downloads/software/systemueberwachung/prime95/


Trust me if prim95 torture test mode can go 8 hours and not fatal
you are good to go CPU wise. If it does fatal and halt you need to
first raise you vcore voltage and run it again and keep doing that
untilit works. if you max your vcore voltage and it still fails
then you need to lower your clock speed simple as that.

NOTE: keep an eye on the CPU core temps. once you hit 60c to 70C
you are in the HOT zone. go get better cooling heat sink like mine

http://www.newegg.com/app/Showimage.asp?image=35-109-119-07.jpg/35-109-119-06.jpg/35-109-119-02.jpg/35-109-119-08.jpg/35-109-119-03.jpg/35-109-119-09.jpg

and get better fans or both. My heak sink is one of the best
and dropped my CPU temps by 10c so that i could increase vcore
voltage to a point that prime95 runs for 12 hours without a failure
even at OC to 2.7Ghz from 2.2. Yes I need to MAX my vcore to
1.80 from default of 1.5 and the sucker runs HOT HOT HOT.

with the 6 fans and new heat sink i now get temps of about 62C
in prim95 and 55c in encodes. down 10c from the first after
market heat sink/fan combo i tried.

your memory is fine. It is your CPU that is messing up i bet.


good luck

[IgorC]

100 fps? for what? At 100 fps 1 film 2 hours will be encoded in 2 pass
during maybe <1 hour. So you can encode 10-20 movies per day. :confused:

However, everybody make own decicion how to trade on speed/quality.

[Dragon Shenron]

Any changes to the decoder part, 'cause I'm not gettin' the b-frame decoder lag message in VDub without PB? And I liked that message a lot :)

[ChronoCross]

Originally posted by IgorC
100 fps? for what? At 100 fps 1 film 2 hours will be encoded in 2 pass
during maybe <1 hour. So you can encode 10-20 movies per day. :confused:

However, everybody make own decicion how to trade on speed/quality.

that's insane to think that he is that under deadline...for what who the hell knows. I'd be interested to see what company is encoding mpeg4 movies. for some reason it just doesn't seem likely. I'd settle for even half that speed.

[squid_80]

Originally posted by Dragon Shenron
Any changes to the decoder part, 'cause I'm not gettin' the b-frame decoder lag message in VDub without PB? And I liked that message a lot :)

Changelog says:

xvidcore
========
* removed the bvop delay warning text ("warning: nothing to output), as this often confuses joe user.

[Didée]

The DS decoder seems to still have that bug with messing up chroma when decoding interlaced material, though. Just to mention. The encoded stream itself is fine.

[Zerox20]

Anybody have a CVS build with the new xvid? Or a link?

[SeeMoreDigital]

While we are on the subject of the decoder filter...

Has anybody looked any further into developing a fix for the AR signalling detection of B-VOP encodes without packed bit-stream?


Cheers

[Koepi]

SMD: GomGom wrote some months back that he found the error - I thought it's fixed now (though I didn't check). Is the bug still in there? :)

Cheers
Koepi

[SeeMoreDigital]

Originally posted by Koepi
SMD: GomGom wrote some months back that he found the error - I thought it's fixed now (though I didn't check). Is the bug still in there? :) I've just checked by generating a 16:9 DAR encode. And yes it still appears to be broken!

The same encode AR's correctly in ShowTime and VLC player.


Cheers

[Zep]

Originally posted by ChronoCross
that's insane to think that he is that under deadline...for what who the hell knows. I'd be interested to see what company is encoding mpeg4 movies. for some reason it just doesn't seem likely. I'd settle for even half that speed.

i put all the hints in my post as to why i need the speed. :)


and yes i get over 100FPS on 624 x 352 (well with beta 1, beta 2 about mid 80's and why i posted)

[ChronoCross]

your either a fansubber or a DVD encoder. those are the only people I know who try to hit 175MB for 23 minutes of video single audio.

[Kagura]

DVD ripper I'll bet. They're the only ones who use that weird resolution =P.

[ChronoCross]

yeah your right.

[helix]

Is there a reason I only get like 20fps with a scipt running 4 average filters? I always though there was somthing a tad odd about my encoding fps. :confused:

AMD @ 2.3Ghz

[ChronoCross]

20fps is really good. I usually only get from 2-8fps depending on heavily I need to filter.

[Shinigami-Sama]

Originally posted by ChronoCross
20fps is really good. I usually only get from 2-8fps depending on heavily I need to filter.
errrhhh
poor you mate
I get about 50-80 depending on source and filtering and if I turn on most avanced features or not
but I sunk about $2800CAD into this PC so I guess it shows

[Didée]

@ Shinigami-Sama:

Ever heard of a term like "Quantity versus Quality" ?

Your preference lies on the former. Ours on the latter. :)


Oh, BTW ... try setting ME=1. You'll get even more of your beloved FPS. :D

[Koepi]

Originally posted by Didée
Oh, BTW ... try setting ME=1. You'll get even more of your beloved FPS. :D

LOL :)

The first smile on my face today :) Thanks!

[AsTimeGoesBy]

Me too, I'm looking forward to get that new beta! :)

Could possibly somebody tell me how many zones are supported in that build? - 64 again or maybe 128 now?

[TripleA]

Originally posted by Didée
@ Shinigami-Sama:

Ever heard of a term like "Quantity versus Quality" ?

Your preference lies on the former. Ours on the latter. :)


Oh, BTW ... try setting ME=1. You'll get even more of your beloved FPS. :D

It's a trade-off between the two, most times. What's acceptable to one will not be acceptable to another. Especially if there are deadlines. Regardless of what created those deadlines.

Personally, I'm all for quality-at-all-costs, but I understand that not everyone would agree with me.

[celtic_druid]

config.h from 1.1.0beta2 shows:
#define MAX_ZONES 64

I did some earlier builds with 512 zones, but I guess no one found them usefull as there was no feedback.

[AsTimeGoesBy]

Originally posted by celtic_druid
config.h from 1.1.0beta2 shows:
#define MAX_ZONES 64

I did some earlier builds with 512 zones, but I guess no one found them usefull as there was no feedback.
Indeed! I remember (http://forum.doom9.org/showthread.php?postid=608605&highlight=zones#post608605) of course!
Very inpolite of me, sorry - and i really thought i have made any further post about it.

Because i have made a 512-zones-video actually with colour-s/w-switches. I did this with help to of a simple javascript loop to produce the registry code (too much work to enter all manually by the Xvid configuration GUI;)).

So far that did work fine, but i have noticed a very heavy memory consumption with that 512-zones build almost near 1GB at all, that's why i have mentioned above for 128 zones. Moreover i guess i'm the only one who sees any profit resp occasion to use for 512 zones :(...

Could it be that a line like "#define MAX_ZONES 512" reserves memory for zones indipendent if so many zones are really used?

[Shinigami-Sama]

Originally posted by Didée
@ Shinigami-Sama:

Ever heard of a term like "Quantity versus Quality" ?

Your preference lies on the former. Ours on the latter. :)


Oh, BTW ... try setting ME=1. You'll get even more of your beloved FPS. :D
no....
I like quality and quantity doesn't matter I don't rip to offent and I jsut set it up so when I come home for work it;s done
BTW look at my sig thats my specs, should clear up my speed a bit for ya ;0

[Heini011]

dear xvid-team,

please let xvid the user warning before a existing .pass file is overwritten! i lost so much encoding-time already...

greeting..

[Heini011]

Hi,

i had accidentally overwritten a .pass file (i think i mention it in any posting above already ;-) ) in a different directory to the encoding files. the old pass file was a small one with only 1400 lines. the new enconding has 150.000 frames, but in the new rendered .pass file are 562 KB of binary zero bytes after 1400 lines and after the binary zero block follow 125.000 other lines.

this seems a little buggy, dosn't it ??

greetings.

[Koepi]

^That sounds like a bug, sure - but it seems to only affect your system. I never managed to force xvid into this behaviour.

Are you sure your system is in order? (Make sure before replying "yes" automatically ;) ).

This _may_ happen if another instance of an encoder is still running. Check your process list please if this is the case.

Cheers
Koepi

[Heini011]

Hi Koepi,

>Are you sure your system is in order?

yes! uhm... wait a minute and let me think about it... yes!

>This _may_ happen if another instance of an encoder is still running.

oh, i can't rule out the possibility, that another encoding process has written to the same .pass file at the same time frame. if this problem occurs at nobody else, you probably right, koepi.

i give the xvid encoder always the complete (absolute) path to the xvid .pass file to avoid any possible confusion... sometimes (most at late night...) i forget to set the path correctly and so 2 days of encoding work are lost.... :-/


greetings.

[goerz]

Hi everybody, I'm new here and I have a simple question about Xvid beta 2 I couldn't find answered in the previuos posts. I can't find the "Cartoon mode" option anymore in beta 2, has it been removed? If so, are there equivalent manual settings in beta 2 for getting results similar to those obtained in 1.0.3 with Cartoon mode enabled?
Thank you very much for your replies.
Goerz

[Koepi]

You find it in the zone-options.

Cheers
Koepi

[Heini011]

Hi,

i can't reach my desired second pass filesize. the first pass is only slightly to big, so i wish to go a little bit down without a big quality drop. i had never such a problem with previous builds.

1-pass (q2) size is: 1594 MB
2-pass target file size was: 1533 MB
finally reached second file size: 1477 MB

frame count: 148.000

i had a q4 zone for the first 3995 frames within first and second pass.

fast-first pass and discard first pass was disabled.

further xvid settings:

profile: unrestricted
adapt. quant.
quarter pixel
b-vop: 3/1.5/0.7
not packed bitstream
i-frame boost: 0
overflow treatment:
i first tried 3/3/3 and now 5/5/5 - same result
motion search: 6- ultra high
vhq: 4- wide search
vhq for b-frames
chroma motion
i-interval 250
trellis quant
i-frame quant: 2-7
p-frame quant: 2-7
b-frame quant: 3-11

i don't want to set min-quants = 1, because i look for a gain in quality not only size! the first pass quality is slightly better than the slightly undersized second pass...

greetings, Heini.

[Manao]

Are you sure trellis and / or VHQ settings were the same on both passes ?

Are the quantizer in the second pass for P's all 2, or are there higher quantizers ?

[yaz]

@heini011
are u aware of that your target quantizer is about 2.08? how do u expect to hit that while forcing avq.q upward by every possible and agressive way?
say, b/3/1.5/0.7 turns lots of p-frames (having avg.q near 2) to b-frames having much higher avg.q (round 4). using aq does the same. if i were u i would use b/1/1/0 (or no b frames at all), no aq and i would boost i frames extensively (say, 20% or more). if it's not enough, u can (should!) use q1 bravely. wont (wouldn't) hurt. amof, i wouldn't bother w/zones here at all.
another (a bit more tricky) way is using const quant zones. say :
- let the movie at const quant 2
- tune the outer zones (intro, end-credit, aso) so as to hit the target.

[Didée]

overflow treatment:
i first tried 3/3/3 and now 5/5/5 - same result

Try 0/9/4.

[unmei]

I'm currently trying to encode an anime TV series from DVD.
I did the first two episodes with beta1, then beta2 came out.

When i tried to encode the 3rd ep, the first pass went fine. But on the second pass it crashed (VDM silently vanishing) on frame 2222. I then tried the second pass again. Crashes always around the same frame. Then i tried with VD (not VDM). Did not crash.
4th episode: same bevaviour, again silent crashes somewhere around frame 222X. But this time using vanilla VD did not help, it also crashed there.
The crash location is still part of the opening that is "about" the same in both episode, not bit exact, maybe not even frame exact, but still it is the same content scene for a human. It is a rather complex scene with the background zooming out and large letter whirling around.

Now i went back to beta1 (still using the 1st pass stats from beta2, i know its not optimal, but i was very desperate to find a way to encode further than the desastrous scene). It just now went over it without crash O.O!

Details:
build: beta2, both koepi's and one found in a thread here (XviD.cvs.head.exe) crashed
platform: winXP SP2, VDM build 1.3.10.1 2439 and VD 1.6.0.0 build 21540
hardware: AMD XP2600 not overclocked (a tad below 2GHz), A7N8X-X, 2x512 DDR running at 333. I can't remember this box crashing XviD before (its only about half a year old tho).
Xvid settings: AQ,QPel,GMC,B default but w/o packet bitstream, 1 zone start with keyframe, chroma optimizer, NOT cartoon mode, second pass settings (rate control) at default, MSP ultra high/wide search, use B-VHQ, chroma motion, turbo, trellis, quant range 2/31/2/31/2/31. 2nd pass quants used before crash seem to be 2..3/2..4/4..7 with avg a tad below 4. Target bitrate is (converted from target size) ~940kbit/s.

The AVS script is slow but doesn't crash neither in VDM nor MPC and encoding in x264 also worked (as did 1st pass and now seemingly 2nd pass with beta1).
What i find strange is it doesnt always crash at the same frame for a given ep (source), only in a close range of frames. And this crash range is the same in a very similar but supposedly not bit identical scene in another ep (source).

[ChronoCross]

I'd be willing to bet it's a filter issue. we can safely assume that beta2 is slower and more intensive than beta1 and therefore would put more stress on your system. alternatively you'd have to recreate the situation under a fully controlled environment. MEaning basically you could try it on a freashly rebooted system with nothing else running.

Also try usign memtest and there is also a CPU scanner thign( I don't remember the name it's kinda early rigth now).

EDIT: Almost forgot..you actually sit there and watch it encode? that's a little wierd :devil:

[unmei]

what makes you think i watch it^^ after the crash there is an avi (exactly 24MB) that can be opened with VDM.. it is broken, but after the "scan" thing, i go to File-File Information ..i guess the frame number there is what actually has been encoded..
As for the quantisers ..yes after the like 10th try i know about how long it takes until it crashes and then i went and looked at the stats window.
Reboot and not running other things ..of course i did all this before posting there - it's the 3rd **** weekend i fight with episode 4..

I did memtest86 when i set the system up, thats a bit of a time ago tho, but i use that PC for encoding all the time, and IMO due to the slow AVS Mem and CPU should get stressed enough in all cases (is 1.4fps enough of an indication of the sluggishness of the AVS? :p )

However ia not absolutely sure it is an XviD issue ..i just can't come up with anything else the could cause it :/

[Heini011]

i had further problems with filesizes. now with short encodes of round about 5 minutes length. i was setting up the second pass target size with -12.5% of first pass size, but some files became -16%.

when i enable quantizer-visualisation within ffdshow, i get for the first pass q2 and q3, but for the saturated second pass mostly q2 and q4!

B-VOPs: 3/1.50/0.70
Quantization:
I: 2-7
P: 2-7
B: 3-11

Overflow treatment 20/20/7 (for the 5 min encodes)

the same q2 and q4 thing is the case on my long encode, wich i described above.

for my other xvid settings see my posting above.

greetings.

[Manao]

OK, heini, I ask again : were all the P's in the second pass encoded at quantizer 2 ? Are you sure your settings were the same in both passes ?

And secondly, I'll quote something in your first post that needs clarification : fast-first pass and discard first pass was disabled.Does that mean that both were disabled ? Or that fast first pass was enabled and discard first pass was disabled ?

If you don't answer our questions, it's likely we won't be able to help you.

[Heini011]

hi manao!

>were all the P's in the second pass encoded at quantizer 2 ?

oh, how can i check that ?

in virtual dub i get always xvid as decompressor, so i watch the video with windows media player and pause the playback sometimes.

at the first pass i get (mostly a array with only 3) or (an array with 2 and 3) or (an array with only with 2).

at second pass i get (mostly a array with only 4) or (an array with 2 and 3) or (an array with only with 2).


>Are you sure your settings were the same in both passes ?

yes.


>>fast-first pass and discard first pass was disabled.

>Does that mean that both were disabled ?

yes. in math form:

(fast_first_pass OR discard_first_pass) = FALSE
(NOT fast_first_pass) AND (NOT discard_first_pass) = TRUE

;-) greetings.

[Heini011]

i discovered, that i can reach my target file size, when setting min b-frame quantizer to 2. strange, but that is not what i wanted too...

--
i compared the image quality. it seem's that min quant=3 for b-frames was not a good idea for some reason.

[Didée]

Originally posted by Heini011
it seem's that min quant=3 for b-frames was not a good idea for some reason.
Yeah ... that's a "feature" ;) of XviD in the quantizer settings: The "min" and "max" quant settings for B-frames do not refer to the real quants for B-frames. They refer to the P-frame quant used in the formula for B-frame quants.

For example, if you've set quant ratio to 2.0 and offset to 0.0, then setting min.B-quant=3 will limit B-frame quants to 3*2.0 = quant 6 ...

Don't know if this is mentioned in crusty's XviD FAQ ?

[Heini011]

thanks Didée!

but one question remains: why shows ffdshow mostly quantizers of 4 and not 5 : 3*1.5+0.7=5.2

how can i check the real frame types and quantizers used in my second pass encodes?

[AgentX]

I found a problem with the force-keyframe flag of XviD zones.

It seems to fail when the rate control parameter is changed from zone to zone.

An example will explain what I mean:
Frame=0 Q=31
Frame=100 W=1,0
Frame=200 Q=31
Frame=300 W=1,0
Frame=400 Q=31
Frame=500 W=1,0
...
(all marked with keyframe flag)

The I-frames aren't generated in the exact positions or not at all.
When using Q=20 some I-frames were generated on the right position.
With Q=5 it seems the I-frames are generated okay.

[LigH]

{ Edit: Sorry - it is hard to find that too short XviD encodes with B-VOPs are the result of a VirtualDubMod bug, not XviD's fault... }