企业官网建设流程全解析

播放器方案从 video.js/flv.js 换成 Jessibuca。

播放器框架/播放器UI封装：video.js 。对当前流的兼容性不足。
播放器SDK：Jessibuca。包含解码、渲染、控制、事件等能力。

一、问题解决方向

1. 思考的边界

是“从理论上推导出哪个层次更先进，再进行切换” 还是 “依据实际兼容性/成功链路、已验证结果进行切换”？。即是一种理论探讨还是工程上选择更合适的视频流播放器方案。

2. 播放失败的原因

原有播放器方案没有把这条流在当前浏览器环境里稳定播出来。

实际：切换为 同视频可播放平台 采用的方案。
理论：不同播放器方案在 “播放器封装、流媒体适配、协议支持、解码渲染方式” 上的差异。
思考：工程上的应用 -> 从播放器内核和播放器架构设计

二、工程上的应用

前端的视频播放分为两层：

1. 浏览器原生播放层 / 播放内核接入层
浏览器自己实现的 <video> 能力；
浏览器的 MSE / WebCodecs / Audio / Canvas / WebGL 等能力

2. 播放器封装层

方案二引用方式：直接使用 Jessibuca 依赖版本 或者 本地静态引入官方浏览器版资源（npm版本和页面不匹配）

三、理论探讨

1. 播放器内核包括什么？
处理流协议、解析封装格式、缓冲管理、
处理音视频同步、处理解码、canvas/webgl 渲染、错误恢复和重连

2. 播放器架构设计（ 播放器接入层 ）

• 方案一
  选择播放器方案：video.js 、 flv.js 、原生 HLS
  不同场景不同协议：根据 hls/flv/ws 去选播放方式
  协议回退
  统一播放器内部的事件模型
  将协议做成可配置策略
  封装成公共组件：video.js/flv.js自动适配选择
  不同页面共用一套播放器层
  实现缺失：FLV解析、H264/H265 解码、音视频同步、渲染引擎等
• 方案二
  动态加载脚本
  创建播放器实例
  协议切换
  错误回调