Streaming 如何解决流式视频（rtmp）性能问题？

我从Amazon Cloudfront通过rtmp传输视频。视频要花很长时间才能开始播放，我无法找出原因。通常情况下，我会使用Firebug或Web Inspector中的“网络”面板来获得良好的第一印象，即资产何时开始加载以及发送所需的时间（这可以表明问题是在服务器端还是网络上，而不是浏览器渲染）。但由于视频是在Flash播放器（本例中为Flowplayer）中播放的，因此无法收集有关流状态的任何信息。另外，由于它是由AmazonCloudFront提供的，所以我不能在服务器上放置任何类型的调试或测量工具（如果存在这样的工具的话）

所以。。。我的问题是：我可以用什么方法来调查这个问题？我希望可以在前端（flowplayer）或后端（Cloudfront）上调整一些设置，但由于无法测量任何内容，甚至无法了解问题所在，我无法确定这些设置可能是什么

关于如何解决流媒体视频性能问题，您有什么想法吗？

您可以使用（can diessect RTMP）或检查正在发生的情况。。。要记住的另一点（除了客户端和服务器）是您的ISP

要深入挖掘，您可以使用此或

---

您需要记住，RTMP并不理想，因为它通常会绕过代理并尝试进行直接连接。。。如果这不起作用，它可以回退，但这意味着已经过了一段时间（它等待连接超时等等）。。。如果您可以选择将CloudFront/Flowplayer设置为RTMPT，那么我建议您这样做，因为它使用端口80进行连接。

大概-如果您尝试观看视频-然后20分钟后返回并再次点击-它加载得很快

SAN->边缘服务器-->客户端

在特定的用例中（即原始内容的小文件大小、长时间运行的大缓存），这一切都很好——但是，当它被扩展时，它会成为一个问题，许多媒体主机通过系统（即CloudFront）运行内容

他们保留在边缘服务器上的媒体缓存经常被转储—缓存填满后—从缓存中最旧的文件开始转储—因此，如果您有不经常查看的大型视频文件—它们不会位于边缘服务器缓存中，并且需要很长时间才能传输到边缘—因此，给最终用户带来了极其可怕的体验

---

例如，youtube也是如此——去看一些随机模糊的、高持续时间的视频——并通过几个代理进行尝试，所以你点击不同的边缘服务器，你会看到完全相同的事情发生。

我注意到从cloudfront流式传输RMTP时有一个非常明显的延迟。我发现从amazon S3 bucket切换到直接http progressive会消除延迟时间。

您能解释一下“RTMP并不理想，因为它通常会绕过代理并尝试直接连接”的说法与加载速度有什么关系吗？我不明白如何切换到使用端口80的RTMPT会使速度更快。我没有任何人连接的问题——只是加载速度。谢谢。RTMP尝试直接连接。。。如果这不可能，它会后退。。。但是，它后退的时间可能相当明显，因为这取决于特定的网络，这可能意味着RTMP等待超时发生。。。你说播放开始需要很长时间。。。我所描述的可能是一个解释…好的，谢谢你的回答。我还没有尝试过你的任何建议，但它们看起来确实很有希望——而且没有其他人响应，所以你得到了赏金！再次感谢您的帮助。只需将我的流媒体链接设置为RTMPT，它将一小时长视频的加载时间从10-30秒缩短为1-3秒开始，感谢您的建议，这是一个简单的解决方案！编辑：这也使用带有自定义策略的签名URL。否，无论请求多少次相同的视频，它似乎都以相同的速度加载。我明白你的意思了，如果没有太多的浏览量，就需要频繁地从缓存中重新加载——如果是这样，这是否意味着我运气不好，不应该使用Amazon CloudFront？我认为流式视频会更快，因为它可以开始发送内容，而不必先加载整个文件（但可能服务器需要先加载整个文件？）。谢谢你的帮助。