Six-Minute Sports Video on an 8 GB Laptop
A Year 12 class is producing a six-minute promotion video for the school's winter sports exchange. Footage comes from two phones and one DSLR: 42 GB of 4K files plus some 1080p60 slow-motion clips. Editing is on the school's media laptops - 8 GB RAM, integrated graphics, 256 GB SSD, DaVinci Resolve (free version). On the timeline playback stutters and the program crashes when the class adds a third video track. The best interview has audio that clips on the loudest words, with wind noise underneath; two clips were shot at 25 fps and the rest at 30 fps. The class wants to use a well-known chart song from a streaming service as the backing track. The final video must be under 100 MB for the school website, play smoothly on a five-year-old phone, and a 1080p copy is needed for assembly next Friday.
1. Explain the cause of the stuttering playback and describe a workflow that would make the edit workable on these laptops.
Read the worked answer
The stutter is a decode problem before it is a storage problem. Phone 4K is long-GOP H.264/H.265 at high bitrate; every frame requires heavy CPU work to decode, and 8 GB of RAM with integrated graphics leaves little headroom when three 4K tracks plus effects are live. Resolve crashes when the CPU/GPU queue and memory run out.
Workflow fix:
- Copy all media to an external SSD, not the 256 GB boot drive, and keep project and cache off the system disk.
- Generate proxies: 1080p (or 960×540) ProRes Proxy or DNxHR LB, matched frame rate and timecode. Editing uses proxies; export relinks to the originals automatically.
- Set the timeline to 1080p. A 4K timeline is pointless when delivery is 1080p web.
- Enable render cache for effect-heavy sections and render in place any nested compound clips.
- Conform frame rates: edit the 25 fps clips in a separate 25 fps sequence and convert on export, or normalise before editing - mixed rates on one timeline cause judder as well as slowness.
- Split the edit into sequences by section instead of one six-minute timeline with many tracks.
Trade-off: proxies cost about an hour of transcoding and extra disk space. That is far cheaper than repeatedly losing work to a crash.
2. Address the music choice and the audio problems, explaining what can be fixed and what cannot.
Read the worked answer
Music. The chart track cannot be used on a video published to the school website. The Copyright Act 1994 gives the composer and the recording owner exclusive rights, and a streaming subscription grants listening only - the terms exclude synchronising the track with video. There is no general 'educational fair use' in New Zealand; the narrow exceptions (criticism or review, performance in class) do not cover publishing online. Using it risks a takedown and puts the school in the wrong.
Alternatives, in order of preference: a Creative Commons track (CC BY requires crediting the artist in the description), a purchased licence from a production music library, or an original track from a student musician with written permission. Record the licence, source URL and attribution in the project notes whichever is chosen.
Audio. Clipping is distortion created at the recorder and cannot be undone - check whether a phone backup of the same interview is clean; if not, re-record or use a different take. Wind noise can be reduced with a high-pass filter around 80–100 Hz plus gentle denoise, but not removed. Judge whether the interview is salvageable before building the edit around it. Normalise the final mix for web to roughly −14 LUFS with true peaks under −1 dBTP.
Consent also matters: get signed permission from identifiable students before publishing.
3. Recommend export settings for the web copy, showing the calculation behind the bitrate.
Read the worked answer
Work back from the constraints.
File size: 100 MB = 800 megabits. Six minutes = 360 s. Total bitrate ≈ 800 ÷ 360 ≈ 2.2 Mbps. Reserve 128 kbps for AAC stereo audio, leaving about 2.0 Mbps for video.
At 2 Mbps, 1080p is tight for fast sport - grass and crowd detail smear into mush. Two defensible options:
- 720p H.264 at ~2 Mbps: safer for a five-year-old phone and looks cleaner per bit.
- 1080p at ~2 Mbps with a slower preset (two-pass or CRF 23), then check the actual file size; if it exceeds 100 MB, raise CRF or drop to 720p.
Settings for either: MP4 container, H.264 High profile (level 4.0 for broad device support), yuv420p chroma, web-optimised/'fast start' so it streams before full download, audio AAC-LC 128 kbps at 48 kHz.
Verify, don't assume: read the real bitrate and size in MediaInfo, then play the file on the actual old phone over the school's wifi. If it stutters there, the problem is your bitrate and resolution, not the phone.
Keep the assembly copy separate at a higher bitrate (8–10 Mbps) - different audience, different export settings.