madVR - high quality video renderer (GPU assisted)

[e2]

Just found out about this and wanted to try it out, and I'm sure it's been mentioned before, but madvr is greyed out for me, i have MPC-HC 64bit, would that be problem?

[leeperry]

madvr is greyed out for me, i have MPC-HC 64bit
you need the x86 build of MPC

[e2]

you need the x86 build of MPC

Just tried the x86, it's still greyed out. Also tried zoomplayer and I could choose madVR there, but I only get audio, no video?

I'm on Windows 7 x64 and I have a ATI Radeon 4870 with the 10.3 drivers.

[leeperry]

Just tried the x86, it's still greyed out.
does it show up in this list? http://thumbnails16.imagebam.com/7949/16e6f479484655.gif (http://www.imagebam.com/image/16e6f479484655)

are you outputting YV12?

[xiulet]

hi i try serveral dvds and mkvs and not problems of visualisation,
but this two are crappy:

http://img8.imageshack.us/img8/9859/snap3j.png
General
Complete name : F:\a copiar\a time to love and time to die(dual) 1958 Douglas Sirk.mkv
Format : Matroska
File size : 1.76 GiB
Duration : 2h 6mn
Overall bit rate : 1 988 Kbps
Encoded date : UTC 2010-05-02 12:49:20
Writing application : mkvmerge v3.2.0 ('Beginnings') built on Feb 12 2010 16:46:17
Writing library : libebml v0.7.9 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Muxing mode : Container profile=Unknown@4.1
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 6mn
Bit rate : 1 565 Kbps
Nominal bit rate : 1 600 Kbps
Width : 720 pixels
Height : 436 pixels
Display aspect ratio : 1.651
Frame rate : 25.000 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.199
Stream size : 1.38 GiB (79%)
Writing library : x264 core 94 r1564 a927654
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / wpredp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=45 / rc=2pass / mbtree=1 / bitrate=1600 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=2:1.00
Language : English

Audio #1
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 2h 6mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 174 MiB (10%)
Language : Spanish

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 2h 6mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Stream size : 174 MiB (10%)
Language : English

Text
ID : 4
Format : VobSub
Codec ID : S_VOBSUB
Codec ID/Info : The same subtitle format used on DVDs
Language : Spanish




http://img687.imageshack.us/img687/7910/snap1k.png
General
Complete name : F:\a copiar\avatar 2009.mkv
Format : Matroska
File size : 33.4 GiB
Duration : 2h 41mn
Overall bit rate : 29.6 Mbps
Encoded date : UTC 2010-04-25 01:45:08
Writing application : mkvmerge v3.2.0 ('Beginnings') built on Feb 12 2010 16:46:17
Writing library : libebml v0.7.9 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 41mn
Bit rate : 28.2 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Bits/(Pixel*Frame) : 0.568
Stream size : 31.9 GiB (95%)

Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 2h 41mn
Bit rate mode : Constant
Bit rate : 755 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Resolution : 24 bits
Stream size : 873 MiB (3%)
Language : Spanish



i am using mpc hc 1.3.1845.0 x32 (haali or internal mkv splitter)
Versión del paquete de controladores 8.723.5-100419a-098854E-ATI
Versión de Catalyst™ 10.4
Proveedor ATI Technologies Inc.
Versión de controlador 2D 8.01.01.1016
Versión de Direct3D 8.14.10.0743
Versión de OpenGL 6.14.10.9756
Versión de Catalyst™ Control Center 2010.0419.2150.37358



thank you, for this great peace of software.

adéu.

[Gandul]

Hey, just wanted to say that whatever you did optimisations wise for v0.12, you're on the right track ! I'm almost able to look at 720p hd movies smoothly on my crappy single core Pentium IV 2,4 Ghz. (My GC is the ATI HD 3850 512 Mb AGP) I only get stuttering on fast scenes but I expected that, maybe in future versions I'll get constant smooth playback ? :D

[namaiki]

maybe in future versions I'll get constant smooth playback ? :D

Depends what video decoding filter you are using, eg ffdshow video, coreavc, mpc decoder(dxva).

[Gandul]

Well I was using ffdshow, maybe it would be smooth with coreavc ? But why did you mention dxva ? It's currently impossible to use that with madvr...

[namaiki]

Well I was using ffdshow, maybe it would be smooth with coreavc ? But why did you mention dxva ? It's currently impossible to use that with madvr...

It's just the name of a video decoding filter. Try the divx h.264 filter. Last I checked, performance was just about in the middle of ffmpeg-mt and coreavc.

[Gandul]

Ok tried the divx one and it gives me the same performance as libavcodec and ffmpeg-mt (Smooth but with stuttering in fast scenes.) Coreavc was the worse one for me and it seemed to degrade considerably the PQ.

[namaiki]

Coreavc was the worse one for me and it seemed to degrade considerably the PQ.

It doesn't change PQ unless you played with the levels or deblocking settings.


Also, try timecodec.exe to find the fastest decoder for your system (http://ffdshow-tryout.sourceforge.net/wiki/faq:performance_with_filters).

[Gandul]

Where must I put that file ? (timecodec.exe)

[namaiki]

Where must I put that file ? (timecodec.exe)

You run it, open a file, let it decode and get statistics at the end. Note how you can choose which decoder to use.

[Anima123]

You can check the forceware version using GPU-z.

Thanks for your help. GPU-Z indicate the forceware version is 188.98

[e2]

does it show up in this list? http://thumbnails16.imagebam.com/7949/16e6f479484655.gif (http://www.imagebam.com/image/16e6f479484655)

are you outputting YV12?

I reinstalled it twice, and it shows up now, thanks!

[leeperry]

I reinstalled it twice, and it shows up now, thanks!
np, glad it worked ;)

BTW, I was discussing about D3D/Vsync w/ Jong again(as we've been doing for quite some time now :D), and a "look ma no hands" mode in mVR to allow Reclock to lead the dance would be really neat if any possible.

It should be possible for madshi, for example, to offer a non-D3D mode that allows Reclock to control vsync. He just needs an option to turn off his code that control point of presentation. Also, just madshi offering a D3D mode will not allow Reclock vsync correction to work - he would still need that option to disable his own vsync code, although D3D mode will probably help him in other ways, as mentioned above.

The default D3D-mode for VMR9 and EVR frees up the point of presentation so Reclock can control it. This is great, but not inevitable. If you turn on vsync correction in EVR Sync or EVR CP, for example, Reclock vsync correction does not work, even in D3D mode.

[djsolidsnake86]

the new version rock! however there is a problem that was also in old release: with some video files probably mp4 and h264 i can't saw the video, i only see various colours like green and red lines
what is?

[madshi]

BTW, I was discussing about D3D/Vsync w/ Jong again(as we've been doing for quite some time now :D), and a "look ma no hands" mode in mVR to allow Reclock to lead the dance would be really neat if any possible.

It should be possible for madshi, for example, to offer a non-D3D mode that allows Reclock to control vsync. He just needs an option to turn off his code that control point of presentation. Also, just madshi offering a D3D mode will not allow Reclock vsync correction to work - he would still need that option to disable his own vsync code, although D3D mode will probably help him in other ways, as mentioned above.

The default D3D-mode for VMR9 and EVR frees up the point of presentation so Reclock can control it. This is great, but not inevitable. If you turn on vsync correction in EVR Sync or EVR CP, for example, Reclock vsync correction does not work, even in D3D mode.
To be honest, I don't even know what Reclock's vsync correction does exactly and how it would "help" madVR. If I disabled my own VSync related code, I wouldn't even know when to present any frames in the first place. My whole presentation logic is based on knowing which VSyncs occur when and on calculating the optimal presentation flow based on that information.

the new version rock! however there is a problem that was also in old release: with some video files probably mp4 and h264 i can't saw the video, i only see various colours like green and red lines
what is?
Which decoder are you using? Try a different one. Might be a decoder bug, or a bug in madVR. Or maybe decoder and madVR don't like each other...

[djsolidsnake86]

To be honest, I don't even know what Reclock's vsync correction does exactly and how it would "help" madVR. If I disabled my own VSync related code, I wouldn't even know when to present any frames in the first place. My whole presentation logic is based on knowing which VSyncs occur when and on calculating the optimal presentation flow based on that information.


Which decoder are you using? Try a different one. Might be a decoder bug, or a bug in madVR. Or maybe decoder and madVR don't like each other...

this is the decoder
if you want i can send you the video file
madvr settings are default


Filter : DivX H.264 Decoder - CLSID : {6F513D27-97C3-453C-87FE-B24AE50B1601}

- Connected to:

CLSID: {55DA30FC-F16B-49FC-BAA5-AE59FC65F82D}
Filter: D:\Video\80s Spot\1988 - Campari Soda.mp4
Pin: Video

- Connection media type:

Video: MPEG4 Video (H264) 450x360 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 0
lSampleSize: 1
cbFormat: 168

VIDEOINFOHEADER:
rcSource: (0,0)-(0,0)
rcTarget: (0,0)-(0,0)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333666

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 5
dwPictAspectRatioY: 4
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 36
dwProfile: 0x00000042
dwLevel: 0x00000016
dwFlags: 0x00000002

BITMAPINFOHEADER:
biSize: 40
biWidth: 450
biHeight: 360
biPlanes: 1
biBitCount: 24
biCompression: avc1
biSizeImage: 0
biXPelsPerMeter: 1
biYPelsPerMeter: 1
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020: 00 00 00 00 00 00 00 00 62 17 05 00 00 00 00 00 ........b.......
0030: 00 00 00 00 00 00 00 00 05 00 00 00 04 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 c2 01 00 00 ........(...Â...
0050: 68 01 00 00 01 00 18 00 61 76 63 31 00 00 00 00 h.......avc1....
0060: 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 24 00 00 00 42 00 00 00 16 00 00 00 ....$...B.......
0080: 02 00 00 00|00 1c 67 42 c0 16 bb 40 e8 5f c4 4b ......gBÀ.»@è_ÄK
0090: ff 80 00 80 00 88 00 00 03 03 20 00 00 bb 54 78 ÿ€.€.ˆ.... ..»Tx
00a0: b1 75 00 04 68 ce 32 c8 ±u..hÎ2È

[mark0077]

Hi madshi, One screenshot was taken lazily at 50hz, I wonder does this explain why the present time was different from one to the other. In any case, I really don't know why the stats would look fine and I was getting just a few frames per second, must be something wrong with gfx drivers perhaps?

Regarding green horizontal lines, I was using ffdshow decoder, which doesn't display the greenish horizontal line in other renderers. This is why I felt it was madVR causing the lines somehow.

Regarding stuttering, yeah any work on this would be amazing, I have to say, maybe because of the great colorspace conversion and scaling, motion looks smoother (apart from the odd judder of course) with madVR. Maybe its a placebo effect but things just look so lovely and smooth in motion. I assume its due to the quality of the renderer. Never imagined I would see that smoother motion effect from increased visual quality.

Send on any betas etc if you require testing, really excited to see madVR become smoother :D

[Jong]

To be honest, I don't even know what Reclock's vsync correction does exactly and how it would "help" madVR. If I disabled my own VSync related code, I wouldn't even know when to present any frames in the first place. My whole presentation logic is based on knowing which VSyncs occur when and on calculating the optimal presentation flow based on that information.


Which decoder are you using? Try a different one. Might be a decoder bug, or a bug in madVR. Or maybe decoder and madVR don't like each other...hi madshi, hope you are well.

It may be worth allowing, optionally, Reclock to control vsync. For those using it for other players it is kind logical to use for mpc-hc too. Alternatively they need to edit Reclock's registry entries before loading mpc-hc to turn off vsync correction, which is a bit messy!

What Reclock vsync correction does is:

- It (somehow!) works out the scanline position at the time of "end of presentation" and averages it over several frames.

- If this average is outside of its desired range it makes small adjustments to the reference clock to move the average end of presentation back into its target zone. To do this the end of presentation must be "free running". If the renderer itself is fixing the start of presentation to (near) a specific scanline then even when Reclock alters the reference clock the renderer just alters its offset to hit its same scanline target, so Reclock sees no change and keeps running the reference clock too fast, or slow, leading to "rolling sync" with periodic judder.

So to make madVR compatible with Reclock vsync you need to render a frame in such a way that small, brief changes to the reference clock will alter the position in the frame that start of presentation (and hence end of presentation) will happen.

As Reclock works on an average the natural variability in rendering/presentation/scheduling time is fine, provided it is relatively consistent, as it is with most modern PCs and especially with W7.

Assuming leeperry is right (I have not tested) and you currently have a problem with synchronised judder, it would of course also be good if that was fixed and MadVR could stand on its own. I don't feel able to comment on your specific algorithm other than to say it does seem surprisingly difficult to really eliminate this issue unless, like Reclock you can use small, brief changes in frame rate to move the point of presentation. Although I am sure it must be possible, a few others have tried and I am not sure any have succeeded. ar-jar has tried with his "Present at nearest" option but that, like, maybe, MadVR, has only made the problem a little less frequent, not fully resolved it.

In ar-jar's case he seems just to have moved the problem. He fixes the start of presentation to a target scanline, so stops that, or end of presentation, happening around vsync, but his code still has a problem when the offset he needs to apply to target that scanline is very close to precisely one frame duration i.e. if, randomly after seek, on average, frames are ready for presentation at around scanline 200, and he is targeting scanline 200, the random variation from frame to frame leads him to sometimes target one frame and sometimes the next - the problem has moved, I think with tighter tolerance, but not really been resolved. Without knowing what you are doing it may be possible you have a similar issue. What do you think?

[madshi]

It may be worth allowing, optionally, Reclock to control vsync. For those using it for other players it is kind logical to use for mpc-hc too. Alternatively they need to edit Reclock's registry entries before loading mpc-hc to turn off vsync correction, which is a bit messy!

What Reclock vsync correction does is:

- It (somehow!) works out the scanline position at the time of "end of presentation" and averages it over several frames.

- If this average is outside of its desired range it makes small adjustments to the reference clock to move the average end of presentation back into its target zone. To do this the end of presentation must be "free running". If the renderer itself is fixing the start of presentation to (near) a specific scanline then even when Reclock alters the reference clock the renderer just alters its offset to hit its same scanline target, so Reclock sees no change and keeps running the reference clock too fast, or slow, leading to "rolling sync" with periodic judder.

So to make madVR compatible with Reclock vsync you need to target a frame in such a way that small, brief changes to the reference clock will alter the position in the frame that start of presentation (and hence end of presentation) will happen.
Hey Jong, nice to see you here!

Hmmmm... What do you mean with "start of presentation" and "end of presentation" exactly?

I understand that Reclock modifies the reference clock, but Reclock does not change the GPU pixel clock (at least as far as I know), so whatever Reclock does, does not change the *system time* (not reference clock time) when the next VSync happens, right? madVR knows at which system time the next VSyncs will happen and executes its presentation logic based on that.

Assuming leeperry is right (I have not tested) and you currently have a problem with synchronised judder, it would of course also be good if that was fixed and MadVR could stand on its own.
I don't know if leeperry is right. It seems that some people have stuttering issues and I don't know where exactly it comes from. In theory I think my presentation logic should be stutter free.

I don't feel able to comment on your specific algorithm other than to say it does seem surprisingly difficult to really eliminate this issue unless, like Reclock you can use small, brief changes in frame rate to move the point of presentation. Although I am sure it must be possible, a few others have tried and I am not sure any have succeeded. ar-jar has tried with his "Present at nearest" option but that, like, maybe, MadVR, has only made the problem a little less frequent, not fully resolved it.

In ar-jar's case he seems just to have moved the problem. He fixes the start of presentation to a target scanline, so stops that happening around vsync, but his code still has a problem when the offset he needs to apply to target that scanline is very close to precisely one frame duration i.e. if, randomly after seek, on average, frames are ready for presentation at around scanline 200, and he is targeting scanline 200, the random variation from frame to frame leads him to sometimes target one frame and sometimes the next - the problem has moved, I think with tighter tolerance, but not really been resolved. Without knowing what you are doing it may be possible you have a similar issue. What do you think?
I'm not sure I understand some of the terms you're using and I also don't really know what ar-jar is doing. I can tell you, however, how madVR's presentation logic works in detail. Maybe that helps clearing up things?

(1) madVR constantly polls the GPU's scanline information, and this way calculates the exact display refresh rate, and also knows when (system time tick) the very next VSync will start exactly, and the VSync after that etc...

(2) Every video frame comes with a timestamp. So madVR calculates at which VSync each frame should be presented. This is done by floating point math. So e.g. for frame 10 madVR might calculate "idealPresentationTime -> 30.2", which means that madVR should try to present frame 10 in such a way that it's shown directly after the blank period of VSync number 30.

(3) Let's say frame 11 ends up with an "ideal presentation time" of "32.5". This is difficult, because madVR could present this frame either after VSync 32 or 33. So for frames which are in the range xx.35 to xx.65, madVR considers rounding the VSync number in either direction. In order to decide in which direction rounding should be done, madVR calculates the time offset between frame 11 and frame 10 for both VSync rounding variations. E.g. let's say that the video is 25fps. So each frame should be displayed for 40ms. And let's say that each VSync is exactly 15ms apart. Now if madVR displays frame 11 at VSync 32, madVR calculates the time difference between VSync 32 and VSync 30 (frame 10). That would be 2 * 15 = 30ms. The time difference between VSync 33 and 30 is then 3 * 15 = 45ms. Now because 45ms is nearer to the ideal time offset of 40ms, madVR decides to present frame 11 after VSync 33.

(4) Now madVR knows exactly at which VSync each frame should be presented. The next problem is when to do the actual "Direct3D::Present()" call. This is problematic, because the "Present()" call blocks (doesn't return), until the target VSync event is through. And during the blocked time, the GPU doesn't render, anymore. So if madVR presents too early, rendering stops, which can cause stuttering (because the queues empty and no new frames can be rendered). But if madVR calls the "Present()" API too late, with a bit of bad luck, it might be too late and Direct3D might sloü the targetted VSync and wait for the next VSync instead, which would also cause stuttering.

So there are multiple reasons for how stuttering can occur: There could be a bug in the steps (1)..(3). Or the stuttering could also be caused by the "Present()" problems I've described in step (4). The fullscreen exclusive mode will fix the problems in (4), because in exclusive mode madVR will be able to present, and still can continue rendering at the same time. This logic only works in fullscreen exclusive mode. However, if the cause of the stuttering is in steps (1)..(3), fullscreen exclusive mode won't fix the stuttering.

I'm not really sure how Reclock comes into play, given the madVR presentation logic described above...

Your thoughts? Hope you understand my explanation above...

[madshi]

this is the decoder
if you want i can send you the video file
And this video file works fine with other renderers? If so, please upload the video file (a small sample should be good enough) and send the link to me via PM. Thanks!

Hi madshi, One screenshot was taken lazily at 50hz, I wonder does this explain why the present time was different from one to the other.
Not really. Do you have Aero on or off?

In any case, I really don't know why the stats would look fine and I was getting just a few frames per second, must be something wrong with gfx drivers perhaps?
Don't know. Depends on Aero. With Aero turned on, strange things can happen, if madVR gets the presentation timing wrong just a tiny bit. madVR might still believe then that everything's ok, while in real life its not. So my best guess is that you have Aero on? Please understand that I don't consider Aero as a bad choice. It has advantages and disadvantages and in future madVR versions I might code a special path for Aero which takes advantage of the positive things.

Regarding green horizontal lines, I was using ffdshow decoder, which doesn't display the greenish horizontal line in other renderers. This is why I felt it was madVR causing the lines somehow.
Not necessarily. madVR is special in that it only accepts YV12. Other renderers are less picky. So maybe the problem doesn't occur with other renderers, because ffdshow connects to them with a different color space/format? Please try a different decoder, just to be sure.

I have to say, maybe because of the great colorspace conversion and scaling, motion looks smoother (apart from the odd judder of course) with madVR. Maybe its a placebo effect but things just look so lovely and smooth in motion. I assume its due to the quality of the renderer. Never imagined I would see that smoother motion effect from increased visual quality.
My best guess would be that it's the high bitdepth processing and dithering. These things are not very visible in motion. But if you have ever so slightly small banding caused by too-low bitdepth or non-dithering, while almost invisible in screenshots, it can look very unnatural in motion.

Just guessing here, though...

[mark0077]

And this video file works fine with other renderers? If so, please upload the video file (a small sample should be good enough) and send the link to me via PM. Thanks!


Not really. Do you have Aero on or off?


Don't know. Depends on Aero. With Aero turned on, strange things can happen, if madVR gets the presentation timing wrong just a tiny bit. madVR might still believe then that everything's ok, while in real life its not. So my best guess is that you have Aero on? Please understand that I don't consider Aero as a bad choice. It has advantages and disadvantages and in future madVR versions I might code a special path for Aero which takes advantage of the positive things.


Not necessarily. madVR is special in that it only accepts YV12. Other renderers are less picky. So maybe the problem doesn't occur with other renderers, because ffdshow connects to them with a different color space/format? Please try a different decoder, just to be sure.


My best guess would be that it's the high bitdepth processing and dithering. These things are not very visible in motion. But if you have ever so slightly small banding caused by too-low bitdepth or non-dithering, while almost invisible in screenshots, it can look very unnatural in motion.

Just guessing here, though...

Hi madshi. Oh yes I have aero on always. Would you recommend I disable it for use in video playback. I thought aero simply introduced a one frame video delay, which I always suspected brought audio / video out of sync but it being on never had bad effects with evr-cp for example.

I'll do more tests with the green lines with different decoders and get back to you, cheers.

[leeperry]

I don't know if leeperry is right. It seems that some people have stuttering issues and I don't know where exactly it comes from. In theory I think my presentation logic should be stutter free.
the only thing I can say is that I've always had this problem w/ all the renderers(regular EVR/HR/VMR9)...Reclock's VSYNC code always seems "fight" against the VR's VSYNC built-in code, reason why Overlay would work w/o a itch apparently...it wouldn't happen to have any VSYNC control code.

Reclock tries to "guess" the VSYNC position, but the VR is already having a hard time trying to figure out where it could be at this very moment...so the best solution would be to let Reclock "control" it, so those "detection" algorithms don't fight back :o

going D3D exclusive mode would force the VSYNC control "in hardware" and force everyone to obey...that's my simple explanation, and I'm sure Jong will get far in more in details about this.

[madshi]

Reclock tries to "guess" the VSYNC position, but the VR is already having a hard time trying to figure out where it could be at this very moment...
madVR knows quite exactly where the VSync position is at any given time.

[leeperry]

ok, my bad! BTW, I don't have that stuttering problem if I check "disable tearing fix" in mVR, but then I get some strange occasional tearing..hopefully Jong will be able to shed some lights on that matter.

[makakam]

The problem with subtitles and the picture in some movies which I experienced and mentioned before is now gone. I've simply installed core avc (previously it was mpc hc decoder) as a decoder and everything is just fine. Even m2ts files with bitrate over 30Mbits are super smooth.

[djsolidsnake86]

http://web.tiscali.it/djsolidsnake86/video.mp4

if anyone want try madvr with this video, there is a very strange problem

[6233638]

Just wanted to thank you for this update. My PC is also using a 9400M (186.86-the last good nvidia driver for it) and when the OSD is hidden I now have perfectly smooth playback with some of the more advanced up/downsampling algorithms. I can tell what is/is not going to be smooth from the time reported in the OSD though, I just need to turn it off for playback. Previously I was stuck using bilinear for everything, though it still looked better than other renderers due to the 16-bit conversion & dithering.

Now I can use Bicubic 75 on the upscaling for chroma & luma, and lanczos3 for downscaling without dropped frames-not that I ever downsample. I need to do more testing on what is best for luma; previously I settled on mitchell-netravali but I want to do more testing on it again, which is going to be a lot easier now that frame-by-frame in MPC-HC is working.

For chroma, unless it has changed in 0.12 from 0.11, Bicubic75 is the only option. The only other that worked well was spline36 but then edges looked strange. Everything else either blurs too much or desaturates things. I was surprised at that result too.


I hope this is a simple request, but I was hoping that you would be able to change the preferences box. Because I use a CRT, I generally adjust the display resolution to match the video resolution (so madVR is only doing chroma upsampling) and the box is too tall for 640x480 so I can't click the ok/cancel/apply buttons. I was thinking if you moved the checkboxes over to the right it would work better.


lee, with reclock, disable its V-Sync correction and leave madVR's tearing correction enabled. Windows 7, Aero on - disabling aero usually causes tearing, leave it on.
ffdshow decoding: ffmpeg-mt for h.264, libavcodec for mpeg2 and libavcodec for vc-1. Make sure you use libavcodec for vc-1. While the wmv9 decoder uses less cpu and benchmarks better, it is not possible to get smooth playback in MPC-HC + madVR from my testing.
Reclock outputting WASAPI, upsampling to 32/192 (best sinc, custom resampler) all v-sync correction off.
Haali media splitter. I'm using one from 2009 as the latest don't work with a lot of Bluray m2ts files. (either no audio or video)
MPC-HC for playback. KMP looks a lot nicer but I had problems playing back some discs/files. MPC-HC works perfectly.
This setup gets 100% smooth playback with perfect lip-sync and no dropped/skipped frames. Reclock is still used for upsampling, slowing down PAL and making sure audio is in sync with video.

[Jong]

Hey Jong, nice to see you here!

Hmmmm... What do you mean with "start of presentation" and "end of presentation" exactly?Hi mate.

Ah! You got me! I've never written a renderer in my life and am using the woolly language of the "web". :o

I believe "start presentation" is when you do your "Direct3D::Present()" call and "end present" is when that returns. It seems you have the same problem as the standard VMR9/EVR renderers, in that the call does not return until after vsync. I thought that, as you are pretty much building from scratch, you might have been able to get round that restriction. If you cannot, like those renderers, it may only be possible to work with Reclock vsync correction in D3D mode, or maybe Aero. Then the call should return as soon as it complete and the gap between the two varies depending purely on the amount of work needed to be done, varying, e.g., even when the OSD is turned on. But we would still need to avoid pinning the "present call" to any specific position in the vsync cycle.

I understand that Reclock modifies the reference clock, but Reclock does not change the GPU pixel clock (at least as far as I know), so whatever Reclock does, does not change the *system time* (not reference clock time) when the next VSync happens, right? madVR knows at which system time the next VSyncs will happen and executes its presentation logic based on that.Yeah, Reclock only alters the reference clock, not the pixel clock. Again, in woolly web language, whether doing vsync correction or just its normal job, it fools the player into thinking time is running faster or slower than it really is so the frame rate is changed without actually changing any timecodes. I don't know if this causes you any specific problems, given your vsync code. To most players it appears to be transparent.

I don't know if leeperry is right. It seems that some people have stuttering issues and I don't know where exactly it comes from. In theory I think my presentation logic should be stutter free.


I'm not sure I understand some of the terms you're using and I also don't really know what ar-jar is doing. I can tell you, however, how madVR's presentation logic works in detail. Maybe that helps clearing up things?

(1) madVR constantly polls the GPU's scanline information, and this way calculates the exact display refresh rate, and also knows when (system time tick) the very next VSync will start exactly, and the VSync after that etc...

(2) Every video frame comes with a timestamp. So madVR calculates at which VSync each frame should be presented. This is done by floating point math. So e.g. for frame 10 madVR might calculate "idealPresentationTime -> 30.2", which means that madVR should try to present frame 10 in such a way that it's shown directly after the blank period of VSync number 30.

(3) Let's say frame 11 ends up with an "ideal presentation time" of "32.5". This is difficult, because madVR could present this frame either after VSync 32 or 33. So for frames which are in the range xx.35 to xx.65, madVR considers rounding the VSync number in either direction. In order to decide in which direction rounding should be done, madVR calculates the time offset between frame 11 and frame 10 for both VSync rounding variations. E.g. let's say that the video is 25fps. So each frame should be displayed for 40ms. And let's say that each VSync is exactly 15ms apart. Now if madVR displays frame 11 at VSync 32, madVR calculates the time difference between VSync 32 and VSync 30 (frame 10). That would be 2 * 15 = 30ms. The time difference between VSync 33 and 30 is then 3 * 15 = 45ms. Now because 45ms is nearer to the ideal time offset of 40ms, madVR decides to present frame 11 after VSync 33.

(4) Now madVR knows exactly at which VSync each frame should be presented. The next problem is when to do the actual "Direct3D::Present()" call. This is problematic, because the "Present()" call blocks (doesn't return), until the target VSync event is through. And during the blocked time, the GPU doesn't render, anymore. So if madVR presents too early, rendering stops, which can cause stuttering (because the queues empty and no new frames can be rendered). But if madVR calls the "Present()" API too late, with a bit of bad luck, it might be too late and Direct3D might sloü the targetted VSync and wait for the next VSync instead, which would also cause stuttering.

So there are multiple reasons for how stuttering can occur: There could be a bug in the steps (1)..(3). Or the stuttering could also be caused by the "Present()" problems I've described in step (4). The fullscreen exclusive mode will fix the problems in (4), because in exclusive mode madVR will be able to present, and still can continue rendering at the same time. This logic only works in fullscreen exclusive mode. However, if the cause of the stuttering is in steps (1)..(3), fullscreen exclusive mode won't fix the stuttering.

I'm not really sure how Reclock comes into play, given the madVR presentation logic described above...

Your thoughts? Hope you understand my explanation above...You are right of course there are many possible causes for judder.

I agree D3D mode should help with your point number 4.

However, the way leeperry describes his issue it is totally consistent with the problem of "synchronised frame rate/refresh rate judder", that Reclock's vsync correction is designed to avoid (as you have seen before, see http://software.intel.com/en-us/articles/video-frame-display-synchronization/ and the description, around figure 5). I think that points to a possible problem with your point 3.

With this issue, the key thing to consider is not what happens in the example you gave, but what happens when the frame rate and refresh rate are precisely "compatible" i.e. an exact multiple of each other (25p@50Hz, 24p@23.976Hz, 29.97@59.94Hz, 30.000fps@60Hz (normally Reclock speedup of 29.97)
etc.), or capable of rendering with a regular cadence (24p@59.94Hz, 30.000fps@50Hz etc.).

If you look at a variation of your example, the question is what happens when the video is 25p and the gap between vsyncs is 20ms. I'm not sure how the problem might occur. I'm not claiming to have some magic insight here. But, looking at it with a new set of eyes, the logic of the method you describe in 3 seems robust. But I wonder how you calculate the "ideal presentation time" and whether Reclock's playing with the reference clock but not the system time or timecodes might cause you some problems. Alternatively, given leeperry's observation that the problem only occurs when the "tearing fix" is enabled, maybe we need to look at what that code does.

the only thing I can say is that I've always had this problem w/ all the renderers(regular EVR/HR/VMR9)...Reclock's VSYNC code always seems "fight" against the VR's VSYNC built-in code, reason why Overlay would work w/o a itch apparently...it wouldn't happen to have any VSYNC control code.

Reclock tries to "guess" the VSYNC position, but the VR is already having a hard time trying to figure out where it could be at this very moment...so the best solution would be to let Reclock "control" it, so those "detection" algorithms don't fight back :o

going D3D exclusive mode would force the VSYNC control "in hardware" and force everyone to obey...that's my simple explanation, and I'm sure Jong will get far in more in details about this.Reclock vsync correction will have a problem with any renderer where changing the frame rate temporarily from its normal target does not change the point "end present" returns. So far it seems "end present" is, "free running", i.e. not tied to vsync if:

- using an overlay surface
- using D3D mode in a renderer that does not itself attempt to pin the start of presentation to a specific scanline (so average end of presentation is also effectively pinned).
- using Aero in a renderer that does not itself attempt to pin the start of presentation to a specific scanline

D3D mode does not I think, "force vsync control in hardware" it just allows end present to "float"with non-overlay renderers thus allowing it to control that position

Reclock does not guess the vsync position. It measures the average position where end of present occurs and changes the frame rate very slightly and briefly to bring that end of presentation to its target position. Based on the way the Reclock vsync slider works it seems (I admit I am not sure on this point) that it does not actually know the scanline. Else I would expect the slider at the top would always put the marker at the top and visa-versa the bottom. But once set "by sight" the effect is the same.

[iSunrise]

http://web.tiscali.it/djsolidsnake86/video.mp4

if anyone want try madvr with this video, there is a very strange problem
No problem at all with that video. It´s perfectly smooth here. Looks like a capture done from a VCR tape. However, by looking at the frame rate it shows 24.967fps, instead of 25.000fps for PAL video.

@6233638:
Same config here, but no reclock. I´ve tried about a hundred different files with madVR 0.12 since yesterday and it´s dead smooth (excluding the 60fps one I posted). Even the OSD shows no dropped frames (sometimes it even starts with 0), but my eyes usually are the judge here. I`ve also tested about a dozen different files from http://w6rz.net/ - even 1080p25@60Hz doesn´t drop frames.

[Jong]

That's all clear.

Yeah, sorry about "D3D mode", sometimes I use "exclusive mode". I'm just using the woolly terminology, in this case of mpc-hc.

I understand you cannot control when present() returns, but users could by choosing Aero mode or "exclusive". that is what i do with EVR Sync renderer.

Regarding the problem with when to call "Present()", maybe it is worth looking at the code for sync renderer or EVR CP, or VMR9 in exclusive mode. All of those work with Reclock vsync if in exclusive or Aero mode, including 24p material @59.94Hz. In fact for 24p sped up to 25p by Reclock @50Hz, 25p@50hz etc. etc. Without designing for Reclock they seem to naturally start presentation at a time that is random after start of playback or after a seek and which then varies if the frame rate is manipulated by Reclock.

[madshi]

Regarding the problem with when to call "Present()", maybe it is worth looking at the code for sync renderer or EVR CP, or VMR9 in exclusive mode. All of those work with Reclock vsync if in exclusive or Aero mode, including 24p material @59.94Hz. In fact for 24p sped up to 25p by Reclock @50Hz, 25p@50hz etc. etc. Without designing for Reclock they seem to naturally start presentation at a time that is random after start of playback or after a seek and which then varies if the frame rate is manipulated by Reclock.
I prefer not to look at other people's code, but writing my own instead. This is not meant as a disrespect to other people's work, but I think it's sometimes better to start with fresh ideas. Also duplicating code from an open source project into my closed source renderer would be "bad".

I'm confident, though, that I'll be able to work out any remaining problems, sooner or later.

[Razoola]

(4) Now madVR knows exactly at which VSync each frame should be presented. The next problem is when to do the actual "Direct3D::Present()" call. This is problematic, because the "Present()" call blocks (doesn't return), until the target VSync event is through. And during the blocked time, the GPU doesn't render, anymore. So if madVR presents too early, rendering stops, which can cause stuttering (because the queues empty and no new frames can be rendered). But if madVR calls the "Present()" API too late, with a bit of bad luck, it might be too late and Direct3D might sloü the targetted VSync and wait for the next VSync instead, which would also cause stuttering.

Is it not possible to calculate if the second instance above has happened by timing how long the present call takes to return? Then if it does happen simply adjust the present time to be earlier?

[edit]
In fact if you do not already do so maybe its always good to time the "Direct3D::Present()" block so the renderer can find the optimal scan line where "Direct3D::Present()" can be called and be returned the quickest.

[6233638]

How did you test desaturation? Did you happen to use that circular test pattern from the Joe Kane calibration Blu-Ray? Or some other test pattern?I actually noticed it when watching a low-resolution video on the HTPC. (about 2:10 into this (http://media.giantbomb.com/video/vf_dper_vj25_here_1500.flv)-sorry it's a huge file and I don't know how to just upload a small section of it)

Magnified 4x:
http://img16.imageshack.us/img16/9069/wgxo46.png Nearest Neighbour Bilinear SoftCubic 100 Lanczos 3. Saturation is fine but edges are bad in other tests; same with spline. Bicubic 75
The algorithms also seem differ and shift left/right slightly as well. Very obvious when you change between bilinear and bicubic for example.

That won't work. In future madVR versions the settings dialog will get rather larger than smaller, because there are going to be plenty more options. There may be other solutions for your problem, but I'm not ready to talk about that yet.No worries, I realize most people won't be using x480 resolutions. (x576 is fine) I can just hit tab 5/7 times on the keyboard to OK/Apply. Not like I need to change things frequently anyway, it's just easiest to see the differences in chroma upsampling at those low resolutions on a CRT.

[Grafisher]

The only problem I have encountered is severe stuttering after a few minutes of playback (using ZoomPlayer + Reclock on Win7 Aero).
Does the "dropped frames" number in the OSD (Ctrl + J) increase when that stuttering begins?
Yes, it drops frames pretty quickly. Also, the render queue and backbuffer queue are empty. Other queues are fine.

I noticed that it does not occur when I play it in a smaller window, which means that this has probably something to do with the memory usage, because, in fullscreen, the buffers occupy 241/256 MB of memory. It plays fine for a while though. I suspect that it fails to allocate memory for something.

I think this can be solved by detecting such problems and decreasing the queue size, or by making this configurable.

Cheers

[leeperry]

actually I think I've just found a bug in the point 3 code in madVR 0.12. I actually implemented this code only in the latest version v0.12. The previous version (v0.11) didn't have that point 3 code yet. And I think it's slightly buggy in the current version. So *maybe* leeperry's problem will already be fixed in the next build.
the problem was identical in 0.11, but as I previously said it completely went away when disabling the anti-tearing fix in mVR.

basically, it goes like this:
-mVR's anti-tearing fix enabled: I get the usual luck of the draw when seeking...either I will "catch" the VSYNC properly, or I won't! same story it's always been w/ HR/EVR/VMR9 etc..and it can look good for 30/45', then go nuts all of a sudden.

-mVR's anti-tearing fix disabled: if I enable Reclock's tearing test(it makes an horizontal line slowly spanning the screen), when I seek it will always look ugly until it reaches the 3/4 of the screen...and then we'll be in sync! always! and it doesn't seem to be prone to completely lose sync after 30/45 mins, so indeed there is hope. too bad it makes very strange random tearing :(

anyway, I guess you got a rough of wth is going wrong when using Reclock...and maybe you could slightly polish the "anti-tearing fix", as it seems to be a very good lead to make everything go smooth(pun intended) :thanks:

[cyberbeing]

As an experiment, I tried out playing back 23.976 video with a 95.904 refresh rate WITHOUT Reclock and dropped frames were even worse. After 5 minutes I had 7 dropped frames from around three different big stutters.

With 3DLUT disabled it was better, with only 2 dropped frames after 10 minutes. I also seem to be getting stuttering without dropped frames being reported, with and without 3DLUT, which as you mentioned, is not good.

Did you have any time to look into that Avatar sample, which also included my 3DLUT, to see why that in particular section was causing massive dropped frames? Since you did a complete re-write, I assume you re-wrote the 3DLUT handling code as well? Is is possible for that code to hang or get delayed in a way not shown by the CTRL+J Stats, and cause dropped frames?

I've also noticed that you are rounding up the VSync interval for the refresh rate. My actual 1600x1200 95.904 Hz Vsync interval is 10.427 and it gets rounded to 10.43 in the CTRL+J Stats. With 1920x1080 119.962 Hz it gets rounded from 8.336 to 8.34. Does madVR internally use the more exact VSync interval? If not, wouldn't that cause a massive skew over time? Do you take into account non-active lines (Front Porch, Back Porch, and Sync Width) or does that not even matter?

[iSeries]

Madshi,

Re. the tearing issue I get with 23/24hz refresh rates - were you able to reproduce this? I don't think I'm the only one with this problem. Without Aero I get tearing about a quarter of the way up from the bottom of the screen. With Aero I get stuttery playback. The only way MadVR works for me is to use Reclock to speed up 24p material to 25hz and set my TV to 50hz. This is with a ATI 4550.

[yesgrey]

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:
Soon I will start a new thread for discussing all 3DLUT related questions. Let's keep this thread only for madVR related questions, please.

Is there something I need to change in the output of ffdshow when I use 3dlut?
You should check only YV12 in ffdshow's output tab.

[namaiki]

Magnified 4x:
http://i39.tinypic.com/wgxo46.png Nearest Neighbour Bilinear SoftCubic 100 Lanczos 3. Saturation is fine but edges are bad in other tests; same with spline. Bicubic 75


How exactly was spline36? What do you mean by 'edges are bad?' or is it because of the ringing? Though I generally don't like bicubic. It.. it.. produces too much artifacts (too sharp? and too much ringing) for my liking.




Madshi: Any chance that you would ever consider defaulting MadVR to a spline or lanczos scaler? Though I would guess, not without a good reason..

[6233638]

How exactly was spline36? What do you mean by 'edges are bad?' or is it because of the ringing? Though I generally don't like bicubic. It.. it.. produces too much artifacts (too sharp? and too much ringing) for my liking.With spline, it's hard to describe. It looks like there's too much interpolation being done and the edges of objects are being rounded off too much. Looks like the image is being drawn with curves. (which I think is what spline is actually attempting to do?)

What I don't like about Lanczos is probably the result of ringing (I find it rings quite badly on luma, 4/8 are even worse) but it looks different when it's being done on the chroma. You can almost see it in that example actually - the red circle almost looks like it has a beveled edge when it's just supposed to be a flat red circle.

And I agree that Bicubic 75 causes too much ringing for luma. I've only set it to that for now so that luma/chroma upsampling 'matched' but I plan on changing it. Then again I always watch content at its native (luma) resolution anyway so it's not really an issue for me.

From the limited testing I did some time last year, I decided mitchell-netravali looked best for luma, but it was too taxing for my system and it was nearly impossible to do a comparison on the exact same frame. Now it should be much easier to evaluate because you can change the rendering on a paused frame.

I haven't really seen any problems with Bicubic 75 on chroma so far at least, and it definitely produced the best results in 0.11 which surprised me as I tend not to like bicubic. What I can say though is that I actually like softcubic less than bilinear; that was also surprising, considering it's often recommended here, but it just blurs things too much.

[Jong]

I prefer not to look at other people's code, but writing my own instead. This is not meant as a disrespect to other people's work, but I think it's sometimes better to start with fresh ideas. Also duplicating code from an open source project into my closed source renderer would be "bad".

I'm confident, though, that I'll be able to work out any remaining problems, sooner or later.That's fair.

If I just call "Present()" as soon as a frame is rendered, video will playback too fast, if I play e.g. a 24fps movie on a 60Hz display, the movie will play with 2.5x realtime speed. I *have* to integrate a logic into madVR which doesn't call "Present()" too often. And that means I have to time the "Present()" calls somehow.Just thinking about it, from a position of blissful ignorance, it seems understandable to me how a renderer could start playback, perform the first "present()" ASAP and then perform each subsequent one the right duration later, but without regard to vsync. That, combined with D3D/Aero is all that would be needed for Reclock vsync to work.

[Jong]

Not sure if we can draw any conclusions from that. I rather think not. If that "tearing fix" is enabled, I'm simply flushing the GPU at some points in my code. If it's disabled, I'm not doing that. That's really all there is to that option.I think you may have added the bit in italics after my original reply!

Is it possible that when refresh rate and frame rate are "compatible" (e.g. exact multiple) and depending on where in the cycle frames become available for presentation (random after each seek and drifting slowly over time, depending on how "exact" the mutiple is) this flush code might sometimes push availability one side or other of vsync?

[djsolidsnake86]

No problem at all with that video. It´s perfectly smooth here. Looks like a capture done from a VCR tape. However, by looking at the frame rate it shows 24.967fps, instead of 25.000fps for PAL video.

@6233638:
Same config here, but no reclock. I´ve tried about a hundred different files with madVR 0.12 since yesterday and it´s dead smooth (excluding the 60fps one I posted). Even the OSD shows no dropped frames (sometimes it even starts with 0), but my eyes usually are the judge here. I`ve also tested about a dozen different files from http://w6rz.net/ - even 1080p25@60Hz doesn´t drop frames.
what decoder and video player are you using?
i have this problem with mpc-hc and divx h264 decoder

[Jong]

Doing that might allow Reclock to work as intended. However, with Reclock turned off you'd actually be in danger of getting "synchronised frame rate/refresh rate judder" this way! Furthermore: If I "blindly" call Present() at a specific interval, disregarding where the scanline currently is, and if the movie framerate and display refresh rate match (e.g. 25fps for both), and if I have bad luck, I might always call Present() directly after a VSync event. Which means that Present() would practically always block, leaving no time for rendering at all. Which would result in empty rendering queues and heavy stuttering.Yes, this would only be an advanced option for users of Reclock using Aero (or exclusive mode if that became available). They could then use Reclock to position "end present" and so "start present". It would be their job to set that position in a good place for madVR. :)

[leeperry]

FWIW. the anti-tearing fix is always on in 0.12, the checkbox in the settings doesn't have any effect in 0.12.

As I said before, there's no hidden secret with the anti-tearing fix and it's not a good lead at all. You'll have to trust me on that
oh ok, well I didn't try it on 0.12 as the associated tearing was very annoying in 0.11 anyway

I'm only telling you what I see, and I can confirm that seeking with Reclock in 0.12 is still a major hit or miss, as it was in 0.11

[madshi]

Yes, this would only be an advanced option for users of Reclock using Aero (or exclusive mode if that became available). They could then use Reclock to position "end present" and so "start present". It would be their job to set that position in a good place for madVR. :)
I still don't think it would be a good idea. E.g. with Aero, the time you present has to be chosen cleverly: If you present too late, then even although it's still before the VSync, the frame will still not be shown, because Aero still needs to do some internal rendering on top of the video playback rendering. Furthermore, and more importantly: For Aero and fullscreen exclusive mode, I plan to make use of the OS internal queues. Which means that I'll present 5-8 frames in advance, by telling the OS when I want the frames to be presented and for how long. Doing so will make sure that even if rendering/presentation is interrupted, playback will still run smoothly, because at least the fullscreen exclusive mode OS queue is managed by hardware interrupts. So if I prerender 8 frames and send them to the OS queue, rendering/presentation would have to be interrupted for 8 * 40ms, before the interruption would result in noticeable stutter. If I do as you suggested, only one frame is in the OS queue at any time. So if the PC gets busy doing whatever for 40ms and doesn't allow me to render/present during that busy period, playback will stutter.

[sepheas]

hey, first ! I would like to thank madshi for his work.

On my config there's some points :

I don't know why when I use Madvr there's so much cpu usage ?

When I use Madvr with an h.264 file I have a cpu occupation of about 70%
While with haali renderer I have a cpu occupation of 30%

Why Madvr causes so much cpu usage ? He's supposed to do all the work with my graphic card ?

The result is that I must overclock my little pentium dual core (2ghz) to about 2.5ghz to play the video without stutters.

The other point is simply the stability when I start my video. Sometimes media player classic doesn't respond. Sometimes It does.... I've got a gt240 and I'm running seven.