第二章IPTV网络部分流媒体的传输与控制协议5
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• UDP和TCP能够对来自不同应用程序的数据流进行 复用，并提供校验
• 如果在接收的包中检测到有一个以上的误码，TCP ／UDP层就丢掉这个包，这样上一层(例如RTP)将 不会收到这个损坏的包
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议的特点
– 可扩展性 – 易解析 – 安全 – 独立于传输 – 多服务器支持
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议的特点
– 记录设备控制 – 流控与会议开始分离 – 适合专业应用 – 演示描述便捷 – 代理与防火墙友好 – HTTP友好
• RTCP控制包
– 每个RTCP控制包包括一个固定包头和可变长的数据部分
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTCP的传输间隔
– RTP设计成允许自动扩展状态，连接用户数可 以从几个到上千个，而对于组播，不管连接者 的数目有多少，数据速率是一个定数
– RTCP控制信号流量是应该受控的。如每个参 加者都以固定速率发送接收报告，则控制信号 流量将随参加者数目而线性增长，因此速率必 须根据参加者数目按比例下降，而不是采用固 定速率
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• RTCP提供的服务
– QoS反馈：这是RTCP的首要功能 – 参与者识别：信源可以由RTP包头的SSRC域来识别 – 控制包定标：为了给发送到若干参与者的RTCP控制包定
标 – 媒体间同步：RTCP发信方报告含有实时指示和相应的
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– RTCP包格式
• RTCP包的类型
– SR：发送报告，当前发送者的发送和接收统计 – RR：接收报告，非发送者发出的接收统计 – SDES：源描述项，包括规范名字项CNAME – BYE：表示结束 – APP：特定应用功能
• 多播设置了一个多播组，源节点仅将数据同时传送 至多播组中的节点，数据的拷贝和发送都由网络动 态完成， 最大限度地保证数据占用尽可能少的带宽 资源，这正是符合分布式多媒体多点传输要求
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 可靠性
• 传统的网络传输目标是提供可靠的端到端的通信 • 通信系统采用校验(如CRC校验)及序列编号的方法，
IPTV流媒体传输与控制协议
• RSVP协议
– RSVP协议的作用及要求
• 针对Internet原有传输层协议不能保障QoS和不支持 多点传输的缺点，RSVP在业务流传送之前，预约 一定的网络资源，建立静态或动态的传输逻辑通路， 保障了每一业务流都有足够的“独享”的带宽，克 服了由于网络信包过多引起的拥塞、丢失和重传， 提高了网络传输的QoS性能
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议功能
– RTSP的一个主要功能是支持类拟VCR的控制 操作，如停止、暂停／重新开始、快进和快退
– RTSP还可以提供选择传输通道(例如，UDP、 组播UDP或TCP)的方法以及基于RTP的传输机 制
– 建立和控制在媒体服务器和客户机之间的连续 的音频／视频媒体流
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– RTCP协议概述
• RTCP协议将控制包周期性发送给所有连接者，采 用与RTP数据包相同的分布机制，低层协议提供数 据包与控制包的复用，使用单独的UDP端口号或使 用TCP协议来传输
• 对于RTP会话或者广播，通常使用组播地址，属于 这个会话的所有RTP和RTCP信息包都使用这个组 播地址，通过使用TCP或不同的端口号，可以把 RTP信息包和RTCP信息包区分开来
(UDP不按次序传送数据包)，RTP用序列编号对接收到的 数据包进行正确的排序 – 有效载荷类型识别：包含在RTP包中的有效载荷类型由一 个称为有效载荷类型识别符的RTP包头域来指示 – 信源识别：每一个RTP包的信源由一个称为同步信源识别 符(SSRC)的R rP包头域来指示
第二章IPTV网络部分流媒体的传输 与控制协议5
• 不同通道的同步问题可以通过设置时间戳与开辟回 放缓冲区来解决，这属于端 到端的协调任务
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 多媒体网络的服务质量(QoS)问 题
– 多媒体与网络要解决的核心问题 – 提高服务质量，涉及到网络的底层物理传输模
式、网络协议堆栈的内容与结构、网络应用系 统的相关控制 等多方面的内容，单纯从一个方 面是不能够解决这个问题
RTP时间戳 – 最少话路控制信息：这项可选功能用于传送话路信息，如
参与者的名字
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– RTP对数据传输的封装
• 数据类型PT(pay)oad type) • 时间戳(Time Stamp) • 序列号(SeqNumber) • 标志位M(ma rker) • 同步源标识SSRC(synch ron1 zat1 OnS0Urce)
– 终端的解包和解压缩延时。从回放缓冲区调度出来的数据 包经过解包和解压缩，这段耗时与压缩和打包延时相同， 为30-40ms
– 传输的端到端延时。经过其他阶段的延时，传输的端到端 延时被限制在40ms以内
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议的特点
– 方便的服务器控制 – 传输协调 – 性能协调 – 操作模式多样化
• 单播： 以用户选择的端口号将媒体发送到RTSP请求源 • 组播，服务器选择地址：媒体服务器选择组播地址和端口，这
是现场直播或准点播常用的方式 • 组播，用户选择地址：如服务器加入正在进行的组播会议，组
• 多媒体数据流对带宽的需求还表现出单向的特性， 这是因为多媒体应用多为非对称的结构，即往往是 从发送方传送大量的数据流给接收方，而反向的传 输量则很小
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 对交互的分布式多媒体应用而言，比带宽更加难以 处理的是传输延迟问题。传输延迟的一个表现形式 是端到端延迟(end—to—end delay)
• RTSP，RTSP为实时流协议，也可以说是话路控制协议，支 持如像VCR那样的操作控制，如暂停、快进、快退等。RTSP 也通过UDP来传输
• RSVP，RSVP协议为资源预留协议，属传输层范围的协议， 对沿路由的路由器提出控制带宽(预留)的要求，以保证某些信 号带宽稳定的需求
第二章IPTV网络部分流媒体的传输 与控制协议5
• TCP重传所引入的延迟对于具有严格延迟要求的流 应用来说是不可接受的，因此一般用UDP作为视频 流传输协议
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• 由于UDP不能保证包的传输，所以接收端必须依靠 上一层协议(即RTP)来检测包的丢失。RTP是一个因 特网标准协议，用于提供端对端的传输功能，以便 支持实时应用
• ATM差 错检验工作都交给端点去完成，交换节点的惟一工作 就是传送信包，因此端到端延时最小
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 支持组播模式
• 分布式多媒体应用系统要求网络支持多播的通信模 式，这尤其体现在多点视频会议系统中
• 由于单播与广播的局限性，在实践中产生组播的概 念
播地址、端口和密匙由会议描述给出
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议参数
– 版本 – RTSP URL – 会话标识 – 连接标识 – SMPTE 时标 – 正常播放时间 – 绝对时间 – 可选标签
第二章IPTV网络部分流媒体的传输 与控制协议5
进行差错检验；采用反向应答、信包重传的握手协 议进行差错恢复 • 系统有必要把差错检验和差错恢复工作交给上层完 成，下层网络只需为上层提供反映物理传 输特性的 服务
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 通道同步
• 视频流、音频流及其他数据流从不同的传输通路， 经由不同的路由到达终端节点时，有必要采取一定 的机制实现异种数据流之间的同步问题，这称为通 道同步问 题
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议
– RTSP交互原理
• RTSP为流音频和视频提供的服务与HTTP(超文本传 输协议)为文本和图形所提供的服务相同
• RTSP中，每一个演示和媒体流都被一个RTSP URL(通用资源定位器)所识别
• RTSP用于从媒体服务器启动和直接传送流媒体数 据
• RTCP是为了向RTP话路的参与者提供QoS反馈
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• RTCP并不保证QoS或可靠性传输，结合RTP提供 以下支持媒体流的功能
– 时间戳：RTP提供时间标记，用于不同媒体流之间的同步 – 序列编号：由于到达接收端的数据包可能是不按次序的
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 旧的互联网的特点，数据量小，实时性低，带 宽低，可靠性差
– 新的多媒体业务流需求必须适应多媒体业务流 传输
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 高带宽和高压缩率
• 即使是传输压缩数据，对带宽的要求还是很大的， MPEG-1的带宽要求是1.5Mbps，MPEG-2则为1.540Mbps；为了在更窄的频带上传输实时高清信息， 则要求采用更高的视频压缩编码技术，如MPEG一4 或ASF等压缩方案，H264至少要8Mbps
– 低传输延迟
• 端到端延时包括线路延时和网络中路由器、网关等逻辑部分的 处理与存储转发的延时。前者无法减少。解决端到端延迟的核 心环节是如何降低路由器等器件的处理与存储转发延时
• 分组交换在网络中间的每个节点上都进行差错检验，如果出现 差错，则进行重传，因此端到端延时较大
• 帧中继只做差错检验，如果出现差错，则丢弃信包，而数据重 传等恢复工作交给端点完成，这样在一般情况下，端到端延时 较小
• 多媒体视频会议的实践和ITU的建议将交互式视频应 用的端到端延迟限制在150ms以内
• 传输延迟的另一个表现形式是传输抖动(jitter)。抖动 是传输中各个分组的不同传送时间和错序造成的
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体ຫໍສະໝຸດ Baidu网络传输特征
– 低传输延迟
• 根据150ms的传输延迟限制，整个传输分为4部分
– 源端点的压缩和打包延时。由于视频源必须处理每秒2530帧的视频，那么实时压缩解压缩的处理能力必须达到 30-40ms以内。这是网络延时中较小的一部分。
– 终端排队和等时延时。数据包排队进入终端以后，进入回 放缓冲区，直到调度出缓冲区，这段延时也是40ms左右
第二章IPTV网络部分流 媒体的传输与控制协议5
2020/12/9
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体传输和控制协议概述
– 流媒体基础网络协议
• TCP、UDP(传输层) • IP协议(互联网层)
– 流媒体传输协议
• RTP、RTCP，RTP为实时传输协议，通过UDP协议传输。 RTCP为实时传输控制协议，可以通过TCP协议传输，也可以 通过UDP协议传输，但与RTP采用不同的端口号，加以分离
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• UDP和TCP能够对来自不同应用程序的数据流进行 复用，并提供校验
• 如果在接收的包中检测到有一个以上的误码，TCP ／UDP层就丢掉这个包，这样上一层(例如RTP)将 不会收到这个损坏的包
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议的特点
– 可扩展性 – 易解析 – 安全 – 独立于传输 – 多服务器支持
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议的特点
– 记录设备控制 – 流控与会议开始分离 – 适合专业应用 – 演示描述便捷 – 代理与防火墙友好 – HTTP友好
• RTCP控制包
– 每个RTCP控制包包括一个固定包头和可变长的数据部分
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTCP的传输间隔
– RTP设计成允许自动扩展状态，连接用户数可 以从几个到上千个，而对于组播，不管连接者 的数目有多少，数据速率是一个定数
– RTCP控制信号流量是应该受控的。如每个参 加者都以固定速率发送接收报告，则控制信号 流量将随参加者数目而线性增长，因此速率必 须根据参加者数目按比例下降，而不是采用固 定速率
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• RTCP提供的服务
– QoS反馈：这是RTCP的首要功能 – 参与者识别：信源可以由RTP包头的SSRC域来识别 – 控制包定标：为了给发送到若干参与者的RTCP控制包定
标 – 媒体间同步：RTCP发信方报告含有实时指示和相应的
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– RTCP包格式
• RTCP包的类型
– SR：发送报告，当前发送者的发送和接收统计 – RR：接收报告，非发送者发出的接收统计 – SDES：源描述项，包括规范名字项CNAME – BYE：表示结束 – APP：特定应用功能
• 多播设置了一个多播组，源节点仅将数据同时传送 至多播组中的节点，数据的拷贝和发送都由网络动 态完成， 最大限度地保证数据占用尽可能少的带宽 资源，这正是符合分布式多媒体多点传输要求
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 可靠性
• 传统的网络传输目标是提供可靠的端到端的通信 • 通信系统采用校验(如CRC校验)及序列编号的方法，
IPTV流媒体传输与控制协议
• RSVP协议
– RSVP协议的作用及要求
• 针对Internet原有传输层协议不能保障QoS和不支持 多点传输的缺点，RSVP在业务流传送之前，预约 一定的网络资源，建立静态或动态的传输逻辑通路， 保障了每一业务流都有足够的“独享”的带宽，克 服了由于网络信包过多引起的拥塞、丢失和重传， 提高了网络传输的QoS性能
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议功能
– RTSP的一个主要功能是支持类拟VCR的控制 操作，如停止、暂停／重新开始、快进和快退
– RTSP还可以提供选择传输通道(例如，UDP、 组播UDP或TCP)的方法以及基于RTP的传输机 制
– 建立和控制在媒体服务器和客户机之间的连续 的音频／视频媒体流
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– RTCP协议概述
• RTCP协议将控制包周期性发送给所有连接者，采 用与RTP数据包相同的分布机制，低层协议提供数 据包与控制包的复用，使用单独的UDP端口号或使 用TCP协议来传输
• 对于RTP会话或者广播，通常使用组播地址，属于 这个会话的所有RTP和RTCP信息包都使用这个组 播地址，通过使用TCP或不同的端口号，可以把 RTP信息包和RTCP信息包区分开来
(UDP不按次序传送数据包)，RTP用序列编号对接收到的 数据包进行正确的排序 – 有效载荷类型识别：包含在RTP包中的有效载荷类型由一 个称为有效载荷类型识别符的RTP包头域来指示 – 信源识别：每一个RTP包的信源由一个称为同步信源识别 符(SSRC)的R rP包头域来指示
第二章IPTV网络部分流媒体的传输 与控制协议5
• 不同通道的同步问题可以通过设置时间戳与开辟回 放缓冲区来解决，这属于端 到端的协调任务
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 多媒体网络的服务质量(QoS)问 题
– 多媒体与网络要解决的核心问题 – 提高服务质量，涉及到网络的底层物理传输模
式、网络协议堆栈的内容与结构、网络应用系 统的相关控制 等多方面的内容，单纯从一个方 面是不能够解决这个问题
RTP时间戳 – 最少话路控制信息：这项可选功能用于传送话路信息，如
参与者的名字
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– RTP对数据传输的封装
• 数据类型PT(pay)oad type) • 时间戳(Time Stamp) • 序列号(SeqNumber) • 标志位M(ma rker) • 同步源标识SSRC(synch ron1 zat1 OnS0Urce)
– 终端的解包和解压缩延时。从回放缓冲区调度出来的数据 包经过解包和解压缩，这段耗时与压缩和打包延时相同， 为30-40ms
– 传输的端到端延时。经过其他阶段的延时，传输的端到端 延时被限制在40ms以内
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议的特点
– 方便的服务器控制 – 传输协调 – 性能协调 – 操作模式多样化
• 单播： 以用户选择的端口号将媒体发送到RTSP请求源 • 组播，服务器选择地址：媒体服务器选择组播地址和端口，这
是现场直播或准点播常用的方式 • 组播，用户选择地址：如服务器加入正在进行的组播会议，组
• 多媒体数据流对带宽的需求还表现出单向的特性， 这是因为多媒体应用多为非对称的结构，即往往是 从发送方传送大量的数据流给接收方，而反向的传 输量则很小
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 对交互的分布式多媒体应用而言，比带宽更加难以 处理的是传输延迟问题。传输延迟的一个表现形式 是端到端延迟(end—to—end delay)
• RTSP，RTSP为实时流协议，也可以说是话路控制协议，支 持如像VCR那样的操作控制，如暂停、快进、快退等。RTSP 也通过UDP来传输
• RSVP，RSVP协议为资源预留协议，属传输层范围的协议， 对沿路由的路由器提出控制带宽(预留)的要求，以保证某些信 号带宽稳定的需求
第二章IPTV网络部分流媒体的传输 与控制协议5
• TCP重传所引入的延迟对于具有严格延迟要求的流 应用来说是不可接受的，因此一般用UDP作为视频 流传输协议
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• 由于UDP不能保证包的传输，所以接收端必须依靠 上一层协议(即RTP)来检测包的丢失。RTP是一个因 特网标准协议，用于提供端对端的传输功能，以便 支持实时应用
• ATM差 错检验工作都交给端点去完成，交换节点的惟一工作 就是传送信包，因此端到端延时最小
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 支持组播模式
• 分布式多媒体应用系统要求网络支持多播的通信模 式，这尤其体现在多点视频会议系统中
• 由于单播与广播的局限性，在实践中产生组播的概 念
播地址、端口和密匙由会议描述给出
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议参数
– 版本 – RTSP URL – 会话标识 – 连接标识 – SMPTE 时标 – 正常播放时间 – 绝对时间 – 可选标签
第二章IPTV网络部分流媒体的传输 与控制协议5
进行差错检验；采用反向应答、信包重传的握手协 议进行差错恢复 • 系统有必要把差错检验和差错恢复工作交给上层完 成，下层网络只需为上层提供反映物理传 输特性的 服务
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 通道同步
• 视频流、音频流及其他数据流从不同的传输通路， 经由不同的路由到达终端节点时，有必要采取一定 的机制实现异种数据流之间的同步问题，这称为通 道同步问 题
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTSP协议
– RTSP交互原理
• RTSP为流音频和视频提供的服务与HTTP(超文本传 输协议)为文本和图形所提供的服务相同
• RTSP中，每一个演示和媒体流都被一个RTSP URL(通用资源定位器)所识别
• RTSP用于从媒体服务器启动和直接传送流媒体数 据
• RTCP是为了向RTP话路的参与者提供QoS反馈
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• RTCP并不保证QoS或可靠性传输，结合RTP提供 以下支持媒体流的功能
– 时间戳：RTP提供时间标记，用于不同媒体流之间的同步 – 序列编号：由于到达接收端的数据包可能是不按次序的
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 旧的互联网的特点，数据量小，实时性低，带 宽低，可靠性差
– 新的多媒体业务流需求必须适应多媒体业务流 传输
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 高带宽和高压缩率
• 即使是传输压缩数据，对带宽的要求还是很大的， MPEG-1的带宽要求是1.5Mbps，MPEG-2则为1.540Mbps；为了在更窄的频带上传输实时高清信息， 则要求采用更高的视频压缩编码技术，如MPEG一4 或ASF等压缩方案，H264至少要8Mbps
– 低传输延迟
• 端到端延时包括线路延时和网络中路由器、网关等逻辑部分的 处理与存储转发的延时。前者无法减少。解决端到端延迟的核 心环节是如何降低路由器等器件的处理与存储转发延时
• 分组交换在网络中间的每个节点上都进行差错检验，如果出现 差错，则进行重传，因此端到端延时较大
• 帧中继只做差错检验，如果出现差错，则丢弃信包，而数据重 传等恢复工作交给端点完成，这样在一般情况下，端到端延时 较小
• 多媒体视频会议的实践和ITU的建议将交互式视频应 用的端到端延迟限制在150ms以内
• 传输延迟的另一个表现形式是传输抖动(jitter)。抖动 是传输中各个分组的不同传送时间和错序造成的
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体ຫໍສະໝຸດ Baidu网络传输特征
– 低传输延迟
• 根据150ms的传输延迟限制，整个传输分为4部分
– 源端点的压缩和打包延时。由于视频源必须处理每秒2530帧的视频，那么实时压缩解压缩的处理能力必须达到 30-40ms以内。这是网络延时中较小的一部分。
– 终端排队和等时延时。数据包排队进入终端以后，进入回 放缓冲区，直到调度出缓冲区，这段延时也是40ms左右
第二章IPTV网络部分流 媒体的传输与控制协议5
2020/12/9
第二章IPTV网络部分流媒体的传输 与控制协议5
IPTV流媒体传输与控制协议
• 流媒体传输和控制协议概述
– 流媒体基础网络协议
• TCP、UDP(传输层) • IP协议(互联网层)
– 流媒体传输协议
• RTP、RTCP，RTP为实时传输协议，通过UDP协议传输。 RTCP为实时传输控制协议，可以通过TCP协议传输，也可以 通过UDP协议传输，但与RTP采用不同的端口号，加以分离