madVR - high quality video renderer (GPU assisted)

[madshi]

I need to rotate some video files (digital camera / smartphone) but I couldn't do it when I use madVR. With EVR everything is working as expected in MPC-HC.
So the question is did I do something wrong or the rotation (at least in the Z axis) is something that the renderer must support / do?
I've no idea.

Subtitles work fine with MPC-HC (1.5.2.3456), even with madVR v0.71 set as the renderer. However, as soon as I add madVR to the external filters list (so that madVR can do video decoding), set it to "prefer", and restart MPC-HC, the subtitles disappear and the MPC-HC subtitle menu is disabled (greyed out).
This is a known bug in MPC-HC. You can make madVR decode without setting it to "prefer" by blocking all other decoders.

[joe42]

This is a known bug in MPC-HC. You can make madVR decode without setting it to "prefer" by blocking all other decoders.

Couldn't it be fixed in madVR? I've added a lot of external filters to MPC-HC and set them to prefer, and madVR is the only one that disables subtitles.

[madshi]

madVR does not disable subtitle. It's a bug in MPC-HC, not in madVR.

[cyberbeing]

I've double checked. The raw unprocessed YCbCr output of the h264 decoder is:

8 bit black, Y: 16, Cb: 128, Cr: 128
8 bit white: Y: 235, Cb: 128, Cr: 128
10 bit black, Y: 64, Cb: 514, Cr: 514
10 bit white: Y: 943, Cb: 514, Cr: 514

Now let's check what the BT.709 specification says:

Black level, 8bit: 16, 10bit: 64
Achromatic, 8bit: 128, 10bit: 512
Nominal peak, 8bit: 235, 10bit: 940

Seems to me the 8bit -> 10bit conversion you've done is broken.
Not good... Since x264 (swscale?) does the 8bit -> 10bit conversion, it means all builds of x264 are affected. Would you speculate that I don't have the issue with swscale 10-bit to 8-bit output because it clips levels (BTB/WTW) to TV-Range when converting to 8-bit YV12 while madVR doesn't, or because magicially swscale 10bit->8bit conversion is able to reverse the inaccuracy of swscale 8bit->10bit conversion...? If it's just an issue of madVR clipping levels, do you think it's worth having an option for clipping 10-bit input until this bug is fixed in x264 (which could take forever if it's a swscale problem)?

Hopefully Dark Shikari is aware of the problem and has someone attempting to fix it in x264 (swscale?). I wonder if it's related to the color hue bug with swscale. Though since you are able to get raw output from the decoder, it may be best if you provided the info on IRC #x264dev @ chat.freenode.net considering using swscale 8bit->10bit->8bit seems to hide the problem...

[madshi]

Not good... Since x264 (swscale?) does the 8bit -> 10bit conversion, it means all builds of x264 are affected. Would you speculate that I don't have the issue with swscale 10-bit to 8-bit output because it clips levels (BTB/WTW) to TV-Range when converting to 8-bit YV12 while madVR doesn't, or because magicially swscale 10bit->8bit conversion is able to reverse the inaccuracy of swscale 8bit->10bit conversion...?
My guess is that the conversion from 8 to 10 bit is done like this: "10bit = 8bit * 1023 / 255". The proper conversion would be a simple "10bit = 8bit * 4". If you use the same buggy conversion for both up- and downconversion, the error roughly equals out.

If it's just an issue of madVR clipping levels, do you think it's worth having an option for clipping 10-bit input until this bug is fixed in x264 (which could take forever if it's a swscale problem)?
I won't introduce buggy conversions to madVR.

Hopefully Dark Shikari is aware of the problem and has someone attempting to fix it in x264
I've just reported the problem to the x264 dev mailing list. Hopefully the problem can be fixed quickly.

[madshi]

No, this looks like the exact bug that caused crashes in 0.69 that you fixed in 0.70, but only occurs in the DX11 path is used.
This happens in the DX9 path, I couldn't test the DX11 path, as it's not stable for this operation.
Can't reproduce any problems here. My win7 PC is single monitor, though. My dual monitor setup is XP.

Here's the log (http://t.inmatrix.com/madVR_blank.rar) file you requested where creating a window (before even showing it) causes MadVR to lose exclusive mode for a second. Are you checking the window handle for visibility and position? If you're just checking position and hooking the window create function, you're going to get false positives.
Argh, I just noticed, the log file only contains the information I need if you enable the madVR debug OSD (Ctrl+J). Could you create another log with the madVR debug OSD on?

I'm enumerating all windows checking whether the madVR parent is fullscreen and on top. Invisible windows should be ignored, at least in theory.

My OSD (ControlBar/pop-up OSD). I try to clear it with a separate API call, I'm not using timeouts at all.
I've just tested that here on my PC with the ZP8 RC you sent me and it seems to work just fine here. Your "stop" message appears and then goes away after 3 seconds or so.

I just did a very quick initial test and 0.71 partially breaks the OSD. If I pause playback, no OSD is displayed. If I press play again, the 'pause' OSD appears briefly before switching to a 'play' OSD.
This doesn't occur here, either. How can I reproduce these OSD problems?

[nevcairiel]

Apparently the status messages of MPC-HC (like changing volume) cause alot of dropped frames now (or at least claims to). I can consistently drive the dropped-frames counter up by simply changing the volume with the mouse-wheel. Is that a display thing, or does it really drop frames? I can't say that it stuttered badly while doing it or anything...

[madshi]

Apparently the status messages of MPC-HC (like changing volume) cause alot of dropped frames now (or at least claims to). I can consistently drive the dropped-frames counter up by simply changing the volume with the mouse-wheel. Is that a display thing, or does it really drop frames? I can't say that it stuttered badly while doing it or anything...
In order to make the OSD more responsive, I'm now cutting the rendering queue down to 4/8 whenever anything OSD related is updated. This may eventually result in frame drops. If your GPU and CPU are fast enough, I would not expect that, though. Can you provide a log with such frame drops caused by the OSD?

[madshi]

madVR v0.72 released

http://madshi.net/madVR.zip

* empty file "force full range input" in madVR folder overwrites auto detection
* empty file "YCbCr" in madVR folder makes madVR output YCbCr data directly
* fixed: video playback in PotPlayer froze in various situations
* fixed: display mode change + "delay playback start..." -> video stayed paused

[nevcairiel]

In order to make the OSD more responsive, I'm now cutting the rendering queue down to 4/8 whenever anything OSD related is updated. This may eventually result in frame drops. If your GPU and CPU are fast enough, I would not expect that, though. Can you provide a log with such frame drops caused by the OSD?

Here is a log of this (started playback, entered exclusive mode, did some volume changing, quit)
http://files.1f0.de/madVR-osd-framedrops.zip

It does indeed only occur when the decoder isn't extremely fast. It does happen with LAV CUVID (hardware is limited to around 70-80fps), but it does not happen with a multi-threaded software decoder pulling off 300-400fps.

[leeperry]

:thanks: for the new build!

* fixed: video playback in PotPlayer froze in various situations
It's stil happening here, but far less worse than in 0.71 of course...how to reproduce:
-open a video in windowed mode
-pause it
-switch from windowed mode to FSE
=frozen.

I've also compared the colors in full range YV12 and RGB2, files available here: mVR.72 comparison.rar (http://www.mediafire.com/?pjolqjnss1w8by8)

-0.72/YV12 looks just like 0.67/RGB32, apart from the lines between the squares compared to both 0.67/RGB32 and HR/RGB32...different chroma placement?
-0.72/RGB32 is FUBAR...green gamma seems AWOL
-both 0.72/YV12 and 0.67/RGB32 look ever so slightly different from HR/RGB32, even checking the colors in Photoshop confirms it...but I guess this might be due to dithering? Next time I make screenshots comparisons, I will disable dithering in mVR :o

[Nevilne]

The PotPlayer bugs are really strange: starting from build 69, after I extract new build, I can play any video one time and then every following video will result in black screen/audio only with unresponsive interface.

After I put 69 back, videos play fine, but then when I put new build even the first video won't play. However, with each new build (70,71,72) the first video will play once again, and the following won't...

Still happens with 0.72
Lav splitter > coreavc,ffdshow audio>madvr,reclock
Internal filters disabled in potplayer.

[andybkma]

I'm confused. Originally you reported a problem only during playback *START*. Now you're saying video playback is generally not as smooth??

Yep, that's exactly what I'm saying. But I'm not saying that's madVR's fault. Am just saying that I absolutely have to have to have exclusive mode turned on (in Win7) in order to avoid drops while watching movies in fullscreen mode. While in XP I didn't even need exclusive mode to get great smooth video. Is just problems inherent in Win7 (for me at least) and I don't know how to make it better

And yes, I still get the juttering at playback start (in Win7) on two different laptops. No probs in XP. Again, it must be probs inherent in the Win7 OS

Note: I know I've already mentioned this in another post so this is not new info

[rahzel]

What does the madVR OSD (Ctrl+J) say about source resolution and target rectangle when playing your 720p video?
It says:
movie resolution 1280, 720
target rectangle 0, 1, 1360, 766

[kostik]

When I make "YCbCr" folder, I get strange colors. I have my video card and tv output YCbCr .How do I properly use it to output YCbCr directly?
Thanks!

[leeperry]

BTW, I use my Avisynth scripts in SuperSampling mode so I first upscale higher than my display native res in ffdshow, get it through the Avysynth filter of ffdshow and then let mVR downscale. I'm still experimenting in order to find the highest possible resolutions my CPU can afford for SD/720p/1080p, and I'm rolling on the fly between 1352/1440/1600 width(running a 720p display)...problem is: most of the time it works fine, but sometimes mVR crashes instantly after the switch or I get a colorful garbage picture for a split second. In both cases, I get an entry in the XPSP3 event viewer saying that "madVR!DllMain" is the culprit. Aren't on-the-fly input resolution switches supported? I'm still using mVR 0.67 in RGB32.

PS: it would appear that if I make more than a half-dozen realtime changes to my Avisynth script in ffdshow, it also crashes and I get the same "madVR!DllMain" event viewer error msg :o

[Hypernova]

madshi, So you don't plan to support H264 FOURCC? I'm not exactly complaining, just curious. Thanks

[maco07]

PotPlayer still freeze with .72 here.

[ryrynz]

Which madVR version did you use? v0.70 contains an improvement for MPEG2 which might already have fixed this (if you tested with an older madVR build).


I was using 0.71, I've since upgraded to 0.72 and it still occurs.

[rahzel]

I've been really trying hard to get madVR to work on my relatively weak machine, and I was just about to give up until I discovered something. I just realized madVR has built in decoders and without them, I couldn't get high bitrate 1080p videos to play smoothly whatever I did. I disabled the internal MPC HC decoders and checked the madVR decoders and my test video (~59m mark of Transformers 2 IMAX where it goes to 16:9) plays smoothly now.

Now to go play around with my main HTPC.

edit: playback is smooth on my HTPC as well, but reclock doesn't seem to detect the video stream using madVR's h264 decoder. hmm....
edit2: tried divx h264 and it works well, too. my cpu seems to be JUST fast enough to play this scene as it's at~80-97% usage!

the scaling algorithms seem to be sorted by sharpness, but does that directly translate to speed as well?

[Leader]

If you use to set the checkbox madVR D3D in MPC-HC, it is impossible to exit full screen mode "Exclusive"

[Volfield]

madVR needs PixelShader 3.0 hardware support. Seems the Intel 3150 can't do that.

This is hw spec. that i found:
Intel GMA 3150
Specifications
Manufacturer: Intel
Family: GMA
Name: GMA
model: 3150
Codename: Pineview
Shaders: 2
Core Clock: 200 MHz
Shader Clock: 200 MHz
Memory clock: 400 MHz
Memory Size: 256 MB
Memory Type: DDR2
Bus: 64 bit
Number of cores: 1
45 nm technology
DirectX 9.0c
Shader model: 3.0
TDP: 2W
Memory Clock (effective) 800 MHz
Memory Bandwidth 6.3 GB / s

So that's not a reason...

[Blight]

Madshi:
Here's an updated log file (http://t.inmatrix.com/madVRlogBlank2.rar). This time with MadVR 0.72 with MadVR's OSD visible (using ctrl+j).


I'm enumerating all windows checking whether the madVR parent is fullscreen and on top. Invisible windows should be ignored, at least in theory.

Are you calling WinAPI's "IsWindowVisible"? and are you checking the window's dimensions to see if they cover the MadVR window?
Cause what happens that exclusive mode is lost for a split second and then it re-activates. If the new window was problematic, wouldn't exclusive mode stay disabled?

[janos666]

* empty file "YCbCr" in madVR folder makes madVR output YCbCr data directly

Hmm. It sounded very interesting but it's not exactly what I thought. The HDMI port on the VGA still outputs RGB 4:4:4 Full, not YCC 4:2:2. I guess it's only for debugging purposes (right now?).

My old LCD let me manually set the input format between RGB and YCC but my current PDP doesn't offer such controls. (But the old one perfectly handled the RGB 4:4:4 input as well.)
Is it YCC 4:2:0, 4:2:2 or 4:4:4 in the RGB 4:4:4? (If you go for actual YCC output then it should be 4:2:2)

[andybkma]

Yep, that's exactly what I'm saying. But I'm not saying that's madVR's fault. Am just saying that I absolutely have to have to have exclusive mode turned on (in Win7) in order to avoid drops while watching movies in fullscreen mode. While in XP I didn't even need exclusive mode to get great smooth video. Is just problems inherent in Win7 (for me at least) and I don't know how to make it better

And yes, I still get the juttering at playback start (in Win7) on two different laptops. No probs in XP. Again, it must be probs inherent in the Win7 OS

Note: I know I've already mentioned this in another post so this is not new info

Have solved this problem by installing ReClock. I never had to use ReClock in XP cuz madVR was just so smooth and never even needed to use its exclusive mode. But that was not so in Win7 for me which ReClock has now solved. Yippee :)

(Just wish I would have thought of this earlier. Perhaps my Soundblaster ExpressCard X-Fi card drivers are not playing as nice nice with Win7 as it did with XP hence the need for ReClock. Either way, good to go now)

[ajp_anton]

To display the same movie on two screens with different resolutions (for example laptop + TV), should I ask here or the MPC-HC guys?

[madshi]

It's stil happening here, but far less worse than in 0.71 of course...how to reproduce:
-open a video in windowed mode
-pause it
-switch from windowed mode to FSE
=frozen.
Still happens with 0.72
PotPlayer still freeze with .72 here.
Ok, I'll check if I can reproduce it.

0.72/RGB32 is FUBAR...green gamma seems AWOL
I don't see that here. RGB32 looks just fine here, with both video and PC input levels, when using ffdshow. Tested with the same AVSForum test video you're using. Can you please try with straight ffdshow (without avisynth)?

both 0.72/YV12 and 0.67/RGB32 look ever so slightly different from HR/RGB32, even checking the colors in Photoshop confirms it...but I guess this might be due to dithering? Next time I make screenshots comparisons, I will disable dithering in mVR :o
I'd guess it's due to slightly different color conversion math. madVR is using a lot more decimals (more accurate conversion math) than most other software.

It says:
movie resolution 1280, 720
target rectangle 0, 1, 1360, 766
In that situation only the luma *up*scaling algorithm should have any effect.

When I make "YCbCr" folder, I get strange colors. I have my video card and tv output YCbCr .How do I properly use it to output YCbCr directly?
Thanks!
Hmm. It sounded very interesting but it's not exactly what I thought. The HDMI port on the VGA still outputs RGB 4:4:4 Full, not YCC 4:2:2. I guess it's only for debugging purposes (right now?).
I see that the changelog is misleading. The "YCbCr" option is just a hack for debugging purposes, nothing more. It is *NOT* supposed to put the GPU into any sort of YCbCr output. The only purpose of this feature is to check which raw YCbCr data a video decodes to. Please ignore this feature, except for low level debugging.

madshi, So you don't plan to support H264 FOURCC?
Yes.

I was using 0.71, I've since upgraded to 0.72 and it still occurs.
Can I have a log, please? Do you see frame drops/delayed/glitches in the madVR OSD (Ctrl+J)?

the scaling algorithms seem to be sorted by sharpness, but does that directly translate to speed as well?
The algorithms down the list tend to consume more GPU power than those up in the list.

If you use to set the checkbox madVR D3D in MPC-HC, it is impossible to exit full screen mode "Exclusive"
The MPC-HC "Fullscreen D3D" option is not officially supported by madVR. Use it at your own risk.

This is hw spec. that i found:
Intel GMA 3150
Shader model: 3.0
So that's not a reason...
wikipedia claims that your GPU implements shader model 3.0 by software. madVR needs it to be hardware.

To display the same movie on two screens with different resolutions (for example laptop + TV), should I ask here or the MPC-HC guys?
You'd probably need two madVR instances with one or two MPC-HC instances. You could realize that manually by starting MPC-HC twice, once for each screen. If you want to have this work "automatically", with only one decoding instead of double decoding, you'd need support by both the media player and madVR. I don't see that coming anytime soon.

[maco07]

PotPlayer still freeze with .72 here.

"restore default settings.bat", "uninstall.bat" and then "install.bat" solved my problem, now 0.72 is working ok with PotPlayer 29162.

[Plutotype]

Hi madshi, watched a 2hour movie today ( used 0.72 ) and I had zero dropped frames after the movie finished ( checked stat ). Nice to see there are no negative secondary effects after all those changes from the last 2 months..

[graeme]

I'd like to add madVR support to my application (NextPVR - see www.nextpvr.com). Unfortunately this renderer doesnt like something about my application, but its not immediately clear what.

My standard graph used for live tv and playback of recordings has a 'NextPVR TS Reader' filter connected to the 'MPEG2 Demultiplexer' filter, connected to a video decoder (and one or more audio decoder filters), then video decoder is connected to a video renderer (current Overlay/VMR7/VMR9/EVR). If

I build this graph in GraphEdit and use madVR as the video renderer, then graphedit crashes as soon as I connect the video decoder output to the video renderer input. Do you have any idea why this is happening? I've attached a stacktrace screenshot I captured by visual studio.

EDIT: that must be some type of record, I joined the forum in 2003 and just made my first post.

[hoborg]

@graeme:

sub? :D

[graeme]

yep - I would have created a 'sub' account, but I already had an account from years ago.

[kasper93]

In exclusive mode madVR drops 3 frames every time when seek bar hides.

[leeperry]

I don't see that here. RGB32 looks just fine here, with both video and PC input levels, when using ffdshow. Tested with the same AVSForum test video you're using. Can you please try with straight ffdshow (without avisynth)?

Oops, indeed you're right! They're fine, I've got no idea what went so terribly wrong :o

Here's a new comparison: mVR72_2nd_comparison.rar (http://www.mediafire.com/?9qwmjc9gacx9j7y)

-the three RGB32 files don't have the same CRC, but look identical. It's 1:1 RGB32 from ffdshow not requiring scaling, I don't see why all the files wouldn't be bit-identical tbh...besides the file size is slightly bigger in HR, next time I will use EVR as well.
-mVR72/YV12 still has thicker lines between the squares, meaning a different chroma placement? Like it's using the MPEG1 alignment even though I'm feeding h264?

Either way, I'm eagerly looking forward a new build that won't freeze in PotP :)

:thanks:

[ryrynz]

Can I have a log, please? Do you see frame drops/delayed/glitches in the madVR OSD (Ctrl+J)?


http://www.fileden.com/files/2006/10/26/319696/madVR%20-%20log.rar

Nothing out of the ordinary with regards to frame drops etc the sync just ends being out by a second or so and the more I seek the worse it gets.
I haven't had the video speed increase like I did the first time, could be fixed or one of those random occurrences.

[rahzel]

is it normal that madvr uses much more cpu power than other renderers (and no, i'm not comparing it with DXVA... with DXVA, CPU usage is ~5-10%). my desktop PC has a quadcore so CPU usage is fine (less than 40% most of the time); the GPU is a big bottleneck, limiting me to bilinear luma downscaling (otherwise 1080p video is unplayable).
Anyway, my HTPC is the problem. I have an AMD Athlon II 250 DC and using ffdshow (no DXVA)/mpc (no DXVA)/Divx H264 with EVR CP, my CPU usage is ~35-50%, but with madVR, it's ~70-90%. Video plays smooth without frame drops, but I'm just wondering why my CPU usage is so high.

Specs of my HTPC:
AMD Athlon II 250
2GB DDR2
ATI Radeon 5570 1GB
Win7 32-Bit
MPC HC x86
ReClock
LAV Splitter/decoder
madVR

edit: seems like 'fastplayer' has the same problem I am.
http://forum.doom9.org/showpost.php?p=1481860&postcount=5861

[cyberbeing]

@rahzel


Play a video using madVR which exhibits the issue
Load up Process Explorer (http://download.sysinternals.com/Files/ProcessExplorer.zip) (run as administrator)
__________
View menu (make sure show processes from all users and show fractional CPU are checked)
__________
View menu->System Information (take a screenshot of CPU tab)
Sort the main window by CPU usage (take a screenshot)
__________
Double click on MPC-HC in Process Explorer
Click on the Performance Graph tab (take a screenshot)
Click on the Threads tab and sort by CPU usage (take a screenshot).
__________
Post the 4 screenshots here.

[rahzel]

http://imageshack.us/photo/my-images/109/cpusorted.jpg/
http://imageshack.us/photo/my-images/594/cput.jpg
http://imageshack.us/photo/my-images/691/mpcw.jpg/
http://imageshack.us/photo/my-images/810/threads.jpg/

Something definitely doesn't seem right, because I see people with inferior hardware running madVR fine. GPU usage is only ~20%.

BTW, Divx H264 decoder is the only decoder that seems to play high bitrate 1080p without significant dropped frames. I've tried ffdshow and MPC.

[madshi]

I'd like to add madVR support to my application (NextPVR - see www.nextpvr.com). Unfortunately this renderer doesnt like something about my application, but its not immediately clear what.

My standard graph used for live tv and playback of recordings has a 'NextPVR TS Reader' filter connected to the 'MPEG2 Demultiplexer' filter, connected to a video decoder (and one or more audio decoder filters), then video decoder is connected to a video renderer (current Overlay/VMR7/VMR9/EVR). If

I build this graph in GraphEdit and use madVR as the video renderer, then graphedit crashes as soon as I connect the video decoder output to the video renderer input. Do you have any idea why this is happening? I've attached a stacktrace screenshot I captured by visual studio.
Unfortunately attachments to this forum sometimes take weeks to be approved. Better upload it somewhere else and link to it here.

Have you tried different decoders? In which module/dll does the crash occur?

In exclusive mode madVR drops 3 frames every time when seek bar hides.
I think it's probably when the seek bar *shows*, not hides?

-mVR72/YV12 still has thicker lines between the squares, meaning a different chroma placement? Like it's using the MPEG1 alignment even though I'm feeding h264?
madVR is currently always using the MPEG2/h264 chroma placement.

is it normal that madvr uses much more cpu power than other renderers (and no, i'm not comparing it with DXVA... with DXVA, CPU usage is ~5-10%). my desktop PC has a quadcore so CPU usage is fine (less than 40% most of the time); the GPU is a big bottleneck, limiting me to bilinear luma downscaling (otherwise 1080p video is unplayable).
Anyway, my HTPC is the problem. I have an AMD Athlon II 250 DC and using ffdshow (no DXVA)/mpc (no DXVA)/Divx H264 with EVR CP, my CPU usage is ~35-50%, but with madVR, it's ~70-90%. Video plays smooth without frame drops, but I'm just wondering why my CPU usage is so high.
That is definitely not normal. Can you upload a (zipped) log of 10 seconds worth of playback with madVR?

-------

Note to everybody: With MPC-HC build 3520 or newer you can now set madVR to "prefer" and subtitles and OSD will still work.

[adolfotregosa]

madshi, thank you for madvr, really makes a difference when configured correctly but a have a request, if possible.

I have seen people ask for this so I'll just re ask again. Can you add the option to only change the resolution/Hz when changing to full screen, only? Only thing i really think it would make a difference at least to me.

thank you

[rahzel]

That is definitely not normal. Can you upload a (zipped) log of 10 seconds worth of playback with madVR?

-------

Note to everybody: With MPC-HC build 3520 or newer you can now set madVR to "prefer" and subtitles and OSD will still work.
this is taken during the intro credits of the film if that matters. CPU usage is 20-35% higher during action scenes and when it goes to IMAX scenes (16:9).

http://www.megaupload.com/?d=EQ3T6QRA
in case the attachment has to be approved or anything.

appreciate the help.

[graeme]

Unfortunately attachments to this forum sometimes take weeks to be approved. Better upload it somewhere else and link to it here.Ah - ok, I'll keep that in mind for future posts.

Conveniently it didnt take weeks this time. You can now see the screenshot here: http://forum.doom9.org/showpost.php?p=1516930&postcount=9088

Have you tried different decoders? In which module/dll does the crash occur?Yes, I've tried it with different decoders (ffdshow, mainconcept, arcsoft etc). The module it's crashing in is madVR.ax.

[madshi]

@graeme, is there some easy way for me to reproduce the problem on my PC?

[madshi]

http://www.fileden.com/files/2006/10/26/319696/madVR%20-%20log.rar

Nothing out of the ordinary with regards to frame drops etc the sync just ends being out by a second or so and the more I seek the worse it gets.
I haven't had the video speed increase like I did the first time, could be fixed or one of those random occurrences.
Hmmmmm... In that log there are so many seeks. One seek after 2.5 seconds of playback, then one after 3.5, another one after 5, another one after 6 seconds. That's not a good thing for a log, it makes the log very complicated and hard to read.

Anyway, the whole problem does not occur with external decoders, correct? Can I have a small sample of the VOB file? Of course that would make sense only if the problem also occurs with the small sample. Which splitter are you using?

I have seen people ask for this so I'll just re ask again. Can you add the option to only change the resolution/Hz when changing to full screen, only?
It's on my list of things to eventually look at.

this is taken during the intro credits of the film if that matters. CPU usage is 20-35% higher during action scenes and when it goes to IMAX scenes (16:9).

http://www.megaupload.com/?d=EQ3T6QRA
in case the attachment has to be approved or anything.

appreciate the help.
Your log looks just fine to me. Do you have the same high CPU consumption in both windowed and exclusive mode? Did you change your madVR flush settings? Make sure you don't use "flush & wait (loop)", those flushes are CPU expensive.

[rahzel]

Your log looks just fine to me. Do you have the same high CPU consumption in both windowed and exclusive mode? Did you change your madVR flush settings? Make sure you don't use "flush & wait (loop)", those flushes are CPU expensive.
I dunno how to check CPU usage in exclusive mode. I'd imagine that it would be a little lower when I'm not running a CPU monitor. Regardless, using EVR CP
The flush settings are default, but I'll take a look and see what they're set to.

This doesn't make sense though.... I see people running older AMD Athlon X2 dual cores with madVR just fine, and the AMD Athlon II dual cores are much faster. Not to mention most people say that changing renderers should make little to no difference in CPU usage.

Hopefully the flush settings will help. What do these do exactly?

I'll play around with it in a bit and report back.

edit: nope, not set to loop. my flush settings are as follows:
back buffers used - 3
flush - after intermediate render steps
flush & wait (sleep) - after last render step
don't flush - after copy to backbuffer
don't flush - after D3D presentation

edit2: fwiw, CPU usage seems to be higher in windowed mode, because I get dropped frames in windowed mode, but none in exclusive mode. windowed mode probably has to scale the video down whereas exclusive doesn't, but isn't the scaling being done on the GPU? Again, my GPU load is only ~15-20%.

[madshi]

http://www.fileden.com/files/2006/10/26/319696/madVR%20-%20log.rar

Nothing out of the ordinary with regards to frame drops etc the sync just ends being out by a second or so and the more I seek the worse it gets.
I haven't had the video speed increase like I did the first time, could be fixed or one of those random occurrences.
P.S: The splitter seems to behave very weird. Most frames come to madVR without any timestamps, which make it hard for madVR to properly sync. Which exact splitter is that? Have you tried a different splitter?

[madshi]

I dunno how to check CPU usage in exclusive mode.
I'm confused. The log you uploaded is from exclusive mode. Why do you upload an exclusive mode log, if you don't know if the high CPU usage problem also occurs in exclusive mode?

Anyway, in order to check CPU usage in exclusive mode, start ProcessExplorer, switch to the CPU usage graphs, then start video playback in exclusive mode. Then after a couple of seconds exit the media player. You should be able to see the CPU consumption in the CPU graphs now.

This doesn't make sense though.... I see people running older AMD Athlon X2 dual cores with madVR just fine, and the AMD Athlon II dual cores are much faster. Not to mention most people say that changing renderers should make little to no difference in CPU usage.
madVR does consume a little bit more CPU than other renderers, I think, but it's really not such a big difference. I'm not sure why the difference is so big in your case. That will be really hard to find out, I fear.

[rahzel]

I just realized that windowed mode seems to use more CPU power... I didn't think it would make a difference since I thought the scaling was done on the GPU and wouldn't affect the CPU much. I'll check CPU load in exclusive mode.

[rahzel]

yeah, exclusive mode definitely uses much less CPU power, avg was about ~60% vs ~85% in windowed mode (during a high bitrate action sequence at full 1920x1080). 60% is only ~10% higher than EVR, so I'm happy. :)

Thanks for the help madshi.

[graeme]

@graeme, is there some easy way for me to reproduce the problem on my PC?The easiest way to reproduce it is probably to install NextPVR, then file up GraphEdit, insert the 'NPVR TS Reader', select a sample .ts file, insert the MPEG2 Demultiplexer, connect the TS Reader to the Demux. Insert a video decoder (like ffdshow), connect the 'video' pin from the demux to the video decoder, then insert the madVR renderer, and connect teh video decoder to madVR. It'll crash at this point.

Alternatively, if you dont want to install nextpvr, I've tried to dump the process at crash time, so if you've still got the PDB files from 'madVR v0.72', then hopefully you can load the dump file into visual studio to find the offending bit of logic. Dump file at http://www.gbpvr.com/madvr/graphedit.zip (65MB)

Or as another option, I've zipped the NPVRTSReader.ax and a sample .ts file at http://www.gbpvr.com/madvr/reader-and-samplefile.zip. I dont think there is any dependency on other NextPVR components, so hopefully you'll be able to register NPVRTSReader.ax, then follow the steps in my first paragraph above. (6MB)