XviD-02022003-1 (unstable) developer build

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