由于视频编码算法H.265专利费上涨，戴尔和惠普部分机型暂停对其支持
戴尔和惠普因专利费上涨在部分电脑上禁用硬件H.265解码功能——企业可大幅节省HEVC专利费，但代价是用户体验受损
据报道，戴尔和惠普已开始在部分个人电脑上禁用HEVC/H.265硬件解码功能，此举可能是为了规避向专利持有者支付专利费。多数禁用HEVC/H.265硬件解码功能的电脑属于面向商务的入门级或主流机型，而配备高品质显示屏的高端产品则完整保留所有功能。
戴尔和惠普向笔者确认，其多款笔记本电脑（包括戴尔“标准及基础配置机型”，以及惠普EliteBook和ProBook 600系列G11、400系列G11、200系列G9机型）均禁用了HEVC/H.265编码视频流的硬件解码支持。戴尔强调，配备集成4K显示屏、独立显卡、杜比视界或Cyberlink蓝光软件的系统仍保留HEVC/H.265硬件解码功能。值得注意的是，戴尔建议用户通过微软应用商店购买“经济实惠的第三方应用”来重新启用HEVC解码功能。
尽管戴尔和惠普均未解释移除长期存在的硬件解码功能的动机，但笔者认为，由于HEVC/H.265编解码器专利持有者计划短期内提高许可费，这些公司正试图削减成本。事实上，设备制造商若要在终端支持HEVC/H.265视频硬件解码，必须向MPEG LA（每台设备0.2美元，或每年每实体2500万美元）、HEVC Advance（每台设备最高1美元，或每年4000万美元许可上限）、 Velos Media（传闻每台设备1至2美元）、Via LA（每台设备0.25美元或实体年限额2500万美元）。鉴于戴尔和惠普每年销售数千万台个人电脑，此类许可费用的减少意味着每年可节省数千万美元。然而，这种节省也意味着终端用户体验将大幅降低。
几乎所有独立显卡和集成显卡均支持HEVC/H.265编码视频流的硬件解码，首批具备此功能的GPU早在2015至2017年间便已问世（英特尔平台始于Kaby Lake架构）。GPU开发商需为在芯片层面实现HEVC硬件解码支付费用，因此专利池可直接从苹果、AMD、英特尔、英伟达或高通等公司获取收益。但若要在设备层面启用硬件解码功能，原始设备制造商同样需向专利池付费。若未支付专利使用费，OEM厂商需通过以下方式禁用该功能：修改驱动程序实现软件层禁用，或修改固件层禁用，抑或要求GPU供应商在芯片层面熔断该功能（此举通常不会实施）。
若通过修改驱动程序禁用功能，终端用户可轻松安装AMD、英特尔或英伟达的通用驱动程序重新启用，但需付出部分定制化功能的代价。然而固件层级禁用的功能难以恢复。此外，尽管戴尔提出建议，若驱动程序或固件已禁用硬件HEVC解码功能，任何第三方播放器均无法重新启用该功能。它们只能添加耗电的软件解码方案，但这可能是许多预装程序默认具备的功能。
因此，低价位系统用户似乎只能选择采用AV1或其他开源硬件编解码器编码的内容，或寄希望于自身CPU性能足以解码高分辨率HEVC流媒体。
他们订购的所有芯片难道不是已经付过许可费了吗？
我倒是能想象他们未来会从芯片中移除这项功能。
这听起来很蠢。
他们采用的似乎是按设备计费的许可模式。我认为这是在细分市场的同时节省成本——从企业笔记本中移除该功能(毕竟多数企业不会进行视频制作)，同时向支持4K视频制作的高端型号进行升级销售。
但这仅涉及解码功能，不包含编码。
我认为许可证并不区分编码与解码，多数硬件编解码器本就兼具双重功能。
传统上许可证是分开的。H264对播放器和编码器的许可证就完全不同。
企业需要H.265。这叫视频会议。
AV1运行良好。
我差点看成AVI格式
H264依然运行良好。
~视频会议中将码率减半可为企业节省可观成本。
H.264专利早已过期。
H.264/VP8/VP9和AV1都是可行的替代方案。
你暗示内容消费者有选择权。
4K分辨率下H.264文件体积同样庞大
实际用户本就无法选择内容存储格式，各平台提供的服务涵盖多种格式而非仅限HEVC。
我认为颇具讽刺意味的是，如今HEVC的重要性已不如一年前。
这取决于你如何定义消费者。
设想你因新生儿购置相机，其输出文件很可能采用HEVC格式。你将照片发给刚买新笔记本的奶奶以便她观看视频。
这类人群大多缺乏技术背景去选择其他格式。
我不明白的是：他们仅在笔记本上取消支持？还是所有台式机现在都用F系列芯片？
或许移动设备或内置摄像头的设备有不同授权条款…这在H.264时代就存在争议。
AV1的解码/编码技术比HEVC要新得多。
H.264在该领域仍占据主导地位。
兄弟，事情没这么简单。HEVC专利持有者通常按设备而非芯片授权。顺便说一句，
拒绝HEVC，拥抱AV1。
说真的，H.265的授权简直一团糟。真盼着AV1能直接成为标准，从此不用再听这些事。
苹果在这方面拖延已久。他们最近才添加AV1解码支持，但录制视频仍用HEVC编码。甚至不确定他们是否已实现AV1硬件编码。
刚发布的M5芯片仅支持解码，不支持编码。A19/A19 Pro同样如此。
至少现在所有设备都支持硬件解码了。我猜他们可能想等更多设备支持解码后再推出编码功能
总有一天我会把视频转成AV1格式。不过iPhone录制的码率高得离谱，转码后可能根本看不出区别。
其实“硬件编码”这个概念本身就值得商榷。复杂编码格式中不存在真正意义上的固定功能编码器，本质上是由主CPU或系统协处理器调度的硬件单元组合。
因此添加AV1解码功能(即便尚未完全优化)本质上是编写一个编解码器：尽可能调用硬件单元，不足部分由软件补足。
有人知道在已支持HEVC、h.264等编码器的硬件上，需要新增哪些单元才能称之为“AV1专用硬件”吗？
苹果选择HEVC作为标准编码器让我很失望。他们常这么做，就像当年采用AAC编码那样。自从决定用HEIF存储相机照片后，他们就有了强烈的理由在视频领域支持HEVC。
谷歌在YouTube上播放苹果设备时似乎仍使用VP9编码。
确实如此。该标准本就面临普及困境，如今又因企业相继撤销支持而遭受重创。群暉科技也刚宣布放弃支持。
其授权协议终将导致该标准走向衰亡。
作为参与HEVC技术标准制定者，我全力支持AV1
哇哦！
有个疑问(如有误请指正)——HEVC针对人脸运动补偿的特殊优化方案，在常规场景中是否真正有效？这个设计似乎过于特殊化了。
那么你认为未来什么技术可能会取代DCT成为压缩领域的核心技术？我对机器学习风格的Transformer系统如何运作有个模糊的概念(“Sora就像7Zip，只不过它能把1KB文本解压成500MB视频”)，但我知道事情绝非如此简单。
我只能想象基于AI的压缩所需计算量会比预定义算法高出几个数量级。到那时存储和带宽成本恐怕会低于处理能力。
针对人脸运动补偿的优化方案，实际效果极为显著。我虽未参与该项目团队，但出于好奇旁听了多次研讨会。这些改进的核心目标是解决唇形同步问题——这始终是实时压缩领域的顽疾，尤其在必须采取最短路径处理的场景下。若无这些优化，尤其在p30内容中，帧时序会明显滞后于嘴部动作等细节。早期编码器硬件对HEVC编码的细节区域(如面部)尤其苛刻，因其子块几何结构大幅增加。
随着硬件升级和实时编码帧率提升至60帧(NHK等极少数案例甚至达到120帧以上)，这项优化逐渐成为常规操作，技术焦点已转向其他领域。
至于大型语言模型(LLM)将1KB文本“解压”为500MB视频的概念并不准确——其输出本质是生成式内容而非真实视频(尽管需要参考现有视频进行训练)。这种操作不仅计算成本极其高昂，且无法保证生成的视频能准确还原原始素材。
机器学习引擎(及特定LLM)真正发挥作用的领域在于压缩算法的设计与优化，尤其体现在HEVC和AVI等编解码器的输入分析环节。IMAX团队(前身为SSIMWAVE)已发表多篇论文并开发出可实际运行的视频质量分析引擎，这些技术被应用于编码器采集环节，可实时调优HEVC和AVI管道以优化视觉焦点编码。这些努力在压缩效率和视频质量方面都取得了飞跃性进步，那种从外向内压缩(过度柔化视频边缘)的时代早已一去不复返。
感谢分享，这些见解非常宝贵。
请问您是如何加入专家组的？这真是了不起的成就！
我在某大型电信公司任职23年，负责视频基础设施的设计、工程实施与建设。在此过程中，我成为该领域的技术专家(SME)，并代表公司参与标准委员会工作。
我的首个标准项目是3D电视广播标准制定，当时我深入参与了压缩算法计算工作——远超电信领域代表的预期(这很合理，毕竟其他电信代表的技术背景都相当有限)。正是这些合作关系将我引入HEVC专家组，主要负责函数并行化工作，并协助完成BT.2020色彩空间管理规范。
> 我曾为某大型电信企业服务23年，负责视频基础设施的设计、工程实施与建设
H.263标准令人印象深刻，哈哈
啊，是的。我也接触过h.263标准。我那段与恐怖的H.263打交道的短暂经历，发生在H.264尚在评审阶段时。当时我在2002年左右为一家小型服务商工作，他们正在尝试视频通话技术。那是我接触视频编码的起点。后来这家小公司被我工作了23年的企业收购了。
需要说明的是，即使我说“大型电信公司”，指的也是同时提供有线电视和卫星电视服务的企业。
大型语言模型似乎让我们离实现过程化压缩更近了。
但我依然认为行不通。模型在生成过程中会注入随机性，导致无法复现输入内容——这就是为何相同提示词会产生不同结果的原因。
我说的不是LLM。
管它叫什么都行。
这些系统本质上是生成符合提示描述的图像或视频。结果在“符合描述”方面得分很高，但它们无法复现任何输入图像。
这并非“解压1KB文本”，而是生成符合提示的内容。因此不存在录制回放机制，对压缩/解压毫无用处。
> 这些系统仍通过生成符合提示描述的图像或视频来运作。
你这里指的是特定应用场景——那种基于自然语言文本提示和概率驱动的系统；而我并非在谈论此类应用(我仅以Sora为例阐释更广泛的_信息论_压缩概念)。
“人工智能”和机器学习的内涵远不止文本提示驱动的大型语言模型。
我们需要为此创造新术语，因为“有损压缩”根本无法描述基于Transformer的视频处理。
或许可以取个带“氛围感”的名称？氛围编码？
当年JPEG2000问世时，小波变换(DWT)本应成为继离散余弦变换(DCT)后的下一个革命性技术。
啊对；上次看到相关讨论都过去十多年了，哈哈——可惜JPEG2000未能广泛普及。
JPEG2000在点对点视频传输领域应用广泛且历史悠久，尤其在体育赛事直播场景(如场馆与远程演播室/制作流程间的传输)。早期曾尝试用于4K等客户端传输，但成本过高。
您指的是针对兴趣点的局部压缩，还是泛指人脸压缩？目前我对HEVC的底层工作原理已不太熟悉。
抱歉记不清了，上次研读HEVC文档已是三四年前。但记得相关章节明确提及人脸识别，并配有示意图说明原理——不过你提到的“兴趣点”概念也似曾相识。
说实话VP9确实要归功谷歌，要是他们所有项目都能这么做就好了。
除了某些需要VPN避开身份识别才能在Quest上播放的3D视频网站，VP9还有其他用途吗？替朋友问问。
这是YouTube的默认编码之一。
我认为这是他们1080p以上分辨率的唯一编码方案。
他们也使用AV1编码。
没错，现在主要用AV1了。我第一次评论没说清楚，但核心观点是：AV1基于VP9的技术成果开发，这得益于VP9开源的特性。
许多PC游戏采用VP9视频编码。这是兼容性最广的选择——既能通过自带解码器轻松解码(跨平台稳定性高)，又无授权问题，且性能出色。
VP9正是AV1的基础
过去几年YouTube主流流媒体采用VP9编码。AV1才刚开始出现在更多YouTube视频中，此前主流是VP8/AVC1视频。
企业视频会议工具中也常见VP8/VP9的应用。
Zoom/Teams等WebRTC应用普遍采用VP8和VP9编码。
或者直接用Linux系统，它根本不依赖Windows那些用于启用硬件功能的参数。r/sysadmin/comments/1opxue7/hp_seems_to_be_disabling_hevc_hardware_decode/ r/GeForceNOW/comments/1omsckt/psa_be_wary_of_purchasing_dell_computers_with/ 看来七个月前就出现过这种情况，并非新问题。 r/Dell/comments/1jxwqj6/hevc_hardware_decoding_unsupported_in_latitude/
英特尔、AMD和英伟达本就不该为HEVC(或AVC)编解码开发专用模块，而应直接添加与软件解码器加速所需基础运算相匹配的指令集，这样既能避免软件授权问题，又能规避硬件授权限制(我认为这可能正是当前争议的症结)。
MPEG该退休了。专有编解码器带来的麻烦永远大于其价值。
症结在于高效解码本质上需要专用ASIC芯片。硬件开发者已将单条指令加速到极限，但需要优化整个流程而非孤立步骤。即便CUDA内核也远未达标。r/hardware/comments/wkpmlu/why_are_video_processors_hardware_encoders_and/
这似乎更多关乎设计效率而非纯粹性能——该帖子提到早期Nvidia GPU就实现了基于CUDA的解码。当然它不如专用芯片高效，但解码任务可能本就不需要达到那种程度。
并非如此，我们讨论的是优质视频解码器功耗甚至低于专用DSP缓存所需的功耗。
两者差距悬殊。
我认为两者各有优势。我曾用三台搭载不同型号老款NVIDIA GPU的机器将大量媒体文件转码为HEVC格式。虽然AV1能实现更显著的压缩率并保留稍高的画质，但对我而言差异并不明显。目前仍有大量设备无法解码AV1，除非使用RTX 40XX及以上型号显卡，否则也无法进行编码。我计划逐步转换为两种格式，但由于缺乏支持AV1编码的硬件设备，目前优先采用HEVC格式。
问题在于编解码器的授权而非质量。随着AV1硬件编解码成为标准，H.265完全可以进垃圾堆了。AV1免版税且没有专利池试图敲诈所有人。
英特尔自Meteor Lake(第14代)起，AMD自RDNA 3(基于Zen 4及更新架构)起均支持该功能。但据我所知，AMD存在一个愚蠢的bug——因默认设置为“最近16像素尺寸”编码，导致无法生成标准1080p视频。
编辑：忘记Zen 3+采用RDNA 2而非RDNA 3
AMD RX7000+系列也能做到，但你的观点没错——AV1硬件编码支持确实极其罕见
英特尔所有集成显卡同样不行
现在请让离线AV1编码别耗时太久，同时确保实时编码能以良好画质满足流媒体/连续屏幕录制需求。
其实已经实现了？新款GPU自带AV1编码器，流媒体画质完全够用；CPU编码器处理1080p内容时，高质量模式下运行速度甚至快于实时。
得知技术在进步真是太好了
为何硬件制造商和内容提供商不这么认为？
你为何不喜欢HEVC？/或者你为何更偏爱AV1？
AV1确实更胜一筹，相比HEVC能实现更小文件体积且无画质损失。
瞧，这又为攻击者开辟了新途径，势必会愈发猖獗。
技术小白近来真是够呛。
先是因内容限制法规被迫在可疑VPN的雷区中摸索，如今又因OEM厂商吝于支付授权费，不得不为第三方编解码器重蹈覆辙。
本文引用的Ars Technica论坛原帖作者。
戴尔和惠普那句“用户可自行购买软件解码器”的答复着实令人震惊。这根本解决不了核心问题——运行在操作系统中的软件无法调用支持HEVC的硬件进行解码。我曾尝试使用VLC媒体播放器，包括强制启用Direct3D和DXVA 2.0(在正常系统中可行的配置)，试图让GPU参与解码。但VLC完全无法实现。
就连戴尔官方知识库也承认：虽然可通过购买编解码器实现软件解码，但因硬件解码功能被禁用存在限制——流媒体无法播放4K内容。这意味着若使用4K外接显示器，用户只能自认倒霉。
惠普和戴尔必须认清现实，补缴许可费用，并为受影响机型发布BIOS更新以恢复硬件解码支持。至于操作系统或预装软件是否包含解码器，这应是另一回事。若问题归根结底取决于AMD/英特尔/英伟达/高通是否愿意在硬件中集成HEVC解码支持，那么就该由芯片制造商来决定——毕竟他们本就负责决定在硬件中预置哪些解码器的支持。
但正如你所言，硬件破解者或许会为这些受影响设备发布修改版BIOS文件，以修复HEVC解码功能…
我猜他们甚至没讨论硬件加速的H.265解码——正是为了节省约24美分成本而被禁用的功能(尽管对视频编解码器而言这笔钱确实不少)。但使用第三方软件解码仍会消耗更多电能且体验更差。
若我遇到这种情况，宁愿花25美分通过固件更新解锁内置硬件加速功能(具体取决于锁定方式)。
我仍不明白：iGPU本就负责硬件解码，制造商为何要参与专利授权？软件解码同样能实现播放功能。
你的困惑很合理——HEVC专利池包含大量模糊宽泛的专利，其授权体系也极其复杂。
基本上集成显卡具备硬件解码能力，但这并不意味着CPU制造商承担许可费用——年销量超万台的OEM厂商和公司需承担专利使用费。软件解码器的专利费也存在猫腻，某些售价1美元的Windows编解码器可能随OEM系统捆绑提供，也可能不包含在内。而OEM厂商为节省成本禁用硬件解码的方式也各不相同。
这解释得真够糊涂的。
显然Windows系统对硬件解码的调度机制是关键因素，使用Linux驱动时该问题似乎不会出现。
说实话，如今普通用户基本不再播放视频文件了。他们几乎都通过流媒体观看，而流媒体平台会自动检测设备支持的编解码器。
Ars Technica引用Reddit帖子的原作者。
问题在于这种检测机制失效了。我遇到这个故障是因为浏览器向媒体流服务报告称我的系统支持H.265解码。当服务商实际推送H.265视频时，我遭遇了无限加载——因为浏览器无法调用硬件解码功能。此时必须降级到软件解码支持，虽然能实现HEVC的软件解码，但代价是DRM保护等级被降低。这意味着流媒体服务会将画质限制在720p左右甚至更差。
流媒体服务无法判断用户的解码管道是否存在故障——除非用户安装了原生应用程序才能检测到这种情况…但我认为很少有程序员会考虑到系统中HEVC解码会以这种方式出现故障。
本质上就是这样。即便是播放录制视频，用户通常通过谷歌相册等服务在浏览器中访问，系统会自动选择最佳编解码器。
欧盟地面电视采用HEVC编码。这意味着过去十余年间售出的每台电视机都支持该格式。
等等我不明白，VLC/CCCO/K-lite不都自带可靠的免费编解码器吗？为什么不用那些？
如果硬件未显示支持该编解码器，就会启用软件解码，速度会慢很多。
这里的“慢得多”是相对概念。即使在近16年前的四核桌面CPU上，软件解码播放1080p视频我也没遇到过问题。
分辨率？色度抽样？
多年前测试新购的11700k处理器时，CPU播放8K HEVC 4.2.2格式占用80%以上算力。而集成显卡播放仅占5%，这很可能是当时其他程序的总和。
这不仅破坏了FHD 4.2.0格式，更破坏了所有基于HEVC的播放
哦，所以除非你在树莓派之类设备上运行，否则这根本不是问题
向来如此。先需要Kazaa/KLite编解码器包，后来又得从Windows商店安装HEVC插件。这不算新鲜事
这篇文章充其量只能说是混乱。前文说禁用了硬件功能，后文又说只是未包含编解码器。
到底是哪种情况？是通过BIOS锁死芯片功能，还是仅影响那些未彻底擦除系统的新机用户？
为省下OEM厂商0.04美元导致永久运行卡顿，和“我直接用VLC就行”是天壤之别。
根据几周前Reddit的帖子(似乎与ACPI相关？)，他们禁用了Windows驱动访问硬件解码器的权限。硬件本身仍具备解码能力，但只有Linux驱动能识别它。因此即使使用VLC，在Windows系统下你仍只能依赖软件解码。
资本主义万岁！
这大概也是Synology放弃支持的原因。
别用HEVC编码了，改用AV1吧。
要是更多硬件支持就好了…我还在尝试远程唤醒游戏主机进行编码，那是我唯一支持AV1编码的设备(AMD RX7700XT)
如今Sparkle Arc A310 ECO主板不到100欧元就能买到，当前所有SoC/APU平台也都支持AV1编码。
那么他们如何禁用该功能？我猜是通过BIOS更新实现的。具体推送方式会是Windows更新吗？文章里完全没提这些细节。
这是针对所有2026款机型的措施，部分设备已受影响。
这是UEFI设置项，似乎仅影响Windows系统，Linux对此无动于衷。
啊，新款笔记本在某些网站播放视频时续航竟不如旧款。干得漂亮！
我十五年来始终购买无Windows预装的设备…这才是正道。
购买后移除功能理应构成犯罪。这本是交易的一部分。倘若我卖掉公司后一年宣称“其实我保留了名称和厂房”，定会被告到倾家荡产。
惠普选择不支付硬件HEVC解码的许可费。他们的做法完全合法，毕竟用户仍可使用软件HEVC解码。
这好比你买了游戏电脑，英伟达却决定禁用你的显卡。听到“没关系，你可以用CPU渲染”的解释，你还会心满意足地用3帧每秒的600p分辨率玩游戏？
我多年前在Windows上付费解锁了HEVC功能。一次性支付1美元即可覆盖所有Windows设备。虽然有点坑，但我觉得也没那么严重？是我漏了什么吗？
我另处读到的文章说这是在硬件层面被禁用的。所以据我理解，CPU支持H265硬件解码，但UEFI未启用该功能。
你可以安装软件解码器，但会显著增加电池消耗，若在飞机上观影之类场景就会产生影响。
我对细节的解读未必完全准确，请酌情参考。
这仍是个值得注意的问题…在受影响机器的Linux系统上运行正常。
我也正有此疑。
没错，H.265可通过软解或硬解实现。硬件解码效率高得多——具体百分比虽不确定，但试着用CPU和GPU原生硬件分别编码视频文件，GPU至少快30倍。因此，即使失去编解码器的硬件支持，视频仍可播放，但会消耗大量CPU资源——播放4K电影时，CPU占用率肯定会飙升至100%。
开源编解码技术，AV1就是这个吗？还是说它只是某种未来会商业化的东西？
AV1完全摆脱了这种麻烦。
或许并非完全摆脱，但谷歌会承担所有责任…所以使用者根本不在乎。
早在上世纪，谷歌核心团队就意识到图像、音频和视频压缩算法专利对业务的威胁。他们资助了技术和法律工作，开发出具有竞争力的无专利算法。这是谷歌最明智的决策之一。这项工作扎实且持续推进。
没错，但关键在于谷歌也宣称其无专利限制——这点至关重要。若有人被起诉，他们就能说：看吧，责任在谷歌，他们声称这是免费的。
这就是谷歌为AV1构筑的母体保护盾，意义至关重要。
关键在于：任何试图对AV1使用者发起专利诉讼的行为，都不会遇到会庭外和解的软弱对手。全球最大企业之一将如天谴般降临，誓死捍卫自身商业利益。
顺带一提…这种事早有先例。谷歌不仅财力足以雇佣全世界律师，更因其身份特殊。若有人想与谷歌打专利官司，那绝不会是那个以索引全球信息为使命的巨头。当年专利流氓们这么干时，谷歌就通过深度先有技术研究批量无效化他们的专利，剥夺了他们用来敲诈他人的武器。压缩专利大战异常惨烈，那些流氓们最终领悟了“不可再犯”的教训。
这和群暉在DSM更新及2025产品线上的操作如出一辙？或许能加速AV1的普及进程
我的群暉NAS虽受影响，但播放NAS存储的HEVC内容毫无问题。手机和华硕笔记本也完全能流畅处理。
啊，又是为了省钱对消费者竖中指的老把戏。
这就是让财务部门凌驾于工程团队之上做产品决策的后果。
任何笔记本制造商若未支付授权费就内置HEVC支持，都属于违法行为。法律规定惠普必须阻止用户在其笔记本上使用硬件HEVC解码功能，除非惠普支付许可费。
这成本怎么没计入芯片价格？这种费用本应在产业链最底层解决，才能防止破解软件在后续启用该功能而不付费？