本页导航
前言
感谢你对kplayer的支持。在经历几乎快一年的时间，发布了0.5.0 的版本。它的改变并不带来功能性上的增加，但是我们认为达到如何让kplayer更好用的目的，这些改动是值得的。
核心设计
在0.5以下的版本，它是一个缺少设计感的工具。在新的版本中，我们做了一下几个大的改动
- 更改技术选型
老版本在易用性上不太便捷，这一部分原因取决于技术选型。众多第三方库的c++支持版本过于老旧或者它并不在现代c++上被完美的支持并且迭代周期会有额外的库处理开销。 所以我们考虑核心的编解码、插件、事件消息使用c++来实现,并由c++14的标准提高到c++17。功能解耦了大部分模块以便于更好的支持多线程编解码。它带来的好处也是显而易见的，现在的kplayer可以完成预编码推流，不需要同步进行等待资源帧实时解码等待推流。这在低配机器或者突发性能的机器上会更有成效
这带来的好处将会加快用户交互类的体验迭代进度，将kplayer变得更加用户友好。
- 更安全的插件
0.5版本以下的插件机制依靠动态链接库功能实现。它有相当大的不便捷性与安全隐患。
动态链接库实际上还是各平台的代码编译实现，依赖操作系统提供的加载与符号寻址机制。这导致不同平台下需要编译多份插件，例如windows下为DLL，linux下为so。还区分64与32位架构区别，这对插件开发者是极不友好的。意味着它们需要分发多份插件来达到跨平台的使用的目的，而且面对不同平台架构需要做代码的适配性调整和麻烦的调试环境的准备与排错
之上的问题仅限在使用与开发方式上的区别。而动态链接库还可以带来的问题就是安全隐患问题，我们并不要求kplayer的插件提供方必须开放源代码来共享插件的具体实现。如果使用动态链接库来执行插件实现的话，面临的问题就是使用者并不了解插件的内部实现机制。这很容易对你的机器造成不可预知的印象。例如可以开启一个线程对你的机器进行全盘文件扫描并且插件可以随意使用任何操作系统提供的API，这将对插件的使用方造成很大顾虑。不得不放在一个无隐私的空白机器上来执行使用它。这也是为什么插件的开发文档迟迟未曾到来的原因，因为它是不可控可能会造成重大隐患的。
v0.5.0版本，我们使用的新的插件机制。我们引用了wasm作为新的虚拟机执行引擎。它的到来解决了以上的两个大难题，插件开发者只需要编码与编译一个实例，把跨平台的问题交给kplayer，一次编译，随处使用。降低了插件的开发难度与调试难度。同时通过wasm的机制，我们可以严格控制每个插件的可访问行为。在无授权的情况下，它并不能访问任何关于你机器上的任何数据。你可以放心的使用它而不必担心会存在恶意插件或者您的机器数据被插件篡改的情况产生
目前kplayer开放给插件的权限仅限为判断kplayer的home目录下某个文件是否存在（判断插件依赖的资源文件是否初始化）、获取系统时间戳（提供打印实时时间功能）两个系统级别API。它被严格控制在可以被允许的范围内。在未来，会开放更多的API以及网络资源的请求来提供给更丰富的插件完善所需的功能，但是我们认为用户有权利了解插件它可以被允许做某些事情。为此在开放这些API之时，会为用户提供一份插件的已注册功能列表以供用户参考插件将会被允许访问你机器上的何种资源，便于使用者是否选择使用它。
你可以使用你熟悉的任何语言来编写插件，只要它符合wasm标准。目前更推荐你使用rust或者c++来编写我们的插件。为了简化开发细节，我们提供了rust的crate包sdk来帮助你如何快速开发你想要的插件。文档将会在之后推出。
- 更安全稳定的服务
0.5.0以下会连接API服务来获取插件等资源文件的初始化下载，这是阻塞并且会影响到使用进程。在新版本这一问题将得到改善，提供更稳定的API服务并且有重试次数来提供容错性。不只是在稳定性方面，同时服务端与客户端采用了双向认证SSL加密，确保不会被不可信任的客户端加入到服务端请求以及客户端接收到的结果被遭遇中间人攻击导致使用不可信的插件或者资源。
- 代码开源
kplayer的golang封装已开源到github中，你可以在当前网站的顶部找到它。它可以帮助你了解更多kplayer的内部实现细节。如果你喜欢本项目，欢迎你给我们的开源项目提供一个star
特性清单
- 拆分编解码逻辑与业务交互代码，使用golang来实现业务层面
- 优化插件加载机制，提供更快速安全的插件
- 默认配置文件由yaml更改至更加友好的json格式
- 提供全新的cli命令来更快捷的控制
- 更改reustul api为jsonrpc
- 提供websocket来监听发生的一切事件消息
- 延时推流，提高低配机器推流效率
- 多线程优化
- 修复不稳定API请求中断的问题
- 更稳定安全的API接口功能与认证
- 添加srt推流协议的支持
待添加功能
- 支持硬件加速