流媒体 订阅
流媒体(streaming media)是指将一连串的媒体数据压缩后,经过网上分段发送数据,在网上即时传输影音以供观赏的一种技术与过程,此技术使得数据包得以像流水一样发送;如果不使用此技术,就必须在使用前下载整个媒体文件。流式传输可传送现场影音或预存于服务器上的影片,当观看者在收看这些影音文件时,影音数据在送达观看者的计算机后立即由特定播放软件播放。 [1] 展开全文
流媒体(streaming media)是指将一连串的媒体数据压缩后,经过网上分段发送数据,在网上即时传输影音以供观赏的一种技术与过程,此技术使得数据包得以像流水一样发送;如果不使用此技术,就必须在使用前下载整个媒体文件。流式传输可传送现场影音或预存于服务器上的影片,当观看者在收看这些影音文件时,影音数据在送达观看者的计算机后立即由特定播放软件播放。 [1]
信息
网络协议
RTP、RTCP、RTSP
采用方式
流式传输方式
中文名
流媒体
外文名
Streaming media
流媒体简介
流媒体(Streaming Media)技术是指将一连串的媒体数据压缩后,以流的方式在网络中分段传送,实现在网络上实时传输影音以供观赏的一种技术。 [2]  流媒体实际指的是一种新的媒体传送方式,有声音流、视频流、文本流、图像流、动画流等,而非一种新的媒体。 [2]  流媒体文件格式是支持采用流式传输及播放的媒体格式。常用格式有:RA:实时声音;RM:实时视频或音频的实时媒体;RT:实时文本;RP:实时图像;SMII.:同步的多重数据类型综合设计文件;SWF:real flash和shockwavc flash动面文件;RPM: HTMI。文件的插件;RAM:流媒体的源文件,是包含RA、RM、SMIIJ文件地址(URL地址)的文本文件;CSF:一种类似媒体容器的文件格式,可以将非常多的媒体格式包含在其中,而不仅仅限于音、视频。quicktime,mov,asf,wmv,wma,avi,mpeg,mpg,dat,mts; aam多媒体教学课件格式,可将authorware生成的文件压缩为aam和aas流式文件播放。 [2] 
收起全文
精华内容
参与话题
问答
  • 流媒体概念介绍

    2012-07-19 23:29:00
    流媒体是指采用流式传输的方式在Internet播放的媒体格式。 流媒体又叫流式媒体,它是指商家用一个视频传送服务器把节目当成数据包发出,传送到网络上。用户通过解压设备对这些数据进行解压后,节目就会像发送前那样...

    流媒体是指采用流式传输的方式在Internet播放的媒体格式。 流媒体又叫流式媒体,它是指商家用一个视频传送服务器把节目当成数据包发出,传送到网络上。用户通过解压设备对这些数据进行解压后,节目就会像发送前那样显示出来。

    流媒体使之以流的方式在网络中传输音频、视频和多媒体文件的形式。 流媒体文件格式是支持采用流式传输及播放的媒体格式。流式传输方式是将视频和音频等多媒体文件经过特殊的压缩方式分成一个个压缩包,由服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中,用户不必像非流式播放那样等到整个文件全部下载完毕后才能看到当中的内容,而是只需要经过几秒钟或几十秒的启动延时即可在用户计算机上利用相应的播放器对压缩的视频或音频等流式媒体文件进行播放,剩余的部分将继续进行下载,直至播放完毕。   这个过程的一系列相关的包称为"流"。流媒体实际指的是一种新的媒体传送方式,而非一种新的媒体。流媒体技术全面应用后,人们在网上聊天可直接语音输入;如果想彼此看见对方的容貌、表情,只要双方各有一个摄像头就可以了;在网上看到感兴趣的商品,点击以后,讲解员和商品的影像就会跳出来;更有真实感的影像新闻也会出现。流媒体技术发端于美国。流式传输方式则是将整个A/V及3D等多媒体文件经过特殊的压缩方式分成一个个压缩包,由视频服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中,用户不必像采用下载方式那样等到整个文件全部下载完毕,而是只需经过几秒或几十秒的启动延时即可在用户的计算机上利用解压设备(硬件或软件)对压缩的A/V、3D等多媒体文件解压后进行播放和观看。此时多媒体文件的剩余部分将在后台的服务器内继续下载。

    流式传输的基础

      在网络上传输音/视频等多媒体信息,目前主要有下载和流式传输两种方案。A/V文件一般都较大,所以需要的存储容量也较大;同时由于网络带宽的限制,下载常常要花数分钟甚至数小时,所以这种处理方法延迟也很大。流式传输时,声音、影像或动画等时基媒体由音视频服务器向用户计算机的连续 流媒体技术

    、实时传送,用户不必等到整个文件全部下载完毕,而只需经过几秒或十数秒的启动延时即可进行观看。当声音等时基媒体在客户机上播放时,文件的剩余部分将在后台从服务器内继续下载。流式不仅使启动延时成十倍、百倍地缩短,而且不需要太大的缓存容量。流式传输避免了用户必须等待整个文件全部从Internet上下载才能观看的缺点。   流媒体指在Internet/Intranet中使用流式传输技术的连续时基媒体,如:音频、视频或多媒体文件。流式媒体在播放前并不下载整个文件,只将开始部分内容存入内存,流式媒体的数据流随时传送随时播放,只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输。   流式传输定义很广泛,现在主要指通过网络传送媒体(如视频、音频)的技术总称。其特定含义为通过Internet 将影视节目传送到PC机。实现流式传输有两种方法:实时流式传输(Realtime streaming)和顺序流式传输(progressive streaming)。一般说来,如视频为实时广播,或使用流式传输媒体服务器,或应用如RTSP的实时协议,即为实时流式传输。如使用HTTP服务器,文件即通过顺序流发送。采用哪种传输方法依赖你的需求。当然,流式文件也支持在播放前完全下载到硬盘。

    实时流式传输

    实时流式传输指保证媒体信号带宽与网络连接配匹,使媒体可被实时观看到。实时流与HTTP流式传输不同,他需要专用的流媒体服务器与传输协议。实时流式传输总是实时传送,特别适合现场事件,也支持随机访问,用户可快进或后退以观看前面或后面的内容。理论上,实时流一经播放就可不停止,但实际上,可能发生周期暂停。实时流式传输必须配匹连接带宽,这意味着在以调制解调器速度连接时图象质量较差。而且,由于出错丢失的信息被忽略掉,网络拥挤或出现问题时,视频质量很差。如欲保证视频质量,顺序流式传输也许更好。实时流式传输需要特定服务器,如:QuickTime Streaming Server、RealServer与Windows Media Server。这些服务器允许你对媒体发送进行更多级别的控制,因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议,如:RTSP (Realtime Streaming Protocol)或MMS (Microsoft Media Server)。这些协议在有防火墙时有时会出现问题,导致用户不能看到一些地点的实时内容。

    顺序流式传输

    顺序流式传输是顺序下载,在下载文件的同时用户可观看在线媒体,在给定时刻,用户只能观看已下载的那部分,而不能跳到还未下载的前头部分,顺序流式传输不象实时流式传输在传输期间根据用户连接的速度做调整。由于标准的HTTP服务器可发送这种形式的文件,也不需要其他特殊协议,它 经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段,如片头、片尾和广告,由于该文件在播放前观看的部分是无损下载的,这种方法保证电影播放的最终质量。这意味着用户在观看前,必须经历延迟,对较慢的连接尤其如此。对通过调制解调器发布短片段,顺序流式传输显得很实用,它允许用比调制解调器更高的数据速率创建视频片段。尽管有延迟,毕竟可让你发布较高质量的视频片段。顺序流式文件是放在标准HTTP或 FTP服务器上,易于管理,基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频,如:讲座、演说与演示。它也不支持现场广播,严格说来,它是一种点播技术。

    流媒体技术原理

      流式传输的实现需要缓存。因为Internet以包传输为基础进行断续的异步传输,对一个实时A/V源或存储的A/V文件,在传输中它们要被分解为许多包,由于网络是动态变化的,各个包选择的路由可能不尽相同,故到达客户端的时间延迟也就不等,甚至先发的数据包还有可能后到。为此,使用缓存系统来弥补延迟和抖动的影响,并保证数据包的顺序正确,从而使媒体数据能连续输出,而不会因为网络暂时拥塞使播放出现停顿。通常高速缓存所需容量并不大,因为高速缓存使用环形链表结构来存储数据:通过丢弃已经播放的内容,流可以重新利用空出的高速缓存空间来缓存后续尚未播放的内容。——流式传输的实现需要合适的传输协议。由于TCP需要较多的开销,故不太适合传输实时数据。在流式传输的实现方案中,一般采用HTTP/TCP来传输控制信息,而用RTP/UDP来传输实时声音数据。流式传输的过程一般是这样的:用户选择某一流媒体服务后,Web浏览器与Web服务器之间使用HTTP/TCP交换控制信息,以便把需要传输的实时数据从原始信息中检 流媒体制作

    索出来;然后客户机上的Web浏览器启动A/VHelper程序,使用HTTP从Web服务器检索相关参数对Helper程序初始化。这些参数可能包括目录信息、A/V数据的编码类型或与A/V检索相关的服务器地址。   A/VHelper程序及A/V服务器运行实时流控制协议(RTSP),以交换A/V传输所需的控制信息。与CD播放机或VCRs所提供的功能相似,RTSP提供了操纵播放、快进、快倒、暂停及录制等命令的方法。A/V服务器使用RTP/UDP协议将A/V数据传输给A/V客户程序(一般可认为客户程序等同于Helper程序),一旦A/V数据抵达客户端,A/V客户程序即可播放输出。   需要说明的是,在流式传输中,使用RTP/UDP和RTSP/TCP两种不同的通信协议与A/V服务器建立联系,是为了能够把服务器的输出重定向到一个不同于运行A/VHelper程序所在客户机的目的地址。实现流式传输一般都需要专用服务器和播放器,其基本原理如图所示。

    智能流技术(SureStream)

      今天,28.8Kbps调制解调器是Internet连接的基本速率,cable modem、 ADSL、DSS、ISDN等发展快,内容提供商不得不要么限制发布媒体质量,要么限制连接人数。根据RealNetwork站点统计,对28.8Kbps调制解调器,实际流量为10bps到26Kbps,呈钟形分布,高峰在20Kbps。这意味着若内容提供商选择20Kbps固定速率,将有大量用户得不到好质量信号,并可能停止媒体流而引起客户端再次缓冲,直到接收足够数据。一种解决方法是服务器减少发送给客户端的数据而阻止再缓冲,在RealSystem 5.0中,这种方法称为"视频流瘦化"。这种方法的限制是RealVideo文件为一种数据速率设计,结果可通过抽取内部帧扩展到更低速率,导致质量较低。离原始数据速率越远,质量越差。另一种解决方法是根据不同连接速率创建多个文件,根据用户连接,服务器发送相应文件,这种方法带来制作和管理上的困难,而且,用户连接是动态变化的,服务器也无法实时协调。 智能流技术通过两种途径克服带宽协调和流瘦化。首先,确立一个编码框架,允许不同速率的多个流同时编码,合并到同一个文件中;第二,采用一种复杂客户/服务器机制探测带宽变化。   针对软件、设备和数据传输速度上的差别,用户以不同带宽浏览音视频内容。为满足客户要求,Progressive networks公司编码、记录不同速率下媒体数据,并保存在单一文件中,此文件称为智能流文件,即创建可扩展流式文件。当客户端发出请求,它将其带宽容量传给服务器,媒体服务器根据客户带宽将智能流文件相应部分传送给用户。以此方式,用户可看到最可能的优质传输,制作人员只需要压缩一次,管理员也只需要维护单一文件,而媒体服务器根据所得带宽自动切换。智能流通过描述I现实世界Internet上变化的带宽特点来发送高质量媒体并保证可靠性,并对混合连接环境的内容授权提供了解决方法。流媒体实现方式如下: * 对所有连接速率环境创建一个文件 * 在混合环境下以不同速率传送媒体 * 根据网络变化,无缝切换到其它速率 * 关键帧优先,音频比部分帧数据重要 * 向后兼容老版本RealPlayer

    智能流

      在RealSystem G2中是对所谓自适应流管理(ASM)API的实现,ASM描述流式数据的类型,辅助智能决策,确定发送那种类型数据包。文件格式和广播插件定义了ASM规则。用最简单的形式分配预定义属性和平均带宽给数据包组。对高级形式,ASM规则允许插件根据网络条件变化改变数据包发送。每个ASM规则可有一定义条件的演示式,如演示式定义客户带宽是5,000到15,000Kbps,包损失小于2.5%。如此条件描述了客户当前网络连接,客户就订阅此规则。定义在规则中的属性有助于RealServer有效传送数据包,如网络条件变化,客户就订阅一个不同规则。

    流媒体技术应用

      互联网的迅猛发展和普及为流媒体业务发展提供了强大市场动力,流媒体业务正变得日益流行。 流媒体技术广泛用于多媒体新闻发布、在线直播网络广告电子商务视频点播远程教育远程医疗网络电台、 实时视频会议等互联网信息服务的方方面面。流媒体技术的应用将为网络信息交流带来革命性的变化,对人们的工作和生活将产生深远的影响。

    流媒体技术

    一个完整的流媒体解决方案应是相关软硬件的完美集成,它大致包括下面几个方面的内容: 内容采集、 视音频捕获和压缩编码、内容编辑、内容存储和播放、应用服务器内容管理发布及用户管理等。

      流媒体技术和声音信息经过压缩处理后放上网站服务器,让用户一边下载一边观看、收听,而不要等整个压缩文件下载到自己的计算机上才可以观看的网络传输技术。该技术先在使用者端的计算机上创建一个缓冲区,在播放前预先下一段数据作为缓冲,在网路实际连线速度小于播放所耗的速度时,播放程序就会取用一小段缓冲区内的数据,这样可以避免播放的中断,也使得播放品质得以保证。

      传输流程

      在流式传输的实现方案中,一般采用HTTP/TCP来传输控制信息,而用RTP/UDP来传输实时声音数据。具体的传输流程如下:

      (1)Web浏览器与Web服务器之间使用HTTP/TCP交换控制信息,以便把需要传输的实时数据从原始信息中检索出来。

      (2)用HTTP从Web服务器检索相关数据,由A/V播放器进行初始化。

      (3)从Web服务器检索出来的相关服务器的地址定位A/V服务器。

      (4)A/V播放器与A/V服务器之间交换A/V传输所需要的实时控制协议。

      (5)一旦A/V数据抵达客户端,A/V播放器就可播放。

      技术方式

    目前主流的流媒体技术有三种,分别是RealNetworks公司的RealMedia、Microsoft公司的WindowsMediaTechnology和Apple公司的QuickTime。这三家的技术都有自己的专利算法、专利文件格式甚至专利传输控制协议。

    存在问题

      流媒体技术不是一种单一的技术,它是网络技术及视/音频技术的有机结合。在网络上实现流媒体技术,需要解决流媒体的制作、发布、传输及播放等方面的问题,而这些问题则需要利用视音频技术及网络技术来解决,具体如下:

      (1)流媒体制作技术方面解决的问题

      在网上进行流媒体传输,所传输的文件必须制作成适合流媒体传输的流媒体格式文件。因这通常格式存储的多媒体文件容量十分大,若要在现有的窄带网络上传输则需要花费十分长的时间,若遇网络繁忙,还将造成传输中断。另外,通常格式的流媒体也不能按流媒体传输协议进行传输。因此,对需要进行流媒体格式传输的文件应进行预处理,将文件压缩生成流媒体格式文件。这里应注意两点:一是选用适当的压缩算法进行压缩,这样生成的文件容量较小。二是需要向文件中添加流式信息。

      (2)流媒体传输方面需解决的问题

      流媒体的传输需要合适的传输协议,目前在internet上的文件传输大部分都是建立在tcp协议的基础上,也有一些是以ftp传输协议的方式进行传输,但采用这些传输协议都不能实现实时方式的传输。随着流媒体技术的深入研究,目前比较成熟的流媒体传输一般都是采用建立在udp协议上的rtp/rtsp实时传输协议。

      为何要在udp协议而不在tcp协议上进行实时数据的传输呢?这是因为udp和tcp协议在实现数据传输时的可靠性有很大的区别。tcp协议中包含了专门的数据传送校验机制,当数据接受方收到数据后,将自动向发送方发出确认信息,发送方在接收到确认信息后才继续传送数据,否则将一直处于等待状态。而udp协议则不同,udp协议本身并不能做任何校验。由此可以看出,tcp协议注重传输质量,而udp协议则注重传输速度.因此,对于对传输质量要求不是很高,而对传输速度则有很高的要求的视音频流媒体文件来说,采用udp协议则更合适.

      (3)流媒体的传输过程中需要缓存的支持

      因为interent是以包为单位进行异步传输的,因此多媒体数据在传输中要被分解成许多包,由于网络传输的不稳定性,各个包选择的路由不同,所以到达客户端的时间次序可能发生改变,甚 至产生丢包的现象.为此,必须采用缓存技术来纠正由于数据到达次序发生改变而产生的混乱状况,利用缓存对到达的数据包进行正确排序,从而使视音频数据能连续正确地播放.缓存 中存储的是某一段时间内的数据,数据在缓存中存放的时间是暂时的,缓存中的数据也是动态的,不断更新的.流媒体在播放时不断读取缓存中的数据进行播放,播放完后该数据便被立即清除,新的数据将存入到缓存中.因此,在播放流媒体文件时并不需占用太大的缓存空间.

      (4)流媒体播放方面需解决的问题

    流媒体播放需要浏览器的支持.通常情况下,浏览器是采用mime来识别各种不同的简单文件格式,所有的web浏览器都是基于http协议,而http协议都内建有mime.所以web浏览器能够通过http协议中内建的mime来标记web上众多的多媒体文件格式,包括各种流媒体格式.

    摘自:百度百科

    展开全文
  • 一套大规模的流媒体系统,由编码工具负责对音视频文件编码压缩(h.264/h.265/VP9/AAC等);由流媒体服务器负责对数据包进行容器封装(flv/ts等)以及负责网络协议打包(RTMP/HTTP等);由CDN网络进行全网分发;由...

    一套大规模的流媒体系统,由编码工具负责对音视频文件编码压缩(h.264/h.265/VP9/AAC等);由流媒体服务器负责对数据包进行容器封装(flv/ts等)以及负责网络协议打包(RTMP/HTTP等);由CDN网络进行全网分发;由播放层负责对图像进行解码显示(FLASH/VLS/VIDEO JS等)。流媒体系统所需的核心组件包括:

    (1)编码工具:用于流媒体文件生成的编码工具

    (2)流媒体服务器:用于控制、传送流媒体数据的流媒体服务器

    (3)CDN网络:用于支撑流媒体的全网分发网络

    (4) 网络协议:用于支持特定的流式传输的网络协议

    (5)播放器:各操作平台用于显示流式数据的播放器

    本篇内容将对上述5个环节做一个整体性论述,由于本系列分享着重讨论流媒体传输分发,所以在后续文章不会再讲编码和播放两个端上的环节。本篇对编码和播放将稍微展开讨论,其它3个环节只简单提及,后续将分章详细讨论。本篇最后将给出一个实例,让大家能直观的看出一个完整的流媒体系统各环节是如何运用到直播系统中。



    2.1

    编码工具


    视音频的编码应该是整个视音频技术中最复杂、涉及知识点最多的技术了,当然也是最重要的技术,这是一门专业学科。我们研究流媒体时,如果不是专业做编解码的,倒不必对编解码技术进行系统学习。因为当下市面上有大量优秀的专业编码设备、编码软件、开源工具,我们只需要了解视音频编解码大致的原理,了解各种编码标准,做流媒体时如何选择及使用编码工具就达到目的了。


    (1)视音频编码原理

    我们所谓的视音频编码,其实就是一个对数据进行压缩的过程。在编码原理这块,我们无需掌握其过于深奥的数学原理和计算机算法,只需要搞清楚两个问题即可,一是为什么要压缩?二是为什么能压缩?

    为什么要压缩,在回答这个问题之前我们需要搞清楚我们天天在网上看的直播里面那些视频和音频到底是个什么东西。视频,是通过摄像头采集下来的YUV等原始数字格式;音频,是通过麦克风拾音器采集下来的PCM等原始数字格式(YUV/RGB/PCM数据格式原理网络上有大量文章)。如果直接通过网络传输这些原始数据,大概需要多大的带宽呢?下图给出了不同YUV分量格式、采样频率、量化比特位数下这些数据所需的传输速率。


    几百兆(音频是需要几兆),这根本无法在网络上传输,同时也不利于存储,一部1小时的电影大约是几百个G。所以,我们必须通过编码技术将原始视音频数据进行大幅度的压缩,以能在互联网上传输及存储。编码设备或编码软件所做的,一是将原始YUV或PCM数据进行大小上的压缩,二是将压缩后的数据打包进流媒体协议发送给流媒体服务器。

    为什么能压缩,主要是由于原始视音频数据存在以下两种冗余数据,所以我们才能使用编码算法对数据量进行大幅压缩,以此实现网络上的传输和存储。

    ·          数据冗余:比如视频画面的众多像素在空间上、时间上、结构上等等方面存在着很强的相似性甚至是完全一模一样。消除这些冗余数据并不会导致信息损失,此为无损压缩。

    ·          视觉/听觉冗余:人眼对亮度和色度的敏感度不同,使得数据在一定范围内压缩引入误差,也基本不会有显著感知;人耳对20Hz~20KHz范围外的声音无法察觉,或者一定程度引入误差也无法感知。利用人类眼睛和耳朵的特性,在不影响正常感知的情况下对数据进行压缩,此为有损压缩。


    (2)编码器工作流程

    在我们熟悉的直播系统中,编码工作一般由硬件编码器、PC端OBS/FMLE、移动端各种采集SDK来完成。这些编码工具除了压缩编码之外,其实还完成了下图所示的采集、编码、封装、协议打包、推流5大环节,其中每一个环节都涉及非常多的理论知识和巨大的研发工作量,此处只介绍各环节作用。


    采集:该环节作用是通过音视频硬件采集卡(如BlackMagic等)、桌面采集程序(如OBS的videoCapture)、移动端采集程序(如IOS的AVFoundation框架等)将视音信号变为YUV/PCM等数字视音频信号。观止云自主研发广电级编码器,在采集环节也遇到过较多的坑,以往微信号分享文章中做过多次论述。

    编码:该环节作用是通过特定的视频、音频编码算法,将原始的YUV/PCM数据进行数量级的压缩,压缩后成为H.264/AAC等压缩数据。编码环节是整个编码工具中最为核心和复杂的部分,其中涉及了多种压缩算法选取、数十项压缩参数的设置、软编/硬编的适配优化及技术方案等等。虽然该环节及其复杂,但我们只需要记住4点结论性的知识点就够了:

    ·          目前最主流的编码算法为:h.264(视)/AAC(音)

    ·          未来可能成为趋势并且竞争激烈的是:h.265(也叫HEVC)(MPEG/ITU-T两个组织2013年联合推出)和VP9(Google 2013年推出)

    ·          视频算法性能排名:h.265(HEVC) > VP9 > H.264> VP8 > MPEG4 > H.263 > MPEG2

    ·          音频算法性能排名:AAC+ > MP3PRO > AAC> RealAudio > WMA > MP3

    封装:该环节将H.264/AAC等压缩数据按照一个统一的格式组装到一个文件里面,这就是我们经常所说的视音频文件格式,也就是文件的后缀名,文件只有有了格式客户端才知道该用什么程序打开。整体上封装格式可能有上百种,但我们经常碰到或者流媒体系统常用的大概有如下几种。


    协议打包:该环节将上述如flv等封装数据加上一些信令数据后进行流媒体协议打包。流媒体协议将在后续分章细述,此处给出目前常用的流媒体协议列表。


    推流:很多编码工具也叫“串流”,就是编码工具将编码、封装好的音视频最终通过流媒体协议发送给流媒体服务器。


    (3)重要的编码参数

    我们在基于一些商用编码设备、开源编码工具搭建流媒体系统或者操作直播相关业务时,掌握了基本概念后,其实更重要的是对编码相关的参数要有深刻的认识和熟练的配置优化。以下给出一些比较重要的参数概念:

    ▣   GOP(Group of Pictures):一个GOP就是一组连续的画面,每个画面就是一帧, GOP就是很多帧的集合。这里面有I/P/B帧的概念,播放器显示画面是去找到最近的I帧(关键帧)来显示,所以为了实现秒开的体验,一般流媒体服务器会有GOP Cache配置,GOP Cache越长,播放体验会越好,但不好的一面是GOP Cache会增加直播的延迟。所以,我们在配置时一方面要做好延时与画质的平衡,另一方面可以通过追帧播放等技术来进行优化。

    ▣  关键帧距离:关键帧(I帧)之间的最大距离(单位:秒),它是根据视频内容中的场景变换自动决策的,但两个关键帧之间的最大距离不超过该设定值,推荐配置:5-10。这个参数会影响到直播的延时,如果为了追求最低延时,可将其配置为1。

    ▣  码率控制VBR/CBR/ABR:

    ·          CBR(Constant Bitrate):恒定比特率,相对于VBR和ABR来讲,它无法根据视频内容的变换而动态变换,导致某些情况下图像质量较差或某些情况下浪费带宽 。

    ·          ABR(Average Bitrate):平均比特率,是介于CBR和VBR之间的一种折中算法。 对于较简单的图像或场景使用相对低的码率,高复杂度和大动态表现时使用高码率。互联网直播推荐使用才控制策略。

    ·          VBR(Variable Bitrate):动态比特率。也就是没有固定的比特率,保持恒定质量的参数,推荐用于内网视频应用或视频存档。


      码率控制缓冲区时长:缓冲区起到平滑码率波动的作用。在编码端,数据输入缓冲区的码率是变化的,而输出端则取决于码率控制模式。缓冲区越大平滑效果就越好同时延时也越大,缓冲区小能保证低延时同时可能由于上溢导致跳帧。

      前向预测延迟:单位为秒,通过缓冲一定数量的视频帧(提高编码延迟)来提高编码质量,默认为自动,该参数跟编码延迟有关

      超低延迟:如观止云广电级编码器等部分编码设备或者编码工具由此选项,启用超低延迟,将关闭B帧、关闭MBtree、关闭码率控制前向预测,使编码的同时能够同步输出;由于启用低延迟模式,会在一定程度上降低视频质量,适用于视频通话和视频会议等。

      参考帧数:控制DPB (Decoded Picture Buffer)的大小。可以在0-16之间选择。简单地说,就是设置P帧可以选择它之前的多少帧作为参照帧。最小可以选择值1,只参照自己前面的那帧。注意H.264标准限制了每个level可以参照的帧的数量。如果选择level4.1,1080p最大选4,720p最大选9。推荐设置为自动,将根据编码复杂度中相关参数设置。

      B帧数量:手动指定在I帧或P帧之间创建的连续B帧的数量,范围是0-16。推荐设置为自动,将根据编码复杂度中相关参数设置。

      视频质量与体验质量:视频是由图像和声音组成的,所以它本身是有质量属性的,我们可以简单的用清晰度、流畅感(帧率)来描述它。但我们在互联网上看视频尤其是直播,其实更需要整体的视听体验要好,这里面大致会涉及到的参数有采样率、帧率、分辨率、码率等,另外还和接入带宽、每个人不同的眼镜、耳朵感知程度等都有关系,是个比较复杂的过程。参数的具体含义之前文章的术语表中都能找到,总体来说,我们需要做的是一种各参数之间的平衡,来保障最终的观看体验。以下是观止云的编码参数配置建议:



    以下几点需要提醒:

    ·          1080P VBR的码率范围一般为2.3-4Mbps,新闻类节目一般建议采用2.3Mbps,运动类节目一般建议采用4Mbps,观止推荐3Mbps;

    ·          720P VBR的码率范围一般为1.2-2Mbps,新闻类节目一般建议采用1.2Mbps,运动类节目一般建议采用2Mbps,观止推荐1.5Mbps;

    ·          576P VBR的码率范围一般为600k-1Mbp,新闻类节目一般建议采用1.2Mbps,运动类节目一般建议采用2Mbps,观止推荐800kbps;

    ·       480P VBR的码率范围一般为400kbps-600kbps,新闻类节目一般建议采用400kMbps,运动类节目一般建议采用600kbps,观止推荐500kbps;

    ·        360P VBR的码率范围一般为200kbps-400kbps,新闻类节目一般建议采用200kMbps,运动类节目一般建议采用400kbps,观止推荐300kbps;

    ·            本编码建议不适合IPTV、数字电视等采用CBR编码方式,通常采用IPTV和数字电视指提供576P和1080P两个选项,码率为2.5Mbps(576P 720x576)和8Mbps(1080P 1920x1080),个别地方提供720P,码率为4Mbps左右(720P 1280x720)

    ·       移动端的编码参数可参照PC-720P、PC-576P

      视频质量评价:它讲的是如何评价视频本身质量,一般分为主观评价方法和客观评价方法。当下有多种成熟的评价模型、评价工具可供直接使用。目前使用的比较广泛的是客观质量评价SSIM和峰值信噪比PSNR,网络上有大量的其算法模型文章。

    ▣ 编码级别(Level):该指标是用来标识解码端解码能力的重要参数,跟每秒解码器能够处理的数据量相关,如果你的编码端有此选项,建议设置为自动,它就会根据当前编码复杂度、分辨率、帧率等配置计算出合适的Level值。如果很懂该参数,那就可以手动限制输出码流的Level值,以适配相应设备。


    (4)开源项目等资料

    FFmpeg:一个跨平台的开源视频框架,能实现如视频编码、解码、转码、串流、播放、字幕、滤镜等丰富的功能。其支持的视频格式以及播放协议非常丰富,几乎包含了所有音视频编解码、封装格式以及播放协议。

    X264/X265:一个简单的额将YUV数据编码为h.264/h.265的开源项目,可以基于它实现编码器功能,是目前视频编码应用最广的,但需要注意的是它只提供编码,不提供解码。

    Xvid:一个开放源代码的MPEG-4视频编解码器。

    libvpx:Google发起的VP8/VP9开源编码器。

    Thor: 思科开源的视频编码解码器。

    Opus:IETF Codec工作组、Skype等共同发起的专注网络音频的编解码器。

    Speex:开源的音频编码项目。

    IQA(Image Quality Assessment):一个快速,精确,可靠的基于C的开源视频质量评价项目,支持SIMM, MSE 和 PSNR等多种质量评价方法。


    另外:国内各大云公司基本都有移动端采集SDK供免费使用。


    音频编码算法对比一览:

    https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats

    视频编码算法对比一览:

    https://en.wikipedia.org/wiki/Comparison_of_video_codecs

    所有视音频封装格式对比一览:

    https://en.wikipedia.org/wiki/Comparison_of_video_container_formats

    更多开源的音视频编码项目一览:

    https://en.wikipedia.org/wiki/List_of_open-source_codecs

    展开全文
  • 最近自己在研究有关于流媒体播放的技术,网上资料甚少。出于开源精神以及在查阅资料得到各位大佬的帮助,故将自己的心得写下记录,便于分享以及日后维护。 在此极力感谢并推荐雷神(雷霄骅) 个人博客:...

    快速搭建一个简单的流媒体视频服务

    前言

    最近自己在研究有关于流媒体播放的技术,网上资料甚少。出于开源精神以及在查阅资料得到各位大佬的帮助,故将自己的心得写下记录,便于分享以及日后维护。
    在此极力感谢并推荐雷神(雷霄骅)
    个人博客:https://blog.csdn.net/leixiaohua1020

    系统组成

    一个完整的流媒体系统大致需要三个部分组成:编码器、流服务器和播放器。

    编码器通过对内容来源(如MP3文件或者麦克风输入)进行编码,并将编码过的内容发送到流服务器;流服务器再将它们发布到Internet,这样客户端的播放器只要连接到流服务器就可以进行在线播放了。

    而本次搭建过程是基于RTMP协议完成。

    RTMP协议简介

    RTMP播放过程
    播放一个RTMP协议的流媒体需要经过以下几个步骤:握手,建立连接,建立流,播放。
    RTMP连接都是以握手作为开始的。

    1:建立连接阶段用于建立客户端与服务器之间的“网络连接”;
    2:建立流阶段用于建立客户端与服务器之间的“网络流”;
    3:播放阶段用于传输视音频数据。
    

    Red5 概述

    Red5 是一个采用 Java 开发开源的 Flash 流媒体服务器。免费开源使软件更加容易扩展,下载后你可以对源代码进行修改;更加经济,比起 FMS 高昂的费用,Red5 能为一般的应用节约大笔费用;同时服务器端的 Java 面向对象语言比起 FMS 服务器端的 ActionScript2 语言更加成熟。鉴于 Red5 的种种优势,推出不久便被广大用户所接受。

    Red 5 支持:

    1. 把音频(MP3)和视频(FLV, F4V, MP4, 3GP)转换成播放流;

    2. 录制客户端播放流, 把摄像头,麦克风等传入的音频视频录制保存到服务器;

    3. 共享对象;

    4. 现场直播流发布;

    5. 远程调用;

    6. 协议:RTMP, RTMPT, RTMPS, and RTMPE。

    Red5 服务器搭建

    JDK自行安装_本文不做演示

    可参考:https://jingyan.baidu.com/article/6dad5075d1dc40a123e36ea3.html

    下载Red5:(本人使用版本:1.0.10)
    官网:http://red5.org/
    GitHub:https://github.com/Red5/red5-server/releases

    下载后解压到自己的固定文件夹,如图:
    在这里插入图片描述
    可以选择在conf/red5.properties文件下修改IP和端口号

    # Socket policy
    policy.host=0.0.0.0
    policy.port=843
    
    # HTTP
    http.host=192.168.1.115	//可在此修改HTTP  IP地址
    http.port=5080
    https.port=5443
    http.URIEncoding=UTF-8
    http.max_headers_size=8192
    http.max_keep_alive_requests=-1
    http.max_threads=20
    http.acceptor_thread_count=10
    http.processor_cache=20
    
    # RTMP
    rtmp.host=192.168.1.115		//可在此修改IP地址
    rtmp.port=1935
    rtmp.io_threads=8
    rtmp.send_buffer_size=65536
    rtmp.receive_buffer_size=65536
    rtmp.ping_interval=1000
    rtmp.max_inactivity=60000
    rtmp.max_handshake_time=5000
    rtmp.tcp_nodelay=true
    rtmp.tcp_keepalive=false
    rtmp.default_server_bandwidth=10000000
    rtmp.default_client_bandwidth=10000000
    rtmp.client_bandwidth_limit_type=2
    rtmp.bandwidth_detection=false
    rtmp.encoder_base_tolerance=5000
    rtmp.encoder_drop_live_future=false
    # traffic optimization hinting. to disable set traffic class set to -1
    # low delay + high throughput == 24 (0x18)
    rtmp.traffic_class=-1
    # requested maximum length of the queue of incoming connections
    rtmp.backlog=32
    # the interval (seconds) between each throughput calculation
    rtmp.thoughput_calc_interval=15
    # enable use of the default mina acceptor
    rtmp.default_acceptor=true
    # socket i/o pool sizes used when default acceptor is disabled
    rtmp.initial_pool_size=0
    rtmp.max_pool_size=2
    rtmp.max_processor_pool_size=8
    rtmp.executor_keepalive_time=60000
    mina.logfilter.enable=false
    # scheduler configs (per application)
    rtmp.scheduler.pool_size=8
    rtmp.deadlockguard.sheduler.pool_size=8
    # message executor configs (per application) - adjust these as needed if you get tasks rejected
    rtmp.executor.core_pool_size=4
    rtmp.executor.max_pool_size=32
    rtmp.executor.queue_capacity=64
    # drop audio packets when queue is almost full, to disable this, set to 0
    rtmp.executor.queue_size_to_drop_audio_packets=60
    # maximum amount of time allotted to process a single rtmp message / packet in milliseconds, set it as 0 to disable timeout
    rtmp.max_handling_time=2000
    # connection tweaks - dont modify unless you know what you're doing
    rtmp.channel.initial.capacity=3
    rtmp.channel.concurrency.level=1
    rtmp.stream.initial.capacity=1
    rtmp.stream.concurrency.level=1
    rtmp.pending.calls.initial.capacity=3
    rtmp.pending.calls.concurrency.level=1
    rtmp.reserved.streams.initial.capacity=1
    rtmp.reserved.streams.concurrency.level=1
    # maximum packet size allowed in bytes
    rtmp.max_packet_size=3145728
    
    # RTMPS
    rtmps.host=0.0.0.0
    rtmps.port=8443
    rtmps.ping_interval=5000
    rtmps.max_inactivity=60000
    rtmps.max_keep_alive_requests=-1
    rtmps.max_threads=8
    rtmps.acceptor_thread_count=2
    rtmps.processor_cache=20
    # RTMPS Key and Trust store parameters
    rtmps.keystorepass=password
    rtmps.keystorefile=conf/keystore.jks
    rtmps.truststorepass=password
    rtmps.truststorefile=conf/truststore.jks
    
    # RTMPT
    rtmpt.host=0.0.0.0
    rtmpt.port=8088
    rtmpt.ping_interval=5000
    rtmpt.max_inactivity=60000
    rtmpt.max_handshake_time=5000
    rtmpt.max_keep_alive_requests=-1
    rtmpt.max_threads=8
    rtmpt.acceptor_thread_count=2
    rtmpt.processor_cache=20
    rtmpt.encoder_base_tolerance=5000
    rtmpt.encoder_drop_live_future=true
    # better setting for streaming media
    rtmpt.target_reponse_size=32768
    # best setting for small messages or shared objects
    #rtmpt.target_reponse_size=8192
    # max incoming messages to process at a time. the most that FP appears to send is 166
    rtmpt.max_in_msg_process=166
    # max time in millis that we will wait when offering data to the in or out queue
    rtmpt.max_queue_offer_time=125
    # max offer attempts
    rtmpt.max_queue_offer_attempts=4
    
    # Debug proxy (needs to be activated in red5-core.xml)
    proxy.source_host=127.0.0.1
    proxy.source_port=1936
    proxy.destination_host=127.0.0.1
    proxy.destination_port=1935
    
    # JMX
    jmx.rmi.host=localhost
    jmx.rmi.port=9999
    jmx.rmi.sport=9998
    jmx.rmi.port.remoteobjects=
    jmx.keystorepass=password
    jmx.mina.monitor.enable=false
    jmx.mina.poll.interval=1000
    # Whether to always create the registry in-process, not attempting to 
    # locate an existing registry at the specified port. Set to "true" in order
    # to avoid the overhead of locating an existing registry when you always intend
    # to create a new registry in any case.
    jmx.registry.create=true
    # Whether or not the MBeanServerFactoryBean should attempt to locate a running 
    # MBeanServer before creating one
    jmx.reuse.existing.server=true
    # Whether to register the MBeanServer with the MBeanServerFactory, making it 
    # available through MBeanServerFactory.findMBeanServer()
    jmx.register.factory=true
    # Whether any threads started for the JMXConnectorServer should be started as daemon threads
    jmx.daemon=true
    # Whether the JMXConnectorServer should be started in a separate thread
    jmx.threaded=true
    
    # Server properties
    # max events to send in a single update
    so.max.events.per.update=64
    so.scheduler.pool_size=4
    keyframe.cache.entry.max=500
    war.deploy.server.check.interval=600000
    fileconsumer.delayed.write=true
    fileconsumer.queue.size=120
    fileconsumer.wait.for.keyframe=true
    subscriberstream.buffer.check.interval=5000
    subscriberstream.underrun.trigger=100
    subscriberstream.max.pending.frames=10
    subscriberstream.max.sequential.frames=10
    broadcaststream.auto.record=false
    
    

    启动red5.bat
    在这里插入图片描述

    出现上图后在浏览器输入:http://IP:port/
    如:http://192.168.1.115:5080/
    在这里插入图片描述
    即代表启动成功!

    展开全文
  • 今天发现二哥在搞流媒体,顿时来了兴趣(之前在考试维护的时候经常听老师说P2P等),追问之下之前林哥搞成功过,而且写了一系列博客;于是乎便翻开博客,认真看了看,写的非常不错:从概念到安装实现(linux和...

    强烈推荐一个大神的人工智能的教程:http://www.captainbed.net/zhanghan

    【前言】

        今天发现二哥在搞流媒体,顿时来了兴趣(之前在考试维护的时候经常听老师说P2P等),追问之下之前林哥搞成功过,而且写了一系列博客;于是乎便翻开博客,认真看了看,写的非常不错:从概念到安装实现(linux和windows)再到性能测试对比非常不错(详见:http://blog.csdn.net/u012407484/article/category/2732453);

        在看博客之前和二哥交流,自己当时认为流媒体是P2P,看了林哥的博客后对流媒体的概念了解了,感觉不太对劲,于是乎马不停蹄在网上度娘了一把进行验证,果然发现流媒体和P2P是不同的两个东西,但是P2P技术在流媒体领域中应用比较广泛,也难怪之前自己将两者混为一谈。

        通过在网上查资料和林哥的博客自己对传统媒体,流媒体,加P2P的流媒体技术有了更多的了解,在此与大家共享。

    【流媒体进化之路】

        1、传统媒体:刚开始的时候大家在网上看视频或音频等媒体是采用传统媒体的方式:从服务器下载完后再能进行播放:

                       

        2、流媒体:随着人类生活越来越丰富,品味越来越高(比如:视频要超清滴等),逐渐发现传统媒体的方式不能满足人类的需要(比如:要看个超清的电影可能需要缓冲4个小时);于是乎流媒体技术应运而生:

                        

        3、加P2P的流媒体:随着互联网的快速发展,利用互联网进行娱乐的人越来越多,相信大家有这样体会,每到上网高峰期自己看视频卡的要死;这便是普通流媒体中存在一个问题,服务器的压力太大,服务器性能和带宽承受不住;很简单一个解决方案:加大服务器的带宽,提高服务器的性能,或许会暂时解决问题,但是当客户再多,服务器的性能和带宽又承受不住,实践表明这种客户增长速度要远大于服务器和带宽的增长。于是乎应用P2P技术流媒体应运而生:

         (1)最开始只有客户A获取资源示意图:

               

         (2)过一会儿后客户B获取资源示意图:

                

         (3)再过一会儿客户C访问资源示意图:

             

        (4)不难看出采用P2P技术后刚开始是从服务器上获取初始资源,随着客户机不断获取资源,后来的客户机可根据相应的算法判断到离其最近的机器上(并不一定是客户机哈)有自己想要的资源然后去获取之;不难看出当客户机越多,资源分布在客户机中的概率越高,自然而然获取资源更快;所带来的体验更好(比如:看视频时,同时看的人越多反而越流畅了)。

    【总结】

        1、从传统媒体—>流媒体—>含P2P流媒体:技术复杂度逐渐递增,人的体验越来越好;

        2、随着人类的生活越来越丰富需求越来越高,从而推动技术在不断的发展;   
        3、学习的兴趣来源于经历来源于好奇心。

    展开全文
  • RTMP流媒体播放过程

    万次阅读 多人点赞 2013-09-15 11:19:49
    本文描述了从打开一个RTMP流媒体到视音频数据开始播放的全过程。 注意:RTMP中的逻辑结构 RTMP协议规定,播放一个流媒体有两个前提步骤:第一步,建立一个网络连接(NetConnection);第二步,建立一个网络流...
  • 网络流媒体(四)———TS流

    千次阅读 2019-08-04 11:54:59
    MPEG-2是MPEG(Moving Picture Experts Group,运动图像专家组)组织制定的视频和音频有损压缩标准之一,它的正式名称为“基于数字存储媒体运动图像和语音的压缩标准”。与MPEG-1标准相比,MPEG-2标准具有更高的...
  • 流媒体地址

    热门讨论 2012-11-29 23:58:50
    这是我最近做web开发中用到WMP空间时,搜集到的在线流媒体地址,包括央视及各大卫视,截至到2012年11月29日,我亲自测试,好用。低分推荐给大家。也欢迎做web开发的猿们一起讨论,进步
  • 流媒体

    2020-10-21 12:26:46
    流式传输:主要指通过网络传送媒体(如视频、音频)的技术...如使用HTTP服务器,文件即通过顺序发送。采用哪种传输方法依赖你的需求。当然,流式文件也支持在播放前完全下载到硬盘。 流式传输的实现需要缓存。因为I
  • Linux下视频流媒体服务器搭建详解

    万次阅读 2018-03-25 10:33:02
    目标用于搭建内网流媒体服务器支持视频的点播。背景用于支持培训网站中视频点拨功能,在培训网站总体方案中需要加入流媒体服务器,用于存储和传输视频资源。相关概念流媒体流媒体(Streaming Media)是一种新兴的...
  • 流媒体/流媒体文件格式详解

    千次阅读 2017-05-31 20:34:41
    摘 要 流媒体文件格式在流媒体系统中占有重要地位,设计合理的文件格式是提高流媒体服务器工作效率最直接和最有效的办法。该文在剖析常用流媒体系统和文件格式的基础上,特别地对美国xiph.org基金会的开源流媒体...
  • 视频的传输方式【转】

    千次阅读 2019-07-29 18:18:13
    流媒体2.TCP/IP、OSI与视频传输协议之间的关系3.组播、单播和广播4.视频传输协议5.自适应流媒体 概述 搜索“视频传输协议”,一般会搜出来RTP,RTSP,UDP等等。光看这些协议,可能有些人会觉得奇怪为什么要把udp也往...
  • FLV流媒体格式

    千次阅读 2012-10-16 14:41:24
    FLV 是FLASH VIDEO的简称,FLV流媒体格式是随着Flash MX的推出发展而来的视频格式。由于它形成的文件极小、加载速度极快,使得网络观看视频文件成为可能,它的出现有效地解决了视频文件导入Flash后,使导出的SWF文件...
  • [总结]RTMP流媒体技术零基础学习方法

    万次阅读 多人点赞 2013-11-18 00:10:34
    本文主要总结一些我在学习RTMP流媒体技术过程中积累的经验。也为后来学习RTMP流媒体技术的人们一个参考。本文力图从简到难,循序渐进的介绍RTMP流媒体技术的方方面面,先从应用说起,逐步深化剖析相关工程的源代码。...
  • LiveQing流媒体服务器软件,提供一站式的转码、点播、直播、时移回放服务,极大地简化了开发和集成的工作。 其中,点播功能主要包含:上传、转码、分发。直播功能,主要包含:直播、录像, 直播支持RTMP输入,RTMP/...
  • ##第二步:安装流媒体服务 免费获得试用安装包,加入QQ群 615081503 群文件里有试用安装包,极速安装,下载解压一键启动即可,支持Windows和Linux双系统。 ##第三步:创建直播间 选择 【直播服务】-》视频直播 ,...
  • 本文转自EasyDarwin团队成员Alex的博客:http://blog.csdn.net/cai6811376/article/details/74783269需求在做EasyDSS开发时,总是在测试推...以及其他RTMP工具。但是,别忘了,还有ffmpeg这个神器。ffmpeg可以获
  • 搭建Nginx-rtmp流媒体服务器+使用ffmpeg推流 https://www.jianshu.com/p/06c2025edcd3 sudo apt-get install build-essential sudo ./configure –prefix=/usr/local/nginx –with-pcre=../nginx-dependence/pcre...
  • Windows10下搭建nginx-rtmp流媒体服务器

    千次阅读 2019-04-07 19:52:19
    FFmpeg是一套可以用来记录、转换数字音频、视频,并能将其转化为的开源计算机程序。采用LGPL或GPL许可证。它提供了录制、转换以及化音视频的完整解决方案。它包含了非常先进的音频/视频编解码库libavcodec,能够...
  • 流媒体协议—RTMP

    千次阅读 2017-01-25 14:48:37
    RTMP协议是由Adobe提出的一个应用层的协议,主要用来解决流媒体数据传输的问题,是目前低延时直播应用最广泛的协议。在我们实际工作中,我们对RTMP应该再熟悉不过,因它是几乎所有编码器标准输出协议,是PC机打开...
  • javaCV系列文章: javacv开发详解之1:调用本机摄像头视频 ...javaCV开发详解之3:收流器实现,录制流媒体服务器的rtsp/rtmp视频文件(基于javaCV-FFMPEG) javaCV开发详解之4:转流器实现(也可作...
  • ios rtsp rtmp流媒体播放器

    热门讨论 2015-07-20 14:21:01
    ios rtsp rtmp流媒体播放器,代码的架构跟kxmovie差不多,但我真实实验过好多kxmovie代码播放rtmp并不能很好的实时播放,后来看了这个播放还是很好,希望对你们有用,本人就是做ios流媒体这一块的,稍微要点资源分。
  • rtmp流媒体测试工具

    2016-01-30 16:59:15
    测试rtmp流或者Adobe Media Server,red5等流媒体服务器是否部署成功
  • 流媒体协议介绍(rtp/rtcp/rtsp/rtmp/mms/hls)

    万次阅读 多人点赞 2013-09-25 23:55:18
    RTP  参考文档 RFC3550/RFC3551  Real-time Transport Protocol)是用于Internet上针对多媒体数据流的...RTP协议常用于流媒体系统(配合RTCP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成
  • 自己从事流媒体近20载, 从没有可用的流媒体服务器到现在服务器遍地开花.  但尽管开源服务器众多,功能强大, 但却没有可以直接拿来使用的. 原因是配置安装困难,没有自己想要的接口,很难与现有系统对接.  &...
  • 基于SRS搭建RTMP直播流媒体服务器

    万次阅读 2018-11-22 11:23:11
    软件定位 SRS 定位是运营级的互联网直播服务器集群,追求更好的概念完整性和最简单实现的代码。 运营级:商业运营追求极高的稳定性、良好的系统对接、错误排查和处理机制。... ...互联网:互联网最大的特征是变化,...
  • 支持rtmp协议的流媒体播放器代码 内附流媒体网址rtmp: 用于测试
  • 本文继续上一篇文章,记录一些基于Flash的流媒体处理的例子。本文记录一些基于Flash技术的网页播放器。基于Flash的网页播放器相比于其他网页播放器来说最大的优势就是“免插件安装”了,这一点可以很大的提高用户的...
  • 目前接触视频直播、点播的协议主要是rtmp和hls,这篇文章就来认识下这2种协议各有什么特色,目的在做直播、点播功能时,对2种协议有对比、有认识。 一、简介 复习下网络传输协议: add:“七层网络”通俗...
  • nginx + rtmp 搭建流媒体服务器直播平台

    千次阅读 热门讨论 2019-05-10 16:10:10
    一、安装与配置nginx服务器 安装nginx: 1,安装参考播客:...2,安装完成后下载 nginx-rtmp-module 模块(我这里的目录是在/usr/local/nginx-1.15.0 下面) cd /usr/local/nginx-1.15.0/ nginx-rtmp-m...
  • 阿里云搭建rtmp流媒体服务器,中间踩过一些坑,过程一步步纪录的很详细,以及碰到的一些问题。

空空如也

1 2 3 4 5 ... 20
收藏数 256,877
精华内容 102,750
关键字:

流媒体