java - 使用HTTP进行实时音频流传输-选择协议(protocol)和Java实现

Question

我正在尝试实现简单的实时音频http服务器（在java中）。假设有一个网站，在那里你可以看到一系列正在播放的歌曲。当客户端连接到服务器时——比方说在歌曲中间——我想使用“range”http头并从歌曲的那部分开始发送数据范围。但是，如果在下载连接过程中暂时丢失（并且歌曲已完成），服务器应该发送上一首歌曲并完成它，还是应该发送正在播放的歌曲的那些部分？什么是最佳实践/原则？
PS-我不想找第三方的音频流软件。
编辑：
在对现有的实时流媒体技术进行了一些研究之后，
我看到了这些目标：
一。简单实时音频流的协议选择
2.Java协议实现（服务器端）

Answer 1

你不能任意地剪切媒体，期望播放器能够播放它。这适用于裸mpeg流，但其他容器和编解码器可能会有问题。因此，除非客户机已经拥有部分文件，否则不要发送部分文件。
你也有一个问题，那就是当歌曲结束时，你要做什么。
有两种方法可以实现这一点。其中一个方法是让客户机可以使用静态媒体，然后在音频客户机端寻找正确的时间。
我会选择的方法是真正创建一个互联网广播流，在这里每个人同时听到相同的东西，因为你有效地有一个共同的缓冲区，块是从复制和发送到所有客户机大约在同一时间。现在，如果您这样做，您要么需要使用支持任意拼接（MP3或AAC）的编解码器/容器，要么在将流发送到客户端时用容器重新包装流。这是一个复杂的问题，所以最好用现成的东西来解决，比如冰镇。我知道你说你不是在寻找第三方解决方案，但这是最好的办法。如果你想自己完成所有的工作，你必须重新实现所有的工作，或者只支持mpeg流。
编辑：来自您的评论：
您能解释一下数据流格式吗，它是[24576字节的流][元锁][24576字节的流][元锁]等等。如何分隔块，元块的内容是什么？
如果愿意，可以将mux shoutcast样式的元数据放入流中。不是所有的客户都支持这一点。如果是，他们将在请求中向您发送以下标题：

Icy-MetaData: 1

如果看到该头和值，则可以选择在流中包含元数据。元数据只是在每个流数据块之后注入。要包含元数据，首先需要确定流块的大小。相隔太远，元数据将无法与流很好地对齐。太近的距离在理论上是在浪费带宽（但不会太多，因为不变的元数据块只有一个字节长）。我通常用8kb。16kb有时32kb并不少见。在响应头中输出块大小、元数据间隔：

Icy-MetaInt: 8192

要开始工作，请向客户端发送8192字节（8KB）的音频流数据。
现在是创建元数据块的时候了。以字符串开头，如下所示：

StreamTitle='This is my stream title';StreamUrl='';

您可以传入streamurl甚至其他字段，但现在只有streamtitle才真正被客户端使用。（ StreamUrl过去有能力通过大写字母或其他方式弹出浏览器，我不记得确切的触发器是什么。然后将这个字符串转换为一个缓冲区，并将空字节（ 0x00）填充到最接近的16个可整除块。也就是说，如果元数据块的字符串版本是51字节长，则需要它是64字节长，以便添加13字节的 NUL填充。
关于字符集的简短说明。许多客户机在其元数据中支持utf-8。有些则没有。另外，如果必须在元数据中使用撇号 '，则需要对其进行转义。不幸的是，似乎没有一个真正标准的方法来做这件事。反斜杠有时有效。重复这个角色有时会奏效。不同的玩家工作方式不同。尝试一下winamp，看看它喜欢什么，因为那将是尽可能“正式”的。其他一切都可能只是一个坏客户。（如果您想变得非常狡猾，可以从 User-Agent请求头确定客户机并相应地调整转义。）
既然已经有了元数据块，只需要在它的前面添加一个字节来指示它的长度，除以 16。因此，如果我们现在有一个64字节的元数据，我们将把字节 0x04添加到它的前面，这表明我们的元数据是64字节长的。这总共提供了一个65字节的元数据块，我们现在发送给客户端。把它寄出去。
从这里开始，我们只需再次进入循环，在插入元数据之前再发送8KB的流数据。不过，这次由于我们不想更改元数据，所以只发送 0x00作为元数据块。同样，由于第一个字节表示块的长度，并且我们不更新标题，所以告诉客户机长度是 0。我们只在事情发生变化时发送字符串。