移动端音视频应用优化之道(共5页).docx

精选优质文档-倾情为你奉上移动端音视频应用优化之道手机APP在音视频方面的应用产品，近两年呈井喷状态。观众在流畅地观看着视频画面的同时，背后其实包含了大量的技术难题。本次分享将从手机摄像头数据采集开始，把视频编码、数据传输、视频解码、画面显示整条链路中的技术难点和优化方法进行详细讲解。另外，还会对音视频开发者最关心的一些问题如直播延时、画面清晰度、手机端资源消耗等展开讨论。移动端的音视频直播，点播，之所以能大量爆发，跟下面几点因素分不开。第一，音视频直播，点播的需求一直大量存在，包括各种行业应用，比如，视频门户、娱乐直播、游戏直播，在线教育、远程医疗，远程监控，企业协作，社交应用等。那么以前为什么没有全面爆发，是因为硬件条件不满足。首先，网络的带宽有限，现在网速不断提升，很多都是光纤到小区，有线网络的上下行带宽已经达到要求。移动网络4G接入速度也挺快，满足了基本的视频直播带宽要求。而且网络资费也比较低，变得大众可接受。其次，智能硬件设备的大量普及，特别是大屏智能手机，平板，基本是人手一台。而且这些设备的性能也越来越强劲，4核CPU是常态，现在都是8核了，2GB内存是小意思，现在都配4GB了。硬件性能的提升解决了视频编解码的性能瓶颈，可以拿手机，平板作为PC机器使用。因此，以上几点满足视频直播的性能，带宽这些基本要求。网络费用便宜达到了大众消费级别，两者一碰撞就把以前压制的视频直播，点播需求都爆发出来了，特别是移动直播，现在的理念是随时随地玩直播。一个完整的视频直播，点播过程主要包括以下几个方面。对于直播来说，首先是音视频推流端会把数据流推送到流媒体服务器，然后在通过CDN平台进行分发，最后观众用各种播放器从CDN拉流观看。对于点播过程来说，首先内容提供商要把视频文件转码，转成符合网络传输的格式，然后把视频文件部署到点播服务器，之后会通过CDN平台进行分发，主要是支持超大并发量的访问，最后观众用各个平台的播放器从CDN拉流观看。在点播过程中有两个额外的服务，一个是转码服务，用来转码各种音视频文件。另外一个是存储服务，用来保存大量的音视频文件。不管是直播或点播服务，都会有一个视频云管理服务器，用来管理直播频道，点播文件，以及后台管理web页面。对外提供http接口，供产品的应用服务器调用。管理服务器协调推流客户端，流媒体服务器，播放器之间保证作为一个整体运行。对于移动端来说，主要涉及到推流端和播放器这两部分。其中推流端包括了音频，视频的采集，预处理，编码，打包，发送这几个模块。而播放器包括了码流接收，解码，后处理，显示这几个模块。分别讲述一下各个模块的功能和特点，音频是从麦克风采集，音视频从摄像头抓取图像，也可以抓取屏幕图片，比如游戏直播。当有混音需求时，也可以采集声卡的音频数据，然后跟麦克风的声音进行混音。对于采集的音频一般先要进行降噪处理，特别是户外环境下，噪声会比较明显。如果涉及到互动直播，有双向通话的情况，还需要对音频进行回声抑制处理，防止出现回声效果。对于采集的图像可以进行一些特效滤镜处理，比如黑白，黄昏，提亮，美颜等，这些处理非常耗费性能，一般都是需要用OpenGL ES来实现。也可以进行图像叠加，比如给主播加个帽子，或者为了保护版权，加个水印图片。所有的这些操作都有实时性要求，因为后端要编码成视频流。因此，对于一般的图像处理算法，当用到视频场景下，有时很难达到性能要求，比如要处理25帧每秒，特别是移动设备，这个性能就更加难达到要求，都是需要进行一些定制优化。目前主流的视频编码标准就是H.264，编码质量，性能，码率，各方面都比较好，而且使用最广泛，现在互联网最常用的就是H.264视频。对于VP8视频编码，这是Google推出的标准，是WebRTC实时视频通话主要编码标准，但是目前在网络直播，点播方面不常用。而音频的AAC标准，是用的最多的音频编码，非常流行，编码的音质也好。而speex音频标准，是一套主要针对语音的开源免费，无专利保护的音频压缩格式。也很适合网络应用，在网络应用上有着自己独特的优势，但是还不够流行，没有普遍使用。对于音视频直播来说，上行推流主要采用rtmp协议，用这个协议的延时小，但是可能会有端口上的限制。如果用HLS推流，那些延时会比较大，走http协议，没有网络端口的限制。对于下行的播放来说，主要有http-flv，HLS，RTMP这几种拉流方式。其中http-flv，HLS这两种方式会在流媒体服务器上进行重新封装，以及协议转换。对于点播服务来说，播放用的主流方式是http-flv，http-mp4，hls这几种，全部走http协议，比较适合网络传输。音视频流通过CDN平台分发之后，能支持超大量的访问，千万级别都没有问题的。对于播放器来说，就是一个推流的逆向过程，先接受媒体流，然后解析协议，解封装，解码音视频数据，后处理，最后显示画面，声音。如果用到后处理，比如图像可以色彩增强，音频可以音量增强。显示的时候也可以做一些处理，比如全屏的时候图像拉伸，或者填黑边，或者裁剪，也可加上走马灯，进行版权保护。主要的优化方向，第一，要选择一个通用性好，性能良好，复杂度相对较低的编码器，现在主流的就是H.264编码器，开源的主要是x264和openh264，其中openh264是思科开源项目，针对实时视频通话场景做了优化。比如选择用H.265编码器，但是编解码复杂度太高，特别是在移动平台性能达不到要求，另外，对于低分辨率的视频直播，节省不了码率，图像质量也没有明显的提高。第二，在选定一个编码标准之后，就要看是否采用硬件编码方式，如果采用软件编码，那么会比较耗费cpu资源，表现出来就是设备发烫，耗电快，但是设备兼容性好，几乎可以在任何设备上运行。如果采用硬件编码方式，那么编码性能好，完全可以支持1080p图像全高清的实时编码，而且也省电，但是设备的适配性比较差，特别Android设备的硬件编码模式支持的比较差。ios设备支持的适配性比较好，但是，没有开放更底层的编码接口，难做到按帧获取码流，进行实时直播。另外用硬件编码方式，也比较难做动态码率控制。针对网络直播和点播场景，在编码阶段要尽量做到码率波动的平滑，这个需要优化码率控制算法。第三，对于Gop的大小也要根据应用场景做适当的调整，如果关键帧之间的间隔小，那么码率会出现频繁的尖峰，发送数据的时候，会造成瞬间的拥塞。第四，可以通过设置buffer来解决码率波动问题，比如在推流端增加一个发送缓冲区，按照固定的码率发送数据，而不是根据每帧数据来发送。同样在播放器也可以设置一个接收buffer，解决网络波动对播放造成的频繁卡顿。但是这个设置过大的buffer会增加延时，不适合直播应用，比较适合点播应用。对于直播场景，要求端到端的延时尽量小，播放端能快速启动，看到画面。对于rtmp直播还要解决累计延时，可以采用在播放器主动清空buffer的方法。这样低延时，小缓冲，主动清空缓冲的方案，抗网络波动比较差，一旦网络不好，会造成不停的音视频卡顿，但比较适合直播场景。对于点播场景，可以适当的增大buffer，进行码流的预加载，在网络好的时候，尽量多加载一些视频数据，这样抗网络的波动就好，基本不会出现卡顿，也没有延时要求，因此这个方案比较适合点播场景。第五，不管是直播还是点播服务，都存在一个端到端的数据传输链路问题。在推流端先要连接到接流服务器，这时就要选择合适的节点，一种是根据客户端的DNS域名来选择就近的节点，当DNS配置有误的时候，可能会存在调度不准的问题。另外一种是根据客户端的出口IP来选择节点，这种调度方式会比较准确一些。同样对于播放器端也是采用类似的方式来选择流媒体服务器集群的边缘节点。第六，在整个直播或点播过程中，最好有实时统计数据，包括网络类型，机器信息，实时网络状况，帧率，码率，分别率等。这样可以分析遇到的各种问题，特别是对于直播场景，当网络波动，出现卡顿时，可以为动态调整qos提供依据。第七，对于直播场景，采用qos策略，动态调整编码参数，包括帧率，码率，分辨率，缓冲区。当直播出现卡顿，采用快降慢升的策略，当网络波动比较厉害，这样可以避免编码参数频繁的来回调整，造成恶性循环。当进行编码参数调整时，一般是根据分辨率把码率，帧率分成几个档次，然后在根据一定时间段内的统计数据，在这几组参加集会之间进行来回切换，确保音视频流畅的同时，尽量提高图像质量。总之，对于视频直播，点播来说，整个优化策略是在清晰流畅，模糊卡顿之间动态平衡。当有足够的带宽，强大的设备性能，那么视频流必然是清晰流畅的。但是，在目前现有的资源下，只能根据网络情况和设备能力，采取一个折中的策略，从推流端到服务器，再到播放器，要尽量保证整个链接的畅通。专心-专注-专业