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 <deathsim...@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 <deathsim...@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.koe...@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.li...@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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
