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.