madshi bug tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000129madVRbugpublic2013-10-03 09:512014-04-03 09:23
ReporterRyrynz 
Assigned Tomadshi 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionunable to reproduce 
PlatformWindowsOS7/8OS VersionAll
Summary0000129: Delay when CPU is taxed (Using Avisynth) when next file is loaded when new exclusive mode is enabled
DescriptionI have a reasonably demanding Avisynth script I run which has my CPU generally working at around 30-50%, when my video finishes and MPC loads the next file in the playlist or folder I have a 1 second odd cut from the start of my next video. Disabling one of my major CPU consuming filters fixes the issue showing that it's only an issue when a high CPU usage scenario is in play.

Unticking 'present frames in advance' fixes the issue, surprisingly delaying full screen exclusive for 3 seconds doesn't work as judging from the OSD exclusive is enabled automatically when the next file plays (another bug?)
All other renderers have no delay issues with all filters enabled.

The following options were tried and had no impact.
- changing the frames displayed in advance
- changing the CPU and GPU queues
- delaying playback until the render queue is full

So it would appear to be only an issue with the new rendering path.
Steps To ReproduceIntroduce high CPU load during playback, let playback finish and progress to the next file.
TagsNo tags attached.
madVR Version0.86.10
Media Player (with version info)BE x32 3420
Splitter (with version info)LAV 0.58.2
Decoder (with version info)LAV 0.58.2
DecodingSoftware
Deinterlacingnone (progressive)
DXVA2 Scaling Activeno
Aero / Desktop CompositionOn
Problem occurs with modefullscreen exclusive mode
GPU ManufacturerIntel
GPU ModelHD 4000
GPU Driver Version9.18.10.3234
Attached Filesrar file icon madVR - log.rar [^] (435,731 bytes) 2014-04-02 02:44

- Relationships

-  Notes
(0000343)
Ryrynz (reporter)
2013-10-04 10:23

New deband test build exhibits the same issue, just to clarify further with what I'm seeing, audio plays for half second or so (no picture is displayed) then audio stops for a second and then picture and audio then play normally.
(0000551)
madshi (administrator)
2014-04-01 19:44
edited on: 2014-04-01 19:45

Could you please double check whether the problem still occurs with v0.87.8? This is a difficult problem for me to reproduce because my CPU is very very fast. If the problem still occurs with v0.87.8, a debug log might help. Ideally with the "delay until render queues are full" option enabled.

(0000557)
Ryrynz (reporter)
2014-04-02 02:44

Still occurring with 0.87.8b, The amount of frames presented in advance has an effect on this too, the smaller the better. I haven't been able to reproduce the starting stopping and starting of the audio as in my first note, it's simply a half second or so cut of the audio I assume it's the video frames too.
Unticking 'present frames in advance' still fixes the issue. I have produced a log.
(0000569)
madshi (administrator)
2014-04-02 22:20

According to the log in the moment when the new file is loaded, it takes 3.5 seconds for the media player to do anything. Then it takes another 3 seconds until the first frame is decoded and sent to madVR. So basically it takes 6.5 seconds before madVR even has a chance to do anything. After that is takes less than a second for madVR to display the first frame. So the majority of the delay seems to be outside of madVR's control. I've no idea why this would only occur with the new FSE mode and not with the old one, though. In any case, the log doesn't indicate any problem inside of madVR. So at the moment I've no clue what to do. Could be that Direct3D itself or the GPU driver gets stuck somewhere with the new FSE mode, when the CPU is so busy. Doesn't seem to be madVR's fault, from what I can see...
(0000570)
Ryrynz (reporter)
2014-04-03 01:05

I guess if there's no workarounds using the new FSE mode then you can probably close it, just one of those things.

- Issue History
Date Modified Username Field Change
2013-10-03 09:51 Ryrynz New Issue
2013-10-04 10:23 Ryrynz Note Added: 0000343
2014-04-01 19:44 madshi Note Added: 0000551
2014-04-01 19:44 madshi Assigned To => madshi
2014-04-01 19:44 madshi Status new => feedback
2014-04-01 19:45 madshi Note Edited: 0000551 View Revisions
2014-04-02 02:44 Ryrynz File Added: madVR - log.rar
2014-04-02 02:44 Ryrynz Note Added: 0000557
2014-04-02 02:44 Ryrynz Status feedback => assigned
2014-04-02 22:20 madshi Note Added: 0000569
2014-04-02 22:20 madshi Status assigned => feedback
2014-04-03 01:05 Ryrynz Note Added: 0000570
2014-04-03 01:05 Ryrynz Status feedback => assigned
2014-04-03 09:23 madshi Status assigned => closed
2014-04-03 09:23 madshi Resolution open => unable to reproduce


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker