最近更新了M89代码，看了下Release Notes，有几个需要关心的地方。
WebRTC 1.0已经正式成为W3C标准，推荐使用标准SDP格式：Unified Plan，主流浏览器基本都支持Unified Plan SDP。Plan B SDP后续将会不赞成使用，直到移除掉。官方后续时间计划如下：
M89中RTP payload类型增加了新的值范围：35-65。
首先根据RFC3551，回顾下目前用于标准音视频编码器的RTP payload类型。
我们首先了解一下 RTP H.264 相关的 RFC，下面的内容是对两篇 RFC 的总结：RTP: A Transport Protocol for Real-Time Applications, RTP Payload Format for H.264 Video。
RTP 包结构
包头有固定 12 个字节部分，以及可选的 csrc 和 ext 数据（在为 janus-pp-rec 增加视频旋正功能一文中有更详细的介绍）：
顾名思义，VAD（Voice Activity Detection）算法的作用是检测是否是人的语音，它的使用
范围极广，降噪，语音识别等领域都需要有vad检测。vad检测有很多方法，这里我们之介绍一
下webrtc里面的vad检测。
webrtc的vad检测原理是根据人声的频谱范围，把输入的频谱分成六个子带
（80Hz~250Hz，250Hz~500Hz,500Hz~1K,1K~2K,2K~3K,3K~4K。） 分别计算这六个子带的、
能量。然后使用高斯模型的概率密度函数做运算，得出一个对数似然比函数。对数似然比分为
全局和局部，全局是六个子带之加权之和，而局部是指每一个子带则是局部，所以语音判决会
先判断子带，子带判断没有时会判断全局，只要有一方过了，就算有语音。
Medooze作为WebRTC流媒体服务器，实现了将WebRTC/RTP流的录制为文件，以及将文件转换为RTP流。
mp4recorder.cpp 包含2个类：MP4Track和MP4Recorder，下面一个个分析。
MP4录制功能由MP4V2库提供支持。
一. VAD
1. 什么是VAD
VAD，也就是语音端点检测技术，是Voice Activity Detection的缩写.
这个技术的主要任务是从带有噪声的语音中准确的定位出语音的开始和结束点，因为语音中含有很长的静音，也就是把静音和实际语音分离开来，因为是语音数据的原始处理，所以VAD是语音信号处理过程的关键技术之一。
语音识别系统在识别或者声学模型训练阶段所遇到的第一个技术就是端点检测，把静音和噪声作为干扰信号从原始数据中去除，并且端点检测对于语音识别系统的性能至关重要。
静音抑制，又称语音活动侦测。静音抑制的目的是从声音信号流里识别和消除长时间的静音期，以达到在不降低业务质量的情况下节省话路资源的作用，它是IP电话应用的重要组成部分。静音抑制可以节省宝贵的带宽资源，可以有利于减少用户感觉到的端到端的时延。
2. VAD的作用
现在流行的语音识别系统大部分，或者是相当一部分都是基于统计和训练的原理所构建的系统，因此对数据来源和训练环境都是很敏感的。在识别的过程中，经常存在实际语音因背景噪声的干扰而与训练失配的情况，实际这也是造成语音识别系统鲁棒性差的一个根本原因（另一个主要的是无法处理非预期的输入），从而导致识别错误，性能下降。哪怕是两段内容上是完全一致的语音信号，可能由于语速不一样，所以语音信号的时间也不相同，音素之间的时间间隙也就不一样，对于时变而非平稳的语音信号来说，其特征就完全不相同了。有音素之间的间隙，也有静音和语音本身的间隙，为了对数据从时间上进行相对的校准，语音端点检测技术就应运而生了，因此端点检测技术可以决定这种校准的相对精度，使得同一内容的特征更趋于相同，当然，一般情况下是不可能完全相同的。大量研究表明，如果环境是安静的环境，没有太多背景噪声，此时语音识别系统的主要错误来源于端点检测技术不精确。
但在实际应用中，不可能没有背景噪声，另外由于麦克风的录制和信号增益也会带来噪声，所以语音识别系统的错误是由多方面影响的，至少包括：端点检测、特征提取、语音模型、声学模型、解码器等多个方面。
对播放器架构演进、流媒体存储传输、视频编解码标准及图像声音信号处理，既对数学要求较高又与当时全民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在流媒体圈子里名气最大，所以就选它了。
