View Issue Details

IDProjectCategoryView StatusLast Update
0000274madVRbugpublic2018-01-16 17:29
Reporterhuhn Assigned Tomadshi  
Status closedResolutionduplicate 
Platformx64OSwindows 10OS Version10041
Summary0000274: 3D LUT 23 hz SM speed up issue.
Descriptionplay back can be speed up a lot. playing a 59p file a 23 hz with enabled SM when a 3D LUT is loaded. audio plays normally. at some point the picture freeze and plays again when audio catches up this can take up to 40 sec.

took me some time to find out the trigger is the 3d LUT because it doesn't make any sense to me...
Steps To Reproducereset madVR to defaults
check SM
load a BT 709 3d LUT
set your TV to 23 hz
start a 59p video
see a 80 % chance for a huge speed up for ~0.5-40 sec

i tried this without loading a 3d LUT it really doesn't trigger the bug without it.
Additional Informationi can trigger speed up with other way by enabling deinterlacing for example but this is the easiest way to reproduce this issue.

alternative way to trigger this issue is to load the 3d LUT in playback.
TagsNo tags attached.
madVR Version0.87.15
Media Player (with version info)mpc-hc
Splitter (with version info)lav 0.64.0
Decoder (with version info)lav 0.64.0
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerAMD
GPU Modelr9 270
GPU Driver Version15.3 beta


duplicate of 0000177 assignedmadshi playback to fast when exclusive fullscreen and SM is used with a 120 fps file on a 60 fps screen. 



2015-03-30 21:46


madVR - (2,381,296 bytes)


2015-03-30 23:15

administrator   ~0000898

I can't seem to reproduce the issue on my PC, at least not with your 3dlut and movie file, with my custom madVR settings. Can you reproduce the issue if you reset madVR to default settings? Does the "delay playback" option help?


2015-03-31 00:02

reporter   ~0000899

it double tested it from reseted settings. and i just reproduce this again.
I'm unable to reproduce this with the "delay playback" option at least at video start.

another way to trigger this speed up is this:
reset madVR to defaults
check SM
load a BT 709 3d LUT
set your TV to 23 hz
start a 59p video
press control + shift + alt + t to enter deinterlacing mode

this happen when i want to switch to decimate mode i have to switch first to deinterlacing.

next easy way to reproduce this is this:
reset madVR to defaults
check SM
set your TV to 23 hz
start a 59p video
load a BT 709 3d LUT

you can switch to "disable calibration controls for this display" and back to 3D LUT to retrigger this issue.

a low refresh rate like 23 hz is a must have setting to trigger this.


2015-03-31 09:56

administrator   ~0000902

Is this a new problem with v0.87.15? Or does it occur with v0.87.14, too?


2015-03-31 10:37

reporter   ~0000903

was there in 87.14 too and it maybe an old problem. i found this by reproducing a decimation issue in 87.14. i found a way to easily reproduce this from reseted settings.

here is another speed up issue with a not realistic source and a different way to trigger it:
i don't know if they have something to do with each other but issue 177 is not a huge deal at all. but if i think about it now I'm pretty sure i used a 3D LUT back there too.


2015-03-31 10:58

administrator   ~0000904

Ok, thanks, will have a look at this, but probably not too soon. I'd suggest to enable the "delay playback start" option for now to work around the issue.


2018-01-14 19:52

administrator   ~0002094

Hmmmm... Reading through the old reports, I'm wondering if this isn't a duplicate of 0000177? Both seem to have the same cause (GPU too slow) and end result (playback too fast), and both seem to happen only when using Smooth Motion with a video file that has a much higher FPS than the refresh rate.

What do you think?


2018-01-14 23:04

reporter   ~0002107

the one talks about FSE the other about just about "playback".
they have in common a SM, HFR(higher than refreshrate) and maybe the 3D LUT.
so they are not trigged the same but the core issue should be the same.

and no the GPU is not to slow for both cases. even through your logs may say so. if the speed up doesn't trigger the file will work perfectly.

i was never able to trigger this issue with "delay playback start" enabled. at least as i can remember and i reproduce a speed up issue a couple of month a ago but i will try to do it again.

i'm pretty sure i have the same 59p file with 3:2 cadence.


2018-01-14 23:25

reporter   ~0002108

still the same issue.
i just took the 120 HZ file. i guess it is easier to trigger with it.

reset madVR to defualt
load a 3D LUT
enable SM
set your playback device to 60 Hz.
play a 120 hz file.
optional: set chroma to bilinear
the file is played as fast as possible (hardware decoder make this really entertaining)


2018-01-14 23:31

administrator   ~0002109

Last edited: 2018-01-14 23:31

Can you upload that 120fps file, please? And it occurs only with a 3DLUT but not without?


2018-01-15 00:05

reporter   ~0002116

i need a 3D LUT and SM or nothing will happen.

i will upload the file tomorrow.


2018-01-15 00:46

reporter   ~0002118

i reproduce the issue on a UHD screen at 60 HZ
mpc-hc 64
3d lut
bilinear chroma
and a double click on the file.


2018-01-15 19:41

reporter   ~0002128

i uploaded the file yesterday in case you missed it.


2018-01-15 19:43

administrator   ~0002129



2018-01-16 17:29

administrator   ~0002139

I can reproduce the issue without FSE mode and without a 3DLUT. This is definitely the same issue as 0000177. So I'm going to close this bug report, but keep 0000177 open.

Issue History

Date Modified Username Field Change
2015-03-30 21:45 huhn New Issue
2015-03-30 21:46 huhn File Added: madVR -
2015-03-30 23:15 madshi Note Added: 0000898
2015-03-30 23:15 madshi Assigned To => madshi
2015-03-30 23:15 madshi Status new => feedback
2015-03-31 00:02 huhn Note Added: 0000899
2015-03-31 00:02 huhn Status feedback => assigned
2015-03-31 09:56 madshi Note Added: 0000902
2015-03-31 09:56 madshi Status assigned => feedback
2015-03-31 10:37 huhn Note Added: 0000903
2015-03-31 10:37 huhn Status feedback => assigned
2015-03-31 10:58 madshi Note Added: 0000904
2015-03-31 10:59 madshi Status assigned => acknowledged
2018-01-14 19:52 madshi Note Added: 0002094
2018-01-14 19:53 madshi Status acknowledged => feedback
2018-01-14 23:04 huhn Note Added: 0002107
2018-01-14 23:04 huhn Status feedback => assigned
2018-01-14 23:25 huhn Note Added: 0002108
2018-01-14 23:31 madshi Note Added: 0002109
2018-01-14 23:31 madshi Note Edited: 0002109
2018-01-14 23:53 madshi Status assigned => feedback
2018-01-15 00:05 huhn Note Added: 0002116
2018-01-15 00:05 huhn Status feedback => assigned
2018-01-15 00:46 huhn Note Added: 0002118
2018-01-15 19:41 huhn Note Added: 0002128
2018-01-15 19:43 madshi Note Added: 0002129
2018-01-16 17:29 madshi Note Added: 0002139
2018-01-16 17:29 madshi Relationship added duplicate of 0000177
2018-01-16 17:29 madshi Status assigned => closed
2018-01-16 17:29 madshi Resolution open => duplicate