2013年11月4日
By 1月时特约编辑
专题文章

操作步骤:计算实时事件的出站带宽需求

出站带宽可以成就或破坏一个直播流事件. 不幸的是, 这在过去很容易计算, 现在，随着流计数的增加以及编码和转码替代方案的激增，这变得相当具有挑战性.

从这个角度来看，我在2010年第一次直播的时候，事情很简单. 因为手机还没有爆发, SD仍然是标准, 我可以用320x240的Flash流编码为500千比特每秒, 它从来没有强调过事件设施提供的850Kbps输出带宽.

从那时起，移动支持就成为一个优先事项，这有几个含义. 第一个, 因为移动设备包括通过蜂窝或Wi-Fi连接的智能手机和平板电脑, 您需要自适应流来有效地服务于各种连接类型和屏幕尺寸. 第二个, 这组流需要格式化为iOS使用HTTP直播(HLS), 而你的桌面流通常是为Flash格式化的. 在过去一个流就足够的地方, 现在，大多数实时事件需要多种格式的多个流.

举个例子, 我最近测试了Brightcove的Live Video Cloud平台, 它提供了8个直播流, Flash和HLS各4个, 综合数据速率为每秒8兆比特(Mbps). 大多数权威机构建议将出站带宽开销控制在30-100%之间，以在整个事件期间维持传输. 如果我在现场制作这些流，我需要10个.4和16Mbps的出站带宽，如果可以获得，这将是非常昂贵的.

那么如何在带宽或预算有限的环境中传输这些流呢? 您必须在选择服务和技术时考虑到这个问题.

图1. 在YouTube上，你发送一个流被YouTube转码成多个流.

当然，关键问题是这些流从哪里产生. 回到早期的直播活动, the delivery schema was simple; you created a stream onsite, 传输到流媒体服务器, 是什么使那条小溪原封不动. 今天的一些服务仍然遵循这种模式, 这意味着您传送的流的数量受到出站带宽的限制.

其他服务使用一种称为实时云转码的技术来接受来自事件设施的单个流，并将其实时转码为所需的流. 例如，在我对Brightcove视频云的测试中，我发送了一个720p的视频.5Mbps的流到Brightcove的服务器，它将流转换为8次迭代. 因为我的办公室有5Mbps的出站带宽，所以这不是问题. Onstream Media在他们的网络广播服务中使用了类似的方案, 海视的视频云服务和YouTube的YouTube Live也是如此.

这种方法的一个辅助好处是，它最大限度地减少了您的现场编码器的成本. 我一直在用Telestream Wirecast进行大量测试, 哪一个可以在4核HP Z400工作站上轻松创建单个720p文件, 但Adobe免费的Flash Live Media Encoder也可以.

图2. 在转播画面, 您将所有编码流发送到服务, 哪些会增加出站带宽需求.

如果你有自己的流媒体传输系统, 您可以通过多种方式复制此功能. 例如, 大多数流服务器可以为其他交付平台转换传入流, 接收Flash流并输出HLS和Flash, 并将您的出站带宽需求减少一半. Or, 使用像Wowza Transcoder这样的产品, 您可以创建自己的服务器或基于云的转码工具，并进一步降低出站带宽需求.

These alternatives make early planning critical; you not only have to determine how many streams you’ll be delivering, 而是它们将在哪里被创造出来. 这将告诉您将从您的实时事件设施中推出多少流, 以及支持它们所需的带宽.