feat(vi) k3 support framectl && rotate Function

[mingjie-wu-spacemit]

feat(vi) k3 support framectl && rotate Function

[spacemit-robot-ci]

Robot CI AI Review

• PR: feat(vi) k3 support framectl && rotate Function #12 feat(vi) k3 support framectl && rotate Function
• Project: components/multimedia/mpp
• Commit: b574dfdafb46

结论：发现 3 个需要处理的问题。

发现：

1. [严重] mpi/vi/vi.c:~295 V2D 输出 buffer 在 depth 路径下存在双重释放
   SYS_SendFrame 之后调用了 VB_RefAdd(ulV2dBuf)，入队 depth 队列，最后再调用 VB_ReleaseBuffer(ulV2dBuf)。如果 SYS_SendFrame 内部不持有引用，这个末尾的 VB_ReleaseBuffer 会立即把 ref 降回 1，之后 depth 队列里的 VB_ReleaseBuffer 再次释放，导致 use-after-free 或双重释放。反观非 V2D 的 depth 路径（diff 下方原有代码）同样先 SYS_SendFrame 再 VB_RefAdd 再入队，但没有末尾的额外 VB_ReleaseBuffer。V2D 路径多出来的 VB_ReleaseBuffer(ulV2dBuf) 应删除。
   建议：删除 depth 分支之后的 VB_ReleaseBuffer(ulV2dBuf)（continue 之前那行），与非 V2D depth 路径保持一致。

2. [严重] mpi/vi/vi.c:~560 mpi_vi_destroy_chn_buf_ctx 提前销毁 V2D pool，致 V2D buffer 泄漏
   新增的 VB_DestroyPool(pstBufCtx->ulV2dOutPoolId) 在 MPI_VI_DestroyOutBufPool 之前执行，但 V2D 输出 buffer 通过 VB_GetBuffer 从该 pool 分配、在 push_task 中持有（已出队但尚未被消费者释放）。直接销毁 pool 不等待所有 buffer 归还，会导致 push_task 线程中仍在访问的 buffer 被提前回收。此外 pool 销毁前没有重置 ulV2dOutPoolId = 0，若 destroy 被二次调用会重复销毁。
   建议：在销毁 pool 之前先确保 push_task 线程已停止（已有 bTaskRun = false + join 逻辑，确认 destroy 在 join 之后），并在 VB_DestroyPool 后将 ulV2dOutPoolId = 0。

3. [中等] mpi/vi/vi.c:~830 VI_SetChnFrameRate 并发写 stFrameRateCtrl 无锁保护
   VI_SetChnFrameRate 直接写 pstBufCtx->stFrameRateCtrl 和 u32FrameRateSeq，而 push_task 线程在 mpi_vi_should_keep_frame 中并发读这两个字段，中间没有任何锁或 _Atomic。在多核环境下结构体赋值不是原子操作，可能读到撕裂值，导致帧率控制逻辑错误或序号跳变。
   建议：复用已有的 depthLock 或新增专用 spinlock，在写 stFrameRateCtrl/u32FrameRateSeq 和读这两个字段时各自持锁。