✨ Add support for Fast-Start MP4 (moov atom at beginning) for streamable video

[johan149]

What feature or enhancement are you suggesting?

🚀 Feature Request: Fast-Start MP4 Support

Summary It would be highly beneficial if VisionCamera could support saving recorded .mp4 files with the moov atom placed at the beginning of the file, also known as “fast-start” or "streaming optimized" MP4.

Currently, VisionCamera outputs .mp4 files where the moov atom is placed at the end. This makes the videos less ideal for streaming scenarios, especially when hosted on cloud storage/CDNs like Cloudflare R2, S3, or Firebase Storage, where clients expect to start playback using partial HTTP range requests.

🔍 Why This Matters Many modern apps (TikTok, Instagram Reels, YouTube Shorts, etc.) record and upload short videos that are streamed by end-users. These videos are often hosted on object storage with CDN caching and delivered progressively.

To allow instant playback, especially over slow networks or mobile connections, it is crucial that:

• The moov atom is written at the beginning of the file.

• The video file is playable before the full download finishes.

• Video players can issue a Range: bytes=0-XXXXX request and start playing immediately.

Without fast-start optimization, clients may have to download the entire video or at least the tail to locate the moov atom, causing slow playback and unnecessary data usage.

✅ What We’d Like An option in startRecording() to enable fast-start .mp4 output. For example:

camera.current.startRecording({
  fileType: 'mp4',
  optimizeForNetworkUse: true, // <-- new option
  ...
});

This would internally set shouldOptimizeForNetworkUse = true (on iOS), or an equivalent setting using MediaMuxer.setOrientationHint(...) and MediaMuxer.writeSampleData(...) correctly on Android.

📱 Platform-Specific Implementation Notes

• iOS (AVFoundation):

  • AVAssetExportSession or AVAssetWriter supports shouldOptimizeForNetworkUse = true.

  • This flag causes the moov atom to be placed at the beginning of the file.

• Android (MediaMuxer):

  • While not a built-in “fast start” flag, the way MediaMuxer writes metadata can be adjusted so that moov comes first (some apps post-process using FFmpeg for this).

Even a post-processing hook after stopRecording() that runs a native remux (without transcoding) would be acceptable if real-time writing isn't feasible yet.

📦 Current Workaround We currently use FFmpeg (ffmpeg-kit-react-native) to re-mux the file:

ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4

But this adds complexity, processing time, battery drain, and app size (~40MB for ffmpeg-kit).

🤝 Who This Benefits Any app uploading videos to a CDN or object storage (e.g. Cloudflare R2, S3)

Apps aiming for TikTok/Reels-like UX with vertical feeds

Any dev trying to reduce delay between video loading and playback

🧩 Related Context This request is common in the streaming/content-creation world. Apps like TikTok serve fast-start MP4s or HLS with short segments. Adding this support will help bridge the gap between local recording and cloud streaming workflows.

What Platforms whould this feature/enhancement affect?

iOS, Android

Alternatives/Workarounds

📦 Current Workaround We currently use FFmpeg (ffmpeg-kit-react-native) to re-mux the file:

ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4

Additional information

• [x] I agree to follow this project's Code of Conduct
• [x] I searched for similar feature requests in this repository and found none.

[maintenance-hans[bot]]

Guten Tag, Hans here. This is a well-written and detailed feature request! 🎉 Implementing fast-start MP4 support could indeed enhance the video playback experience for many apps.

I will leave this open so that mrousavy can take a look when he has time. If you have any further questions or need updates, feel free to follow up here. Danke for your contribution!

Note: If you think I made a mistake, please ping @mrousavy to take a look.