使用 PHP 重新流式传输 Shoutcast/Icecast 流

Question

我需要以某种方式使用 PHP 重新流式传输 Shoutcast/Icecast 流。

为什么？

因为 Shoutcast/Icecast 流不是 https。而且它不是通过80和443端口发送的，而是通过一些不同的奇怪端口发送的。而且我需要普通/标准端口（如 80 或 443）上的 https 链接。这是最大的原因，尽管我认为还有一些更多但不太重要的原因。

这些链接类似于http://hostname.com:5921/stream，而我需要https://hostname.com/stream?user=x 之类的链接。

我进行了深入研究，但没有发现太多。

我发现了类似的东西：

https://stackoverflow.com/questions/7998773/is-it-possible-to-restream-an-internet-radio-using-php-php-guru-needed
https://www.svnlabs.com/blogs/radio-icecast-shoutcast-php-proxy-to-re-stream-radio-stream-on-https/
https://stackoverflow.com/questions/36306457/read-mp3-stream-and-echo-back-to-client-in-php

目前我从所有资源和我自己的尝试中收集到的最好的代码是：

$link = 'http://shoutStreame.streamland.com/proxy/radioGame?mp=/1'; //example link to a Shoutcast stream (not working, only example)

ob_start();
header("Content-Transfer-Encoding: binary");
header("Content-Type: audio/mpeg, audio/x-mpeg, audio/x-mpeg-3, audio/mpeg3");
header('Content-Disposition: attachment; filename="stream.mp3"');
header('X-Pad: avoid browser bug');
header('Cache-Control: no-cache');
$handle = fopen($link, 'r');

while (($data = fread($handle, 1024))) {
    echo $data;
    ob_flush();
    flush();
}

而且这段代码似乎不是……很好？优秀吗？

我只是觉得我用这段代码做错了，效率不高，可能会导致问题。

我主要担心的是：

• 效率，尤其是在许多请求下
• 法律问题？以这种方式做事有什么真正的问题吗？使用 php 重新流式传输？
• 崩溃问题？像整个 php、nginx 甚至机器的崩溃？
• 失去连接，像这个 php 脚本会在一段时间后死掉或什么的

也许还有更多。

我真的很难找到更多关于使用 PHP 重新流式传输音频流的特定主题的资源、数据和信息。

现在我真的不知道该怎么办。我只是在研究和思考，但正如我所说，真的很难找到更多关于这个话题的东西。这是我目前唯一的代码，我不知道它是否好用...... :)

Answer 1

因为 Shoutcast/Icecast 流不是 https。

错误！ Icecast 支持 HTTPS 就好了。查看配置文件中的<ssl-certificate> 标签。 http://www.icecast.org/docs/icecast-2.4.1/config-file.html

而且它不是通过80和443端口发送的，而是一些不同的奇怪端口。

也是假的！ SHOUTcast 和 Icecast 都可以配置为在您想要的任何端口上运行。大多数站点使用标准端口，您也可以。

这些链接类似于http://hostname.com:5921/stream，而我需要https://hostname.com/stream?user=x 之类的链接。

为什么你需要这样做？可能最简单的做法是从您的脚本重定向到/stream 的流 URL。这将满足大多数需求。

您的所有技术问题都是有效的。我绝对不建议通过 PHP 中继流。随着你正在做的事情，你每次都会导致上游连接，而且真的没有任何好处。此外，如果您代理连接，Icecast 中存在一些客户端兼容性漏洞，您会丢失这些漏洞。