请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 6
移动端IM实践:iOS版微信小视频功能技术方案实录

本文由微信开发团队人员编写,转自 WeMobileDev,感谢。


前言


微信里的小视频功能(有些移动端IM里也叫“短视频”)是微信6.0版亮点功能之一,微信技术人员在开发此功能过程中遇到过不少问题,现将技术实现过程中遇到的问题及解决方案分享给大家,希望能对有类似需求的同行有所启发。

产品经理的需求


微信小视频.jpg

1录制需求


  • 支持白平衡、对焦、缩放;
  • 录制视频长度6秒,30帧/秒,尽量不丢帧;
  • 能录制不同尺寸和码率的视频。

2播放需求


  • 可以同时播放多个视频;
  • 用户操作界面时视频可以继续播放;
  • 播放时不能卡住界面,视频滑进界面内后要立即播放;
  • 视频在列表内播放是静音播放,点击放大是有声播放。

技术实现:录制


对于需求1:“支持白平衡、对焦、缩放”,AVFoundation有API可以支持,这里不多说。这里重点说说需求2:“录制视频长度6秒,30帧/秒,尽量不丢帧”、需求3:“能录制不同尺寸和码率的视频”的实现方案。

AVCaptionConnection.png

前期录制方案如下:

  • 创建AVCaptureSession,设置拍摄分辨率;
  • 添加AVCaptureInput,如摄像头和麦克风;
  • 添加AVCaptureOutput,如AVCaptureVideoDataOutput、AVCaptureAudioDataOutput:
       这里AVCaptureAudioDataOutput建议在Session -startRunning后才添加,避免影响摄像头启动时间。
  • 添加AVCaptureVideoPreviewLayer,为用户提供拍摄预览界面;
  • 创建MMovieWriter,里面包含AVAssetWriter对象,用于写视频;
  • 开始捕捉-startRunning;
  • AVCaptureVideoDataOutput和AVCaptureAudioDataOutput不停地往MMovieWriter传递VideoSampleBuffer和AudioSampleBuffer,MMovieWriter对VideoSampleBuffer做分辨率压缩,以及对AudioSampleBuffer做码率压缩;
  • 结束捕捉-stopRunning,MMovieWriter停止写视频,把生成的视频文件抛给上层。

在4s以上的设备拍摄小视频挺流畅,帧率能达到要求。但是在iPhone4,录制的时候特别卡,录到的视频只有6~8帧/秒。尝试把录制视频时的界面动画去掉,稍微流畅些,帧率多了3~4帧/秒,还是不满足需求。通过Instrument检测,发现跟写音频时的压缩有关,写音频时阻塞了AVFoundation的线程,引起后续的丢帧。网上也有人反馈类似问题 http://stackoverflow.com/questio ... single-core-devices。把写音频去掉后,帧率果然上去了。但是系统相机的拍摄视频是非常流畅的。于是用AVCaptureMovieFileOutput(640*480)直接生成视频文件,拍视频很流畅。然而录制的6s视频大小有2M+,再用MMovieDecoder+MMovieWriter压缩至少要7~8s,影响聊天窗口发小视频的速度。

综上所述,要想拍视频不卡,就要在录制过程中尽量不做CPU耗时操作,而且AVCaptureOutput传递数据给上层时不能卡住AV线程。最终想到个方案,加个Cache层,先把AVCaptureOutput传递的SampleBuffer缓存下来,不在AV的线程写视频;等CPU空闲时,再唤起movieWriter线程写视频。流程如下图所示:

0.png

通过这样处理,拍视频流畅度跟系统相机接近了,只是刚拍的前1s帧数只有18帧,后面稳定到30帧/秒左右了。而且用户松手拍完后,最多等1s就能把视频写完文件了;也优化了之前的视频截图生成接口,减少200ms。不过拍摄稳定性不够好,经常出现下面的写失败错误,频率大概是6次/100次:
[GL] <MMovieWriter.mm:476::-[MMovieWriter appendAudioSampleBufferInternal:]> INFO: audio writer status 3, desc Error Domain=AVFoundationErrorDomain Code=-11800 "这项操作无法完成" UserInfo=0x11495910 {NSLocalizedDescription=这项操作无法完成, NSUnderlyingError=0x1146e8d0 "The operation couldn’t be completed. (OSStatus error -12633.)", NSLocalizedFailureReason=发生未知错误(-12633)}

通过google搜索,网上说这错误原因是同一个FrameTime写入了两帧。但是FrameTime是从SampleBuffer里取的,理论上不会时间重合(我没打log验证);而且老方案没出现这种错误,新方案延后处理才会出现的。经过多次试验,把Buffer Cache设置上限,当Buffer数达到一定数量后强制让MovieWriter写入文件,同时把下面这行代码注释,错误不再出现了:
//m_writer.movieFragmentInterval = CMTimeMakeWithSeconds(1.0, 1000); // AVAssetWriter

方案对比:

方案录制平均码率(fps/s)拍完到看到预览的间隔(s)
不加Buffer Cache7.20.64
加入Buffer Cache27.31.2

注:以上数据基于iPhone4聊天窗口拍摄若干个6s视频10次,算平均值。

技术实现:播放


1MPMoviePlayerController方案


MPMoviePlayerController是一个简单易用的视频播放控件,可以播放本地文件和网络流媒体,支持mov、mp4、mpv、3gp等H.264和MPEG-4视频编码格式,支持拖动进度条、快进、后退、暂停、全屏等操作,并为开发者提供了一系列播放状态事件通知。使用时先设置URL,然后把它的view add到某个parent view里,再调用play即可。

但这方案的缺点是,同一时间只能有一个MPMoviePlayerController对象播放,不满足同时多个播放的需求;而且也不支持静音播放。MPMoviePlayerController适合于全屏播放视频的场景。

2AVPlayer方案


VPlayer是AVFoundation.Framework提供的偏向于底层的视频播放控件,用起来复杂,但功能强大。单独使用AVPlayer是无法显示视频的,要把它添加到AVPlayerLayer里才行。另外它需要配合AVPlayerItem使用,AVPlayerItem类似于MVC里的Model层,负责资源加载、视频播放设置及播放状态管理(通过KVO方式来观察状态)。它们关系如下:

avplayerLayer_2x.png

首先创建一个AVPlayerItem对象:
NSURL* videoUrl = [NSURL fileURLWithPath:m_path isDirectory:NO];
m_playItem = [AVPlayerItem playerItemWithURL:videoUrl];

// 监听playItem的status属性
[m_playItem addObserver:self forKeyPath:@"status" 
    options:NSKeyValueObservingOptionNew context:nil];

接下来是创建AVPlayer和AVPlayerLayerView对象。AVPlayerLayerView是自定义的UIView,用于AVPlayer播放,其layerClass是AVPlayerLayer:
// AVPlayer
m_player = [AVPlayer playerWithPlayerItem:m_playItem];
m_player.actionAtItemEnd = AVPlayerActionAtItemEndNone;

// AVPlayerLayerView
m_playerView = [[AVPlayerLayerView alloc] initWithFrame:self.bounds];
[self addSubview:m_playerView];

// 把AVPlayer添加到AVPlayerLayer
[(AVPlayerLayer*)[m_playerView layer] setPlayer:m_player];

// 观察AVPlayerItem播放结束的通知
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(itemPlayEnded:) 
    name:AVPlayerItemDidPlayToEndTimeNotification object:m_playItem];

AVPlayerItem的status属性有三种状态:AVPlayerStatusUnknown、AVPlayerStatusReadyToPlay及AVPlayerStatusFailed。当status=AVPlayerStatusReadyToPlay时,就代表视频能播放了,此时调用AVPlayer的play方法就能播放视频了。

相比MPMoviePlayerController,AVPlayer有最多可以同时播放16个视频。另外AVPlayer在使用时会占用AudioSession,这个会影响用到AudioSession的地方,如聊天窗口开启小视频功能。还有AVPlayer释放时最好先把AVPlayerItem置空,否则会有解码线程残留着。最后是性能问题,如果聊天窗口连续播放几个小视频,列表滑动时会非常卡。通过Instrument测试性能,看不出哪里耗时,怀疑是视频播放互相抢锁引起的。

3AVAssetReader+AVAssetReaderTrackOutput方案


既然AVPlayer在播放视频时会有性能问题,我们不如做自己的播放器。AVAssetReader可以从原始数据里获取解码后的音视频数据。结合AVAssetReaderTrackOutput,能读取一帧帧的CMSampleBufferRef。CMSampleBufferRef可以转化成CGImageRef。为此,我们可以写个MMovieDecoder的类,负责视频解码,每读出一个SampleBuffer就往上层回调:
AVAssetReader* reader = [[AVAssetReader alloc] initWithAsset:m_asset error:&error];
NSArray* videoTracks = [m_asset tracksWithMediaType:AVMediaTypeVideo];
AVAssetTrack* videoTrack = [videoTracks objectAtIndex:0];

// 视频播放时,m_pixelFormatType=kCVPixelFormatType_32BGRA
// 其他用途,如视频压缩,m_pixelFormatType=kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange
NSDictionary* options = [NSDictionary dictionaryWithObject:[NSNumber numberWithInt:
        (int)m_pixelFormatType] forKey:(id)kCVPixelBufferPixelFormatTypeKey];
AVAssetReaderTrackOutput* videoReaderOutput = [[AVAssetReaderTrackOutput alloc] 
        initWithTrack:videoTrack outputSettings:options];
[reader addOutput:videoReaderOutput];
[reader startReading];

// 要确保nominalFrameRate>0,之前出现过android拍的0帧视频
while ([reader status] == AVAssetReaderStatusReading && videoTrack.nominalFrameRate > 0) {
    // 读取video sample
    CMSampleBufferRef videoBuffer = [videoReaderOutput copyNextSampleBuffer];
    [m_delegate mMovieDecoder:self onNewVideoFrameReady:videoBuffer);
    CFRelease(videoBuffer);    
    // 根据需要休眠一段时间;比如上层播放视频时每帧之间是有间隔的
    [NSThread sleepForTimeInterval:sampleInternal];
}
    
// 告诉上层视频解码结束
[m_delegate mMovieDecoderOnDecodeFinished:self];

另一个是MVideoPlayerView,负责视频的显示,它接收MMovieDecoder回调的CMSampleBufferRef后,把它转为CGImageRef,然后设置layer.contents为这个CGImageRef对象。创建CGImageRef不会做图片数据的内存拷贝,它只会当Core Animation执行Transaction::commit()触发layer -display时,才把图片数据拷贝到layer buffer里。

AVAssetReader也能decode音频的SampleBuffer,不过本人还没想到如何播放CMSampleBufferRef的音频,目前只能静音播放。

4以上方案测试对比


* 对方案2、3做了滑动性能对比和耗电对比,测试条件分别是:
  • 滑动:在iPhone4的聊天窗口,有30个小视频,来回做4次列表滑动;
  • 耗电:在iPhone5s,屏幕亮度调到最大,禁止自动锁屏,开启飞行模式,聊天窗口同时播放着3个小视频,10分钟。

方案屏幕滑动(fps)耗电(mHA/s)
AVPlayer18.70.127
MyMoviePlayer42.40.110

5以上方案测试结论


方案3无论滑动性能和耗电均优于方案2,由于方案3只能静音播放,所以方案3用于聊天窗口和朋友圈列表播放,方案2用于点击放大时的有声播放。

全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、V8的前世今生
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登录请求的优化
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

附录:有关QQ、微信的文章汇总


[1] 有关QQ、微信的技术文章:
微信后台团队:微信后台异步消息队列的优化升级实践分享
微信团队原创分享:微信客户端SQLite数据库损坏修复实践
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
微信Mars:微信内部正在使用的网络层封装库,即将开源
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]
微信团队原创分享:Android版微信从300KB到30MB的技术演进
微信技术总监谈架构:微信之道——大道至简(演讲全文)
微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]
如何解读《微信技术总监谈架构:微信之道——大道至简》
微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]
微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案
微信朋友圈海量技术之道PPT [附件下载]
微信对网络影响的技术试验及分析(论文全文)
一份微信后台技术架构的总结性笔记
架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
快速裂变:见证微信强大后台架构从0到1的演进历程(二)
微信团队原创分享:Android内存泄漏监控和优化技巧总结
全面总结iOS版微信升级iOS9遇到的各种“坑”
微信团队原创资源混淆工具:让你的APK立减1M
微信团队原创Android资源混淆工具:AndResGuard [有源码]
Android版微信安装包“减肥”实战记录
iOS版微信安装包“减肥”实战记录
移动端IM实践:iOS版微信界面卡顿监测方案
微信“红包照片”背后的技术难题
移动端IM实践:iOS版微信小视频功能技术方案实录
移动端IM实践:Android版微信如何大幅提升交互性能(一)
移动端IM实践:Android版微信如何大幅提升交互性能(二)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
移动端IM实践:iOS版微信的多设备字体适配方案探讨
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事:
技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码
技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史
开发往事:深度讲述2010到2015,微信一路风雨的背后
开发往事:微信千年不变的那张闪屏图片的由来
开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)
一个微信实习生自述:我眼中的微信开发团队
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:移动端IM实践:Android版微信如何大幅提升交互性能(二)下一篇:微信“红包照片”背后的技术难题

本帖已收录至以下技术专辑

推荐方案
评论 6
这需求:
可以同时播放多个视频;
用户操作界面时视频可以继续播放;
播放时不能卡住界面,视频滑进界面内后要立即播放;
视频在列表内播放是静音播放,点击放大是有声播放。

看一眼就头大:UI线程、后台播放程、UI与后台线程状态同步、列表滑动事件处理。。。。
签名: 好久没来了,签个到
学习了,最近正在做小视频的开发,可以借鉴使用到自己的项目中,哈哈
引用:copper 发表于 2017-04-13 10:08
学习了,最近正在做小视频的开发,可以借鉴使用到自己的项目中,哈哈

希望对你有帮助
签名: 今天有点头晕。。
有源码github分享吗
引用:诗说穿石 发表于 2017-05-10 17:55
有源码github分享吗

只能等微信开源了
签名: 今天有点头晕。。
感谢分享
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部