8K HDR!｜为 Chromium 实现 HEVC 硬解 - 原理/实测指南

已于 2022-10-17 17:29:50 修改
阅读量5.6k 收藏 11
点赞数 3
文章标签： 音视频 视频编解码
于 2022-07-13 15:57:50 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhaoxinyao9/article/details/125764674
版权

本文作者：朱思达 飞书技术团队

HEVC 的现状

背景简介

什么是 HEVC ？简单说就是一种比 H264 压缩效率更高的现代视频编码格式，它支持 8K，支持 HDR，支持广色域，支持最高 16bit 的色彩深度，最高 YUV444 的色彩抽样，总之一句话，是一种用来取代现有 H264 的更高效、现代的视频编码格式，且目前已经被各类硬件广泛支持。

然而因为版权和技术派别等原因，这种格式一直没有被浏览器很好支持，尤其是目前市占率最高的 Chrome，一月初看到了一条 B 站用户吐槽 HEVC 解码性能/发热问题的新闻（感谢 B 站在 HEVC WASM 解码方案上的探索），考虑到这也是困扰业界很久的问题，大量依赖 HEVC 的 Web 项目均被迫产出了各种各样 Workaround 方案，但效果一直都不是最理想的，心想不如帮 Chromium 实现一下 HEVC 硬解吧。

本文简述了 Web 解码方案现状，介绍了作者为 Chromium 浏览器实现 & 完善硬解过程中遇到的问题和实现原理，并在文末附加了测试结果，预编译版本供参考，希望可以解决 FrontEnd 苦 HEVC 久矣的问题。

也可以提前下载 Chrome Canary（https://www.google.com/chrome/canary/） ，体验 HEVC 硬解功能（ChromeOS、Android、Mac、Windows 需要添加启动参数 --enable-features=PlatformHEVCDecoderSupport，Linux 版本暂未支持）。

主流设备早已支持且广泛使用

在 2015 年，苹果的 iPhone6s 就已经在其 A9 芯片内首次实现了 HEVC 硬解能力，同年，Intel 在第六代 Skylake 的 HD500 系列核显上，NVIDIA 在 GTX900 系列独显上，也先后支持了 HEVC 硬解。

在 2017 年发布的 iOS11, macOS 10.13 上，苹果继续完成了其 VideoToolbox 编解码框架对 HEVC 编解码能力的支持，微软也发布了 HEVC Video Extension 作为 Windows PC 环境 HEVC 解码的能力对标。

从此 HEVC 成为苹果，安卓默认视频格式，成为绝大多数单反 / 无人机 / 摄像设备的主推格式。

直到今年，也就是 2022 年，iPhone 已经出到了 13，芯片技术已经提升到了 5 纳米，然而我们所使用的大部分浏览器依然无法播放 HEVC 视频。

硬解的必要性

更低的发热

所谓硬解，即指使用 GPU 内专用于解码的芯片来处理解码工作，由于 GPU 多核心低频且专一的优势，在解码视频时发热和功耗显著低于 CPU。

更好的性能

通过将 CPU 从繁重的解码工作中解放，可极大程度降低系统卡顿。

且 GPU 天生适合进行图形解码工作，解码性能秒杀 CPU，视频分辨率越高，显卡解码越可以做到不掉帧输出，因此“永远不要指望单纯靠 CPU 软解可以流畅播放 8K 60 帧的 HEVC 视频”。

总结

HEVC 是目前桌面端或手机端播放器最主流的编码格式，考虑到其编码复杂度高，解码更耗费资源，因此为其实现硬解非常必要。

HEVC 解码的方案

浏览器解码现状

首先先来看看 Web 侧解码的现状：

Windows

macOS

​目前业内常用的 Web HEVC 解码方案大致可以分为两种：“换浏览器” 或 “WASM 软解”，他们各自有各自的优势和使用场景。

浏览器-Edge (硬解，仅 Windows）

Chromium 内核的 Edge 在 Windows 系统下，额外支持了硬解 HEVC 视频，但必须满足如下条件：

  1. 操作系统版本必须为 Windows 10 1709（16299.0）及以后版本。

  2. 安装付费的 HEVC 视频扩展或免费的来自设备制造商的 HEVC 视频扩展且版本号必须大于等于 1.0.50361.0（由于一个存在了一年半以上的 Bug，老版本存在抖动的 Bug，Issue：https://techcommunity.microsoft.com/t5/discussions/hevc-video-decoding-broken-with-b-frames/td-p/2077247/page/4）。

​3. 版本号必须大于等于 Edge 99 。

​在安装插件后，进入 edge://gpu 页面，可以查看 Edge 对于 HEVC 硬解支持的 Profile：

​出现上图所示的字样，则证明硬解开启成功。

指标：

  1. 分辨率最高支持 8192px * 8192px。

  2. 支持 HEVC Main / Main10 / Main Still Picture Profile。

优势：

  1. 在显卡支持的情况，性能是最好的。

  2. HTMLVideoElement、MSE 等原生 API 的直接支持。

劣势：

  1. 不支持 Windows 8 和老版本 Windows 10。

  2. 需要手动装插件。

  3. HDR 支持不够好。

浏览器-Safari (硬解，仅 macOS）

由于 Apple 是 HEVC 标准的主要推动者，因此早在 17 年的 Safari 11 即完成了 HEVC 视频硬解的支持，无需安装任何插件开箱即用。

指标：

  1. 分辨率最高支持 8192px * 8192px。

  2. 支持 HEVC Main / Main10 Profile，M1+ 机型支持部分 HEVC Rext Profile。

优势：

  1. 在显卡支持的情况，性能是最好的。

  2. HTMLVideoElement、MSE 等原生 API 的直接支持。

  3. 开箱即用，无需装插件。

  4. HDR 支持最好（比如：杜比视界 Profile5，杜比全景声）。

劣势：

  1. 生态不足，缺乏大量 Chromium 内核下“可用、好用的”插件。

  2. Safari 俗称“下一个 IE”，其浏览器 API 兼容性与实现，相比 Chromium 仍有差距。

  3. 部分 HEVC 视频莫名其妙无法播放，哪怕视频本身没问题。

前端解码-WASM（软解，任何平台）

此类方案绝大部分基于 WASM + FFMPEG 编译实现，支持所有支持 WASM 的浏览器。

指标：

  1. 支持 FFMPEG 支持的所有分辨率和 Profile。

优势：

  1. 不挑浏览器，是纯前端的技术实现。

劣势：

  1. 需要依赖所在版本浏览器 WASM 的稳定性。

  2. 不支持硬解，因为软解+性能损耗的缘故，性能有其天花板，4K 以上视频即使使用 5950X 这样的顶级 CPU 也会卡顿掉帧。

  3. 非 HTML Video Element、MSE、EME 原生 API，需要手动用 js 初始化视频播放，使用有成本。

浏览器-本文方案（硬 / 软解，Windows / macOS / Linux）

本文尝试直接为 Chromium 实现硬解，因为尽管 Safari 和 Edge 均已经实现了 HEVC 硬解，但它们均为闭源软件，无法被各种开源框架集成，而因为 Chromium 是开源的，这可以确保所有人可自行编译支持 Windows / macOS / Linux 硬解的 Chromium / Electron / CEF，考虑到实现原理部分较长，因此如果你感兴趣，可直接下载预编译版本（https://github.com/StaZhu/enable-chromium-hevc-hardware-decoding/releases）进行测试（未来会被包含在 Chrome 正式版本内，预编译版本可供大家尝鲜提前试用，也可下载 Chrome Canary），或跳到测评部分查看与 Edge / Safari 的对比。

HEVC 硬解的实现原理

正是因为如上瓶颈，“让专业的人做专业的事”这句话同样适用视频解码，GPU 硬解是很有必要的。GPU 解码的存在正是为了让解码工作可以充分利用显卡内部专用芯片，分担 CPU 解码时的压力，因此支持更多格式的硬解能力，已然成为众多显卡厂商的一大卖点。

首先我们需要做一些调研，研究下目前硬解框架是如何存在，并支持哪些“系统” or “GPU”。

下表来自 FFMPEG 项目对不同解码框架硬解支持情况的总结（来源：https://trac.ffmpeg.org/wiki/HWAccelIntro）

​硬解框架的支持情况，表格内容来自 FFmpeg 官网

可以看到硬解框架五花八门，不同的显卡厂商和设备有各自的专用解码框架，操作系统也有定义好的通用解码框架，由于显卡厂商众多，因此大部分播放器一般均基于通用框架实现硬解，少部分播放器在人力充裕的情况可能会为了更好的性能（显卡厂商自己的框架一般比通用框架性能更好，但也不绝对）额外对专用框架二次实现。

其中 Windows 平台通用的解码框架有 Media Foundation, Direct3D 11, DXVA2, 以及 OpenCL。macOS 平台通用的解码框架只有一个，也就是苹果自己的 VideoToolbox。Linux 平台的通用解码框架有 VAAPI 和 OpenCL。

显然，对于 Chrome 而言，为了更好的兼容性和稳定性，基于通用硬解框架实现硬解，更符合最小成本最大收益的目标，并提升了可维护性。

理解 Chromium 解码流程

根据 Chromium Media 模块简介可知，浏览器将音视频播放一共抽象成三种类型，我们比较常见的有：Video Element 标签，MSE API。此外还有支持加密视频播放的 EME API，这三种在底层又存在多种复用关系。

​Chromium 的解码流程，图片来自 Chromium 代码仓库

那么到了最底层的解码模块，整体逻辑大概可以简述为：

  1. 浏览器会从列表中依次按照顺序查找 Decoder，通常来说优先级最高的是硬解 Decoder, 然后会尝试软解 Decoder。

  2. 如有命中其中的某个 Decoder 则执行后续解码逻辑。

  3. 如没有命中的 Decoder，则解码失败，中止。

因此，为了实现 HEVC 硬解，我们首先需要找到各个平台的通用硬解 Decoder：

  • 对于 Windows，根据操作系统以及显卡驱动版本，分为两种：D3D11VideoDecoder 和 VDAVideoDecoder，前者在大于 Windows8 且支持 D3D11 的系统默认被使用，后者则在前者不被使用时（比如 Windows 7）作为 Backup 方案被使用。

  • 对于 macOS，为 VDAVideoDecoder。

  • 对于 Linux，为 VAAPIVideoDecoder。

macOS 的硬解

在了解了大致背景后，便可以开始探索实现 HEVC 硬解实现了，考虑到 Apple 其最新 Apple Silicon 芯片专门实现了支持 H.264、HEVC 和 ProRes 的专用编解码媒体处理引擎，看在 Apple 这么努力的份上，我首先挑选了 macOS 平台来进行尝试😑。

FFMPEG 方案的尝试

虽然 Chrome 没有直接实现 HEVC 解码能力，但由于其实现了 FFMpegVideoDecoder，因此本质上任何 FFMPEG 可以播的视频，只要利用修改 Chromium 的方式为其添加 FFMPEG 解码器的入口，理论上均可以实现播放，此方案其实是本文硬解实现前开源社区最广为流传的一种方案，@斯杰的文章（https://www.infoq.cn/article/s65bFDPWzdfP9CQ6Wbw6）内已有详尽介绍，由于当时的版本是基于 Chromium 79，目前最新的 Chromium 版本号为 104，因此里面的一些实现有所变动，但整体逻辑并没有明显改变，通过修改 Chromium 104 依然可以实现软解。

优点有很多：由于是 CPU 软解且使用行业最标准的 FFMPEG 解码，最终结果是：不挑系统，容错性好，支持任何 CPU 架构、操作系统，性能虽比不过硬解，但依然比前端 WASM 方案性能更好，且原生支持 MSE 和 Video Element。

缺点也很明显：普通的四核笔记本电脑，即使分辨率只有 1080P，在快进或快退时也会感到明显的卡顿，同时伴随比较高的 CPU 占用，抢占渲染进程 CPU 资源，另外这种方法是否有版权有待评估，但可以确定一点，使用平台提供的解码是合规且没有版权风险的。

当分辨率达到 4K 甚至 8K 级别，8 核甚至更多核的 CPU 也会卡到掉帧。

​FFMPEG 的解码流程，图片来自知乎 @我是小北挖哈哈

根据 FFMPEG 的解码流程如上图（参考：https://zhuanlan.zhihu.com/p/168240163?Futm_source=wechat_session&utm_medium=social&utm_oi=29396161265664），可知道，FFMPEG 除了实现了软解，其实已经完整实现了硬解功能，然而 Chromium 的 FFMpegVideoDecoder 并不支持硬解，因此，我们的同学，首先尝试 FFMpegVideoDecoder 内尝试配置 hw_device_ctx，以开启其硬解能力，具体步骤如下：

开启硬解宏：

// third_party/ffmpeg/chromium/config/Chrome/mac/x64/config.h
 
#define CONFIG_VIDEOTOOLBOX 1
#define CONFIG_HEVC_VIDEOTOOLBOX_HWACCEL 1
#define HAVE_KCMVIDEOCODECTYPE_HEVC 1

设置硬件上下文：

// media/filters/ffmpeg_video_decoder.cc -> FFmpegVideoDecoder::ConfigureDecoder(const VideoDecoderConfig& config, bool low_delay)
 
if (decode_nalus_)
    codec_context_->flags2 |= AV_CODEC_FLAG2_CHUNKS;
 
+ if (codec_context_->codec_id == AVCodecID::AV_CODEC_ID_HEVC) {
+     AVBufferRef *hw_device_ctx = NULL;
+     int err;
+     if ((err = av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_VIDEOTOOLBOX, NULL, NULL, 0)) >= 0) {
+         codec_context_->hw_device_ctx = av_buffer_ref(hw_device_ctx);
+     }
+ }
 
const AVCodec* codec = avcodec_find_decoder(codec_context_->codec_id);

取出解码数据：

// media/ffmpeg/ffmpeg_common.cc -> AVPixelFormatToVideoPixelFormat(AVPixelFormat pixel_format)
 
case AV_PIX_FMT_YUV420P:
case AV_PIX_FMT_YUVJ420P:
case AV_PIX_FMT_VIDEOTOOLBOX: // hwaccel
  return PIXEL_FORMAT_I420;

将硬件解码得到的数据取出，即 av_hwframe_transfer_data 函数：

// media/ffmpeg/ffmpeg_decoding_loop.cc
 
FFmpegDecodingLoop::DecodeStatus FFmpegDecodingLoop::DecodePacket(const AVPacket* packet, FrameReadyCB frame_ready_cb) {
+    AVFrame* tmp_frame = NULL;
+    AVFrame* sw_frame = av_frame_alloc();
    bool sent_packet = false, frames_remaining = true, decoder_error = false;
    while (!sent_packet || frames_remaining) {
        ......
+        if (frame_.get()->format == AV_PIX_FMT_VIDEOTOOLBOX) {
+            int ret = av_hwframe_transfer_data(sw_frame, frame_.get(), 0);
+            tmp_frame = sw_frame;
+        } else {
+            tmp_frame = frame_.get();
+        }
+        const bool frame_processing_success = frame_ready_cb.Run(tmp_frame);
+        av_frame_unref(tmp_frame);
-        const bool frame_processing_success = frame_ready_cb.Run(frame_.get());
        av_frame_unref(frame_.get());
        if (!frame_processing_success)
            return DecodeStatus::kFrameProcessingFailed;
        }
 
    return decoder_error ? DecodeStatus::kDecodeFrameFailed : DecodeStatus::kOkay;
}

如上，经过多次尝试后，通过活动监视器可以观察到点击< Video >标签播放按钮时 VTDecoderXPCService 进程（Videotoolbox 的解码进程）CPU 占有率有所上升，说明调用 VideoToolbox 硬件解码模块成功，但视频白屏说明解码失败。

探索过程中，阅读 Chromium Media 模块的文档后发现，使用 FFMpegVideoDecoder 不支持在 Sandboxed 的进程调用 VT 硬解框架，为了避免在错误的道路上投入过多精力，遂放弃。

在 GPU 进程实现

上面的方式行不通，说明得换一种思路，需要看看正统的 H264 硬解流程是怎样的，通过使用 Chrome 的搜索引擎（https://source.chromium.org/），发现 macOS 的 H264 硬解实现均位于vt_video_decoder_accelerator.cc这个文件内。

VideoToolbox 简介

由 FFmpeg 介绍可知，如我们想在 macOS 实现 HEVC 硬解，则一定需要使用苹果提供的媒体解码框架 VideoToolbox 来完成。

VideoToolbox is a low-level framework that provides direct access to hardware encoders and decoders. It provides services for video compression and decompression, and for conversion between raster image formats stored in CoreVideo pixel buffers. These services are provided in the form of session objects (compression, decompression, and pixel transfer), which are vended as Core Foundation (CF) types. Apps that don't need direct access to hardware encoders and decoders should not need to use VideoToolbox directly.

根据 Apple Developer 网站介绍（https://developer.apple.com/documentation/videotoolbox）可知，VideoToolbox 是苹果提供的直接用来进行编解码的底层框架，要实现硬解，大体解码流程可以理解为：Chromium -> VDAVideoDecoder -> VideoToolbox -> GPU -> VideoToolbox -> VDAVideoDecoder -> Chromium。

因此我们的目标就是正确按照 VideoToolbox 要求的方式，提交 Image Buffer，并等待 VT 将解码后的数据回传。

添加 Supported Profile

根据 Chromium 解码流程 可知，Chromium 对于特定 Codec 的视频首先会尝试查找硬解 Decoder，如硬解 Decoder 不支持，则继续向后查找 Fallback 的软解 Decoder。

通过观察可发现，在 macOS 下，某种编码格式是否支持硬解，取决于硬解 Decoder 内的 SupportProfiles 是否包含这种编码格式，其代码如下：

// media/gpu/mac/vt_video_decode_accelerator_mac.cc
 
// 这个数组内包含了所有可能支持的Profile，但是否真正支持并不取决于这里
constexpr VideoCodecProfile kSupportedProfiles[] = {
    H264PROFILE_BASELINE, H264PROFILE_EXTENDED, H264PROFILE_MAIN,
    H264PROFILE_HIGH,
 
    // macOS 11以上，会尝试对这两种格式进行硬解
    VP9PROFILE_PROFILE0, VP9PROFILE_PROFILE2,
 
    // macOS 11以上，支持的最主流的HEVC Main / Main10 Profile, 以及
    // Main Still Picture / Main Rext 的硬、软解
    // (Apple Silicon 机型支持硬解HEVC Rext, Intel 机型支持软解HEVC Rext)
    // These are only supported on macOS 11+.
    HEVCPROFILE_MAIN, HEVCPROFILE_MAIN10, HEVCPROFILE_MAIN_STILL_PICTURE,
    HEVCPROFILE_REXT,
 
    // TODO(sandersd): Hi10p fails during
    // CMVideoFormatDescriptionCreateFromH264ParameterSets with
    // kCMFormatDescriptionError_InvalidParameter.
    //
    // H264PROFILE_HIGH10PROFILE,
 
    // TODO(sandersd): Find and test media with these profiles before enabling.
    //
    // H264PROFILE_SCALABLEBASELINE,
    // H264PROFILE_SCALABLEHIGH,
    // H264PROFILE_STEREOHIGH,
    // H264PROFILE_MULTIVIEWHIGH,
};

Session 预热与引导逻辑

实现硬解，需要在 Sandboxed 的进程启用前创建解码 Session 预热，并根据系统版本与支持情况决定最终是否启用硬解：

// media/gpu/mac/vt_video_decode_accelerator_mac.cc
bool InitializeVideoToolbox() {
  // 在GPU主进程调用时立刻执行，以确保Sandboxed/非Sandoxed进程均可硬解
  static const bool succeeded = InitializeVideoToolboxInternal();
  return succeeded;
}
 
// 在GPU Sandbox启用前通过创建Videotoolbox的Decompression Session预热，确保Sandboxed/非Sandoxed进程均可硬解
bool InitializeVideoToolboxInternal() {
  VTDecompressionOutputCallbackRecord callback = {0};
  base::ScopedCFTypeRef<VTDecompressionSessionRef> session;
  gfx::Size configured_size;
 
  // 创建H264硬解Session
  const std::vector<uint8_t> sps_h264_normal = {
      0x67, 0x64, 0x00, 0x1e, 0xac, 0xd9, 0x80, 0xd4, 0x3d, 0xa1, 0x00, 0x00,
      0x03, 0x00, 0x01, 0x00, 0x00, 0x03, 0x00, 0x30, 0x8f, 0x16, 0x2d, 0x9a};
  const std::vector<uint8_t> pps_h264_normal = {0x68, 0xe9, 0x7b, 0xcb};
  if (!CreateVideoToolboxSession(
          CreateVideoFormatH264(sps_h264_normal, std::vector<uint8_t>(),
                                pps_h264_normal),
          /*require_hardware=*/true, /*is_hbd=*/false, &callback, &session,
          &configured_size)) {
    // 如果H264硬解Session创建失败，直接禁用整个硬解模块
    DVLOG(1) << "Hardware H264 decoding with VideoToolbox is not supported";
    return false;
  }
 
  session.reset();
 
  // 创建H264软解Session
  // 总结下，如果这台设备连H264硬/软解都不支持，则直接禁用硬解，解码完全走FFMpegVideoDecoder的软解
  const std::vector<uint8_t> sps_h264_small = {
      0x67, 0x64, 0x00, 0x0a, 0xac, 0xd9, 0x89, 0x7e, 0x22, 0x10, 0x00,
      0x00, 0x3e, 0x90, 0x00, 0x0e, 0xa6, 0x08, 0xf1, 0x22, 0x59, 0xa0};
  const std::vector<uint8_t> pps_h264_small = {0x68, 0xe9, 0x79, 0x72, 0xc0};
  if (!CreateVideoToolboxSession(
          CreateVideoFormatH264(sps_h264_small, std::vector<uint8_t>(),
                                pps_h264_small),
          /*require_hardware=*/false, /*is_hbd=*/false, &callback, &session,
          &configured_size)) {
    DVLOG(1) << "Software H264 decoding with VideoToolbox is not supported";
    // 如果H264软解 Decompression Session创建失败，直接禁用整个硬解模块
    return false;
  }
 
  session.reset();
 
  if (__builtin_available(macOS 11.0, *)) {
    VTRegisterSupplementalVideoDecoderIfAvailable(kCMVideoCodecType_VP9);
 
    // 当系统大于等于macOS Big Sur时，尝试创建VP9硬解Session
    if (!CreateVideoToolboxSession(
            CreateVideoFormatVP9(VideoColorSpace::REC709(), VP9PROFILE_PROFILE0,
                                 absl::nullopt, gfx::Size(720, 480)),
            /*require_hardware=*/true, /*is_hbd=*/false, &callback, &session,
            &configured_size)) {
      DVLOG(1) << "Hardware VP9 decoding with VideoToolbox is not supported";
      // 如果创建session失败，说明不支持VP9硬解，跳过，但保持H264可继续硬解
    }
  }
 
// 按照Chromium的要求HEVC硬解相关的逻辑，均需要依赖ENABLE_HEVC_PARSER_AND_HW_DECODER宏定义开关，只有开启开关后才会将代码引入
#if BUILDFLAG(ENABLE_HEVC_PARSER_AND_HW_DECODER)
  // 即使编译时开启了HEVC硬解宏
  // 当启动时传入`--enable-features=PlatformHEVCDecoderSupport`可启用HEVC硬解
  if (base::FeatureList::IsEnabled(media::kPlatformHEVCDecoderSupport)) {
    // 这里限制了至少是Big Sur系统的原因是，Catalina及以下系统使用
    // CMVideoFormatDescriptionCreateFromHEVCParameterSets API创建解码Session
    // 会失败
    // 注：macOS自身问题，苹果承诺了10.13及以上系统即可使用这个API，然，实测结果并卵
    // 但VLC和FFmpeg等使用的CMVideoFormatDescriptionCreate可以正常创建
    // 但，这与硬解模块实现的风格和结构不符
    if (__builtin_available(macOS 11.0, *)) {
      session.reset();
 
      // 创建HEVC硬解Session
      // vps/sps/pps提取自bear-1280x720-hevc.mp4
      const std::vector<uint8_t> vps_hevc_normal = {
          0x40, 0x01, 0x0c, 0x01, 0xff, 0xff, 0x01, 0x60,
          0x00, 0x00, 0x03, 0x00, 0x90, 0x00, 0x00, 0x03,
          0x00, 0x00, 0x03, 0x00, 0x5d, 0x95, 0x98, 0x09};
 
      const std::vector<uint8_t> sps_hevc_normal = {
          0x42, 0x01, 0x01, 0x01, 0x60, 0x00, 0x00, 0x03, 0x00, 0x90, 0x00,
          0x00, 0x03, 0x00, 0x00, 0x03, 0x00, 0x5d, 0xa0, 0x02, 0x80, 0x80,
          0x2d, 0x16, 0x59, 0x59, 0xa4, 0x93, 0x2b, 0xc0, 0x5a, 0x70, 0x80,
          0x00, 0x01, 0xf4, 0x80, 0x00, 0x3a, 0x98, 0x04};
 
      const std::vector<uint8_t> pps_hevc_normal = {0x44, 0x01, 0xc1, 0x72,
                                                    0xb4, 0x62, 0x40};
 
      if (!CreateVideoToolboxSession(
              CreateVideoFormatHEVC(vps_hevc_normal, sps_hevc_normal,
                                    pps_hevc_normal),
              /*require_hardware=*/true, /*is_hbd=*/false, &callback, &session,
              &configured_size)) {
        DVLOG(1) << "Hardware HEVC decoding with VideoToolbox is not supported";
        // 同VP9逻辑，HEVC硬解预热失败不会禁用H264硬解能力
      }
 
      session.reset();
 
      // 创建HEVC软解Session
      // vps/sps/pps提取自bear-320x240-v_frag-hevc.mp4
      const std::vector<uint8_t> vps_hevc_small = {
          0x40, 0x01, 0x0c, 0x01, 0xff, 0xff, 0x01, 0x60,
          0x00, 0x00, 0x03, 0x00, 0x90, 0x00, 0x00, 0x03,
          0x00, 0x00, 0x03, 0x00, 0x3c, 0x95, 0x98, 0x09};
 
      const std::vector<uint8_t> sps_hevc_small = {
          0x42, 0x01, 0x01, 0x01, 0x60, 0x00, 0x00, 0x03, 0x00, 0x90,
          0x00, 0x00, 0x03, 0x00, 0x00, 0x03, 0x00, 0x3c, 0xa0, 0x0a,
          0x08, 0x0f, 0x16, 0x59, 0x59, 0xa4, 0x93, 0x2b, 0xc0, 0x40,
          0x40, 0x00, 0x00, 0xfa, 0x40, 0x00, 0x1d, 0x4c, 0x02};
 
      const std::vector<uint8_t> pps_hevc_small = {0x44, 0x01, 0xc1, 0x72,
                                                   0xb4, 0x62,
最低0.47元/天 解锁文章
字节跳动视频云技术团队
关注
  • 3
    点赞
  • 踩
  • 11
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
chrome 开启HEVC硬件解码
技术控的笔记
09-20 1万+
通过上文配置好的快捷键（一定要从入口打开）打开chrome，输入支持HEVC的视频网址（哔哩哔哩有很多HEVC视频），这里采用我们项目的播放器，播放前端HEVC的摄像机视频，能够正常播放，查看GPU使用情况，GPU VIDEO DECODE项有波动，说明已开启硬件解码。安装完成后，打开如下图，如果有红框内容，则表示支持HEVC。有红框的内容，说明配置成功。
windows chrome中webrtc支持h264
Lucifer的博客
08-14 4071
webrtc在不同的平台上对h264的支持不太一致，webrtc支持h264编码采用openh264，只支持到baseline，解码采用FFmpeg。 通过在windows平台chrome和firefox上测试，h264的协商必须为baseline，即 a=fmtp:126 profile-level-id=42e01f;packetization-mode=1，否则协商会失败。但是，如果传输...
20240503安装HEVC解码器播放H265格式的8K视频
最新发布
南岭笑笑生之家
05-03 1916
但是如果机器硬件支持【杜比视界】的话，在安装 Dolby Vision UWP（https://www.chiphell.com/thread-2136981-1-1.html） 之后，目前尝试的只有 Windows 自带的 【电影和电视】 能够正常支持。该编码器已经被许多播放器或转换器如Handbrake和FFmpeg采用和使用，这表明如果你需要免费的Windows 10上的H.265视频扩展，它应该被添加到你的列表中-因为有许多程序证明它是可靠的，对你有用。
chrome常用启动参数
热门推荐
识途老码
09-04 1万+
chrome常用启动参数
HEVC Edge H.265硬解
qq_40414159的博客
02-08 129
22
chrome107是否支持hevc解码
勇气凛凛
11-14 1127
hevc chrome gpu
Chromium源代码的GitHub官方镜像-C/C++开发
05-26
Chromium Chromium是一个开放源代码的浏览器项目，旨在为所有用户构建更安全，更快，更稳定的方式来体验Web。 该项目的网站是https://www.chromium.org。 Chromium中的文档Chromium是一个开放源代码的浏览器项目，...
/ms-playwright/chromium-1048插件
03-04
标题中的“/ms-playwright/chromium-1048插件”指的是Playwright的一个特定版本，其中包含了针对Chromium 1048的驱动程序。Playwright是一个强大的自动化测试库，它支持多种浏览器，包括Chromium，Firefox和WebKit。...
Chromium嵌入式框架（CEF）官方镜像。 一个将基于Chromium的浏览器嵌入其他应用程序的简单框架。-C/C++开发
05-26
Chromium嵌入式框架（CEF）官方镜像。 一个将基于Chromium的浏览器嵌入其他应用程序的简单框架。 Chromium嵌入式框架（CEF）是用于在其他应用程序中嵌入基于Chromium的浏览器的简单框架。 快速链接项目页面-...
Chromium with HEVC for Ubuntu 16.04 x64-开源
05-31
【Chromium with HEVC for Ubuntu 16.04 x64 - 开源】这个主题涉及到的是一个针对Ubuntu 16.04 x64操作系统定制的Chromium浏览器版本，该版本特别强化了对HEVC（High Efficiency Video Coding）编码视频的支持。...
Chrome浏览器播放rtsp_支持H.265,所需资源
10-08
Chrome浏览器播放rtsp_支持H.265,所需资源 ffmpeg-20200527-8b5ffae-win64-static    oflaDemo  setup-Red5-1.0.5 详见：https://blog.csdn.net/zjy660358/article/details/108959372
92.0.chrome_hevc_installer.rar
07-26
chrome不支持hevc(h265)的解码功能，只能使用asm/wasm方式,性能低下。该资源提供基于chromium.92 版本，支持hevc解码，性能优秀，可支持hevc+aac 的mp4文件播放；直接拖入hevc的mp4文件即可播放。整体软件同chrome 几乎一摸一样
Chrome的历史版本位置：https：vikyd.github.iodownload-chromium-history-version
02-13
Chromium version -> chromium_base_position >版本下载链接的JSON数据。 例子： 版本： 87.0.4253.0 位置： 803990 操作系统： Mac 链接： ： Mac / 使用者 使用此JSON数据 描述 all-version.json 来自所有...
Chromium源码视频播放分析
bberdong的专栏
05-12 1217
​下载代码，调试方法等见Chromium视频播放相关调试记录_bberdong的博客-CSDN博客。
vp9协议梳理-header头文件
纯分享，内容不固定，平时学到什么发什么（非涉密内容），没有积分的话下载内容可以在相关博客下评论区留邮箱，看见了都会发的。
01-29 797
本文是对vp9视频码流中header中包含的语法元素的一个分类整理，及其对具体的解码过程的影响的分析
Chromium视频播放相关调试记录
bberdong的专栏
05-12 1367
enable-logging=stderr --v=1 > log.txt 2>&1 # Capture stderr and stdout to a log file gdb调试 gdb -tui -ex=r --args out/Default/chrome。不然会出现如下错误(chrome://gpu中就可以看到打印)，说明当前vaapi版本太低(vainfo可以看到vaapi版本)然后在我们日常使用的release版本的chrome中即可打开分析。// 如果要调试vaapi，硬解。
【如何在 Debian、Ubuntu 或 Linux Mint 上的 Google Chrome、Brave、Vivaldi 和 Opera 浏览器中启用硬件加速视频解码】
u013044828的博客
02-10 2971
如何在 Debian、Ubuntu 或 Linux Mint 上的 Google Chrome、Brave、Vivaldi 和 Opera 浏览器中启用硬件加速视频解码
HEVC学习(03)
pinkelectronic的博客
09-23 337
（图之后放） 首先知道I、P、B帧的概念是非常重要的。 I帧仅做帧内预测，用于给GOP中的其他帧做参考帧。 P帧（可以帧内吗？) 可以做帧间预测，但只能做前向。 B帧做帧间预测，双向。 P和B帧的存在就是为了压缩，视频编码的主要目的也就是压缩。 视频序列进入编码器后，会进行预测，预测及遍历，找到最优模式后与图像做差，获得残差值，残差值要经历变换（能量集中化），量化（精低频，粗高频），熵编码（转成码流），不仅如此，量化后的值还要经历反变化，滤波来参加预测。
external/chromium-webview/prebuilt/arm64/webview.apk
11-12
根据提供的引用内容，可以得知默认使用的webview apk的路径为external/chromium-webview/prebuilt/arm/webview.apk，而非arm64架构。如果需要获取arm64架构的webview apk，可以参考引用中提供的链接，从apkmirror...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值