[Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3

[Nayan Deshmukh]

Hi Christian,

A few questions.



On Tue, Aug 9, 2016 at 5:10 PM, Christian König <deathsimple at vodafone.de>
wrote:

> I am more than happy to solve these problems, the Lanczos filtering was
> getting a little stale
> anyway because I was not able to reproduce the problems Andy was facing.
>
> Yeah thought so, the reason is probably that you don't have the necessary
> hardware.
>
> Is that why I need to add a PIPE_BIND_LINEAR to a surface?
>
> Yes exactly.
>
> So I need to use maybe a couple of surfaces alternatively to read and
> write with the filters. This approach should work I guess.
>
> Allocate a temporary surface for each step, apply the necessary filters
> using it and then use the temporary buffer as input for the next step.
>
> See how the deinterlacing filter does this, you should use the same
> approach here.
>
> I would use this order for doing things:
> 1. Median filter for noise reduction.
> 2. Sharpening/blur filter.
> 3. Deinterlacing.
> 4. Compositioning and CC conversion.
> 5. Advanced scaling.
>
>
I need to provide the median filter and the blur filter with a sampler view
and the deint filter requires a pipe_video_buffer. I am not sure how to
acheive this. Any suggestions?

Also right now deinterlacing is the first step and the other steps follow.
But if we perform median and sharpening filter before then we also need to
apply them on the past and the future surfaces that we require for
deinterlacing. Am I right?

Regards,
Nayan.

Regards,
> Christian.
>
>
> Am 08.08.2016 um 16:32 schrieb Nayan Deshmukh:
>
> Hi Christian,
>
> I am more than happy to solve these problems, the Lanczos filtering was
> getting a little stale
> anyway because I was not able to reproduce the problems Andy was facing.
>
> On Mon, Aug 8, 2016 at 6:24 PM, Christian König <christian.koenig at amd.com>
> wrote:
>
>> Hi Nayan,
>>
>> ok let's take a step back and put the lanczos filtering aside for a
>> moment. I have another task for you which is more urgent right now.
>>
>> The order we do things in vlVdpVideoMixerRender() was never 100% correct,
>> so we have at least three problems here which needs fixing:
>>
>> 1) The noise reduction and sharpness filter read and write to the same
>> surface at the same time. That only works because we use a linear layout.
>>
>> Is that why I need to add a PIPE_BIND_LINEAR to a surface? So I need to
> use maybe a couple of surfaces alternatively to read and write with the
> filters. This approach should work I guess.
>
> 2) We apply the noise reduction and sharpness filter after the
>> composition. That is rather odd and should be fixed so that we apply those
>> filters on the original video frame instead.
>>
>>  So we need to apply the filter before the CSC conversion.
>
>> 3) We use delayed rendering to render into output surfaces directly. We
>> should rather use the DRI3 capabilities to allocate multiple output
>> surfaces instead.
>>
>> Could you take care of some of those issues? Especially #1 has become a
>> problem recently.
>>
>> Surely, I will start working on the first 2 problem for now and look at
> the third problem a little later.
>
> Regards,
> Nayan.
>
>
>> Regards,
>> Christian.
>>
>>
>> Am 04.08.2016 um 19:22 schrieb Nayan Deshmukh:
>>
>> Hi Andy,
>>
>>
>> On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss <adf.lists at gmail.com> wrote:
>>
>>> Nayan Deshmukh wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> Thanks for testing my patches.
>>>>
>>>
>>> NP
>>>
>>>
>>> The scaling happens after CSC.
>>>>>
>>>>
>>> OK, thanks.
>>>
>>>
>>> I believe there is some misunderstanding here, I was able to see the
>>>> artifacts in the video that you sent me previously. But I was not
>>>> able to replicate them
>>>>
>>>
>>> Yea, I got that - just thought you may want to see how they had changed.
>>>
>>> with the pendulum video on my system. Same case this time the
>>>> pendulum video plays fine this time too. I am attacing a video of it
>>>> here
>>>>
>>>> https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E
>>>> /view?usp=sharing
>>>>
>>>
>>> Hmm, that's interesting for a few reasons.
>>>
>>> Though my monitor won't do 1366x768 I can replicate the same scale
>>> factor windowed with mplayer ... -xy 768/576 ...
>>>
>>> At first glance only level 2 is obviously artifacted (though very close
>>> inspection shows others are slightly).
>>>
>>> Levels: for some reason your vid has the black bars at 0 but the content
>>> isn't scaled - like your mplayer didn't expand tv to pc on playback.
>>> This shouldn't happen by default. Do you have some extra config
>>> somewhere like in $HOME/.mplayer, if so maybe better to test without.
>>>
>>> Most important - though the vp9 compression may be to blame I can't
>>> really see any difference between the levels in that vid.
>>>
>>> In fact closely comparing just your level 1 to my (admittedly
>>> uncompressed) level 1 and 0 output scaled the same plus unstretched
>>> levels wise it looks to me like you are getting level 0 on this test.
>>>
>>
>> You are right it I am getting level 0 only. I have a PRIME configuration
>> and I forgot to set DRI_PRIME to 1. But for some reason, I am not able to
>> create
>> a screen recording when I use my AMD card. So, for now, I can't reproduce
>> the artifacts
>> you are having so can't debug them too :(
>>
>> Regards,
>> Nayan.
>>
>>
>>
>
>
> _______________________________________________
> mesa-dev mailing listmesa-dev at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160809/dd9bed8c/attachment-0001.html>