简介：短视频解析源码是一套面向内容分析者、数据研究者和第三方应用开发者的轻量级工具，通过调用短视频平台公开接口，自动提取视频链接、封面、标题、播放量、评论等数据，省去手动抓取与整理环节。该源码已经过实测，在3月10日确认可正常使用，稳定性有保障；用户只需粘贴视频链接即可获得结构化结果，适合快速搭建数据采集、内容监控或下载辅助脚本。

资源包共含14个文件，压缩后仅203KB，其中5个CSS与4个JS负责前端展示与交互，2个PHP文件承担请求与解析核心逻辑，另有HTML入口、.htaccess及.ini配置文件，整体轻量且结构清晰。通过index.php与api.php的明确分工，能直观理解请求模块、解析模块和数据输出流程，方便二次开发或学习接口调用机制。

目前已有199人学习下载。源码覆盖请求、解析、存储、界面、错误处理等关键组件，既可直接部署用于短视频平台数据分析与市场趋势观察，也可作为研究平台API的参考实现。使用时请注意遵守平台协议和版权规范，确保合法合规获取数据。

1. 短视频解析源码：为什么「上传即可用」才是这类项目的真门槛

拿到「短视频解析源码」这类标题，很多人的第一反应是抓取某个平台的视频链接、扒出无水印地址。但真正常见、也更有落地价值的形态，是在后端接收用户上传的短视频，把它「解析」成明确的元数据与可复用素材——时长、分辨率、编码格式、封面帧、转码后的标准 MP4。标题里「上传即可使用」这六个字，才是这类源码真正难做的地方：它要求代码开箱即跑、依赖尽量少、对上传的视频格式容错高、解析完不把临时文件堆爆磁盘。老手做这套东西的周期基本在两天以内，新手拿现成源码却常常卡在一连串与环境、依赖、边界格式相关的坑里，于是本文就把这套方案拆开讲透，让你既能看懂原理，也能直接照着一行行复现。

2. 选型与最小服务：用 FastAPI + FFmpeg 搭出能接收上传的底座

2.1 为什么是 FastAPI + FFmpeg，而不是 Django + OpenCV

「上传即可使用」意味着服务要轻、启动要快、接口要直观。常见做法是用 Python 的 FastAPI 做 HTTP 层，用 FFmpeg/FFprobe 做解析与转码核心。FastAPI 自带 OpenAPI 文档，上传接口写起来只有几行，不像 Django 那样需要配一堆全局设置；而 FFprobe 本身就是短视频解析的事实标准，它能从 MP4、MOV、AVI、FLV、WebM 里稳定读出时长、码率、分辨率、编码器、旋转角度，这些信息靠 OpenCV 去猜往往不准，尤其是带旋转元数据的手机视频，OpenCV 读出来的宽高经常是反的。

选 FFmpeg 而不是 OpenCV 的另一个理由：解析之外你还大概率要转码。短视频上传后如果要做统一预览、封面截取、或兼容老播放器，最终都绕不开 FFmpeg 的转码管线。FFmpeg 是独立进程，内存泄漏的风险天然隔离，超时可以直接 kill，这对「上传即用」的服务非常重要——你不想因为一个畸形视频把整个 Python 进程拖死。OpenCV 在这套流程里唯一的优势是能直接抽帧到 numpy 数组，方便后续做图像算法，但那属于进阶场景，不在最小可用版本里。

依赖方面需要注意：FastAPI 的 upload file 依赖 python-multipart 库，这是一个极其常见的翻车点——fastapi 装好了，接口也写了，一传文件就报 422，查半天发现是少了python-multipart。这个包在 requirements 里必须显式写上。

2.2 最小服务代码：接收文件、落盘、返回解析结果

以下是这套源码最核心的骨架，接收一个文件上传，把文件存到临时目录，然后调用 FFprobe 提取信息，并回传 JSON。代码刻意保持精简，方便你直接跑通。

import asyncio import json import os import subprocess import uuid from pathlib import Path from fastapi import FastAPI, File, UploadFile, HTTPException app = FastAPI(title="短视频解析服务") UPLOAD_DIR = Path("uploads") UPLOAD_DIR.mkdir(exist_ok=True) FFPROBE = "ffprobe" # 如果 ffprobe 不在 PATH 里，这里写绝对路径 async def run_ffprobe(file_path: Path) -> dict: """调用 ffprobe 提取视频元数据，返回解析后的 JSON。""" cmd = [ FFPROBE, "-v", "error", # 只输出错误，避免日志刷屏 "-print_format", "json", # 以 JSON 形式输出 "-show_format", # 输出容器层信息（时长、大小、比特率） "-show_streams", # 输出每个流的信息（视频流、音频流） str(file_path), ] proc = await asyncio.create_subprocess_exec( *cmd, stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.PIPE, ) stdout, stderr = await proc.communicate() if proc.returncode != 0: raise HTTPException(status_code=422, detail=f"无法解析该文件: {stderr.decode()}") return json.loads(stdout.decode()) def extract_video_meta(probe_data: dict) -> dict: """从 ffprobe 输出里抽取出业务需要的字段，避免把原生 JSON 全量抛给前端。""" fmt = probe_data.get("format", {}) video_stream = next( (s for s in probe_data.get("streams", []) if s.get("codec_type") == "video"), None, ) if video_stream is None: raise HTTPException(status_code=422, detail="文件中没有视频流") # 注意：很多手机视频带旋转元数据，宽高要按旋转角度交换 width = int(video_stream.get("width", 0)) height = int(video_stream.get("height", 0)) rotation = int(video_stream.get("tags", {}).get("rotate", 0)) if rotation in (90, 270): width, height = height, width return { "duration": float(fmt.get("duration", 0)), "size_bytes": int(fmt.get("size", 0)), "bit_rate": int(fmt.get("bit_rate", 0)), "width": width, "height": height, "codec": video_stream.get("codec_name"), "profile": video_stream.get("profile"), "fps": video_stream.get("avg_frame_rate"), # 形如 "30/1" 的分数 } @app.post("/parse") async def parse_video(file: UploadFile = File(...)): # 用 uuid 重命名文件，避免原始文件名带来的路径穿越和中文名乱码问题 ext = Path(file.filename or "").suffix.lower() if ext not in {".mp4", ".mov", ".avi", ".flv", ".webm", ".mkv", ".m4v"}: raise HTTPException(status_code=415, detail=f"不支持的文件类型: {ext}") unique_name = f"{uuid.uuid4().hex}{ext}" save_path = UPLOAD_DIR / unique_name # 分块写盘，避免大文件一次性读入内存 with open(save_path, "wb") as buffer: while chunk := await file.read(1024 * 1024): buffer.write(chunk) try: probe_data = await run_ffprobe(save_path) meta = extract_video_meta(probe_data) meta["saved_path"] = str(save_path) return meta finally: # 解析完成立即删掉临时文件，防止磁盘被填满 save_path.unlink(missing_ok=True)

这段代码里值得展开说明的参数有三个。第一个是-v error，它决定了 ffprobe 只输出错误信息，如果去掉，正常的解析日志会混入 stdout，导致 JSON 解析失败，这是新手最容易碰到的坑。第二个是-show_format与-show_streams的组合：format给的是容器层的时长和总比特率，streams给的是每个视频流/音频流的编码详情，两者缺一不可——只取format拿不到具体的编码器名，只取streams拿不到总文件大小。第三个是avg_frame_rate，ffprobe 返回的是形如"30/1"、"30000/1001"的分数形式，直接传给前端不友好，实际落地时我会用fractions.Fraction转成浮点，或者干脆保留原样由前端处理。

2.3 让上传者「肉眼可见」解析完成

光返回一个 JSON 不够，很多场景需要让调用方确认解析确实成功了。常见的做法是在解析响应里附带一个「可视化摘要」，比如给一个可以直接预览的封面图地址，或者一个临时播放直链。这个能力可以做成可选的第二个接口，因为封面抽取需要走 FFmpeg，比纯 ffprobe 更重。

import subprocess def extract_cover(file_path: Path, output_path: Path, timestamp: float = 1.0) -> bool: """用 ffmpeg 在指定时间点抽一帧作为封面。""" cmd = [ "ffmpeg", "-y", # 覆盖输出文件，不加的话会被交互式询问卡死 "-ss", str(timestamp), "-i", str(file_path), "-frames:v", "1", "-q:v", "2", # 2 到 5 之间，质量足够且文件不大 str(output_path), ] proc = subprocess.run(cmd, capture_output=True) return proc.returncode == 0 and output_path.exists()

这里-ss的位置很讲究：把它放在-i前面是快速定位，ffmpeg 会先跳转再解码，速度极快；放在-i后面是慢速定位，需要从文件头解码到目标帧，耗时随视频时长线性增长。短视频动辄几十秒，慢速定位会让接口延迟变得不可接受。另外-q:v 2这个参数只在输出 JPEG 时有效，如果改成输出 PNG，需要换成-compression_level。如果你想让这张封面能被浏览器直接访问，常见做法是把生成的封面放到静态目录下，或者上传到对象存储拿直链，这取决于你源码的部署形态。

3. 解析与转码链路：定位「上传即用」的完整状态机

3.1 解析流程的输入边界：哪些视频能收、哪些不能收

「上传即可使用」不代表来者不拒。我做这类源码时，会在入口处做三层过滤。第一层是后缀名白名单，因为这是最容易实现的；但后缀名是纯表象，一个伪装成.mp4的文件用编辑器看一眼就知道不是 MP4。第二层是魔数校验，在 Python 里读文件头几个字节，MP4 的 ftyp box 和 FLV 的FLV字样几乎可以当场判断文件类型。第三层才是 ffprobe 的完整解析，它发现不了任何问题时才算真正入库。

现实中后两层更可靠的是 ffprobe 返回的format.format_name，例如mov,mp4,m4a,3gp,3g2,mj2或flv。可接受的格式名要做一个映射表：有的浏览器上传的 WebM 视频，容器格式在 ffprobe 里的名字可能直接是matroska,webm，拿webm去精确匹配会误杀。我一般把「能解出视频流」作为最低要求，格式名校验只用来决定转码参数，不决定是否接收。

除此之外还有一个隐藏边界：时长限制。短视频解析服务如果允许用户传 2 小时的视频，FFmpeg 转码时长会拖垮整个任务的资源池。我通常在接口层用 60 秒或 120 秒作为上限，超过直接 413 拒绝。这个值不是拍脑袋定的，它应该和你部署机器的 CPU 核数、磁盘 IO 匹配——单核机器处理 120 秒 1080p 的转码可能要跑十几秒，如果你希望接口在 3 秒内响应，就得把上传时长上限压到 30 秒以内。

3.2 统一转码：把「五花八门的视频」变成「一种标准成品」

短视频上传后的使用场景千差万别，但下游统一希望拿到 H.264 + AAC 的 MP4：H.264 是浏览器和移动端兼容性最广的编码，AAC 是音频事实标准。FFmpeg 转这条链路的命令，几乎是所有短视频解析源码里的主角。

FFMPEG = "ffmpeg" VIDEO_OPTS = [ "-c:v", "libx264", # 视频编码 "-preset", "veryfast", # 编码速度与体积的折中 "-crf", "23", # 质量参数：18~28，数值越小质量越高 "-profile:v", "high", # H.264 档次，兼容绝大多数播放器 "-pix_fmt", "yuv420p", # 像素格式，不转的话部分播放器黑屏 "-r", "30", # 统一帧率为 30 ] AUDIO_OPTS = [ "-c:a", "aac", "-b:a", "128k", # 音频码率，短视频场景足够 "-ac", "2", # 双声道，避免 5.1 音轨在网页端异常 ] def transcode_to_mp4(src: Path, dst: Path) -> None: cmd = [ FFMPEG, "-y", "-i", str(src), *VIDEO_OPTS, *AUDIO_OPTS, "-movflags", "+faststart", # 让 MP4 的元数据前置，在线播放秒开 str(dst), ] proc = subprocess.run(cmd, capture_output=True, timeout=300) if proc.returncode != 0: raise RuntimeError(f"转码失败: {proc.stderr.decode()[-500:]}")

-preset veryfast和-crf 23是这套参数里最重要的两个旋钮。preset 控制编码速度与压缩率的权衡，veryfast比medium快 30% 以上，体积会略大，但对「上传即用」的场景，速度优先于体积。CRF 是恒定质量模式，23 是 libx264 的默认值，肉眼几乎看不出与源文件的差异；如果你的下游是给算法模型喂数据，可以降到 18 保留更多纹理，但文件体积会明显上涨。-movflags +faststart这条容易被忽略，没有它 MP4 的 moov 元数据会被写在文件末尾，浏览器必须等整个文件下载完才能开始播放，这对短视频预览是致命的——用户看到的一直是播放器转圈。

3.3 临时文件的清理策略：不清理，三天磁盘就满

短视频服务最容易被低估的运维成本是临时文件。上传落盘一个文件、转码再落盘一个文件、封面抽取又要一个文件，如果每个请求不清理，叠加一天的流量就能把服务器磁盘打满。我的清理策略分三层。

第一层是 each-request 清理：就像第 2 章的代码那样，解析或转码完成后，在finally块里删除源文件。第二层是定时兜底：进程启动一个后台任务，每隔 10 分钟扫描上传目录，删除超过 30 分钟的文件，这个策略专门对付接口报错或进程被杀时残留的孤儿文件。第三层是磁盘水位保护：服务启动前检查磁盘剩余空间，低于 1GB 时拒绝新的上传请求并返回 503，同时触发一次全量清理。

import time from threading import Thread def cleanup_loop(upload_dir: Path, max_age_sec: int = 1800, interval: int = 600): """定期清理上传目录中超过 max_age_sec 秒的临时文件。""" def _run(): while True: now = time.time() for f in upload_dir.iterdir(): if f.is_file() and now - f.stat().st_mtime > max_age_sec: f.unlink(missing_ok=True) time.sleep(interval) Thread(target=_run, daemon=True).start()

这里的max_age_sec要大于接口最长允许耗时，否则会出现接口还在转码、文件被后台任务噶掉的灵异现象。我一般会把「最慢请求耗时」估算为转码超时上限的两倍，再取一个安全系数，1800 秒对短视频场景是合理的。如果你部署在容器里，还要注意 uploads 目录要挂载到持久化卷上，否则容器重启后临时文件不会清掉，反而会因为挂载的块存储空间被占满而触发故障。

4. 部署与接口参数：让源码在真实环境里稳定跑起来

4.1 环境准备：FFmpeg 版本与 Python 依赖的坑

部署这套源码，最核心的环境依赖就两样：FFmpeg 可执行文件和 Python 3.9+。FFmpeg 版本建议直接用官方静态构建版或系统包管理器里的最新稳定版，老版本（4.x 早期）对某些新封装格式支持不全。你可以在终端跑ffmpeg -version和ffprobe -version确认两个可执行文件都在 PATH 里，如果不在，代码里可以用绝对路径替代"ffmpeg"字符串。

Python 依赖按最小集来：fastapi、uvicorn[standard]、python-multipart。不要随意加opencv-python之类的重依赖，那是封面做图像处理时才需要的东西，提前加会让部署体积大几十兆，还容易因为 libGL 缺失在容器里启动失败。

# 虚拟环境 + 依赖安装 + 启动，三步走 python3 -m venv .venv source .venv/bin/activate pip install fastapi "uvicorn[standard]" python-multipart # 后台启动服务，0.0.0.0 表示对外可访问，端口按需修改 nohup uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4 > app.log 2>&1 &

--workers 4要结合机器 CPU 核数来设，一般取核数的 2 倍以内。每个 worker 是独立进程，各自持有自己的临时文件状态，所以上传目录是共享的，清理任务会重复执行——这没问题，只是要注意用幂等的unlink(missing_ok=True)。如果你是 Docker 部署，进程模型要反过来：容器里只跑一个 uvicorn worker，多容器由 Kubernetes 或 Compose 的 scale 来控制，别在容器里起多个 worker。

4.2 接口参数与响应字段说明

接口设计上，POST /parse负责纯解析，POST /transcode负责转码成标准 MP4，POST /cover负责抽帧。三个接口的参数如表所示。

响应统一成{ "code": 0, "data": {...}, "message": "ok" }的结构。data里对 parse 接口至少包含：duration（秒）、width（像素）、height（像素）、format_name（容器格式）、video_codec、fps、size（字节）、cover_url（如果生成）。转码接口额外返回output_url和output_size。这套结构让前端不用关心 ffprobe 的原生字段命名差异——例如有的视频duration在 stream 里比 format 里更精确，你后端已经统一取过一遍了，前端拿到的一定是能直接用的值。

4.3 验证部署：用 curl 模拟一次完整上传

服务启动后，本地验证是最重要的一步。我用 curl 模拟一个真实的浏览器上传：

# 用系统自带的方式生成一个测试视频：先用 ffmpeg 生成 5 秒测试源 ffmpeg -f lavfi -i testsrc=duration=5:size=640x480:rate=30 -f lavfi -i sine=frequency=440:duration=5 -c:v libx264 -c:a aac test.mp4 # 上传解析 curl -s -F "file=@test.mp4" http://127.0.0.1:8000/parse | python3 -m json.tool # 上传转码 curl -s -F "file=@test.mp4" http://127.0.0.1:8000/transcode | python3 -m json.tool

curl 的-F "file=@test.mp4"表示以 multipart/form-data 方式上传文件，@后面跟本地路径。如果返回 422，优先检查python-multipart是否安装；如果返回 500，去 app.log 里看 Python 报错栈，大半是 FFprobe 路径不对或权限问题。uvicorn的日志默认打在终端，nohup 启动时重定向到了 app.log，排查时tail -f app.log实时观察。

5. 避坑排查：短视频解析最容易翻车的五个灰犀牛

5.1 上传报 422：multipart 库缺失「现场」

现象：接口文档里能看到/parse，curl 上传却立刻返回 422 Unprocessable Entity，服务日志里没有业务代码的报错。

原因：FastAPI 处理文件上传依赖python-multipart解析 multipart 表单，这个库不在依赖里时 FastAPI 直接拒绝请求，连业务函数都不进。

解决：pip install python-multipart然后重启服务。这个坑几乎每个初装 FastAPI 的人都会踩一次，所以 requirements.txt 里必须显式含它，不要指望把 fastapi 装上就万事大吉。

5.2 ffprobe 报错「Invalid data」：文件名里有中文或特殊符号

现象：同一个视频，重命名成a.mp4上传成功，用原始名旅行日记 (高清).mp4上传就解析失败，报错信息里带 invalid data 或者 file not found。

原因：某些 FFmpeg 版本对非 ASCII 路径处理有 bug，更隐蔽的情况是文件系统编码不一致，subprocess 调用时把中文路径传丢了。

解决：用 uuid 重命名后落盘，这个方案同时解决了路径穿越、中文乱码和超长文件名三个问题。永远不要让用户原始文件名直接出现在服务器磁盘路径里。

5.3 转码后视频在浏览器里黑屏但有声音

现象：转码完成的 MP4 下载到本地播放正常，网页端播放器黑屏，或者 iOS 相册无法预览。

原因：视频流像素格式不是yuv420p。很多剪辑软件导出的视频是yuv444p或yuv422p，浏览器和 iOS 对这两种格式的硬解支持极差。

解决：转码参数里显式追加-pix_fmt yuv420p。这条可以和-profile:v high配在一起用，兼容安卓、iOS、Windows 全平台播放器。这是我排障史上遇到频率最高的转码问题，没有之一。

5.4 FFmpeg 转码卡死：交互式询问吃掉了进程

现象：接口偶尔超时，再次请求又正常；服务端日志里转码命令迟迟不见完成。检查进程发现 ffmpeg 还在跑，但 CPU 占用几乎为零。

原因：ffmpeg 在某些情况下（输出文件已存在、协议异常等）会提示「File 'xxx' already exists. Overwrite?」，等待 stdin 输入。subprocess 没接管 stdin，进程就永久挂起。

解决：命令里显式加-y参数，同时在 Python 侧设置subprocess.run(..., timeout=300)。-y让它永远覆盖，timeout兜底让它不可能无限挂起。这里 300 秒是给大视频的余量，短视频场景可收紧到 60 秒。

5.5 磁盘被占满：临时文件没人收尸

现象：服务跑了几天后上传请求开始 503，SSH 上去一查磁盘 100%。手动删掉 upload 目录后恢复，过几天又满。

原因：异常请求（比如客户端断连、进程崩溃）留下的临时文件没有走正常清理路径。单靠接口finally清理是防不住进程被杀这种极端情况的。

解决：加定时清理线程，删除超过 30 分钟的文件；再加部署侧监控，磁盘使用率超 85% 告警。我一开始只做了第一层，结果线上跑了一周就被临时文件教做人，从那以后定时兜底就成了保留项目。

6. 进阶技巧：让解析结果真正落到业务上

到这一步，你已经有一套能解析、能转码、不爆磁盘的服务了。最后一公里，是让解析出来的数据不只在体检报告里躺着，而是真正驱动业务。这里有三个我觉得值得投入的方向。

第一个方向是把parse结果接到下游调度。比如你做一个短视频审核系统，解析出的width、height、duration可以提前判定视频是否需要转码、是否需要抽更多帧给模型做内容审核。我在实际项目里会把「需要转码」和「仅解析即可」分成两条队列，时长小于 30 秒且编码已是 H.264 的不转码只解析，省掉大量 CPU。

第二个方向是抽帧点位可以做得更智能。现在抽封面是固定 1 秒，短视频如果是黑场开场，封面图就是全黑的，观感很差。我一般会在服务端用 scene detection：先按 0.5 秒间隔抽出 10 帧，算相邻帧的直方图差异，选差异最大的那一帧当封面。这个方案成本高一些，但对内容型产品收益非常明显——封面图基本决定了用户点不点进来。

第三个方向是回源地址的过期策略。如果转码产物放在本地磁盘，直链 URL 要带签名或一次性 token；如果放在对象存储，上传逻辑要走分片或预签名 URL。很多源码项目只做到了把产物落在服务器本地、返回绝对路径，这在开发环境没问题，部署到公网就暴露问题了——路径直接暴露意味着任何人都能遍历你的文件。成熟的做法是output_url里带一个短暂的时效签名，10 分钟后失效，需要时重新向服务换取新链接。这套逻辑不复杂，但能避免你的存储被白嫖成公共网盘。

回顾我自己的经验教训：最早的版本里我只做了解析不做转码，结果前端换了一个播放器内核就暴露了编码兼容问题，不得不回头补转码链路。现在每套新服务上线前，我会强制自己准备一份 H.264 视频、一份 H.265 视频、一份带旋转元数据的手机竖屏视频、一份坏文件，先把四类样本全部跑通再交付。这套源码里的大部分参数也来自这份测试清单，希望你照着搭的时候，也顺手把这四类样本准备好——你会省掉很多临上线才发现翻车的时间。希望帮到你。

本文还有配套的精品资源，点击获取