久了没更新NDK,今天下载了r10d,惊讶的发现多了个native-codec这个sample。
应该就是API 16那个JAVA版MediaCodec的native版
限制就是 最低 api 21 就是Android 5.0
这限制基本上近期都没戏了,先去刷个5.0的系统再来测试。

=============2015年2月10日,测试结果来了======================


继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: 来晚了的 NativeCodec

最近在做全志A20的Android系统开发,经常需要调试script.fex文件中的参数。
会经常用到sunxi-tools中的几个工具

后来需要在windows下工作 切换环境很麻烦 所以用cygwin编译了sunxi-tools 并写了几个脚本文件,方便多了

步骤:继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: windows下全志 A20 Android script.fex 调试工具

官方源码:http://code.google.com/p/libyuv/
简介:

YUV层的缩放,色彩空间转换(nv21/nv12 to i420,i420 to rgb565/rgb888),针对ARMv7使用NEON指令集优化.实际项目使用中测试,缩放/转换性能秒杀ffmpeg的libswscale
按官方的编译方法太麻烦,需要装depot tools,ninja
这里直接用android make 方便的多.
继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: 使用 NDK 编译 libyuv

移动设备上的H.264实时视频编码,需要考虑到cpu占用与带宽这2个限制因素,使用X264软编码,开启neon指令集优化,即使是在arm处理器下,依然可以通过优化配置达到满意的性能.
以下测试环境 一段352×288@15fps的视频,模拟摄像头采集到的数据。ipod touch4 和昨天编译出的X264:
Touch-future:~ root# ./x264 -o video_1.h264 video_1.y4m –profile baseline –preset ultrafast –fps 15

baseline
ultrafast
encoded 467 frames, 48.17 fps, 865.45 kb/s 3368054(压缩后的文件大小,单位字节)继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: Android,IOS平台上x264编码实时视频参数设置与优化

第一个问题:

这类错误,解决方法:继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: 使用C++进行Android NDK开发,引入FFmpeg头文件的注意事项

第一步,制作独立交叉编译链,我使用ndkr9制作的, 使用API 9平台,gcc4.6
进入ndk目录,执行

第二部,修改x264的configure继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: 交叉编译支持多线程的Android版X264库

之前有个基于java和jni共同实现的版本,juv需要授权,语音数据在java层和jni层不停互转。

这个版本,完全在jni层实现,java只处理方法调用和事件回调。

OpenSL ES,从API 9开始支持的技术,通过这个标准,Android已经完全可以在native层采集和播放音频。继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: Android基于OpenSL ES,Speex,RTMP的Voip客户端实现

今天解决了一个需求,通过TCP拉取数据包后按一个私有协议解包封包后得到标准H264.
按以前的方法,在已知高宽的情况下手动注册AVCodecContext,填充AVFrame,解码。。。。 非常繁琐,如果连高宽都不确定的话 :< 但仔细想想这种没有封入容器的裸数据如果是一个文件,据依然可以通过file协议使用avformat_open_input打开并自动解析等。 那么这种场景完全可以用管道来代替,果然ffmpeg是支持pipe的。 我的试验环境是Android,ffmpeg版本1.0.6, NDK8d 流程如下 创建有名管道继续阅读

原创文章,转载请注明: 转载自贝壳博客

本文链接地址: 使用FFmpeg解码私有传输协议标准H264流