HTTP Live Streaming 使用 Wowza 和 CDN 进行现场直播 - 如何进行？
我想在定制的应用程序中向 iOS 设备直播一个活动。应用程序位已排序，直播视频流本身也是如此，但我如何将源从我的 Wowza 服务器获取到具有足够带宽和带宽的 CDN？ grunt 支持 1,000 多个用户？
所以我想到的过程如下：
几台摄像机通过 HD-SDI 连接到 Blackmagic ATEM 切换台。
Switcher 的 HDMI 输出连接到带有 Intensity Pro HDMI 采集卡的 PC，馈入 Wirecast，生成高比特率 MPEG2 流。
第二台 PC 运行 Wowza Media Server，生成 Apple 建议用于 HLS 的 9 个左右 H264 流。
H264 源发送到 CDN，索引文件包含 9 个源的 URL。
困扰我的步骤是最后一步 - 如何将 H264 源获取到 CDN？某种批处理 FTP 进程？来自 CDN 的 API？我不太确定！
I've got an event I want to broadcast live to iOS devices within a custom made app. The app bit is sorted, as is the live video stream itself, but how do I get the feed from my Wowza server to a CDN with enough bandwidth & grunt to support 1,000+ users?
So the process I have in mind is as follows:
Couple of cameras hooked up via HD-SDI to a Blackmagic ATEM switcher.
Switcher's HDMI output hooked up to a PC with an Intensity Pro HDMI capture card, fed into Wirecast, which produces a high bitrate MPEG2 stream.
A 2nd PC running Wowza Media Server which produces the 9 or so H264 streams Apple recommends for HLS.
H264 feeds sent to a CDN with the index file containing URLs of the 9 feeds.
The step troubling me is the last one - how do I get the H264 feeds to a CDN? Some sort of batch FTP process? An API from the CDN? I'm not really sure!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
每个 CDN 可能都不同。
您将专门寻找一种可以进行 HTTP 实时流传输或至少可以快速传播平面文件的产品。为什么？一旦发生分段，h264 编码基本上与发布流无关。 HTTP Live Streaming 的核心是，在分段之后，只是静态提供一堆普通文件。神奇之处在于分段，而不是文件的分布。 （我知道 Wowza 有一个 RTMP 推送模块，但这在这里没有帮助。）
也就是说 1000 多个用户并不是一个疯狂的数字。特别是对于 iOS 设备，因为它们不会占用太多带宽。您真正需要多少带宽？我们假设平均速度为 512kbps。 ：96kbps、256kbps、384kbps、512kpbs、768kbps 甚至 1024kbps。设备本身会调节其质量。在许多蜂窝网络上，它们不会达到最大。）
（使用 iOS 设备，您应该以多种质量进行流式传输。例如 您的客户端连接足够好，可以说它们不是全局的，您可以轻松地在一台半像样的机器上完成此操作1gbps 互联网馈送和高质量对等互连——所有这些都无需将 CDN 加入其中的成本、复杂性或麻烦。
公然自我推销：如果您的直播对象主要是欧洲客户，我的公司可以为您做到这一点。我们有一条 10Gbps 线路。 :)
Each CDN is likely to be different.
You'll be looking specifically for one that can do HTTP Live streaming, or at least rapid propagation of flat files. Why? The h264 encoding is basically irrelevant to publishing the stream once the segmentation has occurred. HTTP Live Streaming it, at it's core, after segmenting, just a bunch of normal files served up statically. The magic is in the segmenting, not the distribution of the files. (I know Wowza has an RTMP push module, but that wont' help here.)
That said 1000+ users is not an insane number. Especially to iOS devices, as they won't be that bandwidth intensive. How much bandwidth do you really need? Let's assume an average of 512kbps. (With iOS devices you should be streaming in multiple qualities. Eg: 96kbps, 256kbps, 384kbps, 512kpbs, 768kbps and maybe 1024kbps. The devices themselves will regulate their quality. Over many cellular networks they won't be maxing out.)
If know your client connections well enough to say they aren't global they you easily could do this on a single half decent machine with a 1gbps Internet feed and quality peering--All without the cost, complications, or hassle of a throwing a CDN into the mix.
Flagrant self promotion: If you are streaming to mostly European clients, my company could do it for you. We have a 10gbps line. :)
正如 Stu 指出的那样，Wowza Push Publish 文章对 HLS 没有帮助，因为它只支持 RTMP。另一方面，EC2 上的单个 Wowza 实例可以在某些较大的实例类型上处理 750M，并且可以为您即时进行转码。
As Stu pointed out, the Wowza Push Publish piece won't help you on HLS, as it only supports RTMP. On the other hand, a single Wowza instance on EC2 can handle 750M on some of the larger instance types, and can do the transcoding on the fly for you.