metapushstreams：webrtc://127.0.0.1/live/livestream
metaplayer3：webrtc://127.0.0.1/live/livestream
srs：objs/srs -c conf/https.rtc.conf
ffmpeg -i westLife_mini.mp4 -strict -2 -f webrtc webrtc://127.0.0.1/live/livestream
objs/srs -c conf/rtc.conf
方案一使用以下：刚刚开始音频有些卡顿，后面流畅，视频刚刚开始偶尔有半秒卡顿，后面偶尔有丢帧，但肉眼流畅，不过有区域花块。当使用-f webrtc时，player3只支持opus的音频播放，ffmpeg默认使用opus编码，音频是在ffmpeg的opus编码的，matertc也认为ffmpeg传输过来的是opus。用opus编码应该是ffmpeg作的，metartc只传输。id:50
推拉流和srs都在本机。
ffmpeg -re -i westlife.mp4 -f webrtc webrtc://127.0.0.1/live/livestream
objs/srs -c conf/https.rtc.conf
metaplayer3
方案一换成：ffmpeg -re -i westlife_opus.mp4 -f webrtc webrtc://127.0.0.1/live/livestream
音视频情况一样。
方案一换成objs/srs -c conf/rtc.conf：情况一样，甚至更差一点。
目前目标：
评估一下FEC(1)，动态码率(2)新增要多少功夫。
tool:
ffmpeg -i westlife.mp4 -c:v copy -acodec libopus westlife_opus.mp4
方案二：视频二十分钟无卡顿，无花屏，metaplayer3没报跳帧
pushstream3
srs：objs/srs -c conf/https.rtc.conf
metaplayer3
方案三：
pushstream3：本机
srs:objs/srs -c conf/rtc.conf 部署在47服务器 这个命令缓存512k，分辨率太大I帧太大会出现卡顿。
metaplayers：本机
10分钟无画面卡顿，1个小时日志未打印丢帧。
tool:
ssh [email protected]
webrtc://47.104.161.61/live/livestream
github上的两个开源库，视频都是webrtc做的，音频不是，可参考这两个来。
方案四：
本机：ffmpeg -re -i westlife.mp4 -acodec opus -strict -2 -ar 48000 -s 640x480 -bf 0 -f webrtc webrtc://139.129.91.106/live/livestream
srs：ssh [email protected] objs/srs -c conf/rtc.conf
本机：http://localhost:8080/players/rtc_player.html?autostart=true
目前音频没问题，视频7分钟两次卡顿，srs在本机时这个分辨率，音视频没问题的，目前考虑是wifi网太弱了，到公司测试一下。公司网络，除去代理服务器，1个小时没有丢帧，但metaplay和网页偶尔有区域马赛克。
PJSIP
freeswitch
相关：
以及I帧申请(PLI，FIR)：PLI
FEC向前纠错(RED packet redundant code)：FEC
jitterbuffer功能，buffer主要对丢包、乱序、延时到达等异常情况进行处理，还会和NACK、FEC、FIR等QOS相互配合。jitter主要根据当前帧的大小和延时评估出jitter delay，再结合decode delay、render delay以及音视频同步延时，得到render time，来控制平稳的渲染视频帧。
就缓存技术而言，WebRTC 中提供了面向视频的 JitterBuff 和面向音频的 NetEQ。
Simulcast和SVC是SFU服务器的两种动态码率方式。
Simulcast模式分为三种分辨率，根据网络不同发送不同的分辨率。
SVC 模式它在视频编码时将视频分成多层——核心层、中间层和扩展层。上层依赖于底层，而且越上层越清晰，越底层越模糊。在带宽不好的情况下，可以只传输底层，即核心层，在带宽充足的情况下，可以将三层全部传输过去。见：SVC
WebRTC防止拥塞的根基是有准确的带宽评估方法。它提供了两种带宽评估方法，一种是基于丢包的带宽评估，另一种是基于延时的带宽评估。而基于延时的评估方法又分为接收端（Goog-REMB）和发送端（Goog-TCC）的带宽评估方法，目前默认采用的是Goog-TCC方法，因为其相对来说更为精准。
webrtc的拥堵算法有两种：
基于延时的，基于丢包的，webrtc拥堵算法
metartc支持jitter，pli，FEC(RED)
webrtc支持jitter,fec，目前的实际应用中，使用Simulcast比使用SVC多，webRTC对两种都支持。
目标：源切换(“实现YangVideoEncoder一个子类即可”)，弱网优化，目前知道FEC是协议层添加冗余，切换源并不会失去FEC特性。