Jambo! (XviD-1.0-RC2-07022004)

[Koepi]

Jambo! everyone!

We decided to make another release candidate of XviD-1.0.

Changelog:
- Internal bitrate calculator added
- Several VfW GUI fixes
- DShow fixes (remembers the flip option etc.)
- Colour space fixes
- Choosable fast 1st pass
- XviD with bframes in packed mode is decodable by DivX
- GMC with interlaced content fixed

ATTENTION: Since I lost all my data, I switched to another installer system.
If you used the old NSIS installer, please uninstall it manually
before upgrading with these new installers.
If you have done that already, upgrading with these new installers
works like you expect it.
Also, Win9x support is better now with this installer.


Known issues: well, some tooltips don't appear like they should, we're still investigating.

The new installer system should get tested as well as I needed to rewrite things from scratch. It should work better in win9x now though. I also added some options to configure dshow decoder from the xvid program group (thanks suxendrol for adding that feature! :) ), the encoder as well and some links to the web. This installer finally works with K6 processors (and similar) too.
I hope you like these changes.

Regards,
Koepi

[sh0dan]

Thanks!

Finally XviD is looking more and more like a 1.0 final! Polishing a final release is always the hardest part, but you're doing an excellent job!

Keep up the good work!

[Stereodude]

Maybe not quite there yet... This is what I get when I encode a 956x536 clip. The chroma and luma don't line up. 960x540 and 960 x 536 work fine at though. Do I need to be able to divide the horizontal res by 8?

http://stereodude.cjb.net/xvid.jpg

Also, is there a guide anywhere or information on the whole Motion Search Precision settings, VHQ mode settings, and Quantization Type settings?

I'm trying to "archive" 1/4 HD res stuff. Xvid trounces WMV9! It has lower CPU usage and better looking ouput at the same datarates, but I'd like to understand how I can potentially squeeze more out of it, specifically less CPU usage on playback and lower data rates. Encoding speed is not a real concern.

[Koepi]

Well, the problem is within the YV12 process chain you're most likely using. If you'd i.e. change the avisynth stuff to stay in YUV2 and feed that to xvid, it'll do perfect encodes even at your resolution.

I'm unable to really track that down to anything, but that indicates at least that xvid seems to be right IMO.

So as rule of thumb you should use mod16 resolutions if you want to use a YV12 process chain - I consider that a feature ;)

If you do a search on VHQ, custom quantization matrix or on motion search precision, you'll find the answers you want to have.

Short summaries:

VHQ: additional search process after normal motion estimation.
Motion search precision: the depth of search and special modes from the mpeg4 profiles.
Custom quant matrices: well, there are more than 1 threads even on this first page of the xvid forum ;)

Regards
Koepi

[chilledoutuk]

Just encoded dvb recording and no problems so far also i believe inoticed a speed improvement.

I would like to thank the devlopers for developing a great codec and koepi for compiling and distributing it to us keen video encoders.

cheers dudes

[Stereodude]

Originally posted by Koepi
Well, the problem is within the YV12 process chain you're most likely using. If you'd i.e. change the avisynth stuff to stay in YUV2 and feed that to xvid, it'll do perfect encodes even at your resolution.

I'm unable to really track that down to anything, but that indicates at least that xvid seems to be right IMO.

So as rule of thumb you should use mod16 resolutions if you want to use a YV12 process chain - I consider that a feature ;)
I'm using thisMPEG2Source("g:\annie.d2v",idct=5, cpu=4, iPP=true)
SeparateFields()
SelectOdd
LanczosResize(956, 536, 0, 0, 1912, 536)and it works with other compressors, like WMV9, but resizing's not a big deal.
If you do a search on VHQ, custom quantization matrix or on motion search precision, you'll find the answers you want to have.

Short summaries:

VHQ: additional search process after normal motion estimation.
Motion search precision: the depth of search and special modes from the mpeg4 profiles.
Custom quant matrices: well, there are more than 1 threads even on this first page of the xvid forum ;) First, thanks for your responses and all the hard work on Xvid.

I have looked at some of those threads, and I guess I should have asked my question differently. I haven't been able to find any information of how they various options effect decoding CPU usage. Also, most of the information out there seems targeted at lower resolution stuff where size is very important. I'm not that worried about size (bitrates up to ~7500kbit/sec are fine), but I want to maximize image quality but keep playback CPU usage as low as possible. The information I've found doesn't seem to necessarily apply to what I'm trying to get out of Xvid.

[mikeX]

@ Stereodude

AFAIK decoding cpu usage is greatly affected by:

QuartelPel
B-Frames

Output Resolution

@ Koepi
XviD with bframes in packed mode is decodable by DivX
i thought that wasn't xvid's fault :confused:

-- edit

the shortcuts to encoder/decoder configuration as well as the webpage links are some nice and useful additions ;)

[el divx]

@koepi: Could you please implement brightness and deringing in the directshow filter at next release

[N-Bomb]

- XviD with bframes in packed mode is decodable by DivX

Just curious if you could clarify that one a bit... is this the 'more than 1 b-frame' thing, or something else entirely?

Thanks :D

[Soulhunter]

http://www.dbzgtlegacy.com/animatedgifs/vegetaflash.gif Raise its power further... :D

[gizmotech]

Color spaces and vsfilter are now playing together correctly again.

Thanks guys. Greatly appreciated.

Gizmo.

[Koepi]

Originally posted by N-Bomb
- XviD with bframes in packed mode is decodable by DivX


sysKin (I think) set some DivX versioning in the bitstream which was 0.00 before to 9.99 - and guess what, DivX doesn't refuse to decode XviD's bframes anymore.

So not really XviD's fault, but a workaround for DivX decoder.

Regards
Koepi

[kadajawi]

just one small side note. My firebird doesn't like your fetch thing on your website (fetch?file=XviD-1.0-RC2-07022004.exe). You're evil, forcing me to use Internet Explorer! :D
Naw, probably just some settings... nevermind.

[Koepi]

It works perfectly with firebird-0.7, mozilla (any version) here. Dunno which setting you must change though, I can't reproduce the behaviour whatever I try :-/

Regards
Koepi

[Luminaria]

I've got a question about 2 of the default xvid settings that have changed since the codec went into RC status. For the quantization seetings the minimum level has been set back to 1 and on the two-pass tuning settings keyframe boosting is set to 10%.

From what I understand, and have read in the past here was that min quants of 1 just bloated the filesize and didnt help quality that much, so 2 was a prefered setting. I remember the keyframe boost always beeing 0 in the past.

Anyway, just was curious as to why the new defaults are like this and if there's any advantage to keeping them. Right now i've been changing them back to min 2, and 0%.

Thanks guys.

[kadajawi]

hmm, strange. Using Firebird 0.7, although I've installed a few extensions.
Anyway, finally XviD decoder works for me. Last time I tried it gave me a blank screen. :)

***edit***
another thing I noticed. When I click on "decoder options", I only get access to the deblocking and film effect settings. When I use configure decoder, I get access to deblocking, film effect, brightness, flip etc. settings. :confused:

[mikeX]

nother thing I noticed. When I click on "decoder options", I only get access to the deblocking and film effect settings. When I use configure decoder, I get access to deblocking, film effect, brightness, flip etc. settings.

same thing here

[kadajawi]

and personally I prefer the old "Show me the internals!". Where you could easily see if I, P/S or B frame.

[patja]

Thanks for keeping the builds rolling.

@sysKin:
Do you think you could add into the main decoder code branch the compatibility fix you made to include support for VIDEOINFOHEADER that we discussed in this thread:
http://forum.doom9.org/showthread.php?s=&threadid=69855

[sh0dan]

Originally posted by Koepi
I'm unable to really track that down to anything, but that indicates at least that xvid seems to be right IMO.

In what way is AviSynth "wrong", then?

I tried to help in the possible vfw YV12 stride bug (http://list.xvid.org/pipermail/xvid-devel/2004-January/003968.html) thread on the mail-list, but so far it has been intensely ignored.

[virus]

random comments on RC2, read at your own risk: :D

-installer: fine (very useful the new configure encoder/decoder shortcuts IMHO).
-calculator: pretty good.
-status window: adding an option for saving the stats (quantizers, average bitrate etc) is feasible? some programs kill the window even with auto-close unchecked... well, not really needed, this is just a suggestion.
-speed: I did a couple of encodings and noticed a small (2-3%) speedup.
Now, for the problems I reported in the RC1 thread:
-browsing fields with TAB button: fixed, thank you!
-weight zone slider: still there, but hey, no hurry for that ;)

some days ago Koepi said that sysKin has coded a lot on the brightness control, so I guess it's almost ready; that means there's only the deringer left, this is really good.
Keep up with the work guys, I can smell 1.0-final, it's almost here :D

thx :)
virus

[Koepi]

Originally posted by virus
some days ago Koepi said that sysKin has coded a lot on the brightness control, so I guess it's almost ready; that means there's only the deringer left, this is really good.


I must have been delerious when I said that. I (now) know nothing about sysKin coding postprocessing such as brightness and stuff.

maybe there is a small misunderstanding? ;)

@sh0dan:
It didn't get ignord. I'm at least to say confused about all this colour space stuff. We had some guy posting weird stuff on XviD developer mailing list which we shortly used in the sources - and which immediatly broke everything.
And your post (woohoo, I didn't know that it's you!) has a line of code which I tried - and which was even worse than everything before. Normal encodes (mod16 resolution) were broken as well then. Sorry for not replying on that list, I just tried that and it didn't work for me.

Maybe you can visit us on irc.freenode.net at channel #xvid and we could look into that matter "realtime" talking? I think that'd be useful :)

Regards
Koepi

[virus]

Originally posted by Koepi
I must have been delerious when I said that. I (now) know nothing about sysKin coding postprocessing such as brightness and stuff.

maybe there is a small misunderstanding? ;)


;)
yeah, looks like I mixed up something, you wrote that (Niltze thread, page 9): "Also, sysKin is coding a lot on the dshow filter...". Probably I read about the brightness control somewhere else. I'm not even sure this was about sysKin at all, can't remember now... sorry! :D
Installing & testing carefully two codecs in 24 hours (the other being a VP6 beta) can hurt my brain... :rolleyes:

[gldblade]

Hm, maybe the bitrate calculator should be disabled when in Target Quantizer mode so as not to confuse the user. And I wish the bitrate calculator had more default sizes (i.e. 2 cds), but that's just a matter of convenience.

Looking very good :)

[AmiRage]

Originally posted by gldblade
Hm, maybe the bitrate calculator should be disabled when in Target Quantizer mode so as not to confuse the user.
I nearly went crazy trying to understand the way the bitrate calculator works ... thanks for your hint. :D

And yes, I second that. :)

[Josip Tosic]

Hi,
I'm encoding a PAL movie, 01:40:02 long, to a 702 MB (718.848 kB) OpenDML AVI file with 112 kbps CBR MP3 and no subtitles.

Built-in calculator says that the targeted size is 632.382 kB but when I click "OK" 628.866 kB is entered as a desired file size.

Is there a reason behind this behavior?

[mikeX]

small typo on encoder configuration first pass:

'compiliant' instead of 'compliant' at the end of the text refering to fast first pass

[Nazgul]

Originally posted by Koepi
So not really XviD's fault, but a workaround for DivX decoder.


This workaround wouldn't happen to make packed bitstream + B-frames usable with ffshow now, by any chance?

[BoNz1]

Originally posted by Josip Tosic
Hi,
I'm encoding a PAL movie, 01:40:02 long, to a 702 MB (718.848 kB) OpenDML AVI file with 112 kbps CBR MP3 and no subtitles.

Built-in calculator says that the targeted size is 632.382 kB but when I click "OK" 628.866 kB is entered as a desired file size.

Is there a reason behind this behavior?

Probably the avi container overhead I would imagine just set the container to none, note changing it to none would not in any way affect what format is actually written it is merely informative.

[mikeX]

This workaround wouldn't happen to make packed bitstream + B-frames usable with ffshow now, by any chance?
nope, there is still stuttering with ffdshow...

[sysKin]

About divx decoding: it seems that if you disable "smooth playback" in divx options, you can decode any number of b-frames in packed mode.

With RC1 you couldn't decode packed mode at all (using divx), divx was ignoring its fake signature completely.

Radek

[jamest]

Both RC1 and RC2 decoder stutter on playback of xvid and divx encoded clips, I tried zp, mpc with vmr9, overlaymixer with similar result.

At time it is so bad, av sync is lost for a few second.

[Koepi]

Disable postprocessing, it's using much CPU power. Since you don't file a proper bugreport we can't help you anything more than that. It stutters for none of us...
(Read the sticky: When posting bugs!)

Regards
Koepi

[communist]

Just a question to the devs - are you going to keep 'Reduced Resolution' or not? I just did a test encode with it (disabled b-frames / GMX / VHQ etc...) and the result looked quite blocky.
Maybe it would be better to not have that feature at all until it works as it is supposed to - or is it supposed to look that way?

[Koepi]

communist:

ouch. Please do a search on that feature, we answered that several times now.

Reduced resolution belongs to the realtime mpeg4 profile - it's for broadcasting/streaming, in situations where there are network congestions or things like these. In that case the encoder can switch to reduced resolution to save bandwidth.

It's not meant for encoding/doing backups. That's why the default profile changed - you can't use reduced resolution in ASP @L5.

(The tooltip should show that information as well.)

Koepi

[communist]

Sorry - I did a search but only came with technical explanations by syskin - not saying anything about how it looked (blocky / 'bump-mapped').
Oh and the tooltip for RR doesnt show up ;)

[Koepi]

I did a silent update of the installer on my page - the weblinks I created in the start menu program group for XviD were "hardcoded" to use the explorer. I now changed that behaviour so that the system default browser gets used (a shame that I didn't think of the solution via *.url files earlier...).

Sorry if that caused you inconvenience.

Regards
Koepi

[Josip Tosic]

Originally posted by BoNz1
Probably the avi container overhead I would imagine just set the container to none, note changing it to none would not in any way affect what format is actually written it is merely informative.
No, it's not that. If I change it to "(None)" calculator displays 634.820 kB but it actually enters 631.304 kB into codec.

[Alxemi]

Thanks to you all people!!! (developers, compilers, testers, etc) :)

mirror (http://138.100.51.162/~alxemi/XviD-1.0-RC2-07022004.exe)

and one question, some people reported the same problem with ffdshow that was in RC1, but i cannot see it in syskin signature... new bug? the same bug? no bug at all? ?¿?¿?

[Koepi]

Originally posted by Alxemi
Thanks to you all people!!! (developers, compilers, testers, etc) :)

mirror (http://138.100.51.162/~alxemi/XviD-1.0-RC2-07022004.exe)

and one question, some people reported the same problem with ffdshow that was in RC1, but i cannot see it in syskin signature... new bug? the same bug? no bug at all? ?¿?¿?

Erm. I think in this thread that got answered already? Or was it one of the other "top 5" threads? ;P

It's the same bug in ffdshow - not in XviD.

(Btw., I don't remember, did I authorize your mirror? ;) well anyways, nice to have the file accessable even if my router goes nuts)

Koepi

[hulkenstrong]

Just a smal question.

When I try to watch a xvid using 768x576 resolution packed,b-frames, birate at about 2000kbps and also uses deblocking when decoding. The cpu usage always is about 95% and sometimes hit 100%(audio format is AAC at 250~.

As the quality is great its not the end of the world. But I think my machine is a fast and wonders if this is a normal behavior and if I whant to try more options will it be even wors or maybe even unplayble on my machine?

Will try to convince a friend to play one of my xvid files to, so I cna compare cpu usage.

AMD XP Barton 2500+ @2260MHz
Curently 256MB ram but soon 1GB (cpu usage is the same on 512MB)
2 non raid 120gb 7200rpm hdds
GF4
Windows 2003 (not using overlay. Tried overlay the cpu usage was the same.)
DirectX9
Audigy2/onboard sound
NFORCE 2 Motherboard.

[Koepi]

You have to test it, it's not that we can "look into the glass bowl" ;) I think your aac is very demanding on processing power as well, you're using your hardware to the limit i'd say. (But that all also depends on memory bandwidth, memory clock, fsb speed, ... nothing we want to discuss here in detail. We're not here for overclocking systems or give hints about proper system setup, that's more for the hardware/software forums here.)

Regards
Koepi

[Alxemi]

It's the same bug in ffdshow - not in XviD.

That is what was in my mind, the confussion was not to see it in syskin signature as with RC1 :confused:

[sh0dan]

Originally posted by Koepi
And your post (woohoo, I didn't know that it's you!) has a line of code which I tried - and which was even worse than everything before. Normal encodes (mod16 resolution) were broken as well then. Sorry for not replying on that list, I just tried that and it didn't work for me.

You should read what I meant - not what I wrote ;)

Anyways - the correct code: if (frame.input.csp == XVID_CSP_I420 || frame.input.csp == XVID_CSP_YV12) {
frame.input.stride[0] = (4 * icc->lpbiInput->biWidth + 3) / 4;
frame.input.stride[1] = frame.input.stride[2] = frame.input.stride[0] / 2 ;
}
Since there are also several places in the decode part that needs this, you can download codec.c (http://cultact-server.novi.dk/kpo/codec.c). The code is tested with both input and output YV12, and it works perfectly with material that is only mod4. (You can see my changes by the missing tabs ;-)

[hulkenstrong]

OK.Sorry for being curios and just sharing my experience. If anyone cares it is the deblocking feuture that uses about 30-45% cpu time. When turned of cpu usage droped below 50%

edited changed deringing to deblocking.
Apologise was so used to ffdshow and there I used both deblocking/derringing. Tried playing file using ffdshow cpu usage was 25% with deblocking/deringind on.

[Koepi]

@sh0dan.

thanks a million for the fix, I sent it further to xvid-devel :)


@hulken:
Now this is strange, deringing isn't implemented (and choosable) in XviD 1.0-*...

What are you using for decoding?!

Regards
Koepi

[OUTPinged_]

- XviD with bframes in packed mode is decodable by DivX

Is there a way to make RC1 encodes also DivX compatible? A small utility maybe?

This is great feature, now people will be able to play xvid with b-frames on divx-compatible standalones. \o/

[Imperial Llama]

Thanks to all the developers and testers who've helped XviD to get this far!

I have two (very) small suggestions for the GUI:

- When you click on the "more..." button next to the encoding type, I think it would be better if the new window it opened contained all three tabs (CBR, 1st Pass and 2nd Pass) with the relevant tab selected, rather then just one tab. That way you can configure your 1st and 2nd pass options in one go.

- For the Bitrate Calculator, add 448 to the list of selectable audio bitrates. I am aware you can enter the bitrate manually, but since this is such a common bitrate for AC3 I think it would make sence to have it in the list.

Keep up the good work. :)

[Koepi]

Originally posted by OUTPinged_
- XviD with bframes in packed mode is decodable by DivX

Is there a way to make RC1 encodes also DivX compatible? A small utility maybe?

This is great feature, now people will be able to play xvid with b-frames on divx-compatible standalones. \o/

Standalone players had no issues there. Only the software DivX decoder that ships to you in any form of the DivX package from DivX.com.

[OUTPinged_]

Crap. :/

The standalone i was messing with (Denver divx-compatible), was accepting divx with b-frames, but not xvid.

[sysKin]

Originally posted by Koepi
Standalone players had no issues there. Only the software DivX decoder that ships to you in any form of the DivX package from DivX.com. Actually we can't be so sure. Maybe it also checks for divx version and gets confused with 0.00 ?

I wouldn't mind if someone tried.

[mikeX]

@ hulkenstrong:
you should find this thread (http://forum.doom9.org/showthread.php?s=&threadid=70084) interesting

I've only encoded a small 10000 frame clip with rc2 so far, i have to say it's nice to see quants 1 are not being used carelessly, quality seems to be slightly worse than rc1 though (have encoded the whole movie with rc1)... gonna do the whole movie to make sure...

[sPunkt]

Originally posted by Stereodude
Maybe not quite there yet... This is what I get when I encode a 956x536 clip. The chroma and luma don't line up. 960x540 and 960 x 536 work fine at though. Do I need to be able to divide the horizontal res by 8?

I also ran into the same problem encoding with rc1. (At resolutions that worked flawless with DivX, so I'm not sure it really is a problem with the chain.) Switching to mod16 solutions was very inconvenient in this special case, but did the trick for me, though.

[kadajawi]

I'm only using mod 4 resolutions, but I don't have any problem at all (or anyway not seen any). My source is YV12. Resolutions are 720x576 or lower (cropped to remove black bars, which sometimes differ a lot (music vids)).

[MTskull]

xvid since rc1 has been giving me really choppy panning.... all of my settings are the same with the addition to cartoon and turbo modes. now i have tryed to encode without those modes and i still get the same results .... and files that i did with previous builds re-doing them with the RC series i get the same choppy results... its as if the motion estimation isnt working period. i had no problems with the beta's, what am i doing wrong

[Koepi]

MTsKull:

you're not by _any chance_ using ffdshow or divx to decode xvid content? Please report back.

Koepi

[erdie]

Originally posted by jamest
Both RC1 and RC2 decoder stutter on playback of xvid and divx encoded clips, I tried zp, mpc with vmr9, overlaymixer with similar result.


don't know if it's the same problem, but with RC1 & RC2 I do too have stuttering playback:

* only RC1/RC2 encodes are affected
* RC1/RC2 decoder used, no ffdshow/standalone decoder
* Mplayer2 (WMP 6.4), DX 9.0, some ASUS MX 440 card
* options used for encodes: all defaults except 2 b-frames, 20 i-frame boost, all min quants set to 2

these encoded clips play fine with XviD-Dec-1.0-Beta3.exe and ffdshow using XviD-24062003-1 for decoding

postprocessing is off, CPU usage at 25-30% (Duron 1600)
clip res is 576x432, datarate about 1000kbit, no sound

[Taurus]

Just as small bug in encoder's bitrate calculator:
Changing the values of target size from 650 to 700 MB, the corresponding values at size and average bitrate are set in the wrong order. At 700MB the lower settings are displayed and vice versa.
Check it and you will see.
Doesn't matter much to me but for a newby this could cause a lot of hazzle.

Cheers
Taurus

###Xvid goes on and on and on................

[crusty]

erdie:
Is it a small clip or a big file? Check for fragmentation.
EDIT: sorry wasn't clear enough I guess...I meant file fragmentation on your harddisk. Defrag your drive.
Outpinged:
Is there a way to make RC1 encodes also DivX compatible? A small utility maybe?
Doubt it's worth the effort...RC1 has been around for only a couple of weeks, the issue is minor, and it was quite obvious that the next release would be rather soon. But that's just my opinion. :)

[erdie]

Originally posted by crusty
erdie:
Is it a small clip or a big file? Check for fragmentation.


~30mins ~300MB

what's "fragmentation"?

[NoX1911]

I used to playback xvid with ZoomPlayer(@StandardRenderer) to avoid OverlayMixer. But since RC1 it doesnt work anymore (always OverlayMixer). Any plans to put a switch in config to disable this?

[kadajawi]

erdie: defrag your hard disc. (accessories/system programs/defrag (or something like that) if you're using XP...)

[ARDA]

quote:
--------------------------------------------------------------------------------
Originally posted by sh0dan

Since there are also several places in the decode part that needs this,you can download
codec.c. The code is tested with both input and output YV12,and it works perfectly with
material that is only mod4.(You can see my changes by the missing tabs ;-)
--------------------------------------------------------------------------------

quote:
--------------------------------------------------------------------------------
Originally posted by Koepi

@sh0dan.
thanks a million for the fix, I sent it further to xvid-devel
--------------------------------------------------------------------------------

I've just cvs update, used codec.c modified by sh0dan and compiled.Can confirm mod4 YV12
(decoder) is fixed when open a d2v with avisynth and virtuldubmod.Just tested with avisynth.

Thanks all for the great work.

Regards
ARDA

[MTskull]

yes i am using ffdshow to decode, its what i have to decode divx because i dont want to deal with gain spyware junk.

[ChronoReverse]

And yet, the normal version of DivX5, which decodes ALL DivX5 content, contains no spyware at all to speak of.

[mikeX]

@ MTscull

ffdshow has a known bug which causes stuttering when playing xvid content with B-VOPS > 1 and packed bitstream, it has been mentioned many many times, you should use the search first!

to work around this, you can:
1) disable xvid in the codec configuration in ffdshow (so that the xvid decoder will get used for xvid clips and ffdshow for all others) or
2) not use 'packed bitstream' with more than one consecutive B-VOPs or
3) completely uninstall ffdshow and use only the xvid decoder (it can decode divx as well)

@ erdie

simply put, 'file fragmentation' is when parts of a file are written in different areas of your hard disk, thus slowing down the process of accessing that file
i don't think that this is a likely scenario for your problem though...

[sapient]

Whatever got fixed to allow b-frame playback with the divx decoder seems to have helped x-card playback with the latest drivers too. I haven't checked thoroughly, but things are definetely better.

sapient

[mikeX]

well, finished encoding the whole movie:

source DVD PAL 16:9 progressive anime 1h 44min

avs script: nic's mpeg2dec3-1.10, crop(0,8,0,-8)

xvid, 1st pass:
defaults -packed_bitstream +adapt_quant +PAR=16:9 +cartoon_mode +BVOP_sens=2
+zone of 6746 frames with weight=0.1,start_w_keyframe, greyscale, BVOP_sens=5 (for end credits)

xvid, 2nd pass:
target_size=670720, defaults+1st pass settings

the movie came out 682092 KB, ~10MB oversized

i got the same oversize (~10MB) for that movie with rc1, it must be the weight zone for the credits that's causing this, since i tried using overflow improvement/degradation and control strength of 60 and 80 (with rc1) and the movie still came out ~10MB oversized

the credits also appear to leave a trail of white dots behind them as they scroll upwards

[Danzel]

@mikeX
Did you set your credits to be really small?
I had a problem where I set the credits to use a real small bitrate with many BFrames and used trellis quantization the credits left a mess as they went up the screen, I disabled trellis and everything worked fine.
However this is a totally different setup to you, as I was using Dev-Api-3 (with trellis backported, the last api3 release by keopi IIRC) and encoding my credits seperately from the main movie.

in short: try disable trellis and see if your credits are better.
(Of course I may be completely wrong)
And I'll test low bitrate trellis on scrolling credits when I get home later....

Danzel.

(I did report this trellis thing quite a while ago but no one responded)

[sysKin]

Originally posted by mikeX
i got the same oversize (~10MB) for that movie with rc1, it must be the weight zone for the credits that's causing thisThat is true, very low values (below 0.2) cause something like this. I recommend using 0.2, it still gives quantizers below 20 in most cases.

Some time ago I thought that 0.01 would also work but I was wrong.

Radek

[sagill]

I'd like to know why in recent releases (RC1/RC2) packed bitstream is enabled by default. ;)

The Xvid FAQ states "It is safer to have it turned off."
One of the guides says "2 pass encoding does not work correctly when this is set" (I guess this advice is outdated)
And also ffdshow has problem with it if b-frame is set higher than 1.

I read through the posts in the "packed bitstream question" thread. Nobody seems to be able to give an advantage of using packed bitstream (other than better cutting in VirtualDub). So actually what is it good for? :confused:

[sysKin]

Originally posted by sagill
I read through the posts in the "packed bitstream question" thread. Nobody seems to be able to give an advantage of using packed bitstream (other than better cutting in VirtualDub). So actually what is it good for? :confused: The advantage is in cutting and generally using vdub. The disadvantage is not in xvid but in ffdshow.

As a result, much less people complain (to us) about ffdshow problems than would otherwise complain about "b-frame decoder lag" problems.

Radek

[sagill]

Originally posted by sysKin
The advantage is in cutting and generally using vdub. The disadvantage is not in xvid but in ffdshow.

As a result, much less people complain (to us) about ffdshow problems than would otherwise complain about "b-frame decoder lag" problems.

Radek

I see. :D
Thanks for the explanation.

Just have another question come up. Does quarterpel in RC2 still cause (possibly) artifacts when decoded in DivX5?

[free666]

There is an archive with several matrices included in the Xvid instalation...i wonder if it is possible to get further info or specification of them...thanx

[TripleA]

First: excellent work! I never dreamt, pre v1.0, I'd be able to fit Armageddon on one 90 minute CD and still have it watchable. I should try to locate "Bring it On" again, I guess.

Second: there seems to be a small, rather cosmetic, bug with the code that calculates the "Total" values in the status window. Or a totally new use of the word "average" I wasn't aware of before: it's telling me here that while the minimum quantizer is 4 and the maximum 5, the average is 1.97.

The actual minimum is 2, btw.

And it's not an undersized-target "bug" (what is that, btw, a bug in the user? :))

[nanga parbat]

hullo

it's telling me here that while the minimum quantizer is 4 and the maximum 5, the average is 1.97.

i guess you didn't use b-frames in that case. i have noticed this thing with niltze, too. there seems to be a slight calculation problem for avg quants as well as avg framesize when b-frames are not in use. i haven't done it, but i guess when you calculate it it for yourself you will find that the values '0' get somehow taken into account, thus giving an avg quant of less than 2 if only quants of 2 and higher got actually used.
the avg values will be correct if b-frames are used.

apart from that, great work! very clean installer, koepi.
i also like the new bitcalc.

guidance, nanga

[Heini011]

hi,

i have the same playback problem as with xvid rc 1 here. after playing few seconds fine, xvid drops occasional a single frame, blayback gets jerky. this is most obvious at the credits, when font is scrolling.

playback is fine with xvid beta 3 as decoder, but with rc 1 or rc 2 it gets jerky. :-(

i use no postprocessing. rc 2 results are the same with the following players: Windows Media Player 6.4.0.7.1112, 7.00.00 and with Media Player Classic 6.4.6.9

CPU-Load @ credits: 25% (with Windows Media Player 6.4)

video encoded with xvid rc 1:

resolution: 720 x 448

Profile @ Level: AS @ L5
Quantization type: H.263
BVOPs: 3 / 1.50 / 0.7
Closed GOV: yes, Packed bitstream: yes
Motion search precision: 6 - ultra high, VHQ mode: 4 - wide search
Use chroma motion: yes, Maximum I-frame interval: 250
Quantizations: all 2-31
trellis quantization: yes

credits: seperatly encoded with single pass @ q10.

container: avi
audio part: vbr mp3 (the problem remains without audio too)

system: win me
athlon xp @ 1900 MHz, nForce 2, Radeon 9100, 256 MB RAM
system is prime95 and 3dmark01 stable.

note:
- disabling b-frames did not help with rc 1.
- xvid manual uninstalled before new install
- defaut options always loaded at first time

i hoping very much that this gets fixed soon or that the beta 3 decoder is coming back...

greetings, Heini011.

[erdie]

Originally posted by kadajawi
erdie: defrag your hard disc. (accessories/system programs/defrag (or something like that) if you're using XP...)

that's not the problem.

[4N]

Hi,

in xvid there are a lot of profiles, and I think that it should be written when a profile corresponds to a certified divx profile,
eg: AS@L?/Home theater

[Olleman]

Hey!

I've found what I at least think is a bug in the latest XViD release (RC2 Jambo!). I've encoded an episode of ducktales from a DVB source with all XViD settings to their default except the "cartoon mode" wich I have turned on.

And I get those weird color problems in many frames. They are not particular to only Keyframes etc, they seems to appear more or less random.

Here is one frame that's messed up:

http://apollo13.mine.nu/ducktales_bad.jpg

and here's the one right after this one and this doesn't have the color problems:

http://apollo13.mine.nu/ducktales_good.jpg


The resolution is 512*384 and I've used GordianKnot with Lanzoz resize filter and TomsMoComp. Exactley the same settings as with RC1 wich I had no problems with.

Just thought that needed sharing :)

Regards, Olle

[Koepi]

The image has 1023x768 resolution here, not 512x384.

If that'd be the case, the uneven resolution will be responsible. The YV12 stride fix is for the next release, but maybe you could try gamr's instabuil to see if it gets fixed by that. Alo check your avisynth script - scroll with vdub to the same location and check if the source has _not_ this problem.

This can also be a temporal filter if i look at it again. (That would mean: no xvid bug, but filter effect).

Check that please and report back. :)

Regards
Koepi

[Olleman]

Hello Koepi!

Thanks for your fast reply.

Firstly, let me comment on the resolution of the pictures, I did a real lazy thing and just did a print screen and then cropped it with PhotoShop, thus the strange resolution :)

And secondly I can only apologize, this problem has in fact nothing to do with XViD. The problem is TomsMoComp (yes, the resolution was dividible by 4) that makes these artifacts...allthough I have no clue about WHY since it has worked before with the exact same crop values...

Nevertheless, it wasn't XViD in any way. Let me also just say that you're all doing a great Job and the latest builds of XViD has been phenomenal!

Best Regards, Olle

[sh0dan]

Originally posted by Olleman
Hey!
I've found what I at least think is a bug in the latest XViD release (RC2 Jambo!). I've encoded an episode of ducktales from a DVB source with all XViD settings to their default except the "cartoon mode" wich I have turned on.

Are you sure this isn't present in the source? It doesn't look like a typical stride error. Try finding the same frame in vdub (using the avs script), and compare.

[chilledoutuk]

use mod16 and see if you get the same colour distortions.

tomsmocomp is good deinterlacer but on DVB sometimes you need to blend.

[fccHandler]

I'm late coming into this thread, but I just wanted to say that the new RC2 seems to have finally cured my "packed bitstream" problems with the DivX decoder. (I knew it would be better to nag you guys! :p)

The quality is absolutely stunning. I also like the new installer (very professional looking). Thanks so much for your excellent work!

[Koepi]

chilledoutuk, sh0dan:

is it just me or didn't you read the second post on this page? It wasn't a xvid problem, it's a temporal smoothing artefact from the filter chain which Ollemann just verified. :)

fcchandler:

I'm glad your problems are solved and that you like the installer :)

Regards
Koepi

EDIT: corrected wrong Nick in my response, sorry %)

[mikeX]

back at 1800+ with northbridge cooler, right on...

@sysKin

yeah i remember you saying 0.01 could be nice for credits (aslo hinting to try out 0.00), that's what i had as a guideline when making those tests (my original weight zone config was at 0.00, same oversize problem, then went to 0.01) :rolleyes:
quant 31 zones have worked fine for me before rc1 (beta versions), do you know by any chance if they have problems now? (well i'm actually working on such an encode right now, will know in ~6 hours...)

--: edit

@ Danzel

oops, i totally missed your post somehow...
well i never really use trellis, so that's not it
Offcourse i give credits very little bitrate, and the 'artifacts' could easily fit into the description of b-frames artifacts, but as i mentioned earlier i've had (much) better credits, even @ quant 31 with 2 consecutive b-vops (only difference in settings could be Q-Pel (<-- that's probably it) and chroma-optimizer (unlikely))

[aaar9800]

I think I found a bug in the "XviD Status" dialog

http://rube.741.com/xvid_status.PNG

As you can see the total min quantizer is wrong. It should say 2 instead of 4.

[sdsalsero]

I have a collection of videos recorded with both Beta3 and RC1 which are in 480x480 size. I play them back in Zoom Player 2.9 and 3.0 with the aspect-ratio set to 4:3. This has always worked fine (and with other codecs, too). Now, with RC1 and RC2, I'm unable to adjust the aspect-ratio during playback. If I revert to Beta3, everything works correctly again.

Any idea what's going on? Do you want me to try anything else?

[TruckChase!]

No probs here sofar, thanks for keeping development going on this guys.

[ChristianHJW]

Just allow me to add that Tim Jansen has recently sent me an updated build of his XviD DirectShow encoder filter, compiled against beta3. Nibor didnt have time to make a nice installer around it, so the release was delayed for this reason. I am trying to get Tim to compile a new version against Jambo now, so that we can use q=1 for high quality real time analog capturing. More news hopefully soon ....

[Leak]

Originally posted by sdsalsero
I have a collection of videos recorded with both Beta3 and RC1 which are in 480x480 size. I play them back in Zoom Player 2.9 and 3.0 with the aspect-ratio set to 4:3. This has always worked fine (and with other codecs, too). Now, with RC1 and RC2, I'm unable to adjust the aspect-ratio during playback. If I revert to Beta3, everything works correctly again.

Any idea what's going on? Do you want me to try anything else?

I'd guess somehow ZoomPlayer is honoring the aspect ratio settings in the video file - try going to the "Aspect Ratio" tab in the "Level @ Profile" dialog (hit "more..." right next to it's combo box) and choose a 4:3 picture aspect ratio there (which is what you want anyway) and see what happens.

np: K-Taro Takanami - Portrait Of Tenderness (Chobits OST 1)

[mikeX]

quant zone @ 31 worked like a charm, the file is 670668 KB (670720 KB desired) plus the credits at the end don't have that nasty effect they had before with the weight zone (that's weird though, do they get less bitrate with a weight zone of 0.01 compared to a quantizer zone @ 31?)

[Matthaeus]

Hi there!
I have a very strange problem with the bitrate calc. When I select an audio file to get its size, the size entered in the Subtitles field not in the Audio/Size field!

[Koepi]

Matthaeus:

the problem is known and already fixed for the next release.

Regards
Koepi

[alky]

vdub crashes when opening a xvid rc2 2 pass encoding:

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 0 with "XviD MPEG-4 Codec" [biCompression=44495658] (VideoSource.cpp:1823).

it was done from an interlaced mpg2 capture using this avscript:

mpeg2source("D:\Capture\Tuner_0-4-20040208-0215\Enterprise.S01E02.d2v", 6, 2)
ColorYUV(Levels="PC->TV",gamma_y=40)
Crop(14,72,-8,-72)
BilinearResize(640,390)

xvid settings:
turbo mode
using chroma motion
wide search vhq
adaptive quantisation
interlaced encoding
quarter pixel
global motion compensation
no packed bitstream
everything else default

the video plays fine with ffdshow but not with xvid as decoder (but need xvid for muxing with sound)
any idea what went wrong?

[sysKin]

Originally posted by alky
An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...This is scary, and it's quite important for us that you cut a piece of this movie (beginning - a keyframe and some frames) and send it to syskinATihug.com.au or otherwise upload somewhere.

Thanks,
Radek

[alky]

i now tried it with "start with keyframe" but doesnt help... here is a sample and the full crashreport:

http://web00020.ipax.tk/xvid

[m0rtal]

strange thing, it doesn't crash on my side...

edit: oops, sorry, it really crashes!...

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 0 with "XviD MPEG-4 Codec" [biCompression=44495658] (VideoSource.cpp:1823).

but playback is OK

[celtic_druid]

Same here, well almost.

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 0 with "XviD MPEG-4 Codec" (VideoSource.cpp:[b]1772).

Could have something to do with the height being 390, try using 384 instead.

[Koepi]

Ah, the good old yv12 stride bug.

It's fixed in CVS, fetch gamr's build and see if it helps :-) (non mod4 res. in yv12? sounds weird to me)

Regards
Koepi

[alky]

tried http://xvid.gamrdev.com/download.php/build/athlon/stamp/200402031210/XviD-athlon-200402031210.exe same thing but using mod 4 resolution helps, thanks!

[Leak]

Originally posted by Koepi
It's fixed in CVS, fetch gamr's build and see if it helps :-) (non mod4 res. in yv12? sounds weird to me)

Is it just me, or did Gamr's autobuilder go boom?

His last build is from the 3rd of February... :( (which, of course, means your RC2 is actually more current than his last build...)

np: Mouse On Mars - Funky Tiste (Glam)

[Selur]

same here :(

[Koepi]

Maybe i have to add a hidden "my most recent build" section, so that in such cases my latest build - working or not - is available for testing bugfixes.

...i'm thiking about a solution, maybe I'll come up with something fancy the next few days ;)

Regards
Koepi

[homersapien]

Xvid=All options at default, 2-pass encoding. 2nd pass file is fine when played by itself. However, when I mux it with an .ogg using OggMux 1.5.1 the resulting .ogm file has playback issues: lots of pixelation and 'smearing'. Yes, I know you'll say its OggMux's fault yada yada, however it has only done this with Jambo and whatever RC1. Does it with Xvid and ffdshow decoding.

[Selur]

Maybe i have to add a hidden "my most recent build" section, so that in such cases my latest build - working or not - is available for testing bugfixes.
Yup, a current bugfix builder would be nice so we would be able to grab it from yours and Gamr's site if everything runs fine ;)

Cu Selur

[Koepi]

homersapien:

this is indeed weird as it works correctly here:

- OggDS 0.9.9.5
- OggMux 0.9.5

Maybe you defined a mapping from xvid to divx in OggDS? Any other filters loaded (SubTitDS)?

Koepi

[_rEuTeL_]

no more flipped videos with this new release, great :)
keep it up

[Micro]

I am having a problem with RC1 & RC2 DS decoder !

Reported in this and RC1 thread previously,
20-30% of tried by me different XviD material
has stuttering problem.
Some data:
P4 3.0GHz, OS: WinXP SP1, DX9b, cpu usage is around 20%
ATI Radeon 9600Pro with latest drivers.
I am using not so well known but extremely powerful MV2Player.
The problem shows itself only when using overlay mixer.
With VMR7 or 9 I have no problem.
With 1.0 betas I had no such problem.

It seems, that audio/container has no influence on this problem.

Please consider this bugreport when preparing to 1.0 final.

XviD dev's, thank you for best encoder ever !

Micro

[_rEuTeL_]

hmmz, have to report a strange issue though
when I use min quantizer 1, the quantizers are really fluctuating (all the way up to 25 Ò.ô) with serious quality drops as a result (duh :) )

when using min quant 2, it doesnt fluctuate

[Koepi]

reutel:

do you talk about single pass (CBR) encoding?

[_rEuTeL_]

nope, happens in second pass

[Koepi]

That's most likely the result of the automatically increased overflow spreading for q1 occurences. I still think it's smart, but it must be tested and tuned a little more i fear.

Regards
Koepi

[celtic_druid]

If anyone wants to test the bug fixes then they are welcome to try:
http://celticdruid.no-ip.com/xvid.cvs.2004.02.13.rar

Download will probably be really slow though.

Ok, looks like gamr's instant builds are working again.

[sdsalsero]

I'd guess somehow ZoomPlayer is honoring the aspect ratio settings in the video file - try going to the "Aspect Ratio" tab in the "Level @ Profile" dialog (hit "more..." right next to it's combo box) and choose a 4:3 picture aspect ratioLeak,
Thanks for the suggestion but the problem seems to be on the decoding side of the equation -- with Beta3 I can correctly playback files encoded with both Beta3 and RC1. But RC1 and RC2 ignore ZP's 'request' to adjust the aspect-ratio. I have the same problem with "Xvid" files (of unknown origin or codec version) downloaded from P2P networks.

[erdie]

the jerky playback issue really is a pain in the ass.
the only workaround is not to use packet bitstream, compensate for b-frame lag while muxing, and using ffdshow for playback...

[temporance]

Just discovered a little problem with the GUI. If lauched from a command line application, the status window appears, but it's just grey with no controls. It disappears at the end of encoding. HTH.

[Maurizio]

@Temporance
I have the same problem.
I usually work with avs2avi, started from a batch file.
If I enable the status window, all I see is a gray window,
that becomes white if I cover and uncover it with another window.

[Koepi]

That issue is within the calling applications.

They don't pass through windows messages - thus the controls of that staus windows can't be build up and actualised.

Head to the author's homepages and ask them to add support for windows message passing, and you're done :)

Regards
Koepi

[vlada]

Hi,
I would like to see the constant quality setting back. If I choose onepass, there is a selection of constant bitrate and constant quantizer. What about to add constant quality, which would give the same result (quality) as twopass but with unpredictable size. I would like to use it for temporal TV recordings, which I won't burn on CDs or DVDs. Is it possible? I think it should be. Thanx, Vlada

[Leak]

Originally posted by vlada
I would like to see the constant quality setting back. If I choose onepass, there is a selection of constant bitrate and constant quantizer. What about to add constant quality, which would give the same result (quality) as twopass but with unpredictable size. I would like to use it for temporal TV recordings, which I won't burn on CDs or DVDs. Is it possible? I think it should be.

You do realize that the "Quality Mode" percentage wasn't ever used for anything other than calculating a fixed quantizer?

IIRC, it was something like

(1-quality/100)*(max_quant-min_quant)+min_quant

i.e usually

(1-quality/100)*29+2

when using the default quant ranges (2-31), so quality 100% would give you a constant quant 2, 0% a constant quant 31 and non-integer quant values made the encoder alternate between the nearest integer quants, which is exactly why you can use floating point numbers as a quantizer in fixed quantizer mode now.

I doubt the developers will add another way of specifying a fixed quant if it won't do anything but add further confusion... :)

(Also, I'm not quite clear why you're comparing quality mode to two pass encoding since they could hardly be much more different, as two pass mode will give you fixed size or average bitrate, but not constant quality...)

np: Mr. Lif - Heavy Artillery (Emergency Rations)

[temporance]

Originally posted by Koepi
That issue is within the calling applications.

They don't pass through windows messages - thus the controls of that staus windows can't be build up and actualised.

Head to the author's homepages and ask them to add support for windows message passing, and you're done :)

Regards
Koepi Aha. The DivX status display works fine in my app: could there be a workaround within xvid?

[dimzon]

yes, please return back quality mode. I understand that this mode is equal to constant quantizer but quality mode (with percentage) is more comfortable for me :)

[free666]

Hi
a problem has occured in my ripps...since Xvid RC1 a have problem with motion estimatimation in my avis...motions time to time look snatchy...i tried several Xvid settings but none of combinations I´ve tried solved this...æan anybody advise me what to do? thanx in advance

[vlada]

Leak: I know that Quality used to be a constant quantizer (but not always an integer). I was asking to implement a new way of deciding for the right quantizer, which would allow a constant quality for the whole movie. I don'd think, that constant quantizer will give a constant quality. But I don't know if it is possible to do it in one pass. I belive it should be. This is what I was talking about.
(Also, I'm not quite clear why you're comparing quality mode to two pass encoding since they could hardly be much more different, as two pass mode will give you fixed size or average bitrate, but not constant quality...)
I always belived, that two pass should give the best possible quality to all scenes, while targeting a specified average bitrate or size. I would call this a constant quality.
Vlada
P.S. Sorry for my english

[Koepi]

Since you can set fractional quantiser, it is a perfect match for "quality". Set it to i.e. quant 3.5 and see for yourself.

regards
Koepi

[chemmajik]

Yeah its a shame people have to know how to calculate setting to set a 1pass hq setting within XVid, in the beginning it worked just fine when there used to be a HQ 1pass setting for dummies! Until its fixed divx5 will continue to dominate on the alt.binaries forums... people have better things to do then 2 pass...

[kilg0r3]

@ vlada

constant quantzier = constant image quality

IMO a constant quantizer compresses every image by the same amount, i.e., it withdraws the same amount of image information, i.e, it reduces the image quality by the same amount. So, IMHO there is no difference between Divx' quality mode and Xvid's constant quantizer.

What you might want - just my interpretation - is an encoding mode that acts a bit like a second pass without first pass (roughly an ABR mode). There it would be possible to specify a given target bitrate but still take advantage of VBR features plus psycho visual decision algos that selct higher quantizers in where you don't easily notice bad image quality.

But wait isn't that already implemented in the form of CBR together with the three parameters Reaction Delay Factor, Averaging Period, Smoother?

Cheers

[sysKin]

Originally posted by kilg0r3
IMO a constant quantizer compresses every image by the same amount, i.e., it withdraws the same amount of image information, i.e, it reduces the image quality by the same amount. So, IMHO there is no difference between Divx' quality mode and Xvid's constant quantizer.Good conclusion, bad argument :devil:

Constant quantizer does not mean constant quality. Higher quantizer means lower quality and vice versa, but only if you concider one frame. In different frame, same quantizer will give different quality.

*Real* constant quality encoding is a very difficult, multi-pass thing to do and involving *adaptive* quantization (so quantizer is not constant, contrary). I'm not aware of any encoder ever trying that.

Divx, xvd and any mpeg1/2 encoder I've ever heard of use constant quantizer in their "constant quality" mode. It's just an easy thing to do.

:)
Radek

[dimzon]

Originally posted by Koepi
Since you can set fractional quantiser, it is a perfect match for "quality". Set it to i.e. quant 3.5 and see for yourself.
Yes, I understand that. But quality mode is more understandable :)
I think it's very easy to add quality mode in XviD 1, you must ONLY change XviD setting's GUI, just add "quality in % mode" and internally convert %-s into quantizer using well-known formula. I.E. "quality in % mode" will be just "shortcut" for constant quantizer

[kilg0r3]

Good conclusion, bad argument:devil:
Yeah .. erm .. Ouups, I did it again. :o

[Philippe734]

hmm, personnaly i don't want install RC2, cause i am entierely satisfy about RC1, higly quality, no problem while encode, no bugs, satisfy about interface configuration, i have nice control about parameters, all my encoded are in my hopefully (~). actually i think about speed encode, to fast to bad, so be patient. and i patient. i stay with RC1.

[springl]

A wish: a first pass at quantizer N (N = 2,3,4,...) as fast as the "regular" first pass.
Will it remain only a wish?
:)
Thanks for the great Xvid
Sorry for my poor english

[Danzel]

@springl
The whole point of Fast First Pass is that it is faster because it doesnt do full motion estimation and encoding, so sadly your request will never be forfilled. (well, in theory it could but the results would be of less quality than a normal fixed quant encode.)

Danzel.

[sysKin]

Originally posted by Danzel
@springl
The whole point of Fast First Pass is that it is faster because it doesnt do full motion estimation and encoding, so sadly your request will never be forfilled. (well, in theory it could but the results would be of less quality than a normal fixed quant encode.)Huh? No, quite contrary. 1st pass *should* be done at quants 3 or 4 or 5 - and yes, should be as fast as possible.

It's an easy thing to do, already on TODO after 1.0 final is out.

:)
Radek

[Joe Fenton]

I've noticed that the backwards compatibility of RC2 is even lower than RC1. Where RC1 would play most pre 1.0 XviD streams (but not all), RC2 plays even fewer old XviD streams. Something needs to be done in the decoder to handle old XviD streams. I have hundreds of encodes I made with the older XviD that now require me to uninstall the 1.0 and reinstall the older XviD, then back again to play new XviD streams.

Edit: more info - if I switch from overlay mode 1 to VMR-9 mode, they play fine. Maybe something in the colorspace code is whacked. I'm not too sure how the codec colorspace handling meshes with the overlay mode used by player programs. In the meantime, I can at least watch the stuff in the other mode, so it's not so bad anymore. :)

[chemmajik]

I asked for the source code to xvid 2yrs ago, that includes filters when I understood programming, now I bitch & get warnings from doom forums today because of the reason I bitched about live video 1pass capturing! I will prob get banned for 30days for my gripe but I griped 2yrs ago why? bec they wouldnt release the code under gpl, when the code was gpl... so I lost interest... So now xvid is fkd... useless codec except 2pass.... joke not Anyways fine ban me the truth be told peace...

[Danzel]

@syskin
woops, misread the post, hahahaha, yes that will be kool :D

@chemmajik
im not sure what your on about, the source for xvid can easily be fetched from www.xvid.org (I have done so myself).
and anyone reading your post will probally discard you as an idiot.
(Can we please not get anyone more responding to his post so that we keep this thread in control).

Danzel.

[Joe Fenton]

Koepi also puts the source he uses on his site right below the binary as well. Finding source to XviD is EASY!

[m0rtal]

Joe Fenton
Koepi also puts the source he uses on his site right below the binary as well. Finding source to XviD is EASY!
Easiest than finding binaries! :)

[springl]

@sysKin
thanks for your answer :)

springl

[Ranma-kun]

I think Xvid is very near of 1.0 version, and it works almost perfect for me, the only bug I have found is this.
When I push the 'Load Defaults' button, if the Encoding type wasn't 'Single pass', it doesn't reset all the items.

Thanks to all Xvid team for your work, you are the best.
And sorry for my bad english.

PS: Koepi, there is a newer Nic's Fourcc changer in Nic's dev-api3 build (it supports drag and drop). Could you include it in your next build?

[Koepi]

Ranma-Kun:

I'll try to d/l it (or ask Nic to send it to me). Nice idea to update that software as well ;) Also, i could throw out the "usual" avi calculator of Nic's as we have one in XviD itself now. (Unfortunately I didn't find the time to extend it to OGM yet, I could throw away OGMCalc then as well).

Regards
Koepi

[Leak]

Originally posted by Koepi
Also, i could throw out the "usual" avi calculator of Nic's as we have one in XviD itself now. (Unfortunately I didn't find the time to extend it to OGM yet, I could throw away OGMCalc then as well).

Seems good to me. :)

By the way - since the bitrate calc is now more or less integrated into the VfW codec, I'd have an idea to make it even better:

How about adding a mode (I guess a checkbox in the calc window should do) where the bitrate calculator automatically fills in the target size field for every file in the second pass when the encoding starts?

That way, you could feed it several episodes of a series that are roughly the same length but still differ by a few seconds or even minutes (last episodes or episodes with a recap at the beginning can do this to you) and still get files of exactly the same size.

The codec both knows the number of frames (which in the worst case it could get from the first pass) and the frame rate (which in the worst case is set in the bitrate calc dialogue), so it knows the total running time of the video *and* it knows the size of the audio (at least if it's constant bitrate, but if your aiming for an AVI file variable bitrate is a pain anyway), so it could automatically adjust the video size for the second pass so that all files really hit the target size. (Which would be especially nice if you're encoding a series and want to fit all episodes on a single DVD-/+R without having to use the bitrate calc for every single file...)

What do you think?

np: Future Sound Of London - Max (Dead Cities)

[Heini011]

Hi,

@devs:

here were no comments to the (at least for me) most important point: stuttering playback with the standard windows-overlay mixer. [windows xp has vmr7 as default]

what is the problem here ? can't you reproduce the problem or don't you know how to fix this ?

greetings, Heini011.

[sysKin]

Originally posted by Heini011
what is the problem here ? can't you reproduce the problem or don't you know how to fix this ?Can't reproduce. I use overlay mixer all the time and have no problems. Also, no related code changed beteen rc1 and rc2.

The bottom line is that we couldn't make it b0rk with overlay mixer even if we wanted to - xvid just decodes frames and pushes them to output pin, it doesn't care if there's an overlay mixer on VMR. Code is in fact so simplistic that I can't see where it can be broken.

[gotaserena]

It is probably not relevant, nor it is an actual XviD issue, but I feel like informing everybody anyways:

Wine doesn't like the new installer -- at least the newest version in redhat. I can't get RC2 to install so I can encode using vdub in wine.

Of course I *can* install xvid by compiling the source (if I could manage to re-compile mencoder too I would be a happy camper). But it would be nice to have a GUI interface (I'm a windows n00b). Well, this is for everybody's information, in case anybody else is trying to do this. Please don't bash me.

[Koepi]

gotasarena:

this is weird. Gamr today made the setup compiler work on wine and was very fast with it, so I doubt there were any difficulties. And as long as you can compile it you should be able to use it as well.

Maybe you should uninstall your current RPM and compile wine from CVS yourself - or get a precompiled, more recent RPM build. Maybe this helps.

Regards
Koepi

[gotaserena]

Koepi:

That's what I did, downloaded the newest CVS (20040121) from winehq and compiled it in my machine. I'm not close to the machine right now, so I can't give the exact error message to you.

Having read what you wrote, I feel that maybe I did not dig deep enough into the problem to solve it -- as anything in linux asks. Thanks for the help anyways, now I know that it is supposed to work.

[Koepi]

gotaserena:

unfortunately my RL kept me from installing a recent linux distro and setup WINE myself to check it out. But I'll try the next days (if I somehow get some hours free time).

Regards
Koepi

[gamr]

gotaserena

i have the cli version working, not the gui, all my scripts are fully automated so gui is useless to me. for the record, right now im using wine-20031118, i havnt had time to run any package updates lately but it works so im not worried.

[el divx]

@Devs: This may sound a bit out of time and space but could you do us users a favor? Please implement deringing and brightness in the decoder at the next release!

PS: Does anybody if and when Nic will start compiling binaries again ?

[Koepi]

Yes, Nic will start compiling builds again, he's just very busy with different projects.

Koepi

[Heini011]

Hi,

@sysKin:

i have a windows me system and directx 8.2 installed. i can't select different overlay-mixers, but some user has reportet, that this makes a difference.

>Also, no related code changed beteen rc1 and rc2.

the jerky playback issue is the same here with rc1 and rc2. but the beta-versions of xvid 1.0 has not this problem !
all my xvid rc2 encodes can be played perfectly with divx5.05-decoder and ffdshow (without packed bitstream).

i had serveral tests done. as other users had reportet too, the playback is (nearly) perfect, when i use gmc AND qpel together (@ a 720x448 encode). all other encoding options have no influence on this playback-issue. but wait a minute - how can this make a difference here ? they slow down the decoding ! so i had underclocked my ahtlon xp from 1900 MHz to 900 MHz and now the encoding with gmc and qpel can't be played fluently (no wonder...) but the other encodings plays (nearly) perfect ! (maybe thats why i sould "up"grade to windows xp ?? ;-) )

this seems to be a timing problem: the xvid rc? decoder skip occasionaly single frames on motion scenes on fast computers.

i hope this observation helps a little. i can mailing a small testencode too, but i don't thing that this is necessary: just encode scrolling fonts at the end of a cinema-film and play it with xvid rc? on a fast pc.

greetings, Heini011.

---
resolution was ever mod 16: (sorry for my confusing 1.post)


remark:

nic's FourCC changer in koepis xvid rc2 build don't know DX50 and the internal bitrate calc don't know matroska (i think that will be the future...)

[gotaserena]

Koepi, gamr:

Like I said, I feel that the problem is in the new installer? With Koepi's build the error is:

--
Exception EAccessViolation in module setup.exe at 40DC529B
Access violation at address 411C64B7. Writing of address 00000000
--


Curiously, gamr's build installs without any problems, I'm currently using it now.

[Koepi]

gotasarena:

"in 0x00000000" means that an object couldn't be created. Thus this is a missing function in some dll - more specific, in your case obviously a "windows dll" from WINE.

Did you install a gamr's build based upon nsis or the new innosetup installer?

Regards
Koepi

[Didée]

For completeness and safety, this is a repetition of a stats-window bug report in this thread (http://forum.doom9.org/showthread.php?s=&postid=445019#post445019):

- As of RC2, when using GMC, all GMC'ed frames are counted as B-frames, not as P-frames like they should.
The bars in the graph are correct. It's the numbers in the statistical table which are wrong.

Sorry

- Didée

[sysKin]

Originally posted by Didée
- As of RC2, when using GMC, all GMC'ed frames are counted as B-frames, not as P-frames like they should.
The bars in the graph are correct. It's the numbers in the statistical table which are wrong.Actually, all S-VOPs were just ignored. This b0rked average quants, frame counts and graph too.

Anyway, you posted it a couple of hours after it was fixed (see my signature).

[Didée]

What?

RC2 MAY CONTAIN NUTS?

And I was wondering why all those black bumps appeared in my face, all of a sudden!

- Didée, /on his way to hospital :)

[gamr]

Koepi: Currently all my builds are still NSIS, i havnt had time to full change to IS

[sdsalsero]

Has anyone had to chance to confirm my post re re-sizing errors (http://forum.doom9.org/showthread.php?s=&threadid=70379&perpage=22&pagenumber=5) during playback of anamorphic material?

[Koepi]

Ok, took the time to setup a linux.

[koepi@koepi XviD]$ wine --version
Wine 20040213

[koepi@koepi XviD]$ ls -la
insgesamt 176
drwxr-xr-x 2 koepi koepi 4096 Feb 17 11:08 ./
drwxr-xr-x 3 koepi koepi 4096 Feb 17 11:08 ../
-rwxr-xr-x 1 koepi koepi 5632 Feb 24 2002 AviC.exe*
-rw-r--r-- 1 koepi koepi 79 Feb 8 11:55 doom9forum.url
-rw-r--r-- 1 koepi koepi 52 Feb 8 11:59 koepishomepage.url
-rwxr-xr-x 1 koepi koepi 23040 Jun 12 2002 MiniCalc.exe*
-rwxr-xr-x 1 koepi koepi 9216 Dez 26 18:26 OGMCalc.exe*
-rw-r--r-- 1 koepi koepi 862 Feb 15 20:05 releasenotes.txt
-rwxr-xr-x 1 koepi koepi 13824 Nov 24 07:28 StatsReader.exe*
-rw-r--r-- 1 koepi koepi 1496 Nov 28 18:32 statsreader.txt
-rw-r--r-- 1 koepi koepi 2355 Feb 17 11:08 unins000.dat
-rwxr-xr-x 1 koepi koepi 76751 Feb 17 11:08 unins000.exe*
-rw-r--r-- 1 koepi koepi 44 Feb 8 11:58 xvidhomepage.url
-rw-r--r-- 1 koepi koepi 2967 Dez 21 11:10 XviD_Quant_Matrices.zip

[koepi@koepi system]$ ls -la
insgesamt 960
drwxrwxrwx 2 root root 4096 Feb 17 11:08 ./
drwxrwxrwx 5 root root 4096 Feb 17 11:07 ../
-rw-r--r-- 1 koepi koepi 73728 Feb 15 20:07 xvid.ax
-rw-r--r-- 1 koepi koepi 729088 Feb 15 20:06 xvidcore.dll
-rw-r--r-- 1 koepi koepi 159744 Feb 15 20:06 xvidvfw.dll

The only thing which didn't want to work was the registration of xvid.ax - but you don't need that dshow stuff for vdub.

Regards
Koepi

[mazzo]

After installing Jambo, I've experienced a weird problem: The decoder jumps in and out, mostly out. When I play a XVID file, the playback becomes sluggish and coarse, and when i check in the filters section, the XVID is not there any longer.

So I'll have to reinstall Jambo. THEN it works. For some time. 'Til it's the same all over again.

Can anyone explain that? I use Win2X.

[sdsalsero]

Koepi, you weren't replying to me, were you?

[Koepi]

sdsal:

nope. that was for gotasarena.

[gotaserena]

Koepi: fantastic, I will try it again as soon as I get to the machine! Anything in your .wine/config I want to know?

[Koepi]

gotasarena:

no, nothing special - i took the sample config that shipped with the wine tarball. You can also try winex (you need to fiddle around with CVS though):

http://www.transgaming.com/showthread.php?msg=1241&forum=3&thread=1237


cvs -d:pserver:anonymous@cvs.winex.sourceforge.net:/cvsroot/winex login

...Password press ENTER

cvs -z3 -d:pserver:anonymous@cvs.winex.sourceforge.net:/cvsroot/winex co wine

than change into the wine folder...

./configure --with-x --disable-trace --enable-opengl --disable-debug

make depend && make

make install

the configfile must be in the ~/.transgaming folder and not in the ~/.wine folder ...you can do a sym link


Regards
Koepi

[crusty]

@mazzo:

That sounds really freaky...could you post as many details as possible?

Including at least:
-Hardware
-OS & OS patch level
-Used players
-Used Vdub(mod) version

Have you tried:
-decoding using ffdshow, xvid via ffdshow or just Xvid.
-different players
-restart after reinstall
-Solve this issue: http://forum.doom9.org/showthread.php?s=&threadid=24305

Please report back whether or not any of these solved your isssues.

[mazzo]

@crusty


Including at least:
-Hardware
-OS & OS patch level
-Used players
-Used Vdub(mod) version


Hardware: 1.7 GHz Pentium III
OS: Win2X - last SP
Used Players: Zoom, Media Player Classic, Crystal, BSPlayer
VDubMod: 1.5.1


Have you tried:
-decoding using ffdshow, xvid via ffdshow or just Xvid.

ffdshow libavcodec and XVid disabled in ffdshow

-different players
yes

-restart after reinstall
no

-Solve this issue: http://forum.doom9.org/showthread.php?s=&threadid=24305
no


I suspect this, though: In the left of the directory window in Win2X a miniature player window opens when you mark a media file in the directory.

If I try to drag and drop the same file to the media player, the player will disable the XViD codec.

But if I just choose "file->open" from the player, it will NOT disable the codec.

I am not sure about this.

Anyway, it only happens with XViD.

[gotaserena]

Koepi:

Success! It works! Yay! :)

It seems the problem was in wine, after all. My apologies and an alert for everyone else to upgrade wine before installing. Thanks a lot for your patience on this!

[Koepi]

...don't forget about the troble with my GF i ran into ("get to sleep now!" - "no, i've to install linux for proving that this thing works") and the time ;)

Just kidding,

I'm glad you managed to get a more recent version of WINE up and running, and that it works with vdub for you.

Regards
Koepi

[ChronoReverse]

Hardware: 1.7 GHz Pentium III

Are you by any chance overclocking? I don't believe there is a 1.&GHz P3. Unless you meant a P4 of course. In any case, does dev-api-4 have any problems with overclocked systems at all? I seem to recall dev-api-3 not being 100% perfect with overclocked systems.

[Bluedan]

I think I have to report a crash. Though I'm using latest VDM build 2424 of version 1.5.10.1 which is not advised I think the crash is clearly related to XVid code. Look as these lines:

Crash reason: Access Violation
Crash context: An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while compressing frame 47707 from 02fa0000 to 03860020 (VideoSequenceCompressor.cpp:406)...
...while running thread "Processing" (thread.cpp:120).

Just writing this I had the next crash. But this time without a warning.

avs script:

LoadPlugin("C:\PROGRA~1\MULTIM~1\Video\Editor\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\PROGRA~1\MULTIM~1\Video\Editor\GORDIA~1\undot.dll")

mpeg2source("G:\2_Türme\2tü.d2v")
crop(8,78,704,420)
TomsMoComp(1,5,1)
LanczosResize(704,288)
Undot()

XVid settings for two pass encoding:

MPEG quant type
Q-pel
max consec.B-VOP 2 | quant ratio 1,5 | quant offset 1
packed bitstream
closed GOV
full qual 1st pass
credits constant quant@15
Motion search precision 6
VHQ 2
use chroma motion
turbo OFF
max I-frame interval 300
trellis quant, apart from that quant range unaltered

I can send full crash report, bits of source video or post here again.
I don't see any "challenging" settings.
And the post RC2 fixes don't touch this issue, I think.

XP pro SP1, Barton 2500+@3200+

[sysKin]

Originally posted by Bluedan
I can send full crash report, bits of source video or post here again.Full crash report will be useful, but if you can extract a piece of source that allows you to reproduce the crash, it would be very very useful. If you can, please send whatever you've got to syskin AT ihug.com.au . Thanks.
XP pro SP1, Barton 2500+@3200+ Overclocked systems are not safe - if xvid crashes at random and you can't really reproduce any crash, I'd start suspecting overheating because of overclocking.

Radek

[Bluedan]

No overheating problem. I'm not an OC enthusiast. I'm more the hasty-shaky type. This was more a question of really saving money!
I'll never reach 60°C (CPU diode) even after hours of putting 100% load on the CPU. Cooling is essential.

I'll mail you in some moments.

[Koepi]

Bluedan:

don't behave like sysKin is stupid. He has a _very_ valid point. XviD stresses your CPU in very small points in the cpu very much, so all your cooling efforts might fail.

Don't o/c your system, run it within it's specifications. If you still can reproduce weird behavour, we're willing to investigate.
if you still insist on overclocking, use divx3 and blame microsoft for being buggy.

Koepi

[crusty]

sysKin and Koepi have a very valid point.

About eight months ago I was running my Athlon XP 1800+ juuuust a bit over spec, and Xvid encoding sessions would just crap out half way through on a regular basis. When I went back to default speed it went ok.
And this is a system that would easily run 3dMark overclocked at that speed (and higher).

I know it's hard to believe, but it can really make a difference.
XviD just stresses some part of the CPU very much, and even at small overclocks can overstress your CPU.

[sysKin]

Originally posted by Bluedan
No overheating problem. I'm not an OC enthusiast. I'm more the hasty-shaky type. This was more a question of really saving money!
I'll never reach 60°C (CPU diode) even after hours of putting 100% load on the CPU. Cooling is essential.

I'll mail you in some moments. Unfortunately I couldn't reproduce any problems with your source and avs script. I did first pass and five different second passes, all went well. I used your settings.

The crash info, however, does indicate overclocking problem - but not with CPU but with your NVidia card. Did you increase CPU multiplier or just FSB? FSB is directly connected to AGP.

If you would take a look at crashreport's stack trace, it indicates that your nvidia driver (ntdll.dll) entered some kind of unhandled exception right before virtualdub started to compress the frame and used some kind of debug output right before the crash. The stack trace after that is apparently corrupted - it says that exectution entered plugin_dump (this plugin is not even opened by xvidvfw.dll, it's only used for debug purposes) and then entered transfer_8to16sub_3dne(), which - again - could not happen from plugin_dump. This function crashed because it had incorrect parameters (all of them are wrong).

Do you use some unofficial nvidia drivers maybe? If not then, unfortunately, I have to blame overclocking. If there was at least other person having any kind of encoding crash I wouldn't be so sure, but unfortunately (well, fortunately) there isn't.

Radek

PS. Why TomsMoComp on progressive source?

[Bluedan]

@Koepi: I didn't wanna sound as if I took syskin for a novice.
It's just that I really care for overclocking/stability issues.
Even extensive gaming (my girl-friend plays prince of persia for hours !) wasn't a problem so far.
I have to run prime as the standard tool to verify.

@syskin: Thank you for your analysis! The driver stuff is weird.
It's the official one. But not the VERY latest. I only raised the FSB to 200MHz, for the multiplier is locked. It's an ASUS a78nx deluxe board. I have to look into specs again.

Will report soon. I'm currently at work.
At last I'm glad that it seems NOT the codec to be blamed, but desperate that I likely have to throttle my precious one... :eek:

[Leak]

Originally posted by sysKin
If you would take a look at crashreport's stack trace, it indicates that your nvidia driver (ntdll.dll) entered some kind of unhandled exception right before virtualdub started to compress the frame and used some kind of debug output right before the crash.

Errr... no. NTDLL is a Microsoft DLL, as the file's properties will show you...

File Version: 5.0.2195.6685
Description: NT Layer DLL
Copyright: Copyright (C) Microsoft Corp. 1981-1999

;)

np: Luomo - Live @ Ultrahang Fest 27.09.03 (http://uhfest.underground.hu/)

[sysKin]

Originally posted by Leak
Errr... no. NTDLL is a Microsoft DLL, as the file's properties will show you...

File Version: 5.0.2195.6685
Description: NT Layer DLL
Copyright: Copyright (C) Microsoft Corp. 1981-1999

;)Now *that* was lame of me ;)
Still, I hope I was right :rolleyes:

Radek

[Bluedan]

:eek:

New light on stage...
How am I supposed to find out if this dll is corrupted or somehow worth being replaced, updated or whatever?
This really leaves me in a state of uncertainty.

It's easier to blame Microsoft. Maybe some aof the latest updates wasn't advised at all!!

OT: Leak, I like the music that you're swinging to!

[m0rtal]

recently found strange bug, but cannot repeat it...
on my last encode I saw strange artifact: in top left corner there was a "triangle" area, which "legs" were laid on the edges on the movie, while hypotenuse creates "stairs" artefact when contents of the screen moves horisontally (and sometimes vertically). Though, in few minutes I've discovered that cause of these strangeness was Quantizer offset with value of 0.75. When I changed it to "1", artifact disappeared and never happened again! No matter what I was doing, including setting Quantizer offset back to erroneous 0.75, turning B-frames off and back on... WTF?

[Koepi]

m0rtal:

do you o/c your fsb or something? That may have been a biterror due to some weird circumstances. If it's not repeatable it's most likely no bug.

Regards
Koepi

[jhutch]

Originally posted by Leak
Errr... no. NTDLL is a Microsoft DLL, as the file's properties will show you...

File Version: 5.0.2195.6685
Description: NT Layer DLL
Copyright: Copyright (C) Microsoft Corp. 1981-1999

;)

np: Luomo - Live @ Ultrahang Fest 27.09.03 (http://uhfest.underground.hu/)

I have had some crashes lately with the NTDLL as mentioned above. I finally narrowed it down to two specific rips (at first I just shrugged it off as a random crash). I'm still working on finding where in the vob it dies, so once I have that info, I'll forward it on, sysKin.

One similarity I've seen is that my machine is an AMD athlon, too. Mine is not overclocked, either. I'm also gonna try running the same encode on a different machine to see if the error is specific to the computer or to the encode. (I'm at work right now, or I'd start running the tests now).

Is there anything specific I should look for or try to help with the debugging process?

JHutch

[Wilbert]

I also tried XviD 1.0 rc2, but I'm going nuts :) The filesizes are way off.

Source: huffyuv 75 frames (640x480, 25 fps).
Settings: everything disabled (VHQ=0), MPEG quantization.
Bitrate: 1200 kpbs (should result in 1200*3/8 = ~440 KB).
I and P: 1-31, no b-frames

Results (vdub 1.5.10.1):
2 passes: 180 KB (average quantizer 12.44)
1 pass: 532 KB (average quantizer 5.67)

I Frames: 2.67%, P Frames: 97.33%

Am I doing something stupid?

[crusty]

@Wilbert:

-Try setting Quantizers in 2-31 range
-Try using a bigger clip. Maybe 3 seconds isn't long enough to properly adjust for?

BTW: where did that 3/8 come from?

[Wilbert]

-Try setting Quantizers in 2-31 range
Same results.

BTW: where did that 3/8 come from?
3 seconds, 8 bits = 1 byte

[Leak]

Originally posted by crusty
-Try using a bigger clip. Maybe 3 seconds isn't long enough to properly adjust for?

I'm pretty sure I remember Koepi saying that the rate control in 2pass is tuned to clips of about half an hour or longer; I doubt it'll work correctly with such a short clip. (It *does* work great with 24-minute episodes, I can tell you... :))

np: Monolake - Remoteable (Cinemascope)

[Koepi]

It's _definatly_ the 75 frames length. It's too short. Set the overflow settings to 20 and it'll more likely hit your desired size - at the prize of fluctuating quantizers (for 2pass). In 1pass, the reaction delay factor could be set to 5, that should help.

Regards
Koepi

...who wonders why someone would encode a 75 frames clip. :)

[m0rtal]

Originally posted by Koepi
do you o/c your fsb or something? That may have been a biterror due to some weird circumstances. If it's not repeatable it's most likely no bug.
no, no o/c, usual circumstances.
problem is that I encountered this issue for the second time, but I thought that was the broken source...
and my fellows sees that error on their computers a few times exactly in XviD encodes...
but nobody can't tell when this error appears or what turns it "on"...
anyway, there is one similarity - this issue is much more visible in fullscreen mode. dunno if it helps...

[Wilbert]

...who wonders why someone would encode a 75 frames clip. :)
We are working on a comparison of smoothers for analog caps. I have limited webspace :)

I will try your suggestions. Thanks!

[Bluedan]

Now when all overclocking has been turned off both passes went fine one after another.
I still have to run Prime to verify.
To me astonishingly it means that no other app being in use on my oc'ed machine had the capability to stress my CPU that much to make it fail. :rolleyes:
Ok, must be related to a certain kind of calculation operations.

I still doubt that it causes heat issues, but for sure this CPU must have been labeled BARTON 2500+ for some reason within post-production testing.

[battyice1847]

Now when all overclocking has been turned off both passes went fine one after another.

If you would like to try and figure out exactly what is causing the problem on your machine, I highly recommend the overclocking section at http://forums.amdmb.com/ You also might want to check out the PC Hardware section on this forum.

Perhaps you need better cooling, some voltage tweaks, or different memory timings; the people on either of the forums mentioned above will certainly help you figure out your problem.

On a side note: I run an Athlon 2700xp at 200*12 with a Volcano 12, CPU die never goes over 45C even after several hours of xvid encoding :-)


Good luck getting your machine diagnosed.


-Rob

[Moitah]

Avery Lee posted this on the VirtualDub forum after researching a problem I was having (http://virtualdub.everwicked.com/index.php?act=ST&f=15&t=6105):looking at the source in CVS it looks like there are a couple of bugs in the XviD codec wrt format handling. One is that ICM_DECOMPRESS_GET_FORMAT returns a bogus biSizeImage that is 8 times too big, and another is that the handler for ICM_COMPRESS uses lpbiOutput->biSizeImage which is basically guaranteed to be garbage on entry.It turned out that neither VirtualDub nor XviD were at fault, but I thought you might want to know about this.

[Ryokurin]

Originally posted by erdie
don't know if it's the same problem, but with RC1 & RC2 I do too have stuttering playback:

* only RC1/RC2 encodes are affected
* RC1/RC2 decoder used, no ffdshow/standalone decoder
* Mplayer2 (WMP 6.4), DX 9.0, some ASUS MX 440 card
* options used for encodes: all defaults except 2 b-frames, 20 i-frame boost, all min quants set to 2

these encoded clips play fine with XviD-Dec-1.0-Beta3.exe and ffdshow using XviD-24062003-1 for decoding

postprocessing is off, CPU usage at 25-30% (Duron 1600)
clip res is 576x432, datarate about 1000kbit, no sound


I've had the same problem but its a file off of a HDTV rip 1024 rez. For the time being, ive been using ffdshow to play the file, but it somewhat not desired as it messes up the rendering often (rolling fog and all that junk) also the latest versions of FFDshow are also starting to have the same problem. Same deal with that it started with RC1

[poochie2]

Is it normal that (happened like after installing RC1) using the included filter do decode xvid (no BVOPs, Chroma On, VHQ2, Turbo, No Trellis or Qpel or GMC and so on) it seems that the playback is a little laggy, but if I install the XvidDecoder 1.0 Beta 3 all is fine?

[sysKin]

Originally posted by poochie2
Is it normal that (happened like after installing RC1) using the included filter do decode xvid (no BVOPs, Chroma On, VHQ2, Turbo, No Trellis or Qpel or GMC and so on) it seems that the playback is a little laggy, but if I install the XvidDecoder 1.0 Beta 3 all is fine? http://forum.doom9.org/showthread.php?s=&threadid=71251

:/

[poochie2]

Thanks, anyway I'd include that beta 3 decoder in Koepi's releases!
Dows anyone know where can I find the latest releases optimized for AMD processors (up to date with rc2 changes)?

[Danzel]

@poochie2
The new fixed decoder is likely to be included in the next release, if you check that thread you'll notice that syskin wants someone to test his new decoder, want to go volunteer yourself ;D

The one AMD optimized release that there was only used a faster AMD optimized mem copy, the current Xvid's are using a different optimized mem copy, so they have the advantage that that build had.

Danzel.

[Koepi]

Originally posted by poochie2
Thanks, anyway I'd include that beta 3 decoder in Koepi's releases!
Dows anyone know where can I find the latest releases optimized for AMD processors (up to date with rc2 changes)?

There are some fixes in CVS and that is the base for the decoder which will be included in the next release.

If you reference to that "amd optimized memcpy" build which was floating around, we checked that and it was just FUD - it wasn't a single CPU cycle faster than our memcpy routines (which are optimized as well if you use Nic's or my builds).
That was just big blabla without any substance. I wonder why someone would do something like that(next to the fact that it was a GPL violation as you can't simply include AMD's code). Well, bottom line, our builds _are_ heavily optimized for AMD _and_ Intel.

Koepi