<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/mlfcjob</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; mlfcjob]]></copyright><item><title><![CDATA[手撕RTSP协议系列（13）——RTCP协议]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109336899</link><guid>https://blog.csdn.net/mlfcjob/article/details/109336899</guid><author>mlfcjob</author><pubDate>Wed, 28 Oct 2020 16:43:03 +0800</pubDate><description><![CDATA[RTCP简介

之前的文章，介绍了RTSP和RTP协议，RTSP用于建立连接及发送请求等，RTP用于实际的媒体数据传输。整个RTSP的流程中，还有一种不可或缺的协议， 那就是RTCP。RTCP的全称是RTP Control Protocol，从英文名称可以看出，其是针对RTP的控制协议！RTCP主要用于提供数据分发质量反馈信息，本文详细介绍一下RTCP协议！



数据包格式

首先，让我们来看一下RTCP的数据包格式，如下图：





对照示意图，可以看到如下字段，下面做详细解释：

V...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（12）——RTP包格式]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109336780</link><guid>https://blog.csdn.net/mlfcjob/article/details/109336780</guid><author>mlfcjob</author><pubDate>Wed, 28 Oct 2020 16:40:02 +0800</pubDate><description><![CDATA[前面我们花了较多的篇幅来介绍了RTSP协议的一些细节，但是rtsp传输，本质上涉及三种协议，RTSP、RTP以及RTCP。RTSP主要负责连接建立，销毁及一些其他的控制。而实际涉及媒体数据传输使用的是RTP协议，本节我们来介绍一下RTP协议。



RTP概览

RTP是一种应用层协议，传输层协议可以是TCP或者UDP（UDP多一些）！

RTP数据包由两部分组成，一部分是RTP Heaeder，一部分是RTP body，RTP Header占用最少12个字节，最多72个字节；另一部分...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（11）——RTSP_SET_PARAMETER]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109336702</link><guid>https://blog.csdn.net/mlfcjob/article/details/109336702</guid><author>mlfcjob</author><pubDate>Wed, 28 Oct 2020 16:36:26 +0800</pubDate><description><![CDATA[上一篇介绍了RTSP的GET_PARAMETER消息，看到这个消息类型，我们很容易习惯性的想到应该还要有一个RTSP_SET_PARAMETER消息，如我我们所愿，RTSP确实有这样一条消息，本篇我们来看一看！



SET PARAMETER作用

SET_PARAMETER方法用于给URI指定的流地址设置参数。

当客户端想要确定为什么某一个特定的请求失败时，请求应该只包含一个参数。

如果请求中包含多个参数值，则服务器只有在所有的参数被成功设置的情况下，才会生效。

服务器允许某个参数...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（10）——GET_PARAMETER]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109336615</link><guid>https://blog.csdn.net/mlfcjob/article/details/109336615</guid><author>mlfcjob</author><pubDate>Wed, 28 Oct 2020 16:34:50 +0800</pubDate><description><![CDATA[上一篇我们介绍了RTSP的TEARDOWN指令，用于结束一个RTSP的会话！本篇我们来介绍RTSP GET_PARAMETER！



GET Parameter作用

GetParameret用作向服务器获取参数，一般用于获取时间范围。当发送的请求中没有相关请求参数时，则用作保持RTSP连接！



GET Parameter格式

GET PARAMETER指令的格式如下：



RTSP URI表示请求的rtsp地址，RTSP version表示版本号；

CSeq表示消息序列号；...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（9）——TEARDOWN]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109336558</link><guid>https://blog.csdn.net/mlfcjob/article/details/109336558</guid><author>mlfcjob</author><pubDate>Wed, 28 Oct 2020 16:32:55 +0800</pubDate><description><![CDATA[上一篇我们讲了RTSP PAUSE消息，本篇我们来看下RTSP TEARDOWN消息！




TEARDOWN作用

TEARDOWN是拆卸的意思，对于RTSP而言，就是结束流传输，同时释放与之相关的资源，TEARDWON之后，整个RTSP连接也就结束了！好了，接下来我们来仔细看一下：



TEARDOWN格式

首先还是看一下TEARDOWN请求的消息格式：



如图中，TEARDOWN消息中，指定了URI，不用多说了；RTSP版本号也是我们的老朋友了；CSeq表示序列号；...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（8）——PAUSE]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109336467</link><guid>https://blog.csdn.net/mlfcjob/article/details/109336467</guid><author>mlfcjob</author><pubDate>Wed, 28 Oct 2020 16:30:45 +0800</pubDate><description><![CDATA[上一篇我们讲解了RTSP PLAY消息，PLAY请求成功之后，RTSP server就会一直向客户端发送RTP数据包！开始“播放”之后，我们相应的就会有暂停，停止等操作！本篇我们就先来看下RTSP的PAUSE！



PAUSE作用

暂停请求会使得流传输暂时中断（相当于暂停），如果请求的URL指向一个流地址，则仅针对该流的回放和录制会被中断！



PAUSE请求格式

PAUSE请求的格式如下：



格式比较简单，一般情况下主要就包含图示中字段！

RTSP URI表示请求的流地址，...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（7）——PLAY]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109336283</link><guid>https://blog.csdn.net/mlfcjob/article/details/109336283</guid><author>mlfcjob</author><pubDate>Wed, 28 Oct 2020 16:25:54 +0800</pubDate><description><![CDATA[上一篇我们熟悉了RTSP_SETUP消息，SETUP可以说是PLAY的准备流程，只有SETUP请求被成功回复之后，客户端才可以发起PLAY请求。本篇我们就来看一下PLAY消息。



PLAY的作用

PLAY消息是客户端发送的播放请求，发送播放请求的时候可以指定播放区间！发起播放请求后，如果连接正常，则服务端开始播放，即开始向客户端按照之前在TRASPORT中约定好的方式发送音视频数据包！播放流程便这样开始了！



PLAY的格式

我们先来看一下PLAY消息中常包含的一些字段...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（6）——SETUP]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109120217</link><guid>https://blog.csdn.net/mlfcjob/article/details/109120217</guid><author>mlfcjob</author><pubDate>Fri, 16 Oct 2020 17:02:07 +0800</pubDate><description><![CDATA[上一讲我们讲了RTSP的DESCRIBE指令，本篇接着来看下一条：SETUP。



SETUP 作用

SETUP请求的作用是指明媒体流该以什么方式传输；每个流PLAY之前必须执行SETUP操作；发送SETUP请求时，客户端会指定两个端口，一个端口用于接收RTP数据；另一个端口接收RTCP数据，偶数端口用来接收RTP数据，相邻的奇数端口用于接收RTCP数据！



SETUP格式

我们来看SETUP请求的数据格式：



SETUP表明消息类型；

URI表示请求的RTSP服务器的地址；

RTS...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（5）——DESCRIBE]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109120169</link><guid>https://blog.csdn.net/mlfcjob/article/details/109120169</guid><author>mlfcjob</author><pubDate>Fri, 16 Oct 2020 16:59:18 +0800</pubDate><description><![CDATA[上一篇我们介绍了RTSP的OPTION指令，客户端发起OPTION请求后，得到了RTSP服务器支持的指令。在此之后，客户端会继续向服务器发送DESCRIBE消息，来获取会话描述信息（sdp）。本篇我们来详细介绍一下DESCRIBE指令。



DESCRIBE的作用

向服务器请求会话描述信息（SDP）。



DESCRIBE的格式

1.请求

格式：



描述：

首先用DESCRIBE描述请求类型；然后在URI中请求的服务器端地址；RTSP_VER表示RTSP的版本号，在加入\r\n消息头结...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（4）——OPTION]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109120103</link><guid>https://blog.csdn.net/mlfcjob/article/details/109120103</guid><author>mlfcjob</author><pubDate>Fri, 16 Oct 2020 16:56:53 +0800</pubDate><description><![CDATA[上一篇，我们介绍了sdp相关信息，接下来开始我们介绍RTSP相关的选项，本篇我们首先来看一下OTPION选项。



OPTION(request)



我们在RTSP消息格式中讲过，rtsp分为request和response两大类消息，OPTION是一个request消息，其格式如下图：



我们来详细说下各个字段：

OPTIONS：标识请求命令的类型;

RTSP URI：请求的服务端的URI，以rtsp://开头的地址，一般为rtsp://ip:554(rtsp默认端口号);

RTSP...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（3）——sdp格式详解]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109120022</link><guid>https://blog.csdn.net/mlfcjob/article/details/109120022</guid><author>mlfcjob</author><pubDate>Fri, 16 Oct 2020 16:54:53 +0800</pubDate><description><![CDATA[上一篇我们介绍了RTSP数据包的格式，在整个rtsp的交互过程，sdp也是很重要不可获取的一环，本篇我们来详细介绍一下sdp的格式！




一 简介


sdp，英文全称Session Description Protocol，会话描述协议，对应RFC2327。我们在此介绍，是因为RTSP协议中使用sdp进行媒体信息的描述，不过，sdp的应用不止于此，语音通话SIP协议，监控安防GB28181国标, 当下比较火热的webRtc都用到了sdp，可谓应用广泛！

sdp的目的就是在媒体会话中，传递媒体流信息.]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（2）——Rtsp消息格式]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109119878</link><guid>https://blog.csdn.net/mlfcjob/article/details/109119878</guid><author>mlfcjob</author><pubDate>Fri, 16 Oct 2020 16:47:45 +0800</pubDate><description><![CDATA[上一篇我们简单介绍了rtsp协议，本篇我们来看一下rtsp的消息结构！

RTSP消息分为两大类，一类是请求消息（request），一类是回应消息（ressponse）！




1请求消息（request）




请求消息的格式如下：



说明：

请求消息由方法+URI+RTSP版本开头，之后跟一条或多条消息！

URI：表示接收方的地址，如rtsp://192.168.1.201:554

CR：表示回车

LF：表示换行

RTSP使用消息类型和消息体来表示不同类型的消息。

最后一条消息...]]></description><category></category></item><item><title><![CDATA[手撕RTSP协议系列（1）——Rtsp基本流程]]></title><link>https://blog.csdn.net/mlfcjob/article/details/109119694</link><guid>https://blog.csdn.net/mlfcjob/article/details/109119694</guid><author>mlfcjob</author><pubDate>Fri, 16 Oct 2020 16:43:13 +0800</pubDate><description><![CDATA[手撕RTSP协议系列（1）——Rtsp基本流程



哈喽，久违的小伙伴们！之前开了一个专辑手撕了rtmp协议！对于流媒体协议，rtsp协议也是很常见的，接下来我们继续手撕，手撕rtsp协议！本篇我们首先来简单了解一下rtsp协议并对其连接过程做一个概览！




1rtsp协议简介




rtsp，英文全称 Real Time Streaming Protocol，RFC2326，实时流传输协议，是TCP/IP协议体系中的一个应用层协议！协议主要规定定了一对多应用程序如何有效地通过IP网络传送多...]]></description><category></category></item><item><title><![CDATA[腾讯云直播服务评测]]></title><link>https://blog.csdn.net/mlfcjob/article/details/106396734</link><guid>https://blog.csdn.net/mlfcjob/article/details/106396734</guid><author>mlfcjob</author><pubDate>Thu, 28 May 2020 09:25:34 +0800</pubDate><description><![CDATA[​2020年注定是魔幻的一年，疫情让我们更热爱生命，也让我们更珍视工作。今年的五一假期比往年多了两天，但在这个特殊的年份的特殊的劳动节中，工作和这个假期更配哦！小编在这个假期就玩了玩直播，解释一下，是腾讯云平台提供的关于一系列的视频应用场景的一些服务，很荣幸能够提前体验一把，顺便简单的做一些评测，主要从产品易用性和性能体验这两个角度做了些测试，在此记录一下。同时也感谢腾讯直播云平台的哥哥姐姐们提供宝贵机会！

接下来，我们书归正传，开始我们的评测之路。

1.推拉流地址易用性测试

对于直播场景...]]></description><category></category></item><item><title><![CDATA[手撕Rtmp协议细节（11）——videoData]]></title><link>https://blog.csdn.net/mlfcjob/article/details/106396673</link><guid>https://blog.csdn.net/mlfcjob/article/details/106396673</guid><author>mlfcjob</author><pubDate>Thu, 28 May 2020 09:21:34 +0800</pubDate><description><![CDATA[上一篇我们看了rtmp audio的数据结构，这一篇我们来一起看一看rtmp video的数据结构。

老规矩，先上一个video数据的抓包文件，有个直观的感受。



通过抓包文件，我们可以看到，熟悉的Rtmp Header + Rtmp Body的组织结构，Body中打包的是经过压缩的视频数据。Body中打包视频数据的方式也与音频类似。首先用一个字节表示视频数据的header，之后是压缩后的视频数据（压缩后的数据是使用FLV的标准进行封装的）。

我们来看一下videoData中的header部分...]]></description><category></category></item><item><title><![CDATA[手撕Rtmp协议细节（10）——audio]]></title><link>https://blog.csdn.net/mlfcjob/article/details/106265156</link><guid>https://blog.csdn.net/mlfcjob/article/details/106265156</guid><author>mlfcjob</author><pubDate>Thu, 28 May 2020 09:19:00 +0800</pubDate><description><![CDATA[​前面我们历经千难万险和重重障碍，接下来，我们音视频通信的二位主角终于要粉墨登场了，那就是音频君和视频君，这一篇我们来一睹音频君的风采。老样子，抓包文件先摆上来：



说明：

rtmp协议wireshark中过滤音频数据包的条件为：


rtmpt.header.typeid == 0x08

通过抓包文件，我们看到音频数据也是按照RTMP Header + Rtmp Body的组织结构来进行封装的。Header部分之前的文章解析过，我们主要来看Body部分。因为rtmp是Adobe公司开发的协...]]></description><category></category></item><item><title><![CDATA[手撕Rtmp协议细节（9）——play拉流]]></title><link>https://blog.csdn.net/mlfcjob/article/details/106242536</link><guid>https://blog.csdn.net/mlfcjob/article/details/106242536</guid><author>mlfcjob</author><pubDate>Wed, 20 May 2020 19:11:41 +0800</pubDate><description><![CDATA[​1综述







在客户端发起createStream命令之后，客户端收到服务端反馈的_result消息，接下来客户端就可以向服务端发起请求播放的指令，这个指令就是play。首先我们看一下官方给出的关于play的消息流示意图。



首先我们来简单介绍一下关于play的流程，客户端向服务端发送play指令之后，服务端收到之后向客户端发送SetChunkSize消息，实际场景中大都在服务器回复客户端connect消息的时候一起发送setChunkSize消息；

服务端向客户端发送Stre...]]></description><category></category></item><item><title><![CDATA[手撕Rtmp协议细节（8）——publish推流]]></title><link>https://blog.csdn.net/mlfcjob/article/details/106221645</link><guid>https://blog.csdn.net/mlfcjob/article/details/106221645</guid><author>mlfcjob</author><pubDate>Tue, 19 May 2020 19:44:36 +0800</pubDate><description><![CDATA[​publish

对于推流端，经过releaseStream，createStream消息之后，得到了_result消息之后，接下来客户端就可以发起publish消息。推流端使用publish消息向rtmp服务器端发布一个命名的流，发布之后，任意客户端都可以以该名称请求视频、音频和数据。我们首先来看一下publish消息的组织结构：




	commandName：使用string类型，表示消息类型（“publish”）;
	
	
	transactionID：使用number类型表示事物ID；
...]]></description><category></category></item><item><title><![CDATA[手撕rtmp协议细节（7）——createStream]]></title><link>https://blog.csdn.net/mlfcjob/article/details/106221630</link><guid>https://blog.csdn.net/mlfcjob/article/details/106221630</guid><author>mlfcjob</author><pubDate>Tue, 19 May 2020 19:43:22 +0800</pubDate><description><![CDATA[​创建完RTMP连接之后就可以创建或者访问RTMP流，对于推流端，客户端要向服务器发送一个releaseStream命令消息，之后是createStream命令消息，对于拉流端，则要发送play消息请求视频资源。我们先来看看推流端的消息流程，当发送完createStream消息之后，解析服务器返回的消息会得到一个stream ID, 这个ID也就是以后和服务器通信的 message stream ID, 一般返回的是1，不固定。



createStream

我们来先看看createStream...]]></description><category></category></item><item><title><![CDATA[手撕Rtmp协议细节（6）——connect后续三剑客]]></title><link>https://blog.csdn.net/mlfcjob/article/details/106221612</link><guid>https://blog.csdn.net/mlfcjob/article/details/106221612</guid><author>mlfcjob</author><pubDate>Tue, 19 May 2020 19:42:04 +0800</pubDate><description><![CDATA[在讲解connect消息的时候，我们说过服务器收到connect消息之后，会向客户端发送Window Acknowledgement Size消息和Set Peer Bandwidth消息，这一篇就来介绍一下这两条消息。



1.概览

首先从抓包文件看一下：



示例中服务器ip地址是192.17.1.200，客户端ip地址是192.17.1.92，客户端向服务器发送connect消息之后，服务器向客户端发送了Window Acknowledgement Size和Set Peer Bandw...]]></description><category></category></item></channel></rss>