本文共 2399 字,大约阅读时间需要 7 分钟。
github上的ortp库镜像:
1、ORTP库概览
(1)没有main,在src目录下提供一堆功能函数 (2)使用案例:有main,在src/tests目录下 (3)相关数据结构和头文件在include/ortp目录下 (4)ortp实现了rtp和rtcp协议,前者负责传输,后者负责控制和同步协调2、ORTP库的使用案例
(1)src/tests/rtpsend.c (2)ortp_init及av_profile_init (3)ortp_scheduler_init和ORTP调度器:一个任务中完成多个会话的发送和接收,类似于select (4)rtp_session_new和rtp的会话管理3、rtp的session
(1)rtp通过会话来管理数据发送和接收,会话的本质是一个结构体,管理很多信息 (2)创建会话用rtp_session_new (3)rtp发送用rtp_session_send_with_ts (4)底层真正干活的还是socket接口那一套,参考rtpsession_inet.c4、ORTP的一些小细节
(1)port.c中对OS的常用机制(任务创建和销毁、进程管理和信号量等)进行了封装,便于将ortp移植到不同平台中 (2)utils.c中实现了一个双向链表 (3)str_util.c中实现了一个队列管理 (4)rtpparse.c和rtcpparse.c文件实现了解析收到的rtp数据包的部分 (5)jitterctl.c中实现了jitter buffer来防抖。jitter buffer技术是ip 音视频通信里相对比较高级的主题,jitter buffer模块好坏通常是衡量一个voip客户端/服务器好坏的技术点之一,尤其是在网络抖动比较严重,如3g, wifi环境,数据包的rtt值不均衡往往会导致语音卡顿,丢字等现象,jitter buffer 模块通过缓存一段数据包,把数据包重排,并均匀的送给播放端,一个好的jitter buffer实现通长是动态调整缓存大小的,在网络延迟大,抖动严重时会动态增加缓存大小,在网络恢复时动态减小缓存大小以减少端到端的播放延迟。5.Jitter buffer
https://blog.csdn.net/wangdapao12138/article/details/82535113
如果网络是理想的,即无丢包、无抖动、低延时,那么接收到一帧完整数据就直接播放,效果一定会非常好。但是实际的网络往往很复杂,尤其是无线网络。如果还是这样直接播放,网络稍微变差,视频就会卡顿,出现马赛克等异常情况。所以,在接收端对接收的数据做一个缓冲是很有必要的。 缓冲一定是以延时作为代价的,延时越大,对抖动的过滤效果越好。一个优秀的视频jitterbuffer,不仅要能够对丢包、乱序、延时到达等异常情况进行处理,而且还要能够让视频平稳的播放,尽可能的避免出现明显的加速播放和缓慢播放。 主流的实时音视频框架基本都会实现jitterbuffer功能,诸如WebRTC、doubango等。WebRTC的jitterbuffer相当优秀,按照功能分类的话,可以分为jitter和buffer。buffer主要对丢包、乱序、延时到达等异常情况进行处理,还会和NACK、FEC、FIR等QOS相互配合。jitter主要根据当前帧的大小和延时评估出jitter delay,再结合decode delay、render delay以及音视频同步延时,得到render time,来控制平稳的渲染视频帧。
后记:
从上述原理可以看出,WebRTC中的接收buffer并非是固定的,而是根据网络波动等因素随时变化的。jitter则是为了对抗网络波动造成的抖动,使得视频能够平稳播放。 那么,jitterbuffer是否存在可以优化的空间呢?jitterbuffer已经较为优秀,但我们可以通过调整里面的一些策略,来使视频质量更好。比如,增大缓冲区,因为jitterbuffer是动态的,直接增大freeframes的size是无效的,只能通过调整延时,来增大缓冲区。再比如,调整等待时间,以期望获得更多完整的帧。再如,配合NACK,FIR、FEC等QOS策略,来对抗丢包。 当然,这都是以牺牲延时为代价的。总之,要在延时和丢包、抖动之间做出平衡。
m=video 8080 RTP/AVP 96
a=rtpmap:96 H264 a=framerate:25 c=IN IP4 192.168.1.202 SDP各个参数简单介绍
下面示例摘自3264协议[1] v=0 o=carol 28908764872 28908764872 IN IP4 100.3.6.6 //会话ID号和版本 s=- //用于传递会话主题 t=0 0 //会话时间,一般由其它信令消息控制,因此填0 c=IN IP4 192.0.2.4 //描述本端将用于传输媒体流的IP m=audio 0 RTP/AVP 0 1 3 //媒体类型 端口号 本端媒体使用的编码标识(Payload)集 a=rtpmap:0 PCMU/8000 //rtpmap映射表,各种编码详细描述参数,包括使用带宽(bandwidth) a=rtpmap:1 1016/8000 a=rtpmap:3 GSM/8000 a=sendonly //说明本端媒体流的方向,取值包括sendonly/recvonly/sendrecv/inactive a=ptime:20 //说明媒体流打包时长 m=video 0 RTP/AVP 31 34 a=rtpmap:31 H261/90000 a=rtpmap:34 H263/90000