[patch] 为pr #142 补充一些注释以及文档说明

pull/146/head
q191201771 3 years ago
parent 3fc508b90e
commit c11fb8081f

@ -90,14 +90,20 @@
"gop_num": 0 //. 见rtmp.gop_num
},
"rtsp": {
"enable": true, //. 是否开启rtsp服务的监听目前只支持rtsp推流
"addr": ":5544", //. rtsp推流地址
"out_wait_key_frame_flag": true //. rtsp出包时是否等待视频关键帧
// 音频和视频需要同时出,如果音频先出,而视频等待关键帧会导致音画不同步问题,两种情况:
// 1. 不等待视频关键帧,音视频包到了就转发
"enable": true, //. 是否开启rtsp服务的监听
"addr": ":5544", //. rtsp监听地址
"out_wait_key_frame_flag": true //. rtsp发送数据时是否等待视频关键帧数据再发送
//
// 2. 等待视频关键帧,视频关键帧到达之前,丢弃音频数据。
// (存在音视频头,但是音频先到,视频晚到的场景等待关键帧会导致超时问题)
// 该配置项主要决定首帧、花屏、音视频同步等问题
//
// 如果为true则音频和视频都等待视频关键帧才开始发送。也即视频关键帧到来前音频或视频全部丢弃不发送
//
// 如果为false则音频和视频都直接发送。也即音频和视频都不等待视频关键帧都不等待任何数据
//
// 注意纯音频的流如果该标志为true理论上音频永远等不到视频关键帧也即音频没有了发送机会
// 为了应对这个问题lalserver会尽最大可能判断是否为纯音频的流
// 如果判断成功为纯音频的流,音频将直接发送。
// 但是如果有纯音频流依然建议将该配置项设置为false
},
"record": {
"enable_flv": true, //. 是否开启flv录制

@ -381,7 +381,7 @@ func (group *Group) broadcastByRtmpMsg(msg base.RtmpMsg) {
// ---------------------------------------------------------------------------------------------------------------------
func (group *Group) feedRtpPacket(pkt rtprtcp.RtpPacket) {
// 出包时不等待视频关键帧
// 如果配置项 OutWaitKeyFrameFlag 为false则音频和视频都直接发送。音频和视频都不等待视频关键帧都不等待任何数据
if !group.config.RtspConfig.OutWaitKeyFrameFlag {
for s := range group.rtspSubSessionSet {
s.WriteRtpPacket(pkt)
@ -390,11 +390,16 @@ func (group *Group) feedRtpPacket(pkt rtprtcp.RtpPacket) {
}
var (
boundary bool
boundaryChecked bool // 保证只检查0次或1次减少性能开销
boundary bool // 是否是视频GOP起始位置
boundaryChecked bool // 保证遍历sub session时在必要时检查0次或1次减少性能开销
)
for s := range group.rtspSubSessionSet {
// session的 ShouldWaitVideoKeyFrame 为false那么可能有两种情况
// 1. 对输入流做智能检测时,判定为流内没有视频
// 2. 该输出流已经发送过了GOP起始数据
//
// 这两种情况下,音频或视频数据都直接发送,不需要等了
if !s.ShouldWaitVideoKeyFrame {
s.WriteRtpPacket(pkt)
continue

Loading…
Cancel
Save