所以我是一名软件工程师,试图了解流媒体工作原理的一些细节。我花了一天的大部分时间来了解与我的应用程序相关的各种编解码器、容器格式和流媒体协议。到目前为止,这是我的理解它的工作原理,这很可能会被误导:
- 流媒体实际上可以归结为容器格式和流媒体协议:
- 所有音频数据均通过音频编解码器编码为音频比特流
- 所有视频数据均被编码(再次通过编解码器)为视频比特流
- 两个流合并(多路复用?)合为一个容器最终变成一个文件(例如MP4等)
- 一个特别的媒体服务器然后通过某种标准流媒体协议(例如 RTSP)将此容器(MP4 文件或其他格式)提供给客户端(可能是在某人的浏览器中运行的 HTML5 视频播放器)
- 对于浏览器客户端,我假设浏览器本身有一个 RTSP 客户端,然后它会以某种方式向用户呈现 HTML5 视频播放器
- 我可以托管来自网络服务器,如 nginx 或 httpd,但由于这些服务器不是 RTSP 服务器,因此只能将 MP4 请求视为下载请求,因此无法流式传输媒体文件
- 同样,如果我使用
curl
从 nginx 服务器获取文件,由于curl
nginx 和 RTSP 都不支持,它将被视为文件下载
- 同样,如果我使用
- 但是,当我从流媒体服务器(VideoLAN、Red5、Wowza 等)托管 MP4 文件,并使用 RTSP 客户端(或任何支持的流媒体客户端)从该服务器请求流时,只有那时是否有任何实际流媒体发生
- 因此,尽管 YouTube 或 Vimeo 的“视频”托管在 HTTP 服务器通过 HTTP(S) 提供的 HTML 页面上,我仍然认为这些页面上嵌入的视频播放器(视频实际播放的地方)实际上正在启动第二个后续连接到流媒体服务器,并且流媒体是通过 RTSP 或其他非 HTTP 协议进行的
这就是我的理解,我想首先问一下,如果我上面说的有误,请先纠正我!假设我或多或少是正确的:
运行在 HTML 页面内并由 HTML 服务器提供服务的流媒体播放器如何与流媒体服务器(服务 RTSP 请求)建立流媒体(RTSP 等)连接?
答案1
运行在 HTML 页面内并由 HTML 服务器提供服务的流媒体播放器如何与流媒体服务器(服务 RTSP 请求)建立流媒体(RTSP 等)连接?
常见应用
实时流媒体传输协议目前似乎更多地用于直接现场直播(例如 IP 摄像头)或重新流式传输(就像发动机)从物理位置流式保存的媒体文件通过带有嵌入式播放器的 HTTP 网络播放界面。
看起来实时流媒体传输协议是有状态的协议,在流式传输时它更多地使用 UDP 而不是 TCP,它更多地用作连接到 TCP/IP 网络的服务器设备(如 IP 摄像头),并通过 UDP 等提供流。然后,你作为同一网络上的客户端连接到这些源(服务器),然后你可以发出RTSP 请求以便相应利用。
协议指令
虽然在某些方面与 HTTP 类似,但 RTSP 定义了可用于控制多媒体播放的控制序列。HTTP 无国籍者,RTSP 具有状态;需要跟踪并发会话时,会使用标识符。与 HTTP 一样,RTSP 使用 TCP 来维持端到端连接,虽然大多数 RTSP 控制消息由客户端发送到服务器,但有些命令会朝另一个方向传输(即从服务器到客户端)。
这里介绍的是基本的 RTSP 请求。一些典型的 HTTP 请求(如 OPTIONS 请求)也可用。TCP 和 UDP 的默认传输层端口号均为 554[3],后者很少用于控制请求。
无国籍
无状态协议不需要服务器在多个请求期间保留每个通信伙伴的会话信息或状态。相反,需要在服务器上保留内部状态的协议称为 有状态的协议。
无状态的一个缺点是可能需要在每个请求中包含额外的信息,并且这些额外的信息需要由服务器进行解释。
逻辑流程
我理解的这种形式的流媒体的流程是:
- 媒体内容所在的服务器将以适当的格式和片段对视频/音频数据内容进行封装、压缩、编码等,以便进行流传输
- 监听流媒体访问连接的 Web 服务器将提供流媒体所需的所有资源
- 客户端请求并下载相应的资源和文件,然后通过配置的URL指针和其他参数将它们以连续的方式组装起来以供播放。客户端级别的播放软件将按顺序传输的数据包组装起来,以便正确播放内容。
请参阅流媒体技术下面的部分对 HTTP 和 RTSP 进行了一般比较。
此外
在下面10 个你不应该自己托管视频的理由部分中我引用了一些切中要点的部分,以帮助“一般性”地回答您的问题,而不会太具体。
本质上,它表示嵌入媒体播放器控件的网站将:
- (1)在客户端“连接并请求”时检测客户端 Web 浏览器设置,并
- (2)这会将编解码器和任何其他客户端检测设置设置为适用的参数值,然后
- (3)它将直接从托管视频和音频文件的流媒体服务器流式传输视频根据嵌入式媒体播放器配置中指向托管服务器上媒体文件的 URL 的进一步代码。
流媒体技术
客户端浏览器必须从服务器接收数据并将其传递给流媒体应用程序进行处理。流媒体应用程序将数据转换为图片和声音。此过程成功的一个重要因素是客户端接收数据的速度要快于应用程序显示信息的速度。多余的数据存储在缓冲区中——应用程序内为数据存储保留的内存区域。如果数据在两个系统之间传输时出现延迟,缓冲区就会清空,材料的呈现将不流畅。
HTTP 协议
HTTP 是互联网上文档链接的主要方式。客户端与包含要流式传输的文件的服务器建立连接,检索文件并关闭连接。HTTP 服务器向浏览器传达要传输的文件类型。
使用 HTTP 的好处
使用 HTTP 流式传输文件时,不需要特殊的流式传输服务器。只要您的浏览器能够识别 MIME 类型,它就可以从 HTTP 服务器接收流式传输文件。使用 HTTP 流式传输文件的一个明显优势是它可以穿过防火墙并利用代理服务器。
一些缺点
HTTP 流式传输使用 TCP/IP(传输控制协议和 Internet 协议)来确保文件的可靠传输。此过程会检查丢失的数据包并要求重新传输。当您希望在传输过程中丢失数据时忽略数据,以便动态文件继续播放时,这在流式传输场景中会成为问题。HTTP 无法检测调制解调器速度,因此服务器管理员必须有目的地为具有不同连接类型的服务器用户生成不同压缩率的文件。在高需求情况下,不建议从 HTTP 服务器流式传输文件。
RTSP 协议
RTSP 是大多数流媒体服务器供应商使用的标准协议。RTSP 服务器使用 UDP(用户数据报协议)传输媒体文件。UDP 不会持续检查文件是否已到达目的地。这对于流媒体应用程序来说是一个优势,因为它允许在延迟不太长的情况下中断文件传输。这种方法的结果是有时会丢失数据,但如果延迟较小,文件将继续播放。
10 个你不应该自己托管视频的理由
我们正在讨论嵌入视频与自托管视频
首先,将视频文件上传到第三方视频托管服务,如 YouTube、Vimeo 或 Wistia。
然后,您复制他们提供给您的一小段代码,并将其粘贴到您自己的 WordPress 网站上的帖子或页面中。视频将出现在您网站上您粘贴嵌入代码的位置,但视频本身是从视频托管服务器流式传输的,而不是托管您的 WordPress 网站的您自己的 Web 服务器。
4. 网络视频没有单一的文件格式标准
当前的 HTML5 草案规范并未指定浏览器应支持哪些视频格式。因此,主流网络浏览器出现了分化,每个浏览器都支持不同的格式。Internet Explorer 和 Safari 可以播放 H.264 (MP4) 视频,但不能播放 WebM 或 Ogg。Firefox 可以播放 Ogg 或 WebM 视频,但不能播放 H.264。值得庆幸的是,Chrome 可以播放所有主流视频格式,但如果您想确保您的视频可以在所有主流网络浏览器上播放,则必须将视频转换为多种格式:.mp4、.ogv 和 .webm
5. 希望您非常喜欢转换视频。
大多数观众可能会使用高速互联网连接从台式机或笔记本电脑观看您的视频。对于这些观众,您需要提供大型高清文件,以便他们可以全屏观看(如果他们愿意的话)。通常,这意味着高流比特率(5000 – 8000 kbps)的 1080p 或 720p 文件。
但您还需要编码一个较小、分辨率较低的版本,以便传送至手机和平板电脑等移动设备,以及传送给互联网连接速度较慢的观众。
6.视频播放器
视频播放器是您在网站上安装的一小型网络软件,它会自动检测哪个设备正在请求您的视频及其连接速度,然后向该用户提供适当的版本。
7. 繁琐的代码(或短代码)
无论您使用第三方插件还是 WordPress 的内置视频功能,您都需要创建一些代码来告诉视频播放器您创建了哪些格式以及它们在服务器上的位置。它看起来像这样……
<video poster="movie.jpg" controls> <source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/> <source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/> <source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/> <p>This is fallback content</p> </video>
那么,向您的网站添加视频的最佳解决方案是什么?
只需使用第三方视频托管服务,然后将视频嵌入到您的 WordPress 帖子或页面中。
步骤1:将您的视频上传到其中一个流行且成熟的视频托管服务,例如 Vimeo PRO。
第二步:视频上传完毕并准备观看后,复制视频的 URL。返回 WordPress 网站并将 URL 粘贴到您希望视频出现的帖子或页面中。
当人们查看您的页面时,视频将显示在您粘贴 URL 的位置。但视频文件本身将从视频托管商的服务器流式传输,而不是托管 WordPress 网站的您自己的服务器。
嵌入的视频播放器将自动检测用户的设备、浏览器和互联网连接速度,然后向他们提供适当版本的视频文件。无需在您的网站上安装任何内容。无需更新插件。无需复杂的代码。
答案2
下面我将主要讨论您的问题:视频在浏览器中显示时会发生什么。这个主题很广泛,因此我只会涉及相关内容。
HTML5 引入了<VIDEO>
标签,解决了使用 JavaScript 和 CSS 将显示的视频集成到浏览器中的问题。以前的<OBJECT>
标签需要外部软件,与页面的集成度很差。新标签实际上要求浏览器也成为视频播放器,尽管没有强加任何标准。结果就是标准完全分裂,唯一的解决方案是视频服务器将提供多种视频格式,并在标签中指定所有这些替代源<VIDEO>
,浏览器将从中选择它支持的格式。
具有多个来源的标签示例:
<video width=320 height=240 controls poster=image.jpg>
<source src="movie.mpd">
<source src="movie.webm">
Your browser does not support the video tag.
</video>
标签<VIDEO>
本身与协议无关,因此可以使用浏览器支持的任何协议,包括 RTSP。支持MPEG-DASH 协议
(HTTP 上的动态自适应流)最近变得非常全面,因此它可以在大多数设备和浏览器上播放,也可以使用 HTML5,这意味着不需要额外的插件。请参阅此设备和浏览器兼容性图表。 也可以看看这篇 Mozilla 文章准备服务器以提供 MPEG-DASH。DASH 通过 HTTP 工作,因此只要您的 HTTP 服务器支持字节范围请求并且设置为使用 提供 .mpd 文件,它就可以工作mimetype="application/dash+xml"
。
客户端和服务器之间的正常交互看起来类似于以下内容。对于 HTML5 视频,浏览器也是播放器,尽管它可能会打开新的连接进行播放。
初始连接提供客户端用来显示视频的元数据。如果使用 RTSP 协议获取该元数据,则稍后会创建 RTP 连接来传输视频+音频数据。RTCP 协议用于向服务器传输其他命令。
RTP、RTCP 和 RTSP 都在不同的端口上运行。通常,当 RTP 在端口 N 上时,RTCP 在端口 N+1 上。RTP 会话可能包含要在接收端合并的多个流;例如,音频和视频可能在不同的频道上。
为了不让任何人被排除在您的内容之外,您应该提供免版税编解码器、webM 或 Theora 和 H.264 视频,以及 Vorbis 和 MP3 音频。(说起来容易,做起来难。)
以下是 RTSP 的具体情况:
客户端与服务器建立 TCP 连接,通常在 TCP 端口 554(RTSP 的知名端口)上。
然后,客户端将开始发出一系列格式与 HTTP 类似的 RTSP 标头命令,每个命令都由服务器确认。在这些 RTSP 命令中,客户端将向服务器描述会话要求的详细信息,例如它支持的 RTSP 版本、用于数据流的传输以及任何相关的 UDP 或 TCP 端口信息。此信息使用 DESCRIBE 和 SETUP 标头传递,并在服务器响应中用会话 ID 进行扩充,客户端和任何临时代理设备都可以使用该会话 ID 在进一步的交换中识别流。
一旦传输参数协商完成,客户端将发出PLAY命令,指示服务器开始传送RTP数据流。
一旦客户端决定关闭流,就会发出 TEARDOWN 命令以及会话 ID,指示服务器停止与该 ID 关联的 RTP 传送。
进一步阅读:
答案3
这是一个快速而粗略的答案-
在网络上播放视频和实际实时播放视频之间存在差异。
播放是通过网页中包含的播放器完成的(可能使用 flash、JS 或 html5 视频对象)。客户端(浏览器)下载并运行此播放器。播放器依次从简单的下载 URL 获取视频。事实上,即使在 Youtube 上,也有一些程序允许您直接访问托管的视频文件并像下载任何文件一样下载它们。由于系统使用常规的旧下载链接,因此不需要复杂的流媒体协议(如 RTSP)
实时流媒体(比如,通过网络摄像头)……嗯,比较棘手。Flash 内置了此功能,但不应再使用。HTML5 视频不支持实时流媒体,但人们已经能够通过让文件托管服务器不断更改其提供的视频文件来“欺骗”它。