Project is abandoned - any new home?

[xmedeko]

For all folks: this GitHub project has been abandoned, it has no activity from the author for the past year and I have it confirmed by the email from Jeremiah Morrill (the original author of https://wpfmediakit.codeplex.com/).

Is there any one to pick the glove and continue the project? I can help with it (already submitted a few PRs). I have just a shallow deep knowledge in the Windows video rendering so I do not feel to become a main maintainer.

[jluisestrada]

You are doing great! Most of the job is already done and is just a matter of maintaining this.

[xmedeko]

Not me, @Sascha-L has done a great job and thanks him for that! Unfortunately, @Sascha-L is not maintaining this project now. So we need a fork which will be maintained. WPF MediaKit still need to fix some bugs (e.g. #21) and improvements.

[Wufflez]

Are you the current leader of this project now @xmedeko? I'm new to GitHub so I'm not really sure if I'm in the right place. I have just found another bug with this project and would like to help fix it. Is this not the right repository to report issues or make pull requests on?

[xmedeko]

@Wufflez nope I do not have access to this project. I think we need to make a fork which will be maintained.

[Sascha-L]

Hey guys,

I'm very sorry for the late reply! I didn't had the time to manage this project in the last months.

I can add you to the project, if you want, so that you can submit fixes and new features.

For example we should make WPF MediaKit (optionally) use madVR instead of EVR. I am using madVR with MediaPortal and the video quality is much better than with EVR :-)

[glenn-slayden]

I may have a number of other fixes beyond #21 that I can enter if there is interest. But I probably don't know enough about GitHub to maintain this project.

[xmedeko]

@Wufflez @glenn-slayden send PRs or issues to this project, it's maintained again :wink:

[glenn-slayden]

@Sascha-L regarding madVR, thanks for pointing it out, but it seems to have some limitations. For one thing, it's 32-bit only, which means running in the WOW subsystem on x64. And obviously, it's not open source.

But mostly, does your advocacy for madVR mean you're writing-off WPF for video? Apparently many other serious devs in this area have done just this, due to issues like inaccessible VSync or being D3D9 bound--and this is all fine--but isn't the purpose of the WPF-MediaKit project inherently about trying to get better video without abandoning WPF?

Do I misunderstand, and that madVR can in fact be used just fine on WPF with some variation on a DirectShow (or perhaps even Media Foundation), D3DImage, RenderTargetBitmap, MILCore, or other approach?* And if that's the case, then shouldn't the WPF-MediaKit project be intensely interested in precisely how madVR is able to reliably ascertain VSync and execute FlipEx most optimally, etc, etc? Because my impression of madVR's no-compromise philosophy is that its generally incompatible with render pipelines that don't allow it obtain the high degree of control it needs to guarantee its trademark quality.

---

*For the purposes of this discussion, I don't consider externally- or incompletely-composited solutions such as PresentationSource/HwndSource be in the spirit of "WPF"

[Sascha-L]

Great thoughts about this topic! Of course WPF MediaKit will be always a real WPF control! That's very important for all of us. I hadn't the time to investigate more on how madVR works. I already use madVR with MediaPortal since a few weeks and thought it would be possible to also support madVR next to EVR (not as a full replacement of EVR cause not everyone can or want to use madVR).

Our big problem is, that we need advanced developers in our team. I don't have any DirectShow or video processing skills :-(

[glenn-slayden]

Ok, from what I've studied so far, I don't think madVR will be able to integrate with 'proper' WPF, but I could be wrong.

[jluisestrada]

If it is DS complaint, it is just matter of updating the graph. Isn't it?

Sent from my HAL 9000 terminal. Excuse the typos and/or any trapped astronauts in the airlock

On Jan 19, 2017, at 5:34 PM, Glenn Slayden notifications@github.com<mailto:notifications@github.com> wrote:

Ok, from what I've studied so far, I don't think madVR will be able to integrate with 'proper' WPF, but I could be wrong.

- You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/Sascha-L/WPF-MediaKit/issues/26#issuecomment-273932732, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGe0EM69TY5pRhiG0oAZVMxVU6AkjQyJks5rT_L7gaJpZM4KxizI.

[glenn-slayden]

I've done some further research on madVR and indeed it does appear that it could be made to render into a WPF D3DImage. The question comes down to how monolithic of a renderer the "R" in madVR is. In other words, the degree to which the renderer supports alternative video presenters, i.e., in the way that the Microsoft EVR allows custom replacements to be swapped in via IMFVideoPresenter and/or IMFVideoMixerControl/IMFVideoMixerControl2.

For WPF we're not so interested in replacing the so-called mixer component, and that's good for two reasons: First, because mixer functions (i.e., scaling) is an area where lots of the madVR enhancements that we want are deployed, and second, because I don't think those "mixer" functions can be customized in madVR (for that very reason).

But I do see, amongst many other settings in the madVR API header file, configuration options regarding video presentation:

//     separateDevice,      use a separate device for presentation (Vista and newer),   boolean
//     useD3d11,            use D3D11 for presentation,                                 boolean
//     dxvaDevice,          use separate device for DXVA processing (Vista and newer),  boolean

These seem to hint at developer hooks for customizing madVR's video presentation. Combining this with some new info I'm developing on WPF rendering, it does appear that madVR surface could be grafted-in to WPF via D3DImage.SetBackBuffer, without resorting to HwndSource-style solutions which, as I indicated before, defeat whatever justifications there were for using WPF in the first place.

Sadly, the madVR limitations of being closed-source and 32-bit-only would remain. Perhaps the thinking behind the latter is that software constrained by bus-bandwidth is hindered by having to move "even more bytes" if you double the size of every persisted pointer and handle... but surely that total size is insignificant--by several orders of magnitude--compared to the video content itself? Another possibility is that madshi has written optimized x86 assembly; porting even a trivial amount of hand-written asm code to x64 would be a huge task, especially for a single developer.

Finally regarding the x86 requirement, unfortunately in my experience, relative to the seamless and generally excellent interop in .NET, attaching to single-architecture native DLLs from managed code is surprisingly difficult and annoying. It's basically because p/Invoke does not incorporate a concept of architecture distinction, and the alternatives of LoadLibrary​/GetProcAddress or publishing to the GAC have complications of their own.

[Sascha-L]

I already got in contact with him because of a few other questions so I can ask him why it is only x86 and whether it will be easily possible to offer a x64 version too.

[glenn-slayden]

That would be great.

[glenn-slayden]

Argh, I may have spoken too soon about the status of madVR video presenter configuration. The options I mentioned yesterday are internal Boolean flags for madVR itself to do the presentation phase in different ways, not "hints at developer hooks for customizing madVR's video presentation," as I had hoped, and as would be necessary for any relevance to WPF. It looks like madVR is a dead-end for WPF, which (to answer jluisestrada's question) behaves as a Direct3D surface sink client (via D3DImage.SetBackBuffer), not an entire Direct3D platform, so it's not "compliant" in the sense that WPF has any "filter graph" that you could just drop madVR into.

[Sascha-L]

No problem! It was just an idea. If it is not working, it's a pity but not the end of the world! :-) So we should continue the work to get WPF MediaKit more stable, fixing bugs and searching for memory leaks, etc. :-)