多媒体应用分类.pptVIP

6 因特网的多媒体应用 基本特性： 对端到端的延迟、延迟变动十分敏感 可以容忍部分数据的丢失 （ loss tolerant ） 和数据传输相反 多媒体也被称为“连续媒体” 多媒体应用分类: 流媒体，储存式音频和视频 （Streaming stored audio and video） 实况音频和视频流 （Streaming live audio and video） 实时交互式的音频和视频 （Real-time interactive video） Streaming stored MM 客户端从服务器请求其所存储的压缩的音频和视频文件 交互性：用户可以进行控制操作 (类似于VCR: pause, resume, fast forward, rewind, etc.) 延迟: 从客户请求发出到开始显示经历1到10秒 Unidirectional Real-Time: 除了是在因特网上传播之外，这种分类与传统的无线广播和电视中的实况转播是一样的 不能交互，只能听或者看 Interactive Real-Time : 电话或者视频会议 对延迟的要求更加严格 Video: 150 msec acceptable Audio: 150 msec good, 400 msec acceptable 因特网的多媒体应用挑战 TCP/UDP/IP提供的服务是所谓“力尽所能的服务(best-effort service)” ，对其传输过程中所产生的延迟不作任何承诺 。 存储式流媒体的用户交互延迟时间一般为5-10秒，但在尖峰时间和跨越拥挤的链路（如拥挤的越洋链路）时，情况就不是那么令人满意 Real-Time Interactive 应用 对对数据分组的延迟和延迟时间变动（也称分组抖动（packet jitter））十分苛刻 如果因特网像铁路交通那样，有特快、直快分出等级，那么多媒体应用程序的设计就可以简单的多 . 但是在Internet,所有的数据报都一律平等 现在正在努力提供有差别服务 Streaming Stored Audio Video Streaming stored media: Audio/video 文件存储在服务器 用户请求audio/video文件 Audio/video 被传送给用户 允许交互 Media player: 去除抖动 解压缩 错误检测 提供交互的图形界面 可以嵌入到浏览器中 Streaming from Web server (1) Audio and video 文件存储在Web servers “天真的方法”： 浏览器用HTTP 请求消息请求文件 Web server通过HTTP响应消息发送文件 content-type header line 指示audio/video编码类型 浏览器加载media player, 并且将文件递交给media player media player 播放文件 主要缺点: media player和server交互需要Web browser的中介 另外的方法: 在server和player之间建立连接 Web 浏览器请求并接收 一个元文件（meta file） 而不是接收文件本身； Content-type header 指示特定的audio/video应用类型 浏览器加载media player 并且把元文件递交给它 Player和server建立 TCP连接，发出HTTP 请求 Some concerns: Media player 的通信是通过HTTP协议，而它并不适宜多媒体交互 可以用UDP传输媒体 Streaming from Web server (2) Streaming from a streaming server 这种结构允许server和media player采用非HTTP协议 可以使用TCP/UDP