构建可扩展的音频流基础架构

在streamABC上,我们正在为广播电台和其他媒体公司构建音频流基础架构已有好几年了。 作为我在streamABC的工程师和开发人员的活动的一部分,我的任务是完全重新考虑和重建现有基础结构。 该技术栈主要基于Icecast(正是Icecast的KH分支)。 过去,只有一台大型主服务器可以接受传入的音频流,而有些边缘服务器则需要繁重的工作来为所有侦听器服务。 所有部署和手动操作。 尽管这在过去的几年中效果很好,但仍然存在很多缺点,这些缺点越来越难以克服。 破烂不堪 客户之间没有分隔(例如,广播电台)。 如果只有几个,这是可以的,但随着越来越多的客户和对单个解决方案的需求增加而变得更加不安。 Icecast是一款可靠的软件,可以完成工作。 但是同时,它已经很老了,无法满足最新的需求,例如更好的日志记录和见解,实时指标,可伸缩性。 现有的设置几乎不可能满足市场的新需求,例如地理位置感知流,流中和流中广告,可跳过流和用户特定的元数据。 大型整体服务器结构,需要更多的操作工作才能提供良好的可用性。 随着无线电台提供越来越多的多达数百个单独频道的趋势,变得难以手动维护配置并保持较低的初始成本和上线时间。 还有很长的路要走 我们的目标是能够快速建立新的流,而无需麻烦,包括源安装,代码转换,分布式边缘,实时监控,注入的元数据,虚拟流URL甚至是播放系统,以从音频播放列表中流式播放文件。 而这一切都不需要庞大的团队。 我们从2015年开始重新考虑音频流。作为第一步,我们创建了用于实时监控现有基础架构的解决方案。…

对于应用程序的IT基础架构成本,每一笔钱都至关重要-容器是关键

在企业软件领域,正在出现一种新趋势,它正在改变组织的工作方式。 这种趋势是“采用微服务”。 根据Nginx(负载平衡和容器化领域的领导者)最近的一项调查,目前接受调查的企业中有36%在使用微服务,而在研究阶段则有26%。 敏捷性和可伸缩性是采用微服务的主要动力。 加拿大沃尔玛在2012年将其软件体系结构重新架构为微服务。之前,它们无法处理每分钟600万次页面浏览量,但后来,他们实现了转换率的显着提高。 停机时间也被最小化,该公司能够用便宜的虚拟x86服务器代替昂贵的商品硬件,从而使总体成本节省了20%到50%。 “降低TCO曲线-解耦是新潮流” 借助微服务,多个团队可以从事独立服务,从而使您能够快速部署。 应用程序开发时间减少了,代码将更可重用。 通过解耦服务,可以使用Basic x86机器代替昂贵的机器。 这样,微服务可以降低基础架构成本,并最大程度地减少停机时间。 但是微服务到底是什么: 微服务被定义为一种精细的软件体系结构,其中应用程序组件是独立设计和开发的,以满足API定义的互操作性要求。 开源Docker普及的容器是企业启用微服务的绝佳工具。 为什么选择集装箱 容器支持全栈部署,因此开发人员团队可以在松耦合的应用程序上工作,然后选择最适合其部署要求的技术栈,而不是相反。 什么是容器…

使用ffmpeg和SRT将视频信号传输到云

将实时视频转码以在线分发到公共云需要一种将视频信号传输到云的方法。 有两种方法可以实现此目的,在本文中,我们将主要研究如何使用SRT(安全可靠传输)和ffmpeg来实现此目的。 在研究如何使用SRT之前,让我们看一下还有哪些其他选择。 今天最简单的选择是使用RTMP作为传输协议。 它是Adobe开发的协议,已经存在了一段时间。 今天,Wirecast,Teradek和OBS等许多生产工具都支持RTMP,这是YouTube,Facebook和Twitch支持的协议。 RTMP是基于TCP的协议,在该协议中,每个数据包均得到确认并保证被传递,这意味着底层协议确保接收端接收到位流中的所有位。 每个数据包的握手过程都会增加开销,并带来一些限制。 RTMP的另一个缺点是并非所有的Live Transcoding软件都支持现成的RTMP。 这限制了您选择正确的代码转换软件时可以使用的某些选项。 在许多情况下,您将需要通过UDP /组播从RTMP到MPEG-TS的“桥梁”。 这也可以使用ffmpeg来完成,我们将在另一篇文章中进行介绍。 同样,在生产方(发送者)不一定总是可以选择使用RTMP作为运输协议。 对于这些情况,有几种商业选择,例如紫溪,可以通过Internet传输MPEG-TS流。 商业协议和专有协议的一种选择是使用SRT(安全可靠传输)来传输信号,而我们将在ffmpeg中完成此操作。 安全可靠的运输…