XviD 12042002-1

[Koepi]

Ahoy,

I just did a fresh CS checkout and upped a new build with EPSZ code enabled.

Some fixes in the VLC tables made it into CVS, and some other things I forgot about ;)

Best regards,
Koepi

P.S.: find teh binaries following teh XviD link in my signature

[N-Bomb]

Mmmm, binaries... :)

Woo woo! Too bad I didn't see this sooner in time for a test encode I'm doing... but I think I'll be grabbing it either way.

Thanks for the dedication!



-Nick

[Schumi3]

I'm just curious, what are the differences between your builds and nic's? In another discussion I've read that nic has some special playback filters, or did I misundersteand something?

Edit: I've installed Koepis one now, no difference, everything fine :) I didn't try to encode!

[The People's Elbow]

Just wanted to report that I get pretty many frames looking like good ol' DivX3.11alphas' shitframes when I try to encode with it ( the Motion Vector hintfile). I'm not using modulated as Quantization type, only H.263 and the speed increase is about 10-15% when doing 2nd pass.

...I just took a look at previous posts regarding this bug...mvh+lumi doesn't work atm, right?

greetz,
Elbow

[rui]

Well, lumi+hmv didn't work in the prior Koepi's build. Since this one doesn't state that the bug was fixed, i am assuming the lumi+hme is still a no go. Also valid to modulated quant+hme.

[Belgabor]

@People's Elbow

Do they look like the screenshots I posted here (http://forum.doom9.org/showthread.php?s=&threadid=22218&pagenumber=2)?

Then it's the same promlem I have since the major core update, and its probably (maybe?) not related to mvhints.

Belgabor

[The People's Elbow]

Belgabor wrote:
Do they look like the screenshots I posted here?
- No, the picture is much more damaged in my tests...and it's really like the old 3.11alpha bug. A kf gets heavy macroblock errors which only get corrected with the next kf, all frames in between look bad, either.
...but as I said, this picture errors only occur, if I use mvh+Lumi, although I didn#t test it without lumi.

greetz,
Elbow

[-h]

- No, the picture is much more damaged in my tests...and it's really like the old 3.11alpha bug. A kf gets heavy macroblock errors which only get corrected with the next kf, all frames in between look bad, either.

Oh heck yeah, if you use hints and lumi masking (only in 2nd pass) then horrible twisted things will happen.

On another thought, using lumi masking only in the 2nd pass makes conecptually no sense whatsoever - it can't redistribute the bits saved by a dark scene to any other scenes, because the overflow mechanism instantly steps in and assumes undersizing is occurring, and assigns the dark scene even *more* bits than it should have to start with.

I'll re-enable lumi masking on the 1st pass, and start encouraging its use. The updates Isibaar made to lumi masking should have eliminated the problem of frames getting too much masking if applied in both passes.

-h

[The People's Elbow]

hmmm, sounds weird ;)
I don't know how Lumi masking is working in XviD right now, but wouldn't it be the most usefull way, if lumi masking would use the stats file, which stores lumi related picture infos from the 1st pass(I hope :rolleyes: ), and calculates the lumi masking out of this stats file for the 2nd pass?

greetz,
Elbow

[chemmajik]

Sorry to change subject for brief, People Elbow are you running 2 capture cards in the same system? What advantages are there to that besides you using one for mpeg2 the other for avi/mpeg4?

[The People's Elbow]

@chemmajik: The Analog WinTV Go is for videos, sometimes I have VCR as source for ripping material, that's the only reason why it's still in my system :)

greetz,
Elbow