最近在研究NMSv3 接入WebRTC协议,以实现浏览器跨平台无插件高清推流,服务端转http-flv,rtmp等。首选视频编码当然是H264了,这样服务端只需做音频实时转码OPUS->AAC即可。

在解析RTP包内H264负载时遇到各种坑,这里记录一下。

环境:

  • OS:MacOS 10.14.6
  • Chrome : 80.0.3987.106

一、查看默认编码器参数,浏览器访问 chrome://gpu/

Video Acceleration Information

Decode h264 baseline16×16 to 4096×2160 pixels
Decode h264 extended16×16 to 4096×2160 pixels
Decode h264 main16×16 to 4096×2160 pixels
Decode h264 high16×16 to 4096×2160 pixels
Encode h264 baseline0x0 to 4096×2160 pixels, and/or 30.000 fps
Encode h264 main0x0 to 4096×2160 pixels, and/or 30.000 fps
Encode h264 high0x0 to 4096×2160 pixels, and/or 30.000 fps

此刻,RTP包的负载,I包和P包使用FU-A,SPS、PPS采用STAP-A打包。

二、通过访问chrome://flags/ ,将Hardware-accelerated video encode 选项设置为Disable,关闭硬件编码,模拟无硬件加速的环境。

继续阅读

前期曾发布过一款windows平台RTMP推送摄像头画面的浏览器插件,近期对这款产品进行了升级,现已支持捕获桌面画面进行推流。

桌面推流当然首选OBS,专业性毋庸置疑。本人开发的这款产品定位为简单业务需求,只需引导客户安装5M左右大小的插件程序,无需任何配置,即可在web网页中进行摄像头或桌面画面的捕获推流。

在本次更新中,加入了H.265编码器的支持,视频码率更低。同时,在SSE指令集加速的软编码基础上,增加了AMD/NVIDIA/INTEL独显核显硬件加速编码,CPU消耗更低。

本插件同时也加入了直播播放器的支持,可以播放rtmp,rtsp,http协议的直播流,并支持硬件加速解码,首屏秒开与延迟消除技术。继续阅读

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

本文链接地址: Windows平台浏览器内捕获桌面画面并RTMP推流

最近在研究用Emscripten开发JavaScript的直播播放器,使用ffmpeg内置的h264解码速度还是可以接受的,本想使用openh264的解码进行比较,但发现非常慢,无法达到640×480@30帧的解码速度。

本来以前也有过用openh264的项目,直接使用libopenh264进行解码速度还是很快的。但编译进ffmpeg里使用就特别慢,于是-g重新编译NodePlayer.js并开始Chrome Performance录制。
继续阅读

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

本文链接地址: ffmpeg.js使用libopenh264解码性能低的原因

此版本发布比较关注的Intel Quick Sync Video编解码器正式推出了,之前2.6的时候在master分支测试过。
相比较NVENC,之前也有测试过,就目前NV的显卡驱动,GeForce系列只支持同时两路编码会话,实在是吝啬,空有强大性能。同期测试过QSV,就没有这方面限制。
在做服务端流媒体实时转码的硬编码方面,QSV目前比较成熟。

————————————————–
下载博主编译的ffmpeg.exe:https://github.com/illuspas/ffmpeg-hw-win32

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

本文链接地址: FFmpeg 2.7发布,Intel Quick Sync Video编解码器已正式推出

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

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

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

阅读ffmpeg串流的手册FFmpeg Streaming Guide
当进行点对点串流
如果视频编码为H.264时,payload type 为 96

此时会自动输出一段SDP的代码,这时候如果直接播放继续阅读

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

本文链接地址: 使用ffmpeg进行rtp串流h.264时关于sdp的一些分析

移动设备上的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编码实时视频参数设置与优化

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

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

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

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

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

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

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

添加如下代码

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

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

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