IOS远程控制技术当中,最重要的环节是视频的输出,本文就目前出现的几种IOS视频流技术做一个实践和对比,重点会放在比较这几个方案在性能上的优缺点。
方案分析
IOS视频流方案,目前可以想到的有以下三种:
- 通过截屏获取图片,转换成视频流的形式,这种方法可见于facebook研发的WebDriverAgent(WDA)[1]技术,后由Appium进行维护,通过WDA的MJPEG服务接口获取屏幕截图,再用web-socket发送到浏览器端,就可以视觉上形成视频的效果。
- Apple自带的开发组件,获取视频流,比如屏幕音视频录制可以使用Apple开发组件:AirPlay、ReplayKit框架等。
- 使用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真机远程控制,用户体验上面可能会遇到一些瓶颈。
结果示意图如下:
结论
参考文献
WebDriverAgent服务:
STF开源项目:
replay kit 接口:
developer.apple.com/documentati…
qvh开源项目:
标签:WDA,浅谈,视频流,IOS,break,开源,延迟 From: https://blog.51cto.com/u_15649298/5719641