【问题标题】:How is audio streamed using HTTP如何使用 HTTP 流式传输音频
【发布时间】:2013-03-14 21:01:06
【问题描述】:

我正在处理一个遗留的播客服务,现在似乎是利用 HTML5 的好时机。我们的用户从我们的网站访问此服务,如果这些匿名用户能够无缝体验我们的过渡,那就太好了。我打算使用Media Element

我担心我不知道的事情……似乎一切。可以用这个论坛问背景信息吗?

“流媒体”的定义甚至不清楚。有些人专门用这个词来指代非持久性数据的直播。我们的播客服务使用静态 MP3 文件。因此,它的重要价值在于强制客户端在下载数据时“播放”数据。实现这种期望的客户端行为的后台有什么魔力?

我刚刚注意到 Firefox 现在会自动执行此魔法。为什么花了 20 年才添加这个相当明显的功能?

流式静态数据与传统数据传输的最大区别在于搜索能力:如果我将 10 首音乐曲目组合成一个播放列表文件(我的老派思维是一张专辑),那么用户应该能够向前跳转到没有中间数据的最后一个轨道。这需要一个请求,在中途发出,改变原始响应。这些机制与 HTML 无关(如在 HTML5 中)。我猜 Flash、RealAudio 等除了任何专有编解码器之外,肯定还创建了 HTTP 专有扩展。 HTML5 如何在没有相应升级到 HTTP 标准的情况下实现媒体流标准化?

我感觉有点像彼得·希格斯定义假想玻色子的性质。显然,有一些协议可以处理完成这种形式的流式传输所需的请求/响应。但是由于我什至无法确认它们的存在,因此询问有关服务器操作的问题似乎是推测性的。尽管如此,兼容 HTML5 的浏览器会以某种方式与我的旧版服务器兼容,这似乎是一种信念的飞跃。

应该很简单。我错过了什么?

谢谢! 吉姆

【问题讨论】:

  • 我认为我的观察是错误的,即 Firefox “自动执行此魔术”。这种突然的行为不是由于最近的 Firefox 升级。似乎是因为 Firefox 在其缓存中找到了 80M mp3 而触发了该现象。 Firefox 以它一贯的方式工作——在播放之前完全下载文件。

标签: html http audio


【解决方案1】:

您说得对,“流媒体”是一个有点过分的术语。我倾向于认为绝大多数流媒体内容是通过普通 HTTP 请求传递的。

“我刚刚注意到 Firefox 现在自动执行了这个魔法。为什么花了 20 年才添加这个相当明显的功能?”

我认为许多浏览器已经有能力至少在本地播放简单的音频格式(我认为 1995 年的 Netscape 版本可以处理一些普通的 PCM WAV、AIFF 和 SND 文件)。关于能够原生处理 MP3,长期存在的法律、许可和专利之争仍在进行中。这增加了摩擦。到目前为止,我认为大多数主流浏览器都可以通过音频标签原生处理 MP3 音频。

关于搜索:一个足够智能的客户端可以通过普通的 HTTP 来做到这一点。如果用户发出了一个搜索请求并且该部分还没有下载,客户端可以关闭 HTTP 连接,创建一个新的连接,并请求一定范围的字节。仅当整个文件尚未下载时。 Media Element 可能已经做了类似的事情。

在您的播放列表示例中,这 10 首曲目应该是单独的文件,而不是压缩到一个大文件中。在第一个轨道上播放完成后,JavaScript 可以接收一个信号,告诉它更新 UI 并请求播放第二个文件。如果用户在播放曲目 1 时选择跳到曲目 10,则客户端只需请求曲目 10。

我希望我有所帮助。我知道您要表达的感受——首先不确定要问的问题是否正确。

【讨论】:

  • 感谢您回答这个令人费解的问题
【解决方案2】:

我不知道如何回答我自己的问题。也许我能做的最好的事情就是取消任何荒谬的猜测。

我的原帖总结:

  1. 在后台实现这种期望的客户端行为(动态处理多媒体数据)的魔力是什么?
  2. Firefox 发生了哪些变化,现在它可以“即时”播放 MP3 音频?
  3. 什么协议用于通过 HTTP 完成流式传输?

根据我对Multimedia Mike 的 回答的理解,如果浏览器可以访问适当的编解码器,则它会“即时”处理数据。所以 Q1 的答案是提供一个包含编解码器的插件客户端,例如 FlashPlayer 或 SilverStream。换句话说,一切都归结为专有或开放的编解码器。同样,Q2 的回答是,为了符合 HTML5,Firefox 现在包括(通过骗子或钩子)一个 MP3 编解码器。

多媒体 Mike 的建议将播放列表曲目作为单独的文件加载并没有具体回答有关底层协议的问题。在我的特定项目中,谨慎搜索将是功能降级,并且可能不可接受。

我目前的假设是,在处理搜索请求时,客户端会在 TCP 级别不雅地切断其连接。然后只需发出一个指定“HTTP Range”的新请求。有趣的是,这种解释与我所经历的笨拙和不可靠的反应是一致的。虽然与其他程序员的一些对话已经足够热烈,但我仍然没有权威的答案。

【讨论】:

  • Meta:最好编辑您的原始问题(或者在我的答案中添加评论,通知我更新);或发布一个单独的后续问题(类似地标记它)。
  • iOS“实时流媒体”将媒体分成许多更小的块,因此它们可以由任何旧的 Web 服务器传送。这里有很多细节:developer.apple.com/library/ios/#documentation/…AFAIK 这不适用于非苹果平台,但请注意,对于使用移动网络的 iOS 应用程序,这是 必需 行为。我不确定这是否适用于音频或视频。
  • 感谢丹的回复。您的回答是有道理的:如果块足够小,则查找请求可以只刷新缓冲区,而不是断开连接。但这意味着一个更可靠的协议,因为客户端需要不断地发出新请求来不断填充缓冲区。
  • 我一直在玩 WireShark,有一些确定的信息我会单独发布。
【解决方案3】:

我能想到的最通用的应用程序是 YouTube 中的 Flash Player。我使用WireShark 来检查HTTP 请求。出乎意料的是,所有内容都作为 URL 搜索参数而不是 HTTP 标头传递。以下是参数列表:

  • 来源
  • ipbits
  • ip
  • cpn
  • 范围
  • MV
  • 速率绕过
  • 新闻碎片
  • 因素
  • 毫秒
  • 保活
  • 身份证
  • fexp
  • 算法
  • 爆裂
  • 垃圾邮件
  • cp
  • 服务器
  • itag
  • 签名
  • 向上
  • 过期

对于所有检查的数据包:

burst=40
algorithm=throttle-factor

只有范围参数似乎因请求而异:

range=13-1781759
range=1781760-3563519
range=3563520-5345279
range=5345280-7127039
range=7127040-8908799

总而言之,这些发现似乎与此线程中讨论的所有内容一致。因此,虽然我知道该协议是由拥有 Flash 的公司编写的专有扩展,但 HTML 5 应该创建一个标准化的替代品。我仍然希望有人能回答这个基本问题:模拟 Flash 的这些功能的底层协议是什么? HTML5 可能不会包含所有这些功能。但这个答案也很重要。

-吉姆

【讨论】:

猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2012-04-25
  • 1970-01-01
  • 1970-01-01
  • 2019-07-01
  • 2011-08-22
  • 2013-04-12
  • 2012-01-18
相关资源
最近更新 更多