浏览器抓包下载网页视频：DASH/HLS分片与ffmpeg合并

1. 先搞清楚为什么网页上的视频右键菜单里没有“另存为”想把自己收藏夹里的一段教程、一场讲座、一个手工制作过程存到本地断网也能反复看这个需求本身一点都不复杂。麻烦的是很多人第一反应是去找一个“视频下载器”装完之后发现桌面多了三个不认识的图标浏览器主页也被改了。其实现在的浏览器自带的开发者工具已经能把这件事干完只是它不会给你一个明晃晃的按钮需要你稍微懂一点播放器在背后做了什么。我在带新人的时候经常说一句话你看到的视频画面和你浏览器真正下载到的数据往往是两回事。这句话不理解后面的所有操作都是瞎点。所以这一节不讲步骤只讲原理把“网页版视频能不能直接存、为什么右键存不了”这件事彻底说透。等你明白了播放器的工作方式再看后面抓请求、拼文件的操作就会觉得顺理成章而不是照着别人的截图一步步试错。1.1 渐进式播放和流式播放是两种完全不同的东西早期的视频网站用的是渐进式下载progressive download。服务器上放着一个完整的xxx.mp4浏览器请求这个地址一边接收一边播放。这种模式下video标签的src属性写的就是那个真实的.mp4地址你在页面上右键浏览器知道“这是一个文件链接”所以“视频另存为”是可用的甚至直接把这个地址复制到新标签页也能弹出下载框。现在的平台基本都换成了流式播放技术上叫 MSEMedia Source Extensions加 DASH 或 HLS。播放器不再向服务器要“一个文件”而是要“一段一段的数据”拿到之后通过 JavaScript 塞进一个叫SourceBuffer的缓冲区里浏览器再从这个缓冲区解码出画面。这时候你去审查元素会看到video srcblob:https://xxx/8f3a-....这个blob:开头的地址是浏览器在内存里临时生成的一个句柄它指向的是 JS 维护的那块缓冲区不是一个真实存在于网络上的文件。这就解释了那个让很多人困惑的现象明明视频在放网络面板里也有一堆数据在跑但你就是找不到一个能右键保存的地址。因为从浏览器的视角看它从来没有“下载过一个文件”它只是收到了一堆二进制片段。对比项渐进式老式 MP4流式MSE DASH/HLSvideo 标签 src真实 http(s) 地址blob:开头的内存句柄右键另存为通常可用灰色或保存下来是空文件网络请求特征单个请求带 Range 分段续传多个请求分片或多次 Range音视频关系通常封装在同一个文件里视频轨、音频轨完全分离处理难度复制地址即可需要抓包、分别下载、再合并1.2 音视频分离这件事是后面所有麻烦的源头流式播放为了节省带宽普遍采用音视频分离的封装方式。也就是说你看到的这一段视频服务器实际上是分两条流发过来的一条只有画面video track一条只有声音audio track播放器在本地把它们对齐时间戳再合成。这么做的好处是用户切换清晰度的时候只需要换视频轨音频轨不用重新下载网络差的时候也可以只降视频码率。但对想保存到本地的人来说这就意味着你抓到的“视频文件”很可能是一个没有声音的哑片。我第一次做这件事的时候就栽在这上面辛辛苦苦把一个几百兆的文件弄下来双击打开画面很清晰一点声音都没有当时还以为是文件损坏折腾了半天才发现自己只下了视频轨。所以你要建立一个预期在这类平台上完整的保存流程通常是“下载视频轨 → 下载音频轨 → 合并成一个文件”三步缺一不可。这也是为什么后面要专门用一节讲合并而不是简单地说“复制链接下载就完事了”。1.3 先判断你面对的是哪一种能省掉一半工作量不是所有内容都走 DASH。平台上的老视频、部分低清晰度版本、一些用户上传的源文件仍然可能是单文件的 MP4。这种情况下事情就简单太多了根本不需要什么控制台脚本复制地址直接下载就行。判断方法很直接三步在播放页面按 F12 打开开发者工具切到 Elements 面板搜索video标签看它的src是什么。如果是blob:开头基本可以确定是流式如果是http开头且以.mp4结尾恭喜你直接复制。切到 Network网络面板刷新页面并让视频播放几秒看请求列表里的文件后缀。出现.m4s、.ts、.m3u8这些就是流式出现单个体积很大的.mp4就是渐进式。看请求的 Headers 里有没有Range: bytes0-这样的字段。有 Range 不代表一定是流式但如果同一个 URL 反复出现、每次 Range 区间不同说明播放器在按需拉取片段你保存单条响应只会得到一个残片。把头三步走完你心里就有数了是“复制地址就能解决”还是“要抓两条流再合并”。这一步花两分钟能避免后面半小时的无效折腾。2. 用开发者工具把真正的媒体请求揪出来原理讲完进入动手环节。这一节的目标很明确在密密麻麻的网络请求里准确找到那个承载视频数据的请求并且把完整的 URL 连同必要的请求信息一起拿到手。听起来简单但实际上很多人卡在这里因为现代网页的请求数量动辄几百条还有各种埋点、心跳、预加载在干扰。我总结了一套自己常用的过滤流程按顺序做命中率很高。2.1 三层过滤把几百条请求压缩到个位数第一层是类型过滤。Network 面板顶部有一排标签All、Fetch/XHR、JS、CSS、Img、Media、Font、Doc、WS、Manifest、Other。直接点Media。这一层会把所有图片、脚本、样式全部挡掉只留下浏览器认为是媒体资源的请求。大部分情况下视频轨和音频轨都会出现在这里。第二层是关键词搜索。如果 Media 分类里还是太多或者什么都没抓到有些播放器用 XHR 拉流会被归到 Fetch/XHR就用面板左上角的搜索框快捷键 CtrlF输入m4s、m3u8、mp4这类后缀。搜索是对所有已记录的请求做全文匹配连响应内容都能搜非常好用。第三层是按体积排序。点击列表里的 Size 列从大到小排。视频轨一定是体积最大的那一条动辄几 MB 甚至几十 MB音频轨通常小一个数量级。这个规律在绝大多数场景下都成立因为画面数据天然比声音数据大得多。三层过滤做完列表里一般就剩两三条请求了。这时候不要急着复制先做一件事把“Preserve log”保留日志勾上。因为播放页面在切换清晰度、跳转进度的时候可能会触发页面重载不勾这个选项你之前抓到的记录会被清空白忙一场。2.2 怎么从请求里区分视频轨和音频轨剩下那两三条请求怎么知道哪条是画面、哪条是声音有三个线索可以互相印证。线索一URL 里的 MIME 参数。这类平台的媒体地址通常很长带一堆查询参数其中往往有mimevideo%2Fmp4或者mimeaudio%2Fmp4这样的字段%2F是斜杠的转义。直接看参数值就知道是哪条轨这是最省事的判断方式。线索二响应体积。前面说过视频轨明显更大。如果两条请求都是几 MB那就看后续的请求次数视频轨因为数据量大通常会被切成更多段。线索三请求的先后顺序和频率。一般播放器会先请求音频轨体积小、加载快先出声再请求视频轨或者两条并发。播放过程中视频轨的请求频率明显更高。拿到两条 URL 之后先别管怎么下载先做一件必须做的事在请求上右键选择 Copy → Copy link address把两条地址都粘贴到一个文本文件里存好。因为这个地址里带着签名参数是有时效的后面如果页面刷新或者时间拖久了地址就失效了你得重新抓一遍。先存下来能省很多事。2.3 注意 Range 请求你可能只抓到了一个片段这是最容易踩的坑我必须单独拎出来说。流式播放器为了快速起播不会一次性把整个视频拉下来而是按需请求。你在 Network 面板里看到的同一条 URL可能对应十几条记录每条记录的 Request Headers 里都有类似Range: bytes0-131071、Range: bytes131072-262143这样的字段表示“我只要这段字节”。如果你在这样一条记录上右键“保存响应”你得到的只是这一小段数据通常只有一百多 KB用播放器打开要么打不开要么只有零点几秒的画面。很多人以为自己下载成功了结果发现文件只有几百 KB就是这个原因。正确的处理方式有两种。一种是把所有 Range 片段按顺序全部下载下来再二进制拼接麻烦且容易出错另一种更省事就是用完整地址重新发一次不带 Range 的请求让服务器把整个文件吐给你。这正是下一节要讲的方案。这里的判断依据很简单点开任意一条媒体请求看 Headers 里Request Headers部分如果有Range说明这是分段请求别直接保存。3. 直链打不开的 403防盗链和签名参数在拦你把抓到的地址粘贴到浏览器新标签页回车结果页面一片空白或者提示 403 Forbidden。这个场景几乎每个第一次尝试的人都会遇到然后就开始怀疑是不是自己抓错了地址。其实地址是对的问题出在请求上下文上。这一节把 403 的成因拆开讲并且给出一个不需要安装任何东西、直接在页面里就能完成的解法。3.1 Referer 校验服务器在看你从哪来HTTP 请求头里有一个Referer字段记录的是“这个请求是从哪个页面发起的”。浏览器在页面内发起请求时会自动带上当前页面的地址而你直接在地址栏输入一个 URL 回车这个请求没有来源页面Referer 就是空的。媒体服务器为了防止资源被外部站点盗用通常会校验这个字段只接受来自本平台页面的请求Referer 为空或者来自其他域名的一律拒绝。这就是为什么你在页面里能正常播放把地址复制出来单独打开就 403。这个机制本身很简单绕过它的思路也很简单让请求从页面内部发出去而不是从地址栏发出去。浏览器会自动帮你补上 Referer服务器看到来源合法就放行了。具体怎么做看 3.3。3.2 URL 里的时效参数抓晚了就白抓除了 Referer这类媒体地址通常还带签名和过期时间。你会在 URL 参数里看到类似deadline、expires、sign、token这样的字段。其中deadline这类参数往往是一个十六进制的 Unix 时间戳转换一下就能看出这个地址在什么时刻失效。我实测的经验是这类地址的有效期通常在几十分钟到两小时之间。听起来挺宽裕但如果你抓完地址先去泡了杯茶、回了几个消息回来再下载很可能就过期了。过期之后的报错同样是 403和 Referer 问题长得一模一样很容易误判。怎么区分这两种 403看响应内容。Referer 被拒的时候返回的往往是一个简短的错误页或者 XML签名过期的话有时候会返回更明确的提示。更快的办法是把地址复制回播放页面的同一个浏览器标签里用控制台发起请求也就是 3.3 的方法如果还是 403那大概率是过期了刷新页面重新抓一次即可。养成“抓完立刻下”的习惯能省掉大量排查时间。3.3 在控制台里发请求让浏览器自己把上下文补齐这是整篇文章里最核心的一个操作。原理不复杂在播放页面的 Console控制台里执行一段 JavaScript用fetch去请求那两条媒体地址。因为代码运行在页面环境下浏览器会自动带上正确的 Referer 和 Cookie因为播放器本身就在跨域拉流媒体服务器必然返回了允许跨域的响应头所以fetch不会因为 CORS 被拦。拿到数据之后把它转成 Blob再用一个临时的a download触发浏览器下载。整个过程不需要任何插件不需要任何外部程序就是浏览器自己在干活。(async () { // 把这里换成你抓到的两条地址 const tasks [ { url: https://example-cdn.com/xxx/video.m4s?mimevideo%2Fmp4deadline..., name: video.m4s }, { url: https://example-cdn.com/xxx/audio.m4s?mimeaudio%2Fmp4deadline..., name: audio.m4s } ]; for (const t of tasks) { try { console.log(开始下载, t.name); const res await fetch(t.url, { credentials: omit }); if (!res.ok) { console.error(t.name, 请求失败状态码, res.status); continue; } const blob await res.blob(); console.log(t.name, 大小, (blob.size / 1024 / 1024).toFixed(2), MB); const a document.createElement(a); a.href URL.createObjectURL(blob); a.download t.name; document.body.appendChild(a); a.click(); a.remove(); // 稍等一下再释放避免下载还没开始就被回收 setTimeout(() URL.revokeObjectURL(a.href), 10000); await new Promise(r setTimeout(r, 2000)); } catch (e) { console.error(t.name, 出错, e); } } console.log(全部任务结束); })();几个使用上的细节都是踩过坑之后总结的credentials: omit是有意为之。签名已经在 URL 里了不需要额外带 Cookie如果带上 Cookie 反而可能触发跨域的凭证校验失败。如果某条地址确实需要登录态再改成include但要确认服务器返回了Access-Control-Allow-Credentials。两条任务之间加两秒间隔是因为浏览器对同一站点的并发下载有数量限制连续触发两个大文件容易其中一个被挂起。下载大文件时控制台可能会卡一下这是正常的因为整个文件要先在内存里转成 Blob。几百 MB 以内一般没问题超过 1 GB 就要考虑 6.1 里说的分段方案。如果res.ok是 false 且状态码 403八成是地址过期刷新页面重新抓不要在原地址上反复试。提示执行脚本期间不要刷新页面也不要关闭标签页否则页面上下文销毁正在进行的请求会中断。4. 两轨到手之后不装下载器的合并路线到这一步你的下载文件夹里应该躺着video.m4s和audio.m4s两个文件。双击视频文件画面清晰但没有声音双击音频文件大部分播放器根本打不开。这不是失败只是还没到终点。这一节讲怎么把它们合成一个正常的 MP4并且按“愿不愿意碰命令行”分成两条路线你可以按自己的习惯选。4.1 先试试能不能省掉合并这一步在动手合并之前值得花一分钟确认一下有没有可能直接拿到单文件版本有些内容平台在特定清晰度下仍然提供音视频一体的 MP4尤其是一些较早上传的稿件、部分低码率版本。判断方法还是看 Network 面板如果你在 Media 分类里只看到一条体积很大的.mp4请求没有独立的音频轨那恭喜你直接下载就是完整文件。另一个思路是换清晰度试试。不同清晰度走的封装策略可能不一样低清晰度更倾向于用单文件来降低播放器复杂度。你可以先在播放器里把清晰度切到较低档再刷新 Network 面板观察请求变化。当然代价是画质下降值不值得看你的用途——如果只是离线听讲座360P 完全够用如果是要看清手工细节那就老老实实走合并路线。顺便说一句.m4s这个后缀本身就是 fMP4分片 MP4格式只是平台给它换了个名字。有人会尝试直接把后缀改成.mp4有时候视频轨能播放无声音频轨改成.m4a之后部分播放器也能识别。这招偶尔管用但不保证时间戳对齐音画可能会不同步只适合应急。4.2 用命令行封装干净、快、无损真正的合并需要一个“封装工具”把两条独立的轨道按时间戳塞进同一个 MP4 容器里。这里要澄清一个概念封装工具不是下载工具。它不联网、不抓地址、不解析页面只做本地文件的重新打包而且用的是流复制stream copy不解码不重编码速度极快几分钟的视频通常几秒钟就完成画质音质零损失。主流选择是 ffmpeg命令行一行搞定ffmpeg -i video.m4s -i audio.m4s -c copy -map 0:v:0 -map 1:a:0 output.mp4参数逐个解释一下方便你以后举一反三-i video.m4s -i audio.m4s两个输入顺序无所谓但后面的-map要对应上。-c copy流复制不重新编码。这是速度和质量的关键千万别漏。-map 0:v:0从第 0 个输入里取第 0 条视频流。-map 1:a:0从第 1 个输入里取第 0 条音频流。output.mp4输出文件名容器用 mp4 兼容性最好。如果合并出来的文件时长不对比如只有几秒或者音画不同步通常有两个原因一是你下载的某一轨其实是残缺的 Range 片段回到 2.3 检查二是两条轨的时间戳基准不同这时候可以加-fflags genpts让工具重新生成时间戳。这两种情况我都遇到过前者居多。Windows 用户如果没有命令行环境也完全可以做把 ffmpeg 的可执行文件解压到某个目录在该目录里按住 Shift 右键选择“在此处打开命令行”然后执行上面那行命令。整个过程不需要装任何“全家桶”软件。4.3 完全不想碰命令行的话代价是什么如果你对命令行有心理阴影也有一些浏览器内的替代思路但我得把代价说清楚免得你白折腾。思路一录屏。用系统自带的录屏功能把视频从头到尾播一遍录下来。优点是零工具、零门槛缺点是耗时等于视频时长画质有二次损失而且录进去的还有播放器的进度条、鼠标指针。适合“就想要个大概内容”的场景不适合收藏。思路二用浏览器内的媒体处理库。有些网页版的媒体处理工具可以在浏览器里完成封装把两个文件拖进去合成。这类方案确实不用安装软件但处理大文件时受浏览器内存限制明显几百 MB 以上容易崩。而且它本质上还是一个“工具”只是跑在浏览器里而已。思路三找支持直接播放分片文件的播放器。有些播放器能识别 fMP4 分片但它没法把两条独立的轨道自动合到一起你还是得面对合并这一步。我的建议是如果这件事你只做一次用录屏或者在线工具凑合如果你以后还会反复遇到花十分钟把命令行那行命令记住长期收益远大于一次性的学习成本。5. 分片流和直播场景m3u8 与 ts 的处理差异前面讲的都是点播视频的 DASH 方案m4s 分片。但平台上还有另一类内容——直播、部分番剧、部分活动页——走的是 HLS 协议你在 Network 面板里看到的不是m4s而是一个.m3u8文件加一堆.ts小文件。处理思路不同得单独说。5.1 m3u8 其实是一个纯文本的播放清单.m3u8不是什么二进制格式它就是一个 UTF-8 的文本文件里面用一行行的指令描述“这个视频由哪些分片组成、每片多长、按什么顺序播”。你在 Network 面板里找到它之后右键 Copy link address粘贴到新标签页打开如果是普通点播的清单通常能直接看到内容。典型内容长这样#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10.000, segment-0.ts #EXTINF:10.000, segment-1.ts #EXTINF:9.960, segment-2.ts #EXT-X-ENDLIST几个关键点#EXTINF后面跟的是这一片的时长秒下一行是分片的地址可能是相对路径需要和 m3u8 的地址拼一下才能得到完整 URL#EXT-X-ENDLIST表示清单结束有这个标记说明是点播内容已经完整没有的话就是直播清单会不断追加新分片。还有一种多码率清单master playlist里面不是 ts 地址而是一堆子清单的地址每行前面带#EXT-X-STREAM-INF:BANDWIDTH...。这种情况你要先挑一个码率合适的子清单再打开那个子清单才能看到真正的分片列表。判断方法很简单打开后如果看到的还是.m3u8结尾的地址就是多码率清单。5.2 按顺序拉取分片注意拼接方式拿到分片地址列表之后处理方式和前面类似也是在控制台里循环 fetch。思路是把清单里的地址解析出来按顺序下载成 Blob最后拼成一个大的 Blob 再触发下载。(async () { const base https://example-cdn.com/path/; // m3u8 所在目录 const listRes await fetch(base index.m3u8); const text await listRes.text(); const lines text.split(\n).map(s s.trim()); const segs lines.filter(l l !l.startsWith(#)); console.log(分片总数, segs.length); const blobs []; for (let i 0; i segs.length; i) { const url segs[i].startsWith(http) ? segs[i] : base segs[i]; const r await fetch(url); if (!r.ok) { console.error(分片失败, i, r.status); continue; } blobs.push(await r.blob()); console.log(已下载 ${i 1}/${segs.length}); } const merged new Blob(blobs, { type: video/mp2t }); const a document.createElement(a); a.href URL.createObjectURL(merged); a.download output.ts; document.body.appendChild(a); a.click(); a.remove(); })();关于拼接有两点经验。第一ts 分片可以直接二进制首尾相接因为每个 ts 包都是独立的顺序拼起来的文件大多数播放器都能播但更稳妥的做法是用封装工具过一遍ffmpeg -i output.ts -c copy final.mp4让工具重新整理时间戳和容器结构。第二顺序不能乱。清单里的顺序就是播放顺序如果你并发下载、乱序 push拼出来的文件会变成一坨乱码画面。所以上面的代码是老老实实串行await的慢一点但不会出错。直播场景要额外注意一点清单是滚动的旧的片段会被移出列表所以你抓到的清单只代表“此刻往前的一小段”。想完整保存一场直播需要在开播时就开始持续轮询清单、增量下载新出现的分片这不是一次性的操作。这部分展开会很长而且涉及的内容更敏感这里只把原理点到位具体场景请自行判断必要性。6. 实操里最容易翻车的几个细节前面几节把主流程走完了但真正动手的时候失败往往不是因为原理不懂而是栽在一些边角问题上。这一节把我自己踩过、也见别人踩过的坑集中列一下遇到问题可以对照排查。6.1 大文件下载到一半浏览器崩了这是控制台方案最典型的失败场景。因为fetchblob()是把整个文件先读进内存再落盘一个 1 GB 的视频峰值内存占用可能到 1.5 GB 以上配置一般的机器或者标签页开得多的时候很容易触发浏览器的内存回收表现为“下载到 80% 突然没反应了”或者标签页直接崩溃。应对办法有几个层次。最轻量的做法是下载前把其他标签页关掉尤其是那些开了视频、地图、在线文档的重页面给浏览器腾出内存。再进一步是改成分片下载如果媒体地址支持 Range大部分都支持可以用循环发多次带Range头的请求每次拉 50 MB把结果存进一个数组最后一次拼成 Blob。这样单次内存峰值小很多代价是代码复杂一些。最彻底的做法是换成流式写入磁盘的方案但那需要引入额外的库就违背了“不装工具”的初衷了。我的实际经验是单个文件在 500 MB 以内控制台方案基本稳超过 1 GB建议先考虑有没有必要下这么高清晰度的版本或者干脆分段来。6.2 文件下下来了但是花屏、没声音、时长不对这几种症状对应的原因非常明确可以按表排查症状最可能的原因处理方式完全没声音只下载了视频轨音频轨漏了回到 Network 补抓音频轨重新合并只有声音没画面下载的是音频轨同上确认两条都下了播放几秒就卡住下载的是单个 Range 片段用完整地址重新请求不要保存单条响应花屏、马赛克、画面撕裂分片顺序错乱或片段缺失检查是否并发乱序改为串行按序下载时长明显偏短播放器只加载了已缓冲部分让视频完整播放一遍再抓或直接拉全量音画不同步两条轨时间戳基准不一致合并时加-fflags genpts重新生成时间戳顺便提醒一个细节有些播放器在你不拖动进度条的情况下只会请求已经看过的那部分数据。也就是说如果一个视频 40 分钟你只看了前 5 分钟就跑去抓包抓到的地址可能对应的是“按需加载”的地址全量请求时未必能拿到完整内容。稳妥的做法是先把进度条拖到最后让整个视频都过一遍再刷新 Network 面板重新抓。6.3 清晰度、账号态和地址时效三个变量互相牵连最后说三个容易忽略但影响很大的变量。清晰度。播放器默认可能只请求 480P你抓到的就是 480P 的地址。想要更高清必须先手动在播放器里切到目标清晰度等画面真正变化之后再抓包。而且不同清晰度对应的是完全不同的 URL换了清晰度就得重新抓一遍不能复用。账号态。部分内容的媒体地址和登录状态绑定URL 里带的签名是基于你的账号生成的。这意味着你抓到的地址别人拿到了也用不了同时也意味着你换个浏览器、退出登录之后这个地址就失效了。这一点在自己机器上操作时感知不强但如果你想在另一台设备上下载就会撞墙。时效。前面提过这里再强调一次地址里的过期时间通常在几十分钟量级。我吃过的最亏的一次是抓完地址去吃饭回来发现全部 403只能从头再来。所以现在的习惯是抓包、下载、合并一口气做完中间不插入其他事情。注意以上所有操作请仅用于个人离线观看、学习研究等合理用途下载的内容不要二次上传、不要用于商业传播。平台的内容是有版权的技术手段可行不代表使用方式可以随意。7. 我个人的几个使用习惯这套流程我用了挺长时间从最早傻乎乎地存 Range 片段到后来摸清楚 DASH 的脾气中间浪费的时间够看完好几部纪录片了。现在我的习惯固定成三步先花一分钟判断是单文件还是分离流如果是单文件就直接复制地址收工如果是分离流先把清晰度切到位、让视频完整缓冲一遍然后再开 Network 抓包抓到之后立刻在控制台跑脚本下完马上合并绝不隔夜。还有一个我特别想分享的小技巧把常用的下载脚本存成一个浏览器书签bookmarklet或者存在自己的笔记里用的时候改两个 URL 就能跑比每次现敲省事得多。另外合并命令也可以写成一个小脚本把文件名做成参数merge video.m4s audio.m4s out.mp4一行搞定用久了形成肌肉记忆比记一堆参数靠谱。至于清晰度的选择我的建议是不要迷信最高档。4K 的码率是 1080P 的好几倍文件大小差距悬殊但如果是看讲座、看代码演示这类内容1080P 已经完全够用下载时间和内存压力都小很多。真正需要高码率的场景其实很有限比如要看清楚手工制作里的针脚细节、或者画面里有大量文字需要放大阅读。搞清楚自己的用途再选清晰度比无脑拉满更划算。