音视频这个领域，刚接触的时候很容易被一堆名词砸晕：编码、封装、协议、推流、拉流、转码、解码、渲染，每个词单拎出来都能写一本书。但真正上手做项目之后你会发现，日常打交道的东西其实就那么几样，把核心链路跑通一遍，剩下的都是在这个骨架上添砖加瓦。这篇内容适合刚入行的开发者、想从前后端转音视频方向的工程师，以及需要自己搭一套直播或点播流程的技术负责人。我会从整体设计思路讲到具体实操，把踩过的坑和验证过的方案都摊开来说，尽量让你看完能直接动手搭出一个能跑的东西。
1. 音视频入门先搞清楚整体链路
1.1 从采集到播放到底经历了什么
很多人一上来就去研究H.264的编码原理，结果看了两周还在纠结B帧和P帧的区别，项目一点进展都没有。我的建议是先站远一点，把整条链路看清楚。一个完整的音视频流程，不管你是做直播、点播还是视频会议，本质上都跑不出这几个环节：采集、预处理、编码、封装、传输、解封装、解码、渲染。这八个环节像一条流水线，数据从一头进去，从另一头出来变成你屏幕上能看能听的东西。
采集环节负责从摄像头和麦克风拿到原始数据。视频这边通常是YUV格式，音频那边是PCM格式。这两个格式的特点就是体积巨大，一个1080p、30帧的YUV420视频，一秒钟的数据量大概是1920×1080×1.5×30，算下来接近93MB。你想想，一分钟就5个多G，这要直接传，带宽根本扛不住。所以必须编码压缩，这就是编码环节存在的意义。
编码完之后数据体积能降到原来的几十分之一甚至几百分之一，但这时候它还是一段一段的裸数据，需要封装成一个文件或者流，把音频、视频、字幕、时间戳这些信息组织在一起，方便传输和存储。封装格式就是我们常说的MP4、MKV、FLV、TS这些。传输环节则决定了你用什么样的协议把数据送出去，直播场景常用RTMP、HLS、HTTP-FLV，点播场景基本就是HTTP了。
到了播放端，流程反过来走一遍：先解封装，把音视频数据分开，然后分别解码成原始数据，最后渲染到屏幕和扬声器。理解这条链路之后，你遇到任何问题都能快速定位到是哪个环节出了毛病，而不是对着一堆日志发呆。
1.2 为什么先跑通再深挖是更聪明的做法
我见过太多人卡在理论里出不来。音视频的理论确实深，光一个H.264标准文档就几百页，但你是来做项目的，不是来写标准的。先跑通再深挖这个策略在音视频领域特别管用，原因是这个领域的工具链已经非常成熟了，FFmpeg一个命令行就能帮你完成采集、编码、封装、推流的大部分工作。
你可以先用FFmpeg推一个本地视频文件到流媒体服务器，再用播放器拉流播放，整个链路跑通可能只需要半小时。跑通之后你再去研究每一步用了什么编码器、什么参数、为什么这么选，这时候你是有体感的，学起来快得多。反过来，如果你先把H.264的帧内预测、帧间预测、变换量化全啃一遍再动手，大概率中途就放弃了。
我自己的习惯是，任何一个新领域，先用现成工具搭一个最小可用系统，然后逐个环节替换成自己写的代码，每替换一个就深入理解一个。这样既有成就感，又能保证学到的东西是真正用得上的。
1.3 入门阶段需要准备的工具和环境
工欲善其事必先利其器，音视频开发对工具依赖很重。下面这几个东西是必须装的，我列个表说明用途和注意事项。
| 工具 | 用途 | 注意事项 |
|---|---|---|
| FFmpeg | 音视频处理瑞士军刀，编解码、转码、推流、拉流全能 | 建议用较新版本，老版本某些编码器有bug |
| FFprobe | 查看音视频文件详细信息 | 随FFmpeg一起安装，分析问题必备 |
| VLC | 播放器，支持几乎所有格式和协议 | 用来验证流是否正常，比写代码调试快 |
| OBS | 推流工具，也可用于录制 | 测试推流链路时非常方便 |
| 流媒体服务器 | 接收和分发流 | 入门可以用开源的，部署简单 |
环境方面，Linux和macOS对音视频工具链支持最好，Windows也能用但偶尔会遇到路径和编码问题。如果你用Windows，建议在WSL里操作，能省不少事。编程语言方面，C/C++是音视频的母语，但入门阶段用Python或Go调FFmpeg的库也完全够用，等深入到底层再转C++不迟。
提示：安装完FFmpeg后，第一件事是运行
ffmpeg -version确认版本，然后运行ffmpeg -codecs看看支持哪些编码器。不同版本支持的编码器差异很大，这个命令能帮你快速确认环境是否可用。
2. 核心概念拆解与实操要点
2.1 编码格式与封装格式的区别
这是新手最容易混淆的一对概念。我用一个生活化的类比来解释：编码格式像是把一顿饭做成了压缩饼干，封装格式像是把压缩饼干装进了一个盒子。压缩饼干是内容本身，盒子是包装方式。你可以把同样的压缩饼干装进不同的盒子，也可以在一个盒子里放不同种类的压缩饼干。
具体来说，H.264、H.265、VP9、AV1这些是视频编码格式，AAC、MP3、Opus这些是音频编码格式。而MP4、MKV、FLV、TS这些是封装格式。一个MP4文件里可能装着H.264的视频和AAC的音频，也可能装着H.265的视频和MP3的音频。封装格式不关心你里面装的是什么，它只负责把音视频数据、时间戳、元信息组织在一起。
理解这个区别非常重要，因为在实际项目中，你经常需要做转封装和转码两种不同的操作。转封装只是换个盒子，里面的压缩饼干不动，速度极快，几乎不消耗CPU。转码则是把压缩饼干重新做一遍，速度慢，CPU消耗大。很多新手一遇到格式不兼容就想着转码，其实很多时候转封装就能解决问题。
举个例子，FLV和TS都常用于直播，如果你的服务器输出FLV但播放端只支持TS，你完全可以用FFmpeg做转封装，命令是这样的：
ffmpeg -i input.flv -c copy output.ts注意这里的-c copy就是告诉FFmpeg不要重新编码，直接复制音视频流。这个操作一秒钟能处理几百兆的数据，而如果去掉-c copy做转码，速度可能只有几倍速。
2.2 关键参数怎么选才不踩坑
编码参数的选择直接决定了画质、带宽和CPU消耗的平衡。我挑几个最关键的参数来说，这些是实际项目里必须调的。
分辨率决定了画面的清晰度，但也不是越高越好。你要考虑播放端的屏幕尺寸和网络条件。移动端直播用720p通常就够了，强行上1080p只会让卡顿率飙升。帧率方面，24到30帧适合大多数场景，游戏直播可能需要60帧，但帧率翻倍意味着数据量也接近翻倍。
码率是最核心的参数，它直接决定了带宽占用和画质。码率给低了画面糊，给高了带宽扛不住。我一般用这个经验公式来估算：码率（kbps）≈ 分辨率宽 × 高 × 帧率 × 0.07。比如1280×720、30帧的视频，算下来大约是1280×720×30×0.07≈1935kbps，取个整就是2000kbps。这个公式不是绝对的，动作剧烈的画面需要更高码率，静态画面可以更低。
GOP大小也很关键，它决定了关键帧的间隔。GOP太大，seek的时候定位慢，直播场景下新观众进来要等更久才能看到画面。GOP太小，关键帧太多，码率会浪费。直播场景一般设2到4秒一个GOP，点播可以设5到10秒。
下面这个表格是我在不同场景下的参数配置参考，可以直接抄作业：
| 场景 | 分辨率 | 帧率 | 视频码率 | 音频码率 | GOP |
|---|---|---|---|---|---|
| 移动端直播 | 720p | 30 | 2000kbps | 64kbps | 2s |
| 游戏直播 | 1080p | 60 | 6000kbps | 128kbps | 2s |
| 视频会议 | 480p | 15 | 500kbps | 32kbps | 4s |
| 点播视频 | 1080p | 24 | 4000kbps | 128kbps | 10s |
注意：音频码率不要设得太低，64kbps以下的AAC音频会有明显的金属感，人声听起来很不舒服。如果带宽实在紧张，宁可降视频码率也不要降音频码率，因为人对声音的敏感度往往高于画面。
2.3 时间戳与同步机制
音视频同步是入门阶段最容易出问题的地方。你肯定见过那种画面和声音对不上的视频，嘴型对不上声音，或者声音比画面快半拍，这就是同步没做好。
同步的核心是时间戳。每一帧音频和视频数据都带有一个时间戳，播放器根据时间戳来决定什么时候渲染这一帧。时间戳的基准叫做时基，视频常用的是1/90000秒，音频常用的是采样率的倒数。不同来源的数据时基可能不一样，所以需要统一转换。
同步策略有三种：以音频为基准、以视频为基准、以外部时钟为基准。实际项目里最常用的是以音频为基准，因为人对声音的断续比画面的卡顿更敏感。音频不能断，视频可以丢帧或者重复帧来追赶音频。
具体做法是，播放器维护一个音频时钟，每渲染一帧视频之前，拿视频的时间戳和当前音频时钟比较。如果视频落后太多，就丢掉这一帧直接渲染下一帧；如果视频超前太多，就等待一会儿再渲染。这个阈值一般设在几十毫秒，太小会导致频繁丢帧，太大会导致不同步感明显。
我在实际项目里踩过的坑是，有些摄像头的音频采集和视频采集用的是不同的时钟源，长时间运行会累积漂移。解决办法是定期做一次重同步，比如每30秒强制对齐一次时间戳。这个细节在文档里很少提，但实际做长时间直播的时候非常关键。
3. 完整实操流程与核心环节实现
3.1 用FFmpeg完成一次完整的转码
我们从一个最实际的场景开始：你有一个手机拍的MOV文件，需要转成适合网页播放的MP4文件。这个需求在项目里太常见了，我把它拆成完整的步骤。
第一步，先用FFprobe看看源文件的信息：
ffprobe -v quiet -print_format json -show_format -show_streams input.mov这个命令会输出JSON格式的详细信息，包括编码格式、分辨率、帧率、码率、时长等。为什么要先看？因为你需要知道源文件用的是什么编码，如果已经是H.264和AAC，那直接转封装就行，不需要转码。很多新手不看源信息直接转码，白白浪费大量时间。
第二步，根据源信息决定转码策略。假设源文件是H.265视频和PCM音频，而网页需要H.264和AAC，那就必须转码。命令如下：
ffmpeg -i input.mov \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 128k \ -movflags +faststart \ output.mp4这里每个参数都有讲究。-c:v libx264指定用H.264编码器，兼容性最好。-preset medium是编码速度预设，从ultrafast到veryslow，越慢压缩率越高，medium是速度和压缩率的平衡点。-crf 23是恒定质量模式，数值越小画质越好，18到28是常用范围，23是默认值。-c:a aac -b:a 128k指定音频用AAC编码，码率128kbps。-movflags +faststart这个参数特别重要，它会把MP4的元信息移到文件头部，这样网页播放器不用下载完整个文件就能开始播放。
第三步，验证输出文件。转码完成后，再用FFprobe检查一遍输出文件，确认编码格式、分辨率、时长都符合预期。然后用VLC播放一遍，看看画质和音质有没有问题。
提示：
-crf和-b:v不能同时用。如果你需要精确控制文件大小，用-b:v指定目标码率；如果追求画质稳定，用-crf。我一般优先用-crf，因为画质更可控。
3.2 搭建一个最小可用的直播链路
直播听起来复杂，但最小可用链路其实很简单：推流端、流媒体服务器、拉流端，三个部分。我用开源方案来演示，整个搭建过程大概二十分钟。
推流端用OBS或者FFmpeg都行。FFmpeg推流的命令是这样的：
ffmpeg -re -i input.mp4 \ -c:v libx264 -preset veryfast -b:v 2000k \ -c:a aac -b:a 128k \ -f flv rtmp://server_ip/live/stream_key-re参数表示按原始帧率读取，不加这个参数FFmpeg会以最快速度推流，服务器和播放端都会出问题。-f flv指定输出格式为FLV，因为RTMP协议通常承载FLV格式的数据。
流媒体服务器这边，入门阶段可以用一些轻量级的开源方案，部署很简单，一条命令就能跑起来。服务器的作用是接收推流，然后分发给多个拉流端。配置的时候要注意端口开放和鉴权设置，不然任何人都能往你的服务器推流。
拉流端用VLC直接打开rtmp://server_ip/live/stream_key就能播放。如果要嵌入网页，可以用支持FLV的播放器库，或者让服务器同时输出HLS流，用原生video标签播放。
这里有个关键点：RTMP延迟低但需要Flash支持（现在浏览器基本不支持了），HLS兼容性好但延迟高。实际项目里常见的做法是服务器同时输出RTMP和HLS，RTMP给低延迟场景用，HLS给网页和移动端用。HLS的延迟通常在10到30秒，如果业务对延迟敏感，需要考虑低延迟HLS或者其他方案。
3.3 用代码实现一个简单的播放器逻辑
如果你需要自己写播放器，理解解码和渲染的流程很重要。我用伪代码的方式展示核心逻辑，语言用Python示意，实际项目里可能是C++或者Go。
# 初始化解码器 video_decoder = create_decoder(codec='h264') audio_decoder = create_decoder(codec='aac') # 主循环 while not end_of_stream: packet = read_packet() if packet.type == 'video': frame = video_decoder.decode(packet) if frame: # 根据时间戳决定是否渲染 if should_render(frame.timestamp): render_video(frame) elif packet.type == 'audio': frame = audio_decoder.decode(packet) if frame: render_audio(frame) # 同步检查 sync_check(video_clock, audio_clock)这段逻辑看起来简单，但每个环节都有坑。read_packet可能返回空，需要处理。解码器可能输出多帧也可能输出零帧，需要循环读取。should_render的判断逻辑就是前面说的同步策略。render_video和render_audio涉及硬件加速和缓冲区管理，实际代码会复杂得多。
我的建议是，入门阶段不要急着写播放器，先用现成的播放器库，把精力放在理解流程上。等你能熟练地用FFmpeg和现成工具解决问题了，再考虑自己写。写播放器是一个深坑，光是音视频同步就能调一周。
3.4 转码服务的参数调优实战
如果你要做一个转码服务，比如用户上传视频后自动转成多种清晰度，参数调优就很重要了。我拿一个实际项目举例，需求是用户上传的视频要转成360p、720p、1080p三档，用于不同网络条件下的自适应播放。
首先确定每档的参数。360p用640×360、800kbps，720p用1280×720、2000kbps，1080p用1920×1080、4000kbps。音频统一用AAC 128kbps。GOP统一设2秒，这样切换清晰度的时候关键帧能对齐，播放器切换时不会卡顿。
然后考虑转码方式。三档可以并行转，充分利用多核CPU。FFmpeg本身支持多线程，但并行跑三个进程通常比一个进程跑三档更快。命令大概是这样：
# 360p ffmpeg -i input.mp4 -vf scale=640:360 -c:v libx264 -b:v 800k -c:a aac -b:a 128k -g 60 output_360p.mp4 # 720p ffmpeg -i input.mp4 -vf scale=1280:720 -c:v libx264 -b:v 2000k -c:a aac -b:a 128k -g 60 output_720p.mp4 # 1080p ffmpeg -i input.mp4 -vf scale=1920:1080 -c:v libx264 -b:v 4000k -c:a aac -b:a 128k -g 60 output_1080p.mp4-g 60表示GOP大小为60帧，在30帧的视频里就是2秒。三档的GOP必须一致，否则切换时会出问题。
转码完成后，还需要生成一个索引文件，告诉播放器每档的地址和带宽要求。这个索引文件通常是HLS的m3u8格式或者DASH的mpd格式。FFmpeg可以直接生成HLS：
ffmpeg -i input.mp4 \ -vf scale=1280:720 -c:v libx264 -b:v 2000k \ -c:a aac -b:a 128k \ -f hls -hls_time 4 -hls_list_size 0 \ output.m3u8-hls_time 4表示每个TS切片4秒，-hls_list_size 0表示保留所有切片不删除。实际生产环境还需要考虑切片清理和CDN分发，但入门阶段这样已经够用了。
4. 常见问题与排查技巧实录
4.1 播放失败问题速查表
音视频项目里播放失败是最常见的问题，原因五花八门。我整理了一个速查表，按现象分类，方便你快速定位。
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 黑屏但有声音 | 视频编码不支持 | 用FFprobe看视频编码格式，确认播放器是否支持 |
| 有画面但没声音 | 音频编码不支持或采样率异常 | 检查音频编码和采样率，常见问题是采样率不是44100或48000 |
| 完全无法播放 | 封装格式不支持或文件损坏 | 用VLC测试，如果VLC也放不了说明文件有问题 |
| 播放卡顿 | 码率过高或网络带宽不足 | 降低码率或检查网络，用-b:v限制码率 |
| 音画不同步 | 时间戳异常或同步逻辑有问题 | 检查源文件时间戳，用FFmpeg重新封装 |
| 拖动进度条后花屏 | 关键帧间隔太大或索引损坏 | 减小GOP，用-movflags +faststart修复索引 |
这个表覆盖了八成以上的常见问题。遇到问题先对号入座，能省很多时间。
4.2 编码参数设置不当引发的典型故障
参数设置不当导致的故障往往很隐蔽，因为文件能播放，只是效果不对。我列几个我踩过的坑。
码率设太低导致画面糊。这个最直观，但新手容易犯的错误是只看分辨率不看码率。1080p配500kbps，画面会糊成马赛克。解决办法是按前面说的公式估算码率，或者用CRF模式让编码器自动决定。
GOP设太大导致seek慢。点播场景下用户拖动进度条，如果GOP是10秒，那最多要等10秒才能看到画面。直播场景下新观众进来也要等这么久。解决办法是直播GOP设2秒，点播设5到10秒。
音频采样率不匹配导致变调。源音频是44100Hz，播放端按48000Hz播放，声音会变尖。解决办法是转码时统一采样率，用-ar 48000指定。
像素格式不匹配导致颜色异常。源视频是YUV420P，编码器要求YUV422P，不转换的话颜色会偏。FFmpeg通常会自动处理，但某些情况下需要手动指定-pix_fmt yuv420p。
注意：
-pix_fmt yuv420p这个参数在输出MP4时几乎应该默认加上，因为很多播放器只支持YUV420P，不支持YUV422P或YUV444P。不加的话，在某些播放器上会出现颜色异常或者直接黑屏。
4.3 网络传输环节的排查思路
网络问题在直播场景里特别常见，排查起来也最麻烦，因为涉及推流端、服务器、拉流端三个环节。我的排查思路是从两端往中间查。
先确认推流端是否正常。用FFmpeg推流的时候加上-loglevel debug，能看到详细的推流日志。如果推流端就报错，那问题在推流端，检查网络连接、服务器地址、流密钥是否正确。
推流端正常的话，去服务器上看是否收到了流。大多数流媒体服务器都有状态页面或者日志，能看到当前有哪些流在推。如果服务器没收到流，那问题在推流端到服务器的网络链路上，检查防火墙、端口、带宽。
服务器收到了流但拉流端播不了，那问题在服务器到拉流端的链路上。先用VLC在服务器本机拉流测试，如果本机能播说明服务器没问题，问题在拉流端的网络。如果本机也播不了，那问题在服务器配置上，检查服务器的输出配置和鉴权设置。
这个排查思路能帮你快速缩小问题范围，避免在错误的方向上浪费时间。
4.4 性能优化的几个实用技巧
音视频处理是计算密集型任务，性能优化能直接省钱。我分享几个实际有效的技巧。
用硬件加速。FFmpeg支持多种硬件加速方案，能用GPU就不用CPU。比如用-c:v h264_nvenc代替-c:v libx264，速度能快好几倍，CPU占用大幅下降。代价是画质可能略差，需要调高码率补偿。硬件加速的可用性取决于服务器有没有对应的GPU，选型的时候要提前确认。
用预设调速度。-preset参数从ultrafast到veryslow，速度差异能有十倍以上。直播场景用veryfast或faster，点播场景可以用medium或slow。不要盲目用veryslow，压缩率提升有限但时间成本很高。
并行处理。多档转码用多进程并行，比单进程串行快得多。FFmpeg本身的多线程主要用在单次编码上，多档并行需要你自己调度。用GNU Parallel或者写个简单的脚本就能实现。
合理设置缓冲区。推流和拉流都有缓冲区，缓冲区太小容易卡顿，太大延迟高。直播场景缓冲区设1到2秒，点播场景可以设5到10秒。这个参数在不同工具里名字不一样，FFmpeg里是-buffer_size，OBS里是缓冲区大小设置。
我在实际项目里的体会是，性能优化要先测量再优化。用top或者htop看CPU占用，用iftop看网络流量，找到瓶颈再针对性优化。盲目优化往往效果不好，还容易引入新问题。
4.5 跨平台兼容性避坑指南
音视频的跨平台兼容性是个大坑，同一个文件在不同平台、不同浏览器、不同设备上表现可能完全不一样。我总结了几条经验。
浏览器方面，Chrome和Firefox对H.264的支持最好，Safari对H.265有支持但其他浏览器基本不支持。如果你要覆盖所有浏览器，H.264加AAC是最安全的选择。AV1编码效率高但兼容性还不行，入门阶段不要碰。
移动端方面，iOS对HLS支持最好，Android对DASH支持更好。实际项目里通常同时输出HLS和DASH，让客户端根据平台选择。移动端的硬件解码能力差异很大，低端机可能只支持720p硬解，1080p会掉帧。做移动端项目一定要在真实设备上测试，模拟器测不出问题。
封装格式方面，MP4兼容性最好但需要完整下载才能播放（除非用faststart），FLV适合直播但浏览器不支持，TS适合HLS但文件体积大。没有一种格式是万能的，要根据场景选择。
提示：做跨平台项目的时候，准备一个测试矩阵，列出你要支持的平台、浏览器、设备，每个组合都测一遍。这个工作很枯燥但能避免上线后的大量投诉。我见过太多项目在开发机上一切正常，上线后用户反馈各种播放问题。
5. 进阶方向与学习路径建议
5.1 从入门到深入的几个阶段
音视频这个领域，入门容易深入难。我把学习路径分成三个阶段，你可以对照自己的情况看看处在哪个位置。
第一阶段是工具使用阶段，能熟练用FFmpeg做转码、转封装、推流、拉流，能搭建简单的直播和点播系统，能排查常见的播放问题。这个阶段大概需要一到两个月，重点是动手，把每个命令都跑一遍，把每个参数都试一遍。
第二阶段是原理理解阶段，理解H.264的编码原理、AAC的编码原理、RTMP和HLS的协议细节、音视频同步的机制。这个阶段需要看一些文档和源码，FFmpeg的源码是很好的学习材料。这个阶段大概需要三到六个月，重点是理解为什么，而不只是知道怎么做。
第三阶段是系统设计阶段，能设计大规模的转码集群、低延迟直播系统、高可用的点播平台。这个阶段需要综合考虑成本、性能、可靠性、可扩展性，需要有一定的架构经验。这个阶段没有明确的时间表，取决于你参与的项目复杂度。
我的建议是不要跳阶段。我见过有人第一阶段还没跑通就去研究WebRTC的拥塞控制算法，结果两头都没学好。踏踏实实把每个阶段的东西吃透，后面会越来越顺。
5.2 值得深入研究的几个方向
音视频领域很宽，一个人不可能什么都精通。我列几个值得深入的方向，你可以根据自己的兴趣和项目需求选择。
实时通信方向，核心是低延迟，WebRTC是绕不开的技术。这个方向适合做视频会议、在线教育、远程医疗等场景。难点在于网络适应性和回声消除，需要深入理解网络协议和信号处理。
直播方向，核心是高并发和低延迟的平衡。这个方向适合做电商直播、游戏直播、赛事直播等场景。难点在于CDN调度、秒开优化、弱网对抗。
点播方向，核心是存储和转码的效率。这个方向适合做视频网站、在线课程等场景。难点在于转码集群的调度和成本优化。
视频处理方向，核心是视频分析和编辑。这个方向适合做短视频、视频审核、智能剪辑等场景。难点在于AI算法的集成和性能优化。
每个方向都有很深的东西可以挖，选一个跟你的项目最相关的深入进去，比泛泛地什么都学要好。
5.3 日常工作中积累经验的方法
音视频的问题往往很隐蔽，积累经验最好的方法就是多踩坑多总结。我自己的习惯是维护一个问题记录本，每次遇到新问题就记下来，包括现象、排查过程、原因、解决办法。时间长了这就是你自己的知识库，比任何文档都有用。
另外就是多动手实验。看到一个参数不懂，就改一改看看效果。看到一个协议不懂，就抓包看看数据长什么样。音视频是实践性很强的领域，光看书是学不会的。
还有一点是关注社区。音视频领域有很多活跃的社区和邮件列表，FFmpeg的邮件列表里有很多高质量的讨论。遇到解决不了的问题，去社区搜一搜，大概率有人遇到过。提问的时候把复现步骤、环境信息、日志都贴清楚，能更快得到帮助。
最后再分享一个小技巧：做音视频项目的时候，养成用FFprobe检查每个环节输出的习惯。从源文件到编码后到封装后到传输后，每一步都检查一遍，能快速定位问题出在哪个环节。这个习惯帮我省了无数调试时间。
