60 FPS glitch

[Da-Sud]

This has been brought up by others, but I wanted to bring this issue up on the radar again in the hopes that we can get a fix.

First, my system specs:

CPU: Unlocked Quad Core i7 2600K @ 3.4ghz OCed stable to 4.4ghz (thermaltake frio)
Mobo: MSI P67A-G43
Ram: Corsair Vengeance DDR3 OCed to 1866ghz
GPU: XFX Radeon 6950
Capture Source: Tried both XSplit screen capture and DXTory
Net Connection: 100 down 5 up


In short, my computer and net connection are fully loaded and ready to go, so there shouldn't be any difficulties, resource wise, for casting at 60 fps. Unfortunately, though, there appears to be an issue that others have encountered where XSplit chokes for some reason at 60 FPS. 45 FPS works fine.

A great example I found of this can be viewed here: http://www.twitch.tv/floatingthru/b/292037586

This guy's movie starts out smooth, then arbitrarily starts chopping out. Does anyone know of a workaround short of "don't use 60 fps"?

[Superroach]

Hi Da-sud, nice game choice

due to the game being so oold this is an excellent choice for testing high fps stuff.
How far in did it start chopping out? I'm nooticing pause for example in the 40-50 second range, which after that become frequent. With that example stream, how was that captured? I think it may be screen region, as unreal is likely dx7/8 and I don't know if gamesource will pick that up.

One of the developers might help if they could answer this one?
- Low cpu intensive game
- 60 fps capture on a machine that can handle it according to the guide (max approx rate is 180fps doing nothing else via looking up that cpu on the guide)
- Pauses which show symptoms of dropping frames before catching up to actual ingame action.

[Da-Sud]

Heya Superroach.

I got some really nice test data for you to work with, if you want.

First, to explain the setup that I'm using, I'm using XSplit in tandem with another program called DXTory. Basically, what DXTory is is an optimized version of the gamesource feature you guys are trying to implement right now. The nice thing about it is that it is very efficient, and takes far less resources than both XSplit's screen cap and game source cap.

How it gets used in tandem with XSplit is that it records the screen data to a virtual camera, so XSplit treats it like any standard webcam source, so you just plug it in, and there you go.

Anyhow, I was playing some SNES games on ZSNES. ZSNES is very light on processor load, and the capture wasn't a full 1080p window, so that also makes CPU load lighter. I was casting at 720p, quality setting 10, 55 FPS, and I was receiving results consistent to the video linked in my original post.

Checking the bitrate, the highest I really saw it go is 2500. I tried XSplit bitrates inbetween 3500-4500 and no tweaking of that setting helped.

So, here is the test data!

1. http://www.justin.tv/da_sud/b/292507471 - starts slightly jittery, but you can see right off the bat when it's going at full 55 fps. It then degrades into really choppy gameplay. Note that none of the chop was visible in game, implying the bottleneck here isn't my CPU.

2. http://www.justin.tv/da_sud/b/292525632 - title screen there is full 55 fps. Then a few seconds in it gets jittery, with patches here and there of full 55 fps.

As I said, the highest bitrate I saw in Xsplit's red text was 2500, meaning there should still be room for 1000-1500 more, so I guess internet would be the most likely, however I've not really experienced issues with 30 fps, and internet diagnostics haven't really shown any issues as far as packet loss or latency goes.

Any insight, or do you need any kind of info from me? Thanks!

[Da-Sud]

Update: I have duplicated the exact same choppiness offline with a local recording. Looks exactly like the chop from the online videos. I think this pretty much confirms the existence of a glitch somewhere in XSplit, considering my rig and the elimination of the internet connection.

I can send you the FLV for testing if you'd like, and if I can be useful in some other manner, let me know.

Edit: for the sake of completeness, I tested both the DXTory source and the XSplit screen capture functionality. Both result in the same chop.

[TechnicalMonkey]

You made sure that when you did this, it was a brand new presentation with no other sources added to any scene switch?

[Da-Sud]

That is correct, the only scene with anything populated in it is scene 1, and it only had either the screen capture area, or the DXTory camera source.

[TechnicalMonkey]

Okay... I was really hoping not to say this as I wanted to see XSplit switcher perform well with the sandybridge, but it looks like you are like the rest of us. Many of us high performance streamer tried to get back the 60fps performance this used to have until only a few builds ago, but it looks like it really is gone for good I hope that the devs would reconsider allowing much older builds back into the mix. They put too much stuff in the switcher like titles and other Flash stuff. The images and the videos were plenty. The most I can get out of switching is 58fps only and that is after changing priorities and affinities, which you can try to experiment with. If you try experimenting with Task Manager or Process explorer keep these things in mind:

1. XSplit likes using a single core when it comes to single source capturing, but when you use more options more cores are needed. That means sound and cameras are extra sources as well. I'm hoping that following these point will allow you to perform well even under a single core affinity *

2. If you are going to broadcast, set xsplit.core.exe to use all of the cores. This is done because VHMultiwriter.exe and ...ext2.exe are both multithreaded (mainly because of X264,) and need to be started because it will be a child process of xsplit.core.exe. You can set the affinity after the stream has started to correct this.*

3. Set xsplit.core.exe to realtime or at least high. With your computer you should be able to handle this task with no problems.

4. To really make sure that xsplit.core.exe does not get affected by other processes, set the affinity of the other processes off of the single CPU setting. example if you have xsplit.core.exe on CPU0 all other processes can be put on CPU2-CPU7*

*You have a i7 2600k, but Hyperthreading is useless for xsplit.core.exe. CPU0-7 is Physical core, then Logical core (HT.) If you really want to make this easier on yourself, disable Hyperthreading. Otherwise, CPU0 for xsplit.core.exe and CPU2-7 for everything else (CPU1 is Hyperthreading for CPU0 no used otherwise. I'm banking on your i7 sandybridge at the OC speed will allow things to work normally again.

By the way, could you help me with DXTory? I hear nothing but great things about it including that it is much better than game source. I can't get it to work for the life of me. I don't want to record with it. I just want to stream with it.

[Da-Sud]

Good info technicalmonkey. I'll try out the different settings you've suggested and see what works. Thankfully I can use offline recordings as a test case and see what, if anything, alleviates the problem.

I would really like to see some developer presence as to this problem. I've got an invested interest in Xsplit succeeding as I've already prepaid for it, and I would hate to be forced into using the garbage product that is FME to get a performance stream going. As it is, these workarounds defeat the purpose of "easy streaming" that XSplit is intended to do.

I can help you for sure with DXtory. What do you need to know?

[TechnicalMonkey]

The fact that Flash Media Live Encoder doesn't have an x264 plug-in is what holds it back. I would otherwise settle for using SCFH DSF as a means of capturing and layouts, and settle on using FMLECMD.EXE.

Till then, this is still the best out there (wirecast don't like 60fps as much as you tell them to do it.) I can't wait for your results (baited breath here.), but in the mean time I'll PM you or just start a thread on help with DXTory with XSplit. I've known about it for months and have been reserved about trying it out (ExKoder is better at japanese than english, but he does mean well. Support...) To think that XSplit used to work well at 60fps. What a shame

EDIT: On a side note I figured out what I didn't do I was supposed to hit F12, but I think under just DirectShow, this feature should be automatic.

[Da-Sud]

haha yeah, exkoder's grasp of english is oil coated at best

good to see you got that figured out, basically it's like fraps, though I do think there is an automatic feature in one of the checkboxes

make sure if you don't want it writing to your hard drives you make the output DirectShow output and not file output in the movie tab, that will get it outputting to a virtual camera instead of a file

[Slayer]

In my experience XSplit chokes if the bitrate goes above 2500kbps in any circumstance. Casting in 1080p/30fps or 720p/60fps does this. This is something with XSplit because I can cast with those settings at 6000kbps+ in Flash Media Encoder just fine.

[Da-Sud]

After doing tests with different affinities and priorities on the processor, and doing a test with FME that was more or less successful, I believe that Slayer is correct in his statement.

This would coincide with my passive observations that I've never really seen xsplit go past 2500-2700 kbps while recording.

I did a test stream with FME at 4200 kbps at 60 fps and got results that were correct - the footage was 60 fps, without any huge jitters like XSplit has. Here is a sample video I recorded from the FME footage: http://www.justin.tv/da_sud/b/292789517

As far as the gameplay goes, there was a little bit of fps hitching here and there, but that can be attributed to the fact that FME is horribly optimized and somehow even manages to create CPU chop on an i7 2600k. This hitching doesn't occur doing an XSplit cast.

I do think we've isolated what's wrong here. I really, really don't want to be forced into using FME, it's awful :/ - I hope that it is a small bug or glitch, and not something huge in the framework of the software that requires hours of coding to fix.

[Da-Sud]

Here is a stream I did with FME at 4400 kbps, 60 fps: http://www.justin.tv/da_sud/b/292847439

This more or less demonstrates as full a load on my PC as it can get, as it's L4D2 (fairly cpu intensive game), and full screen capture. Really good footage, so I'm just putting this up there as extra evidence there is a problem with XSplit.

[mikebaker]

This has been brought up by others, but I wanted to bring this issue up on the radar again in the hopes that we can get a fix.

First, my system specs:

CPU: Unlocked Quad Core i7 2600K @ 3.4ghz OCed stable to 4.4ghz (thermaltake frio)
Mobo: MSI P67A-G43
Ram: Corsair Vengeance DDR3 OCed to 1866ghz
GPU: XFX Radeon 6950
Capture Source: Tried both XSplit screen capture and DXTory
Net Connection: 100 down 5 up


In short, my computer and net connection are fully loaded and ready to go, so there shouldn't be any difficulties, resource wise, for casting at 60 fps. Unfortunately, though, there appears to be an issue that others have encountered where XSplit chokes for some reason at 60 FPS. 45 FPS works fine.

A great example I found of this can be viewed here: http://www.twitch.tv/floatingthru/b/292037586

This guy's movie starts out smooth, then arbitrarily starts chopping out. Does anyone know of a workaround short of "don't use 60 fps"?

Are you using Windows 7 WITHOUT Aero theme. With Aero theme its not possible to capture with very high FPS when using screen capture, so the screen source input to the mixer would never even reach 60 FPS (Probably not even 30). But if you use basic mode you should not have a problem. If you do, then try to upload a local recording of your stream - always try to use "automatically record broadcast" so you can see if any problems are there on your local copy. Providing a copy of your CDN recording is not really useful , your local recording will give much more information.

So if you broadcast to Justin then turn on "automatically record broadcast" in the channel settings and let's see the result of the local recording copy. Remember to note the size of capture area (1080 P should not be a problem) , but it is still important to note.

For future reference you may also want to look at this post:
viewtopic.php?f=13&t=1009&start=30#p6026

viewtopic.php?f=13&t=1009&start=30#p6026

[Trance]

Okay... I was really hoping not to say this as I wanted to see XSplit switcher perform well with the sandybridge, but it looks like you are like the rest of us. Many of us high performance streamer tried to get back the 60fps performance this used to have until only a few builds ago, but it looks like it really is gone for good .

I beg to differ. I just tried 4 different games with 60fps and they all worked flaweless.

Here are my specs:

i7 2600k OC'ed to 4.5Ghz
Asus P8P67 Deluxe
8 GB G.SKILL Ripjaws X 2133mhz
Radeon 6990

Here are the XSplit settings i used:

XSplit screencapture (games were in window mode, 1600x900 rezolution)
Aero off
FPS: 60
Output rezolution: 720p
Preset: Xsplit default
quality: 9
bitrate: 3000
vbv buffer: 6000
optimize for motion picture and optimize text resize disabled
Audio: mp3, 44.100, 128000

Game tests:

Quake-live: http://www.twitch.tv/leveluptv3/b/292890862
Need for Speed Shift 2: http://www.twitch.tv/leveluptv3/b/292891477
Battlefield Bad Company 2: http://www.twitch.tv/leveluptv3/b/292892338
Counter-Strike 1.6: http://www.twitch.tv/leveluptv3/b/292892963

So 60fps is still very much possible, and I'm using it quite often for our Quake Live streams. I don't understand why some people with similar hardware experience these issues, but there must be something specific in each of these cases, right? I hope this helps a bit in troubleshooting your problems.

[Da-Sud]

Are you using Windows 7 WITHOUT Aero theme. With Aero theme its not possible to capture with very high FPS when using screen capture, so the screen source input to the mixer would never even reach 60 FPS (Probably not even 30). But if you use basic mode you should not have a problem. If you do, then try to upload a local recording of your stream - always try to use "automatically record broadcast" so you can see if any problems are there on your local copy. Providing a copy of your CDN recording is not really useful , your local recording will give much more information.

Hi Mike,

The default behavior of XSplit is to disable the aero theme when it is run, and I haven't turned that option off, so all capture tests are indeed with Aero off. I don't know if the Aero theme is something that is related to XSplit, however, FME has no issues capturing at 60 fps with Aero enabled (and I've been casting all this week with no issues using it).

Also keep in mind I'm using a capture program that acts as a virtual camera, so the Aero thing may or may not be a factor in this. I do know, though, with Aero off, and using XSplit's native screen capture functionality, the results are the same.

I beg to differ. I just tried 4 different games with 60fps and they all worked flaweless.

Would you be willing to try an offline test with a bitrate of 4500-5000, just to see if the choking starts, say, sometime past the 3000s?

[TechnicalMonkey]

Okay... I was really hoping not to say this as I wanted to see XSplit switcher perform well with the sandybridge, but it looks like you are like the rest of us. Many of us high performance streamer tried to get back the 60fps performance this used to have until only a few builds ago, but it looks like it really is gone for good .

I beg to differ. I just tried 4 different games with 60fps and they all worked flaweless.

Here are my specs:

i7 2600k OC'ed to 4.5Ghz
Asus P8P67 Deluxe
8 GB G.SKILL Ripjaws X 2133mhz
Radeon 6990

Here are the XSplit settings i used:

XSplit screencapture (games were in window mode, 1600x900 rezolution)
Aero off
FPS: 60
Output rezolution: 720p
Preset: Xsplit default
quality: 9
bitrate: 3000
vbv buffer: 6000
optimize for motion picture and optimize text resize disabled
Audio: mp3, 44.100, 128000

Game tests:

Quake-live: http://www.twitch.tv/leveluptv3/b/292890862
Need for Speed Shift 2: http://www.twitch.tv/leveluptv3/b/292891477
Battlefield Bad Company 2: http://www.twitch.tv/leveluptv3/b/292892338
Counter-Strike 1.6: http://www.twitch.tv/leveluptv3/b/292892963

So 60fps is still very much possible, and I'm using it quite often for our Quake Live streams. I don't understand why some people with similar hardware experience these issues, but there must be something specific in each of these cases, right? I hope this helps a bit in troubleshooting your problems.

I've actually tested your videos, and you do get actual input frame drops. During Bad Company 2, and only when you started to reliably have 60fps in your actual play, the input started dropping out. It's not to say that the encoder is the problem, but the input to the encoder (vhmultiwriter) is causing the video to drop out. Counter-Strike while it shows that the game can hold up well enough, does not stress the video switcher (xsplit.core)at all. Even with the slower update on Need for Speed you still had the occasional drop.

My point is that long ago drops like this NEVER happened! I could run my 920 at stock and I would not get drops like this. I have to keep dropping down the frame rate so that it can be stable, which means not a single drop if it's 13 seconds or 13 hours. If there was a way to use VHMulitwriter the same way as FMLECMD, I would not hesitate in using that with SCFH DSF. The devs don't seem to take kindly to this suggestion even though it is part of the EULA to be able to use VHMultiwriter in command line.

Bottom line is that you need ridiculous amounts of speed just to run the switcher at 60fps. Are we supposed to look forward to IvyBridge Xeons with 2 QPIs for 100% stable 60fps performance?!? What will it take?!?

[Melvin]

This issue may be fixed with the latest development release in tier 3 released on August 25, 2011. See here

[TechnicalMonkey]

The fix is good, but it needs more work. There are frame drops still within the switcher. Of course that first beta 5 was the pits. At least it shows that you guys are listening. I still think that the switcher needs more as it now only works at about 40%. I think that the picture quality may have taken a nose dive though :/ I think I will start a thread with past videos showing how it used to be and track performance levels.

[Da-Sud]

I will test this new release and let you know how it goes.