There are many important aspects that go into streaming a live broadcast. I often have people asking: “Which settings should I use to broadcast a high-quality Flash stream?” Seems like a reasonable question but there are so many variables involved that it’s impossible for me to give a simple answer. My goal here is to explain all of the different factors involved and hopefully give you the knowledge necessary to start Wirecasting like a pro.
First, I’ll briefly go over the major elements involved in live webcasting, then I’ll go more into more detail on each. These are the most important things to keep in mind:
1) Hardware – Obviously, a better machine will be able to handle higher-quality streams.
2) Bandwidth – If you’re broadcasting from a standard DSL connection, you need to make sure you don’t exceed your uploading bandwidth.
3) Broadcast Settings – Higher quality video streams are taxing on your system and require more upload bandwidth.
4) Multiple Streams – If you’re streaming multiple streams simultaneously, this is going to increase the amount of work your machine has to do.
5) Inputs – Your video source can impact your stream in many different ways. Live sources, in particular, can dramatically impact the performance of your broadcast.
6) Codecs – Some codecs are more efficient than others and they do have limitations to what they can handle. Sometimes you can overload the limitations your video codec and start dropping frames on an otherwise ideal recording.
Remember, Wirecast webcasting software is a type of video encoder. For most people, it wouldn’t be surprising if it took a long time to encode a full 1920×1080 HD video on your desktop computer. Still, people seem surprised that Wirecast starts dropping frames when they’re broadcasting at the same resolution!
Wirecast goes through a process called compositing where it decodes all the separate inputs (movies, images, live cameras, etc.), layers them together, then re-encodes them on their way to each destination. That’s a lot of work considering it has to do it at least as fast as real time encoding. If your machine can’t keep up with the quality of your broadcast, Wirecast will start dropping your frame rate to compensate. If you’re just starting to drop frames, you can sometimes get away with it without it being too noticeable but if it starts dipping too low it will become very obviously choppy.
If you’re planning on doing lots of big streams you’re going to need a powerful CPU. Think in terms of multiple cores, not just CPU speed; an eight core i7 will beat your Core 2 Duo and a decent graphics card. In the highly unlikely situation that you are hitting a bottleneck in your record to disk, you may need to upgrade to a RAID hard drive setup or lay down the cash for an SSD.
There are several different ways that you can broadcast to the web. You can do it yourself (via QuickTime Streaming Server, Flash Streaming Server, etc.), you can use a community streaming website (Ustream, Livestream, Justin.tv, etc.) or you can use a content distribution network or CDN (Limelight, Akamai, etc.).
If you’re broadcasting to a community streaming site, you may run into bandwidth restrictions. If your stream is refused for no apparent reason, I would check to make sure that you haven’t exceeded the data rate limitations for that site. This can also cause problems with random disconnects because the data rate fluctuates and the server may kill your stream when your data rate peaks.
If you’re hosting the streaming server yourself then you have to be careful about how many people connect to your stream. This is less of an issue if you are only broadcasting within a local area network but if you’re streaming to the web, you have to be able to manage the data rate for each individual connection to your stream. If you don’t have enough upload bandwidth then people will start losing quality and getting disconnects. Also, make sure that nobody else on your network is using upload bandwidth. This can be a major issue when streaming from a corporate network where there are lots of users sharing the bandwidth. Still, using a streaming server is the best choice for streaming across a LAN or VPN, assuming you know about how many people will be connecting.
Using a CDN is good way to go for streaming to the web. You can embed the videos directly in your website and don’t have to worry about advertisements in your video. Plus, the only restriction will be your upload bandwidth for a single stream which will be reproduced by the CDN for each person who connects. However, they can be prohibitively expensive for individuals or broadcasters working on a tight budget.
Obviously, the quality of stream you are sending out will affect your performance. Let’s say for example that you found the perfect data rate for streaming 320×180 and you want to upgrade to a 640×360 stream. Thinking in terms of pixels displayed, the total number of pixels in a 320×180 image is 57,600. The number of pixels in a 640×360 image is 230,400 – four times greater. However, codecs are more efficient at encoding larger resolutions, so there is not a one-to-one ratio of pixel size to data rate. Jan Ozer wrote a great article on this exact subject.
It’s important to keep in mind the context of your stream when setting up your encoder presets for a broadcast. You need to think about:
1) How much bandwidth do I have to work with?
2) How much bandwidth does my target audience have to work with?
3) What type of video do I want to broadcast?
First, you need to make sure that your broadcast settings aren’t going to use more bandwidth than you have available. You can calculate this by seeing what your maximum upload rate is (from your internet service provider), and by making sure that your presets never exceed that amount. It’s always a good idea to test running a broadcast first just to make sure.
Second, you need to consider your target audience. If you know that it’s only going to be watched by people on your internal network then you just have to limit yourself to the bandwidth of your internal network. Alternatively, if you’re expecting to be streaming to people who are still on dial-up, you are going to have to dramatically reduce the quality of your presets to compensate.
Third, you need to keep in mind the type of broadcast you intend to do. If you are doing a low action interview then you can probably reduce your frame rate and use a conservative data rate without losing too much quality. If you are broadcasting a high-action sports event, you’re going to need a higher frame rate to avoid choppy video and a higher data rate.
Typically, when setting up for a broadcast, I experiment a bit with my data rate beforehand. I start it out a bit high then bring it down little by little until I can get it as low as possible without impacting the quality of my stream. If I’m expecting a higher-action stream then I’ll wiggle the camera around while broadcasting to see if my frame rate starts to drop. If you are starting to drop frames on a broadcast that’s using a preset with more than 30fps (which is rarely necessary), I would recommend lowering your frame rate a bit to maintain quality and reduce your data rate. Typically, I think you can get away with as low as 24fps (standard film) on a stream without it looking too choppy, I would caution against going much lower than that unless you’re working within very specific restrictions.
It’s important to remember, again, that Wirecast is encoding its output on the fly. Sending simultaneous streams works great but will dramatically increase the impact to your machine.
I regularly stream 6 simultaneous streams from my Mac Pro. One high and one low quality QuickTime stream, one high and one low quality Flash stream, one iPhone stream (via Wowza server) and one QuickTime record to disk. However, a lot of fine-tuning was required to make sure that each stream was using exactly the right data rate, resolution and frame rate to give me the quality that I wanted and I am just on the edge of exceeding the limitations of my machine.
Here’s a little known trick to Wirecast that allows it to identify if you are using identical broadcast and recording presets: If you have a broadcast and a record to disk using an identical preset, Wirecast will match them up so it doesn’t have to do the encoding twice. This is helpful if you’re already pushing the limits of your setup and want to get a recording of your broadcast at the same time.
Wirecast is great at managing a wide variety of input sources, so you can easily have several live camera sources feeding into your Wirecast machine. However, really high-quality video sources may end up causing you more harm than good. Let’s hypothetically say that you’re bringing video in from an HD camera, dropping it into Wirecast’s canvas (set to an HD resolution), then broadcasting back out at an HD resolution.
That is a lot of information to be going through your graphics processor (GPU). If your frame rate starts to drop but your CPU usage is staying steady, you’ve hit a bottleneck. Try reducing the frame size going through Wirecast. There’s no need to bring in a 1080p video input if you’re only streaming out to 640×360. Also, always remember, resizing down is okay but resizing up is not.
Above is an exaggerated example of resizing an image from the input to the canvas to the output. By reducing the high-quality source to fit into the lower-quality canvas the output has become extremely pixelated and blurry. As a rule, you should try to keep your resolution as constant as possible from source to output. You get no benefit out of having your HD camera at native resolution if you’re only broadcasting a 640×360 stream, all you are doing is increasing the amount of work your machine has to do and you may end up getting reduced quality.
When using a live source, Wirecast has three potential resize steps.
1) Device Capture Size
2) Wirecast Canvas Size
3) Encoder Preset Size
Your goal should be to bring your Device Capture Size and Wirecast Canvas Size down as low as possible without your Device Capture Size being smaller than your Canvas Size or your Canvas Size being smaller than your highest broadcasting preset size. The Device Capture Size is dependent on your input source so it’s good to experiment a bit with Native, Reduced and Low settings before picking one for your broadcast. Also, many HDV cameras have the ability to switch to a DV mode – which is probably a good call if you aren’t planning on using an HD resolution.
This diagram helps to illustrate the different resize steps your video goes through in Wirecast. The base resolution is dependent on whatever your live source is. It is then scaled down based on your Device Capture Size. The video is then scaled to match your Wirecast Canvas Size. The last step scales it to whatever your highest broadcast preset resolution is. Smaller broadcast presets are automatically resized down from there. Keep this sequence of resizes in mind as you set up your document to ensure the highest possible quality for your output.
Video codecs, by design, have their own built-in data rate limitations. It should be pretty rare that you start exceeding the limitations of your video codec but it’s something to consider for very high-quality video. For example, the Apple H.264 codec claims it can go as high as 135,000 kbits/sec (Level 5, Main Profile) but I’ve found in practice that it’s quite a bit lower than that. If you start to encounter issues with the inefficiencies of the Apple H.264 codec, then you should probably switch to an unrestricted format like Apple Intermediate Codec or Apple ProRes. Be careful though, these are large uncompressed formats and will eat up the space on your hard drive very quickly.
Hopefully this overview has helped illustrate some of the different elements involved in the broadcasting process. Finding the right balance between all of these components is key to getting a high-quality broadcast.
Great article Mike.
Lots of good details.
I’m hearing that super fast 10,000 rpm or 15,000 rpm drives decreases dropped frames on recording as well. Some say it’s even better than SSD or RAID0 but I haven’t tested personally.
I wish you guys would have published something like this when i started testing with Wirecast a couple of months ago..
You would have saved me from all the hair pulling! 🙂
Streaming of hair pulling live could be a great viral hit! 😉
There’s so much ground to cover. Feel free to make suggestions. Of course the tough part is when you’re first starting out it may be tough to figure out what questions to ask. Again, do make suggestions.
Yes, I agree! When I first started working with Wirecast, it took me quite a while to figure out some of the things Mike lays out really quickly.
We’ll continue to put out articles and information on tips and tricks for webcasting and Wirecast. Of course, if you have any focused topics or areas you want to know about, please let us know!
Fantastic article. Great read.
Hunh- I’ve always worked with the premise of “garbage in- garbage out”, but I get what your sayin.
Any idea where I can get the full settings that Ustream uses in their Producer?
I’ve used that with my HD cam in HD mode and got 30fps and no pixalation. Also using their “high quality encoder” When I’ve tried various settings in Wirecast, I drop to 15-20fps, a lot of pixelation and my cpu seems to be working harder. I’m assuming I just need to find the right Ustream settings and enter them into Wirecast and I should be good to go.
“Garbage in, garbage out” is true, you can never increase the quality of your source through video encoding. A bad source will result in a bad output. However, that doesn’t mean that you need to have the highest quality source possible, it just means you need a source of equivalent or better quality.
The High SD Quality encoder settings from Ustream Producer are 640×480 @ 30fps, 500kbps with AAC 44.1k Stereo audio. In Ustream Producer, you can see the preset settings underneath the drop-down menu in the Settings window. I highly recommend experimenting a bit with your broadcast settings to get a feel for how high they can go.
If you are planing on doing this from home keep in mind that your connection is likely asymmetrical. Meaning that your upload bandwidth is much less than your download bandwidth. This is great if you are browsing the net because most things are download. But if you are going to run any kind of VPN that slow upload will be the determining factor in overall speed. A VPN requires fast in and out. So a slow out will hamper it’s effectiveness. It’s going to be much more simple and effective to use a commercial personal vpn service like Aside from being fast the multiple server addresses will not get blocked by web filters like your home one will. However, if you really want to give it a shot then I would recommend OpenVPN It’s bullet proof and fast. You could set it up in a virtual machine on either computer and let it run in the background.
Hi Mike Andersen,
All the different factors involved for doing Webcasting were very useful for me. This is really an informative blog. Your point by point explanation is very obvious. And your explanation is very technical. Thanks for sharing such an useful info with us. But one thing i would like to share with you is, while browsing Google, i got one website who offers Webcasting with Software as well as the Hardware. They provide the complete Setup. I have mentioned the url below for your reference. When you get a chance check it out.
Web casting is definitely the way to go. My company is poised to be the next fortune 500 web conferencing provider in the industry. The main reason being is the features that we provide and the low cost.
This is a great article. Am trying to reduce the load on my CPU for streaming. Just gonna go try some of these tips! Especially like the one about keeping the same settings for recording as streaming. Only problem with that is that this means saving as flv presumably? Not very FCP friendly.
Nice article, Mike, very informative and helpful!
Mike, I really liked your article but it left me with a few questions. If you are running six streams from your Mac Pro, I’d like to know more about your setup. When you mention you are doing a high quality QT and flash. What were the capture, canvas size and broadcast settings you used? Also what kind of upload speed are you using to send the data?
Dirk, our setup has changed a lot over time but we most commonly use a Canon Vixia HV40 camera through either FireWire, Blackmagic Intensity or Blackmagic Decklink SDI (we use the same machine for testing, so it changes a lot!).
Using a Quad-core 2.26 GHz processor with an ATI Radeon HD 5770, using a canvas size of 1280×720, I’m able to broadcast:
1) Flash HD 1280×720, 2200kbps, 30fps
2) Flash Low Quality 320×180, 400kbps, 25fps
3) QuickTime HD 1280×720, 2200kbps, 30fps
4) QuickTime HD 1280×720, 2200kbps, 30fps (paired recording)
5) QuickTime Low Quality 320×180, 400kbps, 25fps
6) iPhone Stream 320×180, 400kbps, 25fps
7) Audio-only Stream, 128kbps
I drop frames on high-action but most of our broadcasts are very low action, so it’s not really an issue for us. I’m sending all of these streams to QuickTime and Flash streaming servers on our network. The majority of our connections are on the internal network, the lower quality connections are available for people connecting over VPN, so we have more upload bandwidth than we need.
I would guess for the above broadcast setup you would want at least 6mbps upload, assuming you’re sending to a CDN which will redistribute. You would need a lot more if you’re hosting the streaming servers yourself.
Hope that answers your questions!
Thanks for the suggestions you have shared here. One more thing I would like to state is that personal computer memory demands generally rise along with other developments in the engineering. For instance, if new generations of processors are brought to the market, there is certainly usually a matching increase in the shape demands of both the pc memory and also hard drive space. This is because software program operated by simply these processor chips will inevitably increase in power to leverage the new technologies.
Great post. I constantly check this blog and I am impressed!
Does anyone have experience with webcasting/capturing from HDMI versus Firewire? Sony Z7’s would be the cameras used. Thanks!
We regularly capture with both HDMI and Firewire. Both work well but HDMI is usually preferred for a variety of reasons.
HDV has to be software decoded which puts a bit of additional load on your system. Not ideal when you’re really trying to push the boundaries of your hardware. Also, if you’re looking for really high-quality video, to my knowledge HDV 1080i is only Anamorphic meaning it’s actually sending 1440×1080 (then stretching it out to 16:9) rather than a true 1920×1080 video. HDV also requires an additional plug-in for Wirecast to decode it (the plug-in is included with Wirecast Pro or can be purchased for Wirecast Standard for $99).
The downside to HDMI is that HDMI inputs are much less common on computers than Firewire inputs. Typically, you’ll need an HDMI capture device like a Blackmagic Intensity Pro or Matrox MXO2. Until recently, it’s been harder to get HDMI sources in to laptops for mobile broadcasts but there are new devices on the way from a variety of hardware developers that can bring in video over Thunderbolt and USB 3.0.
– More common
– More portable
– High quality
– Higher system load
– Not a true 1920×1080 (but you probably wouldn’t be streaming that anyway!)
Edit: I forgot to mention, HDV devices also have a small delay because of the decoding process. This can cause problems if you’re running your audio in from a separate microphone. You can resolve this by running your audio in through the microphone jack on your camera or by using the Audio Inspector in Wirecast Pro to add an audio delay to sync it up with the camera.
Thanks for the response and for the info on your settings. I’m looking at Wirecast Pro to take advantage of the Live Sets with a green screen and multiple cameras. Initially we are going to try one of the Blackmagic Intensity Pro cards to bring in HDMI from either a Canon Vixia and try a second Canon GL-2 via firewire 800. What’s your thoughts on running two Intensity Pro cards on one Mac Pro??
I need to talk with Comcast and see if I am going to be working with different clients, how I can get a business class account with the ability to get higher data rates at a premise location. I.E. they normally have a basic account with limited bandwidth but it seems that having at least 5-6 megs is preferable?
The post explaining the differences between HDMI and HDV input was good stuff.
You can run multiple Blackmagic cards on the same machine but you can’t mix and match. So long as you’re using multiple identical cards, it works great. We often times have machines running three Blackmagic Intensity cards simultaneously without any issues.
In regards to your upload rate, if you’re broadcasting out to a CDN you may not need that much. It all depends on how many destinations you’re planning on sending to and at what datarates. If you’re broadcasting 720p to a single destination, you could probably get away with a 2Mbps upload (granted, that’s assuming you’re compressing to somewhere between 1.2 – 1.5Mbps, which will give you some noticeable quality reduction on 720p).
My advice is to experiment with what you’ve got first, try different destinations and datarates on your current connection and see if you need more or not. If you don’t already have Wirecast, you can download and use it in a trial mode to see what your upload bandwidth can handle. Just be sure to give a bit of cushion between your total datarate and your upload bandwidth. Wirecast aims for an ‘average datarate’, meaning it can fluctuate higher and lower depending on how much action there is in your broadcast.
Hope that helps!
Mike; fantastic post. Lots of good input there. I’m looking to use wirecast more and your setup triggered a question, I hope you will answer.
Why do you also encode the 2 quicktime files? Wouldn’t the Flash-files serve almost everyone (pc, mac and android)? And then you have the iPhone stream for the rest (i-devices).
Good question. Really, the only reason we broadcast simultaneous QuickTime and Flash streams is because we can! It’s not something that would be necessary in most production environments but it’s a great demonstration of Wirecast’s flexibility. However, even if I were not streaming the QuickTime High/Low/Audio streams, I would probably do my record to disk as an H.264 MOV which is a friendlier format than Flash for archiving and recorded playback.
Thanks for getting back, Mike. Yeah, it makes sense to archive in MOV as compared to flash. Hadn’t thought of it that way.
I really like your setup and find a lot of inspiration in how you have setup your streams. If you were to broadcast them online (and not only on an internal network) using a CDN, how would that work using Wirecast? Could the streams be fed to a player on a single webpage that knew how to handle both PC, Mac, Android and iPhone and serve up the relevant format stream and also take advantage of the adaptive bitrates? That would be both cool and easy and something that would be of great value to me.
Also, the quad core cpu you’re referencing does that have hyperthreading (and act like 8 cores)? And does Wirecast support hyperthreading on a quac core cpu?
Thanks for this brilliant write-up quite beneficial also as helpful
Among myself along with my hubby we have owned more Audio players in the past as compared to I will depend, which includes Sansas, iRivers, apple ipods (traditional & touch), your Ibiza Rhapsody, etc. However, the past decades I’ve settled down to 1 distinctive line of gamers. The reason why? Since i has been thrilled to know how well-designed and also enjoyable to make use of the underappreciated (along with extensively mocked) Zunes tend to be.
Using webcasting at your conference not only presents you with far greater opportunities and flexibility, it also sends out a very powerful message about your company; as a forward-thinking organisation, willing to embrace the latest technology.