Repository navigation
refactor: extract SimUseVideo target and rehome Android record-video - #79
Merged
Merged
Conversation
…rget The H.264 Annex B parser, passthrough muxer, AVAssetWriter encoder, frame utilities, and output-path resolution were platform-neutral but lived in iOSSimBackend, forcing the Android record-video orchestration into the SimUse executable target (the only place with both backends in its dep cone). Move them into a new SimUseVideo target (SimUseCore + system frameworks only, FB*-free), and sink the generic process-control helpers (CancellationFlag, OnceFlag, FirstErrorBox, cancellableSleep, SignalObserver) into SimUseCore. The single FB*-tied piece — VideoFrameUtilities.captureScreenshotData — stays in iOSSimBackend as an extension. Pure restructuring, no behavior change; groundwork for hosting Android video verbs in AndroidBackend (#78). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: onevcat <onevcat@gmail.com>
With the video plumbing extracted to SimUseVideo, the Android recording engine no longer needs to live inline in the SimUse executable target. Move it into AndroidRecordVideoCommand and register it, giving record-video the same three-surface layout as every other cross-platform verb (top-level forwarder + `ios` + `android`); the top-level Android branch now forwards to AndroidRecordVideoCommand.record(), symmetric to AndroidScreenshotCommand.performScreenshot. Flag validation is shared across all three surfaces via VideoRecordingOptions in SimUseVideo so the contract cannot drift. Flags and behavior are unchanged. Verified live against emulator-5554: both `sim-use android record-video` and top-level `sim-use record-video` produce a valid H.264 MP4 (ffprobe) with clean SIGTERM finalization. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: onevcat <onevcat@gmail.com>
3 of 4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The platform-neutral video plumbing (H.264 Annex B parsing, passthrough muxing,
AVAssetWriterencoding, frame utilities) lived iniOSSimBackend, so the Androidrecord-videoorchestration from #70 was forced inline into theSimUseexecutable target — the only target with both backends in its dep cone. That asymmetry (noandroid record-videosubcommand, a 475-line top-level forwarder) would have repeated itself for every future video verb, starting with #78.Changes
Two pure-refactor commits, no CLI behavior change:
SimUseVideotarget —AnnexBStreamParser,H264MuxingPipeline,H264PassthroughRecorder, frame utilities,H264StreamRecorder, the recording watchdog, and output-path resolution (VideoOutputFile) move to a new FB*-free target (SimUseCore+ system frameworks only). Generic process-control helpers (CancellationFlag,OnceFlag,FirstErrorBox,cancellableSleep,SignalObserver) sink intoSimUseCore/ProcessControl.swift. The single FB*-tied piece —VideoFrameUtilities.captureScreenshotData(from: FBSimulator)— stays iniOSSimBackendas an extension.AndroidBackend/Verbs/AndroidRecordVideoCommand.swiftand is registered, sosim-use android record-videonow exists andrecord-videohas the same three-surface layout as every other cross-platform verb. The top-level forwarder shrinks to the standard thin shape and callsAndroidRecordVideoCommand.record(), symmetric toAndroidScreenshotCommand.performScreenshot. Flag validation is shared across all three surfaces viaVideoRecordingOptionsso the contract cannot drift.New dependency graph:
SimUseCore → SimUseVideo → { iOSSimBackend, AndroidBackend } → SimUse.Verification
make build+make testgreen (1206 tests; moved suites retargeted to their new modules).record-video(clean SIGTERM finalization, playable MP4) andscreenshot.emulator-5554: bothsim-use android record-videoand top-levelsim-use record-videoproduce an ffprobe-valid H.264 MP4 (1080×2400) with clean SIGTERM finalization.Groundwork for #78 (
stream-videoAndroid support), which lands separately on top of this.🤖 Generated with Claude Code