View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000103 | madVR | bug | public | 2013-07-06 23:40 | 2014-03-04 15:45 |
| Reporter | turbojet | Assigned To | madshi | ||
| Priority | normal | Severity | minor | Reproducibility | random |
| Status | closed | Resolution | no change required | ||
| Platform | Windows | OS | 7 | OS Version | SP1 |
| Summary | 0000103: empty backbuffer in window mode with frc on | ||||
| Description | When another program is using the gpu the backbuffer queue randomly empties. | ||||
| Steps To Reproduce | 1. 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 | ||||
| Tags | No tags attached. | ||||
| madVR Version | 86.6 | ||||
| Media Player (with version info) | mpc-be 1.2.0.3 | ||||
| Splitter (with version info) | mpc | ||||
| Decoder (with version info) | ffdshow | ||||
| Decoding | Software | ||||
| Deinterlacing | auto mode | ||||
| DXVA2 Scaling Active | no | ||||
| Aero / Desktop Composition | On | ||||
| Problem occurs with mode | windowed mode | ||||
| GPU Manufacturer | NVidia | ||||
| GPU Model | gts250 | ||||
| GPU Driver Version | latest whql | ||||
|
|
|
|
|
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? |
|
|
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. |
| 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 |
