Proposal: Windows版&通用改进

[songbirdzz]

1. 可改变窗口大小 (Windows)
2. 可在视频播放页面拖动窗口 (Windows)
3. 重构数据结构，允许分集存储播放进度，历史、追番与首页列表解耦 (Common)

[Predidit]

前两个问题很难解决。

第一个问题，改变窗口大小会导致布局混乱，很多地方的设计不是响应式的。

第二个问题也很难解决，只有 scaffold 中的 appbar 会响应鼠标拖拽事件，但是这种 appbar 无法使用 stack 叠加在其他 widget 上方。如果不叠加的话，非常不美观。

第三个问题感觉可以考虑，但是也不是那么有必要？ 我觉得这个部分本来就不应该解耦的。解耦的话，当首页列表更新时，需要同时维护三个表中的数据，且这三个表的数据重叠度很高，非常不优雅。

[songbirdzz]

关于第三个，返回的link非常适合当成主键，所有东西通过link进行关联就好了，并不需要同时维护三个表的数据。 前两个不好解决的话... 开个V2.0? 这样还可以顺便把弹幕和视频源interface化。

[Predidit]

如果通过 link 关联的话，不就类似于现在的做法吗，还是耦合的。

关于完全重构的 V2.0 的话，如果你有兴趣的话，可以创建一个组织，我们共同来维护。

不过我的想法是不做 anime1 的第三方客户端了，anime1 缺乏番剧元数据，这非常制约我们的具体实现，我们没有办法做美观的番剧列表，没有办法做分类搜索，没有办法做界面友好的番剧详情，没有办法做评分，也没有评论区。

这个客户端的上限也大概就是这样了，因为 anime1 的功能匮乏，并且我们没法解决。

我觉得我们可以换一个视频来源来尝试。

或者以 Bangumi 的开放API为主，加入视频源，效果应该也会很不错的。

[Predidit]

不过我不建议开 第三方漫画阅读/轻小说阅读 的坑，已经有很多功能完备的前辈了，例如 wenku8x 。

带弹幕的第三方番剧客户端现在应该还是有需求的。

其他流行的第三方番剧客户端的弹幕功能似乎都有些问题。

[songbirdzz]

我想的是不固定视频源和弹幕源，写个interface之类的东西然后想加就可以加。

比如主页是bgm获取的数据，点进具体番剧后把可用的视频源列出来。例：https://github.com/open-ani/ani

不过这个是基于种子的，我们接的是视频源。但视频源可能有的问题是可用的太少。

[Predidit]

我也有这样的想法。

通常的想法应该是，从 bangumi 获取排行榜与目录，查看番剧详情时遍历支持的接口。

其实无非是番剧元数据的问题，感觉元数据与实际视频来源的脱节是不可避免的。

[songbirdzz]

匹配的话不那么精准应该也无所谓，用户应该会有容忍度。

不过我看了一下，问题可能主要是API。我看了几个在线的网站，对数据和API都有一定程度的保护，也有跑路的风险。要做这方面工作的话可能工作量会很大。

[Predidit]

这和国内视频站点独特的生态也有关系。

他们的资源都使用大型互联网公司的 CDN 服务的漏洞进行托管，以解决带宽成本问题。

很多情况下，他们本身可能也不清楚具体的利用。

看上去有相关的从业者向他们提供闭源的一站式服务，包括适配于各种主流 CMS 的闭源播放器和相关插件。

这种 API 不仅利用起来非常复杂，而且经常变化。这也是本项目选择台湾的 anime1 的原因，本来最开始本来想用 AGE 的。

一个可能的想法是把接口插件化，这样可以有更多的人参与，维护成本可能会稍微好一点。

[songbirdzz]

应该很难... 倒不是插件化难。 我今天抓了一下樱花动漫的包，发现他们是用.ts文件传的视频数据。要是想对接的话肯定要自己写代码去处理视频数据。如果只需要提供api的url应该很多人会愿意维护，但多了这个步骤应该就只有很少的人愿意写了。

[Predidit]

问题不在这里。

这种是 m3u8 视频流， media_kit 可以较为容易地处理。

话说现在真的 樱花动漫 是哪个啊，仿品也太多了。

刚刚随便找了一个，他们的 m3u8 居然是没有鉴权的。

[songbirdzz]

哦 这样。对编码不太了解。 用的是 https://m.iyhdmm.com/ ，在这里找的。 不过就算解决了这个也只是一个源... 用别人的数据就是不爽

[Predidit]

用别人数据是这样的。

但自己维护服务器肯定是不合适的，无论从成本还是版权角度。

[songbirdzz]

研究了一下另外一个网站，感觉也不是不行🤔

[Predidit]

以 anime1 的 1500 长度的动画列表为例，预估我们需要一台储存在 5TB 左右，带宽在 500 M 以上的服务器。

可能还需要考虑 DDOS 的问题。

很明显为了摊平相关成本，我们需要加入广告。

这就是完全的商业化路线了，和普通的动漫影视站点并没有本质的区别，而且版权会有很大的问题。

[songbirdzz]

没，我指的是抓别人的。

毕竟是盗版网站，鉴权也都相当弱。只要设计得好的话，适配应该也不难。

[Predidit]

主要还是接口不稳定。

不过这也是我认为最理想的结构， Bangumi 元数据 + 多视频源。

[songbirdzz]

很多在线的网站可能也都是同一个模板套出来的，所以接口应该不会区别太大。

另外就是我认为通过设计，应该可以把复杂度限制在adapter里，不会影响其他部分。

[Predidit]

听上去不错。

分叉 https://github.com/open-ani/ani 进行尝试会是个好主意吗。

[songbirdzz]

我没仔细看那个代码，但应该是专门针对种子下载设计的，直接拿来用可能不太合适，还是从头开始写最轻松。

[Predidit]

元数据基于 bangumi 的话。

我们首先要实现一个类似于 bangumi 第三方客户端的东西。

从头开始也可以，但是这个项目感觉仍然是不错的参考。

[songbirdzz]

API稳定的话能写代码解决的都不算问题= =

再说想象了一下应该也没有很难？