Restreamer项目SRT/RTMP推流至YouTube失败问题排查与解决

问题背景

在使用Restreamer项目进行直播推流时，用户遇到了无法通过SRT或RTMP协议向YouTube稳定推送视频流的问题。具体表现为：

1. YouTube平台反馈接收不到数据或数据传输速率过低（仅1000kbps）
2. SRT协议持续输出错误日志"SRT.qr: No room to store incoming packet"
3. RTMP协议偶尔能建立连接但很快进入缓冲状态并最终断开
4. 其他平台如Twitch和Kick推流正常

技术分析

SRT协议错误解析

日志中出现的"SRT.qr: No room to store incoming packet"错误表明接收缓冲区已满。这是SRT协议中的流量控制机制在起作用，通常由以下原因导致：

1. 网络带宽不足或波动
2. 接收端处理能力不足
3. 缓冲区设置不合理
4. 系统内核参数配置不当

可能的影响因素

1. 网络环境：虽然VPS提供商相同，但不同实例的网络性能可能存在差异
2. 系统配置：内核参数net.core.rmem_max/wmem_max的设置可能影响协议性能
3. 容器网络：Podman容器网络模式的选择会影响网络性能
4. 软件版本：操作系统和容器运行时的版本兼容性问题

排查过程

用户尝试了多种解决方案：

1. 调整SRT缓冲区参数（rcvbuf=15000000）
2. 修改系统内核参数（net.core.rmem_max/wmem_max）
3. 重建Restreamer容器
4. 测试YouTube Ingest服务器的连通性
5. 调整OBS编码参数和比特率
6. 降级Restreamer版本至v2.7.0
7. 修改db.json中的缓冲区设置

根本原因

经过深入排查，发现问题根源在于系统软件包的不稳定版本：

1. 用户曾添加了不稳定的软件源仓库
2. 自动更新机制安装了有缺陷的网络相关软件包
3. 这些损坏的软件包影响了网络协议栈的正常工作

解决方案

1. 更换软件源：从不稳定仓库切换到Debian Trixie稳定源
2. 验证网络模式：确认Podman可以使用pasta、slirp4netns或host网络模式
3. 临时解决方案：在无法立即修复的情况下，使用slirp4netns作为临时网络方案

经验总结

1. 软件源管理：生产环境应避免使用不稳定软件源
2. 自动更新风险：关键系统组件应谨慎启用自动更新
3. 网络模式选择：容器网络模式对直播推流性能有显著影响
4. 系统诊断：网络问题应从底层协议和系统配置开始排查

最佳实践建议

1. 对于直播推流场景，建议使用host网络模式以获得最佳性能
2. 定期检查系统软件包来源和版本状态
3. 重要环境应实施变更管理和备份策略
4. 复杂网络问题可采用对比测试法（如尝试不同推流平台）缩小问题范围

通过这次问题排查，我们认识到系统底层网络协议栈的稳定性对直播推流服务至关重要。合理配置系统参数、选择稳定的软件版本，是保障直播服务可靠性的基础。