madVR - high quality video renderer (GPU assisted)

[G_M_C]

Make sure you don't move/delete the madVR folder after installation. Does that fix the problem?

I've now unpacked the .zip in the same folder where MPC-HT [JanWillem32's tests 2964) resides. Runned the .BAT as administrator, but still no-go. I doesn't even show up in the 'external filters' list in MPC-HT.

[Andy o]

Does madVR appear on the "output" section, with all the other renderers, but it's greyed out, or does it not appear at all there? Try downloading MPC-HC from xvidvideo.ru?

[Qaq]

I've now unpacked the .zip in the same folder where MPC-HT [JanWillem32's tests 2964) resides. Runned the .BAT as administrator, but still no-go.
Try some simple path like c:\install\madvr\050\

[nevcairiel]

You need a more recent version of MPC-HC for recent versions of madVR to work 100%, 2964 is too old. Besides, those test builds will not do anything for you when you're using madVR, so just get the most recent build from here: http://xhmikosr.1f0.de/index.php?folder=bXBjLWhj .. or here: http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/

[G_M_C]

Does madVR appear on the "output" section, with all the other renderers, but it's greyed out, or does it not appear at all there? Try downloading MPC-HC from xvidvideo.ru?

Try some simple path like c:\install\madvr\050\

Hmmm, i runned the uninstaller. And than, just out of curiosity runned install.bat again not as administrator (just double clicked). Then i got the confirmation the .ax was installed correctly. So running the installfilter normally, not as administrator, works. MadVR now shows up.

Thx all !

[Abradoks]

What do you mean? madVR has nothing to do with VSFilter.
That (http://forum.doom9.org/showthread.php?p=1490819#post1490819)'s what I mean.

I'm not sure what you mean. I can't reproduce any problems on my XPSP3 PC. Can you make a screenshot?
http://i.imgur.com/LUGMI.png
http://i.imgur.com/wAzmY.png

[ryrynz]

Using the new exclusive path I'm dropping about 3 frames a second. Enabling Avisynth bumps it to around 13 a second.
The old path is working perfectly for me.

This looks to be a problem with the high CPU usage others are reporting It's ~30% on my C2Q 3.5Ghz and drops to ~10% using the old path watching a 720P H264 vid.

Log link below.

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

When I changed to the old path during playback the frames kept dropping until I restarted MPC. Does changing the path require a restart?
If so (requires restart) might be a useful addition to the option text.

[Thunderbolt8]

what would actually be the advantage to get more than 3 frames without blocking?

and just go with whatever gives best pq, as usual. no matter if dxva support or not.

[pdanpdan]

Anyone experience a certain issue (when using multiple monitors - default madVR settings) where a dialog box randomly gets 'stuck' on one monitor when playing a video in full screen exclusive on the other monitor?

I do :)
Mostly the "file save as" in browser (firefox)
I think it is related to "create graph using worker thread":
- mpc with worker OFF + madVR => no stuck window, cannot use buttons
- mpc with worker ON + madVR => stuck window, can use buttons

[cyberbeing]

Resizing is extremely slow with the new Fullscreen Exclusive mode. Present Queue is always 0-3, Backbuffer Queue is almost always 0-3, and Render Queue fluctuates between 1-8 & 5-8, and Upload Queue is always 6-8. Occasionally this results in a stutter without a dropped frame. Using Resizing and a 3DLUT seems to cause everything to fall apart.

Slow Resize Log (http://www.mediafire.com/?3iy3atgsbkb8u2e)

Slow Resize + 3DLUT Log (http://www.mediafire.com/?dl5dpp1mqx7az8l)

Bug: Occasionally the new Fullscreen Exclusive mode will hang MPC-HC when doing a right-click close from fullscreen.
By pure luck I actually caught it at the end of my Resize + 3DLUT log. From 00043310 onward appears to be where it hung.

Bug #2: MPC-HC Crash,
Faulting application mpc-hc.exe, version 1.5.2.3011, faulting module unknown, version 0.0.0.0, fault address 0x01940ef5.
Faulting application mpc-hc.exe, version 1.5.2.3011, faulting module unknown, version 0.0.0.0, fault address 0x01937e17.
Faulting application mpc-hc.exe, version 1.5.2.3011, faulting module unknown, version 0.0.0.0, fault address 0x019413a0.


Bug #3: I will sometimes get some Backbuffer Surface Failed errors if number of backbuffers set to less than 3 with the old Fullscreen Exclusive render path.

The old Fullscreen Exclusive is still broken unless I set backbuffers to 1 in madVR. Setting it to 2 or 3 backbuffers still results in the 'out-of-order' frame stuttering problem.

@cyberbeing, please double check whether the 3dlut stuttering is still there.
Still getting a huge GPU usage spike (normal + 50-90%) with various 'colorful' out-of-gamut video segments that usually last no more than a couple seconds and result in frame drops.

D3D9 is limited to max 3 backbuffers. However, Vista and Windows 7 introduced a slightly extended D3D9 version ("D3D9Ex") which supports up to 30 backbuffers. The new exclusive mode rendering path uses D3D9Ex and I can successfully create those 30 backbuffers. But I can only render 3 frames without being blocked until the next VSync.

Are you making sure to use Direct3DCreate9Ex, Direct3DDevice9Ex, PresentEx, FlipEx, and Back_Buffers_Max_EX instead of their non-Ex counterparts (most if not all of the new sync and preset Ex stuff is Windows 7 only, not supporting Vista) ? Only Direct3DCreate9 appears to be specified in your import table. Just random guesses from looking at DirectX docs. I suspect you may have to use Ex everything throughout the entire chain for it to work.

Or maybe >3 buffers conflicts with DWM backbuffer parameters (Aero)? That said, with an ATI 5750 on Win7 x64, I could never get madVR to use beyond 3 backbuffers even with madVR set to 8. ATI Driver limitation? I seem to remember 8 backbuffers working with NVIDIA in Win7, but last I checked was ~30 madVR revisions ago.

[deptel]

Just posting to show my gratitude for the new rendering path.

Can now use Full screen exclusive mode with ATI crossfire, with no issues.

Thanks madshi !

Oh, and as for the cant seek when paused, the frame on the screen and the animation of the seek bar does not change to where you seek to, but once you resume from pause, it does start playing from the chosen time.

[Blight]

I'm having problem with the new exclusive mode path,
What happens is:
1. Zoom Player is set to go fullscreen on monitor #2.
1. I have my player window monitor #1.
2. I play a video in a window.
3. I press the fullscreen button (or alt+enter).
4. The player moves to monitor #2 fullscreen.
5. Monitor #2 displays a static image of the video.
6. Exclusive mode is activated on monitor #1, playing the video on the wrong monitor.

Switching to the old rendering path fixes the issue.

[sneaker_ger]

Are all queues filled even in that very moment when you get non-perfect playback with the new rendering path?

No, they drop down.

Does the OSD note dropped frames when the get non-perfect playback?

Yes.

I've created a log anyways in case you change your mind on its usefulness:
http://rapidshare.com/files/457057325/madVR_-_log.7z

[Thunderbolt8]

played a BD remux for about 20 mins and the number of dropped and delayed frames didnt change during that time at all.

[Razoola]

What makes you say that?


This was a question you asked regarding my opinion of repeating and not dropped frames. I feel its repeated frames because the OSD does not report dropped frames and the playback seems to mirco pause rather than jump.

[ResCogitans]

I'm having problem with the new exclusive mode path,
What happens is:
1. Zoom Player is set to go fullscreen on monitor #2.
1. I have my player window monitor #1.
2. I play a video in a window.
3. I press the fullscreen button (or alt+enter).
4. The player moves to monitor #2 fullscreen.
5. Monitor #2 displays a static image of the video.
6. Exclusive mode is activated on monitor #1, playing the video on the wrong monitor.

Switching to the old rendering path fixes the issue.I have the exact same problem with MPC-HC.

[madshi]

That (http://forum.doom9.org/showthread.php?p=1490819#post1490819)'s what I mean.
Ah, almost forgot about that. Will check that out in a couple of minutes.

http://i.imgur.com/LUGMI.png
http://i.imgur.com/wAzmY.png
Weird!! Can't reproduce that here. Any tips on how to reproduce it?

When I changed to the old path during playback the frames kept dropping until I restarted MPC. Does changing the path require a restart?
You need to restart MPC or reload the video file.

what would actually be the advantage to get more than 3 frames without blocking?
That would allow the queues to fill up better, giving a bigger safety net against frame drops.

Resizing is extremely slow with the new Fullscreen Exclusive mode. Present Queue is always 0-3, Backbuffer Queue is almost always 0-3, and Render Queue fluctuates between 1-8 & 5-8, and Upload Queue is always 6-8. Occasionally this results in a stutter without a dropped frame. Using Resizing and a 3DLUT seems to cause everything to fall apart.
That sounds bad. Please try again with v0.51, though.

Occasionally the new Fullscreen Exclusive mode will hang MPC-HC when doing a right-click close from fullscreen.
By pure luck I actually caught it at the end of my Resize + 3DLUT log. From 00043310 onward appears to be where it hung.
Hmmmm... I've added some more logging output in v0.51 in the area where the hang occurred according to your log. Can you make another log for me with a similar hang with v0.51? Thanks!

MPC-HC Crash,
Faulting application mpc-hc.exe, version 1.5.2.3011, faulting module unknown, version 0.0.0.0, fault address 0x01940ef5.
Faulting application mpc-hc.exe, version 1.5.2.3011, faulting module unknown, version 0.0.0.0, fault address 0x01937e17.
Faulting application mpc-hc.exe, version 1.5.2.3011, faulting module unknown, version 0.0.0.0, fault address 0x019413a0.
I don't get these crashes here. Any way to reproduce them reliably?

I will sometimes get some Backbuffer Surface Failed errors if number of backbuffers set to less than 3 with the old Fullscreen Exclusive render path.
Does rendering still succeed despite this error message? I've now simply silently disabled this error message in v0.51.

The old Fullscreen Exclusive is still broken unless I set backbuffers to 1 in madVR. Setting it to 2 or 3 backbuffers still results in the 'out-of-order' frame stuttering problem.
IMHO this is a bug in the display drivers. But anyway, the new rendering path doesn't have this problem, right? So let's just tweak the new rendering path until it's better than the old in every way. I hope that will be possible somehow. There's nothing I can do with the old rendering path to solve the "out-of-order" frame stuttering.

Still getting a huge GPU usage spike (normal + 50-90%) with various 'colorful' out-of-gamut video segments that usually last no more than a couple seconds and result in frame drops.
:( With v0.51, too, I guess?

Are you making sure to use Direct3DCreate9Ex, Direct3DDevice9Ex, PresentEx, FlipEx, and Back_Buffers_Max_EX instead of their non-Ex counterparts
Yes, of course.

Or maybe >3 buffers conflicts with DWM backbuffer parameters (Aero)? That said, with an ATI 5750 on Win7 x64, I could never get madVR to use beyond 3 backbuffers even with madVR set to 8. ATI Driver limitation? I seem to remember 8 backbuffers working with NVIDIA in Win7, but last I checked was ~30 madVR revisions ago.
The limitation to 3 is caused by madVR using D3D instead of D3DEx for the old exclusive mode rendering path. The new rendering path uses D3DEx now and should not suffer from this limitation. However, as I said, more than 3 frames blocked, so I limited it to 3 frames myself.

Can now use Full screen exclusive mode with ATI crossfire, with no issues.
:)

I'm having problem with the new exclusive mode path,
What happens is:
1. Zoom Player is set to go fullscreen on monitor #2.
1. I have my player window monitor #1.
2. I play a video in a window.
3. I press the fullscreen button (or alt+enter).
4. The player moves to monitor #2 fullscreen.
5. Monitor #2 displays a static image of the video.
6. Exclusive mode is activated on monitor #1, playing the video on the wrong monitor.

Switching to the old rendering path fixes the issue.
This is a known limitation of the current madVR version. Actually I'm very surprised that it works for you with the old rendering path!! It should not. With the current madVR version you need to move ZP to the target monitor before you load the video file.

I'll fix this very soon now. Maybe already in the next build.

[Plutotype]

Oh, and as for the cant seek when paused, the frame on the screen and the animation of the seek bar does not change to where you seek to, but once you resume from pause, it does start playing from the chosen time.

Confirmed here, needs to be fixed.

[madshi]

madVR v0.51 released

http://madshi.net/madVR.zip

* fixed: seeking while paused with new exclusive path didn't update image
* added D3D9 tweak to allow pre-rendering of more than 3 frames
* added a number of fixes and tweaks to new exclusive mode rendering path
* readded "presentation glitches" to OSD, but only for new exclusive path
* added option to choose the no of pre-rendered frames for new exclusive path
Good news! I've found a way to pre-render more than 3 frames without blocking!! So now you have the option to choose how many frames madVR should pre-render. You can choose anything between 2 and 16 frames. Choosing a higher value increases the size of the safety net against frame drops. This comes at a price, though: First of all memory usage goes up. Furthermore, there's no way to abort the presentation of pre-rendered frames. So if you tell madVR to pre-render 16 frames, whenever you do something (like pausing playback, or switching from exclusive -> windowed mode) you'll get a delay of 16 frames. My tip: Use the lowest number of pre-rendered frames that result in reliable smooth playback. The default is 4 pre-rendered frames. For people using very high refresh rates (e.g. 120Hz) it might make sense to increase the number of pre-rendered frames accordingly.

Please double check all problems you had with v0.50. The seeking issue should be solved. I *hope* that the high CPU consumption is solved, too, although I haven't explicitly tested it yet.

P.S: Windows XP is limited to max 3 pre-rendered frames. More frames are only possible in Vista + Windows 7.

[cvrkuth]

Problem with Cyberlink HAM CPU load is solved in v0.51
Thanks!

[neb1236]

Hi, beginning with madvr 0.50 I have a noticed a small glitch (so small it's a shame to report it, sorry) when switching between fullscreen and windows (exclusive mode disabled):
If watching a video with a AR different than the desktop (4:3 movie on a 16:10 monitor) when switching to fullscreen the 4:3 movie get stretch to 16:10 and then get to it's normal 4:3 AR
And when switching back to windowed, we get the 16:10 frame (4:3 with side black border) squeezed in the 4:3 windows, and then getting back to its normal 4:3
The glitch is very brief on my system (2600K+HD6950), nearly invisible (also because I watch mostly 16:9, witch is less noticeable on my 16:10 screen)
This doesn't seems to be cause by the "upload frames in render thread" option being turned off by default in 0.50 (tested it on off, in v0.49)
Thanks for reading, and continue your good work, we like it!

[6233638]

Haha, in the time it takes for me to download & test 0.50 and come back to report my results, 0.51 is released. Will try that out in a few minutes, but I will just add that:
0.50's new rendering path completely fixes my dropped/delayed frame problem. Decode/upload/render are all at 7-8/8, backbuffer stays at 4-4/4, and present queue is mostly at 3-4/4 but sometimes drops down to 2-3/4, though it does not interfere with playback.

I can confirm that CPU usage is considerably higher on my system with the new rendering path as well, at 2-3x the old rendering path. For me this is not a problem as it is still around 50% load maximum but I can see why it would be on many systems.

Something that I only really noticed now since playback was fine for me long before getting my new TV is that it may be a good idea to change the OSD font to be green rather than red. When I enable the cinema mode on my TV it switches from 4:4:4 to 4:2:2 chroma and the OSD can be tough to read. I would prefer 4:4:4 at all times (after all the chroma upsampling is one of the big advantages MadVR brings) but motion handling is better and contrast is considerably higher in cinema mode.

[fastplayer]

Ah, almost forgot about that. Will check that out in a couple of minutes.
Just in case you're wondering where that part is hidden inside of MPC-HC:
FGManager.cpp (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/apps/mplayerc/FGManager.cpp?revision=2973&view=markup), line 2205-2210.

[6233638]

0.51 results:
Decoder Queue: 7-8/8
Upload Queue: 7-8/8
Render Queue: 7-8/8
Backbuffer Queue: 6-7/16
Present Queue: 6-7/16
Zero dropped/delayed frames or presentation glitches, rendering times appear to be broken, showing ? +0.04ms etc. (not that it's important)

CPU usage is lower again. Perhaps not quite as low as before (would have to do more extensive testing to be sure) but much lower than 0.50.


I'm curious about what the limiting factor for Backbuffer Queue and Present Queue is. VRAM usage is still under 300MB so it can't be that.

Will set it to 8 and leave it there for now. The slight delay is less important to me than it is to have as many frames pre-buffered as possible to ensure there will be no drops.


Fantastic work as ever, this new rendering path has been worth the wait!

[Plutotype]

Thanks for 0.51,

Seeking in paused state in fulscreen exclusive mode works, but the seeking in paused state is not showing the selected frame ( static image ) in the timeline. With pause - seek - play, everything is ok.

[Plutotype]

Hi, beginning with madvr 0.50 I have a noticed a small glitch (so small it's a shame to report it, sorry) when switching between fullscreen and windows (exclusive mode disabled):
If watching a video with a AR different than the desktop (4:3 movie on a 16:10 monitor) when switching to fullscreen the 4:3 movie get stretch to 16:10 and then get to it's normal 4:3 AR
And when switching back to windowed, we get the 16:10 frame (4:3 with side black border) squeezed in the 4:3 windows, and then getting back to its normal 4:3
The glitch is very brief on my system (2600K+HD6950), nearly invisible (also because I watch mostly 16:9, witch is less noticeable on my 16:10 screen)
This doesn't seems to be cause by the "upload frames in render thread" option being turned off by default in 0.50 (tested it on off, in v0.49)
Thanks for reading, and continue your good work, we like it!

Does lowering pre-render frames number does not help?
Madshi mentioned in the post above that higher number will cause this.

[madshi]

Problem with Cyberlink HAM CPU load is solved in v0.51
I think there never was a problem with Cyberlink HAM. The problem was that madVR v0.50 itself consumed *much* more CPU than it should... :)

Hi, beginning with madvr 0.50 I have a noticed a small glitch (so small it's a shame to report it, sorry) when switching between fullscreen and windows (exclusive mode disabled)
Yeah, I'm aware of that. It bothers me, too, although only a tiny little bit. Things like this I'm sorting under "minor cosmetical issues" and they are low on my priority list for now. Gotta do the more important things first!

Haha, in the time it takes for me to download & test 0.50 and come back to report my results, 0.51 is released.
:D

Something that I only really noticed now since playback was fine for me long before getting my new TV is that it may be a good idea to change the OSD font to be green rather than red. When I enable the cinema mode on my TV it switches from 4:4:4 to 4:2:2 chroma and the OSD can be tough to read.
Green? Euwww... Why would green be better than red?

Just in case you're wondering where that part is hidden inside of MPC-HC:
FGManager.cpp (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/apps/mplayerc/FGManager.cpp?revision=2973&view=markup), line 2205-2210.
Thanks!

rendering times appear to be broken, showing ? +0.04ms etc. (not that it's important)
It's not broken. The problem is that the new exclusive mode rendering path doesn't flush the GPU, anymore. Which means that I can't really properly measure rendering times. The "? +" is meant to indicate that there's an unknown amount of time which needs to be added to the measured time. Read it like "something plus 0.04ms". Maybe I should simply hide the rendering times completely in this situation instead of showing them as "? +"?

CPU usage is lower again. Perhaps not quite as low as before (would have to do more extensive testing to be sure) but much lower than 0.50.
Sounds good to me. Would be nice if you could test if it's higher or lower than the old rendering path.

I'm curious about what the limiting factor for Backbuffer Queue and Present Queue is. VRAM usage is still under 300MB so it can't be that.
The limiting factor is the size of the other queues (decoder, render, upload). They're still limited to 8, so the pre-rendered frames can't get higher than 8, if you have a 1:1 match between movie framerate and display refresh rate. The reason why I'm offering a higher number of pre-rendered frames than 8 is that the new exclusive mode rendering path renders at the display refresh rate and not at the movie frame rate. That means if you have a 25fps movie and your display is set to 50Hz then madVR renders 50fps and not 25fps. Well, actually madVR renders 25fps, but it presents every frame twice. For situations like this the pre-rendered frames can reach 16 although the other queues are still limited to 8.

In a future version I plan to make the size of the other queues adjustable, too.

Fantastic work as ever, this new rendering path has been worth the wait!
:)

Seeking in paused state in fulscreen exclusive mode works, but the seeking in paused state is not showing the selected frame ( static image ) in the timeline. With pause - seek - play, everything is ok.
I'm not sure if I understand correctly. In v0.50 when you seeked in paused state, you didn't see any change. But when you pressed play afterwards, the seeking worked. This should be fixed with v0.51. At least it is no my PC. Is it not for you?

[sneaker_ger]

0.51 works like a charm on the 9200M GS:
No dropped frames at all on 1080p60 for the first time ever. I set queue to 16, but it never goes over 6-7.

On my 5850 I just let it run the 1080p60 sample - no frame drops at all even at 200/300 clocks. I only have to make sure that GPU-Z is not running in the background. Same observation as on the Nvidia system: queue set to 16, but it never goes over 6-7.

Also get the "?"s in the stats, like "? + 0.5 ms" etc.

Question:
Do any of the changes in 0.50 and 0.51 have effects on window mode or should it be 100% unaffected?

[madshi]

0.51 works like a charm on the 9200M GS:
No dropped frames at all on 1080p60 for the first time ever. I set queue to 16, but it never goes over 6-7.

On my 5850 I just let it run the 1080p60 sample - no frame drops at all even at 200/300 clocks. I only have to make sure that GPU-Z is not running in the background. Same observation as on the Nvidia system: queue set to 16, but it never goes over 6-7.

Also get the "?"s in the stats, like "? + 0.5 ms" etc.
That sounds great! :)

You'll find answers to your questions in my previous post.

Do any of the changes in 0.50 and 0.51 have effects on window mode or should it be 100% unaffected?
Windowed mode should be 100% unaffected, unless I accidently broke something. The changes should only apply to exclusive mode.

That said, in Windows 7 it should be possible to port the new exclusive mode rendering path to windowed mode, if Aero is enabled. This might actually be worth a try. It might noticeably improve windowed mode video playback with Aero enabled. But first let's make sure that new path works as well as possible in exclusive mode.

[Razoola]

So far issues I had with 050 seem fixed (render queues not filling and D3D error so far). I did have some weirdness when I first tried however it may be nothing but I'll explain what I did in case.

- extracted 051 to a new dir (not over 050)
- used the uninstall bat in 050 dir
- used install bat in 051 installed dir
- copied settings.bin from 050 to 051 dir.

When I first tried a test video the queues were not filling as expected. I tried a few times with the same result. I then tried your suggestion and raised the pre rendered frames to 8 and tried again... This time the queues filled as expected. I then lowered the buffer to 6 and still they filled fine... I tried the default 4 again and this time the queues filled correctly. They have continued to do so after a few tries.

It made me wonder if there is a problem with the default value not being set correctly until you manually set it?

I also noticed that if you disable the new exclusive mode and apply the buffer ammount is not greyed out unless you exit the setting and go back in. Likewise going into the setting and enabling the new exclusive mode and applying the buffer ammount is not selectable unless you exit madvr settings and go back in. Only a cosmetic thing I know but I though it may tie in with the wierdness I had when first trying 051.

For now take it that my D3D error problem is fixed. I will report if it happens again in the future.

[Plutotype]

I'm not sure if I understand correctly. In v0.50 when you seeked in paused state, you didn't see any change. But when you pressed play afterwards, the seeking worked. This should be fixed with v0.51. At least it is no my PC. Is it not for you?

If I open a video a let it play for a while and then pause it and try to seek in paused state throughout the timeline, the images on the display does no reflect correct frame of the movie. When play is pressed from any point ( selected in paused state ), seekbar finds the frame corectly and movie continues from the seeked frame on.

[6233638]

Green? Euwww... Why would green be better than red?Green has a much higher resolution than blue or red in 4:2:2. It's why they switched to using greenscreen instead of bluescreen for chromakeying years ago.

It doesn't have to be a bright neon 255 green, something like 160-192 green is fine against black. The current red is bordering on illegible when my TV is in the 4:2:2 cinema mode instead of 4:4:4 PC mode.

It's not broken. The problem is that the new exclusive mode rendering path doesn't flush the GPU, anymore. Which means that I can't really properly measure rendering times. The "? +" is meant to indicate that there's an unknown amount of time which needs to be added to the measured time. Read it like "something plus 0.04ms". Maybe I should simply hide the rendering times completely in this situation instead of showing them as "? +"?Fair enough. I remember this happened a while back as well with the different flush states. I think hiding it would probably be best, as there doesn't seem to be any useful information displayed now.

Sounds good to me. Would be nice if you could test if it's higher or lower than the old rendering path.I'll try and get something set up to get accurate results. (I was really just eyeballing it in the task manager)

The limiting factor is the size of the other queues (decoder, render, upload). They're still limited to 8, so the pre-rendered frames can't get higher than 8, if you have a 1:1 match between movie framerate and display refresh rate. The reason why I'm offering a higher number of pre-rendered frames than 8 is that the new exclusive mode rendering path renders at the display refresh rate and not at the movie frame rate. That means if you have a 25fps movie and your display is set to 50Hz then madVR renders 50fps and not 25fps. Well, actually madVR renders 25fps, but it presents every frame twice. For situations like this the pre-rendered frames can reach 16 although the other queues are still limited to 8.Ah, of course. Nice idea with the higher refresh rates too. If only HDTVs accepted more than the standard 24/50/60. Even though I have a 3DTV now you still can't send it 48/120Hz. (at least it's not a standard option)

In a future version I plan to make the size of the other queues adjustable, too.Excellent. It's working fine as it is now, but it can't hurt to make full use of your system's memory to guarantee smooth playback. (I suppose it comes "free" when you add in the option to lower the queues as well for a quicker response)

[sneaker_ger]

I'm not sure if I understand correctly. In v0.50 when you seeked in paused state, you didn't see any change. But when you pressed play afterwards, the seeking worked. This should be fixed with v0.51. At least it is no my PC. Is it not for you?

I don't see any problem at all here with seeking anymore. I pause, seek and the frame is shown. What more can there be to it? :confused:

You'll find answers to your questions in my previous post.

Indeed, they've been answered.

[Gleb Egorych]

Interesting. How many frame drops are there with CUDA in v0.50 compared to v0.49? How does the decoder queue behave? Does it ever go below 4?
No, always 5 and above, generally 7-8/8. When frame drop occur I have 0 in present and/or backbuffer queues.

BTW with 0.51 I have a lot of dropped frames with CoreAVC soft mode with 60fps videos using new renderer path. With 0.50 playback was perfect.

[madshi]

When I first tried a test video the queues were not filling as expected. I tried a few times with the same result. I then tried your suggestion and raised the pre rendered frames to 8 and tried again... This time the queues filled as expected. I then lowered the buffer to 6 and still they filled fine... I tried the default 4 again and this time the queues filled correctly. They have continued to do so after a few tries.

It made me wonder if there is a problem with the default value not being set correctly until you manually set it?
Sounds weird. If you think it worthwhile, maybe you could try to reproduce the problem? You could do it like this: (1) Downgrade to v0.50. (2) Change any of the settings and "apply" to make sure that the settings.bin is created by v0.50. (3) Change the settings to what you had before upgrading to v0.51. (4) Re-Upgrade to v0.51. Does the problem occur again?

I also noticed that if you disable the new exclusive mode and apply the buffer ammount is not greyed out unless you exit the setting and go back in. Likewise going into the setting and enabling the new exclusive mode and applying the buffer ammount is not selectable unless you exit madvr settings and go back in. Only a cosmetic thing I know but I though it may tie in with the wierdness I had when first trying 051.
Ooops, thanks. Will fix that.

For now take it that my D3D error problem is fixed. I will report if it happens again in the future.
How about frame drops etc? Can you comment on whether the new rendering path is now better/identical/worse compared to v0.49? Thanks!

If I open a video a let it play for a while and then pause it and try to seek in paused state throughout the timeline, the images on the display does no reflect correct frame of the movie. When play is pressed from any point ( selected in paused state ), seekbar finds the frame corectly and movie continues from the seeked frame on.
Please double check if you really have v0.51. Sometimes the browser doesn't really download a new version but gives you an older zip from the browser cache. I guess that you're still running v0.50? Just a guess, though.

Green has a much higher resolution than blue or red in 4:2:2.
Why is that? Chroma is stored as Cb and Cr. 4:2:2 simply throws away half of the Cb and Cr values. I don't see why that should affect green less than red?

Even though I have a 3DTV now you still can't send it 48/120Hz. (at least it's not a standard option)
Most HDMI chips don't really support 1080p120 yet. Not enough bandwidth. You can do 1080p24 3D or you can do 1080i60 3D, but not 1080p60 3D. Except side-by-side, of course, cause that doesn't consume more bandwidth than 2D.

Excellent. It's working fine as it is now, but it can't hurt to make full use of your system's memory to guarantee smooth playback. (I suppose it comes "free" when you add in the option to lower the queues as well for a quicker response)
Reducing the size of the other queues wouldn't do any good other than saving memory. So I'll probably not allow to make them too small. Maybe I'll allow 4, 8, 12 and 16. Or something like that.

I don't see any problem at all here with seeking anymore. I pause, seek and the frame is shown. What more can there be to it? :confused:
It works just fine for me, too.

BTW with 0.51 I have a lot of dropped frames with CoreAVC soft mode with 60fps videos using new renderer path. With 0.50 playback was perfect.
:( That's the first negative report about v0.51. How do your queues behave like with v0.51 when you get drops with CoreAVC soft mode with 60fps? Have you tried increasing the number of pre-rendered frames?

[dansrfe]

I get multiple dropped frames starting with v0.50. Old rendering path works best for me.

Spline @ 4 taps on all
MPC-HC - latest
ffdshow - latest
Windows 7 x64
ATI Mobility Radeon HD 4570

[madshi]

I get multiple dropped frames starting with v0.50. Old rendering path works best for me.

Spline @ 4 taps on all
MPC-HC - latest
ffdshow - latest
Windows 7 x64
ATI Mobility Radeon HD 4570
Have you tested v0.51, too? Which movie resolution and framerate are we talking about and which display refresh rate? Have you tried increasing the number of pre-rendered frames? What do the queues say when you get dropped frames?

[sneaker_ger]

Most HDMI chips don't really support 1080p120 yet. Not enough bandwidth. You can do 1080p24 3D or you can do 1080i60 3D, but not 1080p60 3D. Except side-by-side, of course, cause that doesn't consume more bandwidth than 2D.

What makes you think he wants to send 1080p120 3D?
But side-by-side could be a workaround, let a renderer or decoder pack 1080p120 to side-by-side 1080p60 and don't use the 3D glasses.

[nevcairiel]

What makes you think he wants to send 1080p120 3D?
But side-by-side could be a workaround, let a renderer or decoder pack 1080p120 to side-by-side 1080p60 and don't use the 3D glasses.

He talked about 3D TVs, and 120Hz would be needed for full 60p 3D playback.
Doesn't really matter if you send 60p for each eye, or 120p in 2D, the point was that HDMI chips are generally too slow for 1080p120, no matter what you put in it.

[sneaker_ger]

He talked about 3D TVs, and 120Hz would be needed for full 60p 3D playback.

Yes, but he didn't say he wants to use the 120Hz for 3D.

Doesn't really matter if you send 60p for each eye, or 120p in 2D, the point was that HDMI chips are generally too slow for 1080p120, no matter what you put in it.

Yes, my mistake. My proposed workaround was to view 48 Hz or 120 Hz 2D video by doing side-by-side packing and fooling the TV into thinking it's being fed 3D material. Guess you'd have use 720p to do 120Hz that way.

[Razoola]

Sounds weird. If you think it worthwhile, maybe you could try to reproduce the problem? You could do it like this: (1) Downgrade to v0.50. (2) Change any of the settings and "apply" to make sure that the settings.bin is created by v0.50. (3) Change the settings to what you had before upgrading to v0.51. (4) Re-Upgrade to v0.51. Does the problem occur again?

How about frame drops etc? Can you comment on whether the new rendering path is now better/identical/worse compared to v0.49? Thanks!

I tried to reproduce the situation with the method you suggested but it did not happen again.

Yes the new 051 exclusive mode is as smooth as 049, the frame repeat issues I had are gone. As far as proformance goes I never had any issues with 049 so I can't really report anything on that front.

One thing I have noticed with 051 is coming in and out of full screen does not feel as smooth as 049.

[Qaq]

Thanks for new version.
Win7 x86, ATI 5450 (512Mb, DDR3). Tried 0.51 with 720p/24 video.
For me results look almost the same as with 0.50. CPU usage little bit less now, but still 4-5 times more than with 0.49. Funny, RAM usage now looks big too. In FS mode it's still bit stuttering and in windowed mode playback is smooth. OSD keeps the same values if I switch between FS and W modes. Decoder queue is about 7-8/8, no drops. Went back to 0.49 to watch the movie. BTW, I'd like to diagnose more, but didn't find any manual (how to make logs, etc).

[6233638]

Why is that? Chroma is stored as Cb and Cr. 4:2:2 simply throws away half of the Cb and Cr values. I don't see why that should affect green less than red?Green is the Y channel, isn't it? Or is that just a photography thing where "luminance" is always the green histogram, and sensors are RGGB.

Green is perhaps not completely untouched but the difference is clear. 192 red, 160 green, 255 blue.

4:4:4 PC mode:
http://i.imgur.com/863aI.jpg
4:2:2 Cinema mode:
http://i.imgur.com/CAafm.jpg

(not sure why the font looks weird in the photos it's fine on the screen)

Most HDMI chips don't really support 1080p120 yet. Not enough bandwidth. You can do 1080p24 3D or you can do 1080i60 3D, but not 1080p60 3D. Except side-by-side, of course, cause that doesn't consume more bandwidth than 2D.Yes, and it sucks. With PCs it is 720p60 or 1080p24. 720p looks awful and 24fps is too slow for games. They should have upgraded the spec.

[nevcairiel]

Yes, and it sucks. With PCs it is 720p60 or 1080p24. 720p looks awful and 24fps is too slow for games. They should have upgraded the spec.
The spec is fine, its the hardware implementation thats just too slow and cannot handle the full bandwidth.

Just in case you're wondering where that part is hidden inside of MPC-HC:
FGManager.cpp (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/apps/mplayerc/FGManager.cpp?revision=2973&view=markup), line 2205-2210.

@madshi
I took the liberty of fixing this for you, also marking madVR compatible with the sub renderer in the Output configuration GUI (in r3025)

[6233638]

The spec is fine, its the hardware implementation thats just too slow and cannot handle the full bandwidth.The HDMI 1.4 spec doesn't make 1080p60 in 3D a standard option. There should have been a HDMI 1.5 spec with 3D's introduction to make it a requirement.

[ajp_anton]

When paused, and you move the mouse up and down very fast between showing the seekbar and not showing it, occasionally it will get stuck at either showing it or not. If it doesn't show, it will still be there (you can seek by clicking where the seekbar should be). This gets reset when you seek or play (update the movie image).

[Plutotype]

Please double check if you really have v0.51. Sometimes the browser doesn't really download a new version but gives you an older zip from the browser cache. I guess that you're still running v0.50? Just a guess, though.


Im definately on 0.51.
Regarding seeking in paused mode - maybe Nevcairel can help - it happens only with VC-1 videos. H.264/MPEG2 are ok. Additionally, when paused and skipping in the timeline the frames are corrupted:
http://img816.imageshack.us/f/paused1.png/
http://img405.imageshack.us/f/paused2.png/
http://img713.imageshack.us/f/paused3.png/

The second issue is, mentioned by anton too - in fullscreen exclusive mode the seekbar does not show always when video is paused and you move over it with the mouse.

[yesgrey]

Why is that? Chroma is stored as Cb and Cr. 4:2:2 simply throws away half of the Cb and Cr values. I don't see why that should affect green less than red?
For BT.709:
R = 1.0*Y + 1.5748*Cr
G = 1.0*Y - 0.1873*Cb - 0.4681*Cr
B = 1.0*Y + 1.8556Cb

If you analyse the above functions carefully, you will see that Cb and Cr have a small influence on Green, but a big one on R and B. So, It's natural that green has more resolution, because the Y resolution is kept intact for every pixel.

[ajp_anton]

Is the decoder supposed to pass the color matrix to the renderer? Tested madVR, EVR and Haali, plus exporting RGB from ffdshow.
ffdshow apparently used the correct matrix, but Haali was the only renderer that correctly used the 601 matrix on a HD test video. (edit: nevermind, see later post)

[Andy o]

Green is the Y channel, isn't it? Or is that just a photography thing where "luminance" is always the green histogram, and sensors are RGGB.
I'm pretty sure this depends on the camera, I've had Canons which offer both luminance and RGB histograms, and luminance is not the same as green channel.

4:4:4 PC mode:
http://i.imgur.com/863aI.jpg
4:2:2 Cinema mode:
http://i.imgur.com/CAafm.jpg

(not sure why the font looks weird in the photos it's fine on the screen)Which screen is that? I think my Pioneer Kuro does the same with PC and video modes.

Yes, and it sucks. With PCs it is 720p60 or 1080p24. 720p looks awful and 24fps is too slow for games. They should have upgraded the spec.
I think madshi meant 1080/120p or 1080/60p 3D. Regular 1080/60p is not a problem, I think all 1080p HDTVs can do it.