Use frame rate reported by CasparCG if nothing else is configured#420
Use frame rate reported by CasparCG if nothing else is configured#420rjmunro wants to merge 3 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
WalkthroughThe CasparCG integration refactors connection initialization and resync handling to return a structured object containing resync flags and channel information instead of boolean values, enabling dynamic channel set support and deferred state population during connection and recovery operations. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
9c2af07 to
6af085d
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Rather than directly defaulting to 25.
Previously, channel info was populated during the virgin check loop but then immediately cleared if a resync was needed (which includes first connect). This meant _currentState.channels was empty during normal operation. Changes: - Move channel info population to after the resync decision - Pass channelInfo through the promise chain alongside doResync - Fix bug where channels[i] was checked but channels[obj.channel] was set - Simplify loop to iterate over channelInfo array directly This ensures channel metadata (fps, videoMode) is always available.
Only clear _currentState.channels when doing a resync (firstConnect || doResync). When updating channel info (videoMode/fps), preserve existing layers that are built up by shared-control feature instead of always clearing them. Addresses PR feedback from @Julusian
6af085d to
cffbaa7
Compare
|
Awaiting retesting by @Saftret. It's possibly not detecting anything and just defaulting to 25fps. |
About the Contributor
Type of Contribution
This is a Bug fix / Feature
Current Behavior
The framerate is read from CasparCG with the INFO command, but it is ignored. It uses a user configured value or a default of 25. This breaks timing in e.g. 50i modes, meaning that you jump to a point twice as far in a video than you should. It probably breaks 30 and 60fps to, but I we didn't test that.
New Behavior
Use the value from the INFO command if config is unset. Only default to 25 if that doesn't work.
Testing Instructions
@Saftret Can you review this?
While working in a 50i setup, leave the configured value in
settings -> studio -> playout devices -> CasparCG -> frame rateblank. Then jump to a place in a clip (how?). It should take you to the right place. The previous version would take you to a point double what you requested.Other Information
This was discussed and coded at the SuperFlyTV dev meet on 2026/01/22.
Status
Use detected frame rate as default if not configured
Problem
The CasparCG integration was ignoring the frame rate reported by CasparCG's INFO command and instead relying on a user-configured value or defaulting to 25 fps. This caused incorrect timing behavior—notably, in 50i setups, jumps landed at twice the requested position, and the issue potentially affects 30/60 fps configurations as well.
Solution
Modified the CasparCG integration to prioritize the frame rate detected from CasparCG's INFO command when the user has not explicitly configured a frame rate. The fallback hierarchy is now:
Technical Changes
{ doResync: boolean, channelInfo: InfoEntry[] }instead of a plain boolean, enabling more flexible channel metadata handlingdoResync: false; otherwisedoResync: true_currentStatefrom the retrieved channel infoinitOptions.fpsif available, else falls back to detected FPS from_currentStatefor the channel, or defaults to 25Testing
Testing instructions provided: In a 50i setup, leave the CasparCG frame rate configuration blank and verify that jumps to clip positions land at the correct location (previously landed at double the requested position).