带有跟踪的网络音频流/寻求(移动+桌面)

时间:2017-05-02 05:21:13

标签: html5 mobile html5-audio audio-streaming

我需要为网络构建流媒体解决方案已经有很长一段时间了,因为有很多优质的服务可以提供基本的需求。很久以前我用Red5和Flow或JW这样的前端播放器进行了流媒体部署,但是尽管进行了大量的搜索,我还没有能够确定最好的现代选项是什么,以实现一个简单的网络解决方案,具有良好的原生与移动和桌面的兼容性。我希望有人可以提出一个很好的开源堆栈,非常适合我尝试做的事情:

  • 移动+桌面网络音频支持(某些时候可能会有某些视频)
  • 流式传输(不是直播流媒体直播,但能够在不下载整个文件的情况下进行搜索和收听,只能缓冲到足以保证良好质量而不浪费带宽)
  • 跟踪已收听的流量(不是已下载的数量)
  • 保护流(通过将该逻辑写入服务器端但在某个时间点之后使用标头或URL模式使链接/连接失效,这应该非常简单,但我还是想提及它)
  • 轻量级,现在可能有10到20个并发音频流。

我最初的想法,因为我在流媒体领域的知识已经过时了,就是使用RTMP,RTSP或HLS以及类似JWPlayer的前端,这取决于哪个协议似乎对大多数设备都有最好的支持。或者,如果客户端支持良好,我可以跳过媒体服务器并通过网络服务器使用伪流媒体。在服务器端,我可以处理对流的访问控制,在前端播放器上,我可以使用API​​来跟踪播放的秒数,并在ajax请求中ping该数据,以跟踪实际有多少也被听过(而不是下载/缓冲)。

事情是我有一种感觉,这可能是2017年的一个过时的方式。即使我还没有找到任何特定的东西,我感觉也许有更好的解决方案在那里利用节点和webockets可以完成相同的事情,服务器和播放器连接得更紧密(服务器意识到播放头/实际播放量与前端相比)或利用更新标准的解决方案(MPEG-DASH?)。此外,过去让其他流媒体协议在所有设备上兼容是一件痛苦的事情,IIRC对所有浏览器中任何一个旧协议都没有通用的HTML5支持。

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

0 个答案:

没有答案