我应该使用哪种协议来播放音频（不是直播）？ [英] Which protocol should I use for streaming audio (not live)?

问题描述

我正在尝试编写一个Python服务器，从头到尾流式传输一个请求的mp3文件。 （没有直播）

我希望能够使用任何媒体播放器（如VLC）播放该流，并且能够改变播放位置。

I'm trying to write a Python server that streams one requested mp3 file from start to end. (No live streaming)
I'd like to have the functionality to play that stream with any media player (like VLC) and be able to change playback position.

我听说过很多关于HTTP Streaming的内容，但在阅读了一些维基百科文章之后，在我看来，HTTP Streaming只是不同流媒体协议的一个总称，如 RTSP / RTCP / RTP 。

I've heard a lot about HTTP Streaming, but after reading a few wikipedia articles it seems to me that 'HTTP Streaming' is just an umbrella term for different streaming protocols such as RTSP/RTCP/RTP.

然后我遇到了 SHOUTcast 这是一个专有软件（服务器！），用于使用它的流媒体自己的协议。另一个似乎提供类似功能的现有服务器程序是 Icecast 。

I我不太确定SHOUTcast和Icecast之间的关系，但似乎有一个。

Then I came across SHOUTcast which is a proprietary software (server!) for streaming media using its own protocol. Another existing server program which seems to offer similiar functionality is Icecast.
I'm not really sure on the relationship between SHOUTcast and Icecast, but there seems to be one.

我认为流式传输一个特定的媒体文件与流媒体文件不同像网络收音机这样的连续流，所以我用Google搜索了第一个webradio并下载了.pls或.m3u文件。

两者基本上都是包含网址的文本文件。所以我开始使用wireshark并将VLC指向该URL。

我看到的主要是HTTP流量：

I figured streaming one specific media file couldn't be that different from streaming a continuous stream like a web-radio so I googled the first webradio and downloaded a .pls or .m3u file.
Both basically were textfiles containing a url. So i started wireshark and pointed VLC to that url.
What I saw was essentially HTTP Traffic:

VLC：

GET /schizoid HTTP/1.1

VLC：

Host: <ip>:8000
User-Agent: VLC/2.0.5 LibVLC/2.0.5
Range: bytes=0-
Connection: close
Icy-MetaData: 1

服务器响应：

HTTP/1.0 200 OK
Content-Type: audio/mpeg
icy-br:128
ice-audio-info: bitrate=128
icy-br:128
icy-description:PsyTrance 24x7
icy-genre:psytrance
icy-name:Radio Schizoid
icy-pub:1
icy-url:http://schizoid.in:8000/schizoid
Server: Icecast 2.3.2
Cache-Control: no-cache
icy-metaint:16000

然后服务器开始发送原始数据，这似乎是mp3流。

Then the server begins sending raw data, which seems to be the mp3 stream.

根据维基百科是SHOUTcast协议。

（我不确定这是否与Icecast使用的协议相同）

According to Wikipedia this is the SHOUTcast protocol.
(Im not sure wether this is the same protocol that Icecast uses)

但我认为已关闭（未记录）协议不可能成为流媒体的标准。

所以我的问题是将流媒体（特定的mp3文件）集成到python服务器中的最佳（最简单和最好的支持）方式？

我是否必须手动实现SHOUTcast协议或类似于RTP要走的路？

（我不介意使用第三方库）

But I figured a closed (not documented) protocol couldn't possibly be the standard for streaming media.
So my Question is what's the best (easiest and best supported) way to integrate streaming (specific mp3 files) into a python server ?
Do I have to manually implement the SHOUTcast protocol or is something like RTP the way to go?
(I don't mind using a third-party library)

推荐答案

SHOUTcast客户端协议实际上与HTTP / 1.0相同。唯一相关的区别是响应状态行：

The SHOUTcast client protocol is effectively the same as HTTP/1.0. The only relevant difference is the response status line:

ICY 200 OK

而不是 HTTP / 1.0 ，你得到 ICY 。真的是这样的！从那里，它的行为相同。 Web浏览器和大多数HTTP客户端忽略了这一点。 Android上扼杀它和一些浏览器，但大多数都很好。 Icecast的客户端流行为与SHOUTcast相同，只是它实际上为其状态行返回 HTTP / 1.0 200 OK 。

Instead of HTTP/1.0, you get ICY. That's really it! From there, it behaves the same. Web browsers, and most HTTP clients ignore this. Android chokes on it, and some browsers, but most are fine. Icecast's client stream behavior is the same as SHOUTcast's, except that it actually returns HTTP/1.0 200 OK for its status line.

现在，您已经注意到这些响应标头中有一些带有流信息的额外标头。除了一个之外的所有信息都只是额外的信息，对您正在获取的数据没有任何影响。如果你没有请求元数据，那么服务器什么也不做，只是从源发送给它的每个字节，并将其中继到每个客户端（也有一点服务器端缓冲区）。

Now, you have noticed in those response headers, there are some extra headers with stream information. All but one are just extra information that don't have any impact on the data you're getting back. If you request no metadata, then the server does nothing but take every byte sent to it from the source, and relay it on to each client (with a little server-side buffer as well).

如果在您的请求标题中指定了 Icy-MetaData：1 ，则行为稍有变化。在回复中，您将获得 Icy-MetaInt：8192 或类似信息。这意味着每8,192个字节，就会有一大块元数据。有时该块只是 0x00 ，这意味着没有元数据更新。其他时候会有像 0x01 这样的字节。如果将该值乘以16，则知道接下来的16个字节将是ASCII元数据，如 StreamTitle：'My Stream'; StreamUrl =''; ，填充 0×00 。如果您感到好奇，我已经在另一篇文章中详细介绍了元数据。

If in your request headers, you specify Icy-MetaData: 1, then the behavior changes slightly. In the response, you will get Icy-MetaInt: 8192 or similar. This means that every 8,192 bytes, there will be a chunk of metadata. Sometimes that chunk is just 0x00 which means that there is no metadata update. Other times there will be a byte like 0x01. If you multiply that value by 16, you know that the next 16 bytes will be ASCII metadata, like StreamTitle: 'My Stream';StreamUrl='';, padded by 0x00. I've described the metadata in more detail in another post, if you are curious.

所有这一切都说最流行的流媒体协议实际上是HTTP，而SHOUTcast / Icecast /许多其他服务器都添加了一个请求标头，您可以在其中将元数据交错到流中。不请求元数据的HTTP客户端只会获得常规的MP3流，浏览器会认为这只是某个文件。毕竟，浏览器并不关心你如何获得数据。

All of this to say is that the most popular streaming protocol is in fact HTTP, and SHOUTcast/Icecast/many other servers have added a request header where you can get metadata interleaved into the stream. HTTP clients that don't request that metadata will just get a regular MP3 stream, which a browser will think is just some file somewhere. Afterall, the browser doesn't care how you get the data.

现在，你应该使用什么？您的要求：

Now, what should you be using? Your requirement:

我正在尝试编写一个从头到尾流式传输一个请求的mp3文件的Python服务器。 （没有直播）

I'm trying to write a Python server that streams one requested mp3 file from start to end. (No live streaming)

HTTP就是你所需要的。实际上，没有必要为此编写一些服务器。 Apache / Nginx /什么都可以正常工作。只是一个简单的HTTP服务器！如果你想通过ID提供文件，那就是你的Python所在的地方。根据该ID，编写一些可以从磁盘中获取相应资源的内容。我不打算使用RTSP ...这对你需要的东西来说太多了，你会损害客户兼容性。

HTTP is all you need. In fact, no need to write some server for this. Apache/Nginx/whatever will work fine. Just a simple HTTP server! If you want to serve up files by ID, that's where your Python comes in. Write something that goes and fetches the appropriate resource from disk, based on that ID. I wouldn't bother with RTSP for this... that is way too much overhead for what you need, and you will be hurting client compatibility.

我希望能够使用任何媒体播放器（如VLC）播放该流，并能够更改播放位置。

I'd like to have the functionality to play that stream with any media player (like VLC) and be able to change playback position.

对于该要求，请确保您的服务器支持范围请求。客户将处理剩下的事情。

For that requirement, just make sure your server supports range requests. The client will take care of the rest.

• SHOUTcast / Icecast服务器用于实时类似无线电的流，其中所有客户端在（大致）同时获得相同的音频流


• HTTP是用于提供任何内容的最兼容的协议客户端，流媒体与否


• RTSP / RTMP / RTP以及所有相关协议都不是必需的，除非您正在流式传输长时间运行或实时流，其中基于客户端带宽可用性的可变比特率很重要。 （这些协议还有其他功能，但这似乎是选择它们的决定性因素。如果你想了解更多信息，我建议你仔细阅读。）

这篇关于我应该使用哪种协议来播放音频（不是直播）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！