文件名称:H264Android_CPP
介绍说明--下载内容来自于网络,使用问题请自行百度
H264解码器源码,移植ffmpeg中的H264解码部分到Android,深度删减优化,在模拟器(320x480)中验证通过。
程序的采用jni架构。界面部分,文件读取,视频显示都是用java做的,底层的视频解码用C来做满足速度的要求。
在这个版本中,从H264码流中分割出Nal是在java层做的,这样在java层直接调用解码时就知道是否有显示视频,缺点的就是耦合度/封装性差一点。
如果采用在底层做Nal分割的方法,可以封装得好看一些,但是每次送的数据有限制,如果送的数据太多,底层可能会一次解码出好几帧视频,但是通知到界面层只能显示一帧,造成丢帧的现象。 如果每次送的数据较少,就会有很多次底层调用没有进行实质解码,很小气的做法,比如有一压缩数据帧需要600字节,如果一次送100个字节给解码器,那么要送6次才会进行实质解码,因为每个数据帧有大有小,所以只能取极小值才不会导致丢帧。
不过所有的编码解码都是各种因素平衡折中的结果,具体用什么方法具体分析。
如果程序崩溃退出,优先考虑:
1)是否是baseline
2)byte [] NalBuf = new byte[40980] 缓冲区是否溢出。
如果有B帧,那肯定不是baseline。
-H264 Decoder C++ version decode source
程序的采用jni架构。界面部分,文件读取,视频显示都是用java做的,底层的视频解码用C来做满足速度的要求。
在这个版本中,从H264码流中分割出Nal是在java层做的,这样在java层直接调用解码时就知道是否有显示视频,缺点的就是耦合度/封装性差一点。
如果采用在底层做Nal分割的方法,可以封装得好看一些,但是每次送的数据有限制,如果送的数据太多,底层可能会一次解码出好几帧视频,但是通知到界面层只能显示一帧,造成丢帧的现象。 如果每次送的数据较少,就会有很多次底层调用没有进行实质解码,很小气的做法,比如有一压缩数据帧需要600字节,如果一次送100个字节给解码器,那么要送6次才会进行实质解码,因为每个数据帧有大有小,所以只能取极小值才不会导致丢帧。
不过所有的编码解码都是各种因素平衡折中的结果,具体用什么方法具体分析。
如果程序崩溃退出,优先考虑:
1)是否是baseline
2)byte [] NalBuf = new byte[40980] 缓冲区是否溢出。
如果有B帧,那肯定不是baseline。
-H264 Decoder C++ version decode source
(系统自动生成,下载前可以参看下载内容)
下载文件列表
本网站为编程资源及源代码搜集、介绍的搜索网站,版权归原作者所有! 粤ICP备11031372号
1999-2046 搜珍网 All Rights Reserved.