为什么 RTMP 流协议的 url 路径彼此不同? [英] Why RTMP streaming protocal's url path different from each other?

问题描述

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

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.

例如，为了让edgecast开心，根据文档，需要指定文件名格式为mp4:filename.mp4、flv:filename(不带.flv扩展名)和mp3:filename(不带.mp3)扩展名).

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).

但是对于 CloudFront，mp4:filename.mp4、filename(没有 flv:prefix，也没有 .flv 扩展名)和 mp3:filename(没有 .mp3 扩展名)是另一回事.

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).

今天我尝试使用Edgecast的loadToEdge函数时，这种格式让人更加沮丧，接受的格式是filename.mp4(没有mp4:前缀)、filename.flv(没有flv:前缀)和mp3:filename.mp3.

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.

我只是想知道是否有人知道为什么不同的提供商以所有定制的方式实施他们的流媒体?或者是Adobe没有统一的形式的错，还是服务提供商可以随心所欲地使用.

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.

谢谢！

推荐答案

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

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.png
• http://server.com/image/question?number=87&image=65.

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

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.

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

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.

这篇关于为什么 RTMP 流协议的 url 路径彼此不同?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！