XviD 02042002-1

[Koepi]

XviD-02042002-1:
- Highly optimized build.
- Gruel's new EPZS and EPZS^2 code activated
- using "motion search precision 6" results in using EPZS^2 code (even better than EPZS)
- code is not yet optimised, thus a little slower (but the result is way better)

Follow the XviD link in my signature :)

Best regards,
Koepi

[Hanty]

Yeah Right! You're not fooling me! That trick only works once. ;)

[Koepi]

erm, april 2nd is not blabla day.

It's a new motion estimation algorithm that isn't tested yet (but looks very promising in my debug output).

regards,
Koepi

[-h]

It's a new motion estimation algorithm that isn't tested yet (but looks very promising in my debug output).

What kind of file size differences are you seeing? Like, same clip, quantizers fixed at 2, 3 and 4, PMVfast vs EPZS vs EPZS^2 etc.

You know you want to :)

-h

[OxP]

umm, am i blind or no alt curve compression?

[yokem55]

I didn't see any alt curve compression either....

[ookzDVD]

I think Alt.Curve only available from Nic's binaries ;)

[yokem55]

umaniac's binaries do, and they come strait from cvs.....

[uManiac]

I just posted a build in my download section with EPZS enabled. It has alt. curve.

uManiac

[rui]

And i just donwloaded it and tried it with my The Replacements trailer.

I used the alt curve, with low curve agression, and 100% low 200% high, with 25% strengh.

The quality was quite good.

[rui]

To uManiac:

Beware that the Nic's ds filter you have in your site (dated from 22/3) has problems with cpu's that don't have SSE.(at least i have problems with it).

Nic already posted a new version that solves this. You should update your file to the newest one.

[uManiac]

@rui:
thanks for the heads-up. I'll fix it today.

[Koepi]

XviD-02042002-2:
- Gruel's new EPZS and EPZS^2 code activated
- fixed: using "motion search precision 6" really results in using EPZS^2 code (even better than EPZS)

Regards,
Koepi

EDIT:

P.S.: alt. curve compression is built in now as well, was a fresh CVS checkout

[uManiac]

@koepi:
Was there a need to do more than just changing the #defines for search16 and search8 to get EPZS^2 working ?

[Koepi]

@uManiac:

if you want to use EPSZ^2, you have to submit a "PMV_USESQUARES16" via the frame.motion-flag, else you just enable EPSZ. frame.motion |= pmv_usesquares16... (find it in codec.c)

Best regards

[uManiac]

@Koepi:

Thanks

[Isibaar]

Originally posted by Koepi

- code is not yet optimised, thus a little slower (but the result is way better)


well, "way better" is simply an exaggeration. There is no big difference (if any) in compression efficiency between EPZS, EPZS^2 and PMVfast (EPZS^2 maybe a bit better in terms of PSNR), they are all pretty much on pair, with PMVfast being fastest. Because PMVfast is already very good you can not expect wonders from EPZS, especially because EPZS was mainly created as a replacement for PMVfast, which is patent covered...

Maybe gruel comes up with a good combination out of EPZS and PMVfast, but until then EPZS is not really a must-have.

[Koepi]

Isibaar,
it works somewhat better for me as PMVfast, it keeps more blocks static.

Can be only useful for the encodihng I'm doing right now, can be bad for other encoding sessions.

Regards,
Koepi

[avih]

especially because EPZS was mainly created as a replacement for PMVfast, which is patent covered...

well, it's not the only thing that's patented right?

as far as i understand, it's impossible to build an mpeg4 codec without using patents (MPEGLA)... so xvid will always use patents. so is there a special reason to replace pmvfast? maybe because it was easy? :)

cheers
avi

ps.
thanx for starting such a great project (that's xvid, not EPZS ;) )

[Isibaar]

Originally posted by avih

well, it's not the only thing that's patented right?

as far as i understand, it's impossible to build an mpeg4 codec without using patents (MPEGLA)... so xvid will always use patents.


true

Originally posted by avih
so is there a special reason to replace pmvfast? maybe because it was easy? :)


well, we don't want to replace pmvfast at all (btw: EPZS is deactivated by default in cvs).
It is there because: a) it was indeed easy (pmvfast and epzs algorithms have quite something in common), b) out of scientific interest,
c) because the creator of the pmvfast and epzs algorithms, Dr. Alexis Tourapis, told us that EPZS could be better than pmvfast and (last but most important) d) gruel had fun doing it.

[Belgabor]

Hi Koepi,

I have a slight problem which might bwe a bug with your 020402-2 build. I don't really know, if its related to the new motion estimation code or not.

What I did was encoding a TV-captured ep of Visions of Escaflowne with XviD (Half PAL res., default options, at about 78% quality (according to GKnot)). About 5 secs into the video theres a discolored blotch in the picture (its hard to describe, I'll post some screenshots after weekend, was too late yesterday ^^'). It's in the (originally) unicolored face of a girl and as such looks like a skin discoloring, which is neither in the Original nor in the encode I did with nics build 270302.

Other thing i noticed, though that seems to be a more general problem as it was in nics build too, is (hard to describe, too) a pixalization in some picture areas which looks a bit like dithering. This, as far as I could check, only occured at the very beginning. I'll look into it more deeply on weekend and add some screenshots, too.

I know this isnt too helpful yet without the shots, I just wanted to inform you asap. I'll try the 050402-2 build on weekend too to see if its alright with that one.

Regards
Belgabor

P.S: I really like the new properitys page, only thing I miss is an about telling what build it is. Would have spared idiotic me a fuitle

[Koepi]

If you choose the codec in virtual dub there is a buttoon "about" next to "configure" with which you get the about box.
I talked to -h once that this behaviour might be a little irritating but until now this is the first complain against it ;)

Regards,
Koepi

[Belgabor]

Damn, I already though I must have overlooked something embarassing like this ;)

Anyways, these are the screenshots. 050302-2 didn't work at all for me ('compression error -100' in vdub if i remember correctly), but as there are new releases out, i'll check them this evening.

Now to the shots. The attachment in this post shows the 'blotching' effect i mentioned. Included are two frame caps out of vdub, one with the first frame where the effect starts (looks almost like a luma invert block in 3.11) and the last frame, which is as you might have guessed, the last one before a key.

Belgabor

[Belgabor]

This is the other, codec build independent 'dithering' effect. Its hardly noticable if you don't enlarge the pic, but you can see it best around the letters of 'Escaflowne' and around the MTV logo.

Belgabor

[-h]

The dithering seems to be a weird MPEG quantization problem. The blocks are a larger concern.

Is it possible for you to upload a lossless avi of a sequence which, when compressed, exhibits the problem on your end? The last such sequence we saw didn't exhibit problems when recompressed (well not at my end anyway).

-h

[Belgabor]

Sure. I'll do some more experiments this evening and u/l tomorrow.

Belgabor

[Belgabor]

Did some more testing yesterday. I was able to do a short clip that produces the same error(s). Its about 35 Mb (any hint where I could u/l this so you can get it -h?).

As to the new builds. The codec error was my fault (small oversight of the properties changes ;)). The new builds give what is basically the same blotch error, although on a diffrent frame and diffrent place in picture. The dithering error is same in all builds i've used (the new ones i checked were 6.4. Koepi and 5.4. Nic. Both give exactly the same results on the blotch error).

Both errors vanish if I use H.263 quant. (Before I used modulated which led to all frames being encoded as mpeg)

Belgabor

[-h]

Did some more testing yesterday. I was able to do a short clip that produces the same error(s). Its about 35 Mb (any hint where I could u/l this so you can get it -h?).

Ouch. Not sure where that could go, but it'd be quite useful if the glitch can be repeated every time. Someone will get back to you on this..

As to the new builds. The codec error was my fault (small oversight of the properties changes ;)). The new builds give what is basically the same blotch error, although on a diffrent frame and diffrent place in picture. The dithering error is same in all builds i've used (the new ones i checked were 6.4. Koepi and 5.4. Nic. Both give exactly the same results on the blotch error).

Do you have any idea of how far back this error has been occurring? Some rather weird behaviour has been uncovered in XviD regarding degrading P-frame quality over time (and overall actually), it'd help immensely if we knew whether it was always occurring, or a specific build brought it in.

Failing a discovery, it's CVS regression testing for all (wheee).

-h

[Belgabor]

So far I've tested back to Nics 27.03. But I can test backwards all builds I have (which are several ;)).

Belgabor

[-h]

So far I've tested back to Nics 27.03. But I can test backwards all builds I have (which are several ;)).

That would be *greatly* appreciated :)

I didn't realise how fun it might be to keep monthly compiles of XviD, to compare it through time.

The MPEG quantization issue (spotty blocks) is known, but the blotches are scarier and hopefully have only been introduced recently.

-h

[Belgabor]

Oh, then we talked a bit besides each other. Its only the dithering effect that goes back this far. The blotch isnt there before 2.4. (as i wrote in my first post on this thing ;)) so it seems an issue of the new core.

Belgabor

[-h]

Oh, then we talked a bit besides each other. Its only the dithering effect that goes back this far. The blotch isnt there before 2.4. (as i wrote in my first post on this thing ) so it seems an issue of the new core.

Oops! Heh that's a bit better I guess, if a little confusing. There hasn't been anything changed in that low-level an area in that time frame that I can think of.

Perhaps tomorrow when I can think better :)

-h

[Milkman Dan]

-h, please check your PM. I have his clip on my FTP, and the address and login information is there as well. Thanks.

[-h]

-h, please check your PM. I have his clip on my FTP, and the address and login information is there as well. Thanks.

This is cool.

First, Belgabor, could you try the most recent build with this clip and ensure that the artifacts still occur?

Also, which frame do the artifacts appear in?

-h

[Belgabor]

Originally posted by -h
First, Belgabor, could you try the most recent build with this clip and ensure that the artifacts still occur?

Also, which frame do the artifacts appear in?


The most recent I checked was Koepis 060402. (I think thats the most recent non insta-build, isnt it?). The Error occurs on a later frame than in the screenshots i posted (which have the frame numbers in the filenames). I cant remember ecactly atm, cause the file is at home, but it was somewhere in the middle between the first and last frame screenshots i had attached. the error is with the new builds on the girs nose, about right between her eyes. I admit its a bit harder to notice than the error i had with the 020402 build.

I'll check the exact frame this evening and post it tomorrow.

Belgabor

[Belgabor]

News update ;)

the error occurs on frames 269-275 of the test clip.

Some further good/interesting/bad news (depends on viewpoint ;)) I found when encoding the new eps of Escaflowne aired on wednesday:

- The error occurs now using H.263 quantizer, too
- The ep was terribly undersized(40Mb)

I have to confirm/validate those claims, as i found them when i was about to go to bed. Especially the undersizing problem is prolly not XviD's fault, as I havent checked the compressibility yet (= it might be at maximum).

The intersting thing is, i'm pretty sure the error with H.263 now occurs where it showed with mpeg using Koepis 020402 build (the one i posted the screenshots from).

So in fact now i'm confuzzled :confused:

Belgabor

Edit: I just read the 120402 build thread, the new clip i encoded using mvhints, perhaps thats why it shows now with H.263 (i'm pretty sure I didn't use mvhints with the mpeg quant encodes though, have to recheck this evening)

[-h]

the error occurs on frames 269-275 of the test clip.

Cool, things will (might) happen :)

-h

[Belgabor]

Originally posted by -h
the error occurs on frames 269-275 of the test clip.

Cool, things will (might) happen :)

-h

Waho! Thats great :D

The undersizing was, as I suspected, a compressibility problem (~130% ^^')

Belgabor