我通過rtmp從Amazon Cloudfront流式傳輸視頻。視頻開始播放時間很長，我也沒有辦法找出原因。通常情況下，我會使用Firebug或Web Inspector中的「Net」面板獲得良好的第一印象，即資產何時開始加載以及需要發送多長時間（可以指示問題是在服務器端還是網絡上與瀏覽器呈現相比）。但由於視頻是在Flash播放器（本例中爲Flowplayer）中播放的，因此無法收集關於視頻流狀態的任何信息。此外，由於它是從Amazon Cloudfront提供的，因此我無法在服務器上放置任何類型的調試或測量工具（如果此類工具存在）。如何解決流視頻（rtmp）性能問題？
所以......我的問題是：有什麼方法可以去調查這個問題？我希望能夠在前端（流式播放器）或後端（Cloudfront）上調整一些設置，但是無法測量任何東西甚至無法理解問題出在哪裏，我不知所措至於這些可能是什麼。
有關如何解決流視頻性能問題的任何想法？
您可以使用WireShark（可以diesect RTMP）或Fiddler來檢查發生了什麼......另一點（除客戶端和服務器之外）要牢記的是您的ISP。
要深入挖掘，您可以使用此http://rtmpdump.mplayerhq.hu/或http://www.fluorinefx.com/或http://www.broccoliproducts.com/softnotebook/rtmpclient/rtmpclient.php。
你需要記住，RTMP是不理想的，因爲它通常繞過代理並嘗試進行直接連接......如果這不起作用，它可以回退，但這意味着一段時間已經過去了（它等待連接超時等）...如果您有一個選項可以將CloudFront/Flowplayer設置爲RTMPT，那麼我會建議您這樣做，因爲它使用端口80進行連接。
想必 - 如果你去嘗試觀看視頻 - 然後回來20分鐘後再次打 - 它加載很快？
SAN - >邊緣服務器--->客戶端
這是所有的孔中，在具體使用情況良好（即原產地的內容，大量長時間運行的高速緩存的文件大小小） - 但是，它成爲一個問題當它被擴大時，許多媒體主機通過系統運行內容，例如CloudFront。
他們保留在其邊緣服務器上的媒體緩存經常被轉儲 - 在緩存填充後 - 開始從緩存中最老的文件轉儲 - 因此，如果您有大量視頻文件不經常查看 - 他們不會坐在邊緣服務器緩存中，並花費很長時間才能轉移到邊緣 - 因此，給予了絕對可怕的最終用戶體驗。
例如，youtube也是如此 - 去看一些隨機模糊，持續時間長的視頻 - 並通過幾個代理嘗試，所以你碰到不同的邊緣服務器，你會看到完全相同的事情發生。
不，它似乎以相同的緩慢加載，無論請求多少次相同的視頻。我看到你在說什麼，如果它沒有得到很多瀏覽，需要經常從緩存中重新加載 - 如果是這種情況，這是否意味着我只是運氣不好，不應該使用Amazon CloudFront？我認爲流視頻會更快，因爲它可以開始發送內容，而無需首先加載整個文件（但也許*服務器*需要首先加載整個文件？）。感謝您的幫助。 –
我注意到從雲端流式傳輸RMTP時存在非常明顯的延遲。我發現從亞馬遜S3存儲桶切換到直連http進程使得延遲時間消失。
您能解釋一下您的聲明「RTMP不理想，因爲它通常繞過代理並嘗試進行直接連接」與加載速度有什麼關係？我不明白如何切換到使用端口80的RTMPT會使速度更快。我對連接的人沒有任何問題 - 只需加載速度。謝謝。 –
RTMP試圖直接連接...如果這是不可能的，它會回落...但直到它回落的時間可能是相當明顯的，因爲根據具體的網絡screnario，這可能意味着RTMP等待，直到超時發生......你說過需要很長時間才能開始播放......我所描述的可能是一個解釋... – Yahia
好的，謝謝你的迴應。我還沒有嘗試過任何建議，但他們確實看起來非常有前途 - 其他人沒有迴應，所以你得到了獎勵！再次感謝您的幫助。 –