从 MP4 到 MP3yoinks 里 ffmpeg 转码流水线是怎么串起来的【免费下载链接】yoinksyoink any video from your terminal. no shady ads.项目地址: https://gitcode.com/GitHub_Trending/yo/yoinks终端视频下载工具近期在社区里热度不低围绕 yoinks 的教程和源码解读已经形成了好几轮讨论有人写「批量提取 MP3 的四种实战技巧」有人拆「媒体直链过期时如何优雅重试」也有人横评它与裸 yt-dlp 命令行的体验差异。这些话题表面上是操作指南内核其实是同一条技术主线——一条从「拿到网页 URL」到「磁盘上躺着一个 MP4 或 MP3」的转码流水线。本文顺着一次下载请求的完整生命周期把这条流水线逐段拆开元数据提取、流选择、ffmpeg 转码/合并、落盘以及直链过期时的两级重试全部落到 src/lib/ytdlp.ts 与 src/app.tsx 的真实代码上。先给结论yoinks 自己不做任何音视频处理。它只做三件事——用 yt-dlp 提取元数据、用-f表达式替用户选流、再解析 yt-dlp 的输出驱动一个五态 UI 状态机。真正的编码、封装、合并工作全部委托给 ffmpeg而 ffmpeg 的发现、定位与参数组合恰恰是这条流水线最见功夫的地方。一次下载请求的完整生命周期yoinks 的界面状态被建模为一个显式的阶段联合类型见 src/app.tsx 中的Phaseinput ──► probing ──► picking ──► downloading ──► done │ │ └─────── error ◄───────┘input校验用户输入。isProbablyUrlsrc/lib/platforms.ts只放行http:/https:协议同时detectPlatform通过 hostname 白名单识别 YouTube、X、Instagram、Threads、TikTok 等平台用于界面展示平台标签。probing调用ensureYtDlp确保二进制可用系统 PATH 优先 →~/.yoinks/bin缓存 → 首次运行自动从 GitHub Releases 下载独立二进制无需 Python 环境然后执行probe。这一步的本质是一条yt-dlp -J --no-playlist --no-warnings url把平台的完整元数据 JSON标题、时长、上传者、全部格式列表一次拉回const child spawn(ytdlp, [-J, --no-playlist, --no-warnings, url], {signal})注意-J只做模拟提取、不下载任何字节所以探测阶段极快。关键的隐藏设计原始 JSON 被原样落盘到临时目录yoinks-info-pid-ts.json路径存入infoJsonRef——这是后面「URL 过期重试」的第一级缓存的来源。pickingbuildChoices把info.formats折叠成最多 9 个下载选项见下一节。downloadingdownload()启动真正的 yt-dlp 子进程进度行、合并/转码阶段标记、最终文件路径全部从 stdout 逐行解析出来驱动界面在三态之间切换有总量走进度条、无总量走downloading…spinner、进入 ffmpeg 阶段走processing…spinner。done / error成功时--print after_move:filepath会把合并/转码完成后的最终路径打到 stdout应用据此 resolvesrc/cli.tsx 在退出备用屏幕后打印✓ yoinked → path。落盘路径固定为~/Downloads输出模板是%(title).60s.%(ext)s——标题截断到 60 字符扩展名则交给 yt-dlp 按合并/转码结果决定MP4 合并后是.mp4音频抽取后是.mp3。清晰度选择背后的码率与容器判定逻辑进入 picking 阶段前buildChoices要在动辄几十个格式里挑出用户能看懂的那几个选项。视频部分的核心逻辑是「按高度去重同高度内打分选优」const videos formats.filter(f f.vcodec f.vcodec ! none f.height) const heights [...new Set(videos.map(f f.height as number))].sort((a, b) b - a) for (const height of heights.slice(0, MAX_VIDEO_CHOICES)) { const candidates videos.filter(f f.height height) const best [...candidates].sort((a, b) scoreVideo(b) - scoreVideo(a))[0] ... }MAX_VIDEO_CHOICES 8封顶了选项数量避免 4K/8K 视频把选择面板撑爆。同一高度往往有多个流不同编码、不同码率、不同容器scoreVideo的打分规则很能说明作者对「容器」的态度function scoreVideo(f: RawFormat): number { let score f.tbr ?? 0 if (f.ext mp4) score 10_000 if (f.vcodec?.startsWith(avc)) score 5_000 return score }总码率tbr是主分但原生 mp4 容器加 10000、H.264avc编码加 5000——码率相近时优先选「本来就是 mp4 H.264」的流因为这意味着一趟下载可能连 ffmpeg 都不需要进场直接落盘反之则要额外承担一次重封装甚至重编码的开销。选出的最佳流还要换算成体积预估展示在面板上filesize/filesize_approx优先若是分离流视频流里没有音频muxed false还要加上最佳纯音频流的体积最终用formatBytessrc/lib/format.ts渲染成「1080p · mp4 · ~12 MB」这样的行。落到 yt-dlp 的参数时每个高度档位对应一段三段式回退的-f表达式args: [ -f, bv*[height${height}]ba/b[height${height}]/bv*[height${height}]ba/b, --merge-output-format, mp4, ],优先级表达式段语义1bv*[height1080]ba恰好 1080p 的最佳视频流 最佳音频流分离流需 ffmpeg 合并2b[height1080]恰好 1080p 的单一 muxed 文件免合并3bv*[height1080]ba/b不超过 1080p 的最佳视频 音频 / 任意 muxed 文件如果连一个带高度的格式都没有极端站点还有兜底项best available · mp4对应-f bv*ba/b --merge-output-format mp4。这正是社区评测里「清晰度选择丝滑」的来源——用户只看到 8 个干净选项背后的回退矩阵和体积换算全被折叠进了这一行表达式。音频提取与 ffmpeg 参数的组合策略「从 MP4 到 MP3」在技术上并不是一个固定动作而是取决于源站格式的两条路径如果源站音频本身就是独立流YouTube 的 DASH 场景ffmpeg 负责解码重编码如果恰好是 mp3 源则退化为重封装。无论是哪条路径ffmpeg 都是必要依赖yoinks 对它的定位因此格外谨慎export async function findFfmpeg(): Promisestring | undefined { if (await commandWorks(ffmpeg, [-version])) return undefined // on PATH, yt-dlp finds it itself try { const mod await import(ffmpeg-static) const ffmpegPath (mod.default ?? mod) as unknown as string | null if (ffmpegPath (await commandWorks(ffmpegPath, [-version]))) return ffmpegPath } catch { ... } return undefined }三条路依次尝试系统ffmpeg在 PATH 上 → 直接返回undefined此时 yt-dlp 自己会找到它无需显式传参否则动态import(ffmpeg-static)拿 npm 捆绑的静态二进制package.json 中ffmpeg-static ^5.3.0保证了这个兜底存在两者皆无则返回undefined此时单文件格式仍可下载只是分离流合并和音频抽取会失败。找到二进制后通过--ffmpeg-location显式告诉 yt-dlp 用哪个。音频选项的参数组合是全项目最凝练的一行args: [-f, ba/b, -x, --audio-format, mp3, --audio-quality, 0],-f ba/b只要最佳纯音频流-x抽取音频--audio-format mp3目标编码--audio-quality 0yt-dlp 把 0–9 映射到 MP3 的 VBR 档位0 是最高档。社区教程里「输出无损音质 MP3」的说法要打个折扣——MP3 本身是有损编码0只是码率上限最高而不是无损。界面同步展示了音频体积取最佳音频流的filesize/filesize_approx所以用户在看到「audio only · mp3 · ~8 MB」时就已经知道产物大小。转码阶段的识别与进度衔接是流水线里最容易被忽略的部分。download()用自定义的 progress template 从 yt-dlp 拉结构化进度const PROGRESS_TEMPLATE ${PROGRESS_PREFIX}%(progress.downloaded_bytes)s|%(progress.total_bytes)s|%(progress.total_bytes_estimate)s|%(progress.speed)s|%(progress.eta)s同时逐行监听 stdout靠两个信号完成阶段切换[Merger] Merging formats into …与[ExtractAudio] Destination: …两行出现 → 触发onProcessingUI 从进度条切到processing…spinnersrc/app.tsx 中processing标志位。[info] xxx: Downloading 1 format(s): 395251行 → 按拆出totalParts进度条在两次文件之间会回落到 0代码用downloadedBytes lastDownloaded判定part于是 UI 能准确显示「part 1/2」——对分离流场景先下视频再下音频再进入合并全程一目了然。一个值得注意的实现细节yt-dlp 的--print隐含--quiet会一并吞掉进度条和[Merger]/[ExtractAudio]行所以代码里显式补了--no-quiet并注释了原因。整条流水线的阶段感知完全建立在「保住这两行输出」之上。媒体 URL 过期重试与流水线的衔接设计多数平台的媒体直链有效期只有几十秒甚至更短这是下载工具最常见的翻车点社区里也专门有文章拆过 yoinks 的应对方案。其设计是两级策略衔接点在 src/app.tsx 的handlePick第一级缓存元数据跳过重复提取。probe 阶段把yt-dlp -J的 JSON 落盘下载时用--load-info-json path代替直接传 URL。yt-dlp 加载本地 JSON 后不再联网提取子进程几乎瞬时启动——代价是 JSON 里嵌的媒体直链可能已经过期。第二级直链失效时降级重新提取。第一级下载失败且不是用户主动取消时先清掉进度、把界面置为refreshing显示「link expired — grabbing a fresh one…」再不带infoJsonPath重试一次让 yt-dlp 用原始 URL 重新提取最新直链try { filepath await download({...base, infoJsonPath: infoJsonRef.current}, handlers, controller.signal) } catch (error) { if (controller.signal.aborted) throw error setPhase(prev prev.name downloading ? {...prev, progress: undefined, refreshing: true} : prev, ) filepath await download(base, handlers, controller.signal) }这个 catch 分支的判定值得细看controller.signal.aborted会原样抛出——用户按esc取消时不能被当作「可重试失败」误触发二次下载其余错误才进入降级重试。两级设计让「绝大部分情况秒开、极少数情况静默自愈」用户无感知。与重试配套的还有两处资源回收一是取消时removePartials根据destinations从[download] Destination:、[Merger]、[ExtractAudio]三处收集到的全部写入路径连带.part/.ytdl临时文件一并清理不留半成品二是模块级activeChild在进程exit时补发SIGTERM防止异常退出时 yt-dlp 子进程变成孤儿。错误信息则经cleanYtDlpError清洗——只保留最后一条ERROR:行并剥掉[extractor]前缀让终端里展示的是「人话」而不是原始堆栈。小结回看整条流水线yoinks 的角色更像一个「编导」而非「演员」用-J提取元数据并落盘缓存用-f表达式把用户的清晰度/音频诉求翻译成 yt-dlp 的选流语言再用--merge-output-format mp4、-x --audio-format mp3 --audio-quality 0这些参数把 ffmpeg 精确调度到「合并」或「抽取」的岗位上最后通过 stdout 逐行解析驱动 UI 状态机完成呈现。直链过期时的两级重试、取消时的临时文件清理、以及--no-quiet保住阶段标记行这类细节则把这条流水线从「能跑」打磨到了「可靠」。下次你在这个 TUI 里按下回车、看到part 1/2然后跳进processing…时就该知道屏幕上每一帧变化对应的都是 src/lib/ytdlp.ts 里某一行解析逻辑在工作。【免费下载链接】yoinksyoink any video from your terminal. no shady ads.项目地址: https://gitcode.com/GitHub_Trending/yo/yoinks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考