爲什麼RTMP流式協議的url路徑彼此不同？

最近，我正在做一些關於RTMP流式處理的工作，即使用Flowplayer與Edgecast Streaming服務和CloudFront Streaming服務集成。爲什麼RTMP流式協議的url路徑彼此不同？

基本概念很容易遵循，但不同供應商的格式確實浪費了我很多時間來弄清楚。例如，爲了使邊緣快樂，根據文檔，您需要指定文件名的格式爲mp4：filename.mp4，flv：filename（不帶.flv擴展名）和mp3：filename（不帶.flav）。 mp3擴展名）。

但對CloudFront的，這是一個不同的故事，MP4：filename.mp4，文件名（無FLV：前綴，並沒有.flv擴展）和MP3：文件名（不含.mp3擴展名）。

這種格式讓人們在今天嘗試使用Edgecast的loadToEdge函數時，Accept的格式爲filename.mp4（不帶mp4：前綴），filename.flv（不帶flv：前綴）和mp3：filename。 MP3。

正如你所看到的，基本上沒有任何邏輯，你必須猜測並嘗試所有不同的組合，以使其最終工作。

我只是想知道，如果有人有想法，爲什麼不同的提供商以所有定製的方式實現他們的流？或者，Adobe的錯誤沒有統一的形式，或者只是服務提供商使用他們喜歡的任何東西。

謝謝！

2012-01-24 Yudong Li

這與RTMP協議無關。 CloudFront和EdgeCast的約定。 – ciphor

謝謝@ciphor，我想這就是爲什麼我提出這個問題。我知道這是不同提供商的約定，但我不明白的是爲什麼在這樣的約定中，特別是mp3 :, mp4 :, flv：前綴。我沒有直接看到添加這些前綴的好處。爲什麼不只是簡單地使用普通的url？在這種情況下，沒有任何定製的url，但都有統一的地址。 –

這是關於實施。 URL格式（包括擴展名）與

無關。作爲比喻，您的問題就像詢問「爲什麼有些網站的網址不同於其他網址？」的服務了一個圖像的兩個不同但可行的方法例子：

這一切都在EdgeCast，亞馬遜，等的程序員想要如何實現他們的CDN。我確信它有一些邏輯，經過深思熟慮或沒有。可能有些需要處理遺留系統，客戶端和URL。

它與FMS本身無關。就像上面的比喻網址與他們服務的網絡服務器無關。

2012-02-07 07:37:41

是的，我知道這可能僅僅是由於一些開發者的一時決定，而沒有完全檢查之前和之後。它也可能與他們的遺留系統有關。這個問題可能只能由他們回答。 –

回答