2011-11-09, 01:28
this from madshi the madvr dev:
"Well, I've added a number of callbacks which might already help. They're explained in "mvrInterfaces.h" which is shipping with madVR. If anybody wants to talk to me I'm open for that, they can email me at any time they want. I'm also willing to consider adding more custom interfaces to support XBMC. However, we'll have to think about what makes sense and what not. As far as I know, XBMC insists of presenting every frame itself. That does collide with madVR because madVR wants to do the presentation itself.
I'm willing to help, though, as far as I can. I'm not sure if I can change the basic way madVR works, though. Why does XBMC require madVR to render to a Direct3D surface? That is not a good solution, IMHO, because if I do that, XBMC takes over a lot of responsibilities that madVR was written for. E.g. when and how to present the rendered frames would be done by XBMC. That would disable the whole internal madVR "smooth motion" logic. It would also disable madVR's automatic fullscreen exclusive mode and some more soon-to-come (not announced yet) features.
The better approach would be for XBMC to "hook into" madVR and draw it's GUI to the madVR Direct3D surfaces, so that madVR can keep responsibility of when and how to present the frames.
I'm planning to add new interfaces/APIs to madVR in the very next build which will allow media players to draw stuff over the madVR rendered video. I've been talking to the ZoomPlayer, PotPlayer and J.River Media Center guys and they told me their wishes and I'll implement them. They all have different wishes, funny enough, so I'll actually implement 3 different ways to draw media player GUI stuff when using madVR. Maybe one of these will work for XBMC, too? The 3 ways will be these:
(1) You can register for a callback. Your callback function will be called once for every video frame. You'll be able to render your GUI in your callback.
(2) You can provide madVR with a bitmap with a color key for transparency, which madVR will then automatically draw over every video frame.
(3) You can provide madVR with a bitmap with a full 8bit alpha channel which madVR will then automatically draw over every video frame.
Would one of these work for you? If not, let me know what you need and I might be able to implement it. I can not really totally change madVR, though. It must stay madVR's duty to present the frames. "
well there you have it please xbmc devs lets get the video engine of xbmc updated it needs it
heres a small tut , that will explain exactly what id like to be incorporated into xbmc , thanks in advance
http://imouto.my/watching-h264-videos-us...ture-cuda/
madshis email : [email protected]
"Well, I've added a number of callbacks which might already help. They're explained in "mvrInterfaces.h" which is shipping with madVR. If anybody wants to talk to me I'm open for that, they can email me at any time they want. I'm also willing to consider adding more custom interfaces to support XBMC. However, we'll have to think about what makes sense and what not. As far as I know, XBMC insists of presenting every frame itself. That does collide with madVR because madVR wants to do the presentation itself.
I'm willing to help, though, as far as I can. I'm not sure if I can change the basic way madVR works, though. Why does XBMC require madVR to render to a Direct3D surface? That is not a good solution, IMHO, because if I do that, XBMC takes over a lot of responsibilities that madVR was written for. E.g. when and how to present the rendered frames would be done by XBMC. That would disable the whole internal madVR "smooth motion" logic. It would also disable madVR's automatic fullscreen exclusive mode and some more soon-to-come (not announced yet) features.
The better approach would be for XBMC to "hook into" madVR and draw it's GUI to the madVR Direct3D surfaces, so that madVR can keep responsibility of when and how to present the frames.
I'm planning to add new interfaces/APIs to madVR in the very next build which will allow media players to draw stuff over the madVR rendered video. I've been talking to the ZoomPlayer, PotPlayer and J.River Media Center guys and they told me their wishes and I'll implement them. They all have different wishes, funny enough, so I'll actually implement 3 different ways to draw media player GUI stuff when using madVR. Maybe one of these will work for XBMC, too? The 3 ways will be these:
(1) You can register for a callback. Your callback function will be called once for every video frame. You'll be able to render your GUI in your callback.
(2) You can provide madVR with a bitmap with a color key for transparency, which madVR will then automatically draw over every video frame.
(3) You can provide madVR with a bitmap with a full 8bit alpha channel which madVR will then automatically draw over every video frame.
Would one of these work for you? If not, let me know what you need and I might be able to implement it. I can not really totally change madVR, though. It must stay madVR's duty to present the frames. "
well there you have it please xbmc devs lets get the video engine of xbmc updated it needs it
heres a small tut , that will explain exactly what id like to be incorporated into xbmc , thanks in advance
http://imouto.my/watching-h264-videos-us...ture-cuda/
madshis email : [email protected]
, hell madshi is just waiting till a xbmc dev sends him an email but atm nobody seems interested kinda unbelievable 
