[WINDOWS] Deband filter (ala ffdshow or flash3kyuu_deband)
#1
I would be interested in a deband filter like ffdshow has one, or like e.g. flash3kyuu_deband() for Avisynth.
I have already done some research, and the implementation should be possible in a D3D9 pixel shader without stressing the GPU too much.

I could provide the filter implementation itself, and if someone takes the time to give me some pointers I think I should also be able to figure out how to integrate the setting in the settings menu.

However, before hacking away, I want to make sure that such a patch would be welcome and be accepted if I submit it (provided the implementation quality meets your standards of course, but I don't expect a problem there).

Since I only have a Windows box, and have no experience with linux/... I would only be able to provide a Windows implementation. The only thing that I might be able to provide in addition to a D3D9 implementation is one for DXVA(2), but since I have no experience with DXVA I don't want to promise anything.
Reply
#2
That would be a nice feature.

The difficult part is the shader itself, the rest is mostly plumbing. The "XBMC Development" forum is there for the help you may need.

Roughly, adding a shader requires creating an additional render target and adding a step in CWinRenderer::RenderPS() to call a new class based on CWinShader. That class would be pretty similar to the other children of CWinShader.
Integrating with dxva would be more complicated, don't worry about it. Same for GL.

A thread in the Development forum to discuss the debanding algorithm would be a good idea. bobo1on1 is the team's video processing guy and may already have an idea or two about this and it's best to get some agreement early on.

edit: actually for prototyping purposes, it may be possible to add the debanding code at the end of an existing shader and avoid writing the C++ code initially.
Always read the Kodi online-manual, the FAQ and search the forum before posting.
Do not e-mail Kodi Team members directly asking for support. Read/follow the forum rules (wiki).
For troubleshooting and bug reporting please make sure you read this first.
Reply
#3
Hi CrystalP,

thanks for your reply.

CrystalP Wrote:That would be a nice feature.

The difficult part is the shader itself, the rest is mostly plumbing. The "XBMC Development" forum is there for the help you may need.

Roughly, adding a shader requires creating an additional render target and adding a step in CWinRenderer::RenderPS() to call a new class based on CWinShader. That class would be pretty similar to the other children of CWinShader.

I've already taken a look at the 10.1 source. IMO the whole CWinRenderer could use a little refactoring. I think in it's current state, if you add another 1-2 features without refactoring, it will start to get ugly.
E.g. factor out the three different rendering methods into helper classes (SW, PS, DXVA), factor out the rendering stages (passes) into instances of some RenderingStage class etc. Maybe even "upgrade" it along the way - play with the scaling/color-conversion part - e.g. it could be beneficial to scale the U and V planes with a lanczos filter, instead of relying on the GFX-cards interpolation (which is what the current implementation is doing, if I understand it correctly).
If I get the OK from whoever currently "owns" that code I could do that as well.

Quote:Integrating with dxva would be more complicated, don't worry about it. Same for GL.
Don't worry because we can live without it, or because someone else on the team can integrate it for GL & DXVA once we have a shader that works nicely? Cool
I *think* implementing it for GL should be rather simple, if one knows his GL and has a Linux box to test on.
And implementing it for DXVA is something that I'd really like to see happening, because DXVA is probably THE decoder/renderer of choice for most Windows based HTPCs.

Quote:A thread in the Development forum to discuss the debanding algorithm would be a good idea. bobo1on1 is the team's video processing guy and may already have an idea or two about this and it's best to get some agreement early on.

Then I will go ahead and post there. I didn't want to do so right away, because it says it's for developers only, and I'm not (yet) one of those Smile

Quote:edit: actually for prototyping purposes, it may be possible to add the debanding code at the end of an existing shader and avoid writing the C++ code initially.

That might be possible, yes. One wouldn't get an accurate impression of the performance though - integrating into an existing shader will probably be rather slow. E.g. I think that one will need a random-number generator for a good implementation, and a fast way to do that would be to use a random-number texture. Which isn't possible without modification to the C++ code. Anyway, one could still get a good impression of the image quality.
Reply
#4
pgroke Wrote:Then I will go ahead and post there. I didn't want to do so right away, because it says it's for developers only, and I'm not (yet) one of those Smile

It's OK to post in the developers' forum with questions and discussion about development - "developers only" just means that it is for people that need help developing things, not that it's only for current developers on Team XBMC.

The devs always appreciate folks like you who take the initiative to do things like this, and any thing that makes for cleaner and more modular code is always welcome.

-Wes

[EDIT] I see that you already posted here: http://forum.xbmc.org/showthread.php?tid=114801 Good luck with this!
Reply
#5
As waldo22 wrote, contributions are always welcome.

Yes the renderer is a bit of a mess and could use some love. My long-term plan would be to turn it into an engine to run a processing pipeline, where the color conversion, scaling, post-processing, deinterlacing are the steps of the pipeline.
That would make it easy to add more processing and I'd like to do video processing add-ons at some time.

It's easy to add the filter after dxva color conversion+scaling, but not efficient as it would have to work on 1080p even if source is DVD for example. To work on source size would require changing the dxva code path more significantly but I think I have an old patch lying around for that. Maybe debanding before scaling is a bad idea anyway so maybe this is not actually a problem.

Adding the debanding to the YUV-RGB conversion would be a good idea for a proof of concept I think. There is a 'random' primitive in HLSL I believe, so maybe a random texture is better but there are easier ways to start. Performance is not very important at first.
Always read the Kodi online-manual, the FAQ and search the forum before posting.
Do not e-mail Kodi Team members directly asking for support. Read/follow the forum rules (wiki).
For troubleshooting and bug reporting please make sure you read this first.
Reply
#6
Hi guys,
Any news?
What is now the best filter to do debanding of m2ts HD files?

Thank you.
Reply
#7
I have nearly zero experience with kodi.
I am planning to get a vero 4k to, yeah, watch everything.
Is there any "deband" possible with a vero 4k?
Reply

Logout Mark Read Team Forum Stats Members Help
[WINDOWS] Deband filter (ala ffdshow or flash3kyuu_deband)0