概述 近期在和同事调试G729的编解码库时碰到一个语音质量的问题,问题产生的原因和RTP包中的时间戳设置有关,特此记录下来. 问题现象,1001和1002账号注册在fs,媒体设置为G729并通过fs中转,1001终端使用eyebean,1002终端使用自己开发的sip终端,从1001-1002的语音正常,从1002-1001的语音卡顿异常. 环境 centos:CentOS  release 7.0 (Final)或以上版本 freeswitch:v1.8.7 GCC:4.8.5 问题分析 fr

转自:http://blog.csdn.net/xujianglun/article/details/48342367 如何计算G711语音等的打包长度和RTP里timestamp的增长量 一般对于不同的语音有不同的打包周期,而不同的打包周期又对应着不同的timestamp in RTP 那么是如何计算的呢,我们通过G711举个例子 G711的打包周期分为10ms,20ms,30ms,sample rate是8000,速率是64kbit/s 64kbits,意味着每秒发送64000比特 那么10

如何计算G711语音等的打包长度和RTP里timestamp的增长量 一般对于不同的语音有不同的打包周期,而不同的打包周期又对应着不同的timestamp in RTP 那么是如何计算的呢,我们通过G711举个例子 G711的打包周期分为10ms,20ms,30ms,sample rate是8000,速率是64kbit/s 64kbits,意味着每秒发送64000比特 那么10ms发送= 64000 * (10/1000) = 640 比特 = 80 字节 那么10ms的包 = 80字节20ms

NTP------网络时间协议 PTP------精确时间协议 PTS,DTS的关系: http://www.cnblogs.com/qingquan/archive/2011/07/27/2118967.html 都知道RTSP协议中,真正的数据传输是RTP协议来传输的,每个RTP包都有一个timestamp,(相对时间戳 relative timestamp)这个时间戳是需要经过换算的,我需要把它换算成相应的时间打印到播放器显示的每一帧上. 不过据http://stackoverflow.c

H.264 视频 RTP 负载格式 1. 网络抽象层单元类型 (NALU) NALU 头由一个字节组成, 它的语法如下: +---------------+      |0|1|2|3|4|5|6|7|      +-+-+-+-+-+-+-+-+      |F|NRI|  Type   |      +---------------+ F: 1 个比特.  forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0. NRI: 2 个比特.  nal_ref_idc

最近在看RTP发送H264数据的文章,感觉很乱,没有比较清晰易懂的教程,自己整理了一下各种资料,备忘! --------Part A  ---- 先说说H264数据,H264在网络传输的是NALU(NAL单元),NALU的结构是:NAL头+RBSP,实际传输中的数据流如图所示: NALU头用来标识后面的RBSP是什么类型的数据,他是否会被其他帧参考以及网络传输是否有错误. NALU头结构为1个字节,既 forbidden_bit(1bit) + nal_reference_bit(2bit) +

live555中数据的发送最后是要使用RTP协议发送的,下面介绍一下RTP包格式. RTP packet RTP是基于UDP协议的,RTP服务器会通过UDP协议,通常每次会发送一个RTP packet.客户端通过解析RTP packet,读取其中的数据然后进行播放了. RTP packet的结构如下: RTP Header:RTP 包的头部 contributing sources:个数为0-n个,所以可以为空.具体定义参考rfc3550 RTP payload:即RTP要传输的数据 RTP H

前段时间写了一个局域网音视频通话的程序,使用开源 KCP 来实现可靠UDP传输. 通过研究发现KCP在发包时,会在数据包前面加上它自己的头.如果数据包较小,KCP可能会把多个数据包合成一个包发送,提高效率. 如下图所示. kcp udp 包结构 28 bytes 4 bytes 4 bytes len1 28 bytes 4 bytes 4 bytes len2├────────────┼────────┬────────┼────────┼────────────┼────────┬─────

[原创] RFC3984是H.264的baseline码流在RTP方式下传输的规范,这里只讨论FU-A分包方式,以及从RTP包里面得到H.264数据和AAC数据的方法. 1.单个NAL包单元 12字节的RTP头后面的就是音视频数据,比较简单.一个封装单个NAL单元包到RTP的NAL单元流的RTP序号必须符合NAL单元的解码顺序. 2.FU-A的分片格式数据比较大的H264视频包,被RTP分片发送.12字节的RTP头后面跟随的就是FU-A分片:FU indicator有以下格式:      +--

这里主要分析一下,live555中关于RTP打包发送的部分.在处理完PLAY命令之后,就开始发送RTP数据包了(其实在发送PLAY命令的response包之前,就会发送一个RTP包,这里传输就已经开始了) 先介绍下主要的流程:RTP包的发送是从MediaSink::startPlaying函数调用开始的,在StartPlaying函数的最后会调用函数continuePlaying. continuePlaying函数是定义在MediaSink类中的纯虚函数,需要到特定媒体的sink子类中实现,对

转载一篇帮助我了解h264 rtp的文档,地址http://www.cppblog.com/czanyou/archive/2009/12/25/67940.html 当packetization-mode的值为0时或不存在时,必须使用单一NALU单元模式. 当packetization-mode的值为1时必须使用非交错(non-interleaved)封包模式. 当packetization-mode的值为2时必须使用交错(interleaved)封包模式. 每个打包方式允许的NAL单元类型总

最近在做基于SIP的VoIP通信研究,使用Wireshark软件可以对网络流量进行抓包. VoIP使用RTP协议对语音数据进行传输,语音载荷都封装在RTP包里面.要对传输中的语音进行截获和还原,需要通过Wireshark对RTP包进行分析和解码.该过程如下: 1.打开截获的pcapng文件,点击Telephony-->RTP-->Show All Streams. 2.根据发送地址和目的地址,选择要分析的语音流,点击图中的Analyze进行分析处理.Packets数太少可能会播放不出声音. 3

1.  预备 视频: 由一副副连续的图像构成,由于数据量比较大,因此为了节省带宽以及存储,就需要进行必要的压缩与解压缩,也就是编解码. h264裸码流: 对一个图像或者一个视频序列进行压缩,即产生码流,采用H264编码后形成的码流就是h264裸码流. 码流传输: 发送端将H264裸码流打包后进行网络传输,接收端接收后进行组包还原裸码流,然后可以再进行存储,转发,或者播放等等相关的处理. 存储转发可以直接使用裸码流,播放则需要进行解码和显示处理 解码显示:        一般会解成YUV数据,然后

我们在上一期使用RTP协议,并进行了配置,打包了视频数据,这一期我们就对发送的数据进行重组,并显示在接受端上.最后对其进行扩展,支持多客户端视频发送,并在接收端分屏显示.完成远程监控的模拟. 先来个效果图吧 private bool NewRTPPacket(RTPPacket packet) { if (!Clients.ContainsKey(packet.SSRC))//如果接受端第一次接受到某源的数据,则加入到 { if (Clients.Count < 4)//如果发送端为4,则丢弃包

(1)sdp 描述格式 (2)sdp example (3) sdp (1)sdp 描述格式 m=video 1234 RTP/AVP 96a=rtpmap:96 H264a=framerate:15c=IN IP4 192.168.0.104 上面是自己写的一个rtp m=audio 1234 RTP/AVP 0a=rtpmap:0 pcma/8000/1a=framerate:25 c=IN IP4 172.18.168.45 1.m=是媒体级会话的开始处,audio:媒体类型 : 1234

H264的RTP负载打包的数据包格式,分组,分片 1.    RTP数据包格式 RTP报文头格式(见RFC3550 Page12): 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC   |M|     PT     |       sequence number 

转自:http://blog.csdn.net/jasonhwang/article/details/7316128 RTP timestamp是用时钟频率(clock rate)计算而来表示时间的. RTP timestamp表示每帧的时间,由于一个帧(如I帧)可能被分成多个RTP包,所以多个相同帧的RTP timestamp相等.(可以通过每帧最后一个RTP的marker标志区别帧,但最可靠的方法是查看相同RTP timestamp包为同一帧.) 两帧之间RTP timestamp的增量 =

from:http://blog.csdn.net/dengzikun/article/details/5807694 最近考虑使用RTP替换原有的高清视频传输协议,遂上网查找有关H264视频RTP打包.解包的文档和代码.功夫不负有心人,找到不少有价值的文档和代码.参考这些资料,写了H264 RTP打包类.解包类,实现了单个NAL单元包和FU_A分片单元包.对于丢包处理,采用简单的策略:丢弃随后的所有数据包,直到收到关键帧.测试效果还不错,代码贴上来,若能为同道中人借鉴一二,足矣.两个类的使用说

最近考虑使用RTP替换原有的高清视频传输协议,遂上网查找有关H264视频RTP打包.解包的文档和代码.功夫不负有心人,找到不少有价值的文档和代码.参考这些资料,写了H264 RTP打包类.解包类,实现了单个NAL单元包和FU_A分片单元包.对于丢包处理,采用简单的策略:丢弃随后的所有数据包,直到收到关键帧.测试效果还不错,代码贴上来,若能为同道中人借鉴一二,足矣.两个类的使用说明如下(省略了错误处理过程): DWORD H264SSRC ; CH264_RTP_PACK pack ( H264S

对于语音通信而言,语音码率较低,添加适当冗余是对抗网络丢包的常见方式.冗余方式有多种,包括RED,FEC等都是冗余的一种,如果冗余份数较多,可以采取交织的方式实现.RFC 3350是RTP的基础标准协议,RFC 2198是冗余数据RTP封装的标准协议,RFC 5109是添加FEC数据的RTP封装标准协议. RTP格式(RFC 3350) 文档地址:RTP: A Transport Protocol for Real-Time Applications RTP(Real-time Transpor