4.2 基础配置信息

无论是rtmp标签，还是server标签，甚至是application标签都算是核心配置信心中的成员。因为他们的存在和控制影响着整个nginx-rtmp-module甚至是至关重要不可以不去配置的。

rtmp

context: root 根级标签，rtmp配置的最关键的标签

rtmp{ ... }
server

context: rtmp 一个rtmp中可以包含多个server，每个server可以通过端口隔离

rtmp{
  server{
        listen 1935;
  }
  server{
        listen 1955;
  }
}
listen

context: server 指定了所在server绑定的端口信息

server{
        listen 1955;
  }
application

context: server application在server标签中，可以包含多个并通过applicationName来隔离

rtmp{
   server{
         listen 1935;
         application A{      
         }
         application B{
         }
   }
   server{
         listen 1934;
         application A{}
         application B{}
   }
   #rtmp://ip:1934/A与rtmp://ip:1935/A是server隔离
   #rtmp://ip:1934/A与rtmp://ip:1934/B是application隔离
}
ping，ping_timeout

context: rtmp, server 主动检查心跳，将个心跳包发送到客户端并通过ping_timeout中设置的值为超时回复时间,如果超时回复时间内没有得到回复,则关闭客户端。ping默认1分钟，timeout默认30s,ping为0时关闭此功能

ping 15s;
ping_timeout 5s;
ack_window

context: rtmp, server 设置RTMP确认窗口大小，默认5000000

RTMP消息包一共分成三种类型。一类是命令（通知）消息，一类是音频消息，一类是视频消息。而窗口大小则属于第一种消息，即命令消息。窗口大小的本意是让对端了解与本端的通信状况，用以控制媒体传输流量的一种方案。通常，我们从RTMP服务器中进行拉取RTMP流到本地时，在协商的过程当中，会发送0x05,0x06消息包，即带宽值通知，通常设为2.5M。在实际的拉流过程中，我们通常隔一段时间就得向服务器报告，我们已经从服务中收到了多少数据量，此种报告，就是窗口大小，即ack size确认。我在实际开发的过程当中，通常，当接收的数据量接近于3倍带宽值（2.5M*3）时，向服务器报告一下目前已接收了多少数据。

在接收端的TCP协议缓存中还有多少剩余空间，发送端必须保证发送的数据不超过这个剩余空间以免造成缓冲区溢出，这个窗口是接收端用来进行流量限制的，在传输过程中，窗口大小与接收端的进程取出数据的快慢有关

ack_window 5000000;
chunk_size

context: rtmp, server 流中的块大小。默认是4096。这个值越大，CPU开销就越低。这个值不能小于128。

chunk_size 4096;
max_message

context: rtmp, server 输入数据报文最大尺寸。所有输入数据会被分割成报文（然后进一步分割为块）。报文在处理结束之前会放在内存里。理论上讲，接收到的报文很大的话对于服务器的稳定性可能会有影响。默认值 1M 对于大多数情况就足够了。

max_message 1M;
buflen

context: rtmp, server 缓冲区长度

buflen 5s;
rtmp_auto_push

context: root 多任务进行时，分发任务到多个进程 

rtmp_auto_push on;
rtmp_auto_push_reconnect

context: root 当rtmp_auto_push 开启并超时被销毁时，进行重连。

rtmp_auto_push_reconnect 1s;
meta

context: rtmp, server, application on值客户端得到一个新的元数据信息，copy客户端得到一个准确的元数据拷贝，默认是on

meta copy;

Context: rtmp, server, application

interleave

context: rtmp, server, application 交叉模式，此模式下音视频在同一个chunk stream上，默认关闭

interleave on;
wait_key

context: rtmp, server, application 使视频流从一个关键帧开始。默认为关闭

wait_key on;
wait_video

context: rtmp, server, application 禁用音频直到第一个视频帧发送。默认关闭。可以与wait_key结合，使客户端接收视频关键帧。然而，这通常会增加连接延迟。您可以在编码器中调整关键帧间隔以减少延迟。 最近版本的IE需要这个选项来正常播放。

wait_video on;
sync

context: rtmp, server, application 同步音频和视频流。如果客户端带宽不足以接收到发行者速率的数据，那么一些帧会被服务器删除。这导致了同步问题。当时间戳差异超过指定为同步参数的值时，将发送一个绝对帧。默认是300ms。

sync 10ms;
allow,deny

context: rtmp, server, application 白名单和黑名单

allow publish 127.0.0.1; 
#允许127.0.0.1推流
deny publish all;
#阻止所有推流，allow publish中的配置除外
allow play 192.168.0.0/24; 
#允许192.168.0.0/24拉流
deny play all;
#阻止所有拉流，allow play的配置除外
play

context: rtmp, server, application 播放本地或远程点播文件

application vod {
    play /var/flvs;
}

application vod_http {
    play http://myserver.com/vod;
}

application vod_mirror {
    #当第一个地址无法播放的时候，会访问第二个地址
    play /var/local_mirror http://myserver.com/vod;
}
max_connections

context: rtmp, server, application 最大连接数

max_connections 1000;
access_log

context: rtmp, server, application 通常来说rtmp日志是和nginx/logs/access.log存放在一起的，通过access_log可以单独存放rtmp_log

access_log logs/rtmp_access.log
log_format

context:rtmp 自定义日志格式

  • connection - 链接数
  • remote_addr - 客户端地址
  • app - application 名称
  • name - 最后一个串流码名称
  • args - 最后一个播放的流/推流参数
  • flashver - flash版本
  • swfurl - swf地址
  • tcurl - tc地址
  • pageurl - 客户端页面地址
  • command - 推拉流中命令：NONE, PLAY, PUBLISH, PLAY+PUBLISH
  • bytes_sent - 发送到客户端的字节数
  • bytes_received - 收到客户端的字节数
  • time_local - 链接关闭时间
  • session_time - 链接持续时间
  • session_readable_time - 格式化日期
  • msec - unix时间戳
$remote_addr [$time_local] $command "$app" "$name" "$args" - 
$bytes_received $bytes_sent "$pageurl" "$flashver" ($session_readable_time)

results matching ""

    No results matching ""