暂时未有相关云产品技术能力~
牛哥@大牛直播SDK,致力于跨平台RTMP|RTSP推流、播放、轻量级RTSP服务和GB28181设备接入
随着物联网等行业的崛起,越来越多的传统行业如虚拟仿真、航天工业、工业仿真、城市规划等,对Linux下的生态构建,有了更大的期望,Linux平台下,可选的直播推拉流解决方案相对Windows和移动端,非常少,基于Unity的Linux推送方案,更是几无参考。本文以Unity3d环境下Linux平台推送Unity窗体和Unity采集的音频,然后编码推送到RTMP服务器为例,大概说下实现过程。
记住一句话就够了:指针三心二意,引用从一而终!
在事先Android平台RTSP、RTMP转GB28181网关之前,我们已经实现了Android平台GB28181的接入,可实现Android平台采集到的音视频数据,编码后,打包按需发到GB28181服务平台。此外,拉流端,我们已经有了成熟的RTSP和RTMP拉流播放方案。
std::string_view系C++17标准发布后新增的内容,类成员变量包含两个部分:字符串指针和字符串长度,相比std::string, std::string_view涵盖了std::string的所有只读接口。如果生成的std::string无需进行修改操作,可以把std::string转换为std::string_view,std::string_view记录了对应的字符串指针和偏移位置,无需管理内存,相对std::string拥有一份字符串拷贝,如字符串查找和拷贝,效率更高。
好多开发者的使用场景,需要在Windows特别是Android平台实现Unity3D的全景实时视频渲染,本文以Windows平台为例,简单介绍下具体实现: 如果是RTSP或RTMP流数据,实际上难点,主要在于拉取RTSP或RTMP流,解析解码,然后把解码后的YUV数据,回调到Unity层,Unity创建个Sphere,创建个材质球(Material),并把材质球挂在到Sphere即可。
std::jthread是C++20新引入的线程类,与 std::thread 类似,或者说,jthread是对thread进一步的封装,功能更强大。
尽管Windows平台有诸多优势,Linux平台的发展还是势不可挡,特别实在传统行业,然而Linux生态构建,总是差点意思,特别是有些常用的组件,本文基于已有的Linux平台RTSP、RTMP播放模块,构建Unity下的RTSP和RTMP直播播放。
通过周期性的状态信息报送,实现注册服务器与源设备之间的状态检测即心跳机制。
随着智慧数字人、AI数字人的兴起,越来越多的公司着手构建全息、真实感数字角色等技术合成的数字仿真人虚拟形象,通过“虚拟形象+语音交互(T-T-S、ASR)+自然语言理解(NLU)+深度学习”,构建适用于数字客服、虚拟展厅讲解、 智慧城市、智慧医疗、智慧教育等场景,通过人机可视化语音交互,释放人员基础劳动力,降低运营成本,提升智慧交互体验。
在实现本文提到的Android平台国标GB28181接入终端的实时位置上报之前,之前已经完成了Android终端GB28181常规功能接入,采集到实时音视频数据,编码PS打包后,按需传到GB28281服务平台,媒体流支持最新GB28181-2016的UDP和TCP被动模式,参数配置,支持注册有效期、心跳间隔、心跳间隔次数、TCP/UDP信令设置,支持RTP Sender IP地址类型、RTP Socket本地端口、SS-R-C、RTP socket 发送Buffer大小、RTP时间戳时钟频率设置,支持注册成功、注册超时、INVITE、ACK、BYE状态回调等。
C++中,我们一般可以以基类声明纯虚函数,然后让派生类继承并重写这个虚函数,用override表示显示覆盖基类方法,但一直没有提供一种方法来阻止派生类继承基类的虚函数。
原始字符串字面值(raw string literal)是C++11引入的新特性。
如何区分这些概念,主要还是看后面两个字,中文表达模式“表语+定性名词”,所以关键的都是后面的这个名词: 指针数组:一个数组,数组元素是指针,如: int* p[20]; 数组指针:一个指针,指向一个数组,如:int(*p)[20]; 函数指针:一个指针,指向一个函数;
在谈NULL和nullptr区别之前,我们先看段代码:
std::remove 不会改变输入vector/string的长度。其过程相当于去除指定的字符,剩余字符往前靠。后面的和原始字符保持一致。
模板类std::atomic是C++11提供的原子操作类型,头文件 #include<atomic>。在多线程调用下,利用std::atomic可实现数据结构的无锁设计。
std::tuple是C++11提供的新模板类,可以翻译为“元组”,可把多个不同类型的变量组合成一个对象。std::tuple可看做std::pair的泛化实现,std::pair包含两个元素,std::tuple 可以同时包含多个元素,它拥有 struct 的表现,但是无需定义实际的 struct,可用于一个函数返回多个值的场景下。
emplace_back() 是 C++11 之后,vector容器中添加的新方法,和 push_back()一样,都是在容器末尾添加一个新的元素,相对于push_back函数,它减少了一次类的构造。不同的是emplace_back() 在效率上相比较于 push_back() 有了一定的提升。
在我们研发Android平台GB28181前端音视频接入模块之前,业内听到最多的是,如何用Android或者Windows端,在没有国标IPC设备的前提下,模拟GB28181的信令和媒体流交互流程,实现GB28181整体方案的测试?
在实现Android平台GB28181前端设备接入之前,我们几年前就有了非常成熟的RTMP推送、RTSP推送和轻量级RTSP服务等模块,特别是RTMP推送,行业内应用非常广泛,好多开发者可能会问,既然有了以上模块,干嘛还要实现GB28181的前端接入呢?
有人说:“如果上帝是程序员,他怎么创造世界上的所有动物。”,理解这个问题就理解了面向对像。
随着智能门禁等物联网产品的普及,越来越多的开发者对音视频互动体验提出了更高的要求。目前市面上大多一对一互动都是基于WebRTC,优点不再赘述,我们这里先说说可能需要面临的问题:WebRTC的服务器部署非常复杂,可以私有部署,但是非常复杂。传输基于UDP,很难保证传输质量,由于UDP是不可靠的传输协议,在复杂的公网网络环境下,各种突发流量、偶尔的传输错误、网络抖动、超时等等都会引起丢包异常,都会在一定程度上影响音视频通信的质量,难以应对复杂的互联网环境,如跨区跨运营商、低带宽、高丢包等场景,行话说的好:从demo到实用,中间还差1万个WebRTC。
首先声明一点,本blog提到的轻量级RTSP服务,类似于网络摄像头(IPC),而非传统意义的接受外部推流的RTSP服务器。
我们在做Android平台RTSP或者RTMP播放器开发的时候,需要注意的点非常多,以下,以大牛直播SDK(官方)的接口为例,大概介绍下相关接口设计:
我们在对接Android平台摄像头或者屏幕采集、编码打包推送场景的时候,随着采集设备的不同,出来的数据也是多样化的,比如NV21、YV12、RGB、YUV等,更有图像数据甚至是翻转或者倒置的,如果上层处理,效率低下,本篇文章主要介绍下常用的编码前数据接口。相关资料或版本测试,也可联系大牛直播SDK(官方)
好多开发者在对接大牛直播SDK(官方)的Windows平台RTMP推送时,不熟悉摄像头调用,实际上,摄像头调用逻辑并不复杂,以下是大概流程:
国标GB/T28181协议全称《安全防范视频监控联网系统信息传输、交换、控制技术要求》,是一个定义视频联网传输和设备控制标准的白皮书,由公安部科技信息化局提出,该标准规定了城市监控报警联网系统中信息传输、交换、控制的互联结构、通信协议结构,传输、交换、控制的基本要求和安全性要求,以及控制、传输流程和协议接口等技术要求。解决了视频间互联互通,数据共享,以及设备控制的问题,这个问题从顶层解决了视频信息各自为战的问题,打通了视频联网的信息孤岛。
无论是Windows平台还是Linux,多路播放诉求非常普遍,比如针对智慧工地、展馆、教育等宏观场景下的摄像头展示,关于RTSP或RTMP直播播放器开发需要注意的点,可参考之前博客,总的来说有以下一些点:
好多开发者在做Android平台RTMP推送对接的同时,除了编码前的数据外,还有些外部编码数据推送诉求,他们希望外部的编码音视频数据不止可以实现RTMP推送,还可以同时在推送端实时录制下来,本文以我们(官方)Android平台RTMP直播推送模块为例,介绍下外部数据对接流程和数据录制流程。
随着Unity3D的应用范围越来越广,越来越多的行业开始基于Unity3D开发产品,如传统行业中虚拟仿真教育、航空工业、室内设计、城市规划、工业仿真等领域。
像Unity3D下的RTMP或RTSP播放器一样,好多开发者苦于在Unity环境下,如何高效率低延迟的把数据采集并编码实时推送到流媒体服务器,实现Unity场景下的低延迟推拉流方案。
我们在Windows平台实现RTSP或者RTMP播放的时候,有个功能是绕不开的,那就是播放窗口全屏。本文就以大牛直播SDK(官方)的Windows播放器为例,大概讲下大概实现:
先说结论,Windows平台播放渲染这块,一般来说99%以上的机器都是支持D3D的,实现GDI模式绘制,除了为了好的兼容性外,在远程连接的场景下,D3D创建不成功,需要使用GDI模式。
大家在做Windows平台RTMP推送或轻量级RTSP服务的时候,不管是采集屏幕还是采集摄像头,亦或屏幕摄像头的叠加模式,总会有这样的诉求,采集到的数据,希望能本地看看具体采集的数据或者图像实际效果,也就是本次介绍的“预览”功能。
本文主要讲的是基于Android平台实现RTMP的技术方案设计,基础架构图如下:
好多开发者在QT环境下实现RTMP或RTSP播放时,首先考虑到的是集成VLC,集成后,却发现VLC在延迟、断网重连、稳定性等各个方面不尽人意,无法满足上线环境需求。本文以调用大牛直播SDK(官方)的Windows平台播放端SDK为例,介绍下如何在QT下实现低延迟的RTMP|RTSP播放器,废话不多说,先上图:
好多开发者在做Android平台录像或者RTSP轻量级服务、RTMP推送相关模块时,对需要设计哪些常用接口会心存疑惑,本文主要以大牛直播SDK(官方)为例,简单介绍下Android平台直播推送SDK所有音频相关的接口,感兴趣的开发者可以看看。
技术背景 最近不少开发者找到我们,他们在做智能家居等传统行业时,希望实现在Android板件拉取本地的RTSP或RTMP流,然后对外推送RTMP出去,亦或内部启个轻量级RTSP服务,提供个对外对接的媒介URL,简单来说,设计架构图如下:
好多开发者在集成大牛直播SDK (官方)的Windows平台RTMP推送模块时吓一跳,怎么这么多接口?本文做个简单的拆分:
OBS 功能强大,几乎所有你想要的场景它都有,用起来很顺手。可以将桌面、摄像头、程序窗口通过rtmp推送到流媒体服务器上。 当然如果你是开发者,想基于OBS做二次开发,实现二次产品化的化,难度比较大,OBS代码量很大,驾驭起来难度很大,有bug的话,跟踪起来很累。
Surface的官方介绍:Handle onto a raw buffer that is being managed by the screen compositor,Surface是一个raw buffer的句柄,通过它在raw buffer上进行绘制,可以通过Surface获得一个Canvas。
Streamedian 提供了一种“html5_rtsp_player + websock_rtsp_proxy”的技术方案,可以通过html5的video标签直接播放RTSP的视频流。
ijkPlayer是BiliBili公司维护的一个开源工程,基于ffmpeg开发的一个播放器软件,支持Android和iOS平台,整个ijkplayer就是以ffplay为基础,如果只是使用它进行播放,集成也较为简单,使用也和MediaPlayer差不多,但是要定制化需求,就有一定的门槛高度。支持软硬编解码,支持倍速播放,可以定制化集成需要的功能,集成占用体积也很小,更详细的解释参看下面官方介绍:
好多开发者提到,在目前开源播放器如此泛滥的情况下,为什么还需要做自研框架的RTSP播放器,自研和开源播放器,到底好在哪些方面?以下大概聊聊我们的一点经验,感兴趣的,可以关注 github:
好多开发者提到,在目前开源播放器如此泛滥的情况下,为什么还需要做自研框架的RTMP播放器,自研和开源播放器,到底好在哪些方面?以下大概聊聊我们的一点经验,感兴趣的,可以关注 github:
好多开发者在做AR、VR或者教育类产品时,苦于如何在windows平台构建一个稳定且低延迟的RTSP或者RTMP播放器,如果基于Unity3d完全重新开发一个播放器,代价大、而且周期长,不适合快速出产品,我们认为当前最好的方式就是集成现有Native平台上成熟稳定播放器,回调rgb/yuv数据到上层,上层做绘制即可。
GOM player 是一款本身装有视频播放所需的解码,及占用系统资源少,并且能以最优秀的画质来观看多种格式影片的播放程序。
介绍移动端RTMP、RTSP播放器实时音量调节之前,我们之前也写过,为什么windows播放端加这样的接口,windows端播放器在多窗口大屏显示的场景下尤其需要,尽管我们老早就有了实时静音接口,相对实时静音来说,播放端实时音量调节粒度更细,从[0, 100],用户体验更好。
首先,虽然本文是介绍IE浏览器下OCX控件播放RTSP或RTMP,但这种方式并不推荐,毕竟它只能用于IE浏览器环境下,局限太大,而且随着微软IE浏览器的更新,不确定后续支持情况。当然,话说回来,如果是在特定的使用场景下,只需要某些版本IE浏览器支持,但对延迟和稳定性要求非常高,OCX控件方式也不失为一个好的选择。
在Google 推出Android 5.0的时候, Android Camera API 版本升级到了API2(android.hardware.camera2), 之前使用的API1(android.hardware.camera)就被标为 Deprecated 了。