Html 带跟踪功能的网络音频流/搜索（移动和桌面）

我已经很久没有为web构建流媒体解决方案了，因为有这么多好的服务提供基本需求。很久以前，我使用Red5和Flow或JW等前端播放器进行流媒体部署，但尽管进行了大量搜索，我仍然无法确定实现简单web解决方案的最佳现代选项，该解决方案与移动和桌面具有良好的本机兼容性。我希望有人能推荐一个好的开源堆栈，它非常适合我正在尝试的工作：

• 移动+桌面网络音频支持（在某些时候可能会有一些视频）
• 流媒体（不是直播流媒体，而是在不下载整个文件的情况下进行搜索和收听的能力，并且只进行足够的缓冲，以获得良好的质量，不浪费带宽）
• 跟踪一个流的收听量（而不是下载量）
• 保护流（通过将逻辑写入服务器端，使用在某个时间点后使链接/连接过期的标题或URL模式，这应该非常容易，但我还是想提一下）
• 轻量级，目前可能有10到20个并发音频流

由于我在流媒体领域的知识已经过时，我最初的想法是使用RTMP、RTSP或HLS以及前端的JWPlayer之类的东西，这取决于哪种协议似乎在大多数设备上具有最好的支持。或者，如果客户端支持良好，我可能会跳过媒体服务器，通过Web服务器使用psuedo流媒体。在服务器端，我可以处理对流的访问控制，在前端播放器上，我可以使用API跟踪播放的秒数，并在ajax请求中ping该数据，以跟踪实际监听的秒数（而不是下载/缓冲）

问题是我有一种感觉，在2017年，这可能是一种过时的方式。尽管我还没有找到任何具体的解决方案，但我有一种感觉，也许有一种更好的解决方案，利用Node和WebSocket来完成同样的事情，即服务器和播放器更紧密地耦合（服务器知道播放头/实际播放量与前端相比），或者一种利用新标准的解决方案（MPEG-DASH？）。此外，在过去，让其他流媒体协议在所有设备上都兼容是一件痛苦的事情，IIRC对于所有浏览器中的任何一个旧协议都没有通用的HTML5支持

那么，目前解决此类问题的最佳方法是什么呢？像JW或Flow这样的媒体服务器+前端仍然是更好的方法之一，还是有更好/更简单的方法来部署这样的解决方案