Here's your issue formatted perfectly for the Reframe template:
Feature description
Add a live "Estimated Time Remaining" display during video export. While FFmpeg processes the video, show a dynamic countdown label (e.g. ⏱ ~18 seconds remaining) beneath the existing progress bar so users always know how long the export will take.
Problem this solves
When exporting a video, the progress bar gives no indication of how long the process will take. For larger files or slower devices, this creates genuine uncertainty — users can't tell if the export is running normally or if the app has frozen. I often find myself staring at a progress bar with no idea whether to wait 5 seconds or 5 minutes, which sometimes leads to accidentally closing the tab and losing the export entirely.
Proposed solution
Since the FFmpeg .on('progress', ...) callback in src/lib/ffmpeg.ts already exposes a progress value between 0 and 1, we can calculate ETA purely from that — no new libraries needed.
Implementation plan:
Record startTime = Date.now() the moment export begins in ffmpeg.ts
On each progress tick: elapsed = Date.now() - startTime → eta = (elapsed / progress) - elapsed
Expose etaSeconds as a new state field in useVideoEditor.ts
Render it in VideoEditor.tsx beneath the progress bar:
Hidden when progress < 0.02 (avoids wild early estimates)
Hidden after export completes
Displayed as ~X seconds remaining during active export
Example UI:
Exporting... 42%
⏱ ~18 seconds remaining
Alternatives considered
Showing elapsed time only (Time elapsed: 12s) — rejected because it gives no useful forward-looking information; users still don't know when it will finish.
A generic "This may take a while" static message — already partially present in some tools; too vague to be actionable and doesn't solve the core problem.
Adding a third-party progress estimation library — unnecessary given the data we already have from the FFmpeg progress callback; keeping zero new dependencies is better for a lightweight browser tool.
Additional context
This is a zero-dependency, frontend-only change touching ~3–4 files
The FFmpeg onProgress hook is already wired and functional in ffmpeg.ts, so this extends existing infrastructure rather than introducing new patterns
Especially impactful on Mobile Safari (listed as "⚠️ Partial" support for large files in the README) where exports can be significantly slower and users need feedback the most
The fix also improves perceived performance — research consistently shows that a labeled wait feels shorter than an unlabeled one, even at the same actual duration
Here's your issue formatted perfectly for the Reframe template:
Feature description
Add a live "Estimated Time Remaining" display during video export. While FFmpeg processes the video, show a dynamic countdown label (e.g. ⏱ ~18 seconds remaining) beneath the existing progress bar so users always know how long the export will take.
Problem this solves
When exporting a video, the progress bar gives no indication of how long the process will take. For larger files or slower devices, this creates genuine uncertainty — users can't tell if the export is running normally or if the app has frozen. I often find myself staring at a progress bar with no idea whether to wait 5 seconds or 5 minutes, which sometimes leads to accidentally closing the tab and losing the export entirely.
Proposed solution
Since the FFmpeg .on('progress', ...) callback in src/lib/ffmpeg.ts already exposes a progress value between 0 and 1, we can calculate ETA purely from that — no new libraries needed.
Implementation plan:
Record startTime = Date.now() the moment export begins in ffmpeg.ts
On each progress tick: elapsed = Date.now() - startTime → eta = (elapsed / progress) - elapsed
Expose etaSeconds as a new state field in useVideoEditor.ts
Render it in VideoEditor.tsx beneath the progress bar:
Hidden when progress < 0.02 (avoids wild early estimates)
Hidden after export completes
Displayed as ~X seconds remaining during active export
Example UI:
Exporting... 42%
⏱ ~18 seconds remaining
Alternatives considered
Showing elapsed time only (Time elapsed: 12s) — rejected because it gives no useful forward-looking information; users still don't know when it will finish.
A generic "This may take a while" static message — already partially present in some tools; too vague to be actionable and doesn't solve the core problem.
Adding a third-party progress estimation library — unnecessary given the data we already have from the FFmpeg progress callback; keeping zero new dependencies is better for a lightweight browser tool.
Additional context
This is a zero-dependency, frontend-only change touching ~3–4 files⚠️ Partial" support for large files in the README) where exports can be significantly slower and users need feedback the most
The FFmpeg onProgress hook is already wired and functional in ffmpeg.ts, so this extends existing infrastructure rather than introducing new patterns
Especially impactful on Mobile Safari (listed as "
The fix also improves perceived performance — research consistently shows that a labeled wait feels shorter than an unlabeled one, even at the same actual duration