srs
srs copied to clipboard
ossrs
SRS is a simple, high-efficiency, real-time video server supporting RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181.
srs的配置文件是否考虑切换成yaml，毕竟配置文件可能需要被很多文件读取和解析。使用通用的结构。可以方便各种语言直接使用类库读写。 考虑如下场景：srs需要读取其他配置文件的配置项，或者其他组件需要读取srs的配置项。 k8s默认使用yaml格式，spring也支持yaml格式。从业务角度，yaml是比较被广泛使用的配置文件格式（特别是docker内） 比对可以参考wiki https://en.wikipedia.org/wiki/YAML#Comparison_with_JSON 设计目标可以参考https://yaml.org/spec/1.2/spec.html#id2708649 当然，yaml的空格问题必须要借助工具，否则可读性就差了那么点意思。
Two questiongs: 1. WebRTC does not work on Edge server? 2. WebRTC also not work on Origin server? How to support cluster for WebRTC? 请教两个关于WebRTC的问题： 1.目前WebRTC是不是并不支持从边缘站回源？ 2.目前WebRTC是否并不支持源站集群？ 使用RTMP推流，WebRTC播流，目前尝试源站集群，和源站-边缘站两种方式，播放WebRTC时似乎都无法进行回源。
> 注意：提问前，请先看FAQ(Please read FAQ before file an issue) https://github.com/ossrs/srs/issues/2716 **描述(Description)** > 描述你遇到了什么问题(Please description your issue here) 现有源站集群3个节点，A、B、C和一个edge边缘拉流节点。C节点上有一路流在推。 当播放器拉edge边缘节点的流时，第一次正常播放，停止播放后立刻、快速再次拉流，无法播放，SRS日志报错。 但当播放器拉源站集群中的C节点的流时，正常播放，停止播放后立刻、快速再次拉流，却能正常播放，无问题。重复多少次都行。 经过不断的测试发现，播放器在向edge边缘节点拉流时，正常播放且断开后的3秒内要想重新拉流，就会造成拉流失败的问题。 最新版的`srs-server-4.0-b6`经过测试也会出现这个问题。 经过查询issues，以为是#1520，仔细阅读后发现不是。（https://github.com/ossrs/srs/issues/1520） 报错如下： `[2022-02-07 16:34:54.525][Error][109157][t4269891][11] serve error code=2020 : service...
我们结构上可能需要做一个非常重要的修改，就是之前SRT和GB，都是转RTMP后转RTC，应该具备直接转的能力。 因为SRT和GB和RTC本质上是RTP的包，所以直接转是更有效的。而RTMP、FLV和HLS是基于帧的协议，他们是类似的，所以转RTMP后转HLS没问题。 也就是基于Packet的协议，应该要能直接转换。而基于Frame的协议可以直接转换。当Packet到Frame时才需要过RTMP。GB和RTC，直接转。SRT和RTC直接转。GB/SRT转HLS，应该GB/SRT转RTMP转HLS。这样SRT可以直接转到RTC，延迟会更低，也更有效。 在实际中发现，低延迟直播，可能SRT更合适，但是播放器只能选择SRT协议，这限制了应用范围。全链路低延迟直播，肯定没法用FLV做低延迟播放器，会有累计延迟。而只能选择RTC播放器，而目前SRT转RTMP再转RTC，延迟很大，链路也很长。 ## SRT SRT每个UDP包，是多个TS包。可能会遇到丢包和乱序，以及重传等问题。 由于TS包能直接转成264的annexb包，因此SRT的UDP包，可以直接转成RTC的RTP包。而丢包、乱序和重传，可以直接对应上。 而FEC会是个问题。 ## GB GB可以是264封装，或者是PS封装，大部分是PS封装。 如果是264封装，则可以直接和RTC的RTP包对应。如果是PS封装，则无法直接转换，需要收到完整的Frame后再转RTP。 > Note: 目前GB是支持RTMP Client，还有RTMP Source直接对接（默认）。 ## RTC RTC的RTP包，里面就是264的raw data，当然也可以是annexb格式的264数据，两种都是可以解析的。 有时候也可以主动把很多小的P帧，打包成一个RTP包，参考： ``` # Whether merge multiple NALUs into...
Some player start to play from the first ts file, which might be cleanup. It's better to delay cleanup the ts files.
开启SRT和hooks，错误日志如下： ``` docker logs -f srs-server|grep 139ng145 03:33:29.679184/srs*E:SRT.d: SND-DROPPED 4 packets - lost delaying for 1022ms 03:35:23.059938/SRT:RcvQ:worker*E:SRT.c: IPE: ACK node overwritten when acknowledging 1162 (ack extracted: 1004308388) 03:36:52.965435/SRT:RcvQ:worker*E:SRT.c: IPE: ACK...
Only SRS knows how to set the `Cache-Control` for m3u8 and ts.
定位到问题是pmt写入信息默认带了视频字段，用ffplay定位到警告。 Could not find codec parameters for stream 1 (Video: h264 ([27][0][0][0] / 0x001B) 查代码发现对应函数 SrsTsPacket::create_pmt ，纯音频情况不应该push_back视频类型； // if h.264 specified, use video to carry pcr. if (vs == SrsTsStreamVideoH264)...
目前SRS的DEMO和Wiki都偏向于原子能力，如何把原子能力组合成场景，需要单独的DEMO。 一对一视频聊天是比较常用的一个场景，目前SRS的DEMO聊天的业务属性比较少，比如没有房间列表，也没有移动端。 而且目前不能方便的获取这个DEMO，路径比较长，混在Wiki中。 想要这个复刻的请留言，最好能说明下是学习用的，还是打算准备业务上用的。
This is a feature request for the HTTP 301/302 Redirect that NGINX RTMP Module supports for on_publish. Basically I am requesting to have the on_publish follow a 301/302 redirect to...
