RTSP 音频轨道、AAC 和未知 SDP 轨道:为什么视频流在播放前失败
如何诊断带有音轨、AAC 有效负载、未知 SDP 媒体部分和客户端兼容性故障的 RTSP 流。
某些 RTSP 摄像机流失败并不是因为视频不可用，而是因为会话包含的内容超出了客户端的预期。摄像机可以在 SDP 中宣传视频、音频、元数据、私有轨道、反向通道音频或供应商特定的媒体部分。严格的消费者在遇到不支持的曲目时可能会拒绝整个会话。
诸如“RTSP AAC 音频不工作”、“SDP 中的未知轨道”、“启用音频时 RTSP 流失败”或“禁用音频后相机工作”等搜索都指向相同的诊断边界：SDP 描述会话，每个广告轨道都可能影响兼容性。
SDP 不仅仅可以做视频广告
RTSP DESCRIBE 响应可以包含多个媒体部分：
m=视频m=音频- 元数据轨道
- 应用轨道
- 供应商私有有效负载
- 控制每个轨道的 URL
对于每个轨道，客户端必须决定是否可以设置、忽略它或失败。有些客户是宽容的。其他人都很严格。如果重新流媒体引擎或分析产品只需要受支持的视频轨道，则未知的 SDP 部分可能会导致意外的失败。
AAC音频有自己的兼容性边界
RTP 上的 AAC 很常见，但并非每个 RTSP 消费者都能干净地处理每个音频负载。 SDP 可能需要描述模式、配置、时钟速率、通道和有效负载类型。如果这些字段丢失或异常，客户端可能会在设置过程中或稍后解包时失败。
音频问题可能表现为：
- 仅当禁用音频时才打开流
- SDP解析错误
- 不支持的负载类型
- 音轨上的“SETUP”失败
- 视频在 VLC 中工作，但在更严格的摄取路径中失败
- 即使视频轨道有效，录像机也会拒绝会话
最后一种情况很重要：不受支持的音轨可能会阻止对可用视频轨道的访问，具体取决于客户端行为。
未知的轨迹应该报告，而不是隐藏
如果 SDP 包含未知媒体部分，诊断工具应保留它。隐藏不受支持的轨道会使解释兼容性故障变得更加困难。
有用的证据包括：
- 完整的 SDP 媒体部分
- 有效载荷类型
rtpmap值fmtp值- 跟踪控制 URL
- 是否尝试了“SETUP”
- 视频、音频或元数据轨道是否发生故障
这让工程师可以决定是否禁用跟踪、对其进行过滤、更改相机配置文件或调整下游支持。
禁用音频作为测试，而不是诊断
禁用音频是一种常见的解决方法。它可能是有效的，特别是对于只需要视频的分析工作流程。但它应该被视为一个测试：
- 视频加音频失败
- 仅视频成功
- 禁用音频后 SDP 发生变化
- 不受支持的有效负载或轨道消失
- RTP 视频路径保持不变
此比较证明故障属于会话组合，而不是基本网络可达性。
RTSP Inspector 适合什么地方
RTSP Inspector 应保持会话结构可见。它的边界不是回放；这是协议解释。对于多轨 RTSP 流，它应该有助于回答：
- SDP 宣传了多少首曲目？
- 支持哪些曲目？
- 哪个轨道设置失败？
- 视频RTP到达了吗？
- 音频或元数据是否阻碍了消费者？
- 下一步行动应该是更改相机配置文件还是更改下游解析器？
当摄像机流“不起作用”时，视频轨道可能没问题。旁边不受支持的轨道可能是会话失败的真正原因。