企业官网建设流程全解析

做视频下载这件事，圈子里一直有个共识：网页上能播的东西，理论上就能存下来。但等真正动手去搞腾讯视频这类平台的M3U8加密链接时，很多人还是会被卡住——要么抓包抓不到真正的索引地址，要么拿到m3u8文件却发现里面的TS分片全是加密的，下载下来根本放不了。这篇文章就是来把这个过程彻底讲透的。

我会用Python把从抓取M3U8索引、解析加密参数、获取解密Key、到多线程下载TS分片、最后用FFmpeg合并成MP4的完整链路走一遍。整个过程基于腾讯视频网页端真实的播放协议来实战拆解，所有代码和思路你都能直接复现。这篇文章适合有一定Python基础、想搞懂流媒体下载原理、或者正在做视频处理相关工具的朋友，看完你不仅能搞定腾讯视频，换到其他用HLS协议加密的站点也能举一反三。

先提醒一句：以下技术内容仅用于学习流媒体协议和下载自己拥有合法版权的视频，请不要用于传播或下载他人享有版权的影视内容。

1. 项目背景与核心技术拆解

1.1 腾讯视频为什么用M3U8加密

腾讯视频网页端目前主流的播放方式是基于HLS（HTTP Live Streaming）协议。HLS是苹果推出的流媒体传输协议，核心思路很简单：把一整段视频切分成无数个小片段（通常是TS格式），再用一个索引文件把这些片段的地址按顺序记录下来，这个索引文件就是M3U8。

你可能会问，为什么不直接给一个MP4链接非要搞得这么麻烦？这里有几个实际原因。第一是省流量，播放器可以根据用户当前的网络状况动态切换清晰度，网络差就播低码率的分片，网络好就自动切到高码率，体验比一整段大文件平滑得多。第二是防盗版，腾讯视频在每个TS分片上都做了AES-128加密，播放器必须拿到对应的Key才能解密播放。你直接下载下来拿到一堆加密的TS文件，没有Key根本放不出来。

在实际抓取过程中你会发现，腾讯视频的M3U8链接是嵌套结构。播放器首先加载一个主索引（master playlist），里面按清晰度列出了多个子索引地址，比如480P、720P、1080P各对应一个独立的M3U8文件，每个子索引才真正指向具体的TS分片列表。所以网上很多人说抓到M3U8地址但下载失败，八成是抓到了主索引而不是子索引。

1.2 解析下载的完整技术链路

整个项目的技术链路可以拆成五个环节，每个环节都有对应的坑：

1. 抓包定位M3U8链接：通过浏览器开发者工具，从Network面板里过滤出Type为m3u8的请求，拿到真正的子索引地址。
2. 请求M3U8索引内容：用Python的requests库模拟浏览器请求，带上完整请求头，解析出TS分片URL列表和AES-128加密参数。
3. 获取解密Key：从M3U8文件的EXT-X-KEY标签里提取Key的下载地址，请求后拿到16字节的二进制Key。
4. 下载并解密TS分片：逐个请求TS片段，用Key和IV（初始向量）进行AES-128-CBC解密，把解密后的数据写入本地文件。
5. 合并TS为MP4：所有分片解密完成后，用FFmpeg按顺序合并并转封装成MP4。

这里容易被忽略的是IV参数。腾讯视频的M3U8索引里，EXT-X-KEY标签通常会带IV=0x...这样的参数，如果没带，默认IV是0x00000000000000000000000000000000。AES-128-CBC解密要求每个分片的IV不同（通常通过IV加分片序号计算），但腾讯视频的做法是对每个分片使用相同的IV，解密时直接使用索引里给的IV即可。很多人解密出来画面花屏，就是IV没用对。

2. 环境准备与核心概念补充

2.1 Python环境与依赖库安装

建议使用Python 3.8以上版本，推荐直接用Anaconda或者官方Python发行版。项目依赖不多，核心就两个：requests用于HTTP请求，pycryptodome用于AES解密。另外需要安装FFmpeg外部工具用于最后合并。

pip install requests pycryptodome

FFmpeg的安装分系统来看。Windows用户直接到FFmpeg官网下载release版本，把bin目录加到系统PATH里；macOS用户用Homebrew一条命令搞定：brew install ffmpeg；Linux用户用各自的包管理器安装，比如Ubuntu执行sudo apt install ffmpeg。安装完成后在终端输入ffmpeg -version验证，能输出版本号就是成功了。

注意：pycryptodome和pycrypto不能同时安装，这两个包存在冲突，如果之前装过pycrypto先卸载干净。另外Windows下如果遇到安装报错，可以用Anaconda的conda环境避免C编译器的问题。

2.2 M3U8索引文件的三种形态

理解M3U8的内容结构是解析的前提。我在实战中总结了三种常见形态：

第一种是主索引（Master Playlist），文件里没有TS分片地址，只有一串子索引URL。你打开看看到处是#EXT-X-STREAM-INF标签，它下面跟着的URL是另一个M3U8文件的地址。

第二种是媒体索引（Media Playlist），这才是真正包含TS分片地址的文件。文件开头是#EXTM3U，中间有#EXTINF标签（表示分片时长），下面跟着分片地址。同时文件里会有#EXT-X-KEY标签，这是加密信息的关键。

第三种是独立分片地址形式，某些情况下M3U8里的分片地址是相对路径，比如/hlstoken/seg_001.ts，需要自己拼接完整的域名才能请求。

实战中我用m3u8这个第三方库来解析索引，这个库会自动处理相对路径拼接和标签解析，比纯正则表达式靠谱得多：

pip install m3u8

当然，不用这个库也行，直接读文本用正则提取EXTINF和EXT-X-KEY也能做，但代码会繁琐一些，而且遇到不同平台的M3U8格式差异时容易翻车。m3u8库本身有容错处理，推荐直接用。

3. 实战第一步：抓取加密M3U8索引链接

3.1 打开浏览器抓包的正确姿势

很多人在抓包这一关就被卡住了。我来说说正确流程：用Chrome或Edge打开腾讯视频网页端，按F12打开开发者工具，切换到Network面板。然后在过滤器里输入m3u8，刷新页面开始播放视频，这时你会看到一系列网络请求被列出来。

这里有个关键技巧：要在视频开始播放之前就打开Network面板，否则播放器已经加载完索引，你很可能错过了关键的M3U8请求。如果没抓到，就清空面板重新刷新页面。腾讯视频比较特殊的是，它的M3U8链接有时会通过fetch请求返回，这种请求在Network里的Type列显示为fetch或者xhr，不一定直接叫m3u8，需要自己根据URL后缀和响应内容来判别。

另外一个技巧是：把Network面板的Preserve log选项打开（保留日志），这样即使页面跳转，之前的请求记录也不会被清空。我实际用下来，腾讯视频网页端的请求量比较大，加上过滤条件后依然是好几条记录，要自己逐个点开看Response内容，找到那个内容以#EXTM3U开头的就是我们要的。

3.2 从Network面板定位真正的M3U8地址

找到M3U8类型的请求后，在Headers里找到Request URL，这一条就是播放器实际拉取的索引地址。但就像前面说的，这个地址很可能是主索引而不是媒体索引。判断方法很简单，直接在浏览器新标签页打开这个URL，如果返回的内容里都是#EXT-X-STREAM-INF和子索引URL，说明是主索引；如果返回的内容里是#EXTINF和一堆TS分片地址，说明就是媒体索引了。

腾讯视频的M3U8链接结构大概是这样的：

https://*.m3u8?start=xxx&end=yyy&type=mp4&vid=xxx

如果拿到的是主索引，还需要再请求子索引。实际项目里我用Python做了一步自动判断，拿到M3U8内容后先检测是否有#EXT-X-STREAM-INF标签，有的话就继续请求子索引，这样在代码层面就可以实现自动穿透主索引定位到媒体索引。

3.3 用Python模拟请求获取索引内容

拿到链接之后，直接用requests请求是很容易失败的，因为腾讯视频的CDN节点有防盗链机制。我在实际调试中发现，至少需要带上User-Agent和Referer两个请求头，其中Referer必须指向腾讯视频的播放页面地址，否则返回403。

这里给出一段最基础的请求M3U8内容的代码：

import requests headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "Referer": "https://v.qq.com/", } def get_m3u8_content(url): resp = requests.get(url, headers=headers, timeout=10) resp.raise_for_status() return resp.text m3u8_url = "你抓到的M3U8链接" content = get_m3u8_content(m3u8_url) print(content[:500]) # 先看前500个字符判断索引类型

代码本身很简单，核心是请求头设置。我在多次调试中发现，光有User-Agent和Referer还不够，某些情况需要带上完整的Cookie。如果页面是登录状态，就把浏览器里的Cookie复制过来加到请求头里。但需要注意Cookie是有时效的，一般几小时到几天就会失效，失效后会返回212错误码或者401状态码，到时候重新抓取即可。

拿到M3U8内容后，先打印前500个字符做个快速判断，再决定下一步是继续请求子索引还是直接解析TS分片地址。

4. 实战第二步：解析索引、解密TS分片并下载合并

4.1 用m3u8库解析索引结构

拿到媒体索引后，直接用m3u8库解析，代码非常简洁：

import m3u8 def parse_m3u8(url): playlist = m3u8.load(url, headers=headers) print("分片数量:", len(playlist.segments)) if playlist.keys: for key in playlist.keys: print("加密方法:", key.method) print("Key地址:", key.uri) print("IV:", key.iv) return playlist

这里playlist.keys是个容易被忽略的属性。如果M3U8里的分片做了加密，这个列表里会有EXT-X-KEY标签的解析结果，包含三个关键信息：method（通常是AES-128）、uri（Key文件的下载地址）、iv（初始向量）。如果iv是None，说明用的是默认值，即全零的16字节数组。

我实际调试时发现，腾讯视频在M3U8里会把Key地址写成一个相对路径，比如/xxx/key.bin，m3u8库在解析时会自动拼上完整的域名，直接用就行了。如果你用正则自己解析，千万别忘了这个拼接逻辑，不然请求Key文件会404。

解析出playlist.segments后，每一个segment对象有几个属性需要用：uri（TS分片地址）、title（分片标题，有些平台会在这里放时长信息）、program_date_time（可选）。注意segment.keys可能和playlist级别的keys不一样，如果TS分片单独设置了Key，以分片上的为准。

4.2 获取解密Key并初始化AES-128解密器

这是整个项目中最核心的部分。先请求Key文件，Key文件是16字节的二进制数据，不是一个文本。我见过很多新手直接把Key当成字符串处理，解密出来的内容全是乱的。

from Crypto.Cipher import AES from Crypto.Util.Padding import pad, unpad def get_decryptor(key_url, iv=None): resp = requests.get(key_url, headers=headers, timeout=10) key_data = resp.content # 二进制数据，长度为16 assert len(key_data) == 16, f"Key长度异常: {len(key_data)}" if iv: iv_data = bytes.fromhex(iv[2:]) # 去掉0x前缀 else: iv_data = b'\x00' * 16 cipher = AES.new(key_data, AES.MODE_CBC, iv_data) return cipher

这里有几个值得注意的细节。第一，iv参数如果带了0x前缀，需要先去掉再bytes.fromhex转换。第二，AES-128的Key和IV都是16字节，多了少了都会报错。第三，腾讯视频用的IV如果是明文写在M3U8里的，直接解析即可；但有些平台的IV是根据分片序号动态生成的，这种情况需要另做处理，Marcher（当前场景）碰到的都是固定IV。

解密的过程是按分片逐个处理：

def decrypt_segment(segment, cipher): resp = requests.get(segment.uri, headers=headers, timeout=10) encrypted_data = resp.content decrypted_data = cipher.decrypt(encrypted_data) # 去除PKCS7填充 pad_len = decrypted_data[-1] return decrypted_data[:-pad_len]

CBC模式的解密器创建后可以一直复用，不需要为每个分片重新创建，这样能节省一部分性能开销。但要注意，cipher.decrypt调用后，状态会变化，如果对每个分片都调用一次，顺序必须正确。实际项目中更稳妥的做法是为每个分片创建一个新的cipher实例，虽然多花一点点创建成本，但不容易出错。

4.3 多线程下载TS分片并保证顺序

TS分片数量通常在几百到上千个，单线程逐个下载太慢，必须用多线程。我用的是Python自带的concurrent.futures.ThreadPoolExecutor，不要自己手动开几十个threading.Thread去管理，交接和异常处理太麻烦了。

from concurrent.futures import ThreadPoolExecutor, as_completed import os def download_and_decrypt_all(segments, cipher, output_dir, max_workers=8): os.makedirs(output_dir, exist_ok=True) results = {} def worker(idx, segment): temp_name = os.path.join(output_dir, f"temp_{idx}.ts") resp = requests.get(segment.uri, headers=headers, timeout=10) encrypted_data = resp.content decrypted_data = cipher.decrypt(encrypted_data) # 去PKCS7填充 pad_len = decrypted_data[-1] if decrypted_data else 0 if pad_len and 1 <= pad_len <= 16: decrypted_data = decrypted_data[:-pad_len] with open(temp_name, "wb") as f: f.write(decrypted_data) return idx with ThreadPoolExecutor(max_workers=max_workers) as executor: futures = {executor.submit(worker, idx, seg): idx for idx, seg in enumerate(segments)} for future in as_completed(futures): idx = futures[future] results[idx] = future.result() print("下载完成的分片数量:", len(results))

这段代码有几个关键点需要注意：

线程并发数max_workers我实测下来8~16个比较合适，太小速度提不上来，太大容易被腾讯的CDN限流甚至封IP。如果下载过程中经常出现超时，可以把timeout加大到15~20秒。

每个分片下载后以temp_序号.ts命名保存，序号是从0开始的整数，这样后面合并时可以直接按文件名排序，不用重新读索引。临时文件的命名别用原始TS文件名，因为腾讯视频的TS文件名带了长串token参数，直接用会导致文件名过长。

解密时cipher.decrypt会一次性处理整个分片，如果有个别分片在传输过程中损坏了（数据长度不是16的倍数），会抛出ValueError异常。我在代码里通过设置超时和重试机制来处理这种情况：下载失败的分片自动重试最多3次，失败次数太多就标记为下载失败，最后统一检查缺失分片。

4.4 用FFmpeg合并为MP4

所有分片下载解密完成后，合并就简单了。最简单的办法是直接用FFmpeg拼接TS文件再转封装MP4：

ffmpeg -f concat -safe 0 -i filelist.txt -c copy output.mp4

但这里有个前提：filelist.txt里的文件路径必须是解密后的TS文件，且所有TS文件的编码参数一致。如果分片来源的码率一致（同一个清晰度下的分片），-c copy直接复制编码流不需要重新编码，速度极快，基本是秒合并。如果出现音画不同步、画面花屏等问题，就需要把-c copy去掉，让FFmpeg重新转码，这样处理起来更稳但速度慢。

用Python调用FFmpeg合并的代码：

import subprocess def merge_ts_to_mp4(output_dir, output_file, count): filelist = os.path.join(output_dir, "filelist.txt") with open(filelist, "w") as f: for i in range(count): f.write(f"file 'temp_{i}.ts'\n") cmd = [ "ffmpeg", "-y", "-f", "concat", "-safe", "0", "-i", filelist, "-c", "copy", output_file ] result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: print("FFmpeg合并失败:", result.stderr[-500:]) else: print("合并成功:", output_file)

这里要小心Windows路径分隔符的问题。在Windows上，filelist.txt里的路径如果用了反斜杠\，FFmpeg的concat协议可能解析失败。解决方法是生成filelist时把反斜杠替换成正斜杠：

f.write(f"file 'temp_{i}.ts'\n".replace("\\", "/"))

合并完成后，把下载的临时TS分片文件清理掉，只保留最终MP4和M3U8索引文件，方便后续排查问题。

5. 常见问题与排查技巧实录

5.1 请求返回403 Forbidden怎么办

这是最常见的错误。403意味着请求被CDN判断为非法请求拒绝服务，原因基本就是请求头不完整。腾讯视频的防盗链机制会校验Referer和User-Agent，缺少任何一个都会返回403。

我自己的排查思路是：先在浏览器里复制M3U8链接到新标签页打开，能正常显示内容说明链接有效，然后在代码里添加和浏览器一致的请求头再测试。如果还403，就把浏览器的完整请求头全量复制过来（除了一些sec-开头的安全相关头可以省略），逐个尝试。还有一个容易被忽略的点：有些CDN节点对无Cookie请求不友好，尤其是在登录状态下抓取的链接，必须带上Cookie一起请求。

注意：腾讯视频的M3U8链接里通常带token参数，这个token有时效性，短则几分钟长则几小时。保存下来的链接过一段时间再用会失效，需要重新抓包。我看到很多人下载到一半链接过期，其实就是token的问题，不是代码写错了。

5.2 下载中途key失效或链接过期

M3U8里的Key地址和TS分片地址都可能带上token参数，这些token的时效性不同。如果下载到一半，某个分片请求返回401或403，大概率是分片链接过期了。这个情况的应对方案是：写程序时加一个完整的重新获取流程，检测到连续多个分片下载失败后，自动重新请求M3U8索引，找出新的分片地址和Key，从失败的位置继续下载。

如果已经下载好的分片对应的Key和新区间的Key不同（腾讯视频有时按时间段切分Key），那已下载的分片不受影响，新下载的分片用新Key解密就行。实际开发中我遇到过M3U8里包含多个EXT-X-KEY标签的情况，这种情况处理起来要更仔细，每个分片解密前先确认它对应的Key是哪一个。

5.3 TS分片损坏或下载不完整

TS分片下载不完整会导致解密失败，或者解密后合并的视频画面出现花屏、断裂。常见的表现是：解密时报ValueError: Data must be padded to 16 byte boundary in CBC mode，或者FFmpeg合并时报Invalid data found when processing input。

排查步骤是这样的：先看下载的TS分片文件大小，如果和其他分片差了几个数量级（比如别的分片300KB，这个是3KB），那基本是下载失败了。再看一下分片内容，正常情况下应该是被加密的二进制数据，如果内容是{"code":-1}之类的JSON字符串，说明服务器返回了异常，这个是需要重试的信号。

我在代码里会在下载后立即校验一下响应内容的长度，和M3U8索引的预期时长做对比（虽然M3U8里没有明确的分片大小，但可以根据码率估算，误差太大就重试）。

5.4 合并后音画不同步

音画不同步的根源是TS分片本身有问题。通常是单个TS分片的时长不对，或者有个别分片在download过程中被截断。如果所有分片都是完整下载的，音画同步问题很少出现。

一个坑是解密时去PKCS7填充的逻辑。PKCS7填充是在每个分片末尾追加1~16字节的填充数据，最后一个字节的值表示填充了多少字节。如果TS分片本身没有按16字节对齐（个别特殊分片），直接取最后一个字节的值作为padding长度可能会出错。我实际处理时会先判断解密后的数据长度是否满足某个阈值（比如小于1024字节就怀疑本身是个异常分片），再决定是否裁剪。

如果确实在某个分片位置后音画不同步，一个补救方案是：重新下载那一段的几个分片，只替换有问题的部分，然后用FFmpeg的-ss和-t参数精确切割重新转码，太复杂了就直接全量重新下载。

5.5 Network面板里找不到m3u8怎么办

这种情况在腾讯视频上比较常见，因为新版播放器可能用了WebAssembly或其他方式混淆请求。我遇到过的情况是：Network面板里能看到fetch请求，但过滤器输入m3u8就是过滤不出来。

解决思路有几种。第一，清空 Network 面板后重新播放，把日志级别从All切换到Fetch/XHR，因为M3U8请求很可能不是通过常规的<video>标签加载的，而是通过JavaScript的fetch或XMLHttpRequest拉取。

第二，在Console里输入performance.getEntriesByType('resource')，把所有资源请求列出来，然后在里面搜索m3u8，这样即使Network面板没显示，也能拿到访问过的M3U8的URL，因为浏览器性能API会记录所有已加载的资源。

第三，如果上面两种都不行，就用proxy工具做中间人抓包，但我个人不太推荐，因为配置HTTPS证书比较麻烦，对新手不友好。先尝试前两种方案，成功率已经很高了。

6. 避坑总结与效率优化补充

6.1 腾讯视频下载的专属注意事项

腾讯视频和其他使用HLS的网站有些细节上的差异，这里单独列一下我实际踩过的坑：

• 播放器可能先请求一个template.m3u8或者index.m3u8，这个文件的响应里会带上当前客户端IP对应的CDN节点列表，真正的M3U8地址是在这些节点的域名下面的。所以你在Network里看到的第一个M3U8地址和第二个M3U8地址的域名可能不一样，这是正常的。
• 部分清晰度（特别是1080P以上）需要vip权限才能获取，未登录或非vip状态拿到的子索引列表里不包含高清码率的地址。想下载高清内容前先确认账号状态。
• 腾讯视频的M3U8链接里的token参数对IP有绑定，换网络后原链接可能失效。这也解释了为什么有时候在公司抓的链接回到家就用不了。
• 请求头里的Referer值不一定都是https://v.qq.com/，某些页面下是具体的播放页URL，建议直接用当前播放页面的完整地址作为Referer。

6.2 提升下载速度的进阶方案

多线程下载能提升速度，但核心瓶颈通常是单分片的网络延迟，而不是带宽。我用ThreadPoolExecutor的并发数是16，实测能把下载速度拉满到带宽上限。但要注意，并发太高中途失败的概率也会上升，被CDN限流后所有请求可能都返回503。

进阶方案是用异步IO替换多线程，用aiohttp库实现的下载效率更高，资源消耗更低。不过代码复杂度会高一些，对于这个项目规模来说，多线程完全够用。这套代码的关键是稳定性，不要在追求速度的路上牺牲了完整度。

还有一个优化点是：解密操作在CPU层面，如果下载速度远大于解密速度，可以先用多线程只下载不解密，然后在一个线程里做顺序解密，这样能避免多线程同时解密导致CPU的GIL争抢。但我实践下来，TS分片单个体积不大，解密耗时在毫秒级，影响不明显。

6.3 如何让代码更健壮：断点续传与日志记录

爬到一半程序崩了是最难受的。我给这套代码加了一个非常简单的断点续传机制：已经下载并解密成功的分片会生成一个.done标记文件，下次运行时先扫描已存在的分片文件，跳过那些已经完成的。这样做的好处是，即使中途因为网络波动挂了，重新运行一遍代码，几百个分片里只需要重下没下完的那几个。

日志方面建议用logging模块，把每次请求的分片序号、状态、耗时、异常信息都记录下来。这样排查问题时不用靠猜，直接看日志就能定位到具体是哪个分片出了问题。

import logging logging.basicConfig( level=logging.INFO, format='%(asctime)s %(levelname)s %(message)s', handlers=[ logging.FileHandler('download.log', encoding='utf-8'), logging.StreamHandler() ] )

我自己做这套工程时，日志是最值的部分。腾讯视频的反爬策略一直在变，有时候今天能跑的代码明天就莫名挂掉。有了完整日志，我能在5分钟内定位是token过期、请求头缺失还是CDN限流，而不是从头到尾猜。

6.4 关于合规使用的再次强调

技术本身没有原罪，但这套下载流程会接触有版权保护的内容，使用边界要拎清楚。我个人的实操准则是：只下载公开的、无版权争议的技术演示内容，或者平台允许离线缓存的内容，以及自己有明确授权的视频素材。下载他人的完整影视作品用于传播，在多数情况下超出了技术学习的范畴。

如果你确实需要用Python处理视频内容，可以把这个项目的核心能力迁移到完全合法的方向，比如下载自己上传的视频、处理自己的课程录像、或者作为流媒体协议学习项目。技术学习的价值在于理解加密流媒体的运作机制和Python网络编程的实战技巧，而不是简单的“下载工具”。

我在实际过程中最大的体会是：腾讯视频这一套M3U8+TS+AES-128加密方案本身就很有代表性，把它完整吃透之后，去理解其他HLS加密流的网站会非常轻松。加密解密本身不是目的，真正有价值的是你在排查403、处理坏分片、优化并发下载速度的过程中积累的工程能力。

最后再分享一个小技巧：如果只是偶尔下载一两次，用我这篇的流程手动操作完全够用。如果你打算做成一劳永逸的批量工具，建议把M3U8链接获取这段也自动化，比如用Playwright或无头浏览器直接播放视频然后从响应中捕获M3U8地址，这样即使腾讯改了前端代码，代码依然能自动适配。不过那是另一个级别的工程复杂度了，建议先把本篇内容跑通，再往这个方向深挖。