MediaStreamVideoTrackSource: hardware encoder reclaimed by Chrome during long pause() — track dies on resume with "Codec reclaimed due to inactivity"

[cxylys]

Environment

• mediabunny: 1.40.1 (also checked 1.56.0 — pause() implementation unchanged)
• Chrome 154 (Windows), hardware H.264 encoder (default hardwareAcceleration: 'no-preference' resolves to hardware)
• Use case: screen recording from getDisplayMedia, encoded via MediaStreamVideoTrackSource into an MP4 Output

What happens

During a recording, the user pauses for a while (long pauses of tens of seconds to minutes). On resume, the next frame fed to the encoder fails and the track source's errorPromise rejects with:

Codec reclaimed due to inactivity.

The recording is effectively dead from that point on — the source cannot recover.

Root cause

MediaStreamVideoTrackSource.pause() only sets an internal flag so incoming frames are ignored:

pause() {
    this._paused = true;
}

While paused, the underlying VideoEncoder receives no encode() calls and stays open-but-idle. Chrome reclaims idle hardware codecs to free GPU resources (battery/memory management), so when resume() starts feeding frames again, the encoder instance is gone and encode() throws.

Suggested directions

One or both of the following would make long pauses safe:

1. Close the encoder on pause() (flush + close()), and transparently re-create it on resume(), continuing to write into the same output track.
2. Recover from reclamation: catch the "Codec reclaimed due to inactivity" encoder error internally, re-create the encoder, and continue — optionally surfaced as a warning.

Workaround we currently use

Listening on errorPromise and auto-stopping the recording to finalize whatever was captured before the pause. It works, but everything after the pause is lost — unfortunate for a feature whose whole point is "pause and continue later".

Thanks for the great library — the pause/resume semantics for streams are otherwise really clean.