对播放器架构演进、流媒体存储传输、视频编解码标准及图像声音信号处理，既对数学要求较高又与当时全民IT热相结合的专业——(计算机)信息安全，精妙绝伦的数论及密码学。既能应用密码学的知识技能又能和声色并茂的多媒体场景结合起来的信息隐藏和数字水印，音视频技术是互联网品质生活的连接器。连接器”的另一头则连接且聚合着信息论、最优化理论、图形图像学、声学、人类视觉系统等一众根基深厚、源远流长的学派。
-- 多媒体技术
基础知识方面推荐岗萨雷斯的《数字信号处理》，东南大学的《信息论与编码》；
编码基础方面推荐Wiley的《THE H.264 ADVANCED VIDEO COMPRESSION STANDARD》或国内毕厚杰老师的《新一代视频压缩编码标准H.264》；
最新的标准可以看相关的标准文档。
部署WebRTC的媒体服务器有两个主要挑战，从一台服务器开始扩展，并且优化参加会议的用户的媒体延迟。尽管简单的碎片化方法像‘将X会议中的所有用户发送到服务器Y’容易实现水平扩展，在用户体验中，媒体延迟是一个关键因素，在这方面，此方法还远远不能达到最优效果。
将视频会议分布在距离用户很近的许多服务器上并且保持相互连接，同时解决了两个问题。本文深度描述了级联SFU存在的问题并且展示了解决方法和遇到的其它问题。
实时交流的App非常依赖网络环境，例如吞吐量，延迟，丢失。低比特率导致低视频质量，导致了视频音频中的传输延迟更高。丢包可以导致视频跳帧，进而导致‘波浪音’和视频冻结。
由于这些原因，在会议中，在两个端点之间选择最优路径是很重要的。当只有两个参与者时，这很直接—WebRTC使用ICE协议在两端建立连接，交换多媒体。如果可能的话，两端直接连接，不然的话，在少数情况下使用 TURN传递服务器。WebRTC支持分解域名来获得 TURN服务器地址，这使得选择基于DNS的本地 TURN服务器相对简单，例如，使用AWS Route53的布线选项。
然而，当一个视频会议的参与者通过中心媒体服务器来发送时，情况变得更复杂。许多WebRTC服务像Hangouts，appear.in, Slack和meet.jit.si，使用SFU来在参与者人数多于3人时更有效的传递音频视频。
在janus Steaming插件中，官方提供了三种不同的流传输方法，即：
前两个在我们安装完janus后是可以直接播放出来的，第三种则需要我们额外部署rtp推流的程序。
官方使用的是使用GStreamer，但使用了FFmpeg，LibAV或其它也可以。
考虑到FFmpeg在流媒体圈子里名气最大，所以就选它了。
文 / Philipp Hancke
译 / 元宝
审校 / Ant
原文：
https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/
同步联播是WebRTC用于多方会议的一个很有趣的方面。简而言之，它意味着可以同时发送三种不同的分辨率（空间可伸缩性）和不同的帧速率（时间可伸缩性）。
通常，需要一个SFU才能利用联播。但是有一个方法可以使在两个浏览器之间或在单个页面内效果可见。这对于做单页测试或使用联播功能是非常有用的，特别是能够只启用某些空间层或控制特定流的目标比特率。
Playground
Playground有两种变体，一种用于Chrome，另一种用于Firefox。Chrome版本使用了我们在2014年夏天的谷歌环聊中首次看到的旧的SDP munging hack 。Firefox 使用‘RTCRtpSender.setParameters’来启用同步联播。两者都没有遵守最新的规范，但这并不会影响任何人对它的使用。
两种变体都可以显示视频图像，首先是发送者图像和总体比特率/帧速率图，其后是三个不同的空间流，每个空间流具有用于比特率和帧率的对应图。
由于我们不想涉及到服务器的内容，所以我们需要破解一些东西。幸运的是，有一个Chrome的测试验证了这个想法。Chrome和Firefox都使用一个数据包的RTP SSRC将其路由到某一个特定的媒体流。这些SSRC可以在SDP提供中找到：
原始的Chrome SDP
webrtc自带了Simulcast功能，可以将一个分辨率的流编码成多个分辨率并发送，观看端可以根据带宽去动态的选择某个分辨率，也可以自己选择某个分辨率，据说在webrtc M70版本提供了对外的接口开启Simulcast，并 vp8，vp9，h264三种编码器都支持Simulcast功能，但是在M70版本以下并不支持h264编码器的Simulcast功能，如果在M70版本以下使用Simulcast功能，需要通过修改SDP来开启，话不多说，直接上代码：
