在使用flash cs/builder开发rtmp视频应用时,我们时常会在nc.connect的时候再传递一个对象作为连接信息发送给服务端。用于验证,确认连接用户,获取用户信息等等操作。
当我们使用ffmpeg来开发android,ios,pc版的rtmp应用时,已经为我们提供了非常方便的传参来实现。
先来看源代码:定位到libavformat/rtmpproto.c文件继续阅读

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

本文链接地址: 使用FFmpeg连接rtmp时发送自定义AMF DATA

第一个问题:

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

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

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

今天编译了raspberry pi 的一个例子hello_video
可以解码.h264文件输出到显示器
使用ffmpeg生成这种无容器的 raw H.264格式

就是将mp4这类 length prefixed mode 转为 start code prefixed mode

另外,pi的硬解码性能确实不错,播放1080P的视频非常流畅,GPU加速,几乎不占CPU

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

本文链接地址: FFmpeg 生成.h264文件

上篇使用pipe播放流后,观看的同时,如需保存成文件,使用ffmpeg也是很方便的.
既然已经是标准H264了,那就不需要再编码,直接copy流再muxer

代码原型请看这个这个回复,不过他的代码中,视频输出流的AVCodecContext

缺少了extradata,造成生成的MP4文件avcC没有SPS PPS信息而无法播放

添加如下代码

另外不需要两次打开输入流,完全是可以在播放开始后任意时间来控制开始保存文件.
使用mp4封装,在Android IOS上均可调用系统自带播放器播放

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

本文链接地址: FFmpeg取回标准H.264流后播放的同时存为MP4文件

今天解决了一个需求,通过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视频流