一段海康SDK解码回调后缩放并用openh264编码的代码

最近有个海康DVR转rtmp的项目,准备用openh264试试,相比x264性能非常强,但相同码率下画质不如x264

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

本文链接地址: 一段海康SDK解码回调后缩放并用openh264编码的代码

如何在windows中编译ffmpeg 2.6.1 以及 NVENC硬编码的尝试

目前我使用的编译链
gcc: TDM-GCC-4.9.2
msys: 从MinGW中拷贝而来

./configure –target-os=win32 –arch=i686

windows下编译ffmpeg 2.6.1
windows下编译ffmpeg 2.6.1

开启NVENC硬件编码H.264
-enable-encoder=nvenc –enable-nvenc –enable-nonfree

ffmpeg 支持 nvenc 硬编码 H264
ffmpeg 支持 nvenc 硬编码 H264

继续阅读“如何在windows中编译ffmpeg 2.6.1 以及 NVENC硬编码的尝试”

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

本文链接地址: 如何在windows中编译ffmpeg 2.6.1 以及 NVENC硬编码的尝试

NodeMedia Dev Server

NodeMedia Dev Server是基于nginx-rtmp-module编译的windows版RTMP服务端完整实例。无需配置,一键运行,是您快速开发,测试,验证RTMP流的好帮手。
可以用来开发:视频直播间,音视频聊天,游戏直播,远程视频监控等。
包含以下实用工具:

  1. RTMP流媒体服务端
  2. Flash Rtmp流播放器
  3. Flash HLS直播流播放器
  4. Flash Rtmp摄像头视频发布器
  5. Flash 视频聊天Demo
  6. 批处理版的视频流循环发布器。

前往下载:http://www.nodemedia.cn/zh/nodemedia-dev-server

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

本文链接地址: NodeMedia Dev Server

Android RTMP Live Encoder SDK

实时的摄像头采集,实时编码,实时发布到流媒体服务器,进行视频直播。视频采用H.264,音频采用AAC,可根据需求发布480×360,320×240,240×180分辨率的视频。可控帧率,码率。320×240分辨率@10fps 中等质量,码率为160kbps左右,非恒定。cpu占用30%左右。
客户端使用Flash播放,跨平台兼容性好。
也可配合使用Android iOS SDK开发手机客户端。

  • 音频编码器:AAC,nellymoser,speex
  • 视频解码器: H.264
  • 协议:RTMP,RTMPT
  • ARMV7-A Neon加速
  • 极速精简内核,so库仅2.0M

前往下载:http://www.nodemedia.cn/zh/client/NodeMediaClient-Android/

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

本文链接地址: Android RTMP Live Encoder SDK

Android RTMP Live Player SDK

RTMP协议的实时视频播放客户端开发库,jni开发,java接口,可配合Adobe Flash Media Live Encoder 3.2或Android iOS直播发布端SDK进行实时视频直播。

  • 音频解码器:AAC,mp3,nellymoser,speex
  • 视频解码器: H.264,flv
  • 协议:RTMP,RTMPT
  • ARMV7-A Neon加速
  • 极速精简内核,so库仅1.4M

前往下载:http://www.nodemedia.cn/zh/client/NodeMediaClient-Android/

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

本文链接地址: Android RTMP Live Player SDK

FFmpeg 2.6 发布

非常多的改进,比较感兴趣的是正式支持openh264作为编码器了。
openh264使用宽松的BSD许可协议,由cisco主导发布。

思科并不是第一个去创建H.264的开源实现的。GNU的libavcodec库已经包括了解码器和编码器,后者基于x264。但是思科提供的开源实现是有法律支持的 – 而这正是其它的开源实现所缺乏的。这使得思科的解码器对象Mozilla这样的公司来说就非常有用,这可以使得它们无需担心法律问题。

另外还支持了Nvidia nvenc的硬件编码器,这无疑加强了了作为云端流媒体转码的优势!
后期做个x264与openh264的性能测试。

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

本文链接地址: FFmpeg 2.6 发布

Android 4.0以上系统硬件解码RTMP流的一种方式

关于Android5.0开放的Native-codec测试一文中有提到4.0通过OpenMAX AL接口实现硬解码。可以先从分析native-media这个sample开始,可以在ndk目录中找到。

  1. 首先调用Java_com_example_nativemedia_NativeMedia_createEngine ?创建引擎和output mix 对象。
  2. Java_com_example_nativemedia_NativeMedia_setSurface 将java层的Surface对象转为NativeWindow对象用于视频显示
  3. Java_com_example_nativemedia_NativeMedia_createStreamingMediaPlayer ?初始化data source、?audio sink、image video sink、media player等对象 ,注册AndroidBufferQueueCallback?StreamChangeCallback两个回调,调用enqueueInitialBuffers预填充部分初始数据。
  4. enqueueInitialBuffers中通过读取ts文件获取足够量的buffer用于初始化
  5. AndroidBufferQueueCallback 的注释:?register the callback from which OpenMAX AL can retrieve the data to play,程序回调这里说明可以读buffer开始播放了

继续阅读“Android 4.0以上系统硬件解码RTMP流的一种方式”

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

本文链接地址: Android 4.0以上系统硬件解码RTMP流的一种方式

开源一个基于js的RTMP服务端

其实是2个,一个基于fibjs,一个基于nodejs
两个版本大部分是一样的,只是在数据处理方面有差异。

fibjs版本:https://github.com/illuspas/NodeMediaServer
fibjs没有回调一说,同步的流程写起来相当舒服。

nodejs版:https://github.com/illuspas/Node-Media-Server
nodejs的数据是on(‘data’)回调回来的,解析rtmp包很费劲,需要根据包头一步一步分析出需要的包大小。为此写了个QueueBuffer类,请求的数据大小足够即返回,不够就回压再等待数据下次继续解析。

目前只支持了H264+AAC,支持多路发布和播放。
fibjs版目前在大并发的时候会阻塞发布端,写得有点问题,空了再改改。
没有缓冲关键帧,播放的启动时间可能会等下一个关键帧来了才开始

此项目仅为空闲时写着玩的,参照了很多别人的代码,并不会长期维护。如果你感兴趣,欢迎fork。

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

本文链接地址: 开源一个基于js的RTMP服务端

来晚了的 NativeCodec

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

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


继续阅读“来晚了的 NativeCodec”

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

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

转一段 Xcode6 下编译x264的脚本

下载最新x264源码 ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2
下载gas-preprocessor https://github.com/libav/gas-preprocessor 并copy到 /usr/local/bin/gas-preprocessor.pl
继续阅读“转一段 Xcode6 下编译x264的脚本”

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

本文链接地址: 转一段 Xcode6 下编译x264的脚本