XviD-14112002-1...

[mikeson]

@Koepi & developers or experienced users of XviD:

I humbly ask you, a developer of XviD and man who knows much more about video coding than I do, for advice. Is it true that P and B frames are "derived" (I know, very desultory explanation) from I frame, isn't it? So would it be wise to set on 2nd pass I frames (just I frames, not P frames) quantizers to 2/2. I think it would improve encoding quality a little bit, wouldn't it?

I'm asking becasue I was very successfull while using this method of encoding with DivX4 and DivX5 with divx4log. It definitelly improves image quality in some cases.
http://forum.doom9.org/showthread.php?s=&threadid=27780

Thank you for answering

[fraatz]

@mikeson
you can do that with xvid...
just cap i frame quants to 2/2 but you really risk to get a much oversized avi.

[iago]

AFAIK, only one or two frames are influenced by the quality of the preceding keyframe, not the whole secene or in other words not the whole series of frames until the next keyframe. Therefore quantizing keyframes higher than 2 even has a positive impact on the overall quality of the encode. A range of 2-6 is very reasonable imho.

-h ?

regards,
iago

[NuclearFusi0n]

holy crap my movie encoded at roughly 769 kb/sec is absolutely STUNNING for such a low bitrate (Run Lola Run is the movie, encoded at 640 x 352)

Thanks Koepi!

here are the settings i used:
Settings for XviD ()
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 451114KB
I-frame Boost: 0%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 20%
Curve Compression: Payback with Bias, Bitrate Payback Delay: 250frames
High Bitrate Scenes: 0%, Low Bitrate Scenes: 0%
Hinted Motion Estimation: OFF
Alternative Curve System: OFF,
Motion Search Precision: 6 - Ultra
Quantization Type: MPEG-Custom <----hvs-good-picture.txt
FourCC Used: XVID
Max I-frame Interval: 300, Min I-frame Interval: 1
Lumimasking: ON
Interlacing: OFF
Greyscale: OFF
Quarterpel: ON
Global Motion Compensation: OFF
Chroma Motion: ON
Max B-frames: 4
B-frames Quantizer Ratio: 150%
B-frames Quantizer Offset: 100
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON
Print debug info on each frame: OFF
Min I-frame Quantizer: 2, Max I-frame Quantizer: 31
Min P-frame Quantizer: 2, Max P-frame Quantizer: 31
Max Bitrate: 10000kbps, Max Overflow Improvement: %, Max Overflow Degradation: %
Start Credits: OFF, End Credits: OFF,

[mikeson]

@iago:

AFAIK, only one or two frames are influenced by the quality of the preceding keyframe, not the whole secene or in other words not the whole series of frames until the next keyframe.

So please can you explain me this?

Situation where there is no B-frames used:

I1 P1 P2 P3 P4 I2

Ok, P1 and probably P2 is influenced by I1, but by what are P3 and P4 influenced? If by I1 - so it would be wise to have I1 Q2 and if by P1 or P2 - it would be wise to have I1 Q2 also, because P1 and P2 are influenced by I1. Or maybe it is completely different and I'm all wrong. :confused:

[AndyP]

As far as I know P1-4 will all reference I1 for blocks that haven't changed while blocks that have changed will be written to the bitstream. When I did tests with I set to min=max=2 and P set to something line min=2 max=8 and then again with I set to min=2 max=4 and P still min=2 max=8, the latter gave a better quant distribution overall. I think the problem would be that if you cap I quants at 2 then the P quants will be higher as a result so it really depends on what is better I=2 and P=high or I=3/4 and P=lower.......... the answer is probably it depends on the movie/scene etc... :D I personally use I=2-4 and P=2-8 and it seems fine to me.

Kind Regards,
Andy

[mikeson]

@AndyP:

I think the problem would be that if you cap I quants at 2 then the P quants will be higher as a result

Yes, you're right but P quants (although with higher quants) are from better looking I frames with 2 quant. So if I have I quant at 4, that has macroblocks, P frame could be anything, but macroblocks still remain.

On the other side when I have I frame at quant 2, then P frame (although with higher quant) has good posibility to achieve better quality (than P frame from previous example), because they are from better I frame.

But this is all my thoughts and speculations, maybe we should have explanation (or correction) from somebody more competent.

-h, Koepi or sysKin?

[-h]

It all depends on what you want to see - sharp but smeared P-frames (which you'll most likely get with the I-frame's quant set to 2) or similar quality for all frames in the sequence (leaving quant choice up to rate control).

There's no set rule, and only a scheme like RDO could make the choice something close to optimal.

-h

[mikeson]

@-h

Thank you for answering.

So what quantizer settings do you recomment as XviD developer?
I'm a little bit confused now. Leave it at default 2-31, or 2-6 for I frames and 2-16 for P frames as iago suggest? I'm not sure, really.

[-h]

So what quantizer settings do you recomment as XviD developer?

I don't know, I never really encode anything apart from testing for bugs :)

-h

[mikeson]

@-h

I see. ;)

[HarryM]

I tested last Koepi's build (03122002).
a) B-frames ON- 2 frames, ChromaME ON, qpel ON, lumimask OFF = 22 221 KB (at quant=2)
b) B-frames ON- 2 frames, ChromaME ON, qpel ON, lumimask ON = 22 803 KB (at quant=2)

Source is a little 2 min video grabed from TV and resized with avisynth and filtered with Convolution3D.

Is theorethically able, that lumi-masking dont help for better compressibility? Vid a) versus b)...

[Didée]

I was running some tests on a short "snip-through-a-movie" with this build, and found the following:

build 03122002
quant3/mpeg: 7412 kB
quant3/h263: 8500 kB
quant4/mpeg: 5494 kB
quant4/h263: 5922 kB

build 25112002
quant4/mpeg: 6404 kB
quant4/h263: 6162 kB
Hello, what's going on here?
Settings were: Bframes 4-125-175, Qpel ON, ChroMo ON, fixed quants (as shown).
My first thought was "hey, this build has mpeg+h263 swapped somehow", but looking at the image characteristics clearly showed that that is not the case.
Could anyone please test this also, to confirm this misbehaviour? Something must be wrong there (at q2 h263 might be bigger in some cases, but not at q3, and for sure not at q4 !)

I would have done more tests on this, but I was hunting another issue:

I still have "nervous blocks" or "block flickering" in my encodings with Bframes. The more still the scene is, the more annoying is the effect. It seems to be in the very basics of Bframe implementation: Effect is still clearly visible with e.g. Bframe 2-100-200 at fixed quant3. I even did a comparison to divx5. Not that I liked its result more - but at least, there was no block flickering.

Hands down, friends:
Are really all of you satisfied with the actual quality of Bframes?
Look close, please!

Or - maybe I simply had a bad evening yesterday ..

[ookzDVD]

Hands down, friends:
Are really all of you satisfied with the actual quality of Bframes?
Look close, please!

I'm satisfied, the quality is "ok" for me even I never look close
since I never see the video that close ;)

[sam_b]

@Didée
I have found this as well. At quality 81ish (quant 4-5 I think) H263 gets bigger files than MPEG at low resolutions. MPEG required quality 84 for me at this setting with my clip. When I put my test sample up to >640x288 this reversed. Just assumed that this was normal behaviour, but I didn't compare with a previous build. Both settings 'look' normal to my eyes at least.

I still have "nervous blocks" or "block flickering" in my encodings with Bframes. The more still the scene is, the more annoying is the effect. It seems to be in the very basics of Bframe implementation: Effect is still clearly visible with e.g. Bframe 2-100-200 at fixed quant3. I even did a comparison to divx5. Not that I liked its result more - but at least, there was no block flickering.

I have noticed this many times, but mainly from DivX5. Xvid only seemed to suffer from it at low resolutions with sharp images, and this is pretty much fixed by Qpel for me. Bframes have always improved picture quality for me for low-medium high bitrates and near-DVD resolutions. I normally encode at around 688x304.

To test if it was a B-frame implementation issue, would you not have to test something like 4-100-0? To test basic B-frame implementation I would test at quant 3 also, not quant 5. I may have misunderstood you here though.

[HarryM]

I have the same experiences.
For many videos is 'mpeg' quant set-up potentially more compressible than 'h263' (but not more nice-look - IMHO).
I observe this from time to time, without important, when I using the newest build or any weeks old.

This is normal.

But why is video with lumimask=ON bigger than with lumimask=OFF?

[sysKin]

Originally posted by Didée
I still have "nervous blocks" or "block flickering" in my encodings with Bframes. The more still the scene is, the more annoying is the effect. It seems to be in the very basics of Bframe implementation: Effect is still clearly visible with e.g. Bframe 2-100-200 at fixed quant3. I even did a comparison to divx5. Not that I liked its result more - but at least, there was no block flickering.I saw them. You know what they are? Ffdshow's postprocessing. Do not ask my why or how, but if you have xvid video with qpel and bframes, you cannot use ffdshow's 'mplayer' postprocessing (in particualr: deringing if I remember correctly). You can use nic's postprocessing and it's fine. Or none at all.

This is a really strange ffdshow bug :)

Radek

[HarryM]

Originally posted by sysKin
I saw them. You know what they are? Ffdshow's postprocessing. Do not ask my why or how, but if you have xvid video with qpel and bframes, you cannot use ffdshow's 'mplayer' postprocessing (in particualr: deringing if I remember correctly). You can use nic's postprocessing and it's fine. Or none at all.

This is a really strange ffdshow bug :)

Radek

I observe this 'macroblock flickering' from time to time at xvid's decoder too.
E.g. at scenes with minimum movement (and very contrasty content) is this 'defect' very good perceptiable. But nothing fateful.

I dont use ffdshow decoder, this decoder is'nt (in quality) exactly same as xvid decoder.

[Didée]

Syskin:

Important point! But, alas, not the solution.

Indeed, ffdshow's mplayer PP makes the problem even worse and clearly visible. But the effect in itself is there even with Nic's PP, and also when not using ffdshow at all.
Generally, I target my encodes that way that they are to watch w/o any PP, and that's what I usually do: use it not.

Thinking a little more about it, I suspect that I encountered this problem since Qpel and Bframes are usable together (but even if qpel is not used). By the time Qpel was not active when Bframes were used, those flickering blocks were not there - if I remember right. I have to check again with an older build.
But I think IF there should be some flaw in the core, that is the direction to search.

BTW, I'm not complaining here. All you XviD devels are doing SO GREAT work, really.
But imagine, Doom9 is doing the next codec comparison, and XviD gets (again) disqualified, because of the flickering ... aaarrgh!!

-------------------------------
P.S. I had a little attachement on page 6 of this thread, just in case someone'd like to check over ..

[colasonic]

Reporting two problems:

1, Qpel's smearing problem still exists in this 0312 Build. I just encode a short black and white DVD clip. Smearing lines appear in a large white background after a slowly moving object. Unchecked the qpel option and all came to normal.

2, StatsReader 2.0: after saving a new stats file, I cannot exit normally. It crashes every time after I click the "Exit" button. Then the computer says " StatsReader meets a problem and needs to be closed..." something like that.

I use English Windows XP plus Chinese language pack.

[ErMaC]

I'm getting those same crashes with StatsReader as well. Program never terminates normally.

[fraatz]

@syskin/koepi: i did a small test with 3b's 150/100 and i can confirm what didee says. this is not a decoding problem, i used xvid.ax and vdub shows this, too.
the flickering effect is clearly visible at static closeups and low bitrates and it doesn't matter if qpel or hpel is used. it would be really nice if you could take a look at this, if you like i can attach a little clip of 10 sec ...
anyway, the latest improvements on xvid are absolutely amazing and with c3d and hvs good picture matrix we can put a quite sharp 2.5 h movie on 1 cd..
thanks a lot

[blivit]

Originally posted by sysKin
I saw them. You know what they are? Ffdshow's postprocessing. Do not ask my why or how, but if you have xvid video with qpel and bframes, you cannot use ffdshow's 'mplayer' postprocessing (in particualr: deringing if I remember correctly). You can use nic's postprocessing and it's fine. Or none at all.

This is a really strange ffdshow bug :)

Radek

It's not a bug. It's a "feature" of the deblocking (not deringing) postprocessing of the mplayer routines. MarkFD's mpeg2dec suffers the exact same jittery artifacts with deblocking turned on. Therefore I no longer use any of the deblocking/deringing features of mpeg2dec.... I tried both on an uncompressed For the Birds from Monsters Inc, and the ending credits show the jittery artifacts quite strongly. Nic's method, as you said, doesn't have this problem. Is there any filter that can be used in avisynth or virtualdub to apply Nic's deblocking method to video before sending it on to be compressed? mpeg2dec just is NOT an option with the kinds of jittery artifacts that it produces.

-Eric

[cjv]

Originally posted by blivit
Is there any filter that can be used in avisynth or virtualdub to apply Nic's deblocking method to video before sending it on to be compressed? mpeg2dec just is NOT an option with the kinds of jittery artifacts that it produces.
I believe Marc FD's modified mpeg2dec already uses Nic's deblocking routines. :)
Originally posted by Marc FD
I've just made a Mod for MPEG2DEC : this version uses PostProcessing.
(big thx for Nic because the PostProcessing is from his XviD Dshow filter)

http://forum.doom9.org/showthread.php?s=&threadid=33600&highlight=mpeg2dec

cjv

[ErMaC]

I think it's perfectly possible to compensate for the blocks created by MPEG2DEC3 by using FluxSmooth and Conv3d. I noticed the problem as well but by using spatiotemporal filters you can alleviate this problem and gain both the deblocking from the MPEG2DEC along with good temporal smoothing as well.

[kilg0r3]

@ermac

which value ranges do you use for fluxsmooth and c3d, and, do you use them together?

[serbersan]

Originally posted by blivit
It's not a bug. It's a "feature" of the deblocking (not deringing) postprocessing of the mplayer routines. MarkFD's mpeg2dec suffers the exact same jittery artifacts with deblocking turned on. Therefore I no longer use any of the deblocking/deringing features of mpeg2dec.... I tried both on an uncompressed For the Birds from Monsters Inc, and the ending credits show the jittery artifacts quite strongly. Nic's method, as you said, doesn't have this problem. Is there any filter that can be used in avisynth or virtualdub to apply Nic's deblocking method to video before sending it on to be compressed? mpeg2dec just is NOT an option with the kinds of jittery artifacts that it produces.

-Eric


Well I don't agree. I use mpeg2dec3 without any postprocessing. I use Xvid 03 from koepi, not ffdshow. And the "nervous blocks" are there. And the efects is visible and without watching close to the monitor.

I've noticed that the effect isn't as noticeable for me as previous versions but is there and noticeable.

Continue such a great effort, the quality is outstanding¡¡¡

[Prettz]

@koepi:

What exactly are the advantages to using "Payback with Bias" over "Payback Proportionally"??? When using nandub, Payback Proportionally has always worked best for me. And just based on the descriptions of those two methods, it would sound like Payback Proportionally would be better.
I've noticed that you and the doom9 xvid guide both always have said to use Payback with Bias. So for the record, what exactly is better about it?

[iago]

@Koepi

I just wanted to share with you that I'm very glad about the results I achieved with my first 1CD/AC3Audio encode ;) "Henry and June" (~130 min.), using b-frames 4/100/200, Quartelpel, hvs-good-picture matrix, together with Convolution3D and UnDot, and a relatively lower resolution of 512*288 with neutral bicubic resize.

Decoded with ffdshow 10/10, "Use XviD" unchecked, "IDCT: simple(16383)" -> no problems with playback, neither smearing, etc.

"FourCC: DX50" and "DX50 B-VOP Compatibility" -> no A/V synch. problems.

best regards,
iago

[miha]

There seams to be quite a lot of changes in cvs dev3-tree does anybody know what are they? (fixes or something else)

[wing1]

@koepi

OK, after many days of codecs comparision for speed/quality/file size differences on the same avisynth script, and this is what i've observed.

umaniac's 29112002 = 18fps(no lumi) & 16fps(lumi) w/ow (B-F/chr m)
koepi's 03122002-1 = 16fps(no lumi) & 12fps(lumi) w/ow (B-F/chr m)

Uncheck chr motion option gives both dll's an additional 2-4fps; However, this will result with a slightly blurry video ( I like sharp video :D ). Hence, this option is always on for me from now on.

Lumi masking option for both dll's creates bad B & P frames intermittently. However, the video sharpness does increase with this option on. Koepi's dll produces more pleasant sharp video but more problematic B and P frames (random macroblocks), while Umaniac's dll produces less problematic B and P frames but at the cost of the sharpness. Both dll's drop encoding speed down by 2-4fps.

As for file size, Koepi's dll produces the smaller of the two at 1-2Mb per minute (depending on the scene intensity). This is true whether lumi mask, chroma motion, and B-frame options are being utilized or not.

Currently I am using Koepi's 03122002-1 xvid.dll with 3/150/100 along with chroma motion option.

[Didée]

I'm not the one who has the deep technical insight, but just a thought, anyway:

Were you using Qpel in your encodings? You didn't say wether it was in use or not ..

Koepi's build 03122002 has a new feature, dynamic Qpel decision: during encoding, the codec enables Qpel dynamically, depending on if the scene may benefit or suffer from using Qpel (search distance is cut to half with Qpel, so it is contraproductive on mid- or hi-motion scenes).
Of course this feature takes additional time to compute - therefore the 0312 is supposed to drop some speed when Qpel is used.
As far as I know, Nic's build 29112002 is without this dynamic decision.

Unless I did get something wrong - if so, just kick me in the a** :)

[iago]

@Didée

Believe me I have no evil intentions such as kicking a** ;), but afaik there is no "Nic's 29112002 build" ;).

I guess the binary you were referring to was "uManiac's 29112002 build".

regards,
iago

[wing1]

heh :D :D @iago you have a good sense of humor.

@didee

If you are refering to my previous post, then no I do not use Qpel. Qpel will drop encoding speed a few more fps if enable and the quality will also suffer imho. If I am going to use Qpel, then I'd use it without B-frame. So far I am not seeing a good result when missing these two options together.

Personally, 1-2 fps differences is not a big deal to me. The quality is what is more important.

[Shayne]

well with all these builds around we have no lack of testing. From my test and im not going to talk quants since that is not what i watch. I watch 2 full encodings 625 megs side by side with ms player64 and pick the better picture which has my preferences at heart sharp and no blocks.

To date, latest builds and past, i have found a good avs filter chain and only QPel is giving me the best results. No bframes no nothing except linear curve thats it?

Rui mentioned this i think but had to prove it to myself i guess

[Didée]

>> Nic's 2911... <<
:stupid:
grrrrrr! Of course I meant Umaniac's ..

Where is the "slapping myself" icon?

[Koepi]

Yes, sorry pals, you are right: I used different compiler optimization switches with ICL7, resulting in a slightly slower binary (so the "tutorial" of intel somewhat sucks ;) ).

I'm back to my old switches and speed is better again - I should release a new binary soon, when my CVS tree detects that there are files to update (it doesn't yet, even a fresh checkout delivers old files :( ).

Best regards
Koepi

[serbersan]

I've used lastest koepi build 03 and Qpel(only)... the quality is amazing. No smearing and no little problem, only amazing.

I've used xvid decoder and the lastest ffdshow alpha 13/11/2002 and no problems.

I think Qpel at least using only Qpel no Bframes together is ready to daily use, and it saves space too.

And the quality is really really great.

Thanks for such a great effort.

[miha]

Hmm well I m using wincvs 1.3 and yesterday there ware 8 updated files today I check it again and there ware 9 updated files

[kempodragon]

I'd have to agree about Q-pel. I've used it on my last few encodes and have had absolutely no problems with it. I also use chroma since most of capturing is anime, and again no problems. B-frames I don't use, mostly because XVID's quality is amazing as is. I was going to try it on a capture of Akira Kurosawa's "The Hidden Fortress", since this movie is 2hrs and 20 mins. But I accidentally overwrote the capture file(where IS that icon of slapping myself?) and I haven't found anything else that needs it. If the Patriots make it to the Super Bowl, I'll do a capture of that and give XVID a REAL torture test.:devil:

[Blight]

Or you can start doing 2 movies per cd ;)

[Koepi]

XviD-09122002-1:
- refdivx's lumi masking finally fixed.
- dynamic hpel/qpel decision - switchable.
- Suxendrol's experimental chroma optimizer (http://www.xvid.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=815)

Enjoy! :)

Best regards
Koepi

EDIT: I forgot to add that sysKin also fixed the search range for qpel resolution, it's decreasing filesize by quite homeopathic dosis :)

[Swede]

Yes! The random dots from LumiMasking is definitely gone, at least in my testclips!
Many thnx to everyone involved!

[Soft Maniac]

it seems that isnt't possible to download the codec from the koepi site!!

Any alternnative link?

[Sofus]

The random dots from LumiMasking is still there, in my testclips!

Sofus

[Bulletproof]

It's working great for me, I'm not seeing any dots in lumi masking, however they could be subtle, I havent done thorough testing. From my first test, I am getting better quality at a smaller filesize with this new build.

[Soft Maniac]

i have been testing xvid for months and i'm seeing a better image quality in cost of speed, but..

Qpel make my movies whith a strange problem!It is more noticeble in faces and boddy parts and it is a kind of noise that i can explain!

A attrached a image so you can see it

[Soft Maniac]

onother one

[MoonWalker]

About the random dots with luma masking...

I get them to...But I also get one BIIIIG block at the bottom right corner of the movie using luma masking..anyone got this? It's ffdshow's fault i think. In Vdud there isn't..I have tested the same clip without luma masking and it's ok...

MoonWalker

[kilg0r3]

@SoftManiac

Sorry, but i cant see your problem in the pictures. The noise that i can see seems to be what i would call ringing artifacts, which could be due to relatively high quatizers.

what are the parameters for your movie?

anybody else?