pingOS监听拉流和推流的响应事件配置

简介: pingOS监听拉流和推流的响应事件配置
worker_processes  1;
error_log  logs/error.log debug;
events {
    worker_connections  1024;
}
rtmp {
    server {
        listen 1935;
        application live1 {
            live on;
#           record off;
            sync 300ms;
            on_play    http://127.0.0.1:9990/video/notify/play args=stream=$stream stage=start,done;
            on_publish    http://127.0.0.1:9990/video/notify/publish args=stream=$stream stage=start,done;
        }
        application live2 {
            live on;
            drop_idle_publisher 5s;
           #on_play    http://127.0.0.1:9990/video/notify/play stage=start,done;
        }
        ping 3m;
        ping_timeout 30s;
    }
}
http {
    server {
        listen      80;
        location / {
            root html;

位置 usr/local/pingos/config/nginx.conf


$domain 客户端服务器时使用的域名,类似http协议中的host参数
$app 挂载点名
$name 流名
$stream 流标识,serverid/app/name拼接而成
$pargs 推流或播放请求连接后携带的自定义参数
$args rtmp协议中,在connection阶段携带的参数
$flashver rtmp协议中的flashver
$swf_url rtmp协议中的swf_url
$tc_url rtmp协议中的tc_url
$page_url rtmp协议中的page_url
$acodecs 音频编码类型
$vcodecs 视频编码类型
$scheme 连接使用的协议,如http、rtmp
$serverid 配置中的serverid
$notify_status notify执行结果
$finalize_reason session被销毁的原因
$stage 当前session所处的阶段:
“init”, “handshake_done”, “connect”, “create_stream”, “publish”, “play”, “audio_video”, “close_stream”
$init session被初始化的时间
$handshake_done rtmp握手完成时的时间
$connect 连接建立的时间
$create_stream 流被创建时的时间
$ptime 从推流端获取到第一帧媒体数据时的时间
$first_data 收到或发送第一帧媒体数据的时间
$first_metadata 收到或发送metadata的时间
$first_audio 收到或发送第一个音频帧的时间
$first_video 收到或发送第一个视频帧的时间
$close_stream 流被关闭的时间
$relay_domain relay操作使用的域名,参考domain变量
$relay_app relay操作使用的挂载点名,参考app变量
$relay_name relay操作使用的流名,参考name变量
$relay_args relay操作connection的参数,参考args变量
$relay_pargs relay操作的pages参数,参考pargs变量
$relay_referer relay操作的referer,参考page_url变量
$relay_user_agent relay操作中User-Agent参数
$relay_swf_url 参考swf_url
$relay_acodecs relay操作成功后,拉取到的或推送出去的音频编码类型,参考acodecs
$relay_vcodecs relay操作成功后,拉取到的或推送出去的视频编码类型,参考vcodecs
$remote_addr 客户端IP
$remote_port 客户端端口
$server_addr 客户端通过服务器的哪个IP连接进来的
$server_port 客户端通过服务器的哪个端口连接进来的
$nginx_version nginx版本
$pid nginx worker进程的进程号
$msec 精确到微妙的时间戳,标记当前操作的精确时间
$time_iso8601 iso8601标准时间
$time_local 格式化的时间
$ngx_worker worker进程的编号
$parg_ 获取到pargs参数中的某个参数,例如pargs为k0=0&k1=1,那么$parg_k0的值就是0,$parg_k1是1



控制事件


  • on_proc


进程启动时通知,只支持 start 触发点。


  • on_play


当有拉流时,触发 on_play的start通知,当拉流持续时,每隔一定时间间隔向外发送on_play的update 通知,当拉流结束时发送on_play的done通知。


  • on_publish


当有推流时,触发 on_publish的start通知,当推流持续时,每隔一定时间间隔向外发送on_publish的update通知,当推流结束时发送on_publich的done通知。


  • on_pull


当需要回源拉流时,触发pull控制(发送on_pull的start通知),回源拉流创建成功后,每隔一定时间间隔向外发送on_pull的update通知,当拉流结束时发送on_pull的done 通知。


  • on_push


当需要转推流时,触发push控制(发送on_push的start通知),转推流创建成功后,每隔一定时间间隔向外发送on_push的update通知,当转推流结束时发送on_push的done通知。


  • on_stream


当有推流时,触发 on_stream的start 通知,当流还继续存在时,每隔一定时间间隔向外发送 on_stream的update 通知,推流结束时发送 on_stream的done 通知。


  • on_meta


meta 的行为和 push 一致,只是 meta 的触发点在收到音视频头,push 触发点是收到 publish 命令,push 和 meta 是互斥的,配置了 push,meta 将不生效。


控制事件触发点包含:


  • start:事件发生时触发,配置或不配置 start 均为默认开启状态


  • update:事件持续过程中的心跳刷新


  • done:事件结束时触发


扩展参数


  • args:向外发送通知或控制请求时,携带的 http 请求参数,可使用变量配置,具体变量列表请参考变量列表↑


  • groupid:分组,主要针对 push 或 meta,多路转推时,用于标识每路转推用


  • stage:触发阶段,可选 start,update 和 done


  • timeout:向外发送通知或控制请求时,等待外部响应的超时时间,默认为 3s


  • update:发送 update 通知的时间间隔,默认为 1min,只有 stage 配置了 update 才生效


配置示例



  • 基本模型
 application test {
      live on;
      cache_time 3s;
      idle_streams off;
      on_publish http://127.0.0.1/xxx/v1/publish stage=start,done args=a=c&b=d&$pargs; # 配置文件中的变量以$开头
      on_play    http://127.0.0.1/xxx/v1/play    stage=start,done args=a=c&b=d&$pargs;
      on_stream  http://127.0.0.1/xxx/v1/stream  stage=start,done args=a=c&b=d&$pargs;
  }

拉流模型

 application edge {
      live on;
      cache_time 3s;
      low_latency on;
      on_pull     http://127.0.0.1/xxx/v1/pull    stage=start,update,done args=a=c&b=d&$pargs;
  }

推流模型

  application pub {
      live on;
      #on_push    http://127.0.0.1/xxx/v1/push    stage=start,update,done args=a=c&b=d&$pargs timeout=1s;
      on_meta    http://127.0.0.1/xxx/v1/push    stage=start,update,done args=a=c&b=d&$pargs timeout=1s;
  }

配置


on_proc


Syntax: on_proc url [timeout=time] [update=time];

Default: -


Context: rtmp


  • Desc


进程启动时,向配置的 url 发送 http get 请求,通知时会携带 call=init_process&worker_id=$ngx_worker 参数。


on_play


Syntax: on_play url [args=string] [stage=[start][,update][,done]] [timeout=time] [update=time];


Default: -


Context: application


  • Desc

只能配置一条。

外部拉流时,向配置的 url 发送 http get 请求,通知时会携带 call=play&act=start&domain=$domain&app=$app&name=$name,如果配置了 args,会将 args 追加到默认参数后面。

如果配置了 update,拉流结束前,每隔 update 时间间隔会发送一条刷新通知,和初始通知区别是,act=update。

如果配置了 done,拉流结束后会发送 done 通知,和初始通知区别是,act=done。

对于初始请求,如果外部异常,将不会发送 update 请求;如果外部回送非 200 响应,将会使用 403/NetStream.Play.Forbidden 断掉拉流请求;如果外部回送 200 响应并配置了刷新,会启动 update 定时器发送刷新通知。 对于刷新通知和结束通知,不对响应做处理。

on_publish


Syntax: on_publish url [args=string] [stage=[start][,update][,done]] [timeout=time] [update=time];


Default: -


Context: application


  • Desc

只能配置一条。

外部推流时,向配置的 url 发送 http get 请求,通知时会携带 call=publish&act=start&domain=$domain&app=$app&name=$name,如果配置了 args,会将 args 追加到默认参数后面。

如果配置了 update,推流结束前,每隔 update 时间间隔会发送一条刷新通知,和初始通知区别是,act=update。

如果配置了 done,推流结束后会发送 done 通知,和初始通知区别是,act=done。

对于初始请求,如果外部异常,将不会发送 update 请求;如果外部回送非 200 响应,将会使用 403/NetStream.Play.Forbidden 断掉拉流请求;如果外部回送 200 响应并配置了刷新,会启动 update 定时器发送刷新通知。

对于刷新通知和结束通知,不对响应做处理。

on_stream


Syntax: on_stream url [args=string] [stage=[start][,update][,done]] [timeout=time] [update=time];


Default: -


Context: application


  • Desc

只能配置一条。

流创建时(有一路推流或一路拉流时),向配置的 url 发送 http get 请求,通知时会携带 call=stream&act=start&domain=$domain&app=$app&name=$name,如果配置了 args,会将 args 追加到默认参数后面。

如果配置了 update,所有推拉流结束前,每隔 update 时间间隔会发送一条刷新通知,和初始通知区别是,act=update。 对于初始请求,如果外部异常或外部回送非 200 响应,将不会发送 update 请求;如果外部回送 200 响应并配置了刷新,会启动 update 定时器发送刷新通知。

如果配置了 done,所有推拉流结束后会发送 done 通知,和初始通知区别是,act=done。

对于刷新通知和结束通知,不对响应做处理。

on_pull


Syntax: on_pull url [args=string] [stage=[start][,update][,done]] [timeout=time] [update=time];


Default: -


Context: application


  • Desc

只能配置一条。

需要触发回源拉流时,向配置的 url 发送 http get 请求,通知时会携带 call=pull&act=start&domain=$domain&app=$app&name=$name,如果配置了 args,会将 args 追加到默认参数后面。

如果配置了 update,relay pull session 结束前,每隔 update 时间间隔会发送一条刷新通知,和初始通知区别是,act=update。

如果配置了 done,relay pull session 结束后会发送 done 通知,和初始通知区别是,act=done。

对于初始请求,如果外部异常,将会启动 pull reconnect;如果外部回送 200 响应,将不会创建 relay pull session,因此后续不会有 update 和 done 通知;如果外部回送 4XX 或 5XX 响应,将会结束所有拉流请求。

如果回送 3XX 响应,将会根据 Location 头构造回源请求,Location 必须是完整的 rtmp 或 http url,如 rtmp://ip/app/name[?args],如果是 rtmp url 将会使用 rtmp 协议回源,如果是 http url 将会使用 http flv 协议回源。如果 3XX 响应中携带 Domain 头,将会使用该头构造 rtmp 的 tc_url 或 http 的 Host 头。

对于刷新通知和结束通知,不对响应做处理。

on_push


Syntax: on_push url [args=string] [stage=[start][,update][,done]] [timeout=time] [update=time];


Default: -


Context: application


  • Desc


最多支持配置 8 条,每条对应一个 relay push session。

需要触发流转推时,向配置的 url 发送 http get 请求,通知时会携带 call=push&act=start&domain=$domain&app=$app&name=$name,如果配置了 args,会将 args 追加到默认参数后面。

如果配置了 update,relay push session 结束前,每隔 update 时间间隔会发送一条刷新通知,和初始通知区别是,act=update。

如果配置了 done,每条 relay push session 结束后会发送 done 通知,和初始通知区别是,act=done。

对于初始请求,如果外部异常,将会启动 push reconnect;如果外部回送 200 响应,将不会创建 relay push session,因此后续不会有 update 和 done 通知;如果外部回送 4XX 或 5XX 响应,将会结束推流请求。

如果回送 3XX 响应,将会根据 Location 头构造回源请求,Location 必须是完整的 rtmp url,如 rtmp://ip/app/name[?args]。如果 3XX 响应中携带 Domain 头,将会使用该头构造 rtmp 的 tc_url。

对于刷新通知和结束通知,不对响应做处理。

on_meta


Syntax: on_meta url [args=string] [stage=[start][,update][,done]] [timeout=time] [update=time];


Default: -


Context: application


  • Desc

最多支持配置 8 条,每条对应一个 relay push session。

基本功能与 on_push 相同,只不过 on_push 是 publish 命令触发,on_meta 是音视频头触发,具体触发规则见 on_meta_type 和 on_meta_once。


on_meta_once


Syntax: on_meta_once on|off;

Default: on

Context: rtmp, server, application

  • Desc

on_meta 通知是否只触发一次


on_meta_type


Syntax: on_meta_once video|audio|both;

Default: video

Context: rtmp, server, application

  • Desc
  • video:on_meta 只有在收到视频头时触发
  • audio:on_meta 只有在收到音频头时触发
  • both:on_meta 在收到音频或视频头时均会触发

学习时的痛苦是暂时的 未学到的痛苦是终生的

相关文章
|
存储 关系型数据库 MySQL
MYSQL 单表可以放多少数据是怎么计算出来的
MYSQL 单表可以放多少数据是怎么计算出来的
670 2
|
Python
一条龙操作有效解决PermissionError: [WinError 5] 拒绝访问的问题
一条龙操作有效解决PermissionError: [WinError 5] 拒绝访问的问题
2411 0
|
6月前
|
人工智能 安全 网络安全
从不确定性到确定性,“动态安全+AI”成网络安全破题密码
2025年国家网络安全宣传周以“网络安全为人民,靠人民”为主题,聚焦AI安全、个人信息保护等热点。随着AI技术滥用加剧,智能化攻击频发,瑞数信息推出“动态安全+AI”防护体系,构建“三层防护+两大闭环”,实现风险前置识别与全链路防控,助力企业应对新型网络威胁,筑牢数字时代安全防线。(238字)
397 1
|
机器学习/深度学习 API 开发工具
|
8月前
|
数据采集 缓存 安全
布隆过滤器的应用场景?
布隆过滤器是一种高效的数据结构,广泛应用于海量数据去重、垃圾邮件过滤、网络安全及缓存穿透防护等领域,能快速判断一个元素是否存在,提升系统查询效率与安全性。
324 0
|
人工智能 自然语言处理 数据可视化
Agentic Reasoning:推理界RAG诞生!牛津大学框架让LLM学会『组队打怪』:动态调用搜索/代码代理,复杂任务准确率飙升50%
Agentic Reasoning 是牛津大学推出的增强大型语言模型(LLM)推理能力的框架,通过整合外部工具提升多步骤推理、实时信息检索和复杂逻辑关系组织的能力。
624 1
|
监控 数据可视化 项目管理
高效时间管理工具如何帮助优化日常任务管理?2024年6款最优秀软件
在快节奏的现代工作环境中,高效的时间管理和任务协作工具成为提升生产力的关键。2024年,随着工作模式的变化,企业及个人愈发依赖这些工具来优化时间管理、任务分配和团队协作。本文精选了几款高效工具,如板栗看板、ClickUp、Notion、Wrike、Todoist和Evernote,它们各自具备独特优势,适用于不同行业和规模的团队,帮助用户在繁忙的工作中保持高效和有序。
2064 6
高效时间管理工具如何帮助优化日常任务管理?2024年6款最优秀软件
|
XML 机器学习/深度学习 数据格式
YOLOv8训练自己的数据集+常用传参说明
YOLOv8训练自己的数据集+常用传参说明
24370 3
|
存储 缓存 监控
MySQL 8.0中查询缓存的废弃与原因分析
MySQL 8.0中查询缓存的废弃与原因分析
926 1

热门文章

最新文章