为什么RTMP流协议的url路径不同？
最近我在做一些关于RTMP流媒体的工作，即使用Flowplayer与Edgecast Streaming服务和CloudFront Streaming服务集成。
基本概念很容易理解，但是不同提供商的格式确实浪费了我很多时间来弄清楚。
例如，为了使 Edgecast 满意，根据文档，您需要以 mp4:filename.mp4、flv:filename（不带 .flv 扩展名）和 mp3:filename（不带 .mp3 扩展名）的格式指定文件名。
但对于 CloudFront 来说，mp4:filename.mp4、filename（没有 flv:prefix，也没有 .flv 扩展名）和 mp3:filename（没有 .mp3 扩展名）是一个不同的故事。
这种格式让人更加沮丧，今天我尝试使用Edgecast的loadToEdge函数时，接受的格式是filename.mp4（不带mp4：前缀）、filename.flv（不带flv：前缀）和mp3：filename.mp3。
正如您所看到的，基本上没有逻辑，您必须猜测并尝试所有不同的组合才能使其最终起作用。
我只是想知道是否有人知道为什么不同的提供商以所有定制的方式实现他们的流媒体？或者是 Adobe 的错，没有统一的形式，或者只是由服务提供商使用他们喜欢的任何形式。
谢谢你！
Recently I'm doing some work on RTMP streaming, that is using Flowplayer to integrate with Edgecast Streaming service and CloudFront Streaming service.
The basic concept is easy to follow, but the format of different providers really waste me a lot of time to figure out.
For example, in order to make edgecast happy, according to the documentation, you need to specify filename in the format of mp4:filename.mp4, flv:filename (without .flv extension) and mp3:filename (without .mp3 extension).
But for CloudFront, it's a different story that mp4:filename.mp4, filename (no flv:prefix, and no .flv extension) and mp3:filename (without .mp3 extension).
This format makes people even more frustrating when today I try to use Edgecast's loadToEdge function, the format the accept is filename.mp4 (without mp4: prefix), filename.flv (without flv: prefix) and mp3:filename.mp3.
As you can see, basically there is no logic there and you have to guess and try all different combinations to make it finally working.
I just would like to know if anyone has idea about why different providers implement their streaming in all customized way? Or is it Adobe's fault doesn't have a unified form or it's just up to service providers to use whatever they like.
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一切都与实施有关。 URL 格式（包括扩展名）与 无关 打个比方
，您的问题就像问“为什么某些网站的 URL 与其他网站不同？” 两种不同但可行的服务方式示例图像：
http://server.com/question/87/why/65.pnghttp://server.com/image/question?number=87&image=65< /代码>。这一切都与 EdgeCast、Amazon 等公司的编码人员希望如何实施他们的 CDN 相关。我确信其中有一定的逻辑，无论是否经过深思熟虑。可能有些需要处理遗留系统、客户端和 URL。
与FMS本身无关。就像上面的类比一样，URL 与为其提供服务的 Web 服务器无关。
It's all about implementation. The URL format, including extensions, has nothing to do with
As an analogy, your question is like asking "Why do some websites have different URLs than others?" Example of two different yet viable ways of serving up an image:
http://server.com/question/87/why/65.pnghttp://server.com/image/question?number=87&image=65.It's all about how the coders at EdgeCast, Amazon, et al wanted to implement their CDN. I'm sure there was some logic to it, well thought out or not. And probably some need to deal with legacy systems, clients and URLs.
It has nothing to do with FMS itself. Just like the above analogy's URLs have nothing to do with the web server they are served from.