LiteCut：长视频快剪，不追求帧精确，追求导出够快

LiteCut长视频快剪不追求帧精确追求导出够快LiteCut 的出发点很简单对一小时以上的长视频来说早一两秒、晚一两秒很多时候不重要。真正重要的是导出不要慢。所以 LiteCut 不把目标设成“手机上的专业剪辑软件”而是设成一个更锋利的小工具基础切割、复制、删除、排序单轨时间线能看懂片段预览要马上出声音、出画面导出尽量走 stream copy不为帧级精度付出重编码成本。核心取舍牺牲一点边界精度 - 避免重编码 - 长视频导出更快关键 idea用 GOP 边界换速度视频不是每一帧都能便宜地独立切开。大多数压缩视频由 GOP 组成关键帧可以独立解码非关键帧依赖前后帧。如果硬要按任意一帧精确切通常就要重编码。LiteCut 反过来把用户选择的时间点对齐到可 stream-copy 的关键帧边界。用户点的是“大概从这里开始”。LiteCut 真正导出时会做这种转换用户选择点 - 查找附近关键帧 - 扩展到安全范围 - ffmpeg -c copy这不是 bug这是产品定位。对于长视频快剪场景1 秒边界误差往往比 10 分钟导出等待更可接受。OpenSpec 怎么帮我们把 idea 做出来这次最有价值的不是“写了一堆文档”而是 OpenSpec 让我们一直守住边界。我们把开发拆成三个 changeChange解决的问题结果litecut-mvpAndroid 文件访问、FFmpegKit、stream-copy 计划跑通无损导出核心android-editor-timeline-ui中文时间线、片段选择、切割复制排序从工具变成可用 Appandroid-preview-timeline-polish长视频黑屏、缩略图、缩放滚动、时间映射真机上可预览、可导航OpenSpec 在这里的作用是每一步先写清楚目标和非目标每个 change 都有任务清单和验收发现问题时回到 spec而不是凭感觉乱改明确“不做什么”避免变成另一个大而全的视频编辑器。最重要的非目标不做帧精确 不默认重编码 不做滤镜/转场/多轨 不做逐帧缩略图这让 LiteCut 的方向一直很清楚快剪不是精剪。App 架构只保留必要复杂度实现上只保留几条主线Android 系统选择器导入 URI立即用 ExoPlayer TextureView 预览后台复制到 app 私有 workspaceffprobe 读取时长和关键帧TimelineProject 管理片段和 source-time 映射Thumbnail 只做稀疏生成ExportPlanner 生成-c copy命令FFmpegKit 执行并发布结果。这套架构的重点不是复杂而是把“不重编码导出”这件事保护好。一次关键调试有声音但黑屏长视频导入后声音马上出来但预览区域黑屏。一开始容易怀疑视频解码失败。logcat 反而说明硬解码器在工作render fps 正常SurfaceView 在 queue buffer本地抽帧不是黑图。结论不是视频没解码而是VideoView/SurfaceView在这个布局里显示路径不可靠。最后改成VideoView - Media3 ExoPlayer TextureView预览黑屏解决。这个细节很关键因为 LiteCut 不是只会导出真机上也必须能马上预览长视频。为什么这个项目有意思很多视频工具默认追求“更专业”更精确、更复杂、更多效果。LiteCut 追求的是另一个方向足够准确 极快导出 长视频友好它适合这种人手上有很长的视频只想剪掉开头结尾或整理几个片段不想等手机重编码接受边界粗一点但不能接受导出慢。这就是 LiteCut 的价值。开源项目仓库gh repo clone STEPHENXING/LiteCut-android仓库只包含 LiteCut Android 项目本身。OpenSpec 的 proposal、tasks、change 等开发过程材料没有混进代码仓库。LiteCut 现在还是 MVP但方向已经很明确不是做一个小剪映而是做一个长视频快剪工具。