由于HLS协议由提出并在移动设备上得到广泛支持，因此可以广泛应用于直播场景。在PC端，hls.js只需要支持MSE即可应用，而在移动端，使用原生标签设置src即可完成播放。 hls.js会先请求m3u8文件，然后读取文件的片段列表，以及视频编码格式、时长等，然后按顺序请求TS片段，然后借助MSE形成可播放的媒体资源文件。
阿里巴巴内部也有多个团队有类似的播放器产品，例如阿里云、淘溪、优酷等，其实现思路也基本相同。 3、经过阿里云几个版本的迭代演进，整个架构更加合理，给自身和用户带来了更多的可扩展性，能够独立添加播放类型和功能。例如，如果想让h5支持flv播放功能，只需要添加flv功能扩展模块，不需要修改其他模块的代码，比如HLS等，保证不影响正常工作其他功能并保持每个版本发布的稳定性。
4、淘宝
底层播放层也经历了几次变化，从一开始的简单标签，到通过MSE扩展各种格式的标签，再到扩展编解码格式+Web API，未来可能会有底层。扩大沟通，增强上层互动能力。
5、优酷
目前的解决方案分为更多细节，包括多个库和组件，主要包括KMux封装库、KDRM插件、播放器控制行为的核心抽象、解码渲染播放的核心抽象以及KUI嵌入式UI框架。播放核心设计如下：
多种编码格式
上一节解决了浏览器不支持的协议和格式的问题（无法解压饼干）。遇到不支持的编码格式（无法消化的压缩技术）怎么办？
H.265、AV1等新的视频编码标准比传统的H.264具有更高的压缩率，但浏览器本身并不支持它们。为了降低成本，企业正在所有链路上改用H.265等新的编码格式。那么多媒体前端就必须自己实现浏览器端JS播放器。因为它是动态解释型语言，所以性能比C++等语言差很多。性能缺陷在处理多媒体数据时体现出来。已经解决的性能缺陷极大地扩展了浏览器的多媒体处理能力和场景。
对于Web上的H.265播放器，阿里巴巴内部很多团队都做了相应的尝试，包括优酷、阿里云、淘西、ICBU等，思路基本一致，都是用+来实现一个JS播放器，使用JS拉流，解封装，将265解码能力编译成wasm模块供JS调用。视频解码得到YUV帧数据，绘制图像帧数据。在音频方面，由于浏览器支持AAC、MP3等主流音频格式，音频数据可以直接通过Web API进行播放。设计思路如下：
多个渲染容器
上面介绍的场景主要是PC网页浏览器，但是我们更多的业务场景是在移动端。面向消费者的场景对于播放体验和性能的要求非常高，因此引入了播放器跨终端支持的问题，特别是交叉渲染容器（/Weex/）。客户端的播放器主要使用播放器，前端封装成Weex/同层渲染组件，运行在各个渲染容器中。如果客户端采用原生方案，会存在兼容性和性能问题。播放器本身会占用大量内存，不规范使用服务会带来稳定性风险，甚至导致APP故障。以端内H5为例，采用与Rax团队、客户端基础团队、客户端玩家团队共同打造的同层渲染方案：
多实例控制
上述场景均为单视频播放场景。实际业务中，也存在同一个页面有多个播放器的场景，比如列表流、页头等，这时候就引入了播放器的多实例控制问题，需要保证。页面中只有一个播放器用于播放（播放最佳点）、内存管理等。
播放器需要具备较强的播放控制能力，即播放调度能力：
事件中心驱动播放器内部维护一个要播放的队列，由rax-view实现。执行时，待播放队列将对应播放器的唯一id存储到队列中。当执行相应的播放器时，从队列中检索该播放器。队列中的播放形式主要分为三种： 1、滚动播放； 2.指定id播放； 3.场景回放；全部由事件控制。事件中心然后分发给不同的玩家，告诉他们哪些玩家可以玩，哪些玩家不能玩。它们存在于 pcom 库中。无论是场地场景还是源码开发场景，活动中心都可以保证所有玩家都得到播放控制的通知。调度播放器实例的内存使用量约为20-40MB。对于H5页面来说，内存占用过高，很容易导致页面内存占用过大，导致其他严重问题。因此，事件驱动播放时，事件中心会保证有且只有一个播放器实例在播放
消费导向：视频直播中的业务系统
前述功能都是纯播放功能，但实际业务场景是直播间或者短视频全屏页面。从播放器到直播间/短视频，另一个非常重要的部分是用户交互层，它引入了在视频直播中开发业务系统。以直播为例，观众有两个需求：观看直播和参与互动。一般直播设计如下：
直播间架构通常有三种：网页直播间、直播间、小程序直播间。例如钉钉公开课直播采用的是网页直播间架构，而蚂蚁、天猫精灵等则采用的是小程序直播间架构。 ，其他业务大多采用直播间架构。
Web直播间架构
纯Web直播间是指主要运行在Web浏览器上的H5直播间，主要包括H5播放器、事件通道、UI组件等。但移动浏览器兼容性较差，移动播放延迟较高。因此，体验和性能要求较高的业务场景一般会选择直播间架构。
直播间采用原生播放器能力，兼容性更好，体验更流畅；同时，活动通道是通道，比网络直播间更安全。
直播间结构
直播间的主持人使用的是原生播放器。交互玩法就是给玩家覆盖一个交互层（或者WEEX容器），并能够与玩家进行交流。
架构中的交互层方案也经历了几个阶段的演变，从最初的每个玩法组件独立一层，到将所有玩法组件封装到一层，再到定义一个直播容器来动态加载组件：
直播容器具有以下特点：
在该架构下开发和调试组件需要有完整的直播间环境和直播容器来开发和调试。如果没有配套的工程系统，组件开发效率非常低。因此，该架构还需要一个配套的工程系统，主要包括以下几个部分：
多媒体前端团队通过搭建直播容器和工程系统，可以高效、稳定地构建视频直播的业务系统。
小程序直播间结构
随着跨端业务尤其是跨APP场景的出现，直播间架构就像一个大胖子，自然不具备跨端优势（客户端集成和SDK维护成本极高），在此背景下，小程序直播间架构出现。小程序直播间的设计分为以下几层：
蚂蚁与淘宝直播联合打造的小程序直播解决方案已在多个APP（包括外部媒体APP）中广泛应用。
生产型：直播、视频编辑等工具。
上述场景更多的是面向消费者。随着业务的发展，各多媒体团队开始更加注重制作端的能力建设。毕竟，内容生产是整个内容生态的血液供应。作为开发者，需要为商家、主播、网红等创作者提供高效、易用的制作工具。制作端主要有两个方向，一是直播的直播工具，二是视频的视频编辑工具。
直播
直播前端的解决方案主要有两种：
淘宝直播主播工作台和1688直播伴侣均采用此方案：
网页浏览器端：采用比桌面端推流分辨率更低、性能更严格的方案。例如， 团队由于业务性质，无法使用第三方OBS开源软件，因此他们选择了该解决方案，并制作了PC网页采集和流媒体混合流SDK，支持摄像头、电脑屏幕和垫流。
视频剪辑
与直播制作相比，视频的制作覆盖范围更广，参与该方向建设的团队也更多，包括阿里妈妈、淘西、盒马、1688、阿里小米、蚂蚁金服等。制作文章内容需要富文本编辑器，制作视频内容需要视频编辑工具。当然，两者的复杂程度是完全不同的。我们打造智能制作、高效易用的深度编辑工具，希望降低制作成本，让视频编辑像编辑文章一样简单。
传统的桌面编辑软件提供GUI界面，向用户提供所见编辑效果的反馈，并在编辑完成后生成编辑描述数据。最后交给图形图像模块、音频处理模块和视频编码模块生成最终的视频文件。参考大多数开源编辑软件的实现，GUI的前半部分是通过操作系统图形界面或QT、SDL、SWT等跨平台方法来实现的。这部分称为“GUI前端”，后面的部分涉及图形、音频、编码相关部分。 ，大部分都会有一套媒体编辑核心来支持，比如大名鼎鼎的MLT等，这里我们称之为“编辑核心”。
基于上述GUI前端+编辑内核的思路，多媒体前端在编辑工具中通常有以下几种实现方案：
网页云剪辑：
浏览器+服务器的方案，GUI前端在浏览器，编辑内核在服务器。由于GUI前端和编辑内核是两端分离的，所以还需要解决GUI如何呈现编辑内核内容的问题。通常有两种解决方案：浏览器主动拉取渲染效果和直播流推送到用户界面。后者延迟更低，体验更好。阿里妈妈、盒马鲜生合作社视频剪辑、淘西PC端淘拍、蚂蚁金服FMS短视频制作工具均采用云剪辑解决方案。以解决方案为例：
但目前Web云编辑采用的是浏览器主动拉取渲染效果的解决方案。笔者还没有看到解决方案（类似云游戏）。淘西目前正在构建云编辑解决方案。
游戏制作
除了直播和视频剪辑之外，还有结合流媒体识别的制作方式，如人脸检测、手势检测、物体识别等，叠加滤镜、贴纸、美化、文字等特效，实现直播与视频媒体融合。智能游戏。外界有AR、Lens、抖音，内部有淘宝系统的MAI（），广泛应用于淘宝直播、购物等业务。
作为本文福利，您可以获得免费的C++音视频学习资料包、技术视频/代码，包括（音视频开发、面试题、、、rtmp、hls、rtsp、、编解码器、推拉流、 srs) ↓↓↓↓↓↓ 见下↓↓点击文章底部即可免费领取↓↓