如何同时启动Android平台GB28181设备接入模块和轻量级RTSP服务模块?

简介: 为什么要设计GB28181设备接入模块?GB28181接入SDK,实现不具备国标音视频能力的 Android终端,通过平台注册接入到现有的GB/T28181—2016服务,可用于如智能监控、智慧零售、智慧教育、远程办公、生产运输、智慧交通、车载或执法记录仪等场景。Android终端除支持常规的音视频数据接入外,还可以支持移动设备位置(MobilePosition)订阅和通知、语音广播和语音对讲、云台控制和预置位查询等。

技术背景

在介绍GB28181设备接入模块和轻量级RTSP服务之前,我们需要先搞清楚,二者的使用场景和技术设计的差别:


首先是GB28181设备接入模块:


为什么要设计GB28181设备接入模块?GB28181接入SDK,实现不具备国标音视频能力的 Android终端,通过平台注册接入到现有的GB/T28181—2016服务,可用于如智能监控、智慧零售、智慧教育、远程办公、生产运输、智慧交通、车载或执法记录仪等场景。Android终端除支持常规的音视频数据接入外,还可以支持移动设备位置(MobilePosition)订阅和通知、语音广播和语音对讲、云台控制和预置位查询等。

0c271e0c9cce4aeab1ca959dfba2f0b5.png

其次是轻量级RTSP服务模块:


为什么要设计轻量级RTSP服务?轻量级RTSP服务解决的核心痛点:避免用户单独部署RTSP或者RTMP服务,实现本地的音视频数据(如摄像头|屏幕、麦克风),编码后,汇聚到内置RTSP服务,对外提供可供拉流的RTSP URL,轻量级RTSP服务,适用于内网环境下,对并发要求不高的场景,视频编码支持H.264/H.265,音频对外输出AAC/PCMA,支持RTSP鉴权、单播、组播模式,考虑到单个服务承载能力,支持同时创建多个RTSP服务,并支持获取当前RTSP服务会话连接数。

35565d142c1e4f5d938b86ef9d43fb8f.png

轻量级RTSP服务的设计,更像Android平台扮演了IPC的角色。


大家有没有这么个感觉,如果GB28181设备接入模块和轻量级RTSP服务模块,二者合二为一的话,是不是更像一个支持国标接入的网络摄像机?


是的,就是如此!


所以,我们在设计Android平台GB28181设备接入模块和轻量级RTSP服务模块的时候,有几个需要注意的地方:


视频编码:


大家都知道,GB/T28181-2016协议规范里面,并没有描述GB28181对H.265的支持策略,如果H.265数据上去,国标平台侧大概率是需要转成H.264输出,一方面徒增时延,另一方面,转换后的数据,可能会导致时间戳偏差等各种问题。所以,如果考虑到二者同时启动,建议视频编码选择H.264。

   /**
    * Set Video H.264 HW Encoder, if support HW encoder, it will return 0(设置H.264硬编码)
    * 
    * @param kbps: the kbps of different resolution.
    * 
    * @return {0} if successful
    */
   public native int SetSmartPublisherVideoHWEncoder(long handle, int kbps);
  /**
   * Set Video H.265(hevc) hardware encoder, if support H.265(hevc) hardware encoder, it will return 0(设置H.265硬编码)
   *
   * @param kbps: the kbps of different resolution.
   *
   * @return {0} if successful
   */
  public native int SetSmartPublisherVideoHevcHWEncoder(long handle, int kbps);
  /**
   * 设置视频硬编码是否使用 Native Media NDK, 默认是不使用, 安卓5.0以下设备不支持
   * @param handle
   * @param is_native: 0表示不使用, 1表示使用, sdk默认是0.
   * @return {0} if successful
   */
  public native int SetNativeMediaNDK(long handle, int is_native);

视频编码,我们有支持Native MediaCodec的底层编码模型,简单来说,支持如下:


1. 软编码(分平均码率和VBR可变码率编码)


2. 特定机型硬编码(分上层MediaCodec调用和Native Mediacodec硬编码(H264/HEVC,5.0+))


音频编码:


音频编码分为AAC编码和G.711 A律编码,由于GB平台大多默认传G.711 A律编码,所以这就需要国标设备接入端,如果同时支持轻量级RTSP服务的话,相对容易一些。

    /**
     * Set audio encoder type(设置音频编码类型)
     * 
     * @param type: if with 1:AAC, if with 2: SPEEX, if with 3: PCMA
     * 
     * @return {0} if successful
     */
    public native int SmartPublisherSetAudioCodecType(long handle, int type);

总结

其他,如果需要同时推RTMP或者实时录像、实时快照、实时音量调节等操作,Android平台天生支持,感兴趣的开发者可以酌情考虑。

相关文章
|
25天前
|
安全 Java 网络安全
Android远程连接和登录FTPS服务代码(commons.net库)
Android远程连接和登录FTPS服务代码(commons.net库)
22 1
|
2月前
|
JavaScript 前端开发 Android开发
让Vite+Vue3项目在Android端离线打开(不需要起服务)
让Vite+Vue3项目在Android端离线打开(不需要起服务)
|
2月前
|
调度 Android开发 UED
Android经典实战之Android 14前台服务适配
本文介绍了在Android 14中适配前台服务的关键步骤与最佳实践,包括指定服务类型、请求权限、优化用户体验及使用WorkManager等。通过遵循这些指南,确保应用在新系统上顺畅运行并提升用户体验。
188 6
|
2月前
|
Web App开发 网络协议 Android开发
Android平台一对一音视频通话方案大比拼:WebRTC VS RTMP VS RTSP,谁才是王者?
【9月更文挑战第4天】本文详细对比了在Android平台上实现一对一音视频通话时常用的WebRTC、RTMP及RTSP三种技术方案。从技术原理、性能表现与开发难度等方面进行了深入分析,并提供了示例代码。WebRTC适合追求低延迟和高质量的场景,但开发成本较高;RTMP和RTSP则在简化开发流程的同时仍能保持较好的传输效果,适用于不同需求的应用场景。
159 1
|
2月前
|
安全 API 开发工具
Android平台RTMP推送|轻量级RTSP服务如何实现麦克风|扬声器声音采集切换
Android平台扬声器播放声音的采集,在无纸化同屏等场景下,意义很大,早期低版本的Android设备,是没法直接采集扬声器audio的(从Android 10开始支持),所以,如果需要采集扬声器audio,需要先做系统版本判断,添加相应的权限。
|
2月前
|
编解码 开发工具 Android开发
Android平台实现屏幕录制(屏幕投影)|音频播放采集|麦克风采集并推送RTMP或轻量级RTSP服务
Android平台屏幕采集、音频播放声音采集、麦克风采集编码打包推送到RTMP和轻量级RTSP服务的相关技术实现,做成高稳定低延迟的同屏系统,还需要有配套好的RTMP、RTSP直播播放器
|
开发工具 Android开发
Android 7.1 使用mmm编译模块失败
Android 7.1 使用mmm编译模块失败
293 0
|
Android开发
Android不编译某个模块
Android 5.1 源码,编译相关的文件一般在build目录下build/target/product 放了很多mk文件;一般不同的产品会有不同的目录 假设我不想编译OpenWnn,在build目录下grep一下“OpenWnn”target/product/full_base.
1428 0
|
3天前
|
搜索推荐 Android开发 开发者
探索安卓开发中的自定义视图:打造个性化UI组件
【10月更文挑战第39天】在安卓开发的世界中,自定义视图是实现独特界面设计的关键。本文将引导你理解自定义视图的概念、创建流程,以及如何通过它们增强应用的用户体验。我们将从基础出发,逐步深入,最终让你能够自信地设计和实现专属的UI组件。
|
5天前
|
Android开发 Swift iOS开发
探索安卓与iOS开发的差异和挑战
【10月更文挑战第37天】在移动应用开发的广阔舞台上,安卓和iOS这两大操作系统扮演着主角。它们各自拥有独特的特性、优势以及面临的开发挑战。本文将深入探讨这两个平台在开发过程中的主要差异,从编程语言到用户界面设计,再到市场分布的不同影响,旨在为开发者提供一个全面的视角,帮助他们更好地理解并应对在不同平台上进行应用开发时可能遇到的难题和机遇。