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 在收到音频或视频头时均会触发

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

相关文章
|
7月前
|
机器人
钉钉的回调事件接入主要涉及到HTTP回调。
钉钉的回调事件接入主要涉及到HTTP回调。【1月更文挑战第9天】【1月更文挑战第45篇】
84 2
|
4月前
|
开发工具 Android开发 开发者
Android平台如何不推RTMP|不发布RTSP流|不实时录像|不回传GB28181数据时实时快照?
本文介绍了一种在Android平台上实现实时截图快照的方法,尤其适用于无需依赖系统接口的情况,如在RTMP推送、RTSP服务或GB28181设备接入等场景下进行截图。通过底层模块(libSmartPublisher.so)实现了截图功能,封装了`SnapShotImpl.java`类来管理截图流程。此外,提供了关键代码片段展示初始化SDK实例、执行截图、以及在Activity销毁时释放资源的过程。此方案还考虑到了快照数据的灵活处理需求,符合GB/T28181-2022的技术规范。对于寻求更灵活快照机制的开发者来说,这是一个值得参考的设计思路。
|
7月前
|
机器人
钉钉的回调事件接入主要涉及到HTTP回调
钉钉的回调事件接入主要涉及到HTTP回调【1月更文挑战第20天】【1月更文挑战第99篇】
260 3
|
存储 编解码 缓存
海康摄像头开发笔记(一):连接防爆摄像头、配置摄像头网段、设置rtsp码流、播放rtsp流、获取rtsp流、调优rtsp流播放延迟以及录像存储
Hik防爆摄像头录像,因为防爆摄像头会有对应的APP软件,与普通的网络摄像头和球机不一样,默认认为它不可以通过web网页配置,所以弄了个来实测确认。经测试实际上也是可以通过web网页配置(与网络摄像头基本是一致的,在码流方面可能会有些不一样),然后提取rtsp流的,界面与球机无异,只是没有球机的云台控制功能,但是界面上也是有的。
海康摄像头开发笔记(一):连接防爆摄像头、配置摄像头网段、设置rtsp码流、播放rtsp流、获取rtsp流、调优rtsp流播放延迟以及录像存储
|
编解码 网络协议 开发工具
IE浏览器下如何低延迟播放RTSP或RTMP流
首先,虽然本文是介绍IE浏览器下OCX控件播放RTSP或RTMP,但这种方式并不推荐,毕竟它只能用于IE浏览器环境下,局限太大,而且随着微软IE浏览器的更新,不确定后续支持情况。当然,话说回来,如果是在特定的使用场景下,只需要某些版本IE浏览器支持,但对延迟和稳定性要求非常高,OCX控件方式也不失为一个好的选择。
191 1
|
定位技术 开发工具 Windows
如何在RTSP/RTMP直播过程中加入SEI扩展数据发送和接收解析
在直播系统中,除了直播音视频之外,有时候还想从主播端发布文本信息等,这些信息可以不通过视频传输通道发送给用户播放端,但如果传输的数据想和视频保持精准同步,那最好的办法就是这些信息和视频数据打包在一起传输,并通过h264 sei方式就可以把数据放入h264 Access Unit中传输。
319 0
|
编解码 开发工具 Android开发
RTSP播放器或RTMP播放器常用的事件回调设计
很多开发者在开发RTSP或RTMP播放器的时候,不晓得哪些event回调事件是有意义的,针对此,我们以大牛直播SDK(github)的Android平台RTSP/RTMP直播播放端为例,简单介绍下常用的event id,总的来说,有以下几个部分组成:
|
编解码 iOS开发 流计算
调用Live555接收RTSP直播流,转换为Http Live Streaming(iOS直播)协议
调用Live555接收RTSP直播流,转换为Http Live Streaming(iOS直播)协议
517 1
|
编解码 网络协议 开发工具
如何在IE浏览器播放RTSP或RTMP流
好多开发者一直苦恼于如何在IE浏览器环境下,构建低延迟的RTSP或RTMP播放,对于RTSP流来说,好多公司通常的做法是把RTSP转RTMP,然后分发到RTMP服务器,然后服务器转http-flv出来,浏览器直接播放http-flv流,亦或通过flash控件直接播放RTMP流,还有就是,转hls流出来,缺点是hls流延迟更大。
467 0
|
开发工具 Android开发 iOS开发
RTSP流怎么录制
大牛直播录像SDK可作为单独功能模块使用(如同时多路录像存档),亦分布于以下模块,和其他模块组合调用: windows/android/iOS推送端SDK Demo; windows/android/iOS播放端SDK Demo;
137 0