在iOS和安卓中拖动进度条到已缓存位置时会重新发起网络请求

[happyjack111]

在iOS和安卓中拖动进度条到已缓存位置时会重新发起网络请求 网络质量较低时会体验很差，您是否会考虑增加这方面的功能？实际上问题是在seek的时候ijkplayer的request不会管是否有缓存

[befovy]

是的， seek 的时候 Bilibili/ijkplayer 确实是直接放弃当前缓冲数据，重新从网络连接中读取数据的。 我会考虑在这一部分进行 seek 操作优化： 1、内存中已经下载到 packet queue 中的数据丢掉 seek 时间戳之前的音视频内容。 这个只能优化 seek 时间戳增长方向。 2、研究文件协议层缓存方案，这样的话两个方向的 seek 都能优化。

如果有其他建议，欢迎一同讨论。 @happyjack111

[happyjack111]

是否可以通过网络请求代理的方式来实现“缓存的快速读取",也就是说所有发往网络的请求都经过代理中转，这样用户seek的时候实际上也能快速返回。

[befovy]

是的， ijkplayer 中提供了 cache 协议，你可以研究一下。 参考 https://github.com/bilibili/ijkplayer/issues/4069

[happyjack111]

您是否打算在fijkplayer中实现seek缓存，个人是服务端程序员，对于移动端一片迷茫

[befovy]

@happyjack111

根据我目前的精力，我打算把 ijkplayer 中实现的协议 ijkio ffio cache 等进行分析，如果本身就支持 seek 缓存最好，我会给出具体的使用方法。 如果少量修改能够使其支持 seek 缓存，我也尽量改一下。 如果是需要完全重新实现，那我估计没这个精力。

[befovy]

想加缓存的话可以看看 bilibili/ijkplayer/issues/4188

[eveinzz]

拖动进度到已缓存位置会重新请求，缓存还是需要优化，对点播型应用影响大。

[deepface1990]

点播强需求，什么时候能解决下么@befovy

[aimin987]

这个问题解决了吗？我测试了一下seek还是卡了很久

[firstmetcs]

#557

[firstmetcs]

https://github.com/bilibili/ijkplayer/issues/4684#issuecomment-502653262 @befovy