Topic: madVR - Any more refinement? (Read 28784 times)

Mike Noe · « **Reply #50 on:** February 03, 2011, 03:41:54 pm »

Quote from: mojave on February 03, 2011, 03:36:44 pm

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.

jmone · « **Reply #51 on:** February 03, 2011, 03:46:23 pm »

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....

rpalmer68 · « **Reply #52 on:** February 06, 2011, 05:07:34 am »

%$&*%##@!!!

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

Osho · « **Reply #53 on:** February 07, 2011, 01:40:25 pm »

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

jmone · « **Reply #54 on:** February 07, 2011, 02:01:03 pm »

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.

rpalmer68 · « **Reply #55 on:** February 07, 2011, 03:18:57 pm »

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

madshi · « **Reply #56 on:** February 07, 2011, 03:48:02 pm »

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?

Matt · « **Reply #57 on:** February 07, 2011, 04:06:12 pm »

Quote from: madshi on February 07, 2011, 03:48:02 pm

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.

Quote

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.

Yaobing · « **Reply #58 on:** February 07, 2011, 04:17:42 pm »

Quote from: madshi on February 07, 2011, 03:48:02 pm

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.

rpalmer68 · « **Reply #59 on:** February 07, 2011, 05:53:35 pm »

Quote from: Matt on February 07, 2011, 04:06:12 pm

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

madshi · « **Reply #60 on:** February 08, 2011, 01:44:52 am »

Quote from: Matt on February 07, 2011, 04:06:12 pm

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).

Quote from: Matt on February 07, 2011, 04:06:12 pm

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.

Quote from: Yaobing on February 07, 2011, 04:17:42 pm

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?

Yaobing · « **Reply #61 on:** February 08, 2011, 11:05:52 am »

Quote from: madshi on February 08, 2011, 01:44:52 am

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.

Osho · « **Reply #62 on:** February 08, 2011, 02:00:43 pm »

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

madshi · « **Reply #63 on:** February 08, 2011, 04:10:02 pm »

Quote from: Yaobing on February 08, 2011, 11:05:52 am

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.

Quote from: Osho on February 08, 2011, 02:00:43 pm

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.

Quote from: Osho on February 08, 2011, 02:00:43 pm

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.

Matt · « **Reply #64 on:** February 08, 2011, 06:03:38 pm »

Quote from: madshi on February 08, 2011, 04:10:02 pm

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?

JimH · « **Reply #65 on:** February 08, 2011, 06:33:38 pm »

Quote from: Matt on February 08, 2011, 06:03:38 pm

I don't think going the other direction and adding player controls and status to the renderer makes as much sense.

I agree.

madshi · « **Reply #66 on:** February 09, 2011, 02:36:51 am »

Quote from: Matt on February 08, 2011, 06:03:38 pm

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.

Matt · « **Reply #67 on:** February 09, 2011, 08:59:03 am »

Quote from: madshi on February 09, 2011, 02:36:51 am

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?

madshi · « **Reply #68 on:** February 09, 2011, 10:02:50 am »

Quote from: Matt on February 09, 2011, 08:59:03 am

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?

Quote from: Matt on February 09, 2011, 08:59:03 am

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.

Matt · « **Reply #69 on:** February 09, 2011, 04:40:39 pm »

Quote from: madshi on February 09, 2011, 10:02:50 am

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.

madshi · « **Reply #70 on:** February 10, 2011, 01:06:16 am »

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.

jmone · « **Reply #71 on:** February 10, 2011, 02:22:38 am »

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?

madshi · « **Reply #72 on:** February 10, 2011, 02:43:32 am »

@jmone, I've seen that, too, and it surprised me, but I don't really know right now what's going on.

madshi · « **Reply #73 on:** February 22, 2011, 08:57:38 am »

Quote from: Yaobing on January 13, 2011, 06:06:48 pm

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

Quote from: jmone on January 13, 2011, 02:46:30 pm

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.

Quote from: rpalmer68 on January 13, 2011, 04:18:32 pm

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.

Quote from: rpalmer68 on February 06, 2011, 05:07:34 am

%$&*%##@!!!

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

Quote from: Osho on February 07, 2011, 01:40:25 pm

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.

Quote from: Matt on February 07, 2011, 04:06:12 pm

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.

rpalmer68 · « **Reply #74 on:** February 22, 2011, 03:30:57 pm »

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

madshi · « **Reply #75 on:** February 22, 2011, 03:54:30 pm »

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)

rpalmer68 · « **Reply #76 on:** February 22, 2011, 04:30:23 pm »

Quote from: madshi on February 22, 2011, 03:54:30 pm

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.

jmone · « **Reply #77 on:** February 23, 2011, 03:52:39 am »

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)

madshi · « **Reply #78 on:** February 23, 2011, 04:36:21 am »

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.

jmone · « **Reply #79 on:** February 23, 2011, 05:06:11 am »

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

jmone · « **Reply #80 on:** February 23, 2011, 05:08:40 am »

Also the UAC issue is better handled, in that it no longer stalls MC (just kills the playback)

madshi · « **Reply #81 on:** February 23, 2011, 05:22:37 am »

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.

jmone · « **Reply #82 on:** March 19, 2011, 10:21:39 pm »

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.

madshi · « **Reply #83 on:** March 20, 2011, 03:26:22 am »

Hmmmm... I've just tried MC 16.0.49 and madVR v0.45 and it works just fine here.

jmone · « **Reply #84 on:** March 20, 2011, 06:10:12 am »

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.

madshi · « **Reply #85 on:** March 20, 2011, 06:50:24 am »

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.

Mike Noe · « **Reply #86 on:** March 20, 2011, 10:49:14 am »

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.

jmone · « **Reply #87 on:** March 20, 2011, 09:45:00 pm »

V46 is working for me on a quick test.

Mike Noe · « **Reply #88 on:** March 21, 2011, 06:44:09 am »

Quote

...
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.

mojave · « **Reply #89 on:** April 13, 2011, 02:46:59 pm »

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.

mojave · « **Reply #90 on:** April 13, 2011, 03:46:47 pm »

The rip finished and the MKV worked fine with madVR. I wonder why playback from the Blu-ray itself doesn't work?

jmone · « **Reply #91 on:** April 13, 2011, 04:21:07 pm »

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.

jmone · « **Reply #92 on:** April 18, 2011, 05:42:59 pm »

FYI madshi has added display rate chager to his renderer!

Matt · « **Reply #93 on:** April 18, 2011, 05:58:23 pm »

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.

jmone · « **Reply #94 on:** April 18, 2011, 06:33:03 pm »

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)

Mike Noe · « **Reply #95 on:** April 22, 2011, 08:04:28 am »

Quote from: Matt on April 18, 2011, 05:58:23 pm

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.

jmone · « **Reply #96 on:** April 23, 2011, 07:15:46 pm »

Quote from: Mike Noe on April 22, 2011, 08:04:28 am

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.

jmone · « **Reply #97 on:** April 29, 2011, 05:38:57 am »

Quote from: Matt on April 18, 2011, 05:58:23 pm

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?

SamuriHL · « **Reply #98 on:** April 29, 2011, 08:20:54 am »

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.

rpalmer68 · « **Reply #99 on:** April 29, 2011, 04:37:10 pm »

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

INTERACT FORUM

Author Topic: madVR - Any more refinement? (Read 28784 times)