obs studio 开源直播软件 简介

目录

1.身世

2.皮肤变身

3.琴棋书画

4.杂耍

5.直播源数据获取

6.直播源数据管理

7.直播源数据渲染

8.直播源数据推流

总结

---

在直播如此火热的 2016 年，OBS 作为一名元老级开源组件在主播和开发面前继续展示着它常青的魅力。自己接触其源码小半年，发现国内的分析篇要么篇幅太短文不达意，要么内容太杂枯燥难懂，总是不令人满意。失望之余便想尝试挑战自己的审美观来分析一下这位美人，今天就首先来分析一下美人的个人状态。

1.身世

OBS 的爸爸是 jp9000，自出生起发展截止目前主要分为两个阶段，第一代犹如未成熟的少女尚未绽开，在设计和代码上都存在较多的缺陷，追求者基本来自叫 Windows 的城市。随着工程的膨胀导致后期维护成本变高，jp9000 也不满足其发展，便对其进行了整容重构，工程的线条变得更加明朗婀娜，追求者也多了来自 Mac 和 Linux 的城市，人数直接翻了两倍多，而且在继续增长。

2.皮肤变身

第一版用的是底层 winapi 写的窗口，所以大家会发现皮肤上面有很多痘痘：

基本一个控件一个句柄，第二版由于兼容 Mac 和 Linux，嵌入了全球著名皮肤精华水 QT，像战网、YY、WPS、优酷客户端、Dropbox 等都用的这款牌子，OBS 也紧跟潮流，成为了又一名「形象代言人」。

3.琴棋书画

OBS 之所以吸引人，主要根源于其具备极多的才艺，可以极大的满足大家的视听，我们来尝试梳理一下套路：

• 琴 - 音频编码：第一代用的 libfaac，第二代迁移到 ffmpeg，录制主要依靠就是 ffmpeg，利用管道跨进程写文件录播；
• 棋 - 视频编码：软编 x264、硬编 qsv、硬编 nvenc，其中 qsv 主要用的 libmfx，属于 inter 流派，nvenc 顾名思义就是 2016 股民们熟悉的 nvidia 流派，相对于 cudaenc 在h264 编码方面性能更优 ；
• 书 - 推流：第一代和第二代都用了鼎鼎大名的 rtmp 库，有推流地址和密钥便可以让所有主播上「电视」，斗鱼、熊猫、战旗、B站、全民直播都可以用这种方式推送；
• 画 - 渲染引擎：第一代只支持 dx，第二代支持分别封装了 dx 和 opengl ，shader 渲染脚本可以共用一份无差使用，语法用的 hlsl，在 opengl 渲染时包装内会转换成 glsl，了解原理后可以非常方便的嵌入各种 effect，可以加入更多的特效。

4.杂耍

第二版由于追求者众多，每个人都想在 OBS 上留下自己的印记，OBS 除了学会了展示窗口、显示器、图片、幻灯片、视频、游戏、文字之外，还可以展示浏览器（基于 cef）、vlc 视频等。在第二版所以这些印记可以方便替代升级，希望你也能鼓足勇气去贡献一把。

5.直播源数据获取

obs在启动时会优先加载 libobs 核心库，这个库初始化 obs 很多内容，包括crash 模块、com、性能监控等。初始化后会加载多个 module （windows下可以理解为dll），一般而言一个 module 对应一个功能特性，每个 moudle 加载时会初始化一些静态函数地址用于处理特性。

特性通过 id 来区分，如主播插入图片时，会调用 id 为“image_source”的moudle 函数来处理，并相应的增加一个对应的 source 对象。

对于外部调用接口而言，所有 module 的数据函数名称基本一致（对于不同type 略做调整），比如 video 类型的直播源数据对外接口长下面这样：

这样做的好处是有利于第三方贡献者接入，如果想加入一个新的直播源类型，只需要仿照已有 module 增加类似的特性处理函数而不用更改主程序框架。当然如果不习惯 C 语言，也可以切换为 C++ 用成员函数地址代替静态函数地址，其它语言依次类推。

6.直播源数据管理

对于直播源数据，obs 首先会建立其一个场景 (scene) 的概念，过程类似于开演唱会搭舞台。舞台场景中有很多部件 (scene_item) ，主播在直播时可以根据需要择时删除、隐藏、添加场景中的部件，管理非常便捷。基本数据结构如下：

obs 除了支持单个场景，也支持同时搭建多个场景，主播可以在场景间过渡切换，不过直播难度也会增加。对于观众而言观看直播犹如观看了一场演唱会，可以发弹幕尖叫呐喊。

7.直播源数据渲染

在obs初始化时会根据直播源类型对数据做一个分类，每一类数据对应相应的channelID，如 scene 对应的 channelID 为 0，麦克风对应的 channelID 为3，目前默认配置了6 个通道，分别用于 scene 、桌面音响、麦克风，最大可拓展为64个：

obs 在初始化时会开启一个 video 和 audio 线程用于定时更新数据，以vide o为例，对于每一个预览界面，首先会 new 一个 display 对象用于关联UIcallback 函数和 video 线程，直播时 video 线程定时更新会调用 UIcallbac k函数，触发场景和 UI 的绘制与刷新。大概流程如下：

（黄色代表线程，蓝色代表对象）

最终渲染会传递到每个scene_item，每个scene_item会绑定一个 texture，texture 对应的便是主播看见的直播画面，在调用 callback 之前会先调用 dx 或 opengl 更新这个 texture 。texture 绘制的顺序跟scene_item的顺序有关，scene_item以链表的形式串联起来，采用尾部插入的方式置入新直播源，外在展现便是越晚置入的直播源数据越在上层，主播调整直播源数据的顺序也就是调整链表的顺序。

8.直播源数据推流

有了直播源数据，主播端可以看见渲染的直播缓慢。但这还不够，只有推送到后台才能展现给更多的观看用户。在直播源推送时会首先创建推流 video 和 audio 的 encoder 对象，并创建 output 对象管理 encode r对象，绑定 encoder 对象与 video 、audio 数据源最后使用 rtmp 或者 flv 推流，关系如下：

对于目前常见的 rtmp 推流过程，主要分为三个步骤：

• 创建connect线程连接服务器，初始化rtmp模块；
• 连接服务器成功后创建send线程并开启hook数据；
• send线程根据信号量来控制是否发送数据，信号量在hook时会重置；

其中 hook 数据的过程可以理解为关联数据采集和数据发送，如下图所示：

（黄色代表线程，蓝色代表对象）

video 和 audio 对象都会绑定回调函数，当 video 与 audio 线程检测到内容有更新时，会根据是否需要编码触发不同的回调函数对数据进行处理，最后序列化后通过 rtmp 打包发送到后台。

总结

obs的整个开播过程都是围绕数据源展开的，代码核心部分由C语言编写，UI层则用的C++11。数据更新回调较多，除了QT的singal和slot的通信机制