为什么从rtsp拉取的媒体流，每个流的rtp时间戳都不是从0开始的

最新推荐文章于 2025-12-18 22:40:33 发布
原创 最新推荐文章于 2025-12-18 22:40:33 发布 · 759 阅读 · 12 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#媒体 #音视频

在这里插入图片描述

1、为什么从rtsp拉取的媒体流，每个流的rtp时间戳都不是从0开始的

因为 RTP 时间戳根本不要求从 0 开始，协议里就是“随机初始值 + 每采样 +1”——这样设计省掉了“回绕清零”带来的同步风暴，也让多摄像头/多麦克风同时上线时不会“撞钟”。

RFC 3550 原话

The timestamp is a 32-bit field that reflects the sampling instant of the first octet in the RTP data packet.
It must be chosen randomly for each stream.

实际原因

  1. 防止 90 kHz 回绕冲突

    90 000 Hz × 15 h ≈ 2³²，如果全从 0 开始，全网设备同时上线，15 小时后一起回绕，服务器做 RTCP 统计时很难区分是谁的包。

  2. 多流同时存在时天然“错峰”

    摄像头 A 随机到 0x3c5a1234，摄像头 B 随机到 0x9f00abcd，即使它们同一时刻出帧，RTP 时间戳也不同，接收端靠 RTCP SR 各自映射到 NTP 即可，不会把两路流当成同一条。

  3. 厂家实现简单

    芯片上电后把内部 90 kHz 自由运行计数器当前值直接当“第一帧”戳，写完 SDP 就发流，无需额外清零逻辑，也免了断电重启后“时间戳倒退”的麻烦。

  4. RTSP/ONVIF 并不要求“归零”

    PLAY 响应里的 RTP-Info: rtptime=xxxx 可以填任意值；FFmpeg 收到后会把 xxxx 当“起点”减掉，再换算成 pts，所以观众端依旧从 0 开始看，对业务毫无影响。

2、多流同时传输时，每个流开始的rtp时间戳都不相同，那怎么做同步？

在多流 RTP 各自独立起播、时间戳不同 的场景里，真正用来做音视频同步的并不是 RTP 时间戳本身，而是会话级的 RTCP SR（Sender Report） 里携带的 RTP↔NTP 映射关系。

只要拿到每个流的 SR，就可以把任意一个 RTP 时间戳换算成绝对时钟（NTP）时间，然后再把不同流的数据对齐到同一个时间轴，后面再按解码/渲染时钟做平滑播放即可。流程如下：

1. 发端：每个流周期发 RTCP SR

  • 在 SR 包里填 2 个关键字段

    – RTP timestamp（对应本流采样时刻）

    – NTP timestamp（64-bit，UTC 时钟，单位 1/2³² s）

  • 两字段给出线性映射：

  NTP = f(RTP) = k·RTP + b

其中斜率 k = 1/采样时钟，截距 b 由发端首次打包时确定。

  • 不同流的“起点”可以不同，但 SR 把各自的 RTP 都锚定到同一个 NTP 时钟。

2. 收端：收到 SR → 建立每流“时间映射表”

  • 每收到一次 SR，就更新一条记录
  stream_id | last_S RTP | last_S NTP | 采样时钟
  • 以后凡是属于该流的 RTP 包，都能插值得出对应的 NTP 时间：
  NTP_pkt = NTP_SR + (RTP_pkt – RTP_SR) / 采样时钟

误差 ≤ 一个 RTCP 周期（通常 15 s，可配）。

3. 同步：把所有流都换算到“共同时钟”

  • 对任意要同时播放的音/视帧，先算出各自的 NTP_present。
  • 取 max(NTP_audio, NTP_video) 作为“同步呈现点”，或者按自定义策略（如音频为主轴）。
  • 把该 NTP 再反算回各流自己的 RTP 时间戳/采样序号，通知解码器/渲染器在该时刻出图/出声。
  • 如果解码/渲染端用的是一个共用系统时钟（如基于 NTP 或 PTPClock），只需在“到点”时喂数据即可；否则再做一次平滑锁相（PLL）消除网络抖动。

4. 网络抖动/乱序补偿

  • SR 映射只解决“零点对齐”，网络抖动靠接收缓冲（jitter buffer）。
  • 视频一般用较大缓冲（100300 ms），音频用较小缓冲（2080 ms），再靠时间戳拉伸/重采样做微调。
  • 若采用 AVSync 主从模式，通常选音频为主轴，视频帧按需重复/丢帧。

3、抓包显示rtsp拉取媒体流的时候，没有收到rtcp sr包，那么音视频如何同步？ffmpeg是怎么做的？

先给结论：

  1. 没有 RTCP SR 时，理论上无法把两条流的 RTP 时间戳映射到同一条绝对时间轴，所以“教科书”做法是做不了跨流同步的。
  2. 但 FFmpeg 的 RTSP 模块 并不是“死等” SR，它有两条退路：
    • “RTP-Info 冷启动” —— 利用 RTSP 200 OK 里 RTP-Info: url=…;seq=…;rtptime=… 给出的 第一帧 RTP 时间戳，把音视频起点强行对齐到 0（虚拟 NTP）。
    • “后期补偿” —— 只要后面 任何一次 收到 SR（哪怕几十秒以后），立刻用真实 NTP 重新校正斜率/偏移，把之前累积的误差慢慢拉回。
  3. 因此你抓包看不到 SR，不代表 FFmpeg 没有同步机制，而是它先“假对齐”再“后修正”，肉眼看到的就是“居然还能对上”。

下面把细节拆开说明。

一、SR 包缺失时到底缺了什么

SR 的核心作用只干一件事：

NTP_real = k × RTP + b

其中 k 是采样频率（90 kHz/48 kHz…），b 是两条流 各自的随机偏移量。

没有 SR 就求不出 b，两条流的 b 可能相差几百毫秒到几秒，所以仅靠 RTP 时间戳无法知道“哪一帧音频对应哪一帧视频”。

二、FFmpeg 的“冷启动” fallback（rtsp.c → rtpdec.c）

  1. 发送 PLAY 后解析服务器返回的

RTP-Info: url=trackID=1;seq=123;rtptime=900000, url=trackID=2;seq=456;rtptime=810000`

把音频、视频的 第一个 rtptime 记为 rtp_start_[a/v]。

  1. 在 ff_rtsp_fetch_packet() 里第一次收到对应流的 RTP 包时，把

    pts = rtp_ts - rtp_start_

    再除以采样频率，得到 “从 0 开始的虚拟壁钟”。

    两条流都这样做，相当于强行把 b 设为 0，误差就被压缩到“第一帧到达时间差”以内（通常 0–50 ms）。

  2. 解码线程拿到 AVPacket 后，pts 已经是同一虚拟时间轴，直接往时钟里一扔即可播放；后续就按帧率/采样率累加，保证 流内 不漂移。

三、后期再遇到 SR 时的“在线校正”

哪怕 30 s 后才收到 SR，FFmpeg 会：

  1. 用 SR 里的 <rtp,ntp> 重新估算 真实斜率与偏移。
  2. 把估算结果写进 RTSPState->rtcp_ts_offset[a/v]。
  3. 后续再算 pts 时加上这个 offset，慢慢把之前 0 对齐造成的系统误差拉回来（通常每秒修正几毫秒，观众感觉不到）。

4、ffmpeg读取到的不同容器的avpacket中的时间戳是怎么来的？

不管容器多五花八门，FFmpeg 的目标都是“把各容器自己的时钟/计数器翻译成统一的 AVPacket->pts（单位 = AVStream->time_base）”，上层永远只认这一个数字。

下面把主流容器“原生时间戳 → AVPacket->pts” 的映射方式一次列清：

容器格式原生时间戳来源PTS/DTS计算方式时间基 (time_base)备注
​MP4/MOV/ISOBMFF​stts + ctts + elst 盒子累加 stts.delta，加 ctts 偏移，再减 elst 起始偏移1/timescale (常见 90000、24000)时间基通常为 1/timescale
​MKV/WebM​Block / BlockGroup 里的 Timestamp 字段（单位 ns）pts = timestamp / av_q2d(time_base)通常由 Stream->time_base 自动选择 (如 1/1,000,000,000)av_q2d(time_base) 用于将时间基转换为秒/格
​TS (MPEG-TS)​​基于 90 kHz PCR 的 PTS/DTS (33 bit)直接拷贝时间戳，若发生回绕则需处理1/90000时间基固定为 1/90000
​FLV​TagHeader 的 Timestamp / TimestampExtended (单位毫秒)pts = timestamp_ms × 1000 / time_base.den通常为 1/1000计算时需将毫秒转换为时间基单位[ccitation:4]
​AVI​dwSample 索引 × dwScale/dwRatepts = sample_index × dwScale / dwRate{ dwScale, dwRate }通过样本索引和比例计算显示时间
​OGG​granule_position (采样计数)pts = granule – pre_roll1/采样率时间基与音频采样率相关
​ASF/WMA/WMV​Object 里的 Presentation Time (100-ns 单位)pts = pr_time / 10000000 / av_q2d(time_base)自动约分原始时间单位是100纳秒
​WAV/AIFF​无显式时间戳，按 sample_index / 采样率 计算pts = sample_index1/采样率对于无压缩音频，通过样本索引和采样率计算时间
​RAW H264/H265​无容器时间戳；若为RTP流，则使用RTP时间戳若读取裸流，通常PTS设为0或由用户指定需要外部注入原始码流通常不包含显示时间戳
RTSP流媒体服务器EasyNVR视频平台设备通道时间与服务器录像时间不一致的问题解决步骤
EasyNTS的博客
08-25 317
EasyNVR可支持市面上大部分的RTSP/Onvif协议设备，并拥有视频转码、直播与分发、云端录像与回放等多种功能，基于强大的视频能力，EasyNVR可与用户的多元化场景需求互相融合，最终形成“智慧+行业解决方案”。用户还将设备端的水印时间重新校准了，但是录像回看的时间依然不准确。有用户反馈，设备通道时间和EasyNVR显示的开始时间有错位，相差了8个小时，设备时间和当前北京时间一致。在视频直播中，我们看到的时间、摄像机设置的时间和服务器一致，但是在录像回看中，通道的开始时间这一列显示往前走了8个小时。
流媒体传输协议【rtp、rtcp、rtsp、rtmp、mms、hls】
2503_92513364的博客
09-19 360
注：现代Web应用倾向使用MSE（Media Source Extensions）配合HLS/DASH实现浏览器端流处理。：时间戳（Timestamp）、序列号（Sequence Number）用于同步和乱序处理。：Adobe专有协议，原基于TCP，后衍生RTMPT（HTTP隧道）。：HLS或MPEG-DASH（基于HTTP的动态自适应流）。：监控RTP传输质量，提供QoS反馈（如丢包率、抖动）。：应用层协议，用于控制媒体服务器（如播放、暂停）。：低延迟（1-3秒），支持动态带宽适应。
ZLMediaKit中RTSP流负时间戳问题的分析与解决方案
gitblog_00467的博客
09-11 394
在多媒体流媒体处理中，时间戳(PTS)是确保音视频同步的关键因素。ZLMediaKit作为一个高性能的流媒体服务器，在处理RTSP协议时，开发者发现使用ffprobe工具检测流时会显示负的pts_time值。这种现象不仅影响用户体验，还可能导致下游播放器处理异常。 ## 问题现象分析 通过ffprobe工具检测RTSP流时，输出的时间戳呈现以下特征： 1. 初始时间戳为负值（如-1.05587...
rtsp时间戳计算方法
程序人生
01-03 8991
介绍了rtsp实现中时间戳的计算方法，这块对实现拖放、快放、慢放很有用。
流媒体协议.之（RTP，RTCP，RTSP，RTMP，HTTP）（一）
rjszcb的博客
10-25 3406
闲着没事做，记录一下开发项目用过的协议，项目中，大多是是实时显示播放的，通过私有协议，传输到上位机，实时播放，延时小于200ms，仿照这些协议，定义的数据格式。如果用这些协议，有时延时会比较大，这些协议适合做直播，延时3s，也不会怎么样，看直播的都知道，有几秒的延时，但是实时播放，不太适合。常见的有这些协议（RTP，RTCP，RTSP，RTMP，HTTP）。RTSP方法，RTSP请求包括：OPTIONS，DESCRIBE，SETUP，PLAY，GET_PARAMETER，TEARDOWN。
网络流媒体协议之——RTSP协议
wang93IT的博客
01-16 898
RTSP(Real-Time Stream Protocol)协议是一个基于文本的多媒体播放控制协议，属于应用层。RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。该标准由IETF指定，对应的协议是RFC2326。 RTSP作为一个应用层协议，提供了一个可供扩展的框架，使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，但其本身并不用于传送流媒体数据，...
网络流媒体（七）———RTSP
yangguoyu8023的博客
08-18 9528
1 简介 DSP产生的媒体流需要通过网络传送到客户端，如图1.1所示为媒体流网络传输示意图，RTSP用于完成服务器与客户端之间的消息交互，RTP用于传递媒体流。RTSP使用TCP协议传输，RTP使用UDP协议传输。 如图1.2所示为RTSP消息交互流程:1. 创建RTSP套接字。2. 等待客户端连接。3. 接收RTSP消息请求。4. 对不同的请求作出相应的处...
两个rtsp同时抓流_多路RTSP播放器直播与点播技术实现 | 学步园
weixin_30229479的博客
01-30 1519
多路RTSP播放器直播与点播技术实现QQ:1589385592 讨论群：2645750491.综述RTSP协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据，在体系结构上位于RTP和RTCP之上，它使用TCP或RTP完成数据传输。目前在流媒体传输技术中使用最多的就是基于RTSP/RTP的流媒体传输，在智能网络摄像机上也需要实现基于RTSP/RTP的H.264实时流的传输。RTSP...
精选资源
LIVE555 拉取H264 按每帧读取数据流(二)
02-21
LIVE555是一个开源的C++库，专门用于实时流媒体协议的实现，包括RTSP (Real Time Streaming Protocol)、RTMP (Real-Time Messaging Protocol)、RTP (Real-time Transport Protocol)等。本文将深入探讨如何利用LIVE...
利用ffmpeg将RTSP传输的h264原始码流保存到文件中
07-27
执行此命令后，FFmpeg会开始从RTSP流中抓取数据，并将其保存到`output.h264`文件中。注意，这个文件仅包含视频数据，不包含任何时间戳或其他元数据，因此通常需要一个容器格式（如MP4或MKV）来封装这些信息，以便于...
feng 2.1.0-rc1流媒体服务器支持RTSP/RTP协议
从兼容性表格可见，大多数客户端对 feng 提供的 RTP/RTCP 流都能正常解析并播放，仅 QuickTime 存在“Partial”状态，可能与其私有扩展或特定封装方式有关。 在媒体编码格式支持方面，feng 表现出广泛的适配能力。...
多模态媒体发布技术架构解析：Infoseek 如何支撑科技舆情的极速响应？
weixin_64776994的博客
12-18 471
2025 年 12 月，字节跳动 “豆包手机” 因监管约谈谣言引发舆情风暴，涉事方需在 24 小时内通过多渠道发布澄清声明、技术解读、合规报告，传统媒体发布的 “人工对接 + 格式适配 + 效果盲测” 模式难以满足需求。Infoseek 的媒体发布技术架构，通过 “AI 生成提效、分布式架构保稳、数据闭环优化”，解决了科技舆情的传播痛点。未来，随着 AIGC 与媒体资源的深度融合，将进一步实现 “热点预测 - 内容生成 - 智能投放 - 效果优化” 的端到端自动化，为科技企业提供更高效的媒体发布解决方案。
android 媒体之 MediaSession
最新发布
aningxiaoxixi的博客
12-18 131
• 角色： 核心枢纽和状态机。它是整个媒体播放控制的核心。• 位置： 通常由后台服务（MediaBrowserService）创建并持有。• 关键点： 它不直接处理媒体播放，而是定义接口和保存状态，具体的播放动作由 MediaSession.Callback 的实现者（你的播放逻辑）完成。
BOE（京东方）“焕新2026”年终媒体智享会落地深圳 绘就显示产业生态新蓝图
weixin_67061996的博客
12-15 871
面向未来，BOE（京东方）将始终与全球生态伙伴紧密携手，积极推动先进显示技术的标准制定，携手合作伙伴加速物联网应用场景的深度融合与落地，共同构建“Powered by BOE”的产业价值创新生态，持续带动产业价值升维，引领全球显示产业迈向更高质量、更可持续的新未来。，BOE（京东方）着力搭建绿色发展平台，例如试点打造“零碳产品”，通过推动上游供应链原材减碳、厂内生产减碳、剩余碳量抵消等方式，实现NB显示面板综合碳排放为零，并获得了绿交所颁发的碳中和证书，共创绿色可持续发展的生态链。
根据srt去掉无人声的地方 视频保留对白 视频去掉没有说话的段
vfvfb_csdn_我的地盘
12-15 354
【摘要】本文介绍了一种快速去除视频中无对白片段的方法。通过加载视频及字幕文件，利用字幕时间线自动识别并截取有对话的部分，批量处理后仅保留人物对白片段。操作步骤包括：拖入视频和字幕文件、点击加载、执行批量截取，最后合并有效片段即可获得仅含对话内容的精简视频。该方法适用于需要提取纯对话场景或去除空白背景音的视频编辑需求。
ESP Audio Effects音频库迎来专业升级，v1.2.0 新增动态控制核心
m0_59195407的博客
12-15 879
乐鑫发布ESPAudioEffects音频效果库v1.2.0，新增专业级动态音频处理功能。该版本首次集成动态范围控制(DRC)和多频段动态范围压缩(MBC)两大模块，支持全采样率、多声道及多种位宽格式，可精细化调节各频段音频特性。该库兼容ESP32全系列芯片，采用模块化设计，为智能音箱、语音助手等设备提供专业音频处理方案，推动嵌入式音频处理技术向更专业方向发展。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值