madVR - high quality video renderer (GPU assisted)

[djsolidsnake86]

BUG: directvobsub problem in some video files persist in 0.13 :(

[cyberbeing]

Somewhat unexpectedly, I now have a NVIDIA GTX 470 on my hands for the next 2 weeks. Currently using the Forceware 197.75 driver on WinXP SP3 x86. That driver does work with madVR.

First thing I did was test that Avatar scene which was causing my 7800GTX 512 major grief. There was still a rendering spike, but overall it seems the GTX 470 is able to muscle through it.

At 1920x1080@120Hz display resolution using Spline64 Chroma resizing, the max render (5s) only spiked from 14ms nominally to 20ms and it got through the scene without any dropped frames.

Next I tired something a bit more intensive with a 2560x1440@72Hz display resolution using Spline64 for both Luma and Chroma resizing. During that scene the max render (5s) spiked from 24ms nominal to somewhere between 27-47ms. Each time I run it it seems different. Occasionally it would drop a single frame, most times it would get through without dropping anything. Somewhat odd behavior.

Another thing I seem to be noticing is that when the 3DLut is applied, it looks much sharper and detailed then I ever remember it looking on the 7800GTX 512, but that could just be better Digital to Analog circuitry. Still makes me somewhat wonder if madVR's 3DLut functionality was ever functioning correctly on my 7800GTX 512 in the first place.

For whatever reason (without any direct comparison) playback doesn't seem as smooth as the 7800GTX 512. I'm not sure why, but the GTX 470 feels like it occasionally stutters during playback, even though it rendering like a champ without any dropped frames. Though now that I think about it, eariler in this thread I reported getting occasional stutters without dropped frames with the 7800GTX 512 as well. Hmm... Maybe it's the opposite and the GTX 470 is smoother when madVR is working correctly, so when a stutter happens it's that much more apparent. With the 7800GTX 512 maybe the gap between 'normal' and a 'stutter' was much smaller and less apparent.

I'm not sure if it's related, but on the GTX 470, the max present (5s) jumps between 8ms and 18ms every few seconds when playing back video at 1600x1200 @96Hz (Vsync interval 10.42ms).

madshi, if you have anything you want me to test please ask soon so I can do as much as possible in the time the GTX 470 is available to me. On June 18th it's going back no matter what.

GTX 470
Windows XP SP3 x86
MPC-HC w/ Reclock
1600x1200 @96Hz | 1920x1080 @120Hz | 2560x1440 @72Hz
Single Monitor

[iSunrise]

It seems I was right about the GPU switching power/clock states when using madVR 0.13, as in my case I could indeed solve the max stats(5s) spiking with the option "Power management mode" and selecting "Prefer maximum performance" under "Manage 3D settings" instead of the default "Adaptive" selection. It´s rock solid now.

http://www.abload.de/thumb/madvr_0.13_adaptivej19e.png (http://www.abload.de/image.php?img=madvr_0.13_adaptivej19e.png) http://www.abload.de/thumb/madvr_0.13_max3df4pp.png (http://www.abload.de/image.php?img=madvr_0.13_max3df4pp.png)
(left adaptive, right maximum performance)

For all NVIDIA users, here´s a very good and detailed article for this on geeks3d:
http://www.geeks3d.com/20090716/nvidia-forceware-190-38-beta-graphics-drivers-with-power-management-capabilities/

In short: When you select "Prefer maximum performance" the driver will always force the GPU to work in maximum performance 3D mode and not allow it to switch between power states based on the actual load of the GPU.

This is especially important on mobile variants of the GPUs out there (e.g. 9400M), where the pre-programmed values are very low to save as much power as possible. These values can also be different based on the actual variant of your graphics card, when there´s a specifically programmed BIOS from a board manufacturer which doesn´t use the reference design provided by NVIDIA.

However, according to the article (not sure if this is still up-to-date) this setting is only available on Vista or higher, so I´m not sure whether there´s even a way for XP users to "force" the maximum performance mode.

Now, since always running your GPU at it´s maximum 3D performance is a total waste of energy I created an application profile for KMPlayer (your player of choice), so that whenever I want to play a movie or video, the above setting will take effect, otherwise I still have "Adaptive" selected on the global profile, so that when I e.g. surf the web the lower power/clock states will be used.

I´m not sure about ATI users though, but it´s possible there´s also a settings to control power modes. If not, maybe you can solve that by using some 3rd party tool.

@cyberbeing:
Can you report if this is possible on XP, too? If yes, please try it out, I think this should solve your spikes, too. Especially since a GTX470 should be powerful enough for almost every content @1900x1080@120Hz (at the very least) and Spline64 chroma upsampling when you´re on maximum performance 3D mode.

@madshi:
On a 1920x1200 display resolution, windowed-mode is always resizing (at least for) 1080p content with madVR 0.13. madVR´s OSD shows the movie resolution as 1920, 800 and the target rectangle as 0, 3, 1902, 796 which will always invoke downsampling. The captures from above show fullscreen (left) and windowed-mode (right) screenshots. Fullscreen mode is ok. Is this intended, normal behaviour?

[madshi]

In madvr I have the anti trearing fix disabled, in reclock I have vsync correction enabled.
Please disable Reclock vsync correction. It doesn't help madVR, instead it makes things more difficult.

madVR's "Connection media type" from its input pin seems a bit odd now.

The horizontal sizes are being rounded up to either 128, 256, 512, 1024, 2048, or 4096.

[...]

Since it appears to be purposeful, why was this change made?
I've done that because VMR9 does it the same way. I thought decoders would be happier this way. But I've already reverted that change in my sources because I didn't notice any improvement anywhere.

Using the madVR [debug].ax appears to completely eliminate the lag going from fullscreen to windowed and windowed to fullscreen.
Weird. Probably some kind of strange timing issue.

I've also run into another problem which caused a hang when opening a video with MPC-HC. I believe this problem may have existed in prior versions of madVR as well. Or for all I know, it may not be madVR to blame at all.
Don't know, the log doesn't help in this case.

In the mean time, could you please quickly release a 0.13 debug build with logging disabled or optional logging
The "debug build" is the same as the "release build", just with added logging code. That's the only difference. If I disable logging, you end up with the release build, once again.

I know my GPU is a bit slow, 7600 GT 256mb and Core 2 Duo E6600, but I've noticed a slowdown in 0.13 especially if I use Spline36 resizer and going between windowed and fullscreen mode (720p movies). I don't mind using Mitchell for luma upscaling, but the switching lag is quite noticeable. Thanks for the continued updates :cool:
Your post lacks OS information, Aero on/off, display mode etc.

madshi, I have uploaded a sample that displays in the correct AR with renderers other than madVR.

It should fill the screen 16:9 and does, just not with madVR. Forgive the 68mb file size. If its too large I'll try to make another sample from it. Its the trailer for "The World Is Not Enough".
Incorrect AR also happend with VMR9 on my PC, at a quick check. Which decoder and splitter are you using? Please everyone, if you upload aspect ratio clips, always state the decoder and splitter you're using, because they play a key role in this.

Fullscreen -> win+D (minimize everything):
http://img139.imageshack.us/img139/7114/madvr.png

Not a big problem since the picture comes back when you press play, but just in case it's easy to fix...
Your post lacks OS information, Aero on/off, display mode etc.

BUG: directvobsub problem in some video files persist in 0.13 :(
Which problem?

Another thing I seem to be noticing is that when the 3DLut is applied, it looks much sharper and detailed then I ever remember it looking on the 7800GTX 512, but that could just be better Digital to Analog circuitry. Still makes me somewhat wonder if madVR's 3DLut functionality was ever functioning correctly on my 7800GTX 512 in the first place.
The 3dlut either works or doesn't work. There's no way the 3dlut can result in less sharp image. If it doesn't work, you'd get all screwed up image.

For whatever reason (without any direct comparison) playback doesn't seem as smooth as the 7800GTX 512. I'm not sure why, but the GTX 470 feels like it occasionally stutters during playback, even though it rendering like a champ without any dropped frames. Though now that I think about it, eariler in this thread I reported getting occasional stutters without dropped frames with the 7800GTX 512 as well. Hmm... Maybe it's the opposite and the GTX 470 is smoother when madVR is working correctly, so when a stutter happens it's that much more apparent. With the 7800GTX 512 maybe the gap between 'normal' and a 'stutter' was much smaller and less apparent.
Once again I'm missing your OS information, Aero on/off. Display mode etc. I know, you probably already stated that information 5 times in this thread. But I can't remember everybody's setup. And I don't feel like searching through the thread all the time. So please restate your setup information, everytime you report a new (potential) problem.

FWIW, I've just seen somewhere you're using 120Hz? That's a very high refresh rate. Basically the higher the refresh rate, the more difficult it is for madVR to achieve perfect smoothness. However, a future madVR version in fullscreen exclusive mode with a new special rendering path should be able to achieve perfect smoothness with e.g. 120Hz. But that's a few revisions away. With the current version lower refresh rates makes things easier for madVR to achieve smooth motion.

madshi, if you have anything you want me to test please ask soon so I can do as much as possible in the time the GTX 470 is available to me. On June 18th it's going back no matter what.
I don't have anything specific in mind right now.

It seems I was right about the GPU switching power/clock states when using madVR 0.13, as in my case I could indeed solve the max stats(5s) spiking with the option "Power management mode" and selecting "Prefer maximum performance" under "Manage 3D settings" instead of the default "Adaptive" selection. It´s rock solid now.
Interesting!

On a 1920x1200 display resolution, windowed-mode is always resizing (at least for) 1080p content with madVR 0.13. madVR´s OSD shows the movie resolution as 1920, 800 and the target rectangle as 0, 3, 1902, 796 which will always invoke downsampling. The captures from above show fullscreen (left) and windowed-mode (right) screenshots. Fullscreen mode is ok. Is this intended, normal behaviour?
The media player controls this. madVR does what it's told to do by the media player. You should double check the zoom settings in your media player.

[ajp_anton]

Fullscreen -> win+D (minimize everything):
http://img139.imageshack.us/img139/7114/madvr.png

Not a big problem since the picture comes back when you press play, but just in case it's easy to fix...
Your post lacks OS information, Aero on/off, display mode etc.
Sorry... I didn't think of it as a serious bug report as it doesn't cause any problems =)
GPU: HD4850
OS: Windows 7 x64
Aero: on
Display: 1920x1200 @ 60Hz, single

If I pause the video first, I get "-resetting Direct3D device failed (80070057)".
I get 80004001 whether I pause the video first or not.
Though I can't remember what I did last time, now I'm just getting 80004001 if I pause it first, and an additional
"- creating Direct3D device failed"
together with the 80004001 if I don't pause.

[djsolidsnake86]

incompatibility with some files and directvobsub: video is black and there is no playback

[madshi]

incompatibility with some files and directvobsub: video is black and there is no playback
I've written a long and detailed report about this problem at the time of the (a few posts before or after) madVR 0.13 release. Please search for that post.

[changturkey]

Hey guys, sorry, newb here, but how do I get subtitles working correctly with MPC HC and Madvr?

[cyberbeing]

Once again I'm missing your OS information...

...Basically the higher the refresh rate, the more difficult it is for madVR to achieve perfect smoothness...

I went back added my information to my previous post.

GTX 470
Windows XP SP3 x86
MPC-HC w/ Reclock
1600x1200 @96Hz | 1920x1080 @120Hz | 2560x1440 @72Hz
Single Monitor

I tested for smoothness a bit more this morning. Oddly enough, the first time I opened the video which was causing me jerkyness, it played back perfectly smooth at 1920x1080 @120Hz. The 2nd through 5th time it was incredibly jerky, and the 6th and 7th time it was smooth again. I assume not catching VSync properly is the 'difficulty' you speak of.


For future reference, would ~275MB (~125MB compressed) 'full' application crash dumps created by Dr. Watson be helpful to you when a crash happens?

I don't really know how to interpret the dumps or logs, but it seems the drwtsn32.log always lists madVR as doing both of the following during the crash, but for all I know it has nothing to do with it:

VSync_EvaluateThread();.by

and then

UploadThread();

What is the chance that VSync_EvaluateThread() or UploadThread() could crash madVR? Were those things changed in 0.13?

[madshi]

Hey guys, sorry, newb here, but how do I get subtitles working correctly with MPC HC and Madvr?
By using DirectVobSub. But you need to use the "right" version. There are 3 different flying around, as far as I've been told.

I tested for smoothness a bit more this morning. Oddly enough, the first time I opened the video which was causing me jerkyness, it played back perfectly smooth at 1920x1080 @120Hz. The 2nd through 5th time it was incredibly jerky, and the 6th and 7th time it was smooth again. I assume not catching VSync properly is the 'difficulty' you speak of.
Strange. Please try again with v0.14. Maybe the new tweak options help?

For future reference, would ~275MB (~125MB compressed) 'full' application crash dumps created by Dr. Watson be helpful to you when a crash happens?
They might. In order to make them perfectly useful, I may have to make the debug build a real debug build. Currently it's just a release build with added logging. But still, even with a release build the crash dumps may help. Sometimes, at least. Please don't upload v0.13 crash dumps, though. You can start with v0.14.

[madshi]

madVR 0.14 released

http://madshi.net/madVR.zip

* fixed: corruption with some decoders and video clips
* fixed: fullscreen -> win+D -> ResetDevice failed
* optimized fullscreen <-> windowed switching a bit
* relaxed texture requirements -> newer Intel GPUs might work now
* added new option "use managed upload textures (XP only)"
* added several new options to tweak GPU flush behaviour
* removed "disable anti-tearing fix" option
I need feedback on the new options in the "windowed mode tweaks" section of the settings dialog. It's very important, that you test these options and report back which options work best for you and which don't. I plan to remove (most of) these options in v0.15 again, replacing them with whatever you guys find out to work best. That means, if you don't give feedback, it might happen that I choose options, which work well for some other people but not for you. So it's your own responsibility to help me choose the right settings for future madVR versions. The reason why I want to get rid of the options in v0.15 again is that I'd like to avoid making the settings dialog any more complicated than is absolutely necessary.

Explanation:

The new option "use managed upload textures (XP only)" changes the way madVR uploads the video to the GPU. If you check this option, rendering will probably be a bit slower, but changes between fullscreen and windowed mode may work faster. This option is only available for XP. madVR 0.12 behaved as if this option was checked. madVR 0.13 behaved as if this option was unchecked.

The flush options control when exactly madVR flushes the GPU and in which way. The option "don't flush" obviously doesn't flush the GPU at all. The option "flush" flushes the GPU, but doesn't wait for the flush to complete. The option "flush & wait (sleep)" flushes the GPU and waits for the flush to complete, by telling to CPU to go sleeping for 1ms at a time. The sleeping saves CPU resources, but the CPU may sleep too long, wasting potential rendering resources. The option "flush & wait (loop)" flushes the GPU and waits for the flush to complete, by constantly checking the GPU state. The CPU (1 core) will run at 100% while waiting for the GPU, when using this option.

My suggestion would be to start with all flushes turned off ("don't flush") because that's the best, if you want to keep rendering times down. However, doing it this way may cause stuttering, because the GPU might become confused. So some flushes will probably be necessary. If you find that flushes are needed in your case, try "flush" (without waiting) next. If that doesn't work well enough yet, try one of the wait options. Personally, on my Vista laptop it seems that the best configuration is to set "after render steps" to "flush" and to set "after last step" to "flush & wait (sleep)" and to keep all other options at "don't flush". But please find out your own best settings and report them to me. Please, when you report them, state your exact HTPC setup, as always. Thanks!

[Keiyakusha]

madshi
Thanks for new version!

P.S.
I'm curious if you got any useful response about subtitles pin?

[noee]

Instant crash with .14.... HD2600XT, CCC10.3, Win7 x64, Aero OFF, FFdshow/Reclock/MPC-HC, either monitor (dual mon). EVR-CP works fine.

00000000 Creator Thread "Creator" = ThreadID 00000690
00000000 Creator CVideoRenderer::CreateInstance();
00000000 Creator CVideoInputPin constructor;
00000000 Creator CVideoInputPin constructor -> +
00000000 Creator CVideoText constructor;
00000000 Creator CVideoText::GetClassWindowStyles();
00000000 Creator CVideoText::GetClassWindowStyles() -> +
00000000 Creator CVideoText::OnReceiveMessage(msg: 129, wParam: 0, lParam: 80855076);
00000000 Creator CVideoText::OnReceiveMessage() -> +
00000001 Creator CVideoText::OnReceiveMessage(msg: 131, wParam: 0, lParam: 80855056);
00000001 Creator CVideoText::OnReceiveMessage() -> +
00000001 Creator CVideoText::OnReceiveMessage(msg: 1, wParam: 0, lParam: 80855076);
00000001 Creator CVideoText::OnReceiveMessage() -> +
00000001 Creator CVideoText constructor -> +
00000001 Creator CVideoRenderer constructor;
00000001 Creator Settings_Init();
00000002 Creator Settings_Init() -> +
00000002 Creator Queue_Init();
00000002 Creator Osd_InitKeyHook();
00000002 Creator Osd_InitKeyHook() -> +
00000002 Creator CVideoRenderer constructor -> +
00000002 Creator CVideoRenderer::CreateInstance() -> +
00000002 Creator CVideoRenderer::NonDelegatingQueryInterface(IUnknown{00000000-0000-0000-C000-000000000046});
00000002 Creator CVideoRenderer::NonDelegatingQueryInterface() -> 0
00000002 Creator CVideoRenderer::NonDelegatingQueryInterface(IUnknown{00000000-0000-0000-C000-000000000046});
00000002 Creator CVideoRenderer::NonDelegatingQueryInterface() -> 0
00000002 Creator CVideoRenderer::NonDelegatingQueryInterface({9cc7f9f7-3ed1-493c-AF65-527EA1D9947F});
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface() -> ISubRender
00000003 Creator CVideoRenderer::SetCallback();
00000003 Creator CVideoRenderer::SetCallback() -> +
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface({56a86895-0ad4-11ce-B03A-0020AF0BA770});
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface() -> 0
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface({8e1c39a1-de53-11cf-AA63-0080C744528D});
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface() -> 80004002
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface({f90a6130-b658-11d2-AE49-0000F8754B99});
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface() -> 80004002
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface({56a86895-0ad4-11ce-B03A-0020AF0BA770});
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface() -> 0
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface({cedb2890-53ae-4231-91A3-B0AAFCD1DBDE});
00000003 Creator CVideoRenderer::NonDelegatingQueryInterface() -> 80004002
00000003 Creator CVideoRenderer::GetPin(0);
00000003 Creator CVideoRenderer::GetPin() -> +
00000003 Creator CVideoRenderer::GetPin(0);
00000003 Creator CVideoRenderer::GetPin() -> +
00000003 Creator CVideoInputPin::CheckMediaType();
00000003 Creator CVideoRenderer::CheckMediaType({32315659-0000-0010-8000-00AA00389B71});
00000003 Creator GetVih2 original media type:
00000003 Creator AM_MEDIA_TYPE:
majortype: {73646976-0000-0010-8000-00AA00389B71}
subtype: {32315659-0000-0010-8000-00AA00389B71}
formattype: {f72a76a0-eb0a-11d0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 380160
cbFormat: 112
00000003 Creator VIDEOINFOHEADER:
rcSource: (0,0)-(720,352)
rcTarget: (0,0)-(720,352)
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 00000000
dwCopyProtectFlags: 00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 352
dwControlFlags: 00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 352
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 380160
biXPelsPerMeter: 0
biYPelsPerMeter: 0
00000003 Creator GetVih2 final output:
00000003 Creator VIDEOINFOHEADER:
rcSource: (0,0)-(720,352)
rcTarget: (0,0)-(720,352)
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 00000000
dwCopyProtectFlags: 00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 352
dwControlFlags: 00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 352
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 380160
biXPelsPerMeter: 0
biYPelsPerMeter: 0
00000004 Creator CVideoRenderer::CheckMediaType(MEDIASUBTYPE_YV12, width: 720, height: 352, bitcount: 12, aspectX: 853, aspectY: 352) -> +
00000004 Creator CVideoInputPin::CheckMediaType() -> 0
00000004 Creator CVideoInputPin::SetMediaType();
00000004 Creator CVideoRenderer::SetMediaType();
00000004 Creator GetVih2 original media type:
00000004 Creator AM_MEDIA_TYPE:
majortype: {73646976-0000-0010-8000-00AA00389B71}
subtype: {32315659-0000-0010-8000-00AA00389B71}
formattype: {f72a76a0-eb0a-11d0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 380160
cbFormat: 112
00000004 Creator VIDEOINFOHEADER:
rcSource: (0,0)-(720,352)
rcTarget: (0,0)-(720,352)
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 00000000
dwCopyProtectFlags: 00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 352
dwControlFlags: 00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 352
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 380160
biXPelsPerMeter: 0
biYPelsPerMeter: 0
00000004 Creator GetVih2 final output:
00000004 Creator VIDEOINFOHEADER:
rcSource: (0,0)-(720,352)
rcTarget: (0,0)-(720,352)
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 00000000
dwCopyProtectFlags: 00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 352
dwControlFlags: 00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 352
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 380160
biXPelsPerMeter: 0
biYPelsPerMeter: 0
00000004 Creator CVideoText::HandleNewMediaType();
00000004 Creator VIDEOINFOHEADER:
rcSource: (0,0)-(720,352)
rcTarget: (0,0)-(720,352)
AvgTimePerFrame: 417083
VIDEOINFOHEADER2:
dwInterlaceFlags: 00000000
dwCopyProtectFlags: 00000000
dwPictAspectRatioX: 853
dwPictAspectRatioY: 352
dwControlFlags: 00000000
BITMAPINFOHEADER:
biSize: 40
biWidth: 720
biHeight: 352
biPlanes: 3
biBitCount: 12
biCompression: YV12
biSizeImage: 380160
biXPelsPerMeter: 0
biYPelsPerMeter: 0
00000004 Creator CVideoText::IsDefaultTargetRect();
00000004 Creator CVideoRenderer::GetTargetRect();
00000004 Creator CVideoRenderer::GetTargetRect() -> 0, 0, 0, 0
00000004 Creator CVideoText::IsDefaultTargetRect() -> -
00000004 Creator CVideoText::HandleNewMediaType(size: 720 352; aspect: 853 352; sum: 853 352)
00000004 Creator CVideoRenderer::SetSourceRect(newRect: 0, 0, 720, 352);
00000004 Creator CVideoRenderer::SetSourceRect() -> +
00000004 Creator CVideoText::HandleNewMediaType() -> +
00000004 Creator CVideoRenderer::SetMediaType() -> +
00000004 Creator CCustomMemAllocator::SetMediaType();

[madshi]

I'm curious if you got any useful response about subtitles pin?
Haven't looked into that yet at all.

Instant crash with .14....
Argh. Does it occur with the debug build, only? Or also with the release build? Does it crash every time, or just sometimes? Maybe only with specific videos?

[iSunrise]

Instant crash with .14...
Same here. Tried KMPlayer and MPC-HC and release build and debug build with both players. Same crash. When playing with KMPlayer Vista x64 tells me that it wants to disable Aero Mode and switch to Windows Vista-Basic. Never had that before.

Log (uploaded.to):
http://ul.to/t9x8xb

Specs:
(1) Geforce GTX 260-216 [Nvidia ForceWare Quadro 197.54]
(2) Windows Vista x64
(3) Aero on
(4) 1920x1200@60Hz
- using KMPlayer

[noee]

yup, like iSunrise, both builds, happens immediately, every time. I tried numerous MKVs (all with SD material encoded with x264). Happens on both monitors, 1920x1080, one is 60hz, one is 24Hz.

[cyberbeing]

Not that it really matters, but your setting dialog for 0.14 still states 0.13.

I'll try testing it out in a bit.

[iSeries]

V0.14 crashes instantly for me as well.

(1) ATI 4550 CCC 10.4
(2) Windows 7 32bit
(3) Aero off
(4) 1920x1080 @ 23.976hz (secondary monitor)

[nlnl]

Mpc HC (Haali mkv spliter) + ATI 5400 (10.5) + Vista 32 + Aero on + 0.14 + monitor 1080p@23 (single)

Mpc Hc crashes not even starting playback.

[madshi]

Weird. I got not crash on my XP32 and Vista64 PCs. But then on my win7 x64 PC I could reproduce the crash (fortunately). Hope it's the same one you got.

[madshi]

madVR 0.15 released

http://madshi.net/madVR.zip

* fixed: crash during startup

[noee]

No crash here, good so far.....interesting your find.

[Trigunflame]

Just installed 0.15, and it's Freezing/Crashing MPC-HC about 5 seconds into playing a video.

Win7 x64

http://www.multiupload.com/KZ71OWTP8R

[madshi]

Just installed 0.15, and it's Freezing/Crashing MPC-HC about 5 seconds into playing a video.

Win7 x64
Are you sure it's 0.15? Maybe you still got 0.14? If it's really 0.15, then I need more information. Your full HTPC setup information (OS, GPU, Aero on/off, display resolution + refresh rate, decoder, splitter, etc). Does the crash/freeze occur with all kinds of different video files or just with some specific? Is it a crash or a freeze? Edit: And is the crash/freeze new with 0.15? Or did you also have that with madVR 0.13?

[nlnl]

Mpc HC (Haali mkv spliter) + ATI 5400 (10.5) + Vista 32 + Aero on + 0.15 + monitor 1080p@23 (single)

The starting crash is still here :(

[Trigunflame]

Are you sure it's 0.15? Maybe you still got 0.14? If it's really 0.15, then I need more information. Your full HTPC setup information (OS, GPU, Aero on/off, display resolution + refresh rate, decoder, splitter, etc). Does the crash/freeze occur with all kinds of different video files or just with some specific? Is it a crash or a freeze? Edit: And is the crash/freeze new with 0.15? Or did you also have that with madVR 0.13?

I'm quite sure it's 0.15, evidenced by both the included changelog & the filters control panel.

Win7 x64 ultimate
aero on
i7 920
8800gts 640mb g80 x2 sli
NV 257.15 drivers
1680x1050 59/60hz
mpc-hc latest svn
ffdshow-tryouts latest svn
mpc-hc mp4 splitter > ffdshow video (ffmpeg-mt @ 8 threads) > ffdshow audio > madvr > directsound

As for particular videos, not really; there is no perceivable pattern on my end. Although, randomly it seems, I can get one to continue playing.

Also, no, it did not occur with 0.13 for myself.

As for the specifics, it's both (in a sense). It will play for ~3-5 seconds; the video frame being shown will freeze, meanwhile the audio continues playing in the background. @ the time of this occurrence, a "(Not Responding)" message will be appended to the window title and any effort on my part to "unfreeze" the video will result in a "Close the Program" dialog window.

This is another log, from a different file.
http://www.multiupload.com/IOH3A3GO8A

[Razoola]

Just installed 0.15, and it's Freezing/Crashing MPC-HC about 5 seconds into playing a video.

Win7 x64

http://www.multiupload.com/KZ71OWTP8R

015 is not working here either on my secondary display, only works on primary display in windowed mode.

win7 x64, gtx295 primary, gt240 secondary. intel cpu, aero off, 257.15 driver.

some more information.... I managed to get fullscreen working on my secondary display. It only works however if I open the movie in windowed mode on my primary display first and then choose the full screen option in the player. The player locks up if I try to go full screen directly.

[rack04]

Is there a way to open in fullscreen in MPC-HC using madVR?

[Razoola]

Please disable Reclock vsync correction. It doesn't help madVR, instead it makes things more difficult.

Maybe it does but its the only way I get perfectly smooth playback, if I disable it I get random stutters.

[Razoola]

Is there a way to open in fullscreen in MPC-HC using madVR?

Yes there is in the SVN builds (use the fullscreen options in the playback menu) but it does not work with madvr 015 for me, only version 013.

[changturkey]

By using DirectVobSub. But you need to use the "right" version. There are 3 different flying around, as far as I've been told.

I've acquired 2.39, is that the version that works or?

EDIT: It works!

[iSunrise]

madVR 0.15 released

http://madshi.net/madVR.zip

* fixed: crash during startup
Thanks!

madVR 0.15 starts up correctly again, but unfortunately, when I go from windowed to fullscreen and back to windowed it will freeze (lock up) the media player completely without any crash, error or warning message. While the media player is in this frozen state, I have to manually kill the media player process itself, which isn´t quite enough, because the process still runs and then there´s that lovely Vista crash pop-up which finally hard kills the media player process, so the OS responds again. This is reproducible every time.

There is absolutely no problem whatsoever if I just keep the media player in windowed mode or I only switch to fullscreen mode once and let it play without switching back again.

Freeze log:
http://ul.to/jqc3ws

Specs:
(1) Geforce GTX 260-216 [Nvidia ForceWare Quadro 197.54]
(2) Windows Vista x64
(3) Aero on
(4) 1920x1200@60Hz
(5) KMPlayer or MPC-HC
(6) ffdshow video and audio decoder
(7) Haali splitter

[Thunderbolt8]

just jumped back and forth in some movies with 0.15 in windowed and fullscreen mode and didnt encounter any problems, no matter whether that XP texture option was checkmarked (with default settings) or not.

winxp pro sp3
radeon HD 4770, catalyst 10.3
whats aero?
1920x1080 movie @1680x1050@60Hz monitor
mpc-hc, ffdshow, madflac, ac3filter, directvobsub, both mpc-hc internal matroska splitter & haali splitter

[ajp_anton]

I'm getting the same old green bar at the top with non-mod16 videos.

[cyberbeing]

After fiddling with the settings for awhile, I ended up with the following (I don't usually use Spline64 for chroma, but figured it would be good for a stress test):

http://img6.imageshack.us/img6/917/madvr14stats.png

The above seems absolutely excellent from a performance and smoothness perspective. Of the flushes I added, some actually seem to improve render/present performance.

Setting any sort of flush for After render steps resulted in dropped frames every few seconds.

Setting any sort of flush for Before present resulted in lots of stuttering.

Setting Flush & Wait for After last step results in an absolutely massive performance hit (literally 100x slower, similar render times to previous versions of madVR).

Managed upload textures is a mixed bag. With certain settings it will actually improve render performance, but with others it hurts. With the above I found it best with it turned off. As I mentioned in a previous post, madVR 0.14/0.15 fixed the massive lag I was experiencing with 0.13 even with this setting disabled.

In all cases, Flush & Wait (loop) was faster then Flush & Wait (sleep).

I'll do some more testing with resizing and other resolutions later to see if things change. For no resizing though, you can't beat render + present times totaling less than the VSync Interval for 120Hz at 1080p. This jives with my likely naive theory that both (most importantly present) should total less then the VSync Interval for optimal smoothness. I mean how could you present in time for every vsync, if just by waiting for present and render to complete causes you to miss multiple vsyncs?

Windows XP SP3 x86
AMD X2 4800+ (939) @2.64Ghz
2GB DDR400 @ 433Mhz 2-3-3-6 (1:1 ratio with CPU)
NVIDIA GTX 470 (PCI-E 1.0 w/ x8 link)
1920x1080 @120Hz (CRT Monitor)
MPC-HC w/ Reclock (100ms Pre-Buffer)
CoreAVC (Software mode), FFDshow Audio, VSFilter, Haali Media Splitter

There is a problem I'm having though. madVR is at times hanging the MPC-HC process on exit. The MPC-HC window closes, but the processs stays active. I have to open up Task Manager and End Task to get it to close. This is a new problem introduced in 0.14/0.15.

[DigitalLF]

7 sec crash...

win7 x64 (fully updated)
CPU: E8400
RAM: 4gb DDR2 (dont remember the speed)
nvidia 9600GT
1920x1080 @ 60hz
nvidia driver 196.21
MPC-HC (v 2007)
ffdshow (v 3468)
madvr 0.15
haali (20/05/2010)

[madshi]

Thanks for the reports, everyone. I think I found the problem. I couldn't reproduce the crash/freeze during startup or after a few seconds of playback, but I could reproduce MPC-HC not closing down properly, and I think it's the same cause. So I hope it's fixed now.

@cyberbeing, you're reporting stutter when waiting for the "After last step" flush. But that's exactly the default seting madVR was using for all recent versions! So you could reproduce the stutter with all madVR versions? And it's gone with your special flush settings? Do the "loop" settings in your setup work better than the "sleep" settings or why are you using "loop" (it eats more CPU)? I think the "Flush & wait (loop)" setting for "After present" wouldn't work well for lower refresh rates. It might work well for you because due to the high refresh rate you're using the wait for the present is never long in your setup. But with e.g. 24Hz the present flush can hang for up to 40ms. If the CPU runs at 100% all that time, that can't be a good thing.

[madshi]

madVR 0.16 released

http://madshi.net/madVR.zip

* fixed: freeze during startup, or after a few seconds of playback
* fixed: media player doesn't close properly
One thing to note: When not using "Flush & wait" for the "After last step" setting, the OSD rendering time measurements are not correct. The measurements only work if madVR is told to wait for the flush "After last step". Which means that you should not base your decisions on the OSD stats, only, but you should check for highest possible quality settings that still achieve smooth playback with no dropped frames and no stuttering.

[namaiki]

Noo! Why do I have to go to work now!!

No crash with 0.16 so far, though I missed the last two versions.

Changing flushes to cyberbeing's gets me stutter, can't check anything else at the moment.

9600M GT, Windoiws 7 x64, Aero On.

[Trigunflame]

Congrats, 0.16 seems to have successfully resolved my issues.

[madshi]

Yippie-Yey!

[cyberbeing]

@cyberbeing, you're reporting stutter when waiting for the "After last step" flush. But that's exactly the default seting madVR was using for all recent versions! So you could reproduce the stutter with all madVR versions?
Well I know for certain that madVR 0.13 had this exact same stuttering problem with the GTX 470. For previous versions I was complaining about stuttering without frame drops with my 7800GTX 512 in this thread. Sadly, I won't know if these settings fixed my 7800GTX 512 as well until June 18th.

And it's gone with your special flush settings? Do the "loop" settings in your setup work better than the "sleep" settings or why are you using "loop" (it eats more CPU)? I think the "Flush & wait (loop)" setting for "After present" wouldn't work well for lower refresh rates. It might work well for you because due to the high refresh rate you're using the wait for the present is never long in your setup. But with e.g. 24Hz the present flush can hang for up to 40ms. If the CPU runs at 100% all that time, that can't be a good thing.

Rather it's gone by NOT using Flush settings for After render and Before present. Setting "Flush & Wait (loop)" for After backbuffer & After Present improved render/present performance.

Setting "Flush" for After last step seems to possibly help a bit as well without any performance hit, and it seems like a good idea to at least try to flush at that point.

"Loop" doesn't appear to be eating any additional CPU @120Hz, and it has slightly improved render/present times. I think "Wait" may have caused stuttering as well.

Maybe you could do something like, if Refresh rate >= 71Hz use "Loop"? If Refresh rate is <71Hz use "Wait"?

One thing to note: When not using "Flush & wait" for the "After last step" setting, the OSD rendering time measurements are not correct. The measurements only work if madVR is told to wait for the flush "After last step". Which means that you should not base your decisions on the OSD stats, only, but you should check for highest possible quality settings that still achieve smooth playback with no dropped frames and no stuttering.
Will this be fixed at some point, or is that just how it is? So what is it measuring? Times do increase/decrease with various settings, even without Wait for "After last step".

[madshi]

Rather it's gone by NOT using Flush settings for After render and Before present. Setting "Flush & Wait (loop)" for After backbuffer & After Present improved render/present performance.

Setting "Flush" for After last step seems to possibly help a bit as well without any performance hit, and it seems like a good idea to at least try to flush at that point.

"Loop" doesn't appear to be eating any additional CPU @120Hz, and it has slightly improved render/present times. I think "Wait" may have caused stuttering as well.
You seem to have based your decisions a lot on the OSD stats. I fear you will have to redo the tests, based on subjective impression, only.

Will this be fixed at some point, or is that just how it is?
The simple problem is that the only way to know the true rendering times is to flush the GPU and wait for it to signal "done". If madVR is told to not wait for the GPU to complete its task, then the rendering time measurements reflect when madVR has stopped waiting for the GPU, and not when the GPU was done rendering. Sadly, this is not fixable.

I'm sorry, I should have made it clear from the beginning that the OSD stats depend on "flush & wait". Maybe I should even remove the stats when the "wait" is removed from "After last step"?

So what is it measuring? Times do increase/decrease with various settings, even without Wait for "After last step".
It simply measures the time before starting the rendering and after having completed the rendering. But if you don't flush & wait, the GPU is still doing rendering work in the background. So the only reliable method to get rendering times is to ask the GPU to flush and then to wait until the GPU is done with rendering. Unfortunately this *can* eventually harm performance. So it will be difficult to find the best settings. You will only be able to judge on subjective impression.

BTW, with "wait (loop)" the rendering times will likely be measured lower than with "wait (sleep)". That's simply because "wait (sleep)" might wait a bit too long and so report rendering times which are slightly too high. But that's just a measurement problem.

[noee]

Does "After backbuffer" mean, after the back buffer is flipped? Is the flipping of the backbuffer asynchronous of the present? Or am I misunderstanding? I've searched around a bit and found some info on triple-buffering, but I'd like to understand the "flow" in a little more detail.

[Peuj]

Hi mashi,

With the 0.16, MPC takes 15~40s to load. This doesn't happen with the 0.13.

Also I surely miss something but I cannot generate a log.
I've tried to use the debug dll but I didn't find any log on my Desktop.

GPU: nvidia 8600M GT with driver 257.15
OS: Vista
Aero: on.
1920x1080 24Hz
Dual monitor PC/TV

Thanks

Edit:

I've changed noting, no reboot... and everything is working correctly now:
no waiting load time and the logs are generated??

*change monitor setup info (thanks Thunderbolt8)

[Thunderbolt8]

how many screens does multi monitor mean in your case?

[cyberbeing]

You seem to have based your decisions a lot on the OSD stats. I fear you will have to redo the tests, based on subjective impression, only.

I think you misunderstood. My current setting are based on completely subjective impressions. My first goal when testing was to find settings which did not give me any stuttering or dropped frames, and to use flushing whenever it didn't have a negative effect. I only used the OSD stats for minor tweaking after I already arrived at the conclusion that these were the best settings for my setup.

My experience with VMR9 in MPC-HC is that using flushing w/ wait is a good thing (eliminates tearing and makes panning more stable and smooth). If I didn't notice any negative effects from using flushing in madVR, I used whatever setting gave me faster render/present times. If there was no noticeable change, I used Flush & Wait (loop) instead of just Flush. Since "Wait (loop)" introduces no additional render/present delay, and doesn't seem to increase my CPU usage in any negative way, I prefer that over "Wait (sleep)" which gives me stuttering, which I just re-confirmed.

For reference, I was also getting occasional stuttering with all flushing settings disabled.

I've been doing some more testing (with resizing as well) and those setting do seem to give me perfect smoothness and nice stable panning (no flickering lines on animation & no vibrating edges, which is something I've never gotten with madVR before). If you used these settings (or at least made them available) in future versions, it seems Fullscreen Exclusive mode may end up being somewhat pointless for this setup.

http://img6.imageshack.us/img6/917/madvr14stats.png
Windows XP SP3 x86
AMD X2 4800+ (939) @2.64Ghz
2GB DDR400 @ 433Mhz 2-3-3-6 (1:1 ratio with CPU)
NVIDIA GTX 470 (PCI-E 1.0 w/ x8 link)
1920x1080 @120Hz (CRT Monitor)
MPC-HC w/ Reclock (100ms Pre-Buffer)
CoreAVC (Software mode), FFDshow Audio, VSFilter, Haali Media Splitter
Edit: Tried CoreAVC (CUDA mode), and it seems to work smoothly as well (Need to do more testing)
In CUDA mode GPU-Z Reports: 32% GPU Load | 35% Video Engine Load | 2% Memory Controller Load when resizing a 1920x1080 video to 1600x900 with Spline64 Luma/Chroma and 3DLUT enabled.

All I know is that those appear to be the perfect Flush settings for a Fermi GPU on WinXP with a CRT monitor when using Reclock.

Changing flushes to cyberbeing's gets me stutter, can't check anything else at the moment.

9600M GT, Windoiws 7 x64, Aero On.
As for Vista/Win7 with Aero, it seems you'll need something completely different. If I have time, maybe I'll load up Win7 x64 and see if I can reproduce Namaiki's stuttering with my settings.

[6233638]

0.16 is smooth again after 0.13 when using bicubic75 chroma on my 9400M.

I need to find a suitable video/way of doing more consistent testing, but setting 'after render steps' to 'flush & wait (loop)' definitely speeds things up.

[ajp_anton]

madshi:

In case you missed it:
I'm getting the same old green bar at the top with non-mod16 videos.

In case you ignored it without a sample:
Green bar at the top + chroma chifted: (500kB)
http://www.multiupload.com/AOR2BYG2O8
Seems to happen on all videos with height=360.

[leeperry]

XP SP3/8800GS/KMP/Reclock here...0.15 was quite horrid tbh! I tried all the "flush options", also "use managed upload textures"...it was still hanging when going FS>windowed, then I had to go away. Now I come back and try 0.16: it seems to work a hell lot better!

indeed "use managed upload textures" is required for me, if I disable it going FS>windowed hiccups a little bit(but no freezing).

I currently got the 4 "flushing" options disabled, everything looks smooth so far! I will do more testing and report back.
BTW, I run XP in "big fonts" and I can't read the last option at the bottom: http://thumbnails29.imagebam.com/8341/aedf0483402641.gif (http://www.imagebam.com/image/aedf0483402641)

:thanks: for the update!

PS: still a luck of the draw when seeking w/ Reclock, though.

PPS: humm yeah, super-smoothness is back w/ a vengeance! 25fps@100Hz/29.97fps@89.91Hz are really amazing and seeking is so fast now :)