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

[Nayan Deshmukh]

Hi Christian,

I have a sent a patch which deals with the order in which filter are applied.
I will send a patch probably by tomorrow which we use temporary surfaces.

Regards,
Nayan.

On Wed, Aug 10, 2016 at 12:49 AM, Christian König
<deathsimple at vodafone.de> wrote:
> Am 09.08.2016 um 19:21 schrieb 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?
>
>
> video buffers are basically just a collection of sampler views and render
> targets (up to six). You just need to apply each filter to each plane
> separately.
>
>
> 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?
>
>
> Oh, good point. Might be that we need to change the order to 1)
> Deinterlacing, 2) Median 3) Sharpening.
>
> Otherwise the calculation overhead/memory bandwidth probably start to hit
> some limits on low end hardware.
>
> Regards,
> Christian.
>
>
>
> 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 list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev