哔哩下载姬downkyi：DASH音视频合并与批量下载去水印边界

1. 先把这件事想明白视频为什么要“下”下来1.1 一个朴素到不能再朴素的需求我做内容整理这些年遇到过最多的一类提问不是“怎么写代码”而是“这段视频我能不能存到本地慢慢看”。场景无非那么几种通勤路上网络不稳想把课程缓存到平板里做剪辑时需要一个参考镜头得反复逐帧拖拽给家里的老人找几段戏曲电视机顶盒连不上再或者自己投稿的视频想留个原始档。这些需求说大不大说小也不小但真要去手动一条条保存体验很差。哔哩下载姬 downkyi 就是冲着这个场景来的。它是个开源桌面工具界面朴素功能直给贴链接、选清晰度、批量排队、自动合并把网页上拆成好几段的音视频数据拼成一个能直接双击播放的本地文件顺带把字幕、弹幕、封面一并收下来。标题里说的“5 分钟搞定批量下载与去水印”前半句不算夸张——装好之后批量拉一整个合集确实就是几分钟的事后半句得掰开讲因为“去水印”这件事的真相和大家想象的不太一样后面我会专门用一节说清楚。这篇文章写给两类人一类是纯新手只想尽快把视频存下来不关心底层原理另一类是想搞清楚工具边界、甚至打算自己改源码的开发者。两种人都能在这篇里找到东西我会把操作步骤、参数取舍、踩坑记录全摊开写。1.2 音视频分离这件事绕不过去很多人第一次用这类工具会懵明明下载完成了文件夹里躺着两个.m4s文件一个特别大一个特别小双击谁都播不了。这不是工具坏了这是现代视频平台的通用做法。主流平台早就放弃了“一个 MP4 装下所有东西”的老路子改用DASHDynamic Adaptive Streaming over HTTP分发。简单说服务器把一条视频拆成两路流一路只有画面video track一路只有声音audio track然后按时间切成若干小分片segment播放器边下边播根据你的网速动态切换清晰度。这个设计对平台友好对带宽友好唯一的不友好就是——你直接存下来的东西是“半成品”。所以任何靠谱的下载工具都必须干两件事把两路流分别完整拿下来再用音视频处理工具把它们封装回一个容器里。downkyi 内部集成了 ffmpeg 来干这活这也是它安装包体积不算小的原因之一。理解这一点后面所有的报错你都能自己推断出方向播不了 合并没成功没声音 音轨没下到或没合进去只有声音 视频轨缺失。1.3 什么人适合用什么人不适合说句实在话工具没有万能的。downkyi 适合的是需要批量处理、需要保留原始画质、需要字幕弹幕封面、能接受一个 Windows 桌面软件的人。它特别适合整理系列课程、番剧合集、UP 主整套投稿这种“一次要几十上百个文件”的活儿。它不太适合的是只想偶尔存一条、不愿意装软件的人浏览器插件或者在线解析更省事用 macOS 或 Linux 的人这类桌面工具的原生支持基本是 Windows 优先其他系统要么跑虚拟机要么找替代方案以及对命令行有强需求、想塞进自动化流水线的人虽然有社区脚本但官方形态是 GUI。还有一个必须提前说的边界下载下来的东西怎么用比怎么下更重要。自己离线看、做笔记、剪个学习视频片段这些都是合理范围二次上传、搬运、商用、去掉作者信息重新发布那就是另一回事了。工具只提供能力不提供授权。这一条我会在全文反复提醒因为它比任何技术细节都关键。2. 整体设计拆解它凭什么能做到批量又快2.1 技术栈的选择逻辑这个项目是用C# .NET写的界面基于 WPF。第一次看到这个技术选型我其实有点意外——这类工具用 Python 或 Electron 的更常见。但仔细想想很合理WPF 做 Windows 原生界面控件齐全写复杂表单清晰度、编码、命名模板、任务队列特别顺手.NET 的多线程和异步 IO 成熟处理几十个并发下载任务不会太吃力而且打包成自包含可执行文件后用户端不需要额外折腾环境。代价也很明显跨平台基本没戏安装包体积偏大首次运行可能缺运行时。这就解释了为什么你在发布页会看到两种包——一种是依赖系统已装 .NET 运行时的“轻量版”一种是自带运行时的“独立版”。新手我强烈建议直接拿独立版省掉“双击没反应”这类排查。提示如果你的机器上装了多个版本的 .NET偶尔会出现版本冲突导致启动闪退。遇到这种情况优先用独立版别去折腾环境变量。2.2 下载链路的核心分片、并发、断点续传downkyi 的下载引擎干的事情可以拆成四步我按实际执行顺序讲第一步是解析。你贴进去的链接可能是BV号、av号、番剧的ep/ss号、某个 UP 主的空间地址、收藏夹地址甚至是“稍后再看”。工具要先把这些入口翻译成一个个具体的视频 ID再逐个去请求元信息标题、分P、时长、可用清晰度列表、可用编码列表。这一步决定了后面能不能批量——你贴一个合集链接它内部其实展开成了 N 个任务。第二步是取流地址。每条视频会返回一组候选流按清晰度、编码、码率排列。工具根据你的设置挑一条视频流、一条音频流拿到带时效签名的地址。这里有个坑签名有时效任务排队太久会失效所以大批量任务建议分批跑别一次挂五百个。第三步是分片并发下载。HTTP 支持 Range 请求工具把一个大文件切成若干块并行拉取每块单独记录进度。这就是“断点续传”的基础——中断后重新打开已完成的块不会重下。并发数可以调这是影响速度最直接的参数但也不是越高越好后面会讲怎么定。第四步是合并与收尾。所有分片落地后ffmpeg 介入把视频轨和音频轨按时间戳对齐封装。封装用的是-c copy模式也就是不重新编码只搬容器所以几乎不消耗 CPU速度取决于磁盘读写。这一点很多人不知道以为合并很慢其实一条一小时的视频通常十几秒就完事。2.3 “去水印”到底去的是什么这是全文最需要说清楚的一节因为标题里这句话最容易让人产生误解。平台在视频画面上叠加的那一小行标识是转码时烧进画面的不是浮在上层的一个图层。不存在什么“关掉开关就没了”的操作。那这类工具里的“去水印”选项是怎么实现的行业里通常有三种做法downkyi 走的是第一种第一种选不带标识的流。平台对不同清晰度、不同编码的流处理策略并不完全一致部分高码率流的画面边缘是干净的。勾选相应选项后工具会在候选流里优先挑这类版本。这是最“无损”的方式因为它压根没改动画面。第二种画面裁切。把边缘一小条裁掉标识自然消失代价是分辨率变小、构图被切。有些工具提供这个选项。第三种区域覆盖或模糊。用一块色块或模糊遮住观感最差一般只在没有其他办法时用。所以正确的预期是这个功能能不能生效取决于你要下的那条视频本身有没有干净版本不是所有视频都能去掉。有些老视频、低清晰度源全系带标识那就没办法。另外我必须强调即便技术上能拿到干净画面也不代表你有权把它当成“原创”传播出去这个界限别踩。2.4 为什么内置 ffmpeg 而不是调用系统环境有人会问为什么不直接让用户自己装 ffmpeg 然后配环境变量原因很实际普通用户配环境变量这一步能劝退一半人而 ffmpeg 版本差异会导致合并行为不一致老版本对某些 HEVC 流的封装支持有 bug。内置一个固定版本等于把变量锁死出问题好复现。代价是更新滞后。如果你遇到某个新编码格式合并报错去发布页看看是不是该升级工具了而不是自己换 ffmpeg。我试过一次手动替换内置 ffmpeg 想支持新格式结果封装出来的文件时间戳错乱音画不同步折腾半天还是退回原版。这个位置不建议自由发挥。3. 五分钟上手从零到第一批文件落地3.1 获取与安装三个容易卡住的点去项目的开源发布页找最新的稳定版本别贪新去拿测试版。发布页一般会给几个压缩包命名里带with-runtime或类似字样的就是自带运行时的完整包体积大一些但省心。下载完解压到一个纯英文路径下比如D:\Tools\downkyi不要放在桌面、不要放在中文目录、不要放在带空格的路径里。为什么这么强调路径因为合并阶段要调用外部进程参数里带中文路径时某些系统区域设置下会出现编码错乱表现就是“合并失败”但没有任何有用报错。这个坑我踩过排查了两小时才发现是路径问题。第二个卡点是杀毒软件。这类工具要读写大量文件、调用外部进程、发起高频网络请求行为特征和某些不受欢迎的程序高度重合被误拦是常态。如果解压后发现主程序不见了或者合并总是失败先去隔离区看看。第三个卡点是首次启动的初始化。有的版本会在首次运行时检查 ffmpeg 是否存在缺了会提示你手动放置。按提示操作即可别跳过。3.2 首次配置登录、路径、并发三件事定调打开软件后别急着贴链接先把三件事配好后面能省很多麻烦。登录。扫码登录你自己的账号登录态会缓存到本地配置里。为什么必须登录因为未登录状态下接口返回的清晰度列表是被阉割的通常最高只给你到 360P 或 480P你会以为工具坏了。登录后能拿到 1080P 甚至更高具体到哪一档取决于你账号本身的权益。登录信息只存在本地工具本身不上传但你在公用电脑上用完记得清缓存。保存路径。建议单独建一个盘或者目录专门放视频别和系统盘混在一起。原因有二一是缓存文件未完成的分片也在这个目录下体积可能是最终文件的一到两倍二是大批量任务时磁盘 IO 很密集跟系统盘抢资源会影响整机响应。并发数。这个参数在设置里通常叫“同时下载数”或者“分片线程数”。默认值一般比较保守。我的经验值是普通宽带、单条任务同时下载 3 到 5 个、单任务分片 8 到 16 比较稳如果你的网络出口本身有限速调太高反而会因为频繁超时重试导致整体变慢。调参的正确方法是先跑三条任务看总速度再往上加加到速度不再上升甚至下降就退回来。3.3 单条视频完整走一遍配置好了贴一条链接试试。流程是这样的复制视频页面地址粘贴到工具的解析框点解析。稍等一两秒界面会列出视频信息标题、分P列表、可选清晰度、可选编码、可选音质。选择你要的清晰度。如果列表里只有低清晰度回去检查登录状态。选择视频编码这一项后面单独讲怎么选。勾选需要的附加内容封面、字幕、弹幕。字幕要注意部分字幕是自动生成的质量参差人工字幕更准。确认保存路径和命名点下载。观察任务列表。下载阶段是分片并发你会看到进度条走得比较快但可能卡在 99%——那是在合并正常现象。合并完成后去目录里看应该是一个.mp4或者你选的容器格式加几个附属文件。双击能正常播放、有声音、进度条能拖就算成功了。这里插一句判断标准能拖进度条。如果拖动后画面卡住或者音画分离说明封装有问题通常是音视频流的时间基没对齐得换合并方式。3.4 批量下载把“一整个合集”变成一堆任务这是这个工具真正的价值所在。批量入口通常有这么几个多P视频解析后列表里会展开所有分P全选即可。番剧/课程合集贴ss或者合集地址会展开整季。UP 主空间贴空间地址能列出该 UP 主的投稿列表可以按时间范围或者数量筛选。收藏夹贴收藏夹地址展开全部内容。稍后再看登录后可以直接拉取。批量任务的关键是分批。我的习惯是一次不超过 20 到 30 条跑完一批再下一批。原因前面说过流地址有时效排队太久会集体失效然后你看到一片红色报错重试又得从头来。分批虽然多点几次但整体成功率高一截。另外一个细节批量任务里的命名模板一定要先设好。默认命名可能是“标题 ID”如果同一批里有重名分P会变成(1)、(2)后缀后期整理很痛苦。模板里带上分P序号和清晰度文件一看就懂。4. 参数取舍清晰度、编码、音质怎么定4.1 清晰度和账号权益的对应关系这是新手最容易困惑的地方“为什么别人能下 4K我这里最高只有 1080P”答案很简单清晰度档位和账号状态绑定。平台对高码率内容做了分层未登录、普通登录、有权益的登录看到的候选列表完全不同。工具只是把你账号能看到的东西列出来它不会凭空变出更高画质。所以遇到“清晰度不全”先排查顺序是是否登录 → 登录是否过期 → 账号本身有没有对应权益 → 该视频是否本身就只上传了低清版本。还有一种情况视频页面显示 4K但工具列表里没有。这通常是编码问题——4K 可能只有 HEVC 或 AV1 版本如果你的设置里把这两种编码屏蔽了列表自然就少。去设置里把编码选项放开。4.2 AV1、HEVC、AVC选哪个这三种是当前主流的视频编码同一清晰度下平台可能同时提供多个版本。选择逻辑看你的用途编码体积解码兼容性适合场景AVC (H.264)最大几乎通吃老设备老播放器都能放要拷到电视、老平板、剪辑软件里用HEVC (H.265)中等比 AVC 小约三到五成近几年的设备基本支持老设备可能黑屏自己电脑看兼顾体积和画质AV1最小较新部分播放器需更新剪辑软件支持一般长期归档、只在自己主力机上播放我的实际做法归档存 AV1 或 HEVC需要二次编辑或外发的存 AVC。剪辑软件对 AV1 的支持至今不算完善导入后可能只有声音没有画面转码一次又损失画质不如一开始就下 AVC。同清晰度下不同编码的画质差异肉眼在正常观看距离下很难分辨别在这上面纠结太久。真正影响观感的是码率而码率是跟清晰度档位走的。4.3 命名模板现在多花两分钟以后少整理两小时命名模板是我认为最被低估的一个设置。默认命名往往只有标题一旦批量下载同一个 UP 主的内容你会得到一堆看起来差不多的文件找起来抓瞎。我用的模板思路是序号 分P名 清晰度 日期。序号保证排序稳定分P名保证可读清晰度方便判断要不要重下更高版本日期方便按时间归档。具体的变量写法每个版本略有差异以界面上给出的变量提示为准一般都能找到“标题”“分P”“UP主”“清晰度”这类字段。注意文件名里不要出现\ / : * ? |这些字符Windows 会直接拒绝写入。有些标题里带英文冒号或者问号工具一般会自动替换但如果你自定义模板时手动加了这些符号就会批量失败。模板设好之后建议先拿三条视频试跑确认目录结构和文件名符合预期再放批量任务。这个“先小后大”的习惯能避免大量返工。4.4 字幕、弹幕、封面要不要一起收这三样东西的价值因人而异我说说我的判断。字幕如果是人工字幕非常值得存尤其是外语内容或者有大量专业术语的课程。存下来的格式通常是结构化的文本文件需要转换才能被普通播放器识别工具箱里有对应功能。自动生成的字幕准确率一般但聊胜于无做检索用还行。弹幕这个看用途。做二创、做数据研究、想还原“原汁原味”的观感可以存。存下来是结构化文本需要转成字幕格式才能在播放器里显示转换后还要装对应字体否则会出现方块。如果只是自己看弹幕意义不大还占体积。封面这个我基本都勾上。做资料整理时一个封面图能让文件夹预览直观很多比看文件名快。三样东西加起来体积很小建议全勾。唯一要注意的是批量任务时如果某条视频没有字幕工具可能会报个警告属于正常情况忽略即可。5. 常见问题排查我踩过的坑都在这5.1 高频故障速查现象最可能的原因处理办法双击程序没反应缺 .NET 运行时 / 被拦截换自带运行时的完整包检查隔离区下载完只有画面没声音音轨未下到或合并失败看目录里有没有独立音频文件检查 ffmpeg 是否完整合并失败无报错路径含中文或特殊字符挪到纯英文短路径重试清晰度最高只有 360P未登录或登录过期重新扫码登录大批量任务集体报错排队过久流地址签名失效分批重跑一次别挂太多下载速度极慢并发设置过高导致重试 / 本地网络限速先把并发调低试再逐步加合并后音画不同步手动替换过 ffmpeg / 文件本身异常恢复内置版本重下该条文件名超长写入失败Windows 路径长度限制缩短保存路径精简命名模板弹幕转字幕显示方块缺对应字体安装字幕文件里声明的字体5.2 几个容易被忽略的坑缓存目录的清理。未完成的任务会在保存目录下留分片文件这些文件不会自动消失。跑过几轮大批量之后你可能会发现磁盘莫名其妙少了几十 G。养成习惯任务列表里清空已完成的记录再去目录里手动删掉残留的临时文件夹。有些版本在设置里有“自动清理缓存”的开关打开它。磁盘空间要按两倍算。一条 2G 的视频下载过程中分片 合并后的成品同时存在峰值占用接近 4G。批量 20 条的时候你得留出足够余量否则会出现“合并到一半空间不足”的尴尬情况分片还在成品没了。登录态过期是静默的。它不会弹窗提醒你“登录已失效”只会默默把你降级到低清晰度。所以当你发现批量任务的清晰度突然全变成 480P第一反应应该是重新登录而不是怀疑视频源。不要同时开两个实例。配置文件和缓存目录是共享的两个实例同时跑会互相踩表现为任务状态错乱、文件被覆盖。想多开就复制一份整个程序目录用不同的保存路径。长时间挂机注意电源策略。系统休眠会中断网络连接醒来后一堆任务超时。挂大批量之前把电源计划调成高性能或者干脆设置成不休眠。5.3 长视频和大规模任务的稳定性处理一小时以上的长视频出问题的概率明显高于短片。我的处理方式是先单独跑不混在批量队列里。长视频分片多、耗时长混在队列里会拖慢整体节奏而且一旦它失败你得在一堆成功任务里翻找。其次把它的优先级调低如果工具有这个选项或者放在最后跑。有些工具支持任务排序把大的往后放能避免它占着并发槽位让一堆小文件干等。再者长视频合并阶段内存占用会上来尤其是高码率 4K。如果机器内存吃紧别同时开其他重负载程序。我试过一边合并 4K 一边跑编译结果合并进程被系统杀掉分片全在但成品没有白等半小时。最后跑完立刻验证。别等下完一百个再统一检查那时候你都分不清哪个是坏的。验证方法很简单随便拖几个时间点看画面和声音对不对得上看文件大小是否合理一小时的 1080P 通常在 500M 到 1.5G 之间明显偏小就是没下全。6. 工具箱与延伸这个软件还有一半功能你没用6.1 内置工具箱的实际用途主界面之外这类工具通常带一个“工具箱”面板功能看着零散实际很实用音视频合并 / 分离手里有独立的视频轨和音频轨时手动拼或者把一条成品拆出音轨做音频素材。字幕格式转换把下载下来的结构化字幕转成通用字幕格式方便播放器加载或者导入剪辑软件。弹幕转换转成字幕格式配合字体在本地播放器里还原弹幕效果。视频号互转在不同编号体系之间换算处理老链接时用得上。我用的最多的是分离功能——做片子的时候经常只需要背景音或者某段环境声把成品拆一下比重新下音频轨快得多。手动合并的命令其实很简单理解了这个你就明白工具在后台干了什么ffmpeg -i video.m4s -i audio.m4s -c copy -movflags faststart output.mp4-c copy表示不重新编码直接搬容器-movflags faststart把索引信息挪到文件头这样边下边播或者网络播放时不用等整个文件加载完。这两条加起来就是“合并”的全部秘密。6.2 用脚本做下载后的整理批量下完之后最烦的是整理。文件名不统一、有重复、想按 UP 主分类。写个小脚本处理比手动快一百倍。下面这段是我常用的整理脚本扫一个目录把文件名里的编号提取出来重新归类顺便统计一下总时长和体积import os import re import shutil from pathlib import Path SRC Path(rD:\Downloads\videos) DST Path(rD:\Library) pattern re.compile(r\[(BV[0-9A-Za-z]{10})\]) def human(n): for unit in [B, KB, MB, GB]: if n 1024: return f{n:.1f}{unit} n / 1024 return f{n:.1f}TB total 0 count 0 for f in SRC.rglob(*.mp4): m pattern.search(f.name) tag m.group(1) if m else untagged target DST / tag target.mkdir(parentsTrue, exist_okTrue) dest target / f.name if not dest.exists(): shutil.move(str(f), str(dest)) count 1 total dest.stat().st_size print(fmoved {count} files, {human(total)})这段代码没什么花哨的但能解决“下完一堆文件散在目录里”的问题。你可以按自己的命名规则改正则比如按 UP 主名归类、按日期归类。核心思路就是文件名里只要有稳定的标识就能自动化归类这也是前面强调命名模板的原因。6.3 从源码构建什么情况下值得折腾如果你只是想用永远不需要碰源码。但有两种情况值得看看一是你发现某个小功能不顺手比如想加一个下载完成后自动执行的钩子二是你想在别的平台上跑。构建流程大致是装 .NET SDK → 拉代码 → 还原依赖 → 构建 → 发布。听起来简单实际会卡在依赖还原上因为这类项目往往引用了若干第三方库网络环境不好的话会反复失败。我的建议是先在能正常构建的环境里跑通一次再考虑改代码。上来就改出了问题你分不清是自己的改动还是环境问题。改代码之前先想清楚一件事你要改的部分是不是核心链路。下载解析、合并封装这两块改错的代价很高容易产出能播但音画不同步的文件。界面、命名、导出逻辑这些外围部分改起来风险低很多。从外围入手别一上来动核心。6.4 合规边界写在这部分最后工具越好用越需要把边界说清楚。下载下来的内容你自己离线看、做笔记、做学习研究、剪一段不超过合理引用范围的素材这些都在正常使用范畴内。但有几件事别做不要二次上传到任何平台冒充原创不要去掉作者信息后重新分发不要拿去做商业用途不要大批量抓取后打包售卖。这些不是“技术问题”是授权问题工具帮不了你。另外一个容易被忽略的点别对平台造成压力。并发拉到几十上百、一天抓几千条这种行为既不礼貌也容易触发风控最后受影响的还是你自己。适度使用工具才能长期可用。7. 我个人用了两年之后的几点体会最后说点零散的、文档里不会写的东西。第一个体会是这类工具的价值不在“下”在“整理”。真正省时间的不是下载那几分钟而是命名模板、批量队列、字幕封面一起收这些设计让你事后不用花几小时归类。所以别跳过配置环节那才是效率的来源。第二个体会是遇到问题先看目录结构。工具报的错经常很含糊但你去保存目录里看一眼——有没有.m4s残留、有没有半截的.mp4、临时文件夹里分片是不是完整的——答案基本就出来了。文件系统不会骗人界面会。第三个体会是参数别迷信“最高”。最高清晰度不代表最适合你AV1 体积最小不代表你的设备能播并发拉满不代表下载最快。找到一个和自己设备、网络、用途匹配的配置然后固定下来比每次调参划算得多。第四个体会也是我最想说的这类开源工具的生命周期取决于使用者的克制。你正常用它就是好工具你滥用它就会消失。这个道理放在任何工具上都成立。我这些年换过好几款类似软件最后留下来的都是那些“够用、稳定、不折腾”的而不是功能最花哨的。下载这件事本身没什么技术含量难的是把一件小事做得让人愿意长期用下去。