Question

我尝试在java中创建音频流服务器。流媒体有几种协议，如RTP，我对所有协议都有些困惑。

RTP和Shoutcast之间有什么区别？他们使用TCP，UDP还是HTTP？有没有人对这一点有明确的解释？

Answer 1

SHOUTcast和Icecast使用非常类似于HTTP的客户端协议。（实际上，Icecast在RFC2616中符合HTTP规范，大多数HTTP客户端都可以在不修改的情况下使用SHOUTcast。）一个请求进入流，它们返回流音频数据的方式与HTTP响应以及一些额外的元数据。

GET /radioreddit/main_mp3_128k HTTP/1.1

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With
Server: AudioPump Server/0.8.1 (http://audiopump.co)
Content-Type: audio/mpeg
Cache-Control: no-cache
Pragma: no-cache
Expires: Sat, 15 Aug 2009 22:00:00 GMT
Connection: close
icy-genre: Indie,Rock,Talk
icy-name: Radio Reddit - Main
icy-pub: 1
icy-url: http://radioreddit.com
Date: Tue, 05 Aug 2014 13:40:55 GMT

在此示例中，响应纯粹是HTTP。如果这是SHOUTcast服务器，而不是在状态行中看到HTTP/1.1 200 OK，您会看到ICY 200 OK。以icy-开头的标头是描述电台的标头。有时会有更多，有时根本不存在。客户端可以按原样播放该电台的MP3数据。

现在，有时客户端将请求在流中发送元数据。这允许玩家告诉你正在播放的内容。客户端通过发送icy-metadata: 1标头来执行此操作。服务器将以icy-metaint: 8192响应，这意味着每8192个字节将有一块元数据。你可以read more about the format of that metadata on a previous answer。

我还应该注意，这种形式的流通常称为HTTP Progressive Streaming。对于客户来说，它与正在下载的媒体文件没有什么不同......除了文件的大小无限。

现在，RTP是与RTSP结合使用的协议。 RTP是RTSP用于控制的实际媒体数据。这些协议要复杂得多，因为它们适用于真正的流媒体。也就是说，如果客户端无法处理带宽，则可以降低到较低的比特率。如果客户端需要控制远程，也可以这样做。这种复杂性是有代价的。服务器实现起来很复杂。客户端兼容性不高。

几年前，当我开始创建自己的流媒体服务器时，我问自己同样的问题。我是否实现了一个真正的流媒体协议，它没有那么好的客户端支持，需要很长时间才能弄清楚，或者我实现了一切都可以播放的协议，而且很容易构建。我走了HTTP路线。

现在，您还应该考虑HLS，这只不过是将您的源流分成若干比特率并通过HTTP提供服务。如果客户端由于缺乏带宽而想要改变比特率，则它可以开始请求低比特率块。 HLS也没有很好的客户支持，但它正在变得更好。我怀疑它会及时超过所有其他网站上的媒体传播。

Answer 2

RTP（协议）与Shoutcast（应用程序）之间的比较不适用。

RTP是通过IP传输多媒体的互联网标准。

这是一个应用层协议，因此RTP可以通过TCP或UDP传输，具体取决于通信的性质。此外，它需要在应用程序可以有任何用途之前实现，就像HTTP必须由浏览器实现，以便用户可以访问网页。当由应用程序实现时，它用于指定媒体格式，许多其他特征和基本控制信息（通过RTSP）。

Shoutcast是由Nullsoft（Winamp作者）创建的流媒体应用程序。它使用自己的媒体传输协议，可以在TCP或UDP上运行。

还有许多其他流媒体协议，因此对该主题进行Google搜索通常是一个好主意。 Wikipedia还会托管comparison of streaming media systems。

流媒体RTP和Shoutcast

2 个答案: