madVR - high quality video renderer (GPU assisted)

[kalston]

When using nVidia drivers newer than 260.xx, I get constant presentation glitches (like thousands if I watch a 2h film) if the "use a separate device for presentation" setting is turned off. Turning it on fixes it.

With drivers </= 260.xx, I don't any glitches even when this settting is turned off. Turning it on doesn't hurt either.

And I do feel playback is smoother when I don't get any glitches (but I'm not so sure, 23.976 isn't exactly "smooth" anyway, so maybe it's placebo)

I suppose this is entirely nVidia's fault though, not yours.

Hope this hasn't been posted already, I just noticed this since I upgraded to win 7 64 and I can't use old drivers on this because custom resolutions are completely broken otherwise. On XP I used older drivers (like 258.xx or 260.xx) so I never noticed this.

[nevcairiel]

If turning the setting on fixes it, all is well, isn't it? =)

[kalston]

If turning the setting on fixes it, all is well, isn't it? =)

Absolutely!
I'm just curious, as I'm not sure what this setting does etc :p

[druneau]

I own a 6bit+Dithering TN pannel (AW2310 120hz). Everything with madvr works great.

Is there a "technically" correct setting for the "display bit depth" in the madvr device properties screen?

Should a 6bit+dithering panel be set a 8bit, 7bit or 6bit?

Thanks,

[nand chan]

If you're not sensitive to flicker, wouldn't temporal dither be better than spatial dithering? If so, I would guess 8 bit and let the panel take care of dithering - unless it bands horribly or flickers, in which case 6 bit I'd guess. I don't think there are any true 7 bit panels around.

@madshi: If using yCMS to generate a .3dlut, does it do YUV->RGB conversion still or RGB->RGB conversion? At what bit-depth are these conversions performed, and is dithering applied before or after?

Ps. Where can I find out more about the structure of .3dlut files (that madVR accepts)? I want to make my own.

[cremor]

I also own a TN LCD (BenQ XL2410T). With madVR set to 8 bit it shows a bit of banding but this is only visible on color testing patterns. Can't see any flickering from the dithering that the panel does.
With madVR set to 6 bit the flickering from the dithering is horrible, I can't watch a movie with it.

[nand chan]

I also own a TN LCD (BenQ XL2410T). With madVR set to 8 bit it shows a bit of banding but this is only visible on color testing patterns. Can't see any flickering from the dithering that the panel does.
With madVR set to 6 bit the flickering from the dithering is horrible, I can't watch a movie with it.

Your monitor probably uses different “stable” levels than madVR, so it ends up dithering every single value that madVR passes through.

[cyberbeing]

@madshi: If using yCMS to generate a .3dlut, does it do YUV->RGB conversion still or RGB->RGB conversion? At what bit-depth are these conversions performed, and is dithering applied before or after?
RGB -> RGB (for madVR)
8bit -> 16bit (for madVR)
Dithering isn't performed by the 3dlut AFAIK

Ps. Where can I find out more about the structure of .3dlut files (that madVR accepts)? I want to make my own.
http://sourceforge.net/projects/thr3dlut/

[nand chan]

RGB -> RGB (for madVR)
8bit -> 16bit (for madVR)

Huh, but then what happens with 10 bit material?

10 bit YUV 4:2:0 -> 16 bit YUV 4:4:4 -> upscaling -> conversion to RGB 16 bit -> dithering down to 8 bit RGB -> 3dLUT -> conversion to target range -> dithering down to output depth?

And thanks for the link, I'll have a look.

Edit: One thing intrigues me. The script madVR uses for generation says:

Input_Range 16 235
Output_Range 16 235

Wouldn't it be better to use 0-255 as the output range of the 3dLUT when dealing with a 0-255 display? That way, the LUT itself would have a wider dynamic range available for its calculations and would be more exact. Though I suppose the point is moot if you're using 16 bit conversions either way..

Edit 2: Started work on a .NET library to read and create .3dlut files. At the moment, it is fully capable of correctly parsing madVR's 3dlut files, but I haven't fully implemented creation or saving yet.

Regardless, WIP: http://pastebin.com/JYVATYDe

It's a bit hackish because the data can be either bytes, shorts or floats, but other than that it works fine.

[cyberbeing]

The madVR/3DLUT workflow has been odd, or rather complex, ever since 0.62 when madshi moved to RGB and offloaded various operations to shaders.

It looks something like the following with BT.709 input:

madVR:
(1) input = 8bit Y'CbCr, 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(2) convert -> 32bit float R'G'B', 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(3) convert -> 32bit float RGB, 709 primaries/gamut, linear light, WTW/BTB, D65 White Point
(4) convert -> 32bit float RGB, Display primaries/gamut, linear light, WTW/BTB, D65 White Point
(5) convert -> 32bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma, WTW/BTB, D65 White Point
3dlut:
(6) input = 8bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma (with trilinear interpolation), WTW/BTB, D65 White Point
(7) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, D65 White Point
(8) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, Display White Point
(9) convert -> 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
madVR:
(10) input = 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
(11) dither down to 8bit R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point

You'll need to use madVR <=0.61 if you want the old behavior of the 3DLUT doing everything (YUV->RGB, Gamut Correction, Gamma Correction, White Point Correction, Levels Expansion) with no shaders. I still like the old way better, for the added flexibility you get with 3DLUT creation.

[nand chan]

The madVR/3DLUT workflow has been odd, or rather complex, ever since 0.62 when madshi moved to RGB and offloaded various operations to shaders.

It looks something like the following with BT.709 input:

madVR:
(1) input = 8bit Y'CbCr, 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(2) convert -> 32bit float R'G'B', 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(3) convert -> 32bit float RGB, 709 primaries/gamut, linear light, WTW/BTB, D65 White Point
(4) convert -> 32bit float RGB, Display primaries/gamut, linear light, WTW/BTB, D65 White Point
(5) convert -> 32bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma, WTW/BTB, D65 White Point
3dlut:
(6) input = 8bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma (with trilinear interpolation), WTW/BTB, D65 White Point
(7) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, D65 White Point
(8) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, Display White Point
(9) convert -> 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
madVR:
(10) input = 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
(11) dither down to 8bit R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point

You'll need to use madVR <=0.61 if you want the old behavior of the 3DLUT doing everything (YUV->RGB, Gamut Correction, Gamma Correction, White Point Correction) with no shaders.

So when do the levels get pulled up to 0-255?

[cyberbeing]

Either in step (11) or a step (12) I believe.

[Homeless]

Is it just me, or does directvobsub not work while using madvr as a decoder?

[nevcairiel]

Is it just me, or does directvobsub not work while using madvr as a decoder?
It does not, it cannot, and it will not.
DirectVobSub needs to go between the decoder and the renderer. In madVRs case, thats no longer possible. If you need DirectVobSub, you need to use another decoder.

[Thunderbolt8]

time for madSubs then :devil:

[nand chan]

time for madSubs then :devil:

Just use MPC-HC. The internal subtitle renderer handles pretty much everything.

You shouldn't draw subs onto the video stream itself like DVS does either way, otherwise lol enjoy your blurry subs when upscaling.

Plus, DirectVobSub is so ridiculously slow it's almost a sin to use it.

[SamuriHL]

Another option is J River MC16. They built their own sub renderer that works with madVR and supports a multitude of different subtitle formats.

[Thunderbolt8]

for me its the other way round, I need to downscale and directvobsub looks much better than the subs with mpc-renderer

[THEAST]

Just use MPC-HC. The internal subtitle renderer handles pretty much everything.
That's exactly where the problem is, it handles pretty much everything, not everything, it isn't hard to break it with some advanced dynamic signs which Directvobsub plays flawlessly.
It also doesn't reflect the changes made in subs during video playback unless you restart the player which is a big downside for me who is used to editing subs while watching the video. :p

Plus, DirectVobSub is so ridiculously slow it's almost a sin to use it.
Well, since Directvobusb is multi-threaded now and pretty much everyone has quad-cores these days, I doubt speed would be an issue even when playing heavy softsubbed karaoke with Directvobsub, even at double rendering resolution.

[nevcairiel]

The code to render the subtitles used in DirectVobSub is exactly the same as the code used to render the subtitles in the MPC-HC internal renderer. The only difference is how its painted onto the video image.

DirectVobSub is also not multi-threaded.

Unless you're using some fork of DirectVobSub, and claiming its the original, of course. :p

[Thunderbolt8]

unfortunately that doesnt change the fact that the internal renderer looks WAY WORSE for me while downscaling.

http://thumbnails28.imagebam.com/14503/a144ff145020192.jpg (http://www.imagebam.com/image/a144ff145020192) http://thumbnails41.imagebam.com/14503/244e50145020255.jpg (http://www.imagebam.com/image/244e50145020255)

cant do full size screenshots with madvr ofc

[Matching_Mole]

It also doesn't reflect the changes made in subs during video playback unless you restart the player which is a big downside for me who is used to editing subs while watching the video. :p

Heuu, this is wrong. You can "reload" subtitle to load changes in subtitles file while watching a video in MPC-HC.

[Puncakes]

unfortunately that doesnt change the fact that the internal renderer looks WAY WORSE for me while downscaling.

Unless you've changed it, the default maximum sub resolution in mpc is 800x600, which means it is probably upscaling the subs. You can change it to your desktop resolution for better results.

Also, THEAST's problem is probably the subpicture buffering which has animations disabled by default. As nevcairiel said, it is the same code. Edit: Subtitle reloading can also be bound to a key for convenience.

Hope that helps.

[nand chan]

That's exactly where the problem is, it handles pretty much everything, not everything, it isn't hard to break it with some advanced dynamic signs which Directvobsub plays flawlessly.
It also doesn't reflect the changes made in subs during video playback unless you restart the player which is a big downside for me who is used to editing subs while watching the video. :p

Never come across a single anime that doesn't play back flawlessly using the internal renderer tbh. If you really want to use DirectVobSub, you can always use LAV Video as decoding instead of madVR's built in one.


Well, since Directvobusb is multi-threaded now and pretty much everyone has quad-cores these days, I doubt speed would be an issue even when playing heavy softsubbed karaoke with Directvobsub, even at double rendering resolution.

I don't know, the last time I tried using it any sort of animated subs would slow to a crawl, and that's on a Core 2 Quad Q9550 at 4.0 GHz.

cant do full size screenshots with madvr ofc

Works fine here, maybe you're doing something wrong in the first place.

[ForceX]

That's exactly where the problem is, it handles pretty much everything, not everything, it isn't hard to break it with some advanced dynamic signs which Directvobsub plays flawlessly.
It also doesn't reflect the changes made in subs during video playback unless you restart the player which is a big downside for me who is used to editing subs while watching the video. :p


Well, since Directvobusb is multi-threaded now and pretty much everyone has quad-cores these days, I doubt speed would be an issue even when playing heavy softsubbed karaoke with Directvobsub, even at double rendering resolution.
DirectVobSub, and even MPC's internal renderer is single threaded. There's a forked version which adds multithreading support: http://code.google.com/p/threaded-vsfilter/

However, DirectVobsub doesn't support 10 bit colorspaces, or even NV12. It really needs some work in the colorspace support front, especially since some other players (ZoomPlayer?) rely solely on VSfilter for subtitle rendering.

[Meowth]

Works fine here, maybe you're doing something wrong in the first place.

It doesn't work for me either. Maybe because my screen is only 1680x1050, which is dumb regardless.

[nand chan]

When using madVR in fullscreen mode on a 1920×1200 monitor using MPC-HC's internal subtitle renderer, bitmap font subtitles appear exactly 60 pixels too high (equivalent the amount of black padding at the top). When using windowed mode, the problem disappears. This happens as well if you set the maximum subtitle resolution to “1920×1080” instead of “Desktop”.

It's as if those subtitles get rendered top-bound instead of center-bound. It does not happen with any other subtitles, even ones with custom fonts - just the bitmaps.

Is this an issue with madVR or MPC-HC? It also happens using the EVR presenter.

Example: http://riff.imgur.com/

It doesn't work for me either. Maybe because my screen is only 1680x1050, which is dumb regardless.

How are you taking screenshots? Alt + PrintScreen when in fullscreen mode?

[cyberbeing]

Is this an issue with madVR or MPC-HC? It also happens using the EVR presenter.

It happens with VMR9 as well, and it doesn't happen with VSFilter with any renderer, so it's a MPC-HC subtitle filter bug.

Never come across a single anime that doesn't play back flawlessly using the internal renderer tbh.
See how easy that was ;)

[nand chan]

It happens with VMR9 as well, and it doesn't happen with VSFilter with any renderer, so it's a MPC-HC subtitle filter bug.


See how easy that was ;)

Yeah but the VSfilter renderer also ruins the image quality so that's sort of like comparing a bucket of shit with a bucket of piss (except the bucket of piss is a really minor detail that only a tiny percentage of people would even notice, eg. those with 8:5 monitors, and furthermore won't bother anybody who watches in windowed mode so I personally don't care about it either way)

Really, there's no reason to render subs onto the image itself before post processing.

But let me correct that quote. “Never come across a single anime that doesn't play back flawlessly using the internal renderer for me”

Satisfied now?

[cyberbeing]

I'm just messing with you nand chan, no reason to get so serious. :eek:

Really, there's no reason to render subs onto the image itself before post processing.
When using a 3DLUT with madVR there is at least one good reason, since MPC-HC subtitles don't get color corrected by madVR.
Typesetting like your Bakemonogatari screen and anything else which was color matched to a video would get messed up to varying degrees.

Other VSFilter advantages include:
VSFilter is a bit faster.
VSFilter-Threaded fork is orders of magnitude faster.
VSFilter has less flickering with pre-buffering and heavy subs.
VSFilter doesn't cause latency issues with the madVR Render Queue.
VSFilter doesn't depend on the video renderer or media player for subtitles to be rendered and positioned correctly.

MPC-HC's advantages include:
Can be used with madVR internal decoder.
Can render subtitles at display resolution after resize.
Can lower the resolution that subtitles render to gain extra performance at lower quality

VSFilter and the MPC-HC ISubRender interface both have their pros and cons. Which someone prefers is just a matter of their needs and personal preference.

[Superb]

When using madVR in fullscreen mode on a 1920×1200 monitor using MPC-HC's internal subtitle renderer, bitmap font subtitles appear exactly 60 pixels too high (equivalent the amount of black padding at the top). When using windowed mode, the problem disappears. This happens as well if you set the maximum subtitle resolution to “1920×1080” instead of “Desktop”.

It's as if those subtitles get rendered top-bound instead of center-bound. It does not happen with any other subtitles, even ones with custom fonts - just the bitmaps.

Is this an issue with madVR or MPC-HC? It also happens using the EVR presenter.Did you try the "Position subtitles relative to the video frame" checkbox under Options -> Default Style? It has 3 states. Default state is checked. Try them all.

[THEAST]

LOL, seems I dragged the discussion to off topic, sorry.

I had also heard that MPC-HC's internal subtitle renderer and Directvobsub are the same code but I'm pretty sure they don't behave the same, a very good example is this:

Directvobsub (Nice!):
http://i3.imgkeep.com/i/00051/6iq3sk6m4bpu.jpg

MPC-HC at windowed mode (Not aligned properly):
http://i3.imgkeep.com/i/00051/kbasdukm38iq.jpg

MPC-HC in full screen @ 1680x1050 (The only thing that is actually rendererd here is the small dot I have drawn a red circle around! ):
http://i3.imgkeep.com/i/00051/bc2w84ihyuaw.jpg

Funny thing is, the same sign renders similar to the way it renders on my machine in windowed mode, if the monitor res is 1920x1080, but the blurred parts in the sign disappear (provided by a friend, the text is different cause I edited my version):

http://sadpanda.us/images/607063-X9UFMW1.png

The sign code is the following, if anyone's interested:

Dialogue: 0,0:09:49.87,0:09:52.10,Typesetting,,0000,0000,0000,,{\bord0.2\be1\frz328.526\fnSoulEater\fs26\org(465,95)\pos(461,127)\frx22\fry46\clip(m 451 89 l 427 110 386 81 404 57 519 137 507 153 439 116 462 98 488 104 451 137 517 89)\c&H656151&\3c&H656151&}Map of the zoo
Dialogue: 0,0:09:49.87,0:09:52.10,Typesetting,,0000,0000,0000,,{\alpha99\t(0,589,\alphaFF)}{\bord0.2\be1\frz328.526\fnSoulEater\c&H584E40&\fs26\org(465,95)\pos(461,127)\frx22\fry46\clip(m 451 89 l 427 110 439 116 462 98 488 104 451 137 517 89)}Map of the zoo

I even tried PotPlayer's internal subtitle renderer, that also renders the subs in the exact same way that MPC-HC's subtitle renderer does, on my machine.

As for Directvobsub, I'm using the xhmikosr's build v2.40.3300 (which he updated to v2.40.3644 a few days ago) and I'm pretty sure it's multi-threaded. On the famous AIR OP with softsubbed karaoke, with Directvobsub set to double rendering resolution, my CPU load is 10-15% before the subs appear but jumps to 55-65% as they appear and since I have a quad-core, the load increase caused by the subs is obviously more than one core reaching 100% and another one reaching soemthing above 50% load. I never managed to play this file properly before I started using xhmikosr's Directvobsub builds.

[madshi]

On the famous AIR OP with softsubbed karaoke
Sample?

[Daiz]

One thing that has never worked properly with subtitle rendering resolution being different from the video resolution: 3D rotations. Any sign involving these (like the one THEAST posted) will get incorrectly aligned. The worse thing is that there's really no way to properly fix it either since MPC-HC doesn't have a "render subtitles at video resolution"-option.

Correct rendering of typesetting is the main reason why I keep using external VSFilter, since typesetting is always made with the video resolution (and subtitles being rendered in video resolution) in mind.

Also, another thing in regards to typesetting. The internal renderer, for whatever, doesn't seem to support the \fax and \fay tags properly. At least this is the case in the version I have right now (1.5.3.3514).

For comparison:
Correct external VSFilter rendering (http://i.imgur.com/G59Zz.jpg)
Incorrect internal VSFilter rendering (http://i.imgur.com/iaaey.jpg)

[ajp_anton]

Bug: ?
When exiting fullscreen exclusive mode, the last frame that was shown before going into fullscreen is shown for a very short time. Can you somehow get rid of this? Or just make it black or something.

[mark0077]

For those using "use D3D11 for presentation", can anyone please go into fullscreen exclusive and pause / unpause the video and report if the present queue drops to "0-1", "1-2" or similar low values after being unpaused.

This happens me in my setup, Windows 7 64bit, mpc-hc, madVR 0.73, Nvidia GTX295.

[nevcairiel]

For those using "use D3D11 for presentation", can anyone please go into fullscreen exclusive and pause / unpause the video and report if the present queue drops to "0-1", "1-2" or similar low values after being unpaused.

This happens me in my setup, Windows 7 64bit, mpc-hc, madVR 0.73, Nvidia GTX295.

It drops to 0 while being paused (both present and render do), but it goes back to its usual values after unpause.

[nand chan]

I'm just messing with you nand chan, no reason to get so serious. :eek:

My bad, 4chan has conditioned me.

When using a 3DLUT with madVR there is at least one good reason, since MPC-HC subtitles don't get color corrected by madVR.
Typesetting like your Bakemonogatari screen and anything else which was color matched to a video would get messed up to varying degrees.
It doesn't match the source material in the first place, also this seems more like a fault with the madVR renderer than the ISR - madVR should be capable of color correcting it.

Other VSFilter advantages include:
VSFilter is a bit faster.
Not here but I'll just pass it off as “I had an older version”
VSFilter-Threaded fork is orders of magnitude faster.
Interesting, but when properly prebuffering using the ISR I don't notice any impact on rendering times either way.
VSFilter has less flickering with pre-buffering and heavy subs.
Never experienced any flickering with the ISR. Demo?
VSFilter doesn't cause latency issues with the madVR Render Queue.
Wouldn't that be an issue with madVR?
VSFilter doesn't depend on the video renderer or media player for subtitles to be rendered and positioned correctly.
It comes at a cost though, ie. loss of quality.

MPC-HC's advantages include:
Can be used with madVR internal decoder.
Negligible because the internal decoder isn't all that special, as long as you have another libav decoder capable of 10-bit P010 output.
Can render subtitles at display resolution after resize.
This is, for me, honestly the real reason why ISR is so much better than VSFilter in my opinion - upscaled subs look like ass.
Can lower the resolution that subtitles render to gain extra performance at lower quality
People do this?

I still think the ISR objectively outperforms DVS simply based on the fact that it doesn't ruin the image quality, any other drawback is pretty much just bugs that need to be fixed.

Maybe once all of the mess with bitmap repositioning and color correction gets properly fixed, the ISR will finally deprecate DVS completely.

[cyberbeing]

also this seems more like a fault with the madVR renderer than the ISR - madVR should be capable of color correcting it.
madshi would need to comment on how feasible this is.

Not here but I'll just pass it off as “I had an older version”

Interesting, but when properly prebuffering using the ISR I don't notice any impact on rendering times either way.

Never experienced any flickering with the ISR. Demo?

Flickering occurs when your computer is not fast enough to render subtitles in real-time with pre-buffering disabled and/or you are buffering less sub-frames then are being rendered in a frame.
VSFilter has the same problem, but it's about 4x worse with the ISR.

How old your VSFilter build is shouldn't matter, it just depends on how fast your computer is. The faster it is, the less you'll notice subtitle bottlenecks on slow karaoke and typesetting.

Wouldn't that be an issue with madVR?
It's not, madVR has no control in how long the MPC-HC ISR takes to pass along subtitles to render.

Negligible because the internal decoder isn't all that special, as long as you have another libav decoder capable of 10-bit P010 output.
The point was the ISR can be used with decoders outputting 10bit formats (since subs can be passed to the video renderer in 8bit), while VSFilter won't accept 10bit formats.

It comes at a cost though, ie. loss of quality.
This is, for me, honestly the real reason why ISR is so much better than VSFilter in my opinion - upscaled subs look like ass.
I still think the ISR objectively outperforms DVS simply based on the fact that it doesn't ruin the image quality
I'm of the opposite opinion, I usually can't stand high-res subs on low-res video, since they stand out too much and steal the focus from the much blurrier video. As long as a thick easily readable font is used (fansubber 101), scaling is usually a non-issue. Not to mention that typesetting designed to blend into the video will often look totally out-of-place when rendered at higher resolution combined with the ISR's occasional positioning issue.


People do this?
Using the ISR (texture size of 1280x720) is my last resort after MPlayer2, when something is too slow to render at 1920x1080 with VSFilter on my slower computer.

[nand chan]

How old your VSFilter build is shouldn't matter, it just depends on how fast your computer is.
Incorrect. The older versions of VSfilter perform abysmally regardless of how fast your computer is. My computer is *not* the bottleneck here - yet the old DVS still made the video stutter on some files.

It's not, madVR has no control in how long the MPC-HC ISR takes to pass along subtitles to render.
And how does VSfilter change that, exactly?

The point was the ISR can be used with decoders outputting 10bit formats (since subs can be passed to the video renderer in 8bit), while VSFilter won't accept 10bit formats.

Well, yes.

[cyberbeing]

Incorrect. The older versions of VSfilter perform abysmally regardless of how fast your computer is. My computer is *not* the bottleneck here - yet the old DVS still made the video stutter on some files.
How old are you talking about? VSFilter hasn't had any significant performance or feature changes since 2008.

And how does VSfilter change that, exactly?
The problem just doesn't exist when VSFilter is rendering the subs.

When madVR needs to render the subs with the ISR, subtitle frames getting delivered at late or at un-even intervals can cause issues like dropped/delayed frames if VSync gets missed, since madVR has less time to do the last steps prior to presenting. Any issues VSFilter has are hidden from madVR, as long as frames are delivered slightly faster than realtime to the Decode queue. For more significant yet brief slowdowns, VSFilter also has the advantage since the Decode queue can drop to around 3/8 before causing significant issues, while the Render queue which the ISR interfaces with can begin causing issues as soon as it drops to 6/8. VSFilter is just more resilient to slowdowns in general compared to the ISR.

[Meowth]

How are you taking screenshots? Alt + PrintScreen when in fullscreen mode?

Using the built in command F5. Results in GetDIB failed, hr = 80004005 when using madVR using full screen or not. It works when I switch it to Haali though.

When using fullscreen alt + printscreen doesn't take a screenshot of what is currently displayed, only the frame that was showing as it entered full screen. And even then it stretches is up/down and shortens it length wise.
http://i.imgur.com/o8Q2I.jpg

I have found a half-assed workaround which is hitting Control, then Alt, then down arrow which pulls up a menu and puts it in full screen window mode temporarily instead of exclusive. Only then can I get a non-distorted one.
http://i.imgur.com/N4IZX.jpg

I still can't get 1080p screenshots with this method because of my monitor size which is what I want so I am forced to switch to Haali renderer or something else. So unless there is something else I don't know about I find it rather annoying.

[nand chan]

How old are you talking about? VSFilter hasn't had any significant performance or feature changes since 2008.

Stable CCCP circa 2010. I was having /significant/ trouble playing back some scenes for example the ED of Madoka episode 3 using Chihiro soft subs, as soon as subtitles kicked in video slowed to a crawl. I had the subpicture prebuffering enabled. With the ISR, this problem disappeared entirely.


When madVR needs to render the subs with the ISR, subtitle frames getting delivered at late or at un-even intervals can cause issues like dropped/delayed frames if VSync gets missed, since madVR has less time to do the last steps prior to presenting. Any issues VSFilter has are hidden from madVR, as long as frames are delivered slightly faster than realtime to the Decode queue.

ISR is also capable of presenting subtitle frames in advance though. True, if I disable the subtitle frame, decoding takes up to 16 ms, but with it enabled, decoding takes around 1.5ms for 1080p Hi10P material.

VSFilter is just more resilient to slowdowns in general compared to the ISR.

I see. Can't you just increase the render queue size in ISR?

Using the built in command F5. Results in GetDIB failed, hr = 80004005 when using madVR using full screen or not. It works when I switch it to Haali though.

When using fullscreen alt + printscreen doesn't take a screenshot of what is currently displayed, only the frame that was showing as it entered full screen. And even then it stretches is up/down and shortens it length wise.
http://i.imgur.com/o8Q2I.jpg

I have found a half-assed workaround which is hitting Control, then Alt, then down arrow which pulls up a menu and puts it in full screen window mode temporarily instead of exclusive. Only then can I get a non-distorted one.
http://i.imgur.com/N4IZX.jpg

I still can't get 1080p screenshots with this method because of my monitor size which is what I want so I am forced to switch to Haali renderer or something else. So unless there is something else I don't know about I find it rather annoying.

Is there any reason you need to use the fullscreen exclusive mode? Just disable it if you want to take a lot of screenshots. You don't need exclusive mode unless you're on XP or have Aero disabled either way.

[cyberbeing]

Stable CCCP circa 2010. I was having /significant/ trouble playing back some scenes for example the ED of Madoka episode 3 using Chihiro soft subs, as soon as subtitles kicked in video slowed to a crawl. I had the subpicture prebuffering enabled. With the ISR, this problem disappeared entirely.
Since ED karaoke was hard-subbed, I have no way of testing that.

ISR is also capable of presenting subtitle frames in advance though. True, if I disable the subtitle frame, decoding takes up to 16 ms, but with it enabled, decoding takes around 1.5ms for 1080p Hi10P material.

I see. Can't you just increase the render queue size in ISR?


I have the exact opposite experience as you, so I don't know what to say. Especially when rendering subs w/ Desktop texture size, the ISR is significantly slower than VSFilter. In the past I've also seen high CPU load increases using pre-buffering with the ISR set to Desktop texture size. On an older dual-core computer, that is a problem. On a faster computer, less so.

Increasing the buffer doesn't always fix the flickering unfortunately, since the pre-buffering implementation is flawed. Unless your computer is fast enough to render all subtitles without pre-buffering, while leaving some head-room, the pre-buffer has the chance of causing flickering issues. Pre-buffering can sometimes give a speed boost, but other times I need to disable it, since the increased CPU load can become a problem.

What it really comes down to, is with an older dual-core CPU you can't reliably take advantage of using the ISR with Desktop texture size and pre-buffering. Even a Core i7 will choke on complex enough subs with the ISR or VSFilter. MPlayer2 and now the threaded VSFilter fork become your only options in some cases.

[misha0209]

Hi,

do not know if someone reported this (probably has, but i do not have time to red through the thread). i am using the latest madvr, with the latest MPC HC and ffdshow. if i watch a video with ordered chapters (anime, where the OP and ED are separate files from the original episode - mkv) when the treansition from the main video to op or ed should be made MPC HC crashes. this only happens if i use madvr, that's why i'm posting here :P

i also have a question. how well does madvr perform on synchronization of video framerate to monitor framerate? to my eyes EVR Sync is a bit better then EVR CP. does madvr outperform EVR Sync? a small graph like in the case of the 2 EVR renders would be greatly appreciated!

[THEAST]

Sample?
The file can be found in pretty much every "How to play anime with DXVA" guide out there, you can find the file here (http://www.filesonic.com/file/11998573/Lia_-_Tori_no_Uta_long_version.mkv), borrowed from this guide (http://imouto.my/watching-h264-videos-using-dxva/comment-page-142/). Though I wonder when people are gonna understand that the subs are the cause of the problem in that video, not the video itself, and DXVA isn't exactly gonna help in rendering the subs.

BTW, can you please have a look at the issue I reported at the top of the page 461? :thanks:

[Thunderbolt8]

might be better to refer to post numbers, as people have different options how many posts per side they like to have. in my case for example, this thread only has 232 pages so far.

[nand chan]

Since ED karaoke was hard-subbed, I have no way of testing that.

I was using the coalgirls release for reference.

I have the exact opposite experience as you, so I don't know what to say. Especially when rendering subs w/ Desktop texture size, the ISR is significantly slower than VSFilter. In the past I've also seen high CPU load increases using pre-buffering with the ISR set to Desktop texture size. On an older dual-core computer, that is a problem. On a faster computer, less so.

Increasing the buffer doesn't always fix the flickering unfortunately, since the pre-buffering implementation is flawed. Unless your computer is fast enough to render all subtitles without pre-buffering, while leaving some head-room, the pre-buffer has the chance of causing flickering issues. Pre-buffering can sometimes give a speed boost, but other times I need to disable it, since the increased CPU load can become a problem.

What it really comes down to, is with an older dual-core CPU you can't reliably take advantage of using the ISR with Desktop texture size and pre-buffering. Even a Core i7 will choke on complex enough subs with the ISR or VSFilter. MPlayer2 and now the threaded VSFilter fork become your only options in some cases.

It sounds like we need to push for MPC-HC to add multi-threading to the ISR and the world will be perfect. Example of complex enough subs? I want something to benchmark with because basically anything will render fine performance-wise for me atm using libav + ISR.

(The horrendous video slowdown I mentioned earlier was while using an older build of ffdshow to CPU decode + upscale to 1080p (again using the CPU) and also had some fullscreen CPU filters enabled - this plus VSFilter running on the CPU. It was at that point in time that I realized I could not continue using my set up the way it was and decided to delete fucking everything + research modern playback solutions)

Ps. Oh god that Tori no Uta long version test file.. I've literally played it back hundreds of times by now testing various configurations. >.<

Some stats: ~25% average CPU load during playback before subtitles, averaged out over 4 cores (each are at about 25% themselves)
~40% average CPU load during playback with subtitles using the ISR. Interestingly enough, the load increased to about 50% on 3 cores (the 4th stayed at ~20% ish) - so it averages out to about 40%.

Playback with subs fluctuates between about 35% and 45%, depending on keyframes etc. There was a short spike on the very first subtitle where CPU jumped to 50% as the ISR pre-buffered a total of 16 sub-pictures. (Seems like it doesn't buffer before that) Also, the madVR OSD didn't report a change in rendering times. Not even a slight one. Was at exactly 2.3 ms before and during subtitles.

Neither core exceeded 50% load during playback, so that's not even close to saturation and proper multi-threading could improve this further.

Tests were on a Q9550 (stock 2.8 GHz) currently downclocked to about 3.4 GHz, nominally at about 4.0 GHz.

[madshi]

One thing that has never worked properly with subtitle rendering resolution being different from the video resolution: 3D rotations.
Can I have a video sample with such a 3D rotation, too, which doesn't look right with the internal MPC-HC subtitle renderer?

[THEAST]

might be better to refer to post numbers, as people have different options how many posts per side they like to have. in my case for example, this thread only has 232 pages so far.

Post #9201! :)

Some stats: ~25% average CPU load during playback before subtitles, averaged out over 4 cores (each are at about 25% themselves)
~40% average CPU load during playback with subtitles using the ISR. Interestingly enough, the load increased to about 50% on 3 cores (the 4th stayed at ~20% ish) - so it averages out to about 40%.
Try with Directvobsub and double rendering resolution, that'll put all your CPU cores to use. ;)