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

Tue Aug 9 11:40:57 UTC 2016

> 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.

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 <mailto: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
>>     <mailto: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
>>             <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160809/f9c5187c/attachment.html>