New Xvid FAQ...feedback requested.

[crusty]

Hi all!

Since Doom9's FAQ here is rather outdated and the new xvid builds changed a lot of things (not only looks, but also about what is safe/MPEG-4 compliant/recommended etc.) I decided to write a new FAQ for Xvid. I started out with rewriting Doom9's FAQ, but I ended up doing a total rewrite. It's turned out to be quite big and elaborate and I hope you like it.

Basic setup currently is in 5 main chapters:
Part A: Introduction
Part B: Getting it working
Part C: Options, Schmoptions....
Part D: Troubleshooting
Part E: Feedback and questions
Appendix (in which stuff like links, downloads, faq contributors etc.)


You can find it at:
http://www.vslcatena.nl/~ronald/docs/xvidfaq.html
(the site is a bit slow now and then)

What I really like is some good feedback and discussion about it.
In descending order of importance I would like feedback about:
-Content errors
-inconsistencies
-useful additions
-Spelling errors
-makeup errors/html tips
-anything else I forgot

I especially like some good tips/explanations on the following stuff which I haven't yet added or are considered incomplete:
B6. I want to compile Xvid myself. How do I do that?
C7: Single Pass 'More' settings explained
C9. Two-pass second pass 'more' settings explained

Kudos go to Koepi, matmike, Nic, sysKin, Snowbeach for helping me out on taking out many errors, inconsistencies and other crap :D.

Enjoy!
Crusty

Edit: Small update to FAQ:
Moved C15 to C16
New C15: "Things that work but are not MPEG-4 compliant."

[Soulhunter]

DAMN NICE FAQ... !!!

[kempodragon]

Very well organized format, I'll have to do a full review this weekend.

[Koepi]

Hehe, I put the link to your FAQ in the forum XviD FAQ (I did the mistake and took a short look what's currently in our FAQ. Amazing. I thought my last changes were some weeks ago. Damn. How fast weeks add up to months ;) ).

I still have some points to add (don't think i'm a jerk, I just want to help):

- most distracting from the content is for me to read "usefull" - it's "useful", with 1 "l". I know. That's picky from me.

- B2: my builds now don't even need a mmx capable CPU, I'm quite sure. though I wouldn't understand why anyone would use a 486 for encoding/decoding.

- B4: Gamr's builds are also insta-builds (=automatically compiled if CVS changes are detected, checking interval is the same is uManiacs, 20 minutes if I'm not mistaken). With all the consequences you mentioned for uManiac ;)

- D1: Loading defaults isn't mandatory after installation of newer (means: 1.0-xxx-...) builds. The registry settings will get dleted upon installation, and thus with the first codec usage the defaults get loaded anyways :) But - if you run into troubles, "load defaults" and doing the coec setup again might help as well.

Well, those are some points which i've noticed in my current, fast review (no time as usual :( ). I hope this helps, and keep up the good work!

Thanks,

regards
Koepi

[crusty]

Roger, will update asap.

Any other non-MPEG-4 compliant stuff besides what I put in C15 ?

EDIT:
Replaced al 'usefull' with 'useful'
B2: removed mmx requiremnet

B4: Added GamR and mention about CVS-tree
D1: Altered it a bit, check it now.

@ RadicalEd below:
If WMV(9) isn't MPEG-4, what is it then?

[RadicalEd]

WMV 9 was incorrectly listed as an mpeg 4 codec.

[Leak]

Originally posted by Koepi
- B4: Gamr's builds are also insta-builds (=automatically compiled if CVS changes are detected, checking interval is the same is uManiacs, 20 minutes if I'm not mistaken). With all the consequences you mentioned for uManiac ;)

- D1: Loading defaults isn't mandatory after installation of newer (means: 1.0-xxx-...) builds. The registry settings will get dleted upon installation, and thus with the first codec usage the defaults get loaded anyways :) But - if you run into troubles, "load defaults" and doing the coec setup again might help as well.

Since Gamr got his autobuilder going again, I just gave his latest build a try and noticed 2 things:

- He's still using an NSIS installer that won't automatically detect and uninstall your RC2 build, which might lead to trouble - I guess mentioning this in the FAQ wouldn't be a bad idea

- His build also didn't reset the registry settings, so mentioning hitting "Load Default" couldn't hurt either

Just my .02 EUR...

np: Markus Guentner - Lost Paradise (Audio Island)

[Koepi]

I meant to send him my updated NSIS script - but before i could do that, ReactOS took over my partition table :( It'll be some major work to get innosetup/istool running on his WINE, but if he's online again (i haven't seen him for some weeks online) i'll send him the _new_ installer system script.

But well, if you know the restrictions which apply support-wise to insta-builds, is it really necessary to mention? Someone not familiar with xvid shouldn't even _think_ about an instabuild.

Just my 2 bucks :P

Regards
Koepi

P.S.: hey crusty, does "schmoptions" imply anything in dutch? Because I don't get the joke :-/ Maybe i'm too much technical orientated though. (Btw., the thing about that "usefull"-stuff is just meant friendly. I got some very unfriendly emails when i wrote usefull in the ancient XviD Options Explained... I want you to be safe from such feedback.)

[Leak]

Originally posted by Koepi
P.S.: hey crusty, does "schmoptions" imply anything in dutch? Because I don't get the joke :-/ Maybe i'm too much technical orientated though.

Sounds like "Consequences, schmonsequences" to me, which in English is often used to downplay possible consequences of someone's actions... :)

And while I'm reading the FAQ:

- A17's "XviD will, however, incorporate new features in the future such as B-frames" sounds a bit dated to me, as it's been supporting B-frames for ages... :)

- C4 should probably note that the tab not only is just informative, but that XviD doesn't take anything but allowed options and maximum frame size into account (i.e. it doesn't limit the bitrate as the information might suggest); yeah, the dialog says so, but sometimes it helps more really driving the point home... ;)

- C8 could use a mention that by turning off fast first pass you get a perfectly valid video file in the first pass

np: Plaid - Kortisin (Not For Threes)

[KpeX]

Originally posted by crusty
If WMV(9) isn't MPEG-4, what is it then? It's proprietary. But I believe the spec is now somewhat open. More info from the search button ;)

[crusty]

- He's still using an NSIS installer that won't automatically detect and uninstall your RC2 build, which might lead to trouble - I guess mentioning this in the FAQ wouldn't be a bad idea
- His build also didn't reset the registry settings, so mentioning hitting "Load Default" couldn't hurt either

Roger, I will add something along those lines in both B4 and D1
P.S.: hey crusty, does "schmoptions" imply anything in dutch? Because I don't get the joke :-/ Maybe i'm too much technical orientated though. (Btw., the thing about that "usefull"-stuff is just meant friendly.
It doesn't imply anything other than have a bit of fun when reading :)
It's something like what Leak says. And np about the spelling error..I'm no English native either so I welcome any spelling corrections as well.

@A17: Well there you have one of the few lines of Doom9's FAQ that are still present in my FAQ...and it's outdated. LOL
Will remove asap.

@C4 I thought I already put it in..must be somewhere else where I added it. I will put another warning in C4 just to be sure. In bold. :D

C8: Yeah that button is extra in RC2 and I didn't update that part yet..I was aware of it tho.
Good that you mention that it is a valid file, I will add that.

About WMV9...I thought it was a descendant of the MPEG-4 codec of MS that later got hacked and became the DivX 3 codec. Isn't it so?


EDIT: OK, updated A17, B4, C4, C8 and D1
Check them now and see if you like the results :D

[iago]

Very nice indeed! Good work, crusty! :)

[mikeX]

hi there, just caught this nice thread and started reading the faq, it's very late here though and i'm sleepy, so i only took a quick glance at it (and got up to A4)

everything i say is to be taken as suggestions in good faith, not nitpicking or complaining :)

-inconsistencies: xvid and GNU/Linux!
(i know the average guy who stamble's into the faq uses window$, but that doesn't mean everyone using linux is an xvid/mpeg-4/video encoding/decoding guru... - at least clarify that you are talking about xvid for window$ from the beginning) (also sorry if i missed anything, i just hit find 'linux/unix' and came up with nothing, will read the whole thing tomorrow)
(i'm willing to try and figure out some very basic q&a if you want)

-Spelling (or syntax) errors:

Foreword
"explanations of Xvid options tended to be rather short and cryptic (if there was one at all)"
--> if there were any at all

A1
"GNU Public License"
--> GNU General Public License

A2
"( or more accurately to program chain that contains the codec)"
--> (or more accurately to the/a program chain that contains the codec)

"-Then the codec does it decompressing "
--> -Then the codec does it's decompressing

keep at it man ;)

[RadicalEd]

Originally posted by crusty

About WMV9...I thought it was a descendant of the MPEG-4 codec of MS that later got hacked and became the DivX 3 codec. Isn't it so?

The sources are completely proprietary as KpeX said, there's really no way to tell exactly what's in it. Microsoft has denied a relationship between MPEG 4 and WMV 9, though, and it certainly isn't compliant with any MPEG 4 decoder, so that's as close as we're going to get. If you remember back in the days of WMV 7 and 8, an ISO MPEG 4 codec and msmpeg4v3 were included seperate from WMV in WME, implying that WMV has been a seperate project from the start.

[bond]

Originally posted by crusty
the MPEG-4 codec of MS that later got hacked and became the DivX 3 codec.altough the name says something else ms mpeg-4/divx3 are not mpeg-4 compliant!

[crusty]

mikeX: Roger, spelling errors updated. Thanx. Keep up the nitpicking! :D

As you say, it's indeed mostly windows oriented.
I know linux a bit, but mostly as a server OS. I don't use it as a Desktop OS.

I'd be more than happy to put some linux stuff in if somebody tells me some details about it. (Same goes for Mac/BeOS/Commodore 64/whatever :) )

That goes basically for anyone: If you've got a better written explanation for a question/option, I'd be more than happy to replace mine with it. I just want it to be as good as possible.

-Removed wmv-9 as an MPEG-4 codec.
BTW: How about VP5/6, is that MPEG-4 or not?

[virus]

Originally posted by crusty
BTW: How about VP5/6, is that MPEG-4 or not?

No it's not. Purely proprietary format.

[Soulhunter]

Maybe something like this could be added ???

-> I get pixolous distorsions in red arears !!! (http://forum.doom9.org/showthread.php?s=&postid=390365)

Bye

[mikeX]

well i have to say that this faq is WAY MORE than just an xvid faq, but one settles for more a lot easier than less ;)

some more (a lot really) 'nitpicking' :D (got up to C6)

spelling/syntax:

A2:
Typically, a codec codes only for one type of data it's specificly designed for.
('the' type of data sounds a bit better)

A3:
In software usually means in some form of codec or decoder software,
(hmmm, maybe 'encoding or decoding'?)

more than 1 B-frame, which Xvid can handle but Divx cannot.
(well it can with the new workaround in rc2, or do you mean encoding wise?)

'that can also play divx' vs 'besides just Divx.'
(capital D, you could run a X/xvid/D, d/Divx/X find&replace with XviD, DivX)

A4:

(well, atleast in theory).
(at least)

Compression FAQ @ www.faqs.org
(maybe hyperlink the whole thing)

the car(s) dead center in his view.
(maybe just 'centered')

video information consists of this type of situation.
(maybe 'falls in that case')

The codec divides the picture up in 8x8 blocks
(maybe 'divides into'?)

DCT takes the detail in those blocks and performs a technique called the quantization process on it. The 8x8 blocks then no longer contain pixels but frequency values.
(i'm confused, are they called frequencies after the DCT or after the quantization process?)

THere are other types

look at a Keyframes without

P-frames only contain the difference between it and the previous frame.
P-frames only contain the difference between them and a previous frame.
or A P-frame only contains the difference from a previous frame.

and in this frame
(and in the current frame?)

that's alot -- the sentence doesn't really need to be in ()

-B-frames are Bi-directional
(maybe 'bi-directionaly predicted'?)

It tries to reference the previous frame, the next frame, or a mix between the two, and choses the way that works best.
(what does? the codec or the frame?)

A5:
occasional thankyou.

A7:
then come over back here
(then come back over here)

A10:
Don't Panic.

A12:
Basically two-fold:
Basically twofold:

without giving a error during compiling.
without giving an error during compilation.

A14:
but have less features or slower.
but have less features or are slower.

B2:
a computer with a 32-bits cpu.
a computer with a 32-bit cpu. (don't know if it's right but it sound's better, doesn's it?)

B3:
extra component requieres at
extra component requires at

note:: you might also wanna mention built-into-motherboard sound/network chipsets(/internal modems) which rely mostly on the cpu to do their processing

C1:
all the options are what makes
(isn't the syntax wrong, can't figure out the correct one...)

playable with other codecs than Xvid,
playable with codecs/decoders other than Xvid,

crawl but will look stunning.
(maybe 'crawl but give stunning results.'?)

containing....more
containing.... more

(in this example virtualdubmod,
you said 'virtualdub' in the beginning, might wanna replace with virtualdub(mod) for the whole faq to be sure...

C3:
that will allow give you unrestricted access

C3b:
is a first 'psychological' innovation in XviD; it is supposed make use of the
is 'psychovisual?' innovation in XviD; it is supposed to make use of the

C3c:
Especially most interlaced DVD's and VHS video's are
(wrong syntax/spelling i think)

C3e:
These macroblocks motion vector
These macroblocks' motion vector

C3f:
vector and whole picture moves.
vector and the whole picture moves.

C3h:
bi-directionally
bi-directionaly

C6:

uses the compressability data
uses the compressibility data
(dictionary says the right adj for compress is 'compressible')

encoding a life feed,
encoding a live feed,

notes/suggestions:

B6: compiling xvid:

some early startpoints:
for windows: proprietary compiler: MSvisual studio, Inter compiler
free/gnu: mingw(?), cygwin(?), bloodshed(?) (dshow problems?)
for linux: piece of cake...

some links: http://www.bloodshed.net http://www.mingw.org http://www.cygwin.com


C1: what can you tell me...

Might wanna mention somewhere that you are specifically talking about xvid >= rc1 gui
(e.g. 'More' is '...' in the betas, not to mention the 0.9x tree gui...)


C9:

Simple 'Overflow Payback Example" (all 3 options) from personal experience:
Default setting of 5 will give a higher quantizer for the majority of frames as to even out the main quantizer distribution to a small zone.
A setting of 80 is likely to spread the quantizer distribution to a wider zone (could range to the whole zone of 1-31, depends on the source/desired compression), giving many frames a lower quantizer than before but also giving a higher quantizer to (probably) equally more frames.
So what does that lead to? one frame can have a really low quant (and look really good, full of detail) while the following frame has a really high quant (looking all messed up and blocky) giving a bad overall impression...

i'm gonna try and start writing down some linux stuff (i really suck at writing stuff...)
a starting point for some linux q&a could be this thread (http://forum.doom9.org/showthread.php?threadid=67976&highlight=settings+AND+linux)

[yaz]

Originally posted by Leak
... Gamr ... his latest build ...
- He's still using an NSIS installer that won't automatically detect and uninstall your RC2 build, which might lead to trouble - I guess mentioning this in the FAQ wouldn't be a bad idea
- His build also didn't reset the registry settings, so mentioning hitting "Load Default" couldn't hurt either
... &
- it delivers a dsf seems to be quite outdated

faq is prettypretty cool ! thx a lot !!

the best
y

[crusty]

@MikeX:
Damn that's a big list!
Thanks for the continued nitpicking. :)

A2:'the' type of data sounds a bit better
If you look again, you will see that it's a contrast between interoperable and non-interoperable codecs. That's why I chose 'one' type instead of 'the' type. Sounds logical?

A3:
How about this:
"Typically MPEG-4 applications are implemented either in software or in hardware. In software usually means in some form of encoder or decoder program, while hardware implementations are typically electronic chips or circuitry designed to encode and/or decode MPEG-4."

well it can with the new workaround in rc2, or do you mean encoding wise?)
Well the workaround is so fresh you can still taste the programmers' coffee in it, so I'll wait a bit for more feedback before I change it.
And of course DivX doesn't encode more than 1 B-frame.
Another typical example would be Xvid's GMC.
Added:
"Another example would be Xvid's 3-warppoint GMC."
capital D, you could run a X/xvid/D, d/Divx/X find&replace with XviD, DivX
That's indeed one of those document-wide inconsistencies that I still have to handle.
Replaced.

A4:
maybe hyperlink the whole thing
I did, didn't you check your bottom bar @ your lower left when you highlighted it?
maybe just 'centered')
That's a nice tip. Replaced.
maybe 'falls in that case'
Nope, even better:
Replaced:
"information consists of this type of situation"
with:
"footage falls in this category"
Also check the added italics in the next sentence.
(i'm confused, are they called frequencies after the DCT or after the quantization process?)

I'm no expert, but I think the DCT transforms the texture information into the 8x8 block 'mean value/frequencies'-combo, and then the quantization process drops the frequencies.
The motion search process works mostly with the macroblocks, but if I understand correctly higher motion precisions also work on lower scale, including 8x8 blocks all the way up to subpixel-precision.

THere are other types + look at a Keyframes without
Typos...removed
or A P-frame only contains the difference from a previous frame.
Altered to:
"P-frames only contain the <i>difference</I> from the previous frame."
and in the current frame?)
Altered to:
"and in the current frame it went from red to green, then this frame would only contain the altered information"
Better?
>More typos altered...<
maybe 'bi-directionaly predicted'?)
Sounds good...replaced.
what does? the codec or the frame?)
That needs some lumination indeed...how about this:
"The codec tries to reference the previous frame, the next frame, or a mix between the two, and choses the way that works best. If the frame references only the previous frame it becomes a P-frame, otherwise it becomes a B-frame."
(Please anyone, tell me if this is technically incorrect.)

A5:
Altered to 'thank you'

a7:
Woot..! :eek:
just removed the 'over'

A12:
OK, altered.

A14:
"but may have less features or are slower."

B2:
typo..altered

B3: idem
Added: "(including 'on-board' ones)"

C1:
Added: "(Note: 'More' is '...' in the betas)"
Altered the "playable with other codecs than Xvid" sentence a bit.
Check it out.
Altered to: "crawl but will give really great results"

Will make Vdub(mod) consistent later on..thanks for mentioning it.

C2: removed 'allow'

C3b:
Altered

C3c:
Think this:
"Especially, most interlaced DVD's and VHS video's are.."
Then it will make more sense. I don't put the comma in because it's only meant to be 'thought' there, not to 'be' there.

C3e:
Altered.
Also altered any 'vector' to 'motion vector' and altered the value explanation to:
"(as a sort of two-dimensional X,Y value)"
Which is much more correct.

C3f:
Altered the whole makeup of the answer a bit, mainly for readability.

C3h:
Check: http://dictionary.reference.com/search?r=2&q=ly
It's directional + ly = directionally

C6:
Altered.

Notes/suggestions:
B6:
Just quickly added the links you gave.

I think I will add a B8:
'How do I use XviD under Linux?'

Pff... a bit tired now...gonna chill a bit.

Keep the suggestions coming!

[mikeX]

just glad to be helping out anyway i can ;)

Regarding Linux integration into the faq, i agree one or two questions are enough, since it's too much trouble integrating it into the whole thing (program chains etc)

it could be something like:
:scared: HELP, what are all those windows programs you keep mentioning, my pc says GNU/Linux at startup (just kidding)

seriously now, it could be:
Q: I see this faq concentrates mostly on using XviD under Windows, but i've heard you can use it on any Unix-like platform, like GNU/Linux. So what's the status on xvid support there?

A: Xvid can run on any unix-like platform, such as ... ...
Most of what's said in A2 applies for such platforms as well...blah blah blah...
the most commonly used applications for encoding with Xvid under GNU/Linux are 'transcode' and 'mencoder' (links etc) which come with the proper communication module for the codec (be sure to get an up to date one for the latest versions (>beta) from http://ed.gomez.free.fr or from transcode's or mencoder's cvs)
these are command-line applications but have many frontends providing them with a GUI (some common ones dvd::rip,...)
moreover xvid configuration is not handled the same way as in windows, so don't look for the configuration GUI, it's not there.
configuration is usually handled from the encoding application with the help of configuration files.
The same options apply offcource but whether or not you have access to them depends mostly on the application you use at the moment.
Check out this thread for more on that:
http://forum.doom9.org/showthread.php?threadid=67976


what do you think (these are just some basic points)?
i'm gonna post back with a more detailed version

regarding B6:
it would be great if a dev could answer on the state of the mentioned compilers (no details, just what works and what doesn't with each one)
the 'INSTALL' file that comes with the xvid source code mentions only MS Visual Studio for windows compilation...
btw that file has some useful info on compiling xvid, it's under '/xvidcore-x.x/doc/INSTALL' in the source package (at least in the bz2 archive i have)

here are some useful threads i dig up from the xvid.org forum:
ms visual c (http://www.xvid.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=1202)
intel compiler (http://www.xvid.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=549)
a guide for compiling xvid under MS VC (http://www.discdude.net/xvid/compile.html) (taken from the first thread)



back to nitpicking, :D

A2:
yeah i see what you mean, it just didn't sound right, it's no big deal

A4:
Compression FAQ @ www.faqs.org:
yeah i saw it, i actually meant something like this:
Compression FAQ @ www_faqs_org (http://www.faqs.org/faqs/compression-faq/part2/section-2.html):
instead of
Compression FAQ @ www.faqs.org (http://www.faqs.org/faqs/compression-faq/part2/section-2.html)

gets converted from whatever it was to a colour space called YUV2.
shouldn't that be YV12???

I'm no expert, but I think the DCT transforms the texture information into the 8x8 block 'mean value/frequencies'-combo, and then the quantization process drops the frequencies.
The motion search process works mostly with the macroblocks, but if I understand correctly higher motion precisions also work on lower scale, including 8x8 blocks all the way up to subpixel-precision.
hmmm, i'm still a bit puzzled, i'll have to check the 'understanding a QM' thread again :)

A7:
There also newer and more flexible file formats
(There are also newer and more flexible file formats)

A good place to start would be by reading the Avi overview on this site or the faq here.
(maybe 'A good start would be to read the Avi overview on this site or the faq here.')
(general note:I think ogm can be also referensed as 'Ogg Media File'(not sure though))

A14:
"but may have less features or are slower."
(hmmm, come to think of it be slower fits better, right?)

B3:
Added: "(including 'on-board' ones)"
(i would say especially on-board ones) ;)

C1:
maybe also add something like:"Expect different look/options/terms for versions < xvid 1 beta"

C3c:
hmmm, still, i think video doesn't have a plural

Sorry about that 'bi-directionaly' stuff, i was in a bit of a 'brain-dead' state (still am most of the time) and couldn't really think... you 'll have to change it to ll on my 'bi-directionaly predicted' suggestion at A4

nice fixes/alterations overall ;)

- some additions -

C10:
imput field and slider are inactive.
input field and slider are inactive.

C11:
Sensitivity will allow you tweak the amount
Sensitivity will allow you to tweak the amount

the amount of B-frames; A negative
'the amount of B-frames; a negative' or 'the amount of B-frames. A negative'

along with that final warning on zones you could also mention there is a known problem with weight zones < 0.2 (at least atm)

ps the italics seem like a good idea :)

[sysKin]

Originally posted by mikeX
the 'INSTALL' file that comes with the xvid source code mentions only MS Visual Studio for windows compilation...No it doesn't - point 1d explains how to compile win32 build on any unix (including mingw and cygwin, but also anything else, like linux).

Also let me point out that point 2 explains MS Visual Studio 6. VS .NET works but is not supported, mostly because it makes errors (big ones) converting project files. Other compilers are just not supported.

:)Radek

[mikeX]

No it doesn't - point 1d explains...
sorry, i meant compiling in windows, not for windows in general (cross compiling)

:)

edit: how about bloodshed, etc... any known errors there?

[sysKin]

Originally posted by mikeX
sorry, i meant compiling in windows, not for windows in general (cross compiling)Um, cygwin and mingw are windows programs :)

[mikeX]

well, i thought mingw was also needed to cross compile from Linux :rolleyes: and that this was the case mentioned in the INSTALL file

so if what is said in the INSTALL file is correct, then you can't compile the decoder with such a program (mingw or cygwin), even from windows?

[atreya2011]

Nice FAQ. Can you modify section C9. "Two pass 2nd pass more settings explained" and explain in detail about "max overflow improvement" and "max overflow degradation". I want to know what they are meant for. Interested to learn.

:thanks:

Also there is a typo in Section "C3a. What is Quantization Matrix?"

Too put it short: It's the lossy filter by which you achieve higher compressibility by losing detail. The amount of detail lost is determined by the values of each individual quantum.

The first word...(To put it short)

[crusty]

gets converted from whatever it was to a colour space called YUV2.
To be honest...don't know for sure really...I have to do some forum digging to get that right probably.

A7:
Altered

A14:
I'm not sure...both sound a bit icky to me. I'll probably rewrite it in a later stage.

B3:
I know, but I already use Especially a few words before that.
Wouldn't be right style.

C1:
Added:
"<FONT SIZE="-1">(The following description is for the Vfw(Video For Windows)-interface for the RC2-build. In other builds the interface could be different, but you will find many if not all options present in one way or another)</font>"

C3:
Well, www.dictionary.com disagrees with you. :)
video - videos

C10:
Ok, did a document-wide 'replace imput with input'

C11:
Roger, altered.

Did some minor alterations to many parts. At the bottom of the document you will find a changelog and I've added the Timezone to last-update-time

I've added B8 and did some major alterations to B6 and B7, check it out. I Hope I got the linux part right. I couldn't find a proper home page for mencoder.

I would like some more feedback on C15: What's not MPEG-4 compliant

and I think I'm gonna add another question (probably in place of C15, moving it up)
Q: What are the current recommended settings?

Also: at
http://www.xvid.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=3&page=1

I find the following Xvid flags:
"- XVID_ADAPTIVEQUANT : informs xvid to perform an adaptative
quantization.

- XVID_LUMIMASKING : infroms xvid to use a lumimasking algorithm. "

So what's the beef? I was under the impression that Adaptive Quantization was the new name for Lumimasking, but here it looks like they are two different options...
Is the Lumimasking flag there for compatibility reasons, or is it obsolete?

Keep it coming keep it coming..I've got plenty of keyboards here to trash. :D

EDIT:
sorry atreya2011, will update that error asap, I'm not very multi-threading ;)

[crusty]

OK, corrected

[crusty]

Working on C9 right now...but you have to have some patience....I'm figuring it out right now. :)

Any other comments?

EDIT:
Oh yeah, I figured a glossary would probably come in handy too...
But first I'll link to Doom9's glossary for the time being.

[crusty]

For people wanting to mirror my FAQ or covert it to Pdf, Doc, Sgi etc., please follow the following guidelines:

-always include at least my nick and the date-of-creation in the name of the document, using DD-MM-YYYY notation.
(Like for instance: XvidFAQ-Crusty-14-02-2004.pdf for today)
-always link to the current official location of the FAQ, I will add that info today in the top of the page. The newest version will be there. Current official location is at :
"http://www.vslcatena.nl/~ronald/docs/xvidfaq.html"
-Directly linking from websites to subparts of the FAQ, like linking to "http://www.vslcatena.nl/~ronald/docs/xvidfaq.html#B8", or to a download link, is allowed, but don't be surprised if I change any of them, as it's currently still in development.
-minor alterations in style are allowed when converting, changes in actual content will have to go through me first.
-Any mirror that wants to, will get listed officially inside the FAQ, (probably in the Appendix)

Thank you.

[crusty]

Current additions to C9 in progress:


Overflow treatment
'Overflow treatment' is the technique used to obtain a properly sized end result. Usually you specify a target filesize and the codec can either overshoot it's target, creating a file too big, or it can undershoot it's target, creating a file too small. Too counter this, overflow treatment can either allocate more bits than abolutely necessary, increasing filesize, or allocating less bits than really necessary, decreasing filesize. Obviously, the second process involves compromising quality.


Curve compression:
Normally the internal curve adjustment values (determined by the XviD developers after much feedback from users) are capable of delivering very nice results (I should say 'excellent' really), but if for one reason or another you want to, you can use these values to adjust the lows and highs of the bit allocation.
If you make a mental image of the curve allocation, you see a graph
with 'highs' and 'lows', sorta like hilltops and valleys. The hilltops are scenes with high bitrates and the valleys are scenes with low bitrates.
-The 'High bitrate scenes %' setting will take bits away from high bitrate scenes and give them back to the bit reservoir. (Think of a bit reservoir as a bucket full of bits wherefrom the codec hands out to each frame) Ergo, it will lower the hilltops, and the bits gained by this will be divided equally accross the entire landscape. This is useful if you really need to keep your encode within certain maximum parameters, like the maxima for a specific profile@level setting.
-The 'Low bitrate scenes %' setting will give extra bits to the low bitrate scenes, sort-of-like filling the valleys with sediment. The bits have to come from somewhere, so the codec takes all the frames in the entire encode and scrapes a few bits of them all.

So, basically, each setting favors compression of one of two possible extremes towards the average of the entire encode. The first takes down the hilltops, the second fills the valleys. The bits lost or gained are allocated accordingly to average out the entire clip.

EDIT:
Updated FAQ, now includes completed C9. Check it out.

[sh03z]

niiice job

I was looking for a good reading on XviD and finally here is one...


many thanks,

[ssjkakaroto]

excellent faq crusty! great job! :D

there are 3 lower cases on the topic links:
A2. what's a codec?
E4. how can I contribute to the XviD project?
c. XviD Developers

[george_zhu]

Very nice faq. Comprehensive.

One suggestion:

Why don't you add some explaination about "status windows"?

[atreya2011]

Obviously, experimenting with these settings may break filesize prediction completely as you're altering the basic settings of the underlying proces

Typo "proces" to "process"


'Cartoon mode' enables some mechanism in the motion estimation which drops (instead of encoding them) more macroblocks. The result is a more stable, a little less detailed image. Exactly what you need for cartoon like futurama or simpsons.


A More detailed explanation would be nice


:D

[crusty]

there are 3 lower cases on the topic links: Typo "proces" to "process"
Roger, typos corrected.
One suggestion:
Why don't you add some explaination about "status windows"?

Will do, as soon as I get around to some actual encoding again...LOL :D
<Intermezzo>No really, I'm in the process of cleaning up my pc before a reinstall of w2k. I always do a sort of 'controlled uninstall' previous to a reinstall of windows...that way I know exactly what programs to reinstall (must be 100+ at least, probably close to 200).

I b0rked my windows install because of testing too much software out for a network administration unattended install project</Intermezzo>
As soon as I have reinstalled my computer I will go back to some serious encoding.
A More detailed explanation would be nice
I took over that explanation from either Koepi or syskin. I will elaborate or replace that explanation in the near future asap.

I've also decided to underline all options, as that makes it easier to find them in the word-jungle that I call my FAQ right now. :)

[atreya2011]

First PDF Compilation.

Crusty's Unofficial XviD FAQ updated as of 15-02-2004 (http://www.geocities.com/atreya2011/index.htm)

Have Fun... :D

[virus]

just some suggested updates & mispellings detected (checked with my English dictionary)
(that's in sync with version Sunday February 15, 06.35 (gmt+1))

*A13 "Of course", not "Offcourse"
*A17 "compatibility", not "compatability"
*B2 you should also mention that cpu requirement depends on the frame size... certainly 320x240 is not the same as 1280x720 ;)
*B5 links to doom9.org's guides don't work anymore
*quote from C3:
"Step sizes will be small in the upper left (low frequencies), and large in the upper right (high frequencies)"

not correct, since the highest frequencies are in the *lower right* part. You can also point out that "higher freq=fine detail", that's a point that newbies find difficult to understand.

hope this helps :)
virus

[mikeX]

ok, here we go again :)

Spelling/Syntax:

B8: How do i use XviD on Linux?
B8: How do i use XviD on GNU/Linux?

it's not there. configuration
it's not there. Configuration

C4:
Please also realize that currently the actual limiter in the codec itself is not implemented yet,

C5:
could mention that AR is called DAR some times (Display Aspect Ratio?)

C8:
It is an avi file, and you can play it
- i see your point but it really depends on the encoding application (whether it is an avi file or not)
maybe: 'it is a playble video file...'

(Then you may choose to keep it, as the file created by the first pass will then be completely normal)

C9:
accross
across

- something i've been wondering: why isn't 0 the default for Overflow Control Strength?

I really like the 'Curve Compression Explanation' :D

C11:
settings..

maybe elaborate a bit on PSNR (at least the meaning of the term)

maybe also give the approximate min/max values for B-frame sensitivity (~ -35,+25 i think), i.e.:
"There are no real min/max values, but values under -35 and over 25 shouldn't make any more difference"

Weight zones with weight lower than 0.02 break filesize prediction.
http://forum.doom9.org/showthread.php?threadid=70379&perpage=20&pagenumber=4
unless sysKin made a typo on that post that's 0.2 (didn't get around testing it myself, only tested quant @ 31 which worked fine)

C12:
A)
how every pixels

Each frame a part of the picture where the block no longer is becomes the background colour while another part has to become the block colour. The change that would have to be encoded each frame would constitute a significant amount of bits.
:confused:

texturebits
texture bits ?

Setting 1 has a relatively small impact and it is recommended for all encodes.
maybe "A setting of 1 has a relatively small impact and is recommended for all encodes. "

maybe elaborate some more on 'Turbo', i.e. minor boost in speed, *minor* degradation in quality ?

C14:
Offcourse
find/replace all 'Offcource' && 'Off cource' with 'Of course' (damn and i was sure it was off :()

AMDs (at least Athlons) have SSE too, i think some latest models have SSE2 as well (not sure)

or DX50 to play with the DivX 5 codec.
maybe use 'decode'

C15:
did use them know and then

Although the option has been removed a long time ago, clips encoded this way somehow still work though.

with another QM work
with another QM works or may work

but are not
but is not

I discovered that a while ago that

D1:
even then, Hitting

D2:
sure all you're settings

make sure all you're settings are what they are supposed to
i don't think this means anything :confused: (maybe you meant "are what you wanted them to be?)

Switch to MPEG quantizer
"Switch to MPEG Quantization Matrix" (to avoid confusion)

Reduce the strenght

Also try more conservative B-frame settings.
maybe "Also try more conservative B-frame ratio/offset/sensitivity settings."

D7:
has enough power
better use "has enough cpu power", :D you never know what someone might think (what! do i need a new power supply :confused: )

D8:
information is encoded and decoded differently
i see what you mean but i think "information is decoded differently" is enough and more correct

E3:
the code and incompatabilites

Where not talking about security-patches
do you mean we're?

DShow filter are using to
DShow filter are you using to

Please post all your options you used
Please post all the options you used

kicked of that forum
kicked off that forum

Specify if your encode is muxed with audio (specify the audio) or not.
maybe add subtitles too(due to the vobsub flip-image thing)

E5:
least a garanteed level of
least a guaranteed level of

glory of XviD.And offcourse
glory of XviD. And of course

List of know bugs for different

-----------------
video - videos
oops, sory for the 'video' stuff, just couldn't think of an expression using 'videos' at the time (duh, music videos)

about B8:

Mencoder is not a standalone project. It's built into Mplayer --> www.mplayerhq.hu
http://www.mplayerhq.hu/DOCS/HTML/en/mencoder.html (mencoder's documentation)
adding mosu's 'dvd ripping and transcoding with Linux' guide may be a good idea too:
http://www.bunkus.org/dvdripping4linux/index.html
it's a bit outdated at the moment, will pm mosu to see if there are any plans for updates/linking to xvid faq etc

you may also wanna add this link:
http://zebra.fh-weingarten.de/~transcode/xvid4conf/
it's a program that resembles the xvid VFW gui and works with transcode's configuration files (and can also be used with dvd::rip --> http://www.exit1.org/dvdrip/)

For people wanting to mirror my FAQ or covert it to Pdf, Doc, Sgi etc., please follow the following guidelines:
what about translating?


well, the faq seems to be taking it's final form :)
My thanks to crusty and everyone who contributed for a REALLY GREAT XviD (and not only) FAQ ;)

[atreya2011]

Originally posted by mf
*VERY* simple explanation: the image is converted to detail signals (DCT), and then those signals are divided (coefficient cutting) to make it smaller. The more signal you cut off, the more detail you lose and more artifacts (blocks, ringing aka mosquitoes) you get. The quantizer is the detail removal factor (DivX3/Nandub thus calls quantizers DRF). The higher the quant, the more detail gets cut off, the lower quality.


Just a sugesstion.

Maybe you could add this in A4. MPEG-4 Basics section

Q. What's a quantizer?

[crusty]

Can't update my FAQ right now...The webserver is a bit boogered, and can't refresh the file..
I'll have to wait until it is fixed. In the meantime I'll include the error corrections in my version at home.
@virus:
"Of course", not "Offcourse"
I'll do a replace all.
A17:
same
B2:
Good point, I'll add it.
B5:
Ok, will look into it.
C3:
It's a quote from another document..hardly something I feel entitled to correct. 'If quoting, quote correctly'.
But what is probably meant is the frequencies for one axis only.
If you take into account both axes, then it would be in the lower right corner.
I'll probably add another link to my explanation of the process at:
http://forum.doom9.org/showthread.php?s=&threadid=54147
which explains a lot.

@MikeX

B8:
I think just Linux is good enough, after all everybody knows it by now. Let's try not to complicate things absolutely more than necessary OK? :) :D

C4:
Please also realize that currently the actual limiter in the codec itself is not implemented yet, as it's hard to do properly.
How about this:
"Please also realize that right now the actual limiter in the codec itself is not implemented yet, as it's hard to do properly."
(underlining not in the FAQ, just here to focus on the difference)

C5:
Good point, I'll add it.

C8:
Well usually the outcome is an avi file, but I'll change it to:
"It is a proper video file, and you can play it."

C9:
Another one of those document-wide replacements coming up... :)
something i've been wondering: why isn't 0 the default for Overflow Control Strength?
Uhmm..did I miss something? I was under the impression that it was... :confused:
Anyway I'll check it this evening.
I really like the 'Curve Compression Explanation'
I like it too. :D :cool: :D
Actually, the part I like the most is that I actually understand it at all...LOL!

In fact, during the writing of this FAQ I found that most options actually make good sense and are quite easy to understand. (Well at least to me)
The biggest problem for me was finding the right explanations in forum threads.
But, if you understand the basics of MPEG-4, everything makes sense much quicker and easier than if you don't have any clue about how it works.

Thinking about this makes me wonder if I should put a better and more fundamental explanation of MPEG-4 into the FAQ. I Probably should.

If you understand the basics behind motion search, psychovisuals (which I haven't adequatly explained at all yet) and the DCT-quantization process, things start making sense very quickly.

You can expect a major rewrite of some of the questions in section A in the future. Especially after Xvid goes 1.0, when it makes more sense to me to take out some of the items there.
(btw, looking at the (lack of) current bugs I expect the next build will be the latest RC, just to fix the really minor bus that are now present. So I guess I should start rewriting soon)

C11:
OK, I see it. Will update.

PSNR:
It's not really an XviD thingy, but expect it to be mentioned in a glossary some time in the future. Indeed, it's mentioned just too often to be overlooked.
@B-vop sensitivity:
I already put this in:
Use small values at first, it's quite sensitive.
But I'll ask sysKin for some more details on exactly how sensitive it is.

C12:
I hardly think 'texturebits' is a proper word anyway. :D
Will update.
Motion search is the process in which the codec is trying to figure out how every pixels of the original clip was moving.
Got the error.
Still, looking at it again makes me think it's not really a proper explanation. It's not the pixels that are moving, it's the content that gets portrayed by those pixels that is moving.
So it's not the motion of the pixels that gets captured, but the (virtual) motion of the objects that is captured. The codec couldn't care less about pixels anyway.
I'll have to rewrite this...
Setting 1 has a relatively small impact and it is recommended for all encodes. maybe "A setting of 1 has a relatively small impact and is recommended for all encodes. "

Well you can look at 'setting' as either a verb 'to set' or as a noun 'the setting'.
I chose the noun.
Turbo:
Indeed, forgot to mention it affects speed. Will update.
(btw:There is no *practical* degradation in quality AFAIK. But I don't know enough about it really to make a proper assumption about that)
AMDs:
I thought T-birds didn't have SSE, Athlons have SSE. Isn't SSE2 a PIV-only thing?

I would *love to* include a small table of cpu's and the instruction sets they have. If someone could post one here I'll include it asap.


C15 'know and then' in 'modulated QM' ...found it.
Anybody know any other non-compliancies?
'work' ...found it.
'but are not considered MPEG-4 compliant'..found it.
' discovered that a while ago that, while Qpel usually '...found it.
'Although the option has' ..etc. It's not exactly literature, but it's correct. ;)

D1:
found it.

D2:
'-make sure all you're settings are what they are supposed to, and that there is no error in any filter setting in avisynth and/or virtualdub.'

How about this:
"
-make sure all your XviD options have the correct settings
-make sure there are no errors in your filter settings and/or scripts in avisynth/virtualdub/whatever-tool-you-use."

"Switch to MPEG Quantization Matrix" (to avoid confusion)
Good one, will update.
Reduce the strenght
What's wrong with it? :confused:
maybe "Also try more conservative B-frame ratio/offset/sensitivity settings."
Hmmm.. I think that would be 'rubbing it in' :D

D7:
CPU power....good one. Don't want people blaming me for the wrong hardware upgrades. :D
The effect this has is that some colour information is encoded and decoded differently when playing an old file with a new decoder.
You're right, I should make it a bit more clear.
How about this:
"The 'Simple' process encoded colour information in another way than the 'Walken' process, and the latest decoders use the 'Walken' process to decode. Because of this discrepancy sometimes colour information might be decoded differently."
Much much better isn't it?
Also, the last line is incorrect, the 'bug' is known (not really a bug, more a result of a development decision) but there is no proper solution yet.
I'll make it this:
"The work on a solution to this issue is currently in progress. Since you can't detect the difference automatically, the decoder will have an option to switch decoding between 'Simple' and 'Walken'."

E3:
'incompatabilites'
replace all....
Where not talking about security-patches
Roger, will update.
-In Windows, what DShow filter are using to decode it
Not my error but Nic's. :D
Will update.
'Please post all the options you used'
Same...
'kicked off that forum'
Roger, will update.
'maybe add subtitles too(due to the vobsub flip-image thing)'
That's a good one! I think that deserves a separate question in section D.

E5:
'XviD would mean there's at least a garanteed level of continuous development.'
Roger, got it.
'glory of XviD. And of course '
..got it.
'List of know bugs for different builds and workarounds'
..got it.

B8:
Mencoder is not a standalone project. It's built into Mplayer --> www.mplayerhq.hu
http://www.mplayerhq.hu/DOCS/HTML/en/mencoder.html (mencoder's documentation)
adding mosu's 'dvd ripping and transcoding with Linux' guide may be a good idea too:
http://www.bunkus.org/dvdripping4linux/index.html
it's a bit outdated at the moment, will pm mosu to see if there are any plans for updates/linking to xvid faq etc
you may also wanna add this link:
http://zebra.fh-weingarten.de/~transcode/xvid4conf/
it's a program that resembles the xvid VFW gui and works with transcode's configuration files (and can also be used with dvd::rip --> http://www.exit1.org/dvdrip/)

Ok, I will give a link to both Mplayer and dvd::rip
The weingarten link is just a ftp directory...I dislike linking to those, as they are not really explanatory.

what about translating?
As long as it's not done with Babelfish, and you add a link to the official page it's OK. PM me with the location and I'll put it in a mirrors/translations appendix.

Thanks a lot for the corrections and keep it up!
(btw look at the bottom of the FAQ :D )

@atreya2011:
'Maybe you could add this in A4. MPEG-4 Basics section'
Sounds good, will look into it.

[crusty]

OK updated all mentioned errors (and some more).

I will have to look a bit longer into some of the other things tho..

EDIT:

Added:
D10. I installed XviD on XP but it doesn't show up in the codec list!

D11. My old XviD files don't play correctly with the latest XviD!

D12. Other issues...
(about Asian Windows, and about WMP9 issues)

[virus]

Originally posted by crusty

C3:
But what is probably meant is the frequencies for one axis only.
If you take into account both axes, then it would be in the lower right corner.

I'll probably add another link to my explanation of the process at:
http://forum.doom9.org/showthread.php?s=&threadid=54147
which explains a lot.


Your explanation in that thread looks good, but be aware that DCT stands for 'Discrete Cosine Transform' (not 'Cosinus', try a Google search with both expressions, you'll see how many pages turn up... I got 54000 vs 800 ;) ).
As for the frequencies... imho it's better not to quote text if it's unclear, I've seen some ppl confused on this topic here.

cheers :)
virus

[mikeX]

D10:
see the codecs files that are Windows is to use
see the codecs files that Windows is to use

shouldn't the question be 'i can't see xvid in the codec list on vdub(mod)'??
btw a good addition :D

D11:
There are many probably causes for this
There are many probable causes for this or
There are probably many causes for this

D12:
from a compatability mode.
you missed that one : P
ANYTHING BUT WMP9.
(:D you got that right)

I think just Linux is good enough, after all everybody knows it by now. Let's try not to complicate things absolutely more than necessary OK?
fine by me, just don't be surprised when those threatening 'Linux-->Kernel, GNU/Linux-->OS' emails start showing up :D)
seriously now, i see your point...

C4:
well actually i meant that you have both 'currently' and 'yet' (could drop the 'yet')

Uhmm..did I miss something? I was under the impression that it was...
nope, it's 5 (i think it has been since beta2 or something - not sure though)

yeap, you've got that right about the basics of MPEG4, i believe that's what makes your FAQ different from other FAQs, and quite more useful and comprehensive overall
I don't know if that's the same from the point of view of a total noob though, I mean i'm no video expert myself, but i learned a lot of stuff in the last few months about video encoding etc, most of which are present in your FAQ.
From such a point of view i find it very comprehensive and all-inclusive, but some feedback from someone clueless (but eager to learn) would be great!

(btw, looking at the (lack of) current bugs I expect the next build will be the latest RC, just to fix the really minor bus that are now present. So I guess I should start rewriting soon)
looks like it, but no need to rush things, quality over quantity ;)

C11:
About the b-frame sensitivity, it's sysKin i'm quoting on those values, but they are not 'absolute' values so it's kinda tricky whether to put them or not.
Most people would probably feel 'relieved' to see a max/min value though (what can i say, people want to feel restrained after all :rolleyes: )

C12:
Yeap i see your point about the pixel thingy, could also cause confusion with q-pel

Well you can look at 'setting' as either a verb 'to set' or as a noun 'the setting'.
oops, that's why it didn't make sense, didn't even cross my mind :D

"make sure.."
sounds good :)

strenght
should be: strength

D8:
great!

The weingarten link is just a ftp directory...I dislike linking to those, as they are not really explanatory.
yeah, see your point, it's mentioned in the dvd::rip INSTALL so it's ok, maybe it could be integrated to xvid in the future...


hehe, big all Mr. Contributor ;) thanx

translation probably on the works but at a slow pace (i posted on greek.doom9 about it)

[atreya2011]

@MikeX
Man, You must be the fastest gun in the west or something, I mean, I figure almost all those mistakes you do and then I say to myself, ok lets go post it and BINGO!, I see your post and then I say to myself, oh man back to the drawing board :D

@Crusty
By the way, how often should I add the link to PDF file in this thread as the FAQ is getting updated on a daily basis.

[mikeX]

@ atreya2011
:D the art of nitpicking...

@ crusty
might wanna check this out:
http://www.tommesani.com/InstructionSetCPU.html

and this as well (mentions sse2 support for AMD 64bit):
http://www.tech-report.com/reviews/2003q3/athlon64/index.x?pg=1

[crusty]

@virus:
Where did you find the word 'Cosinus' I can't find it.

@MikeX:

D10, D11, D12:
updated...

C4:
Well not anymore now..
nope, it's 5 (i think it has been since beta2 or something - not sure though)
I'll look into it.
looks like it, but no need to rush things, quality over quantity
My feeling exactly. I just think it's looking very good right now.

C11:
I'll look into it.

strength
'Replaced all'...

Hmm...I'll check these links.
http://www.tommesani.com/InstructionSetCPU.html

http://www.tech-report.com/reviews/...64/index.x?pg=1

Now how did I do tables again....hmmm (www.htmlgoodies.com here I come) :D

More cpu links:

http://www.qvctc.commnet.edu/classes/csc277/i_sets.html

Thanks for the corrections again.

BTW, I'll also update the Qpel question soon.

[Soulhunter]

Really not want to add it (http://forum.doom9.org/showthread.php?s=&postid=443398#post443398) ???

Or should I write a summary about this stuff... :p

Bye

[mikeX]

Really not want to it ???
oh, i wanted to point that out again (but totally forgot about it)
i find it a useful addition, and i remember it gave me some nasty headaches before i came across those posts....

[crusty]

I'll look into it Soulhunter, I just can't get around to everything in time. Patience, my man, patience! :)

EDIT:
Oh yeah right, forgot to mention:
The links to Doom9's guides were broken apparently because of an alteration at the server side that suddenly makes linking to it case sensitive. Fixed and checked.

[Soulhunter]

Originally posted by crusty
I'll look into it Soulhunter, I just can't get around to everything in time. Patience, my man, patience! :) No problem... Take as much time you need !!!


Bye

[virus]

Originally posted by crusty
@virus:
Where did you find the word 'Cosinus' I can't find it.

In your thread "Understanding a Quantization Matrix", first post ;)
(just in case you want to add this explanation or a link)
In the FAQ it's reported correctly (cosine).
BTW: the problem with the links to doom9's guides was Opera's fault, they don't work even if corrected. They work in IE6.

[Selur]

@crusty:

'I-frame closer than ... frames' sets the minimum number of non-keyframes that have to exist between two consecutive Keyframes.
Note that crossfades (the fluid transformation of one scene into the next) are particularly sensitive to this setting; They will flash or look like crap if you set this too high. Never set it higher than 10. Set this to 1 to disable forced I-frame spacing.


Are you sure about this? Your explaination makes it sound like it's a 'minimum i-frame intervall', but as far as I understood it, it just sais how many non-iframes have to be between two I-frames, so that the second one will not be '... reduced by %'

Cu Selur

[crusty]

@virus:
I had the same problem in mozila firebird, it's one of those 'weird' issues.
I'll change the Cosinus thingy in that post.

@Selur:
That's the problem...all the info I could find didn't make that clear either. I'll dig into it a bit deeper some time soon, but for now it's better than nothing.

@Soulhunter:

How about this:
<START>
Q: Why do red areas in my clip look blocked or pixelated?

A:
This is an issue with some decoding applications, it has nothing to do with encoding. The colour space used by XviD is YV12 and is a very lossy colour space. When decoding the decoder has to convert this to a full quality picture that the video card can send to either a monitor or a TV.
The lossy Xvid file has much less colour information than uncompressed video, so the decoder has to reconstruct the lost information somehow if it wants to put out a proper result. Since there is way less colour information in the Xvid than there is brightness information, the colour information the decoder has to work with is far less precise.
The underlying process is called upsampling and the colour space gets converted from YV12 to RGB32, which isn't (very) lossy. Then the RGB32 signal gets thrown at you via your monitor or TV screen.

The problem occurs when the upsampling isn't done properly; Part of proper upsampling is taking that sparse colour information and making a 'best guess' about what the values inbetween are supposed to be, creating a fine colour gradient across the picture.
A process like this is usually called interpolation and if the decoder doesn't do that properly the decoded output will not have a proper colour gradient but will look a bit blocky; After all the 'in between pixels' will not have an 'in between value' but the closest orginal value, which is far courser, and creates very visible artifacts.
For some currently unknown reason the artifacts tend to be more visible in the red parts of the spectrum. Current best guess is that it is an interaction between YV12 colour space-weirdness and the colour-sensitivity of the human eye, unforeseen by the creators of MPEG.

Now the bad news is that this is an inherent issue with the colour-space used by MPEG, not just with MPEG-4 but also with MPEG-1 and MPEG-2 (VCD and DVD). As long as the output was just on TV noboby seemed to care, but modern monitors and HDTV's are far more precise and it is now an obvious weakness in many MPEG applications.

The good news is that it's just a small issue with decoding and that it is very fixable. Also, if you turn on the chroma motion option of XviD the problem will be smaller and less obvious than usual, because it will make colour information more precise and colour gradients less abrupt.

On windows these are the known fixes:

-First method is to use ffdshow with "ConvertToRGB32()" command in its AviSynth tab (use an ffdshow version that has it).
This will make use of the upsampling features of Avisynth which work properly.

-Second method is to buy another video Card. Not recommended really...
Especially Geforce video Cards and older cards seem to suffer from improper upsampling methods. Trying another driver might help, but feedback on this has been too few and far between to really make any assumptions.

-A third method is to try to use the "VMR 9 Renderless" mode in MPC.
This will make MPC use another type of playback, possibly using proper upsampling.

-A fourth method (untested at this moment) that could hypothetically work is to first open another media file and play this simultaneously with the file you really want to play.
(the idea behind this is that only one media playback can use 'hardware overlay' which makes use of the hardware acceleration features of your video card. The next file opened cannot use these features and would be played using software overlay, which might use other (and proper) upsampling.)
Needless to say this takes quite some extra CPU and it denies you the use of all the nifty hardware features your video card has. But, it might work.
<END>

Some feedback on this would be nice.... :D

[virus]

some more improvements suggested:

from A3:

1) "ISO (International Standards Organisation)"

ISO = International Organization for Standardization
(from their homepage www.iso.ch)

2) "MPEG-4 became a proper MPEG standard in 1998, and became an ISO standard almost immediately".

On their webpage ISO labels MPEG-4 as being released as standard in 2001, not in 1998.
quote from www.iso.ch:
'ISO/IEC 14496-1:2001 Information technology -- Coding of audio-visual objects -- Part 1: Systems'
'ISO/IEC 14496-2:2001 Information technology -- Coding of audio-visual objects -- Part 2: Visual'

3) "XviD uses the improved MPEG-4 version 2 or ISO standard #14496-2"

Better "XviD follows MPEG-4 Part 2, also known as MPEG-4 Visual or ISO standard #14496-2"
(ISO standards are usually structured in "parts" which work together, eventually adding/extending functionalities)

4) you can also add this:
"the latest addition to the MPEG-4 family of standards for video coding is MPEG-4 Part 10 (14496-10) or MPEG-4 AVC (Advanced Video Coding) also known as H.264. XviD does not support H.264 though."


from A4:

"Typically these are called Keyframes (also called I-frames or INTRA-frames), P-frames (for Predicted frames) and B-frames (for BI-directional frames)"

better "P-frames (for Predicted frames, also called inter-frames)"
this should be useful since the Edit Matrix dialog use "intra/inter matrix"

hope this helps :)
virus

[Leak]

Originally posted by crusty
After all the 'in between pixels' will not have an 'in between value' but the closest orginal value, which is far courser, and creates very visible artifacts.


I think you really want to say "coarser" here. :)

Also, if you turn on the chroma motion option of XviD the problem will be smaller and less obvious than usual, because it will make colour information more precise and colour gradients less abrupt.

And of course you'll want to use "Chroma Optimizer" here... ;)

(By the way - are you sure you want to use underlining in HTML? It's easy to mistake underlined text for a hyperlink; also, it's only part of the HTML 4.01 Loose DTD and deprecated (http://www.w3.org/TR/html4/present/graphics.html#edef-U) in all other versions of HTML 4.01 and XHTML 1.0...)

np: Kilogram - A While Ago & Recently (Erlend Oye - Unrest)

[sh03z]

This FAQ is fantastic...
I read it through just once, and I went from crappy rips to perfect ones...
Once again, this FAQ r0x0rz!!!

[crusty]

@virus:
1)
Well I still use the old name..... I don't like the modern practice of institutions altering the name just to be more stylish...especially when the old name makes much more sense. :)

2)
Roger, altered it.

3)
Altered it

4)
I took over part of it. Check it out.

A4:
Roger, will alter

@Leak:
Coarser...got it.

optimizer..got it

@the underlining being deprecated:
Well it's been part of HTML for as long as I can remember. Just because some people would like everybody to use style sheets (which are much more complex) doesn't mean we have to. As far as I can tell, it works in all current browsers, and it is to be supported for backwards compatibility in the future as well.

"User agents should continue to support deprecated elements for reasons of backward compatibility."
I guess you can call me backwards... :D

@sh03z:
Well that's the kind of feedback I LOVE to hear...great that people are actually getting help from my FAQ!! ;)

[crusty]

Update: altered the 'Cartoon Mode' explanation. Gonna do Qpel next...

[Soulhunter]

Originally posted by crusty

This is an issue with some decoding applications, it has nothing to do with encoding. The color space used by XviD is YV12 and is a very lossy color space. When decoding the decoder has to convert this to a full quality picture that the video card can send to either a monitor or a TV.
The lossy XviD file has much less color information than uncompressed video, so the decoder has to reconstruct the lost information somehow if it wants to put out a proper result. Since there is way less color information in the XviD than there is brightness information, the color information the decoder has to work with is far less precise.
The underlying process is called upsampling and the color space gets converted from YV12 to RGB32, which isn't (very) lossy. Then the RGB32 signal gets thrown at you via your monitor or TV screen.

The problem occurs when the upsampling isn't done properly; Part of proper upsampling is taking that sparse color information and making a 'best guess' about what the values in between are supposed to be, creating a fine color gradient across the picture.
A process like this is usually called interpolation and if the decoder doesn't do that properly the decoded output will not have a proper color gradient but will look a bit blocky; After all the 'in between pixels' will not have an 'in between value' but the closest original value, which is far courser, and creates very visible artifacts.
For some currently unknown reason the artifacts tend to be more visible in the red parts of the spectrum. Current best guess is that it is an interaction between YV12 color space-weirdness and the color-sensitivity of the human eye, unforeseen by the creators of MPEG.
Looks really nice to me... :)

But some changes could be still there !!!


I am a bad typer, so I just try to give some infos... ;)

- This YV12 saves the color (chroma) information of a picture in a 1/4 resolution of its original...

- While playback, the chroma gets resized back to the original framesize...

- While "wrong" playback, the chroma gets only resized with lousy nearest neighbor method...

- While "right" playback, the chroma gets bilinear resized...
Originally posted by crusty
The good news is that it's just a small issue with decoding and that it is very fixable. Also, if you turn on the chroma motion option of XviD the problem will be smaller and less obvious than usual, because it will make color information more precise and color gradients less abrupt.
- No, chroma motion will not help with this problem... :(

- Its really only related to the YV12 colorspace !!!

- No possibility to fix this before playback...


Bye

[crusty]

@Soulhunter:

I don't get it...did you just completely missed the point? :confused:
- This YV12 saves the color (chroma) information of a picture in a 1/4 resolution of its original...

- While playback, the chroma gets resized back to the original framesize...
Which is exactly what I wrote....
- While "wrong" playback, the chroma gets only resized with lousy nearest neighbor method...

- While "right" playback, the chroma gets bilinear resized...
...which is a difficult way of saying something that I put in a much simpler way.
- No, chroma motion will not help with this problem...
Well, theoretically, it should mitigate the effect a bit, not solve it.
That's what I said.
- Its really only related to the YV12 colorspace !!!
That's what I wrote. :rolleyes:
- No possibility to fix this before playback...
Which is exactly what I wrote.

Really, this is too silly... do you have anything real to comment? :confused:

[atreya2011]

- detect_static_motion is a motion estimation flag. The threshold below which a macroblock is concidered static is increased so that very fine detail is lost. Since A LOT of 'very fine detail' is actually noise (especially with cartoons) it really helps saving many bits which would otherwise be used to code noise on a static picture.
- vop_cartoon is about quantization - when a block is motion-compensated well enough (with total error below the limit) it's just not coded at all. XviD doesn't drop any data in normal mode (limit = 1), but drops quite a lot in cartoon mode. Again, this usually means that noise is ignored. It might also remove some small details, but small details shouldn't really happen in "proper" cartoons.


A little help here. I don't fully understand that explanation. First
"whats a motion estimation flag" and second "whats vop_cartoon" is it another flag?

:thanks:

[crusty]

Updated it...try it now and see if makes more sense to you.
(it has too to be a proper part of the FAQ)
:)

I also updated the Qpel answer. Please tell me if you understand it.

[mikeX]

wow, i see many new additions, changelog coming?
the cartoon mode stuff sound really interesting

some small corrections:
- find/replace color with colour or vice versa (to be consistent)

Appendix:
A. useful Links
A. Useful Links

I am a bad typer, so I just try to give some infos...

- This YV12 saves the color (chroma) information of a picture in a 1/4 resolution of its original...

- While playback, the chroma gets resized back to the original framesize...

- While "wrong" playback, the chroma gets only resized with lousy nearest neighbor method...

- While "right" playback, the chroma gets bilinear resized...
i think soulhunter just meant that you could add some more details next to your explanation (like just how lossy is YV12 --> 1/4, and what is actually the bad/good upsampling method --> nearest/bilinear)

also (never noticed it myself but i've seen it mentioned) shouldn't there be a similar effect on highly saturated blue areas as well? (maybe add it in the Q?)

keep it up :)

edit: ---
C3c:
The more precise
The more precisely

[crusty]

Will update soon.

'- find/replace color with colour or vice versa (to be consistent)'
Apparently only 'color' is proper, according to spellcheck.com

'i think soulhunter just meant that you could add some more details next to your explanation'
I'll take another look at it and see if I can improve on it.

'also (never noticed it myself but i've seen it mentioned) shouldn't there be a similar effect on highly saturated blue areas as well? (maybe add it in the Q?)'

Well, the thing is, the human eye isn't very sensitive for blue in general, but it is very sensitive to blocks in blue areas. This has been known for quite a while. So the designers of MPEG-4 quickly noticed, that while you can usually assign few bits to blue areas because our eyes are less sensitve to those, assigning them too few bits creates artifacts very quickly.
So they adjusted the blue system for this.
Why the red-block thing slipped them by I don't know...it's quite obvious from some other sources that there are several issues involving MPEG compression schemes and the colour red, not just MPEG-4.
Maybe one of them was colorblind. :)


btw: Were the Qpel and cartoon mode explanations understandable?

[mikeX]

just read the whole qpel explanation, i found it amazing.
i haven't read through the entire qpel thread yet, but one wonders, is there really more to know? :)

about cartoon mode:

both designed to help with cartoons:
maybe " both designed to help with animations:"

i find it enlightening, even though there is some 'techie-talk' in it i don't think it's more advanced than in other parts of the faq where options are explained in detail. And even if one doesn't get it, there is still the 'conclusion' "So, while the first technique helps with removing movements that are so tiny that they can be considered not-to-be-part-of-the-source, the second helps compressibility of the cartoon by removing texture detail that's considered too-small-to-be-part-of-the-source." which should suffice for most people, right?

you could elaborate on why does this happen specifically with animations etc, but that doesn't have to do with xvid really...

ps: colour --> British, color --> American, none of the two will be considered wrong really... (although 'colour' should be considered proper imo (since that's the original), evil conspiracy of spellcheck (hmmmmm))

Maybe one of them was colorblind.
:D or it could be an evil conspiracy of MPEG against red (hmmmmm)

[atreya2011]

@crusty
Well The first part of the explanation on cartoon mode makes lot of sense. In the second, "vop_cartoon is about quantization", is it some sort "quant multiplier"?

As for the explanation on Qpel, most of the explanation was a wee.. bit complicated for my simple brain. Although I will read it 5 or 6 times to see if I can comprehend it because knowledge is power:D

[Soulhunter]

Originally posted by crusty
Really, this is too silly... do you have anything real to comment? :confused: Dont wanted to make you abused... :(

Just thought adding this stuff would make the problem a bit more understandable !!!


And for the chroma motion...

Really, Ive tested this !!!

You will not see reduced pixelisation, even at 4x zoom... :o


Bye

[crusty]

OK, no problem dude.. :D

Perhaps the chroma motion thingy won't work or perhaps it's source dependent. I'll give it another thought..

No updates today really...does anybody have any other additional questions that I could add?

[crusty]

Updates:

Added C17: Recommended newbie settings
(I used safe options only, If something isn't safe please tell me)

Updated D12: Removed the Chroma optimezer/motion bit.

Glossary:
Added YV12, RGB32, upsampling, VMR-7/9 and Video Renderer and FourCC.

Some minor fixes here and there, nothing fancy.


EDIT:
Update:
Also added:
"D0: I get all sorts of garbage during play!"
What happens when DivX decoder overrides XviD by the 'support generic mpeg-4' setting.

[Soulhunter]

C. Glossary

MPEG: Motion Picture Expert Group. A conglomerate of companies and institutions that sit around a table once in a while making up new standards. Creators of the MPEG-1 (VCD) layer-II and layer-III (mp3), MPEG-2 (DVD), MPEG-4 (SVCD, DivX, XviD, etc)) and other standards, they are a very important factor in the media industry.Dont like nitpicking, but...

- AFAIK SVCD is not MPEG4, its MPEG2 !!!

- MPEG-1 layer-xx, should be MPEG-1 audio-layer-xx !!!

- MPEG-1 audio-layer-II is mp2, and not mp3 !!!


Bye

[atreya2011]

Well, I didnt want to post the same post again, but I think my previous request was not looked upon. :(

Originally posted by mf
*VERY* simple explanation: the image is converted to detail signals (DCT), and then those signals are divided (coefficient cutting) to make it smaller. The more signal you cut off, the more detail you lose and more artifacts (blocks, ringing aka mosquitoes) you get. The quantizer is the detail removal factor (DivX3/Nandub thus calls quantizers DRF). The higher the quant, the more detail gets cut off, the lower quality.


Just a sugesstion.

Maybe you could add this in A4. MPEG-4 Basics section

Q. What's a quantizer?

[crusty]

'- AFAIK SVCD is not MPEG4, its MPEG2 !!!'
You're absolutely right and I was already aware of the error, I just hadn't changed it yet. Thanks for reminding me.

'- MPEG-1 layer-xx, should be MPEG-1 audio-layer-xx !!!'
I'll doublecheck and alter it.

'- MPEG-1 audio-layer-II is mp2, and not mp3 !!!'
It wasn't meant to say that layer II was mp3 also, I'll alter it.

@atreya2011:
I kinda forgot, sorry for that.
I'll see where I can slip it in.

Thanks for the comments,
Crusty

EDIT:
Ok, added those alterations to the FAQ.
Check it now.

[BoNz1]

-Turbo ;-): This setting skips some search techniques when using Qpel or B-frames during the first pass to speed it up a bit. Without those options on it has no effect at all. The impact on quality is negligible.

I am sorry I have not had the chance to read all the FAQ but I believe this is wrong, turbo doesn't give any speed up in the first pass I don't think unless if perhaps you have fast first pass turned off. I believe although correct me if I am wrong that it speeds up the second pass it makes no difference whatsoever if it is activated or not in the first pass IIRC.

[crusty]

OK, I will look into it.

EDIT:

Well I looked into 20 threads, including the RC1 and RC2 threads and couldn't find anymore else to say about Turbo, except that I should remove the bit about 'first pass'. ....Done.

[Selur]

All "turbo" optins are related to b-frames and qpel. It won't make Simple Profile faster.
It won't make any differnce in first pass either.
by syskin here (http://forum.doom9.org/showthread.php?s=&threadid=67495)

[nine]

Just a quick note on section A2...

"...but also a life video-feed..."

should read:

"...but also a live video-feed..." :)

[yaz]

@crusty
many thx for your continuous efforts on polishing it. i got some small quests (not having read the very last version)

C17 (noob sect.)
-Profile: Use AS@Level5, nothing else.why? afaik, the whole profile business has no effect at the moment. just as u mentioned earlier.
Don't mess with Interlaced encoding, greyscale, ... , GMC, Reduced Resolution ... These settings are simply not for newbies;it prompts (me) that there's sg risky about using that. These all are 1click options, so no further tweak's needed. why do u think them so risky? if sy reads your guide ... can be no problem with them.
... you need to understand them to use them properly! yeah, that's the point! but it's true for all the options. that's why we all read your faq :-))

thx
y

[atreya2011]

Updated PDF...

Crusty's Unofficial XviD FAQ updated as of 21-02-2004 (http://www.geocities.com/atreya2011/index.htm)


Have Fun... :D

One more thing, if you want to print it out in an A4 paper, its 40 pages long :) (8 pages + Last week's PDF), in the near future, it can be called as the Unofficial XviD Manual :D

[crusty]

Selur:
by syskin here
I read it already...didn't say anything extra really. I think current explanation is good.

@nine:
Thanks..altered.

@yaz:
why? afaik, the whole profile business has no effect at the moment. just as u mentioned earlier.
That's not entirely true. True, Xvid won't keep within maximum bitrates specifief for that particular profile abd level settings.
But that's only half the story.
The other half is, that altering this setting will alter the possible options, including really experimental ones or non-mpeg-4 compliant ones, like RRV and above-DVD resolutions.
So not sticking to AS@Level5 should be considered not safe for newbies. AS@L5 is what I consider safe for newbies.
:D
it prompts (me) that there's sg risky about using that. These all are 1click options, so no further tweak's needed. why do u think them so risky? if sy reads your guide ... can be no problem with them.
Offcourse, if people read the FAQ through they won't be newbies for long anymore...but we live in an imperfect world, so we have to assume the worst. About those options:

-Interlaced encoding:
Really not a newbie thingy, since the vast majority of source is either progressive or (possibly badly) telecined or originally non-interlaced content. Telling a newbie it's safe to use simply isn't true, as proper IVTC and deinterlacing, especially of poor interlaced conversions of originally progressive content, is a whole ballpark by itself.

-grayscale:
Might be used if the original was grayscale, but there's:
a) usually no need to use it with proper B/W content, as it doesn't really add much to compressibility AFAIK .
b) some B/W movies actually have a bit yellowish tint due to aging of the film, and some people might like to keep this tint.
(btw: I think I'll add this extra bit ofinfo to the FAQ)

-Debug settings:
Newbies have got nothing to do with these. Only the FourCC thing could be interesting to them, but even then they have to know the consequences really. Consider a newbie encoding with GMC and a fourCC of DX50...doesn't really sound good now does it? ;)

-Curve Compression & overflow treatment:
You need a very good mental image of the whole effect of these settings to alter them in a positive way.

-GMC:
Has many incompatibilities with non-xvid decoders, and a proper understanding of what one wants to do with it is required for use.

-RRV:
Highly experimental, not completely implemented yet, highly incompatible, no beneficial effect, not in the AS profile...need I go on? :D

-Aspect Ratio:
Difficult stuff even to me. Proper use requires:
-understanding of how the original source was supposed to look like, and on what media it was supposed to look like that (PAL, NTSC, PC, etc.)
-understanding of the different aspect ratio standards
-No errors made in the conversion proces
-Understanding of the type of media it's going to be played on (standalones and their support for aspect ratios, Xvid or ffdshow or DivX decoder, container format, etc. etc. etc.)

For all these reasons I think I'm quite safe and correct when I say in the FAQ: " you need to understand them to use them properly."
As that's really the truth.
For instance the proper handling of Aspect Ratio alone would require a separate document, probably as lenghty as this FAQ.

Not all options are created equal...C17 is there just to point newbies to the safest of them, and like I already stated in the FAQ, it's probably the most often asked question, so that alone warrants at least something of a usable answer in my point of view.

atreya2011:
Thanks for the conversion again. I mirrored it here:
http://www.vslcatena.nl/~ronald/docs/Xvid-FAQ-Crusty-21-02-2004.pdf

EDIT: I will make some more updates later today

[mikeX]

@yaz

I totally agree with crusty, the 'newbie settings' question is completely useless to someone who has already read and understood the FAQ, but it's not there for someone like that, it's for someone clueless and maybe uninterested in learning all those things it takes to understand certain options/settings. As such, i find it a useful and meaningful addition to the FAQ.

@crusty

B6:
All the speed-hungry parts of XviD are written in assembler.
shouldn't that be assembly??

edit: and maybe also 'cpu-hungry' instead of 'speed-hungry'??

[sysKin]

Hi,
I finally found some time to read the FAQ one more time :)

I have some suggestions. Unfortunately not all are very specific, but I'm not a good writer and I'm not trying to rewrite them fully...

Generally, I would like to say that some answers are quite messy and don't focus on answering a question. Instead, they're trying to feed reader with specific and (often) useless in formation that isn't really on topic.

A1 is a perfect example of this. Write that XviD is a multi-platform video encoding and decoding library. Don't introduce virtualdub here. You can write that there are both codecs (like vfw) and decoders (like Nic's directshow-based) which use it, or are based on it. I wouldn't mention Nic's decoder because it's quite old. I wouldn't mention windows media players, they are not xvid (read the question). You can write that XviD aims for medium-to-high bitrates and medium-to-high-resolutions, although works with the other end like mobile phones. You can write that development focuses on encoder.

A2 is even more messy. Don't mention disk drive as part of the stream, it just confuses everyone (would you mention it in notepad.exe FAQ?). Xvid is a library, not a program, so it's logical that some application takes video data (from avs if you want to), uses xvid to encode it and writes the result to a file. Why making it so long and complex? It will be pretty obvious later, when you write about setting up stuff.

A3 Ah I see you've already fixed the "second version of mpeg-4". Nice. I would rewrite the thing about h264 - xvid supports mpeg-4 part 2 and only 2 (which means not 10).

The thing about software and hardware implementations is off topic. Flashing firmware - even more.

A4. Hm... I could rewrite that I think. I'm not sure it belongs to "introduction" part, could be "advanced"... but ok, doesn't hurt.

A7 Who needs to know mpeg-4 to use xvid? Sorry, noone ;) You also assume that user is ripping DVDs in win32 here... XviD is so much more. I would change the question and the answer, too. The most popoular question definitely is about *de*coding.

A8/A10/A11 are sort of in random order and without explaination... first there are binaries (where?), then someone doesn't know how to compile (why, if there are binaries. where's the sourcecode anyway. why developers don't compile for me?).
A11 only works if you've read A10 to the end, so maybe it should be sticked to A10 or named "what are the risks of using bleeding edge binaries?" and combined with A12.

A12 you never mentioned about tested and untested binaries before. Where are the tests made exactly? How can I read about these tests?

A15 is A12.

A13 and A14 and A16 can never be recent in current form... Basically one can either use XviD 1.0 (very soon I hope). There should be many binaries available once it's out. Second, one can use most recent 1.1 build (again: soon) from Koepi, or anyone else who starts building them. He should go to Doom9 and read about known problems and features. Third, someonce can use automatic instabuilds from 1.1 tree and hope for the best. These are the three options.

Dev-api-3 are not recommended anymore. Old 0.9.2 is completely not recommended.

Generally I would make "getting xvid" a separate chapter - third after "introduction" and "playback of xvid files". BTW as for decoding, I'll add more answers about most common problems, solutions and tricks. And a summary of all known mpeg-4 decoders and how they perform.

B4 is A13 and A14 and A16 again.

[** I will edit the post with the rest - I have to go now and don't want to loose what I've written **]

[yaz]

@crusty (mikex)
ok, i got the point. nothing to disagree but ... why don't u cut it short by 'use defaults unless u don't know what, why & how to change'. imho, default setting of the last releases is quite robust & safe.

sg more. i agree with syskin. it seems that the most crucial quest at the moment is playback. if u take a look at the xvid forum(s) the most quests relate to that. in this meaning, the playback part (B1) is bit fishy. starting from there, nobody will ever be able to make good playback. syskin promised to make it clear (& imho he's the only one who can make it), but until u should recommend only the dsf shipped with koepi's rc2 pack.
don't link koepi's site here as there is a standalone playback filter too. afaik, that's not recommended anymore.
don't link ffdshow as its state is messy & the versions downloadable from sf.net are out-of-date & inappropriate for decoding devapi4 encodes. more up to date versions can be downloaded from athos and kurosu, but these are 'unofficial' (& afaik, milan asked them to stop releasing such versions) instead, the ffdshow development thread may be linked (if sy is interested in, at all)
syskin's dsfs work fine (for me!) but the link u dropped is dead (for me!) as it's mispelled (all in small letters, pls) anyway, the zip coming down is broken (for me!) would sy drop me a working pack, pls !

u don't distinguish enough the devapi3 & the devapi4 branches. it is another point where the most 'common users' get confused. afais, both versions are in heavy use at the moment (despite, devels don't recommend devapi3 anymore) the download part (B4) reflects this confusion. imho, there's nothing to do with nic's & umaniac's site at the moment as they don't seem to deal with devapi4 releases. (it's a pity but that's what we have:-()
anyway, to those who wants to use the devapi3 version i would recommend umaniac's last insta build. that's the latest & the most debugged & updated version (to the date of its release).
& here comes ffdshow again. it is the best for decoding devapi3 stuffs but it may fake completely with devapi4 versions. however, it is good for postprocessing(!) both.

about instability. i've tested (almost) every built of gamrdev & i didn't find 'broken' or instable any of them. rc & insta builts are not different in this meaning. all need testing & all can be 'broken' (whatever it means:-).

still love your faq, anyway :-) (despite it may seem different:-)

the bests
y

[virus]

Originally posted by sysKin

A3 Ah I see you've already fixed the "second version of mpeg-4". Nice. I would rewrite the thing about h264 - xvid supports mpeg-4 part 2 and only 2 (which means not 10).
sorry if I enter the discussion, but this is mainly because I suggested this change myself, so I think I have to state something about that... my suggestion, which crusty reported literally, was:
"XviD does not support H.264". It is written very clearly in the FAQ (and in this thread too), so I'm just wondering what you're talking about... ;)

cheers
virus

[sysKin]

Originally posted by virus
It is written very clearly in the FAQ (and in this thread too), so I'm just wondering what you're talking about... ;)Ok I might have gone too far... It's just that when I read it first time, I had the feeling "where did h264 come from?"... It's kinda like saying "note: very important: don't forget: it's not a hamster" :D
Imho all answers should be as clear as possible, if it's mpeg-4 part 2 than that's what it is, no need for extra warnings... There could be an extra question about h264 (in fact it is a frequently asked question) - just not in "introduction" chapter.

I might be too picky I admit, I would just like this FAQ to be as good as possible :) and first answers are quite messy in my opinion. It's much better later.

Radek

[mikeX]

@ yaz

i can decode rc2 encoded material with the latest official alpha build of ffdshow. (given no packed bitstream)
quality can be inferior but i can make use of a wide variety of postprocessing and filtering, whereas the xvid decoder maxes out my cpu (with resolutions >= 5..x4.. & Q-Pel) if i try any postprocessing.
without Q-Pel i can safely use Y deblocking and internal conversion to RGB32

[virus]

Originally posted by sysKin
Ok I might have gone too far... It's just that when I read it first time, I had the feeling "where did h264 come from?"... It's kinda like saying "note: very important: don't forget: it's not a hamster" :D

:)
ok no problem...
BTW when I suggested this change (along with the part/version thingy) I was tempted to write it as:
"XviD does not support H.264. Please do not ask for versions that do."
Don't you think it may be a useful addition? ;)

cheers :)
virus

[yaz]

@mikex
of course, u can decode rc2 with (any release of) ffdshow. i only stated that it's inappropriate. (just as u wrote:-)
i've just made an encode with qpel/qmc/2b-frames & i tried to playback by decoded with xvid rc2 dsf (no pp inside) & postprocd with kurosu's ffdshow (rgb conversion, full postproc, sharpen with asharp hq, noise on y&u). no jerk anywhere on my athlon 2.2+. anyway, i never use ffdshow this way, i just performed it for u :-)

the bests
y

[TorgoGuy]

Hi. I'm a long time lurker...

Crusty has done a great job with his FAQ, but I was wondering if anyone would be interested in a more concise version of his FAQ? I think it would be less confusing to many newbies if you left out many unnecessary details, but still left in enough to be informative.

In that spirit, I've created a rough draft of "Part A" to generate some discussion. If you like it, I'll rewrite what I've already done (to make it clearer) and then continue on to parts B through E.

Here is the link:
http://143.236.28.105/staff/ken/xvid/faq/

I've resisted the (strong) temptation to reorganize the FAQ. This allows the reader of the concise FAQ to consult the exact same question number in Crusty's FAQ to get the full details.


EDIT: Looking up at Syskin's post, it looks like we're thinking along the same lines. I didn't mean to be redundant.

[crusty]

Well that's a lot of discussion suddenly !!

@syskin:

That's a lot of comments...Generally, I would like to say that some answers are quite messy and don't focus on answering a question.
I agree that some of them may be a bit messy, I'm still in the process of writing it. :)

Write that XviD is a multi-platform video encoding and decoding library.
That's a good one...I will make some way to include/replace it.
A1 certainly requires rewriting, it's just that I've been busy with all sorts of things, and I'm currently really only reacting to comments than actively making changes.
I will see what I can do.The thing about software and hardware implementations is off topic. Flashing firmware - even more.
I think I could add another question about XviD on standalones that includes this info.

@A7:
Well, certainly, most newbies do tend to start with DVD-ripping, and most Linux users tend to have a higher level of computer-knowledge.
So if the FAQ weighs heavily towards win32 and DVD-stuff, it's not without reason.
The most popoular question definitely is about *de*coding.
I could split it up of course, making the first question 'What should I know to play (decode) XviD?' and the second one this one. That would first give an easy answer to those who just want to view XviD files, tending to that group, and then to those who want to use XviD to decode. It's not a bad idea I think.

For those who want to use XviD to encode stuff, I consider it important that they should know something about the underlying processes.
And the most important of those are MPEG-4 and avi A/V-processing, (because no matter what we advanced guys do, most people still use avis).
The DVD FAQ also includes many information relating or comparing DVD's to other formats, which are very helpful to many.
(btw, I'm gonna include a Laserdisc FAQ as well later on)

A8 to A16 are to be replaced with a standard 'use XviD 1.0 because it's the best and finest' -answer once that comes out, I've mentioned this before. Consider them obsolete and removed once XviD goes 1.0....that's a promise :D
B4 is A13 and A14 and A16 again.
Well like I said, A13, A14 and A16 will be removed soon anyway.
Also of course B4 will be completely rewritten once XviD goes 1.0.
As of know, I think it's only proper to give people more than one option...I like options.

@yaz:
why don't u cut it short by 'use defaults unless u don't know what, why & how to change'. imho, default setting of the last releases is quite robust & safe.
Well I will alter it to include that at front. But still then there's nothing wrong with both question and answer.
Don't forget, it's still the #1 question after people where told to 'stick with the defaults' so it remains a valid question.

B1: You're right, I will alter it to include only the RC2-pack.
Also if sysKin can tell me where to find his latest ones I will add those as well.(he told me before but I can't remember exactly)
And you're right, the link is dead. I'll alter it to just the directory, that still works.
@B4:
I will make it clear that only Koepi's sysKins and GameR's binaries are current.
rc & insta builts are not different in this meaning.
Not so, Koepi tests his builds before he releases them AFAIK. Insta-builds are completely untested and just represent the latest CVS (which can be broken by just a single typo).
Of course, Koepi's builds can break stuff just as well..just less obvious stuff. :)
It's kinda like saying "note: very important: don't forget: it's not a hamster"
Where!? WHERE?!
<Crusty running around with large club bashing Hamsters all over the place>
There could be an extra question about h264 (in fact it is a frequently asked question) - just not in "introduction" chapter.
You're right. Rereading it right now it does feel a bit unessential (but still noteworthy) information.
"XviD does not support H.264. Please do not ask for versions that do."
Hmm...sounds nice. :D
u can decode rc2 with (any release of) ffdshow. i only stated that it's inappropriate.
I think that's already properly answered in the FAQ with:

"Although FFDShow has more options, it is not based on the XviD project and may contain incompatibilities from time to time. It is advised to try both and see what works best for you."

@TorgoGuy:
Making a short version of the FAQ is a good idea.
Yours and mine represent two different philosophies on FAQ's;
One with short answers and one with very elaborate answers.
There's nothing wrong with either way, it's just a point of view.
Personally, I've seen way too many FAQ's (especially by ISP's, Manufacturers and software companies) that are so short and uninformative I'd like to shoot the morons that wrote it. :D

Basically, my opinion is that a FAQ can never be too elaborate; as with everything in life, one question answered almost invariably leads to another question asked.
It's just a matter of author's decision when the FAQ is so big that making it any bigger would impair proper updates.I didn't mean to be redundant.
Redundancy is good.
Better two FAQ's than none as far as I'm concerned.

EDIT:
Updates:
Altered : B1, B4 and some bits of C17..check it out.
Will make more updates later.

[Soulhunter]

MPEG: Motion Picture Expert Group. A conglomerate of companies and institutions that sit around a table once in a while making up new standards. Creators of the MPEG-1 (VCD), MPEG Audio Layer-II (mp2), MPEG Audio Layer-III (mp3), MPEG-2 (DVD), MPEG-4 (3ivX, DivX, XviD, etc)) and other standards, they are a very important factor in the media industry.
Re-add SVCD, but now to MPEG-2 !!!

Add AC3 to audio...

Add AAC to MPEG-4 audio part...
MPC: Short for Media Player Classic. It's a Media Player with an interface very similar to the Windows Media Player 6.4, which comes with Windows 98 and 2000. But it's much better and there are a gazillion differences under the hood. It's considered better than any media player Microsoft has. MUCH better
For just basic's good old MPlayer2...

For TV-Out users, ZoomPlayer is also nice...

Just mention to be fair !!!
B1. These filters do not decode audio! only video! XviD does not decode or deal with audio in anyway
Maybe mention Alex's AC3 filter here...


Bye

[Bogalvator]

Super dooper looking FAQ; lots of useful info in it - thanks for taking the time out to make it.

Typo spotted btw: C11.Zones - Chroma optimizer "you might want to turn it off when encoding in greyscale."

I did not know that XviD used YV12 all the time. I thought it just supported it (as well as YUY2 etc) and it just used whatever colour space that was passed to it via VirtualDub etc. With this in mind, is it optimal to pass a YV12 clip to the encoder?

[crusty]

@Soulhunter:

'Re-add SVCD, but now to MPEG-2 !!!'
OK, did it. Removing of SVCD was somewhere else btw.

'Add AC3 to audio...'
'Add AAC to MPEG-4 audio part...'
I'm planning to give those two separate entries to the glossary.
There's no need to put every A/V implementation in this entry, the entries are supposed to be examples, not a complete list of MPEG's achievements. :)

'For just basic's good old MPlayer2...'
I'll add it to a separate WMP entry.

'For TV-Out users, ZoomPlayer is also nice...
Just mention to be fair !!!'
True, Zoomplayer is also very nice, I use two players: MPC and Zoomplayer.
I found that Zoomplayer can handle video files with single bit errors in them without hanging the video, which MPC cannot (yet). OTOH MPC plays some files better than Zoomplayer, so they are complementary.

How does Zoomplayer help users with TV-out btw? I never used that feature.

'Maybe mention Alex's AC3 filter here...'
Well I have no clue who Alex is but I guess a mentioning/link of D5: "I want to playback this movie I d/l'ed but there is no sound!"
can't hurt...(in D5 I mention audio filters).

@Bogalvator:
Typo...got it. Thanx.

YV12 is the standard 4:2:0 colour space used for all MPEG-2 and MPEG-4 implementations (not so sure about MPEG-1 really). So whenever an MPEG-4 codec encodes something it does it in YV12, can't really be anything else. That doesn't mean it won't accept anything else as it's input, it's just that there will be less color conversions during the encoding process. This speeds up the process.

Additions to glossary:
3ivX, ABR, CBR, DivX, Ogg Vorbis, Ogm, and VBR...please check them for errors.

[sysKin]

Okay let me start the "decoding" section. I'm posting it here so that we can discuss it before it makes to FAQ ;) (or, maybe, you won't like it at all :D )

Q: I want to play xvid file. What should I install in windows?

A: XviD is an mpeg-4 compiliant encoder, so in theory you need any mpeg-4 decoder for playback. The following mpeg-4 decoders are available for windows:

- XviD's decoder. Althought seems like an obvious choice for XviD files, it's not necessarly your first choice. It supports all XviD's formats and decodes them well. However, it needs a fast CPU for playback - it takes more processing power than most other decoders. It has two postprocessing options [make it a link to postprocessing below] - deblocker and film noise. Some people say it's the best-looking deblocker of all - but it needs HUGE processing power to run. At your choice, you can make xvid's decoder also support divx4, divx5 and generic mp4v files.

- ffdshow. A free GPL-ed decoder for many video formats. Very versitile and useful. It supports all XviD files with one exception - playback might not be fluent with [link?]packed bitstream and more than one b-frame. It's very fast and thus recommended on older systems. It has numerous postprocessing options, can filter or resize the picture, display subtitles and more.
Note: in its configuration, you can change iDCT routine used. It's recommended that you set it to "XviD" for both XviD and DivX5 playback, it prevents [link to a Q below] "floating" artifacts. You can always use its configuration to enable or disable any format support.

- DivX5. Fast decoder with good postprocessing options. Note that you only need the "basic" version for decoding, so don't install spyware or spend money if you don't encode with it. When installed, it decodes XviD files by default and you can disable it from its configuration - look for "generic mpeg-4 formats". It doesn't support XviD's GMC or interlacing, and current version (5.1.1) sometimes doesn't decode b-frames correctly (with any content, not only xvid) [is it still true?]. It also has shuttering problems with more than one b-frame, although unchecking "smooth playback" seems to fix that. [I'll download this 5.1.1 and check compatibility, especially with qpel]

- 3vix decoder. [I'll make some tests with its speed, compared to the rest]. When installed, it decodes XviD files by default, but you can disable it in its configuration. It does not decode XviD's GMC [I'll test b-frames, interlacing, and everyhting else] It has standard postprocessing options. [Anything more?]

- NeroDigital decoder. [Where can I get it?] Decodes XviD when installed, and you can't disable it [am I right?]. It doesn't decode many xvid files correctly [bframes? gmc? qpel? intrlacing?... I'll do my best to test as much as I can][does it have postprocessing?][maybe it's at least fast?]

[are there any other mpeg-4 decoderson windoze?]


Q: Help, I have problems with sound!
A: XviD handles video only. It does not care or interfere with audio decoding. Most likely you need appropriate audio decoder, but you won't find help here.

Q: Help! playback is wrong/I see artifacts/green/ugly/shutters!
A: First of all, you have to find out which decoder is being used. As you can see [link to the first question]here, all mpeg-4 decoders hijack XviD files by default, and only ffdshow will ask you if you really want to do that. Most players will let you see and configure decoding filters by right clicking on video and selecting "filters" (like [link]mpc) or "filter properties" like [link]zoomplayer. WMP9 will let you see the filters used (in video's properties) but will not let you configure them.

If you're not using XviD, you might try switching to XviD first - go to the options of filter used and disable XviD support in that filter.

Q: Can I make XviD's decoder use less CPU?
A: Disable postprocessing first, of course. Another thing you can do is: Go to decoder's configuration and force output colourspace to "YV12". It's the fastest colourspace that can be used, but unfortunately it's not supported by some hardware well, so it's not used by default. It should lower cpu usage by about 5% - if that's not enough, you have no choice but using different decoder.

Q: I'm using XviD decoder and video is still wrong.
A: Unfortunately not all xvid alpha builds were stable. In particular, they never had proper interlacing support for GMC and b-frames. If someone used such settings, he created buggy streams. I don't think you can do something about it.
There was another bug in alpha builds - resolutions not divisable by 16 were also not supported correctly. Newest XviD decoder, as well as ffdshow, have an automatic workaround for this problem and should decode such buggy files corretly.

Q: I'm using XviD decoder and video is still wrong, part 2.
A: Try using different decoder. XviD's one might have some problems on some systems... Decoding was never in the focus of xvid's development.

Q: I see "floating" walls on my video.
Q: What's iDCT and what does it have to do with "floating walls"
Q: When I play video, picture gets worse and worse / colours slowly get wrong, and suddenly everything becomes good again and the process starts over.

A: [iDCT mismatch, let me think how to explain this...]

Q: What's a postprocessing? Deblocker? Deringer? Film effect?
A: [I ran out keys on my keyboard... can someone fill this? LOL]

Q: What's "B-frame decoder lag" message?
A: [still out keys on my keyboard, I'll add answer later]

[more questions? ask them now and they shall be added LOL]

Phew,
Radek

[Stux]

-Current 3ivX implementation normally uses no sub-pixel precision. As an 'advanced' option, you can tell it to use half-pixel resolution. So much for 3ivX being 'advanced'...


Hey! I object to this.

BY DEFAULT 3ivx uses Half Pixel precision, as an advanced option a user can *choose* to disable Half Pixel precision. A user might want to do this because he would rather encode faster (for instance live capturing).

[omion]

I've been lurking around here for the past year, and now there's finally something I can write about!

I section A4, you say:
The result is that, while a Luminance value is stored for every pixel, Chroma is only stored for every two pixels.
Sould be:
The result is that, while a Luminance value is stored for every pixel, Chroma is only stored for every four pixels.

<edit:>
Also, there are references in sections B2, B3, and E3 of a 'Cpu', and sections B2, B3, and E4 of 'cpu'. Should all be capitalized to 'CPU'.

Keep up the awesome work!

[sysKin]

Originally posted by omion
Sould be:
The result is that, while a Luminance value is stored for every pixel, Chroma is only stored for every four pixels.Indeed, it's every two pixels horizontally and every two pixels vertically, so it's total of one chroma pixel for every four luma pixels.

@omion: now *that* is a good first post :) welcome to the forum :)

Radek

[Wilbert]

some useless comments (I still have to read your faq :)

You're right. Rereading it right now it does feel a bit unessential (but still noteworthy) information.
You can put stuff like this in the appendix.

The result is that, while a Luminance value is stored for every pixel, Chroma is only stored for every two pixels.
Like others noted, this is for YUY2/YUYV.

[crusty]

Lots of comments...good!

@sysKin:
@Q: I want to play xvid file. What should I install in windows?

Sounds like a very good addition.

Also, all the other parts sound good as well.

In fact i'm thinking about altering the FAQ like this:

A: Introduction
B: Decoding (playing) XviD questions (including many of the troubleshooting items out of current section D)
(also, a question on standalones would fit in here)
C: How to encode (parts from original B section + additions about avisynth, Vdub etc.
D: Options, Schmoptions (relatively unaltered)
E: Feedback and questions (this part is very much done I think)
Appendix

@Stux:
Sorry, I was not aware of that.
On 3ivX website it says:
Half Pixel Motion
If checked the codec will perform half pixel precision motion search. Half Pixel motion dramatically increases quality and codec efficiency in almost all cases. Disabling Half Pixel Motion can speed up an encode.

Which made me believe Half Pixel is not the default. Still, an option allowing to use full-pixel resolution does seem a bit outdated now..
Anyway, I altered it.

@omion:
Ah, I knew that...just not at that moment. :D
Will update. I think I meant to say that there are two chroma values for every four pixels, which equates to one for every two pixels.
Of course those two values are not identical, so it's not really correct.
I altered it to:
"The result is that, while a Luminance value is stored for every pixel, two (different) Chroma values are stored for every four pixels."

I'll do a 'replace all' on CPU.

@Wilbert:
Yeah I know, I've been searching (and finding) some nice color space informational websites. I'll add them later to the FAQ.

sysKin:
[more questions? ask them now and they shall be added LOL]
I somehow expected you to say:
'ask them now or be forever silent!'
:D :D :D

EDIT:
Updated:
A7 and B1 to give more support to people who just want to play XviD files.

[Wilbert]

"The result is that, while a Luminance value is stored for every pixel, two (different) Chroma values are stored for every four pixels."
I guess you are trying to confuse people here :)

four pixels: four Y values (one for every pixel), one V value and one U value.

Chroma is the UV plane. Thus one chroma value is one UV value (= one value for U and one for V).

I guess that's what you are trying to say ...

http://www.avisynth.org/index.php?page=PlanarImageFormat

[Soulhunter]

Originally posted by crusty
How does Zoomplayer help users with TV-out btw? I never used that feature. Because you can easy adjust (pixelwise) the screen-size to match exactly the overscan-arear of your TV... :)
Originally posted by crusty
Well I have no clue who Alex is...
Well... (http://ac3filter.sourceforge.net/) ;)


Bye

[omion]

Originally posted by crusty
@omion:
Ah, I knew that...just not at that moment. :D
Will update. I think I meant to say that there are two chroma values for every four pixels, which equates to one for every two pixels.
Of course those two values are not identical, so it's not really correct.
I altered it to:
"The result is that, while a Luminance value is stored for every pixel, two (different) Chroma values are stored for every four pixels."

Eh? In YV12 space, one chroma (U+V) is stored per 2x2 block luma block (4 pixels). I think you're still thinking of YUY2. Take a gander at YV12 (http://fourcc.org/yuv.php#YV12) vs. YUY2 (http://fourcc.org/yuv.php#YUY2) from fourcc.org.

[Stux]

Still, an option allowing to use full-pixel resolution does seem a bit outdated now..

The feature was added by request ;)

The only reason I can think of for disabling hpel is when encode speed is more important than compression efficiency

[crusty]

@Wilbert:
'four pixels: four Y values (one for every pixel), one V value and one U value.
Chroma is the UV plane. Thus one chroma value is one UV value (= one value for U and one for V).
I guess that's what you are trying to say ...'

Indeed, that's what I'm trying to say....if you take a look at YV12 in the glossary, you can see I understand how it's stored.
One chroma value is stored for every four pixels, but this chroma value consists of two individual and different one-byte values.
I'll find a way to rewrite it better.


@Soulhunter:
Ah, that's interesting...I never noticed Ac3filter was made by a single author btw.

@omion:
See my answer to Wilbert

@Stux:
Ok.

[Soulhunter]

Originally posted by crusty
@Soulhunter:
Ah, that's interesting...I never noticed Ac3filter was made by a single author btw.I only regive what the "About" window tells me... ;)
AC3Filter v0.70b - Copyright (C) by Vigovsky Alexander, All Rights Reserved

Bye

[omion]

@crusty:

Ah. I got it. Sorry for the misunderstanding.

[fl0]

@ crusty

thanx a lot 4 this great FAQ...

it's great for a newbie trying to get experience like me :)

may i suggest you using some graphs and/or pictures especially the screenshot of encoder settings. by that way i'd feel more secure to know each and every option.

for example from the main encoder window to each sub window, you may explain all items orderly ?

anyway, thanx again :)

[poochie2]

Thinking about the RC3, could you call it "Ave" (Latin) or "Ambanine" (which is what goes nearest possble to "ciao" in Shangane, something similar to swaili)

:sly:

[poochie2]

Pardon, wrong topic :)

[crusty]

@fl0:

I will use pictures in future versions.

[Selur]

about pictures,..
Are there any news, if the current GUI will be the GUI for Xvid. 1.0 ?
:D

Cu Selur

[atreya2011]

Here we go again. Another Update

Crusty's Unofficial XviD FAQ updated as of 25-02-2004 (http://www.geocities.com/atreya2011/index.htm)

[crusty]

Thanks, atreya2011.

UPDATES:
YV12 info in A4, check it out now...
XviD Release Candidate 3 is now recommended version.
Minor updates here and there.

(BTW:I have no information on any GUI changes, but I think it's safe to assume there will be no major changes.)

What language is Shangane?

I will attach screenshots to the FAQ soon with settings at default. (just have to figure out how).

[Selur]

I have no information on any GUI changes, but I think it's safe to assume there will be no major changes.
Would be nice if e.g. syskin or another dev could give a comment about this. :)

Cu Selur

[atreya2011]

Originally posted by crusty
What language is Shangane?


It is one of the languages spoken in the southern part of Africa (similar to swahili)

Sorry, I know this is completely off-topic.:D

[mikeX]

hey there,
just a small remark (i've been both too busy and too lazy to reread all the changed parts...)

C.Glossary
VBR:
but the resolution of XviD is not in seconds but in frames per second.

apart from that, i still don't really get what you mean, plus it's still kinda hard to distinguish it from ABR

[crusty]

Well I knew it's kinda hard to explain properly... I can just say 'per second', but that would not be completely true...but I guess that's easier to understand.

I'll find a new way of describing it.

[fl0]

I will attach screenshots to the FAQ soon with settings at default. (just have to figure out how).

@ crusty

DivX guys has prepared a great guide which i found out recently.

This guide mentions lot of things besides DivX specific topics and features lots of pics & graphics.

if you haven't done before, i think it'd be helpful to you take a look at the guide to get how to attach screenshots & graphics.

also some explanations like Qpel, GMC are very clean and easy to understand: might give you a hint about future releases :)

Here is the link:

!http://www.divx.com/support/guides/guide.php?gid=0

it's a PDF file which is 6170kb in size

[mellon]

the FAQ says in C9: (Two-pass second pass 'more' settings explained)


-'I-frame closer than ... frames' sets the minimum number of non-keyframes that have to exist between two consecutive Keyframes.
...
Set this to 1 to disable forced I-frame spacing


I think this is wrong. I tried with RC3 and set that value to 4 but I got GOPs like IIIP... Furthermore the tooltip in the dialog window says the true meaning of this option.

Btw. I did not find the dialog to enable forced I-Frame spacing in RC3. So I think there is none.

Regards
mellon

[crusty]

fl0:
Looking in to it....

mellon:
You're right, the new popup explains it proper. I had a hard time finding info about before. I will update the FAQ.

Indeed, there is no option to force I-frame spacing anymore. I don't consider that a bad thing though, as when I it used the video turned weird anyway.

[crusty]

Updated the FAQ, it now includes pictures.

Also updated the 'I-frame closer than ... frames' explanation

[atreya2011]

Just another update

Crusty's Unofficial XviD FAQ(Now Illustrated!!!) (http://www.geocities.com/atreya2011/index.htm)

[crusty]

Added webcounter, don't know if it'll work...experimental.
Updated pdf version.

[Zom-B]

Hey Crusty...
I had to wait 5 days until I could thank you for your great Xvid FAQ!!!
Its the best way to introduce n00bs like me into the DVD backup World with this nice codec... :)

I hope your Faq will get official, and replace the old one on this Forum...

thanks...


edit: just a small hint, the link for Iago's two pass walkthrough at C16 changed, but is still at same homepage... ;)

[mikeX]

hi there,
been a while since i checked out the FAQ

i don't have any corrections etc, just a small suggestion:
would you care for changing your screenshots to another format, say PNG?
they are (quite) smaller in size and have much better quality :)

in case you find the idea appealing i have the screenshots ready here (users.ntua.gr/el01707/xvid/xvid-screenshots.zip)

i have also added a few shots of the decoder and the status window in case you find a use for them...
(if you like i can even make them again with the default colour/font sceme)
------------
Maybe you could also include a part about the 'moving/floating walls' side effect somewhere

keep it up ;)

status of png in web-browsers (http://www.libpng.org/pub/png/pngstatus.html)

[omion]

I'd have to agree with mikeX on the PNG thing. JPEG is not good for compressing screen shots, due to the high-frequency information in the text. PNG and GIF, however, are excellent at text. GIF is still patented outside the US, and tends to be larger than 8-bit PNG, so I'd go with PNG.

I tweaked mikeX's PNGs to be palleted 8-bit, which shaves off ~25% of the full-color file size, and is lossless except for the titlebar gradient (hardly enough to worry about). This makes the total size of the images ~50k, as opposed to the ~200k JPEGs, and they look better to boot ;).

Uploaded zip here (http://people.ucsc.edu/~rswilson/other/xvid-screenshots-8bpp.zip).
(site may be spotty for the next week, I think the university is upgrading something)

[crusty]

Thanks, the PNG's look good. I was looking for a way to reduce the size of the pictures. it will take me a while to update though, my internet connection is down for the moment.
I downloaded both versions and I'll see later which ones to use. Thanks for the work.

I will also take a look at Iago's link.

Cheers,
Crusty

[shevegen]

Perfect man, exactly what I needed to learn more. :)
I'll try to help cross-checking infos every now and then, especially about Linux & Xvid

You might also want to add sth like
Laste Update: <script language="JavaScript"> document.write(document.lastModified); </script>

to not need manually update last changes.

[guada]

Very good work ( structure, understanding ):) :)

[lordadmira]

Originally posted by Koepi
P.S.: hey crusty, does "schmoptions" imply anything in dutch? Because I don't get the joke :-/ Maybe i'm too much technical orientated though. Heh, yeah. It's an English slang prefix, schm- added to the front of any word, it implies light hearted derision, "it's no big deal". :devil: U replace the first consonant cluster of the first syllable with schm-. Safety, schmafety. Meaning, screw safety we're going to do it however we want. ;)

LA

[Dams]

@crusty : very good document, I found it and it is exactly what I want! :cool:

[niamh]

Crusty, great job, first ;)

I was just scrolling along tonight and noticed that the gknot bit at the end of C isn't quite up to date...GK now supports all sorts of settings and the latest build ...Easy to oversee stuff in that russian novel I know :D

[synaptical]

dead link.

[Teegedeck]

The up-to-date link is in the forum's topmost sticky post/official XviD FAQ.

Here you have it: http://ronald.vslcatena.nl/docs/xvidfaq.html

[Koepi]

I think i should mirror that FAQ on my site - would be a good starting point, right?

Crusty, if you're reading this, do you allow that?

Regards
Koepi