1.X264码率控制之VBV
2.HEVC开源编解码器HM编译及使用方法
3.FFmpeg源码分析: AVStream码流
4.音视频开发项目：H.265播放器：视频解码篇
5.我们的频源频源码流分析软件支持屏幕内容编码SCC显示了!
6.音视频流媒体开发系列（78)ffmpeg实战教程（一）Mp4，mkv等格式解码为h264和yuv数据
X264码率控制之VBV
X码率控制之VBV详解
视频压缩编码中，码视码原始RGB(YUV)数据量大，频源频源h.等编码标准应运而生。码视码目前，频源频源x因其高效性能常被选用，码视码私密空间软件源码尤其是频源频源在实时场景如视频会议中。码率控制至关重要，码视码特别是频源频源VBV的作用，它在复杂网络环境中确保发送端的码视码码率适中，防止画质差或网络拥塞。频源频源 编码后码流大小受图像复杂度、码视码参考帧相似度和量化程度影响。频源频源x通过CQP、码视码CRF和ABR三种码率控制方法进行管理，频源频源其中CRF和ABR更注重质量和码率的平衡。CRF保持图像质量稳定，ABR则更倾向于码率的稳定，通过动态调整量化值。 在编码过程中，X首先计算出帧级QP，考虑图像复杂度等因素。CRF和ABR通过get_qscale函数计算，CRF基于固定值，ABR则根据实际增长和期望增长动态调整。然后引入VBV，它像一个带容量限制的管道，能确保编码码率在预设范围内，防止过低或过高。 VBV调控机制中，通过注水和排水模拟实际编码过程，当水量超出上下限时调整QP以保持稳定。最终，尽管存在帧级和行级码控，x的lamp 源码包搭建码率控制仍需精细调整，以适应不同场景的需求。 x的码率控制方法远不止于此，如图像复杂度计算和行级码控等更为深入的内容需要进一步研究。实践出真知，深入理解x的码率控制需要查阅源码进行探究。HEVC开源编解码器HM编译及使用方法
HM (HEVC Test Model)是一个开源软件，用于帮助我们理解HEVC编码标准。它包括编码器TAppEncoder和解码器TAppDecoder，能实现HEVC标准中的所有功能，但性能不如商用编码器。该项目由JVET维护。本文记录了笔者在Ubuntu下根据HM项目的README，编译并运行一个小demo的过程。
JVET并未将HM托管到GitHub，而是将其托管在gitlab仓库vcgit.hhi.fraunhofer.de...中。我们可以在该页面找到仓库的git URL，然后在Ubuntu中使用git clone命令克隆源代码：
进入代码目录后，创建名为build的文件夹，并进入该文件夹：
在build目录下运行以下指令：
注意，执行上述指令前需要预先安装cmake工具。
执行cmake后，在当前目录下应该会看到一个Makefile，然后我们可以使用make进行编译：
编译过程可能较长：
编译过程中，如果没有错误，几分钟内即可完成。如果读者在编译过程中遇到依赖问题，可以自行搜索并安装，HM的编译过程相对顺利，没有太多难点。
当make的进度达到%时，说明编译完成。最后几行输出表明编译出的可执行文件位于相应位置，可以在“HM/bin/umake/gcc-9.4/x_/release”目录下找到“MCTSExtractor”“parcat”“SEIRemovalApp”“TAppDecoder”“TAppDecoderAnalyser”“TAppEncoder”等可执行文件。
接下来，qt4.6.3源码我们使用TAppEncoder进行测试，将一个未压缩的yuv序列编码成HEVC视频序列。我们使用的是Derf's Test Media Collection数据集中的akiyo视频序列。下载akiyo_cif.y4m文件后，将其与TAppEncoder可执行文件放在同一文件夹中。
在HM项目的doc目录下，有一个名为software-manual.pdf的说明文档，详细介绍了HM软件的使用方法。通过阅读该文档，我们可以了解TAppEncoder通过-c参数指定配置文件，并在项目的cfg目录下找到示例配置文件。我们将其中一个配置文件拷贝到工作目录下，并执行代码。如果出现错误，可能是因为配置文件中没有指定帧率和编码总帧数。这是一个HM项目的小坑，需要仔细调试。
修改配置文件后，再次执行指令，即可正常编码。编码完成后，可以在当前目录下找到输出文件akiyo_hevc.bin，使用PotPlayer播放，显示输入格式为HEVC。但可能存在一些播放异常，需要进一步检查。
我们可以使用开源软件GitlHEVCAnalyzer对akiyo_hevc.bin进行分析，该软件可以显示视频中的CU、PU等单元以及分块信息。
--更新：使用HM的TAppEncoder对akiyo_cif.y4m进行编码时，编码后的视频画面会发生色彩异常和抖动异常。目前，已找到原因并成功解决。在解决此问题之前，产品追溯asp源码我们需要了解y4m文件格式。Y4M是一种保存原始YUV序列的文件封装格式，包含视频属性信息。而HM的TAppEncoder编码器需要接收仅由视频帧组成的像素矩阵数据。因此，直接将akiyo_cif.y4m文件输入到HM编码器中可能导致帧不对齐，造成抖动。解决方法是提取视频每一帧像素矩阵，丢弃视频属性信息，并将它们写入新文件。使用ffmpeg进行视频内容提取后，将得到的akiyo_yuv.yuv文件输入到TAppEncoder中，以相同方式进行编码，即可正常播放视频。
FFmpeg源码分析: AVStream码流
在AVCodecContext结构体中，AVStream数组存储着所有视频、音频和字幕流的信息。每个码流包含时间基、时长、索引数组、编解码器参数、dts和元数据。索引数组用于保存帧数据包的offset、size、timestamp和flag，方便进行seek定位。
让我们通过ffprobe查看mp4文件的码流信息。该文件包含5个码流，是双音轨双字幕文件。第一个是video，编码为h，帧率为.fps，分辨率为x，像素格式为yuvp。通过svn获得源码第二个和第三个都是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分母。
音视频开发项目：H.播放器：视频解码篇
探索音视频开发的前沿技术，让我们深入剖析一款H.播放器的视频解码优化过程。在这款高性能播放器中，新版以惊人的效率展示了其解码能力，1分钟内处理p/fps的H. MP4视频，内存占用仅为4.6GB，而CPU占用率在极限条件下也保持在+。单帧解码p的速度已经优化到了惊人的毫秒，相较于旧版p的毫秒，无疑展示了技术的飞跃。
播放器的架构设计巧妙，由Loader、Demuxer、Renderer（核心模块）和UI View等模块构成，各部分独立却又协同工作。让我们走进DEMO架构示例：Loader负责从Annex-B码流中读取数据，WASM技术则高效地解码YUV数据，而FFmpeg经过精简编译后，被转化为轻量级的WASM包，实现资源优化。
要实现这一优化，首先从FFmpeg官网获取emsdk和源码版本（4.1），然后通过定制的make_decoder.sh脚本，去除不必要的模块，如swresample和postproc，专注于关键的hevc-decoder模块。这个过程包括禁用非必要的FFmpeg功能，生成简化库和.h文件，为后续的WASM编译做准备。
接下来，编写自定义的C语言入口文件（如decoder.c），运用C语言基础，创建一个初始化解码器的接口，如init_decoder，它接受一个JS回调函数，传递解码数据的地址、长度，以及可选的时间戳（pts）。附赠的学习资料包，包含FFmpeg、webRTC等技术，可通过企鹅裙获取，助你快速上手。
解码的核心在于处理AVPacket和AVFrame，视频中每个压缩帧需要通过demuxers和decoders逐一解析。decode_buffer函数负责数据解析和解码，将解码后的AVPacket传递给解码器，可能需要多次循环以接收完整的AVFrame。而在3.x和4.x版本中，avcodec_send_packet和avcodec_decode_video2/avcodec_decode_audio4的调用方法有所不同。
解码后的YUV数据通常以紧缩格式（如YUVp）和平面格式存储，需要转换后供JS使用。在这个过程中，采样率决定了数据处理的复杂度，例如4个Y分量对应1个U和V分量。将解码后的AVFrame复制到yuv_buffer，然后通过decoder_callback传递给JavaScript。
通过Emscripten构建WASM包，我们编写build_decoder.sh脚本，设置出口函数和内存配置，最终生成wasm/libffmpeg.js。在JS和Worker中，我们加载并调用WASM函数，构建Decoder类，扩展EventEmitter，处理数据的异步加载和解码。在主线程中，通过webpack和worker-loader，数据从主线程传输到Worker，解码器负责解码并返回处理后的数据。
H.视频解码的挑战在于高效处理AVPacket和AVFrame，音频解码则可能需要复用解码链路或者利用浏览器内置的解码器。音频播放则依赖于AudioContext，确保主流音频编码格式在浏览器中的兼容性。通过这个案例，我们了解了如何避免常见问题，以及FFmpeg在视频处理中的强大能力。H.播放器的应用场景广泛，为创新提供无限可能。
我们的码流分析软件支持屏幕内容编码SCC显示了!
HEVC屏幕内容编码技术（SCC）在视频编码标准中得到支持，但市面上大多数普通HEVC解码器不支持SCC，例如ffmpeg和VLC。为了进行SCC码流知识学习和编码码流验证，需使用支持SCC解码的软件，HM参考软件的SCM版本是其中之一。
HM参考软件的SVN源码目录中，HM.0及其后续版本已将RExt扩展部分并入主分支，后缀为SCM的版本包含了SHVC、MV-HEVC、3D-HEVC分支，支持普通H码流及SCC码流解码。已为Gitl HEVC Analyzer添加了HM.版本解码器，可实现SCC码流解码。
要为Gitl HEVC Analyzer增加HM.+SCM8.8版本解码器支持SCC编码技术，首先需了解该软件主要功能：标准解码器对H码流解码并保存信息到txt文件；在解码后，通过正则表达式匹配解析信息并使用QT软件显示。
对于仅需解码和显示SCC H码流，使用HM.+SCM8.8解码器对码流进行解码，然后将YUV文件通过QT软件显示即可。首先使用HM.+SCM8.8编码一段SCC码流。打开VS工程，设置TAppEncoder为启动项目，生成TAppEncoder.exe文件。
新建文件夹并拷贝可执行文件和配置文件.cfg，编写.bat脚本执行编解码器命令，或参照help文档配置参数进行编码。运行.bat脚本开始编码，查看编码过程是否支持SCC技术。编码后得到的SCC码流需使用支持SCC解码的解码器进行解码。
尝试使用VLC、FFMEPG等解码器解码SCC码流，发现图像解码和显示异常。使用升级过的Gitl HEVC Analyzer解码并显示SCC码流，画面显示正常。后续文章将介绍SCC码流的CU划分、MV等信息解析和显示。
音视频流媒体开发系列（)ffmpeg实战教程（一）Mp4，mkv等格式解码为h和yuv数据
在这个FFmpeg实战教程中，我们将探索如何将常见的视频格式如MP4和MKV解码为H和YUV数据。首先，让我们来看一个实例，通过运行解码过程，你将看到两个文件的生成，分别对应解码后的h和YUV数据，其中h由于采用了高效的压缩技术，文件大小明显小于YUV文件。 解码流程包括以下步骤：首先，将ws.mp4文件复制到项目目录，然后创建两个输出文件。接下来，初始化所需的组件，接着打开视频文件，获取视频信息并选择合适的解码器。在解码过程中，要注意av_read_frame()循环结束后可能遗留少量帧数据，这时需要调用flush_decoder函数，将这些帧数据完整输出。 下面是源代码示例，展示如何执行这些操作：拷贝ws.mp4并创建输出文件
初始化解码器和相关组件
打开和解码视频
使用flush_decoder确保所有帧数据都被处理
运行程序后，你将看到生成的h和YUV文件。如果你对音视频开发感兴趣，可以关注我们的免费学习资源，包括FFmpeg、WebRTC、RTMP、NDK和Android高级开发等内容。群文件中提供了详细的面试题、学习资料和教学视频，以及学习路线图，点击加群获取，希望能对你有所帮助。 对于Windows用户，需要配置FFmpeg环境。首先从ffmpeg.zeranoe.com下载相应版本的shared和dev版本，然后将include和lib文件夹分别复制到指定位置，最后在MinGW命令行中执行命令。而对于Linux或MacOS用户，可以在GCC命令行环境中进行操作。