一、兼容性适配处理
为什么需要兼容处理?
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 图形技术栈的最新方向。