今天解决了一个需求,通过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。
配置如下

继续阅读

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

本文链接地址: 使用ffmpeg-1.0内置RTMP协议实时解码H264视频流

之前在公司一个项目中一直使用 http://www.cnblogs.com/mcodec/articles/1780598.html 提供的H264 Android解码库
但是经常崩溃,最终定位到mc_dir_part函数中的

尝试了一晚上也没修复好这个问题,于是打算自己移植FFmpeg
mcodec 兄所做的工作是将H264解码的代码从ffmpeg中提取出来做了深度优化,而本人对FFmpeg?还不甚了解,无法做到提取,而且新版本相互依赖太重,于是将整个FFmpeg?移植过来使用。
在配置时关闭了所有特性,只开启了所需的H264解码库,arm汇编特性,其余全部关闭。
以下是我的配置代码继续阅读

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

本文链接地址: 使用Android NDK8 移植FFmpeg 0.11.1