Bug Report Sluggish video when capturing an OpenGL plugin in ePSXe

[DAOWAce]

Mentioned it in the test build thread, but it wasn't resolved by the time the stable release came out, so I'm creating a dedicated thread about it.


I'm having issues with Game Capture injected into an OpenGL rendering pipeline (or so it says).

I'm running a PSX emulator (ePSXe 1.8.0) and using a software based GPU plugin (BladeSoft) and when I attach Game Capture to it I suffer from random sluggishness, as if I'm dropping frames in my own video feed. XSplit has this issue as well, but not as bad (random as opposed to constantly).

Originally I thought it was due to the software nature of the plugin, but upon testing I found it still happens with a hardware based OpenGL plugin.

When using a DirectX plugin (DX7 I think) OBS only produces a black screen.

It also happens when taking Dxtory's output. Dxtory by itself exhibits no issues in my testing. This is what boggles my mind; why does Dxtory not cause any issues yet if either OBS or XSplit (maybe even FFsplit and FMLE) take Dxtory's output the issue appears? The broadcast program shouldn't even be affecting the source; only Dxtory should.

This is a real big issue for people running PSX emulators, as the only good GPU plugins for PSX emulators are OpenGL based. Any other alternative is very old DirectX which is lacking in features and accuracy and generally never used unless one's using a very old system and/or has issues with OpenGL.

I'm doubtful a logfile would even help; it needs to be seen in action to really be understood, but here's one anyway:

06:17:54: Open Broadcaster Software v0.541b - 32bit (´・ω・｀)
06:17:54: -------------------------------
06:17:54: CPU Name: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
06:17:54: CPU Speed: 3500MHz
06:17:54: Physical Memory:  4095MB Total, 4095MB Free
06:17:54: stepping id: 9, model 10, family 6, type 0, extmodel 1, extfamily 0, HTT 1, logical cores 8, total cores 4
06:17:54: monitor 1: pos={0, 0}, size={1920, 1200}
06:17:54: Windows Version: 6.0 Build 6002 S
06:17:54: Aero is Enabled
06:17:54: -------------------------------
06:17:54: OBS Modules:
06:17:54: Base Address     Module
06:17:54: 002C0000         OBS.exe
06:17:54: 70D30000         OBSApi.dll
06:17:54: 72FD0000         DShowPlugin.dll
06:17:54: 73010000         GraphicsCapture.dll
06:17:54: 72FB0000         NoiseGate.dll
06:17:54: 72F90000         PSVPlugin.dll
06:17:54: ------------------------------------------
06:17:54: Adapter 1
06:17:54:   Video Adapter: NVIDIA GeForce GTX 670
06:17:54:   Video Adapter Dedicated Video Memory: 2091581440
06:17:54:   Video Adapter Shared System Memory: 2147807232
06:17:54: =====Stream Start: 2013-07-12, 06:17:54===============================================
06:17:54:   Multithreaded optimizations: On
06:17:54:   Base resolution: 1280x960
06:17:54:   Output resolution: 1280x960
06:17:54: ------------------------------------------
06:17:54: Loading up D3D10...
06:17:54: Playback device Default
06:17:54: ------------------------------------------
06:17:54: Using desktop audio input: Speakers (Creative SB X-Fi)
06:17:54: ------------------------------------------
06:17:54: Using auxilary audio input: "What U Hear" (Creative SB X-Fi)
06:17:54: ------------------------------------------
06:17:54: Audio Encoding: MP3
06:17:54:     bitrate: 192
06:17:54: Using graphics capture
06:17:54: ------------------------------------------
06:17:54: Video Encoding: x264
06:17:54:     fps: 60
06:17:54:     width: 1280, height: 960
06:17:54:     preset: faster
06:17:54:     CBR: no
06:17:54:     CFR: no
06:17:54:     max bitrate: 4000
06:17:54:     buffer size: 7000
06:17:54:     quality: 10
06:17:54: ------------------------------------------
06:17:54: SharedTexCapture hooked
06:18:10: Total frames rendered: 1007, number of frames that lagged: 1 (0.10%) (it's okay for some frames to lag)
06:18:10: =====Stream End: 2013-07-12, 06:18:10=================================================
06:18:12: 
06:18:12: Profiler results:
06:18:12: 
06:18:12: ==============================================================
06:18:12: frame - [100%] [avg time: 1.69 ms (cpu time: avg 1.735 ms, total 1747.21 ms)] [avg calls per frame: 1] [children: 69.6%] [unaccounted: 30.4%]
06:18:12: | scene->Preprocess - [0.0592%] [avg time: 0.001 ms (cpu time: avg 0 ms, total 0 ms)] [avg calls per frame: 1]
06:18:12: | video encoding and uploading - [69.5%] [avg time: 1.175 ms (cpu time: avg 1.239 ms, total 1248.01 ms)] [avg calls per frame: 1] [children: 68.7%] [unaccounted: 0.828%]
06:18:12: | | CopyResource - [0.533%] [avg time: 0.009 ms (cpu time: avg 0.015 ms, total 15.6 ms)] [avg calls per frame: 0]
06:18:12: | | conversion to 4:2:0 - [0.414%] [avg time: 0.007 ms (cpu time: avg 0 ms, total 0 ms)] [avg calls per frame: 0]
06:18:12: | | call to encoder - [67.7%] [avg time: 1.144 ms (cpu time: avg 1.223 ms, total 1232.41 ms)] [avg calls per frame: 0]
06:18:12: | | sending stuff out - [0.0592%] [avg time: 0.001 ms (cpu time: avg 0 ms, total 0 ms)] [avg calls per frame: 0]
06:18:12: | Convert444Threads - [1.92e+003%] [avg time: 32.402 ms (cpu time: avg 1.239 ms, total 1248.01 ms)] [avg calls per frame: 1]
06:18:12: ==============================================================
06:18:12:

 

[Kharay]

I am using ePSXe 1.8.0 as well, running Pete's OpenGL Driver 2.9 and I have yet to see this particular issue you mention. There is nothing wrong with going OpenGL actually. Given the recent improvements to the OpenGL capture of OBS, it is in fact preferable to go with an OpenGL plugin, for best performance.

Regarding getting a black screen with a DX7 plugin -- OBS does not capture DX7 in Game Capture. It will do it with Window Capture though. Or, it should anyhow. But Game Capture will not work for DX7.

Your hardware is far superior to mine so that can't be the issue either. I would like to note one thing though, regarding the log file -- it is safest to NOT specify a custom buffer size and just leave it the same as the max bitrate. Also, Q-10 is really unnecessary and will only serve to fill that buffer. Never forget -- there is a certain degree of quality loss taking place on Twitch's end as well. Q-10 will not solve that.

Personally, I stream PSX titles in Q-7 at 3000 - 3500 Kbps and they look more than fine. Example: http://www.twitch.tv/kharay1977/b/429379410 -- Q-7, 3500 Kbps, 160 Kbps audio, downscaled by 25% (to 720p, I play it at 1600x900). Game Capture, OpenGL. Looks fine, right? No sluggishness, quality pretty damned solid.

So, go with a lower max bitrate (Twitch advices never going over 3.5Mbps anyhow), not going with a custom buffer size and reducing the quality to Q-7 at the most and see if the problem persists.

 

[DAOWAce]

You mean OpenGL2, as the original OpenGL version is 1.77. I've tried the same one.

There's a chance that it's the specific game I'm running at the time or another issue with the configuration of my plugin(s), but I've yet to go that in-depth with the testing.

Could you send me your GPU plugin settings?

As for my encoding settings: Quality freak. I'm also streaming at 60FPS, resulting in the need for more bitrate and a high buffer; the latter of which is really required to avoid compression artifacts on motion, especially sudden motion. It's not that important for 2D or games that have a lot of static scenes, which is why I'm using quality 10; high amount of static scenes.

Here's a sample PSX game: http://www.twitch.tv/daowace/b/425030326

I know my limits (though they're not without their bizarre problems like this), I know Twitch's limits, and after much testing and some researching, I've come to a set of encoding parameters I'm comfortable with.. for the most part (high lookahead seems to be ruining my stream at 1080p60 despite no problems appearing on my end). If anything, I'd really like colors preserved, as they look really washed out lately compared to last year.

Although..

Trying to stream maximum data rate of 14128 kbps...
Calculated average data rate: 13843 kbps
Dropped frames: 0
Test result: Green

Twitch seems like it can support quite high bitrates. ;p


Also, wtf? Instant killing Emerald Weapon? That makes me cry.

(I also don't agree with running old PSX games in 16:9 unless they've been widescreen modded, which I'm not sure exists for PSX emulation.. PS2 though? Definitely.)

 

[Kharay]

Twitch may be able to support high bitrates but Twitch's staff does not like you doing so. There's a post somewhere here on these forums of a Twitch staff member basically urging people not to go over 3.2 - 3.5Mbps. And I agree with him, completely.

There is very, very, very little quality improvement over 3.5Mbps, if any at all.

Anyhow, my settings:

Perfectly stable in most titles, solid framerate and leaves more than enough room for streaming.

 

[DAOWAce]

There is very, very, very little quality improvement over 3.5Mbps, if any at all.

If you're not going over 30 FPS and staying at or below 1080p, yes. The slower your preset also, the less bitrate you need.

if you're streaming anything over 30FPS, mostly at higher resolutions (though in some cases 720p45/60 can be awful too), compression artifacts can get very bad, especially if you stick to veryfast.

I've seen the post as well; they don't like people going over 3.5k; but I mainly stick to 4-5 (with a high buffer) for my content due to the compression artifacts introduced with lower bitrates. There is no way to avoid them when I cannot lower my preset without negatively affecting the game, sometimes down to unplayable levels.

I'm still experimenting with CBR, so it remains to be seen as to what bitrates are satisfactory for the type of content I put out.


Tested with those settings: It's now causing a lessened effect, down to XSplit's impact. Not great, but it's an improvement; still can't capture with either programs without issues though..

Suppose the last thing to try is a completely different game. I've only tried Valkyrie Profile so far, so I've got nothing else to compare to.

 

[Kharay]

That is so odd though, since I have not a single issue playing and capturing PSX titles. And your hardware is superior to mine. I suppose it could be the game itself that just is sluggish though, indeed. I mean, you should see Chrono Cross in ePSXe + Pete's OpenGL2. Sluggish does not begin to describe it. ;)

 

[Lain]

0.541 has an issue with GL capture on nvidia cards at the moment. It appears to be driver related, and we're trying to figure out precisely how to fix the problem. Actually it should just be a memory leak, not sluggish or anything, the new GL capture should be equivalent to directx capture which is super fast

 

[Kharay]

Well, in the example I gave of Chrono Cross, it really is the OpenGL driver for ePSXe in combination with Chrono Trigger that simply does not work out well. Because I don't even have an nVidia ánd the problem even exists without OBS even being open. ;)

As far as the OP's issue -- I suppose it could be a driver issue indeed. Which I find highly ironic. Since nVidia always was supposed to have the better support for OpenGL. Then again, back when I still had nVidia's, I did indeed have to settle for buggy drivers more than once. They can create some amazing hardware but as far as releasing proper drivers for said hardware goes, they do drop the ball more than occasionally.

 

[CIblue]

I know this thread is old, but I'm wondering if I'm having the same problems you guys are. I'm only an ePSXe user (not developer, tester, etc...). I've been trying to configure my video plugin and I'm experimenting a lag and catchup problem . It gets really slow at points and then suddenly speeds up above the normal speed as if it's suddenly catching up. Playing Medal of Honor. I have an AMD card with software optimized for OpenGL. Not using Game Capture or anything like that. The video plugin is Pete's OpenGL2 driver 2.7. I've tried configuring it to be fast, but poor quality, slow with high quality and in between. There is no change in the lag/catch up problem. The FPS remain pretty constant at about 30 (occasionally it will spike when loading a new level or something similar). I noticed some improvement in speed when I converted the BIN files to ISO and ran ISO rather than BIN, but it still has the lag/catch up issue. Any thoughts/suggestions on what it could be?