EPTNote: This guide is a bit out of date and some things are no longer accurate. For XSplit users, see this post for a quick idea of how settings affect quality.
There are three main factors when streaming:
- Quality
This is how your stream looks to your viewers. - Bandwidth
Streaming requires a high upload bandwidth for best results. - CPU Usage
If you're playing SC2 on the same PC as you're streaming on, you have to balance it so neither your stream nor SC2 starts suffering from lack of CPU power.
Quality
It's important to note that quality is not directly related to any single factor - eg cranking the resolution to 1080p and claiming that's the best possible quality is simply not true. There are many factors involved with how good your stream will look. Here are some:
- Codec
Most streaming software uses either H264 or VP6. The codec is a piece of software that converts the 50MB+/sec of raw image data into a compressed video format suitable for Internet data rates. H264 / MPEG4 is the more modern codec. However there are many implementations and variations in the way codecs can be programmed, such that some encoding software is better than others despite using the same standard.
Popular software that uses H264 includes Adobe Flash Media Encoder and XSplit. XSplit uses the x264 encoder which is regarded as being the highest quality whereas FMLE uses MainConcept. VP6 is an older codec that is available to users of Adobe Flash Media Encoder. It requires a higher bitrate (more upload) for the same quality, but has some benefits in that it recovers from scene changes faster than FME's H264.It's also worth mentioning under the Codec section (but really it's a software issue) that XSplit's internal source scaling will always result in a blurrier output than a Adobe FME stream due to a scaling bug in XSplit (Hi SplitMedia please fix this, I've sent in about three bug reports already!). This becomes very noticeable if you have text or other sharp elements on your stream and is one of the main reasons I personally dislike XSplit.UPDATE: This bug no longer exists as long as your output resolution matches your input resolution. - Frame Rate
The higher the frame rate, the more frames the codec will need to process and the smoother your stream will look. A good frame rate to target is around 25 FPS. Some streamers use 20 FPS and as long as it's a consistent 20 FPS this is fine, however below 20 FPS your stream will become noticeably jerky and unpleasant to watch. Going above 25 FPS does not yield many benefits while taking additional CPU to encode.
The main thing to aim for with the frame rate is consistency. A consistent frame rate is good, a frame rate that jumps up and down is very noticeable and annoying to a viewer. Frame rate correlates pretty directly with the codec - the quickest way to reduce CPU usage if you're having trouble is to reduce the frame rate as a 20% reduction in frame rate results in 20% less work for the codec. - Resolution
While you may think the higher the resolution, the better the quality will be, this isn't necessarily true. Very few people will have the CPU and Internet bandwidth to support a high quality 1080p (1920x1080) stream at a decent frame rate. It's much better to have a lower resolution stream at a steady and consistent frame rate than to try and push the resolution as high as it goes.
Codecs work on a variable bit-rate and more complex scenes can require more time to encode. While your stream might seem fine at 1080p@30FPS while looking at the SC2 menu, come a big battle and you may find your stream turns into a slideshow as the codec can't keep up with all the data.
Try to pick sizes that are exact 2:1 reductions for best quality, eg if your SC2 is at 1680x1050, try streaming at 840x525. To change the resolution you can either set your SC2 to play in a lower resolution or set your streaming software to resize the input / output. Generally though you will want SC2 to run at your native monitor resolution with either a full size or half size resolution for your stream. - Bitrate
The bit rate is the approximate amount of kbps that the codec will try to produce. However the H264 format is a variable bit rate format, so even if you specify 2000kbps, if the codec tries to encode something and it happens to come out at 2500kbps for that particular instant, it's going to either use it or drop it. It's important to pick a bit rate that is well below the maximum upload speed of your Internet to account for bursts like this. If you have 2mbps upload and stream at 1900kbps, come a burst of 2500kbps your stream is going to lag or drop frames (both equally bad).
Lagging can become cumulative to the point where if your upstream never manages to recover and "catch up" to the live point in the stream (eg an average of 2.1mbps trying to go out of a 2mbps upstream), your stream will simply not work. Dropped frames are also bad as if a key frame is dropped, it can take 5 - 10 seconds before another key frame is generated, during which time your viewers will have no video.
On the flip side, too low of a bitrate and your stream will look terrible. Codecs can't work magic - it's impossible to turn 1920x1080 @ 25FPS into a decent looking 1mbps stream for example.
The above four factors are the most important things to consider when setting up your stream. Some streamers prefer a higher resolution with a lower frame rate. Others take a more conservative approach and use a low resolution with a high frame rate and bit rate. This is actually very good option to start with since it guarantees no bitrate quality issues and doesn't usually use much CPU.
Bandwidth
I've touched on the topic of bandwidth in the quality section, but it deserves its own section for clarity. First of all, streaming is tough on your connection. Any packet loss or jitter can cause your data to arrive late at the streaming provider which will discard it due to the timestamp being late. Worse still, your throughput may be reduced by retransmissions to the point where your stream buffer backs up and no new data ever makes it to your viewers.
When determining your bitrate, a good rule of thumb is to leave about 25% of your upstream unused. If you have a 2mbps upload speed, set your stream bitrate to 1500kbps. This leaves enough room for the occasional burst of data from the codec as well as for background applications such as any VoIP software and of course SC2 itself.
When determining your upstream speed, it's important to perform a realistic test. If you go to www.speedtest.net and pick the closest server to you, you're not going to get a realistic result. For users in the US, I would suggest picking a server on the East or West coast, whichever is furthest from you as a good baseline. If you're still using Windows XP, you will need to apply some registry tweaks to be able to get good performance to sites with higher latency, but that's beyond the scope of this guide.
Depending on your connection type, your upload speed may vary during the day as more users get online. Crowded cable networks and especially using wireless can be a big issue. Run tests at the time you would usually be streaming for accurate results. One final thing to keep in mind is some ISPs offer "boost" technology where for the first X seconds of a transfer, upload/download limits are relaxed slightly to provide for better looking results in speed tests.
For those of you on capped connections with a limited amount of transfer per month, you may want to avoid regular streaming. It can very quickly add up to a lot of bandwidth and may cost you additional fees from your ISP.
Finally, keep in mind that when you set your bitrate to X, your viewers need approximately X + 500kbps for a reliable streaming experience. If you can upload at 10000kbps then that's great, but don't expect many people to be able to watch your stream. (Side note: Justin.TV provides a service to transcode your stream into a lower resolution / bitrate if you are a partnered account. Contact them for details)
Here's some very rough example bitrates you should be looking at for a nice quality stream at 25 FPS (these will vary depending on encoder used and other factors, with XSplit you can get away with a lower bitrate for the same quality for example):
480p (720x480): 750-1000kbps
720p (1280x720): 1500-3000kbps
1080p (1920x1080): 3000-5000kbps+
Most of you will not be playing in a resolution that matches one of these exactly, so you'll likely want to resize your stream down to a matching aspect ratio.
CPU Usage
Here comes the fun part. Streaming requires lots of CPU. So does SC2. If you stream at too high a quality, both your stream and your game will start to lag. You need to find a balance between quality and how much the stream impacts your game performance.
First, if you have anything less than a quad core processor, you may as well forget about streaming in any kind of decent quality for now. SC2 itself can easily almost max out a dual core CPU, leaving no room for streaming.
Ideal CPUs:
Core i5 2500k / i7 2600k
Core i5 / i7 8xx / 9xx Series
AMD Phenom X4 / X6
Unfortunately anything less than these including older Core 2 models are showing their age and you won't be able to reach the best results. Streaming and SC2 are extremely CPU dependent, your graphics card has a very minimal impact on things so don't go out and buy an expensive GPU in the hope it will fix things.
The codec you choose (which is influenced by which program you stream with) has a very big impact on CPU. Adobe's Flash Media Encoder has a pretty standard H264 encoder but it uses a lot of CPU. One benefit is that is multi-threaded, meaning it can take full advantage of multiple cores and benefits from i7 CPUs. XSplit on the other hand produces a higher quality output
How you get your SC2 into the streaming program also has a big impact on CPU usage and in-game lag. Most screen capture options such as XSplit's internal capture and VHScrCap use a significant amount of CPU and rely on GDI which causes your game to lag even if your CPU isn't near maximum. The best option by far is to use DXTory which rips the screen directly out of your video card after it has been rendered by intercepting DirectX calls. This has almost zero overhead associated with it, however DXTory is not free - it will set you back around $50 and will not allow you to capture anything other than games. The next best appears to be SCFH, a GDI based screen capture. Even if you use XSplit, you aren't forced to use XSplit's internal capture - you can easily add a camera source of DXTory or SCFH.
Programs such as XSplit offer a virtual set where you can add overlays and other effects. Keep in mind - especially if you use transparency - that the cost of these effects can add up in terms of CPU usage. High-quality resizing is also an expensive operation for CPUs, so for the lowest possible CPU use, try to match your screen size with your stream size (XSplit users can ignore this since XSplit seems to scale everything regardless of it matching the output size).
Some guides recommend setting affinity so your streaming program and SC2 run on separate CPU cores. I don't really recommend this as it just limits performance, if you want to ensure your SC2 doesn't lag at the expense of your stream, simply set SC2.exe to High Priority in task manager.
Another thing if you use Vista / Windows 7 to do is to disable Aero (the fancy translucent desktop effects etc). To do this, right click on the shortcut to your streaming program or SC2 and under Compatibility, tick the "Disable desktop composition" box. This especially helps when using GDI capture methods.
Final Thoughts
One reason I like to use Adobe FMLE over XSplit is the status window. XSplit offers you pretty much zero feedback - it doesn't tell you the current FPS, whether there is any local buffering, if there are any input or output dropped frames, etc. It's pretty much just luck - try some settings and see if your stream lags, if you get buffering just restart and hope it's better, etc. FMLE on the other hand offers you very useful statistics - dropped frames, current bitrate (remember it's variable) and more.
Input drops mean your capture source such as DXTory or SCFH isn't providing input fast enough - this can happen in big battles where your SC2 FPS drops below your desired stream FPS. Output drops are the ones to watch for - this means output frames were dropped because they couldn't be encoded in time. Any amount of output drops means your stream will lag and you should re-adjust your settings. If you see publishing buffer or frame drops at non-zero values, this indicates your upload is too slow or the connection to your streaming service is failing.
Remember to test things with a realistic load - simply looking at the SC2 menu is easy for a codec to encode and won't provide accurate feedback. Watch some replays and move the camera around etc (but don't run replays on 2x or higher since that will use more CPU than a realistic game).
thanks for the answer .
