多线程访问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,只是定位到后才开始各种上网搜寻,如此一来反而又耽误了一些时间。

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

相关推荐
艾迪的技术之路几秒前
redisson使用lock导致死锁问题
java·后端·面试
今天背单词了吗98018 分钟前
算法学习笔记:8.Bellman-Ford 算法——从原理到实战,涵盖 LeetCode 与考研 408 例题
java·开发语言·后端·算法·最短路径问题
天天摸鱼的java工程师21 分钟前
使用 Spring Boot 整合高德地图实现路线规划功能
java·后端
东阳马生架构36 分钟前
订单初版—2.生单链路中的技术问题说明文档
java
咖啡啡不加糖1 小时前
暴力破解漏洞与命令执行漏洞
java·后端·web安全
风象南1 小时前
SpringBoot敏感配置项加密与解密实战
java·spring boot·后端
DKPT1 小时前
Java享元模式实现方式与应用场景分析
java·笔记·学习·设计模式·享元模式
Percep_gan1 小时前
idea的使用小技巧,个人向
java·ide·intellij-idea
缘来是庄1 小时前
设计模式之迭代器模式
java·设计模式·迭代器模式
Liudef061 小时前
基于HTML与Java的简易在线会议系统实现
java·前端·html