zoukankan      html  css  js  c++  java
  • 一些关于流媒体的基本概念

    目录 [hide]

    ASF

    ASF是(Advanced Streaming Format 高级串流格式)的缩写,是 Microsoft 为 Windows 98 所开发的串流多媒体文件格式。ASF是微软公司Windows Media的核心。这是一种包含音频、视频、图像以及控制命令脚本的数据格式。这个词汇当前可和 WMA 及 WMV 互换使用。
    ASF是一个开放标准,它能依靠多种协议在多种网络环境下支持数据的传送。同JPG、MPG文件一样,ASF文件也是一种文件类型,但它是专为在IP网上传送有同步关系的多媒体数据而设计的,所以ASF格式的信息特别适合在IP网上传输。ASF文件的内容既可以是我们熟悉的普通文件,也可以是一个由编码设备实时生成的连续的数据流,所以ASF既可以传送人们事先录制好的节目,也可以传送实时产生的节目。
    ASF用于排列、组织、同步多媒体数据以利于通过网络传输。ASF是一种数据格式,它也可用于指定实况演示。ASF最适于通过网络发送多媒体流,也同样适于在本地播放。任何压缩/解压缩运算法则(编解码器)都可用来编码ASF流。
    Windows Media Service的核心是ASF。ASF是一种数据格式,音频、视频、图像以及控制命令脚本等多媒体信息通过这种格式,以网络数据包的形式传输,实现流式多媒体内容发布。其中,在网络上传输的内容就称为ASF Stream。ASF支持任意的压缩/解压缩编码方式,并可以使用任何一种底层网络传输协议,具有很大的灵活性。
    Microsoft Media player是能播放几乎所有多媒体文件的播放器,支持ASF在Internet网上的流文件格式,可以一边下载一边实时播放,无需下载完再听。
    ASF流文件的数据速率可以在28.8Kbps到3Mbps之间变化。用户可以根据自己应用环境和网络条件选择一个合适的速率,实现VOD点播和直播。

    FLV

    FLV 是FLASH VIDEO的简称,FLV流媒体格式是随着Flash MX的推出发展而来的视频格式。由于它形成的文件极小、加载速度极快,使得网络观看视频文件成为可能,它的出现有效地解决了视频文件导入Flash后,使导出的SWF文件体积庞大,不能在网络上很好的使用等缺点。
    FLV是被众多新一代视频分享网站所采用,是目前增长最快、最为广泛的视频传播格式。是在sorenson公司的压缩算法的基础上开发出来的。FLV格式不仅可以轻松的导入Flash中,速度极快,并且能起到保护版权的作用,并且可以不通过本地的微软或者REAL播放器播放视频。

    H264

    H.264,同时也是MPEG-4第十部分,是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT,Joint Video Team)提出的高度压缩数字视频编解码器标准。H.264是ITU-T以H.26x系列为名称命名的标准之一,同时AVC是ISO/IEC MPEG一方的称呼。这个标准通常被称之为H.264/AVC(或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC)而明确的说明它两方面的开发者。该标准最早来自于ITU-T的称之为H.26L的项目的开发。H.26L这个名称虽然不太常见,但是一直被使用着。该标准第一版的最终草案于2003年5月完成。
    H.264是国际标准化组织(ISO)和国际电信联盟(ITU)共同提出的继MPEG4之后的新一代数字视频压缩格式,它既保留了以往压缩技术的优点和精华又具有其他压缩技术无法比拟的许多优点。
    1.低码率(Low Bit Rate):和MPEG2和MPEG4 ASP等压缩技术相比,在同等图像质量下,采用H.264技术压缩后的数据量只有MPEG2的1/8,MPEG4的1/3。
    显然,H.264压缩技术的采用将大大节省用户的下载时间和数据流量收费。
    2.高质量的图象:H.264能提供连续、流畅的高质量图象(DVD质量)。
    3.容错能力强:H.264提供了解决在不稳定网络环境下容易发生的丢包等错误的必要工具。
    4.网络适应性强:H.264提供了网络抽象层(Network Abstraction Layer),使得H.264的文件能容易地在不同网络上传输(例如互联网,CDMA,GPRS,WCDMA,CDMA2000等)。
    H.264最大的优势是具有很高的数据压缩比率,在同等图像质量的条件下,H.264的压缩比是MPEG-2的2倍以上,是MPEG-4的1.5~2倍。举个例子,原始文件的大小如果为88GB,采用MPEG-2压缩标准压缩后变成3.5GB,压缩比为25∶1,而采用H.264压缩标准压缩后变为879MB,从88GB到879MB,H.264的压缩比达到惊人的102∶1。低码率(Low Bit Rate)对H.264的高的压缩比起到了重要的作用,和MPEG-2和MPEG-4 ASP等压缩技术相比,H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是,H.264在具有高压缩比的同时还拥有高质量流畅的图像,正因为如此,经过H.264压缩的视频数据,在网络传输过程中所需要的带宽更少,也更加经济。

    X264

    x264是一个开源的H.264视频编码函数库。是最好的有损视频编码器。
    x264始于2003年,从当开源社区的MPEG4-ASP编码器Xvid小有所成时开始的,经过几年的开发,特别是Dark Shikari加入开发后,x264逐渐成为了最好的视频编码器。

    ffm

    FFM and FFM2 are formats used by ffserver. They allow storing a wide variety of video and audio streams and encoding options, and can store a moving time segment of an infinite movie or a whole movie.
    FFM is version specific, and there is limited compatibility of FFM files generated by one version of ffmpeg/ffserver and another version of ffmpeg/ffserver. It may work but it is not guaranteed to work.
    FFM2 is extensible while maintaining compatibility and should work between differing versions of tools. FFM2 is the default.

    AVI

    AVI英文全称为Audio Video Interleaved,即音频视频交错格式。是将语音和影像同步组合在一起的文件格式。它对视频文件采用了一种有损压缩方式,但压缩比较高,因此尽管画面质量不是太好,但其应用范围仍然非常广泛。AVI支持256色和RLE压缩。AVI信息主要应用在多媒体光盘上,用来保存电视、电影等各种影像信息。
    它于1992年被Microsoft公司推出,随Windows3.1一起被人们所认识和熟知。所谓“音频视频交错”,就是可以将视频和音频交织在一起进行同步播放。这种视频格式的优点是可以跨多个平台使用,其缺点是体积过于庞大,而且更加糟糕的是压缩标准不统一,最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AⅥ格式视频,而低版本Windows媒体播放器又播放不了采用最新编码编辑的AⅥ格式视频,所以我们在进行一些AⅥ格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放,但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题,如果用户在进行AⅥ格式的视频播放时遇到了这些问题,可以通过下载相应的解码器来解决。是目前视频文件的主流。这种格式的文件随处可见,比如一些游戏、教育软件的片头,多媒体光盘中,都会有不少的AVI。

    rtsp

    RTSP(Real Time Streaming Protocol),实时流传输协议,是TCP/IP协议体系中的一个应用层协议,由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或RTP完成数据传输。HTTP与RTSP相比,HTTP传送HTML,而RTSP传送的是多媒体数据。HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可以发出请求,即RTSP可以是双向的。
    RTSP是用来控制声音或影像的多媒体串流协议,并允许同时多个串流需求控制,传输时所用的网络通讯协定并不在其定义的范围内,服务器端可以自行选择使用TCP或UDP来传送串流内容,它的语法和运作跟HTTP 1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制(Multicast),除了可以降低服务器端的网络用量,更进而支持多方视讯会议(Video Conference)。因为与HTTP1.1的运作方式相似,所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP,并因RTSP具有重新导向功能,可视实际负载情况来转换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。
    该协议用于C/S模型,是一个基于文本的协议,用于在客户端和服务器端建立和协商实时流会话。
    实时流协议(RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使实时数据,如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径,并为选择基于RTP上发送机制提供方法。
    实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的,通常它本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接,如TCP。在RTSP连接期间,RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外,可使用无连接传输协议,如UDP。RTSP流控制的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。

    rtp

    RTP(Real-time Transport Protocol,实时传输协议)是一个网络传输协议,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的,后在RFC3550中进行更新。
    国际电信联盟ITU-T也发布了自己的RTP文档,作为H.225.0,但是后来当IETF发布了关于它的稳定的标准RFC后就被取消了。它作为因特网标准在RFC 3550(该文档的旧版本是RFC 1889)有详细说明。RFC 3551(STD 65,旧版本是RFC 1890)详细描述了使用最小控制的音频和视频会议。
    RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议,但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTSP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用,而且它是建立在用户数据报协议上的。
    实时传输协议(RTP)为数据提供了具有实时特征的端对端传送服务,如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务;这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式,那么 RTP 可以使用该组播表传输数据到多个目的地。
    RTP 本身并没有提供按时发送机制或其它服务质量(QoS)保证,它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送,也不确定底层网络的可靠性。 RTP 实行有序传送, RTP 中的序列号允许接收方重组发送方的包序列,同时序列号也能用于决定适当的包位置,例如:在视频解码中,就不需要顺序解码。
    RTP 由两个紧密链接部分组成:
    RTP ― 传送具有实时属性的数据;

    mms

    Microsoft Media Server (MMS), a Microsoft proprietary network-streaming protocol, serves to transfer unicast data in Windows Media Services (previously called NetShow Services). MMS can be transported via UDP or TCP. The MMS default port is UDP/TCP 1755.
    Microsoft deprecated MMS in favor of RTSP (TCP/UDP port 554) in 2003 with the release of the Windows Media Services 9 Series, but continued to support the MMS for some time in the interest of backwards compatibility. Support for the protocol was finally dropped in Windows Media Services 2008.
    As of 2012 Microsoft still recommends[1] using “mms://” as a “protocol rollover URL”. As part of protocol rollover a Windows Media Player version 9, 10, or 11 client opening an “mms://” URL will attempt to connect first with RTSP over UDP and if that fails it will attempt RTSP over TCP. After an RTSP attempt fails, Windows Media Player versions 9 & 10 will attempt MMS over UDP, then MMS over TCP. If using Windows Media Player 11 and an RTSP attempt fails, or if using a previous version of Windows Media Player and MMS fails, a modified version of a HTTP over TCP connection will be attempted. This modified version is referred to by some third parties as MMSH, and by Microsoft as MS-WMSP (Windows Media HTTP Streaming Protocol). The URI scheme “mms://” has also been proposed to be used for the unrelated Multimedia Messaging Service (MMS) protocol.
    For several years developers of the SDP Multimedia download-tool reverse-engineered the MMS protocol and published unofficial documentation for it. However, Microsoft finally released the protocol specification in February 2008.

    mmsh

    MMS is a proprietary digital media streaming protocol developed by Microsoft.
    It is supported in Windows Media Player and Microsoft® Windows® Media Server v4.0 or later. MMSH is MMS over HTTP.

    ref:http://wiki.videolan.org/MMSH
    ref:http://baike.baidu.com/view/7704.htm
    ref:http://en.wikipedia.org/wiki/Microsoft_Media_Server
    ref:http://baike.baidu.com/view/364757.htm
    ref:http://baike.baidu.com/view/56322.htm?fromId=403562
    ref:http://nmm-hd.org/doc/X264%E4%BD%BF%E7%94%A8%E4%BB%8B%E7%BB%8D
    ref:http://www.videolan.org/developers/x264.html
    ref:http://ffmpeg.org/ffserver.html#What-is-FFM_002c-FFM2
    ref:http://baike.baidu.com/view/7697.htm
    ref:http://baike.baidu.com/view/610472.htm#sub7572724

  • 相关阅读:
    Python时间戳
    vux x-input 清除按钮不起作用
    MySQL连接查询流程源码
    Linux下用的脚本
    TableCache设置过小造成MyISAM频繁损坏 与 把table_cache适当调小mysql能更快地工作
    批量导入数据到InnoDB表速度优化
    DBA面对新mysql环境
    (进阶篇)PHP+Mysql+jQuery找回密码
    (进阶篇)PHP实现用户注册后邮箱验证,激活帐号
    (实用篇)php官方微信接口大全(微信支付、微信红包、微信摇一摇、微信小店)
  • 原文地址:https://www.cnblogs.com/lidabo/p/3701073.html
Copyright © 2011-2022 走看看