请求单个任务多订阅源及多视频版本支持 about albireo HOT 12 CLOSED

@lordfriend
基本所有设备都支持了，网页可以用hls.js
转码非常耗费cpu， 刚开始的时候把所有都切片hls了，但是后来发现效率太低了，常年cpu 500%
然后做了份统计，在～11万份文件内只有9.5%是需要转码的格式(avi, mkv - mkv chrome可以直接播放)
后来就混用了hls和mp4，转码的时候先检查视频和音频编码尽量使用copy参数，压力就大大减轻了

from albireo.

If Chinese is not your native language, let me know and we can discuss in English.

from albireo.

多个订阅源一直是支持的，只不过章节状态是一次性的（即一个章节状态为下载完成之后就不会再处理了）。如果你想让每个章节有多个视频，需要手动添加额外的视频源，多视频源播放需要Web版2.8.0+

from albireo.

你说的多订阅源是指得比如 bangumi.moe 和 dmhy.org 分别订阅一份么？我希望能实现单个站点进行多个不同 Tags 的订阅。
另外，有没有考虑通过一种逻辑实现自动下载多个不同版本呢，比如在两个订阅源分别过滤结果是生肉和熟肉，那么就可以实现第一时间上线生肉，有熟肉后自动添加熟肉。我觉得这个功能会很方便。
具体逻辑如果感兴趣可以进一步讨论。

from albireo.

你说的这个我考虑过，不过因为现有架构的局限，不太容易做，现在不少周边功能依赖episode的状态，所以必须很多东西都重写才行。以及我们这边磁盘空间紧张，也不想保存多个版本。

还有一个现实就是字幕组经常会断更，你锁定一个字幕组也不太容易一直锁定下去，如果先出了某个版本，那么后出的版本被人观看的概率就小很多，所以基于以上的推论我们这边把这个重构放到很低的优先级上。

from albireo.

多個視頻源根據列表中順序優先選擇默認？或者用戶選擇優先順序？不過源太多了，存儲的成本會高很多吧。

from albireo.

其实存储的空间完全不是问题，我们假设所有番都是季番，每个视频 650M ，那么我们每季存储 8 个新番，每个新番存储 2 个版本同时保留一年，那么只需要占用 500G 的存储空间。
另外还有一个问题，作者说现有的很多东西依赖章节状态所以不好改，但是要知道字幕组为了修正错误而发布 V2 版本是很常见的事情，现有的章节任务逻辑并不能自动更新视频到 V2 版，我认为这是一个不小的问题，所以现有的章节状态逻辑实现有必要修改。
后一个问题如果合适可以另开 issue 讨论。

from albireo.

1. 我们一个季度有35个左右的新番，还有5-10个左右的日剧
2. 假设新建一个单独的任务表，每个番組可以可以建立多个任务，任务自己的状态要从章节里获取，那么当章节（增减的时候）任务要怎么做，当删除一个任务的时候，要删除所有之前下的吗，如果从季度中间添加一个新的任务（这是很常见的，因为某个组突然弃坑，或断更），之前的章节要怎么处理。这些要增加非常多的管理员UI的逻辑，让问题很复杂。最后还是主要是因为作为一个在线的看番和管理系统，比起多个源，多个字幕组，我们更在意更新速度。现在我们面临一些其他问题比如字幕组提供一些不兼容的格式可能需要转码，而且我目前也没有多少时间去重写一些底层逻辑。
3. v2版这个不好判断，我们并没有那么好的自然语言识别能力。

from albireo.

以及以后开新issue还是尽量别用中文了吧

from albireo.

存储两份视频带来的优势不足以抵消成本呢，2017年大概总共有2700话，每个视频 650M就是1.7T
按照aws 0.26，每年总共$400，按照递增增长，大概$200

from albireo.

@lordfriend 转码我用其他方案搞定了，在nginx上面做非mp4格式用ffmpeg推rtmp到srs切片hls，然后分发到边缘cdn

from albireo.

@kslr 之前看过一个类似的方案也是把各种视频转码成切片的mp4，可以直接用HLS或DASH。不过我播放器要大改，以及第三方客户端不知道是不是能直接支持，他们倒是都用的ExoPlayer，据说是可以支持的。
但我看的方案nginx-vod大概比较费cpu

from albireo.