一些小小的问题和请求

[bug333555]

issue 内容

用了一段时间的1.4.5的重构后的播放器，感觉目前应该已经没有什么需要完善的了吧？
就是还有一些小小的问题，已经有人帮我提过了，其中就是反向搜索循环bug #456
以及希望可以关闭播放器内部错误的提示，这个也有人提过了 #462
我也就没遇到什么问题了，剩下遇到的问题我估计大概是我的8.1.0安卓系统的手机实在是太老古董了不管是处理器还是系统都是，有点带不动这个新版的播放器。
我在硬件解码的情况下，随便点进一个番，然后启动3倍速播放，播放一小会之后，会出现严重的音画不同步，而且无法通过拖动进度条来重置，只能重新进入番，即使是2倍速也会有略微音画不同步，音画不同步的情况下通常都会有画面卡顿以及音频断断续续的情况。
我不确定这是bug，还是说是我的手机太老古董导致的，所以我现在暂时回退回了1.4.5之前的版本，再怎么说之前的版本硬件解码的情况下怎么加速播放，都不会出现这种卡顿。

（这条是额外的请求：能否添加回原本能做到的 播放器倍速+长按屏幕倍数 的这种加速方式叠加？这1.4.0这个版本仍然可以做到之后的就做不到了，这两个倍数叠加之后，倍数可以来到7.5倍速，我有时候需要用到这个，所以我暂时先回退到了1.4.0这个版本，我希望可以把这个叠加的加速方式添加回来！）

提交前确认

• issue 列表中，没有我的新功能需求 / 问题

[Predidit]

倍速播放导致的音画不同步是一个 bug

问题应该在播放器底层，我看看怎么修

[Predidit]

@bug333555

https://github.com/Predidit/Kazumi/actions/runs/12270297071/artifacts/2303937653

尝试这个构建，应该修复了音画不同步，以及搜索循环

[bug333555]

@bug333555

https://github.com/Predidit/Kazumi/actions/runs/12270297071/artifacts/2303937653

尝试这个构建，应该修复了音画不同步，以及搜索循环

@Predidit

我用了这个构建，其中3倍速音画不同步的bug并没有被修，只是变得不怎么严重了，画面不再有卡顿，音频也不再断断续续的，但仍然是音画不同步的，并且也依旧无法通过拖动进度条来重置，反向搜索循环修复了。
2倍速的音画不同步修复了。
另外还出现了其他的小bug，比如播放器的那个全屏按键无法使用了，原本点一下全屏按键之后就会自动全屏，但现在没效果了，只能通过横着手机来全屏。

[Predidit]

@ErBWs

iOS 模拟器中有全屏问题吗

[ErBWs]

没有

[bug333555]

@Predidit

这里再补充一点，我忘记说了，3倍速导致的音画不同步，现在可以通过切换回1倍速拖动一下进度条后来重置
我说的无法重置是3倍数音画不同步的情况下，拖动进度条无法重置3倍速自身导致的音画不同步
3倍速切换回1倍速后无法自动恢复音画不同步的问题，必须要拖动一次进度条

[ErBWs]

（这条是额外的请求：能否添加回原本能做到的 播放器倍速+长按屏幕倍数 的这种加速方式叠加？这1.4.0这个版本仍然可以做到之后的就做不到了，这两个倍数叠加之后，倍数可以来到7.5倍速，我有时候需要用到这个，所以我暂时先回退到了1.4.0这个版本，我希望可以把这个叠加的加速方式添加回来！）

@bug333555 关于长按倍速被固定是因为之前 iOS 有大于 2.0 的播放倍速会导致比例错误，我在修改提交 PR 的时候发现如果按照播放器速度相乘会导致 0.25 长按会只有 0.5 的速度，所以我就模仿 B 站的行为改成了长按默认某个倍速，然后松手再回到对应的倍速

[Predidit]

我觉得现在的行为是符合预期的。

也许我们可以添加更多的倍速选项。

[bug333555]

@bug333555 关于长按倍速被固定是因为之前 iOS 有大于 2.0 的播放倍速会导致比例错误，我在修改提交 PR 的时候发现如果按照播放器速度相乘会导致 0.25 长按会只有 0.5 的速度，所以我就模仿 B 站的行为改成了长按默认某个倍速，然后松手再回到对应的倍速

@Predidit

唔…这样呀，那也就只能多添加点倍数选项了呢

顺便我来问个问题，曾经的旧版播放器，在软件解码的模式下，在某一些网站的播放源中没有3倍速仅有2倍速的情况下，使用播放器强制启用3倍速后，虽然也会出现音频比画面快的情况，但只要切换回正常的2倍速或默认倍速，音频和画面就会自动对齐，乃至于连拖动进度条都不需要。
似乎重构后的播放器做不到的样子？

而硬件解码则是从来没出现过音画不同步的情况，所以没有例子，仅有软件解码这么一个例子

[Predidit]

原来的硬件解码实现是 android 自带的 ExoPlayer 组件，很完美，几乎不会有问题，除非硬件支持有缺陷 (比如华为某些vulakn驱动有问题的设备) 软件解码是 fvp

现在软硬件解码都是 libmpv

具体在 Android 上的实现是 wid ，也就是嵌入窗体(视图)，而不是其他平台上的 Render API

所以在 Android 平台上，我们和 mpv 的行为是几乎一致的

问题差不多来自 mpv 本身，而我并没有能力解读和修改 mpv 的源码

我们只能通过调整音频输出设备来尝试解决问题，就像我前面做的那样

Q: 那我们为什么要切换到现在的实现呢

A: 原来的实现在 windows/ios/macOS 上有无法忍受的缺陷

Q: 我们可不可以只在 anroid 上回退到原来的实现呢

A: 理论上可以，但是我并不像那么做，那样非常非常麻烦

[bug333555]

@Predidit

这么看来，旧版播放器反而是更优的选择，可惜不好解决软件解码播放过长时长的番剧的卡进度的问题。

另外，能否只在安卓的设备上让硬件解码调用 ExoPlayer 组件？
软件解码可以不动，仅仅只是调用组件