简介这是一份面向桌面应用开发者的 CEF 110.0.5481.180 Windows 64 位非官方编译包适合需要在自有程序中嵌入 Chromium 内核、并直接播放 MP3、MP4 及 H.264 视频的开发者。相比官方默认构建该版本补齐了多媒体编解码支持可用于浏览器、媒体中心、在线视频客户端等对音视频播放有硬性要求的场景。压缩包共 1043 个文件约 136.41MB以 538 个 h 头文件与 358 个 cc 源文件为主体便于阅读接口与二次开发同时包含 60 个 pak 资源包、7 个 dll 动态库、lib 静态库、cmake 与 gypi 构建脚本以及 html、json、manifest 等配套文件覆盖编译、集成与调试所需。内容预览可见 v8、urlrequest、navigation、scheme_handler 等单元测试源码方便理解请求处理与运行时机制。目前已有 294 人学习下载适合具备一定 C 与 Chromium 基础的中高级开发者参考使用。1. CEF 110 非官方编译为什么官方包放不了 MP4而你必须自己编如果你用 CEFChromium Embedded Framework做过桌面客户端大概率遇到过这个场景官方 NuGet 或 Spotify 的二进制包下载下来嵌进 WinForms、WPF 或者 Qt 里网页加载一切正常但一放video srcxxx.mp4就黑屏audio播 MP3 直接静默控制台报DEMUXER_ERROR_COULD_NOT_OPEN或者干脆连报错都没有。这不是你代码写错了是官方预编译包为了规避专利和体积问题默认把 H.264、AAC、MP3 这些编解码器阉掉了。标题里的 CEF 110.0.5481.180 是 Chromium 110 分支的一个具体版本64 位 Windows 平台。所谓「非官方编译」核心就一件事自己拉源码、打开proprietary_codecs和ffmpeg_branding开关重新编出一份带 MP4、MP3 支持的libcef.dll。这件事在 110 这个版本上有一套相对固定的流程但坑集中在依赖同步、GN 参数和 VS 工具链三处。这篇笔记面向的是需要在自己产品里内嵌浏览器、且必须播本地或在线 MP4/MP3 的 Windows 桌面开发者从环境准备一路写到验证和排错参数和命令都可以直接抄。2. 编译前的环境与源码准备把 110 分支的依赖一次拉齐2.1 为什么必须锁死 110.0.5481.180 这个版本号CEF 的版本号和 Chromium 是绑定的110.0.5481.180 对应 Chromium 110.0.5481.180。你如果只写「110 版本」去拉源码automate-git.py默认会取该分支最新的一次提交可能落到 110.0.5481.200 之类导致后面gclient sync拉下来的 Chromium 和 CEF 补丁对不上编译到一半报 patch 失败。所以第一步就是把版本号写死。我一般的工作目录结构是这样路径里不要有中文和空格这是血泪经验GN 在含空格路径下生成 ninja 文件时会出玄学问题# 工作根目录建议放在 SSD 上整个编译过程需要 100GB 以上空间 mkdir C:\cef cd C:\cef # 拉取 depot_tools这是 Chromium 的构建工具集合 git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git # 把 depot_tools 加入 PATH注意要放在最前面 set PATHC:\cef\depot_tools;%PATH%depot_tools里包含gclient、gn、ninja、autoninja等工具后面所有命令都依赖它。加入 PATH 后建议新开一个终端执行gclient --version确认能识别。2.2 用 automate-git.py 拉取 CEF 与 Chromium 源码CEF 官方提供了一个 Python 脚本automate-git.py来协调 CEF 和 Chromium 两个仓库的拉取不要手动去 clone否则子模块和 hooks 会漏。先建一个chromium_git目录把脚本放进去cd C:\cef mkdir chromium_git cd chromium_git # 下载 automate-git.py curl -o automate-git.py https://bitbucket.org/chromiumembedded/cef/raw/master/tools/automate/automate-git.py # 拉取源码--branch 指定 CEF 分支这里对应 5481 python automate-git.py --download-dirC:\cef\chromium_git ^ --depot-tools-dirC:\cef\depot_tools ^ --branch5481 ^ --minimal-distrib ^ --force-clean ^ --no-build参数说明--branch5481对应 Chromium 110 分支--no-build表示只拉源码不编译第一次拉取建议先不编确认源码完整再编--minimal-distrib会精简发行包内容去掉测试用例减小体积。整个拉取过程视网络情况要 1 到 3 小时中途断了重新执行同一条命令即可gclient sync会续传。拉完后检查C:\cef\chromium_git\chromium\src\cef目录是否存在以及C:\cef\chromium_git\chromium\src\chrome\VERSION里的版本号是不是 110.0.5481.180。这一步对不上后面全白干。2.3 确认 VS 工具链版本110 分支只认 VS2019 或 VS2022 特定版本Chromium 110 官方推荐 VS2022 17.4 以上但实测 17.4 到 17.6 都能过17.7 之后有个别头文件变更会导致 CEF 的libcef编译报错。我一般用 VS2022 17.5。安装时务必勾选「使用 C 的桌面开发」和 Windows 10 SDK 10.0.20348 或 10.0.22621。# 设置环境变量指向 VS 安装目录 set GYP_MSVS_OVERRIDE_PATHC:\Program Files\Microsoft Visual Studio\2022\Professional set GYP_MSVS_VERSION2022 set vs2022_installC:\Program Files\Microsoft Visual Studio\2022\Professional set DEPOT_TOOLS_WIN_TOOLCHAIN0DEPOT_TOOLS_WIN_TOOLCHAIN0是关键它告诉 depot_tools 用本机已装的 VS而不是去下载 Google 内部的工具链否则会卡在下载环节。GYP_MSVS_OVERRIDE_PATH路径按你实际安装的版本改Community 版也能用。3. 打开 MP4/MP3 支持的 GN 参数proprietary_codecs 与 ffmpeg_branding3.1 两个决定编解码器是否编进去的开关CEF 的编译配置通过 GN 参数控制核心就两个proprietary_codecs和ffmpeg_branding。前者决定是否启用专利编解码器H.264、AAC、MP3后者决定 FFmpeg 的品牌配置Chrome表示包含所有专有编解码器Chromium表示只有开源部分。在C:\cef\chromium_git\chromium\src\cef目录下创建create.bat内容如下cd C:\cef\chromium_git\chromium\src\cef # 生成 VS 工程文件关键在 GN_DEFINES set GN_DEFINESis_official_buildtrue proprietary_codecstrue ffmpeg_brandingChrome set GYP_MSVS_VERSION2022 set GN_ARGUMENTS--idevs2022 --slncef --filters//cef/* python ..\tools\gclient_hook.pyis_official_buildtrue会开启正式构建的优化体积更小、性能更好但编译时间更长。如果你只是内部测试可以设成 false 加快编译。proprietary_codecstrue和ffmpeg_brandingChrome必须同时出现只设一个不生效这是最常见的翻车点。3.2 用 GN 参数表核对每一项配置下面这张表是我每次编译前都会核对的参数缺一项就可能导致 MP4 播不了参数推荐值作用漏设后果proprietary_codecstrue启用 H.264/AAC/MP3MP4 黑屏、MP3 静默ffmpeg_brandingChromeFFmpeg 含专有解码器同上且报 demuxer 错误is_official_buildtrue正式构建优化体积大、性能略低is_component_buildfalse非组件构建生成多个 dll部署麻烦symbol_level1符号级别调试信息过多体积膨胀enable_naclfalse关闭 NaCl无用依赖增加编译时间blink_symbol_level0Blink 符号级别体积过大is_component_buildfalse很重要组件构建会生成一堆 dll部署时容易漏文件。symbol_level1保留基本符号方便崩溃时定位设成 0 则完全无符号设成 2 体积翻倍。3.3 生成工程并开始编译配置好 GN_DEFINES 后执行create.bat它会调用gclient_hook.py生成cef.sln。然后进入chromium\src目录用 ninja 编译cd C:\cef\chromium_git\chromium\src # 编译 Release 版目标 cefclient 和 libcef ninja -C out\Release_GN_x64 cefclient libcef # 如果只要 libcef.dll可以只编 libcef ninja -C out\Release_GN_x64 libcefout\Release_GN_x64是默认输出目录如果你在 GN_ARGUMENTS 里改了--ide目录名可能不同。编译时间在 16 核机器上大约 1.5 到 2 小时8 核机器 4 小时以上。中途报错先看是不是 VS 版本问题再看 GN_DEFINES 有没有写错。编译完成后out\Release_GN_x64下会有libcef.dll、libcef.lib、cefclient.exe等文件。用cefclient.exe打开一个本地 MP4 文件测试能正常播放就说明编解码器已经编进去了。4. 验证 MP4/MP3 是否真的编进去了三种可复现的检测方法4.1 用 cefclient 直接播放本地文件最直接的方法就是拿cefclient.exe测。启动后地址栏输入本地 MP4 的file://路径比如file:///C:/test/sample.mp4。如果画面出来、声音正常说明 H.264 和 AAC 都编进去了。MP3 同理输入file:///C:/test/sample.mp3能听到声音即可。如果黑屏但控制台没报错先检查文件路径有没有中文CEF 对file://中文路径支持不好换成纯英文路径再试。如果报DEMUXER_ERROR_COULD_NOT_OPEN基本就是ffmpeg_branding没设成Chrome。4.2 用 HTML 页面批量测试多种格式建一个test.html把常见格式都列进去一次性验证!DOCTYPE html html body h3MP4 H.264/h3 video srcsample_h264.mp4 controls width320/video h3MP3/h3 audio srcsample.mp3 controls/audio h3检测结果/h3 script // 用 canPlayType 检测编解码器支持情况 const v document.createElement(video); const a document.createElement(audio); document.body.innerHTML pH.264: v.canPlayType(video/mp4; codecsavc1.42E01E) /p; document.body.innerHTML pAAC: a.canPlayType(audio/mp4; codecsmp4a.40.2) /p; document.body.innerHTML pMP3: a.canPlayType(audio/mpeg) /p; /script /body /htmlcanPlayType返回probably或maybe表示支持返回空字符串表示不支持。这个方法不用真的加载文件适合快速判断。注意avc1.42E01E是 H.264 Baseline Profile 的 codec 字符串不同 Profile 字符串不同但只要能返回非空就说明 H.264 解码器在。4.3 检查 libcef.dll 里是否包含 FFmpeg 符号如果上面两种方法都不方便可以直接查 dll。用dumpbin或者 Dependency Walker 看libcef.dll的导出符号搜avcodec相关# 用 VS 自带的 dumpbin 查看导出符号 dumpbin /exports C:\cef\chromium_git\chromium\src\out\Release_GN_x64\libcef.dll | findstr /i avcodec h264 aac mp3如果能看到avcodec_register_all、ff_h264_decoder之类的符号说明 FFmpeg 编进去了。这个方法适合在 CI 里做自动化校验比人工点播放器可靠。5. 编译与运行中的避坑清单5 个真实踩坑记录5.1 坑一gclient sync 卡在下载 nodejs 或 python现象执行automate-git.py时卡在Downloading nodejs或python不动几十分钟没进展。原因depot_tools 默认从 Google 存储下载预编译的 nodejs 和 python网络不通时就会卡住。解决设置环境变量DEPOT_TOOLS_WIN_TOOLCHAIN0之外再设GYP_MSVS_OVERRIDE_PATH指向本机 VS并确保本机已装 Python 3.9 以上。如果还是卡可以手动下载 depot_tools 的bootstrap所需文件放到depot_tools\bootstrap目录或者用set DEPOT_TOOLS_UPDATE0跳过自动更新。5.2 坑二GN 报错「Unsupported VS version」现象执行create.bat时 GN 报Unsupported Visual Studio version。原因Chromium 110 对 VS 版本有白名单VS2022 17.7 以上不在白名单里。解决降级到 VS2022 17.5 或 17.6或者修改chromium\src\build\vs_toolchain.py里的版本判断逻辑把 17.7 加进去。改源码是下策升级 CEF 版本才是上策但 110 分支就这个限制。5.3 坑三编译到一半报「fatal error C1060: 编译器堆空间不足」现象编译blink或v8时 MSVC 报 C1060或者直接进程崩溃。原因64 位编译单个文件内存占用可能超过 4GB默认 MSVC 堆空间不够。解决在create.bat里加set GN_DEFINES%GN_DEFINES% use_thin_ltofalse关闭 ThinLTO 能显著降低内存峰值。另外把虚拟内存调到 32GB 以上物理内存最好 32GB。如果还不行用ninja -j 4限制并行编译数牺牲时间换稳定。5.4 坑四编出来的 libcef.dll 放 MP4 还是黑屏现象确认proprietary_codecstrue和ffmpeg_brandingChrome都设了编出来的 dll 还是播不了 MP4。原因GN_DEFINES 设置后没有清理旧的 out 目录ninja 用了缓存的旧配置。解决删掉out\Release_GN_x64整个目录重新执行create.bat和ninja。GN 参数变更后必须重新生成不能只重新编译。这是最容易被忽略的一步很多人改了参数直接 ninja结果配置根本没生效。5.5 坑五部署到客户机报「找不到 VCRUNTIME140.dll」现象开发机跑得好好的拷到客户机双击 exe 报缺少 VCRUNTIME140.dll 或 MSVCP140.dll。原因CEF 编译产物依赖 VS 运行时库客户机没装对应版本的 VC Redistributable。解决随包附带VC_redist.x64.exe或者把libcef.dll同目录下的vcruntime140.dll、msvcp140.dll一起拷过去。注意 VS2022 的运行时和 VS2019 不通用客户机装 2015-2022 合集版最稳。6. 进阶把非官方 CEF 集成进自己的项目并做版本管理编出libcef.dll只是第一步真正落地要解决的是「怎么在自己的 C 或 C# 项目里用起来并且下次升级 CEF 时能快速复现」。我一般会建一个独立的cef_build仓库把create.bat、GN_DEFINES、automate-git.py的调用脚本都提交进去每次编译只改版本号。集成到 C 项目时把libcef.dll、libcef.lib、include头文件、Resources目录含icudtl.dat、cef.pak、locales一起拷到项目依赖目录。C# 项目用 CefSharp 的话CefSharp 的 NuGet 包自带的是官方无编解码器版本你需要把 NuGet 包里的libcef.dll替换成自己编的同时保持 CefSharp 的CefSharp.Core.dll版本和 CEF 版本匹配。110 对应 CefSharp 110.0.300替换后重新生成即可。版本管理上我习惯在cef_build仓库里打 tag比如110.0.5481.180-mp4tag 里记录 GN_DEFINES 和 VS 版本。下次要升到 112 或 114只需要改--branch和 tag 名其他脚本不动。这样每次升级的 diff 很小排查问题也快。最后一个技巧如果你只需要 MP3 不需要 MP4可以把ffmpeg_branding设成Chrome但proprietary_codecs保持 true然后在ffmpeg的 GN 配置里裁掉 H.264 解码器能减小 dll 体积约 3MB。不过这个操作要改third_party\ffmpeg\ffmpeg_generated.gni容易出错不是体积敏感场景不建议折腾。我自己踩过最深的坑是第一次编译时忘了删 out 目录改了 GN_DEFINES 直接 ninja结果白等两小时编出来的还是无编解码器版本。从那以后我养成了一个习惯只要动了 GN 参数先rmdir /s /q out再重新生成。这个习惯帮我省下的时间比任何优化都值。希望帮到你。本文还有配套的精品资源点击获取 CEF 110 非官方编译实战：开启 MP4/MP3 支持与避坑指南
简介这是一份面向桌面应用开发者的 CEF 110.0.5481.180 Windows 64 位非官方编译包适合需要在自有程序中嵌入 Chromium 内核、并直接播放 MP3、MP4 及 H.264 视频的开发者。相比官方默认构建该版本补齐了多媒体编解码支持可用于浏览器、媒体中心、在线视频客户端等对音视频播放有硬性要求的场景。压缩包共 1043 个文件约 136.41MB以 538 个 h 头文件与 358 个 cc 源文件为主体便于阅读接口与二次开发同时包含 60 个 pak 资源包、7 个 dll 动态库、lib 静态库、cmake 与 gypi 构建脚本以及 html、json、manifest 等配套文件覆盖编译、集成与调试所需。内容预览可见 v8、urlrequest、navigation、scheme_handler 等单元测试源码方便理解请求处理与运行时机制。目前已有 294 人学习下载适合具备一定 C 与 Chromium 基础的中高级开发者参考使用。1. CEF 110 非官方编译为什么官方包放不了 MP4而你必须自己编如果你用 CEFChromium Embedded Framework做过桌面客户端大概率遇到过这个场景官方 NuGet 或 Spotify 的二进制包下载下来嵌进 WinForms、WPF 或者 Qt 里网页加载一切正常但一放video srcxxx.mp4就黑屏audio播 MP3 直接静默控制台报DEMUXER_ERROR_COULD_NOT_OPEN或者干脆连报错都没有。这不是你代码写错了是官方预编译包为了规避专利和体积问题默认把 H.264、AAC、MP3 这些编解码器阉掉了。标题里的 CEF 110.0.5481.180 是 Chromium 110 分支的一个具体版本64 位 Windows 平台。所谓「非官方编译」核心就一件事自己拉源码、打开proprietary_codecs和ffmpeg_branding开关重新编出一份带 MP4、MP3 支持的libcef.dll。这件事在 110 这个版本上有一套相对固定的流程但坑集中在依赖同步、GN 参数和 VS 工具链三处。这篇笔记面向的是需要在自己产品里内嵌浏览器、且必须播本地或在线 MP4/MP3 的 Windows 桌面开发者从环境准备一路写到验证和排错参数和命令都可以直接抄。2. 编译前的环境与源码准备把 110 分支的依赖一次拉齐2.1 为什么必须锁死 110.0.5481.180 这个版本号CEF 的版本号和 Chromium 是绑定的110.0.5481.180 对应 Chromium 110.0.5481.180。你如果只写「110 版本」去拉源码automate-git.py默认会取该分支最新的一次提交可能落到 110.0.5481.200 之类导致后面gclient sync拉下来的 Chromium 和 CEF 补丁对不上编译到一半报 patch 失败。所以第一步就是把版本号写死。我一般的工作目录结构是这样路径里不要有中文和空格这是血泪经验GN 在含空格路径下生成 ninja 文件时会出玄学问题# 工作根目录建议放在 SSD 上整个编译过程需要 100GB 以上空间 mkdir C:\cef cd C:\cef # 拉取 depot_tools这是 Chromium 的构建工具集合 git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git # 把 depot_tools 加入 PATH注意要放在最前面 set PATHC:\cef\depot_tools;%PATH%depot_tools里包含gclient、gn、ninja、autoninja等工具后面所有命令都依赖它。加入 PATH 后建议新开一个终端执行gclient --version确认能识别。2.2 用 automate-git.py 拉取 CEF 与 Chromium 源码CEF 官方提供了一个 Python 脚本automate-git.py来协调 CEF 和 Chromium 两个仓库的拉取不要手动去 clone否则子模块和 hooks 会漏。先建一个chromium_git目录把脚本放进去cd C:\cef mkdir chromium_git cd chromium_git # 下载 automate-git.py curl -o automate-git.py https://bitbucket.org/chromiumembedded/cef/raw/master/tools/automate/automate-git.py # 拉取源码--branch 指定 CEF 分支这里对应 5481 python automate-git.py --download-dirC:\cef\chromium_git ^ --depot-tools-dirC:\cef\depot_tools ^ --branch5481 ^ --minimal-distrib ^ --force-clean ^ --no-build参数说明--branch5481对应 Chromium 110 分支--no-build表示只拉源码不编译第一次拉取建议先不编确认源码完整再编--minimal-distrib会精简发行包内容去掉测试用例减小体积。整个拉取过程视网络情况要 1 到 3 小时中途断了重新执行同一条命令即可gclient sync会续传。拉完后检查C:\cef\chromium_git\chromium\src\cef目录是否存在以及C:\cef\chromium_git\chromium\src\chrome\VERSION里的版本号是不是 110.0.5481.180。这一步对不上后面全白干。2.3 确认 VS 工具链版本110 分支只认 VS2019 或 VS2022 特定版本Chromium 110 官方推荐 VS2022 17.4 以上但实测 17.4 到 17.6 都能过17.7 之后有个别头文件变更会导致 CEF 的libcef编译报错。我一般用 VS2022 17.5。安装时务必勾选「使用 C 的桌面开发」和 Windows 10 SDK 10.0.20348 或 10.0.22621。# 设置环境变量指向 VS 安装目录 set GYP_MSVS_OVERRIDE_PATHC:\Program Files\Microsoft Visual Studio\2022\Professional set GYP_MSVS_VERSION2022 set vs2022_installC:\Program Files\Microsoft Visual Studio\2022\Professional set DEPOT_TOOLS_WIN_TOOLCHAIN0DEPOT_TOOLS_WIN_TOOLCHAIN0是关键它告诉 depot_tools 用本机已装的 VS而不是去下载 Google 内部的工具链否则会卡在下载环节。GYP_MSVS_OVERRIDE_PATH路径按你实际安装的版本改Community 版也能用。3. 打开 MP4/MP3 支持的 GN 参数proprietary_codecs 与 ffmpeg_branding3.1 两个决定编解码器是否编进去的开关CEF 的编译配置通过 GN 参数控制核心就两个proprietary_codecs和ffmpeg_branding。前者决定是否启用专利编解码器H.264、AAC、MP3后者决定 FFmpeg 的品牌配置Chrome表示包含所有专有编解码器Chromium表示只有开源部分。在C:\cef\chromium_git\chromium\src\cef目录下创建create.bat内容如下cd C:\cef\chromium_git\chromium\src\cef # 生成 VS 工程文件关键在 GN_DEFINES set GN_DEFINESis_official_buildtrue proprietary_codecstrue ffmpeg_brandingChrome set GYP_MSVS_VERSION2022 set GN_ARGUMENTS--idevs2022 --slncef --filters//cef/* python ..\tools\gclient_hook.pyis_official_buildtrue会开启正式构建的优化体积更小、性能更好但编译时间更长。如果你只是内部测试可以设成 false 加快编译。proprietary_codecstrue和ffmpeg_brandingChrome必须同时出现只设一个不生效这是最常见的翻车点。3.2 用 GN 参数表核对每一项配置下面这张表是我每次编译前都会核对的参数缺一项就可能导致 MP4 播不了参数推荐值作用漏设后果proprietary_codecstrue启用 H.264/AAC/MP3MP4 黑屏、MP3 静默ffmpeg_brandingChromeFFmpeg 含专有解码器同上且报 demuxer 错误is_official_buildtrue正式构建优化体积大、性能略低is_component_buildfalse非组件构建生成多个 dll部署麻烦symbol_level1符号级别调试信息过多体积膨胀enable_naclfalse关闭 NaCl无用依赖增加编译时间blink_symbol_level0Blink 符号级别体积过大is_component_buildfalse很重要组件构建会生成一堆 dll部署时容易漏文件。symbol_level1保留基本符号方便崩溃时定位设成 0 则完全无符号设成 2 体积翻倍。3.3 生成工程并开始编译配置好 GN_DEFINES 后执行create.bat它会调用gclient_hook.py生成cef.sln。然后进入chromium\src目录用 ninja 编译cd C:\cef\chromium_git\chromium\src # 编译 Release 版目标 cefclient 和 libcef ninja -C out\Release_GN_x64 cefclient libcef # 如果只要 libcef.dll可以只编 libcef ninja -C out\Release_GN_x64 libcefout\Release_GN_x64是默认输出目录如果你在 GN_ARGUMENTS 里改了--ide目录名可能不同。编译时间在 16 核机器上大约 1.5 到 2 小时8 核机器 4 小时以上。中途报错先看是不是 VS 版本问题再看 GN_DEFINES 有没有写错。编译完成后out\Release_GN_x64下会有libcef.dll、libcef.lib、cefclient.exe等文件。用cefclient.exe打开一个本地 MP4 文件测试能正常播放就说明编解码器已经编进去了。4. 验证 MP4/MP3 是否真的编进去了三种可复现的检测方法4.1 用 cefclient 直接播放本地文件最直接的方法就是拿cefclient.exe测。启动后地址栏输入本地 MP4 的file://路径比如file:///C:/test/sample.mp4。如果画面出来、声音正常说明 H.264 和 AAC 都编进去了。MP3 同理输入file:///C:/test/sample.mp3能听到声音即可。如果黑屏但控制台没报错先检查文件路径有没有中文CEF 对file://中文路径支持不好换成纯英文路径再试。如果报DEMUXER_ERROR_COULD_NOT_OPEN基本就是ffmpeg_branding没设成Chrome。4.2 用 HTML 页面批量测试多种格式建一个test.html把常见格式都列进去一次性验证!DOCTYPE html html body h3MP4 H.264/h3 video srcsample_h264.mp4 controls width320/video h3MP3/h3 audio srcsample.mp3 controls/audio h3检测结果/h3 script // 用 canPlayType 检测编解码器支持情况 const v document.createElement(video); const a document.createElement(audio); document.body.innerHTML pH.264: v.canPlayType(video/mp4; codecsavc1.42E01E) /p; document.body.innerHTML pAAC: a.canPlayType(audio/mp4; codecsmp4a.40.2) /p; document.body.innerHTML pMP3: a.canPlayType(audio/mpeg) /p; /script /body /htmlcanPlayType返回probably或maybe表示支持返回空字符串表示不支持。这个方法不用真的加载文件适合快速判断。注意avc1.42E01E是 H.264 Baseline Profile 的 codec 字符串不同 Profile 字符串不同但只要能返回非空就说明 H.264 解码器在。4.3 检查 libcef.dll 里是否包含 FFmpeg 符号如果上面两种方法都不方便可以直接查 dll。用dumpbin或者 Dependency Walker 看libcef.dll的导出符号搜avcodec相关# 用 VS 自带的 dumpbin 查看导出符号 dumpbin /exports C:\cef\chromium_git\chromium\src\out\Release_GN_x64\libcef.dll | findstr /i avcodec h264 aac mp3如果能看到avcodec_register_all、ff_h264_decoder之类的符号说明 FFmpeg 编进去了。这个方法适合在 CI 里做自动化校验比人工点播放器可靠。5. 编译与运行中的避坑清单5 个真实踩坑记录5.1 坑一gclient sync 卡在下载 nodejs 或 python现象执行automate-git.py时卡在Downloading nodejs或python不动几十分钟没进展。原因depot_tools 默认从 Google 存储下载预编译的 nodejs 和 python网络不通时就会卡住。解决设置环境变量DEPOT_TOOLS_WIN_TOOLCHAIN0之外再设GYP_MSVS_OVERRIDE_PATH指向本机 VS并确保本机已装 Python 3.9 以上。如果还是卡可以手动下载 depot_tools 的bootstrap所需文件放到depot_tools\bootstrap目录或者用set DEPOT_TOOLS_UPDATE0跳过自动更新。5.2 坑二GN 报错「Unsupported VS version」现象执行create.bat时 GN 报Unsupported Visual Studio version。原因Chromium 110 对 VS 版本有白名单VS2022 17.7 以上不在白名单里。解决降级到 VS2022 17.5 或 17.6或者修改chromium\src\build\vs_toolchain.py里的版本判断逻辑把 17.7 加进去。改源码是下策升级 CEF 版本才是上策但 110 分支就这个限制。5.3 坑三编译到一半报「fatal error C1060: 编译器堆空间不足」现象编译blink或v8时 MSVC 报 C1060或者直接进程崩溃。原因64 位编译单个文件内存占用可能超过 4GB默认 MSVC 堆空间不够。解决在create.bat里加set GN_DEFINES%GN_DEFINES% use_thin_ltofalse关闭 ThinLTO 能显著降低内存峰值。另外把虚拟内存调到 32GB 以上物理内存最好 32GB。如果还不行用ninja -j 4限制并行编译数牺牲时间换稳定。5.4 坑四编出来的 libcef.dll 放 MP4 还是黑屏现象确认proprietary_codecstrue和ffmpeg_brandingChrome都设了编出来的 dll 还是播不了 MP4。原因GN_DEFINES 设置后没有清理旧的 out 目录ninja 用了缓存的旧配置。解决删掉out\Release_GN_x64整个目录重新执行create.bat和ninja。GN 参数变更后必须重新生成不能只重新编译。这是最容易被忽略的一步很多人改了参数直接 ninja结果配置根本没生效。5.5 坑五部署到客户机报「找不到 VCRUNTIME140.dll」现象开发机跑得好好的拷到客户机双击 exe 报缺少 VCRUNTIME140.dll 或 MSVCP140.dll。原因CEF 编译产物依赖 VS 运行时库客户机没装对应版本的 VC Redistributable。解决随包附带VC_redist.x64.exe或者把libcef.dll同目录下的vcruntime140.dll、msvcp140.dll一起拷过去。注意 VS2022 的运行时和 VS2019 不通用客户机装 2015-2022 合集版最稳。6. 进阶把非官方 CEF 集成进自己的项目并做版本管理编出libcef.dll只是第一步真正落地要解决的是「怎么在自己的 C 或 C# 项目里用起来并且下次升级 CEF 时能快速复现」。我一般会建一个独立的cef_build仓库把create.bat、GN_DEFINES、automate-git.py的调用脚本都提交进去每次编译只改版本号。集成到 C 项目时把libcef.dll、libcef.lib、include头文件、Resources目录含icudtl.dat、cef.pak、locales一起拷到项目依赖目录。C# 项目用 CefSharp 的话CefSharp 的 NuGet 包自带的是官方无编解码器版本你需要把 NuGet 包里的libcef.dll替换成自己编的同时保持 CefSharp 的CefSharp.Core.dll版本和 CEF 版本匹配。110 对应 CefSharp 110.0.300替换后重新生成即可。版本管理上我习惯在cef_build仓库里打 tag比如110.0.5481.180-mp4tag 里记录 GN_DEFINES 和 VS 版本。下次要升到 112 或 114只需要改--branch和 tag 名其他脚本不动。这样每次升级的 diff 很小排查问题也快。最后一个技巧如果你只需要 MP3 不需要 MP4可以把ffmpeg_branding设成Chrome但proprietary_codecs保持 true然后在ffmpeg的 GN 配置里裁掉 H.264 解码器能减小 dll 体积约 3MB。不过这个操作要改third_party\ffmpeg\ffmpeg_generated.gni容易出错不是体积敏感场景不建议折腾。我自己踩过最深的坑是第一次编译时忘了删 out 目录改了 GN_DEFINES 直接 ninja结果白等两小时编出来的还是无编解码器版本。从那以后我养成了一个习惯只要动了 GN 参数先rmdir /s /q out再重新生成。这个习惯帮我省下的时间比任何优化都值。希望帮到你。本文还有配套的精品资源点击获取