冰上学校通告(石膏)

T与许多其他机构相比，学校的流媒体需求并不大, 尤其是在直播方面. 学校期望看到的最引人注目的直播可能是毕业典礼, 政策的演讲, 还有几位杰出的演讲者. 我多年来一直支持教育视频, 直播的最大观众人数是1人,400名观众同时观看(2010年科学奥林匹克国家奖颁奖典礼), 一个只包含两个边缘Flash媒体服务器的集群很容易处理的受众. 虽然观众不多, 他们很重要:我们不想让一个不能参加毕业典礼的家长错过自己学生的名字被喊到，也不想让一个捐赠者错过他们的认可度因为一条差的小溪.

除了这些事件, 令人惊讶的是，在支持K-12学校的核心教育任务方面，传统的直播几乎没有什么用处. 然而, 我最近咨询了一个有趣的问题:一所小学的晨间通告. 而不是使用古老的对讲系统, 这所学校让学生提供新闻广播式的直播，并将其投射到所有教室. 这过去是通过闭路电视完成的, 但是当这个系统老化的时候, 在向流媒体解决方案过渡的过程中，老师们即兴发挥了技术，做出了非常明智的选择.

等我参与进来的时候, 他们使用OBS Studio将流发布到一个商业主机，该主机将流发送到教室的智能板. 主持节目的老师想要探索一种本地媒体服务器，以消除不重要的托管成本, 虽然小溪很安全, 这名教师对视频传输感到不舒服把小学生送去幼儿园又送回来. 老师还想看看是否可以减少流中的延迟:流媒体供应商遵循行业趋势，采用了相当传统的HTTP Live streaming (HLS)模型，将延迟推到了30秒以上——这已经足够长，会给学生带来困惑.

理想的解决方案是没有成本, on-prem, 低延时, 足够健壮，可以广播到最多30个客户端，没有最后一英里的问题, 而且足够简单，可以可靠地工作, 既适合学生发布广播，也适合课堂老师播放.

这些特性中至少有一个需要妥协:在权衡部署基于webbrtc的解决方案(如Janus或Kurento)的性能优势，以及维护和故障排除一个主要为实时交互服务而不是作为广播流媒体服务器开发的开源产品的困难之后, 很明显，延迟不会像学校的闭路电视解决方案那样低. 我推荐的可能是仍在广泛使用的最古老的媒体服务器:Icecast. Icecast通常被认为是一个纯音频流媒体服务器, 但它也可以在现代浏览器中将WebM视频传输到HTML5视频元素.

调优Icecast以实现低延迟，本质上需要考虑与调优相同的问题 HLS用于低延迟:您需要最小化存储在缓冲区中的视频, 这样做的代价是，整体流的可靠性将不那么健壮. 你唯一能做的就是调整广播挂载点的突发大小. 突发大小与HLS中的片段大小大致相同，并且直接与延迟相关，因为它定义了在发送到客户端之前需要积累多少视频数据. Icecast的默认值是64Kbps, 在发送到客户端之前，非常少量的服务器端数据缓冲. 在Icecast中实现低延迟的真正技巧是在编码器上使用短GOP长度. 在我使用一系列学校预算的硬件进行的测试中, I could consistently get latency of around 4 seconds with tolerable picture quality by setting the keyframe interval in OBS Studio to twice the frame rate: Firefox's