XviD-14112002-1...

[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.