Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TheLion]

Hello!

I would like to point out that I really appreciate the audio quality I am getting with MC15. It has quickly become my only choice for all my audio needs. But for video playback I need to use other applications (MPC-HT, Zoomplayer, Potplayer) due to the lacking madVR implementation. IMHO madVR is the best and most flexible video rendering solution out there - once I got used to the highest quality chroma upsampling and scaling features there is no way going back to EVR, Haali or VMR9.

I would like to know if there is still work done on the madVR implementation? It is the one feature that is holding MC15 back as a universal media player for me.

THANK YOU!

[Osho]

I would like to second this request as well..

Thanks,
Osho

[jmone]

+1
As per the other threads....madVR has been added as a Video Renderer....it just does not work!

[TheLion]

I knew I am not alone  - Thank you guys. As beta tester - do you have any further information if madVR is still a work in progress and fixed support is planned for an upcoming release?

[jmone]

MadVR suport was added back in 14.0.137 (02/01/2010) but none of us have ever got it to work despite several such threads over the year!  Anyway, Yaobing would be the guy to discuss what the plans are?!?!?!

[fitbrit]

I'd love to try this too.

[Yaobing]

Unfortunately madVR is too inflexible - it does not support all video cards, does not support DVD playback, and, more importantly for us, does not work when we use our way of building a DirectShow graph.  I am not convinced yet that I should overhaul our video playback engine in order to support the use of madVR.  Sorry, maybe some time in the future.

[jmone]

Thanks for the feeback Yaobing.  If so it may be worth removing as on option in the Video Renderer box.

EDIT: Alternativly - I've posted on the madVR forum to see if there are any ideas from madshi (the dev) - http://forum.doom9.org/showthread.php?p=1462950#post1462950

[TheLion]

Thank you for the feedback, Yaobing!

I too have contacted madshi personally to discuss this matter.

I wouldn't say madVR is too "inflexible" - it's approach is more about "best possible quality without compromises" - therefor graphic card support is limited and it deals with DirectShow filter chain a little different. But this is all due to the least possible potential for picture degradation. And IMHO it really shows with high quality sources on revealing displays.

What you gain is the most flexibilty in choosing chroma upsampling and scaling filters and 3dLUT "color"/gamma correction. And a resulting picture quality that is "better"/more transparent than any other renderer can provide at the moment.

JRiver MC for me is all about quality - with audio playback it is as good as it gets IMHO - but for video the choice of renderer that is also all about quality is sadly not supported (while practically all other DirectShow player support it without a glitch).

I sincerely hope you/madshi/we can work something out!

[madshi]

Hello,

I'm the madVR developer.

it does not support all video cards

True. But I think today most video cards support DX9, so I don't consider it much of a problem.

does not support DVD playback

Playback of VOBs works just fine. There's a problem with the MS DVD Navigation DirectShow filter, and this problem is caused by MS trying to stop their Navigation filter from working with any renderer others than theirs. The Haali Renderer has the same problem. Maybe I will find a way to work around the problem. Or maybe the open source DVD navigation filter will come to rescue sooner or later, see here:

http://forum.doom9.org/showthread.php?t=153191

more importantly for us, does not work when we use our way of building a DirectShow graph.  I am not convinced yet that I should overhaul our video playback engine in order to support the use of madVR.

I wouldn't expect you to overhaul your playback engine, and I think (hope) that it won't be necessary to make madVR work. Do you have more detailed information about what the exact problem is? I've downloaded the latest Media Center 15 version and tried it with a madVR debug version. From what I can see, you succeed connecting the video decoder to madVR, but then playback is never started. According to the madVR logs, madVR is just sitting idle and waiting for playback to finally start. I don't see any obvious misbehaviour in the madVR logs, but that's just from my side of the fence, obviously.

I'd be willing to work together with you to fix any problems there might be. If you're interested, you can contact me directly via madshi (at) gmail (dot) com.

[JimH]

mad,
Thanks very much for posting.  I've sent you a license by e-mail.

Jim

[madshi]

Got it - thanks!   

[jmone]

Madshi - Welcome and thanks for making contact, as there are a bunch of us keen to get madVR working with JR Media Center!

[madshi]

Hope we'll get it working...   

[TheLion]

Wonderful news! I sincerely hope that a solution can be found and that JRiver becomes the high quality choice for audio AND video by finally supporting madVR!

Thank you so much for your efforts!

[Yaobing]

Hope we'll get it working...  

Thanks for working with us.

Here are a few things that I observed:

1. madVR would not connect to "Microsoft DTV-DVD Video Decoder", nor "DScaler Mpeg2 Video Decoder".  This is not related to MC at all.  I cannot make the connections in GraphEdit.

2. In Media Center 15, using "MPC MPEG-2 Video Decoder (gabest)" or "ArcSoft Video Decoder", the two decoders that I can connect to madVR in GraphEdit, MC hangs.  It hangs when we try to call IVideoWindow::put_Owner() - the call never returns.  This is probably the main reason why it does not work.

So far the only thing that I can think of that may offer a clue is that we build our playback graph in a worker thread, and then do other processing in the main thread.

3. Only upper left corner of digital TV is displayed.  This is true when I tried it in GraphEdit.  In Media Center 15 it also displays the same behavior, or worse (see 4 below).  I am guessing madVR is not handling dynamically changing video size.  In digital TV, the output pin of Microsoft MPEG-2 Demultiplexer seems to be always 720x480.  When the graph is run, video decoders can dynamically adjust the video size to appropriate values (1080i for example), but madVR is not displaying the entire thing.

4. In MC15, when playing a digital TV channel, often I get the following error messages displayed on screen:

madVR reports:
-creating GPU luma texture (scaled x) failed
-initializing buffers failed

[MrHaugen]

I hope you get this working. I'm very interested i trying it out my self. Have had problems with some other decent alternatives over the years.

[madshi]

1. madVR would not connect to "Microsoft DTV-DVD Video Decoder", nor "DScaler Mpeg2 Video Decoder".  This is not related to MC at all.  I cannot make the connections in GraphEdit.

madVR currently only accepts YV12. I think the MS DTV-DVD Video Decoder can only output YUY2 but not YV12. DScaler works fine here (I'm using the DScaler IVTC mod, though), but you may have to configure it to output YV12.

2. In Media Center 15, using "MPC MPEG-2 Video Decoder (gabest)" or "ArcSoft Video Decoder", the two decoders that I can connect to madVR in GraphEdit, MC hangs.  It hangs when we try to call IVideoWindow::put_Owner() - the call never returns.  This is probably the main reason why it does not work.

Ok, that's helpful information. I think "put_Owner()" is implemented internally by the MS base classes, so that's why the madVR logs don't show that the freeze happens inside of madVR. I'll see if I can find out something more...

So far the only thing that I can think of that may offer a clue is that we build our playback graph in a worker thread, and then do other processing in the main thread.

There are some critical sections in the depths of the MS base classes. I could imagine that one of those freezes when using your way of building the graph. I'm not sure why the freeze doesn't occur with the MS renderers. Maybe they're not using the MS base classes or have overwritten their behaviour. Anyway, let me check, maybe I can find out what's going wrong.

3. Only upper left corner of digital TV is displayed.  This is true when I tried it in GraphEdit.  In Media Center 15 it also displays the same behavior, or worse (see 4 below).  I am guessing madVR is not handling dynamically changing video size.  In digital TV, the output pin of Microsoft MPEG-2 Demultiplexer seems to be always 720x480.  When the graph is run, video decoders can dynamically adjust the video size to appropriate values (1080i for example), but madVR is not displaying the entire thing.

madVR is handling various ways of dynamic format changes just fine. But maybe I've missed one. Which exact source file format, splitter and decoder filters did you use to reproduce this problem? To be honest, I haven't tried madVR in GraphEdit for ages. I've only tested with real media players. Will retest GraphEdit, to be safe.

4. In MC15, when playing a digital TV channel, often I get the following error messages displayed on screen:

madVR reports:
-creating GPU luma texture (scaled x) failed
-initializing buffers failed

That's weird! But let's first clear out the other problems and look at this last.

[Matt]

First, I want to say that you have built something really amazing with madVR.  Kudos.

Ok, that's helpful information. I think "put_Owner()" is implemented internally by the MS base classes, so that's why the madVR logs don't show that the freeze happens inside of madVR. I'll see if I can find out something more...

Yaobing is the Directshow expert, but I thought I would chime in about window handles and threads.

The general rule of thumb is that you should not use a window outside the main UI thread.  There are some exceptions like GetDC(...) but sending a message or calling an API like GetWindowText(...) that internally sends a message is dangerous and can easily lead to dead-locks.  You must also remember that it is impossible to pump a window's message loop outside of the owning thread of the window.

On our side, we might experiment with ordering of function calls or providing a display HWND in the main thread before running the graph.  We might also check to see if pumping certain messages in the UI thread while waiting for the graph to build would make a difference.

I'm not sure if other players build their graphs in a background thread, but it seems necessary if the user interface is to remain unlocked during graph building time.

[fitbrit]

Madshi, Yaobing and Matt in one thread! This is almost the directshow equivalent of "The Expendables". We just need Haali, Solveig and Gabest to show up as well.

[madshi]

First, I want to say that you have built something really amazing with madVR.  Kudos.

Thank you, I appreciate that...   

On our side, we might experiment with ordering of function calls or providing a display HWND in the main thread before running the graph.  We might also check to see if pumping certain messages in the UI thread while waiting for the graph to build would make a difference.

Yeah, one of these things might help, I'm not sure.

I'm not sure if other players build their graphs in a background thread, but it seems necessary if the user interface is to remain unlocked during graph building time.

FWIW, I very much like the concept to have the main/UI thread do only UI and to do any serious work in secondary threads. I hate applications where the UI freezes for a few seconds when certain things happen. My usenet application behaves like that and it annoys the heck out of me, sometimes.

[madshi]

Ok, I've found out where the freeze is coming from:

You're creating the madVR instance in one thread, let's call it the "Creator" thread. madVR as a result creates its rendering window in this thread. So the "Creator" thread owns the madVR rendering window.

Later you are calling "IVideoWindow::put_Owner()" from within a different thread. The MS base classes have this code inside of put_Owner():

Code: [Select]

   LONG Style = GetWindowLong(m_hwnd,GWL_STYLE);
    if (Owner == NULL) {
        Style &= (~WS_CHILD);
    } else {
        Style |= (WS_CHILD);
    }
    SetWindowLong(m_hwnd,GWL_STYLE,Style);
The SetWindowLong() call freezes. I've also tried a simple "SendMessage(m_hwnd, WM_NULL, 0, 0)" call, and it also freezes. I believe that the "Creator" thread does not handle messages while you are calling "IVideoWindow::put_Owner()". As a result the SetWindowLong() call blocks and waits for the Creator thread to react. And the Creator thread probably waits something else.

So the proper solution for this would be to make sure that the Creator thread handles messages while you call IVideoWindow::put_Owner().

That makes me wonder:

(1) Does your Creator thread continue to run throughout the whole playback time? It should, because otherwise probably the rendering window would die with the thread, I'd guess.
(2) Why does the Creator thread not handle messages when you call IVideoWindow::put_Owner()?

Generally, I think it's expected for madVR to create its rendering window in the madVR constructor (don't you agree?), and of course madVR depends on that the rendering window reacts to messages. At all times, if possible.

What do you think?

P.S: Which rendering mode are you using for VMR9? Probably windowless or renderless? I guess if you used the old windowed VMR9 rendering mode, you'd probably get the same freeze as you get with madVR? Not 100% sure, though.

[Yaobing]

Thanks for the info.  We may be getting somewhere.

(1) Does your Creator thread continue to run throughout the whole playback time? It should, because otherwise probably the rendering window would die with the thread, I'd guess.

Yes, it does.

(2) Why does the Creator thread not handle messages when you call IVideoWindow::put_Owner()?

Oversight?  We tried to make things simple.

Generally, I think it's expected for madVR to create its rendering window in the madVR constructor (don't you agree?), and of course madVR depends on that the rendering window reacts to messages. At all times, if possible.

What do you think?

P.S: Which rendering mode are you using for VMR9? Probably windowless or renderless? I guess if you used the old windowed VMR9 rendering mode, you'd probably get the same freeze as you get with madVR? Not 100% sure, though.

I will see if we can handle massages and hope it will make a difference.  We use Windowless VMR9, but windowed vmr7 and legacy renderer.  No freeze in all those cases.

[madshi]

I'm positive that adding message handling will fix the freeze. If your Creator thread is in a "WaitForSingleObject()" call (quite likely), you could replace that with a "MsgWaitForMultipleObjects()" loop. But what am I telling you, you surely know that already...   

Thanks!

[Yaobing]

I'm positive that adding message handling will fix the freeze.

It does.  No more hanging on IVideoWindow calls.

There are still more problems:

1.  The video is displayed in native size only (in upper left corner of the window).  My video resizing and zoom code does not have any effect although all function calls seem to return success code.

2.  I can only run video once.  After stopping playback of one file, I can not play (neither the same file nor another file).  Instead, these error messages are shown on screen:

madVR reports:
-creating GPU luma texture (scaled x) failed
-initializing buffers failed

3.  While playing video (as in 1. above), the program is very sluggish - both keyboard and mouse.

[madshi]

It does.  No more hanging on IVideoWindow calls.

Nice - there's progress!   

1.  The video is displayed in native size only (in upper left corner of the window).  My video resizing and zoom code does not have any effect although all function calls seem to return success code.

IIRC, this is controlled via "IBasicVideo::SetDestinationPosition". If you call that and it doesn't work, I'm not sure what the reason is for that. I can check that, but I'd need either a fixed MC version, or a madVR debug log from you. You can create the debug log by renaming "madVR.ax" to "madVR [release].ax" and then renaming "madVR [debug].ax" to "madVR.ax". After that, madVR will log to the file "desktop\madVR - log.txt". If you want to send me log files, please try to keep them small, that makes it easier for me. You can delete the log file whenever you see fit to keep it short.

2.  I can only run video once.  After stopping playback of one file, I can not play (neither the same file nor another file).  Instead, these error messages are shown on screen:

madVR reports:
-creating GPU luma texture (scaled x) failed
-initializing buffers failed

Same as above: I either need a non-freezing MC version or a madVR debug log, then I can look into that.

Is it possible that you recreate the madVR instance in these situations? Currently madVR doesn't handle it well if you create two madVR instances and then destroy one. If possible, please try to properly release the old instance before creating a new one. Could that be the issue?

3.  While playing video (as in 1. above), the program is very sluggish - both keyboard and mouse.

Hmmmm... Does your main/UI thread do anything except drawing the UI? Is any part of DirectShow related to your UI thread? Don't have any good guess about the problem right now...

[madshi]

P.S: I've done some research. Currently the "expected" order of things is this:

(1) the media player connects the decoder to madVR
(2) the media player asks IBasicVideo2::GetPreferredAspectRatio()
(3) the media player takes the information from (2) and transforms it according to the user's zoom/scaling wishes
(4) the media player calls IBasicVideo::SetDestinationPosition()

And when madVR detects a dynamic video size/format change, this is supposed to happen:

(1) madVR fires a "EC_VIDEO_SIZE_CHANGED" notification
(2) the media player receives the EC_VIDEO_SIZE_CHANGED message
(3) the media player asks IBasicVideo2::GetPreferredAspectRatio()
(4) the media player takes the information from (3) and transforms it according to the user's zoom/scaling wishes
(5) the media player calls IBasicVideo::SetDestinationPosition()

Is this how you're doing it right now? I'm not sure what happens if you set the size before connecting the decoder to madVR.

[Yaobing]

It is not quite how we do it.

Instead of using IBasicVideo::SetDestinationPosition, we use IVideoWindow:SetWindowPosition

[madshi]

Ok, here's a madVR beta build which doesn't require "IBasicVideo::SetDestinationPosition". If "IBV:SetDestinationPosition" is not called, madVR will stretch to the IVideoWindow size instead.

http://madshi.net/madVR.rar

For me things appear to work ok now with your latest beta and mine. I can stop/start etc. The only problem I can see right now is the sluggishness you mentioned earlier. I don't really know where it's coming from. Sometimes it appears to be fine, sometimes it's sluggish. Do you have any ideas about how to find out what's causing this? I don't really know how right now...   

[Yaobing]

Ok, here's a madVR beta build which doesn't require "IBasicVideo::SetDestinationPosition". If "IBV:SetDestinationPosition" is not called, madVR will stretch to the IVideoWindow size instead.

http://madshi.net/madVR.rar

For me things appear to work ok now with your latest beta and mine. I can stop/start etc. The only problem I can see right now is the sluggishness you mentioned earlier. I don't really know where it's coming from. Sometimes it appears to be fine, sometimes it's sluggish. Do you have any ideas about how to find out what's causing this? I don't really know how right now...   

Thanks!  I confirm it works pretty well now except the sluggishness.  I am not sure what is causing it either but I will do more digging.  It seems to behave better in our TV playback engine than in video file playback engine.

[madshi]

Thanks!  I confirm it works pretty well now except the sluggishness.

Great! 

I am not sure what is causing it either but I will do more digging.  It seems to behave better in our TV playback engine than in video file playback engine.

If you find out anything, or if you need any assistance or tests on my side, please let me know.

FWIW, there's one more thing to look at:

madVR has an integrated automatic fullscreen exclusive mode, which automatically detects when the media players goes into fullscreen mode. When that happens, madVR automatically switches Direct3D into fullscreen exclusive mode, which increases rendering performance and totally gets rid of any tearing. It also helps with multi monitor setups, where Aero often has trouble with smooth playback. Fullscreen exclusive mode will also be necessary for things like DeepColor (30bit, 48bit) output, frame packed 3D output etc...

The problem right now is that the fullscreen exclusive switch can only be done if a number of conditions are met. One of the conditions is that the madVR rendering window most cover exactly the whole screen, because otherwise Direct3D will refuse to enter excluside mode. With your current logic to set "IVideoWindow::SetWindowPosition" to define the drawing rectangle, this doesn't work on my 1680x1050 monitor, because you never call "IVideoWindow::SetWindowPosition" with exactly 1680x1050.

All the other media players (MPC HC, ZoomPlayer, KMP, PotPlayer) set "IVideoWindow::SetWindowPosition" to match the madVR window to their media player client area, which in fullscreen mode would be exactly the display resolution. Actual rendering size (aspect ratio control etc) is then done through "IBasicVideo::SetDestinationPosition". This way madVR can enter fullscreen exclusive mode just fine, regardless of the media player zoom settings.

So if you want madVR to be able to enter fullscreen exclusive mode, you'll probably have no choice than to use the same window/rendering position logic as the other media players are using (IVideoWindow::SetWindowPosition(MCClientArea) + IBasicVideo::SetDestinationPosition(renderingRect)). If you keep using your current solution, madVR will still work fine - but it will be limited to non-exclusive mode rendering.

[TheLion]

I am very glad to see the progress. Thank you so much guys!


If possible at all I would like to stress the importance of the fullscreen exclusive mode. It certainly makes playback smoother, eliminates any tearing and makes perfect sense especially together with AERO or future 3D playback. I sincerely hope MC goes down that path and supports the exclusive mode. This would make this paying customer very happy.

Thanks again.

[sunfire7]

I heard about madvr some time ago but I havent tried, today I did on mphc and I must say its awesome! good job of j river and madshi to work on the support !! thank you guys!

[fitbrit]

Thanks for the reports back. Nathan.

[sunfire7]

any news about this??  ?

[Matt]

any news about this??  ?

We have been doing a lot of work on nice madVR support for Media Center 16.

We'll have more to say in a couple weeks.

[sunfire7]

Madshi, Im having a problem with madvr:

I open MC to play music etc etc, and close it, the program is still showing in the task manager, like as doing some stuff in background or stays in memory to accelerate opening in the future, I dont know.

Then I open a movie in mpc hc with madvr, and try to set full screen, the screen flicks? and stay windowed, a message appears in the bottom of mpc hc saying focus lost to media center 16.  I have to kill mc with the task manager in order to be able to play fullscreen videos with mpc hc.  Im using MC 16.0.49 and Madvr 0.45

[madshi]

So basically the problem is that MC is not closing properly, correct? You say you open MC to play music. So is madVR involved at all in your MC session?

[sunfire7]

I have MadVR as my video render on MC, but it doesnt matter if in the session I play videos or not, happens the same

[madshi]

Well, the question is if it's a bug in madVR or in MC16. I'd suggest that (just as a test) you choose a different video renderer in MC16. Does the problem still occur that way? If it does then it's a bug in MC16 and not a bug in madVR.

FWIW, if I close MC16 then it completely closes. It doesn't stay in the background.

[jmone]

I just tested madVR .35 in MC (on a PC not my HTPC - family watching content !)
- run a video = madHcCtrl.exe *32 appears in Task Mgr and you see the Icon in the Sys Tray
- stop the video = the process and icon disappears as you would expect

[sunfire7]

madshi, just to report that now I have no problems with MC 16.0.55 and MadVR 0.47, I'll let you know if troubles appears again