Quality Settings
Intro
To broadcast at the highest quality, yet
providing the smoothest stream, requires that you push your Internet
connection and computer to its limits. Even going slightly over the limits
may hurt your broadcast severely. Keeping this delicate balance
requires an understanding of how to configure the resolution and bitrate of
your broadcast.
Resolution
The resolution is the number of pixels in your video. The higher it is, the more detail you will see. With a high resolution of 1280x720 (720p HD), you can even see the pores on the actors' skin. If everyone had an expensive central processing unit (CPU), then we would all be watching HD streams. But most of us have CPUs that are more than a year old and can't broadcast high resolution videos smoothly (slighty not true).
To test what the highest resolution your CPU can handle, use the let me adjust the settings a bit option when asked to set the quality. Start at the lowest resolution of 320x240. Hit the preview button to see if video is smooth. Most computers can handle this low resolution, so stop the broadcast, then click the wrench icon on the playlist item, and finally slide the resolution up one notch. Continue previewing and inching the resolution slider up until your video becomes flickery. This is when your computer has exceeded its limit. At this point, you should drop the resolution down one notch.
Here are some general guidelines for the optimal resolution:
| resolution | number of CPU cores | age of computer | suggested CPU models |
|---|---|---|---|
| 320x240 | single core | 4 years | Intel Pentium, AMD Athlon |
| 480x320 | dual core | 3 years | Intel Core2 Duo, AMD Athlon II |
| 640x480 & beyond | quad core | 1 year | Intel Core i7, AMD Phenom |
Bitrate
The video and audio bitrate of a stream determine another type of quality. With a high video bitrate, there will be less artifacting (blurry blocks). With a high audio bitrate, the sound will be crisp and clear. Like resolution, the combined bitrate of your stream must be controlled for the best viewing experience. Transmitting at a higher bitrate than your Internet connection can handle will result in dropped frames, which means there will be weird ghosting artifacts.
A good way to check your upload speed is to go to
Speedtest.net. They report the upload
speed in Mb/s. You need to convert it to Kb/s by multiplying by 1000. It's
safer to divide this number by 2 to estimate your stable upload
speed. So in this example, 5.27 Mb/s * 1000 / 2 = 2635 Kb/s. Even though you may
have an extraordinary upload speed of 2635 Kb/s, refrain
from streaming at this speed. Many viewers will not be able to download that fast
and, as a result, will get a choppy stream.
You also have to consider if it's necessary to broadcast at high bitrates. Slow moving sports, such as golf for example, won't benefit from high video bitrates. On the other hand, the audio in music videos is very important and would benefit from a higher audio bitrate. Here are some suggested bitrates, assuming that your upload speed is fast enough:
| genre | video bitrate | audio bitrate |
|---|---|---|
| cinematic | 750 kbps | 96 kbps |
| music videos | 600 kbps | 128 kbps |
| sports | 600 kbps | 64 kbps |
| any genre @ 720p | 1200 kbps | 96 kbps |
x264
x264 is the algorithm that transforms the original source video to the h264 video users see on Veetle. We have a full tutorial on x264, but we'll give you the basics here. Increasing x264 settings increases the quality of your video, but also increases CPU usage. When doing offline pre-transcoding, you should always max out the settings because CPU usage and time are of no concern. However, when doing realtime transcoding, the settings should be based off of your final bitrate and resolution so you don't overload your CPU. Below are realtime transcoding suggestions for an average dual core CPU on a 2 Mb upload capacity connection.
| Bitrate | Resolution | ref | subme |
|---|---|---|---|
| 1200 kbps | 1280 x 720 | 1 | 1 |
| 900 kbps | 960 x 540 | 2 | 2 |
| 600 kbps | 640 x 480 | 3 | 4 |
| 450 kbps | 480 x 320 | 3 | 5 |
#transcode{vb=1200, width=1280, venc=x264{ref=1, subme=1, bframes=16, b-adapt=1, bpyramid=none, weightp=0}, vcodec=h264, acodec=mp3, ab=96, threads=2}:std{access=http, mux=asf, dst=127.0.0.1:1234}
#transcode{vb=900, width=960, venc=x264{ref=2, subme=2, bframes=16, b-adapt=1, bpyramid=none, weightp=0}, vcodec=h264, acodec=mp3, ab=96, threads=2}:std{access=http, mux=asf, dst=127.0.0.1:1234}
#transcode{vb=600, width=640, venc=x264{ref=3, subme=4, bframes=16, b-adapt=1, bpyramid=none, weightp=0}, vcodec=h264, acodec=mp3, ab=96, threads=2}:std{access=http, mux=asf, dst=127.0.0.1:1234}
#transcode{vb=450, width=480, venc=x264{ref=3, subme=5, bframes=16, b-adapt=1, bpyramid=none, weightp=0}, vcodec=h264, acodec=mp3, ab=96, threads=2}:std{access=http, mux=asf, dst=127.0.0.1:1234}
Notice how the x264 settings decrease as you increase bitrate and resolution. Increased resolution requires increased bitrate to encode the extra pixels. Furthermore, increased bitrate dimishes the benefits of the x264 settings. That is, you won't see much difference in quality when tweaking x264 at high bitrates. The increased resolution burdens your CPU, but by decreasing x264 settings, we counteract this effect without sacrificing much quality. If you try many of the configurations above, you'll notice that CPU usage hovers around the same percentage because of this balancing act.