Choosing the Optimal Data Rate for Live Streaming

When you’re a hammer, the world looks like a nail. When you have objective video quality measurement tools, you can use them to check all the assumptions that you’ve made in the past to verify their veracity. One of the assumptions that many of us make is that copious outbound bandwidth is necessary to achieve high-quality streaming when producing live events. 虽然这在某种程度上是正确的, as demonstrated by the tests I undertook for this article to identify an optimal data rate for live streams, you quickly reach a level of diminishing returns.

演习目的

The object of the exercise was to show how output quality was affected by the data rate of the incoming video in a cloud transcoding scenario. 具体地说, 比如Ustream网站, YouTube生活, and Brightcove/Zencoder input a single stream and transcode in the cloud into an adaptive group of streams. 在向这些网站传输视频时, 而更高的数据速率总是更好, 许多站点的出站带宽是有限的, and can be expensive in an offsite conference or similar scenario. 问题是, how much difference will a typical user see between an affordable 3 Mbps 720p stream, 和一个可能是奢侈的6mbps 720p流?

事实证明，并非如此.

我是如何测试的

我用两个夹子进行了测试. 一个是我说话的头剪辑, the other a song from a recent concert appearance of the Loose Strings band in Galax, Va. The Loose Strings clip is a single-camera concert shoot with lots of pans and zooms. It's more challenging than a talking-head clip, but not exactly a chase scene from 使命:不可能的 当涉及到编码复杂性时.

Both clips started life as 1080p AVCHD which I copied to disk, 导入Premiere Pro, 添加时间码, 输出为ProRes. I then played the clips out using a Blackmagic Design DeckLink HD Extreme 3D card via HDMI, 并被玛特洛克斯帝王HDX抓获.

原因我稍后会解释, 我首先捕获了一个20mbps的720p流, 然后是10mbps的流, then I captured at decreasing data rate values down to 1 Mbps. 这些作为源测试剪辑.

在转码场景中, you don't care about the quality of the incoming clip, you care about the quality of the clip encoded from that source clip. To measure this, I created two presets in Sorenson Squeeze, one for 640x360 at 1.2 Mbps输出, 另一个为1280x720, 2 Mbps输出, both using x264 with the Fast Encoding preset that many live producers use during transcoding. Then I input all the source clips into Squeeze, and encoded with those presets.

让我们都保持清醒, I’ll call the original Monarch-encoded clips the “source” clips, 都是720p制作的, and the 360p and 720p Squeeze-encoded clips the “transcoded” clips.)

下一个, I measured the quality of the source and transcoded clips using the Moscow University Video Quality Measurement Tool (VQMT), and the SSIMWave Video Quality of Experience Monitor (SQM).

These tests raised some interesting test-related technical issues. 顺便说一下背景, when testing the quality of encoded video on demand clips, 从源剪辑开始, 剪辑编码, and compare the output with the source using the selected tool. 容易,peasy.

在现场场景中, the source file is less easy to identify because it’s slightly changed so many times. 例如, 在我的捕捉工作流程中, the clip was processed by the Blackmagic card to transmit via HDMI, 然后在捕获过程中被帝王蝶缩放. 第一个, I tried comparing the Monarch-encoded source clips with a 720p clip scaled and output in Premiere Pro, but the small scaling and other differences were so substantial that they essentially masked the true compression-related quality differences.

So, rather than comparing the source clips produced by the Monarch-to-Premiere Pro output, I compared them to the aforementioned 20 Mbps source clip. To analyze the transcoded clips produced in Squeeze, I encoded the 20 Mbps clip using the same 360p and 720p presets, and compared all other encoded clips to those outputs.

I can’t say for sure that this is the best approach--and I’m open to suggestions for future articles--but this is the procedure I used for this exercise. 现在，对测试程序的关注已经够多了. 让我们看看结果.