关于 live555延迟优化之缓存区优化“StreamParser::afterGettingBytes() warning: read”” 的解决方法

若该文为原创文章,转载请注明原文出处

本文章博客地址:https://hpzwl.blog.csdn.net/article/details/146354088

长沙红胖子Qt(长沙创微智科)博文大全:开发技术集合(包含Qt实用技术、树莓派、三维、OpenCV、OpenGL、ffmpeg、OSG、单片机、软硬结合等等)持续更新中...)

Qt开发专栏:各种问题解决(点击传送门)

问题

  写live555流媒体服务,发现延迟较大,优化缓存区后,逻辑检查没问题,但是发现无法成功打开,报错"StreamParser::afterGettingBytes() "。

分析过程

  

这里的是一直编码压入缓存,rtsp服务器开启,此时没有rtsp客户端连接,所以缓存是没有被一直消耗的:

  首要优化的就是缓存区的大小,可以让连接慢一点,但是延迟快一点:

  

  

  直接定位源码StreamParser::afterGettingBytes() warning: read"

  

  然后打印一下,是不是把指针当字节数了:

  

  分析结果如下:

  

  其调用顺序:

  

  

  

  

  所以,是调用了以下几个变量:

cpp 复制代码
fAfterGettingClientData
fFrameSize
fNumTruncatedBytes
fPresentationTime
fDurationInMicroseconds

  调用如下:

  

  发现对应的就是fFrameSize和fNumTruncatedBytes。

解决

  优化代码:

  

  这样,延迟逻辑确实得到优化了:

  

  这里只能说是live555代码开发的时候,变量没有初始化0,二次查源码就发现了,这里的缓存区优化完成。

本文章博客地址:https://hpzwl.blog.csdn.net/article/details/146354088

相关推荐
林石工作室13 天前
体育直播APP从0到1搭建指南:技术选型、核心模块与部署实战
spring boot·流媒体·app搭建·体育直播app·星逐赛事
java_logo15 天前
Docker 部署 go2rtc:轻松搭建摄像头多协议流媒体平台
运维·docker·容器·摄像头·rtsp·轩辕镜像·go2rtc
承渊政道17 天前
从GB到TB:KFS如何实现高吞吐、有序的异构增量同步
数据库·kingbase·延迟优化·kfs·数据量级优化
DogDaoDao1 个月前
【H266/VVC提案解读】ITU-T H.274 (V4) 规范深度解读 — 视频编码 SEI 消息的全面演进
音视频·实时音视频·视频编解码·流媒体·h266·vvc·视频编解码标准
程序员老陆1 个月前
FFmpeg RTSP 解复用器(rtsp demuxer)完全解析:从「能播」到「稳播」的参数圣经
ffmpeg·音视频·拉流·rtsp
阿拉斯攀登3 个月前
WebRTC 入门:是什么、能做什么、核心模块
音视频·webrtc·视频编解码·流媒体
换个昵称都难3 个月前
协议之RTSP介绍
rtsp
haibindev4 个月前
别让AI再从零写一堆优美的屎山了
c++·ai编程·claude·流媒体·codex·代码复用
aqi004 个月前
FFmpeg开发笔记(一百零二)国产的音视频移动开源工具FFmpegAndroid
android·ffmpeg·kotlin·音视频·直播·流媒体
aqi004 个月前
FFmpeg开发笔记(一百零一)跨平台的开源音视频移动框架MobileFFmpeg
android·ffmpeg·音视频·直播·流媒体