Video rebuffers? on seek in demo even cache option enabled about ksplayer HOT 9 CLOSED

这个功能是一个使用我sdk的开放者付费1000美元让我来实现的功能。为了保护他的权益。这个功能我会等到2个月后（5月25号）才会以半价的价格（500美元）出售给其他开发者。

from ksplayer.

I can't condone this kind of practice. The seek problem is a bug, not a feature. I'm going to reconsider my sponsorship, it's become nonsense.

from ksplayer.

@skrew @UnknownCoder807 @JeremTM93 @cdguy @v4to @djokt @anrtiger
因为我更新了赏金功能的流程，所以我重新询问了这个功能的赏金赞助商的意见，他是否愿意公开代码。他的结论是继续私有化。我完全理解他的这个决定。因为这个功能的代码已经不是完全属于我了，有部分是属于他的。所以我尊重他的决定。但是技术方案是属于我自己的。我为了澄清这个误会。我会在这边公开我的技术方案。任何人都可以拿这个技术方案去实现这个功能。

1. 继承AbstractAVIOContext 实现一个类 CacheIOContext。这个类的主要的工作是把网络请求下来的数据存到本地，然后每次读取数据的时候。根据当前的位置来判断是否可以用本地的数据，而不用去请求服务端。这个类的实现方式可以参考FFmpeg里面的cache.c。大体原理是差不多的。 https://github.com/FFmpeg/FFmpeg/blob/1f265aa91d6ce11fbf499ee867eae13bc7117e9d/libavformat/cache.c#L4
2. 重载 KSOptions的 open func process(url : URL) -> AbstractAVIOContext? 这个方法。返回上面实现的CacheIOContext就可以了。
   通过上面的技术方案。就可以看出整个方案是要新增代码，而不是改动原有的代码。所以可以判断出这不是一个bugfix。
   这个技术方案是基于KSPlayer的lgpl分支的。

from ksplayer.

Initially, the new options had to be available for sponsors?

So, if I understand, do we have to pay the sponsor + the options? It's becoming ridiculous.

from ksplayer.

Hi Kintan.

I can't hide my disappointment and my incomprehension when we compare your player on TracyPlayer and my favorite application on tvOS where its developer nevertheless pays to use your work 😔

from ksplayer.

这个功能是一个使用我sdk的开放者付费1000美元让我来实现的功能。为了保护他的权益。这个功能我会等到2个月后（5月25号）才会以半价的价格（500美元）出售给其他开发者。

What @skrew says is true. this is a bug and not a "extra diamant plus premium" feature to purchase.

Seeking back during live .ts can be done with the MPV player for almost a decade.

It is a real disappointment to charge developers for a feature that is basic in every player.

from ksplayer.

我明白大家的意思。这个争议的关键是

1. 那些功能是一个播放器的基础能力，
2. seek不够快这个是不是一个bug。
   正常seek都是要要往服务端重新请求数据的，所以都会有一定的耗时。所以我的理解这不是一个bug。原因如下：
   我可以先说下我这个cache的原理是怎么样的。我的cach是把用户通过网络下载的内容存在本地。然后往后seek的话，就会命中本地的文件，不用重新去请求服务端了。所以开启了cache就会导致seek速度很快。如果你往前seek 1分钟的话，你会发现seek的耗时还是会慢的。因为需要走服务端的请求。

另外赏金赞助商一开始悬赏的功能点是 想要实现在直播的时候，可以进行回退查看几分钟前的视频片段。他当时提的时候。我这个播放器是没有这个功能的，并且我也不知道mvp他们有支持了这个功能，所以这个是付费的，并且我优先实现了他的这个功能。目前开启cache可以快速seek是这个赏金赞助商提的这个功能带来的一个附加功能。如果想要在实现快速seek的话，就会导致需要把这个付费功能的代码给公开了。
所以我们接下来可以讨论对于赏金功能的流程是怎么样的。
我认为应该是要让赏金赞助商来决定这个功能是要直接公开到lgpl分支，或是需要后续的人也进行付费。这个可以在提出悬赏的时候进行明确。大家有什么想法也可以提出来。

from ksplayer.

这个项目的开发版本和闭源版本都会有技术支持。对于bug或是crash的技术支持都是免费的。但是对于参数配置，或是功能使用上的一些疑问，是需要收费。有两个收费方式：

1. 单次技术支持收费50美元。
2. 持续每个月捐赠30美元以上(这个跟LGPL的捐赠是分开的)

大家可以提功能改进或是新功能，我会按照自己的优先级先在LGPL版本免费实现，后续才会合入到GPL。如果开发者有功能定制的诉求，或是希望某个功能被快速实现，那开发者可以跟我提赏金功能，流程如下：

1. 赏金赞助商跟我提功能要求，把具体的功能点列出来。我会初步确定哪些功能点可以实现。并会提供技术方案给赏金赞助商。
   1. 赏金赞助商可以决定自己实现这个功能，这时只要支付技术支持的费用即可。
   2. 赏金赞助商也可以选择让我来实现实现功能，那我就会根据工作量来确定费用。费用一般是500美元到5000美元。
2. 赏金赞助商接受报价的话，我就会进入开发。
3. 功能开发完，我会把功能集成到我的APP，赏金赞助商可以在我的APP体验功能。
4. 赏金赞助商确定功能点没有问题的话，通过Github进行付款。
5. 为了保证赏金赞助商的权益，赏金赞助商可以选择代码私有化还是公开。
   1. 私有化的话，我会把相关的代码通过邮件发给开发者，并且我需要等两个月才能以半价的价格把代码出售给其他开发者。
   2. 公开的话我会把代码合并到KSPlayer， 其他开发者可以免费使用。
6. 新的功能开发都是基于KSPlayer的LGPL版本进行开发的，并且在经过两个月左右会合并到GPL版本。功能私有化的话那只会在KSPlayer里面存在少量代码例如接口协议。

from ksplayer.

@v4to 我用其他的方案优化了seek的能力。目前向前15s和向后15s的seek不会有加载过程了，这个能力在lgpl分支是公开的。

from ksplayer.