RTMP摄取块流的问题

Question

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

现在我遇到的问题是 RTMP 分块，第 17 页和第 18 页上的 Adobe RTMP Specification 显示了一个消息如何分块的示例。从这个例子中，我可以看到它是根据块大小（128 字节）分解的。对我来说，块大小在初始连接和交换中协商，始终为 4096 字节。因此，当我交换大于 4096 字节的视频数据时，我需要将消息分块发送 RTMP packetHeader 与前 4096 字节数据相结合，然后发送一个小的 RTMP 标头，即 0xc4 (0xc0 | packetHeaderType (0x04))与 4096 字节的视频数据相结合，直到发送了报头指定的完整数据包。然后一个新的帧进来，重复同样的过程。

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

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

有人知道会发生什么吗？

Answer 1

虽然我没有专门使用 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 中捕获流量并并排比较数据包？有时，“参考”数据包跟踪对于发现最初看起来并不重要的一点点（或很多点）非常宝贵。

祝你好运！