export declare function buildSafeOutputFilename(title: string | undefined, now?: Date): string;
/**
 * R46 #2.5 — Remotion's renderMedia exposes a per-frame onProgress
 * callback we were ignoring. Without it, the surrounding pipeline saw
 * render as a binary 0-or-done stage even though weighted progress
 * budget allocates 75% of the bar to it. Result: bar would sit at 0%
 * for the whole render then snap to 75%. Wiring this through closes
 * the "stuck at 0%" gap surfaced in the 2026-05-09 e2e test.
 *
 * The callback shape is `({ renderedFrames, encodedFrames, ... })` —
 * we use renderedFrames since that's what advances during the slow
 * Chromium screenshot loop. encodedFrames lags by ~10 frames because
 * Remotion encodes in batches; for a smooth UI bar we want the leading
 * edge.
 */
export interface RenderToMp4Options {
    /** 0..1 fraction of frames rendered. Called every ~250ms by Remotion. */
    onProgress?: (fraction: number) => void;
    /**
     * #44 — abort the heaviest stage mid-flight, not just at the next stage
     * boundary. Remotion has its own cancellation protocol (makeCancelSignal),
     * so we bridge the standard Node AbortSignal onto it: an `abort` event calls
     * Remotion's `cancel()`, which kills the headless Chromium render loop and
     * makes renderMedia reject. Same "external signal → subsystem-native cancel"
     * shape that runEncodeStage already uses for ffmpeg child.kill(SIGTERM).
     */
    signal?: AbortSignal;
}
export declare function renderCompositionToMp4(comp: {
    duration: number;
    fps: number;
    width: number;
    height: number;
    title?: string;
    [k: string]: unknown;
}, outDir: string, opts?: RenderToMp4Options): Promise<string>;
//# sourceMappingURL=remotion-renderer.d.ts.map