SRS是个开源流媒体服务器，BMS（目前已停止研发）是在SRS基础上做的一个cdn用的服务器，NGINX是一个web服务器，也有nginx-rtmp模块支持流媒体。 我很久就想说说服务器和CDN的区别，为何很了不起的服务器譬如FMS、WOWZA并没有在CDN中一统江湖？而是给了NGINX空子可以钻，大部分都是NGINX或APACHE在cdn中跑，还有SRS什么事情？ 这个道理其实很简单，服务器和系统之间有个鸿沟，可惜谁也听不懂这个是什么，也讲不清楚。知道我们把服务器完善并在cdn中上线运营，才知道有这么多
目前市面上有很多开源的流媒体服务器解决方案，常见的有SRS、EasyDarwin、ZLMediaKit和Monibuca等，我们应该怎么选择呢？
SRS是一个简单高效的实时视频服务器，支持RTMP/，等多种格式。工作用用到 SRS 服务，本文是我在学习过程中的学习笔记。
SRT是一个广电中新的传输协议，基于UDP，主要实现弱网时更可靠的推流，比如跨国推流、户外4G网络、易干扰的WIFI环境，详细的介绍可以阅读LVS的拆解SRT：新UDP视频传输协议和UDP成为低延时流媒体关键 选SRT还是QUIC？。 runner365(施维)大神，基于SRS实现了SRT推流，以RTMP/HTTP-FLV/HLS/DASH/HDS等协议分发，欢迎runner365成为SRS的第三位主作者。目前SRT已经合并到了SRS4(develop)分支，详细可以阅读原文查看使用说明。 SRT是直播
SRS定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。SRS提供了丰富的接入方案将RTMP流接入SRS，
1. SRS最大的特点就是简单，表现在代码架构简单，实现简单，部署简单，运维简单；
点击上方“LiveVideoStack”关注我们 作者：Winlin、Azusachino、Benjamin 编辑：Alex ▲扫描图中二维码或点击阅读原文▲ 了解音视频技术大会更多信息 ---- 当我们的业务超过单台流媒体服务器的承受能力，就会遇到负载均衡问题，一般我们会在集群中提供这种能力，但实际上集群并非是唯一的实现方式。有时候负载均衡还会和服务发现等时髦词汇联系起来，而云服务的LoadBalancer无疑不可回避，因此，这个问题其实相当复杂，以至于大家会在多个场合询问这个问题，我打算系统地阐述
这里我们选用开源srs流媒体服务器https://github.com/ossrs/srs，有兴趣的同学也可选用Adobe Media Server 5，原理都是一样的。
1 、动手搭建直播服务器，完成一次对移动端支持的直播。 2、使用OBS推流。 3、使用html5网页播放m3u8流媒体文件。
直播平台自建，大多选择开源的项目，比如SRS，Nginx+RTMP,RED5等，如果对直播的质量要求不高，用户量又少，当然可以自建。如果用户量大，质量要求高，还是找个成熟的方案，多花点钱。
移动端发展速度已经不用科普了，移动端的流媒体用什么分发？SRS为何要重写HLS和HTTP？为什么说SRS才是标准移动端的流媒体服务器？ 移动端是个可以好好装逼的领域，对于移动端流媒体更加是可以一装再装逼。这篇逼只是一个开头，这篇专门讲讲移动端会有哪些球会推出来。 接下来可能会陆续的装如下的逼： M3U8/TS到底有什么难的？坑有多大，坑里有多少个球？ 除HLS外，HTTP-FLV/MP3也是移动端需要的吗？ 为何要为移动端重写HTTP服务器？这个球有多大？ 移动端直播和点播P2P的实现。 先了解个大概吧
CDN这几年爆炸式增长，带宽提速是根源，而HTTP始终还是那个屌样，因此目前CDN大多是资本性行业，不用多少知识就能干了；直到流媒体粗现，直播咋这么难搞呢？因为它是流媒体，让我带你深入浅出看流媒体前世今生，分分钟二逼变牛逼。 流媒体分为点播和直播，点播已经堕落为HTTP文件了，直播永远不可能只用HTTP就OK，这是他们的业务差异导致的。流媒体本质上是：现实的图像，经过编码器压缩，持久化为点播文件或者直播流，经过传输，在终端解码和展示。 点播为何属于HTTP而不是流媒体呢？点播，譬如电影或者录制的影像，传输
自由与开源软件的理念，从不解、争议、接受到如今如火如荼，经历了长期的历程。国内开源软件起步较晚，但进展迅速。腾讯经过几年的开源协同运动，也取得了不少成绩。其中，腾讯云音视频在FFmpeg、SRS等重要多媒体开源社区的贡献，颇具代表性。 SRS是开源实时视频服务器、全球流服务器中Star最多也最活跃的开源项目，主要应用在直播、WebRTC、安防和交通等领域，支持常用的流媒体协议和转换，以好用易用赢得了全球开发者的良好口碑。开箱即用的云SRS开源音视频方案赋能众多行业创造了新的可能。同时，SRS由工信部木兰开源
谈起要准备一场直播，你会想到什么？体型庞大的直播车、精密昂贵的直播仪器、职业素养拉满的专业人员…… 然而，现在直播随处可见，进入直播间，看起来这一切并没有预想的那么复杂。终于，经过一番周折，在一个直播平台开始了自己的直播之旅，每次直播前都精心准备内容，并且以最好的状态直播，但费尽九牛二虎之力，结果观看人数0。 此时又听说某某平台流量高，可以去，但一想到那些周折，不免犹豫……不如搞一个私人直播间，要是还能快速转播到多个平台就更好了，一次设置，多平台直播。但怎么搞呢？ SRS是什么 SRS是一个开源的流媒体集群
这一节详细解释HTTP FLV的背景。 What is HTTP FLV 所有的HTTP FLV流都是一个HTTP FLV地址，譬如：http://ossrs.net:8081/live/livestream.flv，但是，流的形式却至少有三种： FLV文件，渐进式HTTP流。放一个文件到nginx目录，可以访问下载在播放器播放，这是HTTP FLV文件，也就是渐进式下载流。所谓渐进式下载，也就是用户观看时无法从未下载的地方开始看。 FLV伪流。一般说的HTTP FLV，比上面的渐进式流高级一点，譬如，一个
SRS定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。
SRS最关键是Simple，最简单的方案就是最佳方案；这个文章记录了SRS关键的Simple方案，也就是50%代码完成200%功能，100%代码完成400%功能的要点。 State Threads ST带来的问题简化，在一个状态空间时至少一个数量级；多个状态空间时就是百个数量级，譬如edge回源，http-flv和hstrs。在网络服务器中st的思路是与众不同，也是很巧妙的思路。 SRS是单进程使用epoll进行异步socket操作的高性能服务器，架构和nginx同源（同为非阻塞、异步、单线程），除了ngi
谈起要准备一场直播，你会想到什么？体型庞大的直播车、精密昂贵的直播仪器、职业素养拉满的专业人员……
Photo by Andre Furtado from Pexels 作为开发者，我们需要有一个服务器来支持新视频行业的互联网化，有哪个开源方案能支持新爆发的业务？该方案需要支持哪些关键的能力或需求？
本文测试的服务器环境： 腾讯云服务器Ubuntu Server 18.04.1 LTS 64位 2C4G100M
互联网视频，在PC时代，Flash这个插件都不叫做插件，因为所有的浏览器默认都会安装flash，因此RTMP成为了流媒体的实际工业标准。 最简单的PC流媒体应用，可以使用Flash采集摄像头和麦克风后，以RTMP协议推送给流媒体服务器，然后在浏览器中用Flash播放器播放这个RTMP流。总共需要多少行代码？可以100行as代码就可以实现，脏累烦的事情都是flash搞定了。 视频点播，从来就不是RTMP的事情，那是HTTP文件的世界，一个HTTP-MP4文件，可以在所有平台观看。直播呢也不仅仅是PC了，移动
背景 SRS已经支持了Linux平台，mac平台，以及部分嵌入式平台，而Windows作为当今用户量最大的桌面系统， 在一定的场景下也有流媒体的诉求，甚至希望在Windows服务器上跑服务，特别是一些小型公司。 另外，很多的前端程序员对Windows的需求也很大，在一定的场景下对流媒体系统也有诉求。 SRS for Windows的编译成功，不仅仅解决了上述的问题，而且在一定的程度上补全了SRS对平台支持的完善。 进展 目前已经完成了SRS for Windows版本的编译。编译脚本适配和代码兼容性修改已经
流媒体服务器 流媒体服务器接管了和用户交互的一部分操作，后端通过ffmpeg推流到流媒体服务器 smart-rtmp地址：https://gitee.com/mirrors/smart_rtmpd?
SRS3从2017.01月春节开始支持MPEG-DASH，2月份后支持了DVR MP4，3月份支持了MPD和init.mp4，5月份支持了MP4 Parser CLI，6月份支持了fMP4切片，可惜最终没有和JS播放器调通以实验性功能发布。 MPEG-DASH在国外用来替代HLS和RTMP，当然也用来替代HTTP-FLV，比如YouTube就有DASH的播放器，实际上DASH在Chrome中是属于MSE的播放器。不管有没有真正达到目标，DASH反正是作为一个标准存在了。 SRS3折腾DASH费了很久，主要D
内嵌 flash 的方式必须要有浏览器支持。这样的方式已经被各大浏览器放弃，在谷歌浏览器中已经不再支持flash。本文不再说明。
EdgeCluster实现了合并回源，对于某一路流，不管有多少客户端播放，EdgeServer都只会从OriginServer取一路流，这样可以通过扩展EdgeCluster来增加支持的播放能力，也就是CDN网络具备的重要能力：高并发。
最近解决一些摄像头上云问题，由于自研播放器有时存在一些播放问题，按照音视频常见问题分析和解决：延时和抖动这篇文章说的定位问题思路，我决定搭建一些RTMP流媒体服务器，供测试用标准播放器如VLC交叉验证。之所以存在这么多奇怪的问题，是因为接上来的摄像头或者平台总是存在一些私有码流或者码流格式不规范导致。下面简单说下RTMP服务器搭建和测试方法，包括FMS和SRS在win和linux下的搭建方法。
忽然距离上次更新，快大半年了，为了证明我们社区还没死透，冒个泡，给大伙儿汇报下进展。
SRS(Simple RTMP Server)是一款开源的流媒体服务器，使用C++开发。
SRS(Simple RTMP Server) 是国人写的一款非常优秀的开源流媒体服务器软件，可用于直播/录播/视频客服等多种场景，其定位是运营级的互联网直播服务器集群。
市面上的流媒体服务器不可谓不多，从本人的第一份工作起，就一直接触和研究了形形色色的流媒体服务器，从最早的FCS(全称Flash Communication Server),后来改名为FMS(全称Flash Media Server),到Red5(java语言开发)，到CrtmpServer(C++开发)，让我对流媒体服务器的基本原理有了深刻的认识。当时本人痴迷C#，于是乎在业余时间对crtmpServer的代码进行移植，用C#仿照着写了一遍取名为csharprtmp，并且适当的增强了一些功能，于是对rtmp协议了如指掌。后来Adobe推出了RTMFP协议，是一种p2p协议，十分节省带宽。我就又开始研究一款名为OpenRTMFP的开源项目，后来该项目改名为MonaServer。我在起基础上进行了扩展，实现了一些例如录制flv，shareObject等原本FMS有的功能。后开发出了HTML5直播技术（现在命名为Jessibuca,尚未开源)，采用的传输协议就是WebSocket传输裸的视频流的方式，属于私有协议。而Server当时就使用的MonaServer。但当时遇到一个问题，C++的内存泄漏问题，这个一直没有很好的解决。遂决定放弃使用MonaServer转而使用srs，而srs要用一个很简单的go写的小程序将http-flv转换成WebSocket的Flv来适配我的Jessibuca，感觉最好能直接修改srs来实现这个功能。对srs的源码研究了一小段时间后放弃了，因为C++代码过于难写，容易出现bug。后来转而使用golang写的gortmp作为server，同样对其进行了扩展，而且进展十分顺利，golang的开发效率令人惊叹，而且其协程的特性很完美的处理了流媒体服务器的并发的场景。所以使用golang写的流媒体服务器项目很多，github上随便一搜就有很多，比如livego、joy4等。期间还接触到一位使用Node.js实现的流媒体服务器Node Media Server，我也和作者交流了许多，收益良多。
没啥好说的，长期稳定的超过同类直播开源服务器，就看图吧： 确实只有微弱的优势超越，那是因为SRS3长期跳票，从GITHUB的数据来看，随着SRS3的强劲推进，很快将明显超过竞品，SRS也将进入新的阶段，需要重新设定目标。 fork数目意味着二次开发SRS会更有优势。star数目目前还有些差距，也将在不久的将来成为No.1，趋势非常明显，见下图： 这是因为SRS从未止步，SRS有不一样的目标、决心和恒心，这背后的根本原因是国内流媒体的持续成长，以及繁荣的生态和开发者。 为啥明明各方面都明显超越竞品，
在直播app平台搭建中，需要才用到非常多的技术手段，例如视频/音频处理，图形处理、视频/音频压缩、CDN分发等，每一个技术都够学好几年的。今天就跟大家介绍一下开发一套视频直播系统，整个流程中所运用到的技术流程大概是哪些。
今年疫情的原因导致直播卖货、快抖短视频、视频会议和在线教育都迎来了井喷。这些业务的落地技术方向基本就是两大类，一类是在传统直播技术上的一些演进，另外一类就是以WebRTC技术为核心或者极其变种的低延时实时通信。
搭建流媒体服务的方式一般会采用nginx+rtmp和srs服务两种，前者是nginx加上插件所用，而后者是专门为了为了流媒体而生，在这一节中我们将从头搭建srs流媒体服务
大家好，今天给大家汇总一些在嵌入式里面常见的流媒体服务器，在以往也有给大家简单提过，今天做一个汇总!希望对大家有用！
点击上方“LiveVideoStack”关注我们 今晚19:30，我们邀请到了四位开源项目维护者来分享他们的最新观察与思考，以及项目进展等。同时，会和大家聊聊开源与全球化，以及做开源最大的收获和困扰是什么？ Open Source 耿 航 耿航，目前担任NextArch基金会TOC成员、木兰开源社区运营负责人、Ceph基金会大使、SODA基金会AC委员会成员、腾源会导师、腾讯云TVP、中国开源云联盟副秘书长、CCF开源委员会首批执行委员。主要专注开源项目孵化，开源运营，开源标准，开源教育，开源
借助哪种办法去实现搭建自己的直播平台?，随着直播开发技术的进步，直播平台开发归纳起来主要有两种，一是定制开发直播平台，二是购买直播源码进行二次开发，两种方式各有各的优势。 不过从价格层面考虑的话，更推
为了更好的支持大家的业务场景，收集反馈和需求，了解流媒体服务器的最佳实践和新技术方向，北京SRS开发者沙龙来了。 收获 1. 了解SRS新的核心功能和进展，拓展业务的新场景。 2. 音视频服务器和云原生方向的最佳实践，给业务降本增效。 3. 社区反馈和共建，让SRS更好的支持你的业务发展。 日程 1. 介绍SRS 5.0和6.0的进展（上）。40分钟。 2. 反馈和交流。20分钟。 3. 中场休息。10分钟 4. 介绍SRS 5.0和6.0的进展（下）。40分钟。 5. 反馈和交流。120分钟。 时间：20
Origin Cluster通过配置其他源站的信息，在本源站没有流时查询到流的位置，通过RTMP302定向到指定源站，具体原理可以参考#464。主要应用场景如下：
SRS3目前在发布流程中，就意味着SRS4要来了，一起来看一看SRS的未来吧。说到流媒体的未来，重心还是国内，我们只需要问我们自己想要什么就可以了。 SRS3正在提升稳定性、紧锣密鼓的发布中，这意味着SRS3不会支持主要的变更，只会提升稳定性，当然就说明了SRS4要来了。 SRS4的代号是Leo，感谢这十多年一起奋斗的兄弟姐妹们，关于代号Leo的故事可以看这里。 这个Issue是为了和大家探讨SRS4应该要支持什么，我知道目前新协议比如WebRTC、SRT、QUIC、KCP的呼声比较大，但我已经确定不会以支
c++实现的开源WebRTC协议栈，代码质量比较高，已经有多种语言的binding
留意到上面映射了 1935 端口，1935 端口是 RTMP 协议的数据交换端口。
CDN是一个服务型的公司，也就是服务+技术。 一般的说法是，CDN的技术只是扯逼用的，服务才是一切。在技术没有差异化的图文时代，用运维和客服就可以搞定一切；在视频能造成技术差异化的时代，还行得通吗？ 不必用嘴巴打架，以下功能要求，是结合在CDN两年的工作经验，还有最近这两年所听到的各家CDN还有各种客户对开源软件提的要求。对于一个流媒体集群系统，也就是cdn系统，能否支持以下业务: 客户送入一个rtmp实时流，譬如秀场，游戏，会议，广电等等。 集群的源站输出hls，适配移动端，包括苹果和安卓。并且支持hl
大家好，我是来自百度智能云的李永兴，在百度智能云媒体云团队主要负责RTC产品的研发工作。
我大约是三年前和志宏结缘，当时是ST需要移植到ARM，志宏被大师兄怼成了SRS的开发者，搞定了ST ARM，后面又贡献了WebRTC的支持，进入了技术委员会，详细的故事请听他亲自讲吧。 这次LVS上，志宏会带来他一直在投入的方向：QUIC。 为何是QUIC？QUIC有多重要？ 其实，之前SRS一直在和nginx-rtmp在干，它是一个几年前就不维护的项目，但是由于nginx强大的生态，我们花了7年时间不断进步，才在流媒体领域成为可能比nginx-rtmp更合适的开源服务器。 支持QUIC后，就是和nginx
你是否有以下烦恼： 流媒体服务器依赖太多，编译总出错，下载太慢？ 如何快速扩容缩容，比如用k8s和docker管理服务？ 环境太复杂，要在Windows和macOS跑，要在其他OS开发调试？ 这些问题在SRS3将不复存在，docker和云化会解决所有这些问题。 SRS目前已经支持了直接docker运行，直接提供服务，比如： docker run -p 1935:1935 -p 1985:1985 -p 8080:8080 ossrs/srs:3 敲黑板，划重点，SRS2和SRS3都是可以用docker跑
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
