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

[JasonFly]

Excuse me.
I wasn't very clear but yes I meant I have decoding problems with Nic's decoder.

I agree that ffdshow with xvid decoding works fine.

[kastro68]

My experience...

If you have a clean source(DVD, HDTV) then use q-pel

If your source is VHS, or TV, then don't use q-pel.

[Nic]

if you didn't notice I put up a new build: http://nic.dnsalias.com
Just built from the CVS HEAD, doesn't have the trellis option? Don't know why, maybe I built from the wrong source...

Might help with decoding...might not. Ill look into it more soon. :)

-Nic

[iago]

Hey man, that's absolutely great! Nic is back! :)

PS: Nic, can you please remove that old outdated document of mine from both your beautiful page and the XviD FAQ thread? You know, it's completed its time and shouldn't be taken as a reference anymore.

best regards,
iago

[bond]

Nic
it really seems to be an old one (no trellis, and no b-frame threshold adjustment possible)

[Nic]

iago: Right-O, ill remove it. Probably put up snowbeach's or something :)

@bond: Yup see what you mean...hmmm...Wonder what branch koepi's is from. I thought there was only HEAD and dev-api-4. Better do a search...

-Nic

[iago]

trellis and b-frame threshold are not present in uManiac's 26.06.2003.1100 build either.

Btw, I guess we have gone faaarrrrr off-topic, hehe!.. Let's start a new thread for Nic's new build to celebrate his return! ;)

[BoNz1]

Well, just a question, has anyone had a chance to look at the code in Isibaar's branch? It is supposed to contain an asm optimized quarter pixel code, fast b-frames along with dynamic quarter and half pixel switching (which I think, before around december was used in dev-api-3 but then taken out because it wasn't exactly spec compliant, IIRC) and some nice postprocessing, I think for cartoon mode. I downloaded Isibaar's branch yesterday just to have a quick peek but I understand very little of the code so it isn't much use. I read somewhere awhile back that some of these things would make their way into dev-api-4 for the 1.0 release. Maybe quarter pixel in this branch will produce the same quality but at least it should be a little faster, ;)
EDIT: BTW nice to see that you made another build nic, I always love your builds since they always are considerably faster on my machine.

[Selur]

started a new thread about Nics build here (http://forum.doom9.org/showthread.php?s=&threadid=57727).

Cu Selur

Ps.: the stuff about "Isibaar branch" sounds interessting

[kastro68]

What does "IIRC" mean?

I've seen people use it frequently on this forum, but I'm not familiar with this jargon.

[bond]

good question :p

btw. what does afaik mean? :D

[Nic]

If I Remember Correctly
As Far As I Know

Please search the web for them next time.

[iago]

Anyway, as a sharp u-turn to the topic, it seems that xvid decoder that comes with nic's latest build (16/07/03) decodes qpel correctly, i.e. without smearing, which is very good! ;)

regards,
iago

[JasonFly]

Sorry but for me, the new decoder doesn't solve the problems than I have with qpel or at least what I think is due to qpel(I have been told in the forum that my problem was probably due to qpel.Besides, ffdshow solve the problem.

Sorry for this bad news.

[soujir0u]

I have just started using qpel in my encodes, and I must say that it really helps in video where there is a lot of smoke and fading scenes. I use it together with Andreas 78er matrix, and at high bitrates the quality is really good!

[sneeky]

I have noticed huge compression gains using Qpel in
scrolling film credits. I process credits separately
and at constant quantizer (typically q=5, 6, or 7).

I have seen this result in the 2 instances I have
tested it. I am using Koepi(05042003) build of Xvid.
The credits are scrolling white on black. No luma
masking or GMC used.


For 5'05" of credits, at q=7,

16.3MB file (no qpel)
9.8MB file (using qpel)

I see no obvious difference when viewing the encoded clips.

Interesting...

[communist]

www.acronymfinder.com
For all the IIRC AFAIK and whatnot ever abbreviations ;)

[deXtoRious]

Does the newest ffdshow decoder get rid of the "smearing" effect for qpel?

[kilg0r3]

Originally posted by communist
www.acronymfinder.com
For all the IIRC AFAIK and whatnot ever abbreviations ;)
darn! ffdshow is not listed ;)

[ominte]

Just wanted to post some early results I've been having with dev-api-4. I ran a qpel test without b-frames and the PSNR increased, the test was only minor though (just 244 frames). However the results do look promising.

Without qpel - PSNR Avg = 42.2687
With qpel - PSNR Avg = 42.6030

I guess this is a welcome change from de-api-3 in which qpel almost always decreased PSNR :)

[Koepi]

@ominte:

can you give the numbers for my latest build please to verify that qpel decreases PSNR? (The same test clip you used for dev-api-4 preferrably)

(It's the first time i hear that, so i want some backup of that thesis if you don't mind :) ).

Regards
Koepi

[Nic]

sysKin has often said that QPel decreases PSNR. Although it sharpens the image, no matter what he tried it decreased PSNR for him, even using a new fancy filter didn't help :(

@kilg0r3: lol. Does anyone actually know what the ff in ffmpeg stands for ;)

-Nic

[RadicalEd]

I've always wondered that myself :/
Fast and free maybe

[JimiK]

In my last test with dev-api-3 (latest Koepi 2406) QPel always increased PSNR. But I haven't got the actual numbers anymore. Still I have to say: I don't trust PSNR and QPel visibly increased "background floating" (no, I did not use ffdshow).
Best regards,
JimiK

[ominte]

I must apologise Koepi it seems my statement about your latest build was wrong:-

Without qpel - PSNR Avg = 42.2543
With qpel - PSNR Avg = 42.6160

I must say this was a surprise to me. I remember doing many tests using older builds with qpel and PSNR would almost always decrease. Maybe the lack of bframes in my test has some influence?

[Koepi]

It also will depend on the source. Try some different clips and your results will vary i think :)

Regards
Koepi

[Acaila]

Just to show that ominte isn't crazy (:D) personally I've never seen QPel increase PSNR on any sources that I've tested it on. As I normally only encode DVD sources I wonder if anyone can tell me what type of source one needs to see an increase in PSNR? Or is it just very content specific and have I just been very unlucky?

[ominte]

@ Acalia

Well the source I'm currently testing is from DVD, it's Conan The Destroyer. The only unusual thing about the source is the amount of noise in the film due to its age.

@ Koepi

I will perform some more testing later (I am currently studying for exams)however it would be nice if we could narrow down the situations where qpel does increase PSNR.

[ChronoReverse]

Just did some test encodes with a 2:33 long clip (the same that I've been using for a while) using dev-api-4.

( note: I'll post actual PSNR numbers later... or maybe not, since I only have average and not the OVERALL PSNR since I can only use compare() )

All encodes done with Bframes 1/175/100 and VHQ4

With this I found that Trellis increased the PSNR and qpel decreased it substantially.

Now, my clip has a LOT of motion, lots of "tv static" transitions as well as multiple transparent backgrounds moving orthogonally simultaneously and is also animated. While I've allocated the equivalent of more than 4000kbps to it, this is really a rather low bitrate (640x480, 30fps, stupidly hard to compress content). Oh yeah, did I mention that most of it is rather bright?

Anyways, considering how poorly qpel performed (a full 0.5db), can it be safely said that qpel doesn't perform well with the above conditions?



BTW, which situations was qpel "supposed" to improve?


P.S. the three encodes were within 2kb of each other. 79830kb and 79832kb.

[superdump]

ChronoReverse: Qpel in dev-api-4 is apparently unfinished as yet. However it IS working afaik. Disregarding PSNRs, which encodes look better, with or without qpel?

[superdump]

A MAJOR bug in dev-api-4 when using qpel and b-frames was fixed earlier by sysKin. It involved not doing any motion searches when using said combination of settings. :)

[ChronoReverse]

O.o

So when did he fix this?

As for the earlier question. To my eyes, there isn't too many differences. The most noticeable difference was that some of the smooth colour gradients in the background was noticebly more blocky with qpel enabled.

BTW is Adaptive Quantization what used to be called Lumi Masking? It reduced the Average PSNR by a full decibel but it looked better to my eyes. When I looked at the frames individually, it looks like the some of the realy dark frames (or even practically black) had much lower PSNR values. This is what it's suppose to do right?

GMC seems to raise PSNR although I still don't see much difference. There was a part where a perfectly static image is movedback and forth smoothly and I suppose a few bits were saved there.

[superdump]

He fixed it sometime this morning I think.

Adaptive quantisation used to be lumimasking, you are correct. It is a work in progress currently and will get much better if a certain addition can be made. It currently works as follows: if a frame is bright then a higher quantiser is used on very dark blocks. It's as simple as that. But it will be developed to something much more complex which gives much better results I'm sure, and then lumimasking will just be a very small part of it, if it is kept in at all.

[ChronoReverse]

Ugh, I guess it time to get a fresh checkout and recompile then :( ;)

Still, it's interesting to see how XviD is heading. I wonder how the Cartoon Mode is working out.

[superdump]

Apparently cartoon mode has already been coded, if I understood what sysKin said. I don't know why it hasn't been included yet though. :) We'll see. It'll be interesting I'm sure.

[BoNz1]

I'm sure a lot of people have looked at the way that ffmpeg does quarterpixel and IMO it is much better. It does not exhibit the smearing that XviD does, the final result is less noisy (but probably the default MPEG matrix is different, so, hard to say for sure), also the background is much more stable not jumpy. I understand that ffmpeg uses simple idct which XviD does not. I also understand that Walken is more compatible since more MPEG4 codecs use it. But does anyone know if simple idct is actually better that Walken as far as having a higher PSNR more often? It seems to me that ffmpeg's implementation increases PSNR more often and the visual quality is much better IMO. But, possibly the problems we are having are more related the decoding that anything. I hope someone can figure this out, maybe we won't be able to do too much better with encoding but I think the decoding could be better (if the smearing and extra noise would go away this would make me extremely happy). And I am using XviD IDCT in ffdshow, :D and simple IDCT when using ffmpeg.

[Didée]

BoNz1:

For me, visual quality is still better when XviD is not decoded by ffdshow, but by xvid.ax ("disable" in ffdshow's codecs page) or by xvid.dll ("XviD" in the codecs page).
Smearing and noisy-ness seems to be a little more pronounced through ffdshow, and less through XviD.

- Didée

[RadicalEd]

Originally posted by superdump
Apparently cartoon mode has already been coded, if I understood what sysKin said. I don't know why it hasn't been included yet though. :) We'll see. It'll be interesting I'm sure.

I looked around in the dev-api-4 source and noticed it was there, been meaning to hack it into the vfw and do some testing, but I'm still having trouble compiling. Any known differences between compiling with vc++.net and vc++ 6? :\

[Nic]

I never noticed any problems apart from the whole NASM thing thats been discussed here before (i.e. When converting from .dsp to .sln, vc .net puts in quotation marks where there not needed in the custom build of the .asm files)

-Nic

[RadicalEd]

I'm wondering because a friend of mine is using .net and the latest cvs of dev-api-4 compiles fine for him, whereas 6.0 chokes on plugin_dump, encoder, and xvid.c with these errors (for me anyways :\ ) :

plugin_dump.c
g:\cvs\xvid\dev-api-4\xvidcore\src\plugins\plugin_2pass2.c(963) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
g:\cvs\xvid\dev-api-4\xvidcore\src\plugins\plugin_2pass2.c(963) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
g:\cvs\xvid\dev-api-4\xvidcore\src\plugins\plugin_2pass2.c(969) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64


encoder.c
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(175) : warning C4018: '<' : signed/unsigned mismatch
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(509) : warning C4018: '<' : signed/unsigned mismatch
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(625) : warning C4018: '<' : signed/unsigned mismatch
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(1256) : warning C4102: 'done_flush' : unreferenced label
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(1736) : warning C4018: '<=' : signed/unsigned mismatch
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(1743) : warning C4018: '>=' : signed/unsigned mismatch

xvid.c
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(722) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(722) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(722) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(727) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(727) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(727) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(732) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(732) : warning C4761: integral size mismatch in argument; conversion supplied
g:\cvs\xvid\dev-api-4\xvidcore\src\encoder.c(732) : warning C4761: integral size mismatch in argument; conversion supplied
Error executing cl.exe.

libxvidcore.lib - 3 error(s), 18 warning(s)


I'm blaming this partially on the fact that I'm a total c++ n00b ;_;

[sysKin]

You need recent service pack for VS 6. Available at microsoft.

Radek

[RadicalEd]

sp5
130 mb later we'll see if it works.
Thanks :O

edit..
same errors :\

[BoNz1]

I get some of the same warnings under VS6 sp5 but no errors, I think last time I built it I got about 9 warnings and some of the same ones as you in encoder.c and xvid.c. That was only a couple of days ago. I wonder though which OS are you using? If you are using XP or 2000 sometimes depending on which service pack you have installed for windows the sp5 for vs6 seems to install but it doesn't really. I have had this problem before. I think you had to put certain dlls in different folders and then install to make it work but unfortunately I can't find the readme that explained this. Anyway it was a problem with the SQL debugger. Oh, nevermind found the readme http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/vcfixes.aspx don't know if it applies to you but it worked for me.
EDIT: The part about the SQL debugger is under known issues.
EDIT 2: Didée, I should say that I have tried this as well and while it is a little better its still not right. It is still noisy but exhibits less dancy backgrounds etc.

[BoNz1]

GomGom has made some fairly significant changes to the decoder. None of the improvements were for quality though just for speed. But I would appreciate it if someone could build a dev-api-4 version of xvid.ax. I downloaded the DirectX SDK and I can't seem to get it to work. Not only that but files encoded with dev-api-4 seem to have problems being played with XviD IDCT from dev-api-3 or libavcodec. It makes a bunch of nasty error messages, this occurs with or without GMC. I also would like to give them some feedback on the decoder. Thanks.
EDIT: Of course feedback pertaining to the quality of qpel decoding.

[ChronoReverse]

xvid.ax for dev-api-4 isn't complete. Use the VFW decoder =(

[BoNz1]

Ok, but how is this done. Do you mean ffdshow>miscellaneous and set IDCT XVID? I thought setting ffdshow>miscellaneous>IDCT XVID would use xvid.ax or does it uses the vfw decoder? Anyway doing this crashes explorer and I can't play it. If I set to simple it crashes too but at least I can play it, ;) but of course it looks very bad for qpel. Or do you mean just opening in vdubmod and playing it? This doesn't crash and I can play it fine. Anyway, I don't want to take this thread anymore off-topic. It would be really nice if we could just set the idct to walken right in ffdshow. Oh, well thanks for listening ;)

[superdump]

Make an avs script with...

avisource("<pathtoavi>")

...in it.

If you use ogm or mkv i think directshowsource() should work ok no, of course it won't, duh. That'll teach me for answering at some ungodly hour in the morning, again . Not sure though. No point storing it properly yet anyway though. :)

[RadicalEd]

Originally posted by BoNz1
Ok, but how is this done. Do you mean ffdshow>miscellaneous and set IDCT XVID? I thought setting ffdshow>miscellaneous>IDCT XVID would use xvid.ax or does it uses the vfw decoder? Anyway doing this crashes explorer and I can't play it. If I set to simple it crashes too but at least I can play it, ;) but of course it looks very bad for qpel. Or do you mean just opening in vdubmod and playing it? This doesn't crash and I can play it fine. Anyway, I don't want to take this thread anymore off-topic. It would be really nice if we could just set the idct to walken right in ffdshow. Oh, well thanks for listening ;)

:\
setting the IDCT to xvid does use walken IDCT. That's also all it does, it dosen't use xvid.ax or xvid.dll or anything.
To use xvid.dll to decode, which is what's being suggested, just check Use Xvid under codecs in ffdshow. Alternatively, you could just open it in Vdub, which always uses the vfw dll to decode. an avs with just Avisource("avi.avi") would also work, however directshowsource("avi.avi") wouldn't, since it's using directshow and not vfw.

[BoNz1]

Ok, thanks RadicalEd I understand now, :)

[CruNcher]

@ BoNz1

the problem you expirience is probably that when useing Qpel the image gets sharper (Low_motion) but this also amplifies noise, the reason that this isn't such recognizable with SimpleIdct is that it blurs the image again where Walken stays Detailed and keeps it

Source (Sharp)->mpeg2dec3 (reference idct) still Sharp->h263 (get blurred)-> qpel (sharps noise amplified) Walken (stays sharp)

Source (Sharp)->mpeg2dec3 (reference idct) still Sharp->h263 (get blurred)-> qpel (sharps noise amplified) SimpleIdct (get blurred noise deamplified)

[BoNz1]

Isibaar just committed some new quaterpixel mmx code yesterday, I haven't done any benchmarks with it in comparison to other builds but it certainly seems to be much faster IMO. Anyway, maybe it will give a nice quality boost, I'm encoding a movie right now with it so once it is done I will see, :)

[JasonFly]

I'm waiting your results.
This would be great if quality and speed were both improved.

[Isibaar]

@BoNz1:
The speedup introduced by the new code is rather small (maybe around 5% of overall encoding time: sometimes more, sometimes less depending on your cpu).

And _of course_ there's no quality increase from just the additional mmx code. The new mmx code should produce bit-identical output to the c code (if not something did go wrong ;-)).

@all:
However I understand from reading this thread that there seems to be a huge interest in improved qpel quality and that higher speed is also desired. Well, I'm a bit stunned about the rather bad opinion most people have about XviD's qpel option. I, myself, am of course totally convinced of the benefits from qpel (but well, I just have to be - having developed XviD's initial qpel support ;-)).

I really believe that qpel very often gives impressive compression improvements (and many of my tests prove this) - actually I've just come across two clips so far where qpel did not yield in a PSNR improvement at the same bitrate in all my tests.

However when reading this thread where people state they've never experienced any improvement from qpel, I begin to wonder if I probably use the wrong input material for my tests ;-) I have some ideas what could be done to 'heal' the bad qpel performance for my two test clips, however just two clips is far too less to decide whether I've found a general solution or not.

So I'd suggest to initiate a 'Call for bad qpel clips': If you have a (please short) sample video clip which encoded with XviD + qpel performs worse (preferably much worse) than XviD without qpel (worse = lower PSNR at same bitrate), get some webspace, upload the clip and post the link. Such clips would help me a lot in finding a solution for this problem because my own test base of 'bad qpel clips' is much too small.

I think the worst thing about qpel (besides the slow-down which isn't that bad compared to DivX btw) is its unpredictable behaviour: Sometimes qpel gives great improvements, sometimes not and from time to time it can even decrease quality. I suppose this unpredictable behaviour is why many people prefer to better not use qpel. I really hope we can overcome this problem soon now and finally make qpel a 'safe' feature...

[CruNcher]

@Isibaar

for me Qpel is working as it should i never had any problems, but many people dont take into account that the psnr lose has todo with the motion of the source so if their clips have more high motion then low motion, psnr would get lower as described here.

http://www.mufflastig.com/CruNcher/XviD/QpelMystery.txt

[Tommy Carrot]

Originally posted by CruNcher
@Isibaar

for me Qpel is working as it should i never had any problems, but many people dont take into account that the psnr lose has todo with the motion of the source so if their clips have more high motion then low motion, psnr would get lower as described here.

http://www.mufflastig.com/CruNcher/XviD/QpelMystery.txt

Not really, not the psnr loss is the problem here. We have to accept qpel has 2 effect. One positive (sharper image, more detail, maybe even a little compressibility gain), and one negative (annoying noise around the edges, the image is "dirty"). It's personal opinion which is the stronger factor.

The noise problem is not an xvid only problem, divx has got exactly the same issue, i guess it's the standard's flaw, not the implementation's.

[Selur]

And in earlier it some times caused a smearing effect, which could be another reason why some people do not like qpel,...

Personally I normally use it only when I encode sharp/good input material. ;)

Cu Selur

[JasonFly]

I used to put qpel in all my encodes some month ago, but there where decoding problem using xvid decoder.

I know that ffdshow decode qpel very well but I don't want to use ffdshow.

Does the decoding part has been improved.
Nic's latest decoder(30/07/03 I think) was suppoed to improve qpel decoding but this didn't worked for me.

I must add that the decoding was bad just in some scenes and not along the whole film.Particularly when the motion was complex. This happened two times during Minority report. I'll try to find these samples.

[yaz]

i've never got any seroius(!) problem with qpel. neither on encoding nor on decoding side. i'm a definite fun:-) i use it since implemented.
yes, the problems listed above are (were?) existing but (imho) any of them is so striking as prompted by some user. say, in general, i've noticed the smearing effect only with nose on the screen.

the only problematic stuff i can recall were the lobby scenes of 'die hard 1'. here the texture of the background is quite complex & as most of the scenes were shot by handy-cam (so there is a constant dizzling all over) the effect was clearly visible. anyway, i left qpel on as other parts looked much better with it. imho, it's the problem that cruncher described but here the problem comes from the small but constant movement. & when it turns to a sudden wide movement the look gets really crappy but it's only annoying when watched frame-by-frame.

so, i'm on cruncher's side. imho, the pros are more relevant than the cons. ok, it's quite subjective. say, the noise improving effect cruncher mentioned i consider a pro (that's me:-) but some may not.

the bests
y

[BoNz1]

Sorry, I've been on a much needed holiday for the past week and haven't been anywhere near a computer. But, I'm happy to report that with a dev-api-4 build from yesterday my qpel problems are gone. It seems that once the frame padding bug in image.c was fixed my encodes with qpel look much much better decoded with ffdshow using libavcodec. In fact, there is no difference that I can see at least between using libavcodec and the XviD decoder now visually. The encoded image is much cleaner and doesn't exhibit nearly as much noise as before and the smearing seems to be gone completely. As for the encoding speedup, it isn't huge but it is quite noticable. And Isibaar, I'm going to be encoding about 5-6 movies in the next week so I will definitely be on the lookout for a qpel killer sample, ;)

[CruNcher]

@all

here are some sample clips of a lowbitrate pearl harbor encode especialy the 180 kbps sequence is impressive useing qpel :)

http://www.mufflastig.com/CruNcher/XviD/phagain

[Tommy Carrot]

Originally posted by CruNcher
@all

here are some sample clips of a lowbitrate pearl harbor encode especialy the 180 kbps sequence is impressive useing qpel :)

http://www.mufflastig.com/CruNcher/XviD/phagain

They are indeed impressive. The qpel artifacts are much less bothering than before.

[JasonFly]

I have just tested the "old" qpel feature with "The two towers", and I still notice artifacts. The source is very clean and the bitrate is quite high. These are noticeable only in some scenes and especially when i put my monitor contrast at max.

I'm wondering if these artifacts cannot be attributed to bframes because they loob like that.Maybe a combination of qpel+bframes is bad for quality.I used 3bf/150/100/10

For those who don't have problems with qpel and that put it in all your rips, what bframe setting do you use?

[Didée]

Originally posted by CruNcher
especialy the 180 kbps sequence is impressive useing qpel :)
Indeed, this is neat quality regarding the bitrate.

But immediately, I heard Sagittaire speaking from /off:
No comment needed ...
The winner is RV9 ...
RV9 is the best ... :rolleyes:

CruNcher: Check PM.

- Didée

[BoNz1]

Ok, I have begun my first search for qpel killers. Here is what I have done, I ripped Terminator and used this avs to encode a small clip:

LoadPlugin("C:\Program Files\Avisynth 2.5\plugins\Mpeg2dec3.dll")
Mpeg2Source("C:\TERMSE_SIDEA\VIDEO_TS\terminatortest.d2v")

I then encoded a clip with and without qpel at a constant quant 2. Default settings were used. Here are the results:

With qpel: 4,918KB, Average PSNR (Y U V): 44.09, 46.66, 46.78 Total Average PSNR: 45.84
without qpel: 4,634KB, Average PSNR (Y U V): 45.08, 46.78, 46.90 Total Average PSNR: 46.25

My XviD build I used was from August the 29. More tests will follow. Here are the files, the source http://bonzi520.tripod.com/terminatorsample.m2v with qpel http://bonzi520.tripod.com/qpel.avi and without http://bonzi520.tripod.com/halfpel.avi the difference is very noticable to my eyes, without qpel it is much better. I should say that I can understand why this kind of clip would give any codec problems, the noise, lightning etc.

[CruNcher]

@BoNz1

sorry but i tried to download the m2v sample with flashget didn't work IE recieved file had visual errors Opera didn't work hmm
the file i got with IE 7,38 MB (7.745.394 bytes)

both avi's worked fine

btw you should really don't do this test with constant quant

[BoNz1]

CruNcher, you are right the m2v doesn't work it should be about 9.3MB. I downloaded it with Opera only 7.38MB. Thats what I get for using crummy free webspace, I will fix it later.
EDIT: Ok, I think I fixed it but it seems you can't download yet since they are experiencing technical difficulties :rolleyes:
EDIT 2: Looks like they removed my account since I apparently violated their terms of service. I will try to find another place to put my files. Oh and BTW why isn't constant quant any good? I figured this would be best.

[BoNz1]

Ok, I have gotten more webspace but I have only 5MB per upload now so I can only upload very small test files :( and I had to cut half of the terminator clip. And I encoded my test files again as suggested by CruNcher using the same bitrate aiming for a 2MB file. Here are the results:
with qpel: Average PSNR (Y U V): 43.26, 45.70, 45.76 Average PSNR: 44.91
without qpel: Average PSNR (Y U V): 44.18, 45.86, 45.96 Average PSNR: 45.33
And here is the url for the source file http://www.geocities.com/bonzi5252/terminatorsample2.zip
EDIT: Another killer sample has been put up, I encoded aiming for a 2MB file again. Here are the results:
with qpel: Average PSNR (Y U V): 44.15, 48.54, 49.01 Average PSNR: 47.23
without qpel: Average PSNR (Y U V): 45.15, 48.67, 49.13 Average PSNR: 47.65
Source file can be found here http://www.geocities.com/bonzi5252/bondsample.zip

[CruNcher]

@BoNz1
here is my result


termi high_motion 2863kbps

none: 42.4056, 1.916.396 bytes, 00:00:09.722
qpel: 41.7637, 1.911.562 bytes, 00:00:18.574


so from what i can see qpel is reacting exactly as it should in this high motion scene could you do the same with a static low motion scene ? like people talking into the camera you should see a file increase in the qpel one then, like it is described here http://www.mufflastig.com/CruNcher/XviD/QpelMystery.txt

To hold quality in this sometimes on the edge from low motion to high motion based scenes it would be needed to triggering qpel only in low motion scenes but this is impossible in the mpeg4 standard it would break it and i think it would even do more harm then good cause you would have no compression gain anymore and avg quantization would rise.

[BoNz1]

Ok, here is a low motion scene that shows a lower PSNR with qpel although not as much lower. I was aiming for 350KB.
With qpel: Average PSNR (Y U V): 45.26, 48.94, 49.09 Total Average PSNR: 47.76
without qpel: Average PSNR (Y U V): 45.94, 48.98, 49.14 Total Average PSNR: 48.02
And the source file http://www.geocities.com/bonzi5252/bondsample2.zip

[Alxemi]

Hum, I've been out a few months and now i cannot find the information i need about qpel searching in the forum so i decided to make a plain question here... please don't blame if it has been answered before, i had really tried to find the answer myself... :confused:

So, I remember a few months ago, the qpel decode smearing was out in these circumstancies:
Using a build that uses Simple idct
Using libavcodec in ffdshow with simple/idct to decode

Now everybody uses walken idct, which (i think) is not implemented in ffdshow.

So my question is: How can be now the qpel be decoded without smearing?
Only using nic's-standalone decoder?
No way with ffdshow?
And in the future? You know if ffdshow will implement walken idct?? Does it matter?

:D Maybe many questions, and surely easy to ask :D

Thanks in advance

[BoNz1]

@ Alxemi, ffdshow uses walken IDCT, set IDCT to XviD and it should work. I don't get any smearing.

[Didée]

Imagine you have an archive with self captured+encoded music videos, perhaps more than one hundred in the past two years, each of them done with the 'actually' most recent XviD build.

Now you have a problem! >_<

'Cause in such a case, not even the "include the used xvid.dll & .ax to the disc" trick is applicable ...

Hrmpfff!

... if only the used IDCT was included or indicated in the bitstream ...

- Didée

[Alxemi]

So, the problem that Iago reported at the beginig of this thread is now fixed? It's safe to decode qpel with libavcodec/idct xvid(walken)?

:confused: :confused:

Sorry if i repeat myself, but i only want to be sure...

[Didée]

For me - almost.

Sometimes I find some minor glitches when decoding actual XviD +qpel encodes by libavcodec. "Mini-smearing", one could say.
Sometimes I have the feeling that texture floating is a little more pronounced through libavcodec, but that could also be me seeing ghosts ...

On my main machine, I still prefer "use xvid" in ffdshow ... whereas on the pure playback machine in the living room - good old Athlon 700, hooked to the TV, needs all speed tricks it can get - I decode by libavcodec. *If* there are artefacts left, they don't show up on TV.

Trust *your* own eyes

- Didée

[unmei]

Didée wrote:

Sometimes I have the feeling that texture floating is a little more pronounced through libavcodec, but that could also be me seeing ghosts ...


i have this same feeling with koepi 24/6 compared to may build

..but i still think the 24/6 brought a huge efficiency gain for my anime and i wouldnt want to step back (ah and ppl may think what they want but i used Qpel for all anime since [insert some medieval date here] :)

i dunno if that has something to do with simple/walken/libav though and im quite happy in my ignorance ><

[sysKin]

Originally posted by exorcism
I heard quarterpel didn't even work right yet. Is this not true? Not true.

[primitive]

I just finished an encode of Galaxy Express 999 (old, noisy anime) @ .14bpp and "wall crawl" was very noticable when using libavcodec. The effect became detectable but unobtrusive when decoding was performed by xvid instead.

My script:


#
# acquire
#

clip1 = mpeg2Source("999.d2v")

#
# decomb / IVTC
#

clip1 = clip1.tomsMoComp(1,5,1)
clip1 = clip1.decimate()

#
# filter
#

#
# crop and resize
#

clip1 = clip1.crop(8,2,704,476)
clip1 = clip1.lanczosResize(576,320)

#
# filter
#

clip1 = clip1.mSharpen(strength=15,threshold=10)

#
# return
#

return clip1