Distribution: Adapting to Multiple Platform Specs, Generating Covers and Titles, Batch Export, and Feeding Data Back

Render once, package many times

Of course not. But explaining why requires separating two words people conflate.

Transcoding decodes the video and re-encodes it, actually recompressing the picture data. Muxing (or remuxing) merely repacks an already-encoded bitstream into a different container, touching not one byte of picture data. In kitchen terms: transcoding re-cooks the dish, muxing serves the same dish on a different plate.

Why does the difference matter? Two reasons. First, time — re-encoding a vertical clip takes seconds to tens of seconds; changing containers takes tens of milliseconds. Second, and more importantly, lossy encoding loses quality on every pass. Your master is already the result of one encode after generation; transcoding once per platform means the audience sees doubly compressed picture. That shows most in dark areas and fast motion — and short drama is full of rainy nights and tracking shots.

So the correct shape is render once, package many times: encode exactly once when producing the master, and make every platform export a stream copy where possible.

# Join shots into the master: identical encoding parameters, stream copy, no recompression
ffmpeg -f concat -safe 0 -i concat.txt -c copy master.mp4
 
# Platform export: change the container, add faststart, still no re-encode
ffmpeg -i master.mp4 -c copy -movflags +faststart episode-1.tiktok.mp4
 
# Over-length needs no re-encode either: -t together with -c copy cuts directly
ffmpeg -i master.mp4 -c copy -t 600 episode-1.trimmed.mp4

When is re-encoding actually required? Only when the master's picture data itself fails a requirement: out-of-range resolution needs scaling, an unaccepted codec needs a different encoder, an out-of-range frame rate needs conversion, an oversized file needs a lower bitrate. Everything else — container changes, faststart, truncation by duration — can be stream-copied.

Write that judgment as a function whose return value is not only "re-encode or not" but also the reason for every decision, or nobody will know afterwards where the conclusion came from:

function decidePackaging(master, spec) {
  const checks = []
  const manualChecks = []
  const extraArgs = []
  let reencode = false
 
  // Unknown-spec platforms: guess nothing, stream-copy as is, hand verification to a human
  if (spec.sourceOfTruth === 'check-your-console') {
    checks.push('spec unknown: stream-copying the master as is')
    manualChecks.push(`${spec.name}: verify against the console spec page before uploading`)
    return { action: 'copy', checks, extraArgs, manualChecks }
  }
 
  const long = Math.max(master.width, master.height)
  const short = Math.min(master.width, master.height)
  if (short < spec.minSidePx || long > spec.maxSidePx) {
    checks.push(`side lengths ${short}-${long} out of range, scaling required`)
    reencode = true
  }
  if (master.videoCodec !== spec.videoCodec) {
    checks.push(`codec ${master.videoCodec} is not the recommended one, re-encode required`)
    reencode = true
  }
  if (master.durationSec > spec.maxDurationSec) {
    // Over-length truncates with -t under stream copy; this is the most misjudged case
    checks.push('duration over limit: truncating with -t under stream copy, still no re-encode')
    extraArgs.push('-t', String(spec.maxDurationSec))
  }
  return { action: reencode ? 'reencode' : 'copy', checks, extraArgs, manualChecks }
}

def decide_packaging(master, spec):
    checks, manual_checks, extra_args = [], [], []
    reencode = False
 
    # Unknown-spec platforms: guess nothing, stream-copy as is, hand verification to a human
    if spec["source_of_truth"] == "check-your-console":
        checks.append("spec unknown: stream-copying the master as is")
        manual_checks.append(f"{spec['name']}: verify against the console spec page before uploading")
        return {"action": "copy", "checks": checks, "extra_args": extra_args,
                "manual_checks": manual_checks}
 
    long_side = max(master["width"], master["height"])
    short_side = min(master["width"], master["height"])
    if short_side < spec["min_side_px"] or long_side > spec["max_side_px"]:
        checks.append(f"side lengths {short_side}-{long_side} out of range, scaling required")
        reencode = True
    if master["video_codec"] != spec["video_codec"]:
        checks.append(f"codec {master['video_codec']} is not recommended, re-encode required")
        reencode = True
    if master["duration_sec"] > spec["max_duration_sec"]:
        # Over-length truncates with -t under stream copy; the most misjudged case
        checks.append("duration over limit: truncating with -t under stream copy, no re-encode")
        extra_args += ["-t", str(spec["max_duration_sec"])]
    return {"action": "reencode" if reencode else "copy", "checks": checks,
            "extra_args": extra_args, "manual_checks": manual_checks}

The lab prints an encode tally: shots encoded 3 times (the master's raw material), re-encodes 0, stream-copy packagings 4, alongside "the naive approach would re-encode 3 times." Covers follow the same idea: all three platforms want a vertical cover, so grab the frame once and copy it three times rather than grabbing three frames.

Covers and titles: let the model produce candidates in bulk

With the cut ready, the two things that decide the click rate come next: the cover and the title.

They differ fundamentally from video: video is expensive and slow; cover copy is cheap and fast. One video generation costs a few yuan and a few minutes; one text call costs a few cents and a few seconds. Two things three orders of magnitude apart in price deserve completely different strategies — video wants "get it right the first time," copy wants "make several and choose."

So the correct shape here is not "have the model write the best title" but have it write one per angle. The lab fixes five: suspense, contrast, identity, numeric, declarative. Each maps to a different instruction, the model writes one of each, and the next step picks.

The angles are not arbitrary; they come from a plain observation that short-drama titles hook people in only a handful of ways, and enumerating those as templates is steadier than free improvisation. And the angles are a function of the input — each template draws from that episode's storyboard (the lead's name, the first line, the last line), so a different episode changes all five candidates.

One more mandatory step: put a backstop on the model's output. What the model returns may not be printable on a cover — too long, carrying an explanatory preamble, or containing debug markers like brackets. The lab has a usableCoverCopy function for exactly this: reject anything outside the length band, anything containing square, curly or angle brackets, anything hitting a hype word. Rejected output falls back to a local template.

Choose rather than generate: converge with a score

With five candidates, how do you choose?

Not by asking the model which is best. Letting a model grade its own homework has two problems: it is unstable, giving different answers to the same batch on two asks; and it is unexplainable, leaving you unable to justify picking the third one to anyone.

The right approach is a deterministic scoring function. It need not be clever; it only needs to turn your editorial judgment into additive points:

const BANNED = ['best ever', 'number one', 'must watch', 'shocking', 'guaranteed']
 
function scoreTitle(title, ctx, others) {
  const reasons = []
  let score = 0
  const len = [...title].length
 
  // The sweet zone below is measured in characters; tune it to your language and font
  if (len >= 24 && len <= 52) { score += 3; reasons.push(`length ${len} in the sweet zone +3`) }
  else { score -= 2; reasons.push(`length ${len} outside the sweet zone -2`) }
 
  if (/[?…]|isn't|turns out|only|still/i.test(title)) { score += 2; reasons.push('carries suspense +2') }
  if (title.includes(ctx.protagonist)) { score += 1; reasons.push('names a character +1') }
  if (/\d/.test(title)) { score += 1; reasons.push('has a concrete number +1') }
 
  const hit = BANNED.filter((w) => title.toLowerCase().includes(w))
  if (hit.length) { score -= 5; reasons.push(`hype wording ${hit.join(', ')} -5`) }
 
  return { score, reasons }
}
 
// Tie-break by id so two runs pick a byte-identical top three
const top3 = candidates
  .sort((a, b) => b.score - a.score || a.id.localeCompare(b.id))
  .slice(0, 3)

import re
 
BANNED = ["best ever", "number one", "must watch", "shocking", "guaranteed"]
 
 
def score_title(title, ctx, others):
    reasons, score = [], 0
    length = len(title)
 
    # The sweet zone below is measured in characters; tune it to your language and font
    if 24 <= length <= 52:
        score += 3
        reasons.append(f"length {length} in the sweet zone +3")
    else:
        score -= 2
        reasons.append(f"length {length} outside the sweet zone -2")
 
    if re.search(r"[?…]|isn't|turns out|only|still", title, re.I):
        score += 2
        reasons.append("carries suspense +2")
    if ctx["protagonist"] in title:
        score += 1
        reasons.append("names a character +1")
    if re.search(r"\d", title):
        score += 1
        reasons.append("has a concrete number +1")
 
    hit = [w for w in BANNED if w in title.lower()]
    if hit:
        score -= 5
        reasons.append(f"hype wording {', '.join(hit)} -5")
 
    return {"score": score, "reasons": reasons}
 
 
# Tie-break by id so two runs pick a byte-identical top three
top3 = sorted(candidates, key=lambda c: (-c["score"], c["id"]))[:3]

Three details are worth keeping. First, every item writes a sentence into reasons: an unexplained score has no floor, and you cannot tune the rules from it. Second, hype wording is a penalty, not a filter: filtering candidates out can leave you with none in the extreme case, while a heavy penalty puts them last but keeps them in the pool. Third, ties need a tie-breaker — order by id. Without it, tied candidates' relative order depends on the sort implementation, two runs may pick different top threes, and you will blame the model's instability and go tune temperature and prompts in entirely the wrong direction.

The "generate candidates, then score to choose" pattern reaches far beyond titles. It fits any stage whose output is subjective, uncontrollable per call, and cheap: copy, cover composition, cut points, even prompts themselves. Give the uncontrollable part to the model and the floor to the scoring function.

Data feedback: map the retention curve onto specific stages

And after publishing? Most people open the dashboard, look at the numbers, sigh, and shoot the next episode. That is not data feedback; that is spectating.

Data feedback has one criterion: every conclusion must land on a specific stage of the pipeline. A metric that lands on no stage cannot be acted on.

The retention curve suits this naturally, because its x-axis is time and your timeline table records every shot's start and end. Three rules map the curve's three segments onto three stages:

function diagnose(stat, windows) {
  const findings = []
  const at = (sec) => stat.retention.find((p) => p.atSec === sec)?.ratio ?? 1
 
  // First three seconds: the cover and title got them in; the first shot failed to hold them
  const openDrop = 1 - at(3)
  if (openDrop > 0.4) {
    findings.push({ stage: 'cover+titles+frames',
      symptom: `lost ${(openDrop * 100).toFixed(0)}% in the first 3 seconds`,
      action: 'repost with the top-scoring cover and title, and check the first frame carries information' })
  }
 
  // Middle: find the steepest drop between adjacent points and map it back to a shot
  let worst = null
  for (let i = 1; i < stat.retention.length; i += 1) {
    const [prev, cur] = [stat.retention[i - 1], stat.retention[i]]
    if (prev.atSec < 3) continue
    const drop = prev.ratio - cur.ratio
    if (!worst || drop > worst.drop) worst = { drop, from: prev.atSec }
  }
  if (worst && worst.drop > 0.15) {
    const shot = windows.find((w) => worst.from >= w.startSec && worst.from < w.endSec)
    findings.push({ stage: 'clips',
      symptom: `lost ${(worst.drop * 100).toFixed(0)}% mid-episode, inside ${shot.shotId}`,
      action: `shorten ${shot.shotId} or change its camera move, regenerating only that shot` })
  }
 
  // Whole episode: a low completion rate means the ending left no hook, so the script is at fault
  if (stat.completionRate < 0.3) {
    findings.push({ stage: 'script', symptom: 'completion rate too low',
      action: 'give the next episode a cliffhanger ending' })
  }
  return findings
}

def diagnose(stat, windows):
    findings = []
    ratio_at = {p["at_sec"]: p["ratio"] for p in stat["retention"]}
 
    # First three seconds: the cover and title got them in; the first shot failed to hold them
    open_drop = 1 - ratio_at.get(3, 1)
    if open_drop > 0.4:
        findings.append({"stage": "cover+titles+frames",
                         "symptom": f"lost {open_drop * 100:.0f}% in the first 3 seconds",
                         "action": "repost with the top-scoring cover and title, and check the first frame"})
 
    # Middle: find the steepest drop between adjacent points and map it back to a shot
    worst = None
    points = stat["retention"]
    for prev, cur in zip(points, points[1:]):
        if prev["at_sec"] < 3:
            continue
        drop = prev["ratio"] - cur["ratio"]
        if worst is None or drop > worst["drop"]:
            worst = {"drop": drop, "from": prev["at_sec"]}
    if worst and worst["drop"] > 0.15:
        shot = next(w for w in windows
                    if w["start_sec"] <= worst["from"] < w["end_sec"])
        findings.append({"stage": "clips",
                         "symptom": f"lost {worst['drop'] * 100:.0f}% mid-episode, inside {shot['shot_id']}",
                         "action": f"shorten {shot['shot_id']} or change its camera move"})
 
    # Whole episode: a low completion rate means no hook at the end, so the script is at fault
    if stat["completion_rate"] < 0.3:
        findings.append({"stage": "script", "symptom": "completion rate too low",
                         "action": "give the next episode a cliffhanger ending"})
    return findings

Note the payoff of the middle rule: it does not say "this episode's pacing is off," it says "shot s02 needs redoing." The scope shrinks from an episode to a shot, and redoing one shot costs a third of redoing an episode — yesterday's arithmetic paying off here. That is the practical value of landing data on a stage: it shrinks both the change and the spend.

The rules are written crudely on purpose. Crude means explainable: you can point at the log and say why this stage is the suggestion. Once you hold real data across dozens of episodes, replacing these hand-written thresholds with learned ones is the next step — but explainability must not be dropped.

The last checklist before publishing

The checklist last. It is not ceremony; its reason is concrete: publishing is the only irreversible action on this line. Every earlier step can be re-run; content that is out cannot be recalled.

The lab prints a tickable checklist in three classes. First, what the machine already verified, listed for human confirmation: all three versions play, the cover orientation matches the cut, the title comes from the top three and contains no hype wording. Second, what the machine cannot verify — the two unknown-spec platforms, verified against the console before uploading. Third, the hard lines, two of them: generated-content labeling (both explicit and implicit; the how is in /en/learn/ai-drama-pipeline/day-11) and traceable provenance for music and material.

Every line must be confirmable by one person in one minute. Writing "ensure the content is compliant" is useless — nobody knows where to look to call it confirmed.

Source Reading

Hands-On Lab

Confirm ffmpeg and ffprobe are both present first. Almost every decision today rests on master information read by ffprobe, and without it the whole decision chain is empty. If you get stuck, look at the encode-tally lines; they tell you directly whether the decision function is inverted.

1. Run the starter unmodified, compare the encode tally, the candidate scores and the diagnoses, and note the obviously wrong ones.
2. Implement spec decisions: unknown-spec platforms stream-copy and leave a manual verification item, documented platforms compare item by item before deciding; confirm re-encodes drop from 3 to 0.
3. Add the scoring function and the tie-breaker, confirm all five candidates print scores with reasons, and that two consecutive runs give an identical top three.
4. Add the backstop on model output and confirm the cover-copy line changes from placeholder text to "falling back to the local template."
5. Implement the retention-to-stage mapping and confirm the two platforms differ, with the middle rule naming a specific shot id.

Interview Questions

Today's 3 questions are in the question bank below, focused on the trade-offs of render-once-package-many, the generate-then-score selection pattern, and designing a data feedback loop. Read the analysis before the key points — practicing the derivation beats memorizing them. The cn / global labels let you pick by target market.

Checklist and Tomorrow

• I can automatically export multiple versions per target platform's spec, including resolution, duration, and cover size
• I can batch-generate cover copy and titles with a model, and pick the best version against judgeable criteria
• I can design a data feedback path that turns playback data into input for the next episode
• I can explain the difference between transcoding and muxing, and list the cases that truly require re-encoding
• I can explain why every number in a spec table needs a stated source, and what to do when there is none
• All 5 lab acceptance criteria pass
• I can answer at least 2 of the 3 interview questions without looking at the key points

Tomorrow (D14) is the last day: run a five-episode season from one world-bible record, check whether characters and art style drifted across episodes, produce a full-season bill, and gather these fourteen days into a portfolio you can present. Why leave a season for last? Because a season is the final examination of every engineering decision above it — idempotency, concurrency, cost, distribution — and any one of them done sloppily shows up immediately when five episodes run back to back.