Release notes

Videorc 0.9.79 Alpha 1

Under output pressure the recorder used to throw away frames it had already encoded — the reported case reached a completely full queue with the oldest frame more than half a second late. It now protects finished frames and skips only work it has not done yet, stopping only after a genuine stall. Live controls also stop getting stuck: scene, screen, caption and chat changes reconcile against what the backend actually did instead of blindly replaying a command whose outcome was unknown.

This release is not currently available for public download.

All releases

Recordings keep every encoded frame under load

  • Recordings under heavy load no longer lose frames that were already encoded — only unrendered work is skipped, and only while real progress continues.
  • Scene, screen, caption, chat and takeover changes no longer stick or double-apply when a command's outcome was unclear.
  • Backend commands run in separate lanes, so a slow chat or account request can no longer delay going live or stopping a recording.
  • Recording and streaming get their own encoder roles where supported, with per-role diagnostics reset between sessions.

Fixed

  • Encoded frames survive output pressure. The bridge shed whole access units when the output queue filled, discarding work the encoder had already done. It now preserves every encoded access unit and drops only unencoded compositor ticks, stopping only after a bounded no-progress stall. Ships exact regression coverage for the reported incident (queue depth 16/16, oldest frame 528 ms against a 250 ms budget).
  • Live-control stalls. Backend commands are split into explicit observation, account, chat, live-control and stop lanes with reconnect-safe ordering, so one slow lane cannot block another. Mutations whose outcome was unknown are reconciled against authoritative backend state instead of replayed.
  • Hardened account-refresh generations, screen-activation persistence, comments timeouts, avatar fetches, and takeover microphone ownership.

Known limitations on Windows

This pilot was not verified on physical Windows hardware. The microphone-loss work carried in 0.9.78 still covers the native audio path only: Windows DirectShow receives the silence-padding policy but does not use the native source-loss monitor, so a clean end-of-stream there raises no microphone-input-lost warning, and a fatal DirectShow driver error can still end the capture process.