View Full Version : Opinions about the QPel


Tommy Carrot
10th October 2002, 23:59
Well, i played with nic's compile a little. Impressions: amazing, how it's sharper than the other encoded clip without it. Really good, indeed. The same quantizer test is usually have the similar bitrate, sometimes bigger, sometimes smaller. But always sharper and more detailed.

BUT!
Switching on the qpel always gives me some horrible artifacts. Something like ringing on the edges or mosquito noise, but everywhere. With higher quantizer, it's even more visible.
I could presume this for being in alpha phase, but the divx5 with qpel gives exactly the same artifacts (hell, even worse). I thought it's just a bug, as divx5 have many, but as xvid have the same...

This is intentional side-effect of the qpel precision, or just some common bug?

Anyhow, has someone else this problem too, or it's just me? :)

SirDavidGuy
11th October 2002, 00:10
This is intentional side-effect of the qpel precision, or just some common bug?

No!

I don't really see how this is happening, short of a bug. Storing the MV's might take a little more space, but I doubt it would cause the amounts you're talking about.

Mosquito noise is usually the result of quantizing the middle-range subbands heavily. It's weird that you're getting this.

Nic
11th October 2002, 00:19
I havent noticed the artifacts, but ive only done a few tests. However, QPel is not to be considered finished, this was just Micheal's first commit of the code. I expect it will be refined as time goes on, so expect bugs, etc.

-Nic

Tommy Carrot
11th October 2002, 01:14
Originally posted by Nic
I havent noticed the artifacts, but ive only done a few tests. However, QPel is not to be considered finished, this was just Micheal's first commit of the code. I expect it will be refined as time goes on, so expect bugs, etc.

-Nic

Yes, but i got the same noise with the divx5.02, which is considered to be finished. Note, that this issue is much more visible on lower (500 kbit test from vcd source, or 600 from dvd at 512xXXX res) bitrates. At higher bitrate, it's quite clean, or at least not annoying. I've tested it on 2 computers (athlonXP 1700, win98; p4 1800, winXP), and the problem exist. But i guess it is a rare case, which unfortunately happens always with me, because you would notice it, if you would see it, believe me.

(and this happens with every tests i made, different sources, resolutions, etc...)

Acaila
11th October 2002, 05:45
DivX advises not to use their Q-Pel except on mid to high bitrate encodes. This mosquito noise you see could be a fair indication that you're too low on bitrate.
Perhaps XviD works in a similar way?

Tommy Carrot
11th October 2002, 23:24
Originally posted by Acaila
DivX advises not to use their Q-Pel except on mid to high bitrate encodes. This mosquito noise you see could be a fair indication that you're too low on bitrate.
Perhaps XviD works in a similar way?

I think this can be the case. At higher quality (quantizer 2-5) the noise is quite tolerable or even pleases to the eye (like the inbuilt noise effect of divx5), or cannot really be seen.

I simply thought this is an universal tool to enhance the quality at every bitrates (h.264 uses qpel or 1/8 pel, and optimized to real low bitrate). I use xvid not for dvd-backups, but tv-captures, so usually i uses higher quantizer, because quality there is not so important. I guess i will have to live without qpel.:)

Tommy Carrot
12th October 2002, 01:13
Sorry, i can't let it so easy. :D A question to the experts:

The artifacts on low bitrates is coming from the theoretical background of qpel, or it is just an implementational issue (an optimization to speed qpel up, which works for general purposes, dvd-rips(high quality), but not really works for other cases, etc.)?

Thanks for the answers.

sungey
24th March 2003, 23:19
i heard Divx 503 fixed the q-pel bug ... is there a way to make an xvid clip with qpel and let Divx 5 decoder detect it as divx 503 clip? i would like to see how well they fixed the bug ... i know its related to version string embedded in the bitstream..isnt there any workaround for this yet ?