对于这样一个专门的问题，这可能不是最好的论坛，但目前我不知道哪个更好（可以接受建议/建议）。
我研发的视频产品在过去10多年中一直使用专有通信协议（基于DCOM）通过网络发送视频。不久之前，我们认识到需要进行标准化，目前几乎已经将所有DCOM行李拆除，并将其替换为完全兼容的RTP / RTSP客户端/服务器框架。
我们在过去几个月的测试中注意到的一件事是，当我们将客户端切换为使用RTP / RTSP时，启动延迟会明显增加。问题是它不是我们而是RTSP。
BEFORE（DCOM）：我们将发送一个DCOM命令，在该命令甚至返回到客户端之前，服务器已经在发送视频。 - 总延迟1 RTT
现在（RTSP）：这是命令序列，每个命令都是一个单独的网络请求：DESCRIBE，SETUP，SETUP，PLAY（假设会话有音频和视频） - 总共4个RTT。
按设计工作 - 不幸的是，感觉就像倒退了一步，因为之前的用户体验确实更好。
这可以改善吗？如果你坚持标准，简短的回答是，不。但是，我的团队完全控制了我们的整个RTP / RTSP堆栈，我一直在想我们可以引入一个新的RTSP命令（不涉及任何现有命令，因此我们仍然可以完全互操作）作为解决方案：DESCRIBE_SETUP_PLAY。
我们可以发送这一个命令，传入感兴趣的流类型（通常，只有一个视频和0..1音频）。响应将包括完整的SDP文本，以及所有端口信息，就像之前一样，服务器将立即开始流式传输而无需等待客户端的其他任何内容。
这会有用吗？我可能没看到的任何缺点？我很好奇为什么不考虑（或被删除）官方规范，因为即使在本地内部网中的延迟也是明显的。
答案 0 :(得分：1)
仅供参考，根据RTSP 1.0规范：
是可能的9.1流水线
支持持久连接或无连接模式的客户端 可以“管道化”其请求（即，不发送多个请求） 等待每个回应）。服务器必须将响应发送给那些 请求的顺序与收到请求的顺序相同。
RTSP 2.0 draft还包含对流水线的支持。
但是我使用的客户端/服务器都没有实现它AFAIK。