软件测试 | 测试开发 | 从几个开源项目浅谈IOS视频流输出方案

IOS远程控制技术当中，最重要的环节是视频的输出，本文就目前出现的几种IOS视频流技术做一个实践和对比，重点会放在比较这几个方案在性能上的优缺点。

方案分析

IOS视频流方案，目前可以想到的有以下三种：

1. 通过截屏获取图片，转换成视频流的形式，这种方法可见于facebook研发的WebDriverAgent（WDA)[1]技术，后由Appium进行维护，通过WDA的MJPEG服务接口获取屏幕截图，再用web-socket发送到浏览器端，就可以视觉上形成视频的效果。
2. Apple自带的开发组件，获取视频流，比如屏幕音视频录制可以使用Apple开发组件：AirPlay、ReplayKit框架等。
3. 使用MAC本身的QUICKTIME对IOS设备进行录制，这种方式需要通过程序来启用QUICKTIME。

实践和对比

这里根据几个开源项目，做一个不同技术方案的视频流效果对比。

为方便比较，展示视频流的应用架构基本一致，不同之处在于使用哪种方式去获取视频流，程序架构图如下：

流程图

1. WebDriverAgent MJPEG 图片服务器

这里我们用开源项目STF[2] 来观察WDA图片服务视频流的效果。我们部署了一套STF在机器上，通过手机的秒表来记录视频流的延迟，结果是大概延迟200毫秒左右，点击有肉眼可见的卡顿。缺点是WDA服务启动过程略长，同时功能上不支持音频服务。

结果示意图如下：

2. Replay kit 视频流

Apple开发组件replay kit[3] 经常用于直播当中，可以实时的获取视频流，它是通过IOS内置的录制视频组件，在苹果手机上启动一个视频输出的服务，再从此端口获取视频流。优点是传输快，缺点是由于使用了本身的录屏功能，因此对苹果硬件损耗大，手机容易发热，使用它做IOS视频流输出时，无法再使用直播APP。我们使用将replay kit录屏方式，服务端使用python的socket方法接收视频流，展示在前端，做了个简单的程序，验证了下效果，延迟大概100-200ms之间。

- (void)processSampleBuffer:(CMSampleBufferRef)sampleBuffer withType:(RPSampleBufferType)sampleBufferType {

    @synchronized(self) {
        switch (sampleBufferType) {
            case RPSampleBufferTypeVideo:
                // Handle video sample buffer
                if (!CMSampleBufferIsValid(sampleBuffer))
                {
                    return;
                }

                if (tempVideoTimeStamp && (CFAbsoluteTimeGetCurrent() - tempVideoTimeStamp < 0.01))
                {
                    NSLog(@"load frame...");
                }
                else{
                    [imageHandler pushOneFrame:sampleBuffer];
                    tempVideoTimeStamp = CFAbsoluteTimeGetCurrent();
                }

                break;
            case RPSampleBufferTypeAudioApp:
                // Handle audio sample buffer for app audio
                break;
            case RPSampleBufferTypeAudioMic:
                // Handle audio sample buffer for mic audio
                break;

            default:
                break;
        }
    }

结果示意图如下：

3. Qvh视频流

QVH[4]通过使用MAC QUICKTIME组件，进行屏幕录制视频，是目前github上的开源项目，这款技术理论上可以用在MAC，LINUX上，可以独立实现录制屏幕。该技术可以继续加入音频。我们使用web-socket技术，把qvh输出的视频流展示出来，得到的结果是延迟略高，我们再来看下qvh本身的延迟，大概有200毫秒，如下图：

通过web-socket转到前端后，延迟在200-700ms之间，假如用于IOS真机远程控制，用户体验上面可能会遇到一些瓶颈。

结果示意图如下：

结论