音频-视频服务总结.docxVIP

音频-视频服务总结 多媒体信息的特征：存在时延和时延抖动，设置缓存，降低时延抖动，不免增加时延 多媒体的信息量往往很大 在传输多媒体数据时，对时延和时延抖动均有较高的要求 边传输边播放 传统的互联网本身是非等时的 设置适当大小的缓存 流式存储音频/视频：边下载边播放 元文件：指明其他文件的一些重要信息 “存储”：不是实时产生的，而是已经录制好的，通常存储在光盘或硬盘中 整个下载过程会花费很长的时间 需要使用单独的应用程序来播放这种音频节目，称为媒体播放器（流式服务器） 媒体播放器的主要功能：管理用户界面，解压缩，消除时延抖动 和处理传输带来的差错 流式实况音频/视频：边录制边发送 这种方式的广播是通过互联网来传送的 一对多的通信 边录制边发送 交互式音频/视频：实时交互式通信 IP电话网关（公用电话网与IP网络的接口设备）：作用：电话信令转换；语音编码的转换 IP电话的通话质量由两个因素决定 通话双方端到端的时延和时延抖动 欢迎分组的丢失率 这两个因素都是不确定的，而是取决于当时网络上的通信量，因此，一个用户使用IP电话的通话质量取决于当时其他许多用户的行为 IP电话端到端时延是由以下几个因素造成的 话音信号进行模数转换要产生时延 已经数字化的话音比特流要积累到一定的数量，才能装配成一个话音分组，这也会产生实验 话音分组的发送需要时间，此时间等于话音长度与通信线路的数据率之比 话音分组在互联网中经过许多路由器存储转发时延 话音分组到达接收端，在缓存中暂存所引起的时延 将话音分组还原成模拟话音信号的模数转换，也要产生一定的时延 话音信号在通信线路上的传播时延 由终端设备的硬件和操作系统产生的接入时延 IP电话应用协议 信令协议 H.323 已有电路交换网，增加IP电话功能 不是一个单独的协议，而是一组协议 系统和构件的描述，呼叫模型的描述，呼叫信令过程控制，报文复用，话音编解码器，视觉编解码器以及数据协议等 四个构件 H.323终端，网关，网匣，多点控制单元MCU 会话发起协议SIP 地址十分灵活 可以是电话号码、电子邮件地址、IP地址等 建立会话、通信、终止会话 基于报文的协议 只涉及IP电话所需的信令和有关服务质量的问题 构件 用户代理（包括用户代理客户和用户代理服务器） 网络服务器（包括代理服务器和重定向服务器） 使用文本方式的客户服务器协议 传送协议 RTP实时运输协议 为实时应用提供端到端的运输，但不提供服务质量保证 RTCP实施运输控制协议 功能 服务质量的监视与反馈 多播组中成员的标志 媒体间的同步 RTCP并不对音频/视频分组进行封装 五类分组 发送端报告分组SR：周期性向所有接收端用多播方式进行报告 接收端报告分组RR：接收端周期性的向所有的点多播方式进行报告 源点描述分组SDES：给出会话参与者描述 结束分组BYE：关闭一个数据流 特定应用分组APP：使应用程序能够定义新的分组 这两个协议配套使用不可分割 实时运输协议RTP 为实时应用提供端到端的运输，但不提供服务质量保证 不对媒体数据做任何处理，只向应用层提供一些附加信息，让应用层知道如何处理 运行过程 多媒体数据块压缩编码 送给RTP封装成为RTP分组 装入运输层的UDP用户数据报，交给IP层 序号、时间戳 序号：发现丢失，重新按序排列 时间戳：反应第一个字节的采样时刻，按时间还原数据块，消除时延抖动，音频同步 实时流式协议RTSP 又称为“互联网录像机遥控协议” 概述 客户服务器方式，应用层的多媒体播放控制协议，UDP 用来使用户播放从互联网下载的实时数据能够进行控制 本身并不传输数据，是使媒体播放器能够控制多媒体流的传送 RTSP控制分组既可以在TCP上传送，也可以在UDP上传送 HTTP是无状态的，而RTSP是有状态的协议 记录客户机所处的状态：初始化状态，播放状态或暂停状态 不规定音频/视频流在媒体播放器中应如何缓存 功能 服务质量的检测与反馈 媒体间的同步 多播组中成员的标志 服务质量QoS 四种机制：分类，管制，调度，呼叫接纳 调度机制 默认先进先出FIFO 缺点：不能区分时间敏感分组和一般数据分组 按优先级排队 使优先级高的分组优先得到服务 缺点：高级优先级队列中总是有分组时，低级优先级队列中的分组就长期得不到服务 公平排队FQ 对每种类别的分组流设置一个队列，然后轮流使每一个队列一次只能发送一个分组 缺点：长分组得到的服务时间长，而短分组就比较吃亏，并且公平排队并没有区分分组的优先级 加权公平排队WFQ 分组到达后就进行分类，然后送交与其类别相应的队列，根据各类别的优先级不同，每种队列分配到的服务时间也不同 管制机制 平均速度 网络需要控制一个数据流的平均速率，这里的平均速率是指一定的时间间隔内通过的分组数 峰值速度 限制了数据流在非