1. 简介
stun协议本身是用来进行NAT穿透使用,其本身实际上是NAT内部设备获取外部IP地址的一种协议。STUN协议在RFC上目前经过三种演变,其中RFC3489上定义的STUN和之后的RFC5389和8489上定义的stun在概念上存在明显区分:
RFC3489定义:Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN)
RFC5389和RFC8489:Session Traversal Utilities for NAT (STUN)
可以看到STUN协议的英文描述本身就已经发生了变化,3489中定义的是通过UDP进行NAT穿越的方式,而在RFC5389上定义的是对于NAT穿越的一整套工具集,这个工具集不在局限于UDP而是同时适用于UDP和TCP协议。
stun信令
2021-06-25 13:08:25详解RTP协议之H264封包和解包实战
2021-06-25 04:43:491.RTP实战源码框架
在win上主要是支持qt,使用2015编译器。linux上支持cmake编译。主要是支持跨平台支持。
使用函数int get_annexb_nalu (nalu_t *nalu, FILE *bits),一开始是读取本地h264文件,解析出不带startcode的nalu,接着是函数static void rtp_h264_pack_get_info(void* pack, uint16_t* seq, uint32_t* timestamp),经过函数就会得到RTP包,处理RTP包就有2个流程,第一个是通过网络发送出去,然后播放。另外一个流程是通过RTP_unpack去解码,生成nalu,再加上h264的start code,就可以存储在本地文件,然后再播放。框架如下图所示:
实现RTP协议的H.264视频传输系统
2021-06-23 00:34:25 随着信息产业的发展,人们对信息资源的要求已经逐渐由文字和图片过渡到音频和视频,并越来越强调获取资源的实时性和互动性。但人们又面临着另外一种不可避免的尴尬,就是在网络上看到生动清晰的媒体演示的同时,不得不为等待传输文件而花费大量时间。为了解决这个矛盾,一种新的媒体技术应运而生,这就是流媒体技术。流媒体由于具有启动时延小、节省客户端存储空间等优势,逐渐成为人们的首选,流媒体网络应用也在全球范围内得到不断的发展。其中实时流传输协议 RTP 详细说明了在互联网上传递音频和视频的标准数据包格式,它与传输控制协议 RTCP 配合使用,成为流媒体技术最普遍采用的协议之一。
H.264/AVC 是ITU-T 视频编码专家组(VCEG)和ISO/IEC 动态图像专家组(MPEG )联合组成的联合视频组(JVT)共同努力制订的新一代视频编码标准,它最大的优势是具有很高的数据压缩比率,在同等图像质量的条件下,H.264 的压缩比是MPEG-2 的2 倍以上,是 MPEG-4的1.5~2 倍。同时,采用视频编码层(VCL)和网络提取层(NAL )的分层设计,非常适用于流媒体技术进行实时传输。本文就是基于 RTP 协议,对 H.264 视频进行流式打包传输,实现了一个基本的流媒体服务器功能,同时利用开源播放器VLC 作为接收端,构成一个完整的H.264 视频传输系统。
视频编解码学习之一:理论基础
2021-06-23 00:31:03第1章介绍
1. 为什么要进行视频压缩?
- 未经压缩的数字视频的数据量巨大
-
存储困难
- 一张DVD只能存储几秒钟的未压缩数字视频。
-
传输困难
- 1兆的带宽传输一秒的数字电视视频需要大约4分钟。
2. 为什么可以压缩
-
去除冗余信息
- 空间冗余:图像相邻像素之间有较强的相关性
- 时间冗余:视频序列的相邻图像之间内容相似
- 编码冗余:不同像素值出现的概率不同
- 视觉冗余:人的视觉系统对某些细节不敏感
- 知识冗余:规律性的结构可由先验知识和背景知识得到
3. 数据压缩分类
-
无损压缩(Lossless)
- 压缩前解压缩后图像完全一致X=X'
- 压缩比低(2:1~3:1)
- 例如:Winzip,JPEG-LS
-
有损压缩(Lossy)
- 压缩前解压缩后图像不一致X≠X'
- 压缩比高(10:1~20:1)
- 利用人的视觉系统的特性
- 例如:MPEG-2,H.264/AVC,AVS
H264关于RTP协议的实现
2021-06-23 00:29:52完整的C/S架构的基于RTP/RTCP的H.264视频传输方案。此方案中,在服务器端和客户端分别进行了 功能模块设计。 服务器端:RTP封装模块主要是对H.264码流进行打包封装;RTCP分析模块负责产牛和发送RTCP包并分析接收到的RTCP包;QoS反馈控制模块则根据RR报文反馈信息动态的对发送速率进行调整;发送缓冲模块则设置端口发送RTP、RTCP包。 客户端:RTP模块对接收到的RTP包进行解析判断;RTCP模块根据SR报文统计关键信息,产牛并发送RR包。然后,在VC++6.0下用Socket编程,完成基于RTP/UDP/IP的H.264视频传输,并在局域网内运行较好。
基于RTP/UDP/lP的H.264视频传输结构设计
对于H.264视频的实时传输应用来说,TCP的重传机制引入的时延和抖动是无法容忍的,因此我们采用UDP传输协议。但是UDP协议本身是面向无连接的,不能提供质量保证。而基于UDP之上的高层协议RTP/RTCP可以一起提供流量控制和拥塞控制服务。图给出了基于RTP/UDP/IP的H.264视频传输的框架。
H264--3--NAL层的处理
2021-06-23 00:25:36H264以NALU(NAL unit)为单位来支持编码数据在基于分组交换技术网络中传输。
NALU定义了可用于基于分组和基于比特流系统的基本格式,同时给出头信息,从而提供了视频编码和外部世界的接口。
H264编码过程中的三种不同的数据形式:
SODB 数据比特串-->最原始的编码数据,即VCL数据;
RBSP 原始字节序列载荷-->在SODB的后面填加了结尾比特(RBSP trailing bits 一个bit“1”)若干比特“0”,以便字节对齐;
EBSP 扩展字节序列载荷-->在RBSP基础上填加了仿校验字节(0X03)它的原因是: 在NALU加到Annexb上时,需要添加每组NALU之前的开始码StartCodePrefix,如果该NALU对应的slice为一帧的开始则用4位字节表示,ox00000001,否则用3位字节表示ox000001(是一帧的一部分)。另外,为了使NALU主体中不包括与开始码相冲突的,在编码时,每遇到两个字节连续为0,就插入一个字节的0x03。解码时将0x03去掉。也称为脱壳操作。
H264--1--编码原理以及I帧B帧P帧
2021-06-23 00:23:08H264是新一代的编码标准,以高压缩高质量和支持多种网络的流媒体传输著称,在编码方面,我理解的他的理论依据是:参照一段时间内图像的统计结果表明,在相邻几幅图像画面中,一般有差别的像素只有10%以内的点,亮度差值变化不超过2%,而色度差值的变化只有1%以内。所以对于一段变化不大图像画面,我们可以先编码出一个完整的图像帧A,随后的B帧就不编码全部图像,只写入与A帧的差别,这样B帧的大小就只有完整帧的1/10或更小!B帧之后的C帧如果变化不大,我们可以继续以参考B的方式编码C帧,这样循环下去。这段图像我们称为一个序列(序列就是有相同特点的一段数据),当某个图像与之前的图像变化很大,无法参考前面的帧来生成,那我们就结束上一个序列,开始下一段序列,也就是对这个图像生成一个完整帧A1,随后的图像就参考A1生成,只写入与A1的差别内容。
在H264协议里定义了三种帧,完整编码的帧叫I帧,参考之前的I帧生成的只包含差异部分编码的帧叫P帧,还有一种参考前后的帧编码的帧叫B帧。
H264采用的核心算法是帧内压缩和帧间压缩,帧内压缩是生成I帧的算法,帧间压缩是生成B帧和P帧的算法。
H264--2--语法及结构
2021-06-23 00:21:50名词解释
场和帧 : 视频的一场或一帧可用来产生一个编码图像。在电视中,为减少大面积闪烁现象,把一帧分成两个隔行的场。
片: 每个图象中,若干宏块被排列成片的形式。片分为I片、B片、P片和其他一些片。
I片只包含I宏块,P片可包含P和I宏块,而B片可包含B和I宏块。
I宏块利用从当前片中已解码的像素作为参考进行帧内预测。
P宏块利用前面已编码图象作为参考图象进行帧内预测。
B宏块则利用双向的参考图象(前一帧和后一帧)进行帧内预测。
片的目的是为了限制误码的扩散和传输,使编码片相互间是独立的。
某片的预测不能以其它片中的宏块为参考图像,这样某一片中的预测误差才不会传播到其它片中去。
宏块 : 一个编码图像通常划分成若干宏块组成,一个宏块由一个16×16亮度像素和附加的一个8×8 Cb和一个8×8 Cr彩色像素块组成。
如何实现1080P延迟低于500ms的实时超清直播传输技术
2021-06-23 00:20:35最近由于公司业务关系,需要一个在公网上能实时互动超清视频的架构和技术方案。众所周知,视频直播用 CDN + RTMP 就可以满足绝大部分视频直播业务,我们也接触了和测试了几家 CDN 提供的方案,单人直播没有问题,一旦涉及到多人互动延迟非常大,无法进行正常的互动交谈。对于我们做在线教育的企业来说没有互动的直播是毫无意义的,所以我们决定自己来构建一个超清晰(1080P)实时视频的传输方案。
先来解释下什么是实时视频,实时视频就是视频图像从产生到消费完成整个过程人感觉不到延迟,只要符合这个要求的视频业务都可以称为实时视频。关于视频的实时性归纳为三个等级:
-
伪实时:视频消费延迟超过 3 秒,单向观看实时,通用架构是 CDN + RTMP + HLS,现在基本上所有的直播都是这类技术。
-
准实时: 视频消费延迟 1 ~ 3 秒,能进行双方互动但互动有障碍。有些直播网站通过 TCP/UDP + FLV 已经实现了这类技术,YY 直播属于这类技术。
-
真实时:视频消费延迟 < 1秒,平均 500 毫秒。这类技术是真正的实时技术,人和人交谈没有明显延迟感。QQ、微信、Skype 和 WebRTC 等都已经实现了这类技术。
市面上大部分真实时视频都是 480P 或者 480P 以下的实时传输方案,用于在线教育和线上教学有一定困难,而且有时候流畅度是个很大的问题。在实现超清晰实时视频我们做了大量尝试性的研究和探索,在这里会把大部分细节分享出来。