RTMP摄取块流的问题

Cha*_*lie 8 objective-c rtmp chunking wowza twitch

我正在尝试为我正在处理的应用程序构建自己的客户端RTMP库.到目前为止,一切都已成功,因为我能够连接到RTMP服务器协商握手,然后发送所有必要的数据包(FCPublish Publish ETC)然后从服务器获取NetStream.Publish.Start的onStatus消息,这意味着我成功地让服务器允许我开始发布我的实时视频广播.Wireshark还确认信息(/数据打包)是正确的,因为它也正确显示.

现在我遇到麻烦的地方是RTMP Chunking,第17页和第18页的Adobe RTMP规范显示了一个消息如何分块的示例.从这个例子中我可以看出它是根据块大小(128字节)分解的.对我来说,块大小在初始连接和交换中协商,总是4096字节.因此,当我交换大于4096字节的视频数据时,我需要将消息分块,然后发送RTMP packetHeader并结合前4096字节的数据,然后发送一个小的RTMP头,即0xc4(0xc0 | packetHeaderType(0x04))结合4096字节的视频数据,直到发送了标头指定的完整数据包.然后进入一个新框架并重复相同的过程.

通过检查用不同语言编写的其他RTMP客户端示例,这似乎就是他们正在做的事情.不幸的是,我尝试传输的摄取服务器没有接收广播视频数据,他们不关闭我的连接,他们只是从不显示视频或视频是正确的任何迹象.Wireshark显示,在发送视频原子数据包之后,发送的大多数数据包都是未知(0x0)一点点,然后它们将切换到视频数据,并在显示未知(0x0)和视频数据之间进行触发.但是,如果我将有效负载最大大小限制为20000字节,Wireshark会将所有内容显示为视频数据.显然,摄取服务器不会在这种情况下显示视频,因为我正在删除大块的数据,因为它只有20k字节.

试图弄清楚出了什么问题我开始了另一个xcode项目,它允许我在我的Lan上欺骗RTMP服务器,以便我可以看到libRTMP IOS进入服务器时的数据.同样使用libRTMP,我可以记录它发送的数据包,它们似乎注入字节0xc4甚至128字节,即使我已经发送Change Chunk size消息作为服务器.当我尝试在我的RTMP客户端库中通过使用128块大小来复制它时,即使它被设置为4096字节,服务器也将关闭我的连接.但是,如果更改libRTMP以尝试转到实时RTMP服务器,它仍会在LibRTMP中打印出它正在以128的块大小发送数据包.并且服务器似乎在视频显示时接受它.当我查看RTMP服务器上的数据时,我发现它就是他们的全部.

任何人都知道会发生什么事吗?

ful*_*els 3

虽然我没有专门使用 RTMP,但我非常广泛地使用 RTSP/RTP/RTCP,因此,根据这些经验和我一路走来的挫败感,这里有一些随机的、可能适用的技巧,可能会有所帮助/要查找的内容可能会导致问题:

  1. 您的视频编码与您告诉服务器的内容匹配吗?换句话说,如果您的视频编码为 H.264,这是您向服务器指定的吗?
  2. 数据是否与服务器期望的容器格式匹配?例如,如果服务器期望接收 MPEG-4 电影 (.m4v) 文件,但您仅发送编码的 MPEG-4 (.mp4) 流,则需要将 MPEG-4 视频流封装到MPEG-4 电影容器。相反,如果服务器只期望单个 MPEG-4 视频流,但您要发送封装的 MPEG-4 电影,则需要将 MPEG-4 流从其容器中解复用并仅发送该内容。
  3. 您是否考虑过传输介质的 MTU?无论块大小如何,客户端和服务器之间的 MTU 不匹配可能很难调试(这可能就是为什么您会收到一些数据包列为“未知”类型而其他数据包列为“视频数据”类型的原因)。只要 MTU 一致,大多数操作系统的内置分段和重组 (SAR) 基础设施就能解决大部分问题,但在您必须执行自己的 SAR 逻辑的情况下,很容易得到这个错误的。
  4. 您是否尝试过使用 libRTMP iOS 和您自己的客户端在 Wireshark 中捕获流量并并排比较数据包?有时,“参考”数据包跟踪对于发现最初看起来不重要的一点点(或很多)数据包跟踪非常有价值。

祝你好运!