flv.js 支持哪些视频编码格式

一、flv.js 的转封装工作原理与编码支持边界

要确切理解 flv.js 为什么仅支持 H.264，首先需要理清它的技术角色。在 Adobe Flash 插件退出历史舞台前，浏览器依靠 Flash Player 插件内部封装的解码器直接解码 FLV 字节流；而现代浏览器采用 HTML5 <video> 标签播放视频，原生无法识别 FLV 传输容器。

flv.js 的核心价值在于建立了一条“纯前端轻量级转封装管线”：它通过 Fetch API 或 WebSocket 以数据流的形式持续拉取二进制 FLV 片段，在浏览器主线程或 Web Worker 中进行内存级解复用（Demux），提取出视频的 SPS（序列参数集）、PPS（图像参数集）和 NALU 单元，随后实时封装（Remux）成包含 moof 与 mdat 的 fMP4 分片，最后调用浏览器的 SourceBuffer.appendBuffer() 喂入 HTML5 媒体播放管道。

正因为 flv.js 本身不包含任何基于软件运算的画面解压缩逻辑（它不是 FFmpeg 的 C 代码编译版），它的视频格式支持边界受限于两项刚性条件：

• FLV 容器协议层限制：FLV 规范中定义的视频标签头仅预留了 4 个二进制位用于标示视频编码 ID（CodecID）。标准 FLV 规范中，CodecID 为 7 代表 AVC (H.264)；而 H.265 在早期 FLV 官方规范中根本没有定义。
• 浏览器 MSE 原生解码支持：转封装后的 fMP4 数据流必须是当前浏览器底层硬件能够直接解析的 MIME 类型（例如 video/mp4; codecs="avc1.42E01E"）。全平台浏览器对 H.264 都有广泛而成熟的硬件加速支持，但对其他编码的 MSE 支持并不一致。

二、主流视频编码格式在 flv.js 中的支持情况对比

实际开发中，开发者常常会接触到多种音视频编码。下表与图示全面梳理了主流编码格式在 flv.js 及其运行环境中的具体支持现状：

三、关于 flv.js 与 H.265 (HEVC) 的常见误区剖析

在安防监控、无人机图传及高画质直播场景中，H.265 凭借其比 H.264 节省约 40%~50% 码率的高压缩效率得到了广泛应用。许多开发者在构建系统时常有疑问：“为什么网络上的很多播放器叫 FLV 播放器却可以播放 H.265，而我引入官方 flv.js 后却直接黑屏抛错？”

1. 为什么“FLV 包装 H.265”看似合理？

从流媒体封装协议的演进来看，国内各大云厂商与推流端（如 OBS、FFmpeg、SRS）推出了“Enhanced RTMP / FLV”草案，将 CodecID 12 或 FourCC hvc1/hev1 作为 H.265 的扩展标识封装在 FLV Tag 之中。这在推流服务端与拉流服务端是完全可以正常通信的，因此服务端能够正常吐出带有 H.265 数据的 .flv 字节流。

2. 为什么官方 flv.js 会直接崩溃报错？

Bilibili 官方维护的 flv.js 仓库核心代码早在 Enhanced FLV 提案普及前就已经处于相对稳定的维护状态。当 flv.js 的 FLVDemuxer 遇到非 7（即不是 AVC）的视频 Tag 时，内部逻辑不会去尝试盲猜，而是直接触发如下断言：

// flv.js 内部 flv-demuxer.js 源码逻辑示意
if (codecId !== 7) {
    this._onError(DemuxErrors.CODEC_UNSUPPORTED, 
        'Flv: Unsupported video codec idx: ' + codecId);
    return;
}

控制台会立即输出 DemuxException: Type = CodecUnsupported, Message = Flv: Unsupported video codec idx: 12，整个播放流水线随即终止。

四、流媒体编码格式检测与实操排查流程

当遇到 flv.js 播放故障（例如“有声音但画面持续黑屏”、“加载即报错中断”）时，可按照规范化的四步流程进行精准定位和处理：

步骤一：使用 ffprobe 探查视频流真实编码

切勿仅凭文件扩展名 .flv 或推流配置来判断编码。在服务器或本地使用 ffprobe 抓取流媒体的实际编码信息：

# 检查远程 HTTP-FLV 流或本地 FLV 文件的实际视频编码
ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,profile,width,height -of default=noprint_wrappers=1 http://example.com/live/stream.flv

预期合规输出：

codec_name=h264
profile=High
width=1920
height=1080

如果输出的 codec_name 显示为 hevc、vp6f 或 flv1，即可确认视频源并非 H.264，官方 flv.js 必定无法运行。

步骤二：在前端代码中精准捕获编码相关事件

在集成 flv.js 时，务必挂载 MEDIA_INFO 及 ERROR 事件监听，以便及时在用户界面上给出明确提示，而不是陷入静默加载：

// 前端 flv.js 初始化与状态监控示例代码
if (flvjs.isSupported()) {
    const videoElement = document.getElementById('videoPlayer');
    const flvPlayer = flvjs.createPlayer({
        type: 'flv',
        isLive: true,
        url: 'https://media.example.com/live/sample.flv'
    }, {
        enableWorker: true,
        enableStashBuffer: false,
        stashInitialSize: 128
    });

    flvPlayer.attachMediaElement(videoElement);
    flvPlayer.load();

    // 监听音视频轨解析完成事件
    flvPlayer.on(flvjs.Events.MEDIA_INFO, (mediaInfo) => {
        console.log('[flv.js 媒体信息]', mediaInfo);
        // 若 videoCodec 字段正常解析，将显示类似 "avc1.640028"
        if (!mediaInfo.hasVideo) {
            console.warn('警告：当前流未检测到有效视频轨道！');
        }
    });

    // 监听解复用及运行时异常
    flvPlayer.on(flvjs.Events.ERROR, (errorType, errorDetail, errorInfo) => {
        if (errorType === flvjs.ErrorTypes.DEMUX_ERROR) {
            if (errorDetail === flvjs.ErrorDetails.CODEC_UNSUPPORTED) {
                console.error('播放失败：视频流编码不受 flv.js 支持（非 H.264）');
            }
        }
    });

    flvPlayer.play();
}

五、遇到非 H.264 编码时的技术选型与升级方案

如果业务场景无法将视频源强制约束为 H.264（例如既有的安防网络摄像机固件仅输出 H.265 流，或希望节约带宽），开发者应当根据端侧环境与延迟要求采用替代方案：

方案 1：无缝升级至 mpegts.js（推荐）

mpegts.js 是 flv.js 原作者及社区重点维护的进阶分支。它不仅向下兼容完整的 FLV H.264 播放能力，还扩展了对 Enhanced FLV 中 H.265/HEVC 以及 MPEG-TS 流的解复用能力。在客户端浏览器和显卡硬件具备 HEVC 解码能力的环境下，直接替换引入库即可无缝实现 H.265 的低延迟播放，前端无需改动主要业务代码。

方案 2：服务端转码保底（服务端方案）

对于需要保证 100% 终端设备兼容性的场景，最稳妥的策略仍然是在媒体网关（如 SRS、ZLMediaKit 或 FFmpeg）进行轻量级转码：将输入的 H.265 流通过 GPU 转码为标准的 H.264 Baseline / Main Profile，以确保无论用户的浏览器版本或硬件环境如何，官方 flv.js 均可秒开播放。

方案 3：WebAssembly 软解渲染方案（纯前端方案）

在不支持 H.265 硬解的 Windows 平台旧版系统或特定嵌入式 Web 环境中，可以采用基于 WebAssembly 的轻量化解码播放器（如开源的 Jessibuca、WXInlinePlayer）。此类播放器将 C/C++ 编写的软解码库（如 libde265 / ffmpeg）编译为 Wasm 模块，利用 Web Worker 进行画面解码，并将 YUV 数据输出至 WebGL/Canvas 绘制。该方案兼容性极广，但需注意在多路高分辨率（如 4K）同时播放时 CPU 占用较高。

六、全文核心要点总结

1. 唯一原生支持：官方 flv.js 视频编码只支持 H.264 (AVC)，音频支持 AAC 与 MP3。
2. 技术本质决定：flv.js 纯粹执行“FLV Tag 解复用 ➔ fMP4 封装”动作，本身无解码器，最终依赖浏览器 MSE 的硬件解码能力。
3. H.265 误区：官方库遇到 H.265 会直接触发 CODEC_UNSUPPORTED 错误终止；若必须在 FLV 体系中播放 H.265，应迁移至 mpegts.js 并配合客户端硬解环境，或改用 WebAssembly 软解方案。
4. 排查实践：切勿轻信扩展名，使用 ffprobe 探查实际 codec_name，并在前端严密监听 DEMUX_ERROR 异常。