联咏平台(Novatek) | 走廊模式切换流程优化

1 问题

  切换走廊模式，约5s后才会有画面变化。等待画面变化时间比原来的版本时间要长 3-4s，影响客户体验。

2 分析

1. 关于走廊模式切变得流程
     1、联咏官方给出的 Demo 的流程是 stop_venc -> set_venc -> start_venc
     2、自己编写的流程是 stop_vprc -> stop_vcap -> stop_venc -> set_venc -> start_vprc
   -> start_vcap -> start_venc

2. 自己代码关于切变走廊模式的流程的解析
     自己代码的视频数据流如下图1所示：
   
     自己代码中的 stop_venc 和 start_venc 的流程是用来切变视频参数使用的，需要做到 Vcap、Vprc、Venc 三个模块统一参数，所以在 stop、start 的流程中会将三个模块全部 stop 之后再全部 start，以确保三个模块的参数统一。
     剖析开来解释这块流程，Vcap 与 Vprc 采用的是 Direct 模式，如果要 stop Vcap 模块，就要先将 Vprc 模块所有的通道 stop。

3. 深挖切变走廊模式耗时根因

1、为什么之前的版本中，切变走廊模式耗时短(约 1s)？
在 TVT_libsdk 的代码中，stop_vcap(0) 的时候，会先 stop_vprc_0_out_1、stop_vprc_0_out_2、stop_vprc_0_out_0、stop_vprc_0_out_4，这样的流程中，遗漏了 vprc_0_out_5 没有被stop，直接导致 stop_vprc 和 stop_vcap 的流程全部失败。在TVT_libsdk 设计的流程 stop_vprc -> stop_vcap -> stop_venc -> set_venc -> start_vprc -> start_vcap -> start_venc 中，真正被执行的只有 stop_venc -> set_venc -> start_venc。误打误撞执行了联咏官方 Demo 中的正确流程。

2. 为什么当前的版本中，切变走廊模式耗时长(约 5s)？
在我发现代码流程中因为遗漏了 vprc_0_out_5 没有被stop，导致 stop_vprc 和 stop_vcap 的流程全部失败之后，我就补充上了 stop_ vprc_0_out_5，使得整个流程被完全正确的执行。那么在切变走廊模式的时候，全部流程就被完全走完，耗时较长。如果能判断是切走廊模式，按 stop_venc -> set_venc -> start_venc 流程，耗时是正常的 1S，验证通过

3 措施

  摸清切变走廊模式耗时较长的根本原因之后，就可以从根本上解决这个问题。重新增加只会 stop_venc 和 start_venc 的函数，在判断为切边走廊模式操作时，调用新的 stop_venc 和 start_venc 函数，使得切变走廊模式的流程跟联咏官方给出的 Demo 的流程一致。

4 测试

  反复切换正常模式和走廊模式，均在等待1S左右改变画面，修改有效。

5 总结

  流程规范化、代码标准化、完整注释等行为，对我们以后的工作有极大的帮助，驱动代码也应该遵循一个准则：通用化、简单化、标准化、接口化。