谈谈关于Android视频编码的那些坑

x264根本上被认为是当今市情上最快的商用视频编码器，并且根本上所有h264的特点都支撑，经由过程合理设备各类参数照样可以或许获得较好的紧缩率和编码速度的，限于篇幅，这里不再阐述h264的参数设备，有兴趣可以看下这里和这里对x264编码参数的调优。

openh264 则是由思科开源的别的一个h264编码器，项目在2013年开源，比较起x264来说略显年青，不过因为思科付出满了h264的年度专利费，所以对于外部用户来说，相当于可以直接免费应用了，别的，firefox直接内置了openh264，作为其在webRTC中的视频的编解码器应用。

但比较起x264，openh264在h264高等特点的支撑比较差：

Profile只支撑到baseline, level 5.2
多线程编码只支撑slice based，不支撑frame based的多线程编码

大年夜编码效力上来看，openh264的速度也并不会比x264快，不过其最大年夜的好处，照样可以或许直接免费应用吧。

大年夜膳绫擎的分析来看，硬编的好处重要在于速度快，并且体系自带不须要惹人外部的看维然则特点支撑有限，并且硬编的紧缩率一般偏低，而对于软编率攀来说，固然速度较慢，然则紧缩率比较高，并且支撑的H264特点也会比硬编码多很多，相对来说比较可控。就可用性而言，在4.4+的体系上，MediaCodec的可用性是可以或许根本包管的，然则不合等级的机械的编码器才能会有不少差别，建议可以根据机械的设备，选择不合的编码器设备。

YUV帧的预处理

根据最开端给出的流程，在送入编码器之前，我们须要先对摄像头输出的YUV帧进行一些前置处理

// XXX 
if (h264type.eProfile != OMX_VIDEO_AVCProfileBaseline) { 
    ALOGW("Use baseline profile instead of %d for AVC recording", 
            h264type.eProfile); 
    h264type.eProfile = OMX_VIDEO_AVCProfileBaseline; 
}

1.缩放

如不雅设置了camera的预览大年夜小为1080p的情况下，在>

mScaleYuvCtxPtr = sws_getContext(

srcWidth,

srcHeight,

AV_PIX_FMT_NV21,

dstWidth,

dstHeight,

AV_PIX_FMT_NV21,

SWS_FAST_BILINEAR, NULL, NULL, NULL);

sws_scale(mScaleYuvCtxPtr,

(const uint8_t* const *) srcAvPicture->data,

srcAvPicture->linesize, 0, srcHeight,

dstAvPicture->data, dstAvPicture->linesize);

在nexus 6p上，直接应用ffmpeg来进行缩放的时光根本上都须要 40ms+ ，对于我们须要录制30fps的来说，每帧处理时光最多就30ms阁下，如不雅光是缩放就消费了如斯多的时光，根本上录制出来的视频只能在15fps高低了。

很明显，直接应用ffmpeg进行缩放是在是太慢了，不得不说swsscale的确就是ffmpeg琅绫擎的渣渣，在比较了几种业界常用的算之后，我们最后推敲实现应用这种快速缩放的算法：

谈谈关于Android视频编码的那些坑

我们选择一种叫做的局部均值算法，前后两行四个邻近点算出最终图片的四个像素点，对于源图片的每行像素，我们可以应用Neon直接实现，以缩放Y分量为例：

const uint8* src_next = src_ptr + src_stride; 	
			 3/6   首页 上一页 1 2 3 4 5 6 下一页 尾页	
			

　　推荐阅读
　　开发一个Linux调试器（六）：源码级逐步执行
            
            我们计算编写这些函数异常简单的版本，但真正的调试器有 thread plan  的概念，它封装了所有的单步信息。例如，调试器可能有一些复杂的逻辑去决定断点的地位，然后有一些回调函数用于断定>>>详细阅读


本文标题：谈谈关于Android视频编码的那些坑
地址：http://www.17bianji.com/lsqh/36974.html
 1/2    1