[Feature] Non-destructive in-app video trim

[hitzhangjie]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

Related but different:

• #15942 is about video rotation / a general in-app editor; trim is only mentioned as an optional extra.
• #22468 and #27810 are about sharing a clip as a new file. Maintainers noted that minting a new video for sharing is a different (and heavier) problem.
• #21405 / #11512 asked for an ffmpeg GUI; that is explicitly out of scope, and this request is not that.

This is a single, narrower feature: non-destructive trim for videos already in the library, in the same spirit as the existing photo editor.

The feature

Problem

A lot of uploaded videos have a few seconds of intro or outro that make playback awkward, and the auto-generated cover often lands on a black or otherwise useless frame. Today the realistic options are:

1. Download → edit elsewhere → re-upload (duplicate file, lost albums/metadata).
2. Overwrite the original (no restore, not acceptable for a photo library).

Apple Photos solves this with a soft trim: playback and the cover use the kept range, the original file stays on disk, and restore is one tap. Optionally you can “save as a new video” if you really want a real file.

Immich already has this model for photos (asset_edit for crop / rotate / mirror, isEdited, restore by deleting edit rows, download original). Videos do not.

Ask

Add a Trim action on video assets:

1. Save (default, non-destructive)
   Persist { startTime, endTime } as a trim edit. Do not rewrite originalPath. Playback starts at startTime and stops at endTime. After save, the viewer progress bar is the clipped duration (0 → end − start), like Apple Photos. The trim editor still shows the original duration and handles. Generate the edited thumbnail/preview from startTime. Restore = delete the trim edit.

2. Save as new video (optional)
   An ffmpeg job writes a new asset; the original is unchanged. Default to stream copy (fast; may snap to keyframes). Optional frame-accurate re-encode.

Out of scope: a general video editor, an ffmpeg settings GUI, sharing a fragment via a special shared-link type, or destroying the original file.

UX sketch

• Viewer toolbar action (scissors). After a soft trim, keep the same icon and distinguish it with color + label (e.g. “Trimmed (original kept)”), so it is obvious the original file is still stored and can be restored or downloaded.
• Trim sheet: drag start/end handles on the original timeline (not numeric intro/outro fields).
• After save, scrubbing the viewer must not jump back to the cut-in point when the user seeks to a time that is before the cut on the original clock. Map display time ↔ file time in the player only.
• “Play original” / “Download original” stay available, same as photo edits.

Implementation sketch (fits the current photo-edit pipeline; no new table)

• Reuse asset_edit: action: 'trim', parameters: { startTime, endTime } (jsonb). Existing insert/delete triggers already maintain asset.isEdited.
• POST /assets/:id/trim with saveAsNew and accurate.
• Soft save: replace the asset’s edits with that one trim row, then queue edited thumbnail generation with seek = startTime.
• Hard export: job writes a new asset in the upload folder, copies album membership, queues metadata extraction.
• Web player: displayTime = currentTime - startTime, seek = startTime + displayTime, duration = end − start. HLS/startLoad still use file time. Trim modal stays on file time.
• Mobile can follow later; web + server is enough for the first cut.

Happy to follow up with a PR if this direction is acceptable. I have a working prototype of this approach here for reference: https://github.com/hitzhangjie-forks/immich/tree/feat/cut_video

Platform

• Server
• Web
• Mobile

[bo0tzz]

#6252