- 博客(10)
- 收藏
- 关注
RSS订阅原创 长期参考帧解决SFU场景多端接入问题
之间已经详细介绍了长期参考帧的技术实现，以及长期参考帧抗网络丢包的技术实现，本章讲解长期参考帧如何应对SFU场景下多终端同时接入问题。阅读本篇帖子之前建议先阅读长期参考帧技术介绍和长期参考帧抗网络丢包帖子视频会议SFU架构下如果会议过程中再邀请10个新的成员入会，成员入会后会主动向SFU码流转发服务器选取已经在会议中的视频流，那么由于成员入会选流并不是完全的同一时刻，多个新成员入会选流的信令到达SFU服务器可能有几十或者几百毫秒的延时，当有一个新的成员选流时SFU会向码流源头请求编码I帧，否则新进入的成员没
2025-02-01 12:00:33
850
原创 RTC场景下长期参考帧抗网络丢包
如上图，发送端编码一路带有长期参考帧的码流，长期参考帧之间的P帧省略没有画出，当该路流向终端1进行转发时，索引2长期参考帧丢失没有完全恢复，此时接收端会向发送端反馈请求基于已经接收到的长期参考帧索引1进行编码一帧恢复帧，恢复帧到达后终端1可以正常解码后续码流，之后转发给终端2的码流，长期参考帧索引3出现丢失没有完全恢复，那么终端2会向发送端反馈请求基于索引2编码一帧恢复帧，但此时终端1内部并没有正确接收到长期参考帧索引2，那么发送端基于长期参考帧索引2编码的恢复帧达到终端1时，终端1将无法正常解码。
2025-01-29 20:40:31
1960
原创 长期参考帧编码技术介绍
首先要说明一点，长期参考帧和普通的编码帧实际内部编码负载数据没有什么不同，只是编码器将某些P帧标记为长期参考帧，那么被标记的帧内部会带有少许标记信息，实际帧大小和普通P帧几乎没有差别，在编码器内部将某个P帧标记为长期参考帧之后，会长期保存该帧对应的YUV数据，直到出现相同索引的长期参考帧时，才会过期之前的长期参考帧。通常的视频编解码使用短期参考帧，在编码器内部保留上一帧的YUV数据，编码下一帧时通过下一帧YUV数据和上一帧YUV数据进行对比，获取帧间差值进行编码，然后过期上一帧，保留最后一帧YUV数据。
2025-01-26 10:14:22
468
原创 视频会议SFU架构下音频端侧混音和服务测混音优劣对比
以上就是两种混音方式的对比，综合来看在端侧进行混音效果应该会更好一些，因为腾讯会议以及ZOOM都是采用端侧混音的方式进行的实现。
2025-01-11 18:06:18
653
原创 webrtc中周期的SR报文对音视频同步的意义
从以上分析中可以看出，RTP场景下要不断发送SR报文校准音频采集的偏差，来让接收端能实现正常的音视频同步。
2025-01-11 17:25:39
923
1
原创 RTC场景下音频时间戳的设置问题
在RTC场景下，音频时间戳通常按照音频的帧数固定递增，基于采样率和帧长度计算时间戳的递增间隔。这种设置方式确保了音频数据的稳定性和实时性。简而言之，音频时间戳是按照固定的帧间隔递增的，例如每20ms增加960（在48kHz时间基下），而不是基于实际采集时间。
2025-01-11 16:15:13
262
原创 RTC实时通信场景下视频时间戳的设置问题
在实时通信（RTC）场景下，视频时间戳的设置通常是基于采集时间（系统时间），而不是按照帧率固定递增。这种设置方式能够：准确反映每一帧的实际采集时间，确保音视频同步。适应帧率波动和网络抖动，支持接收端更好的去抖。满足RTC对实时性和低延迟的高要求。如果采用固定递增的时间戳设置方式，可能会因为帧率波动或网络抖动导致时间戳偏差，从而影响音视频的同步和延迟控制。因此，在RTC场景下，基于采集时间的时间戳是更合适的选择。
2025-01-11 15:58:36
957
原创 webrtc中neteq模块解决音频采集播放偏差问题
正是由于webrtc中是播放事件驱动音频的获取，当系统负载过高实际播放一帧20ms的音频消耗的时间超过20ms的情况下，pcm数据会堆积在neteq内部，neteq感知的内部pcm数据堆积过多时会通过相关的算法对音频pcm数据进行加速融合，比如将1000个音频采样点压缩为900个采样点而不改变声调，做到不增加延时也不丢pcm数据。以win平台的音频播放为例，在core_audio_base_win.cc文件中，会启一个事件监听的线程，当有新的可播放事件时，调用。)//获取可播放的数据放入音频播放缓冲区中。
2025-01-11 15:23:26
895
原创 音频采集播放偏差问题
提示：这里可以添加总结从以上实验可以看出，音频的采集和播放耗时都和理论值有所偏差，如果不对这些偏差做相关处理发送端直接发送，接收端直接解码播发，将会使音频效果出现问题。比如，发送端音频就是20ms采集一帧进行发送，而接收端播放音频每20.1ms才能播完一帧，那么随着时间的推移，接收端势必会出现接收数据堆积越来越多的问题，那么接收端的播放延时会越来越大，如果接收端堆积数据过的时进行丢弃那么又会造成音频数据包的丢失导致音频出现卡顿的现场。
2025-01-11 12:47:02
2011
原创 webrtc视频jitterbuffer全网最详细分析
上图横轴为每一帧的时间戳，纵轴为每帧完整时进行处理通过系统接口获取的当前时间now_ms(也可以理解为一帧在接收端接收的时间),其中绿色的点为每帧实际的时间戳对应的实际接收时间now_ms,最下方黑色虚线为结合所有帧的时间戳和now_ms经过卡尔曼滤波之后拟合出来的一个直线，红色点为最后这一帧根据其自身时间戳在拟合的线性关系上预测出的点，其纵轴对应的为预测出的本地时间Localtime,红色点上方的绿色点为实际该帧在接端接收的时间，灰色的虚线为每帧的实际解码的时间点，最上方黑色虚线为每帧渲染的时间点。
2024-10-13 02:24:08
3776
9
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人