多线程访问FFmpegFrameGrabber.start方法阻塞问题

一、背景

项目集成网络摄像头实现直播功能需要用到ffmpeg处理rtmp视频流进行web端播放

通过网上资源找到大神的springboot项目实现了rtmp视频流转为http请求进行视频中转功能,其底层利用javacv的FFmpegFrameGrabber进行拉流、推流,进而实现了视频中转。

在此感谢大神提供的码云项目:EasyMedia: Springboot、netty实现的http-flv、websocket-flv直播点播,支持rtsp、h264、h265、rtmp等多种源,h5纯js播放(不依赖flash),不需要nginx等第三方拉流服务

二、问题

项目运行起来后各方面都正常,选取了有信号的视屏流地址均可以正常播放,但是将并发数量增加,并且有一部分存在无信号的情况时,拉流功能被阻塞。

通过排查定位发现,FFmpegFrameGrabber对象的start方法并不支持多线程访问,也就是说同时来了多个请求时它会内部形成阻塞队列进行等待。

这就导致,当大量请求同时进入时,它会按照阻塞的情况进行处理,而我们多线程的请求访问将失去意义。就算将超时时间设置的极短,5秒、3秒等,当十几二十个请求同时进入时,它也会按照等差数列进行堆叠,最后一个请求的等待时长将是:请求数量*平均每个的处理时长,假设有20个请求,平局每个请求设置超时未5秒,最后一个请求将会等待100秒。

然而请求时轮训访问的时间只会越来越久,于是开始寻求解决方案。

三、解决

该模式为典型的线程安全阻塞处理逻辑,所以我们去查找FFmpegFrameGrabber是否有非阻塞的方法或者可以实现非阻塞的逻辑即可。

查找API发现了同样入坑的友军,解决方案也是简单粗暴:

start ();改为startUnsafe();即可解决问题。

笔者将超时时间设置为10秒,从日志可以看到,多个请求同时进入时实现了异步操作,同时开始了拉流操作,进而解决了阻塞的问题。

四、总结

问题的解决其实很简单,但是从出现问题到定位问题历时很长。

首先是对这份开源代码的不太理解,每次阅读个大概就匆匆跳过,导致对整个流程总是一知半解,在浪费了大半天时间后才决定静下心来从头梳理下代码逻辑。其次是对问题的根源没有抓准,没有将详细的日志梳理分析,只是大概的定位到多线程执行阻塞。最后,在定位到问题对应的代码行后仍然无法进一步处理,工欲善其事必先利其器,笔者未实现熟悉相关API,只是定位到后才开始各种上网搜寻,如此一来反而又耽误了一些时间。

总之结果是好的,历时两天解决了这个问题,所以写个笔记记录一下供需要的孩子们参阅。

相关推荐
微露清风1 分钟前
系统性学习C++-第五讲-内存管理
java·c++·学习
计算机毕业设计木哥5 分钟前
计算机毕业设计选题推荐:基于SpringBoot和Vue的快递物流仓库管理系统【源码+文档+调试】
java·vue.js·spring boot·后端·课程设计
2351610 分钟前
【LeetCode】146. LRU 缓存
java·后端·算法·leetcode·链表·缓存·职场和发展
聪明的笨猪猪14 分钟前
Java Redis “运维”面试清单(含超通俗生活案例与深度理解)
java·经验分享·笔记·面试
FIavor.30 分钟前
怎么办这是Apifox里执行http://localhost:9002/goods/getByUserName?name=“张三“为什么我改了还是500?
java·网络·网络协议·http
编程饭碗32 分钟前
【Java集合】
java
岁岁岁平安32 分钟前
Java的双重检查锁机制(DCL)与懒加载的单例模式
java·单例模式·synchronized·
Jabes.yang39 分钟前
Java面试场景:从Spring Boot到Kubernetes的技术问答
java· 面试· spring boot· 微服务· kubernetes· 技术栈· redis
小咕聊编程1 小时前
【含文档+PPT+源码】基于SpringBoot+Gpt个人健康管理系统
java·gpt·tomcat·毕业设计·hibernate
阿无,1 小时前
Java设计模式之工厂模式
java·开发语言·设计模式