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 <mailto: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 <mailto: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 <mailto: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
<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
<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
<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
