1.零基础读懂视频播放器控制原理： ffplay 播放器源代码分析
2.FFmpeg源码分析: AVStream码流
3.FFmpeg源码分析：视频滤镜介绍(上)
4.SRS4.0源代码分析之WebRTC服务总体介绍
5.音频数据的音频源码音频源码建模全流程代码示例：通过讲话人的声音进行年龄预测
6.深入剖析-ijkplayer框架音视频开发

零基础读懂视频播放器控制原理： ffplay 播放器源代码分析

       视频播放器的核心原理在于控制音视频帧序列，其中ffplay作为FFmpeg自带的分析分析播放器，利用ffmpeg解码库和sdl库进行视频渲染。音频源码音频源码本文将通过分析ffplay源代码，分析分析深入解析音视频同步、音频源码音频源码播放控制的分析分析街机提取源码原理。

       FFmpeg的音频源码音频源码跨平台特性使得在PC端分析代码更为高效，本文则主要聚焦于ffplay for MFC的分析分析移植代码。首先，音频源码音频源码理解视频文件结构，分析分析每个MP4文件包含封装格式、音频源码音频源码比特率等信息，分析分析音视频被区分为独立的音频源码音频源码stream，并有各自的分析分析参数。解复用后，音频源码音频源码音频和视频帧转化为原始数据，进入播放流程，如图2所示。

       简化播放器，仅考虑视频解码和SDL显示，其流程图显示了FFmpeg初始化、读取并解码帧、然后渲染到窗口的过程。为了实现音视频同步，播放器需要处理帧率、音频采样率和视频帧显示时间的关系，以及不同流的帧数差异。

       文章接下来提出五个关键问题，涉及画面、字幕和声音的组合，音视频同步的具体机制，以及快进/后退操作的实现。ffplay通过定义VideoState结构体，将播放控制分发到不同线程，利用PTS时间戳确保音视频同步。视频播放器操作的实现包括控制暂停和播放，以及通过时间而非帧数进行快进/后退，以保持同步。

       分析ffplay代码时，整体结构包括定时器刷新、多线程解码和显示，以及关键控制函数的哔嘀影视源码接口使用。在深入理解PTS和DTS后，我们看到ffplay如何动态调整PTS以实现音视频同步。最后，文章总结了通过ffplay源码学习到的基础概念和实用技巧，强调了从基础开始理解、代码架构分析和平台选择的重要性。

FFmpeg源码分析: AVStream码流

       在AVCodecContext结构体中，AVStream数组存储着所有视频、音频和字幕流的信息。每个码流包含时间基、时长、索引数组、编解码器参数、dts和元数据。索引数组用于保存帧数据包的offset、size、timestamp和flag，方便进行seek定位。

       让我们通过ffprobe查看mp4文件的码流信息。该文件包含5个码流，是双音轨双字幕文件。第一个是video，编码为h，帧率为.fps，分辨率为x，像素格式为yuvp。第二个和第三个都是audio，编码为aac，采样率为，立体声，语言分别为印地语和英语。第四个和第五个都是subtitle，语言为英语，编码器为mov_text和mov_text。

       调试实时数据显示，stream数组包含以下信息：codec_type（媒体类型）、codec_id、bit_rate、profile、level、width、柚子家政源码安装教程height、sample_rate、channels等编解码器参数。

       我们关注AVCodecContext的编解码器参数，例如codec_type、codec_id、bit_rate、profile、level、width、height、sample_rate和channels。具体参数如下：codec_type - 视频/音频/字幕；codec_id - 编码器ID；bit_rate - 位率；profile - 编码器配置文件；level - 编码器级别；width - 宽度；height - 高度；sample_rate - 采样率；channels - 音道数。

       AVStream内部的nb_index_entries（索引数组长度）和index_entries（索引数组）记录着offset、size、timestamp、flags和min_distance信息。在seek操作中，通过二分查找timestamp数组来定位指定时间戳对应的帧。seek模式有previous、next、nearest，通常使用previous模式向前查找。

       时间基time_base在ffmpeg中用于计算时间戳。在rational.h中，AVRational结构体定义为一个有理数，用于时间计算。要将时间戳转换为真实时间，只需将num分子除以den分母。

FFmpeg源码分析：视频滤镜介绍(上)

       FFmpeg在libavfilter模块提供了丰富的音视频滤镜功能。本文主要介绍FFmpeg的视频滤镜，包括黑色检测、视频叠加、色彩均衡、去除水印、抗抖动、矩形标注、九宫格等。

       黑色检测滤镜用于检测视频中的纯黑色间隔时间，输出日志和元数据。若检测到至少具有指定最小持续时间的简约学校官网源码黑色片段，则输出开始、结束时间戳与持续时间。该滤镜通过参数选项rs、gs、bs、rm、gm、bm、rh、gh、bh来调整红、绿、蓝阴影、基调与高亮区域的色彩平衡。

       视频叠加滤镜将两个视频的所有帧混合在一起，称为视频叠加。顶层视频覆盖底层视频，输出时长为最长的视频。实现代码位于libavfilter/vf_blend.c，通过遍历像素矩阵计算顶层像素与底层像素的混合值。

       色彩均衡滤镜调整视频帧的RGB分量占比，通过参数rs、gs、bs、rm、gm、bm、rh、gh、bh在阴影、基调与高亮区域进行色彩平衡调整。

       去除水印滤镜通过简单插值抑制水印，仅需设置覆盖水印的矩形。代码位于libavfilter/vf_delogo.c，核心是基于矩形外像素值计算插值像素值。

       矩形标注滤镜在视频画面中绘制矩形框，用于标注ROI兴趣区域。在人脸检测与人脸识别场景中，检测到人脸时会用矩形框进行标注。

       绘制x宫格滤镜用于绘制四宫格、九宫格，中枢画线指标公式源码模拟画面拼接或分割。此滤镜通过参数x、y、width、height、color、thickness来定义宫格的位置、大小、颜色与边框厚度。

       调整yuv或rgb滤镜通过计算查找表，绑定像素输入值到输出值，然后应用到输入视频，实现色彩、对比度等调整。相关代码位于vf_lut.c，支持四种类型：packed 8bits、packed bits、planar 8bits、planar bits。

       将彩色视频转换为黑白视频的滤镜设置U和V分量为，实现效果如黑白视频所示。

SRS4.0源代码分析之WebRTC服务总体介绍

       SRS4.0的WebRTC服务提供了一种强大的实时音视频通信解决方案，它基于Web标准，支持浏览器之间的双向通信。SRS4.0引入WebRTC的主要目的是为了增强服务器的SFU（服务器转发单元）功能，以优化客户端接入和降低音视频处理对服务器CPU的负担。通过部署SFU，客户端可以将本地音视频数据推送到服务器，同时服务器根据需要拉取数据，实现低延迟的直播连麦场景。

       WebRTC涉及的知识点广泛，包括SDP报文处理、ICE连接建立、DTLS加密等，但SRS4.0的重点在于简化用户对WebRTC的理解。SRS4.0 WebRTC服务的核心模块在`srs_app_rtc_server.cpp`中初始化，主要负责自签名证书生成、UDP端口监听（如）和推拉流API接口注册。RTMP与WebRTC的不同在于，WebRTC通过P2P/ICE技术建立UDP连接，而RTMP则通过socket复用控制命令和数据流。

       SRS4.0通过HTTP(S)接口提供对外API，如/rtc/v1/publish/和/rtc/v1/play/，用于接收和发送音视频数据。当客户端发起推流或拉流请求时，SRS会创建相应的对象（如SrsRtcPublishStream和SrsRtcPlayStream），并处理SDP交换和ICE连接建立。推流和拉流过程涉及SDP报文协商，ICE用于客户端和服务端建立数据传输通道，确保安全性和稳定性。

       最后，总结SRS4.0 WebRTC的处理流程：首先，监听端口并提供API接口；其次，根据API请求创建相应的数据流对象；接着，通过SDP和ICE建立连接；最后，音视频数据在服务器和客户端之间按此流程传递：客户端→服务器→SRS对象→客户端。理解这些核心流程有助于深入研究SRS4.0的WebRTC功能和实现机制。

音频数据的建模全流程代码示例：通过讲话人的声音进行年龄预测

       音频数据建模全流程详解：通过声纹预测年龄

       本文将引导你从音频数据的初始处理到特征提取、探索性分析和模型构建的全过程。首先，音频数据与图像和文本类似，需要转化为机器可理解的格式。

       音频数据呈现形式多样：波形表示信号在时间上的变化，而快速傅立叶变换和频谱图则揭示频率信息。梅尔频率倒谱系数（MFCC）是常用的表示方式，更接近人类感知。

       数据清洗阶段，通过可视化示例，理解背景噪声的差异，可利用noisereduce包降噪，trim()函数用于修剪音频。

       特征提取是关键，包括检测开始点、录音长度、节奏和基频（音高）等，用于分析说话者的特征。

       通过对Common Voice数据集进行EDA，包括性别和年龄分布分析、特征值分布和相关性，发现性别对f0特征有显著影响，年龄与大多数特征关联度低。

       模型选择阶段，本文采用经典机器学习方法，如LogisticRegression，结合GridSearchCV进行参数调整，评估模型性能。

       通过以上步骤，你将深入了解如何将音频数据转化为可预测的模型，以进行年龄预测等任务。源代码可在github.com/miykael/miyk...获取。

深入剖析-ijkplayer框架音视频开发

       随着互联网技术的迅猛发展，移动设备上的视频播放需求日益增长，催生了一系列开源和闭源播放器。这些播放器的功能虽然强大，兼容性也颇优，但其基本模块通常包括事务处理、数据接收和解复用、音视频解码以及渲染。以下是一个简化的基本框架图。

       在众多播放器项目中，我们选择了ijkplayer进行源码分析。ijkplayer是一款基于FFPlay的轻量级Android/iOS视频播放器，支持跨平台，API易于集成，编译配置可裁剪，方便控制安装包大小。本文基于ijkplayer的k0.7.6版本，重点分析其C语言实现的核心代码，以iOS平台为例，Android平台实现类似，具体请读者自行研究。

       ijkplayer的主要目录结构如下：tool（初始化项目工程脚本）、config（编译ffmpeg使用的配置文件）、extra（存放编译ijkplayer所需的依赖源文件，如ffmpeg、openssl等）、ijkmedia（核心代码）、ijkplayer（播放器数据下载及解码相关）、ijksdl（音视频数据渲染相关）、ios（iOS平台上的上层接口封装以及平台相关方法）、android（android平台上的上层接口封装以及平台相关方法）。iOS和Android平台在功能实现上的主要差异在于视频硬件解码和音视频渲染。

       ijkplayer的初始化流程包括创建播放器对象，打开ijkplayer/ios/IJKMediaDemo/IJKMediaDemo.xcodeproj工程，在IJKMoviePlayerViewController类中viewDidLoad方法中创建了IJKFFMoviePlayerController对象，即iOS平台上的播放器对象。

       ijkplayer的初始化方法具体实现如下：创建了IjkMediaPlayer结构体实例_mediaPlayer，主要完成了以下三个动作：创建平台相关的IJKFF_Pipeline对象，包括视频解码以及音频输出部分；至此，ijkplayer播放器初始化的相关流程已经完成。

       ijkplayer实际上是基于ffplay.c实现的，本章节将以该文件为主线，从数据接收、音视频解码、音视频渲染及同步这三大方面进行讲解，要求读者具备基本的ffmpeg知识。

       当外部调用prepareToPlay启动播放后，ijkplayer内部最终会调用到ffplay.c中的stream_open方法，该方法是启动播放器的入口函数，在此会设置player选项，打开audio output，最重要的是调用stream_open方法。

       从代码中可以看出，stream_open主要做了以下几件事情：创建上下文结构体，设置中断函数，打开文件，探测媒体类型，打开视频、音频解码器，读取媒体数据，将音视频数据分别送入相应的queue中，重复读取和送入数据步骤。

       ijkplayer在视频解码上支持软解和硬解两种方式，可在播放前配置优先使用的解码方式，播放过程中不可切换。iOS平台上硬解使用VideoToolbox，Android平台上使用MediaCodec。ijkplayer中的音频解码只支持软解，暂不支持硬解。

       ijkplayer中Android平台使用OpenSL ES或AudioTrack输出音频，iOS平台使用AudioQueue输出音频。audio output节点在ffp_prepare_async_l方法中被创建。

       iOS平台上采用OpenGL渲染解码后的YUV图像，渲染线程为video_refresh_thread，最后渲染图像的方法为video_image_display2。

       对于播放器来说，音视频同步是一个关键点，同时也是一个难点。通常音视频同步的解决方案就是选择一个参考时钟，播放时读取音视频帧上的时间戳，同时参考当前时钟参考时钟上的时间来安排播放。

       ijkplayer支持的事件比较多，具体定义在ijkplayer/ijkmedia/ijkplayer/ff_ffmsg.h中。在播放器底层上报事件时，实际上就是将待发送的消息放入消息队列，另外有一个线程会不断从队列中取出消息，上报给外部。

       本文只是粗略的分析了ijkplayer的关键代码部分，平台相关的解码、渲染以及用户事务处理部分，都没有具体分析到，大家可以参考代码自行分析。

FFplay源码分析-nobuffer

       在使用 FFplay 播放 RTMP 流时，不开启 nobuffer 选项会导致画面延迟高达7秒左右，而开启此选项后，局域网延迟可降低到毫秒左右。因此，本文将深入探讨nobuffer的实现细节，以及播放端缓存7秒数据的作用。

       fflags 的定义在 libavformat/options_table.h 文件中，这是一个通用选项，所有解复用器均包含此选项。在调用 avformat_open_input() 函数时，会将该命令行参数传入，其位置与所有格式参数相同，如在之前的文章《FFplay源码分析》中所述。记得在调试参数中添加-fflags nobuffer。

       在 avformat_open_input() 函数内部，fflags 这个 AVOption 会被传递给 AVClass，该类存储了多个 AVOption，而fflags 的索引为5。在 av_opt_set_dict() 函数中，fflags 的值会被应用并清除其他选项。在 avformat_open_input() 执行完毕后，AVFormatContext::flags 的第7位应被置为1，即二进制的 。通过下图可以清晰地看到这个过程。

       在 avformat_find_stream_info() 函数内部，如果没有设置nobuffer标记，探测的数据包将被丢入队列。avformat_find_stream_info() 首先读取一段数据包以分析输入流的编码器等信息，为了重用这些数据包，它们会被放入队列中。然而，整个探测过程长达5秒，这意味着 FFplay 大概会读取5秒的数据来分析输入流。若开启nobuffer，则不会重复使用这些探测数据，FFplay 探测完输入流后，会读取新的数据包进行播放。无需缓存，从而降低了延迟。

       通过在 ffpaly.c 文件中的 avformat_find_stream_info() 函数前后输出时间，可以发现两者相差5秒，直观展示了nobuffer对于降低延迟的作用。在实时场景下，缓存功能变得多余，它原本是为了分析本地文件，避免重复读取，但在实时场景中反而影响了性能。因此，在实时场景中，关闭缓存更为合适。

       补充说明：若在本地虚拟机环境下，不启用缓存也能实现流畅播放。然而，如果 SRS 部署在局域网的另一台机器上，不开启缓存可能导致视频卡顿，原因可能是解码前未能及时读取视频帧，FFplay 不断丢弃视频帧，尤其是当视频比音频慢时，这种情况下缓存功能反而成为瓶颈。