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)。这意味着每次有 depth>0 时，该 buffer 都会被多释放一次：入队时持有 ref=2（RefAdd），末尾 Release 降到 ref=1，但 depth 队列里的 Release 再降到 ref=0，导致 buffer 被提前回收；下游 VENC 读到已被复用的内存，造成图像损坏或崩溃。非 depth 路径（depth==0）不受影响。
   建议：在 depth 分支结束后用 goto 或结构调整跳过末尾的无条件 VB_ReleaseBuffer(ulV2dBuf)，只在 depth==0 时执行该释放。

2. [中等] mpi/vi/vi.c:VI_SetChnFrameRate / VI_GetChnFrameRate 并发写入无保护
   VI_SetChnFrameRate 直接写 pstBufCtx->stFrameRateCtrl 和 u32FrameRateSeq，同时 push_task 线程在持续读取并递增 u32FrameRateSeq，两者之间没有任何锁或原子操作。在通道运行期间调用 Set 会产生数据竞争，导致 seq 计数错乱，帧率过滤行为不可预测。原 K1 实现（al 层）也存在同样的字段，但 MPI 层此前通过 plugin ops 间接访问，不存在这个裸访问路径。
   建议：复用已有的 depthLock 或新增轻量 spinlock，在读写 stFrameRateCtrl/u32FrameRateSeq 时加锁。

3. [中等] al/vi/k1/vi_k1.c 删除帧率过滤后 K1 帧率控制完全失效
   diff 将 K1_VI_HandleNormalCallback 中的 K1_VI_ShouldKeepFrame 调用直接删除，而 K1 的 set_chn_framerate plugin op 也已被 MPI 层的新实现替代（VI_SetChnFrameRate 不再调用 g_pViOps->set_chn_framerate）。K1 的 stFrameRateCtrl 字段仍在 al 层 ctx 中存在但永远不会被写入，且回调里不再有任何过滤逻辑，导致 K1 平台帧率控制完全失效——无论用户设置何种帧率，K1 始终全速输出。
   建议：在 K1_VI_HandleNormalCallback 中恢复帧率过滤，或在 MPI push_task 的帧率过滤路径中确认 K1 buffer 也走该路径；若 K1 的帧率控制已整体迁移至 MPI 层，需确认 K1 的 dequeue 路径确实经过 mpi_vi_push_task，并删除 al 层冗余的 stFrameRateCtrl 字段以避免混淆。

备注：

• sample_vi_k3_4venc_bind.c 中 g_stop 为 volatile int 而非 _Atomic 或加 memory barrier，在多核 RISC-V 上存在可见性风险，但作为 sample 代码影响有限，属于非阻塞问题。