wushakun的博客

在音视频处理流程中，的有两种队列，包缓存队列（Packet Buffer Queue）和帧缓存队列（Frame Buffer Queue）。这两个队列的存在，是为了适应音视频数据处理过程中的多线程架构——包括收包线程、解码线程和渲染线程。具体来说，收包线程负责从网络或文件中读取数据并将其放入包缓存队列中；解码线程从包缓存队列中取出数据进行解码，然后将解码后的数据放入帧缓存队列中；最后，渲染线程从帧缓存队列中取出数据进行渲染。由于每个线程的处理速度不同，缓存队列在这一过程中起到了平衡各线程工作负荷和避免数据丢

在多媒体的世界里，播放器是离用户最近的一环，它将数字编码的音频和视频数据转化为生动的视听体验。ffplay 播放器作为一款强大而备受关注的工具，其背后隐藏着一系列精妙的结构体，它们协同工作，共同完成了从数据读取、解码、渲染到最终呈现的复杂流程。以下是播放器的一个简单的流程，当我们启动 ffplay 播放器，它首先会与数据源建立连接，无论是本地文件、网络流还是其他输入源。。紧接着，数据被源源不断地送入解码器，将压缩编码的数据转换为可处理的原始格式。在这一流程中，各种关键的结构体开始发挥作用。

这个接口虽然看起来只有暂停的功能，实际上它负责暂停和继续状态的转换，上一次如果是暂停，这一次就继续，反之亦然。当然，如果用户想知道目前是开始还是暂停的状态，可以通过监听开始和暂停的状态来实现，不用自己再去记录状态。以上就是ffplay的播放控制的流程，用户操作主要是改变播放器的状态，然后收包线程和渲染线程根据状态做响应的处理即可，还是比较容易理解的。按字节跳转一般用于特定的格式，比如ts流，每一个包都是188字节，解析器按这种方式处理可以很方便的跳到目标位置。简单来说就是开始、结束、暂停、继续、跳转。

在ffplay中，音视频的输出有自己的线程。比如一个没有声音的视频，或者刚播放的只有音频没有视频，视频比较晚到，那前面的音频也可以先丢弃。这三种是最基本的策略，考虑到人对声音的敏感度要强于视频，一般情况下我们会采取视频去同步音频的策略。所以最开始的时候的计算方式应该是2s-1.5s，结果是0.5s，和t3时刻计算的结果是一致的。音频同理，音频的pts假设是1.5s，设置时时刻t1假设是1001s（实际是一个很大的值），设置的时候，视频的pts假设是1s，t1假设是1000s（实际是一个很大的值），

在数字化时代，多媒体播放器已成为我们日常生活中不可或缺的一部分。无论是观看电影、听取音乐，抑或是进行视频会议，我们都依赖于功能强大的播放器来呈现丰富多彩的音视频内容。而在众多播放器中，FFplay以其简洁而强大的特性脱颖而出。作为FFmpeg多媒体框架的一部分，FFplay不仅提供了丰富的音视频格式支持，更以其开源、跨平台的特性备受开发者青睐。在音视频相关的面试中，ffplay中的一些代码甚至被认为是标准的解决方案。