Linux 音视频SDK开发实践

一、兼容性适配处理

为什么需要兼容处理？

1、c++兼容处理

主要有ABI兼容性问题，不同ubuntu系统依赖的ABI版本如下：

	ubuntu 18.04	ubuntu 16.04	ubuntu 14.04
g++	7.5	5.4	4.8
stdc++版本	libstdc++.so.6.0.25	libstdc++.so.6.0.21	libstdc++.so.6.0.19
GLIBCXX	GLIBCXX_3.4.25	GLIBCXX_3.4.21	GLIBCXX_3.4.19

若用ubuntu 18.04开发的SDK，在utuntu 16.04去集成SDK开发APP，链接大概率无法通过（如果使用到GLIBCXX_3.4.21以上或CXXABI_1.3.9以上的符号），错误举例如下：

undefined reference to `std::__exception_ptr::exception_ptr::exception_ptr(void*)@CXXABI_1.3.11
undefined reference to `std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)())@GLIBCXX_3.4.22
undefined reference to `__cxa_init_primary_exception@CXXABI_1.3.11'
undefined reference to `std::thread::_State::~_State()@GLIBCXX_3.4.22'
undefined reference to `typeinfo for std::thread::_State@GLIBCXX_3.4.22

鉴于此，我们采用静态链接C++标准库的方式解决高版本开发环境到低版本生成环境无法运行的问题。

思考：怎么操作？
cmake方式下可以在CMakeLists.txt增加一条链接命令target_link_libraries(${PROJECT_NAME} -static-libgcc -static-libstdc++

总结：为了充分利用C++语言的新特性和高级功能，我们开发使用了较高版本的gcc/g++和stdc++，但输出的SDK不再依赖c++，也就实现了开发环境和生产环境的解耦，这里的生产环境可以指代使用SDK的客户开发环境和生产环境。

2、c兼容处理

和c++兼容性一样，c也有同样问题。
如果采用静态链接c库的方式，会造成产物二进制体积暴增，如果对包体积大小不敏感，可以采用此方式，另外可以选择一个低版本的c库去编译链接，这样编译出来的产物就只依赖低版本的c库，这样在高版本的系统里运行是没有兼容性问题的。

target_link_libraries(${RTCSDK_LIBRARY_NAME} ${LIB_DIR}/libc-2.19.so) # ubuntu 14.04, gcc4.8
target_link_libraries(${RTCSDK_LIBRARY_NAME} ${LIB_DIR}/libm-2.19.so)

3、iot兼容处理

Linux音视频SDK除了运行于桌面端环境（比如x86_64-ubuntu, aarch64-uos等），也可以应用于IoT领域(arm-linux平台），比如arm云对讲，教育录播场景。

实践中发现OpenSSL在arm上存在一些兼容性问题，比如使用libcurl based on OpenSSL实现https通信场景下会出现ssl connect error等一系列疑难问题，后来使用libcurl based on mbedTLS顺利解决这个问题，mbedTLS是为嵌入式设备而开发的一个TLS协议的轻量级实现，用作OpenSSL的一个轻量级替代。(参考https://github.com/Mbed-TLS/mbedtls）

二、音频开发

音频开发技术栈包括：

• 基于ALSA驱动开发
• 基于PulseAudio服务开发
• 基于PipeWire服务开发

基于ALSA驱动开发存在独占，混音等诸多难题，开发难度大；PulseAudio声音服务作为声音系统的代理，对上层应用开发较友好，开发者完全不用考虑底层复杂的处理细节；PipeWire作为新一代Linux audio/video bus，旨在取代PulseAudio并统一音视频框架，但目前尚未全面普及，稳定性暂时不如PulseAudio（进展：ubuntu 22.04桌面系统内部预安装了PulseAudio和PipeWire服务，ubuntu 22.10预计会用PipeWire直接替换PulseAudio,基于此并考虑到到当前大多数Linux桌面系统发行版(包括低版本）都将PulseAudio作为默认声音服务器提供音频能力，我们倾向于选用PulseAudio进行音频功能开发，包括：

• 音频设备枚举
  • 包括输入设备（micphone）和输出设备（speaker）
• 音频采集（输入）
• 音频播放（渲染）
• 音频设备事件通知
  • 包括默认设备变更，音频输入和输出设备插入、拔出等

三、视频开发

包括以下功能：

• 基于V4L2视频采集
• 基于OpenGL视频渲染
• 视频设备事件通知
  • 插入、拔出操作等

V4L2（Video For Linux Two的缩写）是Linux下关于视频采集相关设备的驱动框架，为驱动和应用程序提供了一套统一的接口规范。应用程序通过一系列IO系统接口即可完成摄像头数据采集功能，摄像头在Linux系统下会被映射为/dev/video0,/dev/video1等设备文件，特别应注意，V4L2支持的设备十分广泛，但是其中只有很少一部分在本质上是真正的视频设备，实际使用过程中应该特别关注V4L2_CAP_VIDEO_CAPTURE特征，如下：

struct v4l2_capability {
    __u8 driver[16];
    __u8 card[32];
    __u8 bus_info[32];
    __u32 version;
    __u32 capabilities;
    __u32 device_caps;
    __u32 reserved[3];
};

 struct v4l2_capability cap;
if (ioctl(fd, VIDIOC_QUERYCAP, &cap) == 0) 
{
    if (cap.device_caps & V4L2_CAP_VIDEO_CAPTURE)
    { 
       // it is real video
    }
}

Linux 桌面视频渲染较多采用OpenGL渲染，Qt跨平台框架QOpenGLWidget也是基于OpenGL实现的。

四、屏幕共享开发

在Linux的世界里，桌面、窗口或图形化界面并不是必须的，因为Linux是基于命令行的操作系统，图形界面只是Linux下的一个应用程序，不带桌面的发行版也可以自己动手安装上桌面，屏幕共享的实现依赖于桌面环境，更准确的说法应该窗口系统或显示服务器。

窗口系统：
在Linux系统下，有两个比较常见的窗口系统，X Window System（X11）和Wayland，但当前使用最多的还是X11，窗口系统均采用C/S架构。

1、 基于X11屏幕共享开发

适用于X11窗口系统

基于X11进行开发，包括桌面共享和窗口共享，依赖X11，Xdamage，Xfixes，Xext，Xcomposite，xcb，Xdmcp和Xau库等。
客户端应用使用xlib（参考https://www.x.org/releases/current/doc/libX11/libX11/libX11.html）与X Server进行通信，完成屏幕共享等图形功能。

2、基于pipewire 屏幕共享开发

适用于Wayland 窗口系统

WebRTC M95升级pipewire0.2到pipewire0.3，实现了基于pipewire进行屏幕共享和窗口共享功能，内部使用D-bus做为通信方式，依赖pipewire-0.3，glib-2.0，gio-2.0和gobject-2.0四个库。

以上流程分为两大模块，屏幕源选择（由xdg-desktop-portal实现)，pipewire流处理和数据回调，针对屏幕源选择，不像X11需要自己去实现源选择对话框，这里开箱即用。

3、番外（ubuntu 桌面窗口系统演进）

ubuntu在17.04版本引入了wayland，但由于无法实现屏幕共享，远程桌面等问题，在18.04版本去除了wayland feature，重新拥抱Xorg，到22.04版本正式支持了wayland，默认启动wayland窗口系统，同时保留切换为X11的选项（登录界面可进行切换）。除了ubuntu 发行版，其它Linux发行版也在跟进wayland的支持，可见wayland已成为Linux 图形技术栈的最新方向。

4、补充（Linux 图形栈技术）