javacv开发详解之1:调用本机摄像头视频
javaCV开发详解之2:推流器实现,推本地摄像头视频到流媒体服务器以及摄像头录制视频功能实现(基于javaCV-FFMPEG、javaCV-openCV)
javaCV开发详解之3:收流器实现,录制流媒体服务器的rtsp/rtmp视频文件(基于javaCV-FFMPEG)
javaCV开发详解之4:转流器实现(也可作为本地收流器、推流器,新增添加图片及文字水印,视频图像帧保存),实现rtsp/rtmp/本地文件转发到rtmp流媒体服务器(基于javaCV-FFMPEG)
javaCV开发详解之5:录制音频(录制麦克风)到本地文件/流媒体服务器(基于javax.sound、javaCV-FFMPEG)
javaCV开发详解之6:本地音频(话筒设备)和视频(摄像头)抓取、混合并推送(录制)到服务器(本地)
javaCV开发详解之7:让音频转换更加简单,实现通用音频编码格式转换、重采样等音频参数的转换功能(以pcm16le编码的wav转mp3为例)
javaCV开发详解之8:转封装在rtsp转rtmp流中的应用(无须转码,更低的资源消耗,更好的性能,更低延迟)
javaCV开发详解之9:基于gdigrab的windows屏幕画面抓取/采集(基于javacv的屏幕截屏、录屏功能)
javaCV开发详解之10:基于dshow调用windows摄像头视频和音频,想要获取屏幕画面首选gdigrab
javaCV开发详解补充篇:基于avfoundation的苹果Mac和ios获取屏幕画面及录屏/截屏以及摄像头画面和音频采样获取实现
音视频编解码问题:javaCV如何快速进行音频预处理和解复用编解码(基于javaCV-FFMPEG)
音视频编解码问题:16/24/32位位音频byte[]转换为小端序short[],int[],以byte[]转short[]为例
实现给图片增加图片水印或者文字水印(也支持视频图像帧添加水印)
java原生实现屏幕设备遍历和屏幕采集(捕获)等功能
流媒体直播实时视频延迟时间排查和剖析
javacpp-ffmpeg系列:
javacpp-FFmpeg系列之1:视频拉流解码成YUVJ420P,并保存为jpg图片
javacpp-FFmpeg系列之2:通用拉流解码器,支持视频拉流解码并转换为YUV、BGR24或RGB24等图像像素数据
javacpp-FFmpeg系列之3: 图像数据转换(BGR与BufferdImage互转,RGB与BufferdImage互转)
javacpp-FFmpeg系列补充:FFmpeg解决avformat_find_stream_info检索时间过长问题
javacpp-opencv系列:
一、 javaCV图像处理之1:实时视频添加文字水印并截取视频图像保存成图片,实现文字水印的字体、位置、大小、粗度、翻转、平滑等操作
二、 javaCV图像处理之2:实时视频添加图片水印,实现不同大小图片叠加,图像透明度控制
三、java cv图像处理3:使用opencv原生方法遍历摄像头设备及调用(方便多摄像头遍历及调用,相比javacv更快的摄像头读取速度和效率,方便读取后的图像处理)
四、 javacv图像处理系列:国内车辆牌照检测识别系统(万份测试准确率99.7%以上)
本章作为延迟补充篇,我们在搭建直播平台等流媒体服务平台的时候总会遇到延迟的问题,很多人表示束手无策,不知从何下手去优化延迟。本章就从流媒体平台整体到协议细节来剖析和解决直播实时视频的延迟问题。
(1)默认缓存延迟
目前已知VLC、videojs等播放器包含不定的缓存
解决办法: (1)VLC可以在配置中设置低延迟 (2)videojs暂时无法自定义设置缓存大小和时间
(2)播放器查找音频导致延迟
目前已知VLC或者ffplay等播放器在播放rtmp或者flv的视频时,默认行为是分析5秒(rtmp)到90秒(以.flv做为后缀的url)数据查找媒体中是否包含音频。 在无音频的流中,这一播放器行为会造成起播和播放的视频时间延迟。
解决办法: (1)ffplay可以加入参数”-analyzeduration 1”来实现秒开。 (2)vlc在配置中设置低延迟
例如,GOP关键帧间隔设为50,帧率时25,那么就可能造成约2秒的延时;以此类推。
如果播放时间点与上一关键桢相差1秒,则会造成1秒的延时
只拿nginx和srs来讲,这两个默认都是有缓存时间的,但是可以通过设置来达到减少或零缓存。
(1)转流需要拉流和推流两个操作,必然带来双向的网络延迟和缓存延迟。 (2)转码是计算密集型,耗时跟cpu性能有关,如果开启硬编码,则跟gpu性能有关。
使用ffmpeg转码时,禁用B帧。
(1)H264编码中的B帧解码需要I帧和临近的P帧才能解码,而且B帧不是顺序的,可能会出现B帧在很多个P帧后面,这时就需要缓存很多帧才能开始解码B帧,还有就是B帧的播放时间可能在这些P帧之前等等情况都会导致编解码延迟。 (2)B帧在编码时也需要缓存很多帧后才能开始编码,需要后面来了P帧才能开始编码的情况。
综上,目前实时流首帧打开时间简单的计算公式就是: MS+G+P+(SA)+C+N+(F)+(B)
MS表示流媒体服务缓存时间,G表示gop时间间隔,P表示播放时间与上一关键桢时间差,SA表示可能的音频查找时间,C表示播放器默认缓存时间,N表示网络延迟,F表示转流或转码导致延迟,B表示B帧导致的延迟。
目前有很多解决办法来解决这些问题,比如已知可以通过cdn分发降低网络延迟,通过播放器降低缓存时间,通过合理的GOP设置和首帧返回关键帧等方式来优化延迟,尽量少的B帧可以缓解编解码延迟等等。