m4s 这个后缀，绝大多数前端同学第一次撞见都是在浏览器开发者工具的网络面板里：一堆按序号排列、大小几百 KB 到几 MB 不等、Content-Type 写着video/iso.segment或application/octet-stream的请求。它们既不是普通的 mp4，也不是 ts，单独拿一个出来双击打不开，播放器直接报错。这套下载与合并方案就是围绕这种分片格式展开的：搞清楚 m4s 到底是什么、为什么视频网站要把一个完整视频剁成几百块、怎么按正确顺序把音轨和视频轨分别拉下来、最后用 FFmpeg 拼成一个能正常播放的 mp4。它解决的是“素材到手是一堆碎片，没法直接用”的问题，适合三类人看：想给自己有权限的公开课、自己上传的内容做离线备份的普通用户；需要研究流媒体协议、想在自己项目里实现类似分片播放的前端或后端开发者；以及做音视频处理、经常要处理 fMP4 素材的同学。整个方案不依赖任何特殊工具，核心就是浏览器加一个几十行的脚本加一条 FFmpeg 命令。
1. 先搞清楚 m4s 到底是什么东西
1.1 为什么播放器热衷于把一个视频拆成几百个小文件
很多人第一次看到几十上百个分片请求，第一反应是“这网站有病吧，直接给一个文件不好吗”。实际上拆片是流媒体播放的必然选择，背后有几层很实在的工程理由。
第一层是按需加载。一个 40 分钟的视频，完整文件可能是 1.5 GB，但用户大概率看不到第 12 分钟就划走了。如果一次性下发整个文件，绝大部分流量是浪费的。拆成 5 秒到 10 秒一片之后，播放器只要往下要用户即将看到的那几片，首帧时间能压到几百毫秒。
第二层是自适应码率。同一路视频，网站通常会准备 360P、480P、720P、1080P 甚至更高的多个版本，每个版本各自切分片。网络好的时候播放器要高清分片，进电梯信号掉下来就切到低清分片的同一时间点继续播，用户几乎无感。这个“切”的动作，前提就是内容被切成了对齐的、可替换的片段。
第三层是CDN 缓存效率。千兆大文件在边缘节点上命中率很难做，因为用户请求的字节范围各不相同；而固定大小的分片天然适合缓存，边缘节点缓存命中率能拉到很高。
第四层是断点续传和容错。中间某一片网络抖动失败了，重试那一片就行，代价几 MB 而不是几百 MB。
所以你在网络面板看到的“碎片”，不是网站偷懒，而是 DASH 这套流媒体协议（大部分视频网站用的是它，或者与其思路一致的方案）的正常工作形态。理解这一点之后，你的抓取思路就顺了：你要做的不是“找到那个大文件”，而是“把这堆分片按顺序收齐”。
提示：m4s 只是一个后缀习惯，它本质上是 fMP4（fragmented MP4）的媒体分片。有些站点会把它写成
.mp4、.m4f、.cmfv，甚至有站点干脆不带扩展名，判断依据要看响应头和文件头，不是看后缀。
1.2 init 分片与 media 分片：一个管说明书，一个管数据
拆包之后你会发现，视频轨的请求序列里，第一个永远是那个只有几 KB 的小文件，后面的才是几百 KB 到几 MB 的大文件。这个小文件就是init 分片（初始化分片），后面的是media 分片（媒体分片）。
用生活中的类比我更喜欢这么解释：init 分片像是一份乐谱的“曲谱说明页”，它告诉你这首曲子有几个声部、每个声部用什么乐器、节拍是多少、小节怎么划；media 分片则是真正的一页页音符。你把后面的音符页全拿到了，但没有前面的说明页，演奏者不知道该怎么解读这些音符，于是播放器直接报错。这就是为什么单拎一个 media 分片出来双击打不开——它缺了“说明书”。
从 ISO BMFF（MP4 的容器规范）的盒子结构看，这个区别非常具体：
- init 分片里包含
ftyp（文件类型，声明 brand，比如iso6、dash）和moov（movie box）。moov下面挂着trak，trak里的mdia/minf/stbl中有stsd，stsd里就是那个关键的编码描述（比如avc1盒子，里面带着 SPS/PPS）。还有mvex，它声明“这是一个分片文件，后面每个片段自己带自己的元信息”。 - media 分片里则是
moof（movie fragment box）加mdat（media data box）的重复组合。moof里有mfhd（分片序号）、traf（track fragment），traf下的tfhd说明这属于哪个 track，tfdt给出这一段在整条时间轴上的解码起始时间（base media decode time，单位是 timescale），trun则记录这一片里有多少个 sample、每个 sample 的时长和大小。mdat就是真正的压缩数据流。
tfdt这个盒子值得单独拎出来说，因为它是后面排查音画不同步的第一现场。它记录的是一个绝对时间戳，如果分片下载漏了或者顺序乱了，这个时间戳序列就断了，合并出来的文件轻则画面跳动，重则直接解不出来。
1.3 m4s 和普通 mp4 的差别到底在哪
普通 mp4 是“一次性把索引和媒体数据都给你”的结构：ftyp+moov（含完整的 sample table，stts、stsc、stco一个不少）+mdat。播放器读完moov就知道全片的每一个 sample 在文件的哪个字节，可以直接 seek。
fMP4 则把moov简化成了“空壳”，把 sample table 分散到每个moof里。这种设计对网络播放很友好（边下边解析），但对本地合并提出了一个要求：你必须把 init 分片放在最前面，media 分片按mfhd序号或tfdt时间戳升序排列拼接，顺序错一位就完了。
还有一点很多人没意识到：视频网站的音轨和视频轨是完全独立的两条流，各自有独立的 init 分片、独立的分片序列、独立的编号规则。你在网络面板里看到的两组请求，大概率一组是视频一组是音频，它们的分片数量通常不一样——因为音轨码率低、每片时长可能不同。这就是为什么必须“分别下载，最后合并”，而不是“下载一个带声音的视频”。
2. 前端视角的抓取思路：从页面到网络面板
2.1 页面里那份播放描述数据是怎么到前端的
站在前端开发的角度看，播放器拿到播放地址的过程通常是这样的：页面加载时，服务端在 HTML 里注入一段 JSON，或者播放器初始化时发一个请求去换取这份描述，然后前端把它交给播放核心。这份描述里最关键的字段是 DASH 清单部分，形如一个数组，每一项代表一条可用流。
每条流上你会看到这些字段：
baseUrl：分片的基础地址，后面的分片号会拼上去；backupUrl：备用地址数组，主线路不通时可以试这个；initialization：init 分片的相对路径或完整地址；indexRange/segmentBase：说明索引信息在文件里的字节区间；codecs：编码标识，比如avc1.640032、hev1.1.6.L120.90、av01.0.08M.08；bandwidth：这一路的大致码率，单位 bps；width/height：分辨率；mimeType：video/mp4或audio/mp4；id：轨道标识，有些站点的音视频靠这个字段配对。
音频轨的字段结构基本一致，但codecs会变成mp4a.40.2（AAC-LC）之类。
从实操角度说，你不需要逆向任何加密逻辑——这些信息在你打开页面、播放器完成初始化之后，已经存在于前端内存或者已经加载的脚本数据里了。你需要做的是找到它、读懂它、按它给的地址去取分片。这也是我把它叫“前端甜点”的原因：所有拼装逻辑都在客户端跑，浏览器能拿到的，你通过开发者工具也能看到，没有黑盒。
注意：这里讨论的抓取，前提是你访问的内容本身是公开可获取的、或者你自己拥有访问权限的。任何需要绕过权限校验的做法都不在本方案范围内，也不该做。
2.2 网络面板筛选：三步锁定真正的媒体请求
打开开发者工具的网络面板，先播放几秒，然后按下面的顺序筛：
第一步，按类型筛。选Media分类，如果没抓到东西，就切到XHR/Fetch，再不行就选All然后按 Size 倒序。大部分站点的分片请求会落在 Media 或 XHR 里。
第二步，按体积排序。分片请求的体积特征非常明显：几百 KB 到几 MB，而且大小彼此接近（同一路流的码率稳定）。你会看到几十上百条记录，名字里带数字序列。这一步能过滤掉 90% 的干扰请求。
第三步，看请求 URL 的结构。同一路流的分片 URL 差异通常只在最后一段数字，前面的路径完全一致。找到这个规律，你就拿到了“URL 模板”，后面脚本直接按模板生成就行。
这里有个常见误区：有人会去抓m3u8或者清单文件，然后发现里面全是加密的或者根本对不上。对于 DASH 方案，清单信息其实已经在播放描述数据里了，不需要额外去拉。反倒是有些站点会把分片地址做一次重定向，你需要勾上“保留日志”并允许重定向，才能看到最终的真实地址。
2.3 请求头里的三个字段，少一个就 403
分片请求能成功，靠的不只是 URL。我用下来最关键的是三个头：
| 请求头 | 作用 | 缺失后果 |
|---|---|---|
Referer | 校验来源页，防盗链的第一道关 | 直接 403，或者返回一个几百字节的错误 JSON |
User-Agent | 部分站点做基础客户端识别 | 可能返回降级内容或空响应 |
Range | 声明需要的字节区间 | 一般不影响，但有些站点依赖它做分片寻址 |
Referer是坑最多的一个。很多站点做了严格的来源校验，你少了这个头，服务器返回的不是 403 就是一段看起来像正常响应的错误体——大小可能只有一两百字节。如果脚本没做校验，你会 happily 地把它存成.m4s，最后合并时报一堆“moov atom not found”。
我自己的习惯是：先在浏览器里复制一条成功的分片请求，用curl完整复现一遍，确认能拿到正确大小的文件，再把这套头搬进脚本。这一步花五分钟，能省掉后面一小时的排查。
curl -H "Referer: https://example.com/" \ -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \ -H "Range: bytes=0-" \ -o test.m4s \ "https://example.com/media/seg-00001.m4s"2.4 命名规律与排序：别栽在字符串排序上
分片编号的常见形式有三种：纯数字（0、1、2……）、补零数字（00001、00002……）、以及时间戳或者混合 ID。补零的还好，纯数字的如果直接按字符串排序，10会排在2前面，合并出来的视频就是乱序的。
我的处理方式统一是：下载时按数字编号保存成固定宽度的文件名，比如00001.m4s、00002.m4s，这样无论后面用ls、通配符还是脚本拼接，顺序都不会错。这一步看似琐碎，但它是我踩过最蠢也最费时间的坑之一——某次合并完发现画面在 8 分钟处开始疯狂跳帧，查了半小时才意识到是排序问题。
还有一种情况是分片不是从 0 或 1 开始的，可能从 100 开始，也可能中间有跳号（缺片）。所以脚本里一定要做连续性检查：拿到编号列表之后，先算一遍最小值和最大值，看看总数对不对，缺了哪几个心里有数再动手。
3. 下载与合并的实操流程
3.1 准备工作：工具清单与目录结构
整个流程需要的工具很少，我把清单列清楚，方便你对照准备：
| 工具 | 用途 | 备注 |
|---|---|---|
| 浏览器开发者工具 | 抓分片地址、看请求头、读播放描述 | 任何现代浏览器都可以 |
| Python 3.8+ | 跑批量下载脚本 | 只用标准库加requests就够 |
| requests | 带请求头下载、支持流式写入 | pip install requests |
| FFmpeg | 音视频合并、格式转封装 | 建议 5.0 以上版本 |
| ffprobe | 检查合并结果的时长、流信息 | 随 FFmpeg 一起装 |
目录结构我习惯这么分，好处是同一个视频的素材集中管理，出问题好回溯：
work/ ├─ video/ │ ├─ 00000.m4s # init 分片 │ ├─ 00001.m4s │ └─ ... ├─ audio/ │ ├─ 00000.m4s # init 分片 │ ├─ 00001.m4s │ └─ ... └─ out/ └─ result.mp4注意00000.m4s这个位置专门留给 init 分片。很多脚本会把 init 也当成普通分片编号，结果合并时它排到中间去了，直接导致文件损坏。
3.2 批量拉取分片：并发、重试、断点续传三件套
最朴素的写法是一个for循环串行下，但几百个分片串行跑下来非常慢，而且中间任何一个网络抖动都会中断。我用的脚本加了三个保护：有限并发、指数退避重试、秒传跳过。
import os import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed HEADERS = { "Referer": "https://example.com/", "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)", "Accept": "*/*", } URL_TMPL = "https://example.com/media/seg-{i:05d}.m4s" def fetch_one(i, outdir, retry=4): path = os.path.join(outdir, f"{i:05d}.m4s") # 秒传：已存在且非空就跳过 if os.path.exists(path) and os.path.getsize(path) > 1024: return path, "skip" for attempt in range(retry): try: with requests.get(URL_TMPL.format(i=i), headers=HEADERS, timeout=(5, 30), stream=True) as r: r.raise_for_status() tmp = path + ".part" with open(tmp, "wb") as f: for chunk in r.iter_content(chunk_size=64 * 1024): if chunk: f.write(chunk) os.replace(tmp, path) return path, "ok" except Exception as e: if attempt == retry - 1: raise RuntimeError(f"seg {i} failed: {e}") time.sleep(1.5 ** attempt) # 1.5s, 2.25s, 3.4s... def batch(start, end, outdir, workers=6): os.makedirs(outdir, exist_ok=True) with ThreadPoolExecutor(max_workers=workers) as pool: futures = {pool.submit(fetch_one, i, outdir): i for i in range(start, end)} for fut in as_completed(futures): i = futures[fut] try: path, status = fut.result() print(f"[{status}] {i} -> {path}") except Exception as e: print(f"[FAIL] {i}: {e}") if __name__ == "__main__": batch(1, 241, "./video", workers=6)几个参数的选择理由，我展开说一下：
并发数为什么是 6 而不是 20。这类 CDN 通常对单 IP 有隐性的速率限制，并发太高反而会触发限速，表现是后半程每个请求都被拖到十几秒。4 到 8 之间是比较稳的区间，实测 6 并发比 20 并发整体耗时更短。我试过 16 并发下一个 200 片的视频，前 60 片很顺，后面全部超时重试，总体反而慢了一倍。
重试为什么要退避。立即重试大概率撞上同一个问题。1.5 ** attempt的间隔是 1.5 秒、2.25 秒、3.4 秒，足够让服务端的瞬时压力缓过来。如果四次都失败，那就是地址或者请求头的问题，再重试没意义了，该停下来查。
为什么要写.part临时文件再os.replace。这是防止下载中途中断留下半截文件。下次跑脚本时，.part文件不会被认为是“已完成的分片”，而完整的文件才会被跳过。这个细节在几百个分片的场景里能省掉大量重复劳动。
超时为什么拆成两个数。timeout=(5, 30)表示连接超时 5 秒、读取超时 30 秒。连接建立快说明服务器在，读取给足时间是因为单片可能几 MB，慢网络下需要缓冲。
3.3 下载完先别急着合并：三步校验
分片下完之后，直接合并是把运气当能力。我固定做三步校验，能拦下绝大部分问题。
第一步，数量对账。拿到的最小分片号和最大分片号之间，文件数是否等于max - min + 1。缺片是合并后画面跳段的最常见原因。
第二步，体积异常检查。正常分片的大小分布是相对集中的。写几行脚本算出中位数，把小于中位数 10% 的文件挑出来——这些大概率是错误响应体。我遇到过服务端在限流时返回一个 200 状态的 JSON 错误，大小 187 字节，如果不检查，它会安静地混进分片序列。
import os, statistics files = sorted(os.listdir("./video")) sizes = [os.path.getsize(os.path.join("./video", f)) for f in files if f.endswith(".m4s")] med = statistics.median(sizes) suspicious = [f for f in files if os.path.getsize(os.path.join("./video", f)) < med * 0.1] print("中位数:", med, "可疑:", suspicious)第三步，文件头魔数检查。用 Python 读每个文件的前 16 个字节，正常的分片开头应该是ftyp、moof、styp或者sidx这几个盒子名。读到{开头的，那是个 JSON；读到<!DO开头的，那是 HTML 错误页。这一步能百分之百确认文件是不是真的媒体数据。
with open(path, "rb") as f: head = f.read(16) box = head[4:8].decode("latin-1") assert box in ("ftyp", "moof", "styp", "sidx"), f"{path} 不是有效分片: {head!r}"提示：这三步加起来不到两分钟，但它把“合并后才发现问题”的返工成本从半小时压到了两分钟。养成习惯之后，你会发现自己几乎不再需要debug合并结果。
3.4 音视频合并：FFmpeg 命令逐条拆解
两个方向的素材都下好了，最后一步是合成。最常用的命令是这一条：
ffmpeg -i video/merged_video.m4s \ -i audio/merged_audio.m4s \ -map 0:v:0 -map 1:a:0 \ -c copy \ -movflags +faststart \ out/result.mp4我逐段解释这些参数，因为每一条都是有理由的，不是抄来的：
-i两个输入，视频在前音频在后。顺序重要，因为后面-map要靠索引引用。
-map 0:v:0 -map 1:a:0明确指定“取第 0 个输入的第一个视频流”和“取第 1 个输入的第一个音频流”。不写-map的时候 FFmpeg 会走默认流选择，大多数情况没问题，但如果分片里混进了字幕轨或者多余的音轨，默认选择可能挑错。写死是最稳的。
-c copy是核心：不重新编码，只做容器层的封装转换。这意味着合并速度极快（几个 GB 的文件也就几十秒），画质零损失。代价是它要求输入和输出容器兼容——这也是后面会讲到的，某些编码格式塞进 mp4 会有麻烦。
-movflags +faststart把moov盒子挪到文件开头，适合边下边播的场景。本地播放其实无所谓，但如果你要把文件放到网页上、或者用一些对索引位置敏感的播放器，这个参数能救命。
还有一种情况：你的分片是分开的，还没拼成一个整段的 m4s。这时候不用先拼，FFmpeg 支持用 concat 协议直接把一堆文件当输入：
ffmpeg -f concat -safe 0 -i video_list.txt \ -f concat -safe 0 -i audio_list.txt \ -map 0:v:0 -map 1:a:0 -c copy out/result.mp4video_list.txt里每行一个file '00001.m4s'。注意-safe 0是为了放开路径限制，因为默认的 concat 只允许相对路径。这条路的好处是不产生中间文件，省磁盘。
合并完一定要用ffprobe验一下：
ffprobe -v error -show_entries format=duration,size \ -show_entries stream=codec_name,width,height,duration \ -of default=noprint_wrappers=1 out/result.mp4重点看三件事：视频时长和音频时长是否一致（差个几十毫秒正常，差几秒就是有问题）、codec_name是不是你以为的那个、width/height对不对。这三项里任何一项不对，说明前面的环节出错了。
3.5 纯二进制拼接：一条不用装 FFmpeg 的野路子
如果你的需求只是拿到一个能播的文件，而且音视频轨你打算分开存（或者你只要视频不要音频），其实可以完全不用 FFmpeg——直接把 init 分片和所有 media 分片按顺序二进制拼起来就行。
cat video/00000.m4s video/00001.m4s video/00002.m4s ... > out/video.mp4或者用通配符（前提是你已经补零命名）：
cat video/*.m4s > out/video.mp4这条路能成立，是因为 fMP4 本身就是“可顺序解析”的格式：播放器从ftyp开始读，读到moov拿到编码描述，之后每遇到一个moof+mdat就解一段。整个文件不需要回退寻址，所以简单拼接在理论上就是合法的。
但它有三个明确的限制，我用下来必须提醒：
第一，cat的通配符顺序依赖文件名排序，必须是补零命名，否则10排在2前面，拼出来是废的。
第二，这样拼出来的文件没有mfra（movie fragment random access）盒子，部分播放器做精确 seek 时可能不准，表现为拖动进度条后卡一下或者跳回。多数主流播放器能兜住，但不是全部。
第三，也是最关键的，这样拼出来的文件只有视频没有声音（或只有声音没有视频）。你得单独拼一份音频，然后要么在播放器里外挂音轨，要么还是得回 FFmpeg 合并。
所以我的实际做法是：用cat做快速验证，确认分片本身没问题、顺序也对，然后走 FFmpeg 做最终合并。这样排查问题时能把“分片坏了”和“合并命令写错了”这两类原因分开，定位效率高很多。
4. 编码格式与画质音质的那些坑
4.1 同一路视频为什么有好几套编码
如果你仔细看过播放描述里的codecs字段，会发现同一个清晰度下有好几个可选项。这不是冗余，是为了兼容不同设备的解码能力。
常见的有三类：
| codecs 前缀 | 编码 | 特点 | 适用场景 |
|---|---|---|---|
avc1 | H.264 / AVC | 兼容性最好，硬解覆盖面最广 | 通用首选，老设备也认 |
hev1/hvc1 | H.265 / HEVC | 同画质下体积约小 30% 到 50% | 移动端、支持硬解的设备 |
av01 | AV1 | 体积更小，压缩效率最高 | 新设备，解码开销较大 |
从下载角度看，你要做的决策是：挑哪一路。我的建议是默认选avc1。理由很实际——合并出来的 mp4 几乎任何播放器、任何剪辑软件、任何系统自带的预览都能打开。选hev1的话，Windows 上可能提示需要额外的解码组件，某些剪辑软件直接不认。选av01更麻烦，不少工具链还没跟上。
如果你的目标就是存档、不在意通用性，那选体积最小的那一路没问题。但如果你后面还要转码、剪辑、或者发给别人，avc1能省掉一堆沟通成本。
还有一个细节值得注意：avc1和hev1后面的那串数字是有含义的，比如avc1.640032里的640032拆开是 profile、constraint、level。6400对应 High Profile，32对应 Level 5.0。这不是必须掌握的，但当你发现某个文件播放器打不开、提示“不支持该 profile”时，这串数字就是线索。
4.2 音轨的差异比想象中大
大多数人默认音轨就是 AAC，随便下一路就行。实际上不少站点会提供多个音频选项：
mp4a.40.2：AAC-LC，最标准的选择，兼容性最好，码率通常 128 kbps 到 320 kbps。mp4a.40.5：HE-AAC，低码率下表现更好，但部分老播放器支持不佳。ec-3：杜比数字+（Dolby Digital Plus），多声道，需要播放端支持。fLaC：无损音频，体积大，用于高保真场景。
装进 mp4 容器时，AAC 是最省心的。ec-3一般也没问题，现代 FFmpeg 都支持。fLaC就麻烦了——老版本 FFmpeg 把 FLAC 塞进 mp4 会报错，需要较新的版本，或者干脆封装成.mkv：
ffmpeg -i video.m4s -i audio.m4s -map 0:v:0 -map 1:a:0 \ -c copy out/result.mkvMKV 容器对编码格式的宽容度高得多，什么都能装。代价是部分设备和软件不认 mkv，需要额外转一道。
4.3 合并后音画不同步、时长不对，从哪查起
这是这套流程里最容易出问题、也最难一眼看出来的环节。我把它拆成几种典型症状和对应对策：
症状一：合并后只有画面没有声音，或者反过来。通常是-map写错了，或者某个输入文件其实是空的。先用ffprobe单独看两个输入文件，确认各自都有流。如果音频文件ffprobe显示“no streams”，那就是它本身坏了，回到第 3.3 节的校验环节。
症状二：时长明显不对，比如视频 40 分钟但文件显示 8 分钟。这是分片没下全的典型表现。fMP4 的时长由最后一个moof里的tfdt加上trun里的 sample 时长推算出来，缺了后面的分片，时长自然就短了。回头对账分片数量。
症状三：音画不同步，越到后面差得越多。这种情况通常是两路流的分片时长不一致导致的累计误差，或者是某一路中间缺了几片。有个应急的处理方式是在合并时做时间偏移：
ffmpeg -itsoffset 0.35 -i audio.m4s -i video.m4s \ -map 1:v:0 -map 0:a:0 -c copy out/fixed.mp4-itsoffset给音频整体延后 0.35 秒。但这只是打补丁，正解还是把缺的分片补齐，让tfdt序列连续。
症状四：播放器能打开但拖进度条就崩。大概率是走了cat拼接路线、缺mfra盒子，或者分片顺序错了。换成 FFmpeg 合一遍基本能解决。
5. 常见问题速查与避坑经验
5.1 问题速查表
下面这张表是我和身边同学实际踩过的坑的汇总，按“症状 → 最可能原因 → 处理方式”组织，遇到问题先扫一眼，能省不少时间。
| 症状 | 最可能原因 | 处理方式 |
|---|---|---|
| 请求返回 403 | 缺Referer或User-Agent | 从浏览器复制完整请求头复现 |
| 下载的文件只有一两百字节 | 服务端返回了错误 JSON，被当成正常响应存下 | 加体积校验和魔数校验 |
合并报moov atom not found | init 分片缺失或没排在最前面 | 确认00000.m4s存在且顺序正确 |
合并报Invalid data found | 混进了 HTML 错误页或半截文件 | 清理.part文件重下 |
| 画面在某个时间点开始跳帧 | 分片顺序错乱或中间缺片 | 检查文件名是否补零、对账数量 |
| 只有画面没有声音 | -map参数写错 | 显式指定-map 0:v:0 -map 1:a:0 |
| 音画不同步 | 两路流分片时长不一致或有一路缺片 | ffprobe分别查两路时长，补齐缺片 |
| 拖进度条异常 | cat拼接缺索引，或分片顺序错 | 改用 FFmpeg 合并 |
| 下载到一半集体超时 | 并发太高触发限速 | 把并发降到 4 到 6 |
| 合并后体积异常小 | 选错了低码率的那一路流 | 按bandwidth字段重新挑 |
5.2 几个容易被忽略的细节
关于“备份地址”。播放描述里的backupUrl不是摆设。主地址在某些网络环境下会被限速，切换到备用地址往往能恢复正常速度。脚本里可以做个简单的主备切换：连续三次失败就换备用域名重试。这个改动只有几行，但在网络不稳定的环境下体验差别很大。
关于Range请求。有些站点的分片地址其实指向同一个 URL，靠Range头切分字节区间。这种形态在网络面板里看起来像“一个请求下了很多次”。遇到这种情况，你的脚本要把每条请求的Range值也记录下来，不能只存 URL。
关于磁盘空间。一个 1080P、40 分钟的视频，视频轨加音频轨加起来可能 1.5 GB 到 3 GB。下载过程中还要额外占一份临时文件的空间。开始之前先看一眼可用空间，我吃过一次跑到 98% 卡住的亏，清理起来很麻烦。
关于文件名的可读性。建议在最外层目录带上标题和清晰度标识，比如某课程名_1080P_avc1/。几百个00001.m4s散在一个叫download的目录里，过两天你自己都不知道那是什么。
注意：处理音视频素材时，请确认你对目标内容拥有合法的访问和使用权限。方案涉及的技术手段仅适用于个人离线备份、自有内容处理、以及公开授权素材的整理。不要用于二次分发、商业使用或任何侵犯他人权益的场景，同时遵守所在平台的服务条款。
5.3 我在实际使用中总结的三条经验
第一条，先跑通一个分片，再跑全部。不要一上来就对着 300 个分片开跑。先手工下第一片，用ffprobe或者文件头检查确认它是有效的媒体数据，再放到脚本里批量执行。这个习惯能帮你把“地址错了”和“脚本逻辑错了”这两类问题彻底分开。
第二条，把日志写下来，不要只 print。批量下载跑到一半崩了，终端滚屏早刷没了。把每次的序号、状态码、文件大小、耗时写进一个download.log，出问题时直接grep FAIL就能定位。这个改动五分钟，回报很高。
第三条，合并结果一定要验，不要靠“看起来能播”。人的眼睛对轻微的时长差异、帧率异常是不敏感的，尤其是你不熟悉的素材。ffprobe输出三行，看一眼时长和流信息，三十秒的事，但能避免你三个月后才发现存档是坏的。
这套流程我前后迭代了好几版，从最早的手工点几百次、到串行脚本、再到现在的并发加校验，最大的感受是：技术难度其实不高，难的是细节的完整性。每一个校验、每一次重试、每一个请求头，单看都不起眼，但它们合在一起决定了你是花二十分钟搞定，还是花两小时debug。真要说有什么诀窍，就是把“验证”这件事前置——下之前验地址，下完验文件，合并前验数量，合并后验结果。四道关卡摆在那里，剩下的就是等进度条了。
