皮皮网

1.h?频源频?ƵԴ??
2.FFmpeg源码分析: AVStream码流
3.流媒体客户端RTMP拉流保存h264（flv保存为h264）
4.FFmpeg 集成 x265 编译及解码
5.如何调试H.264代码?
6.FFplay源码分析-nobuffer

h??ƵԴ??

       本文将展示如何在纯网页中实现视频聊天和桌面分享功能的Demo，无需额外插件即可在浏览器中运行。码视

       一. 功能及支持平台

       该Demo具备以下功能：

       一对一语音视频聊天

       远程桌面观看

       客户端掉线后自动重连，源码网络恢复时重连成功

       支持的论坛操作系统包括：Windows、信创国产Linux（银河麒麟、频源频统信UOS）、码视weui c 源码Android、源码iOS、论坛Mac、频源频鸿蒙OS。码视

       CPU架构：X/X、源码ARM、论坛MIPS、频源频Loongarch。码视

       主流浏览器：Chrome、源码Edge、Firefox、Safari、浏览器、QQ浏览器等。

       APP套壳内加载Demo页面，同样可正常视频聊天。

       二. 开发环境

       服务端使用Visual Sudio ，C#语言；

       PC端Web：VS Code 1.，Vue 3框架；

       手机端Web：HBuilder 3.8.，uni-app（导出H5）。

       三. 运行效果

       Demo源码分为三部分：服务端、PC端Web和手机端Web。

       移动端Web运行效果包括：登录界面、已连接提示框、发起视频聊天、手机端不支持桌面分享但可观看PC端桌面。

       PC端Web运行效果包括：登录界面、显示对方摄像头或桌面。

       四. 服务端源码说明

       部署需使用HTTPS协议，服务端需使用WSS协议。本地测试无需准备SSL证书。

       服务端初始化代码需根据部署环境调整配置。

       五. Web端源码说明

       Web端包含移动端和PC端代码，逻辑基本相同。

       消息定义：定义种消息类型用于通信。

       自定义消息处理器：在登录成功后注册回调函数。

       一对一语音视频：用户间发送请求，对方选择同意或拒绝。

       桌面分享：发起和回应过程与语音视频类似。

       断网重连：网络中断时每5秒重试连接。

       六. 本地部署Web端

       移动端：通过HBuilder X运行uniapp项目。

       PC端：安装NodeJS，使用npm命令启动Vue3项目。

       七. 源码与测试

       PC版源码与手机版源码可下载。

       提供测试服务器，方便验证。最新区块挖矿源码

       通过本Demo，网页中实现视频聊天和桌面分享功能变得简单可行，满足多种平台与浏览器需求。

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分母。

流媒体客户端RTMP拉流保存h（flv保存为h）

       librtmp是通过调用int RTMP_Read(RTMP *r, char *buf, int size); 来拉取流，直接得到的流是flv格式，保存后即可播放。

       RTMP_Read内部调用Read_1_Packet，其功能是从网络上读取一个RTMPPacket的数据，RTMP_Read在此基础上增加了个字节的flv头。

       在librtmp的源码中，可以看到flv头信息。

       flv头实际只有9个字节，但为何是个字节？因为除了9个字节的flv头外，还有多个Tag，每个Tag的开头有4个字节表示上一个Tag的长度，即使是第一个Tag也需填充这4个字节，以匹配源码中的flvHeader。

       srs_librtmp是通过srs v2.0-r6版本（v2.0-r7版本加入了ipv6功能，但连接rtmp服务器时总是失败，可能是个人使用不当）来拉流并保存为flv文件。

       从srs导出的srs_librtmp客户端详情见github.com/ossrs/srs/wiki...，导出后，在research/librtmp下有作者编写的demo，其中srs_rtmp_dump.c用于从rtmp服务器拉流并保存为flv文件。

       以下是简化版的demo源码，我注释了自己的理解，若有错误请指正。在vs下此代码能编译运行，但在linux下能正常播放。

       主要讲述了flv头信息的结构，srs_librtmp源码中srs_flv_write_tag通过data封装成Tag并写入flv文件，srs_rtmp_read_packet读取的数据是flv文件中的tag data。

       Tag data分为Audio、Video、Script三种，这里仅讲解Video Tag Data。

       VideoTagHeader的第一个字节包含了视频帧类型及视频CodecID的基本信息。VideoTagHeader之后跟着的外汇反向加倍马丁源码编写是VIDEODATA数据，即video payload，对于H.格式的视频，VideoTagHeader会额外包含4个字节的信息。

       AVCPacketType和CompositionTime。AVCPacketType表示VIDEODATA的内容类型：若AVCPacketType为0，则为AVCDecoderConfigurationRecord（H.序列头）；若为1，则为一个或多个NALU（完整帧是必需的）。

       AVCDecoderConfigurationRecord包含H.解码相关的sps和pps信息，解码器在送数据流之前必须送出sps和pps信息，否则解码器不能正常解码。在解码器停止后再次开始之前，如seek、快进快退状态切换等，都需要重新送出sps和pps的信息。AVCDecoderConfigurationRecord在FLV文件中通常只出现一次，即第一个video tag，但有些视频流的sps和pps可能会发生变化，所以可能会出现多次。

       Composition Time用于告知渲染器视频帧进入解码器后多长时间在设备上显示。在flv格式中，timestamp用于告知帧何时提供给解码器，单位为毫秒。Composition Time告诉渲染器视频帧显示的时间，因此compositionTime = (PTS - DTS) / .0。

       总结如下：使用srs_librtmp拉流，拉取的数据为一个又一个的Tag Data，可通过type与宏值比较判断Tag Data是否为Video Tag Data。连接rtmp服务器拉流时收到的第一个Video Tag Data通常包含PPS和SPS信息。对于每个h编码的Video Tag Data，会多出4个字节的AVCPacketType和CompositionTime，其中CompositionTime用于B帧，这里暂时忽略它，我们仅支持P帧和I帧。Frame Type在h编码中只能是1或2，Frame Type == 1表示关键帧或包含PPS和SPS信息的Video Tag Data。CodecID在h编码中只能是7（AVC）。当AVCPacketType == 0时，Video Tag Data包含SPS和PPS信息；当AVCPacketType == 1时，为帧数据。

       获取PPS和SPS信息非常关键，如果不告知解码器，根本无法播放视频。我写了一段代码，虽然技术有限，但希望能帮助到您。

       AVCPacketType为1表示Video Tag Body的内容是NALU。Frame Type为1表示NALU内容是关键帧，Frame Type为2表示NALU内容是非关键帧。NALU的开头的4个字节表示NALU的长度（nalu_length），nalu_length之后是一个字节的nalu header。

       nalu header中nal_ref_idc表示优先级，帮企信息技术源码范围在~（2进制），值越大表示越重要。值指示NAL单元的内容不用于重建影响图像的帧间图像预测。对于nal_unit_type为6、9、、、的NAL单元，H.规范要求NRI的值应该为0。对于nal_unit_type等于7、8（指示顺序参数集或图像参数集）的NAL单元，H.编码器应设置NRI为（二进制格式）。nal_unit_type表示nalu类型，SPS开头是0x（nal_ref_idc为3，nal_unit_type为7），PPS开头是0x（nal_ref_idc为3，nal_unit_type为8），关键帧开头是0x（nal_ref_idc为3，nal_unit_type为5），非关键帧开头是0x（nal_ref_idc为2，nal_unit_type为1）。nal_unit_type为5表示idr帧，idr帧具有随机访问能力，所以每个idr帧前需要加上sps和pps。startcode起始码。

       H.原始码流由一个一个的NALU组成，其结构包括起始码（0x或0x，取决于编码器实现）和数据。具体何时使用3个字节的起始码，何时使用4个字节的起始码，这个我没有完全弄明白，资料中提到具体哪种开头取决于编码器实现。0x是NAL起始前缀码，解码器检测每个起始码，作为NAL的起始标识，当检测到下一个起始码时，当前NAL结束。同时H.规定，当检测到0x时，也可以表示当前NAL的结束。对于NAL中数据出现0x或0x时，H.引入了防止竞争机制，如果编码器检测到NAL数据存在0x或0x时（非起始码，而是真正的音视频数据），编码器会在最后个字节前插入一个新的字节0x，这样当遇到0x或0x时就一定是起始码了。解码器检测到0x时，把抛弃，恢复原始数据。因此，组装H的步骤如下：读取tag data并判断是否是video tag data，判断frameType和AVCPacketType，区分video tag data是AVCDecoderConfigurationRecord还是NALU，如果是AVCDecoderConfigurationRecord则解析PPS和SPS保存在内存中并加上startcode（我这里加的是0x），如果是NALU，则判断nal_unit_type（有些NALU的流比较奇怪，依然包含PPS、SPS信息，甚至还有SEI信息）。switch case根据不同的nal_unit_type来解析，并加上startcode。如果nal_unit_type == 0x，则是idr帧，需要加上PPS和SPS信息（即一个idr通常包含3个startcode，SPS一个PPS一个idr帧数据一个）。

       以下是完整代码：

       rtmpTo.h

       rtmpTo.cpp

       main.cpp

       原文链接：blog.csdn.net/qq_...

FFmpeg 集成 x 编译及解码

       x 是一个免费开源的视频编码库，支持 H./MPEG-H HEVC 格式，遵循 GNU GPL 许可证。

       为了在 FFmpeg 中集成 x，以支持 H. 编解码功能，需先编译 x。然而，并非所有 FFmpeg 版本都能直接使用 x，如在 Android、Windows 和 Linux 平台上使用 Android NDK re 时，可能会遇到符号缺失、无法编译 .S 文件等问题。

       一、x 的编译

       在进行编译前，请确保系统使用的是 Ubuntu .。编译目录结构应根据平台选择相应的目录，例如在 Windows 平台下使用 i 或 x_ 目录，Android 则使用 arm 平台的 armeabi-v7a 或 arm-v8a 目录。

       编译 x 时，使用特定脚本执行编译过程，如 `build_x.sh`，然后在同级目录下的 build 目录中生成编译产物。

       对于 Android 平台，需要使用 Android NDK re 的 Linux 版本。需要调整 `build_x.sh` 脚本中的内容，并修改 x 源代码以支持 NEON 处理。编译 x Release_3.5 版本时，可能遇到 fseeko 和 ftello 符号缺失的问题，这是因为 NDK re 中无法导出这些符号。解决办法是使用 x 2.6 版本，该版本能正常编译。

       在 Windows 平台上，可以使用 mingw-w-build 工具来搭建编译环境。对于 Linux 平台，仅需编译 x_ 版本。

       二、FFmpeg 集成 x 的编译

       在编译 FFmpeg 时，需对脚本进行修改以集成 x。这包括在 Linux 系统上增加特定差异点，确保 FFmpeg 能够成功利用 x 进行 H. 编解码。

如何调试H.代码?

       æˆ‘正在做这方面~时间有限，就按照我平时做的步骤来，不清楚的hi我~

       1、下载并解压 JM 源代码

       2、在源代码根目录下的 bin 文件夹中新建 backup 文件夹，将 bin 文件夹中所有文件移入该文件夹做备份

       3、在源代码根目录下新建 encodtest 文件夹，作为编码使用。将编码过程所需要的文件，例如：编码配置文件（encoder_baseline.cfg），待编码视频序列文件

       ï¼ˆforeman_part_qcif.yuv，对应为编码配置文件中 InputFile 参数的值）复制到该文件夹中

       4、在源代码根目录下新建 decodtest 文件夹，作为解码使用。将解码过程所需要的文件，例如：解码配置文件（decoder.cfg）复制到该文件夹中

       5、打开源代码根目录下的工作区 tml.dsw

       ç¼–码：

       6、鼠标左键选中 lencod 工程

       7、打开 Project -> Settings -> Debug ，在 Working directory 选项中填写 ./encodtest ，在 Program arguments 选项中填写需要使用的编码配置文件（要与第3步所复制

       çš„文件同名），例如：-d encoder_baseline.cfg ，然后确定修改

       8、鼠标右键选中 lencod 工程，选择鼠标右键菜单 Set as Active Project

       9、编译运行编码器，完成编码。这个时候会在源代码根目录下的 encodtest 文件夹中生成几个新文件，其中 test. （对应为编码配置文件中 OutputFile 参数的值）即为

       åŽ‹ç¼©ç æµæ–‡ä»¶

       è§£ç ï¼š

       ã€é¼ æ ‡å·¦é”®é€‰ä¸­ ldecod 工程

       ã€æ‰“å¼€ Project -> Settings -> Debug ，在 Working directory 选项中填写 ./decodtest，在 Program arguments 选项中填写需要使用的解码配置文件（要与第4步所复制

       çš„文件同名），例如：decoder.cfg ，然后确定修改

       ã€å°†ç¼–码生成的压缩码流文件 test. 复制到 decodtest 文件夹中

       ã€é¼ æ ‡å³é”®é€‰ä¸­ ldecod 工程，选择鼠标右键菜单 Set as Active Project

       ã€ç¼–译运行解码器，完成解码。这个时候会在源代码根目录下的 decodtest 文件夹中生成几个新文件，其中 test_dec.yuv（对应为解码配置文件中的第三个参数）即为解码

       æ–‡ä»¶

       å¦å¤–：

       å¯ä»¥ä¸ç”¨æ‰“å¼€ tml.dsw 工程，而直接打开单个工程，例如：打开 lencod.dsw 就可以进行编码，而打开 ldecod.dsw 就可以进行解码。单独打开工程所需要的设置与前述过程相

       åŒã€‚

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 不断丢弃视频帧，尤其是当视频比音频慢时，这种情况下缓存功能反而成为瓶颈。

优秀的 Verilog/FPGA开源项目介绍（十）- H.和H.

       H.是ITU-TVCEG在H.之后推出的新视频编码标准，它在保留H.某些技术的基础上，对相关技术进行了改进。H.采用了先进技术，以优化码流、编码质量、延时和算法复杂度之间的关系，旨在提高压缩效率、鲁棒性和错误恢复能力，减少实时延时和信道获取时间，降低复杂度。

       H.，即MPEG-4第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT）提出的高度压缩数字视频编解码器标准。H.的最大优势是其高数据压缩比率，在同等图像质量的条件下，其压缩比是MPEG-2的2倍以上，是MPEG-4的1.5～2倍。

       H.旨在在有限带宽下传输更高质量的网络视频，仅需原先的一半带宽即可播放相同质量的视频。这意味着，我们的智能手机、平板机等移动设备将能够直接在线播放p的全高清视频。H.标准也同时支持4K（×）和8K（×）超高清视频。

       H.与H.的不同之处在于，H.在H.的基础上进行了改进，包括帧内预测、帧间预测、转换、量化、去区块滤波器和熵编码等模块。H.的编码架构大致上与H.相似，但整体被分为三个基本单位：编码单位（CU）、预测单位（PU）和转换单位（TU）。

       复旦大学H./H.开源IP，包括H. Video Encoder IP Core，是由复旦大学专用集成电路与系统国家重点实验室（State Key Lab of ASIC & System，Fudan University）视频图像处理实验室（VIP Lab）范益波教授研究团队开发完成，并开放源代码。

       开源地址：openasic.org

       关于上板验证，网站上有相关的验证板卡代码，如下：

       github上的开源H.，开源地址：github.com/tishi/h...

       用verilog和system verilog编写，在FPGA板上用Xilinx ZYNQ验证，运行最高MHZ。

       内容：文件夹“src”包含所有解码源文件。文件夹“tb”包含测试台文件，ext_ram_.v使用axi3接口模拟ddr。文件夹“pli_fputc”是verilog pli，用于在运行模拟时将输出bin写入文件。

       使用方法：模拟：将所有测试平台和源代码文件添加到您的模拟项目源中，例如modelsim。将测试文件in.放到您的模拟项目文件夹中。然后运行，例如，对于modelsim，运行“vsim -pli pli_fputc.dll bitstream_tb”。输出是out.yuv和一些日志文件。

       在FPGA板上运行：将“src”文件夹中的源文件添加到您的FPGA项目中。顶部文件是decode_stream.sv。两个接口，stream_mem_xxx用于将H比特流馈送到解码器。

       github上的开源H.，开源地址：github.com/aiminickwong...

       无介绍

       说明：第一个项目由复旦大学专用集成电路与系统国家重点实验室（State Key Lab of ASIC & System，Fudan University）视频图像处理实验室（VIP Lab）推出，不论项目完成度还是文档说明，都非常详细，同时上面给的是该项目的论坛，论坛上有相关工作人员维护，活跃度很高，适合去学习使用。

       后面两个项目，碎碎并没验证过，但是感觉不怎么靠谱，README完整度不高，有兴趣的可以去看看。

       最后，还是感谢各个大佬开源的项目，让我们受益匪浅。后面有什么感兴趣方面的项目，大家可以在后台留言或者加微信留言，今天就到这，我是爆肝的碎碎思，期待下期文章与你相见。

       优秀的 Verilog/FPGA开源项目介绍（九）- DP（增改版）

       优秀的 Verilog/FPGA开源项目介绍（八）- HDMI

       优秀的 Verilog/FPGA开源项目介绍（七）- CAN通信

       介绍一些新手入门FPGA的优秀网站（新增2）

       优秀的 Verilog/FPGA开源项目介绍（六）- MIPI

       优秀的 Verilog/FPGA开源项目介绍（五）- USB通信

       优秀的 Verilog/FPGA开源项目介绍（四）- Ethernet

       优秀的 Verilog/FPGA开源项目介绍（三）- 大厂的项目

       优秀的 Verilog/FPGA开源项目介绍（二）-RISC-V

       优秀的 Verilog/FPGA开源项目介绍（一）-PCIe通信

WebRTC 源码分析——Android 视频硬件编码

       本文深入剖析了 WebRTC 在 Android 平台上的视频硬件编码机制。首先，回顾了 MediaCodec 的概念和基础使用，这是Android中用于处理音频和视频数据的关键组件。MediaCodec 支持编码（将原始数据转换为压缩格式）和解码（将压缩数据转换回原始格式），通常与MediaExtractor、MediaSync、MediaMuxer、MediaCrypto、MediaDrm、Image、Surface等组件一起使用。

       接下来，文章探讨了WebRTC 如何利用硬件编码器。通过 DefaultVideoEncoderFactory 和 HardwareVideoEncoderFactory 的交互，WebRTC 实现了 h 编码器的初始化和配置。在代码实现中，我们关注了 MediaCodec 的输入和输出缓冲区、编码器工作模式以及 MediaCodec 与 Surface 的关系，这些是理解整个编码流程的关键点。

       在编码器初始化的部分，通过 DefaultVideoEncoderFactory 的 createEncoder 函数，实例化了 HardwareVideoEncoder。调用栈显示，这一过程主要在 native 端完成，通过 jni 调用 Java 端代码来获取当前设备支持的编码器信息。

       编码数据送入编码器的过程涉及到 VideoEncoder 接口，WebRTC 使用 HardwareVideoEncoder 实现了这一接口，利用 MediaCodec 进行编码。通过 EglBase 和 OpenGL ES 的集成，WebRTC 将 VideoFrame 对象转换为与 MediaCodec 关联的 Surface 的纹理。这一过程确保了编码器接收到了正确的视频数据格式。

       获取编码后的数据时，WebRTC 使用 MediaCodec 的同步模式进行获取。当数据可用时，通过 callback.onEncodedFrame(encodedImage, new CodecSpecificInfo()) 方法告知引擎，引擎负责进一步处理编码后的帧，如封装 RTP 包和发送到对端。

       码流控制方面，WebRTC 包括拥塞控制和比特率自适应两个主要方面。当比特率发生变化时，WebRTC 会调用 VideoEncoder.setRateAllocation() 方法来更新比特率。在编码过程中，通过特定的代码逻辑来判断并调整当前的码率与所需码率是否匹配，以适应网络条件的变化。

       本文以几个疑问的方式从源码角度详细解析了整个编码流程，包括从 MediaCodec 的创建和配置、视频数据的编码到编码后的数据获取和码流控制等关键步骤。通过深入分析，希望读者能够更好地理解 WebRTC 在 Android 平台上的编码技术。

       为了进一步加深对 Android 音视频核心知识点的理解，推荐访问以下链接：/Ei3VPD。