SRT项目中的FFmpeg监听模式连接断开问题分析

问题现象

在使用SRT协议进行音视频传输时，当FFmpeg作为监听端(listener)运行时，如果呼叫端(caller)意外断开连接，FFmpeg进程会出现崩溃退出的情况。具体表现为：

1. FFmpeg以监听模式启动SRT服务
2. 呼叫端连接并开始接收流
3. 当呼叫端断开连接时
4. FFmpeg输出错误信息后异常退出

错误分析

从错误日志可以看出几个关键点：

1. SRT底层报告了"socket not found"错误
2. FFmpeg的av_interleaved_write_frame()函数报告了"Unknown error occurred"
3. 最终导致整个转码过程失败

这表明当连接断开时，FFmpeg未能正确处理SRT套接字的清理和重新初始化工作。

技术背景

SRT(Secure Reliable Transport)是一种基于UDP的开源传输协议，专为低延迟音视频传输设计。在SRT协议中：

• 监听端(listener)等待呼叫端连接
• 呼叫端(caller)主动发起连接
• 连接建立后形成双向数据通道

FFmpeg通过libsrt库实现对SRT协议的支持，但在连接管理方面存在一定局限性。

临时解决方案

目前发现以下两种临时解决方案：

1. UDP中转方案：

   • 首先将音视频流输出到本地UDP端口
   • 然后使用srt-live-transmit工具将UDP流转发为SRT流

2. 管道中转方案：

   • 使用FFmpeg的pipe输出
   • 通过管道连接srt-live-transmit工具
   • 这种方案减少了数据拷贝，效率更高

根本原因探讨

经过分析，这个问题可能源于：

1. FFmpeg对SRT连接断开的处理不够健壮
2. 连接断开后未能正确清理和重新初始化SRT套接字
3. 缺乏自动重连机制

建议解决方案

对于长期解决方案，建议：

1. 向FFmpeg项目提交功能请求，增加SRT协议的重连机制
2. 改进连接断开时的错误处理流程
3. 考虑在应用层实现连接监控和自动重启

总结

SRT协议在音视频传输领域具有重要价值，但其在FFmpeg中的实现还存在一些稳定性问题。通过使用中转工具可以暂时规避这些问题，但长期来看需要FFmpeg项目本身对SRT支持进行完善。开发者在使用SRT协议时应当注意连接管理，确保传输过程的稳定性。