Streaming 如何制作实时音频流网站？

我一直想做一个实时音频流服务，有点像twitch。现在，在你说这太难了，应该只使用一个已经存在的服务之前，我真的很想知道如何从根本上做到这一点。我做了一些研究，但我发现的结果非常模糊，或者说是指向Wowza之类的东西。我看过一些关于HTTP直播的内容，我想我理解了其中的大意：麦克风/摄像机将其提要发送到编码器，编码器将其以m3u8格式发送到服务器，人们将m3u8文件从服务器流到设备。但我该怎么做呢？这背后的实际编程是什么？是否需要使用Wowza或Red5之类的服务

我做了一些研究，但是我发现结果非常模糊

不幸的是，你问了一些非常模糊的问题，这就是为什么你会得到模糊的答案。让我试着把你的问题分成几部分。如果你对细节有疑问，你应该发布一个单独的具体问题，然后在评论中链接到它

是否需要使用Wowza或Red5之类的服务

这些不是服务（Wowza提供了一些），而是处理流媒体的服务器。它们获取您的源流并有效地将其转发给您的所有侦听器。是的，你需要某种服务器，通过互联网将你的流媒体发送给人们，而不需要是Wowza或Red5。根据您的具体需要，还有许多其他方法可以做到这一点

让我们讨论一个更简单的方法。。。HTTP渐进式流媒体。您的客户端（网络浏览器、应用程序、互联网收音机等）可以在接收音频流时播放音频流。他们不知道也不在乎它是活的。。。他们所知道的是，他们发出了一个HTTP请求，收到了足够的数据进行播放，然后开始播放。他们也不知道也不关心来源是什么。。。无论是转码到流中的文件还是对着麦克风说话的人。这无关紧要。在这种模式下，互联网广播流基本上就像一个似乎永远不会结束的音频文件。如果您查看SHOUTcast或Icecast，HTTP progressive是他们所使用的协议

对于编码器，原始音频必须来自某个地方，例如音频捕获设备（麦克风、混音器等）或一组音频文件。原始音频数据（通常为PCM）使用编解码器（如MP3）进行编码。现在，该编解码器的输出通过HTTP PUT请求发送到服务器（如果您使用的是Icecast…hacky其他方法用于SHOUTcast，而SOURCE用于旧的Icecast）。服务器接收这些数据，保留一个小的缓冲区，并将其副本发送给连接的客户端

如果您正在播放MP3，服务器只需在数据输入时将数据发送回客户端。其他容器格式（如Ogg）要求在流捕获之前首先发送头。此时，服务器基本上动态地将流数据多路复用到每个客户机的容器中。（通常，这是通过构建标头来完成的，然后在流的其余部分的正确点进行拼接。）

HTTP渐进式流媒体的优势在于，它可以在浏览器中开箱即用，与新旧设备兼容（我的旧Palm Pilot可以很好地播放它们），并且只需要很少的服务器资源

我看过一些关于HTTP直播的东西

HLS是可用的协议之一。不是像HTTP progressive那样持续运行的流，而是一次记录几秒钟的编解码器输出，保存一块数据，然后将其上载到服务器。然后，客户端可以按顺序下载这些块并播放它们。这种方法有很多开销，但人们选择它有一些关键原因：

• 客户端可以在段中断时切换到不同的流。如果客户端正在流式传输一些高清视频，但随后发现它没有足够的带宽来支持它，那么它可以开始下载SD视频。编码器通常配置为以各种比特率提供块。HLS使用的容器格式支持这种直接流连接，因为编解码器基本上是被告知的，以确保流在这些点是可拼接的

• HLS不需要特殊的服务器。您可以通过SFTP或任何您通常使用的方法将文件上载到web服务器。除了网页通常需要的内容外，没有其他内容可供安装

• 由于您将数据存储在服务器上，因此如果客户机能够处理数据并且您有足够的磁盘空间，您可以自动支持及时回放

• CDN分布。如果您想在S3存储桶前面使用Cloudfront之类的东西，您可以，AWS不必以任何不同的方式来支持您，就像您分发任何其他文件一样

然而，对HLS的一大负面影响是客户支持。虽然HTTP渐进式流媒体技术自HTTP以来一直有效地存在，但HLS是一种新技术，客户端并不擅长于此。浏览器不直接支持它，需要使用MediaSourceAPI和一些手工JavaScript来处理播放。依赖标准框架的移动应用程序经常遇到麻烦。。。特别是Android 3.0有一些非常讨厌的HLS错误。随着时间的推移，情况越来越好

还有另一个类似的协议，我不想讨论，但它是MPEG DASH。分割的完成方式与HLS类似，它正在迅速消耗HLS在现实世界中的使用

但我该怎么做呢？这背后的实际编程是什么

你必须把这个问题分解成几个部分来决定你想要实现什么。具体做什么？你想做一个编码器吗？做服务器