madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000103madVRbugpublic2013-07-06 23:402014-03-04 15:45
Reporterturbojet 
Assigned Tomadshi 
PrioritynormalSeverityminorReproducibilityrandom
StatusclosedResolutionno change required 
PlatformWindowsOS7OS VersionSP1
Summary0000103: empty backbuffer in window mode with frc on
DescriptionWhen another program is using the gpu the backbuffer queue randomly empties.
Steps To Reproduce1. Find the video codec of a video file at least 5 minutes long
2. Download and install lavfilters, set codec of file in step 1 to nvcuvid or quicksync through graphstudio or video player
3. Download attached and extract
4. Open Win7DSFilterTweaker > preferred decoders > set the codec of the file in step 1 to lavfilters, apply and close
5. Drag file in step 1 to x264encode.cmd, encode should start
6. Open video player with madvr rendering, disable overlay, set frc on. enable osd and pay attention to backbuffer queue and dropped frames
TagsNo tags attached.
madVR Version86.6
Media Player (with version info)mpc-be 1.2.0.3
Splitter (with version info)mpc
Decoder (with version info)ffdshow
DecodingSoftware
Deinterlacingauto mode
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modewindowed mode
GPU ManufacturerNVidia
GPU Modelgts250
GPU Driver Versionlatest whql
Attached Fileszip file icon x264encode.zip [^] (6,764,506 bytes) 2013-07-06 23:40

- Relationships

-  Notes
(0000325)
turbojet (reporter)
2013-07-29 08:18

Switching from MPC-BE/HC to PotPlayer fixed this issue. Instead of backbuffer emptying immediately the render queue drops down 2-3 frames but fills back up before it empties. Would this be a player issue or interfacing between player and madvr?
(0000435)
madshi (administrator)
2014-03-04 15:45

I'm not sure where this problem comes from, to be honest. The rendering and backbuffer filling in madVR is done in separate threads. Don't know why the media player would make a difference. And if there's enough CPU time left for madVR, x264 encoding should not be problem. However, if x264 eats a lot of CPU power, there is a chance madVR might not get enough CPU resources to run smoothly, anymore. You could try to solve this problem by giving the media player process a higher priority in the task manager. Or give the x264 encoder a lower priority.

In any case, I don't think there's much I can do here. It's mostly a matter of priorities and whether the OS gives madVR enough CPU time. So I'll close this bug for now, unless you have some thoughts/ideas on what I should do to fix this.

- Issue History
Date Modified Username Field Change
2013-07-06 23:40 turbojet New Issue
2013-07-06 23:40 turbojet File Added: x264encode.zip
2013-07-29 08:18 turbojet Note Added: 0000325
2014-03-04 15:45 madshi Note Added: 0000435
2014-03-04 15:45 madshi Status new => closed
2014-03-04 15:45 madshi Assigned To => madshi
2014-03-04 15:45 madshi Resolution open => no change required


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker