1.ijkplayer源码分析 视频解码流程
2.完美解码设置源码输出完美解码设置
3.源码输出和解码输出有什么区别
4.MediaCodec源码浅析
5.FPGA高端项目：6G-SDI 视频编解码，解码解码提供工程源码和技术支持
6.HEVC开源编解码器HM编译及使用方法
ijkplayer源码分析 视频解码流程
深入ijkplayer源码，系统系统本文聚焦视频解码流程。源码源码用在video_thread中，解码解码我们首先审视IJKFF_Pipenode结构体，系统系统定义于ff_ffpipenode.h和ff_ffpipenode.c。源码源码用webps源码在线ps源码pipenode封装软解与硬解功能，解码解码初始化流程在stream_component_open中启动，系统系统调用pipeline.ffpipeline_open_video_decoder实现。源码源码用
在视频解码流程中，解码解码视频帧处理在video_thread线程下进行。系统系统从packet_queue读取视频packet，源码源码用然后通过软/硬解码，解码解码最终将解码结果放入frame_queue。系统系统软解通过ffpipenode_ffplay_vdec.c实现，源码源码用硬解则在ffpipenode_android_mediacodec_vdec.c中执行。不论软解还是硬解，解码后的结果均被引导至ff_ffplay.c#queue_picture进行队列化，准备渲染。
对于LinuxC++音视频开发者，学习资源尤为关键。免费音视频开发资料、视频、学习路线图以及面试题，涵盖C/C++、Linux、FFmpeg、WebRTC、周线kdj源码RTMP、NDK和Android音视频流媒体高级开发，免费提供给有需求者。学习交流君羊群，点击加入即可获取资料。
最后，渲染流程在stream_open方法中启动，创建video_refresh_thread线程。此线程从frame_queue中读取视频帧，进行音视频同步后，完成渲染。此环节聚焦渲染流程，音视频同步细节暂不展开。
完美解码设置源码输出完美解码设置
关于完美解码设置源码输出，完美解码设置很多人还不知道，
1、有些用户会在完美解码，播放3D**，但**视频是3D的，字幕是2D，大大降低了观看效果。那么如何设置3D字幕效果，我们来教你怎么操作。
2、首先我们将字幕加载到视频中去后，在画面右键菜单选择字幕-3D字幕，然后根据3D的走向共和原版源码类型选择左右或者上下字幕。
3、如果效果还是不满意，那么请直接前往3D字幕设置中，对其进行深度的设置，比如三维景观深度，人像深度等。
4、以上就是完美解码设置3D字幕的方法了，当然了你也可以建立一个字幕文件夹来专门存放字幕，以便下次加载视频的时候能够快速识别到字幕文件。
本文讲解到此结束，希望对大家有所帮助。
源码输出和解码输出有什么区别
区别：
1、源码输出，是指播放器播放的音频以数字形式输出给功放或者解码器进行音频的解码，然后输出到音箱。
2、解码输出，是指播放器本身先将音频进行解码，然后将解码后的音频输出给功放或者其他设备然后输出到音箱。
3、相对来说，源码输出好，因为功放的解码硬件要好于播放设备的解码。
4、没有功放或者解码设备的，都是多商户源码开发播放器本身解码后输出。
5、有功放或者解码设备，建议播放器设置源码输出，然后解码工作交给功放或者解码器来进行解码。
MediaCodec源码浅析
本文从MediaCodec源码的主要结构出发，深入分析了其核心函数dequeueOutputBuffer的实现机制。MediaCodec主要结构包括API、JNI、Native三个部分，这些部分共同构成了客户进程中运行的代码基础。在这些结构中，应用代码通过Java层MediaCodec接口与JNI代码交互，进而调用Native代码，实现解码器的主要逻辑。
结构上，MediaCodec源码主要分为以下几个关键组件：JMediaCodec、MediaCodec、ACodec和OMXClient。JMediaCodec作为与Java层交互的桥梁，包含智能指针sp和MediaCodec实例mCodec，以及用于事件循环的mLooper。MediaCodec则负责将ACodec与OMX服务端连接起来，实现解码功能。ACodec内部实现为状态机，并继承CodecBase功能，其构造函数初始化内部状态类，并设置初始状态为UninitializedState。源控控制源码OMXClient则负责维护与binder的连接，访问binder方法，实现与服务端的交互。
在分析过程中，重点关注了dequeueOutputBuffer函数的调用流程。该函数从MediaCodec.java调用native_dequeueOutputBuffer，在android_media_MediaCodec.cpp中映射到android_media_MediaCodec_dequeueOutputBuffer函数。最终，此函数通过JMediaCodec.dequeueOutputBuffer调用MediaCodec::dequeueOutputBuffer。在这一过程中，JMediaCodec.dequeueOutputBuffer构建kWhatDequeueOutputBuffer消息，通过ALooper传递给自己处理。消息处理后，将结果返回给调用者，完成输出缓冲区的获取。
在处理过程中，使用了消息队列来管理输入输出缓冲区。消息队列中包含两个关键组件：mPortBuffers和mAvailPortBuffers。mPortBuffers用于存储解码器的所有缓冲区，而mAvailPortBuffers则作为缓冲区队列，用于管理当前可用的缓冲区。dequeuePortBuffer函数用于从mAvailPortBuffers中获取可用缓冲区的索引。生产过程则通过updateBuffers更新缓冲区状态，清理过程则在returnBuffersToCodecOnPort中进行，清空了mAvailPortBuffers。
综上所述，MediaCodec源码的核心在于其结构设计和dequeueOutputBuffer函数的实现，通过消息队列管理和缓冲区操作，实现了高效的解码流程。
FPGA高端项目：6G-SDI 视频编解码，提供工程源码和技术支持
FPGA高端项目：6G-SDI 视频编解码，提供工程源码和技术支持
前言：Xilinx系列FPGA实现SDI视频编解码的方案主要有两种：一是使用专用编解码芯片，如GS和GS，优点是简单，但成本较高；二是使用FPGA实现，通过合理利用FPGA资源实现解串，操作难度稍大，对FPGA水平要求较高。UltraScale GTH适用于Xilinx UltraScale系列FPGA，支持更高线速率、更多协议类型、更低功耗和更高带宽。Xilinx还提供了SDI视频编解码的专用IP，如SMPTE UHD-SDI，支持多种视频格式编解码。
设计详情：本文采用Xilinx 7系列Kintex7型号的FPGA实现6G-SDI 视频编解码。设计包括编码和解码两部分，即视频发送和接收。6G-SDI 视频接收过程：使用标准6G-SDI摄像头，通过GVA芯片均衡EQ，然后使用GTX原语解串，将高速串行SDI视频解为并行数据。接着，调用Xilinx的SMPTE UHD-SDI IP核进行视频解码。视频发送过程：使用静态彩条作为源，调用SMPTE UHD-SDI IP核进行编码，然后使用GTX原语串化视频数据。
系统框图：参考了Xilinx官方设计文档，框图包含GVA均衡EQ、GTX时钟配置与控制、SMPTE UHD-SDI IP核等关键组件。
GTX 与 SMD UHD-SDI IP：调用GTX原语进行SDI视频解串与串化，使用SMPTE UHD-SDI IP核实现SDI视频编解码。
输出展示：接收端接收6G-SDI视频后，通过ILA观察数据正确性；发送端输出静态彩条视频。
Vivado工程详解：开发板为Xilinx 7系列Kintex7，使用Vivado.2，输入为6G-SDI摄像头，输出为静态彩条视频。工程代码架构与资源功耗预估。
工程移植说明：不同vivado版本需调整工程保存或升级vivado版本。FPGA型号不一致时需更改型号并升级IP。
上板调试：需要FPGA开发板、6G-SDI相机、BNC转SMA线、SDI转HDMI盒子和HDMI显示器。提供完整工程源码和技术支持。
福利：工程代码以某度网盘链接方式发送。
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”等可执行文件。
接下来，我们使用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进行编码时，编码后的视频画面会发生色彩异常和抖动异常。目前，已找到原因并成功解决。在解决此问题之前，我们需要了解y4m文件格式。Y4M是一种保存原始YUV序列的文件封装格式，包含视频属性信息。而HM的TAppEncoder编码器需要接收仅由视频帧组成的像素矩阵数据。因此，直接将akiyo_cif.y4m文件输入到HM编码器中可能导致帧不对齐，造成抖动。解决方法是提取视频每一帧像素矩阵，丢弃视频属性信息，并将它们写入新文件。使用ffmpeg进行视频内容提取后，将得到的akiyo_yuv.yuv文件输入到TAppEncoder中，以相同方式进行编码，即可正常播放视频。
