wangyongyao1989的博客

本文基于开源项目 WebRTCDemo，完整实现安卓（webrtclib）、Python 信令服务器与网页端的 WebRTC 视频通话。三端通过分离信令（WebSocket）与媒体（UDP SRTP）通道，实现低延迟直连。重点展示弱网自适应策略：网络差时自动关视频保音频，恢复后逐级回升，断线后通过 ICE 重连机制自动恢复。全程实测，支持带宽压至 100kbps、丢包 25% 场景，代码真实可运行，源码已开源。

Android FFmpeg 实战项目技术解析 该项目提供了一个完整的Android音视频处理框架，基于FFmpeg实现从基础功能到高级播放器的全流程开发。项目采用多模块架构设计，分为9个独立模块，涵盖音视频基础操作、编解码、图像处理、滤镜应用、硬件编解码和播放功能。 技术架构采用三层设计： UI层：单Activity+多Fragment导航结构，基于ViewBinding和ViewModel实现界面交互 JNI+业务层：使用动态注册方式实现Java与C++交互，每个功能模块独立封装 底层：预编译FFmpe

这篇文章介绍了一个Android平台的全栈多媒体开发项目WyFFmpeg，该项目整合了FFmpeg编解码、OpenGL ES渲染、H.264/H.265解析和RTMP推流等核心技术。项目包含7个模块：ffmpegplay（音视频处理）、glplay（OpenGL渲染）、h264（H.264解析）、h265（H.265解析与转码）、rtmplive（RTMP推流）等。文章详细解析了各模块的架构设计和关键技术实现，包括JNI动态注册、FFmpeg音视频处理流程、OpenGL ES渲染管线、H.264/H.265

本文介绍了基于FFmpeg实现音视频同步播放的技术方案。主要内容包括：1. 音视频同步原理：采用音频主时钟策略，通过比较视频帧PTS与音频时钟，动态调整视频播放速度（丢帧或延迟）。2. 关键技术实现：使用FFmpeg解码音频（OpenSL ES播放）和视频（ANativeWindow渲染），通过多线程架构（解复用、解码、播放线程）处理数据流。3. 核心代码结构：详细设计了音频/视频帧队列、时钟管理模块，并实现了音视频同步控制逻辑。该方案能有效解决播放过程中的时钟漂移问题，确保音画同步。完整代码已开源在Git

本文介绍了使用FFmpeg解码视频数据并通过OpenGL纹理进行播放的实现方案。文章首先概述了OpenGL渲染环境的搭建，包括EGL核心初始化、着色器编译、纹理创建等关键步骤。然后详细讲解了FFmpeg解码线程与OpenGL渲染线程的协同工作流程，重点分析了YUV420P格式视频帧到纹理数据的转换过程。文中提供了完整的代码实现，包括EGLSurfaceViewVideoRender类封装OpenGL渲染逻辑，以及FFGLPlayer类处理FFmpeg解码与OpenGL渲染的线程同步。最后展示了实现效果并提供

本文介绍了使用FFmpeg解码视频数据并通过ANativeWindow进行播放的实现方案。主要内容包括：1）设计线程安全队列实现解码线程和渲染线程间的数据传递；2）解码线程通过FFmpeg读取视频帧并存入队列；3）渲染线程从队列获取帧数据，转换颜色空间后通过ANativeWindow进行显示；4）实现了帧率控制机制，基于时间戳调整播放速度。系统采用双线程架构，通过条件变量实现线程同步，确保流畅播放。完整代码已开源在GitHub项目中，为Android平台视频播放开发提供了实用参考方案。

本文介绍了使用FFmpeg解码音频数据并通过AudioTrack和OpenSL ES播放的实现方法。首先通过FFmpeg完成音频文件的打开、流信息解析、解码器初始化和PCM数据提取，其中涉及关键的重采样处理。在播放环节，分别实现了两种方案：1）通过回调将PCM数据传递给Java层的AudioTrack播放；2）利用OpenSL ES构建完整的音频播放管线，包括引擎创建、混音器配置和播放器初始化，并通过缓冲区队列回调机制实现解码线程与播放线程的同步控制。文中详细展示了OpenSL ES的封装类实现，以及解码线

本文介绍了音视频编解码流程中从媒体文件提取数据包后进行解码的两种实现方式：FFmpeg和MediaCodec。在FFmpeg部分，详细说明了交叉编译、数据包提取、解码器查找和分配、数据包解码等步骤，并提供了完整的代码实现。在MediaCodec部分，重点讲解了Extractor初始化、轨道选择、解码器初始化以及解码过程，同样包含详细代码示例。文章还对比了两种解码流程的异同，并展示了实际效果。所有代码均可在作者GitHub项目中查看。该系列文章为音视频开发提供了完整的流程参考，适合开发者学习音视频编解码技术。

本文介绍了使用FFmpeg和NDK实现音视频文件转封装生成MP4文件的全流程。在FFmpeg部分，详细展示了通过AVFormatContext读取源文件、提取音视频流、创建输出文件并写入数据包的过程。NDK部分则基于Android原生API，使用AMediaExtractor和AMediaMuxer实现类似功能，包括初始化提取器、选择音视频轨道、配置复用器以及执行转封装操作。文章对比了两种技术方案的实现差异，并提供了完整的代码实现（GitHub项目可查）。两种方法均能有效完成音视频数据的提取和重新封装，适合

本文介绍了Android音视频编解码中Extractor和Muxer的使用流程。主要内容包括：1）使用FFmpeg进行音视频文件写入的11个关键步骤，从初始化AVFormatContext到写入数据包；2）NDK MediaMuxer的实现方式，通过HwMuxer和ProcessMuxer类完成媒体文件复用；3）对比了FFmpeg和NDK MediaMuxer在获取复用器和写入数据包操作上的差异。文章提供了完整的代码实现，展示了两种技术方案在Android音视频处理中的应用方法。

本文介绍了Android平台下媒体文件处理的两种技术方案：基于FFmpeg的软件编解码和基于MediaCodec的硬件编解码。详细阐述了FFmpeg通过avformat_open_input()等API提取音视频流信息的过程，以及MediaCodec借助AMediaExtractor提取媒体数据的实现方法。文章对比了两种技术在文件打开、流索引获取、编解码器选择、轨道选择等关键环节的差异，并提供了完整的代码实现（GitHub项目链接）。通过BenchmarkCommon、Stats等工具类，实现了对编解码性能

视频编码的目标由单纯的追求高压缩率转向了使视频流能够更好地适应各种不同的网络环境和用户终端。然而， 实际系统中网络环境和用户终端设备均存在异构性。网络的异构性体现在带宽的不同，终端设备的异构性则是指处理能力和显示能力的差异。这些对视频编码提出了新的挑战，编码器无法预知传输网络和客户设备的条件，因此，视频服务器需要对视频传输请求有自适应性， 以使得码流可以被灵活地组织适应不同的应用需求。为了获得这种自适应性，可以采用的视频编码技术主要有自适应编码、转码、联播、多描述编码和可伸缩编码等。

 H.264采用分层模式，定义了视频编码层（VCL）和网络提取层（NAL），后者专为网络传输设计，能适应于不同网络中的视频传输，进一步提高网络“亲和性”。H.264引入了面向IP包的编码机制，有利于网络中的分组传输，支持网络中视频的流媒体传输。H.264具有较强的抗误码特性，特别适应丢包率高、干扰严重的无线视频传输的要求。多媒体视频在不同环境下的传输，不仅需要高效率的编码，同时还需要编码后的视频能容易地无缝集成到当前和未来的网络协议架构当中。VCL包括VCL编码器与VCL解码器，主要功能是采用运动补偿、

 H.264包含视频编码层（VCL）和网络提取层（NAL）。 VCL包括核心压缩引擎和块、宏块及片的语法级别的定义，它的设计目标是尽可能地独立于网络的情况下进行高效地编解码；而NAL则负责将VCL产生的比特字符串适配到各种各样的网络环境中，它覆盖了所有片级别以上的语法级别，同时支持以下功能：支持独立片解码，起始码唯一保证，支持SEI，支持流格式编码数据传送。NAL解码器负责将符合H.264码流规范的压缩视频流解码， 并进行图像重建。根据如图7.1所示的解码器，我们可以看出基本的解码流程如下：解码器从NAL

 在编码器输出的码流中，数据的基本单位是句法元素。每个句法元素由若干比特组成，它表示某个特定的物理意义，例如：宏块类型、量化参数等。句法表征句法元素的组织结构，语义阐述句法元素的具体含义。所有的视频编码标准都是通过定义句法和语义来规范编解码器的工作流程。编码器输出的比特码流中，每个比特都隶属某个句法元素，也就是说，码流是由一个个句法元素依次衔接组成的，码流中除了句法元素外并不存在专门用于控制或同步的内容。在H.264定义的码流中，句法元素被组织成有层次的结构，分别描述各个层次的信息。

H.264/AVC视频编码技术详解 H.264/AVC是新一代高效视频编码标准，由ITU-T和MPEG联合开发。该标准通过多项创新技术显著提高了视频压缩效率，主要特性包括： 高效的预测编码：采用可变尺寸块运动补偿（16×16至4×4）、1/4像素精度运动估计和多参考帧预测，大幅提升预测准确性。 先进的变换量化：使用4×4整数DCT变换，结合52级量化参数和自适应量化矩阵，有效去除空间冗余。 两种熵编码：CAVLC（基于上下文的变长编码）和CABAC（二进制算术编码），后者可提升9%-14%压缩率。 环路滤波

预测法是最简单、实用的视频压缩编码方法，经过压缩编码后传输的并不是像素本身的取样值，而是该取样的预测值和实际值之差。        为什么取像素预测值与实际值之差作为传输的信号？因为大量统计表明，同一幅图像的邻近像素之间有着相关性，或者说这些像素值相似，如图3.1所示。邻近像素之间发生突变或“很不相似”的概率很小。而且同帧图像中邻近行之间对应位置的像素之间也有较强的相关性。人们可以利用这些性质进行视频压缩编码

本文综述了视频压缩编码技术及数字视频的基本概念。首先，文章介绍了信息的三大特性（通用性、抽象性、无限性）及信息化的定义与实现途径。接着，文章详细分析了视频信息的特点，包括直观性、确定性、高效性和广泛性，并指出视频信号的高带宽性。随后，文章探讨了视频压缩编码的必要性及可能性，重点介绍了预测编码和变换编码的原理。文章还概述了视频编码系统的基本结构，分为基于波形的编码和基于内容的编码两大类，并简要提及了立体视频编码的发展方向。最后，文章介绍了数字电视的基本概念、PCM原理及数字电视信号的编码参数，强调了数字电视在

 视频传输带宽通常都会受到一定限制，为了在满足信道带宽和传输时延限制的情况下有效传输视频数据，保证视频业务的播放质量，需要对视频编码过程进行速率控制。所谓速率控制，就是通过选择一系列编码参数，使得视频编码后的比特率满足所需要的速率限制，并且使得编码失真尽量小。速率控制属于率失真优化的范畴，速率控制算法的重点是确定与速率相关的量化参数(QuantizationParameter，QP)。

   为了将具有庞大数据量的视频在有限信道内传输、存储，高压缩率的编码算法往往会造成编码重建视频与原始视频存在差别，即重建视频产生失真，该类压缩被称为有损压缩。对于有损压缩算法，其性能需要根据编码输出的比特率和编码带来的失真度共同衡量。编码比特率和失真度相互制约、相互矛盾，如降低比特率往往会增加视频的失真度，相反要想获得更好的视频质量，又会提高视频的编码比特率。因此，视频编码的主要目的就是在保证一定视频质量的条件下尽量减少编码比特率，或在一定编码比特率限制条件下尽量地减小编码失真。在固定的编码框架下，为了应

新一代视频压缩标准 H.265/HEVC 在很大程度上是为了满足人们对于高分辨率视频的需求，而对于高清乃至超高清视频，分辨率达到了4kx2k或8kx4k，无论是从编码还是从解码的角度，其计算复杂度都是极高的。而为了提高H.265/HEVC的网络适应能力，其压缩性能与H.264/AVC 相比显著提高，相同条件下的码率可以降低50%，获得性能提升的代价就是编解码复杂度的大大提高。 与H.264/AVC相比，H.265/HEVC的复杂度主要体现在以下几点：H.265/HEVC 的帧内预测模式增多，

H.265/HEVC也采用了视频编码层(Video Coding Layer，VCL)和网络适配层(Network Abstract Layer，NAL)的双层架构，以适应不同的网络环境和视频应用。网络适配层的主要任务是对视频压缩后的数据进行划分和封装，并进行必要的标识，使其可以很好地适应复杂多变的网络环境。当前的网络类型多种多样，不同的网络环境具有不同的特性，压缩视频在其中进行传输时必然会受到影响。例如，不同类型的网络支持的最大传输单元(Maximum Transmission Unit，MTU)可能有所

熵编码是指按信息熵原理进行的无损编码方式，无损编码也是有损视频编码中的一个关键模块，它处于视频压缩系统的末端。编码把一系列用来表示视频序列的元素符号转变为一个用来传输或存储的压缩码流，输入的符号可能包括量化的变换系数、运动矢量信息、预测模式信息等。熵编码可以有效去除这些视频元素符号的统计几余，是保证视频编码压缩效率的重要工具之一。

类似于以往的视频编码标准,H.265/HEVC 仍采用基于块的混合编码框架，方块效应、振铃效应、颜色偏差以及图像模糊等失真效应仍存在于采用 H.265/HEVC 标准的压缩视频中。为了降低这类失真对视频质量的影响，H.265/HEVC中采用了环路滤波技术叫(In-loop Filtering)，包括去方块滤波(Deblocking Filter)和像素自适应补偿(Sample Adaptive Offset)两个模块。去方块滤波用于降低方块效应，像素自适应补偿用于改善振铃效应,这两个模块在编码框架中的位置如

量化 (Quantization) 是指将信号的连续取值(或大量可能的离散取值)映射为有限多个离散幅值的过程，实现信号取值多对一的映射。在视频编码中，残差信号经过离散余弦变换 (DCT) 后，变换系数往往具有较大的动态范围。因此对变换系数进行量化可以有效地减小信号取值空间，进而获得更好的压缩效果。同时，由于多对一的映射机制，量化过程不可避免地会引入失真，它也是视频编码中产生失真的根本原因。

变换编码图像变换编码是指将以空间域中像素形式描述的图像转换至变换域，以变换系数的形式加以表示。绝大多数图像都含有较多平坦区域和内容变化缓慢的区域，适当的变换可使图像能量在空间域的分散分布转为在变换域的相对集中分布，以达到去除空间几余的目的,结合量化、“z”扫描和熵编码等其他编码技术，可以获得对图像信息的有效压缩。H.265/HEVC标准规定，在帧内4x4式亮度分量残差编码中使用4x4 整数 DST，而在帧内其他模式、帧间所有模式，以及所有色差分量的残差编码中一律使用整数DCT。这主要是由于帧内预测利用周围已

预测编码是视频编码中的核心技术之一。对于视频信号来说，一幅图像内邻近像素之间有着较强的空间相关性,相邻图像之间也有很强的时间相关性。因此，先进的视频编码往往采用帧内预测和帧间预测的方式，使用图像内已编码像素预测邻近像素，或利用己编码图像预测待编码图像，从而有效去除视频空域和时域的相关性。视频编码器对预测后的残差而不是原始像素值进行变换、量化、熵编码，由此大幅提高编码效率。自差分编码被应用于视频压缩以来,预测编码一直是视频编码标准的重要内容。

H.265/HEVC采用混合编码框架，包括变换、量化、熵编码、帧内预测、帧预测以及环路滤波等模块。但是，H.265/HEVC几乎在每个模块都引入了新的编码技术。

 H.265又称为HEVC(全称High Efficiency Video Coding，高效率视频编码，本文统称为H.265)，是 ITU-T H.264/MPEG-4 AVC标准的继任者。2004年由ISO/IEC Moving Picture Experts Group(MPEG)和 ITU-T Video Coding Experts Group(VCEG)作为ISO/IEC 23008-2 MPEG-H Part 2或称作ITU-T H.265开 始制定。第一版的HEVC/H.265视频压缩标准在

帧缓冲对象（Framebuffer Object, FBO）是 OpenGL 中用于管理渲染目标的核心工具。它允许你将渲染结果输出到纹理、渲染缓冲对象（Renderbuffer）或其他自定义的缓冲区，而不是默认的屏幕缓冲区。帧缓冲在图形渲染中具有重要作用。        以下是帧缓冲的主要作用和应用场景：

根据前置储备，该功能的实现流程：创建一个GLThread的OpenGL运行环境；YUV数据绘制到OpenGL纹理中；图片纹理创建绘制到glViewport；文字渲染绘制到glViewport；录制视频的surface并根据此切换GLContext上下文交换（swapBuffer）渲染与显示的视频数据 ；MediaCodec获取出encodeData写入MediaMuxer成为MP4文件格式的视频

​OpenGL Texture C++ Camera Filter滤镜视频录制; 基于文章1/2/3的代码，结合Google开源项目grafika中的WindowSurface.java/Coregl.java/TextureMovieEncoder2.java/VideoEncoderCore.java创建出录制视频的surface并根据此切换GLContext上下文交换（swapBuffer）渲染与显示的视频数据，最终在VideoEncoderCore中通过MediaCodec获取出encodeDat

由上GLSurfaceView源码分析可知，内部维护着一个GLThread子线程，用来保持GL的上下文GLConext一致性的操作。接下来仿造GLSurfaceView创建一个同样继承于SurfaceView的自定义类WyyGLSurfaceView。WyyGLSurfaceView是在OpenGL Texture C++ 预览Camera视频-优快云博客中GLTextureCPlusVideoPlayView进行改造的，有兴趣的可翻看我的这一篇的博客。

基于OpenGL Texture纹理的强大功能，在片段着色器（Shader）中编写GLSL代码，对YUV的数据进行数据转换从而实现视频编辑软件中的相机滤镜功能。接上一篇OpenGL Texture C++ 预览Camera视频的功能实现，本篇来实现Camera滤镜效果并各种滤镜的切换。

OpenGL是一个图形API，并不是一个独立的平台。包含了一系列可以操作图形、图像的函数。基于Texture纹理强大的功能，本篇文章实现Android OpenGL Texture C++ 预览Camera视频流的功能。

RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写，它是由Adobe公司提出的一种应用层的协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题。RTMP是应用层协议，采用（通常）TCP来保证可靠传输；在TCP完成握手链接建立后，还会进行RTMP的一些自己的握手动作，在建立RTMP Connection链接；

我们播放的视频文件一般都是用一种封装格式封装起来的，封装格式的作用是什么呢？一般视频文件里不光有视频，还有音频，封装格式的作用就是把视频和音频打包起来。所以我们先要解封装格式，看有哪些视频流和哪些音频流，此时的音频流和视频流都还是压缩数据，不能直接用于显示的，这就需要解码。如FFmpeg 视频文件就是一个容器 (视频流（H264） 音频流(aac))。

AVFormatContext是一个贯穿全局的数据结构，很多函数都要用它作为参数。FFmpeg代码中对这个数据结构的注释是format I/O context，此结构包含了一个视频流的格式内容。其中存有AVIputFormat(或AVOutputFormat，但是同一时间AVFormatContext内只能存在其中一个)、AVStream、AVPacket这几个重要的数据结构以及一些其他的相关信息，比如title、author、copyright等。

FFmpeg是广泛使用于的多媒体解决方案，是一个自由软件项目的名称，采用LGPL或GPL许可证。它提供了录制/转换以及流化音视频的完整解决方案。包含非常先进的音频/视频编解码库libavcodec。为了保证高可移植性和编解码质量，libavcodec里很多代码都是新开发的。“FFmpeg”这个词中的“FF”指的是“Fast Forward”，而“mpeg”指的是一种压缩率比较大的活动图像和声音的压缩标准。一.FFmpeg简介：命令行工具概述（Command Line Tool Documentati

1 视频编码：视频编码就是指通过特定的压缩技术将某个视频格式文件转换成另一种视频格式的文件方式，视频传输中最重要的是编解码标准有国际电联的H.261/H.263/H.264/H.265，运动静止图像专家组的M-JPEG和国际标准化组织的运动图像专家组MPEG系列标准，此外还有网上广泛应用的Real-Networks的RealVideo/微软公司的WMV以及Apple的QuickTime等。...