madVR - high quality video renderer (GPU assisted)

[yesgrey]

In that time, you told me that you have your output at 16-245 to be safe. Are you still thinking the same way?
Ye, but only because my projector gamma curve is very bad near the top. I'll continue to set it like that to avoid the bad portion of my gamma curve, and not because there is significant data above 235...

About cr3dlut, there should be news within this week...

[cyberlolo]

Ye, but only because my projector gamma curve is very bad near the top. I'll continue to set it like that to avoid the bad portion of my gamma curve, and not because there is significant data above 235...

About cr3dlut, there should be news within this week...

Ok, so your advice now is to set output at 16-235 (in case we don't have your gamma curve problem) instead of 16-254?

Thanks about your c3dlut news. We'll be waiting.

[yesgrey]

Ok, so your advice now is to set output at 16-235 (in case we don't have your gamma curve problem) instead of 16-254?
For Blu-ray and DVD yes, it might be preferable when using a display without big flaws in the gamma curve. Another option would be giving a slight margin, like 16-237, just to be safe.;)
But let's follow the discussion in the thread I've pointed you to.

[SacredCultivator]

@madshi: Woops I meant similar to cyberbeing >< about the animorphic source not being displayed right for XviD.

I've sent you a PM of a sample.

[iSunrise]

Quick feedback re: madVR 0.12

1) High CPU load on pause on one core when switching to full-screen after pausing (and back) (i7 920). For this to happen (I can replicate this every time) I either start playing the file in windowed-mode and pausing, then going into fullscreen, or by playing the file in fullscreen, pausing and then going to windowed-mode. This will not happen, if you just stay either at window-mode or fullscreen and pause/unpause the movie.

2) DVD: Macrovision Fail is still there, like with Haali. I´m on Vista x64 and this will show up everytime the MS DVD Navigator (system default) is invoked. All system renderers, like e.x. EVR work fine. madVR works perfectly, however, if you just select the VOBs by hand (Open file... instead of Open DVD...).

3) Very good news, however, is that I did not have any crashes happen when skipping while playing a movie, like with 0.11. I also didn´t have a crash happening when I just wanted to close the player itself after playing a file, this happened very rarely, but I find it important enough to mention it.

@leeperry (KMP user) and madshi
What I find a bit annoying is that when using madVR with KMP, I can´t get any OSD information from KMP to display. That probably has something to do with an interference from madVR´s own OSD, which works perfectly when hitting CTRL+J. If I´m using EVR or Haali, KMP´s OSD works as it should (and Haali also has his own OSD which works in combo with KMP´s). So there must be a fundamental difference about how madVR draws it´s OSD, when you compare it to Haali´s method. Is it possible to change this?

[namaiki]

i can replicate this every time by playing the file in fullscreen, pausing and then going to windowed-mode

oh brilliant! You caught it!

[pie1394]

Quote:
Originally Posted by Grmpf
I still got the tearing problem with 23.976/24.000hz (50.000/59.940hz are fine).

I'll turn Aero off and check whether I can reproduce the tearing here.



Actually I also have the same result under Windows 7. It only works fine when the refresh rate is changed to 60 Hz. With EVR Sync renderer, it works fine at 24 Hz under Win7.

After some tests, it shows ver 0.12 has improved a lot about the seeking problem on ver 0.10 ~ 0.11. Has verified it under WinXP x64 and Win7. It just takes a little bit longer time to make the seeking responsed. With ver0.9, it is almost no delay on most video seeking just like other video renderers.


Do you consider adding the following features now?
1. NV12 + DXVA support
2. OSD pin

The reasons come from my recent experience under Win7. Have tried the Win7 platform for several months, and I have found nVidia's PureVideo MPEG2 / H.264 DXVA acceleration in MS DTV Video decoder, MPC-HC H.264 DXVA decoder + MPC-HC EVR Sync mode perform quite well on various HD contents.

It is the only platform that I can have the same or better experience of Pure Video MPEG2 decoder quality under WinXP. nVidia GTX260+ Pixel Adaptive Deinterlacer + frame rate doubler / post-processings are very good in handling interlaced DVD / HDTV contents.

[Steveo08]

@madshi

ok here is the second log file and this time i zipped it :-)



http://rapidshare.com/files/383448980/log2.zip.html

[namaiki]

madshi: could you please make a test build of madvr without the power of 2 textures check? doesn't matter if it crashes, but I'd simply love to try run MadVR on my Intel GPU.

[leeperry]

@leeperry (KMP user) and madshi
What I find a bit annoying is that when using madVR with KMP, I can´t get any OSD information from KMP to display.
I think it's due to the subs pin...KMP uses it for its own subs engine(far more refined and user configurable that anything else) and for its OSD/media infos.

[iSunrise]

I think it's due to the subs pin...KMP uses it for its own subs engine(far more refined and user configurable that anything else) and for its OSD/media infos.
Ah, now that explains it! Thanks leeperry.

[Steveo08]

@madshi



sounds great! :)

[namaiki]

Won't help. Already tried on my old ATI laptop which also doesn't support power of 2 textures. I need to change code to make this work.

I see. :thanks: for the reply. :D

[JarrettH]

I read the ReadMe for 3dlut a bit...so this should be used? It's a benefit for lower cpu usage and picture quality correct? Do I need a large amount of GPU memory? Does it erase and recreate this offline data for every video watched? :thanks:

[Razoola]

I have had problems getting madVR working with the latest nvidia graphics drivers and I can confirm v012 still has the same problem on my system as previous madvr version.

win7 ultimate x64
197.45 nvidia drivers
gtx295 and gt240 in system (making three gpus in system)

Problem I see is player freeze trying to play video.

To get 012 working I have to go back to nvidia drivers 191.07 which was the same situation as v011 of madVR.

Just to add Im using x86 build of MPC-HC

I have just seen you have supplied a debug build, here is a log of your 2nd build on my pc to see if its the same issue as Steveo08 (I have different gpu's). http://unibios.free.fr/log.rar

[cyberbeing]

Well I've noticed a problem new to madVR 0.12.

At random, after ~5-10 minutes, madVR suddenly begins dropping a couple frames every few seconds. Yet if I reopen the video or seek, I can usually get through the entire video without any dropped frames. Nothing unusual is happening with the render and present times, and the decode/backbuffer/render queues are remaining full when it drops frames.

On that note, the CTRL+J statistics must be leaving out some important statistic which could cause frames to drop independently of those which are already shown.

In any case, it appears there is something wrong with the 0.12 VSync code, which is occasionally causing it to lose VSync after a period of time and never fully recover. I never had that problem with 0.11.
My refresh rate is 96.0005 Hz and I use MPC-HC + Reclock on WinXP x86 with a 7800GTX 512.

That's bad news, because such kind of problems are hard to find. Are you using Aero?

Is it possible that your GPU is running on max all the time? v0.12 seems to be slightly more GPU hungry compared to v0.11. Could that explain the problem? (Not the missing information in the OSD, though.) Or is there plenty of power left in your GPU?
No Aero on Windows XP. If it matters madVR (0.11 & 0.12) usually reports my display refresh fluctuating between 96.00050 - 96.00060 Hz.

I wouldn't say plenty of spare GPU, but there is enough.

madVR 0.12
GPU Render + Present times = 32ms
Frame Interval (24fps) = 41.71ms
GPU-Z: 35% GPU Load

madVR 0.11
GPU-Z: 45% GPU Load

Each frame is ready to display 10ms before a frame is needed. Oddly enough, GPU-Z is reporting 10% less GPU usage in 0.12.

I'll stress that the problem is somewhat random. Sometimes I can get through a video without any dropped frames. Other times, after 5-10 minutes it starts dropping 1-3 frames every 15 seconds or so. That 5-10 minutes number is important because there are no dropped frames until 5-10 minutes have passed, if the issue even occurs.

The v0.12 dropping logic works slightly differently to v0.11. The concept of "delayed frames" doesn't exist in v0.12.

Could this have something to do with it? So instead of delaying frames to get back in sync, it instead just drops frames in a failed attempt to get back in sync???

Would you like me to try the capture the problem in a debug log or does it not log any information which would be helpful?

[flanger216]

Just clarifying, but were you one of the people who was experiencing issues before?

Yeah, madVR would crash on load. Now it works perfectly, even @ 24hz.

[Mark_A_W]

No Aero on Windows XP. If it matters madVR (0.11 & 0.12) usually reports my display refresh fluctuating between 96.00050 - 96.00060 Hz.



cyberbeing, can you try 95.904hz?

Your refresh rate is actually wrong.

(If you use Reclock 96.000 is close enough, but without it you will get dropped/repeated frames).

[cyberbeing]

cyberbeing, can you try 95.904hz?

Your refresh rate is actually wrong.

(If you use Reclock 96.000 is close enough, but without it you will get dropped/repeated frames).
When using Reclock it isn't really 'wrong', just sub-optimal (i.e. why change the frame rate if you don't have to). Since I always use Reclock, 96.000 Hz shouldn't be an issue since it just sets the fps to a multiple of your refresh rate (96.000/4 = 24.000). Unless the problem is that madVR doesn't display 24.000 fps when Reclock tells it to (which madshi would need to fix), there shouldn't be any problem.

Feature Request: Have the CTRL+J stats show achieved FPS.

The real reason why I use 96.000 Hz is for simplicities sake, since with a bit of fiddling I was able to get the NVIDIA control panel to set it as a custom resolution. I've had no such luck getting the NVIDIA control panel to set a custom resolution with exactly 95.904 Hz refresh, so I would be forced to use Powerstrip.

In any case I'll try 95.904 Hz with Powerstrip (fluctuates around 95.90415 Hz) and see if the problem still happens.

On that note, madshi, have you added any VSync code in madVR 0.12 for non-fps-multiple refresh rates yet? I remember you saying a long time ago it was on your to-do list.

[Mark_A_W]

Sorry, I was a bit unclear.

96.000hz + Reclock = all good (sub optimal perhaps...perhaps super optimal = you are back to the film rate).

96.000hz no Reclock = potential issue with repeated frames.


Not sure you'll have much luck with Powerstrip and an Nvidia card (or a 5 series ATi...grrr).

[leeperry]

On that note, madshi, have you added any VSync code in madVR 0.12 for non-fps-multiple refresh rates yet? I remember you saying a long time ago it was on your to-do list.
I have to admit that "non-fps-multiple refresh rates" look amazingly smooth in the latest build...I often find myself checking the actual refresh rate in Reclock(that doesn't do any "adaptation" due to the rates mismatch) :p

[Mark_A_W]

I have to admit that "non-fps-multiple refresh rates" look amazingly smooth in the latest build...I often find myself checking the actual refresh rate in Reclock :p


With or without Reclock Mr Scratch?


On my system, Reclock causes chaos unless the refresh rate is a multiple of the source fps.

[cyberbeing]

Bad news, the problem still happens with Reclock + 95.90415 Hz refresh rate. The dropped frames are more infrequent though (1-3 ever couple minutes again beginning after ~10 minutes). I never had issues with dropped frames in madVR 0.11.

madshi, how were you determining that 0.12 was slower? If something is slower, it's not being displayed by the CTRL+J statistics on my machine. Maybe the "slowness" is caused by madVR constantly waiting on something, which would explain the 10% less GPU utilization in 0.12? If the GPU isn't given enough work, GPU utilization would obviously be lower.

To help troubleshot the issue, could you compile a madVR 0.11 build with more detailed stats like 0.12? What about a madVR 0.12 debug build which outputs to log some extremely detailed execution statistics for every portion of the code which other parts of the code would be forced to wait on until finished?

[ajp_anton]

I remember you saying MadVR + DXVA is not (and will not be) possible. Is this still true?

[Razoola]

Well I've noticed a problem new to madVR 0.12.

At random, after ~5-10 minutes, madVR suddenly begins dropping a couple frames every few seconds. Yet if I reopen the video or seek, I can usually get through the entire video without any dropped frames. Nothing unusual is happening with the render and present times, and the decode/backbuffer/render queues are remaining full when it drops frames.

On that note, the CTRL+J statistics must be leaving out some important statistic which could cause frames to drop independently of those which are already shown.

In any case, it appears there is something wrong with the 0.12 VSync code, which is occasionally causing it to lose VSync after a period of time and never fully recover. I never had that problem with 0.11. My refresh rate is 96.0005 Hz and I use MPC-HC + Reclock on WinXP x86 with a 7800GTX 512.

I used to have a problem like this (long ago). The cause turned out to be the OS starting its file indexing service (or other type service) as it though the PC was not in use. Try watching something again but every few minutes give the mouse a wiggle and see if the issue stops. If it does you can then look into what your OS is starting to do.

[JarrettH]

Is there something I need to change in the output of ffdshow when I use 3dlut? My experience so far is that it makes my video stutter or lag. When I leave it off it's fine.

[namaiki]

Is there something I need to change in the output of ffdshow when I use 3dlut? My experience so far is that it makes my video stutter or lag. When I leave it off it's fine.

What's your video card? Maybe it's not fast enough to process 3dlut.

[Mark_A_W]

Is there something I need to change in the output of ffdshow when I use 3dlut? My experience so far is that it makes my video stutter or lag. When I leave it off it's fine.



Same here.

I assume it's because my 2600XT is not up to the task.

[JarrettH]

A 7600GT 256mb, 196.21 drivers

Perhaps :p

[namaiki]

ooh I forgot. you can check GPU usage/load with the latest GPU-z. check it.

Also, make sure that you're not running out of video ram.
ie. I can't run madvr and coreavc with cuda acceleraton at the same time, or vram is at 230MB and there is immense lag. but if I make the media player window smaller or disable cuda, acceleration vram goes down to ~170 and playback is smooth.

[Mark_A_W]

At this point in time is there any real advantage to running a stock 3D lut?

Once we can customise them, there is a real point, and I will buy a new card. But now?

[cyberbeing]

Render time usually falls between 20-25ms when resizing 1280x720 to 1600x900 with Spline36 Luma / Mitchell-Netravali Chroma and Present time somewhere between 8.5-9.5ms.

I never paid that close attention to delayed, only dropped. If I have time later today I'll check it out and report back. I'll try to get you some logs of 0.12 dropping frames as well.

Are you absolutely positive that the Render Queue staying permanently on 7/8 isn't related to my dropped frame woes? I'm asking again is because one thing I do remember is that madVR 0.11 would get delayed frames whenever the Render Queue dropped from 8/8 to 7/8 for a split second (which usually only happened when resizing 1080p and never 720p). In other words, if madVR 0.11 was staying permanently on 7/8 Render Queue, it would have caused guaranteed delayed frames, yet 0.12 only knows how to drop. It sounds extremely suspect to me.

I'm a bit curious why in 0.12 you are preferring to drop frames instead of keeping the delay+drop logic in 0.11. Does the drop only method bring some sort of benefit? It seems like it would just make things worse, causing a noticeable stutter whenever a frame drops, compared to a delayed frame where you would be hard pressed to notice a stutter at higher refresh rates since the frame is still displayed (at the next vsync?).

The part about the OSD causing stuttering on the 9400 makes me a little worried (stuttering=dropped frames?), since the dropped frames in 0.12 are at times very minor and hard to detect without the OSD being shown.

[tetsuo55]

Casimir (from the MPC HC crew) has sent me some code which might make DXVA possible with madVR. I'm not really sure yet how well it will work and if there will be any compromises in quality. E.g. it's quite possible that when using DXVA decoding, I also have to use the chroma upsampling and color space conversion of the GPU, instead of being able to do these things myself. Not really sure yet, though...The implementation he sent to you works exactly the same like a software decoder as far as the renderer is concerned.

[madshi]

Are you absolutely positive that the Render Queue staying permanently on 7/8 isn't related to my dropped frame woes? I'm asking again is because one thing I do remember is that madVR 0.11 would get delayed frames whenever the Render Queue dropped from 8/8 to 7/8 for a split second (which usually only happened when resizing 1080p and never 720p). In other words, if madVR 0.11 was staying permanently on 7/8 Render Queue, it would have caused guaranteed delayed frames
The queue being 8 frames long is a arbitrary decision on my side. I could make it 7 or 9 frames long and there wouldn't be any noticeable different. So the queue being 7/8 instead of 8/8 really doesn't matter much. Furthermore: The OSD only shows the state of the queues at one exact moment every second, while the queues are likely to fluctuate quite a bit during that second of runtime. The queue *can't* be always full, because in that moment when a new frame is shown, the old frame gets deleted and due to this deletion the queue must automatically go to 7/8. Then the new frame coming from the decoder is rendered and the queue goes back up to 8/8. Depending on when the OSD grabs the current queue state, it can be 7/8 or 8/8. I don't think that has anything important to say.

I'm a bit curious why in 0.12 you are preferring to drop frames instead of keeping the delay+drop logic in 0.11. Does the drop only method bring some sort of benefit? It seems like it would just make things worse, causing a noticeable stutter whenever a frame drops, compared to a delayed frame where you would be hard pressed to notice a stutter at higher refresh rates since the frame is still displayed (at the next vsync?).
Well, to be honest, I concentrated on situations where display refresh rate and movie frame rate are identical, because I think that's the future of playback setups. But I have to admit, with high refresh rates such as yours, delayed frames would be much better than dropped frames. So maybe I should restore the old logic.

The part about the OSD causing stuttering on the 9400 makes me a little worried (stuttering=dropped frames?), since the dropped frames in 0.12 are at times very minor and hard to detect without the OSD being shown.
The OSD only causes stuttering because my 9400 is basically too slow for madVR, anyway. Your GPU seems to be much faster, so the OSD should be no problem for you. It's not the OSD in itself which is causing the stuttering for me, it's just the small added burden on the GPU.

The implementation he sent to you works exactly the same like a software decoder as far as the renderer is concerned.
Unfortunately it's not exactly the same:

(1) With a software decoder the decoded frame ends up in system RAM and I can reformat it in any way I like before uploading the data to the GPU. For your information: madVR splits the luma and chroma channels and stores them into separate textures. The textures claim to contain RGB data (although in reality they contain YCbCr data). So the GPU is not doing any damage to them when my pixel shader reads them.

(2) With DXVA the decoded frame ends up as an NV12 surface in GPU RAM. Now the problem is that pixel shaders can only read textures and not surfaces. And textures don't support NV12. I could directly copy the NV12 surface to a YCbCr texture on the GPU. But if a pixel shader reads a pixel from a YCbCr texture, the pixel is converted to 4:4:4 RGB on the fly behind the back of the pixel shader. The pixel shader never gets to see the original YCbCr data. I could directly copy the NV12 surface to an RGB texture, but doing so will make the GPU do chroma upsampling and YCbCr -> RGB conversion. I don't see any way to access the raw NV12 data from within my pixel shaders, without transfering the data to system RAM first. And as you probably know, transfering data from GPU RAM to system RAM is painfully slow... :(

[leeperry]

in a future version madVR may also be able to do the primaries conversion via shader code.
oh, great news! using the PS gamut mapping script is dead easy, it will improve the ease of use for newbies/lower the GPU load and loading time...and tbh, I'm not quite convinced that a 16bit 3DLUT is not *way* overkill for an 8bit 16-235 SMPTE-C source :o

I can compare real world test patterns as much as I want, the PS script does a perfect job doing the 3D lut thingie *to my eyes*. I guess it'll be a different story on xvYCC material.

[iSunrise]

I´ve just played back some blu-rays with 29.976 fps, several videos with 29.970fps, 25.000 fps and one with 60fps on a 60Hz display refresh (Eizo CG243W) and I must say I really like 0.12.

Apart from the 60fps one, every other movie/video played back without any dropped frames at all. Skipping is also quite fast (this may be dependent/limited by the res of the video, the GPU performance and your disk access time, e.x.) and happens without dropped frames. I don´t have reclock installed, btw. and I´m using the nvidia quadro 197.54 drivers for my GTX260.

The 60fps video behaves completely different though, but I think that´s (in part) due the refresh rate being higher than my actual display refresh. While I´ve configured 60Hz in the nvidia control panel, my actual refresh is more like 59.9 (that´s what my monitor shows), so I´m guessing it´s closer to 59.94Hz and not exactly 60Hz. While with 0.11 I can see "major" stutters and dropped frames along the whole video (~5:30 minutes) and about 10-15 dropped frames every 5-10 secs, 0.12 plays the video _very_ smooth, but still with a dropped frame almost every 10-20 secs, which I wouldn´t have noticed, but because the OSD is there and shows me "another frame just got dropped", I indeed can see that there´s a lag happening. With the OSD off, however, I´m under the impression that playback is perfectly smooth.

[namaiki]

Regarding the 60fps video: That's exactly what Reclock is for.

In the same way, my setup stutters, or jerks once a second because of 29.970fps and ~60Hz monitor without Reclock.

[Mark_A_W]

Render time usually falls between 20-25ms when resizing 1280x720 to 1600x900 with Spline36 Luma / Mitchell-Netravali Chroma and Present time somewhere between 8.5-9.5ms.

I never paid that close attention to delayed, only dropped. If I have time later today I'll check it out and report back. I'll try to get you some logs of 0.12 dropping frames as well.

Are you absolutely positive that the Render Queue staying permanently on 7/8 isn't related to my dropped frame woes? I'm asking again is because one thing I do remember is that madVR 0.11 would get delayed frames whenever the Render Queue dropped from 8/8 to 7/8 for a split second (which usually only happened when resizing 1080p and never 720p). In other words, if madVR 0.11 was staying permanently on 7/8 Render Queue, it would have caused guaranteed delayed frames, yet 0.12 only knows how to drop. It sounds extremely suspect to me.

I'm a bit curious why in 0.12 you are preferring to drop frames instead of keeping the delay+drop logic in 0.11. Does the drop only method bring some sort of benefit? It seems like it would just make things worse, causing a noticeable stutter whenever a frame drops, compared to a delayed frame where you would be hard pressed to notice a stutter at higher refresh rates since the frame is still displayed (at the next vsync?).

The part about the OSD causing stuttering on the 9400 makes me a little worried (stuttering=dropped frames?), since the dropped frames in 0.12 are at times very minor and hard to detect without the OSD being shown.

My Queue also sits on 7/8, and I am also running 95.904hz. I'm not having dropped frames with bluray mkvs.


I´ve just played back some blu-rays with 29.976 fps, several videos with 29.970fps, 25.000 fps and one with 60fps on a 60Hz display refresh (Eizo CG243W) and I must say I really like 0.12.

Apart from the 60fps one, every other movie/video played back without any dropped frames at all. Skipping is also quite fast (this may be dependent/limited by the res of the video, the GPU performance and your disk access time, e.x.) and happens without dropped frames. I don´t have reclock installed, btw. and I´m using the nvidia quadro 197.54 drivers for my GTX260.

The 60fps video behaves completely different though, but I think that´s (in part) due the refresh rate being higher than my actual display refresh. While I´ve configured 60Hz in the nvidia control panel, my actual refresh is more like 59.9 (that´s what my monitor shows), so I´m guessing it´s closer to 59.94Hz and not exactly 60Hz. While with 0.11 I can see "major" stutters and dropped frames along the whole video (~5:30 minutes) and about 10-15 dropped frames every 5-10 secs, 0.12 plays the video _very_ smooth, but still with a dropped frame almost every 10-20 secs, which I wouldn´t have noticed, but because the OSD is there and shows me "another frame just got dropped", I indeed can see that there´s a lag happening. With the OSD off, however, I´m under the impression that playback is perfectly smooth.

Are you sure the video is 60.000fps? The normal framerate is 59.94fps.

[iSunrise]

Are you sure the video is 60.000fps? The normal framerate is 59.94fps.
Yeah, I´ve double-checked it, just to be sure. It´s not an NTSC or PAL video, it´s a direct capture from a PC demo production, I prolly shouldn´t have used the term "video". Here´s the site http://www.pouet.net/prod.php?which=51078 and the direct link ftp://ftp.untergrund.net/users/kb/videos/ASD%20-%20Size%20Antimatters.mp4 (~412MB) in case anyone wants to try it out.

[Anima123]

Thinkpad T410 with NVS 3100 Video card, the latest driver. MadVR not working but freezes and occupy one core cpu power.

[namaiki]

Anima123: please name forceware version.

[tetsuo55]

Unfortunately it's not exactly the same:

(1) With a software decoder the decoded frame ends up in system RAM and I can reformat it in any way I like before uploading the data to the GPU. For your information: madVR splits the luma and chroma channels and stores them into separate textures. The textures claim to contain RGB data (although in reality they contain YCbCr data). So the GPU is not doing any damage to them when my pixel shader reads them.

(2) With DXVA the decoded frame ends up as an NV12 surface in GPU RAM. Now the problem is that pixel shaders can only read textures and not surfaces. And textures don't support NV12. I could directly copy the NV12 surface to a YCbCr texture on the GPU. But if a pixel shader reads a pixel from a YCbCr texture, the pixel is converted to 4:4:4 RGB on the fly behind the back of the pixel shader. The pixel shader never gets to see the original YCbCr data. I could directly copy the NV12 surface to an RGB texture, but doing so will make the GPU do chroma upsampling and YCbCr -> RGB conversion. I don't see any way to access the raw NV12 data from within my pixel shaders, without transfering the data to system RAM first. And as you probably know, transfering data from GPU RAM to system RAM is painfully slow... :(
albain and/or tal.aloni can help with that section.

[mark0077]

albain and/or tal.aloni can help with that section.

With all of this talk about DXVA with madVR, does it also apply to hardware de-interlacing. Reasons for me not outputting RGB32 with ffdshow, or not using madVR are basically because hardware de-interlacing still looks alot nicer to me than software (with yadif).

Would be amazing if I could have hardware de-interlacing in nv12, then to have madVR do the lovely conversions to RGB and scaling to 1920 x 1080.

[leeperry]

having second thoughts, if you ever decide to add PS gamut mapping script support, it'd be really sweet to be able to switch on the fly...it's not too convenient w/ 96MB lut files, and it would also allow ppl to set hotkeys and possibly assign them to a RF remote.

Joe Kane's Samsung projectors give direct access to the gamut mapping from their remote, but on the latest Epson's you have to dig into a bunch of sub-menus FWIR...direct access is a really nice feature :)

and possibly assign different default script depending on the windows device display name too, like HR does for the misconvergence "fix".

but I think D3D exclusive support would need to have a higher priority on your list if any possible, as this would finally put an end to all those VSYNC fliptime issues....I've spoken w/ Jong about all this, he told me "If madshi is doing anything at all to solve this problem it sounds like he is doing the equivalent of EVR Sync's "present at nearest" and having trouble working out which frame to target when at random, or after drift, the offset he needs to apply is almost exactly the same as the frame duration. EVR Sync even has the same bug, although the problem is less evident than without it.

if you use Beliyaal's "alternate vsync" there is no risk of synchronised judder because it writes straight to the front-buffer but the risk is you see tearing. It relies on VBlank to hide the tearing and positioning is done in software. Timing has to be really tight."

I've never seen tearing w/ his EVR CP, but ya never know :o

[cyberbeing]

For reference, I do find Beliyaal's "Alternate VSync" + "Accurate VSync" (along with "Flush GPU after VSync" + "Flush GPU after Present" and optionally "Wait for Flush" to help prevent tearing) is the smoothest when using VMR9 or EVR in MPC-HC with Reclock. On the other hand, "Present at Nearest" was horrible, so if madVR really is doing something similar, it may not be a bad idea to look into implementing something similar to Beliyaal's "Alternate VSync" to see if it improves things.

[Kazuya]

Strange, I saw a lot of systems so to mine which present tearing in Alternative Vsync in EVR Custom mode. But with windows XP !
Do you use Seven ?

[mark0077]

Hi madshi,

Using madvr 0.12 I can often play back perfectly smooth. However today, and only once, I started playing Avatar blu-ray, and although mpc-hc showed ~500 drawn, and 0 dropped frames, I seemed to be getting about 2fps, the video was so noticibly jerky. I took a screenshot when this was happening, for about 20 seconds.

Does anything look wrong in this screenshot + stats that might indicate what caused this niggle with madVR. This is using Core i7 @ 3.7ghz, GTX295, Windows 7 64bit.
http://img688.imageshack.us/img688/3944/avatarjerking.th.jpg (http://img688.imageshack.us/i/avatarjerking.jpg/)

And "The Dark Knight" m2ts file looks like this with madVR 0.12
http://img294.imageshack.us/img294/9536/thedarkknight.th.jpg (http://img294.imageshack.us/i/thedarkknight.jpg/)

and I'm also seeing random stutters even with almost perfectly matching rates and reclock vsync enabled. During a full bluray tonight myself and gf noticed maybe 5 or 6 big stutters.

[Grafisher]

0.12 really is awesome, because it plays my 40GB BDRip file very smoothly (unlike 0.11). The only problem I have encountered is severe stuttering after a few minutes of playback (using ZoomPlayer + Reclock on Win7 Aero). That's a showstopper for me, but I hope this will be fixed soon.

Thanks!

[Anima123]

Anima123: please name forceware version.

As I know, Thinkpad Laptop cannot use general version forceware. I couldn't tell what the equivalent forceware version is. Just want to know if there's someone happens to have the same kind of laptop as I have and have the same problem.

It was sad for me not being able to enjoy the new version of madVR with my new laptop. Hope the new video card driver can solve the problem or maybe madshi can bring us a compatibility enhanced new version.

[namaiki]

You can check the forceware version using GPU-z.