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:

[MaTTeR]

Yep, that's what I meant also. The latest uManiac builds seems to decode Qpel with much less smearing at least here on the two machines I tested. Sorry I should have been more clear I guess.

For sure the I-Frame distance isn't being respected by the encoder though. Well maybe every 3000 frames or so. LOL

[Sigmatador]

Originally posted by MaTTeR
For sure the I-Frame distance isn't being respected by the encoder though. Well maybe every 3000 frames or so. LOL [/B]

does anyone know the priority of this bug ?

[nexus]

No oversize problem here, too:
target: 1291264 kbytes
result: 1291442 kbytes

But the sound is async. Audio delay of 120ms works.
Settings: QPel, 3 B-frames


--
nexus

[ak]

Originally posted by nexus
But the sound is async. Audio delay of 120ms works.
Settings: QPel, 3 B-frames

That's normal, you know :sly: (http://forum.doom9.org/showthread.php?postid=247335#post247335)

[nexus]

@ak:
But I was testing this build: XviD-02022003-1 (according to the thread).
Moreover this should be a confirmation of known issues, eg. oversize, because there are still people having size-probs, and there is no problem with oversizing in this build.
That're my results. Just another test.

--
nexus

[bob0r]

I know what people mean

i encoded like 10 Videos i capped.

all did 2pass, 300MB was my goal. (300000)

like 2/10, some after trying 3x, only became 263MB

and 1 even the first time did 758mb, did job again, it was 300MB

Dont ask me for details, all i did is install virtualdub(newest)
set 1 pass quality to 100, choose 2pass 1st pass then 2pass int and set size.. i all put them in job control.

This all happened at Night so, not nothing i notices... i dont have stats file nor 1pass file, sorry....

Just to confirm xvid of koepi can be quite mysterious :D

PS videos where ~45 minutes each

[Teegedeck]

:rolleyes: :cool:

[Sigmatador]

Originally posted by bob0r
set 1 pass quality to 100, choose 2pass 1st pass then 2pass int and set size.. i all put them in job control.

set 1 pass quality to 100 then choose the 2pass mode ... :confused: :confused:

[nexus]

@Sigmatador:
2 tests :)
-first test: 1pass qual=100
-second test: 2pass

--
nexus

[SiXXGuNNZ]

I had an undersized problem with this build, target size was 950 MB came out to 697 MB

gonna run some tests on an individual chapter from the matrix, I used identical settings to the jan 26th build, which also came out slightly under, but only by a few MB

[Koepi]

UNDERsize is no problem.

OVERsize is. And - sorry to say this - it's dpending on the usr's settings. This build has no such problems, else every other build rom the last year would have it *hint*.

So please DO what the readme says and report afterwards. (erm. and i mean: do a _full_ 2 pass again)

Koepi

[Mango Madness]

when aiming for a 650meg encode the file was 125KB off, that is unacceptable :) Anyways, good build, and glad to see everything stable. I just hope for continued improvements on quality and speed.

[SiXXGuNNZ]

Originally posted by Koepi
UNDERsize is no problem.

OVERsize is. And - sorry to say this - it's dpending on the usr's settings. This build has no such problems, else every other build rom the last year would have it *hint*.

So please DO what the readme says and report afterwards. (erm. and i mean: do a _full_ 2 pass again)

Koepi

well, I must have had something screwed up, because when I do chapter 29 of the matrix with your last 2 builds they both come out near perfect for filesize, so I really have no idea what happened to make mt filesize 250 MB smaller. I am going to re-encode it tonight tho, I probably won't have a problem :)

@Mango Madness

OMGHI2U

[SleepEXE]

Oh, man. This build is just crazy good! I just compressed three clips from Final Destination:

1. B-frames only (3/130/100)
2. B-frames & Qpel
3. B-frames, Qpel & GMC

and loaded them into a 2x2 grid along with the source MPEG2 using Avisynth's StackVertical() and StackHorizontal(). Each clip was compressed in two-pass mode to ~65% of its first pass bitrate. It is very difficult to see any differences against the source except in scenes with broad gradients. A little touch of noise with ffdshow during playback makes it virtually indistinguishable.

Very impressive. Now my only concern is the XviD developers haven't left much room for improvement. I hope I'm wrong ;)

Many thanks!

Best regards,
SleepEXE

[NuclearFusi0n]

Originally posted by SleepEXE
Now my only concern is the XviD developers haven't left much room for improvement. I hope I'm wrong ;)
I've been thinking about that too. Devs, is there room to improve (in image quality, not stability) or are we pretty much pushing the limits already? :(

[Teegedeck]

Well, I'm afraid there is just no stopping those XviD-devels.

It would seem that over the next couple of months we can expect other improvements coming in to keep us testing; improved adaptive quantization that takes texture and movement into consideration should help a little bit (ATM most of us don't use lumi-masking when aiming at HQ-encodings, right?) and, talking about HQ, there's work in progress on a VHQ-mode with additional refinement-steps and better mode-decision that could save a few % in bitrate. :) :) :)

If we are patient and good children, I think we'll be rewarded not only once a year. Things don't look like they'll get boring anytime soon.

[kilg0r3]

Hi,

i am attaching a detail from a frame of 'Spiderman'. As you can see there is still chroma stepping on the red border between. Similar effects can be seen with blue edges. The tested builds was the latest koepi. i would be glad if anybody could confirm this. You can also get it from here (http://kilg0r3.cjb.net/img/stepping.jpg) a better file is here (http://kilg0r3.cjb.net/img/stepping2.jpg)

[Koepi]

Does YV12 ring a bell there?

half resolution in chroma? (i.e. 640x272 has a chroma resolution of 320x136...)

Koepi

[iago]

@kilg0r3

I agree with Koepi (one more time ;)) that this is more a YV12 issue than an XviD one. I bet you would get the same stepping artifacts with DivX 5.0.3 too in the YV12 colour space.

regards,
iago

edit - but maybe it all depends on the edge enhancement of the source and more or less you would get them in YUY2 too (I'm still a bit unsure about this ;)).

UnFilter?.. Tom?.. ;) (afaik UnFilter does not filter chroma)

[kilg0r3]

o.k. since i have restarted this, i feel obliged to give some more information. i did some more screen captures.

1. avs 2.5 file (YV12)opened in vdubmod with some filters and BicubicResize
2. avs 2.5 file(YUY2) opened in vdubmod without anything but mpeg2dec3
3. avs 2.5 file(YUY2) opened in vdubmod without anything but mpegdecoder
4. avs 2.07 file(YUY2) opened in vdub without anything but mpeg2dec3
5. dvd2avi without overlay (of course)

Here are the results

chroma jaggies were visible in 1-4 but not in 5. huh? The strange thing is that i never saw this before, say, november 2002. probably the codec just gets too good :) i would love to see somebody else verify this.

i have not had the time to put them up on my site. but if anyone needs them i will do so some other time.

[Bulletproof]

I have found that Vobsub can cause the jaggies also, I recently changed my Vobsub to "Force RGB" and to RGB32, This makes the subtitles colors alot better, but I had thought they would only affect the subtitles and not the entire picture. I had noticed that the Reds in my picture were largely pixelated. After turning off RGB32 and telling Vobsub to use YV12 the pixelation in the red colors of the movie went totally away, however the subtitles showed some color bleeding then, and I'm assuming thats because of the low chroma resolution for YV12.