洪伟的专栏

libjpeg-turbo 是一个 JPEG 图像编解码器，它使用 SIMD 指令加速 x86、x86-64、Arm、PowerPC 和 MIPS 系统上的基本 JPEG 压缩和解压缩，以及 x86、x86-64 和 Arm 系统上的渐进式 JPEG 压缩。在这些系统上其他条件相同的情况下，libjpeg-turbo 通常比 libjpeg 快 2-6 倍。在其他类型的系统上，由于其高度优化的 Huffman 编码算法，libjpeg-turbo 仍能比 libjpeg 有显著的性能提升。

在编译 FFmpeg 之前需要先编译 x265，但并不是所有的版本都能直接使用，比如笔者同时编译 Android、Window 和 Linux 三个平台时，使用 Android NDK r21e 会遇到很多报错，符号缺失，无法编译 .S 文件都是可能遇到的问题。

RTP 协议是为流媒体端到端的实时传输而设计的。该协议提供了抖动补偿和数据包丢失和乱序的检测功能，这些在 IP 网络上的 UDP 传输中很常见。RTP 允许通过 IP 组播将数据传输到多个目的地。RTP 被认为是 IP 网络中音频/视频传输的主要标准，并与相关的配置文件和有效载荷格式一起使用。RTP 的设计基于被称为应用层分帧的架构原则，其中协议功能在应用程序中实现，而不是在操作系统的协议栈中实现。实时多媒体流应用要求信息的及时传递，通常可以容忍一些丢包来达到这一目的。

YUV 是一个颜色模型，通常用作彩色图像管道的一部分。它对彩色图像或视频进行编码时考虑到了人类的感知，与“直接”的 RGB 表示相比，允许减少色度分量的带宽。

现在编译 FFmpeg 已经全面采用 Clang 了，gcc 被高版本 NDK 废弃，所以从网上搜索出来的编译脚本既有使用低版本 NDK 编译 FFmpeg 的，也有采用高版本 NDK 编译的。采用低版本 NDK 编译 FFmpeg 虽然也是一种手段，但是采用高版本 NDK 编译 FFmpeg 一定是“大势所趋”。另外就算采用低版本 NDK 去编译 FFmpeg，你会发现高版本的 FFmpeg 编译会报各种错误，有的人甚至修改了 FFmpeg 源码，虽然修改源码最终可以编译完成，但是终究不是解决问题的良方

FFmpeg 解码 H264 主要分三个步骤，其一获取解码器，其二向解码器中送入 H264 NALU，其三从解码器中获取解码后的 YUV 等数据。一、H264H.264，同时也是 MPEG-4 第十部分，是由 ITU-T 视频编码专家组（VCEG）和 ISO/IEC 动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。这个标准通常被称之为 H.264/AVC（或者 AVC/H.264 或者 H.264/MPEG-4 AVC 或 M

FFmpeg 默认是可以解码 AAC 格式的音频，但是如果需要获取 PCM16 此类数据则需要经过音频转码。首先要打开解码器，然后向解码器发送 AAC 音频帧（不带 ADTS），然后从解码器获取解码后的音频帧，数据是 float 类型的，如果需要则进行转码流程将 float 转成整型。一、AAC 音频AAC 是高级音频编码（Advanced Audio Coding）的缩写，出现于 1997 年，最初是基于 MPEG-2 的音频编码技术。由Fraunhofer IIS、Dolby Laboratorie

做 Android 音视频离不开 MediaCodec。实际上不局限于平台看问题，不管是 Linux、Mac OS、iOS、Android 还是 Window 这些系统，只要涉及到音视频编解码，无非要么软编解码、要么硬编解码，软编解码通常会使用瑞士军刀“FFmpeg”，主要靠 cpu 的算力去实现。硬编解码就要调用系统开放的 API 去使用硬件编解码。从效率上看，调用硬件编解码是最快的，通常会使用专用的硬件去处理编解码。尤其在嵌入式设备上通常 cpu 性能有限，想要达到满足要求的编解码需求，不用硬件编解码也

使用 FFmpeg 获取 rtsp/rtmp 流非常方便，将开发 rtsp/rtmp 客户端工作变的简单了许多。将 rtsp/rtmp 流路径送入 avformat_open_input 函数进行打开动作，得到 AVFormatContext 封装格式上下文；调用 avformat_find_stream_info 获取流的详细信息；分别记录 rtsp/rtmp 流中的音频和视频流索引；初始化视频解码器上下文，调用 avcodec_parameters_to_context 将流信息转移到视频解

谈到 YUV 图像在 arm 芯片架构下的高性能处理方案就离不开单指令多数据流（SIMD），这样性能提升是非常明显的。比如要实现 NV12 格式的 YUV 数据堆叠出画中画的效果，首先前景画一般需要缩小，然后将其叠加到背景画指定的坐标位置处。另外 NV12 转 I420 涉及到格式转换，缩放操作涉及插值和抽点算法，如果自己去实现这些算法耗时费力，可能还需要迭代很多轮才能稳定。我们知道 arm 架构下 SIMD 其实就是 NEON 指令集，libyuv 这个库实现了大部分的 YUV 缩放、转换功能，而且是在

CLion 是一款优秀的编程开发软件，没有 IDE 辅助开发工作很难，因此使用 CLion 开发 Ubuntu 20.04 下的项目是个不错的选择。一、CLion 安装首先到 jetbrains 官网 https://www.jetbrains.com/clion/ 下载 CLion 安装包 CLion-2021.1.tar.gz。下载好安装包后，解压缩包即可，直接使用图形界面工具，鼠标右键，解压到此处即可。或者使用解压命令也是可以的。tar -zxvf CLion-2021.1.tar.gz

这些函数负责分配、释放和复制内存。所有内存分配函数都有一个内置的 INT_MAX 字节上限。这可以通过 av_max_alloc() 进行更改，但要非常小心。一、av_malloc分配一个适合所有内存访问的对齐内存块（包括 CPU 上可用的向量）。当存在 HAVE_POSIX_MEMALIGN 条件，实际分配工作是 posix_memalign(…) 完成的，此函数是 POSIX 1003.1d 提出的；如果条件 HAVE_ALIGNED_MALLOC 为真，则使用 _aligned_malloc

AVBuffer 表示数据缓冲区本身；它是不透明的，不能被调用者直接访问，只能通过 AVBufferRef 访问。AVBuffer 函数族定义在 libavutil/buffer.h 头文件中。一、av_buffer_alloc使用 av_malloc() 分配给定大小的 AVBuffer。返回给定大小的 AVBufferRef，在内存不足时为 NULL。使用 av_malloc 分配 buffer，av_malloc 详细分析参见《FFmpeg 源码之内存管理函数族》；调用 av_buffer

查看 packet.h 源码，可以看到一系列的 AVPacket 分配与释放函数。熟悉这些 API 有利于方便在不同场景下使用 AVPacket。一、av_packet_alloc分配一个 AVPacket，并将其字段设置为默认值。得到的结构体必须使用 av_packet_free() 释放。返回一个用默认值填充或失败时为 NULL 的 AVPacket。这只分配 AVPacket 本身，而不是数据缓冲区。这些必须通过其他方式分配，比如 av_new_packet。av_mallocz 函数可分配一个

AVPacket 存储的是编码后的帧数据，它通常由 demuxer 输出，然后作为输入传递给 decoder，或者从 encoder 接收作为输出，然后传递给 muxer。对于视频，它通常应该包含一个压缩帧。对于音频，它可能包含几个压缩帧。encoder 允许输出空数据包、不包含压缩数据、只包含 side data（例如，在编码结束时更新一些流参数）。数据所有权的语义取决于 buf 字段。如果设置了该值，则动态分配 Packet 数据并无限期有效，直到对 av_packet_unref() 的调用将引

FFmpeg 官方 Demo encode_video.c 学习，是一个用 libavcodec API 编码视频的例子。其中涉及了 AVCodecContext、AVFrame、AVPacket、AVCodec 和 AVRational 结构体，以及 avcodec_send_frame(…)、avcodec_receive_packet(…)、av_packet_unref(…)、avcodec_find_encoder_by_name(…)、avcodec_alloc_context3(…)、av_p

FFmpeg 编译最佳的做法当然是参考官方文档，官方文档的指导最权威可行了。但还是需要一点小技巧才行。编译环境：Ubuntu 20.04官方文档指出安装是非侵入性的，将在主目录（home）中创建几个目录:ffmpeg_sources——源文件将在这里下载。如果需要，可以在完成编译时删除。ffmpeg_build——在这里构建文件并安装库。如果需要，可以在完成编译时删除。bin——在这里安装二进制文件（ffmpeg, ffplay, ffprobe, x264, x265）。一、获取编译前的依

上一节《libmatroska 与 libebml 移植到 Android 支持 mkv 格式解析与创建》成功编译了 Android 平台可用的 libmatroska.so 和 libebml.so。具体如何使用它们还没开始，这一节以创建 mkv 格式为例对它们进行使用。当然还要排坑！这花费了我不少力气去找到库中的 bug。一、使用 libmatroska 与 libebml首先在 Android Studio 中新建一个 Project。复制上一节编译出的 so 和 头文件到 libs/ 路径下

Matroska 多媒体容器（Multimedia Container）是一种开放标准的自由的容器和文件格式，是一种多媒体封装格式，能够在一个文件中容纳无限数量的视频、音频、图片或字幕轨道。所以其不是一种压缩格式，而是 Matroska 定义的一种多媒体容器文件。其目标是作为一种统一格式保存常见的电影、电视节目等多媒体内容。在概念上 Matroska 和其他容器，比如 AVI、MP4 或 ASF（Advanced Streaming Format，即高级流格式）比较类似，但其在技术规程上完全开放，在实现上包

WAV 是最常见的声音文件格式之一，是微软公司专门为 Windows 开发的一种标准数字音频文件，该文件能记录各种单声道或立体声的声音信息，并能保证声音不失真。但 WAV 文件有一个致命的缺点，就是它所占用的磁盘空间太大。它符合资源互换文件格式（RIFF）规范，用于保存 Windows 平台的音频信息资源，被 Windows 平台及其应用程序所广泛支持。Wave 格式支持 MSADPCM、CCITT A 律、CCITT μ 律和其他压缩算法，支持多种音频位数、采样频率和声道，是 PC 机上最为流行的声音文件