视频网站都是h5视频播放器硬解和软解使用的软解还是硬件呢？

点击联系发帖人 时间：2022-10-13 15:15
视频播放器硬解和软解

本文聚焦 RTMP 协议的最精华的内容，接进行实际操作 Buffer 的练习和协议的学习。

RTMP 全称即是 Real-Time Messaging Protocol。顾名思义就是用来作为实时通信的一种协议。该协议是 Adobe 搞出来的。主要是用来传递音视频流的。它通过一种自定义的协议，来完成对指定直播流的播放和相关的操作。和现行的直播流相比，RTMP 主要的特点就是高效，这里，我就不多费口舌了。我们先来了解一下 RTMP 是如何进行握手的。

RTMP 是基于 TCP 三次握手之后的，所以，RTMP 不是和 TCP 一个 level 的。它本身是基于 TCP 的可靠性连接。RTMP 握手的方式如图：

它主要是通过两端的字段内容协商，来完成可信度认证的。基本过程如下：

  • 客户端在未接受到 S1 之前不能发送 C2 包

  • 客户端在未接收到 S2 之前不能发送任何实际数据包

【2】 服务端在接受到 C0，发送 S0，S1 包。也可以等到接受到 C1 之后再一起发送，C1 包的等待不是必须的。

  • 服务端在未接受到 C1 之前不能发送 "},

  • videoCodecs[Number]: 客户端支持的视频解码。有自定义的标准。默认可以设置为 252

  • videoFunction[Number]: 表明在服务端上调用那种特别的视频函数。默认可以设置为 1

简单来说，Command Object 就是起到 RTMP Route 的作用。用来请求特定的资源路径。实际数据，可以参考抓包结果：

上面具体的取值主要是根据 rtmp 官方文档来决定。如果懒得查，可以直接使用上面的取值。上面的内容是兼容性比较高的值。当该包成功发送时，另外一端需要得到一个返回包来响应，具体格式为：

connect 包发送的位置，主要是在 RTMP 握手结束之后。如下：

call 包主要作用是用来远程执行接收端的程序（RPC, remote procedure calls)。不过，在我解 RTMP 的过程中，并没有实际用到过。这里简单介绍一下格式。它的内容和 connect 类似：

Command Object 里面的内容主要是针对程序，设置相关的调用参数。因为内容不固定，这里就不介绍了。

call 一般是需要有 response 来表明，远端程序是否执行，以及是否执行成功等。返回的格式为：

createStream 包只是用来告诉服务端，我们现在要创建一个 channel 开始进行流的交流了。格式和内容都不复杂：

当成功后，服务端会返回一个 _result 或者 _error 包来说明接收成功，详细内容为：

NetStream 里面的 Msg 有很多，但在直播流中，比较重要的只有 play 包。所以，这里我们着重介绍一下 play 包。

play 包主要是用来告诉 Server 正式播放音视频流。而且，由于 RTMP 天然是做多流分发的。如果遇到网络出现相应的波动，客户端可以根据网络条件多次调用 play 命令，来切换不同模式的流。

  • Stream Name[String]: 用来指定播放的视频流文件。因为，RTMP 天生是支持 FLV 的，所以针对 FLV 文件来说，并不需要加额外的标识，只需要写明文件名即可。比如:

  • 不过，如果想要支持其它的文件，那么则需要额外的表示。当然，音频和视频需要不同的支持：

  • 如果是播放音频文件，比如 mp3，那么则需要额外的前缀标识符-mp3。例如：mp3:f9。

  • 如果涉及到视频文件的话，不仅需要前缀，还需要后缀。比如播放的是 MP4 文件，则标识为：mp4:f9.mp4。

  • -2: 如果是该标识符，服务端会首先寻找是否有对应的 liveStream。没有的话，就找 record_stream。如果还没有的，这次请求会暂时挂起，直到获取到下一次 live_stream。

  • =0: 相当于就是 seek video。它会直接找到 record_stream，并且根据该字段的值来确定播放开始时间。如果没有的话，则播放 list 中的下一个 video。

  • 0: 会播放一段一段的 frame。一般不用。

  • 0: 会直接播放指定 duration 之内的流。如果超出，则会播放指定时间段内容的 record_stream。

  • reset[Boolean]: 该字段没啥用，一般可以忽略。用来表示否是抛弃掉前面的 playlist。

整个 play 包内容就已经介绍完了。我们可以看看实际的 play 抓包结果：

那 play 包是在那个环节发送，发送完之后需不需要对应的 _result 包呢？

了解，来自网易核心架构的通信与视频云服务。

网易云信（NeteaseYunXin）是集网易18年IM以及音视频技术打造的PaaS服务产品，来自网易核心技术架构的通信与视频云服务，稳定易用且功能全面，致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API，即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

}

通常，摄像机H265视频编码在传输快、存储小、画质高等方面的优势使得其备受企业青睐，但是由于主流浏览器不能够支持这种格式，因此在浏览器下播放和解析视频都受到一定的约束。那么，如何实现 Web 视频播放的通用就成为了我们必须研究的课题。本期技术的真相将带你了解旷视盘古系统是如何解决 Web 视频播放通用方案这一难题的。

在视频智能分析领域，绝大部分摄像机视频码流均支持 H264 和 H265 两种编码格式，H265 视频编码相比 H264 有着诸多优点：视频数据传输带宽减半、存储减半、画质提升等。因此，在大部分智慧安全管理项目中， H265 视频编码使用较为广泛，能够直接减少用户项目成本。

但当下主流浏览器对 H265 视频编码格式仍然未能够支持，主要还是支持 H264 视频编码格式，随着 Flash 插件退出市场后，在 Chrome 浏览器下支持视频播放难度雪上加霜，所以大部分智慧安全管理厂家依然是在 IE 浏览器插件机制下支持着摄像机视频播放。

旷视在浏览器端视频播放也有诸多实践，旷视的盘古系统深耕智慧园区领域，在业内各项指标均遥遥领先，系统功能繁多，其中视频播放就是其必不可少的一部分，面向 ToB 市场，盘古平台系统自然需要适配用户各种使用场景，能够在不同浏览器中进行视频播放是基本要求。因此，在视频播放方面，我们需要研究一套通用的 Web 视频播放解决方案，来适配不同使用场景：高性能多路视频播放、强实时性视频播放等，并能够兼容不同的浏览器（IE / 360 / Chrome）。


盘古系统中视频数据来源

如上图所示，盘古系统中，视频数据来源各异、数据内容各异、甚至视频编码也各不相同，怎么样实现 PC 端跨浏览器进行 Web 视频播放，当前也有诸多方案，下面简易介绍下各个方案的实现关键点。

Web 前端收取到视频流后，进行 FMP4 封包，并使用 MSE 扩展 video 标签进行视频播放，对于智能帧（ Intelligence Frame 即结构化信息）采取透传方式，前端 Canvas 绘制。

即可实现浏览器视频播放，当前主流浏览器支持情况：


当前浏览器对MSE支持情况

WebAssembly 是一种新的编码方式，可以在现代的网络浏览器中运行，它是一种低级的类汇编语言，具有紧凑的二进制格式，并为其他语言提供一个编译目标，以便它们可以在 Web 上运行。它也被设计为可以与 JavaScript 共存，允许两者一起工作。近几年已经被各主流浏览器所广泛支持，支持情况：

前两方案基本是依靠 Web 前端实现视频播放，压力基本都在前端，播放路数受限，而此方案是需要部署一台服务器，进行视频码流的解码、编码、封装等动作，前端 Web 拿到 FMP4 视频数据后，依靠 MSE 扩展 video 标签的方式进行视频播放。

上述方案各有优缺点，如下：


那么我们依然面对以下问题：

  1. 如何面对服务器端资源紧张的情况下播放多路视频？
  2. 如何面对跨浏览器播放各种音视频编码视频数据？
  3. 如何面对端到端实时性要求高的使用场景？

三、Web 视频通用解决方案

我们经过大量分析讨论及预研，发现要解决这些问题的依然可行，在没有服务端资源情况下，我们只能将视频播放资源消耗前置，但考虑到浏览器对密集型数据计算并不擅长，我们决定在视频播放端使用后台程序，来实现视频封装、解码等动作。


在这个架构基础下，我们能够支持各种音视频编码格式，如 H264、H265、MJPEG、SVAC 等，同时，我们增加了多种模式来应对不同的使用场景。

3.1 适配兼容性好，实时性优先的视频播放需求：解码成 YUV + Web 前端 WebGL 显示

  1. 组件获取音视频码流，CPU 软解成视频帧 YUV 、音频帧 PCM ；
  2. 电脑环回地址 Websocket 数据传输，不受网络带宽限制； 
  3. 前端视频帧 WebGL 渲染，音频帧 Audio 标签音频播放，支持各种浏览器；
  4. 通用性较强，支持各种音视频编码格式；

3.2 适配视频码流自适应、性能优先的视频播放需求

  1. 组件获取音视频码流，若视频码流是 H264 ，封装成 FMP4 ，音频码流解码成 PCM ；
  2. Web 前端 H5 播放显示，利用浏览器硬解码能力，性能消耗较少；
  3. 通过判断视频码流格式，自适应输出不同视频数据给前端，来达到综合性能消耗最低，支持路数更多的效果，支持各种浏览器。

3.3  适配高分辨率、多路数的视频播放需求

  1. 在 IE 引擎下，Web 前端可以加载组件中 OCX 控件，控件获取音视频码流；
  2. GPU 解码显示能力较好，使端到端播放延迟能够在 200ms 以内；

总结：当然每个视频播放方案各有实际的使用场景及约束条件，在浏览器尚未支持 H265 等视频编码格式前，每个方案实现起来都有其对应的代价，怎么样实现 Web 视频播放并满足各自项目需求应该是百花齐放，各有略同。

}

本文聚焦 RTMP 协议的最精华的内容，接进行实际操作 Buffer 的练习和协议的学习。

RTMP 全称即是 Real-Time Messaging Protocol。顾名思义就是用来作为实时通信的一种协议。该协议是 Adobe 搞出来的。主要是用来传递音视频流的。它通过一种自定义的协议，来完成对指定直播流的播放和相关的操作。和现行的直播流相比，RTMP 主要的特点就是高效，这里，我就不多费口舌了。我们先来了解一下 RTMP 是如何进行握手的。

RTMP 是基于 TCP 三次握手之后的，所以，RTMP 不是和 TCP 一个 level 的。它本身是基于 TCP 的可靠性连接。RTMP 握手的方式如图：

它主要是通过两端的字段内容协商，来完成可信度认证的。基本过程如下：

  • 客户端在未接受到 S1 之前不能发送 C2 包

  • 客户端在未接收到 S2 之前不能发送任何实际数据包

【2】 服务端在接受到 C0，发送 S0，S1 包。也可以等到接受到 C1 之后再一起发送，C1 包的等待不是必须的。

  • 服务端在未接受到 C1 之前不能发送 "},

  • videoCodecs[Number]: 客户端支持的视频解码。有自定义的标准。默认可以设置为 252

  • videoFunction[Number]: 表明在服务端上调用那种特别的视频函数。默认可以设置为 1

简单来说，Command Object 就是起到 RTMP Route 的作用。用来请求特定的资源路径。实际数据，可以参考抓包结果：

上面具体的取值主要是根据 rtmp 官方文档来决定。如果懒得查，可以直接使用上面的取值。上面的内容是兼容性比较高的值。当该包成功发送时，另外一端需要得到一个返回包来响应，具体格式为：

connect 包发送的位置，主要是在 RTMP 握手结束之后。如下：

call 包主要作用是用来远程执行接收端的程序（RPC, remote procedure calls)。不过，在我解 RTMP 的过程中，并没有实际用到过。这里简单介绍一下格式。它的内容和 connect 类似：

Command Object 里面的内容主要是针对程序，设置相关的调用参数。因为内容不固定，这里就不介绍了。

call 一般是需要有 response 来表明，远端程序是否执行，以及是否执行成功等。返回的格式为：

createStream 包只是用来告诉服务端，我们现在要创建一个 channel 开始进行流的交流了。格式和内容都不复杂：

当成功后，服务端会返回一个 _result 或者 _error 包来说明接收成功，详细内容为：

NetStream 里面的 Msg 有很多，但在直播流中，比较重要的只有 play 包。所以，这里我们着重介绍一下 play 包。

play 包主要是用来告诉 Server 正式播放音视频流。而且，由于 RTMP 天然是做多流分发的。如果遇到网络出现相应的波动，客户端可以根据网络条件多次调用 play 命令，来切换不同模式的流。

  • Stream Name[String]: 用来指定播放的视频流文件。因为，RTMP 天生是支持 FLV 的，所以针对 FLV 文件来说，并不需要加额外的标识，只需要写明文件名即可。比如:

  • 不过，如果想要支持其它的文件，那么则需要额外的表示。当然，音频和视频需要不同的支持：

  • 如果是播放音频文件，比如 mp3，那么则需要额外的前缀标识符-mp3。例如：mp3:f9。

  • 如果涉及到视频文件的话，不仅需要前缀，还需要后缀。比如播放的是 MP4 文件，则标识为：mp4:f9.mp4。

  • -2: 如果是该标识符，服务端会首先寻找是否有对应的 liveStream。没有的话，就找 record_stream。如果还没有的，这次请求会暂时挂起，直到获取到下一次 live_stream。

  • =0: 相当于就是 seek video。它会直接找到 record_stream，并且根据该字段的值来确定播放开始时间。如果没有的话，则播放 list 中的下一个 video。

  • 0: 会播放一段一段的 frame。一般不用。

  • 0: 会直接播放指定 duration 之内的流。如果超出，则会播放指定时间段内容的 record_stream。

  • reset[Boolean]: 该字段没啥用，一般可以忽略。用来表示否是抛弃掉前面的 playlist。

整个 play 包内容就已经介绍完了。我们可以看看实际的 play 抓包结果：

那 play 包是在那个环节发送，发送完之后需不需要对应的 _result 包呢？

了解 ，来自网易核心架构的通信与视频云服务。

网易云信（NeteaseYunXin）是集网易18年IM以及音视频技术打造的PaaS服务产品，来自网易核心技术架构的通信与视频云服务，稳定易用且功能全面，致力于提供全球领先的技术能力和场景化解决方案。开发者通过集成客户端SDK和云端OPEN API，即可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。

}

我要回帖

更多关于 视频播放器硬解和软解 的文章

更多推荐

版权声明：文章内容来源于网络，版权归原作者所有，如有侵权请点击这里与我们联系，我们将及时删除。

点击添加站长微信