如何对流视频 (rtmp) 性能进行故障排除？
我正在通过 Amazon Cloudfront 的 rtmp 流式传输视频。视频需要很长时间才能开始播放，我无法弄清楚原因。通常我会使用 Firebug 或 Web Inspector 中的“Net”面板来获得有关资产何时开始加载以及发送需要多长时间的良好第一印象（这可以表明问题是在服务器端还是网络上）与浏览器渲染）。但由于视频是在 Flash 播放器（本例中为 Flowplayer）中播放，因此无法收集有关流状态的任何信息。此外，由于它由 Amazon Cloudfront 提供服务，因此我无法在服务器上放置任何类型的调试或测量工具（如果存在这样的工具）。
所以...我的问题是：我可以通过哪些方法来调查这个问题？我希望我可以在前端（flowplayer）或后端（Cloudfront）上调整一些设置，但无法测量任何内容，甚至无法理解问题出在哪里，我不知所措至于那些可能是什么。
关于如何解决流视频性能问题有什么想法吗？
I'm streaming videos via rtmp from Amazon Cloudfront. Videos are taking a loooong time to start playing, and I don't have any way of figuring out why. Normally I'd use the "Net" panel in Firebug or Web Inspector to get a good first impression of when an asset starts to load and how long it takes to be sent (which can indicate whether the problem is on the server end or network versus the browser rendering). But since the video is played within a Flash player (Flowplayer in this case), it's not possible to glean any info about the status of the stream. Also since it's served from Amazon Cloudfront, I can't put any kind of debugging or measuring tools on the server (if such a tool even exists).
So... my question is: what are some ways I can go about investigating this problem? I'm hoping there would be some settings I can tweak on either the front-end (flowplayer) or back-end (Cloudfront), but without being able to measure anything or even understand where the problem is, I'm at a loss as to what those could be.
Any ideas for how to troubleshoot streaming video performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以使用WireShark（可以解析RTMP）或 Fiddler 检查发生了什么...要记住的另一点（除了客户端和服务器）是您的 ISP。
要深入挖掘，您可以使用此 http://rtmpdump.mplayerhq.hu/ 或 http://rtmpdump.mplayerhq.hu/ 。 fluinefx.com/">http://www.fluinefx.com/ 或 http://www.broccoliproducts.com/softnotebook/rtmpclient/rtmpclient.php。
您需要记住，RTMP 并不理想，因为它通常会绕过代理并尝试建立直接连接...如果这不起作用，它可以回退，但这意味着已经过去了一段时间（它等待连接超时等）...如果您可以选择将 CloudFront/Flowplayer 设置为 RTMPT，那么我建议您这样做，因为它使用端口 80 进行连接。
You can use WireShark (can diessect RTMP) or Fiddler to check what is going on... another point (besides the client and the server) to keep in mind is your ISP.
To dig deeper you can use this http://rtmpdump.mplayerhq.hu/ OR http://www.fluorinefx.com/ OR http://www.broccoliproducts.com/softnotebook/rtmpclient/rtmpclient.php.
You need to keep in mind that RTMP isn't ideal since it usually bypasses proxies and tries to make direct connection... if this doesn't work it can fallback, but that means that some time has already passed (it wait for a connection timeout etc.)... if you have an option to set CloudFront/Flowplayer to RTMPT then I would recommend doing so since that uses Port 80 for the connection.
大概 - 如果您尝试观看视频 - 然后 20 分钟后回来并再次点击 - 它加载得很快？
SAN->边缘服务器--->客户端
这在特定用例中（即原始内容的小文件大小、长时间运行的缓存较大）一切都很好 - 但是，当它横向扩展时，它会成为一个问题，因为许多媒体主机通过系统（即 CloudFront）运行内容。
他们保留在边缘服务器上的媒体缓存经常被转储 - 缓存填满后 - 从缓存中最旧的文件开始转储 - 因此，如果您有不经常查看的大型视频文件 - 它们不会位于边缘服务器缓存，并且需要很长时间才能传输到边缘 - 因此，会给最终用户带来非常可怕的体验。
例如，YouTube 也是如此 - 随机观看一些晦涩的、持续时间较长的视频 - 并通过几个代理进行尝试，因此您访问不同的边缘服务器，您会看到完全相同的事情发生。
Presumably - if you go and attempt to view a video - then come back 20min later and hit it again - it loads quickly?
SAN -> Edge Servers ---> Client
This is all well and good in a specific use case (i.e. small filesize of the origin content, large long running cache) - but, it becomes an issue when it's scaled out, with lots of media hosts running content through the system i.e. CloudFront.
The media cache they keep on their edge servers gets dumped fairly often - after the cache is filled - start dumping from the oldest file in cache - so if you have large video files that are not viewed often - they won't be sitting in the edge server cache, and take a long time to transfer to the edges - thus, giving an utterly horrific end user experience.
The same is true of youtube, for example - go and watch some randomly obscure, high duration video - and try it through a couple of proxies, so you hit different edge servers, you'll see exactly the same thing occur.
当从 cloudfront 传输 RMTP 时，我注意到有非常明显的延迟。我发现从亚马逊 S3 存储桶切换到直接 http 渐进式可以消除延迟时间。
I noticed a very noticable lag when streaming RMTP from cloudfront. I found that switching to straight http progressive from the amazon S3 bucket made the lag time go away.