为什么 RTMP 流协议的 url 路径彼此不同？答案

【问题标题】：Why RTMP streaming protocal's url path different from each other?为什么 RTMP 流协议的 url 路径彼此不同？
【发布时间】：2012-02-17 09:29:05
【问题描述】：

最近我正在做一些RTMP流媒体的工作，即使用Flowplayer与Edgecast Streaming服务和CloudFront Streaming服务集成。

基本概念很容易理解，但是不同提供商的格式确实浪费了我很多时间去弄清楚。

例如，为了让 edgecast 快乐，根据文档，您需要指定格式为 mp4:filename.mp4、flv:filename（不带 .flv 扩展名）和 mp3:filename（不带 .mp3扩展名）。

但对于 CloudFront，mp4:filename.mp4、文件名（无 flv:prefix 和无 .flv 扩展名）和 mp3:filename（无 .mp3 扩展名）是另一回事。

今天尝试使用Edgecast的loadToEdge函数时，这种格式让人更加沮丧，accept的格式是filename.mp4（不带mp4：前缀）、filename.flv（不带flv：前缀）和mp3：filename.mp3 .

如您所见，基本上没有逻辑，您必须猜测并尝试所有不同的组合才能使其最终起作用。

我只是想知道是否有人知道为什么不同的提供商以所有定制的方式实施他们的流媒体？还是 Adobe 的错没有统一的形式，还是只能由服务提供商随意使用。

谢谢！

【问题讨论】：

这与RTMP协议无关。只是 CloudFront 和 EdgeCast 的约定。
谢谢@ciphor，我想这就是我提出这个问题的原因。我知道这是不同提供商的约定，但我不明白为什么在这样的约定中，尤其是使用 mp3:、mp4:、flv: 前缀。通过添加这些前缀，我没有直接看到任何好处。为什么不简单地使用纯 url？在这种情况下，不再有自定义的 url，但都有一个统一的地址。

【解决方案1】：

一切都与实施有关。 URL 格式，包括扩展名，与

无关

打个比方，您的问题就像问“为什么有些网站的 URL 与其他网站不同？” 提供图片的两种不同但可行的方式示例：

这完全是关于 EdgeCast、亚马逊、等的编码人员希望如何实施他们的 CDN。我敢肯定它有一些逻辑，无论是否经过深思熟虑。可能有些人需要处理遗留系统、客户端和 URL。

它与 FMS 本身无关。就像上面类比的 URL 与提供它们的 Web 服务器无关。

【讨论】：