通过示例从HTML页面中流媒体播放

所以我是一名软件工程师,试图了解有关流媒体的一些细节。我花了大部分时间来理解与我的应用程序相关的各种编解码器、容器格式和流媒体协议。到目前为止,这是我对它的理解,但可能存在误导:

流媒体实际上归结为“容器格式”和“流媒体协议”: - 所有音频数据通过音频编解码器编码成音频比特流 - 所有视频数据再次通过编解码器编码成视频比特流 - 这两个流被合并(多路复用)到一个容器中,最终成为一个文件(如MP4等) - 一个特殊的媒体服务器通过某种标准的流媒体协议(如RTSP)将这个容器(MP4文件或其他格式)提供给客户端(可能是运行在浏览器内的HTML5视频播放器) - 对于浏览器客户端而言,我猜测浏览器本身具有一个RTSP客户端,然后以某种方式呈现给用户的HTML5视频播放器 我可以从Web服务器(如nginx或httpd)托管一个MP4文件,但由于这些服务器不是RTSP服务器,只能将对MP4的请求视为下载请求,因此无法流式传输媒体文件。 同样,如果我使用curl从nginx服务器获取文件,由于curl和nginx都不支持RTSP,它将被视为文件下载。 但是,当我从流媒体服务器(VideoLAN、Red5、Wowza等)托管一个MP4文件,并使用RTSP客户端(或任何支持的流媒体客户端)向该服务器请求流媒体时,只有在这种情况下才会发生实际的流媒体传输。 因此,即使YouTube或Vimeo的“视频”是通过HTTP服务器通过HTTP(S)提供的HTML页面托管的,我猜测这些页面上的嵌入式视频播放器(实际上播放视频的地方)实际上是启动了第二个、后续的连接到流媒体服务器,并且流媒体是通过RTSP或其他非HTTP协议进行的。

那就是我的理解,如果我上面说的有任何不正确之处,请先纠正我!假设我大致正确:

流媒体播放器如何在HTML页面内运行并由HTML服务器提供服务,与流媒体服务器(提供RTSP请求)建立流媒体(RTSP等)连接?


4为什么要踩一下投票?这不是一个重复的问题,而是与话题相关的,绝对展示了研究成果,并且是一个SSCCE - smeeb
为什么通过HTTP进行流媒体传输会很奇怪呢?流媒体基本上就是“边下载边播放”,之后丢弃数据(可选择性缓冲),而不是等待下载完成。这种概念在编程中也被用于其他类型的流处理。 - Daniel B
嗯,读完被删除答案上的评论后,我终于弄清楚了你在问什么:“如何利用HTTP流式传输进行查找工作?你无法将时间戳转换为文件内的字节位置!”也许你应该对这个问题进一步澄清一下。 - Daniel B
3个回答

如何让运行在HTML页面内、由HTML服务器提供服务的流媒体播放器与流媒体服务器(用于提供RTSP请求)建立流媒体连接? 常见应用 目前看来,RTSP 更多地被用于直接实时传输(例如IP摄像机)或者重新传输(如引擎)的应用/设备接口,而不是通过HTTP网页播放界面和嵌入播放器从物理位置流式传输保存的媒体文件。 似乎 RTSP 是一种有状态的协议,在流媒体传输时使用UDP更多于TCP,并且它更多被用作服务器设备(如IP摄像机),该设备连接到TCP/IP网络,并通过UDP等方式输出流。然后你可以作为客户端连接到这些流(服务器),并发出RTSP请求以相应利用。

协议指令

虽然在某些方面与HTTP相似,RTSP定义了在控制多媒体播放中有用的控制序列。虽然HTTP是无状态的,但RTSP具有状态;当需要跟踪并发会话时,使用标识符。与HTTP一样,RTSP使用TCP来维护端到端的连接,大多数RTSP控制消息由客户端发送到服务器,但也有一些命令是从服务器发送到客户端的。

这里介绍了基本的RTSP请求。还提供了一些典型的HTTP请求,例如OPTIONS请求。默认的传输层端口号为554[3],既适用于TCP,也适用于UDP,后者很少用于控制请求。

来源


无状态

无状态协议不需要服务器在多个请求的持续时间内保留有关每个通信伙伴的会话信息或状态。相反,需要在服务器上保持内部状态的协议被称为有状态协议。

无状态的缺点是可能需要在每个请求中包含额外的信息,并且这些额外的信息需要由服务器进行解释。

来源


逻辑流程

我对流媒体的流程理解如下:

  • 媒体内容所在的服务器将会对视频/音频数据进行封装、压缩、编码等处理,以适合流传输的格式和片段
  • 监听连接以访问流媒体的网络服务器会提供所有需要的资源来进行流媒体传输
  • 客户端请求并下载适用的资源和文件,然后根据配置和其他参数按照连续的方式组装它们,通过URL指针进行回放。客户端级别的播放软件会按顺序组装传输的数据包,以实现内容的正确播放。

请参考下面的流媒体技术部分,了解HTTP与RTSP之间的一般比较。


此外,在下面的“为什么你永远不应该自己托管视频的10个原因”部分中,我引用了一些关键点,以帮助回答你的问题,而不是过于具体。 基本上,它说的是具有嵌入式媒体播放器控件的网站将会: (1) 在与客户端建立连接和请求时检测客户端的Web浏览器设置,并且 (2) 这将设置编解码器和任何其他客户端侧检测设置为适用的参数值,然后 (3) 根据嵌入式媒体播放器配置中进一步指向托管服务器上媒体文件的URL的代码,直接从您托管视频和音频文件的流媒体服务器流式传输视频。

流媒体技术

客户端浏览器必须从服务器接收数据并将其传递给流媒体应用程序进行处理。流媒体应用程序将数据转换为图像和声音。该过程成功的关键因素是客户端能够以比应用程序显示信息更快的速度接收数据。多余的数据存储在缓冲区中,即应用程序内部用于数据存储的内存区域。如果两个系统之间的数据传输延迟,缓冲区会被清空,导致材料的呈现不流畅。

HTTP协议

HTTP是互联网上链接文档的主要方式。客户端与包含要流式传输的文件的服务器建立连接,获取文件并关闭连接。HTTP服务器向浏览器通知要传输的文件类型。

使用HTTP的好处

使用HTTP流式传输文件时,不需要特殊的流媒体服务器。只要您的浏览器理解MIME类型,就可以从HTTP服务器接收流媒体文件。使用HTTP流式传输文件的一个明显优势是它可以通过防火墙并利用代理服务器。

一些缺点

HTTP流式传输使用TCP/IP(传输控制协议和互联网协议)以确保文件可靠传递。该过程检查丢失的数据包并要求重新传输。在流媒体场景中,当您希望数据在传递过程中丢失时被忽略,以便动态文件继续播放时,这会成为问题。HTTP无法检测调制解调器速度,因此服务器管理员必须有意地以不同的压缩率生成文件,以服务于具有不同连接类型的用户。不建议从HTTP服务器流式传输文件以满足高需求的情况。

RTSP协议

RTSP是大多数流媒体服务器供应商使用的标准协议。RTSP服务器使用UDP(用户数据报协议)传输媒体文件。UDP不会持续检查文件是否到达目的地。对于流媒体应用程序来说,这是一个优势,因为它允许文件传输被中断,只要延迟不太长。这种方法的结果是有时会丢失数据,但如果延迟很小,文件仍然会继续播放。

来源


10 Reasons Why You Should Never Host Your Own Videos

We’re Talking About Embedding vs. Self-Hosted Video

First, you upload your video file to a third-party video hosting service like YouTube, Vimeo, or Wistia.

Then, you copy a small bit of code that they furnish to you, and paste it into your post or page on your own WordPress site. The video will appear on your site, in the location where you pasted the embed code, but the video itself is being streamed from the video host’s servers, as opposed to your own web server, where your WordPress site is hosted.

4. No Single File Format Standard for Web Video

The current HTML5 draft specification does not specify which video formats browsers should support. As a result, the major web browsers have diverged, each one supporting a different format. Internet Explorer and Safari will play H.264 (MP4) videos, but not WebM or Ogg. Firefox will play Ogg or WebM videos, but not H.264. Thankfully, Chrome will play all the major video formats, but if you want to ensure your video will play back on all the major web browsers, you’ll have to convert your video into multiple formats: .mp4, .ogv, and .webm

5. Hope you like converting videos. A lot.

Most of your audience will likely watch your videos from their desktop or laptop with the benefit of a high-speed Internet connection. For those folks, you’ll want to deliver a large, HD-quality file so they can watch it full-screen if they so choose. Generally, this means a 1080p or 720p file at a high streaming bitrate (5000 – 8000 kbps).

But you’ll also want to encode a smaller, lower-resolution version for delivery to mobile devices like phones and tablets, as well as delivery to viewers with slower Internet connections.

6. Video Players

A video player is a small piece of web software you install on your site that will automatically detect which device is requesting your video, along with its connection speed, and then deliver the appropriate version to that person.

7. Cumbersome Code [or Shortcodes]

Whether you use a third-party plugin or WordPress’ built-in video capabilities, you’ll need to create a bit of code to tell the video player which formats you’ve created, as well as their location on the server. It looks something like this…

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

So what’s the best solution for adding video to your site?

Simply use a third-party video hosting service, then just embed your video into your WordPress post or page.

Step One: Upload your video to one of the popular, well-established video hosting services like Vimeo PRO.

Step Two: Once your video has been uploaded and is ready for viewing, copy the URL to your video. Return to your WordPress site and paste the URL into your post or page where you want the video to appear.


When folks view your page, the video will appear in the location where you pasted the URL. But the video file itself will be streamed from the video host’s servers, as opposed to your own server, where your WordPress site is hosted.

The embedded video player will automatically detect the user’s device, browser, and Internet connection speed, and then serve the appropriate version of the video file to them. Nothing to install on your site. No plugins to keep up to date. No tricky code.

source


谢谢@PIMP_JUICE_IT (+1) - 如果你不介意的话,我有几个跟你关于“嵌入式视频播放器”这个短语使用上的一点困惑有关的后续问题:当你说“基本上它表示拥有嵌入式视频和音频播放器的网站将...”时,你所说的嵌入播放器是什么意思呢?对我来说,音频/视频可以通过网络服务器(使用MPEG-DASH或类似技术)或者使用RTSP等协议进行传输。而对我来说,一个播放器是一个客户端构件,用于向人们播放/呈现音频/视频内容。 - smeeb
当你谈论一个网站(服务器)拥有一个播放器时,这有点令人困惑。你能解释一下吗? - smeeb

我将主要讨论浏览器中视频显示时发生的情况。这个主题很广泛,所以我只会涉及相关的项目。 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协议(动态自适应流传输)的支持已经非常全面,因此它将在大多数设备和浏览器上本地播放或使用HTML5,这意味着不需要额外的插件。请参见设备和浏览器兼容性图表。另请参见Mozilla文章以准备您的服务器为MPEG-DASH提供服务。 DASH通过HTTP工作,因此只要您的HTTP服务器支持字节范围请求并设置为使用mimetype="application/dash+xml"来提供.mpd文件,就可以正常工作。 客户端和服务器之间的正常交互类似于以下内容。对于HTML5 VIDEO,浏览器也是播放器,尽管它可能会打开一个新的连接进行播放。

image

初始连接提供了客户端用于显示视频的元数据。如果使用RTSP协议获取该元数据,则稍后会创建一个RTP连接来传输视频+音频数据。RTCP协议用于向服务器传输附加命令。 RTP、RTCP和RTSP都在不同的端口上运行。通常情况下,当RTP在端口N上时,RTCP在端口N+1上。 一个RTP会话可以包含多个流,在接收端合并;例如,音频和视频可以在不同的通道上。 为了确保所有人都能访问您的内容,您应该提供免版税的编解码器,如webM或Theora,以及H.264视频和Vorbis和MP3音频。(说起来容易,做起来难。) 以下是RTSP的详细过程:
  1. 客户端与服务器建立TCP连接,通常使用TCP端口554,这是RTSP的众所周知的端口。

  2. 然后,客户端将开始发出一系列类似于HTTP格式的RTSP头命令,每个命令都会得到服务器的确认。在这些RTSP命令中,客户端将向服务器描述会话要求的详细信息,例如它支持的RTSP版本、用于数据流的传输方式以及任何相关的UDP或TCP端口信息。这些信息通过DESCRIBE和SETUP头部传递,并在服务器响应中使用会话ID进行补充,客户端和任何临时代理设备都可以使用该ID来识别进一步的流交换。

  3. 一旦传输参数的协商完成,客户端将发出一个PLAY命令,指示服务器开始传送RTP数据流。

  4. 当客户端决定关闭流时,会发出一个TEARDOWN命令,同时附带会话ID,指示服务器停止与该ID相关联的RTP传输。

进一步阅读:


这是一个快速而简单的答案- 在网络上播放视频和实时流媒体之间有区别。 通过在网页中包含的播放器来进行回放(可能使用Flash、JS或HTML5视频对象)。客户端(浏览器)下载并运行此播放器。播放器从简单的下载URL获取视频。事实上,即使是YouTube,也有一些程序可以让您直接访问托管的视频文件并像下载任何文件一样下载它们。由于系统使用常规的下载链接,因此不需要复杂的流媒体协议,如RTSP。 实时流媒体(比如来自网络摄像头的流媒体)更加棘手。Flash内置了这个功能,但现在不应再使用。HTML5视频不支持实时流媒体,但人们已经能够通过使文件托管服务器不断更改提供的视频文件来“欺骗”它。