流媒体传输和控制协议概述
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 流媒体的网络传输特征
– 旧的互联网的特点，数据量小，实时性低，带 宽低，可靠性差
– 新的多媒体业务流需求必须适应多媒体业务流 传输
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 高带宽和高压缩率
• 即使是传输压缩数据，对带宽的要求还是很大的， MPEG-1的带宽要求是1.5Mbps，MPEG-2则为1.540Mbps；为了在更窄的频带上传输实时高清信息， 则要求采用更高的视频压缩编码技术，如MPEG一4 或ASF等压缩方案，H264至少要8Mbps
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• 由于UDP不能保证包的传输，所以接收端必须依靠 上一层协议(即RTP)来检测包的丢失。RTP是一个 因特网标准协议，用于提供端对端的传输功能，以 便支持实时应用
• RTCP是为了向RTP话路的参与者提供QoS反馈
IPTV流媒体传输与控制协议
– 功能描述
• UDP和TCP能够对来自不同应用程序的数据流进行 复用，并提供校验
• 如果在接收的包中检测到有一个以上的误码，TCP ／UDP层就丢掉这个包，这样上一层(例如RTP)将 不会收到这个损坏的包
• TCP重传所引入的延迟对于具有严格延迟要求的流 应用来说是不可接受的，因此一般用UDP作为视频 流传输协议
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 通道同步
• 视频流、音频流及其他数据流从不同的传输通路， 经由不同的路由到达终端节点时，有必要采取一定 的机制实现异种数据流之间的同步问题，这称为通 道同步问 题
• 不同通道的同步问题可以通过设置时间戳与开辟回 放缓冲区来解决，这属于端 到端的协调任务
IPTV流媒体传输与控制协议
• 多媒体网络的服务质量(QoS)问 题
– 多媒体与网络要解决的核心问题 – 提高服务质量，涉及到网络的底层物理传输模
式、网络协议堆栈的内容与结构、网络应用系 统的相关控制 等多方面的内容，单纯从一个方 面是不能够解决这个问题
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
IPTV
---网络部分-流媒体传输和控制协议
IPTV流媒体传输与控制协议
• 流媒体传输和控制协议概述
– 流媒体基础网络协议
• TCP、UDP(传输层) • IP协议(互联网层)
– 流媒体传输协议
• RTP、RTCP，RTP为实时传输协议，通过UDP协议传输。 RTCP为实时传输控制协议，可以通过TCP协议传输，也可以 通过UDP协议传输，但与RTP采用不同的端口号，加以分离
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 支持组播模式
• 分布式多媒体应用系统要求网络支持多播的通信模 式，这尤其体现在多点视频会议系统中
• 由于单播与广播的局限性，在实践中产生组播的概 念
• 多播设置了一个多播组，源节点仅将数据同时传送 至多播组中的节点，数据的拷贝和发送都由网络动 态完成， 最大限度地保证数据占用尽可能少的带宽 资源，这正是符合分布式多媒体多点传输要求
• 多媒体视频会议的实践和ITU的建议将交互式视频应 用的端到端延迟限制在150ms以内
• 传输延迟的另一个表现形式是传输抖动(jitter)。抖动 是传输中各个分组的不同传送时间和错序造成的
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 根据150ms的传输延迟限制，整个传输分为4部分
• RTSP，RTSP为实时流协议，也可以说是话路控制协议，支 持如像VCR那样的操作控制，如暂停、快进、快退等。RTSP 也通过UDP来传输
• RSVP，RSVP协议为资源预留协议，属传输层范围的协议， 对沿路由的路由器提出控制带宽(预留)的要求，以保证某些信 号带宽稳定的需求
IPTV流媒体传输与控制协议
– 源端点的压缩和打包延时。由于视频源必须处理每秒2530帧的视频，那么实时压缩解压缩的处理能力必须达到 30-40ms以内。这是网络延时中较小的一部分。
– 终端排队和等时延时。数据包排队进入终端以后，进入回 放缓冲区，直到调度出缓冲区，这段延时也是40ms左右
– 终端的解包和解压缩延时。从回放缓冲区调度出来的数据 包经过解包和解压缩，这段耗时与压缩和打包延时相同， 为30-40ms
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 可靠性
• 传统的网络传输目标是提供可靠的端到端的通信 • 通信系统采用校验(如CRC校验)及序列编号的方法，
进行差错检验；采用反向应答、信包重传的握手协 议进行差错恢复 • 系统有必要把差错检验和差错恢复工作交给上层完 成，下层网络只需为上层提供反映物理传 输特性的 服务
• 多媒体数据流对带宽的需求还表现出单向的特性， 这是因为多媒体应用多为非对称的结构，即往往是 从发送方传送大量的数据流给接收方，而反向的传 输量则很小
ห้องสมุดไป่ตู้
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 对交互的分布式多媒体应用而言，比带宽更加难以 处理的是传输延迟问题。传输延迟的一个表现形式 是端到端延迟(end—to—end delay)
– 传输的端到端延时。经过其他阶段的延时，传输的端到端 延时被限制在40ms以内
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 端到端延时包括线路延时和网络中路由器、网关等逻辑部分的 处理与存储转发的延时。前者无法减少。解决端到端延迟的核 心环节是如何降低路由器等器件的处理与存储转发延时
• RTP／RTCP协议族概述
– 功能描述
• RTCP并不保证QoS或可靠性传输，结合RTP提供 以下支持媒体流的功能
– 时间戳：RTP提供时间标记，用于不同媒体流之间的同步 – 序列编号：由于到达接收端的数据包可能是不按次序的
• 分组交换在网络中间的每个节点上都进行差错检验，如果出现 差错，则进行重传，因此端到端延时较大
• 帧中继只做差错检验，如果出现差错，则丢弃信包，而数据重 传等恢复工作交给端点完成，这样在一般情况下，端到端延时 较小
• ATM差 错检验工作都交给端点去完成，交换节点的惟一工作 就是传送信包，因此端到端延时最小
– 旧的互联网的特点，数据量小，实时性低，带 宽低，可靠性差
– 新的多媒体业务流需求必须适应多媒体业务流 传输
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 高带宽和高压缩率
• 即使是传输压缩数据，对带宽的要求还是很大的， MPEG-1的带宽要求是1.5Mbps，MPEG-2则为1.540Mbps；为了在更窄的频带上传输实时高清信息， 则要求采用更高的视频压缩编码技术，如MPEG一4 或ASF等压缩方案，H264至少要8Mbps
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
– 功能描述
• 由于UDP不能保证包的传输，所以接收端必须依靠 上一层协议(即RTP)来检测包的丢失。RTP是一个 因特网标准协议，用于提供端对端的传输功能，以 便支持实时应用
• RTCP是为了向RTP话路的参与者提供QoS反馈
IPTV流媒体传输与控制协议
– 功能描述
• UDP和TCP能够对来自不同应用程序的数据流进行 复用，并提供校验
• 如果在接收的包中检测到有一个以上的误码，TCP ／UDP层就丢掉这个包，这样上一层(例如RTP)将 不会收到这个损坏的包
• TCP重传所引入的延迟对于具有严格延迟要求的流 应用来说是不可接受的，因此一般用UDP作为视频 流传输协议
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 通道同步
• 视频流、音频流及其他数据流从不同的传输通路， 经由不同的路由到达终端节点时，有必要采取一定 的机制实现异种数据流之间的同步问题，这称为通 道同步问 题
• 不同通道的同步问题可以通过设置时间戳与开辟回 放缓冲区来解决，这属于端 到端的协调任务
IPTV流媒体传输与控制协议
• 多媒体网络的服务质量(QoS)问 题
– 多媒体与网络要解决的核心问题 – 提高服务质量，涉及到网络的底层物理传输模
式、网络协议堆栈的内容与结构、网络应用系 统的相关控制 等多方面的内容，单纯从一个方 面是不能够解决这个问题
IPTV流媒体传输与控制协议
• RTP／RTCP协议族概述
IPTV
---网络部分-流媒体传输和控制协议
IPTV流媒体传输与控制协议
• 流媒体传输和控制协议概述
– 流媒体基础网络协议
• TCP、UDP(传输层) • IP协议(互联网层)
– 流媒体传输协议
• RTP、RTCP，RTP为实时传输协议，通过UDP协议传输。 RTCP为实时传输控制协议，可以通过TCP协议传输，也可以 通过UDP协议传输，但与RTP采用不同的端口号，加以分离
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 支持组播模式
• 分布式多媒体应用系统要求网络支持多播的通信模 式，这尤其体现在多点视频会议系统中
• 由于单播与广播的局限性，在实践中产生组播的概 念
• 多播设置了一个多播组，源节点仅将数据同时传送 至多播组中的节点，数据的拷贝和发送都由网络动 态完成， 最大限度地保证数据占用尽可能少的带宽 资源，这正是符合分布式多媒体多点传输要求
• 多媒体视频会议的实践和ITU的建议将交互式视频应 用的端到端延迟限制在150ms以内
• 传输延迟的另一个表现形式是传输抖动(jitter)。抖动 是传输中各个分组的不同传送时间和错序造成的
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 根据150ms的传输延迟限制，整个传输分为4部分
• RTSP，RTSP为实时流协议，也可以说是话路控制协议，支 持如像VCR那样的操作控制，如暂停、快进、快退等。RTSP 也通过UDP来传输
• RSVP，RSVP协议为资源预留协议，属传输层范围的协议， 对沿路由的路由器提出控制带宽(预留)的要求，以保证某些信 号带宽稳定的需求
IPTV流媒体传输与控制协议
– 源端点的压缩和打包延时。由于视频源必须处理每秒2530帧的视频，那么实时压缩解压缩的处理能力必须达到 30-40ms以内。这是网络延时中较小的一部分。
– 终端排队和等时延时。数据包排队进入终端以后，进入回 放缓冲区，直到调度出缓冲区，这段延时也是40ms左右
– 终端的解包和解压缩延时。从回放缓冲区调度出来的数据 包经过解包和解压缩，这段耗时与压缩和打包延时相同， 为30-40ms
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 可靠性
• 传统的网络传输目标是提供可靠的端到端的通信 • 通信系统采用校验(如CRC校验)及序列编号的方法，
进行差错检验；采用反向应答、信包重传的握手协 议进行差错恢复 • 系统有必要把差错检验和差错恢复工作交给上层完 成，下层网络只需为上层提供反映物理传 输特性的 服务
• 多媒体数据流对带宽的需求还表现出单向的特性， 这是因为多媒体应用多为非对称的结构，即往往是 从发送方传送大量的数据流给接收方，而反向的传 输量则很小
ห้องสมุดไป่ตู้
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 对交互的分布式多媒体应用而言，比带宽更加难以 处理的是传输延迟问题。传输延迟的一个表现形式 是端到端延迟(end—to—end delay)
– 传输的端到端延时。经过其他阶段的延时，传输的端到端 延时被限制在40ms以内
IPTV流媒体传输与控制协议
• 流媒体的网络传输特征
– 低传输延迟
• 端到端延时包括线路延时和网络中路由器、网关等逻辑部分的 处理与存储转发的延时。前者无法减少。解决端到端延迟的核 心环节是如何降低路由器等器件的处理与存储转发延时
• RTP／RTCP协议族概述
– 功能描述
• RTCP并不保证QoS或可靠性传输，结合RTP提供 以下支持媒体流的功能
– 时间戳：RTP提供时间标记，用于不同媒体流之间的同步 – 序列编号：由于到达接收端的数据包可能是不按次序的
• 分组交换在网络中间的每个节点上都进行差错检验，如果出现 差错，则进行重传，因此端到端延时较大
• 帧中继只做差错检验，如果出现差错，则丢弃信包，而数据重 传等恢复工作交给端点完成，这样在一般情况下，端到端延时 较小
• ATM差 错检验工作都交给端点去完成，交换节点的惟一工作 就是传送信包，因此端到端延时最小