Xvid...H2.63 Vs Mpeg

[kastro68]

I have found that Mpeg quantization looks RELATIVELY better at higher bitrates and that H2.63 works RELATIVELY better at lower bitrates.

What are other peoples findings?

[Teegedeck]

Your findings are correct... :) Low MPEG-quants look better than low H.263-quants (H.263-quant 2 looks about the same as MPEG-quant 3), but high MPEG-quants look worse than high H.263-quants

There were thoughts to let the codec switch between quantization methods automatically, but I don't know if the idea was dropped. I'd welcome that very much. -h?

[Koepi]

Teegedeck,

do you know which quantizer presents the "break even" point between .h263 and MPEG quantizers?

I could try to make an experimental build with such a feature. But as good as the idea sounds - it might require 2 first passes... have to see how the size predictability is affected...

Regards,
Koepi

[Teegedeck]

Hi Koepi,

my personal taste says that beginning at quant 4, H.263 is equal/better. But that's as maybe - could you make the threshhold selectable?

AFAIK H.263 and MPEG produce similar _framesizes_. If I'm wrong there, we should perhaps dump the idea because the 2-pass algo would need modifications that aren't worth the trouble. -h made a comparison of codecs and framesizes, perhaps he's tested the different quantizers, too?

[kastro68]

I would welcome 2 first passes as long as it results in better quality and and accurate size prediction.

I end up re-encoding several times myself with divx 4.12 just to get the size right...but i find that xvid is currently just as accurate as nandub when it comes to output size...which is one good reason for switching from 4.12 to xvid.

[Koepi]

Just asked for a little help at videocoding.de and got a reasonable answer:

it's absolutely useless as the overhead produced by that would eat up all bitrate available so we would have to use a higher quantizer again....

So this idea is dropped.

Regards,
Koepi

[-h]

I don't know about the overhead being that big ;) We're talking about 140 bytes for an average VOL header.

The size differences between MPEG / H.263 at low quantizers would more than compensate for that, but I'm not sure I have time to implement it right now. It is definitely a stop-gap measure until we get user-defined quant matrices, though I can see how it would be useful until then.

-h

[Koepi]

Hu. I'll simply try what I can do. This might result in a non-standard branch :-/

Hopefully I can get it to work without modifying the core, but I still have to figure out how to inserv a BitstreamVolHeader, that's all it needs to change the quant_type...

Regards,
Koepi

[Koepi]

At the moment I'm testing a new build of XviD... _with frame based quant_type settings_!

The size prediction should be way more accurate now, since I subtract the overhead for a quant_type change as well! :)

Thanks to Isibaar this was posible, he sent me 2 modified core files that allow for this :)

I'll post results when I have some.

Best regards,
Koepi

[rui]

Huumm.. This sounds interesting :)

[Uli]

...sounds like we will get a GWXviD ( Gee Wizz ;) )

greetz, Uli

[-h]

Sounds neat. I'm hacking in interlacing support at the moment - it'll bump the stream up to "core" profile, but that doesn't really matter since we can still decode it. It just means nothing else can :)

One other thing I've been thinking of doing, is expanding the "simple" frame.quant decision in the 2-pass code. Actually using a table of "average" frame size change when different quantizers and quant_mode's are used should be a bit closer..

-h

[Koepi]

Hm, the actual decision design works very well for me. But it's nice to test the other option...
Btw., we should take a closer look at the nandub stuff ;) If we'd calculate a motion curve we could give more bits to scenes that really need it and take some away were the motion is higher (high motion = the eye can see less details...)

Just an idea, but I#m too tired now, I've to get some slepp. Tomorrow morning the encoding will be ready and hopefully the quality raised a little (since the quality was already very good before it will be hard to tell...) :)

Regards,
Koepi

[Koepi]

Btw., that additional subtracting the overhead for quant_type change was a stupid mistake - the frame size get's reported correctly with all overhead...
thanks isibaar for the info!!!

G'night,
Koepi

[-h]

Btw., that additional subtracting the overhead for quant_type change was a stupid mistake - the frame size get's reported correctly with all overhead...

Yeah I was going to ask you why you were doubling up on what's already in frame.length ;)

Ah well. Tomorrow should be interesting then.

-h