AddThisFeature

Video Upload and Encoding

Accept a video file and turn it into versions that play in a browser.

involved Media & Video

What it adds

An upload path for video files plus a background pipeline that produces web-playable renditions and a poster frame.

What your agent is told to do

5
  1. 1

    Extend the app's existing File Upload rather than adding a second uploader. Video differs in size and in the processing that follows, not in how a user picks a file, and two uploaders means two sets of limits to keep in sync.

  2. 2

    Upload in resumable chunks straight to storage, and enforce size, duration, and type limits on the server. Client-side limits are a convenience, not a control.

  3. 3

    Do the encoding in the app's existing background job system so the user is not holding a tab open, and surface its state through the app's existing Background Job Progress rather than a bespoke poller.

  4. 4

    Produce the minimum coherent set of outputs: one or two web-playable renditions covering a small and a large screen, plus a poster frame. Do not build a general-purpose adaptive ladder until someone is actually watching on a bad connection.

  5. 5

    Run whatever content scanning the app already applies to uploads, including Upload Malware Scanning if present, before any output becomes reachable. A video is a container format and is a perfectly good delivery mechanism for something else.

Edge cases it handles

8
  • Large files will be interrupted by dropped connections, closed laptops, and mobile handoffs. Support resuming an interrupted upload from where it stopped rather than restarting a multi-gigabyte transfer.
  • Upload, queue wait, and encode are three different stages with different durations, and a single bar that sits at ninety-nine percent through a long encode reads as broken. Show which stage the job is in and what is still to come.
  • Plenty of common recordings use codecs or containers browsers will not play, and some files are simply corrupt. Detect this before encoding, transcode where you can, and reject with a specific message where you cannot.
  • A failed or cancelled job leaves a source file and partial outputs behind. Clean both up on failure and sweep for orphans on a schedule, or storage cost grows quietly forever.
  • Cap concurrent jobs per account so one person uploading fifty videos cannot starve every other tenant's queue, and make the queue position visible when a job is waiting.
  • Decide who is allowed to read a finished video back, and enforce it on the delivery path. If the app has Secure File Downloads, route playback through the same signed, expiring access rather than leaving outputs on a guessable public address.
  • A user who navigates away mid-upload needs a warning, and the partial upload needs an expiry so abandoned chunks do not accumulate.
  • Retention matters. Decide whether the original source file is kept after encoding, say so, and apply the same deletion rules to renditions when the record is deleted.

Definition of done

9
  • Uploads are chunked, resumable, and validated for size, duration, and type on the server.
  • Encoding runs as a background job with visible upload, queue, and encode stages.
  • Unplayable formats are detected before encoding and either transcoded or rejected with a specific reason.
  • Failed and cancelled jobs leave no orphaned source files or partial outputs.
  • Concurrent jobs are capped per account and queue position is visible.
  • Finished videos are readable only by users permitted to see the owning record.
  • Every upload passes the app's existing content scanning before its outputs are reachable.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.