【问题标题】:Streaming without Content-Length in response没有 Content-Length 的流式响应
【发布时间】:2011-11-06 08:35:03
【问题描述】:

我正在使用 Node.js、Express(和连接)和 fluent-ffmpeg。

我们希望通过 http 流式传输存储在 Amazon S3 上的音频文件。

我们都在工作,除了我们想添加一个功能,即通过 ffmpeg 对流进行即时转换。

这很好,问题是某些浏览器在实际获取文件之前会提前检查。

包含 Range 标头的传入请求(我们用 S3 的所有信息回复 206)存在一个基本问题:我们需要提前知道文件的内容长度。

我们不知道,因为它正在通过 ffmpeg。

一种解决方案可能是在存储文件时直接在 S3 上写出生成的内容长度(在一个特殊的标头中),但这意味着我们必须经历上传后排队编码的痛苦才能知道未来请求的大小。 这也意味着如果我们更改压缩器或预设,我们必须重新进行所有这些操作,所以这不是一个可行的解决方案。

我们还注意到 Chrome 和 Safari 请求音频标签 src 的方式有很大不同,但这可能是另一个话题的讨论。

事实是,如果没有适当的内容长度标头作为响应,一切似乎都会中断,或者浏览器进入无限循环或随意重新启动流。

想法?

【问题讨论】:

    标签: html node.js ffmpeg connect express


    【解决方案1】:

    这似乎对我有用。

    如果您能确认它是否在您的浏览器中也能提供预期结果,那就太好了。

    res.writeHead(200, {
                           'Transfer-Encoding': 'chunked'
                         , 'Content-Type': 'audio/mpeg'
                         , 'Accept-Ranges': 'bytes' //just to please some players, we do not actually allow seeking
    });
    

    基本上,您告诉浏览器您将使用分块编码进行流式传输。一个问题可能是某些浏览器不喜欢流式传输而不知道他们应该期望总共多少字节。

    【讨论】:

    • 所以你总是向 Range 请求发送 200?
    • @kain,我就是这么做的。这只是因为我实际上不允许玩家寻找。
    • 我们最终为 S3 流式传输构建了一个完美的代理。它所做的是有一个额外的身份验证层,对 S3 隐藏真实的 url,并动态转换文件,所有这些都无需触及文件系统;我们仍在研究动态编码的细节,因为我们希望符合要求,但我们会永久采用您的解决方案。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-03-08
    • 2013-09-25
    • 1970-01-01
    • 1970-01-01
    • 2011-02-16
    • 2020-07-15
    相关资源
    最近更新 更多