an editor spends most of their time deciding where to cut. cineflow reads the footage and
proposes those points, then hands them back fast enough to feel like part of the timeline.
1st place at the adobe express hackathon.
the output is a list of timestamps, not a rendered video. the editor keeps the last word.
the problem
cut detection models are usually trained to find hard scene changes, which is a different
question from where a cut belongs. a hard change is a fact about pixels. a good cut is a
fact about motion, framing, and pacing, and it often sits a few frames off the obvious one.
23% higher f1 than a c3d baseline on the same held-out clips.
how it works
a vision transformer fine-tuned on 10,000 clips in tensorflow, trained on human cut
points rather than on scene-change labels, so it learns where editors actually cut.
opencv does the frame work: decode, sample, and normalize before anything reaches
the model, which keeps the expensive part small.
served as a gpu-backed microservice on aws lambda with efs holding the weights, so a
cold start does not pay to download the model.
sub-250ms inference on 1080p footage, which is the budget that lets a react timeline
ask for suggestions while the user is still scrubbing.
what it means
the accuracy number matters less than the latency one. a suggestion that arrives after the
editor has already made the cut is worth nothing, so the whole design is bent around
answering before they finish moving the playhead.