背景与痛点

RTSP（Real Time Streaming Protocol）作为流媒体控制协议，在视频监控、直播等领域广泛应用。但用Java实现RTSP推送时，开发者常面临三大难题：

1. 协议解析复杂性：RTSP基于文本，需处理OPTIONS、DESCRIBE、SETUP等交互流程，手动解析易出错
2. NAT穿透困难：推送端在私有网络时，SRS公网服务器无法主动建立连接
3. 稳定性挑战：长连接下的网络抖动、丢包会导致会话中断

技术选型

主流Java媒体框架对比：

• JavaCV：
• 优点：封装FFmpeg，支持硬编码，社区活跃

• 缺点：内存消耗较大

• Xuggler：

• 优点：API简洁，适合快速开发
• 缺点：已停止维护

推荐组合：JavaCV + Netty（处理网络层）

核心实现

RTSP客户端关键代码

// 使用JavaCV创建推流上下文
FFmpegFrameGrabber grabber = new FFmpegFrameGrabber("input.mp4");
grabber.start();

// 配置RTSP传输参数
FFmpegFrameRecorder recorder = new FFmpegFrameRecorder(
    "rtsp://srs_server/live/stream", 
    grabber.getImageWidth(), 
    grabber.getImageHeight()
);
recorder.setFormat("rtsp");
recorder.setVideoCodec(AV_CODEC_ID_H264);
recorder.start();

// 帧推送循环
Frame frame;
while ((frame = grabber.grab()) != null) {
    recorder.record(frame);
}

SRS服务器关键配置（conf/srs.conf）

listen 1935;
max_connections 1000;
daemon off;

rtc_server {
    enabled on;
    listen 8000; # WebRTC端口
}

vhost __defaultVhost__ {
    rtsp {
        enabled on;
        port 554;
        mount /live;
    }
}

性能优化

1. 多线程处理：分离视频采集、编码、网络IO线程
2. 动态缓冲区：根据网络RTT调整jitter buffer大小
3. QoS保障：
4. 实现RTCP反馈机制
5. 关键帧重传策略

避坑指南

1. SDP协商失败：检查a=control字段路径是否匹配SRS配置
2. 端口冲突：确保554（RTSP）、1935（RTMP）端口未被占用
3. 时间戳跳跃：强制统一时间基准-use_wallclock_as_timestamps 1
4. 内存泄漏：定期调用avformat_free_context释放资源
5. 防火墙拦截：配置UDP端口范围（默认5000-65000）

安全考量

• Basic Auth：在SRS启用rtsp_auth模块
• SRTP加密：配置encryption为aes128
• IP白名单：通过SRS的allow_play限制访问源

开放性问题

1. 如何实现RTSP over WebSocket以绕过企业防火墙？
2. 在弱网环境下，怎样优化RTSP的快速重连策略？
3. RTSP与SRT协议在延迟控制上有何本质区别？

通过Wireshark抓包分析可见，成功的RTSP会话会经历DESCRIBE→SETUP→PLAY→TEARDOWN的标准流程，每个阶段都应收到200 OK响应。建议开发者重点关注Session头的维护和Transport层的RTP/RTCP包序列。