![2f03e22be85e704dc33a64dfa99a5312.png](https://i-blog.csdnimg.cn/blog_migrate/4dbd4d917af2080b4c761dce32155ed8.jpeg)
现开源一个项目
oeipgithub.com项目实现的功能Demo展示
![0972cc14764ea4cbb7b698c8a8a39e1d.png](https://i-blog.csdnimg.cn/blog_migrate/c35074aa44788367d7cbfa748ea78ba9.jpeg)
这个项目演示了在UE4中,接入摄像机通过OEIP直接输出到UE4纹理上,并直接把UE4里的RenderTarget当做输入源通过OEIP里GPU管线处理后推流出去,而另一边Unity3D也是把RenderTarget当做输入,用OEIP处理后推流,经过OEIP封装signalR技术的直播SDK通知,二边各自拉另一边的流并通过OEIP相应管线直接输出到Texture2D并显示出来。演示的机器配置是i5-7500,8G内存,有二个推1080P,拉1080P流的处理,再加上生成截屏视频和yolov3-tiny神经网络识别,所以CPU有点吃不消。
这是我个人验证一些技术所搭建的DEMO级方案,接入了基本的普通摄像头处理,也没有提供稳定的直播供应商的实现,一些基本的图像处理,推拉流也只支持422P/420P格式。但是我自己还是花了大量业余时间在这方案上,并以及大热情来完善,不过业余时间毕竟有限,测试不完善,加上本人C++不是太熟悉,所以肯定有很多隐藏问题,欢迎指出问题,更欢迎提交修改。
本项目重点主要在图像处理并与游戏引擎的对接上,主要实现与游戏引擎对接更少的性能消耗,方便引入各种图像处理,包括相关神经网络图像处理,余下处理都是结合网上代码加上测试完善逻辑。毕竟这个项目开始只是想验证DX11比CUDA的GPGPU计算资源占用高是不是因为线程组的分配方式,后来想着用神经网络层的做法来搭建相关逻辑,方便用来做测试一些算法。双十一腾讯的云服务器打折,一时手痒就买了台,现在不是直播很火吗,再加上对云游戏的概念感兴趣,本人在工作过程也接入过二个商业的直播SDK,通过接入SDK自己思考下流程,发现做一个技术验证性的DEMO还是比较容易的,所以也就有了这个项目。
本项目暂时只考虑WIN平台,但是框架从开始就考虑从多平台扩展,后面熟悉别的平台相关知识后,会把相应功能补起。
特点:
- 1 与游戏引擎UE4/Unity3D方便接入,引擎里的纹理可以直接传入传出。
- 2 图像处理现支持CUDA/DX11,图像处理管线可以直接输入输出DX11纹理,可以做到不需要CPU/内存做图像中转,提高效率。
- 3 图像处理管线类似神经网络框架的图像处理层设计,并且可以动态打开与关闭某层,方便组合。
- 4 方便接入各种神经网络框架处理,项目上面集成yolov3(darknet),可以方便对比别的神经网络框架接入。
- 5 使用Media Foundation采集图像设备,WASAPI采集麦与声卡。
- 6 用signalR搭建直播SDK,配合nginx管理推拉流,使用ffmpeg编码解码推流拉流,设计支持多推流多拉流。
- 7 有一些同学找我要过我原来写的CUDA grabcut实现,我是感觉效果不好也没有商用价值,这次也集成在上面,要的可以去找相应实现自己改进。
- 8 结合后面5G,有4K,8K图像处理的,这种所有计算都用GPGPU来完成的应该有更多可能。
大致内容如下。
- 1 OEIP框架设计
- 2 GPGPU图像处理
- 3 采集音视频数据
- 4 FFmpeg编解码与推拉流
- 5 直播服务器设计
- 6 Unity3D插件
- 7 UE4插件
1OEIP框架设计
和一般直播SDK类似,分为设备采集,图像/音频处理,编码,推流,服务器通知与分发,拉流,解码,图像显示这几步。
方案中,核心项目oeip定义上面模块的各个功能接口,插件模块化,图像处理层的设计。
图像处理层采用类神经网络实现,层之间可以互相结合,层支持多输入与多输出,可以方便扩展成别的GPGPU方案,现在主要是CUDA与DX11实现,CUDA模版添加与神经网络Darknet的集成,后续会引入别的神经网络框架集成图像处理。
关联项目:oeip
2 GPGPU图像处理
在游戏引擎里,想设计各种图像处理说方便也方便,说麻烦也很麻烦,说方便就是因为如果你想实现的功能在这个框架下,那很简单,嗯,UE4下如果要集成自己的Compute shader还是有点麻烦,复杂点我想引入抠图相关算法,会发现各种麻烦,以及如果想引入 神经网络框架的处理更是复杂,由此我想实现一个能支持CPU数据输入,也支持引擎里GPU数据直接输入,支持CPU数据输出,也支持直接把处理的GPU显存结果返回给游戏引擎,脱离实际游戏环境,只关注本身的逻辑实现。
最开始,并没有输入层与输出层的设计,但是有几个问题,如在DX11中,让所有层以纹理流通,而传入与传出的CPU数据与纹理长度不一定对应是其一,其二封装内存/显存处理,显存外部上下文与Oeip处理的上下文不同线程切换等,三是并不好处理多输入与多输出,中间层输出等各种问题,所以加入输入与输出层,这二层本身并没任何逻辑,专门用来解决上面的问题。
在GPU算法中,一是善用一些多线程的算法,如跨线程组步长的循环,以及线程组内二分操作,尽可以同时多利用线程组内所有线程。二是多利用共享显存,注意这个大小有限制,如果你把太多数据放进去,可能会起反作用。三是GPGPU线程组的划分也比较重要,如果出现几个线程同时访问或是读取某个显存地址,不管需要同步不,都不算太好的方式,情愿一个线程读写多个显存地址。四是可以在CPU确认判断可以先编译成不同GPU代码,如HLSL可以通过加入宏定义编译,而CUDA可以利用模版。五减少与CPU的数据交互,如1080P的数据下,上传与下载到显存的时间大约是你做一次基本图像处理的十倍左右,我认为的理想方法,要么是从CPU数据读入,然后所有处理在GPU,并通过引擎显示,或是数据就在GPU上,图像处理最后一步交给CPU传输用,或是从GPU来,GPU处理后再还给GPU,中间但凡出现多次CPU-GPU的交互不如考虑方案的合理性。
关联项目:oeip-win,oeip-win-cuda,oeip-win-dx11
天天不在:CUDA版Grabcut的实现zhuanlan.zhihu.com![b2f15b8cb470cf820be0fdd51d4f2e3a.png](https://i-blog.csdnimg.cn/blog_migrate/3212ef4f620f2e24c82bb5e8bb40e40f.jpeg)
![ed36d3414b2ed34da35405e74ea55375.png](https://i-blog.csdnimg.cn/blog_migrate/72d5b4b5d8e8db7b47788d1549f8effb.jpeg)
3 采集音视频数据
这个没什么好说的,采集图像视频用的是Media Foundation技术,大约有几点,一是读不管异步还是同步,数据读取都应该放在非主线程中,用异步读自己不需要开,用同步自己管理线程,但是需要注意设备关闭时,确保相应数据流线程最好同步调用线程关闭,免的数据状态不正确。二是避免CPU处理数据,直接读取设备所支持的原生格式,如NV12(YUV420SP),YUV422I,我们在GPGPU图像处理层里有相应的YUV/RGB层,层里采集设备常用的NV12,YUV420I,BGR,YUV422I等都支持,当然传输用的YUV422P,YUV420P也是支持的,相应的CUDA/HLSL代码都有.三是我以前采过的坑,采集设备就是采集数据,他本身不应该和数据处理绑在一起。
音频采集用的WASAPI技术,处理没用Media Foundation,重采样,混音用的FFmpeg,音频采集主要是麦与声卡这二部分,麦还好,声卡处理需要注意静音的处理,别的跟着网上的代码来就行。
关联项目:oeip-win-mf,oeip-ffmpeg
4 FFmpeg编解码与推拉流
现在直播相关比较火,并且结合现在网络情况可以做很多原来想不到的事情,云游戏这种原概念产品感觉有完善的可能了,我今年也学了些FFmpeg相关知识用来储备。
推流前,数据处理后需要编码,主要用来压缩数据,可以说是超强的压缩率,在这只结合网上代码完善了H264与AAC这二种视频与音频编码方式,推拉流使用RTMP协议。
而拉流就是把上来的拉到的H264/AAC数据解码得到YUV/PCM固定格式后固定大小的数据,然后自己处理。
主要代码都是参照网上部分,然后整合,其中感觉主要是FFmpeg各种资源的销毁比较麻烦,比如要动态更新编码格式,重采样混音都有FFmpeg中间重用的资源,结合std::unique_ptr可以自定义销毁函数与模板,写出C#的感觉,省了我不少脑力与代码。
关联项目:oeip-ffmpeg
天天不在:音视频开发-FFmpegzhuanlan.zhihu.com5 直播服务器设计
直播服务器简单来说,就是通知一组成员之间消息流通,比如张三李四王五,张三上来了,李四推流了,王五关闭推流了等等这些消息,都需要及时通知这组里的所有成员,每个成员根据需求来对各种消息做各种处理。
直播服务器通信方案我选择的signarR,我对C#相关的技术熟悉点。
这只是一个非常简单的设计,主要分为三方,一是SDK调用方,也就是上面的张三李四王五他们,二是直播服务器,管理上面的各种通知,三是媒体服务器,管理推拉流的音视频数据。三方是可以分开放的,不过现没有丢桢方案,SDK调用方最好和媒体服务器在同一局域网效果会比较好。
相关流程简单来说,先打开直播服务器,然后打开媒体服务器,这样直播服务器就知道了所有的媒体服务器,然后SDK调用方连接直播服务器后,直播服务器返回给SDK调用方相应的媒体服务器地址,这样SDK调用方推流后就知道向那个媒体服务器的地址推流并记录下来,然后别的用户进来,就通知别的用户已经有别的用户推流了,并返回相应的推流地址,然后就可以拉流的,当然这个用户推流了,也需要返回相应推流地址给前一个用户。
注意事项,signalR 现在也是类似ASP net core里的一个中间件,在这为了直播服务器是否成功打开,我也写了个简单的中间件验证是否能成功连接服务器,打开服务器就会返回结果,在这中间件处理的是每个请求,每次请求都会生成一个HUB对象,这样导致相应的HUB里面绑定事件话,会累加,所以并不是一个好的选择,可以用GlobalHost返回这个HUB逻辑上的所有链接用户。
SDK调用方,我最开始找的是signalR的C++实现,可惜,一个是老版概念signalR 实现的,几年没更新了,最新的在asp net core下有份C++ 实现,这个还没BATA版,故客户端SDK调用方与直播服务器通信用C#完成,我们知道,与播服务器通信主要是二个部分,一个是我们主动提交的信息,如我们登陆了,我们推流了,还有一个是直播服务器的通知,比如通知你别的用户上线,别的用户推流了。第一个部分我们主动发起通知,表现就是我们从C++调用相关C#的实现,而第二部分是服务器通知回调,需要从C#端通知到C++端,这个算是不常用调用方法,综合考虑了下,把相应的C#客户端封装成COM接口,方便一是C++调用相关C#的实现,二是把相应的C++接口实现传入到C#环境中去执行。需要注意的,这个C++客户端事实上包含相应的CLI环境,所以如果销毁资源,如unity3D/UE4里的每次play/endplay间,要确认引用的C++DLL所关联的CLI环境已经清理干净,我反正是在对应销毁时调用GC.WaitForPendingFinalizers()才搞定关闭时不挂起的现象。
需要注意的是,客户端C#使用COM封装,那么每台机器需要注册相应的COM组件,如果你是用的VS,直接开管理员,编译相应的OeipLiveCom项目就行。
当然这个等asp net core signalR的C++实现完善后,会把相应C#+COM/C++调用方案改成全C++低层实现。
关联项目:OeipLiveServer,OeipLiveMedia,OeipLiveCom,oeip-live,oeip-live-ffmpeg
6 Unity3D插件
因为在验证各项功能前,我已经用WinForm+SharpDx做了验证项目,包含DX11纹理的传入传出验证,Unity3D的大部分代码和这部分共用,注意事项就一点,在Unity3D C#中我们拿不到DX11设备与上下文,我们需要编写一个Unity3D的非托管插件,在这插件里我们能拿到Unity3D的DX11设备与上下文,结合OEIP原来接口再封装一层。
注意事项,更新Unity3D的RHI资源,需要用到Unity3D的非托管插件特定的写法,保证在渲染线程中更新资源,而OEIP回调大部分在非主线程中,所以回调里要用到Unity3D游戏线程里的资源里,请转到游戏线程去执行。
关联项目:oeip-unity3d,OeipWrapper,OeipUnity3D
更详细说明请看
UE4/Unity3D中同时捕获多高清摄像头的高效插件 - 天天不在 - 博客园www.cnblogs.com![2bab4c2ab40a2de298b746de14752597.png](https://i-blog.csdnimg.cn/blog_migrate/1693d1380a12ca38d4c1897f25f2b7cc.jpeg)
7 UE4插件
基本和Unity3D插件思路一样,相应数据处理编写相应管线,设备数据处理管线,拉流管线,推流管线,直播SDK的再封装都是差不多的,就连注意事项也是差不多,回调里用到UE4资源的,请转到游戏线程,用到RHI资源的,请转到渲染线程。
关联项目:OeipUE4
更详细说明请看
UE4/Unity3D中同时捕获多高清摄像头的高效插件 - 天天不在 - 博客园www.cnblogs.com![2bab4c2ab40a2de298b746de14752597.png](https://i-blog.csdnimg.cn/blog_migrate/1693d1380a12ca38d4c1897f25f2b7cc.jpeg)
最后说下项目编译相关
我主要环境在VS2017上开发。
第三方库:
CUDA 10.1安裝:https://developer.nvidia.com/cuda-downloads
CUDNN 10.1安裝:https://developer.nvidia.com/cudnn
下载https://github.com/xxxzhou/oeip-thridparty在Oeip项目下,新建一个ThirdParty文件夹,把oeip-thridparty里的文件全部复制到这。 二种引用DLL方式。 一是把相应的DLL复制到对应oeip dll目录下。 二是在环境变量里把上面的几个文件夹的BIN目录写入,推荐第二种。(1 ThirdPartycuda 2 ThirdPartyFFmpegdll 3 ThirdPartyopencv4bin 4 ThirdPartypthreaddll).
直播SDK环境配置:
- 1 先启动直播服务器 OeipLiveServer
- 2 启动媒体服务器 OeipLiveMedia
- 3 本机注册OeipLiveCom这个COM组件,然后就可以用了。
相应UE4/Unity3D里神经网络加载用的的绝对路径,请自己修改相应路径。
其主要只考虑了64位,相应编译的环境只有64位配置了,32位需要自己配置。