YouTube A/B test video cuts. Make 3 hooks from one encode.

YouTube is about to let you upload three cuts of the same video and find out which opening keeps people watching. The production question landed before the feature did: how do you produce three files that are identical except for the first three seconds, without cutting the same video three times on a timeline?

Quick answer: To make three versions of one video with different hooks for YouTube A/B test video cuts, encode the body once, render each hook as its own short clip with matching codec, resolution, frame rate and audio settings, then join hook plus body with FFmpeg's concat demuxer using -c copy so the body stays byte-identical across all three files. By hand that's three renders and three chances for the encode to drift. Sent to the FFmpeg Micro API as the same job three times with only the hook text changed, it's three upload-ready cuts from one master, with no encoder to install and no render queue to babysit.

What YouTube announced, and what it asks you to produce

At Made on YouTube on September 23, 2026, YouTube said creators will be able to test up to three video cuts to see which hook performs best, with Studio reporting per cut. It's "coming soon" with no launch date, and TechCrunch reports it starts with Shorts and arrives from 2027.

A Creator Insider demo published September 25, 2026 showed alternative cuts of one upload getting watch-time retention curves for each, the example being a cut that opens on a dramatic reaction against one that opens on an unhinged question. The judged signal is watch time, not click-through rate, a change from the title and thumbnail Test & Compare system this extends, which requires YouTube Partner Program membership.

Nothing in the announcement says what has to stay the same between cuts. Isolating the hook is your job, not YouTube's.

Re-encoding the whole file per cut is what breaks the test

Drop three different hooks onto a timeline and export three times, and the encoder runs over the entire video three times. Rate control makes different decisions in each pass, bitrate lands elsewhere, and the body is not the same body anymore. You set out to test two hooks and ended up testing two encodes.

That matters at the margins where these tests get decided. A cut that holds 41% at the 15-second mark against one that holds 38% is a result you'd act on, and a few hundred kbps in the body can move it.

The fix is structural. Encode the body exactly once, keep it as a fixed asset, and treat the hook as a separate layer that gets joined on. FFmpeg's concat demuxer with -c copy copies packets without touching them, so the body in cut A, cut B and cut C is the same bytes. Not similar. The same. A timeline editor can't guarantee that, because every export re-runs the encoder.

Stream-copy concatenation only works when every input shares codec, resolution and frame rate, so the hook clips have to be built to match the body's spec, not the other way around.

Build the three cuts from one master

Three commands: one for the body, one per hook. Assume a 9:16 Short at 1080x1920, 30 fps, with a three-second hook window.

Cut and pin the body

The body is everything after the hook window, with every parameter stated explicitly so it's reproducible:

ffmpeg -ss 3 -i master.mp4 \
  -vf "scale=1080:1920" -r 30 -pix_fmt yuv420p \
  -c:v libx264 -preset slow -crf 20 \
  -c:a aac -b:a 128k -ar 48000 -ac 2 \
  -movflags +faststart body.mp4

Don't use -c copy here. Under stream copy, trim points land on the nearest keyframe rather than the timestamp you asked for, so -ss 3 can hand you a body that starts at 2.4 seconds. Re-encoding once gets you a frame-accurate cut and a known spec, and it's the only time the body gets encoded.

Render one hook clip per variant

Each hook is a three-second clip matching body.mp4 on codec, resolution, frame rate, pixel format, audio codec, sample rate and channel count. Burning hook text onto the master's own opening looks like this:

ffmpeg -i master.mp4 -t 3 \
  -vf "scale=1080:1920,drawtext=fontfile=/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf:\
text='I deleted 40 hours of footage':fontsize=64:fontcolor=white:\
box=1:boxcolor=black@0.6:boxborderw=20:x=(w-text_w)/2:y=h*0.18" \
  -r 30 -pix_fmt yuv420p \
  -c:v libx264 -preset slow -crf 20 \
  -c:a aac -b:a 128k -ar 48000 -ac 2 \
  hook_a.mp4

Run that three times with three different text= values. Escape colons and apostrophes inside the text or drawtext will fail to parse the filter string.

Join each hook to the same body

Write a concat list per variant and copy the streams through:

printf "file 'hook_a.mp4'\nfile 'body.mp4'\n" > cut_a.txt
ffmpeg -f concat -safe 0 -i cut_a.txt -c copy cut_a.mp4

Three list files, three -c copy joins, three uploads. Verify with ffprobe -v error -show_entries stream=codec_name,width,height,r_frame_rate,sample_rate -of csv cut_a.mp4 across all three files. If anything differs, the join re-encoded something and the guarantee is gone.

Prepend a hook clip, or burn text on the existing opening?

Burning different text onto the master's own first three seconds is the tighter experiment: the footage, audio and framing are held constant and only the words move, so a retention difference is attributable to the copy. Prepending a separately shot hook clip tests a stronger variable, the whole opening moment, which is what Creator Insider demoed. Pick based on whether the footage changes.

Hook-variant testing is already routine in paid social: one shoot, the body held constant, only the first three seconds changed, so the shoot cost divides across every variant. Organic Shorts is getting the same mechanic.

Keep the hook window the same duration in all three cuts either way. If hook A is 3 seconds and hook B is 5 seconds, every point on the retention curve is shifted by 2 seconds and the curves aren't comparable.

The same job three times, as one API call

Three renders per upload, two or three uploads a week, is roughly 400 renders a year of a job that never changes shape. That's a loop, not an editing session. In n8n, Make or Zapier it's one HTTP Request node inside an iterator over three items; in code it's a for loop over an array of hook strings. The job body is the same every time with one field different:

{
  "input": "https://cdn.example.com/master.mp4",
  "args": "-i {{input}} -t 3 -vf scale=1080:1920,drawtext=text='HOOK_TEXT':fontsize=64:fontcolor=white:box=1:boxcolor=black@0.6:x=(w-text_w)/2:y=h*0.18 -r 30 -pix_fmt yuv420p -c:v libx264 -crf 20 -c:a aac -b:a 128k -ar 48000 -ac 2 {{output}}",
  "webhook": "https://your-n8n-host/webhook/hook-variant-done"
}

Submit, get a job id, receive the webhook, download the file. The full parameter list is in the docs, and reliable pipeline patterns for long-running video jobs covers retry and idempotency on the callback side. Run it this way rather than shelling out to a local binary, because n8n disabled the Execute Command node on Cloud, so an HTTP call is the only route that works on a hosted instance.

If you'd rather not assemble the loop, the Text Hook Variants blueprint is this pipeline as one upload: give it a master file and up to three hook lines, get back three files where only the burned-in hook changes. Same body-pinned concat, minus the list files.

Pitfalls that cost you the test

Most of what goes wrong here is quiet. The files render, they upload, and the result means nothing.

When three cuts aren't the right move

Hook variants are worth building when the body is already good and the drop-off is in the first five seconds. If retention falls off a cliff at 40 seconds, three openings won't fix it.

Hook variants also aren't an editing tool. If the three versions need different pacing, different b-roll, or a restructured middle, that's three different videos and you want a timeline. The programmatic path only pays when the variants are mechanically identical below the hook.

The same three cuts transfer to paid testing, with one caveat: Meta and TikTok placements want ratios YouTube Shorts doesn't, so run each winner through a reframe step. Meta ads video specs from one master file covers that pass.

FAQ

Does YouTube A/B testing of video cuts work for long-form, or just Shorts?

YouTube's three-cut testing starts with Shorts per TechCrunch's September 23, 2026 reporting, and long-form isn't confirmed. Build your hook-variant pipeline against a 9:16 1080x1920 Short for now, since the same body-pinning technique applies unchanged if the feature reaches 16:9 long-form.

How many views does a cut test need before the winner means anything?

A video cut test needs roughly two weeks of run time and something near 10,000 views before the watch-time difference between cuts is usable, based on the thresholds for YouTube's existing Test & Compare system. Below that, the retention curves overlap enough that you're reading noise.

What exactly should change between the three versions?

Change only the opening hook: the on-screen text, the spoken line, or the first shot, inside a fixed window of three to five seconds. Everything after that window stays identical in content and in encode, and so do the title and thumbnail. Each extra variable splits the same view volume across more unknowns.

Can I make multiple versions of one video without a video editor?

You can produce multiple versions of one video from a script or an automation workflow, no editor involved. FFmpeg's drawtext filter burns different hook text onto a copy of the opening, the concat demuxer joins each hook to one pre-encoded body with -c copy, and an HTTP node in n8n, Make or Zapier runs that job once per variant.

What metric does YouTube Studio report for each cut?

YouTube Studio reports watch-time performance per cut, shown as a retention curve for each version, per the Creator Insider demo published September 25, 2026. That's a shift from title and thumbnail tests, judged on click-through rate, so a cut that wins on hook retention wins on the metric the feature optimizes.

Three hooks, one body, three files that differ in nothing else. Sign up free and run the first variant against a real master before the feature ships, so your pipeline is producing cuts the day Studio starts asking for them.