基于浏览器的流媒体视频/音频（非渐进式下载）
我试图从概念上理解提供真实流媒体音频和视频内容的最佳方式。我希望它可以通过网络浏览器使用，使用最少的专有技术。我不会提供静态文件并使用渐进式下载，这将是实时捕获的真实音频流。如何广播与源合理同步的流？什么样的协议合适？
编辑：
在研究中我发现有几种协议：RTSP、HTTP Streaming、RTMP 和 RTP。
如果您正在流式传输某种类型的现场表演/通信，HTTP 流式传输 有点不适合，因为它依赖于 TCP（因为它基于 HTTP）并且不会丢失数据包。在低带宽情况下，客户端的播放速度可能会明显落后。 ref
RTMP 是一项专有技术，需要闪存媒体服务器。废话。我之所以关注 Flash，是因为它们在用户体验方面非常灵活。 SoundManager2 提供了一个优秀的 javascript 接口，用于使用 flash 播放媒体。这就是我在客户端应用程序中寻找的内容。
Microsoft 转而使用 RTSP/RTP，弃用了他们的 MMS 协议。 RTSP 是控制协议。它与 HTTP 类似，但有一些明显的区别 - 服务器也可以与客户端通信，并且还有其他命令，例如 PAUSE。它也是一个有状态协议，通过会话 ID 进行维护。 RTP 是用于传送有效负载（编码的音频或视频）的协议。有一些开源项目，其中一个由苹果此处支持。看起来这可能会达到我想要的效果，而且看起来相当多的玩家支持它。听起来它适合从这个页面此处进行“现场”广播。
谢谢， 乔什
I am trying to understand conceptually the best way to deliver real streaming audio and video content. I would want it to be consumed with a web browser, utilizing the least amount of proprietary technology. I wouldn't be serving static files and using progressive download, this would be real audio streams being captured live. How does one broadcast a stream that will be reasonably in sync with the source? What kind of protocol is suitable?
Edit:
In research I've found that there are a few protocols: RTSP, HTTP Streaming, RTMP, and RTP.
HTTP streaming is somewhat unsuitable if you are streaming a live performance/communication of some kind because it relies on TCP (as its HTTP based) and you don't lose packets. In a low bandwidth situation, the client can get significantly behind in playback. ref
RTMP is a proprietary technology, requiring flash media server. Crap on that. The reason I looked at flash is because they are extremely flexible as far as user experience goes. SoundManager2 provides an excellent javascript interface for playing media with flash. This is what I would look for in a client application.
RTSP/RTP is what Microsoft switched to using, deprecating their MMS protocol. RTSP is the control protocol. Its similar to HTTP with a few distinct difference -- server can also talk to the client, and there are additional commands, like PAUSE. Its also a stateful protocol, which is maintained with a session id. RTP is the protocol for delivering the payload (encoded audio or video). There are a few open sourced projects, one of them being supported by apple here. It seems like this might do what I want it to, and it looks like quite a few players support it. It sounds like it would be suitable for a "live" broadcast from this page here.
Thanks,
Josh
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，让我快速删除两个不正确的点。详细信息如下：
我的理解是，复杂且基于 UDP 的流媒体正在逐渐减少。我并不是在预测死亡，只是预测市场份额越来越小。相对于基于 TCP 的解决方案（例如 10 倍或更多），基于 UDP 的流服务器消耗大量资源，而且好处并不明显。
你说你不想要专有技术，并且“[Flash] 很糟糕”，但你仍然想做真正的流媒体？不想打扰您，但是 RealAudio 和 RealVideo 都是专有的。
如果开源对你真的那么重要（我可以理解），那么你就需要忽略绝大多数流媒体市场。看看
如果实用主义战胜了你，那么请重新考虑你的厌恶Adobe 产品。请记住，Flash 比任何其他基于浏览器的播放器（即 Windows Media Player、Quick Time 和 Real Players）分布更广泛。
您仍然可以通过开源使用 RTMP：Red5 可能是最受关注的——它可以将直播流传输到支持 Flash 的浏览器。
我建议您考虑一下您的优先事项。在您的问题中为我们拼写出来。
First, let me knock off two incorrect points quickly. Details to follow below:
My read is that complex and UDP-based streaming is tapering off. I'm not forecasting death, just a lesser and lesser share of the market. UDP-based streaming servers consume huge resources, relative to TCP-based solutions (like 10x or more), and the benefits just aren't that tangible.
You say you don't want proprietary technology, and "crap on [Flash]", but you still want to do Real streaming? Hate to break it to you, but both RealAudio and RealVideo are both proprietary.
If going Open Source really is that important to you, which I can understand, then you'll need to ignore the vast majority of the streaming media market. Have a look at
If pragmatism gets the best of you, then reconsider your aversion to Adobe products. Remember, Flash is more widely distributed than any other browser-based player (namely Windows Media Player, Quick Time and Real Players.)
You can still use RTMP with open source: Red5 is probably of greatest interest--it can stream live to Flash-enabled browsers.
I would recommend thinking about your priorities. Spell them out for us in your question.
我想在 Stu 的回复中补充一点，基于 UDP 的流协议在防火墙或 NAT 后面工作时通常会具有额外的复杂性。例如，如果您计划在家外使用 WIFI 接入点，其中许多接入点将不支持使用 UDP 传输的 RTP。许多客户端都有故障恢复机制，如果在超时之前没有收到数据包，客户端将尝试 TCP 传送。
I would add to Stu's reply that UDP based streaming protocols often have additional complexity to work when behind firewalls or NATs. For example, if you plan to use WIFI access points outside of the home, many of these will not support RTP using UDP delivery. Many clients have a failback mechanism where if no packets are received prior to a timeout, the client will attempt TCP delivery.