Fixes JAVA-580

📜 Description

The MediaMuxer inside SimpleMp4FrameMuxer is constructed eagerly when the video encoder is created (CloseGuard.open registers a guard expecting release()), but release() was only reachable on the happy path. Two cases leaked it:

• ReplayCache.createVideoOf returned early when frameCount == 0 (frames exist but none could be encoded) without calling encoder?.release().
• SimpleMp4FrameMuxer.release() called muxer.stop() before muxer.release(). MediaMuxer.stop() throws IllegalStateException if the muxer was never started (i.e. no frame was ever muxed, so INFO_OUTPUT_FORMAT_CHANGED never fired), so muxer.release() was skipped. The exception was then swallowed by SimpleVideoEncoder.release()'s catch block.

The fix guards stop() behind the started flag so release() is always reached, and releases the encoder on the no-frames return path.

💡 Motivation and Context

Surfaces as a CloseGuard warning: A resource was acquired at attached stack trace but never released ... Explicit termination method 'release' not called, pointing at the MediaMuxer constructor in SimpleMp4FrameMuxer. It is a latent resource leak in production whenever a segment ends up with zero encodable frames, and it shows up consistently in Robolectric tests where the encode pipeline doesn't start the muxer.

💚 How did you test it?

The existing ReplayCacheTest."when screenshot is corrupted, deletes it immediately" exercises the frames-present-but-none-encoded path (frameCount == 0 after the encoder is created), which previously triggered the leak.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps