本文基于 WebRTC M76 来分析下 Mac 端的音频采集和渲染逻辑。
代码位置
代码位置:webrtc/src/modules/audio_device/mac
1 | audio_device_mac.h |
本文基于 WebRTC M76 来分析下 Mac 端的音频采集和渲染逻辑。
代码位置
代码位置:webrtc/src/modules/audio_device/mac
1 | audio_device_mac.h |
前文 WebRTC 开发(六)摄像头采集与视频渲染分析 提到了 WebRTC 视频渲染的大概流程,但没有具体分析每个实现文件的功能,本文会深入到具体的实现文件。
渲染的代码位置
代码位置:webrtc/src/sdk/objc/components/renderer
1 | # opengl |
将 Xcode 升级到 Xcode 11.1 版本后,工程 AppRTCMobile 编译报错 “code object is not signed at all”。详细信息如下:
1 | Showing Recent Messages |
在上一篇文章 WebRTC 开发(五)编译与运行 Mac 工程 中,我们编译了 WebRTC 的工程 AppRTCMobile,也看到了 App 启动后的初始界面。本文基于 WebRTC M76 ,将通过展示两人加入视频会议的 App 界面来分析视频画面的渲染流程。
不管是远端还是本地的用户的视频画面渲染,我们可以将网络或本地的一些预处理看成一个盒子或者模块,我们可以从盒子或模块中不断的取出视频帧,然后通过 cpu 或 gpu 的处理将视频帧,也就是一张图片呈现到显示器上。WebRTC 的视频帧处理逻辑以及渲染逻辑是怎样的呢?这需要通过阅读代码来理清楚流程。
在 WebRTC 开发(四)源码下载与更新 一文中,我们获取到了可以在 iOS,macOS 平台运行的 WebRTC 源码。其中,在执行命令 fetch --nohooks webrtc_ios 时,我们可以明确看到代码支持的平台 ios, mac。
1 | suntongmiandeMacBook-Pro:webrtc suntongmian$ fetch --nohooks webrtc_ios |
以前,我的精力一直放在 iOS 平台的项目开发上,现在主要投入 Mac 平台的项目开发,所以,对 Mac 项目的关注度更大一些。下面的编译也以 Mac 为切入点。
WebRTC 的编译可以使用 ninja,也可以使用 Xcode。本文采用 Xcode 来编译 WebRTC 的 Mac 工程。
前文 WebRTC 开发(二)源码下载与编译 提到了 WebRTC 的下载和编译,但没有提及切换到某个 release 分支去做编译。
看了下博客的文章归档记录,有五个多月没更新音视频相关的文章了。至于是哪些因素影响了,我会在后续的随笔中写写。回归正题,在这五个多月里,WebRTC 更新了一些版本,我们可以通过 https://webrtc.org/release-notes/ 看下2019年1月到现在,Google 的 WebRTC 的进展。
M76 Release Notes, 2019年7月1日
M75 Release Notes, 2019年5月16日
M74 Release Notes, 2019年3月27日
M73 Release Notes, 2019年2月26日
WebRTC 是个庞大的项目,阅读项目的架构和每个版本的 release notes 是很有必要的。
这里顺带提下 Google 的工程开发日历 https://chromiumdash.appspot.com/schedule,可以了解 Google 项目开发的规划。
代码分支 https://chromiumdash.appspot.com/branches 上可以看 Google 浏览器的版本和内置的工具版本,比如 WebRTC
1 | Milestone Chromium Skia V8 WebRTC Pdfium |
前面松松散散开了个头,接下来的内容就是实际操作 WebRTC 源码的下载、更新、代码分支的切换。最后将分支 branch-heads/m76 拉取到了本地,后续的文章将基于 m76 这个版本来做讲解和分析。
通过 git branch -r 可以看到存在 branch-heads/m79,但是为什么不用 m79 呢?原因是 m76 是最新的 release 版本,稳定性和可调试性可以得到保证。
上一篇写的是 WebRTC 源码的下载和编译,为什么不先剖析 WebRTC 的架构设计而是先讲编译过程呢?原因是通过观察 WebRTC 的编译过程,能看到 WebRTC 里有什么。很多人觉得编译过程耗时长,就去干点其它的事坐等编译过程结束。我喜欢观察编译过程的打印信息,通过观察,可以看到 WebRTC 里面有什么,形成对 WebRTC 源码库有基本的认识。接触一个东西时,最初都是从局部到整体。知道 WebRTC 里面存在一些东西,但这些东西是如何组织在一起形成一个完整的解决方案的呢?那就要分析 WebRTC 的架构和设计了。
在使用任何工具之前,我们都有必要对工具做大概地的了解,做到粗犷但不失偏颇,这对我们选择工具和切入点是很关键的。本节的标题虽然是 WebRTC 源码下载与编译,但在这之前,我们有必要大概地了解 WebRTC,比如开发机构、免费性、支持的平台、功能亮点。
WebRTC 是一个免费开源的跨平台项目,由 Google,Mozilla,Opera 等支持,支持 Chrome,Firefox,Opera 以及 Android 和 iOS 平台,能够给浏览器、手机应用和物联网设备提供了实时互动能力。
WebRTC 是一组协议和 API。WebRTC 的起源可追溯到 2011年,经过六年多的时间的发展,在 2017年底 WebRTC 1.0 标准正式出炉。通过 WebRTC 的 Release Notes 可以看到现在最新的 release 版本是 M74 Release Noted。
2015年移动端直播的兴起,观众可以在手机端实时看主播的直播,但是观众与主播之间的沟通需要通过发弹幕来进行,这种交流的实时性较差,沟通不便利,观众参与感较差。2016年初移动端上出现了主播与观众之间可以通过实时视频聊天这种方式来沟通,即,视频连麦。那我们想实现这种视频连麦的功能该怎么做呢?
现在通过 WebRTC 以及其它一些音视频工具,我们就可以搭建一个视频聊天工具,做到视频连麦,也能做到类似于微信视频群聊。关于各种实现视频连麦的方式,这里就不细说了,放到后面的章节来解说。
了解到 WebRTC 是个什么东西后,通常人的心里就会产生一种跃跃欲试的冲动,想试试,那试试就试试呗。“磨刀不误砍柴工”这句话是有道理的,当我们没有经验和没有人传授经验的时候,那我们就要琢磨这句“磨刀不误砍柴工”了。我们要砍柴做饭,找到一把刀拿起就跑到树林里去砍柴,结果发现刀太钝,砍柴真费劲。这个时候,我们就意识到砍柴刀要用磨刀石磨一磨,磨锋利了,就能提升砍柴的效率。我举这个例子,就想说明两点:
三年前在 《聊一聊互动直播》中一文中谈了些对 WebRTC 和 RTC 的看法。现在 WebRTC 的热度不断攀升,我对 WebRTC 的热情也是一度高涨的,对实时音视频以及大数据、机器学习、深度学习这些方向的发展一直保持着关注。在 QN 工作了三年,这三年的远程办公经历,总结下来就是太忙了,工作和私人时间搅合在一起,感觉一天二十四小时都在工作,有些疲惫不堪,但收获也是有的。而今,经过一段时间的休息调整,状态恢复的不错,有时间思考,有时间写写自己的看法,还有点时间感受生活。
摧毁一个人,最直接最暴力的方式就是让他没有时间思考。没有时间思考的人,也是一个不懂得交流的人。如果一个人没有时间思考,也就没有自己的想法,更谈不上与人交流产生火花。时间是个很神奇的东西,能成就人,也能让人“几十年如一日”没有长进。特别是做程序员这行,思考力与实践力至关重要。对于生活与工作,作为人,我们更需要思考,会工作会生活。
最近温习数据结构与算法,在学习字符串的匹配算法 BM 算法、KMP 算法时,看到了两篇关于 KMP 算法讲解的文章,写的很经典。
阮一峰写的 字符串匹配的KMP算法
BF 算法、KMP 算法匹配过程如下:
主串 S:“BBC ABCDAB ABCDABCDABDE”
模式串 P:”ABCDABD”
BM 算法很简单,就是暴力匹配,以主串 S 为基准,模式串 P 从主串 S 的串头单步向后移动匹配到主串 S 的串尾。