[mingjie-wu-spacemit]

Summary

• Pause new capture dequeue requests while a channel flush is in progress.
• Wait for an in-flight dequeue to finish before flushing the capture queue.
• Serialize capture ownership updates and recycle QBUF operations without holding the ownership lock across the existing 100 ms waits.
• Drain the GetFrame depth queue and re-queue only buffers that were still decoder-owned before the flush.
• Wake paused output work during channel shutdown.

Validation

• scripts/lint/lint_cpp.sh mpi/vdec
• Clean Release CMake build

[spacemit-robot-ci]

Robot CI AI Review

• PR: fix(vdec): serialize capture ownership during flush #39 fix(vdec): serialize capture ownership during flush
• Project: components/multimedia/mpp
• Commit: 36435dfaa962

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

发现：

1. [严重] mpi/vdec/vdec.c:1514 嵌套锁顺序不一致，可能死锁
   在 VDEC_Flush 中加锁顺序为 lock → reqLock → poolLock → depthLock，但在 vdec_recycle_task 中为 reqLock → poolLock。若 recycle 线程持有 reqLock 并等待 poolLock，而 flush 持有 poolLock 并等待 reqLock（虽然当前代码路径未显式出现，但嵌套结构已埋下风险），可能死锁。
   建议：统一全局锁顺序（如 lock → reqLock → poolLock → depthLock），或在 flush 中先释放 lock 再获取 reqLock，确保与 recycle 线程的加锁顺序一致。

2. [中等] mpi/vdec/vdec.c:1475-1518 flush 中 re-queue 逻辑未处理部分失败场景
   在 re-queue 循环中，若 queue_output_buffer 失败，只将 bInDecoder 置为 MPP_FALSE 并记录错误，但未释放该 buffer 的 decoder ref（bHasDecoderRef 仍可能为真），可能导致 VB 引用计数不平衡，后续 DisableChn 时资源泄漏。
   建议：re-queue 失败时，若 hadDecoderRef[i] 为真，调用 VB_ReleaseBuffer(pChn->stExtBuf[i].ulVbBuff) 并将 bHasDecoderRef 置 MPP_FALSE，确保引用计数正确。

备注：worker-cache review 失败，已回退 baseline review：worker-cache review failed: snode5: fetch base failed: From github.com:spacemit-com/mpp
! [rejected] main -> refs/robot-ci/base/main (non-fast-forward); From github.com:spacemit-com/mpp
! [rejected] main -> refs/robot-ci/base/main (non-fast-forward); hp-probook: sync worker helper failed: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:DaJdTDzKLjEd/wLfaMcCfMssCA5vL538g4U27/I2BnY.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /root/.ssh/known_hosts:15
remove with:
ssh-keygen -f '/root/.ssh/known_hosts' -R '10.0.91.193'
Host key for 10.0.91.193 has changed and you have requested strict checking.
Host key verification failed.