rtp协议

背景： 我在最近的项目中遇到了使用Android的MediaPlayer来进行RTSP播放的场景。但对于RTSP这种流媒体协议，其实Android原生的播放器支持得不是很好，所以有许多需要修改的地方。 本文主要简单介绍RTSP协议及其在MediaPlayer中的层级，后续会记录下在项目中遇到的具体情况及对应的修改。 RTSP播放器架构 播放器的架构很清晰， apk–>MediaPlayer->media_server–>厂商自己的Player(和NuPalyer/StagefrightPlayer一个层级)–>FFmpeg 如下图。 因为走Android MediaPlayer的流程，拉流的部分是使用FFmpeg实现的，所以FFmpeg是最核心的部分，主要的修改，也即是针对FFmpeg里RTSP部分的修改，以适配项目的特殊性。 ##RTSP协议简介## ###1、简介### RTSP属于应用层协议，被用于控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色，对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据。 因为RTSP的作用相当于流媒体服务器的远程控制，所以客户端需要和服务器进行命令交互，以到达建立/释放连接及远程控制的目的。命令连接基于TCP，一般使用554端口。而数据传输可以选择TCP或UDP来传送，这个需要看服务端的支持情况及客户端的选择。

RTP 参考文档 RFC3550/RFC3551 Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 RTP 由两个紧密链接部分组成： RTP ― 传送具有实时属性的数据；RTP 控制协议（RTCP） ― 监控服务质量并传送正在进行的会话参与者的相关信息。 RTCP 实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制

1 RTSP概述 1.1 RTSP概念 RTSP(Real-Time Stream Protocol ) 是一种基于文本的应用层协议，在语法及一些消息参数等方面， RTSP 协议与 HTTP 协议类似。 RTSP 被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。 RTSP 本身并不用于传送媒体流数据。媒体数据的传送可通过 RTP/RTCP 等协议来完成。 1.2 基本的 RTSP 操作过程 首先，客户端连接到流服务器并发送一个 OPTIONS 命令查询服务器提供的方法收到服务器的回应后，发送 DESCRIBE 命令查询某个媒体文件的 SDP 信息。流服务器通过一个 SDP 描述来进行回应，回应信息包括流数量、媒体类型等信息。客户端分析该 SDP 描述，并为会话中的每一个流发送一个 SETUP 命令， SETUP 命令告诉服务器客户端用于接收媒体数据的端口。流媒体连接建立完成后，客户端发送一个 PLAY 命令，服务器就开始传送媒体流数据。在播放过程中客户端还可以向服务器发送 PAUSE 等其他命令控制流的播放。通信完毕，客户端可发送 TERADOWN 命令来结束流媒体会话。 1.3 RTSP与HTTP的区别 可以发现 RTSP 协议的格式与 http 协议很类似，都是基于文本的协议，语法也基本相同。但是它们并不相同，有以下主要差别： 首先，方法名称不同。

1、简介 目前，在IP网络中实现实时语音、视频通信和应用已经成为网络应用的一个主流技术和发展方向，本文详细介绍IP协议族中用于实时语音、视频数据传输的标准协议RTP（ Real-time Transport Protocol）和RTCP（RTP Control Ptotocol）的主要功能。 2、RTP/RTCP协议简介 RTP 由 IETF（ http://www.ietf.org/ ）定义在 RFC 3550和3551中。 RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议，与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性，此协议提供的服务包括数据顺序号、时间标记、传输控制等。 RTP通常与辅助控制协议RTCP一起工作，RTP只负责实时数据的传输，RTCP负责对RTP的通信和会话进行带外管理（如流量控制、拥塞控制、会话源管理等）。 3、RTP/RTCP协议层次和封装 RTP位于传输层（通常是UDP）之上，应用程序之下，实时语音、视频数据经过模数转换和压缩编码处理后，先送给RTP封装成为RTP数据单元，RTP数据单元被封装为UDP数据报，然后再向下递交给IP封装为IP数据包。 RTP分组只包含RTP数据，而控制是由另一个配套协议RTCP提供。RTP在端口号1025到65535之间选择一个未使用的偶数UDP端口号

本文在文章[1]的基础上，从源代码实现角度对WebRTC的GCC算法进行分析。主要内容包括： RTCP RR的数据源、报文构造和接收，接收端基于数据包到达延迟的码率估计，发送端码率的计算以及生效于目标模块。 拥塞控制是实时流媒体应用的重要服务质量保证。通过本文和文章[1][2]，从数学基础、算法步骤到实现细节，对WebRTC的拥塞控制GCC算法有一个全面深入的理解，为进一步学习WebRTC奠定良好基础。 1 GCC算法框架再学习 本节内容基本上是文章[1]第1节的复习，目的是再次复习GCC算法的主要框架，梳理其算法流程中的数据流和控制流，以此作为后续章节的行文提纲。GCC算法的数据流和控制流如图1所示。 图1 GCC算法数据流和控制流 对发送端来讲，GCC算法主要负责两件事：1)接收来自接收端的数据包信息反馈，包括来自RTCP RR报文的丢包率和来自RTCP REMB报文的接收端估计码率，综合本地的码率配置信息，计算得到目标码率A。2)把目标码率A生效于目标模块，包括PacedSender模块，RTPSender模块和ViEEncoder模块等。 对于接收端来讲，GCC算法主要负责两件事：1）统计RTP数据包的接收信息，包括丢包数、接收RTP数据包的最高序列号等，构造RTCP RR报文，发送回发送端。2）针对每一个到达的RTP数据包，执行基于到达时间延迟的码率估计算法

一．产生的背景 随着互连网的发展，人们已经不满足于传统的HTTP，FTP和电子邮件等文本信息和服务，而对内容丰富多彩的多媒体信息，服务以及多媒体通信方式提出了需求，包括声音，图象，图形，视频信息等等，而这些不但传输的数据量大而且对交互性和实时性要求很高。 这时,基于HTTP的TCP协议无法达到要求,故产生RTP协议来进行多媒体数据实时传输. RTP/RTCP,RTSP图例 协议关系图 二．RTP/RTCP/RTSP协议与TCP/IP协议对比 那么，现在有个疑问是:为什么TCP/IP协议就不能满足多媒体通信的要求呢？ 这是因为TCP有以下4个特点: 1.TCP重传机制 2.TCP拥塞控制机制 3.TCP报文头比UDP报文头要大 4.TCP的启动速度慢 RTP由IETF（Internet Engineering Task Force，互联网工程任务组）的音频/视频传输工作组制定，主要实现实时数据的传输，它在包头中提供编码类型，包中数据的采样时刻和数据包的序号，根据这些信息发送和接受方可以协商编码类型，可以对接收到的数据包进行排序等工作；RTCP主要负责传输质量的监控以及传送发送者的一些标志信息。试验和研究表明，RTP/RTCP所提出的实时数据的传输机制是行之有效的。 对比记忆 IP:数据传输 RTP:多媒体数据实时传输 TCP:保证数据传输可靠 RTCP:保证多媒体数据传输的可靠 三

用一句简单的话总结：RTSP发起/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进行控制，同步。 转自该博客：http://blog.csdn.net/xdwyyan/article/details/41721307?utm_source=tuicool&utm_medium=referral 感觉这些基础关系此君写的比较清楚，转载学习一下，如有侵权，联立删 1、 RTP Real-time Transport Protocol，是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于网络应用程序去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。 2、 RTCP 实时传输控制协议（Real-time Transport Control

pgm不太能用，没有想象中的可靠，重传机制貌似仍然使用组播重传，丢包率80%的网络感觉没啥改进，如果有所好转延迟估计也是个不小的问题。 后听说rtp也有nack机制，webrtc基于rtp实现了重传在一定程度上保证可靠性。 在各路大神的指引下找到了rfc4585，看到了这么一段 RTCP扩展反馈报文，有一种nack报文 当FMT=1并且PT=205时，代表此报文是个NACK报文 Name Value Brief Description RTPFB 205 Transport layer FB message PSFB 206 Pyload-specific FB message 0: unassigned 1: Generic NACK 2-30: unassigned 31: reserved for future expansion of the identifier number space The Generic NACK message is identified by PT=RTPFB and FMT=1. FCI字段会有如下图所示的数据 PID：表示Packet ID，用于表明当前接收端丢失的数据包的序号，是接收端期待收到的下一个数据包 BLP：表示bitmask of following lost lost packets，占两个字节，16位

https://blog.csdn.net/pu1030/article/details/7619908 http://blog.chinaunix.net/uid-27875-id-5017161.html 流媒体指的是在网络中使用流技术传输的连续时基媒体，其特点是在播放前不需要下载整个文件，而是采用边下载边播放的方式，它是视频会议、IP电话等应用场合的技术基础。RTP是进行实时流媒体传输的标准协议和关键技术，本文介绍如何在Linux下利用JRTPLIB进行实时流媒体编程。 一、流媒体简介 随着Internet的日益普及，在网络上传输的数据已经不再局限于文字和图形，而是逐渐向声音和视频等多媒体格式过渡。目前在网络上传输音频/视频（Audio/Video，简称A/V）等多媒体文件时，基本上只有下载和流式传输两种选择。通常说来，A/V文件占据的存储空间都比较大，在带宽受限的网络环境中下载可能要耗费数分钟甚至数小时，所以这种处理方法的延迟很大。如果换用流式传输的话，声音、影像、动画等多媒体文件将由专门的流媒体服务器负责向用户连续、实时地发送，这样用户可以不必等到整个文件全部下载完毕，而只需要经过几秒钟的启动延时就可以了，当这些多媒体数据在客户机上播放时，文件的剩余部分将继续从流媒体服务器下载。 流（Streaming）是近年在Internet上出现的新概念，其定义非常广泛