Task可以注册Hook,RTP也可以,只需在VIP中包含组件INCLUDE_RTP_HOOKS。每种Hook可以注册的数量为RTP_HOOK_TBL_SIZ
今天,我们主要讲讲Android平台GB28181接入模块的技术对接,Android平台GB28181接入模块设计的目的,可实现不具备国标音视频能力的 Android终端,通过平台注册接入到现有的GB/T28181—2016服务,可用于如智能监控、智慧零售、智慧教育、远程办公、生产运输、智慧交通、车载或执法记录仪等场景。
好多开发者在做国标对接的时候,首先想到的是IPC摄像头,通过参数化配置,接入到国标平台,实现媒体数据的按需查看等操作。
我在之前的blog,有提到过Android端GB28181接入端的语音广播和语音对讲,今天主要从GB/T28181-2016官方规范和交互流程,大概介绍下Android平GB28181接入端的语音广播和语音对讲。
前面我们花了较多的篇幅来介绍了RTSP协议的一些细节,但是rtsp传输,本质上涉及三种协议,RTSP、RTP以及RTCP。RTSP主要负责连接建立,销毁及一些其他的控制。而实际涉及媒体数据传输使用的是RTP协议,本节我们来介绍一下RTP协议。
[vxWorks *]# rtp exec [-s | -c] [-i] [-g | -a | -z] [-x | -X] [-p <priority>] [-u <stacksize>] [-o <rtpOptions>] [-t <taskOptions>] [-v <level>] [-e name=value] <filename> [--] [args] [&]
GB28181协议是一种用于设备状态信息报送的协议,可以在不同设备之间进行通信和数据传输。
找了一台Intel的设备,跑了一次性能测试 可用横屏观看 Intel Haswell Processor 主频 2808400492Hz VxWorks 6.9 SMP 循环10遍 数据单位: 微秒 测试项 平均值 最小值 最大值 ---------------- -------- -------- -------- /* binary semaphore */ Vx_SemBCreate
我们在开发网络程序时经常用到UDP或RTP来发送和接收流媒体,而开发程序完毕需要搭建一个环境测试,这时候可能你需要一个推流端或接收端。对于推流端,我们可以借助FFmpeg工具轻松完成该功能,只需要敲一条命令后就可以实现发流,并且支持多种网络协议(UDP/RTP/RTSP/RTMP)。而接收端我们可以使用ffplay,这个程序也是在FFmpeg工具包的Bin目录里面。大家可以根据自己需要使用这两个工具进行推流或接收,下面就以传输协议UDP、RTP为基础,介绍几种最常见的推流场景下两个工具的用法。
在此之前,我们先对协议规范做个简单了解:GB28181协议是一种用于视频监控系统互联互通的国际标准,它定义了视频监控系统中的设备间如何进行通信、交换数据和协调控制。以下是GB28181协议的一些主要内容:
在实现Android平台GB28181前端设备接入之前,我们几年前就有了非常成熟的RTMP推送、RTSP推送和轻量级RTSP服务等模块,特别是RTMP推送,行业内应用非常广泛,好多开发者可能会问,既然有了以上模块,干嘛还要实现GB28181的前端接入呢?
=====================================================
最大的限制是内存的访问。如果RTP与RTP之间,或者RTP与Kernel之间,需要传递少量数据,可以使用Public的Message Queue。大量数据,可以使用共享数据区。
实时传送协议(Real-time Transport Protocol或简写RTP)是一个网络传输协议,
RTP全名是Real-time Transport Protocol(实时传输协议)。它是IETF提出的一个标准,对应的RFC文档为RFC3550(RFC1889为其过期版本)。RFC3550不仅定义了RTP,而且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输控制协议)。RTP用来为IP网上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP为Internet上端到端的实时传输提供时间信息和流同步,但并不保证服务质量,服务质量由RTCP来提供。
音视频传输的基石:RTP和RTCP。对于协议的讲解主要是是对于RFC文档的阅读和理解。不同的使用场景用到的字段也有所侧重,RTP和RTCP定义在RFC3550中。其中RTP用于数据流的传输;RTCP用于数据流的控制。可以说rtp/rtcp协议是即时通讯不可或缺的组成。RTCP协议介绍见:音视频协议-RTCP协议介绍
前 12 个字节出现在每个 RTP 包中,仅仅在被混合器插入时,才出现 CSRC 识别符列表。各个域的含义如下所示:
早在2015年,我们发布了RTMP直播推送模块,那时候音视频直播这块场景需求,还不像现在这么普遍,我们做这块的初衷,主要是为了实现移动单兵应急指挥系统的低延迟音视频数据传输。好多开发者可能会疑惑,走RTMP怎么可能低延迟?网上看到的RTMP推拉流延迟,总归要2-3秒起,如果是自己实现框架,RTMP推拉流逻辑自己实现的话,延迟确实可以控制在毫秒级,这个已无需赘述。
该功能实现,主要需要考虑RTSP取摄像头视频流,拆RTP包,组H264帧,通过PJSIP的视频通道转发;这个过程中,涉及到RTP通道保活,RTSP通道保活;调试时间多耗费在对摄像头返回的RTP数据包的拆解和重新组H264帧上面。
//h264视频流打包代码 // NALDecoder.cpp : Defines the entry point for the console application. #include <stdio.h> #include <stdlib.h> #include <string.h> #include <memory.h> #include “h264.h” #include “initsock.h” CInitSock initSock; // 初始化Winsock库 //为NALU_t结构体分配内存空间 NALU_t *AllocNALU(int buffersize) { NALU_t *pNalu; if ((pNalu = (NALU_t*)calloc (1, sizeof (NALU_t))) == NULL) { printf(“AllocNALU: Nalu”); exit(0); } pNalu->max_size=buffersize; if ((pNalu->buf = (char*)calloc (buffersize, sizeof (char))) == NULL) { free (pNalu); printf (“AllocNALU: Nalu->buf”); exit(0); } return pNalu; } //释放 void FreeNALU(NALU_t *pNalu) { if (pNalu) { if (pNalu->buf) { free(pNalu->buf); pNalu->buf=NULL; } free (pNalu); } } static int FindStartCode2 (unsigned char *Buf) { if(Buf[0]!=0 Buf[1]!=0 Buf[2] !=1) return 0; //推断是否为0x000001,假设是返回1 else return 1; } static int FindStartCode3 (unsigned char *Buf) { if(Buf[0]!=0 Buf[1]!=0 Buf[2] !=0 Buf[3] !=1) return 0;//推断是否为0x00000001,假设是返回1 else return 1; } // 这个函数输入为一个NAL结构体。主要功能为得到一个完整的NALU并保存在NALU_t的buf中,获取他的长度。填充F,IDC,TYPE位。 // 而且返回两个開始字符之间间隔的字节数,即包括有前缀的NALU的长度 int GetAnnexbNALU (NALU_t *pNalu, FILE *bits) { int info2=0, info3=0; int pos = 0; int StartCodeFound, rewind; unsigned char *Buf; if ((Buf = (unsigned char*)calloc (pNalu->max_size , sizeof(char))) == NULL) printf (“GetAnnexbNALU: Could not allocate Buf memory\n”); if (3 != fread (Buf, 1, 3, bits)) { //从码流中读3个字节 free(Buf); return -1; } if (Buf[0]!=0 Buf[1]!=0) { free(Buf); return -1; } if (Buf[2]==1) { pNalu->startcodeprefix_len=3; //初始化码流序列的開始字符为3个字节 pos =3; }else { if (1 != fread (Buf+3, 1, 1, bits)) { //从码流中读1个字节 free(Buf); return -1; } if (Buf[2]!=0 Buf[3]!=1) { free(Buf); return -1; } pos = 4; pNalu->startcodeprefix_len = 4; } //查找下一个開始字符的标志位 StartCodeFound = 0; info2 = 0; info3 = 0; while (!StartCodeFound) { if (feof (bits)) { //推断是否到了文件尾 break; } Buf[pos++] = fgetc (bits);//读一个字节到BUF中 info3 = FindStartCod
前面讲解了PS、TS、FLV这三种媒体封装格式,现在新开一个系列讲解下传输协议,这里面会包含RTP、RTSP、HLS、RTMP等。当然最复杂的封装格式MP4在准备中,后面会把封装格式这个系列讲完。今天要说的RTP传输协议,有人也认为这是封装格式,因为协议中打包音视频要填写时间戳的相关信息,FFmpeg就把这个作为封装格式。我觉得都没啥问题,不过我更偏向认为是传输协议。
Shell里有很多命令用来查看/管理/调试RTP,最基本的应该就是组件INCLUDE_RTP_SHOW带来的rtpShow()
http://blog.csdn.net/niu_gao/article/details/6946781
要想使用WindML,需要先将源码编译为库,内核态就用DKM来编译,用户态当然就用RTP了 打开Workbench,建个RTP:
AIE Kernel有时需要由外部提供参数更新kernel行为,此时就要用到RTP(Run-Time Parameter)。
在谈国网B接口的语音广播和语音对讲的时候,大家会觉得,国网B接口是不是和GB28181大同小异?实际上确实信令有差别,但是因为要GB28181设备接入测的对接,再次做国网B接口就简单多了。
实时视频点播、历史视频回放与下载的 TCP媒体传输应支持基于RTP封装的视音频PS流,封装格式参照IETFRFC4571。
https://www.srtalliance.org/interoperability-between-rtp-and-srt/
上篇文章提到Android端GB28181接入端的语音广播和语音对讲的实现,从spec角度大概介绍了下流程和简单的接口设计,好多开发者私信我,希望展开说一下。其实这块难度不大,只是广播和对讲涉及到双向实现,如果之前没有相关的积累,从头实现麻烦一些而已。
当应用程序建立一个RTP会话时,应用程序将确定一对目的传输地址。目的传输地址由一个网络地址和一对端口组成,有两个端口:一个给RTP包,一个给RTCP包,使得RTP/RTCP数据能够正确发送。RTP数据发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数UDP端口(偶数的UDP端口+1),这样就构成一个UDP端口对。 RTP的发送过程如下,接收过程则相反。
通常来说,RTSP提供UDP方式发送RTP流。当然,发送流媒体时,UDP往往是更好的选择。
GB28181的TCP码流遵循的标准是RFC4571(RTP OVER TCP),具体类型是:
RTSP协议是TCP/IP协议体系中的一个应用层协议,EasyNVR视频平台即是支持RTSP协议的流媒体服务器,能够自由对接流媒体服务器平台,支持微信、QQ、支付宝等工具,扫一扫直接观看,且不限制观看人数。
在《Task之任务的删除》里介绍了任务是如何退出的,那么进程呢?进程里可以启动多个任务,这些任务的存在与进程的存在是否有关系?
SIP(会话初始化协议)是在 IP网络上进行多媒体通信的应用层控制协议,以几种RFC的形式提供,其中最重要的是包含核心协议规范的RFC3261。该协议用于创建,修改和终止与一个或多个参与者的会话。通过会话,我们了解了一组进行通信的发送方和接收方,以及在通信过程中这些发送方和接收方保持的状态。会话的示例可以包括Internet电话呼叫,多媒体分发,多媒体会议,分布式计算机游戏等。
先看看RTP时间戳的定义: RTP包头的第2个32Bit即为RTP包的时间戳,Time Stamp ,占32位。 时间戳反映了RTP分组中的数据的第一个字节的采样时刻。在一次会话开始时的时间戳初值也是随机选择的。即使是没有信号发送时,时间戳的数值也要随时间不断的增加。接收端使用时间戳可准确知道应当在什么时间还原哪一个数据块,从而消除传输中的抖动。时间戳还可用来使视频应用中声音和图像同步。 在RTP协议中并没有规定时间戳的粒度,这取决于有效载荷的类型。因此RTP的时间戳又称为媒体时间戳,以强调这种时间戳的粒度取决于信号的类型。例如,对于8kHz采样的话音信号,若每隔20ms构成一个数据块,则一个数据块中包含有160个样本(0.02×8000=160)。因此每发送一个RTP分组,其时间戳的值就增加160。
如果你是音视频开发者亦或寻求这块技术方案的公司,在探讨这个问题之前,你可能网上看了太多关于语音广播和语音对讲相关的资料,大多文章认为语音对讲和语音广播无本质区别,实现思路也大同小异。
程序流程发送:获得接收端的IP地址和端口号创建RTP会话指定RTP数据接收端设置RTP会话默认参数发送流媒体数据接收:获得用户指定的端口号创建RTP会话设置接收模式接受RTP数据检索RTP数据源获取RTP数据报删除RTP数据报1.初始化I、在使用JRTPLIB进行实时流媒体数据传输之前,首先应该生成R...
程序流程 发送:获得接收端的 IP 地址和端口号 创建 RTP 会话 指定 RTP 数据接收端 设置 RTP 会话 默认参数 发送流媒体数据 接收:获得用户指定的端口号 创建RTP会话 设置接收模式 接受RTP数据 检索RTP数据源 获取RTP数据报 删除RTP数据报
实时视频系统中的媒体传输,绝大多数都会采用RTP(实时传输协议)标准。H.264视频作为当前应用最广泛的视频编码标准,其传输协议也会首选RTP标准。在设计实现H.264的实时传输时,H.264协议基于RTP的打包和解包定义于IETF标准-RFC6184,RTC系统需要遵循这个标准来设计打包和解包处理模块。在通信理论中,这个过程可以被认为是基于传输的信道编码。本篇技术文章带你了解H.264在RTP中的基本格式和技术实践。
原博客地址:http://www.cnblogs.com/qingquan/archive/2011/07/28/2120440.html
对网络协议来说,需要做的通常就两件事情:1、建立连接,2、传输数据,WebRTC也不例外。
基于RTP的 PS封装首先按照ISO/IEC13818-1:2000将视音频流封装成PS包,再将PS包以负载的方式封装成 RTP包。
导语 | 音视频时代,WebRTC在形形色色的产品和业务场景下均有落地。在熟悉如何在浏览器获取设备的音视频数据和WebRTC是如何将获取的音视频数据进行网络传输的同时,我们更要夯实一下网络传输协议相关的基础知识,这能帮助我们更深入地学习WebRTC。推荐和前端音视频专题中的文章一起食用。 1. 传输层协议:TCP vs. UDP 我们都知道HTTP协议,运行于TCP协议之上,是万维网的运转的基础。作为一名前端开发,我们似乎理所应当熟悉HTTP、TCP协议,以致于HTTP状态码、报文结构、TCP三次握手、四次
对于语音通信来说,语音的码率较低,添加适当的冗余是对抗网络丢包常见的方式。冗余方式分为多种,包括数据冗余,或者编码冗余等,RED,FEC等都是冗余的一种。如果冗余分数较多,可以采取交织的方式实现。RFC 2198 是冗余数据 RTP 封装的标准协议,RFC 3550 为RTP的基础标准协议,RFC 5109 为FEC数据的 RTP 封装标准协议。webrtc中有RED和FEC相关的实现与处理,这也是在看代码时才决定重新整理协议并记录下来。
在基于RTP的实时码流传输过程中,经常会遇到音视频卡顿、花屏的现象。对于这类问题,如何定位? 下面这个工具可以帮助分析类似问题:
之前我们已经分享过很多关于音视频处理的文章。其中最绕不开的就是ffmpg工具,这个命令行工具构建了当今大小智能设备音频,视频,图片等多媒体文件处理的方方面面。
调阅实时视频包括信令接口和媒体流接口,采用标准的SIP INVITE+SDP流程,媒体传输使用RTP/RTCP。
在实时音视频通话中,我们通常使用 UDP 作为传输层协议,使用 RTP 协议包荷载音视频数据,RTP(Real-time Transport Protocol)是一种在 Internet 上传输多媒体数据的应用层协议,它通常建立在 UDP 之上(也可以建立在 TCP 上)。UDP 协议没有序号等信息,而 RTP 协议可以补充许多音视频传输必要的信息,让音视频数据到达对端后可以重新组合完整,RTP 本身只保证实时数据的传输,并不能提供可靠传输保证,也没有流量控制,拥塞控制机制,它通常与 RTCP 配合使用以提供这些服务。
请横屏观看 或使用搜索功能 以下命令出自Vx69 命令 简介 adrsp Display information on the address space. alias Add an alias or display alias arp IPNET arp control bp Display, set or unset a breakpoint C Switch to C interpreter cd Change current directory. cpu Set/Get CPU affi
领取专属 10元无门槛券
手把手带您无忧上云