Quarterpel

[iago]

Since this powerful feature (which I really like especially for the reason that I've always preferred a bita graininess to blockiness) seems to be disregarded recently and the information concerning it is mostly scattered in different threads, I thought that it might be useful to start a fresh thread about quarterpel to share experiences, trace bugs (if any), and discuss the advantages and disadvantages of it in different scenarios.

Well, as a quick start to a new flamewar ;) -> to keep the quality up for lower resolutions and to increase compressibility in low-mid motion clips I suggest 'using' quarterpel!

regards,
iago

[Nibor]

I agree with that at high bitrates :D (oooh, not yet a flamewar ;))

But!!! (<- hehe)
I would not suggest quarterpel in encodes with a bitrate lower than 800 kBit/s ! IMO the result is not pleasing, motion in some areas looks like kinda moving pixel army :)
Anyone doesn't agree? :devil: ;)

Greets,
Nibor

[frodoontop]

I used to be a big fan of quarterpel. It really gave me a sharper picture, like it's supposed to. But... It's quite heavy to encode and decode, so I don't use it anymore. Maybe I'll use it again when I have a faster machine. (Currently running on 800MHz)

Quarterpel did let me down on some scenes with a lot of smoke or the like. I didn't like it's graininess too. Especially not with movies containing lot of noise already in the source. But that's just my humble opinion.

Fortunately we do now have VHQ, which does deliver me a sharper picture too. This is also heavy to encode, but not to decode :D . VHQ didn't prove to have any problems so far. So given my computer's limited capacity I prefer VHQ.

[iago]

Ah, forgot to mention that as a proper viewing environment to spot the benefits and harms of using quarterpel (just like in the case of black-block hunting or judging the true quality of an encode), I also suggest turning off the lights at night prior to sitting before your monitor screen (or either viewing your encode on TV or doing a full brightness up on your monitor for daylight conditions)! :D

regards,
iago


edit1: At least that's what I do to decide on the quality of my encodes. Btw, smearing is still a problem as I mentioned in the ffdshow thread. Only the built-in XviD decoder (in Koepi's and uManiac's latest builds) doesn't cause smearing when viewing qpel encodes. (Of course using "XviD" -not "libavcodec"- in ffdshow codecs tab for XviD decoding also works.)

edit2: I know that "quality" is quite a subjective matter and personal tastes differ, therefore one's own eyes are probably the best measure of quality ;).

[Koepi]

Did you set IDCT to "XviD" in ffdshow? In the latest builds i switched back to walken idct - which causes smearing (or at least suboptimal results) when being decoded with simple idct.

Regards
Koepi

[iago]

Koepi,

Yeah, I know walken idct is used again in your latest builds, and I have tried both XviD and Simple IDCT, but both of them cause the same problem when decoded with libavcodec, which is quite strange actually (because I remember Isibaar mentioning this issue was resolved when he was talking about Walken IDCT in another thread).

Only decoding with XviD solves the problem.

I think, at least for the time being, choosing "XviD" for both Codecs/XviD/Decoder and IDCT is the most reliable way for playback using ffdshow.

edit: the exact same problem occurs with umaniac's latest dev. binary (XviD.Alpha.26.06.2003.1100) as well. Neither XviD nor Simple IDCT helps when using libavcodec. With XviD decoding everything is OK.

[HarryM]

Originally posted by Koepi
Did you set IDCT to "XviD" in ffdshow? In the latest builds i switched back to walken idct - which causes smearing (or at least suboptimal results) when being decoded with simple idct.

Regards
Koepi

Is it possible autodetection of Walken/Simple IDCT at decoding?

[Didée]

No, this is not possible with any encoding you did up to now, because of one simple reason: there is no flag in the bitstream indicating which IDCT was used. However, the idea of including such a flag has come up in the XviD mailing list, IIRC. It's only a little late ...

I vote for implementing a "use simple idct" checkbox in the decoder property page (which was Koepi's idea).
Since ffdshow is, for me, no reliable decoder (-> qpel, -> "below-16"-matrices), I actually have two batch scripts on my desktop, that switch between the 'simple' and 'walken' versions of XviD's DLL and AX by de-registering, renaming and re-registering ... not exactly elegant, but at least it works.

- Didée

[YY1020]

I agree with that at high bitrates (above 1000kbps),but i would not suggest quarterpel in encodes with a bitrate (below 900kbps)!!

[iago]

I agree with that at high bitrates (above 1000kbps),but i would not suggest quarterpel in encodes with a bitrate (below 900kbps)!!Depends. Rather than bitrate, compressibility and quantizer range is important imo.

Bitrate alone is no measure for anything. A bitrate of x (say 1200 or 600) for what resolution, for what clip, etc.

[iago]

To take the argument even further regarding the benefits of qpel (especially for lower resolutions such as 512*xxx, 544*xxx, etc. where mpeg-4 artifacts such as blockiness in flat areas, black-blocking, etc. are much more likely to occur due to lower detail level than a higher resolution), I suggest using qpel with LanczosResize and MPEG quantization (!), and without any filtering, even without b-frames, as long as you can stay within a 1stPass/2ndPass ratio of ~2 (maybe a bit lower ;)).

regards,
iago

[Tommy Carrot]

Originally posted by iago


Well, as a quick start to a new flamewar ;) -> to keep the quality up for lower resolutions and to increase compressibility in low-mid motion clips I suggest 'using' quarterpel!

regards,
iago

Sorry, i have to disagree. :D

At lower resolutions the smearing is even more annoying. At HDTV resolution the noisy edges and most of the qpel artifacts are quite unvisible (at least on my 17' display).

I was quite fan of the idea of qpel, because the detail gain is really there, but the smearing is became more and more annoying to me. So i don't use it anymore.

IMO, until a codec uses DCT to transform (floating point transformation), the smearing will be there and could not be avoided. This is why the h.264 is so promising.

[iago]

Sorry, i have to disagree. :DSure, you might. There are sometimes various discussions around here that I disagree too (the general approach to "noise" for instance ;)).

Of course there are many factors affecting one's encoding preferences, from the cpu/system power to the viewing environment, from personal taste to the archiving medium and target space, etc.

I work on a Celeron 900, generally do 1CD encodes (why else would one resize a 1.85:1 movie to 512*272 for instance) and watch them either on my 17" monitor (with 800*600 or 1024*768 display) or with TV-out on a regular TV, if you know what I mean. (Also, I personally neither like nor encode anime for instance.)

Regarding smearing (if we are talking about the same problem, which for example ffdshow libavcodec-decoding exhibits atm), using the codec's built-in XviD decoder solves the issue. But if you are referring to the graininess effect introduced by qpel it's definitely more pleasing for my eyes than the dancing dct blocks in my viewing experience.

Of course I don't imply that qpel looks "worse" on higher resolutions and higher bitrate encodings. I just say that an encode with qpel at a lower resolution (sometimes it's a necessitty to reduce your resolution to hit your target size with decent quality) together with sharp resizing looks better than an encode without it.

Anyway....

regards,
iago

[Tommy Carrot]

Hmm, i always thought the terms "smearing" and "increasing of noise" are the same. Maybe i'm wrong?

Anyway, here is my opinion: The qpel has a positive (sharper image, more detail) and a negative (noisy edges) effect. It is a personal preference which weights more. To me, the later, so i don't use it.

I doesn't matter which decoder i use. If i decode with virtualdub, the artifacts are still there, because they are created on the encoder-side, not with the decoder.

[iago]

If you decode a qpel XviD file (encoded with Koepi's or uManiac's latest builds) first with libavcodec and then with XviD decoder, you can see what I mean. So it seems that there _is_ a problem on the decoder side.

Also, I'm inclined not to call graininess an 'artifact' but only an effect of qpel. Decoded with VirtualDub the effect is as it's supposed to be, just like when decoded with the built-in XviD decoder. Smearing artifacts occur with libavcodec decoding atm.

But yes, I agree that it's a personal preference after all. (Ah, gimme some more noise, noise, noise... Where art thou SansGrip man, where have you gone!? :D)

regards,
iago

[ominte]

iago if you prefer noise so much I suggest you ditch the qpel and encode without it, then when decoding add in noise with ffdshow. In my opinion this added noise decreases the effects of artifacts and increases perceived sharpness of the image. Just a preference of mine.

[iago]

ominte the smart,

You can do as you say to cover up the artifacts in shitty encodes. It's not for me. I watch my encodes "without" any post-processing and my preference is to get an encode with minimum artifacts. Concerning noise, I prefer to have or preserve it -as much as possible- in the "encode", not add it with post-processing -which I don't use- during "decode".

[drebel]

Personally, I can live with the amount of noise that Qpel preserves as long as I have my movies (especially the old ones) de-noised accordingly first.
IMHO, I think Quant matrix plays a significant role in the final result. I find some combos work great and others...not so great.

regards,
george

[ominte]

You can do as you say to cover up the artifacts in shitty encodes. It's not for me.

If your so "concerned" about artifacts then I can't see why you continue to use qpel. Even with the increased sharpness of qpel the increased number of artifacts (which you claim to hate) still outweigh the benefits in my opinion. Although I made mention to noise possibly being used to cover up artifacts in encodes this was not my main idea. The reason I personally use noise is to recreate the film noise apparent before filtering my source. This way I can filter my source making it easy to encode/compress with XviD thus reducing artifacts. Overall, the final result I am left with is less artifacts and the original film noise when decoding, the best of both worlds.

I would also like to know what "shitty encodes" you are refering to? You of all people should understand sometimes it is neccessary to put up with artifacts in an encode whether it be to save space or due to the limitations of the source or mpeg4 compression.

Concerning noise, I prefer to have or preserve it -as much as possible- in the "encode", not add it with post-processing -which I don't use- during "decode".

There is nothing dishonorable about using postprocessing when decoding like you seem to insinuate.

Finally you do not have to take on board any of my ideas but I hope you at least test them before further commenting on their usefulness.

[Koepi]

Ominte,

don't react like someone insulted you. This isn't the case.

Of course you can go your postprocessing way. BUT don't think that everybody wants to do it that way.

If you only get artefacts with xvid/qpel there must be something wrong with your setup. I use qpel very often and have _no_ artefacts (well, of course a little more noise - which is good, as I can see we agree on).

Koepi

[JimiK]

I have to stand up for ominte. IMHO iagos post was a bit sharper, while ominte stayed quite cool. I know that iago and you are quite good friends and I greatly respect iago, but ominte has done nothing wrong.
Back on topic I have to say that I use a similar approach to omintes. I can't point the finger on it, but I just don't like the looks that qpel produces. So I'd rather save some CPU power and go without. Of course all that is very subjective. And of course, adding a bit noise to the picture while playing is changing the picture. But even though it should be called so by definition, would you really call this "postprocessing"? :)
Best regards,
JimiK

[Koepi]

I'd say you should _really_ try different quant matrices with qpel, you'll see that i.e. MPEG quant and qpel are awesome. h263 and qpel is only good if the sources are clean IMO. And so on.

But I think here it comes to the usual "taste is different from person to person".

(And to your OT: just because I consider iago as friend this doesn't necessarily mean I am biased and don't read correctly. Read my post again, I just tried to cool down the heat that seemed to come up :) )

Koepi

[Didée]

Originally posted by iago
(Ah, gimme some more noise, noise, noise... Where art thou SansGrip man, where have you gone!? )
-----------------------------------------
Concerning noise, I prefer to have or preserve it -as much as possible- in the "encode", not add it with post-processing -which I don't use- during "decode".
SansGrip is missing and missed here in the forum, yes.

However, for encoding I found that adding noise is mostly useful when using h263 quantization - for mpeg quantization, which I use almost exclusively, I found no benefits.

For playback, I prefer to add some very light noise. Usually, in ffdshow I set "mpayer noise" to "11" (practically invisible) or "12" (the noise "disappears" after some seconds). Such light settings don't disturb at all, but really help a lot in stabilizing some leftover "floating walls" and such.

Hmmm, this post was not about qpel, again ... :o

- Didée

[iago]

This way I can filter my source making it easy to encode/compress with XviD thus reducing artifacts. Overall, the final result I am left with is less artifacts...(ominte)This is just a common misunderstanding. Of course, sometimes it works. But an increase in compressibility (achieved by especially unnecessary filtering) does not always/necessarily bring a quality boost and reduction in artifacts. On the contrary, sometimes it might introduce even more artifacts, especially at the low-detail, low-luma regions, which are the most tender areas of mpeg4 compression.

You of all people should understand sometimes it is neccessary to put up with artifacts in an encode whether it be to save space or due to the limitations of the source or mpeg4 compression.(ominte)Sure. If only you had read the whole thread. What I said is no different from this as a reply to Tommy Carrot's first post. But with XviD and its powerful features it is possible to minimize artifacts adopting different encoding approaches for attaining particular goals.

Finally you do not have to take on board any of my ideas but I hope you at least test them before further commenting on their usefulness.(ominte)It's just ridiculous to imply that I state my opinions without any testing (of other alternatives, settings, etc.). Just ridiculous! Do you really think that I have only encoded "with" qpel so far, and tried nothing else?


JimiK,

Yeah, I have always considered Koepi a real friend here. I guess you have no objection to this? Still, this is no valid ground for your implication that he posts his opinions on this issue just to support "iago, his friend" ;).


All,

At least it's nice to see some common-sense is finally beginning to be exhibited in the general approach to "noise", though not from the same perspective, and if not yet for qpel! ;)


best regards,
iago


edit: ominte, I'm really sorry if my post sounded so harsh, I didn't mean to hurt anyone. Only I thought that your post was representative of many certain cliches, which I am gradually growing extremely tired of replying to.

[ominte]

It's just ridiculous to imply that I state my opinions without any testing (of other alternatives, settings, etc.). Just ridiculous! Do you really think that I have only encoded "with" qpel so far, and tried nothing else?

I was just implying that you may have not yet tried my idea. I did not mean you had not encoded without qpel.

ominte, I'm really sorry if my post sounded so harsh, I didn't mean to hurt anyone. Only I thought that your post was representative of many certain cliches, which I am gradually growing extremely tired of replying to.

Forget about it, I hardly meant to begin an argument. I just wanted to provide an alternative idea to using qpel. I just hope I haven't upset anyone :(.

Oh and thanks for your show of support Jimik :)

[bond]

qpel gives me much more details and a crispier, grainier picture (even on 1 cd rips) at cost of compressibility (~ 2 - 2,5%) and Speed (~ 1,5 - 2fps)

thats why i use it

although if used together with hvs_good the walls doesnt look that stable (with vhq) any more than with only qpel or hvs_good, they show many small blocks

[iago]

bond,

Try qpel with MPEG quantization and LanczosResize (preferably without b-frames and vhq) to see if it makes a difference regarding those small blocks on the walls that you mention. For me, it makes a difference. Ah, those low-detail flat areas, such as walls, etc ;).

[bond]

Originally posted by iago
Try qpel with MPEG quantization and LanczosResize (preferably without b-frames and vhq)for high bitrates it looks nice but as i am aiming for 1cd encodes these settings arent really usable :(

[iago]

for 1cd encodes these settings arent really usableThey are. As long as you manage to keep within a 1stPass/2ndPass ratio of ~2/1. Without trying, you might never know! ;)

[bond]

ok 'll give it a try

but why did you write than that i should disable vhq and b-frames?

[iago]

but why did you write than that i should disable vhq and b-frames?Since those settings (no filtering, motion search 6, chroma motion, qpel, MPEG quant, LanczosResize, ~2/1 1stPass/2ndPass ratio) "surprisingly" has sufficed "for me" to get the results I want on several encodes :). Of course I'd also resort to heavier guns (such as vhq and b-frames) if they didn't work.

Btw, there's nothing against vhq and b-frames here! ;)

Also, as repeatedly pointed out, personal tastes might definitely differ.

regards,
iago

[bond]

Originally posted by iago
They are. As long as you manage to keep within a 1stPass/2ndPass ratio of ~2/1.hm interesting, but how do you get a 2/1 ratio without filtering and b-frames? -> lower resolution? and if yes, which res do you use (normally)

[iago]

Simply, with 1.85:1 and 1.33:1 AR, I don't insist on 640*xxx resolution for 1CD encodes. 576*xxx, 544*xxx, or even 512*xxx for 1.85:1, and 512*384 for 1.33:1 is enough for me to keep good quality. For 2.35:1 I prefer to use only 640*xxx.

But that's only me, and I'm really a bit tired. Do as you like folks, and of course go with what best pleases "your" eyes! :)

[bond]

hm i now tried it with 7000 frames from matrix with 650kbs

settings:
576x224
Qpel
mpeg
no vhq or b-frames
no filtering
lanczos resize

but i dont think that the output has good quality :( (perhaps i did something wrong compared to iago?)

EDIT: but the walls are "stable" even without vhq ;)

[JimiK]

@iago
I certainly do not object that you and Koepi are friends. Best would be when all people in this forum (and in the world) would be friends. It's also good to see that you and ominte seem to get along very well.

I wanted to post this 6 hours ago, but my PC does not like my modem :) Some questions are already (kind of) answered by bond and iago. And I have to say that I agree with Didee on mplayer noise. But he also said that he uses additional avisynth noise for h263 encodings what is opposite to Koepis suggestion. Here we go with my "old" post:
@Koepi
Now it's an interesting point that you recommend qpel for some matrices and for some only for specific (clean) sources. I did not investigate much, because I didn't like qpel. The point is: I'm going (almost always) for 1CD with 2 Vorbis audio streams. So I'm mostly using hvs-good or now with Trellis h263. Would you recommend qpel for hvs-good? And when going for 2CD's I'm not using MPEG, but hvs-best. How about that one?
As I said, I didn't test much with qpel. What I observed was that without qpel the picture seems more steady (shouldn't it be the other way around?). The problem occurs also in the background when there should be almost no motion, but it's not a iDCT problem. You can also see it without qpel, but not so "heavy". In fact it's hardly noticable, but you certainly know, when you encode movies and you check the quality, you literally "crawl" into the monitor. :) Right now I don't have the time, but sometimes, I'll do some tests with MPEG and qpel.
Oh, one more point, what about the "speckles" in faces Didee mentioned sometime ago. I don't think that anybody has worked on qpel since that. Is this also a iDCT problem?
Sincerly,
JimiK

[iago]

bond,

Have you really read my previous post? ;) Afaik, Matrix AR is not 1.85:1 so 576*xxx is too low a resolution for a > 2.35:1 movie. The real AR of Matrix is ~ 2.50:1 I guess, so try it with 640*256 resolution.

[bond]

i know i also first tried it with 640x256 (as i mostly use this res) and the output wasnt better (even worse i think)

[iago]

He he, OK then, I give up! Qpel is evil, do not use it! ;) He who uses or recommends the use of qpel should be banned or punished or even both! :D

[bond]

no qpel is good (i use it of course)

but i would use it together with vhq and not too sharp resizers (if you are aiming for low bitrates), i am also thinking about switching back to h263 (because of the walls and the picture doesnt look that "dirty" like with hvs_good)

iago:
for me the problem is that while aiming for 1cd encodes imho it doesnt really fit together using bitrate consuming, high detail settings and resolutions (like i would use for 2cds), but without any bitrate saving settings like b-frames or filtering

-> so the output i get doesnt really surprises me (and matrix is a good compressible movie) :confused:

EDIT:
ok, perhaps it is really just a matter of taste :)
With your settings the picture is sharp (of course) but what i dont like is that there is a lot of mosquito noise and the picture isnt really "clear" it's more like that there are "swimming" pixel

but perhaps i am just not "revolutionary" enough and too conservative ;)

[BoNz1]

Ok, since we all seem to be giving our opinions about qpel, I want to my honest but extremely bias opinion. I love qpel, in fact I don't think I would ever even consider doing an encode without it. The picture is _always_ much sharper with it, without it, it is much softer. I often use it for 1 cd rips as well at lower bitrates with higher resolutions I take a little different approach than iago, I really dislike lowering the resolution any lower than 640x whatever for most movies unless of course it is 4/3. Using settings like this it is certainly tough to get something I am happy with for 1 cd you certainly have to use b-frames, vhq, and h263 quants or hvsgood matrix. I typically have to redo movies 3 or 4 times to get something I'm happy with. I do mostly agree about filtering though, I feel a light spatial filtering can help but in general it is better not to use any. I'm doing a 2 cd encode right now with b-frames 0, no vhq, and qpel, the comp test is about 50-55% which is lower than I usually like but I am very interested to see how it will turn out.

[iago]

Any ideas from developers/coders (isibaar, radek, milan, etc.) regarding the playback issues, which seem to be problematic again?

As a repetition, currently XviD quarterpel encodes only playback correctly (without exhibiting the smearing problem) with the codec's built-in XviD decoder (tested with Koepi's and uManiac's latest builds). Libavcodec -neither with XviD IDCT nor with Simple IDCT- doesn't decode quarterpel correctly. Nor does DivX5 decoder when FourCC is set to DX50 (even worse actually).

regards,
iago


Imho, this points to a problem somewhere either on the encoder or the decoder side since Walken IDCT is used in the recent builds and normally such playback problems shouldn't occur any more with libavcodec when IDCT set to XviD, right?

[kilg0r3]

Just a general comment. since by a statement of IIRC syskin, quarterpel in its current implementation is nothing more but a first attempt, I consider it too unstabel for general usage. the fact that the smearing problem seems to be reappearing atm just adds to my conviction.

So I'll just lazily wait for the nextentries in the changelog that regard quarterpel. then I will surely reconsider application of this feature.

[iago]

kilg0r3,

I think that's what I'll do from now on and put a stop to my whining about it! ;) But I really hope more work will be done on this powerful feaure until it's totally safe to use.

regards,
iago

[sysKin]

Originally posted by kilg0r3
since by a statement of IIRC syskin, quarterpel in its current implementation is nothing more but a first attempt, I consider it too unstabel for general usage.Just wanted to say that it definitely wasn't me, and it's not true either.

Qpel is not exactly doing what I hope for, but it's mpeg4 problem, not xvid problem. Today, I run a series of tests that proved (at least to me) that qpel is not buggy. It's doing exactly of what is expected, and it will not get better unless someone gets some brilliant new idea.

Qpel is finished. As I said, I was hoping for more, but what can I do?*

I've been using qpel for all my encodes and I'm happy about it. There is one thing I've noticed in ffdshow - but I have to confirm it - I sometimes get identical smearing with 'xvid' or 'simple' idct, which makes me believe that configuration is broken and ffdshow is using 'simple' all the time.
I'll find out one day.

Regards,
Radek

* <-- Kludge, of course

[bond]

Originally posted by sysKin
Qpel is not exactly doing what I hope forwhat did you hope for?

[iago]

Today, I run a series of tests that proved (at least to me) that qpel is not buggy. It's doing exactly of what is expected, and it will not get better unless someone gets some brilliant new idea [...] Qpel is finished. (sysKin)It's interesting to hear that. That really confirms my opinion that qpel is doing exactly what it's supposed to do (if we put aside the smearing problem caused by libavcodec decoding atm and consider graininess as a natural -and for some of us even desirable- effect of quarterpel) and there's something broken on the libavcodec 'decoder side'.

Anyway, hope that problem gets resolved one day! ;)

regards,
iago

[Nic]

Yup, syskin tried everything to get QPel to perform "as well as it's supposed to". But it never did, PSNR always drops and the image gets sharper. So whether or not to use QPel will always be a matter of opinion and they'll never be a definitive answer.

-Nic

ps
http://nic.dnsalias.com/qpel.txt is the chat log from when me and syskin last talked about QPel. (quite a while back now)

(also check out http://nic.dnsalias.com Koepi redid it for me :) )

[JasonFly]

Seems that qpel isnot buggy.

In fact, that's true that qpel work fine while decoding with ffdshow but Wille there be any improvement in the xvid defaut decoding.

Will it work some day.
I hope I haven't missed anything because the last time I tested Nic's dec was in March and this doesn't worked perfectly.

To developpers: Thank you for all your work.

[iago]

Nic,

Hehe, why didn't you post that chat log before pal? :p

Also, your site is deadly sharp indeed! (Koepi seems to have picked up a new hobby recently!) But I guess you gonna have to adorn that cool page with a new XviD build! Yours have always been faster on my machine though I dunno why! ;)


JasonFly,

Come on man, are you kidding! It's just the opposite with recent builds. Only XviD decoding works with qpel, not libavcodec.

regards,
iago

[Nibor]

I think JasonFly meant Nic's DirectShow Decoder Only..
AFAIK it uses Simple IDCT doesn't it?

@Nic
I'd really appreciate it, if you could do a new Decoder Only DShow Filter, in which you can choose between Simple and Walken IDCT!
I don't like ffdshow, your decoder has much more "style" :D

I'm going on holidays today and when I'll be back, I want to see a news entry on your page, saying something like "New Decoder Only DS Filter out" :p :)

Did I make myself clear ;)
... I have an offer you can't refuse... No not really :p

I wish everybody beautiful holidays!! (those who have)
Nibor