暂时未有相关云产品技术能力~
牛哥@大牛直播SDK,致力于跨平台RTMP|RTSP推流、播放、轻量级RTSP服务和GB28181设备接入
我们在对接轻量级RTSP服务的时候,遇到客户这样的使用场景:客户是用于车载自组网环境,确保多辆车之间可以相互看到对方的实时视频,以期可以了解到前方路况等关注的信息。
元宇宙业务场景对流媒体传输的实时性和互动性提出了更高的要求,这就需要在传统的 RTMP、SRT、 HLS 等基础上增加实时互动的支持。实时互动,指在远程条件下沟通、协作,可随时随地接入、实时地传递虚实融合的多维信息,身临其境的交互体验。实时互动作为下一代互联网基础设施,实现了从“在线”到“在场” 的重要转变,将推动互联网向以“临场感”为主要特征的元宇宙方向的升级变革,当前几个主流的技术方向如下。
我们在做Android平台RTMP推送和GB28181设备对接的时候,遇到这样的问题,有的设备,麦克风采集出来的audio,音量过高或过低,特别是有些设备,采集到的麦克风声音过低,导致播放端听不清前端采集的audio,这时候,就需要针对采集到的audio,做音量放大处理。
AtomicLong 是 Java 提供的一个原子长整型类,提供了对长整型数据的原子性操作。在多线程环境下,AtomicLong 可以确保对长整型数据的操作是线程安全的。
好多新学设计模式的同学,对责任链模式一知半解,今天以C++为例,做个简单的分享。
什么是观察者模式? 观察者模式是一种一对多的以来关系,当一个对象的状态发生改变时,所有依赖于他的对象都得到通知并被自动更新。它的主体是通知的发布者,发出通知时并不需要知道谁是它的观察者,可以有任意数目的观察者订阅并接收通知,将观察者和被观察的对象分离开。
GB/T28181-2016官方规范和交互流程,我们不再赘述。
GB/T28181是广泛应用于视频监控行业的标准协议规范,可以在不同设备之间实现互联互通。今天我们主要探讨Android平台的Audio采集部分。
GB28181协议是一种用于设备状态信息报送的协议,可以在不同设备之间进行通信和数据传输。
我们在对接GB28181设备接入侧的时候,除了常规实时音视频按需上传外,还有个重要的功能,就是本地实时录像,录像后的数据,在执法记录仪等前端设备留底,然后,到工作站拷贝到专门的平台。
Unity平台下,RTSP、RTMP播放和RTMP推送,甚至包括轻量级RTSP服务这块都不再赘述,今天探讨的一位开发者提到的问题,如果在Unity下,实现RTSP播放的同时,随时转RTMP推送出去?
闲来无事,我们今天探讨下音视频绕不开的一个话题:WebRTC。WebRTC之于音视频行业,无异于FFMpeg,可以说WebRTC的开源,让音视频行业大跨步进入发展快车道。
闲暇之时,聊到C++14,实际上C++14相对之前的11并没有太大的改动,或者说更像C++11标准基础上的查漏补缺,C++14之后,还有17、20甚至23,所以说,C++14更像个过渡版本。
实现RTSP摄像头数据转RTMP推送到服务器,可以用第三方库或者工具实现,总体设计架构如下:
NV21、NV12、YV12、RGB、YUV、RGBA、RGBX8888都是常见的图像颜色编码格式,它们之间的主要区别在于色彩空间和数据排列方式。
Java和C++都是非常受欢迎的编程语言,各有各的优势和适用场景。以下是对它们的简要比较:
在 Android 中,AtomicBoolean 是一个原子布尔类,用于在多线程环境中安全地进行布尔类型的操作。它提供了一些原子性的操作方法,如 set()、get()、compareAndSet() 等。
为满足内网无纸化/电子教室等内网超低延迟需求,避免让用户配置单独的服务器,我们发布了轻量级RTSP服务模块,轻量级RTSP服务解决的核心痛点是避免用户或者开发者单独部署RTSP或者RTMP服务,实现本地的音视频数据(如摄像头、麦克风),编码后,汇聚到内置RTSP服务,对外提供可供拉流的RTSP URL,轻量级RTSP服务,适用于内网环境下,对并发要求不高的场景,支持H.264/H.265,支持RTSP鉴权、单播、组播模式,考虑到单个服务承载能力,我们支持同时创建多个RTSP服务,并支持获取当前RTSP服务会话连接数。
设计模式是一种通用的解决问题的经验,可以帮助我们设计出可重用、可维护和可扩展的软件。
在此之前,我们先对协议规范做个简单了解:GB28181协议是一种用于视频监控系统互联互通的国际标准,它定义了视频监控系统中的设备间如何进行通信、交换数据和协调控制。以下是GB28181协议的一些主要内容:
观察者模式是一种设计模式,定义了对象之间的一对多关系。当一个对象状态发生改变时,它的依赖者都会收到通知并自动更新。在C++11中,可以通过以下方式实现观察者模式:
好多新人函数指针、指针函数迟迟分不清。实际上,函数指针和指针函数有以下区别:
多态(Polymorphism)是指面向对象程序运行时,相同的消息可能会送给多个不同的类之对象,系统依据对象所属类,引发对应类的方法,而有不同的行为。
早在2015年,我们发布了RTMP直播推送模块,那时候音视频直播这块场景需求,还不像现在这么普遍,我们做这块的初衷,主要是为了实现移动单兵应急指挥系统的低延迟音视频数据传输。好多开发者可能会疑惑,走RTMP怎么可能低延迟?网上看到的RTMP推拉流延迟,总归要2-3秒起,如果是自己实现框架,RTMP推拉流逻辑自己实现的话,延迟确实可以控制在毫秒级,这个已无需赘述。
我们在对接Android平台GB28181设备接入模块的开发者时,遇到这样的场景,除了Android设备(如执法记录仪、智能安全帽等)自带的camera或camera2前后摄像头数据外,还有些场景是需要外部编码前或编码后数据,比如对接OTG类似的外置数据源,如NV12、NV21、YV12、RGB或YUV等格式,这里做个简单的汇总。
好多开发者,希望我们能探讨下Unity平台RTMP或RTSP直播流数据播放和录制相关的模块,实际上,这块流程我们已经聊过多次,无非就是通过原生的RTMP或者RTSP模块,先从协议层拉取到数据,并解包解码,回调YUV或RGB数据,然后,在Unity创建响应的shader,获取图像数据填充纹理即可,说起来流程很简单,但是每个环节,如果做到极致体验,都非常难。简单来说,多一次拷贝,都会增大性能瓶颈或延迟。
新版国家标准GB/T28181-2022《公共安全视频监控联网系统信息传输、交换、控制技术要求》已于2022年12月30日发布,并将于2023年7月1日正式实施。
录像有什么难的?无非就是数据过来,编码保存mp4而已,这可能是好多开发者在做录像模块的时候的思考输出。是的,确实不难,但是做好,或者和其他模块有非常好的逻辑配合,确实不容易。
我们在做Android平台GB28181设备接入模块的时候,遇到这样的场景,比如执法记录仪或智慧工地等场景下,由于GB28181设备接入模块,注册到国标平台后,平时只是心跳保持,或还有实时位置订阅,查看视频的时候,是按需看,而且有时候,网络环境并不是太好,所以,催生了这样一个诉求:部分开发者希望能本地录像的时候,录制高分辨率(比如1920*1080),国标平台侧发起实时视频查看请求的时候,上传低分辨率(如1280*720)数据,有点类似于IPC的主码流和子码流。
好多开发者可能疑惑,外部数据实时预览播放,到底有什么用? 是的,一般场景是用不到的,我们在开发这块前几年已经开发了非常稳定的RTMP、RTSP直播播放模块,不过也遇到这样的场景,部分设备输出编码后(视频:H.264/H.265,音频:AAC/PCMA/PCMU)的数据,比如无人机或部分智能硬件设备,回调出来的H.264/H.265数据,除了想转推到RTMP、轻量级RTSP服务或GB28181外,还需要本地预览甚至对数据做二次处理(视频分析、实时水印字符叠加等,然后二次编码),基于这样的场景诉求,我们开发了Android平台外部编码数据实时预览播放模块。
我们在做内网环境的一对一音视频互动的时候,遇到这样的技术诉求:如智能硬件场景下(比如操控智能硬件),纯内网环境,如何不要单独部署RTMP或类似流媒体服务,实现一对一音视频互动。
今天分享的是外部RTSP或RTMP流,拉取后注入到本地轻量级RTSP服务模块,供内网小并发场景下使用,这里我们叫做内网RTSP网关模块。
我们在对接开发者的时候,遇到这样的诉求:除了正常的RTMP、RTSP直播播放外,有些硬件设备输出编码后(H.264/H.265)的数据,比如无人机或类似硬件产品,回调出来的H.264/H.265数据,除了正常转推到RTMP、轻量级RTSP服务或GB28181外,还需要本地预览甚至重新对数据做二次处理,基于这样的场景诉求,我们开发了外部编码后数据实时预览播放模块。
GB/T28181-2022和GB/T28181-2016规范,有这么一条“更改了附录 D 基于 TCP 协议的视音频媒体传输要求(见附录 D,2016 年版的附录 L)。”。
我们在做Android平台GB28181设备接入模块的时候,遇到这样的需求,做移动对讲的时候,是不需要视频数据的,但是国标平台侧,没有视频的话,大多平台又无法播纯音频打包的数据(网页端大多基于http-flv或webrtc实现),基于此,我们做了个简单的处理,通过Bitmap生成个32*32的黑帧,然后,确保上行的音视频数据都有,但是由于视频系黑帧数据,几乎不占用带宽。
在谈国网B接口的语音广播和语音对讲的时候,大家会觉得,国网B接口是不是和GB28181大同小异?实际上确实信令有差别,但是因为要GB28181设备接入测的对接,再次做国网B接口就简单多了。
国网B接口调阅实时视频,相关规范写的比较粗略: 调阅实时视频包括信令接口和媒体流接口,采用标准的SIP INVITE+SDP流程,媒体传输使用RTP/RTCP。
我们在做Android平台RTMP推送、轻量级RTSP服务和GB28181设备接入模块的时候,有一个点是逃不掉的:如何高效率的实现视频数据编码?
对接Android平台GB28181设备接入端语音广播的时候,我们有遇到过INVITE SDP需要PCMA格式的audio,对方同时回了PS和PCMA两种,然后,发数据的时候,直接发了PS的。
GB28181-2016和GB28181-2022关于媒体保活机制这块,并无调整,平台、设备媒体流保活机制规定如下: a)链路建立后,码流经过的各级平台应具备媒体流丢失监测能力,若监测到媒体流丢失,应释放该条媒体链路,并通过会话内Bye消息通知上下级平台;
GB28181-2022相对2016,其中有个变化是:报文中携带协议版本标识 X-GB-Ver:3.0(3.0-2022 2.0-2016)
在探讨Unity平台RTMP或RTSP直播流数据播放和录制之前,我们先简单回顾下RTSP或RTMP直播流数据在Unity平台的播放流程: 1. 通过Native RTSP或RTSP直播播放SDK回调RGB/YUV420/NV12等其中的一种未压缩的图像格式; 2. Unity下创建相应的RGB/YUV420等Shader; 1. Unity从各个平台获取图像数据来填充纹理即可。
上一篇blog“Android平台GB28181设备接入模块之球机/云台控制探究”谈到,Android平台做国标GB28181设备接入端的时候,PTZ控制要不要处理?如果处理,难度大不大?
前两篇blog介绍了国网B接口注册和资源上报相关,今天继续整理国网B接口资源信息获取相关的接口描述和消息示例。
今天某乎收到个问题推荐,如何实现RTSP回调YUV数据,用于二次处理? 正好前些年我们做RTSP和RTMP直播播放的时候,实现过相关的需求,本文就以Android为例,大概说说具体实现吧。
随着国产操作系统的推进,传统行业对Linux平台的呼声和需求越来越大,之前几年,我们发布了Linux平台运营商级的RTSP转RTMP推送模块、RTMP推送模块和RTSP、RTMP播放模块,前段时间,有开发者问我们,是不是可以在Linux平台实现轻量级RTSP服务,通过采集摄像头或者屏幕,在Linux平台实现类似于IPC的功能,便于第三方系统对接。
我们在做Android平台GB28181的时候,其中实时位置(MobilePosition)订阅和上报这块,涉及到实时经纬度的获取,特别是执法记录、车载系统的那个等场景,几乎就是标配。
关于Unity实现RTMP直播推送技术方案,之前零散的写过几篇介绍,得到了好多开发者的关注。以Android平台为例,目前视频这块,我们demo实现的是Camera数据的采集,然后编码投递到底层,如果设备没有性能瓶颈,可达到高帧率(60帧)均匀的RTMP推送效果。
今天主要聊聊GB/T28181状态信息报送这块,先回顾下协议规范相关细节,然后再针对代码实现,做个简单的说明。
首先我们先回顾下相关技术规范,看看基于RTP的音视频数据PS封装。