Interview Bank

Build an AI Short-Drama Production Pipeline With Agents in 14 Days

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

• The same video has to be published to several platforms with different specs. How do you design the export flow to minimize transcoding?同一条视频要发多个平台，每个平台规格不同，你会怎么设计导出流程才能少转码？

  Common in ChinaCommon overseasIntermediate#media-pipeline#ffmpeg

  How to reason about it · think before answering

  1. This question tests whether you distinguish transcoding from remuxing. Rendering once per platform is not a coding failure, it is a failure to notice that every lossy re-encode costs quality.
  2. Separate the two: transcoding decodes and re-encodes, so the picture data is genuinely recompressed; remuxing just moves an already-encoded bitstream into another container without touching a byte. One takes seconds and loses quality, the other takes milliseconds and is lossless.
  3. Then give the flow: render one master using the most conservative parameters that satisfy every target, then run each platform through a decision function and stream-copy whenever possible. Container changes, faststart and duration trims all stay within stream copy.
  4. Know the cases that truly require re-encoding: out-of-range resolution, an unaccepted codec, a frame rate outside the allowed band, and a file that exceeds the size cap. Duration is the one people misjudge most, since -t with stream copy already trims it.
  5. Add an engineering rule: the decision function should return a list of reasons, not just a boolean. When someone asks why a platform got re-encoded, you answer from the log rather than rereading the code.
  6. Expect the follow-up: how do you prove it? Print an encode counter alongside the count the naive approach would have produced. A number without a baseline convinces nobody.

  分析过程 · 先想清楚再作答

  1. 这题在考你分不分得清转码与封装。答成「按每个平台各渲染一遍」的人不是不会写代码，是没意识到有损编码每转一次就掉一次画质。
  2. 先把两个词分开：转码是重新解码再编码，画面数据真的被压了一遍；封装只是把已编好的码流换个容器，一个字节都没动。前者要几秒到几十秒并且掉画质，后者几十毫秒且无损。
  3. 然后给流程：先渲染一份母版，参数取所有目标平台的交集里最保守的一档；之后每个平台走一次判定函数，能流复制就流复制。换容器、加 faststart、按时长截断都属于流复制的范围。
  4. 必须重编码的情况要能背出来：分辨率越界要缩放、编码格式不被接受、帧率超范围、文件大小超限要降码率。除此之外都不该重编码——尤其时长超限这一条最容易被误判，其实 -t 配流复制就能切。
  5. 补一条工程判据：判定函数要返回理由列表，不只是布尔值。出片之后有人问「为什么这个平台转了码」，你要能拿日志回答，而不是重新读一遍代码。
  6. 可预期的追问是「怎么证明真的少转了」。答案是打印一个编码次数计数器，并同时给出朴素做法的次数做对照——没有对照的数字说服不了任何人。

  Key points

  • Separate transcode from remux: container swaps, faststart and duration trims are all stream copies
  • Render one master using the most conservative intersection of all target constraints
  • Re-encode only for out-of-range resolution, unaccepted codec, out-of-band frame rate, or oversize files
  • Have the decision function return reasons so every re-encode can be explained
  • Print an encode counter next to the naive baseline to prove the saving

  答题要点

  • 分清转码与封装：换容器、加 faststart、按时长截断都可以流复制
  • 一次渲染母版，参数取所有目标平台约束的最保守交集
  • 只有分辨率越界、编码不被接受、帧率超范围、体积超限才必须重编码
  • 判定函数返回理由列表，让每次重编码都能被解释
  • 打印编码次数计数器并与朴素做法做对照，才算证明少转了码