RTCP / RTP通信问题

时间:2012-02-23 17:07:14

标签: c++ udp rtsp rtp rtcp

不幸的是,我仍然坚持使用一点RTP / RTCP通信来正确访问我的IP摄像头。

我想做什么

相机有一个我想读的内部缓冲区。因此,我通过RTSP与相机通信,并告诉它流式传输数据。当摄像机通过整个缓冲区时,流媒体将停止。

到目前为止我有什么

  1. 通过RTSP与DESCRIBE / SETUP / PLAY请求(RTSP)进行通信的TCP连接,以启动流。当相机流式传输数据时,此连接必须保持打开状态。

  2. 我收到通过RTP发送的数据的端口(基于UDP) - 处理这个并不是我关心的问题,我甚至完全无法访问它,我只想提及它是为了完整性。

  3. 接收RTCP Sender Reports / Source Descriptions的UDP套接字。这很重要,因为我不知道流何时停止(如第2点所述,我不能只看流停止时)。在这个Socket上我读到RTCP Sender Report Goodbye,这意味着流已经完成。然后我可以关闭TCP套接字(来自RTSP 通信)。

  4. 出了什么问题

    适用于2MB或4MB等小缓冲区。我收到一些来源说明,然后是Goodbye。但在我的特定测试案例中,我想使用16MB(仍然不到相机能力的一半)。 我收到发件人报告,但在某些时候(总是大约8MB +/- 300KB),相机才停止发送。

    值得注意的是,我可以通过VLC访问缓冲区而不会出现问题。我甚至看过通信(RTSP和RTCP),它与我的应用程序几乎完全相同......我想在下面提到一件事:

    可能的原因

    这是我需要你的建议的部分。

    可能性:缺乏接收者报告

    当通过VLC进行流式传输时,我注意到从VLC发送了一些RTCP Receiver Reports到相机(像Sender Reports那样循环)。那么camere是否期望在特定时间内(或在发送特定数量的字节之后)至少有一个Receiver Report? 目前我想不出任何其他原因。

    解吗

    • 如果我们假设相机停止流式传输,因为没有Receiver Reports我想知道是否有办法实现它们而不需要携带太多信息。我已经阅读了一些RFC 3550,我猜这些报告消息背后仍然有一堆逻辑。现在我实际上不需要,所以我也不想要在这里实现完整的RTCP协议。是否足以发送一些Receiver Report虚拟帧,以便相机继续流式传输?如果是这样,他们看起来如何?

    • 如果它与缺少Receiver Reports无关,而我只是不需要它们,那么相机停止流媒体的原因是什么?有什么建议?

    修改

    好吧,我刚刚创建了某种虚拟Receiver Report,它似乎有效(我只能收到12MB,然后我得到了想要的再见)

    我刚填充了一个28Byte缓冲区,只是在Header字段中使用了一些值,意思是:

    buffer[0] = 0x80;   // Version 2 , Padding = false, Reception Count = 0
    buffer[1] = 0xC9;   // Packet Type 201 Receiver Report
    buffer[2] = 0x00;   // Higher byte for total length
    buffer[3] = 0x06;   // Lower byte for total length ( in 32 Bit words -> 28 Byte )
    

    缓冲区的其余部分我只用零填充。是的,我知道这只是一个黑客,你不应该告诉你的孩子这样编程。

    现在我的问题有所改变:这个黑客可以吗?它似乎工作,但我仍然有点担心我的相机将使用这些虚拟数据和更改配置导致它在其中插入一些奇怪的东西?

2 个答案:

答案 0 :(得分:1)

您应该自己从流中读取数据。这样你就可以提供真实的接收者报告,而不是假的报告。

如果您需要将其转发到另一个应用程序或库的另一个端口,您可以这样做。

答案 1 :(得分:1)

某些摄像机可以将接收器报告(RR)用作“保持活动”消息。如果摄像机接受GET_PARAMETER,您可以尝试每分钟向相机发送GET_PARAMETER作为保持活动消息。看看它在回应DESCRIBE时告诉你的内容。

某些IP摄像机无法正确解析RR。我实际上是想阻止我在客户端使用的live555库发送RR消息,因为某些型号的三星相机会断开连接(根据他们的技术支持)。