madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000261madVRbugpublic2015-03-15 12:192015-03-15 18:52
Reporter6233638 
Assigned Tomadshi 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionno change required 
Platformx64OSWindows 8.1 ProOS Version6.3 (Build 9600)
Summary0000261: FSE Present Frames in Advance creates uncorrected lip-sync errors
DescriptionThe FSE option to present several frames in advance is creating lip-sync errors equal to the number of frames presented in advance.
 
For example:
16 frames at 60 FPS = audio 266.67ms ahead of video
 4 frames at 24 FPS = audio 166.67ms ahead of video
 8 frames at 24 FPS = audio 333.33ms ahead of video
 
This only affects FSE mode with the new path. (present several frames in advance)
It does not affect any other mode. (windowed new/old/overlay, or old FSE path)
TagsNo tags attached.
madVR Version0.87.14
Media Player (with version info)JRMC 20.0.80 / MPC-HC 1.7,4
Splitter (with version info)LAV Splitter 0.64.0
Decoder (with version info)LAV Video 0.64.0
DecodingDXVA2 Copyback
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modefullscreen exclusive mode
GPU ManufacturerNVidia
GPU ModelGTX570
GPU Driver Version347.52 WHQL
Attached Files

- Relationships

-  Notes
(0000778)
6233638 (reporter)
2015-03-15 14:22

I'm not sure how, but I just realized that I said audio appears ahead of the video.
Audio is *behind* the video by x number of frames.
(0000779)
madshi (administrator)
2015-03-15 14:31

I'm kinda stumped about this report. FSE mode was largely unchanged for years. If there were such big AV sync mismatches, why has nobody noticed until now? Also the FSE mode is virtually identical to the new windowed presentation mode. Basically the new windowed presentation mode is almost identical to the "new" FSE mode which was used for years. So why would the problem occur only in FSE mode, but not in windowed mode?

I don't doubt that you're seeing these problems. I'm wondering, though, whether it could be one of the following 2 issues:

1) Maybe running the new windowed mode first, and then switching to FSE mode, could be responsible for the problem? What happens if you setup MPC-HC to start in fullscreen mode, then madVR should already start in FSE mode directly (in that case you should *not* see the "Exclusive" OSD message at all). Does the same problem still occur then? Or if you can't manage to get madVR into immediate FSE mode, does e.g. using Overlay for windowed mode change the FSE behaviour/sync?

2) It could be a driver and driver configuration issue. Do you have a chance to test a different driver version (preferable one that is relatively old)?

I mean, 8 frames in advance is not that much, if that always produced 333ms sync mismatch for everybody, wouldn't have somebody noticed by now?

P.S: Just tested an "AV sync" test video on my AMD 7770 on Windows 8.1 x64. I'm getting perfect sync in both new windowed and new FSE presentation modes here. And that is with a 16 frame GPU queue and with presentating 16 frames in advance, too. And the test video is 24p, so I should have gotten 667ms sync mismatch, but from what I can see, I'm getting around 0ms. So it's gotta be something with your driver or driver settings?
(0000781)
madshi (administrator)
2015-03-15 15:06

Tested on Intel HD4000. Same as with AMD, no problems at all. Unfortunately my NVidia GPU doesn't like my monitor via DVI/HDMI, so I can't check that atm, don't remember where I put my VGA cable...
(0000782)
6233638 (reporter)
2015-03-15 15:17

For what it's worth, I don't normally use FSE mode at all.
I normally stick to the old windowed mode for a few reasons, but I had some time spare today to try and hunt down some of the AV Sync issues I had reported recently, and this was one of the things that showed up in my testing.
 
The delay I'm seeing is indeed 667ms with a 24 FPS source and 16 frames presented in advance.
 
I've updated MPC-HC to 1.7.8, tried starting out in 24Hz and disabling the display mode switcher, starting in FSE mode and bypassing windowed mode altogether, and I still have the same delay.
(0000783)
6233638 (reporter)
2015-03-15 15:35
edited on: 2015-03-15 15:35

Downgrading my driver to 327.23 (Sep 2013) fixed it - though it was not the latest driver at fault, it fixed things because it cleared all the driver profiles out.
What should have been a per-game setting, was being applied globally for some reason.
 
The "Maximum Pre-Rendered Frames" setting in the driver being set to 1 was the cause of this.

(0000788)
madshi (administrator)
2015-03-15 18:04

Ah, makes sense. Which is the default driver setting? Hopefully it's "Use the 3D application settings"? If not, madVR users might be in trouble...
(0000789)
6233638 (reporter)
2015-03-15 18:49
edited on: 2015-03-15 18:50

The default setting is "Use the 3D application settings".
I had reduced the value to 1 for some games, since it can reduce latency when V-Sync is enabled.
But I must have accidentally set this value on the global profile as well.
It seems that only the new FSE path is affected by this.

(0000790)
madshi (administrator)
2015-03-15 18:52

That makes some sense. I think the new windowed mode, although using the same APIs, internally works quite differently (through DWM), that's why it probably isn't affected. Anyway, I guess I can close this one now.

- Issue History
Date Modified Username Field Change
2015-03-15 12:19 6233638 New Issue
2015-03-15 14:22 6233638 Note Added: 0000778
2015-03-15 14:31 madshi Note Added: 0000779
2015-03-15 15:06 madshi Note Added: 0000781
2015-03-15 15:06 madshi Assigned To => madshi
2015-03-15 15:06 madshi Status new => feedback
2015-03-15 15:17 6233638 Note Added: 0000782
2015-03-15 15:17 6233638 Status feedback => assigned
2015-03-15 15:35 6233638 Note Added: 0000783
2015-03-15 15:35 6233638 Note Edited: 0000783 View Revisions
2015-03-15 15:36 6233638 Note Added: 0000784
2015-03-15 15:36 6233638 Status assigned => resolved
2015-03-15 15:36 6233638 Resolution open => fixed
2015-03-15 18:04 madshi Note Added: 0000788
2015-03-15 18:49 6233638 Note Added: 0000789
2015-03-15 18:49 6233638 Status resolved => feedback
2015-03-15 18:49 6233638 Resolution fixed => reopened
2015-03-15 18:49 6233638 Note Deleted: 0000784
2015-03-15 18:50 6233638 Note Edited: 0000789 View Revisions
2015-03-15 18:52 madshi Note Added: 0000790
2015-03-15 18:52 madshi Status feedback => closed
2015-03-15 18:52 madshi Resolution reopened => no change required


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker