Skip to content

fix: cover the remaining native failure paths of the media module - #442

Merged
devopvoid merged 1 commit into
mainfrom
fix/media-jni-exceptions-followup
Oct 25, 2026
Merged

devopvoid merged 1 commit into
mainfrom
fix/media-jni-exceptions-followup

Conversation

@devopvoid

Copy link
Copy Markdown
Owner

Follow-up to #439, for the failure paths it left open:

  • A recorder whose writer thread cannot start stays idle on both sides, so it can be started again or closed, instead of reporting RECORDING.
  • OnEncodedFrame, called by WebRTC through the C interface, no longer lets a C++ exception escape into WebRTC: a frame that cannot be queued is dropped and a key frame requested.
  • A player that fails during create drops its observer before it is released, also when a C++ exception unwinds.
  • The text of a standard exception reaches Java as printable ASCII, since ThrowNew expects modified UTF-8.
  • MediaFileSource cleans up on Error as well, and the FFmpeg entry points run behind the boundary too.
  • AllocationFault can also fail a general allocation or a thread start, with tests for each path.

A recorder whose writer cannot start stays idle, a frame that cannot be
queued on a WebRTC thread is dropped instead of thrown into it, a player
that fails to start loses its observer first, exception text reaches
Java as ASCII, and MediaFileSource cleans up on errors too.
@devopvoid
devopvoid merged commit 814604c into main Oct 25, 2026
49 of 52 checks passed
@devopvoid
devopvoid deleted the fix/media-jni-exceptions-followup branch October 25, 2026 13:19
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