To Qpel or not to Qpel: That is the question (OT from "Future DivX Products")

[Hyper Shinchan]

Even though hpel is better when the source was a mpeg2 that has not been resized ? hpel has its uses.

In fact. MPEG-4 ASP isn't AVC. Quality can encrease if you use qpel but there are situation where it's not so useful.

[CruNcher]

if you compare directly qpels speed loose vs the enhanced texture preservation quality, you will see that the factor 2 of time needed for encoding is not allways worth it.

[chilledoutuk]

Manao i like you have always thought using qpel when your source is hpel and your keeping the resolution is pointless as you cant create information thats not there.

This is something that irritates me about many h.264 encoders and there forcing the use of qpel which in many cases is not useful and simply uses up bitrate.

Especially if your encoding hdtv content at the original resolution the addition of qpel can be the difference it playing back on some systems and not on others.

[Manao]

h264 is a different story, which ought to belong in another thread. To summarize : the hpel interpolation in h264 is different from the one in mpeg2/4, so the "harm" is done ( don't get me wrong, a sharp hpel is quite better than the bilinear hpel in mpeg2/4, except possibly when the source is mpeg2/4... ), and qpel in h264 is a lot faster than in mpeg4 ( and, particularly, interpolating a qpel position instead of a hpel one isn't that much slower. Deblocking & cabac are the slow factors in h264 )

[skal]

Hi Chilledoutuk and all,

Manao i like you have always thought using qpel when your source is hpel and your keeping the resolution is pointless as you cant create information thats not there.


depends if you want to exactly reproduce the source -including compression artefacts- or not. But for instance, it's not unusual that a MPEG2 movie often shakes a little (very little) due to analog->digital conversion. If the shaking is sub-hpel, MPEG2 will have more problem capturing it, while qpel interpolation (or GMC at 1/16th pel, even!) will be ok with it. And you can gain (not in PSNR which will drop, but in crispness and image stability) by qpel-recompressing a hpel MPEG2 source which exhibits shaking. Now, MPEG4 qpel has mirroring which i find not good personally, prefering h264's unmirrored interpolation. But on the other hand, MPEG4's qpel has larger filter base, so...

well, just my .02cents. As usual, it ends up being a matter of personal taste...
Skal

[Manao]

your keeping the resolution is pointless as you cant create information thats not thereI wasn't thinking about unexisting information. Qpel creates a motion compensation that is necessarily different from the hpel one. So if in the mpeg2 video there was a block that was perfectly motion compensated by another block through a hpel vector, you can't get the same result with qpel, since the motion compensation result changes. With hpel only, you'd have been able to match it perfectly, thus not having to add some coefficients after the motion compensation : you end up coding less informations in those cases thanks to the hpel interpolation. Now, MPEG4 qpel has mirroring which i find not good personallyI do hope nobody finds it good ( and I still dream, at night, to meet the guy who thought of that marvellous idea, just to explain to him my "poing" of view ).MPEG4's qpel has larger filter baseFor the hpel pixels, indeed, though i wonder if 8 taps brings so much in comparison to 6 taps. For the qpel one, I wonder if the successive 8 taps / 2 taps with rounding at each steps gives a sharper picture than AVC's qpel.

[Sagittaire]

and for 720*576@720*400 or 1920*1080@720*400 resize with MPEG2 source ... ???

[Manao]

As soon as you resize your MPEG2 source, qpel becomes a viable option - at least, PSNR wise. Visually, qpel changes the look of the video whatever the source, and that "new look" can either please or displease people.

[skal]

Hi Manao and all,

I do hope nobody finds it good ( and I still dream, at night, to meet the guy who thought of that marvellous idea, just to explain to him my "poing" of view ).

hey, my guess is that the hardwire guys made their "poing" here: with mirroring, interpolating a 8x8 block at qpel pos only requires reading 8x8 pixels from source. Without mirroring, in h264 for instead, you need to read (8+5)*(8+5) pixels, which is 2.64 times more bandwidth. For 16x16 qpel interpolation, it's "only" 70% more reads. Well, they could also have used a random generator to save bandwidth :)

Skal, exaggerating of course.

[Manao]

But I wonder if they ever thought of the consequences on the encoding-side. Furthermore, with a decoder loading the reference frame by slice ( after all, max mv length is part of the level indication, so they had to consider such a decoder ), the actual memory bandwith could have been the same if they just reduced the mvrange by 4 for qpel. That doesn't decrease the number of additionnal reads, but the memory bandwidth stays sane.

Additionnally, I would really like to know why did they think necessary to use 4 steps to compute some of the qpel positions.

Finally, I wonder : does a 8x8 block, mirrored then interpolated as described, looks like the original 8x8 block at all ?

[dwallersv]

Good Gravy, I wish I could understand what you guys are talking about here :D