NotionNext BLOG

Win11+ VS2022编译 FFmpeg6.0 静态库

Thu, 17 Aug 2023 00:00:00 GMT

编译前言

编译作为自己持有的稳定版本用来练习

网上有使用cygwin版本，在把ffmpeg作为静态库依赖的时候要添加iconv等其他的库，非常麻烦，有很长的打包链条，编译出来的库不能独自成军。

网上其他的编译环境也太杂太乱了，目前有个开源项目致力解决ffmpeg编译的问题，暂时拿来用，如果这个项目不维护或者坏了，再考虑其他。

为什么编译ffmpeg？

编译作为自己持有的稳定版本用来练习ffmpeg的一些方法，音视频同步等操作。

前期准备

使用github 上开源项目的解决方案编译 ShiftMediaProject

环境配置

先创建代码目录，作者建议的。

进入source目录打开git bash 克隆代码

这里因为我已经git 拉到本地过了，所以报错，不影响。

ffmpeg外部库

代码拉取完毕后，如果一切顺利，/vs2022/source/FFmpeg/SMP目录可以查看readme.txt，里面介绍了如何编译配置整个项目，包括外部库：x264、x264、vpx等，可以使用脚本下载，路径

vs2022\\source\\FFmpeg\\SMP\\project_get_dependencies.bat,感兴趣可以看一下他这个bash脚本，它会按照脚本中配置的外部库名字

按顺序

拉取。如果万一下载失败，可以根据输出日志跟脚本内容排查问题，手动下载或者重新运行脚本。运行情况如下：

好了经过漫长的下载与数次执行./project_get_dependencies.bat

,所有的库也都下下来了。

额外的编译选项-for渲染

根据readme.txt先在/vs2022/msvc/下创建include目录，include里创建gl、AMF两个目录，用来放opengl、nv-codec、AMF的头文件。

opengl (需要glext)

a. OpenGL-Registry\\api\\GL\\ 里的glext.h跟wglext.h放入 /vs2022/msvc/include/gl/中

b. EGL-Registry\\api\\KHR 将KHR整个文件夹放入/vs2022/msvc/include/下

ffnvcodec (需要nv-codec-headers)

a. nv-codec-headers\\include里的ffnvcodec目录复制到/vs2022/msvc/include

AMF sdk头文件

a. AMF\\amf\\public\\include里的两个文件夹复制到/vs2022/msvc/include/AMF中

编译工具链

配置 NASM、YASM,这两个是汇编的编译工具

nasm

yasm

同样我们查看脚本可知它会根据不同VS的大版本去做适配安装，我们的是VS2022,vs17，如果有报错可以往这方面去排查。执行安装

开始编译

到这一步，所有的准备工作基本完成，打开工程文件

step1. 选择编译类型 Debug/Release Dll/lib

这里我们先选择的Debug,因为只是练习用，需要调试什么的。接下来就是直接生成了，生成时间稍微有点长，我这里10分钟左右，而且中间果不其然出现了错误。让我们来分析一下：在libavcodec 编译的过程中提示找不到好几个宏都是NV_ENC_PARAMS打头的，我们找一下他的同类型,大概是这么一个枚举类型

，这里我们替换一下ffnvcode的版本，退回到5月份的版本，跟ffmpeg6r1保持一致

重新生成就能成功了。

lib库在`/msvc/lib/x64下面，我们可以看到生成的各种lib库

step2. 打包SDK

把上述生成的include、lib打包带走，直接放到应用的项目下就可以直接用了

验证

结果如下，我们在这里输出了ffmpeg的编译配置，可以看到其他的一些基础库都是enable的状态，说明都编进去了，本次编译宣告成功。如需要在项目中使用到这些外部库诸如x265之类的，在项目中加上这些库的lib连接就可以。

结尾

如果上述方式失效了，要回到手动编译配置的老路子，脏路子，也不用慌，相信经过这些配置编译的历程，作为老手，相信诸君也能轻松应对，处变不惊，将正确的东西放到正确的篮子里面。

最后，感谢你的阅读，若能带来些许启发就更好了，与君共勉。

参考链接：

1.CSDN令狐掌门

2.Shift Media Project

3.FFMPEG官方git仓库

RTP的H264载荷分析

Mon, 17 Jul 2023 00:00:00 GMT

RTP Header解析

V：RTP协议的版本号，占2位，当前协议版本号为2

P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。

X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头

CC：CSRC计数器，占4位，指示CSRC 标识符的个数

M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

PT: 有效荷载类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。

序列号(sequence numbers)：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。

时戳(Timestamp)：占32位，必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

取一段码流如下：

其中 80 是V_P_X_CC e0 是M_PT 00 1e 是SequenceNum 00 00 d2 f0 是Timestamp 00000000 是SSRC 把前两个字节换成二进制如下 1000 0000 1110 0000 按顺序解释如下: 10 是V；

0 是P； 0 是X； 0000 是CC； 1 是M； 110 0000 是PT;

RTP载荷信息

RTP载荷H264码流

载荷方式有三种

单个NAL单元包荷载中只包含一个NAL单元 NAL头类型域等于原始单元类型 1-23。
聚合包聚合多个NAL单元到单个RTP荷载中，单元类型是24,25,26,27。
分片单元分片单个NAL单元到多个RTP包，FU-A, FU -B,单元类型28-29。常用的打包时的分包规则是：如果小于MTU采用单个NAL单元包，如果大于MTU就采用FUs分片方式。

常用的打包方式就是单个NAL包和FU-A方式。

单个NAL单元包

定义在此的NAL单元包必须只包含一个。这意味着聚合包和分片单元不可以用在单个NAL单元包中。并且RTP序号必须符合NAL单元的解码顺序。NAL单元的第一字节和RTP荷载头第一个字节重合。打包H264码流时，只需在帧前面加上12字节的RTP头即可。

分片单元(FU-A)

分片只定义于单个NAL单元不用于任何聚合包。NAL单元的一个分片由整数个连续NAL单元字节组成。每个NAL单元字节必须正好是该NAL单元一个分片的一部分。相同NAL单元的分片必须使用递增的RTP序号连续顺序发送(第一和最后分片之间没有其他的RTP包）。相似，NAL单元必须按照RTP顺序号的顺序装配。

当一个NAL单元被分片运送在分片单元(FUs)中时，被引用为分片NAL单元。STAPs,MTAPs不可以被分片。 FUs不可以嵌套。即, 一个FU 不可以包含另一个FU。运送FU的RTP时戳被设置成分片NAL单元的NALU时刻。

表示FU-A的RTP荷载格式。FU-A由1字节的分片单元指示（如图5），1字节的分片单元头（如图6），和分片单元荷载组成。

S: 1 bit 当设置成1,开始位指示分片NAL单元的开始。当跟随的FU荷载不是分片NAL单元荷载的开始，开始位设为0。

E: 1 bit 当设置成1, 结束位指示分片NAL单元的结束，即, 荷载的最后字节也是分片NAL单元的最后一个字节。当跟随的 FU荷载不是分片NAL单元的最后分片,结束位设置为0。

R: 1 bit 保留位必须设置为0，接收者必须忽略该位

打包时，原始的NAL头的前三位为FU indicator的前三位，原始的NAL头的后五位为FU header的后五位。取一段码流分析如下：

前12字节是RTP Header 7c是FU indicator 85是FU Header FU indicator（0x7C）和FU Header（0x85）换成二进制如下 0111 1100 1000 0101 按顺序解析如下： 0　　　　是F 11　　　　是NRI 11100　　是FU Type，这里是28，即FU-A 1　　　　是S，Start，说明是分片的第一包 0 是E，End，如果是分片的最后一包，设置为1，这里不是 0 是R，Remain，保留位，总是0 00101 是NAl Type，这里是5，说明是关键帧（不知道为什么是关键帧请自行谷歌）打包时，FUindicator的F、NRI是NAL Header中的F、NRI，Type是28；FU Header的S、E、R分别按照分片起始位置设置，Type是NAL Header中的Type。

解包时，取FU indicator的前三位和FU Header的后五位，即0110 0101（0x65）为NAL类型。

win11 编译webrtcM109 for Windows

Thu, 27 Jul 2023 00:00:00 GMT

WebRTC编译库一览

平台	目标平台	编译产物
Android	armeabi-v7a、 arm64-v8a	.so静态库
iOS	armv7、 arm64	.a静态库
Windows	x86 、x64	.lib静态库
Linux	多种平台	.a静态库

系统要求

系统要求

具有至少8GB RAM 的 64 位 Intel 机器。强烈建议超过 16GB。
NTFS 格式的硬盘驱动器上至少有 100GB 的可用磁盘空间。FAT32 不起作用，因为某些 Git 包文件大于 4GB。
适当版本的 Visual Studio，如下所述。
Windows 10 或更新版本。

Windows 设置

这里谷歌要求最好是VS2022(>17.0.0) 必须勾选如下几项：

Desktop development with C++组件中10.0.20348.0或10.0.22000.0(win11)以上的Win10 SDK（如果没看到该版本，去左侧Individual components那里勾选）

使用C++ 进行桌面开发组件

MFC/ATL 支持子组件

安装完VS2022后，必须安装SDK调试工具。打开控制面板->程序与功能，找到刚才安装的最新Windows Software Development Kit（比如10.0.20348.0），鼠标右键->修改

勾选Debugging Tools For Windows，然后点击修改。

下载源码

获取depot_tools git clone > 将depot_tools的路径加入系统环境变量Path，然后移到最前面(避免已安装的python与git造成影响)。

获取WebRTC源码需要设置代理。

打开windows命令行

如果一切顺利的话，这里应该可以看到已经在开始下载各部分内容。
如果有其他问题，可以仔细看下报错内容然后根据相应内容解决。

可参考：

1.cipd.bat中修改powershell 为pwsd powershell5 跟powershell7 的执行程序变了

2.修改depottools中 /.cipd_bin/3.8/bin/Lib/subprocess.py 735 __init__中 shell=True

这一部分需要等待很久，代理及网速良好的情况下短则1-2小时，长则数小时仍没有明显变化，内容较多的部分是在../src/third_party(12.5G左右)，所以最好保持电脑在下载期间不休眠或者关机
如果有部分内容获取较慢或者持续卡住的话，可以ctrl + c,然后 gclient sync继续同步。

`开始编译`

打开x64 nativve tools vs2022

生成VS工程文件，之前有些准备步骤需要在命令行输入，确定编译环境。

`本机编译需要的命令`

-ide=vs 使用gn ninja 生成vs工程编译好之后如果在vs中无法直接运行而且报错找不到Ninja.exe 将ninja.exe 放到用户变量中

编译时需要使用clang的编译器
如果 Visual Studio 应用没配置 Clang 编译器，链接这个 webrtc.lib，生成工程文件时需要配置如下参数：

还需要禁用webrtc内部使用的stdcxx库(这一部分编译有点困难，经常报错)

如果需要添加ffmpeg_H264则必须打开clang编译器

//ffmpeg_h264支持功能

is_debug=false

use_custom_libcxx=false 是否使用内置的libcxx作为默认的c++标准库

rtc_include_tests=false

is_component_build=false 是否使用动态运行库 false表示使用静态运行期库 Release版本对应MT，Debug版本对应MTD

symbol_level=0 裁剪包

proprietary_codecs=true H264

rtc_use_h264=true 是否使用H264。注意Windows平台编码使用OpenH264，解码使用ffmpeg

ffmpeg_branding=\\"Chrome\\" ffmpeg的分支名，采用Chrome的分支

is_clang=true

use_lld=false

treat_warnings_as_errors=false

`错误点1`

5414版本可能会报这个错误，按照错误提示修改一下就行。
修改源码的std::towupper 为::towupper

`错误点2`

build/toolchain/win/tool_wrapper.py
提示unicode utf8错误   在对应的文件内将utf8字样修改为gbk

就可以在 out/vs2022_m109_x64_release_ffmpeg_h264下面找到VS工程文件了。

`引用WebRTC库`

WebRTC编译后会在src\out\Default\obj目录下生成整个WebRTC工程的静态库：webrtc.lib，就这个是完整的包，如果只想编译部分也是可以的。

`参考`

[1] https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md



WebRTC Native添加H264+OpenSSL支持
Tue, 06 Jun 2023 00:00:00 GMT
😀
给WebRTC静态库在Windows下使用增加一些支持内容：
在Windows下使用WebRTC.lib完成PeerConnection的通话，代码写完之后，发现程序虽然通了，但是It dosn’t work! 通过追查，发现是一个简单的问题，WebRTC在Windows 下默认使用的是VP8编码格式，而我们使用的服务器选择的是H264编解码，在SDP信息交换中的格式对不上，所以，需要在编码时给WebRTC指定一下编码格式。
 
📝WebRTC Windows版编译(添加H264+OpenSSL支持)
概要：
版本配置信息
配置名称 版本 介绍
WebRTC版本 M109 //5414
Windows win11 ㅤ
H264 chrome 主线版本
OpenSSH 3.0.8 ㅤ
因为在现有业务环境下，需要HTTPS,当前的工具链是libcurl +openssh + webrtc，而webrtc中其实有自己的openssh分支，叫boringssl，但是如果使用了这个谷歌版本的boringssl，会引起库冲突，试想一下，同样的一个库但是确是不同名字。
为什么需要添加H264支持
 


WebRTC封装静态库
Tue, 06 Jun 2023 00:00:00 GMT
📥WebRTC封装桌面采集功能
 
简介
本文用于记录在Win11环境下，封装WebRTC-Native-M109版本的动态库调用库的过程。
环境
win11
WebRTC M109
正文
本次编译工作是基于成功使用WebRTC推流桌面到SRS服务器的Demo，将屏幕共享功能独立抽离出来，也为以后动态编译其他模块的工作打个底。
话不多说
Step1. 编译通过封装项目
Step2.封装库需要注意的点
C/C++ 不同封装的区别 [[深入静态库、动态库]]
几条代码之间的区别 函数调用方式 __stdcall跟__cdecl 参考 [[函数调用方式 __stdcall跟__cdecl详解]]
这里得到的结论之一是如果你的程序中没有涉及可变参数，最好使用__stdcall
遇到的问题以及思考
        编译过程中，有一个问题困扰了我一段时间，就是一个网络类的信号槽无法响应。具体情况是这样，在Qt的主线程中有一个调用类A，它负责调用SDK中封装的C风格函数，我在A的一个方法中使用lambda调用SDK函数创建了一个Controller,然后在A->First 方法中调用SDK::CreateDomain,并把A::FirstCallback作为回调传入了CreateDomain中，并且SDK把回调存储起来，在经过一段时间后，SDK::GetMessage获得了讯息，开始调用A::FirstCallback，我在FirstCallback中使用了网络请求，但是槽函数始终无法响应，但是把它单独拎出来发放在主线程执行也可以得到响应。做让我们来梳理一下。见下列代码。
 
main.h
    
      这里使用了一个技巧 ，因为在库函数中定义的SDK::SetCallback的回调函数 是纯函数指针，把A的普通成员函数作为回调是不行的，因为不存在 从类的成员函数的指针直接转化成函数指针的隐式转换，所以这里我们面临有几个选择
1: 手搓一个转化方法，让这个类成员函数指针转化成对应的函数指针，这很麻烦，而且不一定能实现，我放弃。
2：使用static 修饰另一个函数，当然，使用static修饰之后 ，这个函数就不属于这个类了，具体细节参考static深入理解，然后在这个static函数中调用原本的想要调用的A::FirstCallback，这相当于一次桥接。这样实现也不是很优雅，函数调来调去看上去比较凌乱。暂时放弃。
3：使用喜闻乐见的lambda委托一下，跟第二种其实很类似，但是lambda可以直接被传入当作参数，更方便与高效，笔者正是使用的这个方式。

class_a.h
       那么从现在开始，函数执行栈执行到了SDK::SetCallBack，我们知道，被调用的函数运行结束后当前帧全部收缩，回到调用者的帧,而在这里，我们使用的是匿名函数，他其实在传入的时候是作为闭包对象，并且分配在堆上，并没有传入函数调用栈，栈上只保存了必要的帧信息。
![[Pasted image 20230601103935.png]]
HttpManager 是一个继承自QObject的单例类
http_manager.h
sdk.h
重点来了，此时，我们执行到了SDK::SetCallback,而SetCallback中给固定的一个session对象设置了回调函数，那么此时，通过闭包就已经传递到了sdk库内的session对象中，然后在SetCallback中通过特定的事件机制，通过线程异步延迟在OnCall得到了响应，此时OnCall是在SDK函数内部的子线程内，因此，在OnCall内部调用的ses_->mfirst_callback((void*)_ses_,message.c_str(),ses->mfirst_callback_usr_); 自然也是在子线程的函数调用栈上！，线程有自己独立的函数调用栈，理解这一点尤为重要。那么回到调用，在这个子线程中，回到了A的函数A::FirstCallback上，我们再回顾一下这个函数，
此时一切正常，顺利走入HttpManager->postRequest()中，并传递了一个闭包给HttpManager作为回调保存下来。
但是，所有的消息在m_accessManager Post请求出去之后石沉大海，没有响应。
一开始笔者排除了几个方向
HttpManager的构造函数接受了调用者作为父类对象，而它的成员对象 m_accessManager把调用者作为父类对象，因此执行Post请求跟需要接受的槽函数类不在同一个线程，所以只要将Connect申明成跨线程调用就可以了？ 但是证实无效
使用笔者总结的另外一套常用的网络模型，核心方法是moveToThread,通过Controller来控制内部线程的一切I/O请求，所有参数通过信号槽传递。 这套方法可以是可以，但是信息部分都是通过信号槽来传递的，我有意的在新的网络模型中寻求更高效的方式，所以这套作为备用。
其他的方法都太过于黑魔法，确实可行，但是不适合在项目工程中使用，比较破坏编程规范，这里也不再赘述。
还有两个方向，手搓事件类使用Qt自带的跨线程异步回调相关的类 QEventLoop或者QInvoke,写代码的时候不宜尝试过多，项目中能用且可控是第一要义，需要快速产出，所以使用了QEventLoop。把FirstCallback内部包起来，形成一个loop,lambda闭包回来的时候因为loop没有退出，所以m_accessManager 的槽函数能响应到。这样确实可行，但是有个问题，eventloop会阻塞主线程，也就是Ui线程，但是这里使用起来确实是没问题的，渲染会在另外的线程中执行，这里只是不能退出。
一点思考：
所以前面的问题，大概方向是，QNetworkAccessManager 对象所在的线程与接收信号的对象不在同一个线程，可能会导致信号无法正确触发。但是其实都是基于QObject,connect函数设置成异步调用，为什么不能触发这一点还没有特别清楚。还有它的生命周期应该是全局的，但是生效条件比较苛刻，这一点可能跟SDK库中的环境也有关。
写在最后
代码中需要有I/O对象的时候，需要特别关注对象的生命周期
对于回调函数需要谨慎使用，使用者应该明确内部对象的生命周期，确实很容易出现线上问题。
学无止境~


如何理解协程-以st-thread为例
Tue, 11 Jul 2023 00:00:00 GMT
如何理解协程
协程相比之与进程、线程，更像是用户自己实现的库函数，是在操作系统之上的操作，保存堆栈上下文信息。
二.进程、线程、协程三者的上下文切换比较
ㅤ 进程 线程 协程
切换者 操作系统 操作系统 用户（编程者/应用程序
切换时机 根据操作系统自己的切换策略，用户不感知 根据操作系统自己的切换策略，用户不感知 用户自己的程序决定
切换内容 页全局目录，内核栈，硬件上下文 内核栈，硬件上下文 硬件上下文
切换内容的保存 保存于内核栈中 保存于内核栈中 保存在用户自己的变量（用户栈或堆）
切换过程 用户态 - 内核态 - 用户态 用户态 - 内核态 - 用户态 用户态（没用进入内核态）
切换效率 低 中 高
ㅤ ㅤ ㅤ ㅤ
协程的利与弊
代码风格更易于理解，代码复用更方便
协程最大的问题就是无法利用CPU多核
协程应用场景
一个线程内的多个协程是串行执行的，不能利用多核，所以，显然，协程不适合计算密集型的场景。协程适合I/O 阻塞型。
I/O本身就是阻塞型的（相较于CPU的时间世界而言）。就目前而言，无论I/O的速度多快，也比不上CPU的速度，所以一个I/O相关的程序，当其在进行I/O操作时候，CPU实际上是空闲的。
我们假设这样的场景，如下图：1个线程有5个I/O的事情（子程序）要处理。如果我们绝对的串行化，那么当其中一个I/O阻塞时，其他4个I/O并不能得到执行，因为程序是绝对串行的，5个I/O必须一个一个排队等待处理，当一个I/O阻塞时，其它4个也得等着。
关于 State-Thread 的一个问题思考
关于st源码分析-运行协程文章 阅读中的一个思考，文中指出 State-Thread 在执行restoreWork的时候，在内部封装recevfrom,函数，主要是在idle主协程中，判断切换所有协程的sendto，发送域名查询请求后，再切换到idl来进行阻塞，其根本原理同手动执行所有sendto,再执行select/epoll一样，只是协程的st_sendto跟st_recvfrom看起来是顺序执行的。
如果说state thread  协程其实本质是对系统的select /epoll 进行封装的话，那么在什么时候进行切换是由库决定还是必须人工想好每个切换点，然后利用协程的切换去做这个事情。
除了 idle 协程，其他所有协程做的事情都是对于 在 系统线程 看来都是非阻塞，非阻塞协程干的话，就是把 需要监听的 fd 放进去全局变量 fd_set，然后由 idle 协程 执行 select() 函数阻塞，等待信号。ST的调度策略是 _ST_RUNQ 里面已经没有协程要运行了，才会切换到 idle 协程来阻塞。
State-Thread——Sleep
由于协程实际上是在单线程中运行，如果需要sleep而调用系统的sleep或者usleep的话会阻塞整个线程，所以协程内部需要实现自己的sleep, state-Thread是这样做的：
st_usleep(st_utime_t usecs)
_st_idle_thread_start(void *arg)
通过 引入一个协程状态 ST_ST_SLEEPING
将a协程加入SLEEPQ队列中，然后使用_ST_SWITCH_CONTEXT()切换其他协程，此时协程a的状态相当于挂起
在最终的_st_idle_thread_start()中，通过_st_vp_check_clock()处理所有进入_ST_ST_SLEEPING状态的协程，通过比对a协程加入SLEEPQ队列的时间值是否满足睡眠时间来做出下一步决断。
State-Thread——协程通信

配置名称	版本	介绍
WebRTC版本	M109	//5414
Windows	win11	ㅤ
H264	chrome	主线版本
OpenSSH	3.0.8	ㅤ

ㅤ	进程	线程	协程
切换者	操作系统	操作系统	用户（编程者/应用程序
切换时机	根据操作系统自己的切换策略，用户不感知	根据操作系统自己的切换策略，用户不感知	用户自己的程序决定
切换内容	页全局目录，内核栈，硬件上下文	内核栈，硬件上下文	硬件上下文
切换内容的保存	保存于内核栈中	保存于内核栈中	保存在用户自己的变量（用户栈或堆）
切换过程	用户态 - 内核态 - 用户态	用户态 - 内核态 - 用户态	用户态（没用进入内核态）
切换效率	低	中	高
ㅤ	ㅤ	ㅤ	ㅤ