本文基于 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 版本,稳定性和可调试性可以得到保证。
《搬瓦工搭建 ShadowSocks 翻墙(VPN)系列》
(1) 搬瓦工搭建 ShadowSocks 翻墙(VPN)
(2) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 IP 被墙
(3) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 port 被封
(4) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 更换密码
我写一篇文章时,都要交待下写作的原因。交待下原因,透露出多的信息,会更好的发挥文章的价值。在 搬瓦工搭建 ShadowSocks 翻墙(VPN) 一文发布后不久,就收到了同学的留言“VPN 服务搭建完成后,想更换密码该怎么操作?”。请允许我过多的使用同学一词,因为我觉得这个叫法很亲切,谓之同学,乃共同进步之意。
刚开始看到这个留言的时候,我觉得这不是什么硬需求,毕竟密码设置这个东西在我们操作的时候肯定是在脑海中思考好了的。如果真的出现设置的密码不好记、密码太长、密码忘记了该怎么办呢?真的就需要重新再搭建一次 VPN 服务?有没有更好更简单的办法解决问题?
《搬瓦工搭建 ShadowSocks 翻墙(VPN)系列》
(1) 搬瓦工搭建 ShadowSocks 翻墙(VPN)
(2) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 IP 被墙
(3) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 port 被封
(4) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 更换密码
在上一篇 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 IP 被墙 谈到了如何解决 IP 被墙的问题,但没有提及端口 port 被封的问题。本文就来说一下 port 被封导致 VPN 服务无法使用的问题。
之前我在使用过程中,出现过 VPN 突然无法使用的问题。定位下来的原因是 IP 被墙了。其实更详细的原因是 IP 被墙,端口 port 被封。我用工具检测了 IP 地址、port 端口,检测结果是 IP 地址国内检测点超时,国外监测点正常,port 端口处于关闭状态。我在 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 IP 被墙 一文中只提到了更换 IP 的解决途径。为什么我没有提到要更换 port 端口呢?原因在于使用更换后的 IP 地址,也就是新的 IP 地址搭建 VPN 服务时,默认的 VPN 服务端口 port 跟以前搭建的 VPN 服务的默认端口 port 不一样,我每次搭建 VPN 服务的时候,都是使用提示的默认端口号 port,这让 port 端口被封导致 VPN 服务无法使用的问题没有暴露出来。
《搬瓦工搭建 ShadowSocks 翻墙(VPN)系列》
(1) 搬瓦工搭建 ShadowSocks 翻墙(VPN)
(2) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 IP 被墙
(3) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 解决 port 被封
(4) 搬瓦工搭建 ShadowSocks 翻墙(VPN)- 更换密码
使用搬瓦工搭建 ShadowSocks 翻墙(VPN) 一文中写了如何搭建 VPN 翻墙工具,但对于可能出现的问题没有提及。本文要说的是 VPN 服务所在的主机 IP 被墙后导致 VPN 服务无法使用的问题。
事情经过是这样的,今天我想使用 VPN 服务访问 Google 的服务,发现 google.com 响应超时。有点想不通,因为前几天 VPN 服务可以正常使用。出现这种问题,那就需要排查问题所在了。
(1)访问 搬瓦工 (BandwagonHost) 主页,登录之后,查看主机的运行状态。
结果:主机处在正常运行中。
上一篇写的是 WebRTC 源码的下载和编译,为什么不先剖析 WebRTC 的架构设计而是先讲编译过程呢?原因是通过观察 WebRTC 的编译过程,能看到 WebRTC 里有什么。很多人觉得编译过程耗时长,就去干点其它的事坐等编译过程结束。我喜欢观察编译过程的打印信息,通过观察,可以看到 WebRTC 里面有什么,形成对 WebRTC 源码库有基本的认识。接触一个东西时,最初都是从局部到整体。知道 WebRTC 里面存在一些东西,但这些东西是如何组织在一起形成一个完整的解决方案的呢?那就要分析 WebRTC 的架构和设计了。