Skip to content

Fix: MJPEG video streaming and xcode-select detection on modern macOS - #897

Open
amilich wants to merge 1 commit into
facebook:mainfrom
amilich:main
Open

Fix: MJPEG video streaming and xcode-select detection on modern macOS#897
amilich wants to merge 1 commit into
facebook:mainfrom
amilich:main

Conversation

@amilich

@amilich amilich commented Dec 14, 2025

Copy link
Copy Markdown

Two key fixes for idb_companion on macOS 12.1+:

  1. FBSimulatorVideoStream.m: Don't require hardware-accelerated encoding for JPEG

  2. FBXcodeConfiguration.m: Fall back to xcode-select -p for developer directory

    • The symlink at /var/db/xcode_select_link no longer exists on modern macOS
    • Now tries the symlink first, then falls back to running xcode-select -p
  3. FBSimulatorControl.xcodeproj: Mark required headers as Public

  4. Applied fixes from upstream PRs Fix up compiler errors #889 and Fix createGzipForPath compile failure #895 for compilation issues

These fixes video streaming.

Two key fixes for idb_companion on macOS 12.1+:

1. FBSimulatorVideoStream.m: Don't require hardware-accelerated encoding for JPEG
   - The original code unconditionally required hardware acceleration on macOS 12.1+
   - JPEG encoding may not have hardware encoder support on all systems
   - This caused VTCompressionSessionCreate to fail with -12902 (kVTParameterErr)
   - Now only H.264 requires hardware acceleration; JPEG prefers but doesn't require it

2. FBXcodeConfiguration.m: Fall back to xcode-select -p for developer directory
   - The symlink at /var/db/xcode_select_link no longer exists on modern macOS
   - Now tries the symlink first, then falls back to running xcode-select -p

3. FBSimulatorControl.xcodeproj: Mark required headers as Public
   - FBSimulatorApplicationCommands.h and FBSimulatorFileCommands.h need to be public
   - Required for idb_companion to build against the framework

4. Applied fixes from upstream PRs facebook#889 and facebook#895 for compilation issues

These fixes enable MJPEG video streaming at ~30 FPS without requiring the
simulator window to be visible on screen.
@meta-cla

meta-cla Bot commented Dec 14, 2025

Copy link
Copy Markdown

Hi @amilich!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-codesync Bot pushed a commit that referenced this pull request Jul 28, 2026
Summary:
TL;DR: Preserve IDB's existing hardware-required encoder behavior by default and add a narrowly scoped, explicit opt-in for software MJPEG fallback. Orchard Studio is the sole opt-in in D113560940; H.264, HEVC, Minicap, and every existing IDB caller retain their prior behavior.

Orchard's native preview sends MJPEG over a private Unix socket into a main-owned loopback stream so Electron can display simulator frames directly, without an H.264 container/keyframe/decoder-buffering or MediaSource/WebCodecs pipeline. On macOS 26.5.2 with Xcode 26.6, an A/B control using IDB's hardware-required JPEG policy timed out in `startPreviewStream` after 120 seconds, while the explicit software-fallback configuration delivered a complete JPEG frame and passed the live preview path.

This matches the modern-macOS compatibility request in #897, which specifically reports that JPEG hardware encoding cannot be required on all systems: https://github.com/facebook/idb/pull/897/files

Add `allowsSoftwareMJPEGEncoding` to `FBVideoStreamConfiguration` through new overloads while preserving the existing initializer symbols. It defaults to `false`; the encoder relaxes the hardware requirement only when the format is exactly `.mjpeg` and the caller explicitly opts in. Minicap remains hardware-required even though it also uses the JPEG codec, and compressed H.264/HEVC behavior is unchanged.

Reviewed By: eromanc

Differential Revision: D113560936

fbshipit-source-id: 77f3cca8340c2a17481bc3579d7618fdb10aac9b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant