Nyakku Shigure
Nyakku Shigure
不不，我还是选择了 Python，TS 感觉还不太合适，如果不出意外的话，最后还是 Python，只不过不会使用多线程，而是会使用协程，暂时整体设计思路基于[AsyncBilibiliDownloader](https://github.com/changmenseng/AsyncBilibiliDownloader/blob/master/asyn_downloader.py)，将暂时未按序到达的 chunk 暂存到内存的一个 Buffer 里，避免像 bilili 那样创建多个文件分块。但这样做也有不少问题，就是维持块的有序性消耗了大量 CPU 资源，同时在 Buffer 里的 chunk 也会占用不少内存资源。 另一个方案是更早一些尝试的 seek 方案，做了个简单的原型 [mugyu](https://github.com/SigureMo/mugyu)（Deno + TypeScript），就是不断切换文件读写指针，以完成多个 Promise 协同工作的。不过这也必然需要维持一个文件状态文件以保证断点续传等功能。 最终采取哪种方案得看哪种效果更好了，暂时我是采用前者，如果其 CPU 与 内存资源占用量实在优化不下去的话我会再使用后者，不过估计也会是 Python 吧？
不过，不管哪个，2.x 都不用急，因为我想在 2.x 废弃源格式 flv 与 mp4 的支持以提高可维护性，但即便是现在，也有少数资源仅支持 flv，而不支持 dash，但这是必然趋势，毕竟 b 站 flash 播放器都下架了。 另外，想要超越 bilili 的稳定性，也是需要很长一段路要走的……
唔，格式我是在 yutto 就完全不打算支持 flv 的，因为维护起来太麻烦了，遇到不支持的就用 bilili 好了。 至于 bilili 那样的分块下载，维护成本实在是有点点高，一旦残留一两个块对用户也非常不友好，所以该方案只会在前两者都不太行的时候再试。 另外，我的想法是 yutto 虽然作为 bilili 的后继，但并不是直接将 bilili 覆盖那种，在很长一段时间内他们还会同时存在的（大概类似于 yarn 与 berry 之间的关系），所以关于兼容性的历史包袱我不想带到 yutto 这里。 这段时间比较忙，回复会不太及时。如果五一有时间把 yutto 的单文件下载做好的话，我就上传上来。
后续暂时在 #92 跟进吧，这里不是太合适了。
> 希望添加一个参数选项：只下载音频流或视频流。例如： bilili [url] -s audio 嗯，这个实现应该不难，只是这个生成格式有什么建议吗，这个也用 `.mp4` 就没必要了 :joy: > 音频流也有不同码率档位，如果能细分就更好了 这个我得考虑下怎么来调整，有什么建议吗，额外加一个参数这样？ `bilili --audio-quality=xxx`
好哒～之后我试试～
之后我会采用 PR 的形式来添加这两个功能，由于我对音视频相关不是太了解，能否麻烦你进行 review，有问题尽管提出
嗯，有看到你有对 ffmpeg 相关研究的 repo 你看 #35 这里现阶段实现的音频调节是否可以
好的多谢，之后我什么时候再实现单一媒体流再来麻烦你～
其实 ts 的合并不需要 ffmpeg 的，直接顺序合并成 mp4 就行