The stub types have no schema behind them. protocol.json types 14 array fields as Array<Object> and says nothing more, because obs-websocket's doc pipeline has no concept of a named type: it parses pipe-delimited @responseField comments into a flat string per field. So the shapes exist only as C++ in Obs_ArrayHelper.cpp, Obs_ObjectHelper.cpp, Obs_VolumeMeter.cpp, RequestHandler_Canvases.cpp and RequestHandler_Ui.cpp.
Ours were written from what one OBS instance happened to return, and a manual diff against those sources found eight fields missing and one that does not exist:
SceneItemStub inputKind, sourceType, sceneItemBlendMode, sceneItemBlendMethod
InputStub inputKindCaps
OutputStub outputFlags (and outputSettings, which GetOutputList never sends)
TransformStub cropToBounds
They were landing in ExtensionData, so nothing failed loudly; they were just unreachable as typed members. Same sweep found four numeric fields too narrow for what OBS can send.
Both classes are mechanically detectable. A script that walks the C++ for xJson["field"] = expr;, resolves expr to its libobs return type, and diffs that against the stubs would have caught every one of them, instead of depending on a live run happening to hit an uninitialised virtual camera.
Shape:
- Run it as a manual check, not a build step, so it needs no obs-studio checkout to build the package.
- Point it at a local obs-websocket + obs-studio clone via a path argument.
- Report missing fields, extra fields, and numerics narrower than the C type behind them.
Considered and rejected: proposing @typedef support upstream. It would be a breaking change to protocol.json for every downstream consumer, the annotations would still be hand-maintained and free to drift from the C++, and it would not carry integer widths, so NumericFieldTable survives either way. Not worth the coordination.
Roughly half a day.
The stub types have no schema behind them.
protocol.jsontypes 14 array fields asArray<Object>and says nothing more, because obs-websocket's doc pipeline has no concept of a named type: it parses pipe-delimited@responseFieldcomments into a flat string per field. So the shapes exist only as C++ inObs_ArrayHelper.cpp,Obs_ObjectHelper.cpp,Obs_VolumeMeter.cpp,RequestHandler_Canvases.cppandRequestHandler_Ui.cpp.Ours were written from what one OBS instance happened to return, and a manual diff against those sources found eight fields missing and one that does not exist:
They were landing in
ExtensionData, so nothing failed loudly; they were just unreachable as typed members. Same sweep found four numeric fields too narrow for what OBS can send.Both classes are mechanically detectable. A script that walks the C++ for
xJson["field"] = expr;, resolvesexprto its libobs return type, and diffs that against the stubs would have caught every one of them, instead of depending on a live run happening to hit an uninitialised virtual camera.Shape:
Considered and rejected: proposing
@typedefsupport upstream. It would be a breaking change toprotocol.jsonfor every downstream consumer, the annotations would still be hand-maintained and free to drift from the C++, and it would not carry integer widths, soNumericFieldTablesurvives either way. Not worth the coordination.Roughly half a day.