OpenCV视频写出指南：VideoWriter_fourcc与VideoWriter参数详解及排坑实践

很多第一次用 OpenCV 做视频相关项目的朋友基本都会在cv2.VideoWriter_fourcc()和cv2.VideoWriter()这两个函数上卡一阵子。你问群里老手得到的回答往往是“照着抄就行”可一旦你换了摄像头分辨率、换了系统、或者换了个视频格式照抄的代码突然就不好使了生成的视频要么打不开要么是 0 字节要么报一堆看不懂的错。这篇文章我就把这两个函数彻底讲透包括它们各自的参数含义、组合使用的完整套路以及我在实际项目里踩过的坑和排查方法。准备把视频写出从“能跑”做到“跑得稳”这篇内容可以直接收藏。1. 视频写出这个需求远没有你想的那么简单很多人以为视频写出就是“拼图片”一帧一帧往文件里丢就行。实际上视频文件是一个高度封装的容器里面有编码格式、压缩算法、帧率、分辨率、色彩空间、音频轨道等等一堆信息。cv2.VideoWriter负责的正是“按指定规则把帧序列包装成视频文件”这个过程而cv2.VideoWriter_fourcc()则决定了包装时采用哪种编码规则。如果还是觉得抽象你可以把视频文件想象成一个快递包裹。cv2.VideoWriter()是快递公司的打包台负责把东西装进箱子cv2.VideoWriter_fourcc()则是你贴在箱子上的运单标签它写明了这箱货要用哪条运输线路、什么包装方式。没有运单标签打包台根本不知道该按什么标准处理你的帧数据。有一个非常常见的误解很多人以为 FourCC 只是“视频后缀名”的意思比如把文件名改成.avi或.mp4就能决定格式。这是错的。文件后缀只是外壳真正决定视频能不能被播放器识别、文件体积多大、清晰度多高的是编码器本身。比如你写了一个.mp4后缀的文件但 FourCC 指定的是老旧的 MJPG 编码生成的视频在某些播放器里依然可能无法播放或者体积大得离谱。在 OpenCV 的 Python 接口里这两个函数的用法长这样fourcc cv2.VideoWriter_fourcc(*MJPG) writer cv2.VideoWriter(output.avi, fourcc, 30.0, (640, 480))*MJPG这个写法会把字符串拆成四个字符传入等价于cv2.VideoWriter_fourcc(M, J, P, G)。很多教程直接让你这么写却没人解释为什么这里有个星号。理解了这一点后面遇到自定义编码格式时你就不会懵。我先给一个最常用的组合示例后面再逐步拆解细节import cv2 cap cv2.VideoCapture(0) # 注意这里的分辨率必须和后续写入的帧尺寸完全一致 frame_width int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)) frame_height int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)) fourcc cv2.VideoWriter_fourcc(*XVID) writer cv2.VideoWriter(output.avi, fourcc, 20.0, (frame_width, frame_height)) while cap.isOpened(): ret, frame cap.read() if not ret: break writer.write(frame) cv2.imshow(Preview, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() writer.release() cv2.destroyAllWindows()这个代码是最经典的“摄像头录制”骨架。接下来我会把每一行背后的原理和坑都补齐。2. cv2.VideoWriter_fourcc() 拆解四个字符背后的编码逻辑FourCC 的全称是 Four Character Code四个字符代码最早是苹果公司在 QuickTime 里定义的一套格式标识方案。它用一个 32 位整数来表示编码格式32 位正好拆成 4 个 8 位每个 8 位对应一个 ASCII 字符所以看起来就是四个字符的组合。比如MJPG转成整数的过程大致是M - 0x4D J - 0x4A P - 0x50 G - 0x47组合起来就是0x4D4A5047正好是一个 32 位整数。cv2.VideoWriter_fourcc()这个函数就是帮你完成这个字符到整数的转换省得你手算十六进制。2.1 常见 FourCC 编码格式横向对比我在不同项目里试过下面这些编码按使用频率和场景整理如下FourCC 字符容器/文件后缀编码特点适用场景踩坑提醒MJPG.aviMotion JPEG每帧独立压缩兼容性极好Windows 下几乎万能文件体积巨大不适合长时间录制XVID.aviMPEG-4 编码压缩比高最经典的 OpenCV 示例格式新版 OpenCV 在某些系统里需要装解码器mp4v.mp4MPEG-4 Part 2入门级 MP4 输出在部分播放器里画质偏糊avc1.mp4H.264 编码高压缩比画质好流媒体兼容性佳部分 OpenCV 版本不支持需要额外编译VP80.webmVP8 编码Web 场景友好坑多少用H264.mp4H.264 的另一种标识同 avc1行为不稳定DIVX.aviDivX 编码老式播放器兼容新系统上可能找不到编码器注意同一个 FourCC 在不同操作系统、不同 OpenCV 版本上的支持程度差异很大。你在 Windows 上能用的编码器换到 Linux 服务器上未必存在。2.2 为什么字符的大小写不能乱写cv2.VideoWriter_fourcc(*mp4v)和cv2.VideoWriter_fourcc(*MP4V)在部分环境下行为一致但我不建议你赌这个一致性。FourCC 本质上是把字符严格按 ASCII 码转成整数大小写不同最终整数就不同编码器识别时有的做大小写归一化有的不做。我遇到过最典型的例子在 Ubuntu 上使用大写MJPG没问题但有人把代码里的MJPG改成小写后writer.isOpened()返回False视频文件创建失败。排查半天其实就是大小写导致找不到匹配的编码器。2.3 特殊情况的处理获取本机支持的编码器列表你可能想知道“我机器上到底有哪些可用的编码器”。OpenCV 本身没有提供直接枚举编码器的 Python API但你可以用一条曲线方式跑一个循环逐个尝试所有常见 FourCC然后用cv2.VideoWriter.isOpened()检查是否能正常创建。这里是我调试时写的一个小工具函数import cv2 fourcc_list [ MJPG, XVID, DIVX, mp4v, avc1, H264, VP80, VP90, I420 ] def check_fourcc(filename_basetest_output): available [] for code in fourcc_list: filename f{filename_base}_{code}.avi fourcc cv2.VideoWriter_fourcc(*code) writer cv2.VideoWriter(filename, fourcc, 25.0, (640, 480)) if writer.isOpened(): available.append(code) # 写一帧测试数据 import numpy as np frame np.zeros((480, 640, 3), dtypenp.uint8) writer.write(frame) writer.release() if not available or available[-1] ! code: print(f{code}: 不支持) print(可用的编码器:, available) check_fourcc()这个函数会在当前目录生成一堆测试视频跑完看一眼输出列表你就知道自己这个环境里哪些编码器靠谱。顺手检查生成文件的大小也能看出压缩效率同分辨率同帧数下MJPG 生成的文件会比 XVID 大好几倍。3. cv2.VideoWriter() 构造函数逐参数解读cv2.VideoWriter()的完整签名在不同 OpenCV 版本里略有差异但核心参数基本稳定cv2.VideoWriter(filename, fourcc, fps, frameSize, isColorTrue)老版本也支持cv2.VideoWriter(filename, apiPreference, fourcc, fps, frameSize, isColorTrue)这样带apiPreference的形式。这里我以最常用的五参数版本为例逐个说明。3.1 filename不止是路径filename是你想保存的视频文件路径。除了普通路径你还可以传入图像序列模式比如writer cv2.VideoWriter(frame_%03d.png, fourcc, fps, frameSize, isColorFalse)当文件名里带%03d这类格式化占位符时OpenCV 会把你写入的每一帧保存成独立图片文件。这个用法适合做视频抽帧调试但注意此时fourcc参数实际上会被忽略OpenCV 只看图片后缀决定编码方式。另外要注意的是OpenCV 不会自动创建不存在的目录路径指向的文件夹必须提前存在否则文件创建失败但不会抛异常只会在isOpened()里返回False。3.2 fourcc编码器标识这个参数就是上一节cv2.VideoWriter_fourcc()函数的返回值。它是整数类型不能直接传字符串。fourcc cv2.VideoWriter_fourcc(*XVID) writer cv2.VideoWriter(out.avi, fourcc, 25.0, (640, 480))如果你传了字符串OpenCV 虽然可能不报错但内部实际用到的会是一个错误的值生成的视频文件基本是坏的。3.3 fps帧率参数的隐藏影响fps是你期望的输出帧率。通常取 20.0、25.0、30.0 这样的值。很多人忽略的一点是OpenCV 在写视频时并不会均匀地对帧做时间戳控制它只是把这个值写入视频文件的元数据里。也就是说如果你处理每帧花了很长时间实际文件的时间轴按就是这个 fps 计算的。举例你设置 fps30但你的图像处理循环每帧要 0.1 秒即实际 10 帧/秒写 300 帧进去生成的文件播放时长会被系统认为 10 秒但你录制过程实际花了 30 秒。看起来画面是“快进”的。要解决这个问题要么让实际处理速度跟上目标 fps要么把 fps 设成实际能达到的值。3.4 frameSize和输入帧尺寸必须严格一致frameSize是一个(width, height)元组注意顺序是先宽后高。这个参数是视频写出中最大的坑之一因为很多人习惯用frame.shape获取尺寸而frame.shape返回的是(height, width, channels)顺序正好反了。正确的做法height, width frame.shape[:2] writer cv2.VideoWriter(out.avi, fourcc, fps, (width, height))还有一个隐藏约束某些编码器要求 width 和 height 必须是偶数尤其是基于 H.264/MPEG 系编码的。如果你的摄像头分辨率是 1280x720 这种偶数没问题但如果是 1279x720 或 640x481 这种奇数生成的视频可能出现花屏、绿屏或者直接写不进去。处理方式是自行调整 frameSizewidth int(width / 2) * 2 height int(height / 2) * 23.5 isColor容易忽略的色彩空间开关isColor参数默认是True表示输入帧是 BGR 彩色图。如果你设置为FalseOpenCV 会按灰度图处理此时你写入的帧可以是一维的单通道图。又一个大坑在这里当 isColorFalse 时frameSize 的第二个维度会被忽视。官方文档有些地方甚至建议此时传(width, 1)因为内部会强制把高度当 1 处理。我没法确认所有版本都这样但实测在部分版本上灰度写入时传正常尺寸会导致文件损坏。稳妥的做法一直是写灰度视频时用(width, 1)然后每帧写成二维扩展。不过这个行为在不同版本上表现并不统一我也见过传(width, height)正常的。建议在你自己的环境中先写一帧测试验证。4. 两者结合实战摄像头实时录制的完整示例理论讲完该上手了。我这里给一个可以直接抄的摄像头录制脚本里面加了各种防御性判断比市面上大多数教程代码要完整得多。4.1 基础版带状态检查的录制循环import cv2 import os import time def create_video_writer(output_path, fourcc_str, fps, frame_size): os.makedirs(os.path.dirname(output_path), exist_okTrue) fourcc cv2.VideoWriter_fourcc(*fourcc_str) writer cv2.VideoWriter(output_path, fourcc, fps, frame_size) if not writer.isOpened(): raise RuntimeError(f无法创建视频写入器: {output_path}) return writer def main(): cap cv2.VideoCapture(0) if not cap.isOpened(): print(无法打开摄像头) return # 从摄像头读实际分辨率避免写死尺寸 w int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)) h int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)) # 某些编码器要求偶数分辨率 w (w // 2) * 2 h (h // 2) * 2 print(f摄像头分辨率: {w} x {h}) # 尝试用 XVID如果不可用则回退 MJPG fourcc_str XVID writer None try: writer create_video_writer(record.avi, fourcc_str, 25.0, (w, h)) except RuntimeError: print(XVID 不可用回退到 MJPG) writer create_video_writer(record.avi, MJPG, 25.0, (w, h)) start_time time.time() frame_count 0 while True: ret, frame cap.read() if not ret: break # 如果实际帧尺寸和 writer 设置不一致直接跳过或强制缩放 if frame.shape[1] ! w or frame.shape[0] ! h: frame cv2.resize(frame, (w, h)) writer.write(frame) frame_count 1 # 显示实时预览 cv2.imshow(Recording..., frame) key cv2.waitKey(1) 0xFF if key ord(q): break # 统计实际平均帧率 elapsed time.time() - start_time actual_fps frame_count / elapsed if elapsed 0 else 0 print(f实际写入帧数: {frame_count}, 耗时: {elapsed:.2f}s, 实际帧率: {actual_fps:.2f}) cap.release() writer.release() cv2.destroyAllWindows() if __name__ __main__: main()这个脚本有几个细节值得展开说从摄像头动态读取分辨率而不是写死(640, 480)。因为不同摄像头默认分辨率差异很大写死之后要么强行拉伸变形要么还要手动改代码。分辨率做偶数化处理。MJPG 对奇数尺寸容忍度高但 XVID/H264 在部分平台上会翻车统一处理保险。对写入器的创建做了回退。XVID在纯净版 Windows 上可能不可用回退到MJPG至少能出文件。统计实际帧率。这能帮你发现“设置 30 fps实际上只有 12 fps”的问题。4.2 进阶版从视频文件逐帧处理后写新视频摄像头录制是最常见的场景但更常见的是“视频转码/抽帧处理后再写出去”。比如你要给视频加水印、抽帧、调色、做目标检测然后把处理后的帧合成新视频。import cv2 def process_video(src_path, dst_path, fourcc_strMP4V, target_fps30.0): cap cv2.VideoCapture(src_path) if not cap.isOpened(): raise RuntimeError(f无法读取源视频: {src_path}) fps cap.get(cv2.CAP_PROP_FPS) width int(cap.get(cv2.CAP_PROP_FRAME_WIDTH)) height int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT)) total_frames int(cap.get(cv2.CAP_PROP_FRAME_COUNT)) print(f源视频: {fps:.2f} fps, {width}x{height}, 总帧数 {total_frames}) # 计算缩放比假设最长边不超过 1280 scale min(1.0, 1280.0 / max(width, height)) out_width int(width * scale / 2) * 2 out_height int(height * scale / 2) * 2 fourcc cv2.VideoWriter_fourcc(*fourcc_str) writer cv2.VideoWriter(dst_path, fourcc, target_fps, (out_width, out_height)) if not writer.isOpened(): raise RuntimeError(f无法创建输出视频: {dst_path}) frame_idx 0 while True: ret, frame cap.read() if not ret: break # 这里是处理帧的地方缩放、加滤镜、画框等等 if scale ! 1.0: frame cv2.resize(frame, (out_width, out_height)) # 加一个简单的文字水印 cv2.putText(frame, fFrame {frame_idx}, (30, 50), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 2) writer.write(frame) frame_idx 1 if frame_idx % 30 0: print(f处理进度: {frame_idx}/{total_frames}) cap.release() writer.release() print(处理完成) process_video(input.mp4, output.mp4)这个场景里cv2.VideoWriter_fourcc()和cv2.VideoWriter()的组合没那么难真正麻烦的是目标帧率的选择。如果你把 60 fps 的源视频用 30 fps 写出去文件时长会翻倍看起来像慢动作反过来用 60 fps 写 30 fps 的源画面就会快进。所以除非你有特别的变速需求否则target_fps最好等于源视频帧率。另外如果你在帧处理中耗时较高比如跑目标检测模型一帧要 0.2 秒那么 30 fps 的目标根本达不到。这时有两种选择一是把目标帧率降到 5二是用多线程做生产者消费者缓冲后面我会讲这部分工程思路。4.3 为什么 isOpened() 必须检查OpenCV 一个反直觉的设计是cv2.VideoWriter创建时如果出问题通常不会立刻抛异常而是让你拿到一个“无效”的对象。等之后调用write()时可能直接段错误崩溃或者在最后的release()时才暴露问题。所以我强烈建议创建后立刻检查writer.isOpened()。如果返回False直接看这几个方面检查项说明文件路径目录是否存在OpenCV 不会帮你创建目录编码器是否支持换一个 FourCC 再试分辨率是否合法改成偶数尺寸试试系统是否缺编码库Linux 上需要安装libavcodec-extra之类OpenCV 是否带 FFmpeg 支持有些 pip 安装的 opencv-python-headless 没有视频编码模块5. 高频报错与排查链路写视频这个操作报错方式和底层原因之间的关系往往绕好几个弯。我总结了几个高频问题给出完整的排查思路而不是直接给答案。因为直接给答案换个环境就失效排查方法才是通用的。5.1 生成的文件是 0 字节这是最经典的坑。writer创建得很顺利isOpened()也返回True循环也跑了但最后文件大小是 0。排查链路确认你是否真的调用了writer.write(frame)。有人把cap.read()拿回来的ret为False导致循环体一次都没进帧从未写入。确认你写入的frame不是空数组。某些摄像头在初始化未完成时会返回None此时writer.write(None)不会立刻报错但那帧没写进去。确认writer.release()被调用。视频文件不是写一帧落盘一帧的很多编码器会把数据缓存在内存里只有调用release()或writer被销毁时才刷新到磁盘。如果你程序中途崩溃没走到release()文件可能就停留在 0 字节。确认磁盘空间够用。MJPG 编码生成本地大幅面视频时占空间速度很快磁盘写满后文件会停留在 0 字节。5.2 报错 “OpenCV: FFMPEL: tag 0x... is not supported”这个报错信息里会有一个十六进制数比如tag 0x48435641把它按字节拆成 ASCII 码48 43 56 41对应HCVA其实就是V4CH反转过来。这个报错的意思是你指定的 FourCC 编码器在当前 OpenCV/FFmpeg 构建里找不到支持。处理这种问题的顺序先确认 FourCC 字符串有没有拼错MJPG写成MPJG这种低级错误。换一个系统自带支持率高的编码器比如MJPG或XVID。如果用的是opencv-python精简版可以考虑重装成opencv-contrib-python这个版本通常带更多编解码支持。在 Ubuntu/Debian 系系统上安装 FFmpeg 相关的额外编解码包sudo apt install ffmpeg libavcodec-extra装完之后可能需要重建 OpenCV 才能让它在运行期看到新的编码器这个要看你的 OpenCV 是怎么装的。如果是 pip 装的通常只需要系统有 FFmpeg 运行库即可。5.3 视频花屏或绿屏花屏问题的原因比较多按我的排查经验概率从高到低排列是分辨率不是偶数。很多 MPEG 系编码要求宽高为偶数奇数宽高会导致宏块对齐失败表现为最右侧或最底部出现彩色噪条。解决把宽高调整成偶数。帧尺寸和 frameSize 不一致。如果你在VideoWriter里写的是(640, 480)但实际写入的frame.shape是(480, 640, 3)OpenCV 不做自动检查底层直接按(640, 480)解析内存画面当然乱。BGR 与 RGB 通道顺序问题。OpenCV 默认写入 BGR 通道但如果中间你用了 PIL 或其他库处理过帧变成了 RGB写进去之后视频画面红蓝互换看起来像花屏。检查方式很简单如果画面整体的颜色明显不对先用cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)或者反向转一次看颜色是否正常。isColor 参数错误。写入彩色帧却把isColor设为False某些编码器会把 3 通道数据强行按单通道解析出来的画面会乱掉。确认你的输入帧通道数和isColor设置一致。5.4cv2.waitKey(0)27和卡死问题这个其实是视频显示配合问题。录制时用cv2.waitKey(1)来刷新画面waitKey(0)会阻塞程序直到按键导致视频录制和显示卡住。热搜词里“opencv库waitkey为啥没参数时会卡主”指的就是waitKey(0)。如果你在录制循环里用了waitKey(0)整个循环都会停住视频一帧都不写看起来就跟死机一样。正确做法是cv2.waitKey(1)参数 1 表示等 1 毫秒让 OpenCV 有机会处理 GUI 事件。还有一个小坑waitKey的返回值在高位还包含了很多信息所以需要用 0xFF只取低 8 位的键值来和 ASCII 码比较。这也是为什么到处都有key cv2.waitKey(1) 0xFF这种写法。6. 编码格式选型和工程化落地建议前面讲了很多基础最后这部分分享一些我在实际项目里的选型经验和工程化思考。6.1 不同场景的编码选型推荐场景推荐编码容器理由快速调试/临时录制MJPG.avi兼容性最好几乎所有环境都支持长时间监控录制XVID 或 mp4v.avi / .mp4压缩比适中不挑环境最终交付/在线播放H264 (avc1).mp4文件小画质好浏览器/手机都能播灰度图/深度图序列I420 或 MJPG isColorFalse.avi单通道数据写起来干净关于 H264 在 OpenCV 里的支持我要多说一句你真想在 Python 里稳定产出 H264 视频别指望 OpenCV 的VideoWriter它在不同平台的行为差异太大了。最稳的做法是用VideoWriter写出无损或低压缩的中间视频然后调用系统里的 FFmpeg 命令行做转码ffmpeg -i raw_output.avi -c:v libx264 -crf 23 -preset fast final_output.mp4这也是很多 CV 项目在生产环境里的标准做法。OpenCV 负责帧处理FFmpeg 负责终极编码各干各擅长的。6.2 处理速度跟不上目标帧率时的工程解法前面说到如果帧处理太慢实际写入的帧率和目标帧率不匹配会导致视频时间轴错乱。这里说两个工程解法。方案一抽帧处理降低目标帧率。如果一帧处理要 0.1 秒你干脆把目标 fps 设为 10这样录制出来的视频播放速度和实际录制进度一致。方案二开启一个写入缓冲线程把处理完的帧放进队列由后台线程负责writer.write()。这样可以避免 I/O 或编码耗时拖慢主循环但队列要设置最大长度否则内存暴涨。import cv2 import threading import queue import time class AsyncVideoWriter: def __init__(self, output_path, fourcc_str, fps, frame_size): self.writer cv2.VideoWriter( output_path, cv2.VideoWriter_fourcc(*fourcc_str), fps, frame_size ) self.frame_queue queue.Queue(maxsize128) self.running True self.thread threading.Thread(targetself._write_loop) self.thread.start() def _write_loop(self): while self.running: try: frame self.frame_queue.get(timeout0.1) self.writer.write(frame) except queue.Empty: continue def write(self, frame): try: self.frame_queue.put_nowait(frame) except queue.Full: # 队列满了就丢帧防止内存爆掉 pass def release(self): self.running False self.thread.join(timeout1.0) self.writer.release() # 使用示例 async_writer AsyncVideoWriter(async.avi, XVID, 25.0, (1280, 720)) # 主循环里只需要 async_writer.write(frame)这里队列满了直接丢帧的策略适合实时监控类应用——你更关心“当前帧有没有被记录”而不是“历史帧是否完整”。如果是离线文件处理就不要丢帧而是把队列容量调大或者改用多生产者多消费者模型。6.3 长视频录制中的文件切分策略录制超过 10 分钟的视频时有几个实际问题文件过大超过 4GB部分文件系统写不了录制过程中程序崩溃会丢失全部数据后期处理单个大文件内存压力大。我的经验是每 5 到 10 分钟切一个新文件。MAX_FRAMES_PER_FILE 25 * 300 # 25fps * 300秒 5分钟 frame_counter 0 file_index 0 writer None while True: ret, frame cap.read() if not ret: break if frame_counter % MAX_FRAMES_PER_FILE 0: if writer: writer.release() file_index 1 filename fsegment_{file_index:03d}.avi writer cv2.VideoWriter(filename, fourcc, fps, (w, h)) writer.write(frame) frame_counter 1切分逻辑很简单但注意release()和重新创建 writer 的时机要放在写帧之前否则会丢一帧。6.4 我的一些个人经验与习惯最后聊点个人习惯。踩了这么多年视频写出的坑后我现在写任何VideoWriter相关代码都默认带上三层防护第一创建后立刻检查isOpened()不检查不往下走。这能拦截掉八成的环境问题。第二所有尺寸都做偶数化和显式转换不依赖 OpenCV 的隐式行为。第三release()放在finally或使用with语义保证程序异常退出时也能刷盘。writer None try: writer cv2.VideoWriter(...) # 写入循环 finally: if writer is not None: writer.release()还有一个小心得不同 OpenCV 版本对同一个 FourCC 的支持矩阵可能完全不同。遇到诡异的视频写出问题先把cv2.__version__打出来再看官方文档对应版本的支持说明往往比瞎试更高效。尤其在离线环境里没有外网查资料时先用我前面提到的check_fourcc()函数把可用编码器列表跑一遍问题就能范围缩小到“编码器支持层面”还是“参数使用层面”。视频写出的本质其实不难难的是边界情况足够多分辨率奇偶、编码器索引、线程安全、文件系统限制、内存缓冲、时间轴语义……每一个小细节单独拿出来都不算大事但叠在一起就足以让一个看起来很简单的小功能折磨你半天。希望这篇从头到尾拆解两个函数使用细节的内容能帮你把这些边界情况提前堵上让你做视频相关开发时少走几段弯路。