前阵子，交易略有阶段所成。分享了这个事物给周边的朋友，以此启发做个blog。

近一年多来，一直让人持续着迷，探索与实践的一个想法：货币市场策略挖金。

一句话介绍就是：算法辅助的货币金融交易。 流行叫法也可称，基于机器学习图表模式的交易算法辅助。

这真的是个很有吸引力的事物，让人越了解越喜欢的感觉。因为涉及话题范围较多，也不好一两句话说清，就用工程师思维提取这个事物的几个特点。

这也是我学习探索总结下来，非常推崇货币市场的几个根本原因。

1、大数规律的根基：跟随超大体量的国家纸面资源流动，不是赌场那样久赌必输的大数规律，也不是不成熟股票市场割韭菜的零和游戏。根本上，顺遂整个人类生产活动的〔好事〕。这个顺遂作何理解，犹如远古人类狩猎，顺遂提供弓箭。现代货币运行，则借贷货币给农场主，购买肥料和机器，提高种植效率获得更大收成。

2、开放的交易策略，开源的交易历史评判：上点简说了货币市场也是长远生产行为。再加上现代货币制度，允许享受货币膨胀的纸面财富扩张。所以允许建立开放的掘金策略，开源的交易历史测试。所以，完全可以建立一个『互利交易社区』，挖掘有交易能力的人或算法进来交易，也挖掘有闲散资金的人进来委托交易。。（外话，资金数量级越大，开放策略有效性减弱，成负相关）

3、创新的信号捕捉：上面提到机器学习图表，还有算法交易。这也是我们程序员喜欢这事物的关键原因。使用算法交易、机器学习 k 线形态、策略历史回测辅助策略效益， 都是很有趣有价值的玩法。历史发展原因，在国内应该还是比较少。

4、简单遵循『效率即收益』法则。实事求是的原则，交易水平、算法辅助的质量直接作用收益率。成绩有无，效益有无，都是一目了然。

随着深入了解，会有进一步感觉，这个货币市场的基础设计非常耐人寻味，是越了解越喜欢。同时还是有着开放开源的基础。

最后再附注这段时间几个总结和交易曲线。

一段交易心历的阶段[总结文集]

mw20170303

LearningLoop：[笔记、理论、手册、总结]

1、[笔记、理论、手册] …从经典入手，勤于打基础loop。 2、[学习，训练，思考] …交易日志。

功夫在诗外：小得在勤奋在磨砺，大成靠顺道靠天时。

磨一把刀：杰出的心性，也是探索一种交易哲学。

博采众长，开放求是：交易方法论为根基。

运转模型：资本流动性规律的一些经典运转模型。

budda

整理了一下笔记，回顾 Evernote 发现以前针对技术小点的学习探讨笔记。较实用的。可快速掌握知识点且良好实践同步，分有四步，

  • 1、基础知识点收集；
  • 2、关键知识点理解；
  • 3、场景试验；
  • 4，要点List总结

比如之前和同事探讨 block 与 retain cycle ，还有 GCD复习时都是用这个思路，使用了这个方式。

引子：

半年前搞的HJY云导播项目，因为有个多流直播且流组合切换的特殊需求，从 vlc 摸索折腾到Vitamio sdk,七牛直播 sdk，金山云 sdk 等等，到回归 ffmpeg和 ffplay还有基于 ffplay 的 ijkplayer，经历了一段蛮揪心的视频播放技术探索。回过头来，都有点生疏了细节，不过主干的思想和直播化改造ijkplayer的过程还是值得做个回溯的。

音视频base：

  1. 音视频入门，可我之前总结的 《入门启发：音视频的简单理解》
  2. 里程碑1=>熟悉 FFMpeg，可参考 《FFMPEG详解》
  3. 里程碑2=>熟悉 VLC,可参考《VLC架构及流程分析》、VLC 官网具完整文档、vlc模块化思路是其架构核心《VLC 关键模块结构分析》
  4. 里程碑3=>熟悉 ijkPlayer，到这一步就更了解移动音视频 sdk 了。可参考《ijkPlayer 系列分析》
  5. sample_cmd1 #:** ffmpeg -i rtmp://live.hkstv.hk.lxdns.com/live/hks ** 了解音视频文件的繁杂参数群。
  6. sample_cmd2 #:** ffplay rtmp://live.hkstv.hk.lxdns.com/live/hks ** 了解音视频解码、同步、渲染的过程。

简要回顾：

  1. 这里ijkPlayer播放器是一个包括iOS、Android两个平台的播放器。
  2. ijkPlayer是Bilibili网址基于FFmpeg的简易ffplay播放器来进行开发的。相比于更有名的VLC播放器，ijkPlayer更精简，代码量更小，更方便改造。
  3. ijkPlayer 的 c 层内核是ffplay 。而ffplay又是 ffmpeg 的一个使用示范。ijkplayer 最重要的意义就是在根据平台来硬解码的优化。
  4. 三条关键 pipe：ijkPlayer的初始化流程，音频文件读取流程(网络流读取)，音频解码与视频解码和音视频同步渲染流程。这里面就主要有 三层 cache，读取 cache，解码 cache，渲染 cache。参考下图取自《VLC架构及流程分析》。
  5. 《入门启发：音视频的简单理解》 E、F 部分。

pic

主要目的：

移动视频直播的需求，一般比较重视的特性和目的，

  1. 规避花屏、规避弱网卡顿。只是视频播放最基本的要求了，特别是直播中视频质量息息相关着创收的钱袋子。
  2. 直播的秒开。不要太高估用户的耐心，也不要低估产品追求最极致的用户体验的决心。
  3. 直播的低延迟。既然直播，互动性占据很大的有趣重要程度。所以以前以视频稳定播放为第一，现在转向了最低延迟播放为第一追求。

分支特性：

特性的实现，也都是为着上方的主要目的来的。

  1. 规避花屏、规避弱网卡顿。这点得综合的处理了。规避『花屏』的出现，其实就是在『录制端、中转端、客户端』三处对视频 I、B、P帧编码解码时做『纠错性处理』，不至于出现找不到关键帧 I 的导致花屏。至于卡顿，移动直播在复杂的网络情况下确实难以避免，只能在技术层面动态调整，在『帧率、码率、分辨率』参数间做出折中方案，另外当网络实在糟糕了，则才去优先音频传送，视频画面冻结的思路。
  2. 直播的秒开。思路是，a最快拿到第一帧 I帧，b最快将第一张画面渲染到屏幕。这就需要服务器一侧将 gop 进行缓存，在连接建立时第一时间给到。也需要播放端最快获取、解析、渲染上这张画面。所以客户端也需要在几处逻辑中对缓存进行特别的『优先』操作。
  3. 直播低延迟。服务器和客户端同时优化多级缓存中的默认时长。其实具体实现时，还需要考虑在网络平均质量、缓存的稳定效率与紧追效率间做出一些折中方案的选择。
  4. 紧追效率。这点金山云直播 sdk 应该是最早做到的。从它的 sdk 注释，以及侦测它的缓存市场参数，可以知道它是采用『维护最佳缓存』方案，就是在 cache 过多时，最快消耗掉缓存，达到紧追视频发生源时间的目的。

github地址：

https://github.com/limbo0312/ijkplayer-liveYY

原文 on evernote:《回顾&总结：ijkPlayer 直播特性分支 》