obs-websocket中requestBatch指令顺序问题解析

问题背景

在OBS自动化场景切换过程中，开发者发现使用obs-websocket的requestBatch批量请求功能时，指令执行顺序会影响最终效果。具体表现为：当先执行场景切换(SetCurrentProgramScene)再执行过渡效果设置(SetCurrentSceneTransition)时，会导致程序场景卡住；而顺序调换后则能正常工作。

问题复现

开发者最初尝试的代码实现如下：

var requests = [
    {"requestType": "SetCurrentProgramScene",
    "requestData": { "sceneName": jumpToScene }
        
    },{"requestType": "SetCurrentSceneTransition",
    "requestData": { "transitionName": current_transition }}
    ];
jsc.obs_v5.requestBatch(p1, requests);

这种实现方式会导致场景切换和过渡效果卡住。而将两个请求顺序调换后：

var requests = [
    {"requestType": "SetCurrentSceneTransition",
    "requestData": { "transitionName": current_transition }
        
    },
    {"requestType": "SetCurrentProgramScene",
    "requestData": { "sceneName": jumpToScene }}
    ];
jsc.obs_v5.requestBatch(p1, requests);

则能够正常工作。这表明在obs-websocket的批量请求处理中，指令的执行顺序对最终效果有直接影响。

技术分析

1. 请求处理机制：obs-websocket的requestBatch虽然是批量发送请求，但OBS内部可能是顺序执行这些请求。当先切换场景再设置过渡时，可能因为场景切换尚未完全完成就尝试应用过渡效果，导致状态不一致。

2. 时序依赖：场景切换和过渡效果设置之间存在隐式的时序依赖关系。过渡效果需要基于当前场景状态才能正确应用。

3. 异步处理：OBS内部处理这些请求时可能存在异步操作，批量请求无法保证前一个请求完全处理完毕后再执行下一个请求。

解决方案

开发者最终采用的解决方案是使用setTimeout在两个操作之间添加延迟：

jsc.utils.trigger.addSingleRunVideoOnStop(mediaName, function() {
    jsc.obs_v5.setActiveScene(p1, jumpToScene);
    var backTransition = h.setTimeout(function() {
        jsc.obs_v5.request(p1, 'SetCurrentSceneTransition', { 'transitionName': current_transition });
    }, 1500);         
});

这种方法虽然有效，但有几点需要注意：

1. 延迟时间：1500ms的延迟是经验值，可能需要根据实际硬件性能调整。

2. 可靠性：依赖定时器不是最可靠的解决方案，因为不同环境下场景切换所需时间可能不同。

最佳实践建议

1. 使用回调机制：如果API支持，最好使用场景切换完成的回调来触发过渡效果设置。

2. 状态检查：在设置过渡效果前，先确认场景切换是否已完成。

3. 错误处理：添加适当的错误处理逻辑，确保在操作失败时有恢复机制。

4. 性能考量：在自动化脚本中，合理设置操作间隔，避免给OBS造成过大负担。

总结

这个案例展示了在OBS自动化开发中时序控制的重要性。虽然requestBatch提供了批量操作的便利性，但对于有严格顺序依赖的操作，开发者需要特别注意执行顺序或添加适当的同步机制。理解底层API的行为特点对于构建稳定的自动化流程至关重要。