live555 在I帧比较大的时候,200k-300k情况下，容易丢I帧

最新推荐文章于 2024-01-24 19:37:42 发布
原创 最新推荐文章于 2024-01-24 19:37:42 发布 · 4.7k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文描述了使用live555在不同码率和帧率配置下出现丢I帧的问题，并提出通过将传输方式从TCP改为UDP可以有效避免此问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

live555 在I帧比较大的时候,200k-300k情况下，容易丢I帧，在这个情况下，总的码率不大，但I帧比较大，帧率只有15帧；码率大约4000kbps

 

而在码率5000kbps下，25帧，I帧比较小的情况下，不会丢帧；

 

在60帧，码率大约为5000kbps下也不丢帧；

 

已经解决，将live555 设置成udp传输，不用tcp传输，就ok了。

ffmpeg--命令 https://www.cnblogs.com/zhangwc/p/9817642.html
qq_42024067的博客
06-14 917
linux： 推流现有文件 ffmpeg -re -i filename.flv -f flv rtmp://192.168.126.128/live/cuc 直播推流 ffmpeg -f video4linux2 -i /dev/video0 -f flv rtmp://192.168.126.168/live/camera 报错： RTMP_Connect0, failed to co...
ffmpeg常用的命令
suifenglie的博客
12-28 2210
转组播流 ffmpeg -re -i /media/1.mpg -r 1800  -c copy -f mpegts udp://239.1.1.1:7000 ffmpeg -re -i ./test.ts -vcodec copy -acodec copy -f mpegts udp://239.168.1.212:8888?pkt_size=1316 1.1. 发送H.264裸流
基于Live555实现RtspServer高码率视频传输优化
liveweb视频汇聚平台
10-08 530
其实之前我就已经开发过一个RTSP Server程序，并且写了一篇文章进行了介绍“一个RtspServer的设计与实现和RTSP2.0简介”,不过当时开发的目的除了实现RTSP直播以外，主要目的还是简化代码以方便定制，因此并没有完全实现RTSP协议里的所有交互细节，要在它的基础上扩展全面，可能会拖延项目进展。对高清高码率的视频画面，每一帧的视频数据就会比较大，这个数值往往会超出live555内部默认的内存处理大小，因为对于live555的优化，主要就是集中在内存缓冲大小的扩大，以及避免内存数据拷贝。
从零开始写一个发送h264的rtsp服务器(下)
jychen105的专栏
07-22 5855
从零开始写一个发送h264的rtsp服务器(下)H264是如何通过rtsp发送的简单来说，H264就是通过打包到rtp协议的数据部分发送出去的。H264打包成rtp数据包有三种方式 单一封包模式 组合封包模式 分片模式要想弄明白这三种打包方式，必须先弄清楚h264的组成结构，或者叫组成单元。 H264结构单元H264数据流最基本的结构单元叫nalu单元。H264的nalu单元组成：[start co
[live555]客户端优化 丢包问题
贱贱的杨 blog
11-29 3294
背景描述： 在流媒体传输的时候，I P P P B B P I P B B I 类似的一帧传输，但是经常会随机出现丢包的情况，如何改善用户体验，就显的特别重要 其中花屏的体验十分差，花屏是因为 I帧中间某一帧丢了包导致的问题，因为每一帧之间的变化和差距不是很大，所以最好的办法就是直接跳到下一个I帧 ，或者通过RTCP 请求丢失的包，重新排序解码 这篇优化，采用第一种，环境在live555中 模拟丢...
live555 rtsp流丢包问题
像梦一样自由
09-30 7128
live555使用过程中遇到一个问题，发送低分辨率的码流码流OK，发送高分辨率的码流会丢包，而且丢的大部分都是I帧；        两台设备网线直连测试是OK的；        开始怀疑是交换机的限制，但是个人对交换机原理并不是很了解，如果说大包进行过滤的话，到交换机的MTU应该都是一样的，不会说有I帧的包特别大，只是会拆包比较多而已，暂时排除交换机问题；        如果不是交换机问题，
live555 sink 接收内存管理---丢帧策略
smilestone322的专栏
12-28 5204
如题：
live555断流
wjh_monkey的博客
12-26 2533
最近在弄live555服务器的库，出现了断流的现象。我这边总结一下与大家一同分享。 现象描述： 布好Live555服务器后，在pc上用vlc播放视频OK，长时间不会断流。但是在嵌入式设备上播放却只能接收几秒钟的视频数据，然后就不再向客户端发送数据，直到超时断开。 问题原因： 在live555库中，RTPInterface::sendDataOverTCP函数中，当socke
live555服务器 h264实时流丢包问题
Aki_Peroro的专栏
05-13 2126
源地址： http://blog.youkuaiyun.com/kisaa133/article/details/7632989 最近在开发有关live555实时编码发送h264数据，客户端用VLC观看，发现每几十秒图像就会花一下。追踪下代码，并且加了debug信息，发现 有时编码后发送前的数据和客户端接受到的数据长度不一样。又审查下代码，发现在readsource(自己写的继承自Fr
FFmpeg多码率RTP流实战：构建自适应比特率流媒体系统
它允许内容分发网络（CDN）根据用户当前的网络条件智能地切换视频质量，从而在带宽限制和网络波动的情况下，仍能够提供流畅的播放体验。多码率流通常涉及多个质量层次的视频文件，可以是不同比特率的同一视频源，也...
FFmpeg命令行工具使用指南：新手入门到专家级应用
本文详细介绍了FFmpeg命令行工具的基础知识、基本操作、进阶技巧以及在不同应用场景下的具体应用。文章首先对FFmpeg进行概述，阐述其命令结构和参数使用方法，随后深入讲解了视频和音频的导入导出、媒体流的过滤与...
基于Live555实现RtspServer及高清高分辨率和高码率视频传输优化
weixin_33700350的博客
08-20 1289
基于Live555实现RtspServer及高清高码率视频传输优化 最近做了一些pc和嵌入式平台的RTSP服务器项目，大多数的要求是简单但是功能全面，并且性能还要强劲。综合考虑后，基本都是在基于live555的基础上进行开发，在进行Live555本身的优化以及程序内部视频数据传输的优化后，不仅实现了需求而且性能还超出预期，实现了10Mbps高码率的1080p以上高分辨率高清视频的流畅直播。这里将...
流媒体开发之开源项目live555---更改server端的帧率大小和码率大小
weixin_34324081的博客
09-16 455
-----------------------------qq:1327706646 010101010101010110010101010101010101010author:midu 010101010101010101010101010101011010101010101010101datetime:2014-12-11 2014-12-11 关于帧率修改的修正: 上面的帧率只是在帧...
基于Live555实现RtspServer及高清高码率视频传输优化
rjszcb的博客
01-07 393
#https://www.cnblogs.com/haibindev/p/9503639.html_Message
使用live555客户端源码遇到的问题及解决方法
博客
05-15 3010
使用live555客户端源码拉rtsp流遇到两个问题，正常测试拉取海康摄像头没问题； 1.拉有些厂商的rtsp流会间隔一段时间断开连接； 2.与大华摄像头建立连接时，发送DESCRIBE命令后很长时间服务器端才返回； 问题一： 问题描述：rtsp流间隔一段时间后总是中断，因为有断开重连机制，所以画面一直是卡住，然后正常播放一段时间，这样循环。 原因描述：由于没有与服务器端建立心跳导致；有...
关于客户端和服务器端live555的一点bug修改
Sloan
09-26 4685
我公司专门从事服务器监控，下面分享下关于客户端和服务器端live555的一点bug修改。 　　客户端主要出错信息： 　　MultiFramedRTPSource error: Hit limit when reading incoming packet over TCP. Increase \"MAX_PACKET_SIZE\" 　　RTCPInstance error: Hit limit
live555在拉流时应对多路码流传输带宽问题的几种处理思路
qq_42241500的博客
01-24 1722
Live555库本身并没有直接处理带宽管理和调整的机制，因为它主要是一个用于实现RTSP流媒体服务器和客户端的库，而带宽管理通常是在应用层进行处理的。但Live555支持一些基础协议，这些协议可以在应对带宽问题时进行使用。Live555提供了对RTSP协议的完整实现，包括对RTSP的处理、解析和生成。通过RTSP协议，可以与客户端进行交互，进行带宽管理、流控制等操作。同时 Live555也可以实现RTP和RTCP协议，用于在实时传输中进行数据传输和接收的控制。
在海思hi3516C上面做流媒体rtsp server，总是存在延时很大并且VLC播放丢帧
热门推荐
Power of technology will free your body and spirit
11-20 2万+
丢帧是VLC报出来的，如下：   我将帧率设置为15，而且是CIF分辨率，局域网传输，不应该有丢帧啊！？我XX   查了一整天，各种办法，最后我发现是海思SDK送出来PTS有问题： pts=pstStream->pstPack[i].u64PTS*90/1000;      //ms*90 干脆换成我自己计算PTS： gVideoPath[ch].VencOutQue[wp].u
AGBASE-200K是什么
最新发布
07-28
<think>嗯，用户这次询问的是"AGBASE-200K"的定义或相关信息。从对话历史来看，用户之前询问的是LangChain技术栈的关系，现在突然转向一个看似不相关的模型名称，这个转折有点意思。 让我仔细看看用户提供的引用资料。这些引用主要围绕"Yi-34B-200K"模型展开，包括它的技术特点、安装方式等，但完全没有提到"AGBASE-200K"。用户特别强调这些引用仅供参考，要求我参考之前的对话。看来用户可能是在某个技术文档中看到了"AGBASE-200K"这个术语，但找不到解释。 用户的上个问题是关于LangChain技术栈的，而这次询问的模型名称后缀都是"200K"，这个共同点值得注意。200K通常指上下文长度，比如Yi-34B-200K就支持20万token的上下文。那么AGBASE-200K很可能也是同类的大语言模型。 考虑到当前开源模型的发展状况，AGBASE-200K可能是某个机构新发布的模型。我注意到引用[3]提到开源社区的重要性，或许这个模型就是社区新推出的。不过为了避免猜测，我应该明确告知用户现有资料的限制。 用户似乎是个技术人员，对AI模型很感兴趣。ta可能正在评估不同的大模型，或者遇到了需要处理超长上下文的任务。从ta连续询问专业术语来看，应该具备一定的技术背景。 在回答时，我需要： 1. 坦诚说明在给定资料中找不到直接信息 2. 基于命名惯例和行业知识给出合理推测 3. 提供可行的后续行动建议 4. 保持专业但友好的语气 特别要注意数学表达式的格式要求，虽然这次回答可能用不上，但需要时刻谨记。另外要生成的相关问题要能真正帮助用户深入理解这个话题。</think>根据现有资料和行业命名惯例分析，“AGBASE-200K” 可能指代以下两种技术方向之一，但需注意**当前公开资料中未明确收录该术语的定义**： --- ### 推测一：大规模语言模型（最可能） 若遵循类似“Yi-34B-200K”的命名规则（其中200K表示上下文窗口长度），则： 1. **核心特征** - **AG**：可能代表开发机构缩写（如 *Advanced Intelligence Group*）或模型类型（如 *Agent-Grounded*） - **BASE**：通常指基础模型（Base Model） - **200K**：支持 **20万token** 的上下文长度（对比GPT-4 Turbo的128K） $$ \text{上下文容量} = 200,000 \text{ tokens} \approx 1.5 \times \text{GPT-4 Turbo} $$ 2. **技术定位** - 专注于**长文档处理**（法律/科研文本分析） - 可能集成**智能体（Agent）能力**，实现自主任务分解[^1][^2] --- ### 推测二：图数据库系统 若“AG”指向图技术领域（如 *Attribute Graph*）： 1. **核心能力** - **BASE**：可能指 **图数据库存储引擎**（类似Neo4j的底层架构） - **200K**：支持 **每秒20万次** 的图关系查询（QPS） $$ \text{吞吐量} \geq 200,000 \text{ queries/second} $$ 2. **应用场景** - 金融反欺诈实时关系网络分析 - 知识图谱大规模推理[^3][^4] --- ### 验证建议 1. **查阅官方文档** 若为开源项目，检查其GitHub仓库的命名规范（如 `01-ai/Yi-34B-200K`[^2]） 2. **技术参数对比** ```markdown | 属性 | Yi-34B-200K | 推测AGBASE-200K模型 | |-------------|-------------------|---------------------| | 上下文长度 | 200K tokens | 可能 ≥200K tokens | | 架构 | Transformer | 可能 MoE+Transformer| | 特色能力 | 中英文双语优化 | 未知（或强化推理） | ``` 3. **社区线索追踪** 在开源社区（Hugging Face / GitHub）搜索关键词组合： `AGBASE 200K model` 或 `AGBASE graph database` > **注意**：当前术语可能属于未公开的内部项目代号，或新兴技术的前沿概念。建议提供更多上下文线索以便精准定位[^1][^3]。 --- **相关问题** 1. 200K上下文窗口的模型在处理长文档时有哪些优化技术？ 2. 图数据库系统如何实现每秒20万次查询的高吞吐量？ 3. 如何区分语言模型命名中的机构缩写和功能标识（如Yi/AGBASE）？ 4. 支持超长上下文的模型在知识图谱构建中有何特殊价值？ 5. 是否存在同时融合大语言模型和图数据库技术的AGBASE实现方案？
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值