【问题标题】:Icecast 2: protocol description, streaming to it using C#Icecast 2:协议描述,使用 C# 流式传输到它
【发布时间】:2017-09-08 17:15:57
【问题描述】:

我需要编写一个 Icecast 2 客户端,它能够将音频从计算机(mp3 文件、声卡录制等)流式传输到服务器。我决定在 C# 上编写这样一个客户端。

两个问题:

1) 了解我可能/应该/必须使用的通用准则(最佳实践,也许是技巧)将非常有用,以便在 C# 中无缝处理流式音频(当然是通过网络流式传输)。一些关于通过 TCP/IP 进行流传输的通用技术文档,特别是 ICY,将非常感谢有关应用程序整体架构的建议和注释。

2) 有没有关于 Icecast 2 流媒体协议的好文档?我在 Icecast 的官方网站上找不到这些文档。我不想直接从它的源代码中提取协议描述。如果该协议真的很简单和整洁,有人可以在这里提供它的摘要吗?

【问题讨论】:

标签: c# .net icecast


【解决方案1】:

据我所知,除了 Icecast 源代码之外,任何地方都没有协议规范。这是我从数据包嗅探中发现的:

音频流

协议类似于 HTTP。源客户端将连接到服务器,向挂载点发出请求,并传递一些带有流信息的标头:

SOURCE /mp3test ICE/1.0
content-type: audio/mpeg
Authorization: Basic c291cmNlOmhhY2ttZQ==
ice-name: This is my server name
ice-url: http://www.google.com
ice-genre: Rock
ice-bitrate: 128
ice-private: 0
ice-public: 1
ice-description: This is my server description
ice-audio-info: ice-samplerate=44100;ice-bitrate=128;ice-channels=2

如果一切正常,服务器会响应:

HTTP/1.0 200 OK

然后源客户端继续发送二进制流数据。请注意,似乎有些编码器在开始发送流数据之前甚至不等待服务器响应200 OK。只是标题,一个空行,然后是流数据。

元数据

元数据是使用带外 HTTP 请求发送的。源客户端发送:

GET /admin/metadata?pass=hackme&mode=updinfo&mount=/mp3test&song=Even%20more%20meta%21%21 HTTP/1.0
Authorization: Basic c291cmNlOmhhY2ttZQ==
User-Agent: (Mozilla Compatible)

服务器响应:

HTTP/1.0 200 OK
Content-Type: text/xml
Content-Length: 113

<?xml version="1.0"?>
<iceresponse><message>Metadata update successful</message><return>1</return></iceresponse>

还要注意,音频流和元数据请求都在同一个端口上发送。与 SHOUTcast 不同,这是服务器运行的基本端口。

【讨论】:

  • @JonathanC,没有格式...只发送原始编码的音频数据。您甚至可以在流中的任意位置开始。
  • 这对我来说并不完全清楚。因此,当我以块的形式录制和编码为 mp3 时:我是否为每个原始二进制块放置了这些相同的标头?我不完全清楚的是“只发送原始编码数据”。我是否在 HTTP 请求的正文中发送转储?
  • 我想我的意思是:对于这个原始二进制数据,icecast 期望什么协议?
  • @JonathanC,没有任何预期。连接后发送标头后,您需要做的就是发送编码器输出的数据。标头只发送一次......不是每个块。服务器不太关心格式。它将缓冲数据并按原样发送给客户端。
  • 我明白了。谢谢你的回答。所以这些块是在一个简单的 HTTP 正文中发送的,对吧?我最初以为我必须打开一个套接字连接或其他东西。因此,我发送以下 HTTP 请求,正文是原始二进制数据:“SOURCE /mp3test ICE/1.0 content-type: audio/mpeg”是否正确?
【解决方案2】:

尽管这个问题已经很老了,但我还是要在这里发表评论。

Icecast 符合 HTTP。侦听器端总是如此(简单的 HTTP1.0,RFC 1945),从 2.4.0 开始,源客户端也是如此。

要实现源客户端,它是一个符合 HTTP 1.1 又名 RFC2616 的 PUT 请求。部分选项可以通过 HTTP 头设置,具体请参考当前的 Icecast 文档。

如果您发送一种受支持的容器格式:Ogg 或 WebM(技术上是 EBML),那么这就是您需要知道的全部内容。明确地说,这至少涵盖了 Opus、Vorbis、Theora 和 VP8 编解码器。

请注意,虽然通常可以正常工作,但技术上不支持其他格式。在这种情况下,Icecast 只通过流而不进行任何处理。

如果您需要帮助或有其他问题,那么官方邮件列表和 IRC 频道是您的理想去处。

【讨论】:

  • 你好!很高兴看到 Icecast 现在支持简单的 HTTP PUT 请求。关于 2.4 何时会被认为是稳定的任何想法?而且,有指向此文档的链接吗?除了发布公告,我找不到任何内容。
  • Icecast 2.4.0 于 2014-05-06 发布。当前版本为 2.4.1,修复了许多错误。
【解决方案3】:

很久以前看过 Icecast2:我能找到的最佳参考是 http://forums.radiotoolbox.com/viewtopic.php?t=74 链接(我应该把它打印出来,我花了很长时间才找出正确的谷歌咒语来再次展示它)。它似乎涵盖了源到服务器和服务器到客户端。

关于它的准确度仍然存在问题:在其他事情消耗我之前,我已经完成了 Android 实现的一半,我不太记得我的实现与 VLC/Winamp 之间的通信出了什么问题,但是老实说,这是我能找到的最接近规范的东西。

【讨论】:

  • 请注意,这是针对 SHOUTcast 源协议的。 Icecast 支持一次使用此协议的单一源客户端。 Icecast 有一个单独的源协议,本质上是 HTTP。
  • 规范的网址?很想得到我的手。
  • 你和我都......不幸的是,我没有在任何地方找到它的记录。似乎唯一的文档在源代码中。我刚刚通过数据包嗅探连接来弄清楚它。没那么复杂。您可以在此处查看我的问题第一块中的一般流程:stackoverflow.com/questions/9970679/…
【解决方案4】:

我知道的最好的描述在这里:https://gist.github.com/ePirat/adc3b8ba00d85b7e3870

@ePirat 是 xpiph/icecast 核心提交者。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-11
    • 1970-01-01
    • 2020-05-01
    • 2011-05-20
    相关资源
    最近更新 更多