XviD-02022003-1 (unstable) developer build

[kilg0r3]

Hi, as koepi said, it's up and running(?). Just wanted to help and keep the forum tidy. You can find it on my 'site' (http://www.mynetcologne.de/~nc-allgeife8/) too.

cheers


EDIT BY KOEPI:
Even if it's an unauthorized mirror %) - the original site is mine:
http://www.roeder.goe.net/~koepi/
no offense, but it's still the real download site. Thanks for the backup for cases where my network/MAN fails.

[Selur]

thx for the info and mirroring the .exe's :)

Cu Selur

Ps.: Seems like you missed Nic's 29.01.03 build, at least it's not on your side. :)

[jwu42]

Thanks for the notice!

[ciper]

I'm having size problems again .. they are not that serious .. for a 10Mbs target size i got 13 Mb ..
configuration:

Bframes (2/100/150)
Lumimask
Gmc
Chroma Motion
2 Passes ..
movie length: 3.7 minutes
(matrix in the hall scene, one of the most dificult scenes to encode in this movie, lot's of debris flying in the air).
Movie resolution: 640x256 (resized)

In the other hand, the quality was ok (got an average of 70 KB/s). Xvid is improving at large passes ;) congrats to all developers .. BTW, speed encoding is ok too .. i have a duron 1.3 (i'm already using avisynth 2.5 with yuv12), got average 20-18 fps (without bframes and GMC) and 12-10 (with them on)

[Bulletproof]

Yes it seems a bit off for me too, Luma+GMC+B-Frames set to 1 (Ratios to default etc.), target size to 200 megs came out to 236 megs.

[ookzDVD]

Report:
I just use the latest Koepi's 02022003,
VDub crash while use Lumimask + B-Frame + GMC + ChromaME,
but OK without Lumimask, just B-Frame + GMC + ChromaME.

Edit: No Oversize problem.

[Koepi]

I published this build because I didn't have oversize problems with it.

2 ways to go for you:
- hit "load defaults" (!)
- make sure your quantizer restrictions and different settings don't cause this.

(more in the sense of: give xvid the freedom to decide itself what to do)

Regards
Koepi

[kilg0r3]

@koepi

no problem and sorry for not asking. i just figured it would be useful for some people. anyway i will put the links to your, nic's, umaniac's and the xvid site on mine and some comment.

@selur

currently i am mirroring only koepi's binaries (most widely used) Nic's decoder and some random insta builds. the idea was to provide access to older builds for testing/verification purposes.

@ that leads me to the question: is there a stand alone version of your decoder? couldn't find it.

[frodoontop]

I can confirm there are no oversize problems. I used B-frames, Chroma-motion, GMC and Quarterpell. Guess Koepi is right, just hit that default button. My test clip was only two minutes, but it hits the right filesize.

Many thanks Koepi!

[blue`ostyler]

First of all, thx to all the Xvid team for their great job ^^

I have a pb with the frame delay at beginning. The maxBF+1 frame delay (or maxBF only delay with pb) is back. We got it all before the hack correction in Vdubmod 1.14.11, but as we know, the first frame decode error still remains.

But with the last codecs (after the 24012003), the hack seems not to work. So in maxBF 3 without PB, it would give me a 4 frame delay.
I have the last realize of Vdubmod 1.14.13.1 with the 310103 exe.

[ciper]

@ koepi

That's just what i did .. i loaded the defaults (i didn't mess with the quantizers). But to avoid any doubts i'll reencode de video again .. (pressing again the load defaults)

[terwin]

Great work. Neither problems with oversized files nor with other options like B-Frames, CM, QPel or GMC.

CU terwin

[nFury8]

Ditto, I didn't have oversize problems either. Only used Chroma Motion and Qpel,no B-frames, MPEG quant; Quant Restrictions set to: I-frame=2-6, P-frame=2-16, the rest set to default. Used VdubMod 1.14.13.1 with 310103 exe. As usual resulting quality is great.

That being said, I have to re-label this build from 'unstable' to 'unstoppable'. Hats off to Koepi.

[ciper]

the thing is .. with no bframes i also have no oversizing problems..

[frodoontop]

That's exactly what we want!:D

[pandv]

I encoded a movie with:

2 pass
Color Motion
QPEL
B-Frames 1/150/0
Maximum keyframe dist: 175

The first pass has 586 keyframes, but in the resulting second pass only 18 keyframes are present (making a superb quality and unseekable movie).

I report this because I think this bug has been resolved, and remained only the no count b-frames bug.

pandv

[Koepi]

NO, sysKin had to take back his "bug-fix" as it introduced even worse unpredictable behaviour :-/

Still, this issue is known and will be solved not too far in the future.

Regards,
Koepi

[Gazza]

Koepi,
Just finished re-encoding video streams with B-frames (3,100,200), gmc and chromaME. I didn't select qpel in order to keep things the same as my previous tests. Very very very nice quality.

However I still had problems syncing video with audio. Sample video had a audio delay of -80ms (as reported by dvd2avi 1.76). However when processed to produce a *.ogm, it looks as if the audio should be delayed significantly more.

[kilg0r3]

Originally posted by pandv


The first pass has 586 keyframes, but in the resulting second pass only 18 keyframes are present (making a superb quality and unseekable movie).

no such problem here. all options except gmc enabled + 3 bframes.
anyway movies are for watching not for seeking, aren't they?:rolleyes:

[echo]

First I would like to thank koepi and the development team for the new build.

No doubt I get great quality encoding with this build but the bug with the "Floating point division by zero" when trying to open the stats file with gknot that was reported in the previous build's thread still exists... at least for me.

Just my 2 (euro) cents...

Regards

echo

[vinkes]

@echo,

you can still open stat-files in gknot when you use the nandub-statfiles tab.

Regards

[echo]

Originally posted by vinkes
@echo,

you can still open stat-files in gknot when you use the nandub-statfiles tab.

Regards

Hey, thanks a lot for the answer vinkes. I never thought of doing it that way. Its time to move on from the 091202 build I was using until now because of that problem then :-)

Regards

echo

[nexus]

Hi,

I tried latest unstable build (XviD-02022003-1) and the result was a
higly undersized file
target: 1198080 Kbytes!
result: 1127226 kbytes!

No idea, what's the reason.

Here are the settings:

GLOBAL
Max I-frame interval: 250
Enable lumi masking: on
Enable greyscale: off
Enable interlacing: off
Use chroma motion: on
Quarterpel: on
GMC: off
B-frame
Maximum B-frames: 3
B-frame quant ratio: 150
B-frame quant offset: 100
Packed bitstream: off
DV50 B-VOP compatibility: on
Print debug info: off

QUANTIZATION
Min I-frame quantizer: 2
Max I: 5
Min P-frame quantizer: 2
Max P: 12

Alternative curve sys not used

CREDITS:
from 184550 til 190918
quant:20

2nd Pass: internal

1stPass: 2675 keyframes
2ndPass: 2583 keyframes

And I DID hit "load defaults".


Keep up the good work!

--
nexus

[MoonWalker]

How much MB was the 1pass? Maybe you movie got saturated..

MoonWalker

[Teegedeck]

Nothing obviously wrong with those settings IMHO. Maybe you just 'maxed out' on this one. Can you tell us what the 1st pass' size was?

[nexus]

Unfortunately, I didn't save the first pass file (discard). XviD Analyzer doesn't work, it reports 1 keyframe and size: 2kbytes.
Any idea how i can get the filesize of the first pass?

--
nexus

[Wormz]

Do you still have the .stats file?

[Gazza]

Is anyone else experiencing video/audio async problems with this build when using b-frames? The reason I ask is that I see these problems but not sure if others confirm it is a definite bug?

[seewen]

I've seen no video/audio async problems. ( using B-frames 3/150/100 & 2/150/100, ChromaME, NO DX50 B-VOP Comp, NO GMC, NO Qpel, and defaults values for the rest ).

And the target size is perfectly respected ( but I had to "load defaults" when I installed XviD... If not, I got oversized result ).

And I use AVI containers.

[atcronin]

well i can confirm asynch. but only at the begining of rips.

using bframes 3,150 or 200 +gmc+chromaME. pal 25fps.

ac3 file had a -96ms delay, but when muxed was clearly outa synch.

but muxed it at 24ms and is fine.

im guessing its bframes, as with both the sync towards the end of the movie is perfect.

[oh and this is saving video into either ogm or avi and muxing into either again.]

[Koepi]

Man, with ac3 you get asnych issues?

Sorry, but ac3 is known for such problems.

A usual transcode contains a transcoded video and transcoded audio, i.e. xvid+ogg or xvid+mp3.

Tested "Das Boot" again where my 2601 build got those asnych issues - with this build everything is perfect, no ansych to find.

No such bug.

Regards
Koepi

[nexus]

@Wormz: Sure, i still have it.

--
nexus

[ookzDVD]

I can confirm that I don't have such async problem with AC3.
But all my .ac3 files are 0ms delay. I and mux into .ogm use Cyrius's ogmuxer without problem.

[nexus]

Ok, if I watch the film with ffdshow's OSD it reports quant 2 for I&P-frames and quant 4 for b-frames. So it seemes to be maxed out. Sorry for the false alarm. I think i can put an 2h-film on 1 CD! :-)) Anyway, is there any possibility to get the first pass size with the help of the first pass video.stats?


--
nexus

[frodoontop]

I've got the same synch-problem. Though the solution as atcronin(thanks!)mentioned worked for me. Just add an 120 ms delay. Guess this only works for pall-encoded movies with 3 b-frames though. It's a nice workaround for me.

[kilg0r3]

@nexus

load it into koepi's stats viewer.

And, if you suspect that a film could max out the codec, untick the 'discard first pass' box in the xvid's config dialog.

[Nic]

New build at my site: http://nic.dnsalias.com ICL7 compiled, newly written dshow, but still has the occasional bug ;), theres a link to the source.
(Now it decodes the video as the xvid dshow decoder in the cvs would if theres no PostProcessing set. And my way of doing it only kicks in if postprocessing is used)

Cheers,
-Nic

[duartix]

@Koepi
I also get synch problems in OGM with AC3 when using b-frames.

@frodoontop & others with synch trouble:

My way of solving synch problems was this (http://forum.doom9.org/showthread.php?s=&threadid=35593&perpage=20&pagenumber=2)

[Gazza]

I tried atcronin's suggestion of adding 120ms and re-muxing and it works for me. Note, I produced an ogm from a ogg (which was produced using oggmachine.....). In other words I didn't use the ac3 file.

Now 120ms on a 25fps PAL represents 3 frames. So somewhere along the way I suspect 3 frames are getting dropped at the beginning of the video.

I had a look at an old test ogm that was encoded with a version of xvid circa early Nov 2002 and there is no sync problems.

Hope this helps

[ookzDVD]

@Nic,

About your latest build, the oversized problem is gone finally ;)
the DS filter without postprocessing is quite good even still
have problem with shuttering while seeking.

[Koepi]

ookz,

tzhere is no oversize problem with my build. (?!?)

Koepi

[ookzDVD]

Originally posted by Koepi
ookz,

tzhere is no oversize problem with my build. (?!?)

Koepi

Of course, your build is ok, no oversize problem. :)

[Nic]

@ookz: Thanks for the report, the two known bugs for my DShow are that seeking somtimes gets confused & sometimes while going from fullscreen to windows the output goes black and white (?!?) But at least now it decodes exactly right, the problem comes from me calling XviD's internal colorspace routines, but I dont know why that causes the problem (& I dont want to add colorspace routines to it).

Ill figure it out one day :)

Cheers,
-Nic

[kilg0r3]

hi nic!

what about qpel decoding? to it seems that there are still slight smearing artefacts. or is it just my eyes?

[nexus]

@kilg0r3:
Nice idea, nic's decoder in a .rar at your site. That's exactly what I searched. :-)

(Sorry for being off-topic)

--
nexus

[Nic]

@kilg0r3: Yeah I think your right, its not caused by my decoder though I dont think, more likely that particular CVS build. Ill rebuild the CVS and re-encode to see what I can find :)

-Nic

[MaTTeR]

Yep, uManiacs latest build doesn't seem to show the Qpel smearing near as bad as Koepi's latest build. Perhaps the fix was commited to CVS already?

FWIW- Latest ffdshow displays the smears if using libavcodec instead of uManiac's xvid.dll (latest).

Koepi,
Slight over-sized problem still exists in your build when B-Frames are used. 700MB target usually comes out around 708-710MB. Thankfully I can overburn that much easily:D

[cult]

no oversize here...

[kilg0r3]

whoopsie!
i always thought, the qpel smearing was only a _de_coding problem :(

[AmiRage]

Originally posted by kilg0r3
i always thought, the qpel smearing was only a _de_coding problem :(
That's the impression I got too from what was said so far ... :rolleyes: