[Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3
Christian König
deathsimple at vodafone.de
Tue Aug 9 19:19:05 UTC 2016
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 <mailto: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 <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
>> <mailto:mesa-dev at lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> <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/5990bbcb/attachment-0001.html>
More information about the mesa-dev
mailing list