[camera] add custom path ouput to recording

[Mairramer]

This PR introduces the ability to save videos to custom locations, taking into account the limitations and behavior of each platform.

Due to platform-specific security restrictions and limitations:

• On Android, I was able to save videos directly to /storage/emulated/0/Download/video.mp4 without issues.
• On iOS, I was able to save videos to On My iPhone -> Camera Example -> Movies.
• On Windows, the behavior is similar to Android.

Closes flutter/flutter#91680

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[Mairramer]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for a custom videoOutputPath to the startVideoRecording API across Android, iOS, Windows, and Web platforms. The changes include updates to the camera_platform_interface, native implementation logic for path validation, and a new interactive example app. Technical feedback identifies several improvement opportunities: the Android example should use path_provider instead of hardcoded paths, and the UI should be updated to reflect that content:// URIs are not supported. Additionally, the reviewer recommended properly managing TextEditingController lifecycles, using locale-aware string conversions in Java, fixing a potential logic error in the Swift path validation, and integrating the new demo into the existing example app structure rather than replacing the main entry point.

[Mairramer]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for a custom videoOutputPath in the startVideoRecording method across the Android, iOS, and Windows implementations of the camera plugin. The changes include updates to the platform interface, implementation of path validation logic on both Dart and native sides, and the addition of a new example demonstrating the feature. Feedback identifies that the web implementation currently ignores the new parameter and that the example UI documentation incorrectly suggests support for multiple file extensions despite the implementation strictly enforcing .mp4. Additionally, inconsistent SDK and Flutter version constraints were noted in the web package compared to other packages in the pull request.

[Mairramer]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds support for a custom video output path (videoOutputPath) to the startVideoRecording method across the Flutter camera plugin and its federated platform implementations (Android, iOS, and Windows). It includes platform-specific validation logic to ensure output paths are not directories, have valid parent directories, and end with the .mp4 extension. Additionally, a comprehensive video recording example app has been added to demonstrate this feature. Feedback on the changes highlights a type mismatch in the example app's validation helper, potential memory leaks from unhandled asynchronous initialization when widgets unmount, and a bug in the Windows path parsing logic when a parent directory contains a dot.

[gemini-code-assist]

Code Review

This pull request adds support for a custom videoOutputPath to the startVideoRecording method across the federated camera packages, including Android, iOS, Web, and Windows implementations. It updates the platform interface, implements platform-specific path validation, adds unit and integration tests, and introduces a new video recording example app. The review feedback highlights three key improvements: ensuring the previous CameraController is properly disposed in the example app to prevent resource leaks, correcting path generation logic in the example app for Android and iOS, and deleting any pre-existing file at the destination path on iOS to prevent AVAssetWriter initialization failures.

[bparrishMines]

@Mairramer What's the use case you want to solve by adding this feature? From my understanding, it should currently be possible for the app to rename the file to change it's location without copying.

The issue linked mentions being able to save to an external SD card and finding the file if the app crashes during recording, but I dont think this PR would fix these.

[Mairramer]

@Mairramer What's the use case you want to solve by adding this feature? From my understanding, it should currently be possible for the app to rename the file to change it's location without copying.

The issue linked mentions being able to save to an external SD card and finding the file if the app crashes during recording, but I dont think this PR would fix these.

Thanks for the review!
I get your point about rename, but the main issue here is cross-filesystem moves.

If we record a video to the internal cache and then try to rename() it to an external SD card, the OS can't just move the file pointer. It's forced to do a full byte-by-byte copy and delete. For large videos, this causes a huge I/O bottleneck and temporarily doubles the storage space needed (which can fail if internal storage is low). Writing directly to the target path avoids this completely.

Regarding the SD card: apps still have direct write access to their app-specific folders on external SD cards (for example, the second directory returned by getExternalStorageDirectories() in path_provider). By using videoOutputPath, we can record straight to the SD card from the start and bypass internal storage limits altogether.

Regarding the crash recovery scenario mentioned in flutter/flutter#91680, you're absolutely right that the MP4 may end up corrupted after a crash, especially if the final moov atom was never written.

The main issue today is that the native layer generates a random temporary filename, and Dart only receives that path after stopVideoRecording completes successfully. If the app crashes before that happens, the temporary file becomes orphaned and the application has no reliable way to discover or identify it afterward.

By providing the output path upfront, the application always knows where the recording is being written. After a restart, developers can at least locate the interrupted file, attempt MP4 recovery if possible, or simply clean up the orphaned file to avoid unnecessary storage leaks.

Let me know if this makes sense or if I should adjust anything in the implementation.

[Mairramer]

Regarding crash recovery:

On iOS, we could use movieFragmentInterval, which allows the movie file to be fragmented periodically and can help reduce data loss in crash scenarios.

On Android, as far as I know, there is no equivalent native solution available. We would probably need a custom implementation using MediaMuxer or something similar to periodically fragment or remux the recording stream, but that’s not something I’d really like to introduce at the moment.