前几篇都是拉流这头:WebRTC 的流进来,解码渲染归播放器。这篇是推流那头:WebRTC 自带的源和编码器用不上项目已有的东西——各平台的硬编、截屏与摄像头这...

两台设备互看,一台拍一台看,方向反过来也一样。这条链拆开是五段:拉流、解码、图像处理、编码、推流,每段都留了不止一种做法——拉流推流可以在两套实现里挑,解码编码...

播放器要播 WebRTC 的流,有一种接法是把它的原始包拉下来,照 RTSP 那套自己拆自己解——复用度最高,但 WebRTC 为实时做的那几样东西(抗抖动缓冲...

录屏录音推出去,对面听到的声音有回声、有噪音,音量还忽大忽小。这三件事在音视频里合称 3A(回声消除、降噪、自动增益),WebRTC 里有一整套维护了很多年的处...

要在自己的工程里用 WebRTC 的音频处理和解码工厂,得先把 WebRTC 这个库编出来。它不走常规的 CMake,代码要用 depottools 拉,构建用...

Apple 平台上的硬编接口给的东西比较全:一个压缩会话负责一切,配好几个属性就能收帧出包。它的输入可以是三种帧——带共享面的、系统原生像素缓冲的、以及内存里的...

Apple 平台上采画面与采声音走的是同一套采集会话:挂不同的输入设备、挂不同的输出,回调走同一种委托。所以这一侧的结构比另外两个平台更整齐——差别集中在格式与...

在 Apple 平台上,硬解帧天生就是能直接给 Metal 用的——带一个可以映射成纹理的面。所以这一侧不需要先拷一次:平面各取一张纹理、画成一张 RGBA,再...

Apple 平台上的硬解接口是 C 的,但周边全是 Objective-C 与 CoreMedia 的对象。边界划得清不清,决定了这一层是「一个 C++ 类顺手...

Android 这边硬编有两种给输入的方式:一种是把平面数据拷进队列,一种是让编码器拿出一个「能收纹理的面」,由渲染那一侧把帧画进去。前一种通用,后一种省一次拷...

Android 上采画面与采声音落在两套完全不同的东西上:相机走 NDK 那套相机接口,声音反过来要落到 Java 侧去用录音类。相机这一侧有个选择要做:采到的...

硬解在 Android 上出来的是一张外部纹理,GL 能直接采样,Vulkan 不行。所以这一帧要先由平台渲染器转成一张普通的 RGBA 纹理,再由它决定往哪去...

硬解在 Android 上要过两套东西:一套是 MediaCodec 那边的创建与配置,另一套是 Surface 那边的生命周期。前者里这里有一道关口——参数集...

H.265 在安防、教育、广电这几个圈子里基本已经是默认编码。摄像头出厂就是 H.265，同画质下码率比 H.264 省将近一半。

硬编这件事在两端的说法不一样:苹果与安卓各自有系统给的编码器接口,Windows 这边则是先在一张表里挑一个编码器,再决定帧怎么进去。挑的部分与解码那侧同构,但...

播放器要能把屏幕、摄像头、麦克风都当成一个源,但三者的来路完全不同:屏幕和窗口是抓出来的画面,摄像头是设备推来的码流,声音还要分麦克风与声卡回环两套。Windo...

硬解帧出来是一张平面的 NV12 纹理,窗口和 Vulkan 都直接吃不了,所以先去平台的像素处理层转成 RGBA。转完的产物有两个消费者:一个把它导进 Vul...

前面几章解出来的帧都躺在内存里,每帧还要再传一次才能上屏。硬解要做的就是把这步搬到显存里,让帧从解码器出来时本来就在 GPU 上。难点在每个平台都是自己那一套:...