尧图网页设计 
简介这份PDF资料面向具备一定Java基础、希望掌握音视频同步播放的开发者围绕Javacv调用ffmpeg展开重点解决音视频帧捕获后如何同步播放的问题。内容以FFmpegFrameGrabber帧捕捉器为核心讲解视频帧经Java2DFrameConverter转为BufferedImage显示、音频帧通过sourceDataLine写入扬声器并采用生产者消费者模式缓冲帧数据缓解捕获速度大于消耗速度的矛盾。同步方案采用视频向音频对齐借助音频帧时间戳驱动视频线程延时播放同时针对Thread.sleep不精确、声卡缓冲易耗尽等问题给出动态调节延时与依据available()判断数据量的优化思路。资源包为1个PDF文件大小约178KB篇幅精炼适合作为音视频同步入门与排错参考。目前已有3281人学习可帮助读者快速理解同步播放的整体流程与关键实现细节。1. JavaCV 配 FFmpeg 做音视频同步播放为什么你播出来的画面总比声音慢半拍用 JavaCV 调 FFmpeg 做播放器最容易翻车的不是解码失败而是音视频各播各的——画面越播越慢声音早就跑前面去了或者反过来声音断断续续像卡带。这个问题的本质不是 JavaCV 的锅也不是 FFmpeg 的锅而是你没有建立一套统一的时钟基准来驱动两路数据。JavaCV 在这里的角色是 FFmpeg 的 Java 封装层它把AVFormatContext、AVCodecContext、AVFrame这些 C 结构体映射成 Java 对象让你能在 JVM 里直接调avcodec_send_packet和avcodec_receive_frame。但封装层不会替你做同步决策时间戳怎么对齐、谁等谁、丢帧还是补帧全得自己写。这篇文章面向的是已经能用 JavaCV 解出画面和声音、但播放时音画不同步的开发者我会把同步策略的选择依据、具体实现步骤、参数怎么调、以及我踩过的坑一条条讲清楚。读完你至少能搭出一个音视频偏差控制在 40ms 以内的播放器骨架。2. JavaCV 解码链路与音视频同步的时钟选型2.1 JavaCV 里 FFmpeg 解码的基本数据流JavaCV 的FFmpegFrameGrabber封装了从打开文件到解码出Frame的完整流程。它的内部逻辑是avformat_open_input打开容器 →avformat_find_stream_info探测流信息 → 分别对音频流和视频流调avcodec_open2打开解码器 → 在grab()里循环调av_read_frame读包再按 stream_index 分发到对应的解码器。你拿到的Frame对象里视频帧是BufferedImage音频帧是Buffer[]采样数据而时间信息藏在frame.timestamp里单位是微秒。关键点在于FFmpegFrameGrabber默认是单线程顺序 grab 的它按容器里包的物理顺序返回帧。如果你直接在一个循环里 grab 一帧视频就画一帧、grab 一帧音频就写一帧那播放速度完全取决于解码速度跟真实时间没关系。这就是为什么很多人第一次写出来的播放器要么快进要么慢放——它根本没有时钟概念。要做同步你得把 grab 和解耦成两个独立线程各自维护队列然后用一个统一的时钟来决定什么时候消费队列里的帧。这个时钟可以是系统时钟、音频时钟或视频时钟选哪个直接决定了同步策略的复杂度和最终效果。2.2 三种同步策略的取舍音频为主、视频为主、外部时钟音频为主的策略是以音频播放的进度作为主时钟视频帧根据音频时钟来调整显示时间。人耳对音频的断续和变速极其敏感对视频帧的微小延迟反而容忍度高。所以业界绝大多数播放器包括 FFplay 默认模式都选音频为主时钟。具体做法是音频线程每播放完一个采样块就更新当前音频时钟audio_clock pts 已播放时长视频线程拿到一帧后比较自己的 pts 和当前音频时钟如果视频快了就等慢了就丢帧或加速。视频为主的策略反过来以视频帧的显示时间为主时钟音频通过重采样或丢采样来追赶。这种策略在视频会议里常见因为画面卡顿比声音卡顿更不可接受。但在点播播放场景里音频变速会带来明显的音调变化体验很差所以不推荐。外部时钟策略是维护一个独立的系统时钟音频和视频都向它对齐。这种方案实现最简单但精度最差因为系统时钟和媒体时钟之间会有漂移播久了必然不同步。除非你的场景对同步要求极低比如只是预览否则不要用。我一般会选音频为主时钟配合视频帧的丢帧/等待策略。下面这张表是我在实际项目里总结的三种策略对比策略主时钟来源音频处理视频处理适用场景同步精度音频为主音频播放进度正常播放等待或丢帧点播、本地播放±20ms视频为主视频显示时间重采样或丢采样正常显示视频会议、直播±40ms外部时钟系统纳秒时钟向系统时钟对齐向系统时钟对齐预览、低要求场景±100ms选音频为主之后还有一个参数要定音频时钟的更新粒度。如果你每播放一个采样点就更新一次时钟那锁竞争会很频繁如果每播放一个音频缓冲区才更新那视频线程拿到的时钟会有缓冲区大小的延迟。常见做法是每播放完一个AVFrame的音频数据后更新一次时钟同时在计算时把当前缓冲区已播放的偏移量加进去。2.3 用 JavaCV 打开流并拿到音视频时间戳在写同步逻辑之前先得确认你能正确拿到每一路的时间戳。JavaCV 的Frame.timestamp在解码后可能是AV_NOPTS_VALUE这时候你需要用frame.opaque里的AVFrame原始指针去读pts或者退而求其次用grabber.getTimestamp()。下面这段代码是我常用的初始化方式// 初始化 FFmpegFrameGrabber打开输入源 FFmpegFrameGrabber grabber new FFmpegFrameGrabber(inputPath); grabber.setOption(rtsp_transport, tcp); // 如果是 RTSP 流强制 TCP 避免丢包 grabber.setOption(stimeout, 5000000); // 5 秒超时单位微秒 grabber.start(); // 拿到音视频流的基本参数 int audioStreamIndex grabber.getAudioStream(); int videoStreamIndex grabber.getVideoStream(); double frameRate grabber.getVideoFrameRate(); // 视频帧率 int sampleRate grabber.getSampleRate(); // 音频采样率 int audioChannels grabber.getAudioChannels(); // 音频通道数 // 计算视频帧的理论间隔微秒 long videoFrameInterval (long) (1000000.0 / frameRate); // 打印流信息确认时间基 System.out.println(Video stream: videoStreamIndex , fps: frameRate , timebase: grabber.getVideoStreamTimebase()); System.out.println(Audio stream: audioStreamIndex , sampleRate: sampleRate , channels: audioChannels);这段代码里几个参数值得展开说。rtsp_transport设成tcp是为了避免 UDP 丢包导致的时间戳跳变如果你播的是本地文件可以去掉。stimeout是 socket 超时单位是微秒设太小会在网络抖动时误断设太大又会在流断开时卡住5 秒是个折中值。getVideoStreamTimebase()返回的是AVRational你需要用它把 pts 从流时间基转换到微秒pts_us pts * timebase.num * 1000000 / timebase.den。JavaCV 的Frame.timestamp已经帮你做了这个转换但如果你直接操作AVFrame就得自己算。还有一个容易忽略的点音频帧的frame.samples长度和采样率决定了这一帧覆盖的时间长度。比如 44100Hz 采样率、1024 个采样点的一帧覆盖时间是1024 / 44100 ≈ 23.2ms。这个值在更新音频时钟时要用到。3. 音频为主时钟的同步实现从队列到丢帧策略3.1 双线程加阻塞队列的骨架搭建同步播放器的基本结构是一个 grab 线程负责从FFmpegFrameGrabber里不断读帧按类型分别塞进音频队列和视频队列一个音频播放线程从音频队列取帧写到SourceDataLine播放同时更新音频时钟一个视频渲染线程从视频队列取帧根据音频时钟决定是等待、立即显示还是丢弃。队列的选择上我一般用ArrayBlockingQueue容量设 30 到 50 帧。容量太小会在解码抖动时断流太大则会导致 seek 时延迟高、内存占用大。音频队列和视频队列分开因为音频帧的消费速度是恒定的由采样率决定视频帧的消费速度取决于显示刷新率和同步策略。// 音频队列和视频队列容量 50 帧 BlockingQueueFrame audioQueue new ArrayBlockingQueue(50); BlockingQueueFrame videoQueue new ArrayBlockingQueue(50); // 音频时钟单位微秒用 volatile 保证可见性 volatile long audioClock 0; volatile boolean playing true; // grab 线程持续读帧并分发到两个队列 Thread grabThread new Thread(() - { try { Frame frame; while (playing (frame grabber.grab()) ! null) { if (frame.streamIndex grabber.getAudioStream()) { audioQueue.put(frame); // 队列满时阻塞形成背压 } else if (frame.streamIndex grabber.getVideoStream()) { videoQueue.put(frame); } } } catch (Exception e) { e.printStackTrace(); } }); grabThread.start();这里有个细节grabber.grab()返回的Frame对象在下次 grab 时会被复用所以你不能直接把引用塞进队列必须做深拷贝。音频帧要拷贝samples数组视频帧要拷贝image数据。这是 JavaCV 新手最容易踩的坑之一不拷贝的话队列里所有帧都会变成最后一帧的内容。3.2 音频时钟的更新与视频帧的等待/丢帧判断音频播放线程的核心逻辑是从队列取一帧写进SourceDataLine然后更新audioClock。SourceDataLine.write()是阻塞的它返回时数据已经进了声卡缓冲区但还没播完。所以audioClock的准确更新方式是在 write 之前记录当前时钟write 之后加上这一帧的时长。// 音频播放线程 Thread audioThread new Thread(() - { try { // 假设 SourceDataLine 已经按 sampleRate/channels 初始化好 while (playing) { Frame audioFrame audioQueue.poll(100, TimeUnit.MILLISECONDS); if (audioFrame null) continue; // 计算这一帧覆盖的时长微秒 int sampleCount audioFrame.samples.length 0 ? audioFrame.samples[0].limit() : 0; long frameDuration (long) (sampleCount * 1000000L / sampleRate); // 写入声卡 for (int i 0; i audioFrame.samples.length; i) { byte[] bytes new byte[audioFrame.samples[i].remaining()]; audioFrame.samples[i].get(bytes); sourceDataLine.write(bytes, 0, bytes.length); } // 更新音频时钟当前帧 pts 帧时长 audioClock audioFrame.timestamp frameDuration; } } catch (Exception e) { e.printStackTrace(); } }); audioThread.start();视频渲染线程的判断逻辑是拿到一帧后计算diff videoFrame.timestamp - audioClock。如果diff 0说明视频帧还没到显示时间线程 sleepdiff微秒如果diff -thresholdthreshold 一般设 40ms 到 100ms说明视频已经落后太多直接丢弃这一帧否则立即显示。// 视频渲染线程 Thread videoThread new Thread(() - { try { while (playing) { Frame videoFrame videoQueue.poll(100, TimeUnit.MILLISECONDS); if (videoFrame null) continue; long diff videoFrame.timestamp - audioClock; if (diff 0) { // 视频超前等待 Thread.sleep(diff / 1000); } else if (diff -100000) { // 视频落后超过 100ms丢帧 continue; } // 显示帧这里用 Swing 的 JPanel 举例 panel.setImage(videoFrame.image); panel.repaint(); } } catch (Exception e) { e.printStackTrace(); } }); videoThread.start();丢帧阈值-100000微秒100ms是个经验值。设太小会导致正常抖动时频繁丢帧画面闪烁设太大则会让延迟累积音画不同步感明显。如果你的场景对画面流畅度要求高可以放宽到 150ms如果对同步精度要求高收紧到 50ms但要配合更好的解码性能。3.3 音频重采样与缓冲区大小的参数调优SourceDataLine的缓冲区大小直接影响音频延迟和时钟精度。缓冲区越大声卡能缓存的音频越多时钟更新就越滞后缓冲区越小越容易 underrun声卡取不到数据导致爆音。我一般用sampleRate * channels * 2 * 0.1来估算即 100ms 的缓冲。比如 44100Hz 立体声 16bit就是44100 * 2 * 2 * 0.1 17640字节。// 初始化 SourceDataLine AudioFormat format new AudioFormat(sampleRate, 16, audioChannels, true, false); DataLine.Info info new DataLine.Info(SourceDataLine.class, format); SourceDataLine line (SourceDataLine) AudioSystem.getLine(info); // 缓冲区设为 100ms 的音频数据量 int bufferSize (int) (sampleRate * audioChannels * 2 * 0.1); line.open(format, bufferSize); line.start();如果源音频的采样率和声卡不支持的一致你需要做重采样。JavaCV 提供了FFmpegFrameFilter和SwrContext两种方式。FFmpegFrameFilter用起来简单但性能不如直接调SwrContext。我一般用FFmpegFrameFilter做快速原型生产环境换成SwrContext。// 用 FFmpegFrameFilter 做音频重采样 FFmpegFrameFilter audioFilter new FFmpegFrameFilter( aresample44100, // 重采样到 44100Hz audioChannels, sampleRate, audioChannels, 44100 ); audioFilter.start(); // 在音频线程里写声卡之前先过 filter Frame resampled audioFilter.pull(audioFrame);aresample的参数除了采样率还可以指定重采样算法比如aresample44100:resamplersoxr用 SoXR 算法质量更好但 CPU 占用更高。默认的 swr 算法在大多数场景下够用。4. 音视频同步播放的避坑与排查4.1 现象画面越播越慢声音正常原因通常是视频渲染线程里用了Thread.sleep(diff / 1000)但diff是微秒除以 1000 得到毫秒如果diff是负数视频落后sleep会抛IllegalArgumentException被 catch 吞掉然后循环继续视频帧被快速消费但显示速度没跟上。解决方法是判断diff 0才 sleep负数走丢帧逻辑。另一个可能原因是audioClock更新时用了audioFrame.timestamp而不是audioFrame.timestamp frameDuration导致时钟始终比实际播放进度慢一个帧时长视频线程以为音频还没播到那里就一直等。4.2 现象声音断断续续有爆音先检查SourceDataLine的缓冲区是否太小。如果bufferSize小于一帧音频的数据量write 会频繁阻塞声卡取不到数据就 underrun。把缓冲区调到至少 50ms 的数据量。如果还不行检查音频队列是否经常为空——grab 线程解码速度跟不上播放速度。这时候要么加大队列容量要么降低视频解码优先级让音频解码先跑。还有一种情况是音频帧的samples数组里有多个Buffer多通道你只写了第一个通道的数据。要遍历所有samples依次写入。4.3 现象seek 之后音画完全错位seek 时FFmpegFrameGrabber会调av_seek_frame但音频和视频的 seek 目标位置可能不一致导致两路的时间戳基准不同。解决方法是在 seek 之后清空两个队列重置audioClock为 seek 目标时间然后重新开始 grab。如果用的是grabber.setTimestamp()注意它接受的是微秒而且 seek 后第一帧的 timestamp 可能不等于你设的值要以实际拿到的第一帧 timestamp 为准来重置时钟。4.4 现象播放几分钟后音画漂移越来越大这是典型的时钟漂移问题。音频时钟基于声卡的播放进度但声卡的晶振和系统时钟有微小频差播久了就会累积。解决方法是定期用系统时钟校准音频时钟每隔几秒比较audioClock和System.nanoTime() / 1000 - startTime如果偏差超过 50ms就微调音频时钟。但不要直接跳变否则声音会卡顿要用渐进的方式修正比如每次调整 1ms。4.5 现象JavaCV 报 “avcodec_send_packet() error” 或 “Invalid data found”先确认 FFmpeg 的版本和 JavaCV 的版本匹配。JavaCV 的ffmpeg-platform依赖会自动下载对应平台的 FFmpeg 动态库但如果你手动指定了ffmpeg依赖而没指定平台就会加载失败。检查javacv-platform的版本确保它包含了你操作系统对应的ffmpeg-version-platform.jar。另外如果输入流的编码格式是 H.265 而你的 FFmpeg 编译时没开libx265也会报这个错。用FFmpegFrameGrabber.getFormatContext().iformat().name()确认容器格式用grabber.getVideoCodecName()确认编码器。5. 用 PTS 差值做动态丢帧与音频时钟校准的进阶技巧前面讲的丢帧策略是固定阈值实际场景里网络抖动和 CPU 负载波动会让固定阈值要么太激进要么太保守。我后来改成动态阈值维护一个最近 30 帧的 PTS 差值滑动窗口计算平均值和标准差丢帧阈值设为平均值 - 2 * 标准差。这样在解码稳定时阈值收紧保证同步精度在抖动时阈值放宽避免频繁丢帧导致画面闪烁。// 动态丢帧阈值基于最近 30 帧的 PTS 差值统计 private final double[] diffWindow new double[30]; private int diffIndex 0; private int diffCount 0; private long computeDynamicThreshold(long currentDiff) { diffWindow[diffIndex] currentDiff; diffIndex (diffIndex 1) % diffWindow.length; diffCount Math.min(diffCount 1, diffWindow.length); if (diffCount 10) return -100000; // 样本不足时用固定阈值 double sum 0, sumSq 0; for (int i 0; i diffCount; i) { sum diffWindow[i]; sumSq diffWindow[i] * diffWindow[i]; } double mean sum / diffCount; double std Math.sqrt(sumSq / diffCount - mean * mean); // 阈值 均值 - 2 倍标准差且不低于 -150ms return (long) Math.max(mean - 2 * std, -150000); }音频时钟校准也是类似思路。我每隔 5 秒做一次校准计算audioClock和系统时钟的偏差drift。如果|drift| 50ms就在接下来的 1 秒内分 100 次把audioClock调整到位每次调整drift / 100。这样声音听起来是平滑的不会有跳变感。// 音频时钟渐进校准 private volatile long clockCorrection 0; // 待校准的偏差 private static final int CORRECTION_STEPS 100; // 在校准线程里 long drift audioClock - (System.nanoTime() / 1000 - playbackStartTime); if (Math.abs(drift) 50000) { clockCorrection drift; } // 在音频线程更新时钟时 if (clockCorrection ! 0) { long step clockCorrection / CORRECTION_STEPS; audioClock step; clockCorrection - step; }还有一个技巧是用AVFrame的pkt_dts而不是pts来做同步判断。在 B 帧存在的情况下pts是显示顺序dts是解码顺序如果你用pts做队列排序B 帧会乱序。JavaCV 的Frame.timestamp默认取的是pts但FFmpegFrameGrabber在解码时已经帮你处理了 B 帧重排所以队列里的帧顺序是正确的。如果你直接操作AVFrame记得用av_frame_get_best_effort_timestamp来获取可靠的显示时间戳。最后说一个我自己的习惯每次调同步参数我都会用ffprobe先看一眼源文件的音视频起始 PTS 是否对齐。有些文件音频从 0 开始、视频从 0.5 秒开始这种文件你不管怎么调同步策略开头半秒都是黑屏加声音。遇到这种情况在初始化时把audioClock的起始值设为视频第一帧的 PTS而不是 0。这个坑我踩过不止一次希望帮到你。本文还有配套的精品资源点击获取 JavaCV+FFmpeg音视频同步播放：音频为主时钟策略与丢帧调优实战
简介这份PDF资料面向具备一定Java基础、希望掌握音视频同步播放的开发者围绕Javacv调用ffmpeg展开重点解决音视频帧捕获后如何同步播放的问题。内容以FFmpegFrameGrabber帧捕捉器为核心讲解视频帧经Java2DFrameConverter转为BufferedImage显示、音频帧通过sourceDataLine写入扬声器并采用生产者消费者模式缓冲帧数据缓解捕获速度大于消耗速度的矛盾。同步方案采用视频向音频对齐借助音频帧时间戳驱动视频线程延时播放同时针对Thread.sleep不精确、声卡缓冲易耗尽等问题给出动态调节延时与依据available()判断数据量的优化思路。资源包为1个PDF文件大小约178KB篇幅精炼适合作为音视频同步入门与排错参考。目前已有3281人学习可帮助读者快速理解同步播放的整体流程与关键实现细节。1. JavaCV 配 FFmpeg 做音视频同步播放为什么你播出来的画面总比声音慢半拍用 JavaCV 调 FFmpeg 做播放器最容易翻车的不是解码失败而是音视频各播各的——画面越播越慢声音早就跑前面去了或者反过来声音断断续续像卡带。这个问题的本质不是 JavaCV 的锅也不是 FFmpeg 的锅而是你没有建立一套统一的时钟基准来驱动两路数据。JavaCV 在这里的角色是 FFmpeg 的 Java 封装层它把AVFormatContext、AVCodecContext、AVFrame这些 C 结构体映射成 Java 对象让你能在 JVM 里直接调avcodec_send_packet和avcodec_receive_frame。但封装层不会替你做同步决策时间戳怎么对齐、谁等谁、丢帧还是补帧全得自己写。这篇文章面向的是已经能用 JavaCV 解出画面和声音、但播放时音画不同步的开发者我会把同步策略的选择依据、具体实现步骤、参数怎么调、以及我踩过的坑一条条讲清楚。读完你至少能搭出一个音视频偏差控制在 40ms 以内的播放器骨架。2. JavaCV 解码链路与音视频同步的时钟选型2.1 JavaCV 里 FFmpeg 解码的基本数据流JavaCV 的FFmpegFrameGrabber封装了从打开文件到解码出Frame的完整流程。它的内部逻辑是avformat_open_input打开容器 →avformat_find_stream_info探测流信息 → 分别对音频流和视频流调avcodec_open2打开解码器 → 在grab()里循环调av_read_frame读包再按 stream_index 分发到对应的解码器。你拿到的Frame对象里视频帧是BufferedImage音频帧是Buffer[]采样数据而时间信息藏在frame.timestamp里单位是微秒。关键点在于FFmpegFrameGrabber默认是单线程顺序 grab 的它按容器里包的物理顺序返回帧。如果你直接在一个循环里 grab 一帧视频就画一帧、grab 一帧音频就写一帧那播放速度完全取决于解码速度跟真实时间没关系。这就是为什么很多人第一次写出来的播放器要么快进要么慢放——它根本没有时钟概念。要做同步你得把 grab 和解耦成两个独立线程各自维护队列然后用一个统一的时钟来决定什么时候消费队列里的帧。这个时钟可以是系统时钟、音频时钟或视频时钟选哪个直接决定了同步策略的复杂度和最终效果。2.2 三种同步策略的取舍音频为主、视频为主、外部时钟音频为主的策略是以音频播放的进度作为主时钟视频帧根据音频时钟来调整显示时间。人耳对音频的断续和变速极其敏感对视频帧的微小延迟反而容忍度高。所以业界绝大多数播放器包括 FFplay 默认模式都选音频为主时钟。具体做法是音频线程每播放完一个采样块就更新当前音频时钟audio_clock pts 已播放时长视频线程拿到一帧后比较自己的 pts 和当前音频时钟如果视频快了就等慢了就丢帧或加速。视频为主的策略反过来以视频帧的显示时间为主时钟音频通过重采样或丢采样来追赶。这种策略在视频会议里常见因为画面卡顿比声音卡顿更不可接受。但在点播播放场景里音频变速会带来明显的音调变化体验很差所以不推荐。外部时钟策略是维护一个独立的系统时钟音频和视频都向它对齐。这种方案实现最简单但精度最差因为系统时钟和媒体时钟之间会有漂移播久了必然不同步。除非你的场景对同步要求极低比如只是预览否则不要用。我一般会选音频为主时钟配合视频帧的丢帧/等待策略。下面这张表是我在实际项目里总结的三种策略对比策略主时钟来源音频处理视频处理适用场景同步精度音频为主音频播放进度正常播放等待或丢帧点播、本地播放±20ms视频为主视频显示时间重采样或丢采样正常显示视频会议、直播±40ms外部时钟系统纳秒时钟向系统时钟对齐向系统时钟对齐预览、低要求场景±100ms选音频为主之后还有一个参数要定音频时钟的更新粒度。如果你每播放一个采样点就更新一次时钟那锁竞争会很频繁如果每播放一个音频缓冲区才更新那视频线程拿到的时钟会有缓冲区大小的延迟。常见做法是每播放完一个AVFrame的音频数据后更新一次时钟同时在计算时把当前缓冲区已播放的偏移量加进去。2.3 用 JavaCV 打开流并拿到音视频时间戳在写同步逻辑之前先得确认你能正确拿到每一路的时间戳。JavaCV 的Frame.timestamp在解码后可能是AV_NOPTS_VALUE这时候你需要用frame.opaque里的AVFrame原始指针去读pts或者退而求其次用grabber.getTimestamp()。下面这段代码是我常用的初始化方式// 初始化 FFmpegFrameGrabber打开输入源 FFmpegFrameGrabber grabber new FFmpegFrameGrabber(inputPath); grabber.setOption(rtsp_transport, tcp); // 如果是 RTSP 流强制 TCP 避免丢包 grabber.setOption(stimeout, 5000000); // 5 秒超时单位微秒 grabber.start(); // 拿到音视频流的基本参数 int audioStreamIndex grabber.getAudioStream(); int videoStreamIndex grabber.getVideoStream(); double frameRate grabber.getVideoFrameRate(); // 视频帧率 int sampleRate grabber.getSampleRate(); // 音频采样率 int audioChannels grabber.getAudioChannels(); // 音频通道数 // 计算视频帧的理论间隔微秒 long videoFrameInterval (long) (1000000.0 / frameRate); // 打印流信息确认时间基 System.out.println(Video stream: videoStreamIndex , fps: frameRate , timebase: grabber.getVideoStreamTimebase()); System.out.println(Audio stream: audioStreamIndex , sampleRate: sampleRate , channels: audioChannels);这段代码里几个参数值得展开说。rtsp_transport设成tcp是为了避免 UDP 丢包导致的时间戳跳变如果你播的是本地文件可以去掉。stimeout是 socket 超时单位是微秒设太小会在网络抖动时误断设太大又会在流断开时卡住5 秒是个折中值。getVideoStreamTimebase()返回的是AVRational你需要用它把 pts 从流时间基转换到微秒pts_us pts * timebase.num * 1000000 / timebase.den。JavaCV 的Frame.timestamp已经帮你做了这个转换但如果你直接操作AVFrame就得自己算。还有一个容易忽略的点音频帧的frame.samples长度和采样率决定了这一帧覆盖的时间长度。比如 44100Hz 采样率、1024 个采样点的一帧覆盖时间是1024 / 44100 ≈ 23.2ms。这个值在更新音频时钟时要用到。3. 音频为主时钟的同步实现从队列到丢帧策略3.1 双线程加阻塞队列的骨架搭建同步播放器的基本结构是一个 grab 线程负责从FFmpegFrameGrabber里不断读帧按类型分别塞进音频队列和视频队列一个音频播放线程从音频队列取帧写到SourceDataLine播放同时更新音频时钟一个视频渲染线程从视频队列取帧根据音频时钟决定是等待、立即显示还是丢弃。队列的选择上我一般用ArrayBlockingQueue容量设 30 到 50 帧。容量太小会在解码抖动时断流太大则会导致 seek 时延迟高、内存占用大。音频队列和视频队列分开因为音频帧的消费速度是恒定的由采样率决定视频帧的消费速度取决于显示刷新率和同步策略。// 音频队列和视频队列容量 50 帧 BlockingQueueFrame audioQueue new ArrayBlockingQueue(50); BlockingQueueFrame videoQueue new ArrayBlockingQueue(50); // 音频时钟单位微秒用 volatile 保证可见性 volatile long audioClock 0; volatile boolean playing true; // grab 线程持续读帧并分发到两个队列 Thread grabThread new Thread(() - { try { Frame frame; while (playing (frame grabber.grab()) ! null) { if (frame.streamIndex grabber.getAudioStream()) { audioQueue.put(frame); // 队列满时阻塞形成背压 } else if (frame.streamIndex grabber.getVideoStream()) { videoQueue.put(frame); } } } catch (Exception e) { e.printStackTrace(); } }); grabThread.start();这里有个细节grabber.grab()返回的Frame对象在下次 grab 时会被复用所以你不能直接把引用塞进队列必须做深拷贝。音频帧要拷贝samples数组视频帧要拷贝image数据。这是 JavaCV 新手最容易踩的坑之一不拷贝的话队列里所有帧都会变成最后一帧的内容。3.2 音频时钟的更新与视频帧的等待/丢帧判断音频播放线程的核心逻辑是从队列取一帧写进SourceDataLine然后更新audioClock。SourceDataLine.write()是阻塞的它返回时数据已经进了声卡缓冲区但还没播完。所以audioClock的准确更新方式是在 write 之前记录当前时钟write 之后加上这一帧的时长。// 音频播放线程 Thread audioThread new Thread(() - { try { // 假设 SourceDataLine 已经按 sampleRate/channels 初始化好 while (playing) { Frame audioFrame audioQueue.poll(100, TimeUnit.MILLISECONDS); if (audioFrame null) continue; // 计算这一帧覆盖的时长微秒 int sampleCount audioFrame.samples.length 0 ? audioFrame.samples[0].limit() : 0; long frameDuration (long) (sampleCount * 1000000L / sampleRate); // 写入声卡 for (int i 0; i audioFrame.samples.length; i) { byte[] bytes new byte[audioFrame.samples[i].remaining()]; audioFrame.samples[i].get(bytes); sourceDataLine.write(bytes, 0, bytes.length); } // 更新音频时钟当前帧 pts 帧时长 audioClock audioFrame.timestamp frameDuration; } } catch (Exception e) { e.printStackTrace(); } }); audioThread.start();视频渲染线程的判断逻辑是拿到一帧后计算diff videoFrame.timestamp - audioClock。如果diff 0说明视频帧还没到显示时间线程 sleepdiff微秒如果diff -thresholdthreshold 一般设 40ms 到 100ms说明视频已经落后太多直接丢弃这一帧否则立即显示。// 视频渲染线程 Thread videoThread new Thread(() - { try { while (playing) { Frame videoFrame videoQueue.poll(100, TimeUnit.MILLISECONDS); if (videoFrame null) continue; long diff videoFrame.timestamp - audioClock; if (diff 0) { // 视频超前等待 Thread.sleep(diff / 1000); } else if (diff -100000) { // 视频落后超过 100ms丢帧 continue; } // 显示帧这里用 Swing 的 JPanel 举例 panel.setImage(videoFrame.image); panel.repaint(); } } catch (Exception e) { e.printStackTrace(); } }); videoThread.start();丢帧阈值-100000微秒100ms是个经验值。设太小会导致正常抖动时频繁丢帧画面闪烁设太大则会让延迟累积音画不同步感明显。如果你的场景对画面流畅度要求高可以放宽到 150ms如果对同步精度要求高收紧到 50ms但要配合更好的解码性能。3.3 音频重采样与缓冲区大小的参数调优SourceDataLine的缓冲区大小直接影响音频延迟和时钟精度。缓冲区越大声卡能缓存的音频越多时钟更新就越滞后缓冲区越小越容易 underrun声卡取不到数据导致爆音。我一般用sampleRate * channels * 2 * 0.1来估算即 100ms 的缓冲。比如 44100Hz 立体声 16bit就是44100 * 2 * 2 * 0.1 17640字节。// 初始化 SourceDataLine AudioFormat format new AudioFormat(sampleRate, 16, audioChannels, true, false); DataLine.Info info new DataLine.Info(SourceDataLine.class, format); SourceDataLine line (SourceDataLine) AudioSystem.getLine(info); // 缓冲区设为 100ms 的音频数据量 int bufferSize (int) (sampleRate * audioChannels * 2 * 0.1); line.open(format, bufferSize); line.start();如果源音频的采样率和声卡不支持的一致你需要做重采样。JavaCV 提供了FFmpegFrameFilter和SwrContext两种方式。FFmpegFrameFilter用起来简单但性能不如直接调SwrContext。我一般用FFmpegFrameFilter做快速原型生产环境换成SwrContext。// 用 FFmpegFrameFilter 做音频重采样 FFmpegFrameFilter audioFilter new FFmpegFrameFilter( aresample44100, // 重采样到 44100Hz audioChannels, sampleRate, audioChannels, 44100 ); audioFilter.start(); // 在音频线程里写声卡之前先过 filter Frame resampled audioFilter.pull(audioFrame);aresample的参数除了采样率还可以指定重采样算法比如aresample44100:resamplersoxr用 SoXR 算法质量更好但 CPU 占用更高。默认的 swr 算法在大多数场景下够用。4. 音视频同步播放的避坑与排查4.1 现象画面越播越慢声音正常原因通常是视频渲染线程里用了Thread.sleep(diff / 1000)但diff是微秒除以 1000 得到毫秒如果diff是负数视频落后sleep会抛IllegalArgumentException被 catch 吞掉然后循环继续视频帧被快速消费但显示速度没跟上。解决方法是判断diff 0才 sleep负数走丢帧逻辑。另一个可能原因是audioClock更新时用了audioFrame.timestamp而不是audioFrame.timestamp frameDuration导致时钟始终比实际播放进度慢一个帧时长视频线程以为音频还没播到那里就一直等。4.2 现象声音断断续续有爆音先检查SourceDataLine的缓冲区是否太小。如果bufferSize小于一帧音频的数据量write 会频繁阻塞声卡取不到数据就 underrun。把缓冲区调到至少 50ms 的数据量。如果还不行检查音频队列是否经常为空——grab 线程解码速度跟不上播放速度。这时候要么加大队列容量要么降低视频解码优先级让音频解码先跑。还有一种情况是音频帧的samples数组里有多个Buffer多通道你只写了第一个通道的数据。要遍历所有samples依次写入。4.3 现象seek 之后音画完全错位seek 时FFmpegFrameGrabber会调av_seek_frame但音频和视频的 seek 目标位置可能不一致导致两路的时间戳基准不同。解决方法是在 seek 之后清空两个队列重置audioClock为 seek 目标时间然后重新开始 grab。如果用的是grabber.setTimestamp()注意它接受的是微秒而且 seek 后第一帧的 timestamp 可能不等于你设的值要以实际拿到的第一帧 timestamp 为准来重置时钟。4.4 现象播放几分钟后音画漂移越来越大这是典型的时钟漂移问题。音频时钟基于声卡的播放进度但声卡的晶振和系统时钟有微小频差播久了就会累积。解决方法是定期用系统时钟校准音频时钟每隔几秒比较audioClock和System.nanoTime() / 1000 - startTime如果偏差超过 50ms就微调音频时钟。但不要直接跳变否则声音会卡顿要用渐进的方式修正比如每次调整 1ms。4.5 现象JavaCV 报 “avcodec_send_packet() error” 或 “Invalid data found”先确认 FFmpeg 的版本和 JavaCV 的版本匹配。JavaCV 的ffmpeg-platform依赖会自动下载对应平台的 FFmpeg 动态库但如果你手动指定了ffmpeg依赖而没指定平台就会加载失败。检查javacv-platform的版本确保它包含了你操作系统对应的ffmpeg-version-platform.jar。另外如果输入流的编码格式是 H.265 而你的 FFmpeg 编译时没开libx265也会报这个错。用FFmpegFrameGrabber.getFormatContext().iformat().name()确认容器格式用grabber.getVideoCodecName()确认编码器。5. 用 PTS 差值做动态丢帧与音频时钟校准的进阶技巧前面讲的丢帧策略是固定阈值实际场景里网络抖动和 CPU 负载波动会让固定阈值要么太激进要么太保守。我后来改成动态阈值维护一个最近 30 帧的 PTS 差值滑动窗口计算平均值和标准差丢帧阈值设为平均值 - 2 * 标准差。这样在解码稳定时阈值收紧保证同步精度在抖动时阈值放宽避免频繁丢帧导致画面闪烁。// 动态丢帧阈值基于最近 30 帧的 PTS 差值统计 private final double[] diffWindow new double[30]; private int diffIndex 0; private int diffCount 0; private long computeDynamicThreshold(long currentDiff) { diffWindow[diffIndex] currentDiff; diffIndex (diffIndex 1) % diffWindow.length; diffCount Math.min(diffCount 1, diffWindow.length); if (diffCount 10) return -100000; // 样本不足时用固定阈值 double sum 0, sumSq 0; for (int i 0; i diffCount; i) { sum diffWindow[i]; sumSq diffWindow[i] * diffWindow[i]; } double mean sum / diffCount; double std Math.sqrt(sumSq / diffCount - mean * mean); // 阈值 均值 - 2 倍标准差且不低于 -150ms return (long) Math.max(mean - 2 * std, -150000); }音频时钟校准也是类似思路。我每隔 5 秒做一次校准计算audioClock和系统时钟的偏差drift。如果|drift| 50ms就在接下来的 1 秒内分 100 次把audioClock调整到位每次调整drift / 100。这样声音听起来是平滑的不会有跳变感。// 音频时钟渐进校准 private volatile long clockCorrection 0; // 待校准的偏差 private static final int CORRECTION_STEPS 100; // 在校准线程里 long drift audioClock - (System.nanoTime() / 1000 - playbackStartTime); if (Math.abs(drift) 50000) { clockCorrection drift; } // 在音频线程更新时钟时 if (clockCorrection ! 0) { long step clockCorrection / CORRECTION_STEPS; audioClock step; clockCorrection - step; }还有一个技巧是用AVFrame的pkt_dts而不是pts来做同步判断。在 B 帧存在的情况下pts是显示顺序dts是解码顺序如果你用pts做队列排序B 帧会乱序。JavaCV 的Frame.timestamp默认取的是pts但FFmpegFrameGrabber在解码时已经帮你处理了 B 帧重排所以队列里的帧顺序是正确的。如果你直接操作AVFrame记得用av_frame_get_best_effort_timestamp来获取可靠的显示时间戳。最后说一个我自己的习惯每次调同步参数我都会用ffprobe先看一眼源文件的音视频起始 PTS 是否对齐。有些文件音频从 0 开始、视频从 0.5 秒开始这种文件你不管怎么调同步策略开头半秒都是黑屏加声音。遇到这种情况在初始化时把audioClock的起始值设为视频第一帧的 PTS而不是 0。这个坑我踩过不止一次希望帮到你。本文还有配套的精品资源点击获取