XviD-14112002-1...

[Koepi]

Ahoy,

I made a new build:

XviD-14112002-1:
- Fresh CVS checkout.
- Added bframe+skip-frame report+storage (nns.dd_v bits 30+29).

It's nice to watch the debugview output now, you can see skipped+bframes. They're not steering the 2nd pass now, but my first tests for a few 1000 frames showed that the i/p/b-decision is quite stable and thus it gives at least a propper view of things.
VDub might show funny things though, it might be that it reports bframes as keyframes, but who cares as it is just cosmetical ;)

Regards
Koepi

[Selur]

thx for the new build

[Koepi]

You're welcome :)


New, silent update: binary with same name is up, got that issue with Vfw solved (vdub reporting bframes as keyframes...).

Regards,
Koepi

[HomiE FR]

Thanks a lot Koepi! :)
I hoped that someone would make the infos on B-frames appear on debugview.

[MoonWalker]

Originally posted by HomiE FR
Thanks a lot Koepi! :)
I hoped that someone would make the infos on B-frames appear on debugview.

Hehe :)..I am working on it...Just had too much job for my University..

PS @Koepi I suppose your build is YU12 "compliant" :)

MoonWalker

[iago]

@Koepi

Thanks a lot for the new build "dostum". I'll write longer soon! ;)

best regards,
iago

[Koepi]

Heh, thanks for all the compliments, but I have to warn you:

It's just a visualisation of the bframes (and it's not 100% correct, we suxen_drol made me aware of the fact that we have different frame types as well which I have to sub-categorize).

I have a build up and running here that e.g. eliminates the first "delayed frames" from the stats file. But unfortunately, for the second pass we need much more complicated (well, not really) handling of this (delayed overflow compensation, resorting of frametypes/stats entries,...) which I unfortunately can't make as for my taste foxer's code is a bit too cryptic, I couldn't garantuee that the code works bug-free - if it works at all (dunno where to start for a lack of better explanation).

But it's a nice feature and it is a step in the right direction, as proper bframe treatment for VfW is in progress now.

I just want to mention that here, because curve treatment is absolutely wrong now and results in "funny" results (way less than optimal).

Best regards
Koepi

P.S.: serefe, iago :)

[MoonWalker]

I have encode a movie with this build and I have a problem. It plays in slow motion..Tried to playback with nic's filter, bsplayer gave me "Unsupported format"..

My setting where the defaults (2-pass) with Chroma ME..

MoonWalker

[CruNcher]

Tried to playback with nic's filter

It won't work correct by now, try the new ffdshow it works perfectly without this slowmo effect i think NIC is working on the Problem so we have to wait

[kastro68]

gmc, b-frames, chroma and quarter pixels seem to work fine without any problems for me so far.

However, I am using DX50 fourcc.

[NoLogo]

CruNcher> do you know where ffdshow can be downloaded, the usual link seem to be broken... :(

[Koepi]

http://sourceforge.net/projects/ffdshow/ -> ffdshow-alpha.

Currently, sourceforge is down for a bit for maintenance but will be back up soon.

Regards
Koepi

[NoLogo]

Koepi> Yeah, that's what I've seen... but if you say "soon", i think I can wait for a few day :)
Thanx for the reply and for the binaries.

[ffroms]

Yep. ffdshow-20021113-Alpha is the only that can play movies correctly(b-frame,GMC,QPel,Luma motion).

Thanks Koepi for that build together with AVISynth 2.5 gives best resoults I've seen so far.

[cult]

With gmc enabled and bframes in encode I get strange smearing effect with ffdshow.If I check "use xvid" then I get slow motion,so i am not sure if it works ok.

[ffroms]

Did U use this alpha version? I have no problems with it . And check "use Xvid".

FFS

[cult]

with another movie didnt get this effect.So I guess it was the movie after all.With another one it works fine.With checked use xvid-terrible slow.Alpha build 13/11 using

[ffroms]

Yes. There is something wrong with xvid.ax in that. Hope there will be new build of DS filter soon.

[iago]

Has anyone tried GMC alone (without b-frames) with the new 14112002-1 build? It seems OK here, decoding with ffdshow 13/11, "use xvid" unchecked.

However, GMC + QPel (without b-frames) seems to have some (decoding?) problems, when decoded with ffdshow 13/11.

(I can neither use Nic's xvid.ax nor ffdshow 13/11 with "use xvid" checked, since my limited processor power doesn't allow me to use them without playback problems with a resolution of 640*... ;))

regards,
iago

[Teegedeck]

Did you see any noticeable visual improvement or filesize-reduction with GMC? Neo Neko reported some bitrate-reduction with noisy analogue captures.

[ffroms]

I tried with GMC+Q+LumaM (only 1pass on 3000 frames) and had no playback problems with ffdshow (without "use Xvid"). There is no file size improvement (actualy it was a little biger than without GMC,B,Q,LumaM).

FFS

[Koepi]

XviD-16112002-1:
- BFrame support in Vfw added by Foxer, not perfect yet but better than before.


YAY! try it! (I did and it worked very well!)

Regards
Koepi

[TheUnforgiven]

@koepi
could u explain more about how the 2-pass mode is now aware of b-frames.
thanks in advance

[Koepi]

?

Before these changes VfW just tried to scale everything as if there were no bframes. Now it "knows" about bframes and has a bframe-curve as well which it scales separately, resulting in proper scaling results compared to the scaling before.

As I wrote about the old stuff: curve treatment / overflow treatment went nuts due to bframes and wasn't at all suitable.

This has changed.

I hope it's clearer for you now.

Koepi

[iago]

@Koepi

You're lightning fast these days! Thanks one more time! ;)

Btw, (just a personal observation but) with the recent builds, quality and speed improvement (with Avs2.5 and YV12 colorspace) is even more noticable imho. XviD is moving with big steps towards perfection! ;)

regards,
iago

[TheUnforgiven]

@koepi
thanx for the fast responce
i know about the problem, just wanted more details about the solution.
gonna try the new build tonight.

[HarryM]

@Koepi:

Thanks.

[Dali Lama]

Hi Koepi, I am currently running my second pass of a movie with b-frames. If I want to try out the b frame aware curve treatment, can I just run a second pass again or both?

Thanks,

Dali

[Koepi]

Unfortunately we must store the different frame types, the old build did that wrong.
You need to do a full 2pass again :-/

Regards
Koepi

[iago]

Koepi,

I guess GMC doesn't work with the new 16112002-1 build. ffdshow 13/11 OSD doesn't report any GMC frames, and I get identical results in my short "2-pass" tests with and without GMC (the same 1st Pass size, the same quantizer distribution, etc.)

Can you please check and confirm this issue?

best regards,
iago

Btw, I have started a full two-pass encode of a ~ 101 min. movie, with the 16112002-1 build, aiming for 613000 kb, using b-frames 4/200, LanczosResize(640,352), and no special credits treatment ;). Let's wait and see the results!

[crOOk]

I've personally never used B-Frames before because they didn't look good in 2pass. This has changed since the 914 build. Thanx to all the developers!!

[MoonWalker]

BTW..Does all these features (B-Frames,Qpel,GCM,Chroma Motion e.t.c) work with MPEG quants? Or it's just H.263? Or some of the work with MPEG?

Thanks,
MoonWalker

[neo_sapien]

Do any of these bugfixes deal with the b-frame desync bug?

[Koepi]

bframe desync bug?

Sorry, but that's system-immanent to bframes.

Fetch yourself a copy of ffdshow, set video-delay to -120ms (-80 is fine, too), and you're done, perfectly sync movie. Or if you know that you'll use bframes on your encode, add 120ms (or 80ms are fine, too) of delay to the sound.

Regards
Koepi

[neo_sapien]

Ah, I didn't know that feature had been implemented yet in ffdshow, but I'm very glad it has :)

Danke

[NoLogo]

I can confirm GMC doesn't modify the encode at all: same size, quality and quantizer distribution.

Iago> how do you see GMC with FFDSow ?

[cjv]

To see if GMC was used (or b-frames, or qpel, etc..) go to
ffdshow->Configuration->OSD->Frame Type. Make sure "Frame type" is checked, and "OSD" is checked. You can see the results in green when you view your video in a media player.

cjv

[cult]

confirmed here too.No gmc showing with ffdshow

[Gaia]

I can see GMC with ffdshow. I just checked it out.

[iago]

@Gaia,

With the 14112002-1 or 16112002-1 binary?!

I guess it doesn't work with the 16112002-1 build, as others have confirmed too.

regards,
iago

[Koepi]

EDIT: GMC is just a "draft impementation" now, it's not giving much compressability increasement. It's switched on and off dynamically when it helps a frame, so your sequences might be just not suitable to GMC. Try a clean scene with a longer camera pan and see if GMC is used please.

Regards
Koepi

[AndyP]

Likewise, could somebody verify if the qpel tickbox is working. I have tried encoding a short clip with the 16/10 build (1 pass quant =3, motion search 6, tried with both H263 and MPEG, all else default) with the qpel box enabled/disabled and the resulting avi's were identical....

EDIT: Also tried with the colour motion box ticked/unticked and that seems to make no difference either.

It could, however, just be me... :D

Kind Regards,
Andy

[Koepi]

The code looks fine, might be something with the core... VERY strange.

Hopefully someone finds the error.

Regards
Koepi

[unplugged]

Originally posted by AndyP
Likewise, could somebody verify if the qpel tickbox is working. I have tried encoding a short clip with the 16/10 build (1 pass quant =3, motion search 6, tried with both H263 and MPEG, all else default) with the qpel box enabled/disabled and the resulting avi's were identical....
Yes, this happens me too with sysKin special 18/11 compile (QPel & B-Frames working together), files result identical with or without.

[iago]

Yes, I can confirm that the problem persists with sysKin's 18/11 binary as well. No QPel, no GMC (being reported by ffdshow OSD) with or without b-frames.

regards,
iago

[sysKin]

See what heppens when I make a build at 2 am?
You're right. I added Koepi's new 2-pass code (more correct for bframes) and didn't notice that checkboxes-realted part is just not active. Uh.

Don't worry about this special build, I've found at least four new errors is it (quite serious ones) so it's bad anyway.

If I'll get rid of them, I'll just give the code to Koepi and he'll make a build :)

Radek

[Koepi]

Changelog:

XviD-18112002-1:
- sysKin added support for GMC and QPEL with bframes. Try it please!

ah, and the code is enabled which sets the switches for GMC, chroma ME, qpel,... dunno why it was commented out :-/

Regards
Koepi

[Gaia]

It's little off the topic but is QPel working now better? I tried it few builds back and still saw colour smearing and Divx3 style noise. I can't test it today because i am in the middle of encoding, testing some other sfuff. Or is QPel just like that because atleast in Divx5 pro it just creates strange noise/artifacts or whatever and nobody recommends to use it. It might work better with really high bitrates but below 1000 bitrates it doesn't look good.

[AndyP]

Hi

All checkboxes now work fine with Koepi's 18/11 build :D However I get a consistant crash in vdub 1.4.11 using Bframes (2/150) with qpel. Settings - 1 pass quant 3, H263, Motion search 6, bframes 2/150 with DIVX5 compat, qpel ticked. GMC and chroma unticked.

AVS
---
LoadPlugin("mpeg2dec.dll")
LoadPlugin("convolution3d.dll")
mpeg2source("E:\DVD\THE_MATRIX\The Matrix.d2v")
trim(142800,143100)
crop(4,80,712,416)
BicubicResize(640,256,0,0.5)
Convolution3D(0,4,4,4,4,2.8,0)

Bframes and chroma search work together (at least on this clip). Have not tried GMC as the clip does not have any good pans.

Kind Regards,
Andy

[MoonWalker]

I can confirm what AndyP sais...

I too get a crash using b-frames + qpel..The other setting are working ok...

As for GMC, I tested it on "Spiderman : The Movie" (before the end credits) which has large camera pans..Works ok..

MoonWalker

[Koepi]

sysKin is sending me a fix right now, a new build will be up soon...

regards
koepi

[sysKin]

Originally posted by Koepi
sysKin is sending me a fix right now, a new build will be up soon...
This sounds so good. Let me write it in other words:
sysKin just removed all functions which caused known problems. Encoding will be slower, because one of the functions was supposed to increase speed without changing anything (but it changed).

Encoding will be worse, because one of four macroblock modes is disabled. It didn't work correctly anyway.
DO NOT use this bulid for non-qpel, because this mode will still be disabled and encoding will suck.

But anyway, thanks for the kind words, like "fix". LOL. :D

Have fun testing,
Radek

[Koepi]

New build up, with interpolate mode switched off... ;)

Regards
Koepi

[Trahald]

well.. i guess this is the exciting world of using unstable builds.. lol

great job addressing the issues so quickly, guys

i did an encode with the 16112002 build (just b-frames and lumi) and it came out great (decoded with nics ds filter )

guess i'll try a gmc - bframes encode tonight with teh new build

[JimiK]

Sorry guys, just have to ask now. sysKin wrote that encodes will be worse. Does that apply to every setting, even with qpel? Koepi wrote at his site "do not use without qpel". If you want to encode with bframes, but without qpel, you better use the 1811-1, or the 1611 build? Is this a "only if you really like bframes and qpel and want to use them together, even though there could be a quality decrease"-build?

Best regards,
JimiK

[sysKin]

Originally posted by JimiK
[B]Sorry guys, just have to ask now. sysKin wrote that encodes will be worse. Does that apply to every setting, even with qpel? Koepi wrote at his site "do not use without qpel". If you want to encode with bframes, but without qpel, you better use the 1811-1, or the 1611 build?In this highly-experimental build, b-frames's quality will be worse (or more precise: they will be bigger at the same quality) then it should be. For non-qpel, use 'normal' builds where quality is not impared. For qpel, you don't have much choice ;)Is this a "only if you really like bframes and qpel and want to use them together, even though there could be a quality decrease"-build?
Well yes, exactly. Qpel+bframes in _this_ bulid already give better quality then only qpel or only bframes, but are absolutely sub optimal. Only for testing - but if you encode anything it's ok, you make a valid movie.

[iago]

Well, that sounds interesting ;). I'll start a fresh two pass now with "b-frames + qpel" using Koepi's new 18112002-2 build.

@sysKin and Koepi,

Thanks for all your great work!

best regards,
iago

[drebel]

Internal CVS changes are affecting Avisynth?

Using latest Koepi's compilations(16/11 and 18/11-1)i came across the following phenomenon;it's been more than a year that i'm using VirtualDub jobs to encode only a portion of the movie to check the final(more or less) result.That means i'm aborting first pass after ~3000 frames which leaves VDuB job to perform the second pass UNTIL that frame comes(causing an internal avisynth error and VDub to stop because of "possible data corruption"...
During the latest two builds,i noticed somethind strange:VirtualDub keeps encoding for the second pass AFTER the certain frame(and after more than 1000 frames-i dont really know if it completes the 2nd pass).Image visual quality of the encoded part is not bad ,but it seems to me that i get more compression artifacts AFTER that frame.
I've passed to YV12 lately,using all the required stuff from the Avisynth Faq with no probs fo far except for this one.To avoid the problem,i changed almost EVERY Xvid option(except lumi and interlaced),with the same NON FATAL result for VirtualDubMod.Only when changing back to Koepi's 14/11 i saw the usual response.(it's not a script prob,avs is fine with Avisynth 2.5 11/11)
Does anybody have any ideas?Am i missing anything critical here?Could anyone else confirm this?What's been feeding the 2nd pass if stats file from the uncomplete 1st pass contains data up to that frame...?

thanks in advance,
george

[AndyP]

I might be missing the point, but have you tried using trim in the script. Relying on errors and aborting things seems a little risky.....

Kind Regards,
Andy

[unplugged]

It's just a sensation, it seems that after these modifications even the little smearing visible with non xvid-ax decoder (ffdshow...) is *ENTIRELY* gone...

:D ?

[vinks]

been testing out this qpel stuff on this new build dated as of today on "The Test" the dvd single by the chemical bros (lots of varying scenes its a difficult enough clip to encode)

and it came out much "sharper" and more detailed than with out, didn't have any problems on playback either in xvid or ffdshow, here are the details...

--
Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 3 Times, Percentage Used : 0.03%
Quant 3 Used : 4095 Times, Percentage Used : 44.89%
Quant 4 Used : 4827 Times, Percentage Used : 52.92%
Quant 5 Used : 190 Times, Percentage Used : 2.08%
Quant 6 Used : 7 Times, Percentage Used : 0.08%

Average Quantizer Used for Movie : 3.573

No credits encoding!!

H.263 Quantization Type Used 9122 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 2 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 3 Times, Percentage Used : 1.89%
Quant 3 Used : 156 Times, Percentage Used : 98.11%

No credits encoding!!

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 3 Used : 3939 Times, Percentage Used : 43.95%
Quant 4 Used : 4827 Times, Percentage Used : 53.85%
Quant 5 Used : 190 Times, Percentage Used : 2.12%
Quant 6 Used : 7 Times, Percentage Used : 0.08%

No credits encoding!!



Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 159
Number Of Inter-Frames (P-Frames) : 8963
Total Number Of Frames : 9122

1.74% of the Movie is Intra-Frames (Key-Frames)
98.26% of the Movie is Inter-Frames (P-Frames)



Size Analysis
----------------

1-Pass Size : 77402458 Bytes or 75588 KBytes or 73 MBytes
Scaled Size : 41132481 Bytes or 40168 KBytes or 39 MBytes
Actual Size : 41126360 Bytes or 40162 KBytes or 39 MBytes

Usefull Statistics
------------------
Compressibility : 53.13%
Relative Quality of XviD avi : 55.98%
Absolute Quality of XviD avi : 95.28%
--

used the following avs file

--
LoadPlugin("C:\PROGRA~1\GORDIA~1\MPEG2dec3.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\undot.dll")
mpeg2source("C:\divx\the_test\work\the_test.d2v",idct=5)
crop(0,70,718,436)
undot()
LanczosResize(608,336)
--

i shall have to try it with bframes later on and see how it all goes.

nifty work people. keep it up.

note: oh yea playback with ffdshow-20021113 seemed to be better than xvid. xvid blured things a little, ffdshow seem to "degrade" the quality of the clip till the next keyframe comes about, i think this is a known issue?.

[drebel]

@Andy
thanks for the quick reply.
So,here's the script to avoid misunderstanding(BTW i didnt change avisynth version : 2.5 , 11/11)


LoadPlugin("C:\Program Files\Avisynth2.5\MPEG2Dec3.dll")
#LoadPlugin("C:\Program Files\Avisynth2.5\TomsMoComp.dll")
LoadPlugin("C:\Program Files\Avisynth2.5\UnDot.dll")
#LoadPlugin("C:\Program Files\Avisynth2.5\UnFilter.dll")
#LoadPlugin("C:\Program Files\Avisynth2.5\Convolution3DYV12.dll")
#LoadPlugin("C:\Program Files\Avisynth2.5\Focus2.dll")
LoadPlugin("C:\Program Files\Avisynth2.5\FluxSmooth-2.5.dll")
clip=mpeg2source("D:\Movies\Time\time.d2v",cpu2="ooooxx")
Part1=trim(clip,0,1277)
Part2=trim(clip,1278,130300)
Part3=trim(clip,130301,0)
Start=Part1.crop(0,75,720,424).LumaFilter(-3,1).BilinearResize(672,272).FluxSmooth(0,5)
Movie=Part2.crop(0,75,720,424).LumaFilter(-3,1).Undot().LanczosResize(672,272)
Credits=Part3.crop(0,75,720,424).LumaFilter(-3,1).BilinearResize(672,272).FluxSmooth(0,5)
Return Start+Movie+Credits

I always use trim,but for another reason....
I'm only concerned if something 's changed inside curve compression treatment to cause such a difference

have fun with xvid,
george

[vinks]

this might be a bit pointless, since my copy of xvid analyser is old and out of date, (same settings as above post, but bframes and qpel turned on)


--
XviD Analyzer v0.14 by MoonWalker & MarcFD
e-mails : s_ilias@gmx.net & marc.fd@libertysurf.fr


Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 39 Times, Percentage Used : 1.07%
Quant 3 Used : 2460 Times, Percentage Used : 67.60%
Quant 4 Used : 1085 Times, Percentage Used : 29.82%
Quant 5 Used : 50 Times, Percentage Used : 1.37%
Quant 6 Used : 3 Times, Percentage Used : 0.08%
Quant 7 Used : 2 Times, Percentage Used : 0.05%

Average Quantizer Used for Movie : 3.320

Quantizers Used For Credits :
--------------------------------
Quant 2 Used : 104 Times.
Quant 3 Used : 4247 Times.
Quant 4 Used : 1089 Times.
Quant 5 Used : 33 Times.
Quant 6 Used : 5 Times.
Quant 7 Used : 2 Times.
Quant 8 Used : 3 Times.

H.263 Quantization Type Used 9122 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 15 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 8 Times, Percentage Used : 0.14%
Quant 3 Used : 412 Times, Percentage Used : 6.97%
Quant 4 Used : 11 Times, Percentage Used : 0.19%

Credits
---------
Quant 2 Used : 104 Times, Percentage Used : 1.76%
Quant 3 Used : 4247 Times, Percentage Used : 71.81%
Quant 4 Used : 1089 Times, Percentage Used : 18.41%
Quant 5 Used : 33 Times, Percentage Used : 0.56%
Quant 6 Used : 5 Times, Percentage Used : 0.08%
Quant 7 Used : 2 Times, Percentage Used : 0.03%
Quant 8 Used : 3 Times, Percentage Used : 0.05%

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 31 Times, Percentage Used : 0.97%
Quant 3 Used : 2048 Times, Percentage Used : 63.84%
Quant 4 Used : 1074 Times, Percentage Used : 33.48%
Quant 5 Used : 50 Times, Percentage Used : 1.56%
Quant 6 Used : 3 Times, Percentage Used : 0.09%
Quant 7 Used : 2 Times, Percentage Used : 0.06%

Credits
---------



Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 5914
Number Of Inter-Frames (P-Frames) : 3208
Total Number Of Frames : 9122

64.83% of the Movie is Intra-Frames (Key-Frames)
35.17% of the Movie is Inter-Frames (P-Frames)



Size Analysis
----------------

1-Pass Size : 51519504 Bytes or 50312 KBytes or 49 MBytes
Scaled Size : 31518312 Bytes or 30779 KBytes or 30 MBytes
Actual Size : 28715821 Bytes or 28042 KBytes or 27 MBytes

Usefull Statistics
------------------
Compressibility : 55.74%
Relative Quality of XviD avi : 60.25%
Absolute Quality of XviD avi : 96.04%
--

i did notice though that there were quite a few intra frames used consequtively, even though i set the min iframes to 10. i wont comment on the quality though.

bframes were set to 3, 150%

[AndyP]

Hi drebel,

I'm certainly no expert but as the second pass is going on beyond the first pass end is it not bound to look bad as the first pass info is not available for the curve compression etc.. to use. Now why it allows itself to carry on is another matter (I honestly have no idea). It's as you say what is feeding the second pass...

Kind Regards,
Andy

[NoLogo]

Originally posted by vinks
i did notice though that there were quite a few intra frames used consequtively, even though i set the min iframes to 10. i wont comment on the quality though.


I have noticed that point too, and it seems quite odd to me...

I've done some tests using the 16/11/02 build by Koepi, with a short part of Ghost Dog (2'20, frames 112000 to 115546), composed with slow- and low-motion scenes, with the following tuning:

Duration: 2'20
Size: 11000ko (about 700kbs)
MSP: 6
Quant. type: H263/New mod. HQ
Max I-frames interval: 300
Min I-frames interval: 9
Lumi: off
Interlacing: off
Qpel: off
Packed bitstream: on
DX50 B-VOP compatibility: on

Then:
BF(2/150)
BF(3/150)
BF(2/200)
BF(3/200)
GMC only
Chroma motion only
BF(2/150)+GMC

that is to say 7 encodings.

Using DebugView and XviD Analyzer, I obtained the results for each encode, and it's quite dissapointing: using BF, 90% of the movie is KF (despite the fact i chose "Min I-frames interval=9), whereas without them, it's pretty normal, only 5-10% of the frames are KF.
Nevertheless, the quality is better with BF, with an average Quantizer=2.2 (2.8 without BF), and the compressibility grows as well (110% against 65%). Moreover, I can see that H263 is never used, whereas it was with the same tunings with older builds.

Here one analysis with BF:

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 85 Times, Percentage Used : 76.58%
Quant 3 Used : 26 Times, Percentage Used : 23.42%

Average Quantizer Used for Movie : 2.234

Quantizers Used For Credits :
--------------------------------
Quant 2 Used : 2785 Times.
Quant 3 Used : 651 Times.
Quant 4 Used : 3 Times.

MPEG Quantization Type Used 3550 timed, Percentage Used : 100.00%

No prevention happened

Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 27 Times, Percentage Used : 0.78%

Credits
---------
Quant 2 Used : 2785 Times, Percentage Used : 80.35%
Quant 3 Used : 651 Times, Percentage Used : 18.78%
Quant 4 Used : 3 Times, Percentage Used : 0.09%

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 58 Times, Percentage Used : 69.05%
Quant 3 Used : 26 Times, Percentage Used : 30.95%

Credits
---------
Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 3466
Number Of Inter-Frames (P-Frames) : 84
Total Number Of Frames : 3550

97.63% of the Movie is Intra-Frames (Key-Frames)
2.37% of the Movie is Inter-Frames (P-Frames)

Size Analysis
----------------

1-Pass Size : 1047751 Bytes or 1023 KBytes or 0 MBytes
Scaled Size : 864864 Bytes or 844 KBytes or 0 MBytes
Actual Size : 1099778 Bytes or 1074 KBytes or 1 MBytes
Actual Size of Avi File without Sound : 1193984 Bytes or 1166 KBytes or 1 MBytes

Usefull Statistics
------------------
Compressibility : 104.97%
Relative Quality of XviD avi : 89.52%
Absolute Quality of XviD avi : 99.30%

When i try to read the vids, I always got the same result: the decoding is quite jerky (using either Nic's DShow filter or FFDShow), as if I got 25fps then 10, then 25 again. I have only 30-40% CPU load, so I think it has nothing to do with this. But the quality is perfect, considering the birate i had, XviD's BF are lot better than DviX's ones.

I have tried later with the new build (18/11/02-2), without "packed bitstream" and "DX50 B-VOP compatibility" and it's exactly the same.

So my question is: does it come from what i did (e.g. BF and New Mod HQ), or is it something that was changed in the build ?

Hope my problem may help (or maybe I'm just an idiot...).

NoLogo

PS: XviD is getting better and better, thanx to all developpers.
PPS: sorry for the long post :).

[MaTTeR]

Originally posted by NoLogo
XviD's BF are lot better than DviX's ones. I have to say I was never much of enthusiast of B-Frames until seeing some recent tests myself. Admittingly it was because I was use to seeing the (blurred)implementation of DivX 5.x. However, my recent tests on some 4:3 films made a true believer out of me! The quality is indeed outstanding to say the least with these latest builds, I still prefer Koepi's 09112002 build myself.

A big thanks from me to all the developers and contributors. I never doubted for a moment the implementation would be greater than that of a commercial codec(no names mentioned):D

Edit- I should have mentioned B-Frames play perfectly smooth for me using a 10-10-2002 build of ffdshow decoding with libavcodec.

[NoLogo]

Originally posted by MaTTeR
I should have mentioned B-Frames play perfectly smooth for me using a 10-10-2002 build of ffdshow decoding with libavcodec.

Booooooh... why not by me ?... :(
And i suppose you have no problems with I-frames ?
Whatever, maybe i should try some older builds. Thanx for the advice.

NoLogo

[scorchED]

when i am using koepis built 14112002 then i get a very nice result of every encoding. i tested only first pass with all standart parameter and MSP: 6-Ultra High, QT: H263, b-frames: 2@150, chroma motion enabled. the encodet movies (res 640x352) are clean and without any jerky playback by using ffdshow 20021113.
this built is my reference built now:)
i also tried koepis built 18112002 with the same settings (and qpel+bframes enabled), but i don't like the results i get. you have to enable q-pel with b-frames and you get a movie with some smearing effects in high and slow motion scenes. you get some sharper frames too, but the smearing is too much. also there is a lot of backround noise in slow motion areas. (in the source isn't any noise, because i use a very efficient filter chain to eleminate all noise.)

[lighty]

Just finished encode with Koepi's build 18112002-2 and used QPel+GMC+B-frame3/200+NewModHQ.

Everything plays fine without any sound desync (so B frames are then working as they suppose to?) with FFD show. It reports Bframes, QPel and GMC used. XviD decoder however plays in "slow motion".

I am VERY happy with this build it is obviously a step in the right direction.:D

[iago]

Hello all,

After some short tests and especially after a full two-pass encode of a 2+ hr. and hard to compress movie with "b-frames 5/200 + qpel + gmc" using the 18112002-2 build from Koepi, together with UnFilter(-10,-10) in the script, I must admit that I'm quite surprised to get such good results! ;) Also, no decoding problems with the latest ffdshow - libavcodec, dated 13/11.

The giant steps being taken in XviD development recently are absolutely great; and XviD is, without any doubt, "the" codec at the moment!

Thanks again to all the developers for all their effort!

best regards,
iago

[neo_sapien]

Originally posted by scorchED
when i am using koepis built 14112002 then i get a very nice result of every encoding. i tested only first pass with all standart parameter and MSP: 6-Ultra High, QT: H263, b-frames: 2@150, chroma motion enabled. the encodet movies (res 640x352) are clean and without any jerky playback by using ffdshow 20021113.
this built is my reference built now:)
i also tried koepis built 18112002 with the same settings (and qpel+bframes enabled), but i don't like the results i get. you have to enable q-pel with b-frames and you get a movie with some smearing effects in high and slow motion scenes. you get some sharper frames too, but the smearing is too much. also there is a lot of backround noise in slow motion areas. (in the source isn't any noise, because i use a very efficient filter chain to eleminate all noise.)

I concur. I did a 30 second low motion sample of Star Trek TNG 220 Cost of Living at 1-pass quant 3, and it amplified the noise present in the source. The first thing I'm thinking is really, really really high motion search precision.

Settings for XviD (11/18/2002 8:32:34 AM)
Mode: 1 Pass - quantizer, Quantizer: 3
Motion Search Precision: 6 - Ultra
Quantization Type: H.263
FourCC Used: XVID
Max I-frame Interval: 240, Min I-frame Interval: 5
Lumimasking: OFF
Interlacing: OFF
Greyscale: OFF
Use Chroma Motion-ON
Global Motion Compensation-ON
Quarterpel-ON
Max B-frames: 2
B-frames Quantizer Ratio: 200%
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON
Print debug info on each frame: OFF
Min I-frame Quantizer: 2, Max I-frame Quantizer: 2
Min P-frame Quantizer: 2, Max P-frame Quantizer: 16
Max Bitrate: 10000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%
Start Credits: OFF, End Credits: OFF,



AVS Script:
SetMemoryMax(40)
LoadPlugin("D:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("D:\PROGRA~1\GORDIA~1\decomb.dll")
mpeg2source("H:\DivX\Unfinished DivX\Season 5 Disc 5\PROCESSING\sample.d2v")
Telecide(guide=1,firstlast=true,gthresh=10,post=true)
Decimate(mode=2,cycle=5,quality=3,threshold2=2.0)
crop(13,0,701,478)
BicubicResize(576,432,0,0.5)

Attached is a screen of the AVS and a screen of the XviD. Attachment is pending mod confirmation. Images had to be saved in JPEG at Quality 94 in Adobe PS 5.5 because max attachment size is 204kb, so no PNG.

[MaTTeR]

scorchED,

Do you see the smearing with Qpel disabled? I've noticed B-Frames does seem to leave motion trails around small movement in darker scenss. It almost reminds me of the problem I seen with Qpel some weeks back.

NoLogo,

No I had no cosecutive I-Frames and I reproduced your problem last night. I set ffdshow to decode with XviD instead of libavcodec and the playback was very choppy and sometimes in slow motion.I switched back to libavcodec on the PIII 850 and it played the frames perfectly.

[NuclearFusi0n]

I got a small amount of shitframes when I encoded run lola run with 11/18, with ffdshow 11/13, but when I open it in virtualdub, there are no shitframes, and when i disable ffdshow and open it in windows media player 6.4, the entire movie is garbled

:confused:

edit: the entire movies looks excellent except for some light smearing at parts :(

settings:

Mode: 2 Pass
Motion Search Precision: 6 - Ultra
Quantization Type: MPEG for both passes
FourCC Used: XVID
Max I-frame Interval: 300, Min I-frame Interval: 1
Lumimasking: OFF
Interlacing: OFF
Greyscale: OFF
Use Chroma Motion: OFF
Global Motion Compensation: ON
Quarterpel: ON
Max B-frames: 2
B-frames Quantizer Ratio: 125%
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON
Print debug info on each frame: OFF
Min I-frame Quantizer: 2, Max I-frame Quantizer: 4
Min P-frame Quantizer: 2, Max P-frame Quantizer: 16
Max Bitrate: 10000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%

Curve was linear, no iframe boost, 0% for high bitrate scenes, 0% for low, 250 bitrate payback delay, and payback proportionally

edit: found another area with heavy shit, and when opened in virtualdub, it's totally clean

[Pasqui]

@NoLogo
I guess XviD Analyzer does not support yet B Frames. That's why you get such a high amount of "keyframes" (in fact real keyframes + B Frames).
BTW, in all my tests, checking Packed bitstream always resulted in a jerky playback. Just unticking it and activating DX50 BVop Compatibility always resulted in a perfectly smooth playback.

[NoLogo]

Yeah, since Matter told me he had no problem with an older Build of libavdec, I tried the 9/27/02, and i have to say it seems to look better (but maybe I managed to convince myself there is a problem, and now I can't believe it's OK). But I have re-thought about all this stuff, and I have the same conclusion: maybe XviD analyzer is not B-frames compliant...
Whatever, I have launched a pretty long encode (still 10 hours), with a whole movie (Ghost Dog, again :)), I'll see tomorrow what it looks like. I keep my finger crossed (not easy to type).
Thanx for all.

NoLogo

PS: does anybody know if Nic has planned to make anew DShow filter ?

[scorchED]

@Matter
i only get smearing effects on all movements when i used the 18112002built from koepi with q-pel enabled. without q-pel and with the 14112002built everything is very fine. i encodet the same movie with the same script and other parameters two times.

[Koepi]

XviD-20112002-1:
- Fresh CVS checkout. Plenty bugfixes and additions...

Short summary:

- bframes: interpolated prediction mode works again
- major slowdown when using bframes, qpel, gmc, chroma me together ;)
- some more bugfixes in the ME according to sysKin
- the rest I've forgotten - sysKin is sure to have introduced some new bugs ;)

Enjoy testing the new build,

best regards
Koepi

[Koepi]

Hm. For me, the code crashed again. If that happens, try disabling "Integer SSE" in the debug-panel of xvid and try again.

Regards
Koepi

[HarryM]

I use only q-pel.
Other special features are possible buggy for me.

[celeron]

Hi 1º post :)
I have test the today Keopi build and it rocks i dont have no prob now whit this new one, i have made a short encode(250mb vob from Perfect storm) and realy it looks great.
I only have test it whit Bframes 3/150 and chroma motion, even the final size have drop from 32.3mb too 31.2mb.
And now i can decode the clip even whit the xvid.ax whitout the clip being in slow motion.

@Keopi
No crash in here i have done 2-pass, i dont have need it too dissable the "Integer SSE" :)(Win2k+SP3 and Duron Morgan 1.2Ghz)

Thks for your hard work guys ;)

PS: sorry very bad english :)

[Koepi]

That crash only occurs very seldom (and somewhat randomly) when using qpel+bframes (and there it's exactly located within "bframe interpolate qpel search").

I'm using the old duron700, no real SSE in there - but it's more likely that a vriable/pointer gets messed up, but strange enough this behaviour changes if I disable XMM (integer SSE).

Just to clear that up :)

Best regards,
Koepi

PS: welcome aboard, celeron!

[cult]

true true!now we can check use xvid in ffdshow without slowmotion fx.And what a quality that is!
Thanx all-lets do the happy dance

[celeron]

Thks Keopi its nice 2 be here :)

I have made again another short encode whit 02112002-1(same source as my previus post) this time whit Bframes-3/150+Qpel+chroma motion.
Cunclusion no crash but the quality its very bad.
For me only whit Bframes and chroma motion the quality its great.

PS: Bframe+qpel decoding only work whit ffdshow if i try to open in virtualdub or open whit xvid.ax it just crash the xvid.dll.

Thks :)

[NuclearFusi0n]

i crash with MMX, SSE, 3Dnow, and 3dNow2 enabled, Integer SSE, and SSE2 disabled
AMD Athlon XP 2000+

when running with only SSE, 3dnow and 3dnow2 enabled, i have 8 hours left in my firstpass! :(

I need to stop MMX and Integer SSE to be stable. I don't know wether that is causing the slowdown, or whether it's the QPel + BFrame issue.

[Pasqui]

So as to encode a movie with BFrames + QPel on my AMD Athlon 500, I have to disable MMX otherwise I get a crash.

[Gaia]

No crashes with Duron 950. I didn't disable anything but i used only b-frames, no QPel or GMC.

[tiki4]

Just a short question:

Is it now safe again to use the latest build of Koepi without QPel? The build from 1811 was said to be 'QPel only'.

Regards,

tiki4

[drebel]

Encoding+decoding probs here ...

Only by disabling MMX,int.SSE,3Dnow2! i can avoid crashes, with severe speed penalty which drops my Duron 1 GHZ to ~2 fps.

The decoding problem appears as huge black pixels aroung moving edges(no choppy playback though)and crashes ZoomPlayer 2.90 after a while.

All that with Qpel+GMC+Bframes enabled.Waiting a little longer(for other compilations) is definetely NOT a problem...;)

Should we switch back to 14/11 or this one will do the trick,as Tiki4 suggested ?

regards,
george

[Gaia]

I can confirm that if you use just b-frames everything works just fine. No crashing. I haven't tried QPel or GMC.

[glenn]

Perhaps it's worth giving it another go now;

20.11.2002 15:40:
U xvidcore/src/motion/motion_est.c (rev.1.44.) syskin:
- all qpel code rewritten
U xvidcore/src/motion/motion_est.h (rev.1.1.2) syskin:
- all qpel code rewritten

20.11.2002 20:20:
U xvidcore/src/decoder.c (rev.1.37.) Isibaar:
- bframe+qpel decoding support, bframe decoding bugfix, qpel interpolation speedup, bframe decoding speedup
U xvidcore/src/xvid.c (rev.1.33.) Isibaar:
- bframe+qpel decoding support, bframe decoding bugfix, qpel interpolation speedup, bframe decoding speedup
U xvidcore/src/image/interpolate8x8.c (rev.1.4.2) Isibaar:
- bframe+qpel decoding support, bframe decoding bugfix, qpel interpolation speedup, bframe decoding speedup
U xvidcore/src/image/interpolate8x8.h (rev.1.5.2) Isibaar:
- correct interpolate8x8_avg2 calls
U xvidcore/src/image/x86_asm/interpolate8x8_mmx.asm (rev.1.8.2) Isibaar:
- bframe+qpel decoding support, bframe decoding bugfix, qpel interpolation speedup, bframe decoding speedup
U xvidcore/src/motion/motion_est.c (rev.1.44.) Isibaar:
- bframe+qpel decoding support, bframe decoding bugfix, qpel interpolation speedup, bframe decoding speedup

I'm not at home, so I can't test, but... anyone else?

[MaTTeR]

Ran several tests with B-Frames alone and then with GMC and all worked perfectly, no crashes or artifacts.

Edit- Actually I did notice that scene changes seem to "flash" instead of being seemless now. I had never seen that happen before but it happens with B-Frames @ 2/150.

[iago]

Imho, latest developer build, XviD.Alpha.20.11.2002.2300.exe from uManiac's site, is absolutely great in terms of both quality and decoding! :)

After several tests with "b-frames 4/150/150", "b-frames 4/200/200", and "b-frames 4/200/200 + qpel" I started a full two pass encode of a rather difficult 121 min. movie with only "b-frames 4/200/200" (fourCC XviD, "Packed bitstream" and "DX50-BVOP compatibility" unchecked), aiming for 592500 kb (with 128 abr mp3 audio), BicubicResize(512,288,0,0.4) and together with UnDot() and UnFilter(-10,-10) in the script without any special credits treatment.

Second pass is to finish after some 5 or 6 hours, and I'll report back the complete results then, but as I can see from the debugview output, everything seems great atm! ;)

Many thanks to all developers of XviD one more time!

best regards,
iago

[celeron]

hi again i have test it the uManiac's build XviD.Alpha.20.11.2002.2300.exe Like Iago as sayd its beter, but for me the Qpel still produces some sh*ty frames but its faster 2 encode.
But again whit this build i cant play Bframe in virtualdub whitout being in slow motion (droping frames) i can decode good only whit ffdshow or xvid.ax from nick´s.
And no more crash in deconding.

Thks :)

[sysKin]

Hi,
Today's builds are much better because I found a lot of bugs and removed them. Expect more bugs to be found.

However, Koepi and I just discovered that GMC does something very wrong when combined with qpel and bframes. I never recommended using GMC (not in it's current state), now I recommend even less.

See ya,
Radek

[Koepi]

Just to agree with syskin:

XviD-21112002-1:
- Fresh CVS checkout. Plenty bugfixes and additions...
- Don't use GMC for now, it's buggy. The rest should work fine though.

But it was him who discovered that the GMC option caused the error, so all praise him :)

Best regards
Koepi

[Nic]

Well done the both you :D Hopefully ill be able to get back in the running...Im still not sure if the colorspace code is correct or its just my cr*ppy computer. Its works in RGB though & thats good enough to start releasing again ;)

-Nic

[celeron]

Hi again.

only 2 say that in XviD-21112002-1 all its good again nice speed good quality.
Both Bframes+Qpel or only Bframes, no more probs. whit decoding :)

Great work guys ;)

PS: about GMC i never use.

[scorchED]

could somebody explain us what "b-frame quantizer offset" is, please? what is the setting of 100 or 150 or 200 doing:confused:

[scorchED]

what i've done wrong?
i installed koepis new build 21112002 and tried to make an encode, but the first pass doesn't work. it doesn't matter whicj option i selected. VDubMod starts to encode, but only 1kb per sek is written and i get only a blanc "video" window. Quantizer Mode at Q2 work well with b-frames and qpel.
i tried to switch back to a working 14112002 built but the same problem occurs:eek:
i tried to disable all CPU optimizations, but this problem is still there.
does somebody have an explanation, whats wrong?

[MaTTeR]

scorchED,

Did you load the defaults and then try it?

[Koepi]

_first pass_ with defaults _discards the bitstream_ and just writes a statsfile.
Tht's a wished behaviour.

I don't understand the problem. Just look at the xvid settings panel, check that checkbox off and you'll end up with a >1GB avi after first pass.

EDIT: and with bframe offset... just point your mouse into the field and wait for the tooltip to show up. I've changed the formula how bframe quantizers are calculated:
Bframe quant= (((previous+future pframe quant)/2) * quant_ratio) + offset / 100

EDIT2: you got a preview in vdub before? Then you did a "full recompress" which converts the video into RGB space. So all your old encodes suffered serious quality degradation.

(it isn't the first of april, right?)

[scorchED]

thanks a lot!
i made the mistake to load the defaults after XviD installation and forget to uncheck "discard first pass". i stupid mistake i know:rolleyes:
i ever use fast recompress - i'm not soooo stupid, you guess me.
the first pass end up into a so small moviesize so i don't need a second pass mostly in 640x352 resolution, and the picture quality is fine.
i pointed the mouse over b-frame quantizer offset i read the text, but i didn't understand it really. maybe it's because of my english.
Could you explain it in this thread, what this option is doing, please?

[The Link]

Using b-frames with Koepi´s latest build the playback freezes from time to time (it hangs ~1sec and then goes on playing). It´s always the same if I use b-frames alone or with q-pel etc.
This only happens if I do not use ffdshow for decoding. I thought the already mentioned (in this forum) b-frame decoding issues got fixed. That´s why I want to report this.
Anyway the picture quality is greate even with b-frames.

Regards,

The Link

[Gaia]

Originally posted by The Link
Using b-frames with Koepi´s latest build the playback freezes from time to time (it hangs ~1sec and then goes on playing). It´s always the same if I use b-frames alone or with q-pel etc.
This only happens if I do not use ffdshow for decoding. I thought the already mentioned (in this forum) b-frame decoding issues got fixed. That´s why I want to report this.
Anyway the picture quality is greate even with b-frames.

Regards,

The Link I have seen this sometimes but i think it has nothing to do with Xvid.

[ErMaC]

Try turning down your Post Processing settings. With the DivX5 filter and B-Frames you will sometimes get this because that's how the codec deals with too much CPU usage. B-frames take more CPU than normal so if your system is just barely keeping up in the first place then b-frames will cause problems.

[The Link]

Yes, probably my PC (P3 667) is too slow for the XviD dshow filter. Since there´s nothing to change (or am I too dumb?) in XviD dshow filter I´ll just stick to ffdshow for decoding bframes.
I should think before I post ... sorry!

Regards

The Link

[vinetu]

@The Link :
Try the filter in first post here:
http://forum.doom9.org/showthread.php?s=&threadid=37800
(just copy over current xvid.ax file in %system% folder)
your CPU is fast enough...

[scorchED]

Nobody can explain in which way "b-frame quantizer offset" influence the quants of b-frames?
i start some encoding with parameters of 100 150 and 200.

[Koepi]

scorched, now you start to annoy me.

Let me quoe myself from my post above:
Bframe quant= (((previous+future pframe quant)/2) * quant_ratio) + offset / 100
PLEASE do some maths, test 1-2 values, and see what happens.

I won't explain the use of a calculator here.

This kind of ignorance really wastes my nerves. :(

(forum rule 4 comes to mind)

Koepi

[wotef]

nicht alle können wir gerade entlang erhalten? <-- google translation

- wonder if someone could explain to me, if i encode something and saturate the codec with 100% quantizer 2 --> is there any benefit of having b-frames? or not?

how comes if i encode (say a 250 frame video, and say i set a desired filezise of 1 gigabyte, with all default settings, except the b-frame control) 2-pass with b-frames but also an otherwise identical 2-pass with no b-frames --> resulting file is smaller with b-frames enabled?

[Koepi]

hm, dr. google miserably failed - that makes exactly... _non_ sense :) (did you mean "not everybody get's it straight away"? That could be a word-by-word translation.)

To your question:

If you saturate the codec without bframes at quant 2 (you aim for 1.1 GB and get e.g. 1.0999GB), then leave your hands off bframes. Bframe decoding takes more CPU power, your i-p-frame-only encode is watchable on even older computers.
But - you can set the bframe parameters that way that they (most likely) increase the filesize: e.g. quant ratio =< 100 and offset 1 (or offset=0).

I hope this helps.

Koepi

[wotef]

thanks, koepi, ok i think i'll leave b-frames alone for the moment :scared:

erm, heh, yes, my translation was "can't we just all get along?"

fyi, futurama season 2 dvd box-set is now available :D

[Teegedeck]

Originally posted by scorchED
Nobody can explain in which way "b-frame quantizer offset" influence the quants of b-frames?
i start some encoding with parameters of 100 150 and 200.

Well, I'm very bad at maths; but just for you I took pen and paper and tried to figure it out...

It seems to come down to this: If your B-frame quantizer ratio is just 100% and your B-frame quantizer offset is 100, too, your B-frame quantizer will simply be the average of the preceding and following P-frame +1. I.e. P-frame(quant3), B-frame(quant4), P-frame(quant3).
If you raise the offset to 200, the B-frame quantizer should come out (average of the preceding and following P-frame +2): P-frame(quant3), Bframe(quant5), P-frame(quant3).

If your B-frame quantizer ratio is higher than 100%, B-frame-quant won't be just P-frame-quant+1, it will rise exponentially the higher your P-frame quants are. Say, at B-frame quantizer ratio 150%, P-frames at quantizer 3 will trigger B-frames at (theoretically) quantizer 5.5, P-frame-quant 4 will trigger B-frame-quant 7 and this effect grows stronger, the higher you P-frame quant is and/or the higher your B-frame quantizer ratio is.

Basically, B-frame quantizer offset seems to me as a way of minimizing this exponential effect. Before it was there, B-frame quantizer ratios <200% seemed pretty ineffective to me - now 200% is definitely too much.

You might even try setting B-frame quantizer ratio to 100% and just use the offset, who knows if it looks better before someone tested it? All I wrote is purely theoretical, I haven't tested it at all. :rolleyes:

Please someone correct me if I'm wrong.

[The Link]

@vinetu

Thanks! I think that´s exactly what I need but unfortunately I can´t connect to the server. :(

[scorchED]

@Teegedeck
i am very pleased with your explaination.:rolleyes: i tried too explain it myself in this direction, but hadn't time to make some calculations.

[Didée]

Alas, I have to report major problems with the builds 20.11.2002.2300(insta-build), 20112002(koepi), 21112002(koepi).

Though everybody seems to be satisfied (In particular, I wonder because Iago reported outstanding quality), for me the combination of B-frames & QuarterPel with these builds is unusable.
I get very annoying blocks popping around all over the frame, in sequences where B-frames are used. I have attached a very short avi clip that shows this problem. It is very ugly compressed (only for attaching here), but shows the problem still very well. The effect is the same even with constant quant=2.

It's not a decoding problem - ffdshow, xvid.ax, Vdub, all show the same.

As soon as I switch off qpel, the encoding is fine.
To be on the safe side, I uninstalled XviD, rebooted, and installed again. No change.

However, the special build koepi had on his side a few day ago (the one that was for B+qpel ONLY, with ?one special block-type? disabled), is the only build that works fine for me with B+qpel together. Therefore, I assume that the problem with this one block-type still isn't really resolved in the latest builds.

Nobody experienced this problem up to now? I can't believe ...

<attached: snip_avi.zip, 85kB>

[JimiK]

Yes, I also experienced this problem. I didn't mind too much because I normally don't use QPel. But of course this seems to be a bug and should be reported.
I've also got some problems without QPel, using Koepis 21112002-1 build. Codec was set to 4 consecutiv Bframes max, ratio and offset to 200%. The avs-script looks good in VDub and for encoding I used AVS2Avi. It's not an dshow problem, because it also shows in VDub in the encoded movie. Now the problem is that I cannot reproduce this, it occurs somewhat randomly. In one short encode it appeared and in the next with the same settings it was gone. But I've got many of those frames in the movie. I cannot explain how it looks, so just wait until the attachment is confirmed.
Still it's great how fast development is going on. In a way, wouldn't it be boring if everything would work from the start? :) Thanks to everybody who's involved in developing or testing.
Best regards,
JimiK

[JimiK]

this one looks weird

[Shayne]

I to have found nov 21 bug, Shoot quality is good but flashes like this make it impossible.

Qpel and Bframes 3 150

Divx 3 macro blocks is what it reminds me of

[SleepEXE]

Didée, I downloaded your sample clip and can see the artifacting in Media Player manifested as shimmering in the man's hair, and a "dirt trail" as he turns his head. But if I open it in VirtualDub where the VFW codec is used, the artifacts aren't present. I imported it into Vdub with AviSynth's DirectShowSource and the artifacts reappeared. I checked my ffdshow settings and noticed I had it set so that ffdshow handles all rendering. When I set the option "Decode using XviD", the artifacts disappeared again.

For me, these errors appear to be specific to ffdshow. Are you guys seeing something different?

I have Umaniac's Nov 20 23:00 build installed.

A curious sidenote, I had an instance a few days ago of gross block errors (like the "dirt trail" from the man's head) on a HuffYUV capture encoded with Koepi's 20021004 build. No B-frames or QPEL were used. That was the first time I have ever seen that with the XviD codec in the 11 months I've been using it, comprising some 200+ encodings. And I can't assert that it had anything to do with Koepi's 20021004 build since I've used it quite a bit (probably 30 jobs) and haven't seen the problem before. I had already discarded the source material so I couldn't test reproducing it.

This behavior actually has me a bit concerned because I often don't watch the material until long after I've discarded the source. Months of use have conditioned me to take for granted that the XviD codec won't "allow" these gross block errors. I use what are generally regarded as safe, well-tested settings...among them, not restricting the codec with extreme limits and always keeping the second pass bitrate at about 60% of the first so as not to starve the codec.

Best regards,
SleepEXE

[HarryM]

Use only qpel or b-frames, don't b-frames + qpel, don't GMC.

[JimiK]

I did a few tests and it could be that my problem (colorful macroblocks) could be related to AVS2Avi. At least in my VDub encodes I never saw those blocks. With AVS2Avi 1.15 I could "produce" blocks in different test, but in different places, although I always used the same settings. That does not mean that I'd guarantee there are no blocks with VDub. And a question to the XviD developers: is XviD deterministic? Why do I get with the same settings different sizes (only 1kb or 2kb off)? Is this a problem of Avisynth and its filters or is it an XviD "problem"? That I get a size of 10005kb in the first encode and 10006kb in the second means they're not the same, right?
Best regards,
JimiK
P.S. This is not meant as critics, but only as a bug report. And maybe it has nothing to do with XviD.

[Didée]

BTW, JimiK,

about your settings:Originally posted by JimiK
Codec was set to 4 consecutiv Bframes max, ratio and offset to 200%
Seems like a little overkill, at least for my taste.

Are you aware that these settings produce

P-quant = 2 --> B-quant = 6
P-quant = 3 --> B-quant = 8
P-quant = 4 --> B-quant = 10

Not that these high B-quants should produce the defects you showed in your screenshots, no.
But I simply think that 4-200-200 is kind of "brute-force" (quantizer at 6 where the codec tries to produce its very best quality, wohoo!).

These are not your settings for final encodings, are they?

[JimiK]

Yes, you're right. Iago wrote that he did tests with 150-150 and with 200-200 and then used the latter for his encode. But I already switched to offset:100, ratio: 150.
P-quant=2 --> B-quant=4
P-quant=3 --> B-quant=5 or 6?
P-quant=4 --> B-quant=7
Maybe that's a to conservative setting. I'm trying to get 4 ST-TNG episodes on 1CD, using 2 audio tracks, each episode 40 mins, size 480x360. So there is some compression to do. I reencoded the episode with the errors again in VDub and now they're gone. Seems really to be an AVS2Avi problem. Perhaps it has something to do with the B-frame handling that DaveEL mentioned.

Best regards,
JimiK

[HomiE FR]

Hi all!
I had some undersize problems while encoding LOTR on a 800MB CD, so I thought this would be interesting to post something to see what Koepi or any other XviD tester or developer thinks of that :
(if the post seems to long, just look at the end. I think that there is a problem between B-frames and alt-cc)

The Lord of the Rings - The Fellowship of the Ring (standard version)
DVD Zone 2 (PAL 25fps)

Software used to rip the DVD :
1. SmartRipper 2.41
2. DVD2AVI 1.76
3. Avisynth 2.07
4. VirtualDub 1.4.10 (Fast recompress)

Avisynth script used :
LoadPlugin("C:\Program Files\Video\Avisynth 2.07\MPEG2Dec.dll")
Clip=MPEG2Source("D:\DVD\LOTR\vts_01.d2v")
Start=trim(Clip,0,1315).Crop(0,79,720,418).BilinearResize(720,304)
Movie=trim(Clip,1316,245539).Crop(0,79,720,418).LanczosResize(720,304)
Credits=trim(Clip,245540,256596).Crop(0,79,720,418).BilinearResize(720,304)
Return Start+Movie+Credits

XviD settings (Koepi 21-11-2002-1 ALPHA) :

Global settings :
Motion search precision : 6 - Ultra High
Quantization type : H263
FourCC used : XVID
Maximum I-frame interval : 300
Minimum I-frame interval : 1
Enable lumi masking : OFF
Enable interlacing : OFF
Quarterpel : OFF
Enable greyscale : OFF
Use chroma motion : OFF
Global Motion Compensation : OFF

B-frames control :
Maximum B-frames : 2
B-frame quantizer ratio (%) : 150
B-frame quantizer offset (%) : 100
Packed bitstream : OFF
DX50 B-VOP compatibility : ON
Enable debug info on each frame : OFF

Quantization :
Min I-frame quantizer : 2
Max I-frame quantizer : 6
Min P-frame quantizer : 2
Max P-frame quantizer : 16

Two-pass tuning :
I-frame boost (%) : 0
Discard first pass : ON
Dummy 2nd pass : OFF
Below I-frame distance (frames) : 10
I-frame bitrate reduction (%) : 30

Hinted ME : OFF

Alternative curve compression :
Use alternative curve system : ON
Curve aggression : Medium
High distance from average (%) : 450
Low distance from average (%) : 100
Enable automatic minimum relative quality : ON
Strength (%) : 30
Enable automatic bonus bias calculation : ON

Max bitrate (Kilobit/s) : 10000
Max overflow improvement (%) : 60
Max overflow degradation (%) : 60

Credits :
Credits at end of movie : ON
Credits start at frame no. :
Credits end at frame no. :

Credits rate reduction :
I-frame quantizer : 16
P-frame quantizer : 16

2nd pass results :
Desired size : 749777 KBytes
Final size : 724196 KBytes -> 25581 KBytes undersize !!!

First I thought this could have been caused by the credits (I don't know why I thought about that but nevermind), so I compressed the credits separately. And I launched another 2-pass encode without the credits. The rest of the XviD options is totally the same : only there is no credits.

2nd pass results :
Desired size : 736591 KBytes
Final size : 711026 KBytes -> 25565 Kbytes undersize !!!

So the problem is still here, but I was stupid to think that the credits could have been the cause because the codec just take the size of the credits after the first pass (encoded with the quantizers at 16 like I set them) and then encodes the rest of the film with a size equal to the desired size - the size of the credits. So the credits are not responsible.
But I think now that the alt-curve could really be the responsible. I can't understand why, but maybe this curve compression doesn't support the B-frames yet (if this is obvious I'm sorry but I didn't know that). I'll do the same encode with the credits and with a linear scaling, and then with a "standard" curve compression, just to see if I'm right.

So just a question : does the alternative curve compression support B-frames yet ? Or is it totally normal to have such undersizes with this curve system ? I looked at DebugView during the encodes and I especially looked at the overview. I didn't see anything special, it seems that the codec did his job normally according to what was left in the overflow (just a few kbytes) but there is this huge 25000kbytes undersize. That's why I think that alt-cc doesn't support B-frames yet.

[scorchED]

i read somewhere in this forum that alt-cc has problems with predicting filesize when b-frames are used. so use only normal curve compression.

[iago]

Originally posted by Didée
Though everybody seems to be satisfied (In particular, I wonder because Iago reported outstanding quality), for me the combination of B-frames & QuarterPel with these builds is unusable.
@Didée

I didn't report outstanding quality, I just reported that "b-frames" and "qpel + b-frames" _worked well_ (based on only short test results as was stated) with uManiac's latest dev. build.

edit:

However, I can say that only "b-frames" ("Packed bitstream" unchecked / "DX50 B-VOP Compatibility" checked or unchecked) with the latest dev. builds (both Koepi's and uManiac's) have been working fine for me.

Also, since I've always had some problems when qpel activated (dunno why, perhaps due to "qpel", perhaps due to the combination of "b-frames + qpel", perhaps due to my system), I keep my hands off everything except b-frames for the time being.

regards,
iago

[Bulletproof]

For me with koepi's build I can only use B-frames. If I enable only Q-pel with default settings, quantizer at 2, I get smearing effects and that's with B-frames off.

[iago]

@Bulletproof

I agree that smearing effect is very visible whenever qpel is turned on (alone or with b-frames).

iago

[ookzDVD]

@Koepi,
Talking about B-frame offset, do you know the "internal" value before it become visible (as parameter) ?

Second, is your stable build 04102002 support YV12 ?

@Forum,
Is it save to use MPEG-Custom with B-frame ?

Thank you.

[Foxer]

Originally posted by scorchEDi read somewhere in this forum that alt-cc has problems with predicting filesize when b-frames are used. so use only normal curve compression. I included b-frame curve compression code in both normal cc and alt-cc portions of the size prediction correction code so alt-cc doesn't have any problems normal cc doesn't have. heh

[Koepi]

Heh, as usual, it's the secret of tweaking AltCC correctly I guess ;)

Ah, xvid-04102002-1 unfortunately doesn't support YV12-decoding.

Btw....:
XviD-25112002-1:
- Fresh CVS checkout. Major & minor bframe bugfixes.

Iago, you may want to check with qpel again... those trails/smearing effects could've been caused by some buggy bframe code (never mix up x and y ;) ).

Enjoy!

Regards
Koepi

EDIT: I forgot to mention that this build includes ReferenceDivX' great lumi masking code, based upon HVS. This means great quality even at high quantization levels, and much less blocking in dark areas. You should definatly give it a shot, it's working amazingly good!

[HarryM]

Originally posted by iago
@Bulletproof

I agree that smearing effect is very visible whenever qpel is turned on (alone or with b-frames).

iago

When you use much higher compressibility (65%-75%), you eliminate smearing effect.

[Foxer]

@koepi

Hmm? Secret of tweaking AltCC correctly?
Tweaking CC doesn't change size prediction's targetted size and so, should affect the resulting filesize very very little.

[Koepi]

@Foxer:

You _can_ get an impact on size predictability with AltCC, i.e.:

Agression: low
High distance: 500
Low distance: 500

in a high action movie ;)

I hope you get the idea - I just meant that with "wrong" settings you can get a different filesize as desired.

Best regards
Koepi

[iago]

Originally posted by Koepi
... XviD-25112002-1:
- Fresh CVS checkout. Major & minor bframe bugfixes.

Iago, you may want to check with qpel again... those trails/smearing effects could've been caused by some buggy bframe code (never mix up x and y ;) )

I forgot to mention that this build includes ReferenceDivX' great lumi masking code, based upon HVS. This means great quality even at high quantization levels, and much less blocking in dark areas. You should definatly give it a shot, it's working amazingly good! @Koepi,

Yes, my friend, absolutely I will try the new build right away! Especially, I'm looking forward to see the results of the new lumi-masking code!

best regards and thanks for the new binary,
iago

[Koepi]

@iago,

I'm looking forward to hear your oppinion dostum! :)

Serefe,
Koepi

[HomiE FR]

Foxer and Koepi : Sorry to bother you again about my problem but my alt-CC settings have not been set by "instinct". If you look at the settings I put :
High distance : 450 % (there is less than 1% higher than this point and the max distance within the movie was +1010%)
Low distance : 100 % (about 50% of the frames are between -50% and -100%).
Curve aggression : Medium (Koepi said it was the best choice in most cases just a few days ago if I remember right)

So I think these settings are totally safe.
Moreover I really can't understand when Koepi talks about 300 in low distance... I personally think that frames can't have a negative amount of bits (even frame dropping isn't enough :) ) and I thought that 100 in low distance already put the limit at 0 bytes for a frame (average frame size - 100% * average frame size). So setting the low distance above 100 just puts it to 100 I think... When Koepi's joking you have to think to understand the joke! :p

So now I've done the same encode with the same settings, except I chose a standard curve compression with default settings (high bitrate : 25% - low bitrate : 10% - payback delay : 250 frames) and there isn't any filesize problem !
Desired file size : 749777 Kbytes
Total file size : 749890 Kbytes (113 KBytes oversize)

So I do go on thinking that there might be a problem with B-frames in alternative curve system. I don't think LOTR is a "special" movie, so I'll try the same thing with other movies to be sure it's not caused by the source, but this is highly unprobable I believe.

[Sofus]

Hello Koepi

Just did some testing with the new build XviD-25112002-1
ReferenceDivX' new lumi masking code seem to work fine with out B-frames
With B-frames it generates lots of rough pixels, both with and without Qpel.

Settings:

Croma motion = off
GMC = off

Maximum B-frames = 3
B-frame quan. ratio = 150
B-frame quan. offset = 100
Packed bitstream = on
DX50 B-VOP com. = on

Sofus :)

[Teegedeck]

As we seem to be discussing new lumi-masking here, I've moved my original post.

We have a problem with lumi-masking and contrasts, now. :(
Apart from that, the new version is absolutely OK for me.

Some out-of-place pixels, typically white pixels in grey areas and vice-versa, not only on the edges, watch the upper-left area.

Koepi's build, H.263, constant quant=2, no B-frames, no GMC, no quarterpel.

[Sofus]

Update !

The rough pixels seen, when enabling b-frames and the new lumi masking code, seems to come from way to small file size.

Lumi masking on
B-frames off
14.1MB

Lumi masking on
B-frames on
1.36MB

Sofus

[Shayne]

@Koepi Is this correct would like to hear your response to the strange artifacts people have posted here.

Originally posted by HarryM
Use only qpel or b-frames, don't b-frames + qpel, don't GMC.

[Koepi]

I'm currently testing if those problems are solved with the correction of the x+y-mixup.

Regards
Koepi

[celeron]

well i made some tests whit this new build and the trails/smearing effect in the use of bframes+qpel its gone(well i dont see it).
But the new lumi masking in my test work very well the only prob. i see whit that its in decode, the sample plays a little slow but whit xvid.dll or ffdshow.

PS: sorry very bad english

here its a shot whit bframes(3/150/100)+chroma motion+lumi masking.

http://pwp.netcabo.pt/celeron/bf-lm-cm.jpg

And another one this time whit Bframes(3/150/100)+Qpel

http://pwp.netcabo.pt/celeron/bfqp.jpg

[NoLogo]

@Koepi

Has the code for Hinted Motion Vectors been modified in the recent releases ? Because i made some tests, particularly two: classic encode (without any special or exotic options) and the same with HMV (and only HMV) and the results are quite... dissapointing.
The first one had quant from 2 to 8 (average quant about 4.5) and the second one (HMV)... it's really nasty: quant from 2 to 21 (average quant about 11). And there's no use to see what DebugVeiw shows to realize how poor the quality is: big macroblocs everywhere.
So, maybe it's a bug, maybe it was so earlier, maybe it's my system, but i already used HMV with older builds (yours from april or may, don't exactly remember), and it was much better than it is right now.

NoLogo

PS: If you want, I can find a way to give you some short parts of both files (with and without HMV), so that you can exactly see what i mean by "nasty".

[Foxer]

@HomiE FR

I just tracked down the undersizing problem..

I had accidentally missplaced a b-frame equation in the CC application code for altcc.. :rolleyes:

The fix should find it's way into the cvs sooner or later.

[NoLogo]

@Foxer

Does this bug have any influence on the first pass ? That is to say, do I have to stop my first pass after 12 hours, or can I let it run till it's over ?

NoLogo

[serbersan]

With the last stable Koepi 04102002 Build to use internal linear scaling we had to disable alt cc and put :
high bitrate scenes % -> 0 &
low bitrate scenes % -> 0

With the lastest dev builds to enable internal linear scaling Could I use the same trick? I mean this has changed?

I'm not using any new features only taking advantage of the YU12 compression speed.

EDIT: I've read in releases notes:

This dev-api-3 binary is most likely not producing standard conform bitstreams when some of the newer features are used, keep that in mind!

Without any new features those dev-api-3 builds are safe to use in quality and conform bitstreams? I don't know if the modifications in code are only in new features code or could affect more things. Sorry for my ignorance. At least in my last encode without new features and 21112002 all was fine. I could decode it with the lastest stable decoder (04102002).

[Foxer]

@NoLogo

Nope :) It only affects the second pass.

[HomiE FR]

@Foxer : Thanks ! I'm always happy to be useful. I find the alt-CC much smarter than the standard CC, so I was quite disappointed to see these huge undersizes...

[ErMaC]

I too can corroberate the undersizing problem in the Alt CC usage. Just did a test with both targetting same filesize (230something megs, it's an anime episode) and normal CC hit it almost dead on, AltCC was undersized by 5MB. Build was Koepi's 25112002-1 and only exotic options were b-frames 3/150/100 and chroma estimation - no masking or anything else.
I look forward to a new build - so far uManiac hasn't had a new build and Koepi's last one is the 25th (which is only like yesterday, gosh that's SO OLD! :D)
Huzzah for the bleeding edge.

[kilg0r3]

@ ermac

did you make any comparisons between enabling/disabling chroma motion? What are the effects?

[ErMaC]

I haven't been testing it personally, I just went ahead and turned it on. I don't really care about the encoding speed - I only care about final quality. From previous threads about it, which have said it will improve the ME on animation, I figure it can't hurt the matter and so I turned it on. My 1st passes all look damn perfect. ^_^
I will run another first pass with Chroma ME turned off but with same settings otherwise and let you know if there's a change in filesize. From what I understood of the explanation, if the motion estimation is worse it'll take more bits to fit the same data so we would see a filesize difference.
Koepi et al: If my information is wrong please let me know. ^_^
I will set up the encode now and check it in the morning.

[serbersan]

@kilg0r3

I've made a rip of killerJoy a 70 minutes movie and in the first pass
the difference between use chroma estimation or not was 1Mb. And yes I had made 2 first passes the only difference between them in parameters was than one has enable chroma estimation and the other not.

The first pass was over 1000Mb

[kilg0r3]

that does not seem to be much of a difference regarding filesize, but, is there a gain in visual quality

[Koepi]

Yes, there is a huge improvement: it meakes blocking nearly impossible (well, with bframes and high quantization there is _of course_ blocking in i.e. smoke, but that isn't what I'm talking about here). Walls etc. look better with chroma me.

Regards
Koepi

[NoLogo]

@Koepi

Have you seen what I said about hinted vectors a few posts above ? Is it a bug or does it come from my system ?

Regards
NoLogo

[Koepi]

MVhints are broken for several weeks now :(

Maybe sysKin spends some time on that later, but it isn't top priority at all ...

Best regards
Koepi

[iago]

@Koepi and all,

After several constant quant 2 tests with the 25112002-1 binary, I still get the annoying smearing effect with "qpel" (though not in all test clips), which somehow becomes less visible when using "qpel + b-frames" (ffdshow 13/11 libavcodec for decoding).

As for the b-frames alone (4/150/100), imho it's literally great in terms of quality and compressibility gain! Also, using mpeg and h263 quantization types with b-frames gave me different results and different filesizes, which is a good sign, too, I believe ;).

I still prefer and find safer to use only b-frames at the moment.

best regards,
iago

[Koepi]

@iago:

thanks for the report.
I have a local build (maybe i'll put it online?) which even handles custom quant matrices again... Unfortunately I think I know what you mean by "smearing effect", but I don't think it looks too bad - it's just a little strange .) (like a temporal smoother on moving objects?)

Serefe dostum!

Best regards,
Koepi

[Didée]

About the smearing effect

Personally, I didn't experience that up to now with koepi's 25112002.

But, a friend tried to encode TombRaider with this build, and in the beginning sequence (spinning wheels, lots of information is coming into the frame from outside the top border, plus the sequence is pretty dimish/dark), very strong smearing appeared.
I don't know the exact settings - but Bframes 4-150-100 + qpel was used, no filters at all but cropping & resizing, processing in YUV2.

<EDIT> Deleted some misinformation the friend told me

[iago]

@Koepi

It's nice to hear that a new build (handling custom matrices too) is on the way! ;) Well, actually I don't know what to call this effect (smearing?) with "qpel", but on some sources I get it on flat surfaces such as sky, walls, etc., especially when there is also some sort of motion in the scene. Yep, it resembles the effect of (heavy?) temporal smoothing I guess.

Looking forward to the new build! ;)

take care my friend, ;)
iago


Edit: Btw, I forgot to mention that "qpel + b-frames" helps compressibility gain a lot, resulting in even more compressibility than b-frames alone and great visual quality (except for the "smearing effect" of course!). ;)

[NoLogo]

@Koepi or any developpers

After a first pass done with a given build (Umaniac's 20112002 one, in my case), using BF and only BF (3/200/150, DX5), is it possible to re-use that 1st pass with a more recent build and same options or do I have to keep the same build (or redo first pass) ?
I know it's not possible to make a second pass with different options but same build, but is it (or theorically is - or maybe if I'm lucky :)) with same options but different build ?
Because Foxer told me that any change in altCC wouldn't be a pb (as it affects on second pass only), but maybe there can be other, not viewable, changes.

PS: I didn't know for hints ME, hadn't used them for a while before my tests. But anything else (especially BF is real good: didn't know Mulholland Drive at 522kB/s could be so nice :)) is great.

Thx for everything

Regards
NoLogo

[Koepi]

Hm, there were changes in the ME routines affecting compressability, thus you need to do a full 2pass again, sorry for the bad news :-/

Regards
Koepi

PS: @iago, hehe, bframes+qpel+gmc+chroma me+lumi masking are my favorites ATM, I have 1st pass of 5th element down to 1.3GB with an amazing quality :)
(btw., i prefer 3/100/200...)

[NoLogo]

@Koepi

Ok, I hope then that I won't have any oversize... :(
One more question: do you consider that the really recent improvements (compared to the Umaniacs 20112002) really worth the try ? I mean, would you give up a 22 hours first pass, to re-make it with your new build ?

About Qpel or CM, I had tried them, but get strange "slipping colors" effects; I still consider these options as "really exotic", whereas BF... oh lovely BF !... :)

Regards
NoLogo

[HarryM]

Originally posted by NoLogo
@Koepi

Ok, I hope then that I won't have any oversize... :(
One more question: do you consider that the really recent improvements (compared to the Umaniacs 20112002) really worth the try ? I mean, would you give up a 22 hours first pass, to re-make it with your new build ?

About Qpel or CM, I had tried them, but get strange "slipping colors" effects; I still consider these options as "really exotic", whereas BF... oh lovely BF !... :)

Regards
NoLogo


I think, that you can use (without big risk) 1st pass from older build. My experiences are, that deviations are very little, practically unvisible!

[sysKin]

Originally posted by NoLogo
[B]One more question: do you consider that the really recent improvements (compared to the Umaniacs 20112002) really worth the try ? I mean, would you give up a 22 hours first pass, to re-make it with your new build ?Koepi knows how things work in 2-pass encoding, so he's very strict about using exactly the same settings etc for both passes. However, I noticed that it's even safe to change quant type from one pass to another and still have both correct size and quantizer distribution. I never tried this, but I think I'm going to make first pass with motion precision 5 and no CM, second with 6 and CM. I _bet_ it will work great.
About Qpel or CM, I had tried them, but get strange "slipping colors" effects; I still consider these options as "really exotic", whereas BF... oh lovely BF !... :)CM is a safe thing. It only extends motion estimation procedure, so it's just motion precision 7. It can't produce wrong bitstream.

Best regards,
Radek

[NoLogo]

@HarryM & sysKin

Thx guys, this reassures me :) but I guess it's a no-no tu add QPel or GMC only in the second pass, right ? Maybe I'll give a look at the new build.

@sysKin

About your .dll, are they for developpers only, or can they safely be used for testings ?
Sorry for saying CM was "exotic", actually you're right: the problem with "slipping colors" only occured with GMC; the fact is that CM, when I tried it, did nothing: nor size neither quant changes. But maybe this has changed in the new build (after 20112002).

Regards
NoLogo

[Boardlord]

@Nic

Hi Nic! I absuletely love your Dshow filter for XviD, but now it seems that there is a bug in it. I used your newest (from 11/25) filter to watch a film, but DirectVobsub (2.20) didn't show the subtitles. Whenever I seeked, I saw the subs for a split second, than they vanished again. DirectVobsub works with ffdshow, but your postprocessing method is broken in it right now.

Thanks 1000x!!

[Snakeisthestuff]

Hi i have tested koepi's 25112002 build yesterday at an anime source
with bframes (8 bframes 200/150) + qpel and got very good results, but i noticed that koepies xvid.ax, the bframes not correct decoded, there seams to be an affect like an dropped key-frame at severall times, ffdshow 13112002 decodes it well. the b-frames increases the compressabelity a lot but i noticed this smear effect iago is talking about too, i think 8 bframes are maybe too much, but for an anime this smearing is not so bad how for an other movie :)

thx alot for this great build koepi :D

[ErMaC]

OK For those interested, here's status on my encodes:

Galaxy Angel 3rd Epsiode 1-2, 24:55 long
First pass, with Chroma ME: 355,174,400
First pass, w/o Chroma ME: 362,952,704

That's 338MB vs. 346MB, a fairly substantial difference. They both subjectively look the same to me, I think of course the smaller filesize comes from more accurate motion estimation meaning less bits needed to compress the same thing.
I suspect the reason this test was so positive was because it was done on animation (very clean digital one, too).

I'm also of the opinion that now b-frames are good enough for primetime, but I'm still keeping away from Qpel and GMC until they're more mature.

[iago]

... @iago, hehe, bframes+qpel+gmc+chroma me+lumi masking are my favorites ATM, I have 1st pass of 5th element down to 1.3GB with an amazing quality ...

@Koepi,

All are OK imho, except GMC for the time being! ;) I got terrible color artifacts with it in my Indian Runner encode.

If you only knew what kinda scripts I've been trying for a while for 1CD encodes with LanczosResize and 0.400q vorbis audio! :D (Pardon, did you call me crazy?! ;))

However, I'm sure we'll achieve that soon with a reasonable resizing of minimum 576*... and "b-frames + qpel + cm + a good lumi masking algo and custom matrices + the proper use of certain avisynth filters"! ;)

Since I _know_ that LanczosResize is _the_ resizing method, ogg vorbis (at ~128 Kbps) is _the_ audio (for 1CD), and XviD is _the_ codec!

þerefe dostum! ;)

and best regards to all,
iago

[Koepi]

@iago:

i had _no_ problems watching those movies with the latest pre-p4-optimizations ffdshow :)

Ah, well, the problem may be: I've a local build that differs from the public build... i wanted to see the results with 5th Element before i put it online.

It seemed to work flawless (in a previous version I have to admit) with "kiss of the dragon", but I thought it would be nice testing the functionality before giving it to the public, it's really disturbing getting useless bug-reports for things that are known to happen.

(No offense in this, it's just something like quality-assurance).

*hicks*

To the next drinks... þerefe!

Koepi

[NoLogo]

@iago

Of course you use Convolution3d, do you ? :)
God bless highly compressible movies.

@Koepi

If you want, I can make test series on my poor computer, running 24 hours a day, 168 hours a week. :D

Regards
NoLogo

[lighty]

Originally posted by Koepi
bframes+qpel+gmc+chroma me+lumi masking are my favorites ATM, I have 1st pass of 5th element down to 1.3GB with an amazing quality :)
(btw., i prefer 3/100/200...)

Just to report that I just finished encoding with almost the same settings: bframes+qpel+chroma me+lumi masking+AltCC-Medium

The results are GREAT. I mannaged to finaly encode some movies I had problems with in the past. That and the fact that trbarry provided TomsMoCompYV12 and Marc FD mpeg2dec3YV12 makes me a very happy puppy. Thx to all ppl involved!:cool: :cool: :cool:

[kilg0r3]

um, i have got a problem here with the latest koepi dev build

i shifting blocks before keyframes. here (http://www.mynetcologne.de/~nc-allgeife8/blocks-683KB.rar) are some screen shots from a clip i encoded recently. For this one i only used bframes (3/150/0 or 100 not sure) without DX50 compatibility this phenomenon occurs before scene changes and is visible in vdub, mplayer+ffdshow, mplayer+xvidDec. it occurs in avi container as wellas ogm. the avi was a created from the ogm though.

The screen shots are taken with virtualdubmod.

i hope i am not repeating something already mentioned here. If so, please tell me.


ok stupid me, DX Vop compatibility seems to fix this. Is this a known issue?

[Rrrough]

DX Vop compatibility seems to fix this. Is this a known issue? AFAIK switching off DivX-compatibility means that you'll get b-frames which are related to the following I-frame. DivX doesn't do that, its bframes are correlated only to P-frames. I guess I-frame related bframes are ISO-compliant, but no decoder is supporting it. thus you can't play your file without these huge shifting blocks (just like here, always before keyframes) and it's recommended to always switch on DivX-compatibility for the moment.
please correct me if I'm wrong here.

cheers

[lighty]

Originally posted by Rrrough
I guess I-frame related bframes are ISO-compliant, but no decoder is supporting it. thus you can't play your file without these huge shifting blocks (just like here, always before keyframes) and it's recommended to always switch on DivX-compatibility for the moment.

I don't experience any of the probs you talk about and I don't use DX compatibility? BTW- I use FFDshow.

[Rrrough]

well, I haven't tried with the latest ffdshow version, maybe it's "solved" now, but I guess kilg0r3 tried with latest !?

[jpl]

My settings are for B-frames are

packed bitstream = on
divx compatibility = off

and I have no problems either (using ffdshow)

[kilg0r3]

the problem is not ffdshow related. as i said, it appered with ffdshow and the with the standalone xvid decoder. yet, most importantly it also shows in vdub which uses the xvid.dll and not the directshow filter (no divx installed on my system).

@jpl
i though packed bitstream was still buggy ..
:confused: i don't have enough time to keep up with the changes of status of the xvid features, it seems. :(

BTW is the 'smearing' issue with qpel resolved now?

[iago]

Movie length: ~120min.
Audio: 0.700q ogg
Video size: 558000 kb
700 mb 1CD encode

encoding parameters:
--------------------
XviD 25112002-1 / b-frames 4-150-100 - FourCC: DX50 - DX50 B-VOP Compatibility / h263 / chroma motion / lumi masking / internal linear scaling

script:
-------
LoadPlugin("C:\FILTERS-YV12\MPEG2Dec3.dll")
LoadPlugin("C:\FILTERS-YV12\DctFilter.dll")
LoadPlugin("C:\FILTERS-YV12\UnFilter.dll")
mpeg2source("D:\GHOSTDOG\GHOSTDOG.d2v",cpu2="ooooxx")
crop(2,16,-2,-16)
LanczosResize(576,304)
LumaFilter(-2)
UnFilter(-10,-10)
DctFilter(1,1,1,1,.7,.4,.4,0)

Results: Great and no A/V synch. problems!

best regards ;),
iago

[DBaT]

Iago:
Good to know your 2h movie turned out ok.

I'm trying to get a 2h 4:3 movie on one cd with decent picture. I'm not there yet but while I learn every weeks something new and new xvid builds and avisynth filters turn up every week I'll have atleast hope.

I made some short quant2 tests with b-frame to see what different b-frame settings would do to file size:

test1 no b-frame -1 21118KB
test2 b-frame 2 150,100 16630KB
test3 b-frame 2 200,100 15904KB
test4 b-frame 2 200,200 15528KB
test5 b-frame 2 200,300 15266KB
test6 b-frame 2 300,200 15082KB
test7 b-frame 2 300,300 14934KB

test8 b-frame 3 150,100 16552KB
test9 b-frame 3 200,200 15384KB
test10 b-frame 3 200,300 15098KB
test11 b-frame 3 300,200 14906KB
test12 b-frame 3 300,300 14746KB
test13 b-frame 4 300,300 14758KB

[NoLogo]

Movie length: 2h20
Audio: 2 x Ogg q1.5
Video: Xvid 537598kB (500kBs) 720x384
700 MB 1CD encode

Encoding parameters:
--------------------

XviD 20112002U / BF-3-200-150 - FourCC: XviD - DX50 B-VOP Compatibility - MSP:6 - MPEG.

Script:
-------

LoadPlugin("E:\Rippage\Progz\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("E:\Rippage\Progz\GORDIA~1\Convolution3d.dll")
mpeg2source("E:\Rippage\Ripp\D2vz\muholland_drive.d2v",lumoff=20)
Convolution3D(preset="movieHQ")
crop(0,8,720,560)
trim(0,204900).BicubicResize(720,384,0,0.5)+trim(204901,0).BilinearResize(720,384)

The results are amazing at such a Bitrate, it almost do not need any post-proc...:eek:
The movie may be highly compressible, I wasn't sure I could have done it... but it's done :D

Here a few stats:
-----------------

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 6671 Times, Percentage Used : 10.33%
Quant 3 Used : 50599 Times, Percentage Used : 78.35%
Quant 4 Used : 7196 Times, Percentage Used : 11.14%
Quant 5 Used : 109 Times, Percentage Used : 0.17%
Quant 6 Used : 8 Times, Percentage Used : 0.01%
Quant 7 Used : 1 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.012

MPEG Quantization Type Used 210856 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 20 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 1038 Times, Percentage Used : 0.72%
Quant 3 Used : 45 Times, Percentage Used : 0.03%
Quant 4 Used : 28 Times, Percentage Used : 0.02%


Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 5633 Times, Percentage Used : 8.52%
Quant 3 Used : 50554 Times, Percentage Used : 76.46%
Quant 4 Used : 7168 Times, Percentage Used : 10.84%
Quant 5 Used : 109 Times, Percentage Used : 0.16%
Quant 6 Used : 8 Times, Percentage Used : 0.01%
Quant 7 Used : 1 Times, Percentage Used : 0.00%


Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 144708
Number Of Inter-Frames (P-Frames) : 66141
Total Number Of Frames : 210849

68.63% of the Movie is Intra-Frames (Key-Frames)
31.37% of the Movie is Inter-Frames (P-Frames)


Size Analysis
----------------

1-Pass Size : 634188174 Bytes or 619324 KBytes or 604 MBytes
Scaled Size : 418319040 Bytes or 408514 KBytes or 398 MBytes
Actual Size : 335431105 Bytes or 327569 KBytes or 319 MBytes
Actual Size of Avi File without Sound : 340603904 Bytes or 332621 KBytes or 324 MBytes

Usefull Statistics
------------------
Compressibility : 52.89%
Relative Quality of XviD avi : 66.40%
Absolute Quality of XviD avi : 96.96%



BF are definitely not dev anymore, I think this could be a root option.

Thanx a lot to all developpers.

Regards
NoLogo

[mikeson]

Hi!

First of all I want to thank all XviD developers for their great work!

But to the point...

I've tested latest development build 25112002 from Koepi and noticed some things.

1. I-frames are not inserted as they should be while using B-frames (3/150/100). First frame is I-frame (of course :)) but next I-frame is at frame 986 (I've specified min/max I-frame interval as 1/300). This only appears when using B-frames, otherwise it is ok.

2. There is a strange artifact on the top of the movie, but it only appears while using Lumi masking, otherwise it is gone.

Maybe I'm doing something wrong... :confused:

Using Avisynth 2.5, MPEG2Dec3 0.93b, XviD 25112002 (1 Pass - quantizer 5) and VirtualDubMod 1.4.11.2.

Here is the link: http://mikeson.wz.cz/xvid_testing.rar

[NoLogo]

@mikeson

1) I've been told (can anybody confirm that point ?) that user's specifications about min and max I-frames interval are not used anymore by the codec for quite a long time ago, this could maybe explain that...

2) Sorry, don't know where it comes from... cause I've never found Lumi mask very usefull or reliable, then I do not use to check the option...

Regards
NoLogo

[mikeson]

@NoLogo

1) I've been told (can anybody confirm that point ?) that user's specifications about min and max I-frames interval are not used anymore by the codec for quite a long time ago, this could maybe explain that...

But if I turn B-frames off, I-frames are inserted as they should be (ie on max I-frame interval or scene change) :confused:

[Koepi]

Only pframes are counted for the iframe interval, that's causing this strange behaviour.

Regards
Koepi

[mikeson]

@Koepi

Only pframes are counted for the iframe interval, that's causing this strange behaviour.

Is this an intention or a bug?

[Koepi]

?

Guess!

[mikeson]

@Koepi

I'm not sure, really. Anyway thank you for answering.

[Koepi]

It's not intentional, but noone coded that yet with the new motion estimation routines.

SysKin is fixing it ATM and we're thinking about adding support for min iframe interval as well again... but i prefer consecutive keyframe treatment over hacking such bad things into xvid.

regards
Koepi

[mikeson]

@Koepi

Thank you again for explanation.

I'm just asking because I've encoded a movie and seek times are very long (much longer than usual).

[miha]

Koepi can you compile a new build please

[Koepi]

I don't have the fix for the iframe interval counter here, so it wouldn't be of any use.

I'll put up a new binary soom though (not today).


regards
Koepi

[ffroms]

Here is how you can calculate and enter correct Iframe interval.
Let say you are using 4B-frame and 300 max Iframe interval.
With this you'll get Iframe every 1500 frames.
4x300+300=1500 (or 5x300)
or for 3Bframes
3x300+300=1200 (or 4x300)

So for 4Bframes set Max I-frame interval to 60, for 3B set to 75, for 2B set to 150 and 1B let as it is.

This is only until Koepi (or someone else) fix the problem. Keep up with good work Koepi and thanks.

[sysKin]

Originally posted by ffroms
Here is how you can calculate and enter correct Iframe interval.
Let say you are using 4B-frame and 300 max Iframe interval.
With this you'll get Iframe every 1500 frames.
4x300+300=1500 (or 5x300)
or for 3Bframes
3x300+300=1200 (or 4x300)

So for 4Bframes set Max I-frame interval to 60, for 3B set to 75, for 2B set to 150 and 1B let as it is.

This is only until Koepi (or someone else) fix the problem. Keep up with good work Koepi and thanks. No it won't work, because max number of b-frames is only a max, it usually is not reached. We decide on the number dynamically.

However, it really doesn't matter - it's been fixed for a day now :D

Radek

[iago]

uManiac's site:

XviD.Alpha.29.11.2002.1100.exe

---------------------------------------------------------------------
29.11.2002 11:00:
U vfw/src/config.c (rev.1.20.) suxen_drol:
- removed EnableWindow(FALSE) for bframes widgets

28.11.2002 20:20:
U xvidcore/src/encoder.c (rev.1.76.) syskin:
- proper max keyframe interval with b-frames
U xvidcore/src/image/image.c (rev.1.20.) syskin:
- qpel interpolation code fixed (but please check it's really a fix, noone answered to my mail)
U xvidcore/src/motion/motion_est.c (rev.1.44.) syskin:
- another interpolate bug (I promise to stop producing them. really. lol); some thresholds fixed for better mode decision (in bframes)
U vfw/vfw.dsp (rev.1.8.2) suxen_drol:
- removed #ifdef BFRAMES
U vfw/src/2pass.c (rev.1.7.2) suxen_drol:
- foxers 2pass + 'packed bitstream' patch; part 2
U vfw/src/codec.c (rev.1.23.) suxen_drol:
- removed #ifdef BFRAMES
U vfw/src/config.c (rev.1.20.) suxen_drol:
- removed #ifdef BFRAMES
U vfw/src/config.h (rev.1.14.) suxen_drol:
- removed #ifdef BFRAMES

21.11.2002 11:00:
U xvidcore/src/motion/motion_est.c (rev.1.44.) syskin:
- an ugly bug squashed (bframes+qpel)
---------------------------------------------------------------------

He he, worth a try until Koepi releases a new(est) binary! ;)

[Koepi]

hehe, most of those fixes are already in my 2511-binary (!) - since we closed up in development i have some of those fixes before they appear in CVS.

I want to release the next binary when i can apply suxendrol's 2ndpass corrections for IPB-decision, and for that occasion i have statsreader2.0 waiting in the queue. it's capable of inserting keyframes (!), but since now oin 2nd pass dynamic IPB decision is still done, those keyframes are ignored :-/

Well, just wanted to give some feedback here so you people know what you're dealing with :)

Best regards
Koepi

[iago]

@Koepi,

Thanks for the explanation man! Looking forward to the new build actually! ;)

regards,
iago

[NoLogo]

@iago

Hehe, just finished my Ghost Dog (2 languages - ogg) today, and it looks so greaaat !!
I used XviD-U-20112002 (cause U-28112002 had BF off...:confused: ), MSP6 / H263 / BF-4-200-200 / DX5, and , wooh ! the video still has the sharpness and details of the original one (that means: DVD). I had been already impressed on Mulholland Drive (not really sharp movie), but this time... post-proc is almost useless (ok, almost... :)).

Repeat after me: "XviD, XviD rocks you !" (© Queen)

So, I can't wait for the new improvements...

Very best regards
NoLogo

[Sgt_Strider]

Originally posted by NoLogo
@iago

Hehe, just finished my Ghost Dog (2 languages - ogg) today, and it looks so greaaat !!
I used XviD-U-20112002 (cause U-28112002 had BF off...:confused: ), MSP6 / H263 / BF-4-200-200 / DX5, and , wooh ! the video still has the sharpness and details of the original one (that means: DVD). I had been already impressed on Mulholland Drive (not really sharp movie), but this time... post-proc is almost useless (ok, almost... :)).

Repeat after me: "XviD, XviD rocks you !" (© Queen)

So, I can't wait for the new improvements...

Very best regards
NoLogo

If I use the current developmental build of xvid to encode my movies, will it still be compatibible with the xvid decoder from the final build?

[NoLogo]

If developpers don't make errors, any old XviD encode should be readable by any earlier version (that's what -h told once in a post, the "lowering compatibility"). However, I do not use in my encodes "exotic" option like GMC or QPel, which are buggy , or not stable enough, and could (maybe) be rewritten. Or you keep, on your CD, with your encodes, the codec that read it when you did it.

[iago]

NoLogo,

Did you use "FourCC: DX50" and "DX50 B-VOP Compatibility" in your encode or only "DX50 B-VOP Compatibility" keeping FourCC as XviD? And what about the A/V synch issue?

I experienced no delay/synch problems in my encodes with "FourCC: DX50" and "DX50 B-VOP Compatibility", as -h had mentioned before.

regards,
iago

[Didée]

On my latest testing, I used VdubMod 1.4.12.1, which is said to handle XviD equal as DivX regarding Bframes&synching...

For me, no real success.

With encodings (Koepi's 25112002) using 4 BFfames max., I still had a delay of 2 frames, and therefore to use an audio-delay of 80ms for muxing!!

[cca]

I have a question: how you determine the audio delay like Didie has? Certainly not by just looking at the movie! I encoded yesterday Star Wars Episode II using VirtualDub 1.4.13 without any special B frame handling enabled in XVID, just with 1 B Frame. The result is very good except for one thing: the final size. I requested a final video size of 972371 KB and I got 898860 KB. I used XviD-25112002-1 from Koepi's site, linear curve compression with 1 B-frame, no DivX 5 B-VOP compatibility, chroma ME, ultra high motion search precision and MPEG quantization type. I cannot see any audio delays, but that's just my eyes, I don't know if there is any real delay of 1 or 2 frames without some proper tool.

EDIT: I should also mention that I use AVImux GUI to mux the audio with video and that for the above mentioned movie I used the full AC3 audio stream.

[Manao]

@cca : For your undersize problem, it should be because you aimed for a final size larger that the one of the first pass. Your movie is a bit too compressible for the size you aim, so :

* Increase the resolution or
* Use lanczos instead of bilinear or bicubic or
* Don't use b-frame at all

For the audio delay, 2 frames begins to be sensible, but only 1 frame delay is hard to perceive.

[unplugged]

Originally posted by iago
uManiac's site:

XviD.Alpha.29.11.2002.1100.exe

---------------------------------------------------------------------
29.11.2002 11:00:
U vfw/src/config.c (rev.1.20.) suxen_drol:
- removed EnableWindow(FALSE) for bframes widgets

28.11.2002 20:20:
U xvidcore/src/encoder.c (rev.1.76.) syskin:
- proper max keyframe interval with b-frames
U xvidcore/src/image/image.c (rev.1.20.) syskin:
- qpel interpolation code fixed (but please check it's really a fix, noone answered to my mail)
U xvidcore/src/motion/motion_est.c (rev.1.44.) syskin:
- another interpolate bug (I promise to stop producing them. really. lol); some thresholds fixed for better mode decision (in bframes)
U vfw/vfw.dsp (rev.1.8.2) suxen_drol:
- removed #ifdef BFRAMES
U vfw/src/2pass.c (rev.1.7.2) suxen_drol:
- foxers 2pass + 'packed bitstream' patch; part 2
U vfw/src/codec.c (rev.1.23.) suxen_drol:
- removed #ifdef BFRAMES
U vfw/src/config.c (rev.1.20.) suxen_drol:
- removed #ifdef BFRAMES
U vfw/src/config.h (rev.1.14.) suxen_drol:
- removed #ifdef BFRAMES

21.11.2002 11:00:
U xvidcore/src/motion/motion_est.c (rev.1.44.) syskin:
- an ugly bug squashed (bframes+qpel)
---------------------------------------------------------------------

He he, worth a try until Koepi releases a new(est) binary! ;)
Ummmm... I have tried this build and I GUESS it has TOO_SMALL_LIMIT problem again, this build isn't able catch detail at all
Am I right... ? If yes, why isn't this fix committed to CVS yet?
It's a bit like bundle LAME with default preset --lowpass 16000 ...

sorry :o

[cca]

@Manao: I don't think that's the problem because first pass size is over 1 GB. I'm already using lanczos as a resize filter. I'm doing a second encoding now with a greater target size as a test. We'll see how it goes...

[NoLogo]

@iago

I checked "DX50 B-VOP Compatibility" and chose "FourCC: XviD". I haven't any kind of A/V delay, and I never had any whatever. Or maybe I'just to blind to see them... How long are these delays ?
Actually, everithing turned fine.
I used Avisynth 2.5 alpha (11112002 build), VirtualDubMod (1.4.12 VDub based), but not any kind of buggy or unstable option: it's a pure_BF_encode.

[Trahald]

Ive never had any delay problems either.

@cca- anytime ive had 2 pass size problems is when ive made setting changes between passes. im not saying this applies.. but just a mention. usually doing both passes over gets me dead on.

setting a larger size is a neat trick and will get you alot closer to the right size.. or at least highlight if you have hit the max q

[cca]

Well, my test encode finished and now I'm more confused than before! This time I specified a size of 1072371 Kb and ended up with a 1072468 Kb avi file! That's pergect for me. So what happenned before? I made only one change besides the size: Instead of using Virtualdub 1.4.13 I used VirtualDubMod 1.4.12.1. The conclusions are obvious I believe. I will now make a third encode with the original size and VirtualDubMod. It should give me the exact size. If not, something else is happening!

[cjv]

Originally posted by unplugged
Ummmm... I have tried this build and I GUESS it has TOO_SMALL_LIMIT problem again, this build isn't able catch detail at all
Am I right... ? If yes, why isn't this fix committed to CVS yet?
It's a bit like bundle LAME with default preset --lowpass 16000 ...

sorry :o
Hmm, the last time I checked out from CVS (about 4-5 days ago), this was the default:

#define TOOSMALL_LIMIT 1 /* skip blocks having a coefficient sum below this value */


cjv

[cca]

Well, my third test encode completed and guess what. This time the size was OK, so the first time I got the smaller file it had something to do with VirtualDub 1.4.13. So I recommend that anyone that does not want to use compatibility FourCC and B-VOP while encoding to use VirtualDubMod 1.4.12.1 instead of VirtualDub 1.4.13, at least until there is a newer release of VirtualDub. Also I hope that VirtualDubMod developers will take notice and won't break XVID B-Frame support by merging the sources.

[NuclearFusi0n]

Latest development (unstable) binary:
XviD-02122002-1.exe (368kb)
Changelog:
- Fresh CVS checkout
- bframe updates (mpeg + cust. quant matrices work)
- refdivx's lumi masking bugfixed (hopefully)
- sysKin's updated dynamic halfpel/quarterpel code is used.
- StatsReader updated to 2.0.

new binary! :)

heh, i went to koepi's site, saw 11/25, closed it because i was late to class, then decided to go back and start my encode before going to class and there it was :D
heh, i get too excited over these things ;)

[Koepi]

XviD-02122002-1.exe (368kb)
Changelog:
- Fresh CVS checkout
- bframe updates (mpeg + cust. quant matrices work)
- refdivx's lumi masking bugfixed (hopefully)
- sysKin's updated dynamic halfpel/quarterpel code is used.
- StatsReader updated to 2.0.

Enjoy!

Best regards
Koepi

[Koepi]

that was fast nuclearfusion, i put it online 2 minutes ago and you already noticed.... i guess you keep hitting shift+reload the whole day? ;)

Best regards
Koepi

[NuclearFusi0n]

Originally posted by Koepi
XviD-02122002-1.exe (368kb)
Changelog:
- Fresh CVS checkout
- bframe updates (mpeg + cust. quant matrices work)
- refdivx's lumi masking bugfixed (hopefully)
- sysKin's updated dynamic halfpel/quarterpel code is used.
- StatsReader updated to 2.0.

Enjoy!

Best regards
Koepi
"Error 404 - File not found

We are sorry, but the file or page you requested is not on this server."

on your site link to XviD-02112002-1.exe :(

[Koepi]

Already found that error and fixed it :)

Regards
Koepi

[NuclearFusi0n]

Originally posted by Koepi
Already found that error and fixed it :)

Regards
Koepi heh, forgot to refresh....doh!

[mikeson]

@Koepi

Still cannot download - Error 403 - Access forbidden!

I'm using Mozilla, but IE gives me the same message.

Can you please fix it, I would like to do some overnight tests ;)

[Koepi]

Mike,

the problem you have is:

referer check

(mentioned on the 403 page you're getting there...)

Send a referer (i.e. disable "norton internet obscurity" and similar products that give you the wrong feeling of security), use mozilla or IE (plain)...

Then the download works.

Regards
Koepi

[mikeson]

@Koepi:

Yes, you were right, it was because of Norton Firewall.

Thank you very much! ;)

[iago]

@Koepi (and mikeson)

I have just downloaded the new build ;), and immediately started to try the "qpel + b-frames + cm + lumi" combination. With this combination I'm planning to do my first 1CD encode with AC3 audio! :D

Well, OK, the movie is Henry and June, 130 min, ~ 184000 kb 2.0 AC3 audio. Also, I must admit that it's pretty well compressible ;).

Many thanks for the effort and the new binary my friend!..

iago

[mikeson]

@Koepi

I would like to know, when new build of XviD appears, do I have to reedit queued tasks in VDub or can I use the old ones? I'm asking besause in VirtualDub.jobs there are data sended to codec (in VirtualDub.video.SetCompData) and I'm not sure if these data changes between XviD versions.

Thank you for answering

@iago:

I'm looking for new results and conclusions from your testing. ;)

[stax76]

I would like to know, when new build of XviD appears, do I have to reedit queued tasks in VDub or can I use the old ones? I'm asking besause in VirtualDub.jobs there are data sended to codec (in VirtualDub.video.SetCompData) and I'm not sure if these data changes between XviD versions.

I guess if there a new settings, it would be a problem, that's probably the main reason why GKnot don't support XviD. The jobs/profiles of DVX read and write the setting in the registry, so it works with all XviD/DivX build/versions

[fraatz]

@koepi: just wanted to report that lumi masking in your latest build (2.12.) is still producing white pixels. i don't get black ones anymore...
want a screenshot?

[unplugged]

Unfortunately :( this build seems to generate non-standard videos, or at least this is what happens with MPEG4 player...
with EnvivioTV for first time (never happened) they appers very messed up.
Maybe something has been forgotten around xvid code at last minute...

(tried fix q2, H.263, motion 6, Qpel, CM, BF3/150%/100%)

[wing1]

@koepi

I am seeing an encoding speed degration with the last few new builds.

umaniacs' 11-25-2002 instabuild = 18fps
(lumi+cm+bframe w/ mpeg or H263 @ ms=6, xvid4cc)
biggest of the three semi blurry video in a few frames

koepi's 11-25-2002-1 = 14fps
(lumi+cm+bframe w/ mpeg or H263 @ ms=6, xvid4cc)
smaller filesize and sharper video

koepi'2 12-02-2002-1 = 12fps
(lumi+cm+bframe w/ mpeg or H263 @ ms=6, xvid4cc)
smallest filesize and sharpest video

I ran the same clip through avs2.5 with avs2avi encoder for testing new builds. The settings are the same with all builds.

I am not complaining here :D just report on what I've observed. I'll trade off QUALITY over SPEED anytime when it comes to that.

My CPU is AMDxp1900+

[NuclearFusi0n]

during my SECOND pass, i get about 10 fps with my 512mb PC2100 Crucial DDR RAM and a AMD Athlon XP 2000+

Settings for XviD ()
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 451114KB
I-frame Boost: 10%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 30%
Curve Compression: Payback Proportionally,, Bitrate Payback Delay: 1frames
High Bitrate Scenes: 0%, Low Bitrate Scenes: 0%
Hinted Motion Estimation: OFF
Alternative Curve System: OFF,
Motion Search Precision: 6 - Ultra
Quantization Type: New Modulated HQ
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: 6
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,

[Bulletproof]

Well, it did say that he added dynamic q-pel mode, which I guess would take more cpu cycles to make decisions.

[Koepi]

Originally posted by NuclearFusi0n

Settings for XviD ()[size=1]
I-frame Boost: 10%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 30%
Curve Compression: Payback Proportionally,, Bitrate Payback Delay: 1frames
Quantization Type: New Modulated HQ


Ok, these settings can be finetuned ;)

iframe boost is just necessary when you iframe quants are too low. Is this the case? I prefer a boost of 0. iframe br reduction 20% suffices in my excessive tests I made, I wonder why I didn't change the defaults... ;) For curve compression, use "paback with bias" and a payback delay of 250, your results will be better!
And finally, "new mod hq", hm... I think i get better results with "plain" quant matrices, e.g. the "hvs_good_picture" matrix for low bitrate encodes. Just some thoughts on these settings.

@wing1:
As to talk about the speed:
I use ICL7 atm, and "finetuned" th optimizations according to the compilers documentation. This can give some speed changes.
The dynamic hpel/qpel decision takes a bit more time - but most important, referencedivx' lumi masking is very slow compared to the old lumi masking code. Check the speed without lumi masking and qpel and compare against uManiacs build please, and report the results - if my binary is still slower, I will use the "old" optimizations again!

@unplugged:
Dynamically changing qpel/hpel resolution is hardly "non standard" - ok, it requires a VOL header for each change, but so does any "modulated quant" mode. Can your decoder decode encodes containing modulated quant matrices?

@fraatz:
Damn, and we thought the issue is solved. I just did a small test with a sample of the 5th element where i got massive spots/mirrored pixels and they were gone (white text on black background). Is the effect at least less visible?

@all:
thanks for testing and posting your results here! Keep doing that :)

Best regards
Koepi

[cjv]

Originally posted by Koepi
Check the speed without lumi masking and qpel and compare against uManiacs build please, and report the results - if my binary is still slower, I will use the "old" optimizations again!
Koepi,

I also noticed this slowdown..I used just standard settings, 3 b-frames, no qpel or lumi, and noticed this build is approx 2-4 fps slower (on p4 1.4 and Athlon 1400).

As always, thanks for the new build...just a few questions:
1) I've been playing with the new statsreader, but I'm kinda confused. Could you explain this a bit..ie: the implications:
"New in 2.0: if setting target size to "0" you can use StatsReader
to add keyframes in desired locations."
Am I right in assuming this is useful for manual tweaking of misplaced I-frames..but not normally needed?

2) Any talk about the aspect ratio flag being implemented?..please keep pushing for its official inclusion :)


cjv

[Koepi]

Ok, I will return to the old optimizations again and will see if speed improves again.

The statsreader can force keyframes (as long as you don't use bframes [or the dynamic IPB decision gets fixed]) at any place you like. This was requested for example for supporting chapters in OGM better. It's just something to play with.

I'll keep asking about the DAR flag inclusion, but unfortunately it doesn't seem to work in windows. Someone has to write some ugly decoder hacks for that :)

I tested the lumi masking code and I have to say: yes, some spots still occur, but it's already way better than before. Refdivx has a suggestion what to change, this might be included in the next build (some thresholds can be finetuned...).

Regards
Koepi

[NuclearFusi0n]

I'm going to do the full encode of "Run Lola Run" (80 minutes) tonight, and let you know how the encode looks in the morning, and the speed of it too. my settings 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
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: 3
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,

[Koepi]

XviD-03122002-1:
- refdivx's lumi masking fixed (new thresholds)
- using old compiler optimizations, they were faster

*caugh* ok, please test again %) As for the DSF, I really forgot to activate bframe decoding in the core, so now it should work again ;)

Best regards
Koepi

[mikeson]

@Koepi:

Ok, aborting current encoding process and starting new one with 03122002-1 :)

[NuclearFusi0n]

Originally posted by mikeson
@Koepi:

Ok, aborting current encoding process and starting new one with 03122002-1 :)

same goes for me

[Koepi]

Sorry for that mates - but you asked for it somehow ;)

Have fun!

Regards
Koepi

[mikeson]

@Koepi:

You don't have to appologize, I was at 2% ;)

Anyway I'm happy for every improvement and bug fixed! :)

[iago]

Same here pals, I have aborted an approximately 13 hours first pass at the 10th hour of it! ;) Restarting with the new build.

iago

[fraatz]

@koepi thanks a lot man, you are f*a*s*t!!

anyway i made some tests on qpel/hpel compressibillity and qpel gave smaller filesize in any test no matter if fm or lm scene with crisper image.
wouldn't it be nice to have the ability to switch hpel/qpel- switching on and off?

-f

Edit:
"motion search distance comes into play. since qpel halves the max search distance, high action scenes will suffer."quote from xvid developer mailing list - so forget about the switch...;)

[Swede]

Originally posted by Koepi
Damn, and we thought the issue is solved. I just did a small test with a sample of the 5th element where i got massive spots/mirrored pixels and they were gone (white text on black background). Is the effect at least less visible? They are less visible but they're still there. If you want I can provide you with a 10MB-huff-clip that still gives the white pixels when Lumimasking is on.

[NuclearFusi0n]

i'm getting the same speed - if anything, it's a frame or two per second slower :(
scratch that: it's a few fps faster! :D

[Koepi]

swede:

does that still occur with the 03122002-1-build? I modified the thresholds accordingly to refdivx...

(I have a "hardcore" sample as well which exhibits that problem massively - and guess what, i didn't check that with the new build ;) ).

Best regards
Koepi

[Swede]

Yup, still there.. Only when using Fast Recompress and Lumi.
(I have a "hardcore" sample as well which exhibits that problem massively - and guess what, i didn't check that with the new build ;)). Duh.. :D

[Koepi]

Left "newer" code from 02122002-1 build, on the right the first attempt in the build from 25112002-1.

I think it's definatly better. Dunno about the actual build though :-/ (have 13hour of first pass to do until i can verify/falsify that ;) )

[fraatz]

@koepi: i can confirm that there are still some white pixels in 3.12 build...

[gamr]

Well i have to say it, im unimpressed. I tried it out on properly filtered/ivtc'd anime and got a 3.5meg LARGER pass1 than without it (375062k vs 371378k), that said, with the 03 it was 50k smaller than with whatever was the first build with the new lumi masking code in it.

I do realize that the old lumi masking was unusable in a lot of cases but i didnt expect a detrimental effect on compressability :(

cm+b(2/100/400) h263, nothing special

any suggestions? or is lumi masking just bad with anime? (fair enough if it is, anime sux to encode)

[Teegedeck]

Just allow me to remark that all assumptions that 'psychovisual' stuff like lumi-masking is based on very probably don't hold true for anime. Better not use it for anime ever.