Flywheel
Flywheel produces a continuous, normalized MPEG-TS output with KLV, regardless of whether a source stream is present.
It requires both the Recast and Flywheel license options.
Why use Flywheel?
Live contribution streams are not always stable. A source can disappear temporarily, change timing, or deliver video in a format that is unsuitable for a downstream decoder, recorder, multiplexer, or distribution system. Forwarding that source unchanged also forwards those interruptions and variations.
Like a mechanical flywheel that smooths an uneven input, the Flywheel processor isolates downstream outputs from source instability. It decodes the incoming video and continuously creates a new output with the configured codec, resolution, frame rate, GOP, PID, and rate-control behavior. If the source is lost, Flywheel keeps the output timeline moving with a timeout visual. When the source returns, live video resumes without rebuilding the rest of the stream graph.
Flywheel is especially useful when several streams must be recorded or played back in synchronization. Without continuity, a temporary loss on one source can create a gap or shorten that recording while the other streams continue, making later time-aligned playback difficult. Flywheel preserves the affected stream's output timeline by inserting the timeout visual at the configured frame rate until live video returns. As a result, all recordings continue to cover the same elapsed time, and a synchronized player can keep the streams aligned instead of pausing, drifting, or requiring the missing interval to be reconstructed later.
Use Flywheel when a destination needs a predictable video contract or must remain connected through short source outages. Do not use it when byte-for-byte forwarding is required: outputs set to Original source preserve the received transport stream, while outputs set to Flywheel receive newly encoded video.
What Flywheel does
| Function | Behavior |
|---|---|
| Video normalization | Re-encodes video as H.264 or H.265 at the configured resolution, frame rate, GOP, PID, and bitrate settings. |
| Continuous output | Maintains timestamps and emits a timeout visual while live video is unavailable. |
| Rate control | Supports unpadded VBR output or CBR MPEG-TS output maintained with encoder filler or transport null packets. |
| KLV continuity | Forwards live KLV and can generate fallback MISB ST 0601 data when live KLV is missing. |
| Independent routing | Allows each supported output to select either the original source or the Flywheel result. |
| Fault isolation | Keeps original playback and source-attached outputs running if the Flywheel worker or one of its outputs fails. |
Flywheel currently outputs video and KLV only. Audio is neither generated nor passed through.
How the stream is routed
Flywheel is a processor in the stream graph, not a separate stream type. The normal SkyView input remains authoritative:
- SkyView receives the source once and keeps local WebRTC playback, preview, KLV windows, analytics, and outputs set to Original source on that path.
- A private loopback branch feeds the Flywheel processor.
- Outputs whose Input is Flywheel receive the processor's continuous MPEG-TS output.
UDP, SRT, and UDS outputs can use Flywheel. Raw PCAP output always uses the original source. The internal loopback connections are private implementation details and do not appear as outputs or statistics.
Configure Flywheel
Choose a UDP, SRT, or UDS MPEG-TS stream, select Recast or Play and Recast, and open the Flywheel tab. Enable Flywheel and configure the video codec, rate control, bitrate, frame rate, resolution, keyframe interval (GOP), and video PID.
VBR is the default. Set both the target bitrate and a maximum bitrate that is at least as high as the target. VBR is not padded, so simple scenes and timeout visuals may use much less than the target rate. Encoder support for an explicit VBR maximum is best effort.
CBR maintains the configured MPEG-TS rate with encoder filler or transport null packets, including while the timeout visual is shown.
Prefer hardware acceleration is enabled by default and applies to both decoding and encoding. SkyView reports the decoder and encoder actually selected. On Linux this setting is strict: decoded frames, composition, and encoder input remain in GPU memory, and the worker reports an error instead of silently copying video through CPU memory. Disable the setting explicitly only when a software Flywheel is acceptable. On Windows, compatible hardware encoders receive the composited frame directly as D3D11 memory, avoiding the former GPU readback and CPU upload. The system-memory path remains available when the installed encoder cannot accept D3D11 memory.
Add or edit an output and set Input to Flywheel. An enabled Flywheel cannot be removed while outputs still reference it; reassign those outputs to Original source or remove them first.
Source loss and recovery
Flywheel keeps its output decodable and timestamped while the source is missing. It displays the configured timeout visual and resumes live video when the source returns. Local playback and preview always remain on the original source and therefore show the source's actual state.
KLV behavior
Live source KLV is forwarded when available. If Generate synthetic data when live KLV is missing is enabled, Flywheel generates minimal MISB ST 0601 data at the configured PID and rate, including NO SIGNAL semantics during source loss. Synthetic data stops when real KLV resumes.
The video and fallback KLV PIDs must differ. This version supports one output KLV elementary stream.
Linux container runtime
Pass /dev/dri and the video group into the container for the default Linux Flywheel configuration. The worker uses a hardware EGL renderer plus a hardware decoder and encoder with GLMemory or DMA-BUF handoff. If any part of that GPU path is unavailable, startup fails with the selected component in the diagnostics. It does not silently introduce a CPU video copy. Software operation remains available only when Prefer hardware acceleration is disabled explicitly.