BiliTools 流媒体格式指南：一文读懂 DASH / MP4 / FLV 串流方案与下载参数选择

本篇技术指南以 BiliTools（基于 Tauri 构建的哔哩哔哩工具箱）中的“流媒体格式”下载参数为核心，系统梳理哔哩哔哩曾采用与正在使用的三种串流方案（DASH、MP4、FLV）的技术原理、历史沿革与当前适用场景。读完本文，你将理解为什么默认应保持 DASH 格式、MP4 与 FLV 在什么场景下才会被实际用到，并能结合源码掌握 BiliTools 内部如何通过 fnval 参数请求不同格式的播放地址，从而在下载设置与任务队列中做出正确选择。

哔哩哔哩串流方案的历史演进

哔哩哔哩在历史上曾采用过多种流媒体串流方案，总体可分为三种：DASH 格式、MP4 格式与 FLV 格式。三者的核心区别在于服务器向客户端下发媒体数据的方式：

格式	下发方式	现状
DASH	音频、视频分别切片独立下发	2018 年引入，沿用至今，为当前主力方案
MP4	直接下发含音频的完整 MP4 媒体	基本停用，仅剩试看类资源（付费番剧、影视、课程）
FLV	FLV 分段下发	基本完全退役，保留选项仅用于存档

其中，DASH 方案于 2018 年被哔哩哔哩引入，并一直使用至今（当时官方曾发布“关于引入 DASH 技术，提升用户播放体验的说明”公告，可自行在哔哩哔哩官方动态中检索原文）。DASH 的全称是“基于 HTTP 的动态自适应流”（Dynamic Adaptive Streaming over HTTP），其典型特征是媒体内容被切分为多个分片，客户端可根据网络状况动态选择码率档位请求分片，从而实现更平滑的播放体验。对下载工具而言，这一方案最直观的体现就是“音视频分离”的取流结果。

DASH 格式：当前主力的流媒体方案

[!TIP] 这是哔哩哔哩目前采用的串流格式。其分发的音频与视频质量最好，下载速度也最快。 在大多数情况下，使用该串流格式即可。若不了解其他格式，不要修改下载参数中的“流媒体格式”。

DASH 方案下，音频与视频会被切片并单独下发给客户端，因此解析结果只能拿到 无声视频 与 无画音频 两类独立流。这意味着：直接下载下来的“视频”文件是不含声音的，而“音频”文件是不含画面的。

要合并为完整的一个音视频文件，需要调用 FFmpeg 进行混流（mux），也就是应用内名为 “音视频” 的任务。这一设计在 BiliTools 的任务类型枚举中也有直接对应：TaskType.AudioVideo = 'audioVideo'（见 src/types/shared.d.ts），它与 Video（纯视频）、Audio（纯音频）并列，共同构成弹窗中选择“媒体”内容时的三个选项。

源码侧：DASH 取流如何实现

在 src/services/media/data.ts 的 getPlayUrl 函数中，前端会根据用户选择的格式构造播放地址请求参数，DASH 对应：

case Types.StreamFormat.Dash:
  params.fnval = user.isLogin ? 4048 : 16;
  break;

请求的其余基础参数还包括：

• qn：清晰度档位，登录用户为 127（8K 超高清），未登录为 64（720P）；
• fnver: 0、fourk: 1：开启 4K/8K 等超高清取流能力；
• auth: 'wbi'：携带 WBI 签名鉴权。

收到响应后，代码从 data.dash 分支中分别取出视频流与音频流，并且音频数组会额外并入杜比与 Hi-Res 无损轨道：

} else if (data.dash) {
  const video = data.dash.video?.length ? data.dash.video : [];
  const audio = [
    ...(data.dash.audio?.length ? data.dash.audio : []),
    ...(data.dash.dolby?.audio?.length ? [data.dash.dolby.audio[0]] : []),
    ...(data.dash.flac?.audio ? [data.dash.flac.audio] : []),
  ];
  const codec = Types.StreamFormat.Dash;
  return { video, audio, codec };
}

也就是说，只有 DASH 方案才能完整覆盖哔哩哔哩的高规格音轨（如杜比全景声、Hi-Res 无损、无损 FLAC），这与文档中“DASH 分发的音频与视频质量最好”的结论相互印证。音频流与视频流随后分别交给下载核心（aria2c）下载，再通过 Rust 后端的 FFmpeg 封装完成合并——从源码结构看，混流逻辑集中在 src-tauri/src/services/ffmpeg.rs 的 merge 函数中，这也是“音视频”任务在下载完成后需要额外占用处理时间的原因。

MP4 格式：仅剩试看资源的兼容方案

[!WARNING] 不要因为长得像 MP4 后缀就选择该格式。在大多数情况下，其下载速度较慢，且质量不如 DASH 格式。

MP4 方案顾名思义：服务端直接向客户端下发 MP4 格式的完整媒体，视频自带音频，无需再经过 FFmpeg 混流即可直接播放。这也是它在历史上曾作为简单直接方案被使用的原因。

但它的劣势同样明显：

• 由于是单一封装整体下发，通常无法像 DASH 那样灵活按分片请求，下载速度较慢；
• 可用的清晰度档位与编码规格有限，画质与音质普遍不如 DASH；
• 目前哔哩哔哩已基本不再使用该方案，除了一种例外场景——试看资源：例如需要付费的番剧、影视、课程，这类资源几乎只能拿到 MP4 格式，且画质与音质大多欠佳。

源码侧：MP4 取流如何实现

在 getPlayUrl 中，MP4 对应：

case Types.StreamFormat.Mp4:
  params.fnval = 1;
  break;

响应处理时，如果接口返回了 data.durls（注意是复数形式，多清晰度列表），则代码将其映射为视频流数组，并标记 codec = Types.StreamFormat.Mp4：

if (data.durls?.length) {
  const video = data.durls.map((v) => ({
    id: v.quality,
    baseUrl: v.durl[0].url,
    backupUrl: v.durl[0].backup_url,
    size: v.durl[0].size,
  }));
  const codec = Types.StreamFormat.Mp4;
  return { video, codec };
}

注意此时返回结果中没有 audio 字段，与文档所述“视频会自带音频”的结构特征一致——BiliTools 不会为 MP4 单独下载音轨，也就不存在“音视频”合并任务。

FLV 格式：已退役的存档选项

[!WARNING] 该格式基本已完全退役。保留该选项仅用于存档，部分资源 可能 仍可下载。

FLV 是哔哩哔哩早年采用的格式，使用 FLV 分段方式向客户端下发流媒体。在当年带宽与播放器技术条件下，它是网页端低延迟播放的主流选择；但随着 2018 年 DASH 方案的上线，FLV 逐渐退出历史舞台。如今 BiliTools 保留该选项，目的只是兼容存档：仍有极少量历史资源可能只提供 FLV 取流地址，勾选后可尝试下载，但不应将其作为常规下载格式。

源码侧：FLV 取流如何实现

在 getPlayUrl 中，FLV 对应的 fnval 最为特殊，直接置零以请求最传统的播放地址：

case Types.StreamFormat.Flv:
  params.fnval = 0;
  break;

响应处理时，代码先检查 data.durl（单数形式），若命中则会按 accept_quality 逐档重新请求，收集所有可用的清晰度分片，再根据返回的 accept_format 是否包含 flv 决定标记为 FLV 还是 MP4：

} else if (data.durl?.length) {
  // 按 accept_quality 逐档请求，收集 durl 分片
  const codec = data.accept_format.includes('flv')
    ? Types.StreamFormat.Flv
    : Types.StreamFormat.Mp4;
  return { video, codec };
}

从这段逻辑可以推断：当服务器实际只能返回 FLV 时，即便前端选择了其他格式，最终也会被归并为 FLV 处理；反之亦然。这正好印证了文档中“部分资源 可能 仍可下载”的不确定性——FLV 是否可用，最终取决于服务端是否还保留该格式的取流能力。

三种格式的请求参数对照（源码级）

综合 src/services/media/data.ts 中的实现，BiliTools 对三种格式的播放地址请求参数映射如下：

流媒体格式	fnval 值	返回结构	音轨处理	合并任务
DASH 格式	登录 4048 / 未登录 16	dash.video + dash.audio（含杜比 / FLAC）	独立音轨	需要（“音视频”任务）
MP4 格式	1	durls（自带音频）	无独立音轨	不需要
FLV 格式	0	durl（分段）	无独立音轨	不需要

三种格式在代码中的枚举定义位于 src/types/shared.d.ts：

export enum StreamFormat {
  Dash = 'dash',
  Mp4 = 'mp4',
  Flv = 'flv',
}

而下载设置与弹窗中“流媒体格式”下拉选项的顺序（DASH 格式、MP4 格式、FLV 格式）来自 QualityMap.fmt（同文件），对应文案定义在 src/i18n/locales/zh-CN.json 的 quality.fmt 中。此外，该地图还一并提供了分辨率（res，240P 极速至 8K 超高清）、音频比特率（abr，64K 至无损 FLAC、杜比全景声、Hi-Res）与编码格式（enc，AVC / HEVC / AV1）的完整档位，供在下载参数中组合使用。

下载实战：如何正确选择与处理

1. 保持默认，优先使用 DASH

如果你对三种格式的差异并不熟悉，最稳妥的做法是保持默认的 DASH 格式不变，不要修改下载参数中的“流媒体格式”。原因有三：

1. 质量最好：DASH 能拿到当前资源可用的最高规格音视频流，包括杜比视界、8K、杜比全景声、Hi-Res 等（相关档位映射同样来自上文提到的 QualityMap）；
2. 速度最快：分片化下发天然支持并发下载，配合 BiliTools 内置的 aria2c 下载核心可获得更好的吞吐；
3. 无需决策成本：即使拿到的是“无声视频 + 无画音频”，BiliTools 会在下载后通过 FFmpeg 自动执行“音视频”合并任务，产出完整文件。

2. 理解“音视频”任务的必要性与耗时

选择 DASH 格式时，请务必勾选或确认任务中包含了音视频（audioVideo）选项，否则最终可能只得到分离的视频与音频文件。合并过程由 FFmpeg 完成（对应 src-tauri/src/services/ffmpeg.rs 中的 merge 实现），属于本地重封装/转码操作，会占用一定的 CPU 时间与磁盘临时空间，视频越长耗时越明显，这是 DASH 方案固有的一环，并非异常。

3. 何时才考虑 MP4 与 FLV

• MP4：仅当你下载付费番剧、影视、课程的试看资源，且服务端只提供 MP4 地址时，才需要切换到该格式。此时请对画质与音质有合理预期（大多欠佳）。日常下载普通视频时不要因为“看起来像 MP4 后缀”就选择它。
• FLV：基本仅用于存档与尝鲜。如果你明确知道某个历史资源仍提供 FLV 取流，可以切换到该格式尝试；否则不建议作为常规选项。

4. 相关转换与整理设置

在“设置 → 策略”页面（对应 src/components/SettingsPage/Strategy.vue）中还提供了与流媒体结果相关的两个转换开关（见 src/i18n/locales/zh-CN.json 的 settings.convert）：

• 转换为 MP3：将下载的音频统一转成 MP3 格式，便于在更广泛的播放器中使用；
• 转换为 MP4：若启用，会强制把视频转换为 MP4 封装，同时将音频流转为 AAC 格式，适合对封装格式有硬性要求的场景。

这两个开关作用于下载完成后的处理阶段，与“流媒体格式”取流参数是两个独立维度：前者决定从服务端取什么，后者决定本地处理成什么，理解这一点可以避免混淆。

小结

• DASH 是哔哩哔哩自 2018 年沿用至今的主力方案：音视频分离下发、质量与速度最优，需要 FFmpeg 混流，是 BiliTools 的默认与推荐选择；
• MP4 已基本停用，仅试看类资源（付费番剧、影视、课程）仍可能返回，下载前需接受其较低的速度与质量；
• FLV 为早年分段格式，已完全退役，保留仅用于存档，部分资源可能仍可下载。

在 BiliTools 中，这一切最终都体现为下载参数里“流媒体格式”（fmt）这一个选项：不了解其他格式时，请让它保持 DASH；确知目标资源只提供 MP4 / FLV 时，再按需切换。更完整的下载流程与设置说明，可继续阅读 下载指南 与 设置指南。