Yt-dlp：YouTube下载即将新增要求
近期起，您需要安装Deno(或其他支持的JavaScript运行时环境)，才能确保YouTube下载功能正常运行。
原因何在？
迄今为止，yt-dlp 始终能通过其内置 JavaScript “解释器” 解决 YouTube 下载所需的 JavaScript 处理需求。但由于YouTube近期实施的变更，内置JS解释器将很快无法满足此需求。这些变更影响深远，yt-dlp必须借助专业的JavaScript运行环境才能解决JS验证问题。
我需要做什么？
所有用户都需要安装Deno(或其他支持的JavaScript运行时环境；详见下方常见问题解答)。
yt-dlp还需加载若干JavaScript组件，具体操作步骤取决于您的安装方式，可能需要额外配置：
- 官方 PyInstaller 打包的可执行文件用户(例如
yt-dlp.exe、yt-dlp_macos、yt-dlp_linux等)：- 无需额外操作(只需安装 Deno)。所有必要的 JavaScript 组件都将与这些可执行文件捆绑在一起。
- PyPI包用户(例如通过
pip、pipx等安装)：- 安装并升级yt-dlp时需包含
default可选依赖组，例如：pip install -U “yt-dlp[default]”
- 安装并升级yt-dlp时需包含
- 官方zipimport二进制用户(即Unix平台的
yt-dlp可执行文件)：- 运行 yt-dlp 时添加额外标志，允许 Deno 下载
npm依赖项 –或– 在 Python 环境中安装 yt-dlp 的 JS 求解器包。(标志名称和包名称均待定。)
- 运行 yt-dlp 时添加额外标志，允许 Deno 下载
- 第三方包用户(例如通过
pacman、brew等安装)：- 具体操作取决于第三方包仓库对本次变更的处理方案。但“官方zipimport二进制用户”适用的选项同样适用于您。
常见问题解答
(及对应解答)
-
这是否意味着没有Deno(或其他支持的JavaScript运行时)就无法使用yt-dlp？
否。JavaScript运行时要求仅适用于YouTube下载功能。在支持的其他数千个网站上仍可正常使用yt-dlp。
yt-dlp 与 JS 运行时之间的关系将类似于 yt-dlp 与 ffmpeg 之间的关系。您需要自行准备 ffmpeg，但即使没有它，yt-dlp 仍能完成许多任务。
在不使用 JS 运行时的情况下，从 YouTube 下载某些格式仍将至少在短期内保持可行：例如 web_safari 的 m3u8 格式既不需要 n 参数，也不需要 PO 令牌。我们将尽可能延长这些格式的可用性。
-
为何不能改进 yt-dlp 的原生 JavaScript 解释器以支持新版 YouTube 播放器 JS？
当前yt-dlp依赖一套复杂的正则表达式模式集来识别YouTube播放器JS中的必要函数，并依赖更多正则表达式尝试在Python内部原生解析该JavaScript代码。
该代码的维护成本本就极其高昂。每当YouTube修改播放器JS时，都会迫使多名维护者放下所有工作，耗费接下来2-3天的全部空闲时间进行修复。
随着最新变更，必要功能分散在播放器各处，识别难度大幅增加。继续采用基于正则表达式的方案将过于脆弱且代价高昂(即维护人员在功能崩溃后需耗费未来两到三周的所有空闲时间进行修复)。
因此我们已放弃正则表达式方案，转而采用基于抽象语法树(AST)的方法(https://github.com/yt-dlp/ejs)，这将使我们能够更快速响应播放器JS的变更，即便其混淆程度不断加深。
-
为何选择_Deno_？
Deno默认采用沙箱机制，禁止文件系统及网络访问。这对保护技术基础薄弱的用户至关重要。其单文件可移植执行特性，使得“安装”流程与ffmpeg类似(所有用户都应对此操作流程熟悉)。
近期面临的另一挑战是YouTube强制要求所有播放器客户端采用来源验证令牌(PO)。要实现内置解决方案，需要远超我们原生jsinterp模块的JavaScript功能。因此我们选择了能同时应对JS挑战(n参数/签名密码)和未来PO令牌生成的运行时环境。
-
是否支持其他JavaScript运行时？
关联的拉取请求 除 Deno 外已支持 Node 和 Bun。
此功能未在原始公告中提及，因为： Deno是最安全的选项，我们希望技术基础较弱的yt-dlp用户继续使用它；B.) Deno将作为默认选项，而使用Node/Bun需要用户干预(即传递CLI参数)；C.) yt-dlp可能仅支持Node和Bun的近期版本(详见下方问题10)。
虽然Deno、Node和Bun是_初期_唯一支持的运行时环境，但我们欢迎添加更多支持。
-
关于_PhantomJS_？
yt-dlp的YouTube提取器将全面停止使用PhantomJS。该项目已无人维护、技术过时且存在安全隐患。从开发者角度看，其调试难度极高。虽然曾尝试将其整合至本方案但未成功，最终决定彻底弃用。目前仅有少数非YouTube提取器仍在使用PhantomJS。
-
关于_QuickJS_？
还尝试过将我们的外部求解器脚本与QuickJS结合使用，但每段视频的执行时间约为33分钟。(该方案还因QuickJS需要URL的polyfill而失败)。根据与quickjs-ng维护者的沟通，QuickJS并不适合我们，因为实际能达到的最快速度仅为当前的两倍(约每视频15分钟)。
-
是否考虑采用Selenium或无头浏览器方案？
yt-dlp维护者仅在万不得已时才会考虑此方案。采用无头浏览器等同于承认失败，违背本项目的初衷。
-
此变更是否等同于YTNSigDeno插件？
不同。该插件仅在使用Python正则表达式提取n密钥函数后，用Deno替换原生JSInterp。实际解决方案将(出于必要性)完全将n密文函数提取工作委托给JS运行时处理。
该插件开发已终止，待yt-dlp实现原生Deno支持后将归档其代码库。
-
Deno的最低要求版本是多少？
目前尚不确定，但暂定为2.x版本。待补丁最终确定并完成更多测试后，我们将给出明确答案，并随发布公告一并公布。若提前获知结果，此处将及时更新。
-
Node的最低要求版本是多少？
可认为Node的终止支持版本(即<20)将不被支持。根据今日早些时候的测试，PR分支要求Node版本>=21。我们将研究支持Node 20版本的可行性。
-
对于未被这些JavaScript运行时最低要求版本支持的平台怎么办？
只要符合现有框架规范(详见相关PR)，我们欢迎为其他JavaScript运行时添加支持。欢迎提交PR，但请务必待初始PR合并后再行操作。
-
若使用[插入Linux/BSD发行版名称]系统该如何处理？
您需要等待发行版软件包维护者的后续安排。
-
我已安装 Deno，为何 yt-dlp 似乎未启用它？
此变更尚未实施。本公告旨在提前告知各位。
我是YouTube付费高级会员。上周末想下载视频在通勤途中观看，结果iPad应用卡在“等待下载…”界面，iPhone也同样卡住。重启无效，尝试30分钟后放弃(实际操作30分钟，等待系统修复30分钟)。最终用yt-dlp下载视频，拷贝到USB-C闪存盘观看。
正等着他们执行“高级会员不得与家庭外人员共享”的政策，好让我终于能取消订阅。家人倒是把无广告功能用得挺好。
我也是高级会员，iPad应用同样存在相同问题。我常为幼儿下载节目，但下载功能从未能一次成功。
最终忍无可忍，我在eBay花50美元买了三星Galaxy Tab A7，刷入LineageOS系统。现在可以随意将媒体文件存入安装的1TB SD卡了。这台五年机龄的硬件通过VLC播放器流畅播放视频。意外收获是：通过F-Droid商店安装的第三方YouTube客户端NewPipe，其视频下载稳定性远超官方客户端。原本计划用yt-dlp导入SD卡，现在完全不需要了。
我在iOS的a-shell终端中运行yt-dlp，再用VLC播放文件。
我用这个来收藏在IG上转发的带评论的内容。实在不想在手机里堆满一大堆下载的乱七八糟的东西，连自己想不想再看都不确定。(而且我特别懒得清理手机空间。)
这根本解决不了VLC在iOS上糟糕的表现。明明iOS系统支持画中画功能多年了，它却依然不支持…
当你的PR准备就绪，可在此提交：
https://github.com/videolan/vlc-ios/pulls
是啊，难道每个对软件提出用户体验反馈的人都神奇地成了专业程序员？那种自鸣得意的“PR已接受”根本帮不上忙。表达对功能的期待至少能让潜在开发者知道这个功能有人需要。
创意/混蛋/人人皆有，诸如此类
表达对功能的期待？你从那篇帖子里解读出这种语气？
好招数，我得试试。谢谢！
NewPipe太棒了。如果谷歌停止签名这类应用，我就改用Linux手机。
“如果谷歌停止签名这类应用，我就改用Linux手机。”
这不就是变相说“我会用到它彻底失效为止”吗？
我偶尔用F-Droid平台的Skytube应用下载内容，挺满意的。
https://f-droid.org/en/packages/free.rm.skytube.oss/
只要他们推出支持CarPlay的地图应用，我就立刻换用Linux手机。
CarPlay和Android Auto不都依赖专有库吗？除非它们大行其道，或者像microg那样重构专有组件，否则我怀疑Linux手机能实现。
GNOME地图对我来说足够用了。我不知道Carplay是什么，现在也不想问。
这是将车载娱乐系统作为屏幕/输入设备的框架。安卓有类似方案叫Android Auto。
题外话。
TIDAL应用简直垃圾，这个问题反复出现；不仅如此，下载失败时它会直接卡死，无法继续下载专辑/歌单剩余内容。
话说回来，下载内容的初衷不就是离线播放吗？可当你断网打开应用时……它居然要求登录，导致连自己的音乐都无法访问。年费90万的天才设计啊。
至今没取消订阅纯粹因为懒得重置密码登录取消，哈哈。不过可能很快就要动手了。
试用一个月后发现最糟糕的是…整个下载队列会永久失效，除非手动逐条删除数百项内容
若歌曲已从流媒体库中移除，或您所在地区(如旅行时)无权限播放，则无法删除卡住的项目。您根本无法打开该曲目进行取消下载。
不过Tidal有个优点：使用tidal-ng工具可下载所有无DRM限制的歌曲。
我虽订阅了YouTube Premium，仍坚持在手机上使用ReVanced禁用自动翻译功能。官方应用竟不支持此项设置，简直荒谬至极。
等哪位产品经理把它当促销项目推出时，这个问题自然就解决了。
我向“朋友”抱怨日历因导入多个来源导致节日重复，他竟问解决后能带来“什么价值”。我困惑地解释会导致事件错位无法阅读，他才说明指的是金钱价值…
我们都是程序员，都清楚这不过是一行正则表达式的问题…
我认识不少这样的人，他们在大科技公司担任高管…不用天才也能明白为何所有产品用户体验如此糟糕，为何软件质量如此低劣。似乎没人真正关心产品本身，他们只会纠正你说：“产品是股票，客户是股东，不是用户。”
我们搞砸了…
嗯。如果年费是100美元，那么修复这个问题的价值就是100美元。
如果免费的话，那么这个用户档案一年的价值是多少…这就是价值所在。
用户留存是个问题。
反正这些数字都是编造的，工程师何必在意？让工程师去证明金钱价值的想法本身就…荒谬。他们该专注于技术难题，让工程经理去操心那些虚幻的数字吧。
问题在于，当产品垄断市场时，没人需要关心产品质量…若用户分不清好坏产品，这种担忧就更微不足道了。技术文盲现象直接催生了柠檬市场
> 我指的是这些数字本来就是编造的，工程师何必在意？
这些数据正是他们直接或间接的考核依据。即便他们无需证明工作对公司利润的影响，他们的上级或上级上级必须证明，责任只会层层下推。
> 要求工程师证明经济价值的想法简直…荒谬。他们该专注于工程难题，让工程经理去操心那些虚幻的数字吧.
要是这行也能这样就好了。小公司嘛，本来就得身兼数职。大公司嘛——我老婆最讨厌我处处挑毛病，但隐性通胀确实存在。随着岗位被削减(呃，“精简”)，人人都被逼着处理本不该操心的琐事(我最爱举例的例子就是报销单)。
正如你之前精辟指出的：我们搞砸了…
我想你会认同这种情况本不该存在。工程经理或项目经理如此尚可理解，但工程师？简直荒谬。
我们需要防火墙。一组人的首要任务是专注产品，另一组人的首要任务是确保企业生存盈利。
前者过多就会错失重点工作，后者过多就会制造 vaporware。偏向任一极端的弊端显然更严重…
哈哈，你老婆要是遇到我老婆，怕是要乐疯了…
我始终坚信，世间存在着远超我们认知范畴的复杂性。随着我们不断前进，复杂性只会与日俱增。曾经微不足道的舍入误差，最终会演变成难以逾越的障碍。这正是成功的双刃剑本质：进步越多，突破越艰难。我实在无法理解为何所有人(包括专业领域的专家)都认为事物如此简单。
不过我的伴侣正在攻读经济学博士学位，她也常思考机会成本问题。但我觉得她(以及她许多朋友)对科技行业内部运作机制知之甚少[0]。
可能还因为——你知道的——我不太擅长简明扼要 :/
[0] 我最爱在她系里的聚会(总少不了酒精)上向他们介绍开源软件。不少人难以理解这个世界竟如此依赖这类工作，却几乎赚不到钱。更别提背后的动机了。xz压缩算法的讨论引发了不少有趣的争论…
得益于集成服务带来的粘性与网络效应，用户留存已不再是难事。
当所有功能都与之深度集成/所有人都在这个网络上独家发布内容时，你不可能轻易更换日历/视频流媒体服务。
你告诉他具体金额是多少？假设每年有5个节假日导致部分人放假而另一些人正常工作，因此当天安排的商务会议就会出现缺席情况。假设使用这款日历软件的用户有1亿人。假设其中0.5%属于高管阶层。进一步假设10%的高管因界面问题错过会议，即5万场会议流失。若粗略估算每场会议可能为公司带来1000万美元交易额，这个界面漏洞正让客户损失_5000亿美元_！
因此，在估算747飞机能装多少乒乓球之后，你该做的就是编写正则表达式并将其加入宣传资料。五千亿美元啊！
显然他们指的是软件公司_的经济价值_。若修复该漏洞，公司能增加多少收入？
抱歉，我需要更清晰地说明(但这会引发类似问题)
显然他们指的是_对软件公司而言_的货币价值。若实施该方案，他们能增加多少收入？
在我的iPhone[0]日历中，我导入了微软(工作)和谷歌(个人)日历，同时还保留着iPhone自带日历。以去年劳动节为例，若未在微软和谷歌日历中禁用节假日提醒，我将收到3条劳动节提醒。节假日事件会占据当日顶部位置，因此在手机上查看时基本看不到其他日程。而在MacBook上，当日历占据60%垂直空间时，我只能看到“劳动节+3条”。全屏状态下最多显示4-5条条目…
只需一行简单的正则表达式就能节省大量界面空间。同时还能有效合并日历，从而查看某个日历独有的节日。
这样我就能真正看清当天安排的日程[1]
当然这也会影响其他事项。有时谷歌会因后续邮件自动添加事件，该死的重复项又出现了…生日提醒也常出这种问题…更糟的是遇到某个该死的bug：当联系人因莫名原因出现姓名、电话、生日完全相同的重复条目时，合并操作[2]反而会导致日历条目翻倍，最终变成四倍重复项！
我错过了太多该死的事情，只因没在日历上看到[3]。居然还有人厚颜无耻地问能省多少钱？我们讨论问题的时间都比解决问题耗时更长！我面对的可不是新手(那种会问“但我无法控制或合并其他日历”这种蠢问题的人，根本没意识到这是显示问题)，而是亚马逊的L6级别员工[4]
我发誓，问题在于没人明白LeetCode题目的意义从来不是要得到正确答案，而是给面试者一个问题让他们动脑，看看他们如何解决。我宁愿工程师给出错误答案但思路清晰，也不愿看到他们用明显背诵的烂代码给出正确答案。教人如何思考远比教人死记硬背具体知识困难得多。
[0] 我几乎立刻就后悔了这个决定…
[1] 这是发泄情绪的吼叫，不是冲你吼
[2] 不，那个“查找重复联系人”功能根本找不到重复联系人(他们到底在找什么数据？肯定不是完全相同的姓名。为什么连相似姓名都不尝试匹配？！)
[3] 还因为那个滚轮动画没转完，搞错日期或把上午调成下午，搞砸了太多破事。通知系统根本没法管，我连手动取消都来不及，只要解锁手机它们就消失了，害我错过太多事。所以不仅需要解决这个单行指令的问题，其他类似的单行指令优化也会带来巨大帮助。
[4] 这家伙抱怨应聘者用GPT做LeetCode题，说他很难判断对方是否作弊。我提出的诸多建议之一是“为什么不做现场面试？”，结果被“机票太贵”的理由驳回(他的面试对象都是本地人)，这与他前后关于招聘/面试成本高昂的说法自相矛盾。恕我直言，花6名工程师的薪资进行6场1小时面试，这笔钱能买几张国内往返机票？或者让面试官开车过来…
> 我们都是程序员，都清楚这不过是一行正则表达式…
身为大型科技公司的程序员，事情几乎从来没这么简单…
一行正则表达式无法覆盖的细微边界情况，在规模化应用时可能引发重大问题——尤其涉及日历内容删除时。
我承认自己确实有些戏谑。但我们也必须承认，如果连日历中名称完全相同的条目都无法去重，那系统就存在根本性缺陷。
我特意以假期日历为例，正是因为这个狭窄的范围能极大简化问题，同时又是你能亲自验证的现实场景。
你说的没错，边界情况确实会带来巨大复杂性，但你能想到什么理由，让重复处理完全相同名称和时间条目的事件变得困难？尤其当这些事件明显是节假日时？我们甚至可以只考虑那些完全覆盖整天的节假日(比如劳动节)。
你真认为无法快速编写覆盖这些核心场景的解决方案？那些主导整个问题的典型案例？其失败模式恰恰导致现有问题(重复项存在)的方案？难道我遗漏了需要复杂方案处理的边缘案例，以致影响这些极其常见场景的处理？坦白说，这根本就是标准的表连接问题。当前结果迫使我面临两难：要么保留三份重复条目(严重影响可用性)，要么停用多个日历(既无法泛化问题又导致遗漏次要节日)。坦白说，问题严重到即使手动审核所有去重条目我也心怀感激…
如果不是这样，我真的很想听听具体情况。因为这意味着我对问题的描述存在重大偏差，不该使用这个例子。同样不该举例说明无法_找到_那些姓名、昵称、电话号码、生日完全相同，仅邮箱地址和备注不同的人员记录的情况。因为我一直强烈认为后者只需简单的数据库查询，返回包含匹配项的_任何_记录即可 (失败模式应是向用户展示过多匹配项而非匹配项不足。必要时可按重复字段数量排序分批显示匹配项。笨拙的解决方案也优于现状…)。
我的请求是认真的，但若我确实严重误判了情况，相信您也能理解这番论述显得多么荒谬。我真心想弄明白，因为这实在令人费解。若我确实愚不可及，请务必_毫不客气_地指正。但别让我仅凭你的片面之词就信服。
当被提拔者不再参与该项目时，该标记将被移除
自动配音功能简直疯狂。几天前我首次注意到它，只能祈祷少有创作者启用此功能，且希望YouTube能在设置中默认禁用(目前无法实现，每次观看都得手动关闭)。
我身处西班牙语国家，但希望观看英语视频时保持英语原声。
自动生成的其他语言字幕可以接受，但我只想听原声！
该功能默认开启。有位英语内容创作者的视频被错误标记为西班牙语，导致观众在观看英语视频时收到机器生成的英语配音。解决这个问题的支持流程简直像噩梦。
等等，你是说默认开启但作者可以关闭吗？
如果不是，我很好奇为何我仍能观看大部分原声视频(尽管身处西班牙语国家)，至今只遇到过一次这种情况。
理论上存在手动移除各语言配音的流程，但该功能已失效(至少去年如此)。
自动翻译的标题呢？视频章节也存在同样问题…
和我用的是相同语言。这简直令人抓狂，因为翻译几乎总是错误的。
这个“功能”令人震惊。设计拙劣且思路错误。我从未观看过配音视频，为何要显示翻译标题？更令人费解的是，谷歌明明雇佣了大量英语非母语员工。
肯定存在某种KPI指标，要求AI模型在YouTube等平台提供翻译服务的频率。有人升职就指望这个翻译功能在YouTube上被尽可能多地使用。
无论我是否懂该语言，都不想要配音版本。
是的，这就是我的意思。我绝不想要配音版。
我宁愿使用自动生成的字幕(即使有瑕疵)，但我要听原声！
> 其他语言的自动生成字幕可以接受，但我坚持要听原声！
我第一次看到这个功能，是在某首外语流行歌曲的翻唱版本里。这到底是为什么…？
评论区很擅长指出创作者是否不小心开启了该功能(它默认是开启的，作者需要主动关闭)。
感谢推荐。
我之前用的是浏览器功能，能在手机上禁用移动模式。
自动配音功能应该尽快禁用。至少得提供全局禁用选项，让我能在所有设备上关闭。
真好奇YouTube管理层哪来的脑洞，竟觉得强制自动配音是好主意。这充分暴露管理层的失能。团队里混进混蛋是一回事，对他们的所作所为视而不见则是另一回事。
更荒谬的是，若你将视频上传至YouTube后，再试图通过创作者控制台下载(比如直播时忘了保存本地副本，或下载会占用过多设备资源)，得到的竟是糟糕的720p渲染版本，而ytdlp却能获取客户端支持的最高画质。
哦，这让我想起Facebook视频的类似经历。几年前直播DJ时，我只在本地以最高质量录制了音频。记得当时就得用浏览器调试器检查视频720p版本的URL。
最近他们发邮件催促我下载视频以免功能下线，结果提供的选项只能下载标清版本(数据导出还耗费了相当长时间)。
我取消订阅的导火索竟是YouTube Kids(在ShieldTV上)的无广告功能失效。虽可能是系统漏洞，但面对近乎缺失的客服渠道，除了取消订阅别无他法。
作为Play Music付费用户的遗留用户，这次变动恰逢音乐服务从Pita平台迁移至YouTube的混乱期，这成了压垮骆驼的最后一根稻草。
真想揍死那个导致Play Music死亡的高管。这曾是款极其优秀的应用，即便平台终止服务也完全能继续独立运行，但他们连这个机会都不肯留给我们。我至今仍保留着它，拒绝卸载。
>正等着他们出台“高级会员不可与家庭外人员共享”的政策，好让我终于能取消订阅。
那我有好消息告诉你！https://lifehacker.com/tech/youtube-family-premium-crackdown
事实上，我已经收到他们关于此事的邮件了。不过我的YouTube频道目前仍未显示广告，所以不确定何时会真正生效。
是啊，我休假一周时收到了这条消息。他们这边操作似乎有点混乱。
ReVanced等替代方案依然存在。
只要他们通过公开渠道传播媒体内容且未设置明确登录系统——本质上是利用公共访问获取曝光——那么用户通过任意浏览器或软件获取内容的行为，在法律和道德层面都完全正当。
自从他们用广告轰炸我，开始随意更改功能并降低用户体验后，我就停止付费，转而使用免费且能屏蔽广告的客户端。
如果他们真要封杀第三方应用并加强系统封闭，我可能会彻底抛弃手机。
> ReVanced等替代方案依然存在。
至少目前如此。我怀疑这才是谷歌要求侧载应用也需开发者证书的真正原因：https://www.techradar.com/phones/android/google-will-soon-st…
问题在于，谷歌发现你违反服务条款时会采取何种措施难以预料。他们曾因YouTube版权投诉直接封杀_整个谷歌账户_且用户毫无申诉渠道。
关键在于，当谷歌发现你违反服务条款时，你根本无法预料他们的处置方式。他们曾因YouTube版权投诉直接封杀_整个谷歌账户_，用户毫无申诉机会。
这就是为什么我不把谷歌账户用于任何重要事务，我早在2014年就放弃了Gmail，真心建议大家也这么做。
你永远不知道大限何时降临。
深有同感。我实在不明白为何有人甘愿承担风险依赖谷歌——考虑到其风险等级、影响范围以及“除了公开羞辱外别无他法”的政策。
谷歌不会在短时间内随意废弃功能。当他们终止服务时，总会提前发出充分警告。他们会明确告知“大锤”的存在，并预告六个月后执行——这足以让你提前撤离。当然我宁愿没有这把锤子，但他们绝不会在周五突然宣布周一关闭Google Keep，逼得我整个周末都得忙着备份笔记。
所谓“锤子”并非指服务下线，而是指你的谷歌账户因违规或其他任意理由被封禁。
我不怕他们废弃Gmail，我怕某天醒来发现账户被封禁且毫无申诉机会。
同感。我仍保留一个仅转发邮件的Gmail账户，并在新服务开通时更新邮箱。使用自有域名邮箱体验更佳——不过邮件服务器本身还是托管在服务商那儿。
我也是同样处境的付费用户。我在电脑上使用uBlock Origin和Sponsorblock，电视上用SmartTube。我付费订阅正是为了能和技术水平较低的家人共享无广告体验，并使用他们的原生iOS应用。如果他们真要收紧付费家庭共享的规则，我会立刻取消订阅。
作为Premium用户，我主要通过AppleTV观看内容。近期新增的功能是：当赞助商环节开始时，按遥控器快进键即可跳过整个片段，包括“常见跳过”内容。
虽然无法完全屏蔽，但至少让我自主选择是否观看，且单键即可跳过——全程使用原生应用。初次体验时我颇感意外。想必创作者对此深恶痛绝。
本人亦为YouTube Premium付费用户。居住在加州偏远地区，5G信号覆盖有限。长途驾驶时，我会通过iPhone的HDMI接口让幼儿在车载屏幕上观看Rachel老师的节目。YouTube Premium视频带有DRM限制，禁止通过HDMI播放下载内容，所以我不得不效仿你的做法——将视频作为本地文件添加到VLC中播放。
YouTube Premium所谓的“下载”功能根本是彻头彻尾的骗局。下载到哪里去了？我能复制什么文件？
文件？你来自哪个时代？史前时代吗？
文件已经不复存在了。准确地说，它们在技术上依然存在，但版权产业不希望你在未经授权的情况下查看它们，安全人员根本不允许你接触它们，而用户体验专家则认为，让你知道“文件”这种东西的存在本身就是个糟糕的主意。
分享并享受。点赞并订阅。这个世界终究只是应用程序的堆砌。
YouTube Premium下载功能的糟糕实现始终令我困惑。视频几秒就能缓冲至100%，点击下载按钮却陷入无限卡顿。为什么？所有数据字节明明都已存在我的设备上。
因为他们想掌控你设备上的数据流。
提供数据本身易如反掌，难点在于阻断信息的自由流动。那些故障不过是副作用罢了。
整个YouTube应用都怪怪的。有时它允许你设置1.0x-2.0x倍速，有时又变成0.25x-4x倍速范围，有时还会弹出文本选择框提供从0.1到4.0的0.05倍速选项。有时界面又会变得更友好，提供常用选项的快捷选择和滑动条调节速度。最近它还出现了一个新bug：当你播放下载的视频时，如果关闭屏幕再重新打开，视频播放似乎就会崩溃。几个月前，它的投屏功能变得极其缓慢，所有操作(暂停、切换视频等)都需要30秒才能同步到投屏视频上…但通常不会丢失指令。(如果指令偶尔丢失反而更正常些。) 该应用极度限制短视频投屏功能，其政策动机令人费解——但若直接通过机顶盒的YouTube应用播放，短视频却能正常投屏。尽管应用声明下载内容一个月内无需重新验证，但它会周期性清空所有下载记录，迫使用户重新下载。更荒谬的是，当我在无网络区域时，它竟试图重新授权半小时前刚完成的下载——这完全背离了下载功能的初衷。下载进度约四分之一时，界面会显示“下载完成，准备观看”的提示，但实际播放时却报错“尚未完全下载”。
感觉这个应用程序已经超出了负责团队的处理能力阈值。或者可能是AI代码过多，而审查和测试不足。这两种情况也可能同时存在。
控制变化听起来像是你可能陷入某种A/B测试
但控制项以极高频率反复切换。五分钟内我能经历全部三种状态，这种情况已持续数月。
更荒谬的是视频速度选项竟采用下拉菜单形式，从0.05x到4.00x所有选项堆叠呈现——其垂直高度足足占满我屏幕三分之一。
经过这么多测试，他们居然从未想到提供一键返回速度控制的功能——尤其当我已在同一视频中调整过多次速度后。
更别提“最高画质”账户设置在有4K选项时绝对不会自动选择。他们非得通过将画质选项嵌套在多层菜单里，多点几下才能节省带宽成本。(桌面端和iOS/iPadOS的Safari浏览器可用用户脚本修复此问题，但若使用原生应用，我付费购买的画质体验根本配不上这份钱。)[特权吐槽结束！]
这种模式如今正成为普遍现象。
典型案例(抱歉又提这个话题)：大型语言模型供应商似乎正加倍押注自动模型选择功能，并将其包装成能提升用户体验和响应质量的特性，尽管这本质上是通过欺骗用户(或剥夺用户选择权)迫使其调用更廉价、性能更弱的模型来削减服务成本的赤裸裸尝试。这显然违背用户意愿——在这个领域，用户需求甚至比视频流媒体领域更强烈：超过90%的终端用户都希望获得当前最顶尖的模型服务。
至少YouTube过去曾对此坦诚相告，记得在新冠疫情初期——我印象中应用界面曾明确说明：为节省突然变得极其稀缺的带宽，默认画质已被调低。
> 等待他们推出“高级会员不得与家庭外人员共享”政策
我最近因“在另一设备观看”被暂停服务，但当时根本没用其他设备。你提到的政策恐怕指日可待。
> 等着看他们推出“高级会员不得与家庭外人员共享”政策，这样我就能终于取消订阅了
这政策早就存在了，注册页面醒目地写着“会员必须同住一个家庭”。
不过不确定是否严格执行。
我有两处住所。每次“北上”都得切换Netflix家庭账户，返程后又要切回原账户。听起来今后连这种操作都不允许了。
我订阅了YouTube Premium，主要在iPad和电视上观看。但YouTube每天至少会强制注销一次账号——我注意到这个现象是因为视频突然又开始播放广告(我都是通过RSS阅读器打开视频，从不访问YouTube官网)。在未订阅Premium时从未发生过这种情况。虽然不明白他们为何这么做，但近一年来的体验让我觉得，这种强制注销带来的困扰仅比广告稍好一点。到这种地步，我干脆不续费，直接用广告拦截器算了。
YouTube的“下载”功能并非真正下载，其实是YouTube应用内的“缓存离线”功能。
我在YouTube Music也有类似经历。后来发现提示信息有误导性，其实只要在非WiFi环境下开启下载功能即可。
我经常遇到下载问题。每次下载视频都得暂停，强制关闭YouTube应用，再重新启用下载才能继续。这个问题存在多年仍未修复。
我是高级订阅用户，通过yt-dlp下载时从不出现错误或警告。
我们情况不同。
你看了什么视频？
任天堂直面会。不过所有视频都存在下载问题
我承认会用yt-dlp下载想留存的视频副本，这样别人就拿不走我的东西了。但我付费订阅高级会员，因为这能支持我观看的内容。若不付费，内容从何而来？Patreon只适合拥有庞大粉丝群的超级明星。
为何不用Brave浏览器及其播放列表功能实现离线下载？
为何不用非Chromium内核的浏览器，阻止谷歌进一步掌控互联网？
浏览器领域仍需竞争，否则谷歌将对互联网架构拥有不成比例的影响力。我向你保证，Firefox和Safari其实不差。Firefox或许略有不同，但对绝大多数人而言差异微乎其微[0]。至少让非技术背景的亲友使用这些浏览器，顺便装个广告拦截器。
[0] 你作为个体的独特性并不否定普遍规律。
Firefox正走下坡路，Brave很快会超越它。Brave原生支持广告拦截，这带来诸多优势，未来我们或许还能看到新的互联网资金模式。而Firefox和Safari显然无法撼动广告生态。
https://data.firefox.com/dashboard/user-activity
https://brave.com/transparency/
顺便提一下，zen-browser.app 是基于 Firefox 轻度分叉的浏览器，外观模仿(已弃用的 Chromium 项目)arc 浏览器，体验很棒。
那个Brave链接显示增长已停滞
这条曲线并非月活跃用户增长。
我觉得你完全没抓住重点。
关键在于：若所有人使用单一浏览器(不限于Chrome/Chromium)，该参与者将获得不成比例的互联网控制权。这对任何人都没有好处。
针对Chromium的具体不满在于——谷歌获得了这种话语权，而我认为他们比其他参与者更不可信。我并非要求大家信任Mozilla，但任何声称Mozilla比谷歌更可信的人，恐怕是在兜售天方夜谭。请记住，基于Chromium意味着Brave仍依赖谷歌。这导致了诸如[0,1]这类问题。需知Chromium源代码体量庞大，[0]这类问题并非轻易可被发现。在此引用[0.1]的论述：
这并非人们首次发现谷歌偏袒自家浏览器，YouTube存在这种情况已是公开的秘密。我们真的希望任何公司都能掌控互联网吗？真的希望谷歌做到这一点吗？
我不确定你试图传达什么。是说Brave用户数达到Firefox的64%？还是Brave用户特别青睐Gemini、Coinbase和Uphold？又或是Brave用户正将账户关联至Twitter、YouTube、Reddit、GitHub、Vimeo和Twitch等平台？还是Brave广告系统能追踪到州级数据？老实说，看到Brave的“透明度”报告后我反而产生更多疑问——它似乎比Firefox掌握了更多用户信息…
若您格外重视隐私并以此为理由选择Brave，我建议您尝试Mullvad浏览器[2]？该浏览器基于Firefox分叉开发，并与Tor合作最大限度减少追踪和指纹识别。您既能获得安全保障和隐私保护，又能摆脱谷歌的掌控。
[0] https://github.com/brave/brave-browser/issues/39660
[0.1] https://simonwillison.net/2024/Jul/9/hangout_servicesthunkjs…
[1] https://www.bleepingcomputer.com/news/google/google-to-kill-…
[2] https://mullvad.net/en/browser
我一直是Brave的忠实用户，但此刻我的忠诚正动摇…
> 我不太明白你想表达什么。
我是在说Firefox很快会倒闭，因为用户更青睐广告拦截和追踪器屏蔽功能。这是大势所趋。Firefox已经停止增长了。
> 说实话看到Brave的“透明度”报告后我更困惑了，它似乎比Firefox掌握更多用户信息…
数据传输完全可以不暴露用户身份，这是常识。
你什么都别提了。我不想再讨论这个话题。
难道你不觉得那些宣称火狐即将倒闭的人也在助推这个局面吗？
无论如何，你忽略了我的核心论点。我并非刻意为火狐辩护，但市场选择本就有限。当前竞争格局是Chrome、火狐、Safari三足鼎立，其中唯有火狐不属于“科技巨头”阵营。
这点鲜为人知，我觉得你在此处不经意间暴露了自己。在隐私保护领域，一个广为人知的难题是：传输用户数据时往往会无意间泄露其他信息。这里有一个相当著名的案例[0,1]。我建议你仔细阅读该案例，并认真思考：仅通过阅读他们去匿名化数据集的描述，是否就可能实现去匿名化？
若你选择退出讨论，那是你的自由。我始终真诚地试图与你展开对话。我甚至并非真正针对Brave浏览器，我的批评指向Chromium生态系统。若你重新审视我的论点，会发现若Brave基于Gecko或Webkit引擎，这些观点将截然不同。坦白说，若它采用这些引擎，我反而会鼓励使用Brave。更理想的是拥有自主引擎！因为我的核心观点在于反对垄断。
[0] https://courses.csail.mit.edu/6.857/2018/project/Archie-Gers…
[1] https://arxiv.org/abs/cs/0610105
> 为何不使用Brave？
Reddit 给出了解答：https://www.reddit.com/r/browsers/comments/1j1pq7b/list_of_b…
我没用Brave浏览器，所以不知道它能下载视频
我用Brave的，但同样不知道这个功能 :p
不错，没想到Brave还能这么用。
给在座的创业者们提个建议：
1. 无限畅享YouTube Premium
2. 无限饮品报销(咖啡、茶、奶昔，随便喝)
这两项带来的心理损失感，远比5%的加薪更有价值。
我不喜欢这种算法，宁可拿5%加薪也不要8000美元福利。
这其实是给雇主的方案：成本更低且员工粘性更高。
我个人不会雇佣连浏览器扩展都不会安装的初创员工 😉
Roku才懂啊
你把初创企业都当成科技公司了。在我公司，技术人员连员工总数三分之一都不到。
浏览器扩展本就不是为技术人员设计的，而是面向所有浏览器用户安装的。若有人连安装浏览器扩展、更换灯泡、补充冰盒都不会，无论是否技术人员，我的初创公司都不需要这种人。
啊对，我这就给孩子iPad装个浏览器扩展
供您下次购买时参考：您可以在安卓设备上安装火狐浏览器，不过谷歌计划限制用户安装软件的能力，这可能对火狐的安装造成威胁。
这个链接或许能帮上忙
https://kagi.com/orion/
我非常欣赏这个“JavaScript解释器”背后的工程设计
https://github.com/yt-dlp/yt-dlp/blob/2025.09.23/yt_dlp/jsin…
这完美解决了他们面临的问题。他们为避免增加额外开销做到这种程度，实在令人惊叹。
这才是公告中被埋没的重磅消息——我完全没想到他们已付出如此巨大努力。实在令人钦佩！
这是JavaScript的子集。相关讨论见此https://news.ycombinator.com/item?id=32794081
太棒了，在现代技术中采用这种经典而高效的方法。我还担心他们会嵌入浏览器呢。
我只是简单浏览了代码，就发现了Python中的ChainMap。
这对我某些场景非常实用。我想让AI代理以某种方式“分叉”其上下文，这比处理字典树结构更高效。
嘿，现在我好奇它究竟能解释多少JavaScript代码，而且考虑到它不到1000行，是否能用于编译器入门课程。
显然不行。入门课程会介绍词法分析器、语法分析器、抽象语法树等概念，而不是处理字符串。
以下是第431至433行代码：
David Beazley有个著名的演示，他用不到一小时就用Python实现了WASM解释器。强烈推荐。
相较于真正的词法分析器/语法分析器，字节码解释器其实相当简单。
我在手机上操作，这似乎是个真正的JS解释器，仅支持对象和算术运算。能做到这种程度相当惊人
等等，我以为他们运行的是完整浏览器引擎
长期来看他们可能需要这么做。YouTube至今仍允许这些操作主要是出于“遗留应用”的兼容性考虑，不过这类支持正逐步被淘汰。不确定是否有人统计过最古老的兼容应用，但像通过稍旧的游戏主机访问YouTube这类场景基本已无法实现。
基本上任何公开已知、能以最低成本和认证门槛获取视频内容的方法，都将成为此类攻击的常见突破口。
嘿，这挺酷的。
我猜它要多久才会独立成项目。眼下至少需要补充大量文档。好在他们至少做了些测试！
> 我猜它要多久才会独立成项目
提交内容明确表明他们正弃用它转投Deno，所以“永远不会”这个答案应该相当接近。
感谢说明——我之前没意识到被替换的正是这个。
且不论公告核心是彻底放弃该项目，这个“解释器”本身就是个临时拼凑的方案，根本无法处理任意JavaScript代码。例如它仅能处理Date对象的
new操作——通过平衡括号推断调用参数，再将整组参数视为字符串进行正则表达式匹配。刚和妻子同居时，我显得比现在更疯狂些——毕竟我是个囤积媒体资料三十多年的狂人。家里没有散落的VHS录像带或DVD，因为我只保留数字副本，但我的档案相当完整。没什么特别重要的东西，就是些普通内容和些随时间流逝会消失的稀有冷门资料。
我妻子对我在家自建“家庭版Netflix”的创意很感兴趣，尤其喜欢看任何内容时没有广告或垃圾信息的体验。我从未想过自己会成为什么“典范”——当时完全认定所有人都会永远拥抱流媒体，毕竟我以为那些公司不会犯这么多错误。过去十年我总对人说：“真棒！我用自建系统看片，你最爱哪些剧集？我得确保自己也收录”
近两年越来越多的亲友要求接入我的Jellyfin系统，还让我在客厅电视下方或壁橱里帮他们搭建类似的低存储方案。
最近我们扩展了Jellyfin功能，新增了YouTube内容支持。每个频道对应一个目录，运行以下命令即可：
这段代码实际上未能实现我的预期目标，导致下载了h264格式的内容。因此我将其重新编码——因为在多数设备支持h265等格式之前，我始终将媒体库保存在h264格式。不过这些其实都不重要，因为这些YouTube视频采用的是AV1格式，而据我所知，目前我的智能电视均不支持该格式。
起初我运行了一个简单脚本，现在使用ytdltt [1]让母亲通过Telegram机器人下载YouTube视频(对她而言更像是有声读物)，并将其分类存放于目录中，以便她通过Jellyfin访问/下载。三年间她已积累约1.2TB的有声读物。
1: https://github.com/entropie/ytdltt
请查看https://github.com/meeb/tubesync
> 该工具无法实现我的需求，无法下载h264格式内容，因此我重新编码处理
我曾为此困扰(yt-dlp文档确实有待完善)。目前有效的方案是：
最近发现Pinchflat[1]，它似乎是受arr启发的网页替代方案，对我非常实用——只需将目标视频加入播放列表即可自动抓取。底层同样使用yt-dlp。
1. https://github.com/kieraneglin/pinchflat
使用新预设功能获取h264格式：-t mp4
也可通过运行/videos网址替代主频道网址跳过匹配过滤器。
若需720p分辨率，请添加参数 -S res:720
是否需要设置cookie来避免登录/机器人提示？下载yt视频时是否使用VPN？
试过这个命令吗：“yt-dlp -f ‘bestvideo*[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best’ -S vcodec:h264 -other_options …”？用这个命令我依然能获取标准的h264格式(我的树莓派3只接受标准编解码器…那些模糊的新时代编解码器可不行 😉 )
>此处无法实现预期效果，无法下载h264内容
你是否遗漏了[vcodec^=avc1]参数？
单纯从网页获取数据的时代即将终结——如今所有内容都需通过运行数千行混淆JavaScript代码的完整浏览器才能获取。网站不再提供可缓存的1KB JSON数据，转而强制启动完整浏览器栈，通过100次请求传输10MB数据，搞乱你的分析数据和安全配置，最终两败俱伤。真棒。
不过话说回来，这倒是为上万家公司创造了商机——它们唯一的工作就是抓取10MB垃圾数据，然后提供个像样的API接口。
所幸这一切都将不再是问题，因为这些网站上的内容大多已不值得抓取。
*而这些公司的唯一客户正是利用这些数据进行AI训练
他们之所以能负担得起，是因为市场正确地押注于训练模型比上游数据源更有价值。
事实上，在当下这个阶段(这种情况不会持续太久)，大型语言模型最实用的应用之一就是让它们处理当今网络中大量用户不友好的垃圾内容，这样你就不必亲自忍受这些烦扰。这也是目前实现任何软件互操作性最简单的方式(这种情况绝对不会持续太久)。
所幸如今进行小规模抓取(类似yt-dlp的操作)比以往任何时候都更容易。
我只需花一两小时摸索，就能编写出利用无头火狐浏览器+mitmproxy的脚本。只要不试图从100台VPS同时运行并大规模抓取整个网站，通常就能存档我真正需要的内容。基本上无论对方部署何种防护机制都无济于事。低流量下(所谓“低流量”指家用IP下笔记本电脑的常规操作)Cloudflare根本无法检测无头Firefox，现代浏览器脚本编写极其简单，因此即使面对大量动态JS的SPA网站，单人也能轻松完成抓取。更不用说小规模操作时，验证码完全可以自行破解。
最近我写了个抓取脚本，遇到验证码时就会发Discord提醒，我只要看一眼笔记本电脑解决问题，就能继续抓取。当时我正在存档付费漫画，但那款封闭式应用显然不允许用户掌控自己付费购买的数据。
这种1KB的OS JSON数据至今仍像现代产物——你得下载数MB的JavaScript代码才能执行并展示这区区1KB的数据。
理想方案是只下载10-20KB的HTML文件，可能加个对应的CSS文件，以及HTML中引用的图片。若需视频，直接获取视频文件即可。
简单高效，除非你需要销售产品。
视频通过JS传输的主要原因(除混淆外)在于支持可变码率。奇怪的是某些电视能直接支持可变码率HLS，苹果设备也支持，但普通浏览器不行。详见https://github.com/video-dev/hls.js/
> 除非你需要销售产品
视频托管及其内容审核成本高昂，这正是市场竞争者寥寥的原因。
所谓“不多”，你其实想说的是_零_竞争对手。
(免得你问：Vimeo正被卖给一家垃圾化公司)
这些“零”竞争对手包括：Rumble、Odysee、Dailymotion、Twitch、Facebook Watch…等等。
这里有个不错的清单：https://ideaexplainers.com/video-sites-like-youtube/
Twitch确实提供直播服务，但最近大幅限制了存档内容的免费托管范围。
前两个平台没听说过，它们的独特卖点是什么？
这一切都是为了卖更多广告。
这已演变成军备竞赛。网站变得愚蠢/多余/敌意地复杂化，但AI/大型语言模型让提取其中有用信息成为可能(尽管成本更高)。
不久后，大型语言模型将在合理时间内破解人类能完成的任何验证码。届时“模拟漏洞”可能永久开启——只要能对准摄像头和麦克风，AI的理解能力将超越人类。
未来每个网络会话都将绑定真实身份，若服务端检测到你是机器人，直接通过身份验证机制封禁即可。
未来确实会有更多网站强制登录，但网站如何区分操控浏览器的人类与机器人？验证码已近乎淘汰，而ARC AGI技术又过于繁琐无法实现实时验证。
请记住，大型语言模型访问任何网站本身并非问题所在。真正的问题在于那些爬虫机器人——它们通过饱和服务器带宽(某种拒绝服务攻击)来收集数据，进而训练这些语言模型。大型语言模型破解验证码或处理Anubis式工作量证明问题并非主要担忧，因为它们收集数据最多只是缓存以供后续分析和报告。与爬虫不同，大型语言模型没有像巨型吸尘器般疯狂吸取海量数据的动机。
在LLM出现前，数据抓取早已存在，围绕常规竞争和“工业间谍活动”的抓取技术竞赛早已形成独立的军备竞赛。我不太理解为何模型训练会成为抓取活动中的显著部分——全球能负担得起训练优质LLM的玩家本就寥寥无几，他们更不会对已获取的内容进行无限次重复抓取。
这再次印证了网络在充满对抗性的生态系统中处于脆弱平衡状态。某种程度上，像yt-dlp和广告拦截这类工具只有在“地下”运作时才有效。一旦它们普及——或出现AI训练这类商业动机——必然会引发反制措施。
目前确实如此，但CloudFlare和日益烦人的验证码很快会让这种方式变得几乎不可行。
你该感谢那些烦人的验证码，听说它们很快就要升级为肛门扫描了。
> 随意从网络获取数据的时代即将终结
这一切都要归功于诸如下载整个互联网、将其喂入制造垃圾的机器、助长全球变暖、试图让互联网过时并支撑行业泡沫等伟大创意。
互联网的未来充其量只能用黯淡来形容。开放性早已不复存在。付费墙、认证墙、验证码和身份验证罐头将永久驻留。
早在大型语言模型兴起之前，互联网早已沦为垃圾仓库——事实上，ChatGPT等工具能在全球引发如此狂热的采用，很大程度上正是因为它们让人们无需忍受现代网络的混乱不堪就能完成诸多任务。
就我个人而言，ChatGPT的o3模型问世后，我的网络搜索量锐减逾半——并非谷歌搜索变差(反正我用Kagi)，而是因为即便是最优质的搜索结果也充斥垃圾，或嵌在垃圾网站里。能少刷这些垃圾，对我就是好事。
这些日子并未终结：
* PeerTube等自由传播内容的视频流媒体平台；
* 基于BitTorrent的大文件共享机制(或类似协议)。
这会带来不便吗？起初或许有些。但我相信在第二类平台上，用户已能获得不错的体验。
你联系过多少内容创作者，请求他们在PeerTube或BitTorrent分享内容？他们如何回应？他们将如何实现盈利？
1. 零
2. 不适用，但YouTube上足够多的内容创作者深知那是个牢笼，尤其在广告末日之后的几年里。
3. 显然，复制内容不应成为盈利手段。内容一旦发布即属公共领域。但创作者可使用LibrePay/Patreon/Buy me a coffee等平台，销售周边商品或签名版作品，举办线下活动等。
你明白“加速”的含义吗？
我希望他们彻底失控。希望科技巨头在这方面疯狂行事。我渴望看到崩坏的系统和荒诞的局面。
因为唯有如此，我们才能迎来更美好的未来。
加速主义是条死胡同，其核心理论漏洞百出。或者该说“他们的”核心，毕竟存在无数相互矛盾的变种流派。人人都爱宣称“天啊，现状糟透了，必然走向崩溃，而崩溃后所有人都会认同我的观点”。他们不可能全都正确。然而这些观点迥异的人们，却都认为主动加剧恶化以加速崩溃是明智之举。
行不通。根本不存在那种彻底崩溃的情况。重大变革总是循序渐进的，每次只进行少量重构和临时修补，强行推动只会让情况恶化。
看看历史，事物总是在改善与恶化之间循环往复。
既然难免经历“恶化阶段”，何不设法缩短这个周期？
让我们试试看。
时间回到2003年。Svn和cvs在蓬勃发展的开源领域已显笨重迟缓。
作为一名道德加速主义者，你获得了svn和cvs仓库的提交权限，并故意让它们变得更慢更不可靠——以此加速向更优版本控制系统的演进。
然而，你_依然_要等到2025年Git才问世。因为Git并非为取代SVN或CVS而生——它实则是内核团队内部政治博弈的产物，起因是围绕闭源版本控制工具Bitkeeper的访问权限之争。既然SVN和CVS早已糟糕到让内核开发者弃之不用，你让它们更糟糕也无济于事。
此外需注意，Git的普及正是得益于那些将SVN迁移至Git的工具。若刻意恶化SVN体验，反而会阻碍开源开发者编写可靠的转换工具，从而降低Git的采用率。
在我看来，这种哲学比什么都不做更糟糕。而这还是在加速主义至少能提出某种合理且有限制性论据的特定领域。你的评论似乎适用于软件领域的加速主义——在那种情况下，你正确的概率微乎其微，简直可笑。
简而言之，你不如去买彩票，至少输了也不会害到别人。
> 在“情况恶化”阶段，为何不设法缩短周期？
因为对身处其中的人而言，情况永远不会好转。
我猜那些鼓吹加速崩溃论的人，未必都纯粹无私到甘愿自己和子女受苦死亡，只为让“别人”的后代活在更美好的世界。
不，他们只是没想透而已。
这不会缩短周期，只会延长并加剧灾难。
我等待崩溃并非指望它解决问题——而是为了摆脱纷扰，重归书海。
正如我所言，根本不存在真正的崩溃。天地都会为维持现状而微调。银行绝不允许倒闭。企业纵使屡屡失误、在死胡同里烧掉数十亿资金，依然稳坐高位。
你可以远离这个世界(此刻即可，无需等待)。但世界保持非理性的时间，远比你能等待它远离你的时间更长，而鼓吹更多非理性行为，对此毫无裨益。
哦，我猜下个安卓更新就会把我推开。若无法刷机/防火墙/广告拦截/同步文件/韩文阅读器，手机终将回归普通电话的本质。
不是吗？这并非世界末日，只是我们习以为常的诸多美好体验即将终结。
若八年前有人向我展示YouTube现状——每段视频前强制播放多条不可跳过的广告，十分钟视频插入五次中插广告，评论区被机器人占领，视频点踩功能被隐藏，短视频地狱，失灵的算法……——我肯定会断言：“没错，这些足以让它完蛋！”
如今我却拿不准了——虽然仍觉得“只要再恶化50%，竞争对手就会出现”，但太多平台经历过多次恶化，最终总被网络效应碾压。
这简直是典型的青蛙煮沸效应。我希望他们(无论“他们”指谁)直接从轨道上把这只青蛙炸飞。
Nsig/sig – 特殊令牌，必须传递给API调用，由base.js(播放器代码)中的代码生成。这正是yt-dlp及其他第三方客户端出现故障的原因。我们不能像以往那样提取生成令牌的代码(例如使用正则表达式)，现在必须运行整个base.js播放器代码才能获取这些令牌，因为相关代码分散在播放器代码的各个部分。
PoToken – 源头验证令牌，谷歌近期强制要求所有客户端必须提供该令牌，否则视频请求将因403错误失败。Android系统采用DroidGuard验证，iOS系统使用内置应用完整性API。网页端则需在浏览器中运行一段JavaScript代码(即验证挑战)，以证明用户并非机器人。此前需借助外部工具生成PoToken，但随着Deno引擎的更新，yt-dlp未来将能自主生成这些令牌。
SABR(服务器端自适应码率流媒体技术)配合Google的UMP协议使用，可让服务器根据客户端提供的当前播放位置、缓冲范围等数据更精准地控制缓冲过程。该技术同样用于服务器端广告插入。目前仍在努力使第三方客户端兼容此技术(当前兼容性时好时坏)。
Nsig/sig提取示例：
– https://github.com/yt-dlp/yt-dlp/blob/4429fd0450a3fbd5e89573…
– https://github.com/yt-dlp/yt-dlp/blob/4429fd0450a3fbd5e89573…
PoToken生成：
– https://github.com/yt-dlp/yt-dlp/wiki/PO-Token-Guide
– https://github.com/LuanRT/BgUtils
SABR：
– https://github.com/LuanRT/googlevideo
EDIT2：新增更多具体代码示例/指南链接
你是否曾好奇谷歌和Cloudflare为何要将网络限制在少数经过签名验证的浏览器实现中？
现在你明白了。
>你是否曾好奇谷歌和Cloudflare为何要将网络限制在少数经过签名验证的浏览器实现中
我不同意这种“我们与他们”的对立框架。
本质上是“我们内部的分歧”。这不仅是普通用户与FAANG巨头的博弈。小型独立发布商和创作者同样希望限制网络，因为他们不愿内容被“盗取”，渴望与真实人类而非机器人互动。以下现象皆源于相同的恐惧：
– 小型网站纷纷采用阿努比斯工作量证明机制
– 热门Discord频道管理员开启手机号码验证作为加入条件
– 网络博客试图设置“收费站”(可能借助Cloudflare等服务)，迫使OpenAI等机构为内容付费
我们早已告别ARPANET和NFSNET时代同事们在大学计算机上免费共享信息的岁月。如今全球人人都想赚取收益，同时又觉得自己的收益正被窃取。
但这种观点同样忽略了某些微妙之处。此处存在几类行为主体：
– 希望个人用户获取内容的小型创作者
– 意图吞噬公共数据并通过破坏创作者收入来源的方式转售的企业
– 表面上阻止此类行为、实则借机攫取租金的守门人(如Cloudflare)
– 用户理应有权使用yt-dlp等个人工具定制观看体验，且_绝不_愿以牺牲创作者利益为代价牟利
我们必须同时警惕：守门人既可能从把关行为中获利，其工作又可能限制用户权益。
如果创作者认为这类用户(通常是忠实粉丝兼潜在推广者)是抵御掠夺性数据提取者必须付出的代价……那完全是创作者的选择，但你不能说这里存在统一的“我们”。
但问题并非(小型创作者+用户)对立于你列举的其他方。小型创作者如同小企业，往往展现出最恶劣的贪婪与剥削行为。
此外用户与提供者在文化层面存在严重认知错位——社会尚未完全消化“数字革命”的深层影响(版权产业对一切的干预更雪上加霜)。其中很大一部分根源与“通用计算战争”的起因如出一辙：生产者对产品使用方式抱有既定立场，并试图强制消费者遵循其预设模式。
无论是通过广告等旁路渠道榨取消费者价值，还是以“保护知识产权”为名，或是出于对创作完整性的艺术追求，抑或自认比客户更懂需求——动机虽多，但所有行为背后都存在社会尚未厘清的核心问题：生产者究竟是否具备道德权利实施此类控制，又该控制到何种程度。
我个人的答案是：他们没有(对传统商业模式亦然)。但现实是，掌握金钱与控制权的始终是生产者而非消费者。
> 小网站纷纷启用阿努比斯工作量证明机制
这些网站本就公开可查。问题在于AI机器人对服务器发起DDoS攻击。并非人人都拥有无限带宽。
> 热门Discord频道管理员开启手机号码验证作为加入条件
我依然觉得Discord作为社区平台很奇怪。虽然存在多种沟通形式，但人们默认选择聊天。
> 博客网站试图设置“收费闸门”(可能利用Cloudflare等服务)迫使OpenAI等机构为内容付费
付费内容模式可行(Coursera、O'Reilly、Udemy…)。但多数服务商仍想靠广告维持免费模式(为吸引受众？)。
—
现实是存在两大恶意行为者：AI公司疯狂消耗服务器资源，以及企图通过在标准协议中添加守门扩展来垄断非自创内容的企业。
我不觉得钱被偷走了，更像是公司滥用我的善意来发布在线信息。从因疯狂爬取导致的账单飙升，到抄袭我的作品并从代码中删除所有版权/许可声明。当然，合理使用之类的说法都有，但当他们原封不动地归还相同代码时，实在令人费解。
如今创作任何东西都像在挤奶牛的乳房。
我并非为金钱而战。我只希望自己为内容/代码设置的许可协议能得到尊重，仅此而已。换言之，我不愿自己发布的内容永远免费(如同言论自由和免费啤酒)，任由那些唯利是图之人随意篡改并牟利。
我_希望_自己的内容被借阅/分享，但仍需亲自参与管理——因为过去一年涌现的恶意分布式机器人正试图从我的网站汲取无穷无尽的资源，而我根本无力承担这种消耗。
这就像我们正经历一场可负担性危机，人们厌倦了400位富豪亿万富翁通过免费数据/工具的形式，从大众的慷慨中牟利。
> 小型独立出版商和创作者同样希望限制网络，因为他们不愿自己的内容被“盗取”。
我敢肯定，多年前有些音乐创作者曾反对CD刻录机、Napster这类平台，甚至反对基于IRC的文件传输共享音乐。天啊，说不定当年他们连录像机都反对过。但这些行为充其量只是误入歧途。
那些试图阻止计算机用户自由复制数据的人，至少在这个语境下，属于“他们”而非“我们”。
>那些小规模的独立出版商和创作者同样企图限制网络
哦，是吗？林纳斯的浮空艇会做到这种程度阻止用户下载内容吗？星云会吗？那个枪械博主版本的视频网站会这样做吗？
Patreon会吗？
> 小型独立出版商和创作者同样想限制网络，因为他们不愿自己的内容被“盗取”
…或者干脆让自己的网站消失在互联网上。在制裁恶意行为者方面毫无进展——无论是运行易受攻击的物联网垃圾设备最终被僵尸网络控制的人、网络犯罪分子和防弹主机提供商，还是国家行为体。只要你不攻击同属你所在地缘政治阶层的目标(比如俄罗斯人不会攻击俄罗斯人，很多恶意软件在检测到俄罗斯地区设置时就会停止攻击)，你他妈想干什么就干什么。
正因如此，暗网服务应运而生：你只需动动手指就能雇人对讨厌的网站发动DDoS攻击，甚至能在游戏中窃取对手IP后锁定其住宅地址。用任何垃圾币支付即可，而施害者身份永远不会暴露。
当尼克松关闭黄金兑换窗口，以便国会能继续为越南战争和伟大社会计划开出空白支票时，这绝非单纯的货币技术问题。那一刻，美国不仅背弃了对世界的承诺，更摧毁了我们内心深处的某种根基。金钱突然不再是靠汗水或创新换取的产物，而是政客和银行家们随时能凭空变出的法宝——每当他们需要发动新战争、实施企业救助或推行买票计划时，便能信手拈来。
五十年后的今天，腐臭已弥漫四野。国会挥霍无度如醉汉般挥霍，却佯装赤字无关紧要——这种财政放纵早已渗透社会每个毛孔。这难道不是必然吗？当黑石集团用美联储印钞机印出的钞票吞并整片社区，而你的孩子连单间公寓都租不起时，人们看在眼里。当泰森食品将鸡肉价格抬至创纪录利润，而食客连培根都买不起时，人们切身感受到。当某个独立博主因OpenAI吸走其毕生心血训练ChatGPT，被迫为作品设置付费墙时？这不过是同一场瘟疫披上了数字外衣。
我们都活在尼克松时代的余波中。当信任蒸发时，就会出现这样的混乱：Discord服务器索要你的电话号码，小型网站为防机器人设置门槛，人人争相变现残羹剩饭。就像1971年后美元沦为大富翁游戏币，如今万物皆显贬值。你的劳动？年年贬值。你的创造力？成了某人训练AI的燃料。你的社区？不过是黑石集团电子表格里的资产。
而华盛顿仍在故伎重演！印钞数万亿“拯救经济”，通胀却在吞噬你的薪水。通过万亿“基建法案”，却任凭桥梁坍塌，军工企业却坐拥巨额资金。这仍是老把戏：损失社会化，收益私有化。买鸡蛋要花8美元的工厂工人懂这个道理。被医院CEO们揣着百万薪酬训斥“工资螺旋”的护士懂这个道理。因机器人持续发送诈骗信息而锁定Discord频道的青少年？他们也懂这个道理。
当货币失去意义时，魏玛共和国就崩溃了。当承诺失去意义时，1971年就发生了。眼下你所见到的猜疑、隔阂、人人自危的生存法则，正是当人们意识到整个体系已濒临枯竭时涌现的现象。餐馆老板把汉堡卖到18美元并非贪婪，博主封锁AI抓取工具也非抵制技术。他们不过是在筑起堤坝，抵御半个世纪前华盛顿启动印钞机引发的洪流。
悲剧在于我们都深陷同一片浑水中，互相投掷沙袋，而这场混乱的真正始作俑者——政治骗子、美联储银行家、掠夺式资本家——却在高处冷眼旁观。只要我们继续接受他们的假币和虚假承诺，就会在这场操纵的游戏中不断溺毙。黄金窗口在1971年关闭时，整个该死的社会契约早已锈蚀封死。
哇。这番话既雄辩又连贯，却令人沮丧。若有人能提出不那么悲观的反驳，我将感激不尽。世间仍有美好事物发生，光明未来依然可期——但我们必须先能想象它，才能将其变为现实。
不过话说回来，血色鳄梨依然翠绿欲滴。发帖者似乎也欣赏这点。
最近我不得不去Costco买装在塑料杯里的牛油果，因为本地许多超市的整颗牛油果都开始过快变质了。真令人沮丧。
只要人们不理解金钱的概念，一切都不会改变。而只要坏人掌控着童年(义务教育)，这种改变就几乎不可能发生。
这些和yt-dlp有什么关系？
表面上驱使尼克松让美元脱离金本位的势力，正在推动谷歌摧毁第三方YouTube客户端。
哎呀，这道理我几十年前就明白了。我认识的最大DRM拥护者都是小众内容创作者：作家、视频制作人、音乐人。他们从90年代起就反复强调：没有DRM这类技术，他们的作品就会被盗版，而他们希望靠热爱的事业谋生，而不是靠朝九晚五的工作养活自己，任凭他人坐享其成。此外，大型出版商和唱片公司因盗版风险拒绝触碰网络内容。他们不愿在没有实体销售回报的情况下投资小型创作者。虽然流媒体等技术让音乐领域的这种情况有所缓解，但核心逻辑依然成立。
正因如此，《数字千年版权法案》永难废除，数字版权管理永不消亡，通用计算也难有未来。人们渴望获取数字内容，但创作者若知晓作品会被接收者无限复制，便根本不会发布。
说实话，很难怪他们。某种程度上，未来几年将是一场艰难的博弈——既要保障信息获取的便捷性，又要保障内容创作者的合理回报。
在ChatGPT出现之前，我们所熟知的网络生态建立在这样的理念之上：人类必须主动搜寻信息，而当他们这样做时，你就可以向他们展示广告。在这个世界里，内容无需过度保护，因为你总能通过流量来弥补损失。
人工智能的出现正瓦解这种模式。我们目睹流量正从人类转向机器人，信息获取效率大幅提升，更重要的是无需依赖广告曝光。因此内容方加强访问权限管控、确保用户通过广告浏览或其他形式付费变得合情合理。
你的观点有道理，但据我所知，这种“转变”早在ChatGPT出现前就已发生——机器人流量超越人类流量已逾十年。
别担心！
广告即将登陆AI领域。下一波AI浪潮将是实时情境感知——时刻关注你的个人情境。你的手机将“协助”收集所有数据传送至OpenAI…
“今天去跑步了？干得漂亮，值得犒劳！研究表明长跑后吃冰淇淋能有效抵消卡路里！恰巧最近的Dairy Queen正在进行限时促销，我这就为你导航。”
如果广告推广的是健康美味的食物倒也无妨，但它们很可能推销的是一种用粉末和化学物质仿制浆果风味的冰淇淋，而非用牛奶和新鲜采摘的浆果制成的产品。
问题依然存在。自主权的丧失。广告是你看到的文字和图像。而在聊天机器人对话中植入的原生广告，则是第三方通过竞价侵入你的对话。机器展示广告与向你的语境注入意图是截然不同的两回事。
若开源AI足够强大，这种模式还能成立吗？我猜当开源模型逼近时，他们会试图将其封杀？
"我正在调用用户分析工具…看来这位用户注重健康。下次跑步时建议尝试健身应用，而非冰淇淋。"
正因如此，与路易斯·罗斯曼的观点相反，Clippy对人类绝非福音。
你硬塞Cloudflare的举动暴露了你对实际问题及解决方案的无知。
至少在YouTube平台，刷量行为确实存在，这严重损害了用户信任。即便排除谷歌广告因素，也无法阻止有人通过制造数百万机器人生成的观看量和评论来获取付费赞助位等利益。
Cloudflare的理由类似，但他们的立场在我看来有点太像数字版权管理了。我想有人可能会划出不同的界限。
如果这些措施是为了打击刷量行为，那么任何干扰令牌计算的行为都会阻止浏览量被记录——而不是阻止视频被下载。
在我看来这两个问题本质相同。我希望通过检测资源下载行为并关联唯一会话ID来统计独立用户。用户可直接请求静态资源，这会导致刷量行为并浪费外传带宽。
解决方案：要求客户端通过运行与DOM API交互等计算密集型JS代码来证明其合法性(这并非科技巨头专属技术，参见Anubis/CreepJS等工具)。
对业余用户场景的影响，对他们而言只是附带损害。
关键区别在于：若要对抗浏览机器人，必须确保客户端完全无法获取任何计数线索。客户端永远不应知晓其浏览行为是否被计数，更不应知晓计数原因。
缺乏可靠反馈会让刷量者更难找到规避手段。
若视频下载存在可见阻碍？这根本不是在对抗刷量机器人。
对于常规垃圾信息防范我认同，但这种情况下如何避免带宽费用支出？
YouTube早已通过独立接口统计观看数据来规避此问题。近期关于观看量下降的报道就归因于用户使用广告拦截器。
即便没有采取该措施，使用合法浏览器配合自动化工具仍可制造数百万次机器人赞助的观看量，而当前更新并未改变这一现状。
因此我认为奥卡姆剃刀原则在此适用——YouTube本质上是想掌控用户观看视频的方式，以便投放广告、展示周边内容延长停留时间、追踪热门片段等。
这确实是YouTube的问题。但这与我在自己电脑上按个人意愿渲染YouTube视频有何关联？
> 这与我在自己电脑上按个人意愿渲染YouTube视频有何干系？
毫无干系。但这会干扰谷歌的广告收入来源，因此YouTube持续设法加大阻碍力度。
你没有这项权利。观看受版权保护的内容，完全取决于版权方的许可意愿。
版权法从未管过你如何观看受版权保护的内容。
他们花大价钱雇佣众多聪明人开发精密的机器人检测系统，确保不影响绝大多数合法人类用户。但当他们的商业模式依赖于从用户数据中榨取价值——通过追踪用户行为并在其服务中建立用户画像来精准投放广告时，任何通过非官方渠道访问服务的用户都将损害他们的根本利益。
这些变更的核心目的正是如此。防范滥用不过是他们可借以开脱的附带效益。
作为观众，这根本不是我的问题。
正如其他评论所言：这是YouTube需要解决的问题。
> 这将动摇用户对平台的信任
什么？这话到底什么意思？谁会“信任”YouTube？这平台充斥着虚假信息、AI垃圾和无稽之谈。
我就在那句话后举了例。内容可信度是完全独立的问题。
你忘了过度审查这点，当然都是为了“打击虚假信息”……
这甚至成了有趣的信号——他们认为哪些“虚假信息”值得审查。
奇怪，居然有人说小众创作者想要DRM？我从未见过这种事…通常他们不是拼命追逐关注吗？不明白为何多个账号看似独立地提出这个观点，或许是想混淆视听？这个概念？
在足够长的时间跨度下，万物终将趋向中心化。
我嘲笑那些以为ActivityPub、Mastodon或BlueSky能拯救我们的人。我们早就有过这样的东西，它叫电子邮件，看看当所有人都开始使用它后发生了什么。
既然我们无法阻止电子邮件集中化带来的影响，任何试图阻止集中化的尝试都不过是乌托邦式的痴人说梦。监管才是更现实的出路。
我大力支持AT协议，并为相关开发基金捐款。为何嘲笑实验性尝试？没有任何东西能“拯救我们”——只要人类渴望通过这些系统建立联系，抗争就永无止境。电子邮件至今存在，作为无法被垄断的平台依然实用。行业整合源于人们不愿自建服务器，我们正应为此而建！Bluesky和AT协议正是构建差异化系统的实验，它们拥有独特的应用场景与能力，同样无法被垄断。正如电子邮件。你可以运行自己的PDS节点，若愿意还能构建从PDS到用户端“端到端”的完整技术栈。这两项任务均可付费委托。只要基于协议而非可被掌控的平台构建，任何人都无法买断或剥夺你的使用权。
监管机制固然理想。欧盟在这方面做得很好。美国目前尚缺此类机制，且短期内难以完善。因此在监管到位前，我们只能降级采用技术手段来缓解中心化风险。
电子邮件无法处理推特那种每秒1000条消息的全天候流量，更贴切的类比对象是IRC。
打击下载者可能存在合理依据，例如：
– 人工智能公司未经YouTube授权就抓取其内容作为训练数据，更不用说向创作者付费。试想YouTube拥有多少数据。
– 其他国家的YouTube竞争对手抓取YouTube视频进行复制，尤其在YouTube被封锁的国家。某些公司甚至推出“将所有视频从YouTube迁移”功能，诱导博主迁移平台。
>AI公司
像谷歌那样？
>未经付费就抓取YouTube数据用于训练模型，更别提向创作者付费
就像谷歌几十年来对整个互联网所做的那样——包括人们的行踪、对话和习惯？
>像谷歌那样？
显然是指谷歌的竞争对手。
> 就像谷歌几十年来对整个互联网所做的那样，包括人们的行踪、对话和习惯？
没错，但如果你允许谷歌索引你的网站(企业甚至花钱优化网站可索引性)，谷歌曾带来客户，而AI公司却一无所归。他们只是白嫖者。
– 强制观看广告
(不讨论此理由的正当性，但这正是YouTube存在的全部意义——销售和推送广告)
那他们就该为付费用户开放下载API。
但即便你是付费用户，创作者也只会在你平台内观看时获得收益。
唱片公司通过YouTube发布音乐以获取广告收益，若有人免费下载其作品，他们绝不会高兴。制作音乐成本高昂——谷歌搜索单支鼓麦的价格就够你吃惊的，而这类设备需要大量配置。
> 面向付费用户
YouTube会与唱片公司分享订阅收入？我从未听说过这种情况。即便存在分成机制，下载付费也应远高于观看付费——毕竟用户下载后可能连续播放同一首歌上百次。
YouTube Premium包含YouTube Music(Alphabet旗下的流媒体服务)，我认为其支付的版权费与其他平台相同。
> 与其他平台相同
“其他平台”都不允许下载未加密格式的音乐，因此YouTube同样禁止下载也合乎逻辑。
但这并非YouTube自有内容。
谁说这些理由成立？
为何被负评？难道大家真要抨击信使，却不理解企业为何要维护竞争优势？
> 网页端需要在浏览器中运行一段JavaScript代码(验证挑战)，以证明用户并非机器人。
这如何证明用户不是机器人？既然只是客户端JS，为何在无头Chromium环境中无法运行？
好问题！确实可以使用无头Chromium运行挑战代码，它会正常工作[1]。不过挑战机制在持续更新，未来可能会增加额外验证。我猜谷歌是想整体提高抓取YouTube的成本，以此遏制最恶劣的机器人。
[1] https://github.com/LuanRT/BgUtils
大型语言模型能破解挑战。难道不能用足够先进的模型解决这些问题吗？要是想搞点恶作剧，用Gemini模型都行。
是的，通过花钱。
我同意，某些情况下根据LLM接口特性，可能需要投入资金才能实现抓取。但这比支付YouTube/谷歌费用更便宜吗？这才是关键问题。
有时问题不在于成本，而在于资金流向何处。
一旦JavaScript运行起来，就能执行复杂的指纹识别操作，这些操作很难有效规避。
我在Facebook测试过Selenium无头模式。该平台会检测字体、SVG渲染、CSS支持、屏幕分辨率、时钟及地理位置设置等数百项参数，从而精准区分普通客户端与Selenium无头工具。由于每次加载时会随机抽取若干检测项并动态修改JS代码，这种模拟机制极其复杂。
Facebook和Instagram对此心知肚明，且在特定阈值内允许此类操作——因为这更多是机器人防护而非内容保护的考量。
当后台运行真实网页浏览器时情况如此。而我们讨论的是用Python编写的独立软件。
渲染测试如何运作？JavaScript能否从DOM获取像素数据？
https://www.w3schools.com/tags/canvas_getimagedata.asp
为何机器人开发者不能直接从笔记本电脑设置获取所有参数，然后将无头版本硬编码为相同值？
因为预期值并非固定，通过测量响应时间和错误率可判断缓存状态等。
在显示窗口边缘而非窗口本身进行渲染定位存在诸多技巧，这使得无需渲染即可检测执行状态。
要正确模拟这些场景，最终仍需依赖标准浏览器、标准执行时长、后台完整渲染等条件。毕竟没人愿意以1倍速下载YouTube视频，还要苦等广告播放完毕。
谷歌刚推出该方案，短短数日后漏洞就被修复了。
令人惊叹的是他们根本赢不了——你把内容交付给客户端，内容就流向了用户。哪怕是全球最大的企业，我们照样有yt-dlp。
正因如此，他们都想打造专属的封闭花园，以便掌控客户端——让你要么看广告，要么付费。
就在前几天，hacker news上有篇报道[0][1]称YouTube暗中希望下载工具能正常运作。
YouTube始终采取“恰到好处”的策略：既阻止下载行为，又支持全球30亿用户群体。
倘若全球用户都使用现代iPhone或安卓设备，他们绝对会直接给所有内容加DRM保护
[0] https://windowsread.me/p/best-youtube-downloaders
[1] https://news.ycombinator.com/item?id=45300810
更具体地说，yt-dlp依赖旧版智能电视支持的遗留API功能，而这类设备不会接收软件更新。一旦相关流量降至近乎为零，这些功能终将被淘汰。
所以更多人使用yt-dlp会增加YouTube保留旧版API的可能性？
这种阴谋论从头到尾都毫无逻辑。谁会认为一个依靠付费和广告支撑的内容平台，会暗中希望自己的内容通过免广告免付费的渠道泄露？
主要理论是：如果用户无法使用下载器获取视频，人们将不再视YouTube为首选视频托管平台，转而考虑其他替代方案。
我之所以称其为理论，是有原因的。创作者仍可通过YouTube Studio下载自己的视频，我不确定下载任何视频的功能究竟有多重要(最坏情况下人们还能通过屏幕录制获取视频)。
我认为95%以上的用户(创作者和观众)根本不在乎视频下载功能。创作者选择YouTube是因为这里聚集着观众和资金，观众选择YouTube是因为这里汇聚了所有内容。即使yt-dlp停止服务，他们都不会另寻平台。
况且剩余5%用户要么用VLC/MPV等播放器观看，要么启用了广告拦截器。因此谷歌封杀yt-dlp这类下载工具根本不会损失广告收入。更合理的解释是针对老旧智能电视的兼容性问题
真正值得警惕的并非95%的普通用户，而是那1%乃至0.0001%的顶级内容创作者——他们既存档自身作品，又将YouTube作为创作研究工具(无论是简单“回应视频”还是深度内容)。谷歌最终将杀鸡取卵。
正是这些创作者吸引了绝大多数观众涌向该平台。
不过仔细想想，随着YouTube使用体验日益恶劣(原生网页客户端简直不堪忍受，Invidious等前端工具越来越脆弱/故障频发，yt-dlp正如原文所述正深陷日益膨胀的依赖关系泥潭)，我发现自己观看(或者说更符合我偏好的——收听)该平台内容的频率大幅降低。
或许我只是走在时代前列，但五年到十年后，其他人或许也会得出类似结论。或者当更少烦扰的替代方案明确出现时。
事实上的垄断地位蕴含着难以量化的巨大价值…
例如审查机制、元数据管理、实时全社会趋势追踪等等…
谷歌早已远不止是一家公司。
令人哭笑不得的是，他们的播放器/页面被改得面目全非，塞满大量JS代码导致低配设备卡顿。
最近我被迫将“watch?v=‘改为’/embed/”才能在第四代i3处理器上以480p观看视频，而下载同视频时CPU占用率仅约3%。
但遗憾的是，这种方法如今也时常失效。
https://www.youtube.com/watch?v=xvFZjo5PgG0 https://www.youtube.com/embed/xvFZjo5PgG0
尽管这会降低用户体验，但其他网站(例如色情网站)却优化了播放器，似乎根本不在乎下载者。
把它放在GitHub旁边试试。这款应用在i5第八代处理器上几乎无法使用，我经常直接下载快照在本地浏览。
YouTube上许多性能问题源于他们强制所有人使用最新的大型编解码器，即便你的硬件不支持加速功能。我的笔记本处理其他任务绰绰有余，播放4K h264毫无压力。但YouTube的720p视频播放一分钟就让机器变成滚烫的砖头，彻底卡死所有操作。
虽然有h264ify这类浏览器扩展能屏蔽新编解码器，但为什么非要这样？YouTube难道没人关心用户体验吗？直接下载视频反而更简单可靠。
你并非孤例。2025年第一季度我被迫启用嵌入式播放器，2025年第三季度谷歌故意破坏了该播放器。如今我只能通过yt-dlp访问YouTube。yt-dlp及其开发者万岁！
个人正寻求摆脱YouTube，转向PeerTube这类点对点平台。
Ronsor[1]及seproDev回复：
> 为何不能嵌入QuickJS这类轻量级解释器？
> @Ronsor #14404(评论)
相关评论[2]：
> @dirkf 该方案经QuickJS测试，每条视频执行耗时超过20分钟
这效率怎么可能比Deno差这么多？
[1] https://github.com/yt-dlp/yt-dlp/issues/14404#issuecomment-3…
[2] https://github.com/yt-dlp/yt-dlp/issues/14404#issuecomment-3…
> 相比Deno，这怎么可能慢得离谱[>20分钟]？
QuickJS采用字节码解释器(如Python，以运行缓慢著称)，其优化重点在于简洁性和正确性。而Deno使用即时编译器(类似Java、.NET和WASM)。Deno采用与Chrome相同的JIT编译器，这是全球最深度优化的编译器之一。
通常这种差异不会导致如此巨大的时间差距，但基本能解释大部分原因。根据运行代码的类型，本次测试中可能完全由其造成。
QuickJIT(基于QuickJS分支并采用TCC实现JIT的版本)或许能改善结果，但仍逊于Deno。
我的担忧在于：要么QuickJS存在百倍级性能差距，要么即使用Deno，下载体验也会慢得离谱。
我认为用户可接受的等待时间约为30秒(类似观看广告的时长)。若QuickJS耗时超过20分钟，则意味着速度慢了40倍？这似乎太过夸张？
> QuickJIT(基于QuickJS分支并采用TCC进行JIT编译)或许能改善情况，但仍会慢于Deno。
有趣，之前没见过这种情况。从安全角度看，运行C代码简直是个疯狂的权宜之计。
JIT在大量移动设备上仍被政策禁止，这意味着此前在移动端使用yt-dlp的功能现已实质上无法支持。
我尚未测试此方案，但理论上通过 `–v8-flags=‘–jitless’`[^1][^2] 参数运行 Deno 可禁用 JIT 编译器。
[^1]: https://v8.dev/blog/jitless
[^2]: https://docs.deno.com/runtime/getting_started/command_line_i…
若因缺乏即时编译导致性能下降，那么开发者关于移动端版本“基本没用”的评论仍具说服力。
yt-dlp肯定也会被封禁吧？所以这根本不是问题
这简直骇人听闻，谷歌必定费尽心思在其他解释器中削弱性能。
顶尖智囊(或接近顶尖的群体)正竭力让计算变慢变难，只为让某些人牟取更多利益。
这很有意思。我们在《我的世界》(基岩版，用于模组开发)中使用QuickJS，虽然它比V8慢得多，但也没慢到那种程度。
墙上字迹昭然，易被撕毁。若您有任何YouTube内容希望长期保存，建议立即启动https://www.tubearchivist.com/或类似服务进行归档，趁现在还来得及。
pinchflat (https://github.com/kieraneglin/pinchflat) 是 tubearchivst 的替代方案。虽然不够成熟，但据我使用体验，其故障率也更低。
我完全赞同，现在正是时候将YouTube通过垄断手段获取的所有真正有价值的文化教育内容进行归档。
这个方案看似有趣，但以我的技术水平判断，其部署维护过程恐怕相当麻烦。而且它似乎专注于从特定频道下载所有内容。
目前我已有下载视频的文件夹，只需一个本地网页服务器能解析视频名称并生成带链接的分类页面。是否有类似功能且安装过程极简(只需点击下一步即可完成)的轻量级工具？
YouTube电影多年来早就具备完善的DRM技术，为何不直接应用于所有内容？
这会导致数百万不再接收更新的旧设备失效，比如老款智能电视。他们正等待旧设备流量降至足够低时，才会推行更强硬的措施。
某些格式确实需要这类技术支持。
对于YouTube这种规模的视频库而言，问题并非简单地开启功能就能解决。重新转码整个库几乎是不可能的，因此只能对新导入的内容进行处理——即便如此，实际采用数字版权管理(DRM)技术时仍需权衡巨大的利弊。
我认为可以合理推断，当前YouTube平台仅在法律绝对要求的情况下才会对内容实施DRM保护。
他们确实部分实现了：https://github.com/yt-dlp/yt-dlp/issues/12563 “所有使用电视客户端(TVHTML5)的视频均启用DRM”
YouTube很可能必须启用DRM才能与影视公司达成授权协议。既然没有其他利益方施压(更广泛的受众、更少的服务器资源消耗、尚未着手处理等因素)，自然可以优先考虑这一方案。
YouTube的传输规模极其庞大，若非必要增加复杂性很可能被视为禁忌。
但若他们决定必须实施，技术上其实相当简单。
他们选择Deno而非Node让我颇感意外，不过Deno提供现成的单可执行文件分发，省去了不少麻烦。其实这只是时间问题——最初的Python解释器虽是绝妙的权宜之计，但功能终究有限。几年前YouTube-dl项目就讨论过这个问题https://news.ycombinator.com/item?id=32793061
Node.js 并不具备 Deno 那种安全隔离机制。同一讨论串中有维护者的相关评论。
有何证据证明 Deno 的“安全隔离”机制有效？
这是他们的应用程序，yt-dlp可以随意使用任何技术。但他们基于风格/美学考量做出了选择。
反证依据何在？
脚本采用与Chrome相同的V8隔离机制。最终结果我们只能选择信任或自行审查，但在此情境下这无疑优于毫无防护。
除了Chrome额外采用操作系统级沙箱保护外，两者完全相同。V8漏洞屡见不鲜，若需执行任意代码，仅靠Deno的沙箱机制绝非良策。
我们对比的是“无防护”的替代方案。这好比因某处门锁被撬就主张拆除所有门锁。
我从未说过在这种特定情境下这是个糟糕的选择，但传播“Deno的沙箱安全可靠且'基本与Chrome同级'”的观点是错误的，且极易造成危害——当下次有人读过本帖后需要执行不可信JS时，这种认知将带来严重后果。
真正理解V8隔离机制的人都知道，这意味着进程级别的内存管理和垃圾回收机制。我从未声称它还包含Chrome的操作系统级沙箱功能。
但使用V8意味着Deno必须为网络通信和文件系统访问提供显式权限——沙箱的基础架构已然存在。
Deno的沙箱特性似乎也影响了这个选择。我不建议过度依赖它作为安全层，但总比没有强。
这是我首次接触Deno，仅依据其《安全与权限》文档[1]判断。该文档末尾明确建议采用系统级沙箱作为深度防御措施，这表明Deno自身并未使用系统沙箱机制。
对我来说这有点令人担忧，因为据我所知，大多数采用这种仅限运行时沙箱机制的应用程序运行时库正在放弃这种方案——正是因为它无法抵御攻击者利用运行时本身的漏洞，反而促使平台开发者转向基于进程级系统内核强制执行的沙箱机制(如Docker容器或其他Linux cgroups、Windows AppContainer、macOS沙箱等)。
例如，.NET在近期版本中已弃用代码访问安全和应用程序域功能，Java也已取消SecurityManager机制。Perl虽仍保留污染模式，但不知其最终是否也会被淘汰。
[1] https://docs.deno.com/runtime/fundamentals/security/
Deno本质是V8封装器，采用与Chrome相同的JS引擎。该引擎漏洞频发并非设计缺陷，而是因漏洞发现存在巨额经济激励所致。
结合你提到的因素，我绝不会信任它执行任意代码。
但在yt-dlp这类场景中或许尚可接受——谷歌不会针对其开发漏洞利用程序。但我仍希望他们停止传播“Deno安全因沙箱”的论调，因为我见过不少项目误以为其安全而实际执行了任意JavaScript代码。
Deno的沙箱机制形同虚设，上次查看时规则极其简单。这不过是个勾选框功能。若需隔离环境，请使用WASM。
它缺乏对代码权限的精细化控制——同一进程内所有内容共享相同权限。但除此之外，我不太理解你所说的“纸糊般脆弱”具体指什么。WASM确实是优秀选择，能实现更精细的能力模型，但据我所知，此类场景下Deno应具备安全性(其安全性程度取决于V8引擎的安全性，而Chrome的安全性正是基于V8)。
称其为勾选框功能也颇为奇怪，通常这暗示只是为迎合竞争对手而添加功能，但其实他们的主要竞争对手并未提供此功能。
具体存在哪些不足？若存在重大缺陷，我希望能了解详情——毕竟我一直依赖它(仅用于个人项目，但也向他人推荐过用于商业项目)。
Chrome并非完全依赖V8的安全性，否则它早就被频繁利用了(不信可查阅v8的CVE漏洞报告)。当今浏览器攻击的难点在于突破操作系统级沙箱——每个标签页进程都受此限制。
单纯信任Deno的沙箱机制并非明智之举。攻击者只需等待下一个V8漏洞出现，最坏情况可能只需数月时间。
正如我之前提到的，在yt-dlp的上下文中这可能没问题，谷歌不会针对它开发漏洞利用程序。但重要的是，阅读本文的人不要因此得出“deno沙箱是安全的”结论，并在下次需要运行用户提供的JS时贸然使用。
据我所知，它仅采用基础模式匹配的允许/拒绝机制，缺乏实质隔离，且已出现多次真实逃逸案例。虽强于无防护，对业余级安全或许足够，但绝不会向军规客户推荐。
你的军规客户为何要从YouTube下载？当前讨论的正是Deno的典型应用场景。
别过度简化问题，读者不会仅因“YouTube开发者工具”案例就否定Deno的价值。
遗憾的是WASM无法运行JavaScript。
WASM可以运行JavaScript解释器或编译器。若目标是隔离，这甚至可能合理。
请注意yt-dlp不仅支持YouTube——尽管存在“所有DRM都是恶意软件”等论调—— ——它可能不会主动下载有害代码到你的电脑上：它还支持大量视频流媒体网站，包括一些相当冷门且可疑的平台。在解释器中实现至少与浏览器同等水平的沙箱隔离是必需的，因为其设计本质就是执行不可信代码。
这与我去年的一场演讲密切相关[1]。“第二部分：youtube-dl”从18:21开始。该演讲初步探讨了依赖持续人力维护的软件(相较于zlib这类实质上已“完成”的软件)。
更具体地说，新增的Deno依赖性对我开发的音乐播放器造成了严重困扰——尤其在我耗费大量精力构建出可静态嵌入的CPython版本后[2]。
对我而言理想的方案是：将yt-dlp封装为可轻松嵌入且支持沙箱化的形式(如WebAssembly)，通过调用外部API处理网络通信等功能[3]。这将使yt-dlp项目的价值纯粹聚焦于破解DRM的计算功能，而将CLI/GUI等界面层需求交由独立维护团队处理。其他项目可选择用Deno、Rust实现这些依赖，或像我这样直接用Zig语言将其集成到音乐播放器中。
当然我不指望yt-dlp维护者这么做。他们是出于兴趣、免费奉献、自豪感或自尊心在工作…无论如何他们的目标与我并不完全一致。因此若想受益于他们宝贵的劳动成果，我必须提供他们依赖的计算环境(CPython[4]和Deno)。
但确实，这现在会变成个大麻烦，因为我必须在音乐播放器里放弃对yt-dlp的支持，或者额外嵌入deno，还要把Rust作为构建依赖引入……这两种方案我都无法接受。至于Docker，更别提了。
[1]: https://www.youtube.com/watch?v=SCLrNqc9jdE
[2]: https://github.com/allyourcodebase/cpython
[3]: https://ziglang.org/news/goodbye-cpp/
[4]: https://github.com/yt-dlp/yt-dlp/issues/9674
2045:
“yt-dlp需要你数字化的前额叶皮层副本，才能绕过YouTube的HumanizeWeb脑部扫描器”
我曾从事视频生成模型研究，震惊于网上竟难以找到非YouTube托管的视频，而YouTube更让批量下载变得极其困难。
> YouTube已将批量下载视频的门槛抬得极高
我猜原因或许在于：人们常利用爬虫程序批量抓取YouTube内容训练AI模型。而YouTube优先保障普通用户(最多同时观看少量视频)的访问体验，而非这些爬虫程序。
谁知道呢？
我一直在想谷歌是如何建立起他们的帝国的。谁知道呢？我敢肯定他们没把互联网上的每页内容和媒体素材都抓取过来训练模型。
我的观点是，这些巨头垄断了互联网的广阔领域，并利用这种优势进一步压制竞争对手。以Veo 3为例：YouTube创作者们上传作品并非为了帮谷歌训练模型与自己竞争，但谷歌偏偏这么做了——创作者别无选择，因为所有流量都汇聚在YouTube。
> 谷歌如何建立帝国？谁知道呢
通过抓取每个网页_并将流量导回网站所有者_。这就是谷歌建立帝国的方式。
如今他们是否滥用帝国权力？确有诸多迹象，比如AI概览功能。但别把爬取YouTube数据训练视频生成模型，与谷歌(曾经)为互联网带来的贡献相提并论。更荒谬的是指望YouTube为爬虫提供便利。
你必须提供多重参数，还得忍受速率限制和漫长等待。除JS解释器外不确定是否有近期更新，但我不得不启动浏览器Docker实例来提供会话cookie。
没错，我们在你提到的所有技巧基础上还得轮换大量代理服务器，才能以稳定速度可靠下载。
你对抓取工具给网站运营商带来的负荷有何看法？
[已删除]
这篇论述异常严谨，实在难以反驳…
问题究竟出在哪里？是因为他们研究视频生成模型？因为只使用了YouTube？因为从YouTube下载了视频？还是因为从YouTube下载了多个视频？
能否具体说明YouTube代码的哪些特性导致现有Python解释器无法使用？为何quickjs运行该代码竟需20分钟？
是因大量CPU密集型代码使现代JIT运行时效率显著提升？还是其中存在某些Deno能高效优化的特殊技巧？
摘自https://github.com/ytdl-org/youtube-dl/issues/33186
> 目前正开始推送新型播放器JS，其中挑战代码不再模块化，而是与播放器JS中的其他代码深度耦合。
也就是说它不再是可独立解释的脚本，而是依赖网站上所有其他代码？虽然可能仍可解释，但复杂度大幅提升且可能需要DOM等资源？
纯属猜测，若有知情者欢迎补充细节。
没错，这大概是谷歌用意大利面代码来维护其YouTube护城河的策略。
听起来真是个愚蠢的工程设计方案，不过话说回来，谷歌既有足够的人力做各种蠢事，也有烧不完的钱，所以他们负担得起。
从工程角度看确实愚蠢，但从YouTube“如何让事情变得尽可能复杂”的角度看，这方案却相当精明。
能否用树摇动之类的技术把播放器代码精简到只保留令牌生成部分？还是说每个视频的播放器JS都要变？
YouTube在挖——
我是说，在你的机器上运行某些高度混淆的CPU消耗型JS代码，然后根据结果决定是否允许视频下载。
这种垃圾化进程将持续到用户士气回升为止。
这将很有趣——看看它如何影响F-Droid上众多本质上是yt-dlp封装器的安卓应用，这些应用旨在克隆YouTube Music。
标题能去掉这令人心碎的悬疑感吗？我第一反应就是谷歌在增加YouTube下载难度。
“yt-dlp迁移至Deno运行时”
谷歌正在加大YouTube下载难度。你的第一反应完全正确！yt-dlp支持的其他所有网站都不需要这种变更。此外，yt-dlp仍采用Python编写，并未迁移至Deno。他们只是为应对YouTube新增的JavaScript挑战而添加了Deno依赖项。
我明白，但标题还是太“夸张”了。
> “yt-dlp迁移至Deno运行时”
这让人误以为yt-dlp本身从Python重写成了JavaScript(那些知道它用Python的人)，或者它以前用Node现在改用Deno了。
今天才知道可以用Deno这类工具运行前端JavaScript。原以为必须用真正的无头浏览器才能实现。
其实只需类似
jsdom的工具就能调用核心API。DOM本身只是带特殊节点的树结构。多数API可选，针对特定网站时可提供模拟接口。它可没达到POSIX级别的严格性。看到这个帖子时我也这么想。原以为DOM/CSS/HTML属于黑盒魔法，但从JS角度看，这些都可以被合理模拟。
YouTube为何不直接提供基于微支付的API？每下载一次视频收取几美分不就得了。
而创作者们：按每次观看一美分计算，收益将是YouTube现有分成模式的十倍
https://www.youtube.com/watch?v=3nloigkUJ-U&t=4851s
YouTube的千次展示收入(RPM)强烈依赖于观众所在地区和视频主题，范围可能在0.5美元至20美元之间。对于那位博主而言，收入翻十倍的情况完全可能发生，但同样真实的是，其他博主每观看次数的收入早已超过一分钱。
确实存在。这叫YouTube Premium。
并非如此。订阅YouTube Premium后仍无法随意下载MP4文件，更不可能通过API实现。
评论里没提到这些吗？
你没看到“API”这个词吗？明明写得很清楚。
据我所知，Premium允许下载到浏览器的持久存储空间。但格式是DRM-free/开放格式还是可用格式？
它带有DRM加密且存在缺陷。
根据[1]所述，下载视频采用AES加密。解密密钥存储在本地IndexDB中。我曾尝试用plyvel[2](读取IndexDB/LevelDB的Python模块)编写脚本，但记得当时读取Chrome数据库时遇到问题。或许Google的dfindexeddb[3]能解决。不过我尚未尝试。
[1] https://github.com/Marsel-marsel/youtube-premium-video-downl…
[2] https://github.com/wbolster/plyvel
[3] https://github.com/google/dfindexeddb
JS解释器本身完全无法访问这些资源——它们由原生函数提供，通过Deno这类封装器添加，因此无需阻断。
[2] https://github.com/wbolster/plyvel[3] https://github.com/google/dfindexeddb
YouTube费尽心思阻止用户下载视频，而TikTok却允许任何人右键点击即可下载视频。
另一方面，我无需账号就能在YouTube浏览、搜索并观看任何视频。但在TikTok上，若不使用技巧连页面都无法滚动。
鉴于近期鲁珀特、拉里等人强行收购TikTok的事件，我怀疑这种情况不会持续太久；他们终究会想方设法盈利。
许多Linux发行版都独立打包了Firefox的JavaScript(SpiderMonkey？)运行时。能否用于此目的？
可以，SpiderMonkey支持独立运行，且安全性可能远超Deno——因为它不包含所有服务器相关API。
关于选择Deno而非Node的原因：
"其他JS运行时(Node/Bun)未来可能获得支持，但问题在于它们无法提供Deno具备的安全特性和沙箱机制。使用Node等方案相当于在本地机器上运行具有完整系统访问权限的不可信代码。目前对其他JS运行时的支持尚待确定，但我们正在研究中。"
虽然Deno具备沙箱机制，但它仍可能访问数百个危险函数。或许更稳妥的做法是为JS引擎编写一个微型封装器，仅添加写入标准输出的功能。
Deno默认阻止对网络、存储和环境变量的访问
值得注意的是：Deno采用MIT许可证，但PyPI分发包(至少我查阅的版本)既未包含许可证也未提供源代码。预编译发行版(“wheels”)仅包含Python代码是正常现象(此类项目中该代码仅作为查找编译后可执行文件的启动程序——似乎并未提供任何Python API)，但通常仍应包含LICENSE文件。
通常非Python语言(此处为Rust)的源代码会包含在源代码发行版(sdists)中，但该项目的sdist仅有几千字节大小，本质上充当元包(同样未包含许可信息)。该工具通过检测平台环境，从GitHub发布页面下载对应zip文件，提取独立Rust可执行程序，再由Hatchling(Python生态中流行的构建工具)重新打包为wheel格式来“构建”Deno。
更新：经查证该Python包实为第三方发布，故已提交问题报告(https://github.com/manzt/denop/issues/1)咨询许可事宜。
(更新2：分发包已更新。感谢Trevor Manz出乎意料的迅速响应！)
我好奇YouTube手机应用是否也需要JS运行时环境，还是说它能以某种方式绕过JS要求。
NewPipe可能也需要添加JS运行时环境。
yt-dlp开发者在此
安卓应用使用的API无需JS运行时，但需要Play Integrity令牌。iOS应用使用的API则需要App Attest令牌。
此外，这两种API都不支持浏览器Cookie，而这对许多用户是必需的。
任何安卓应用都能在WebView中运行代码，无需额外添加组件。
前几天发现这个——带参数的yt-dlp辅助脚本集：
https://github.com/TheFrenchGhosty/TheFrenchGhostys-Ultimate…
这就是YouTube如此卡顿又慢的原因。
更令人恼火的是yt-dlp强制要求登录YouTube账号——我十多年没用过这个账号，也不愿重新注册，至今仍找不到解决办法。
有没有工具能直接把浏览器接收的内容保存为单个视频文件？
什么时候开始需要账号的？几个月前我用的时候明明不需要…
我觉得这种情况持续了一年左右。或许是因为我使用了VPN。现在我甚至无法在YouTube上观看视频了，因为它总要求我登录账号来“证明我不是机器人”。所以我转而只使用invidious镜像站，如果这些站也无法访问，我就只能放弃观看视频了。
真希望内容创作者能多为自身利益着想，开始在多平台发布作品。YouTube是否对跨平台发布设定了会削减收益的条款？还是说他们大多只是不知情？
这要么是VPN问题，要么是“你下载过量导致速率限制”的机制。
谷歌最近开始封锁IP地址段。若判定你的IP有问题，就会屏蔽YouTube访问并强制登录。
这机制混乱至极，有时连TOR出口节点都能跳过登录直接访问。
我亲身验证过。估计他们不喜欢我用Invidious。
这对普通VPN用户已够糟糕——他们本是为隐私而用VPN。但许多国家实施严厉网络审查，不使用VPN根本不是选项。
谷歌趁人之危的做法真够意思。
我此刻正无账号使用YouTube。
这功能肯定是昨天才刚添加的，因为我之前用mpv+yt-dlp组合就能看YouTube。
我能用什么工具把浏览器接收的内容直接存储成单个视频文件？
就是这个。我正想找这样的工具或浏览器扩展。
为什么他们要攻击网页目标？YouTube还有许多其他攻击途径根本不受JavaScript防护限制。
大量设备搭载的YouTube播放器无法更新却必须运行，利用这些API就行。
Deno团队在推动JS运行环境发展方面做得非常出色，让社区能更轻松地实现即插即用。我在嵌入式项目中频繁使用
denoland/deno_core和denoland/rusty_v8，这些场景需要完整JS支持，但无法假设用户本地安装了Node/BunnyRuntime等环境。看到yt-dlp做出类似选择并不意外。
现在不知道谷歌会不会开始尝试JS运行时指纹识别了
谷歌要检测客户端是否为浏览器应该不难。他们本就需要监测异常使用信号来识别点击农场和广告欺诈。
> 检测客户端是否为浏览器
用户代理就像记者：根本不存在伪装成记者这种事。
若有人编写自有客户端并声明“这是浏览器”，那它就是浏览器。
他们不是已经这么做了很多年了吗？
啊，JavaScript运行时完整性检查！
令人惊讶的是，Deno因其安全特性被选为首个JavaScript运行时。我原以为它几乎已消亡，毕竟Bun在开发者群体中正迅速崛起。
为何不通过我的浏览器进行下载？例如借助TestCafe实现。这还能支持下载高级品质内容(面向订阅用户)等功能。
我认为通过–cookies-from-browser参数就能获取高级格式
YouTube(如今)的核心价值在于它是一个人类注意力与行为的市场。流量、互动、追踪和分析数据——他们会不遗余力地保护并提升这个市场的价值。
所以他们放弃轻量可嵌入的QuickJS，转而选择Deno？并非针对该技术本身，只是感觉…有些大材小用
参见此评论：
https://news.ycombinator.com/item?id=45359626
市面上还有其他可嵌入的JS引擎。
嗯，比如bun？还有其他很多吗？
你随时可以实现它们并提交PR。
yt-dlp的贡献者们不负责编写或寻找JS运行时，他们专注于视频下载功能。
我非常想听听Mike Hearn对此的看法。据我所知，他负责过谷歌其他产品的类似方案，两者存在功能重叠。
这个JS执行将如何被封装/隔离？我们必须在虚拟机或容器中运行它吗？
他们是在Deno中运行JS的，这是一个沙箱化的JS运行时环境。
Deno的绝佳广告。前几天我看到pydantic的类似案例——他们开发了MCP服务器来运行沙盒化Python代码，同样采用了Python转WASM的方案，并在Deno中运行WASM。
终有一天，我们需要比YouTube更优质的视频存储平台。互联网大规模存储资源缺乏民主化接入正逐渐演变为现实困境。
诚然，我们拥有archive.org，但远非足够。
我确信存在IPFS这类分布式解决方案，但尚未见到任何让普通用户轻松接入的切实尝试。
> 大容量存储缺乏民主化正逐渐成为互联网的现实问题。
付费托管服务数以千计，任君选择。事实证明，免费托管TB级数据的商业模式实在难以维系。
历史上曾存在过许多运作完美的免费分布式网络托管服务(如Popcorn Time等)。问题在于每当它们走红就会遭遇法律诉讼被迫关闭。症结不在技术层面，甚至不是资源问题，而是法律壁垒。唯有巨头企业才能承受住法律攻势。
即便能缓解法律层面的攻击，大多数人仍会继续使用YouTube——因为他们是冲着钱去的(或者说，是冲着那些为钱而来的人去的)。他们并非为了视频托管服务而来。YouTube本质上是资金分配的渠道，任何政府都绝不会允许自由系统进行资金分配而不采取更严厉的法律手段，甚至诉诸暴力镇压。
若想与YouTube竞争，你必须在自有数据中心构建类似AWS S3的服务。要想生存下去，就必须找到比谷歌更低廉的运营成本。必须采取极端灵活且高风险的策略。我建议从核心问题切入：我们究竟需要多少个9的可靠性？能否在模型验证前承担风险？丢失猫咪视频和《超级马里奥64》全速通视频会产生什么后果？首套机械磁带库将是巨额资本支出。在联系IBM等供应商询价前，务必确保整个方案具有可行性。
“速通速捐”活动已为慈善筹集数千万美元。若他们想建立速通存档库，我猜筹集几千美元就能购置几十TB的NVMe存储设备。
YouTube每天接收70万小时的视频上传。这相当于每天新增4.3 PB的数据。你可能需要远超几十TB的存储空间… https://www.reddit.com/r/AskProgramming/comments/vueyb9/how_…
这是因为YouTube允许几乎所有安全内容在其平台上托管且不受任何限制。
我设想如果他们设置速率限制(例如每周每个IP仅限30GB)，那么上传到YouTube的垃圾内容、纯白噪音和诈骗视频数量将减少几个数量级。另一种策略是：若视频一周内未达到1000次观看量，则予以删除。
但他们无法垄断特定领域的70万小时内容，因此小型团队完全有能力与YouTube竞争满足自身需求。
> 若想与YouTube竞争，你必须在自有数据中心构建类似AWS S3的服务。要想生存下去，必须找到比谷歌更低廉的服务运营成本。
YouTube的规模经济远不止自建数据中心，他们在大多数ISP网络内部署了边缘缓存，在流量抵达谷歌数据中心前就完成分发。要在成本上与之抗衡需要惊人的投资规模。
有：Peertube、Odysee、Minds、Rumble、Bitchute(网页种子)…
这正是人们无法摆脱IG的原因。网络效应使然，而YouTube还拥有海量存储空间和带宽资源。
若不涉及内容推广，网络效应影响有限。机构只需在其网站添加链接即可。
我承认未深入研究Peertube，且认为Rumble并不比YouTube更优。其余平台尚不熟悉。感谢提醒，我会重新调研。
> 肯定存在类似IPFS的分布式解决方案
上网近25年，我始终无法从IPFS下载任何内容。难道需要博士学位才能操作？
海量存储的根本问题在于——它必然会遭大规模滥用。
儿童色情贩子、知识产权侵犯者、非自愿性内容传播者(“复仇色情”)、寻找窃取数据外泄渠道的恶意软件作者、宣传者与恐怖分子……滥用者名单既冗长又令人不寒而栗。
对于某些滥用类别的用户，任何存储服务都面临高风险。不同司法管辖区要求服务提供商必须以极快的速度和彻底的措施作出响应才能免责，有时响应时限仅为24小时甚至更短(如欧盟反恐立法)，有时则会对责任人处以巨额罚款甚至监禁。天啊，就连TOR出口节点提供商都遭遇过家中突袭、被警方拘留，甚至更糟的是面临刑事起诉和监禁——特别是涉及儿童色情材料指控时。而这些只是中转服务商，并非持久存储服务商。
更遑论基础设施供应商的风险。部分供应商会在你遭遇DDoS攻击时直接断网，另一些则会对流量收取天价费用(亚马逊/谷歌云/微软云就是你们)，足以让你个人破产。即便你愿意承担这些风险，仍需面对硬件成本的挑战——存储绝非廉价，20TB存储约需200欧元，若要实现冗余备份，实际成本将升至60-100欧元/TB，外加持续的电力和网络开销。
这正是为何你鲜少见到民主化进程的原因。
或许如此，但YouTube的使用体验实在糟糕透顶。肯定存在更优选择。
我总在电视上看到Photobucket的广告(我以为它已经倒闭了)，宣传免费或5美元即可获得1TB存储空间，具体取决于广告内容。
或许这家企业存在扩张机遇。
YouTube这种相对开放的特性，感觉真的是在借来的时间里勉强维持
首先投入资金打造用户真正需要的产品，积累庞大用户群。
接着开放平台接入第三方企业，让它们依赖你的平台盈利。
待用户锁定后，便榨取企业尽可能多的利润。
最后在平台衰败前榨干用户价值，直至它彻底失去存在意义。
你说的对大多数公司/软件都成立，但YouTube能在衰败前玩弄卑劣手段很长时间(如果真会衰败的话)。他们拥有巨大的护城河，挑战者需要海量资源才能抗衡，我认为没人有那样的耐心或资源去尝试。无论喜欢与否，我们都得忍受YouTube一阵子。
YouTube教会了我太多——只愿它能对创作者和用户更开放友好 🙁
眼下我们能做的，就是支持像https://nebula.tv/这样的小型替代平台
看起来这个运行时是用Rust编写的。Rust确实正迅速吞噬各类常用工具和库。像yt-dlp这类工具，能用单个编译二进制文件支持多种架构确实相当方便。
Deno本身主要用Rust编写，但同时也调用了[1]谷歌的V8 JavaScript引擎——该引擎采用C++开发。
[1]: https://choubey.gitbook.io/internals-of-deno/architecture/v8
我一直用yt-dlp下载字幕文件。有没有更简便的替代方案？估计没有吧。
> 迄今为止，yt-dlp都能通过内置JavaScript“解释器”[1]实现功能
哇，这既令人着迷又令人毛骨悚然。
编辑：稍作研究后发现：Deno的独立构建版本竟重达40MB(为什么？)，因此我理解他们试图规避这种情况的努力，并对此表示赞赏。
[1] https://github.com/yt-dlp/yt-dlp/blob/2025.09.23/yt_dlp/jsin…
照这趋势他们干脆直接捆个浏览器一起发算了哈哈。
开发工作量未免太大，干脆直接在浏览器里运行不就好了？现有扩展程序效果不错，比如Tubly下载器、Video DownloadHelper。
YouTube成了自己成功的牺牲品
我不提倡盗版，但从YouTube下载音乐似乎比用种子更容易，这着实令人惊讶。
谁能想到这么大的公司竟会助长盗版？
如果谷歌能为YouTube打造出最强大的搜索引擎，我愿意付费。我指的是对每段视频的每个词进行反向索引和语义索引，同时标注发言者并添加二级时间戳。我要能查询“维里塔西姆穿着蓝衬衫说数学的全部时间戳”。
YouTube才是真正的垄断者。创作者如同奴隶——既无法在其他平台变现，也不允许用户下载自己的内容。更可笑的是，没有广告拦截器根本无法忍受YouTube，而现在连拦截广告的用户都遭到流量限制。
这简直是垃圾场，却找不到真正替代品，真是可悲的现状。
为什么不能在别处变现？
> 问题在于(但并非无法克服)：当前内容受众规模缩小100倍，而赞助者数量却按比例保持不变，这使得可持续的内容生产缺乏便捷路径。
https://www.jeffgeerling.com/blog/2025/self-hosting-your-own…
https://www.jeffgeerling.com/blog/2025/self-hosting-your-own…
确实有创作者实现了转型，那些成功转向赞助或订阅模式的创作者似乎因此获得了更多满足感。但这种模式对那些已建立起稳定受众基础的创作者更为可行——而这些基础通常始于YouTube平台。若从其他平台起步，转型难度将大幅增加。
其他平台的受众规模要小得多，小得多，小得多。
倘若某平台用户规模扩大，全球政府必将联手将其拖入法庭，直至平台关停或卖给埃里森的儿子。
这场永无止境的逆流之战可有正式名称？反垃圾化运动？
清理奥吉亚斯牛栏。
北美时段内，批评谷歌的帖子竟能迅速从首页消失，实在令人惊叹。
不知他们能否利用Wasmer在后台无限制执行JavaScript。
这些下载YouTube视频的开源项目投入了惊人精力，尤其当YouTube不断破坏它们时。竟有近1500位贡献者参与
公平地说，yt-dlp支持的远不止YouTube
https://github.com/yt-dlp/yt-dlp/tree/master/yt_dlp/extracto…
几年前我确实下载过YouTube视频，当时很看重YouTube能记住播放进度这个功能。
但这简直一团糟，它总是不停崩溃。我或许该谦虚地归咎于自己文件太多，但更想被动攻击地怪罪于iPad版YouTube没有存储空间限制。
另一方面，我下载的许多精彩视频竟被远程清空了。气死我了
大家最近对jdownloader2有什么看法？天啊这东西还在用吗？
jdownloader2属于那种奇怪的许可模式，自称“开源”却找不到完整源代码。说实话比专有软件更糟糕。
我至今仍在用它下载YouTube视频。目前运行效果依然稳定。
所幸这场战役并非孤军奋战，许多AI公司同样需要下载YouTube视频。但他们应该更直接地赞助yt-dlp项目。
这项改动早就该实施了。yt-dlp与网页播放器长期存在兼容问题。
我拒绝在n270上网本上运行JS，更不接受专有许可协议。因此我将直接使用invidious镜像。
今早yt-dlp失效时吓了我一跳，但git拉取更新后已修复。
衷心感谢yt-dlp团队，他们的工作令人惊叹。
既然如此，不如直接启动项目重写计划，用JavaScript重构整个项目
Revanced万岁！
更多依赖膨胀，只为反混淆那些毫无价值的随机生成垃圾代码——这些代码毫无理由地日益复杂，其存在本身就毫无意义，恰如其创造者。
[已删除]
"2025年，YouTube开始推行名为SABR的新流媒体协议，该协议将视频拆解为多个小块，其内部URL会动态变化而非提供单一静态链接。这带来了严重问题：由于仅能识别格式代码18(这是唯一不使用SABR的可用格式代码)，导致yt-dlp等下载工具无法获取高于360p的YouTube视频。目前该问题仅影响网页客户端，因此可通过切换客户端(如尚未部署SABR的tv_embedded)来规避。例如在yt-dlp中添加参数–extractor-args “youtube:player_client=tv_embedded”即可启用该客户端。由于YouTube正逐步向更多客户端推广SABR，该变通方案的有效期尚不明确。"
https://wiki.archiveteam.org/index.php/YouTube/Technical_det…
感谢评论，楼主直接抛出“SABR”这个术语，好像我们都该知道它是什么意思似的。
抱歉，我看到这篇投稿(无人投票且即将过期)，便点赞并留言以为帖子会沉下去。但谢天谢地有人做了我本该做的事。
这与本文讨论的JavaScript挑战无关，而是视频流媒体领域一项非常特定的技术。SABR即“服务器端自适应码率”，是谷歌正在推进的定制化视频流协议，旨在取代现有的DASH协议。相关信息详见https://github.com/LuanRT/yt-sabr-shaka-demo
Wordle至少需要5个字母。
美国棒球研究协会跟这事有什么关系？
罗杰的偷袭？
发音是sabray
唉…Deno。自从他们开始向JS社区勒索资金，用来资助针对Oracle的公关闹剧，并引发后续的“最后机会”商标纠纷后，我尽可能远离它。
[已删除]
我清楚这个词的定义，所以才使用它。若你不同意我的用法，请解释为何他们的行为不构成敲诈。
事实是：他们利用平台影响力让6万人签署请愿书。
通过这份请愿书及随之而来的法律程序，他们将整个社区逼入绝境，将其包装成“最后机会”来获取商标权——而这完全是他们一手造成的局面。
他们单方面将此事定性为“最后机会”，却未曾征求他们声称代表的社区的任何意见。连OpenJS组织都未获知情。如今他们竟索要20万美元，声称独自推进难度极大，暗示若无此资金恐难成功。
这正是教科书式的敲诈：制造人为紧迫感，利用社群压力，以“目标将告失败”为要挟索取报酬。
有这样的“朋友”，谁还需要敌人？
这一切很快都将失去意义。你想看的内容都将动态生成。终结者时代已然降临。
那我想离线重温呢？
谁需要离线功能？
欣慰地看到老鼠仍在猫鼠游戏中占上风。说实话，我有点希望猫能开始占上风，满足我的好奇心。我预测如果YouTube真的禁止下载功能，支持下载的竞争对手会立刻走红。我想验证这个预言是否正确，除非谷歌真的开始获胜，否则别无他法。加油谷歌！我相信你！
我怀疑如果YouTube彻底封禁视频下载功能，很快就会涌现大量盗版组织和文件共享社区提供YouTube内容。
下载视频者本就是少数群体，针对少数群体永远无法实现指数级增长。更何况这群人很可能滥用广告拦截工具，想从这些白嫖族身上榨取一分钱都难。
> 针对少数群体永远无法实现指数级增长
服务小众市场是许多产品的绝佳起点，这在初创企业中更是公认的真理。其余观点我表示赞同。
我毫无要求，因为根本不用YouTube 🙂 替代平台多的是。
我哥发来YouTube上长篇演讲视频，苦苦哀求我听完。视频里全是坐在椅子上喋喋不休的头颅，根本没法看。但你不可能边听耳机里的音频边关掉手机——手机浏览器休眠后音频就会中断。所以我用yt-dlp抓取音频，导入Plex服务器用Prologue播放。这甚至不是为了避开广告，我只是想边干活边戴耳机听点东西，同时不用开着手机屏幕。
Firefox移动版有个扩展“Video Background Play Fix”，能禁用页面可见性API这个反功能特性。
在iPhone上，如果你使用浏览器而非应用程序观看YouTube(这是正确做法)，那么你可以通过以下步骤实现后台播放：播放视频→锁屏→解锁→重新播放视频→锁屏→解锁→使用媒体控制按钮继续播放→锁屏。
https://newpipe.net/
不客气
我关注的不是YouTube而是视频创作者。若想追的创作者未在其他平台发布内容，确实别无选择。
或许观看“推荐”内容时无需订阅存在替代方案(具体哪些？反正我列不出好例子)，但若观看订阅内容，你就必须依赖提供该订阅的平台。而且内容创作者并非可互换的。
这显然不是针对YouTube这个产品本身，而是针对YouTube这个内容库。我认为目前没有比这个内容库更优的替代方案。
感谢告知！
除非有人主动分享视频给你
有什么推荐吗？
Dailymotion、Vimeo等平台。无广告无垃圾信息，仿佛重获自由。即便它们改变，也总有其他平台取而代之。
但内容创作者只在YouTube发布视频时，你如何在Dailymotion和Vimeo观看这些内容？
我有个朋友用OBS录制了YouTube视频。她需要做些微调，录制时无法使用系统，但最终成功了。我告诉她必须停止这种行为，因为这侵犯了创作者的版权，更是对国家数字经济的侵害。自那以后她再没录过视频——至少我所知如此。我认为确保YouTube能合理获利是合理的，毕竟他们免费提供了存储和访问服务。
禁酒令时期Vine-glo葡萄浓缩液使用说明：“切勿将液体倒入此壶后封存二十一日，否则将酿成葡萄酒。”
我还有个朋友直接用手机录制YouTube视频。身为恪守法律的公民，我当即拍掉他手中的手机，并滔滔不绝地宣讲版权法如何奠定信息时代基石——这代表着未来，漠视它无异于对现代文明的亵渎。我逼他删光所有视频，还让他手写道歉信给YouTube创作者。虽然这些创作者不公开住址，但收到附有手写信扫描件的邮件时，他们肯定很感激。
我们那台老旧的SCSI扫描仪效率极低，扫描耗时几乎和手写信一样长。
说得好