gb28181-爱代码爱编程
规范解读 GB28181-2022针对“基于TCP协议的视音频媒体传输”实时点播、历史视频回放与下载中,TCP媒体传输重连机制,做了说明。 修改后的“基于TCP协议的视音频媒体传输要求”如下: 实时视频点播、历史视频回放与下载的TCP媒体传输应支持基于RTP封装的视音频PS流,封装格式参照IETF RFC 4571。 流媒体服务器宜同
代码编织梦想
规范解读 GB28181-2022针对“基于TCP协议的视音频媒体传输”实时点播、历史视频回放与下载中,TCP媒体传输重连机制,做了说明。 修改后的“基于TCP协议的视音频媒体传输要求”如下: 实时视频点播、历史视频回放与下载的TCP媒体传输应支持基于RTP封装的视音频PS流,封装格式参照IETF RFC 4571。 流媒体服务器宜同
规范解读 GB28181-2016和GB28181-2022关于媒体保活机制这块,并无调整,平台、设备媒体流保活机制规定如下: a)链路建立后,码流经过的各级平台应具备媒体流丢失监测能力,若监测到媒体流丢失,应释放该条媒体链路,并通过会话内Bye消息通知上下级平台; b)上下级平台之间、平台与设备之间、平台与客户端之间应通过注册,状态信息
GB/T28181-2022规范说明 GB/T28181-2022相对来GB/T28181-2016针对H.265、AAC的更新如下: ——更改了“联网系统通信协议结构图”,媒体流通道增加了 H.265、G.722.1、AAC(见 4.3.1, 2016 年版的 4.3.1)。 ——增加了对 H.265、AAC 的支持(见 6.2、A
我们在对接Android平台GB28181设备接入端的时候,有开发者提出这样的疑惑,如何调整设备接入端的实时音量? 实际上,这块我们前几年在做RTMP直播推送模块的时候,已经发布了相关的接口,这里再回顾下: /* * SmartPublisherJniV2.java * Author: daniusdk.com */ /** * 设置输入音
大牛直播SDK研发的Android平台GB28181设备接入SDK(SmartGBD),可实现不具备国标音视频能力的 Android终端,通过平台注册接入到现有的GB/T28181—2016服务,可用于如执法记录仪、智能安全帽、智能监控、智慧零售、智慧教育、远程办公、明厨亮灶、智慧交通、智慧工地、雪亮工程、平安乡村、生产运输、车载终端等场景。 Andro
我们在做Android平台RTMP推送和GB28181设备对接的时候,遇到这样的问题,有的设备,麦克风采集出来的audio,音量过高或过低,特别是有些设备,采集到的麦克风声音过低,导致播放端听不清前端采集的audio,这时候,就需要针对采集到的audio,做音量放大处理。 先说如何采集,android平台通用的做法是采集audiorecord,设置aud
什么是数字城管? 数字城管,又称“数字化城市管理”或“智慧城管”,是一种采用信息化手段和移动通信技术来处理、分析和管理整个城市的所有城管部件和城管事件信息,促进城市管理现代化的信息化措施。 数字城管通过建立城市管理信息化平台,实现城市管理信息的采集、处理、分析和应用,以问题为导向,采用闭环监管、联勤联动、公众参与等手段,形成跨部门、跨区域、跨层
背景 我们在做GB28181设备接入模块的时候,考虑到好多设备性能一般,我们一般的设计思路是,先注册设备到平台侧,平台侧发calalog过来,获取设备信息,然后,设备侧和国标平台侧维持心跳,如果有位置订阅信息,按照订阅时间间隔,实时上报设备位置信息。 如果本地没有录像诉求,或者,国标平台侧不发起invite请求,Android平台GB28181设备接入
技术背景 GB28181的应用场景非常广泛,如公共安全、交通管理、企业安全、教育、医疗等众多领域,细分场景可用于如执法记录仪、智能安全帽、智能监控、智慧零售、智慧教育、远程办公、明厨亮灶、智慧交通、智慧工地、雪亮工程、平安乡村、生产运输、车载终端等: 公共安全:通过GB28181协议,用户可以实时监控特定区域的视频画面,从而提高公共安全水平。交通管理:
技术背景 GB/T28181-2016官方规范和交互流程,我们不再赘述。 SIP服务器发起广播流程示意图如下: 需要注意的是:语音广播通知、语音广播应答命令 消息头 Content-type字段为 Content-type:Application/MANSCDP+xml。 语音广播通知、语音广播应答命令采用 MANSCDP协议格式定
技术背景 新版国家标准GB/T28181-2022《公共安全视频监控联网系统信息传输、交换、控制技术要求》已于2022年12月30日发布,并将于2023年7月1日正式实施。 国家标准GB/T28181-2022《公共安全视频监控联网系统信息传输、交换、控制技术要求》规定了公共安全视频监控联网系统(以下简称“联网系统”)的互联结构,传输、交换、控制的基本
我们在做Android平台RTMP推送、轻量级RTSP服务和GB28181设备接入模块的时候,有一个点是逃不掉的:如何高效率的实现视频数据编码? 为此,我们设计了软编码、基于MediaCodec的硬编码和MediaCodec native层硬编,尽可能的减少数据拷贝和交互,确保高效率的完成视频编码,目前,编码前数据类型,已经涵盖了YV12/NV21/NV
技术背景 我们在做Android平台gb28181设备接入模块的时候,遇到这样的情况,比如横竖屏分辨率不锁定,采集摄像头的时候,可以实现,横屏状态采集横屏,竖屏状态采集竖屏,简单来说,横屏状态比如采集的1280*720的,竖屏状态,采集的数据源成了720*1280。 这块对我们来说,已经轻车熟路了,老早就已经处理,分辨率发生变化的时候,会重启encod
技术背景 今天,我们主要讲讲Android平台GB28181接入模块的技术对接,Android平台GB28181接入模块设计的目的,可实现不具备国标音视频能力的 Android终端,通过平台注册接入到现有的GB/T28181—2016服务,可用于如智能监控、智慧零售、智慧教育、远程办公、生产运输、智慧交通、车载或执法记录仪等场景。 Android终
我们在实现Android平台GB28181设备接入模块的时候,有遇到发送多条记录的情况,本文主要探讨下GB28181多响应传输。 规范解读 如GB/T28181-2016规范所说:目录查询响应、文件查询响应、订阅后的通知消息会出现响应、通知消息需发送多条记录的情况,此时可通过多条响应、通知消息对记录进行分批传送,各响应消息的SN 值需与请求消息相同。
规范解读 我在之前的blog,有提到过Android端GB28181接入端的语音广播和语音对讲,今天主要从GB/T28181-2016官方规范和交互流程,大概介绍下Android平GB28181接入端的语音广播和语音对讲。 关于交互流程,本文不再赘述,一张图足矣: 接下来,我们主要来看看规范里面提到的协议接口。 语音广播通知、语音广播应答
在之前,我有写过Android平台GB28181设备接入模块的好多blog,包括参数设置、功能支持与扩展等,以数据接入为例,支持的数据类型涉及编码前、编码后或直接流数据(RTSP或RTMP流)。可用于如智能监控、智慧零售、智慧教育、远程办公、生产运输、智慧交通、车载或执法记录仪等场景。 编码前数据(目前支持的有YV12/NV21/NV12/I420/RG
GB28181语音广播这块,我们依据GB/T28181-2016针对流程和实例代码,做过详细的描述,本次主要是探讨下,广播数据过来后,如何处理。 鉴于我们之前有非常成熟的RTMP|RTSP低延迟播放模块,语音广播数据过来后,调用startAudioPlay(),ntsOnInviteAudioBroadcastResponse()处理如下: @Over
实现Android平台GB28181设备接入的时候,有个功能点不可避免,那就是本地录像,实际上,在实现GB28181设备接入模块之前,我们前些年做RTMP推送和轻量级RTSP服务的时候,早已经实现了本地录像功能。 本地录像功能,我们实现的主要控制接口如下: 音视频录制开关,为了更细粒度的控制录像,如只需要录纯音频还是纯视频,或者音视频,可以通过下
今天主要聊聊GB28181中,SSRC的作用,从我们之前跟第三方厂商的对接来看,好多厂商对SSRC的处理,并不符合规范。 举个典型的操作:语音广播时带的SSRC和发送RTP包时的SSRC并不一致,然后厂商一开始给出来的结论是,不一致也不影响使用,实则按照规范来看,SSRC还是至关重要的,想想看,如果SSRC不重要的话,SDP携带的SSRC的意义在哪里?如