项目码云(Gitee)地址:https://gitee.com/banmajio/RTSPtoRTMP
项目github地址:https://github.com/banmajio/RTSPtoRTMP
个人博客:banmajio’s blog

javacv使用ffmpeg将rtsp转rtmp直播流播放的问题解决与优化系列文章:
FFmpeg转封装rtsp到rtmp(无需转码,低资源消耗)
JavaCV中FFmpegFrameGrabber调用start()方法时出现阻塞的解决办法
JavaCV使用FFmpeg进行rtsp转rtmp直播流画面延时的优化方法
JavaCV1.5.3版本FFmpegFrameGrabber初始化的时候加载时间长的解决方法
av_write_frame() error -22 while writing video packet解决方法

场景描述:使用之前博客中的FFmpeg转封装rtsp到rtmp(无需转码,低资源消耗)服务进行直播流的播放时,发现从调用api到客户端播放器出现画面会耗时3-7秒所有,也就是说播放器点击播放后,会黑屏几秒才会出现直播画面。

问题分析:通过debug发现两个地方会影响画面加载速度:
1:由于首帧pts和dts不相等导致的画面延时
2:FFmpegFrameGrabber调用start()方法执行时间太长导致画面延时

下面从上述两个方面对画面延时问题进行解决

探测流信息之后dts没有被重置

问题分析

DTS(Decoding Time Stamp):即解码时间戳,这个时间戳的意义在于告诉播放器该在什么时候解码这一帧的数据。
PTS(Presentation Time Stamp):即显示时间戳,这个时间戳用来告诉播放器该在什么时候显示这一帧的数据。

根据ffmpeg打印的信息猜测是因为探测流信息之后,有一些探测阶段的pkt被缓存了下来。当grabber获取到pkt的时候,dts从0开始累增,但是之前的pts没有被重置,当前的dts一直都小于之前的那个pts的值,所以这些包会被丢弃掉,直到dts累增到大于等于上一包pts的时候,才会播放。
FFmpeg提示信息如下图:
pts&dts
可以看到首帧的pts是从1081开始的,而dts是从0开始的。所以dts会一直累加直到大于等于pts的值。

解决方法

有两种方法可以解决上图中的报错信息
1.在推流函数中,获取grabber数据包之前,将缓冲释放掉

		// 连续五次没有采集到帧则认为视频采集结束,程序错误次数超过5次即中断程序
		logger.info(cameraPojo.getRtsp() + " 开始推流...");
		// 释放探测时缓存下来的数据帧,避免pts初始值不为0导致画面延时
		grabber.flush();
		for (int no_frame_index = 0; no_frame_index < 5 || err_index < 5;) {
			try {
				// 用于中断线程时,结束该循环
				nowThread.sleep(1);
				AVPacket pkt = null;
				// 获取没有解码的音视频

2.直接在根源上制止这种行为的发生。在grabber.start()函数内会有一个探测流信息的函数avformat_find_stream_info(),在这边可以设置一个属性flags,在探测流信息的时候读取的数据包不放入AVFormatContext的缓冲区packet_buffer中。

		// 将avformat_find_stream_info内部读取的数据包不放入AVFormatContext的缓冲区packet_buffer中
		oc.flags(AVFormatContext.AVFMT_FLAG_NOBUFFER);

		AVDictionary optionOut = new AVDictionary(null);
		if ((ret = avformat_find_stream_info(oc, (PointerPointer) null)) < 0) {
			throw new Exception("avformat_find_stream_info() error " + ret + ": Could not find stream information.");
		}
		if (av_log_get_level() >= AV_LOG_INFO) {
			// Dump information about file onto standard error
			av_dump_format(oc, 0, filename, 0);
		}

以上两种方法都可以完美解决ffmpeg 出现Application provided invalid, non monotonically increasing dts to muxer in stream 0 错误的情况。

FFmpegFrameGrabber调用start()方法执行时间太长导致画面延时

问题分析

如上文所言,在start()函数内会有一个探测流信息的函数avformat_find_stream_info();这个函数主要是读一些包(packets ),然后从中提取出流的信息。对于这个函数更详细的解释和源码分析可以参考:ffmpeg源码分析5-avformat_find_stream_info()这篇博客。

在执行到这个函数的时候,会消耗大量的时间,甚至出现阻塞现象导致函数无法返回。

解决方法

可以通过设置两个属性来限制此函数的执行时间:
1.probesize属性限制avformat_find_stream_info接口内部读取的最大数据量,probesize属性的默认值是5000000 B的数据量,一般情况下50x1024的数据量足够探测出高清摄像头一帧的信息,这个值可以通过摄像头最大码率值来设置,只要大于最大码率值即可。
2.max_analyze_duration属性设置avformat_find_stream_info这个函数的持续时长,超过这个时间不结束也会结束
在调用avformat_find_stream_info()函数之前设置这两个属性可以极大的减少此函数的执行时间。

		oc.max_delay(maxDelay);
		// Retrieve stream information
		// 限制avformat_find_stream_info接口内部读取的最大数据量
		oc.probesize(Integer.parseInt(streamCode));
		// 设置avformat_find_stream_info这个函数的持续时长,超过这个时间不结束也会结束
		oc.max_analyze_duration(5 * AV_TIME_BASE);
		// 将avformat_find_stream_info内部读取的数据包不放入AVFormatContext的缓冲区packet_buffer中
		oc.flags(AVFormatContext.AVFMT_FLAG_NOBUFFER);

		AVDictionary optionOut = new AVDictionary(null);
		if ((ret = avformat_find_stream_info(oc, (PointerPointer) null)) < 0) {
			throw new Exception("avformat_find_stream_info() error " + ret + ": Could not find stream information.");
		}
		if (av_log_get_level() >= AV_LOG_INFO) {
			// Dump information about file onto standard error
			av_dump_format(oc, 0, filename, 0);
		}

如有错误或者更好的解决办法,请指正!!!

Logo

致力于链接即构和开发者,提供实时互动和元宇宙领域的前沿洞察、技术分享和丰富的开发者活动,共建实时互动世界。

更多推荐