INTERACT FORUM
More => Old Versions => Media Center 16 (Development Ended) => Topic started by: jmone on January 12, 2011, 07:39:00 pm
-
Hi, Just a quick q if there is any more tweaking going on with madVR or is it pretty well done (and do you want logs at this stage when stuff hangs)? The reason I ask:
1) MC locks up hard if you do anything that brings up a UAC diag box when madVR is rendering
2) I'm seeing some general instability (MC hangs, LS clients can't see the LS till the LS is resarted) that could be madVR related but I can not put my finger on it.
Thanks again for the work on this,
Nathan
-
I'm also seeing stability issues with MC when using madVR, switch back to EVR and MC16 is as stable as MC15.
Is madshi in the Beta team? As it's a bit hard to discuss anythng madVR related in the MC15 board until MC15 acutally supports it.
Richard
-
Forgot:
3) "Crop Edges" = green line at the bottom of the pic (ATI HW)
Example of "stability issue", just had a movie play for 45mins to see how it would go (all fine) but when I pressed STOP the screen just went Black. It was like a blank playing now windows was there as I could minimise/detach it then "X" to close it and MC16 was fine underneath.
-
Forgot:
3) "Crop Edges" = green line at the bottom of the pic (ATI HW)
Have you tried boosting the amount of cropping MC employs for video - try 2 or 3%. This feature was added to MC 15 about a month back and solved all my white/green line artefact problems.
-
Have you tried boosting the amount of cropping MC employs for video - try 2 or 3%. This feature was added to MC 15 about a month back and solved all my white/green line artefact problems.
Thanks - I've only tested quickly on one PC with one media type but very interesting results (and it is good the % is selectable), as:
1.00%: Green Line Bottom and Right
1.25%: Green Line Bottom and Right
1.50%: No Lines ;D
1.75%: No Lines ;D
2.00%: Green Line Bottom (** Default **)
2.25%: No Lines ;D
2.50%: No Lines ;D
2.75%: Green Line Bottom and Right
3.00%: Green Line Bottom and Right
-
I just tried different a different video formats and it looks that there is no one crop edges settings that works with all Resolutions, eg at 1.75%
* 640x336 = Big Green Line Bottom and Right
* 720x576 = No Green Line
* 1280x720 = No Green Line
* 1440x1080 = Green Line Right
* 1920x1080 = Green Line Right
PS - you can see the content behind the green lines, it is like it is an overlay.
-
I've just tried 16.0.8 and on a quick check it seems to work quite nicely for me. Couldn't find any obvious issues.
Not sure about the problems mentioned in this thread. Could be MC issues or madVR issues, can't say for sure. If you have some way to reliably reproduce the problems, it would be helpful if you could write down a step-by-step way to reproduce each problem. FWIW, my dev machine is still XPSP3, so can't test UAC problems too easily myself right now. madVR logs might be helpful, but please try to keep them as small as possible, and add a detailed description to each log, what you did, what problem occured at what time during playback.
-
madshi - welcome to the Beta Team! I must say it is looking great so far and thank you for the work to date. It is late here in Oz so I'll post some logs and more detail tommorow.
-
madshi - Newbie Q but how do you create logs from madVR?
-
(1) rename "madVR.ax" to e.g. "madVR [released].ax"
(2) rename "madVR [debug].ax" to "madVR.ax"
(3) start MC and reproduce the behaviour
(4) stop MC as quickly as possible
(5) zip up the file "madVR - log.txt", which you will find on your desktop
If you fail to reproduce the problem, please stop MC and delete the log file, then try again. That helps keeping the log size smaller.
-
Nathan, in my experience, the dodgy GREEN lines are due to specific ATI Catalyst settings. From memory, the de-noise and / or colour settings. Maybe check to make sure all that junk is switched off.
The persistent problem I had which was thankfully resolved with MCs configurable crop setting was WHITE line corruption.
-
MY issues have been;
1) Using madVR .36 starting live TV playback has issues with scaling for me, the picture can be correct, VERY large or very small and up in the top left corner. Using the version supplied by madshi in the MC15 thread seems to resolve that issue. Is this what should be expected?
2) General instability of MC16. I'll get MC just freezing when using it along with madVR. Maybe when seeking shortly after starting playback, or changing channels. Or it moight just freeze/crash after I play one video, stop playback and then try to start playback of another. At this stage all my testing is just on jtv files or live TV. Switching back to ERV and I haven't had any freezes/crashes.
I have also noticed that every time I seek and madVR switches from exclusive to winowed I get a flash of whatever the last windowed frame was prior to switching to exclusive. Is there a way of stopping this?
I can generate some logs over the next couple of days hopefully, but madshi is there a logging version of the madVR.ax you posted up on the forums here?
Cheers
Richard
-
madshi / Yaobing?
Here is the first set of logs zipped together (an MC log and a madVR log)as it is the easiest to produce and 100% repeatable. This one is for when MC/madVR hangs when a UAC box appears (it does not hang with a MC/EVR combo).
Thanks
Nathan
-
Second set of logs - Green Line. This shows the toggling Crop edges. See pic below (note the CCC setting as suggested by raym are off). This only happens with MC/madVR (ok with MC/EVR) and the green lines can appear at the bottom and/or RHS depending of the original resolution of the clip being played and the % cropping being done (see posts above).
-
1) Using madVR .36 starting live TV playback has issues with scaling for me, the picture can be correct, VERY large or very small and up in the top left corner. Using the version supplied by madshi in the MC15 thread seems to resolve that issue. Is this what should be expected?
FYI - I've never seen a scaling issue on either of my pcs
-
So the other issues I've seen are:
* General Instability: I'll try to grabs logs when I get something to report but this one will be hit and miss and I'm sorry for the vague unhelpfullness of the this one! It is not too bad is would be OK if I was around but adds just enough issues to confound the Wife/Kids when something locks up.
* Can't Start Exclusive Mode: I should be able to grab logs of this at some point. Once madVR fails to start Exclusive Mode it was then always fail to start it on following media. A reboot fixes this.
* On a dual display, with madVR goes into Exclusive Mode on one screen MS Internet Explorer gets "locked" (you can't type in boxes like this, links don't activate etc) yet other apps like Notepad are unaffected.
I must say most of these "issues" are really minor. The big one is the stability factor (which will be the hardest to track down) as WAF is #1 for me.
Thanks
Nathan
-
FYI - I've never seen a scaling issue on either of my pcs
Hmm,
OK here is a log using .36 where I get the issue. http://www.thepalmers.com.au/temp_txfr/madVR - log_R1.zip (http://www.thepalmers.com.au/temp_txfr/madVR - log_R1.zip)
I start and then stop live TV playback on the same channel 3 times.
The 1st time scaling is correct. the 2nd I get a picture 1/4 of my screen size in the top left corner, the 3rd is OK again.
Richard
-
Doing some more testing I got MC to freeze. I did the same as the above post, but I enabled the switchig to exclusive mode (I'd disabled this for testing earlier).
So I started playback and stopped it a few times, the 2nd time I got a small imaage, the 3rd the image was OK but when I moved the mouse (which brings up the MC OSD positon bar) everything froze.
madVR and MC logs enclosed, sorry the madVR log is BIG!
http://www.thepalmers.com.au/temp_txfr/RP-Log2.zip (http://www.thepalmers.com.au/temp_txfr/RP-Log2.zip)
Richard
-
One more update.
Went back to trying madVR posted in the MC15 forum, this too is giving me scaling issues.
I thought this one was OK, but I just got a 1/4 sized image so I guess it's not OK either.
Richad
-
madShi,
A big thank you to you for helping getting this to work.
I see the green line at the edges. I do not know what the cause may be.
Crop Edges option is meant to remove vision noises that exist at the edges of video. Basically it removes the edges by specifying a smaller source rectangle by calling IBasicVideo::SetSourcePosition().
The option does not help with the green line problem reported here. It appears that the green lines are not visual noises that exist in the video itself. Rather they seem to be artifacts of rendering. When play a particular video clip, I do not get green lines when the option is off, but get a green line at the right edge, or bottom edge, depending on how much cropping is used (2% or 3%).
Any ideas?
Yaobing
-
In doing some testing on cnbc's issues, I found a bug using "Playback Info" to change refresh rates when madVR is the renderer:
EVR: Start Playback --> MC changes display based on Playback Info --> file plays --> when playback finishes MC changes display back to the original settings ;D
madVR: Start Playback --> MC changes display based on Playback Info --> file plays but MC changes display back to the original settings immediately --> when playback finishes nothing happens as it is already back to the original settings :(
It gets a bit more interesting if Reclock is also running and doing display rate changes:
madVR & Reclock: Start Playback --> MC changes display based on Playback Info --> file plays but MC changes display back to the original settings immediately then Reclock reads the frame rate and changes it back to suit --> when playback finishes Reclock changes display back to the original settings :o
Anyway it seems that when using madVR, MC is thinking that file playback ends immediately so changes the refresh rate back. I'm sure all the unnecessary refresh rate changes is not great!
-
@Yaobing, this might very well be a bug in madVR. I'll double check my "IBasicVideo::SetSourcePosition()" handling. Might take a couple of days, though.
-
@Yaobing, this might very well be a bug in madVR. I'll double check my "IBasicVideo::SetSourcePosition()" handling. Might take a couple of days, though.
madshi/Yaobing, I'm note sure if you have progressed with this at all but as now MC16 has added the ability to "Adjust audio rate to maintain video sync" we can use the JR Audio Renderer instead of Reclock but then we lose the alternative method of changing display rates till this bug is fixed.
Thanks
Nathan
-
jmone or madshi... I'm sure I could look and dig through mountains of threads over at AVS, but can one of you post a link to somewhere that explains why I might want to use madVR rather than EVR?
-
jmone or madshi... I'm sure I could look and dig through mountains of threads over at AVS, but can one of you post a link to somewhere that explains why I might want to use madVR rather than EVR?
First couple of posts at madshi's Doom9 thread (http://forum.doom9.org/showthread.php?p=1271414#post1271414) give most of the story.
-
Awesome. Thanks.
EDIT: Okay. This makes sense.
-
Is it just me or are others seeing stability issues using madVR with MC16?
I'm getting regular hangs, for example I was watching a TV recording (jtv) and paused playback, then I skipped forward a couple of times pressed play and tried to skip forward again, MC totally hung.
The other issue I have is that when I pause or skip and madVR switches from exclusive to windowed mode I get a few frames of whatever was left in the "windowed buffer" previously thus making for an odd visual experience every time I pause/skip.
I'm running win7 x64, 11.1 ati drivers on a HD5670 GPU.
Anybody else seeing either of these issues, or am I just "lucky"??
Cheers
Richard
-
@Richard.
if you can reproduce those hangs, it might help if you could create, zip and upload a madVR debug log for me to look at. If it's a bug in madVR, the log might help me figuring out where the hang comes from. However, if the whole MC hangs, I'm not sure if that can be the fault of madVR, since MC runs madVR in its own thread, so MC's GUI should stay active, even if madVR itself hangs. @Yaobing, what is your opinion on this?
The problem with the "old frames from the windowed buffer" is a known problem, but I'm pretty sure it's not a bug in madVR, but rather caused by the Windows GUI ("Aero"). I'm not sure if I can do anything about it, I kinda doubt it. You could try disabling Aero/Desktop Composition, maybe that fixes the problem. Or you could disable the exclusive mode, if windowed mode works well enough on its own. Or you could try to avoid switching between windowed <-> exclusive mode, if you can.
-
@Richard.
if you can reproduce those hangs, it might help if you could create, zip and upload a madVR debug log for me to look at. If it's a bug in madVR, the log might help me figuring out where the hang comes from. However, if the whole MC hangs, I'm not sure if that can be the fault of madVR, since MC runs madVR in its own thread, so MC's GUI should stay active, even if madVR itself hangs. @Yaobing, what is your opinion on this?
The problem with the "old frames from the windowed buffer" is a known problem, but I'm pretty sure it's not a bug in madVR, but rather caused by the Windows GUI ("Aero"). I'm not sure if I can do anything about it, I kinda doubt it. You could try disabling Aero/Desktop Composition, maybe that fixes the problem. Or you could disable the exclusive mode, if windowed mode works well enough on its own. Or you could try to avoid switching between windowed <-> exclusive mode, if you can.
Thanks madshi,
I have posted a log in an earlier post in this thread where MC has hung, along with the scaling issue I was seeing with live TV playback. I didn't see the scaling issue today so I'm hoping that fixed itself with my recent ATI update, but I was mainly testing with recordings so it may still be there.... I can generate more logs with hangs if you need them?
I already have aero disabled on my system and exclusive seems to produce better results I think so would like to use it if I can. How do I avoid switching? Is it a setting in madVR or do you mean avoid it by just not seeking/bringing up the MC OSD etc?
Thanks
Richard
-
I haven't had time to do any work on madVR in the last 2-4 weeks or something like that. So I haven't checked out the logs yet, either. One log for every problem would be helpful. If you've already posted a log about the hang earlier, then that should probably be good enough.
With avoiding exclusive mode I meant that you could try avoiding MC to have to draw any GUI stuff by avoiding to bring up the OSD etc. Of course that's not nice, but that's the price of exclusive mode: If you want it, you can't have normal GUI stuff. Does MC support exclusive mode for other renderers, btw? If so, does the normal MC GUI work there?
So it seems Aero is not at fault for displaying the "old" frames. Then it must be the new window drawing technique in Vista (and higher). Because in XP the problem does not exist.
-
Summary of current issues that I see between madVR and MC are:
- Green Line when cropping enabled
- Refresh Rate changes are reversed to the default immediately and not at the end of playback
- Stability (though it is better for me recently)
Thanks
Nathan
-
I think I have finally got to the bottom ofthe stability issue I was getting.
After a visit to Nathan (jmone) to actually see his system working correctly (which is almost identical to mine in terms of OS, GPU and drivers) the only real diffeence was the output settings in FFDShow Video.
ffdsow.jpg are my original settings and ffdshow2.jpg are the working settings.
Wth these I can skip, change channes etc without MC hanging and without odd scaling issues.... well so far anyway......
So in case anybody else is having madVR stability issues in the furute, hopfully you'll find this and it may help.
Richard
-
@Richard, I've no idea why ffdshow even allows these options to be disabled. Makes zero sense to me. Your original settings are very bad, they make ffdshow behave in a very bad way and I honestly think that these settings should be removed from ffdshow and forced on. But I don't think we've any chance to get this to happen. The ffdshow people seem to love having every funny thing customizable, even if it makes near zero sense. FWIW, every other good decoder behaves like ffdshow behaves with these options turned on.
-
@Richard, I've no idea why ffdshow even allows these options to be disabled. Makes zero sense to me. Your original settings are very bad, they make ffdshow behave in a very bad way and I honestly think that these settings should be removed from ffdshow and forced on. But I don't think we've any chance to get this to happen. The ffdshow people seem to love having every funny thing customizable, even if it makes near zero sense. FWIW, every other good decoder behaves like ffdshow behaves with these options turned on.
I just had them at default as I had no idea what they did! Either that or I copied jmone's settings as he sent me his originally, in which case he's a bad boy too!
Are thre any other settings in FFDShow that we should make sure are set a certain way for the best results in madVR?
Cheers
Richard
-
No other options needed, I think. Of course you want to disable any kind of processing that isn't absolutely needed.
-
I just had them at default as I had no idea what they did! Either that or I copied jmone's settings as he sent me his originally, in which case he's a bad boy too!
Are thre any other settings in FFDShow that we should make sure are set a certain way for the best results in madVR?
Cheers
Richard
Don't listen to Richard ...he Lies...all Aussies Lie...(see I just did it :) ) - he came over this arvo, copied my settings then it WORKED and now he complains! ;D
Seriously madshi - thanks for all of this...
-
No other options needed, I think. Of course you want to disable any kind of processing that isn't absolutely needed.
Mmmm the only other processing that I use in FFDSHOW is deinterlacing (YADIF with double frame rate seems to work well) and subtitles.....
-
Well, deinterlacing and subtitles are not supported by madVR yet, so they fall under "necessary processing".
-
I take it back, although more stabe than before I'm still getting MC hanging when changing live TV channels sometimes.
Now I continue to get sound but the picture jumps to the top left 1/4 of the screen and MC "stops responding".
I'll try to find a pattern (It may only be when switching between certain channels) and generate some logs today and post them here.
Cheers
Richard
EDIT:
A new update (old comments removed)....
I think I have found the solution now (I hope). For some reason MPEG1 and MPEG2 decoding in FFDShow was set to libmpeg2, I changed these back to the default of libavcodec and channel changing seems to be working OK now.
I'll continue to test and will report back if there is still a problem.
Richard
-
I recently started using madVR. I have ripped my Blu-rays to MKV, but have not recoded the video. On some movies madVR is used and on others it uses Video Renderer. First, do I need to change something to allow all of my MKV's to use madVR? Is it an ffdshow setting that is wrong or VC-1 vs H.264? Second, if a file can't use madVR, I would like my default to be Haali Video Renderer. Maybe there should be an option for secondary renderer.
-
@Richard, I've no idea why ffdshow even allows these options to be disabled. Makes zero sense to me. Your original settings are very bad, they make ffdshow behave in a very bad way and I honestly think that these settings should be removed from ffdshow and forced on. But I don't think we've any chance to get this to happen. The ffdshow people seem to love having every funny thing customizable, even if it makes near zero sense. FWIW, every other good decoder behaves like ffdshow behaves with these options turned on.
Actually, the default, grayed/middle state is not "disabled". It is more like an intellectual mode that first tries to use the better options (assuming the settings work as described). See the tooltips in the attached screenshots.
-
I recently started using madVR. I have ripped my Blu-rays to MKV, but have not recoded the video. On some movies madVR is used and on others it uses Video Renderer. First, do I need to change something to allow all of my MKV's to use madVR? Is it an ffdshow setting that is wrong or VC-1 vs H.264? Second, if a file can't use madVR, I would like my default to be Haali Video Renderer. Maybe there should be an option for secondary renderer.
It's probably the decoder settings in FFdshow. In the Codec settings, make VC1 "WMV9" (this will give you multi-threaded decoding, libavcoded is single threaded in VC1) and for h.264/AVC, select FFMPEG-MT. madVR requires YV12 input, so make sure your Output is set to YV12 (sounds like it probably already is).
-
It's probably the decoder settings in FFdshow. In the Codec settings, make VC1 "WMV9" (this will give you multi-threaded decoding, libavcoded is single threaded in VC1) and for h.264/AVC, select FFMPEG-MT. madVR requires YV12 input, so make sure your Output is set to YV12 (sounds like it probably already is).
My Output is set to YV12 and I changed my codec settings to match your suggestion. I verified during playback that ffdshow is the video decoder. However, the same MKV's still won't use madVR. The problem is not codec dependent. The Blind Side is VC-1, but won't use madVR. Public Enemies is also VC-1, but it will use madVR. I also tried some AVC encodings and some work and some don't. Any other suggestions?
-
Do you have any other FFDshow filters enabled?
On the FFDshow Output tab, uncheck all formats except YV12 (if you haven't tried that already). See what happens, seems weird.
-
I have no other ffdshow filters turned on. I had already tried with just YV12 selected but I did it again (I also usually have YUY2 selected under Packed YUV). Still the same problem. I also clicked on Info & CPU in ffdshow. Both Blind Side and Public Enemies are shown as VC-1, YV12, and being decoded by WMV9. However, Blind Side refuses to use madVR. Blind Side does have an aspect ratio of 1.78:1, but I don't think that would make any difference.
I am using 3dlut in madVR and SoftCubic for all the scaling options. The rest of my madVR settings are the default ones.
-
I just switched to using the lavf source filter and now all MKV's are using madVR! Now I need to figure out how to use it with DVD's. I am using ffdshow video/audio decoders for DVD, but I can't use madVR or Haali.
-
I don't think you can, as from what I understand (happy to be corrected), you will use the MS Navigation Filter and it insists on EVR. I don't know of any other "freeware" DVD Navigation Filters so the end result is no madVR from a DVD.
-
I don't think you can, as from what I understand (happy to be corrected), you will use the MS Navigation Filter and it insists on EVR. I don't know of any other "freeware" DVD Navigation Filters so the end result is no madVR from a DVD.
In case you guys don't know, you can use madVR with DVDs if you don't go through the DVD menus, but just go to the IFOs or VOBs directly....
@mojave:
I'm not sure what to make of that precisely re: switching to LAVF splitter, there must be something in the mediatype flags coming forward from the splitters that is affecting renderer pin connection. While LAVF is somewhat reliable with MC16, I'm having occasional issues with multi-zone video playback where the movie plays (or at least you can hear audio), but the MC display just says "Opening...........".
-
I just tried both and all I get from MC is "Waiting." The DVD never opens. I am using Windows 7 32 bit.
-
In case you guys don't know, you can use madVR with DVDs if you don't go through the DVD menus, but just go to the IFOs or VOBs directly....
Yup, it is then just standard file playback, no probs there (FYI I break many of the DVD conent up into individual files per TV Eps, or Video Music Track)
-
I just tried both and all I get from MC is "Waiting." The DVD never opens. I am using Windows 7 32 bit.
Oooops. Yeah, works fine in MPC-HC, not MC. MC appears to hard-code the load of the DVD Navigator with at "DVD File (vob,ifo)" is played directly.
-
Yup MC seems to have locked down playing VOBs as a normal file (not sure when this changed). Anyway, simple cheat is to rename VOB to MPG and all is fine if you just want to playback the single file. This is drifting from the aim though, which is trying to use madVR for DVD (not file) playback......I don't think we can....
-
%$&*%##@!!!
MC just hung again tonight changing channels when using madVR!
Usual thing happend; picture in top 1/4 of screen, audio continues to pay but MC/video frozen.
Have checked all my FFDShow settings etc and they are still as per my last posts.
madshi, any change of a debug version of .37 so I cna capture this please?
Cheers
Richard
-
I noticed a bug in MC16.0.24 + madvr combination with both VideoClock options enabled. When madvr is playing in exclusive mode and I do something (say change volume - which brings up the pop-up showing what is the current volume), madvr automatically switches to windowed mode. At this point, for a brief split second, there is a video frame displayed that is from some point of time long ago in this video stream. It seems to be around the time when madvr switched from windowed to exclusive last (could be many minutes ago). This is really annoying and disturbing. Similar phenomenon occurs when one pauses a video playing in madvr exclusive mode.
Is this a known issue? Should we just be using windowed mode in madvr at this point?
Thanks,
Osho
-
Yup. I know that it annoys Richard and he was going to play with some of the buffer settings. I did not notice it till he pointed it out ... but I also get a black frame or two when switching that I find distracting.
-
madshi did respond to this.
It's something to do with Vista/Win7 and he doesn't think there is anything he can do about it, although I have to say I really hope he thinks of something!
You can stay in windowed mode, but I think exclusive gives a better and smoother result, or at least on my system it seems to.
Richard
-
Yes, it's a known problem. However, Osho's report reads like the problem would be stronger with the new MC VideoClock options turned on. That's maybe something the MC guys could look at, don't know.
The ultimate solution to all this trouble would be to draw all GUI stuff in exclusive mode, so that madVR would never have to leave exclusive mode. But that's currently not possible, madVR doesn't offer MC any way to do that right now. madVR will add support for that in a future version, but then MC would also have to make use of that, so I don't know if that will ever happen.
Does MC support exclusive mode for any other renderer, btw?
-
Yes, it's a known problem. However, Osho's report reads like the problem would be stronger with the new MC VideoClock options turned on. That's maybe something the MC guys could look at, don't know.
Windows (Aero) keeps a hardware buffer for each Window and shows it at times you might not expect. This causes us troubles too, and we haven't found a good way around it.
The ultimate solution to all this trouble would be to draw all GUI stuff in exclusive mode, so that madVR would never have to leave exclusive mode. But that's currently not possible, madVR doesn't offer MC any way to do that right now. madVR will add support for that in a future version, but then MC would also have to make use of that, so I don't know if that will ever happen.
Isn't the ultimate solution good hardware that doesn't need exclusive mode? I mean, if the hardware can render the video and overlays without dropping frames, why not?
From what I can tell, even pretty modest hardware is capable of this. Both my work machine (old video card) and home machine (new video card) seem to handle 1080p without trouble in non-exclusive mode.
Is this a case of chasing low-end hardware (which should shrink in importance over time), or is there some other argument for exclusive mode?
Thanks.
-
Does MC support exclusive mode for any other renderer, btw?
VMR9 Renderless mode. For some reason that I have not understood, it does not work for all video cards and I did not try hard to fix it.
-
Windows (Aero) keeps a hardware buffer for each Window and shows it at times you might not expect. This causes us troubles too, and we haven't found a good way around it.
Isn't the ultimate solution good hardware that doesn't need exclusive mode? I mean, if the hardware can render the video and overlays without dropping frames, why not?
From what I can tell, even pretty modest hardware is capable of this. Both my work machine (old video card) and home machine (new video card) seem to handle 1080p without trouble in non-exclusive mode.
Is this a case of chasing low-end hardware (which should shrink in importance over time), or is there some other argument for exclusive mode?
Thanks.
I'm running Q9400 CPU running at 3.0Ghz and an ATI HD5670 GPU using the latest 11.1 ATI drivers and in windowed mode with a SD JTV recording madVR is dropping close to 20 frames a second in windowed, but none in exclusive.
EDIT: I just tested with the Realtek HDMI audio driver (for a different reason) and with the same video drivers as above but this audio driver madVR reports 1 frame dropped per second. Until I bring up the MC OSD then this jumps to 20 frames /second. I also get "Exclusive mode failed" with the Realtek driver.
Richard
-
Isn't the ultimate solution good hardware that doesn't need exclusive mode? I mean, if the hardware can render the video and overlays without dropping frames, why not?
From what I can tell, even pretty modest hardware is capable of this. Both my work machine (old video card) and home machine (new video card) seem to handle 1080p without trouble in non-exclusive mode.
Is this a case of chasing low-end hardware (which should shrink in importance over time), or is there some other argument for exclusive mode?
There are a number of arguments for exclusive mode:
(1) In windowed mode, every Direct3D9 "Present" call blocks until the present has succeeded. The reason for that is that actually "Present" ends up copying/blitting the rendered frame into the render window DC. This must be done during a VSync phase (otherwise there would be tearing), so "Present" can't return until the blitting was executed. In exclusive mode, "Present" goes to a backbuffer (if one is still available) and the "Present" call returns at once, allowing you to start rendering the next frame. This way you can render and present up to 32 frames (Windows 7) into the future. Meaning that even if the PC suddenly gets busy doing some funny stuff, the next (up to) 32 frames are already in the GPU driver frame queue and should show up just fine, without needing any CPU cycles. In windowed mode you can only ever render and present the very next frame. Meaning that if the PC suddenly gets busy and you get no CPU cycles for a couple of milliseconds, there may be frame drops. This problem is intensified if higher refresh rates are used. E.g. some madVR users are driving their CRT projectors with 120Hz.
(2) In windowed mode, the renderer has to use heaps of tricks (e.g. flushing the GPU and waiting for the result by polling the GPU state in a 100% CPU consuming loop) to make sure that no tearing occurs. That costs CPU and GPU performance, and even then, with a bit of bad luck, tearing can't always be avoided. In exclusive mode frames are switched in the driver in the VSync interrupt handler -> no tearing, ever. And better performance.
(3) Only exclusive mode allows the use of more than 8bit output. This may not sound very useful, but it would allow madVR to lower the dithering noise level, which might be visible on really big front projection screens.
(4) I'm not 100% sure, but I think only exclusive mode will support frame packed 3D rendering (HDMI 1.4a).
Is this a case of chasing low-end hardware (which should shrink in importance over time)
FWIW, the current madVR version only offers very basic video algorithms. I do plan to offer higher quality algorithms in the future, and more features. The highest quality algorithms might not run fluidly even with current high-end GPU hardware. E.g. there are scaling algorithms available which need a minute to upscale one 320x200 image, when using a current top-of-the-line CPU. If I implement such a scaling algorithm in madVR, you probably can't have enough GPU power.
VMR9 Renderless mode. For some reason that I have not understood, it does not work for all video cards and I did not try hard to fix it.
Hmmmmm... How do you draw your GUI in your exclusive mode VMR9 renderer? Do you simply not show any GUI at all? Or do you draw it onto the video image before passing it on to VMR9?
-
Hmmmmm... How do you draw your GUI in your exclusive mode VMR9 renderer? Do you simply not show any GUI at all? Or do you draw it onto the video image before passing it on to VMR9?
It is not pretty :-[. Basically we are not handling it. That is partly why I am actually considering removing that option completely.
-
Would it be possible for MC16 to provide an option (or do it automatically) to not display any of its own GUI elements when we are using madvr? MPC-HC does something similar (which also shows madvr's own seek bar - I don't know why MC16 does not show it). For example, if I paused with madvr, picture should just pause without any OSD. Ditto for volume changes/seek etc.
EDIT: Given the current situation, imho, it would be great if minimal interface was provided by madvr itself ( seek bar - which it already has, volume controls, prev, next, pause/play buttons are all that are needed ).
Thanks,
Osho
-
It is not pretty :-[. Basically we are not handling it. That is partly why I am actually considering removing that option completely.
Too bad. I was hoping you'd say that you had a GUI for your VMR exclusive renderer, because then we could have talked about how to make it work with madVR.
Would it be possible for MC16 to provide an option (or do it automatically) to not display any of its own GUI elements when we are using madvr? MPC-HC does something similar (which also shows madvr's own seek bar - I don't know why MC16 does not show it).
In exclusive mode madVR modifies the mouse messages, which works for MPC-HC, but not for any other media player, it seems. An MC option to avoid non-crucial OSD/GUI elements when madVR is in exclusive mode would be nice to avoid superfluous windowed <-> exclusive mode switches. But then which OSD/GUI messages are non-crucial and which are crucial? That may be hard to decide. It might even be a matter of taste. So the whole classification of non-crucial vs. crucial might open up a can of worms. Maybe a strict "don't show any GUI while madVR is in exclusive mode" would work, but wouldn't it be too restrictive? You'd lose the whole nice automatic windowed <-> exclusive mode switching logic.
EDIT: Given the current situation, imho, it would be great if minimal interface was provided by madvr itself ( seek bar - which it already has, volume controls, prev, next, pause/play buttons are all that are needed ).
I might add some more controls to madVR's own exclusive mode interface, but right now I don't plan to add pause/play buttons because you can simply configure every media player so that clicking into the video area pauses/restarts video. So buttons for pause and play are superfluous IMHO.
-
I might add some more controls to madVR's own exclusive mode interface, but right now I don't plan to add pause/play buttons because you can simply configure every media player so that clicking into the video area pauses/restarts video. So buttons for pause and play are superfluous IMHO.
My preferred solution would be for madVR to have an interface where we could provide an overlay image and position. Another way to do this would be for us to provide a callback for you to call in your render loop that provided us a device (or locked surface pointer to confine what we're able to do) where we could render overlays.
I don't think going the other direction and adding player controls and status to the renderer makes as much sense.
Would something like this be possible?
-
I don't think going the other direction and adding player controls and status to the renderer makes as much sense.
I agree.
-
My preferred solution would be for madVR to have an interface where we could provide an overlay image and position. Another way to do this would be for us to provide a callback for you to call in your render loop that provided us a device (or locked surface pointer to confine what we're able to do) where we could render overlays.
I don't think going the other direction and adding player controls and status to the renderer makes as much sense.
Well, the only reason why I've added a seekbar to madVR and am considering adding more controls is that most media players don't have a nice GUI yet (or any at all) for exclusive mode. So if I don't draw my own GUI, there is none, or madVR has to constantly switch between windowed <-> exclusive mode.
If you would be willing to create an exclusive mode GUI by providing an overlay image or reacting to callbacks, that would be great!! I agree with you that it makes more sense this way round. But it would require some work on your side, too. However, you could use the same GUI solution for madVR and for your own exclusive mode renderer(s), too. So your work would not be limited to work with madVR, only. FWIW, I think VMR/EVR exclusive mode OSDs/GUIs are usually drawn by calling "IVMRMixerBitmap(9)::SetAlphaBitmap", see here:
http://msdn.microsoft.com/en-us/library/dd390451%28v=vs.85%29.aspx
I was planning to support the same function/functionality in a future madVR version, too. So if you do plan to add support for drawing an exclusive mode OSD/GUI for madVR, you could start by writing one for your own VMR7 exclusive mode renderer. It should then later simply work with a future madVR version, too, once I've added support for the "SetAlphaBitmap" function. Of course if you plan to trash your VMR7 exclusive mode renderer, it might not make sense to work on an exclusive mode GUI for it now. In that case you could also simply wait until I've added the necessary functionality to madVR.
If you would prefer a different API for drawing the GUI/OSD, I'd be happy to add a custom API, too. In that case just let me know your wishes.
-
If you would be willing to create an exclusive mode GUI by providing an overlay image or reacting to callbacks, that would be great!!
For the on screen display (position, volume, etc.), I think it should be pretty easy for us to tunnel drawing to the renderer, and fallback to drawing to a window if the renderer doesn't support drawing.
We're already rendering the image to memory first anyway.
The player bar that appears on mouse movement would be also be easy to render, but I'm not sure how to handle mouse messages if there isn't really a window. If you're on your couch with a remote, you would never see this. But if you're at your desktop with a mouse, this is the main way to control playback. Any ideas?
-
For the on screen display (position, volume, etc.), I think it should be pretty easy for us to tunnel drawing to the renderer, and fallback to drawing to a window if the renderer doesn't support drawing.
We're already rendering the image to memory first anyway.
Great!
Does the "SetAlphaBitmap" logic look useful to you, or would you like a custom interface to do the madVR GUI drawing?
The player bar that appears on mouse movement would be also be easy to render, but I'm not sure how to handle mouse messages if there isn't really a window. If you're on your couch with a remote, you would never see this. But if you're at your desktop with a mouse, this is the main way to control playback. Any ideas?
There's an official way to get mouse messages. See here:
http://msdn.microsoft.com/en-us/library/dd377323%28v=vs.85%29.aspx
This should also work with madVR.
-
Great!
Does the "SetAlphaBitmap" logic look useful to you, or would you like a custom interface to do the madVR GUI drawing?
All our non-hardware accelerated drawing uses 32-bit ARGB images in memory (as a DIB section in an HDC). So in this case, we would provide the HDC.
But one issue with the HDC is that I don't think it will support the alpha channel nicely. VMR9AlphaBitmap takes a single overall alpha instead.
So from that standpoint, providing a pointer to a 32-bit ARGB buffer would be better since it would allow per-pixel alpha.
I'm assuming internally you just have a Direct3D overlay texture. If you create it with D3DFMT_A8R8G8B8, it's pretty simple to fill from an ARGB buffer. You could probably let the video card do the scaling (if any) by creating the texture the same size as the provided overlay.
-
Ok, will add an interface for that to a future madVR version. Might take a couple of weeks, though. I'll let you know when it's ready.
-
madshi - I see over in your Doom9 thread there seems to be some success in using madVR with the MS DVD Navigator filter, any comment as I thought that the MS DVD Navigator Filter would only connect to MS Video Renderers?
-
@jmone, I've seen that, too, and it surprised me, but I don't really know right now what's going on.
-
I see the green line at the edges. I do not know what the cause may be.
Crop Edges option is meant to remove vision noises that exist at the edges of video. Basically it removes the edges by specifying a smaller source rectangle by calling IBasicVideo::SetSourcePosition().
The option does not help with the green line problem reported here. It appears that the green lines are not visual noises that exist in the video itself. Rather they seem to be artifacts of rendering. When play a particular video clip, I do not get green lines when the option is off, but get a green line at the right edge, or bottom edge, depending on how much cropping is used (2% or 3%).
This was a bug in madVR. I didn't properly handle source rects with non-zero left/top values. The latest official madVR version (v0.37) now fixes this:
http://madshi.net/madVR.zip
Here is the first set of logs zipped together (an MC log and a madVR log)as it is the easiest to produce and 100% repeatable. This one is for when MC/madVR hangs when a UAC box appears (it does not hang with a MC/EVR combo).
Haven't had a chance to look at the UAC problem yet, but it's on my to do list for the next release.
Doing some more testing I got MC to freeze. I did the same as the above post, but I enabled the switchig to exclusive mode (I'd disabled this for testing earlier).
So I started playback and stopped it a few times, the 2nd time I got a small imaage, the 3rd the image was OK but when I moved the mouse (which brings up the MC OSD positon bar) everything froze.
madVR and MC logs enclosed, sorry the madVR log is BIG!
The log tells me that the decoder stops sending video frames to madVR. I don't know why, can't see that from the log, unfortunately.
%$&*%##@!!!
MC just hung again tonight changing channels when using madVR!
Usual thing happend; picture in top 1/4 of screen, audio continues to pay but MC/video frozen.
Have checked all my FFDShow settings etc and they are still as per my last posts.
madshi, any change of a debug version of .37 so I cna capture this please?
http://madshi.net/madVR.zip
I noticed a bug in MC16.0.24 + madvr combination with both VideoClock options enabled. When madvr is playing in exclusive mode and I do something (say change volume - which brings up the pop-up showing what is the current volume), madvr automatically switches to windowed mode. At this point, for a brief split second, there is a video frame displayed that is from some point of time long ago in this video stream. It seems to be around the time when madvr switched from windowed to exclusive last (could be many minutes ago). This is really annoying and disturbing.
You can fix this now in madVR v0.37 by letting madVR disable desktop composition (aka Aero) in fullscreen. madVR v0.37 will do this by default now. So the problem should be gone with default settings.
Windows (Aero) keeps a hardware buffer for each Window and shows it at times you might not expect. This causes us troubles too, and we haven't found a good way around it.
FWIW, I've found out that disabling desktop composition fixes this. Ok, that was kind of expected. But I also found that disabling desktop composition and reenabling it right away also fixes this problem. Disabling + reenabling sometimes doesn't look too nice, either, though.
-
I'm having aspect ratio issues with the new madV .37
MC is set to "Source Apsect Ratio" but 16:9 content isn't going full screen (it look slike 4:3 with black bard on each side) and 4:3 content is squashed vertically. I have to manually change the aspect to "1.78:1 Widescreen" to fix it.
Going back to .36 and everything work correctly again with Source aspect ratio.
Richard
-
Argh, this is a follow-up problem of the MPC-HC decoder crash workaround I implemented in v0.37. I've fixed this AR problem now in v0.39:
http://madshi.net/madVR.zip (v0.39)
-
Argh, this is a follow-up problem of the MPC-HC decoder crash workaround I implemented in v0.37. I've fixed this AR problem now in v0.39:
http://madshi.net/madVR.zip (v0.39)
WOW!
.37, .38 and now .39 all in one day! Go madshi!
And thank you.
-
Great set of updates, thanks madshi. Only done some brief testing but I now get the following Windows Diag Box evertime I try to play a file (Win 7 64-Bit)
-
Well, Windows just asks if you want to run the file, because you downloaded it, so Windows wants you to confirm, just to be safe. If you don't want Windows to ask you every time, simply uncheck "Always ask before opening this file", then press "Run". After that Windows shouldn't ask, anymore.
-
Yup got that (just reporting it in).
Ran through my test files and it looks really good so far. The Crop edges issues seems to be gone and playback looks very good but I've an issue with my 1920x1080/50p AVC Camcorder files where I'm dropping dozens of fames per second. I'll need to double check on my HTPC to see if it is just PC specific but do you have a debug version?
Thanks
Nathan
-
Also the UAC issue is better handled, in that it no longer stalls MC (just kills the playback)
-
Maybe 1080p50 is too much for your GPU to handle? Try switching the madVR scaling algorithms to "bilinear", just as a test.
Nice to hear about the UAC issue. The playback kill should be fixed is a future build.
-
FYI - Had to rollback to V43 from the new V45 as I was getting Black Screens and a non response MC (but Audio would play on). Let me know if you want JR or madVR Logs.
-
Hmmmm... I've just tried MC 16.0.49 and madVR v0.45 and it works just fine here.
-
Mmmm.... I'll have to play more tommorow but it has something to do with MC's "Playback Info". MC tags each file with a bunch of info to remember how to play it back (resolution, frame rates, streams, subs, cropping etc). It seems that some of the files with this playback info is causing the issue with V45 on my HTPC.
-
I don't really have any idea how v0.45 could behave different than v0.43 because of anything related to MC's "Playback Info" tags. But well, weirder things have happened, I guess. The only things (worth mentioning) that I changed in v0.44/v0.45 are really subtitle related, and I don't think MC is using any of that stuff.
-
I've been banging on MC and madVR .45 pretty hard with SD and HD sources, using Dscaler IVTC (got it working, finally) and FFDshow (AVC).
Working very well as before, though I do notice that with Dscaler and SD sources (DVD), MC will not start playing until I seek.
-
V46 is working for me on a quick test.
-
...
Working very well as before, though I do notice that with Dscaler and SD sources (DVD), MC will not start playing until I seek.
Solved with .47.
-
Now that lav splitter can handle Blu-ray and I can decode DTS-HD with the ArcSoft audio decoder, I setup my computer for playback directly from the Blu-ray without ripping to MKV. I tried two Blu-rays (MPEG 2) with both ffdshow video decoder and lav CUVID video decoder and I keep getting EVR as the renderer instead of madVR. I am currently ripping one of them to an MKV to see if I can use it with madVR, but I'm fairly sure that the MKV will work.
-
The rip finished and the MKV worked fine with madVR. I wonder why playback from the Blu-ray itself doesn't work?
-
Working fine for me - here is I Am Legend (VC-1, True HD) using LAV, and madVR. FYI - I've added BDMV and MPLS as a file type to the associates.xml file (see other thread) so this may be a difference to how you are importing them. That said, once JR add support to MC then we faultfinding will make sense.
-
FYI madshi has added display rate chager to his renderer!
-
Just an update from our side on madVR. I've had some troubles with madVR hanging when starting playback of television that's currently recording.
Mathias added logging to madVR that showed the trouble was because we use a zero size window when starting playback that madVR doesn't like.
We're changing this, but also changing the threading approach a little in the television playback code at the same time. It'll be a week or two before this is finished.
My goal is for madVR to be bullet-proof for me at home, after which I'd like to work on making it easier for users to enjoy.
I'm hoping Mathias gets a chance to make madVR cleanup more completely when unloaded in a coming build of madVR, because this is one of the few reservations I have about it currently.
Thanks all.
-
Thanks for the update Matt. Is there anything that needs test (I'll be giving the combo of madVR + display rate changing + JRSS instead of reclock this long week end)
-
I'm hoping Mathias gets a chance to make madVR cleanup more completely when unloaded in a coming build of madVR, because this is one of the few reservations I have about it currently.
Thanks all.
YEs, this will be interesting. I have had a handful of madVR crashes when stopping video playback in MC16, but it's been very few, sporadic, and impossible to repro. So far, with madVR v.58 and the later MC16 versions, it's been rock solid, so we'll see.
One anomaly I'm seeing now is when I set my monitor to 23.976Hz (23.97665Hz according to madVR) and playback 23.976fps movies, madVR reports a frame repeat every 20-40secs and then I get a frame drop (noticeable) every 2 minutes or so. This does not happen with MPC-HC (using Reclock or not). I'm using the JRiver Audio Renderer with the LAV Filters and FFDshow for video decoding and using FSE mode playback on my secondary HDTV.
Strangely (at least for now), when I insert Reclock back into the graph (removing JRiver Audio Renderer), change the monitor refresh to 24Hz (24.00016 according to madVR), I get no drops and madVR reports a frame drop every 3 or 4 hours.
-
One anomaly I'm seeing now is when I set my monitor to 23.976Hz (23.97665Hz according to madVR) and playback 23.976fps movies, madVR reports a frame repeat every 20-40secs and then I get a frame drop (noticeable) every 2 minutes or so. This does not happen with MPC-HC (using Reclock or not). I'm using the JRiver Audio Renderer with the LAV Filters and FFDshow for video decoding and using FSE mode playback on my secondary HDTV.
Strangely (at least for now), when I insert Reclock back into the graph (removing JRiver Audio Renderer), change the monitor refresh to 24Hz (24.00016 according to madVR), I get no drops and madVR reports a frame drop every 3 or 4 hours.
I've done a quick run through my test files and find that I'm not dropping/repeating frames at all (see the JR, mad & LAV: Testing thread for more details http://yabb.jriver.com/interact/index.php?topic=62996.0 ) but I'm using refresh rates of 24 not 23.976hz and 60 not 59.94hz and of course 50hz. I now need to run a movie for longer to see if any issue come up but 10-min checks on stuff like the opening few chapters of Transformers (the the rotating cube etc) was perfect for me.
-
Just an update from our side on madVR. I've had some troubles with madVR hanging when starting playback of television that's currently recording.
Mathias added logging to madVR that showed the trouble was because we use a zero size window when starting playback that madVR doesn't like.
We're changing this, but also changing the threading approach a little in the television playback code at the same time. It'll be a week or two before this is finished.
My goal is for madVR to be bullet-proof for me at home, after which I'd like to work on making it easier for users to enjoy.
I'm hoping Mathias gets a chance to make madVR cleanup more completely when unloaded in a coming build of madVR, because this is one of the few reservations I have about it currently.
Thanks all.
I too get the odd hangs - any progress on this?
Also madshi has just added a PAL speeddown option (play 25p at 24hz) that works with Reclock, any chance that this can also work with MC?
-
I've been using madVR with MC16 for the past few days. I haven't had any problems at all with hanging/crashing. Things are almost perfect. Absolutely loving this setup.
-
For some reason I still randomly get "Exclusive Mode Failed" messages when madVR tries to switch from Windowe to Exclusive mode.
Once I get this message I get a lot of dropped frames.
The only way to fix it is to close MC down (and MC Server) and restart MC. It will then work agian fine for a while and then at some stage I'll start getting the messages again.
This has been happening ever since I started using madVR.
Win7 Ultimate X64 with latest versions of MC, reclock and madVR on an ATI 5670 GPU, with latest ATI drivers
Any ideas why?
Thanks
Richard
-
For some reason I still randomly get "Exclusive Mode Failed" messages when madVR tries to switch from Windowe to Exclusive mode.
Once I get this message I get a lot of dropped frames.
You might look at the 'Handles' column in Task Manager. Is it high when this happens (over 1500)?
-
Has there been any progress on adding hardware accel to madvr? I'd like to use it madvr, but my amd zacate setup simply isn't powerful enough w/o the hw accel.
-
I'm using GPU decoders myself. LAV CUVID is a CUDA decoder that Nevcairiel wrote for nVidia cards. Cyberlink Video Decoder has HAM mode for AMD cards. That offloads all video decoding to the GPU's but still brings the decoded frames back into system memory for madVR to do its rendering magic. Best of both worlds. :)
-
I'm using GPU decoders myself. LAV CUVID is a CUDA decoder that Nevcairiel wrote for nVidia cards. Cyberlink Video Decoder has HAM mode for AMD cards. That offloads all video decoding to the GPU's but still brings the decoded frames back into system memory for madVR to do its rendering magic. Best of both worlds. :)
Hi - when you get time do you mind adding some details of the Cyberlink HAM Filter stuff to this thread http://yabb.jriver.com/interact/index.php?topic=63282.0 - I think we have the others covered so far.
-
Sure. I can do that tomorrow. It's late here.