✨ 增加 UP 主全视频、系列视频、个人收藏夹、个人追番下载支持

[SigureMo]

特性描述

基于 #47 ，增加额外命令 bilili-blabla（名字没想好），通过管道来给 bilili 提供前置参数

bilili-blabla https://space.bilibili.com/100969474 | bilili --overwrite --sess-data="xxxxx"

是否愿意为此贡献代码

先做完 #47 再说吧……还有一堆 issue 没处理呢

[dydhyhwu]

感觉追番这种功能放在命令行是不是有点不太不合适，职责有点复杂了。
建议是不是可以采用如下形式：

• bilili负责下载功能，提供有限的对外服务。
• 其他边缘业务功能交给独立的上游系统负责，比如自动追番等，上游系统底层依赖bilili的下载服务。

最近也在构思这一块子，想法完善后分享一下一起看看是否可行。我也来贡献贡献 嘿嘿

[SigureMo]

追番确实不太适合，你所说的“上游系统”，应该就是我当初所设计的 bilili-blabla 这种命令吧，通过 bilili-blabla 与 bilili 命令组合实现更多的功能（前者通过管道传输给后者）。后来考虑到复杂度什么的，我就暂时放弃了，打算 bilili1.x 维持现有架构，而 2.x 可能会做出改变。

其实近期我也在着手准备 2.x 了（新建目录了），目前暂定名为 yutto，yutto 的定位是支持多个子命令的，你可以看作是 bilili 与 bilili-blabla 的整合，只不过放在两个不同的子命令里了。分离成不同子命令也是防止仅使用 url 导致的语义不明确问题（比如 https://xxxx?p=2 这样的 url 我到底应该是只下载第二话呢还是应该把全番都下载下来呢？）

关于 yutto，我想尽可能地精简其功能，其中一个子命令应当只是单纯下载一个视频那种（比 bilili 更低级的操作），其他子命令会调用其下载逻辑。

最后，欢迎贡献，不过 bilili 还是算了，毕竟我自己现在都觉得难以维护了 😂，不过可以一起设计下 yutto 的架构

[dydhyhwu]

😁 我的荣幸，乐意之至。
这样看起来， yutto的最终目的像是分解粒度更细了？职责更加单一，最终通过组合能产生的效果也会更加强大。

我所构思的“上游系统”，一方面是类似bilili-blabla这种cli，其实更倾向一套比较大而全的业务系统（这个大是相对的），做成Web的，操作性上面应该会更加好一点？像追番这种操作，然后底层调用yutto去做下载，API请求结果也可以适当做缓存减少被ban的概率。

我先整理一下我的想法:smile:

[dydhyhwu]

2.x是准备用ts重写么？ 我先了解下技术栈。 😄 刚好最近在用ts

[SigureMo]

不不，我还是选择了 Python，TS 感觉还不太合适，如果不出意外的话，最后还是 Python，只不过不会使用多线程，而是会使用协程，暂时整体设计思路基于AsyncBilibiliDownloader，将暂时未按序到达的 chunk 暂存到内存的一个 Buffer 里，避免像 bilili 那样创建多个文件分块。但这样做也有不少问题，就是维持块的有序性消耗了大量 CPU 资源，同时在 Buffer 里的 chunk 也会占用不少内存资源。

另一个方案是更早一些尝试的 seek 方案，做了个简单的原型 mugyu（Deno + TypeScript），就是不断切换文件读写指针，以完成多个 Promise 协同工作的。不过这也必然需要维持一个文件状态文件以保证断点续传等功能。

最终采取哪种方案得看哪种效果更好了，暂时我是采用前者，如果其 CPU 与 内存资源占用量实在优化不下去的话我会再使用后者，不过估计也会是 Python 吧？

[SigureMo]

不过，不管哪个，2.x 都不用急，因为我想在 2.x 废弃源格式 flv 与 mp4 的支持以提高可维护性，但即便是现在，也有少数资源仅支持 flv，而不支持 dash，但这是必然趋势，毕竟 b 站 flash 播放器都下架了。

另外，想要超越 bilili 的稳定性，也是需要很长一段路要走的……

[dydhyhwu]

格式上，可以命令上先移除，对于那少数资源做降级。因为最终输出的还是MP4，中间格式用户应该是不需要去关心的。

[dydhyhwu]

技术栈没什么问题，这三种方案（算上bilili文件分块）各自有取舍，其实如果能隐藏分块的这部分不暴露给用户（比如隐藏cache文件夹，合成完后移动文件之类的操作），问题应该不大，从资源上应该也是比较理想的，毕竟不需要CPU去维护有序性，也不需要内存去做这个事。
不过最终还得看实际效果差距，如果很不理想的话只能逐个方案试了。

[SigureMo]

唔，格式我是在 yutto 就完全不打算支持 flv 的，因为维护起来太麻烦了，遇到不支持的就用 bilili 好了。

至于 bilili 那样的分块下载，维护成本实在是有点点高，一旦残留一两个块对用户也非常不友好，所以该方案只会在前两者都不太行的时候再试。

另外，我的想法是 yutto 虽然作为 bilili 的后继，但并不是直接将 bilili 覆盖那种，在很长一段时间内他们还会同时存在的（大概类似于 yarn 与 berry 之间的关系），所以关于兼容性的历史包袱我不想带到 yutto 这里。

这段时间比较忙，回复会不太及时。如果五一有时间把 yutto 的单文件下载做好的话，我就上传上来。

[SigureMo]

后续暂时在 #92 跟进吧，这里不是太合适了。