第一步,制作独立交叉编译链,我使用ndkr9制作的, 使用API 9平台,gcc4.6
进入ndk目录,执行
1 |
$ ./build/tools/make-standalone-toolchain.sh --platform=android-9 --install-dir=/home/aliang/arm-linux-androideabi |
第二部,修改x264的configure 继续阅读“交叉编译支持多线程的Android版X264库”
第一步,制作独立交叉编译链,我使用ndkr9制作的, 使用API 9平台,gcc4.6
进入ndk目录,执行
1 |
$ ./build/tools/make-standalone-toolchain.sh --platform=android-9 --install-dir=/home/aliang/arm-linux-androideabi |
第二部,修改x264的configure 继续阅读“交叉编译支持多线程的Android版X264库”
今天编译了raspberry pi 的一个例子hello_video
可以解码.h264文件输出到显示器
使用ffmpeg生成这种无容器的 raw H.264格式
1 |
ffmpeg -i INPUT.mp4 -codec copy -bsf:v h264_mp4toannexb OUTPUT.h264 |
就是将mp4这类 length prefixed mode 转为 start code prefixed mode
另外,pi的硬解码性能确实不错,播放1080P的视频非常流畅,GPU加速,几乎不占CPU
之前有个基于java和jni共同实现的版本,juv需要授权,语音数据在java层和jni层不停互转。
这个版本,完全在jni层实现,java只处理方法调用和事件回调。
OpenSL ES,从API 9开始支持的技术,通过这个标准,Android已经完全可以在native层采集和播放音频。 继续阅读“Android基于OpenSL ES,Speex,RTMP的Voip客户端实现”
要在 Microsoft Win32??平台上编译Nginx你需要:
编译步骤
在开始之前,你需要将Perl,Mercurial,MSYS bin目录加入PATH环境变量,也就是打开cmd,输入perl,hg,bash不会提示找不到命令.运行vcvarsall.bat或者叫Visual Studio命令提示(2010). 继续阅读“编译windows版nginx-rtmp-module”
上篇使用pipe播放流后,观看的同时,如需保存成文件,使用ffmpeg也是很方便的.
既然已经是标准H264了,那就不需要再编码,直接copy流再muxer
1 2 3 4 5 |
_______ ______________ ________ | | | | | | | input | demuxer | encoded data | muxer | output | | file | ---------> | packets | -------> | file | |_______| |______________| |________| |
代码原型请看这个这个回复,不过他的代码中,视频输出流的AVCodecContext
1 2 |
AVCodecContext *c; c = o_video_stream->codec; |
缺少了extradata,造成生成的MP4文件avcC没有SPS PPS信息而无法播放
添加如下代码
1 2 |
c->extradata = i_video_stream->codec->extradata; c->extradata_size = i_video_stream->codec->extradata_size; |
另外不需要两次打开输入流,完全是可以在播放开始后任意时间来控制开始保存文件.
使用mp4封装,在Android IOS上均可调用系统自带播放器播放
今天解决了一个需求,通过TCP拉取数据包后按一个私有协议解包封包后得到标准H264.
按以前的方法,在已知高宽的情况下手动注册AVCodecContext,填充AVFrame,解码。。。。 非常繁琐,如果连高宽都不确定的话 :<
但仔细想想这种没有封入容器的裸数据如果是一个文件,据依然可以通过file协议使用avformat_open_input打开并自动解析等。
那么这种场景完全可以用管道来代替,果然ffmpeg是支持pipe的。
我的试验环境是Android,ffmpeg版本1.0.6, NDK8d
流程如下
创建有名管道 继续阅读“使用FFmpeg解码私有传输协议标准H264流”
前面说道FFmpeg在整个视频解码的过程中存在很大一个瓶颈,就是做色彩空间转换时。看源代码目录结构便知:libavcodecarm下有大量音视频编解码的汇编代码。而libswscale下却没有。
事实上也确实如此,在使用了PINK NOISE的YUV2RGB后性能提升非常明显。(目前项目需要,只移植了YUV420toRGB565,在移动设备上实时视频也足够了。
如需软解码回放高清画质,PINK NOISE的库中,yuv420 422,444 to 565 888 8888 都有。
这是我移植的补丁,是在FFmpeg 1.0版本基础上导出的。 继续阅读“适用于FFmpeg 1.0的ARM汇编优化yuv2rgb补丁”
正在做一个基于RTMP+H264的手机端实时视频流项目。
按以前的方案需要分别用librtmp/JUV和opencore的H264解码库实现。
在进一步了解FFmpeg后,决定全部使用ffmpeg来实现。
当然,在手机客户端上,多余的解码库是不需要的。因此需要对ffmpeg精简配置,最终jni代码编译链接libavcodec.a?libavformat.a ?libavutil.a?libswscale.a 后的so大小控制在1.2M左右,打包到apk后压缩到456k。
配置如下
离写上篇快4个月了,近期整理了下,写了个Demo,过段时间补上说明,先看代码吧。
还没有搭好服务端,可以看看这篇。
2012/10/8申请的key,30天过期了自己再去申请。
操作如图 😀
继续阅读“Android通过JUV+Red5+Speex实现网络语音聊天(二)”
IOS平台上使用FFmpeg解码H264的例子
https://github.com/lajos/iFrameExtractor
Xcode4.5 安装路径变了的缘故吧,修改了下build_armv6 build_armv7 build_i386 三个编译脚本
继续阅读“使用Xcode4.5 编译运行 iFrameExtractor”