fix: add warnings for large FFmpeg video uploads

[YLaxmikanth]

Description

This PR fixes the missing user feedback issue when uploading large videos that may exceed FFmpeg.wasm browser memory limitations.

Previously, users could upload very large files (500MB+) and experience browser freezes, silent export failures, or crashes without any warning or actionable feedback.

This PR introduces reusable file-size risk detection, adaptive warning thresholds, and a dismissible UI warning banner to improve export UX and reduce confusion around browser memory limitations.

Related Issue

Closes #1150

Type of Contribution

• Bug fix
• New feature
• Documentation update
• Refactor
• GSSoC contribution

Participant Info

• GitHub username: YLaxmikanth
• Contribution level (Beginner/Intermediate/Advanced): Intermediate

Screen Recording

Recording / Loom link: Not attached

Checklist

• I have read the contribution guidelines
• My changes follow the project structure
• I have tested my changes in Chrome, Firefox, and Safari
• bun run lint passes (no ESLint errors)
• bunx tsc --noEmit passes (no TypeScript errors)
• New interactive elements have aria-label / accessible names
• No console.log statements left in
• This PR is related to a valid issue
• Screen recording attached above (required for UI/feature/design changes)

---

Root Cause

The app only enforced a hard 2GB upload limit and showed minimal guidance for moderately large files.

There was no structured risk detection or user-facing warning for the common real-world scenarios where FFmpeg.wasm becomes unstable or memory-constrained during browser-based exports.

As a result:

• exports could silently hang
• browser tabs could freeze
• FFmpeg processing could fail without feedback
• users had no indication that file size was the likely cause

---

Fix Implemented

Reusable File Risk Detection

Added:

• src/lib/fileSizeRisk.ts

Introduced:

• FileRiskLevel
• analyzeFileRisk()
• formatBytes()

Risk levels:

• safe
• large
• very-large

Default thresholds:

• > 500MB → warning
• > 1GB → stronger warning

---

Adaptive Device-Memory Heuristics

When available:

navigator.deviceMemory

is used to scale thresholds more conservatively on lower-memory devices.

Examples:

• 4GB device → earlier warnings
• 16GB desktop → standard thresholds

This remains non-blocking and lightweight.

---

Improved Warning UI

Added a dismissible warning banner in:

• src/components/VideoEditor.tsx

The warning now:

• appears immediately after upload
• displays detected file size
• explains FFmpeg/browser memory limitations
• recommends smaller files for stability
• remains non-blocking (exports still allowed)

Example UX:

⚠ Large file detected (842 MB)

Browser-based FFmpeg processing may be slow or fail due to memory limits.
For best results, use files under 500 MB.

---

Files Modified

Added

• src/lib/fileSizeRisk.ts
• src/lib/tests/fileSizeRisk.test.ts

Updated

• src/hooks/useVideoEditor.ts
• src/components/VideoEditor.tsx

---

Test Coverage

Added dedicated tests for:

• safe file detection
• large file detection
• very-large file detection
• custom threshold overrides
• formatBytes() formatting
• device-memory scaling behavior

---

Validation

Build

• npm run build ✅

Lint

• npm run lint ✅

Tests

• npm run test ✅
• 83 tests passing

TypeScript

• bunx tsc --noEmit ✅

---

Expected Outcome

• Users receive immediate feedback for large uploads
• Reduced confusion around FFmpeg/browser crashes
• Better UX for browser-based video exports
• Improved awareness of browser memory constraints
• Reusable infrastructure for future upload risk analysis

[vercel]

@YLaxmikanth is attempting to deploy a commit to the magic-peach1's projects Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

👋 Thanks for your PR, @YLaxmikanth!

Welcome to Reframe — a browser-based video editor built for everyone 🎬

🟠 GSSoC'26 PR detected — thanks for contributing under GirlScript Summer of Code 2026!

What happens next

1. 🤖 Automated checks — build & TypeScript typecheck will run automatically
2. ✅ Vercel preview — a preview deployment will be created (requires maintainer authorization for fork PRs)
3. 👀 Code review — a maintainer will review your changes
4. 🚀 Merge — once approved, your PR will be merged!

Quick checklist

• PR title follows Conventional Commits (e.g. feat: add dark mode)
• Linked the issue this PR closes (e.g. Closes #123)
• Tested the changes locally (bun run dev)
• Build passes (bun run build)

Useful links

• 📖 CONTRIBUTING.md
• 🐛 Open Issues
• ⭐ Star the repo to support the project!

Happy coding! 🎉

[github-actions]

✅ PR Format Check Passed — @YLaxmikanth

Basic format checks passed. A maintainer will review your code changes.

This does not mean the PR is approved — it just means the format is correct.