Lastest alpha, GMC + B-Frames + QPEL

[Sirber]

Hi

I did a 2 pass movie with 4 bframes @150, GMC and QPEL. It worked so great! The quality is better than DIVX 5.0.2 Pro. The only problem is the smaller size (I wanted a 590 MB, but I recieved a 550 MB).

Good work XviD Team :)

GMC works well
B-frames are better than DIVS

I made "The Rock" with 2 OGG stream (French and English) @ 75 kbps for "testing only ;)" on a 700 MB.

It's too hot!!!!!!!!!!

[duartix]

The only problem is the smaller size (I wanted a 590 MB, but I recieved a 550 MB).Check your first pass size!
You are probably maxing out the codec.
If so, increase your resolution.

[Asmodian]

I have actually noticed slightly undersized files (~8MB undersized with a target size of 200MB for an ~25min episode @ 608x448 24fps) with Koepi's 18112002-2 build and with the instant build from the 19th (I haven't finished the encode with today's build). I am sure the codec isn't maxed out as the average quant is >3. I was using B-frames 3@200 (w/ divx5 compatibility), chroma motion and q-pel.

[jpl]

I think it is possible that you could be maxing out the codec. You have B-frames set to 3@200. That means you could have up to 3 consecutive B-frames with a quantizer 200% higher. If the quant is 2 then you would wind up with a B-frame of quant 4, and if you had maximum utilization of B-frames (not very likely but still possible) you would have close to 75% of your frames B-frames.

[Asmodian]

I actually looked at the debugview output, the highest quantizer used was 10 with about 1000 quant 2's 16000 quant 3's and 10000 quant 4's with everything else droping off from 500 at quant 5 to 1 frame at quant 10.

[Alestrix]

I'm also experiencing freeze-frames (or stall frames or whatever they might be called) once an audio stream is muxed in. The ogm plays fine without sound, but hangs on occations once audio is muxed in. I used both OggMux and the VirtualDubMod to multiplex the vorbis audio into the video.

- aL

[Sirber]

The new alpha version from yesterday crash on the first pass with the same settings I used after ~100 frames.

@Alestrix

I never had freezing frames. What settings did you use?

[Alestrix]

I don't have it written down but I think it was
b-frames 3@175
gmc
qpel (it works w/ bframes since the 18/11 build, doesn't it?)
2-pass, alternative curve compression, but at the end codec turned out to be maxed out. But this didn't really matter since the filesize was very close to the desired one and I just reencoded the audio at higher quality.
I used VDubMod 1.4.11 and the ogm container only and worked in YV12 colorspace.
When playing back with XviD, I only get like 10fps, but ffdshow plays nice.
btw: the lastest ffdshow20021118 crashes the player (WMP and MPC) the instant I try to open an XviD, reverting to 20021113 solved at least that issue.
So without audio the file plays nice, but once audio is muxed in, I get freeze frames every 30 seconds or so which are gone once an i-frame occures.
I tried both OggMux and VDubMod to mux in the vorbis stream and the players use DirectSound (not Waveout) to play back the audio.

- Alex

Edit:

PS: I never had this problem occur to me before I tried b-frames. My current encode is w/o bframes again (but with gmc, qpel, chrME, and luma-masking). I'll be able to report my results in about 15 hours.

[iago]

Imho, at the moment, best possible results can be achieved with the latest developer build XviD.Alpha.20.11.2002.2300.exe from uManiac's site! All options work without any problems and no more weird decoding problems! Give it a try! ;)

regards,
iago

[-h]

I don't believe that GMC does anything at the moment apart from hurt quality. Has anyone tested it to do otherwise?

-h

[iago]

Originally posted by iago
... All options work without any problems ... -h

You're right, what I was referring to were b-frames and qpel actually. I didn't test GMC.

iago

[mikeson]

@-h

I've tested GMC, B-frames and Qpel with build 18112002 from Koepi and I didn't noticed any problem or artifact. Maybe I'm watching wrong. So what should I see if there would be any problem?

Now I'm testing the same movie with build 21112002 from Koepi, but it will be done tomorrow morning.

[-h]

I meant that GMC currently almost *never* performs better than normal ME, i.e. any frame you choose would require more bits for the same quality when GMC is enabled.

That's probably not what you want to do.

-h

[Sgt_Strider]

Originally posted by iago
-h

You're right, what I was referring to were b-frames and qpel actually. I didn't test GMC.

iago

What are your b-frame settings?

[Sgt_Strider]

Originally posted by -h
I meant that GMC currently almost *never* performs better than normal ME, i.e. any frame you choose would require more bits for the same quality when GMC is enabled.

That's probably not what you want to do.

-h

I'm a noob to encoding but are you saying that GMC doesn't help with picture quality at all and that it only hurts picture quality? If that's the truth then what's the point of even using GMC?

[NuclearFusi0n]

Originally posted by Sgt_Strider
I'm a noob to encoding but are you saying that GMC doesn't help with picture quality at all and that it only hurts picture quality? If that's the truth then what's the point of even using GMC?
Well, it's a pretty new feature to XviD, and is still being worked on. It will get better and better as development progresses. For now, the just making it WORK is important. making it work WELL will be done after it starts working

[-h]

Exactly - the GMC framework was added so that XviD can produce and decode *valid* GMC data. However the current GMC encoding code is so primitive that it's almost useless for anyone to use in an actual encode.

And yes, it will get better over time. No one *ever* said that dev builds would give you good quality, the point of dev builds is so developers can play with new features that potentially harm quality. If users enable options that result in bad quality, well that's the risk they run.

-h

[Sgt_Strider]

Originally posted by -h
Exactly - the GMC framework was added so that XviD can produce and decode *valid* GMC data. However the current GMC encoding code is so primitive that it's almost useless for anyone to use in an actual encode.

And yes, it will get better over time. No one *ever* said that dev builds would give you good quality, the point of dev builds is so developers can play with new features that potentially harm quality. If users enable options that result in bad quality, well that's the risk they run.

-h

Even Divx 5's GMC implementation is crap?

[-h]

Even Divx 5's GMC implementation is crap?

DivX 5 is a different codec to XviD, so its implementation of GMC is different too.

XviD's is mostly useless at the moment because no effort has been made to improve it yet. The same can not be said for DivX 5 because I have no idea how their implementation works. GMC isn't inherently a "useless" feature - if it's implemented properly it could result in some significant bitrate savings.

I haven't experimented with DivX 5's implementation myself, so I can't comment on how good it is. I have read that it has a bug with regard to the spec however.

-h

[OUTPinged_]

I haven't experimented with DivX 5's implementation myself, so I can't comment on how good it is.

I did. I was getting lower speeds, a tiny bit lower PSNR (45,14 to 45,28 if i recall correctly) (i couldnt tell two encodes apart visually), and about 0.1% bigger size :/

That was with 5.0. After some tests i dumped 5.0x codecs as i didnt like it. Also, messing with alt.cc was alot more fun.