[Mesa-dev] [PATCH 0/2] Implement lanczos interpolation filter

[Andy Furniss]

Nayan Deshmukh wrote:
> Hi Andy,
>
>
>
> On Wed, Sep 21, 2016 at 9:30 PM, Andy Furniss <adf.lists at gmail.com> wrote:
>
>> Andy Furniss wrote:
>>
>>> Andy Furniss wrote:
>>>
>>>> Andy Furniss wrote:
>>>>
>>>>> Andy Furniss wrote:
>>>>>
>>>>> bz2 compressed vid showing the issue -
>>>>>>
>>>>>> https://drive.google.com/open?id=0BxP5-S1t9VEEUE5sbUFBV20zSms
>>>>>>
>>>>>
>>>>> To be clear this is just the test rez vid I used so you can
>>>>> possibly recreate the issue your self.
>>>>>
>>>>
>>>> Hmm, interesting, with bicubic, hqscaling=1 this vid behaves
>>>> differently with mplayer compared to mpv, the latter looks like
>>>> it's scaling a bit, maybe there's an off by one somewhere in mpv
>>>> code.
>>>>
>>>
>>> I don't know if it's the cause, but looking for differences between
>>> mplayer and mpv it seems that mpv sets video mixer height so it's
>>> divisible by 32 but mplayer doesn't. For this 720p sample it uses 736
>>> and mplayer uses 720.
>>>
>>> vdp_video_mixer_create(1, 1, {11}, 3, {0, 1, 2}, {1280, 736, 0}, -)
>>>
>>> for output surfaces and render calls it uses 720.
>>>
>>> So does the bicubic code see/use this 736 somewhere?
>>>
>>
>> To answer my own question - it does.
>>
>> Putting a printf in vl_bicubic.c create_frag_shader video_height = 736
>>
>> We intialize the filters with height of video mixer, So that explains the
> difference.

Yea, is there a way around it though? I assume what mpv does is legal.

> I was not able to make any progress with offsets nor the artifacts. Can you
> try
> testing the lanczos filter by removing this line form create_frag_shader :-
>
> ureg_SUB(shader, ureg_writemask(t_array[1], TGSI_WRITEMASK_XY),
>              ureg_src(t_array[1]), half_pixel);

This causes a shift in the opposite direction.

Maybe offset is the wrong way to describe it as there are no lost
pixels at the edges - they are just blended a bit and the whole image
appears to move slightly when overlaid with one made with other scaling
methods. Up and left with the above removed, down and right with above
in place. This happens even on an un-scaled image but is more obvious on
one scaled up. IIRC bicubic used to do this at one stage but doesn't now
at all for un-scaled, maybe a tiny bit for scaled up.

The above change makes no difference to artifacts. I also managed to
get 2 to artifact and of course 2 and 4 still have white line artifacts
sometimes, which I thought may be to do with the offset - but they are
still there (same place) with the above removed, so I guess not.

There is still the issue with all levels eating the 1:1 pix detail on
the vertrez720 vid I uploaded when unscaled.