• 从几个开源项目浅谈IOS视频流输出方案


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

    方案分析

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

    1. 通过截屏获取图片,转换成视频流的形式,这种方法可见于facebook研发的WebDriverAgent(WDA)[1]技术,后由Appium进行维护,通过WDA的MJPEG服务接口获取屏幕截图,再用web-socket发送到浏览器端,就可以视觉上形成视频的效果。

    2. Apple自带的开发组件,获取视频流,比如屏幕音视频录制可以使用Apple开发组件:AirPlay、ReplayKit框架等。

    3. 使用MAC本身的QUICKTIME对IOS设备进行录制,这种方式需要通过程序来启用QUICKTIME。

    实践和对比

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

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

    1080×381 24.2 KB

    流程图

    1. WebDriverAgent MJPEG 图片服务器

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

    结果示意图如下:

    1080×646 401 KB

    2. Replay kit 视频流

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

    1. - (void)processSampleBuffer:(CMSampleBufferRef)sampleBuffer withType:(RPSampleBufferType)sampleBufferType {
    2. @synchronized(self) {
    3. switch (sampleBufferType) {
    4. case RPSampleBufferTypeVideo:
    5. // Handle video sample buffer
    6. if (!CMSampleBufferIsValid(sampleBuffer))
    7. {
    8. return;
    9. }
    10. if (tempVideoTimeStamp && (CFAbsoluteTimeGetCurrent() - tempVideoTimeStamp < 0.01))
    11. {
    12. NSLog(@"load frame...");
    13. }
    14. else{
    15. [imageHandler pushOneFrame:sampleBuffer];
    16. tempVideoTimeStamp = CFAbsoluteTimeGetCurrent();
    17. }
    18. break;
    19. case RPSampleBufferTypeAudioApp:
    20. // Handle audio sample buffer for app audio
    21. break;
    22. case RPSampleBufferTypeAudioMic:
    23. // Handle audio sample buffer for mic audio
    24. break;
    25. default:
    26. break;
    27. }
    28. }

    结果示意图如下:

    1080×673 371 KB

    3. Qvh视频流

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

    996×567 324 KB

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

    结果示意图如下:

    892×679 374 KB

    结论

  • 相关阅读:
    使用 etcdadm 快速、弹性部署 etcd 集群
    ResNet——Deep Residual Learning for Image Recognition(论文阅读)
    第三章:存储系统
    QT读取DLL加载算法
    【大数据】-- flink kubernetes operator 入门与实践
    Redis进阶
    最近面试 Java 开发的感受:就以平时项目经验面试,通过估计很难
    neo4j load csv 配置和使用
    企业架构LNMP学习笔记45
    NFT 分化趋势已显,如何捕获价值?
  • 原文地址:https://blog.csdn.net/ceshiren456/article/details/126782211