1. 这场竞争为什么现在才被摆上台面先说一个有意思的巧合。最近不少做视频处理的朋友都撞上过这样一个报错UnicodeEncodeError: gbk codec cant encode character。你看连 Python 处理字符串时都会因为“编码标准不统一”而翻车视频领域这边关于“下一代编码标准到底该往哪走”的争论也卡在同样的十字路口上。一个是字符编码一个是视频编码本质上是同一类问题信息在传输和存储时怎么用最少的比特把该表达的东西表达清楚。在视频编码圈里H.266/VVC 和神经编码Neural Video Coding就是目前最有竞争力的两个方向。H.266 是传统编码路线的集大成者几乎把手工设计的编码工具榨到了极限号称比上一代 H.265/HEVC 再省 30%-50% 码率。而神经编码则是把深度学习模型直接塞进编解码链路跳过人工设计的模式用神经网络自己找压缩规律。两者路线截然不同但目标高度一致用更少的码率还原更高清的画质。这篇文章不打算搞那种“最终赢家是谁”的站队式结论而是把这两个方向拆开来看它们各自真实的水平、背后的技术逻辑、落地的难度以及最关键的——它们之间真正的竞争关系其实很可能不是“你死我活”而是“合二为一”。2. H.266/VVC 到底牛在哪2.1 它强在“把老手艺做到极限”如果要一句话总结 H.266/VVC 的技术本质那就是它没有改变编码范式但把所有环节的工具精度都往上推了一级。编码范式还是沿用了几十年的混合编码框架——预测、变换、量化、熵编码这一套流水线但 VVC 在每个环节都做了“更精细的分工”。拿块划分来说。H.265 最大支持 64x64 的编码树单元H.266 直接推到了 128x128而且引入了 QTMT四叉树加多类型树结构——不仅允许正方形块还能拆成横向或纵向的长条形块。为什么这样做因为画面里的纹理往往是各向异性的比如天空渐变色、墙面砖缝、人物头发丝这些内容用方形块去拟合要么块太大拟合不准要么块太小浪费比特。长条形的块能更贴合自然画面的边缘走向压缩效率自然就上去了。再比如帧内预测的角度H.265 支持 33 种角度模式H.266 直接翻到 65 种。角度越多意味着参考像素能更精确地沿着纹理方向去预测。但代价也很直观模式越多编码器在决策时的计算量就越大需要做的率失真优化搜索空间也越大。这就是 VVC 一直被诟病“编码复杂度爆炸”的根本原因。2.2 VVC 的几个关键提升点到底提升了什么我用一个比较直观的类比来解释 VVC 的几项核心技术多参考帧与运动细化以前是找相似的参考块之后就直接抄过来H.266 会在参考块附近再做一次更精细的位置修正相当于在旧照片里眯着眼睛再对一次焦。这就是 DMVR解码端运动矢量修正干的事。仿射运动补偿以前假设画面里的物体是平移的但实际场景里有旋转、缩放比如无人机航拍推进、镜头通过窗外的物体。仿射模型用 4 参数或 6 参数来描述运动可以在一个块内表达旋转缩放变化。这个工具对航拍视频、影视镜头抖动的提升非常明显。环内滤波增强VVC 在去块滤波和 SAO 之外加了 ALF自适应环路滤波器用维纳滤波器对重建画面做全局修正。滤波不是简单地去除噪声而是让重建帧尽量逼近原始帧的像素分布。这些工具叠加起来效果确实扎实。实测在同等主观画质下VVC 相比 HEVC 平均节省约 35%-40% 码率极端内容屏幕内容、纹理密集场景下可以到 50% 以上。这个数字是编码领域很少见的大跳级因为每一代标准的码率压缩率提升通常在 25% 左右VVC 直接干到了接近两倍。2.3 代价与门槛为什么“先进”不等于“普及”VVC 的编码复杂度大概是 HEVC 的 10 倍左右解码复杂度则是 2-3 倍。很多人觉得“编码慢没关系反正可以离线编解码快就行”但直播和实时通信场景完全不一样——那要求在几十毫秒内完成编码VVC 的软件编码要在普通 CPU 上做到 1080p 实时目前依然是很大挑战需要极强的优化或者依靠专门的硬件编码器。还有一个更现实的问题专利授权。HEVC 当年被专利池搞得七零八落VVC 的授权模式到现在也没有彻底清晰这让很多中小厂和开源社区在现场观望。编解码器的标准技术再先进授权费谈不拢就只能在巨头的武装里打转普通团队根本不敢碰。3. 神经编码路线变了而不是算法升级3.1 神经编码的工作原理与 H.266 完全不同神经编码的底层逻辑是不做人工设计改用神经网络学一个压缩函数。传统编码器是“我告诉你规则你按规则编”神经编码是“我让你看一百万张图你总结出怎么编最省”。具体架构上目前主流的学习型图像/视频编码框架大致是这样的编码端先做非线性变换把像素域映射到隐空间latent space然后用超先验网络捕捉隐空间的概率分布结合上下文模型做熵估计最后用算术编码把特征量化后的符号压成码流。解码端再通过对称的神经网络反变换重建画面。这套路子和传统编码器的“分块-预测-变换”完全不同。神经网络不限定块大小也不区分帧内帧间它把所有信息建模成一个高维张量在隐空间里做压缩。更新的视频编码模型还会引入光流网络来估计帧间运动再用 warping 做运动补偿相当于把传统编码器里的“运动估计运动补偿”模块替换成了“光流网络可微变形”。3.2 神经编码目前能做到什么水平衡量编码效率最权威的方式是用详细的测试条件下做 BD-Rate 对比也就是在相同质量下比较码率节省比例。目前发表在 CVPR、ICLR 等顶会上的多个神经视频编码模型在 PSNR 指标下已经能做到与 VVC 相当、甚至在特定数据分布下超过 VVC。需要说明的是这些对比通常是在特定测试集上完成的而不是像标准组织那样在多样化的大规模语料库上做一致性测试所以参考意义和全面性还需要打折。这里必须泼一盆冷水实验室里的“超过 VVC”和工业级的“可用”差距很大。因为码率节省的前提是模型知道测试集的内容分布。你要是用自然风景片训练突然丢给它一个屏幕录制视频它的性能会下滑得很厉害。传统编码器就没有这个问题因为手工设计的工具是通用的不管画面里是猫还是飞机还是 Excel 表格它都按同一种规则处理。3.3 神经编码的复杂度常被误解很多人以为“神经网络编码肯定比 VVC 快”这是个严重的误解。神经编码的编码端推理确实不需要像传统编码那样做海量模式搜索看起来“一次前向传播就搞定”但这“一次前向”在 GPU 上可能要跑几百毫秒。更麻烦的是熵编码环节。传统编码的熵编码是轻量级的查表操作而神经编码里的概率估计是网络实时预测出来的解码端每解一个符号就要跑一次网络推理。而且如果要维持压缩效率上下文模型需要逐个符号串行解码——这个串行过程是 GPU 最不擅长的事情时延非常高并行化极难。这也是为什么神经编码虽然压缩率屡创新高但离实时视频通话这种场景依然有非常大的距离。4. 正面碰撞四个维度的综合对比我整理了一张对比表按实际应用视角去比较这两个路线维度H.266/VVC神经编码压缩效率相比 HEVC 省 35%-50%稳定可预期特定内容/特定模型下与 VVC 打平或略胜但泛化性弱编码复杂度极高HEVC 的约 10 倍需硬件或强优化GPU 推理不适合 CPU熵编码串行化时延高解码复杂度相对可控HEVC 的 2-3 倍硬件化潜力大解码也是神经网络算力需求高移动端暂不现实标准化与生态ITU/ISO 标准产物专利授权待明确生态尚在建设无统一标准各团队自研架构模型互不兼容实时性靠硬件编码器可满足直播/通话场景目前实时低延迟场景基本不可行泛化性内容自适应任何画面都能编对训练分布外的内容稳定性差单拎任何一个维度做“谁更先进”的结论都容易跑偏。压缩率上神经编码已经逼近甚至局部超越 VVC但这是靠巨大的算力代价和内容特化换来的通用性和生态成熟度上VVC 又完全碾压神经编码。我实话讲单看已经达到的水平VVC 是目前唯一能真正商用的“下一代标准”——注意是“能商用”不是“已普及”。神经编码更像是从另一个维度杀出来的潜在变量它证明了一件事编码工具可以不再是手工设计的。5. 真正决定胜负的是标准组织的“兼容并蓄”5.1 神经编码正在被标准化很多人不知道ISO/IEC 的 MPEG 和 ITU-T 的 VCEG 一直在关注神经编码的进展。MPEG 甚至在近期启动了神经压缩标准的探索——试图定义一种统一的神经编码接口不强制具体模型结构而是规定模型部署的框架和码流格式。这意味着“神经编码”并不一定永远是各玩各的它正在被标准化的“安全网”接住。这一块的意义相当深远。一旦有了标准接口不同厂商训练的模型就能在同一容器里部署播放端只需要支持“神经解码加速模块”就能解码不同模型的码流。这和当年 H.264 统一解码兼容是一个逻辑只不过把“解码器芯片”换成“通用模型容器”。5.2 下一代真正的形态基座仍是传统框架这里是我个人这几年观察下来最有信心的判断下一代视频编码不会是“纯神经”而是“传统框架神经增强模块”的混合体。这不是谁替代谁的问题而是分工问题。传统编码框架里块划分、运动补偿、变换、量化这套结构经历了三十年验证鲁棒性极强。问题在于人工设计的工具无法精准地适配任意内容而神经网络恰恰可以在细节局部做“超分辨率增强”或者在决策环节做“率失真优化加速”。典型案例就是 JVETH.266 的制定团队已经在探索的 NNVC神经网络视频编码方向——保留 VVC 的块结构和运动补偿但把环路滤波替换成神经网络滤波器或者在帧内预测时用神经网络辅助生成参考像素。这样做的好处是编码复杂度只增加 10%-20%但压缩效率可以再提升 15%-20%。而且由于基础结构还是标准框架兼容性没问题你即使用神经增强模块解码也可以退回纯传统解码器——这就是一种向下的兼容性保障。5.3 “先有鸡还是先有蛋”的生态问题为什么 H.266 到现在都没有全面普及说白了不是技术不行是生态没转起来。编码器做好了但没有设备硬件解码就没有终端会播放没有播放需求就没有内容方愿意用内容方不用芯片厂就没有动力把解码器做进 SoC。这是一个典型的先有鸡还是先有蛋的问题。神经编码要走进这个生态除了要解决算力和泛化还要面对一个更根本的挑战——模型持续更新的问题。传统解码器一旦定义好几十年不用改神经模型要是更新了版本旧码流还怎么解这需要通过“模型版本管理”和“码流内嵌模型描述”来兜底而不是像传统标准那样“一次性冻结”。所以我倾向于这样看未来两三年内H.266 一定会在大规模视频分发场景里逐步落地因为它的硬件解码方案已经趋于成熟而神经编码会在特定垂直场景爆发比如视频云转码、影视文件压缩、医学影像存储、监控视频归档这些对编码耗时不敏感的离线场景。6. 给工程实践者的选型建议如果屏幕前的你正准备在项目里用上“下一代编码”我根据自己的实际踩坑经验给几条判断建议第一视频内容以自然场景为主、有离线批量处理需求可以开始试神经编码模型。选模型时别看论文里的 PSNR 和 BD-Rate 数字直接拿 500 张与你真实业务数据分布接近的图片做一次主观对比测试“眼见为实”永远是第一标准。第二做实时通话、直播、会议这类延迟敏感型业务短期之内不要指望纯神经编码方案。老老实实跟硬件平台确认支持 AV1 和 H.266 的时间表在硬件成熟之前HEVC 依然是性价比最高的选择——这个话说出来可能不好听但现实就是如此。第三做视频编辑、非编系统、后期制作工具需要灵活逐帧访问H.266 的帧内编码和随机访问能力依然不可替代。神经编码目前对随机访问、帧级编辑的支持非常弱基本是整段序列一起压缩这一点在实际剪辑流程里往往是致命的。第四如果你是独立开发者或小团队别轻易押注任何一个标准去做深度定制。保持解码器抽象、编解码参数可配置让核心业务逻辑与具体 Codec 解耦——这一条经验我在 AV1 和 HEVC 切换上吃了不少亏等到 H.266 成熟时能换得更加从容。再分享一个实操细节做神经编码部署时千万别忽略量化导出的环节。很多模型在 PyTorch 里 PSNR 很高一旦转成 TensorRT/ONNX 并做低比特量化重建画面立刻出现色偏或块状伪影。这在传统编码器里不会遇到所以在搭神经编码工程链路时建议在模型训练阶段就用模拟量化导出后再做一次验证集全量回归。7. 最后的个人观察回头看那个gbk codec的报错其实挺适合做这次讨论的注脚——字符集不同导致同样的字节被人为地解错。视频编码领域也处于类似的“标准冲突期”H.266 的标准很严谨但它是在旧范式的延长线上神经编码虽然打破了很多限制但距离“可用的标准”还有很长的路要走。我个人在实际实验里最大的感受是不要用“谁替代谁”的思路去理解这件事。传统编码和神经编码不是两个赛道的竞争对手而是同一道工序里的两个环节。真正能做出来的下一代视频编码系统大概率是让 VVC 的稳健结构做骨架让神经网络在骨架上的关键节点提供“读不懂规则时用经验补位”的能力。最后再分享一个我在对比测试中的发现单独测 H.266 和单独测神经编码都各有亮点但把它们串成一个混合管线——用神经网络后处理增强 VVC 解码画面——在相同码率下主观画质提升反而比单纯替换编码器更明显。这个小实验给了我一个很强烈的启示下一代 Codec 的竞争比拼的不是某一个单一技术的极限而是把现有技术重新组合的能力。这大概才是这场竞争里最值得关注的部分。
企业数字化 ERP 产品动态
相关推荐
Django认证模板美化:AllAuth UI集成与定制指南 Django 项目里集成第三方认证功能,很多人第一反应是上django-allauth——它确实是这个生态里最成熟、覆盖最全的方案,邮箱注册、第三方账号登录、邮箱验证、密码重置这些流程它全包了。但真正动手接过的人都知道,功能齐全是它的事,… · 2026/11/2 20:01:30
跨网文件摆渡系统:安全传输与行业应用解析 1. 跨网文件摆渡系统的本质与核心需求在医疗、金融、半导体等对数据安全要求极高的行业里,网络隔离是常见的安全防护手段。我曾参与过某三甲医院内外网改造项目,亲眼目睹医护人员为了传输一份CT影像报告,不得不反复使用U盘在内外网电脑间&quo… · 2026/11/2 20:01:30
安理会限速、真武V900、Gemini4泄题:AI正从比快转向比稳 1. 早上刷屏的三条消息,拼出了今天AI圈的全貌今天早上起来,群里消息直接炸了。三条新闻几乎同时刷屏:国际方向开了一场关于AI“限速”的高层讨论,云栖大会上真武V900正式亮相,Gemini 4的“幽灵模型”传闻又说有实锤泄露… · 2026/11/2 20:01:30
CogAgent 9B:AI精准操控GUI界面的终极工具 CogAgent 9B:AI精准操控GUI界面的终极工具
导语:基于GLM-4V-9B大模型优化而来的CogAgent 9B正式发布,凭借在GUI感知、操作预测和跨平台适配能力的突破性提升,重新定义了AI驱动的图形界面自动化交互标准。
行业现状:从… · 2026/11/3 1:59:19
【深度学习-实验】花卉识别:用少量数据构建多分类系统的设计思路 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:59:19
StepVideo-T2V-Turbo:15步生成204帧视频的AI新突破 StepVideo-T2V-Turbo:15步生成204帧视频的AI新突破
导语:AI视频生成技术迎来效率革命——StepVideo-T2V-Turbo模型实现仅需15步扩散即可生成204帧高质量视频,将文本到视频的创作效率提升3倍以上。
行业现状:从"能生成"… · 2026/11/3 1:59:19
Prometheus+Grafana监控 部署根目录:/home/ops_app_user/middleware/prometheus
一、部署概述
1.1 适用场景
单业务服务器/小规模集群的主机系统、Docker容器、MySQL数据库、Redis缓存一体化监控,满足生产环境持久化、权限管控、告警预留、可维护性要求。
1.2 组件清单ÿ… · 2026/11/3 1:59:19
【51】番茄成熟度数据集(有v5/v8模型)/YOLO番茄成熟度检测 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:59:19
《潜意识之门(三)》生生不息催眠的三大核心原则:将问题转化为资源的智慧 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:58:19
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 4:42:45
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 5:17:18
STM32F411RE与MAX14431实现SPI隔离:工业现场抗共模干扰实战 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
ESP32+大模型AI硬件开发:从Demo到产品的8个工程问题 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
基于MAX14431BAEE+与PIC18F85J10的SPI隔离方案设计与实践 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/3 1:01:59
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 13:10:28
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 4:42:45
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案 /* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/2 5:17:18