RTMP流媒体播放过程

 

 

RTMP协议规定：第一步，建立一个网络连接（NetConnection）:客户端和服务端的基础连通关系 第二步：建立一个网络流（NetStream）发送多媒体的通道（只能建立一个网络连接，可以建立多个网络流）

播放一个RTMP协议的流媒体：1.握手 2.建立连接 3.建立流 4.播放 RTMP连接都是以握手作为开始的。建立连接阶段用于建立客户端与服务器之间的“网络连接”；建立流阶段用于建立客户端与服务器之间的“网络流”；播放阶段用于传输视音频数据。

1.握手（HandShake）

一个RTMP连接以握手开始，双方分别发送大小固定的三个数据块

a)握手开始于客户端发送C0、C1块。服务器收到C0或C1后发送S0和S1。

b)当客户端收齐S0和S1后，开始发送C2。当服务器收齐C0和C1后，开始发送S2。

c)当客户端和服务器分别收到S2和C2后，握手完成。

 

2.建立网络连接（NetConnection）

a)客户端发送命令消息中的“连接”(connect)到服务器，请求与一个服务应用实例建立连接。

b)服务器接收到连接命令消息后，发送确认窗口大小(Window Acknowledgement Size)协议消息到客户端，同时连接到连接命令中提到的应用程序。

c)服务器发送设置带宽()协议消息到客户端。

d)客户端处理设置带宽协议消息后，发送确认窗口大小(Window Acknowledgement Size)协议消息到服务器端。

e)服务器发送用户控制消息中的“流开始”(Stream Begin)消息到客户端。

f) 服务器发送命令消息中的“结果”(_result)，通知客户端连接的状态。

 

3.建立网络流（NetStream）

a) 客户端发送命令消息中的“创建流”（createStream）命令到服务器端。

b)服务器端接收到“创建流”命令后，发送命令消息中的“结果”(_result)，通知客户端流的状态。

4 播放（Play）

a) 客户端发送命令消息中的“播放”（play）命令到服务器。

b)接收到播放命令后，服务器发送设置块大小（ChunkSize）协议消息。

c)服务器发送用户控制消息中的“streambegin”，告知客户端流ID。

d)播放命令成功的话，服务器发送命令消息中的“响应状态” NetStream.Play.Start & NetStream.Play.reset，告知客户端“播放”命令执行成功。

e) 在此之后服务器发送客户端要播放的音频和视频数据。

 

网络视音频服务主要包括两种方式：点播和直播。点播意即根据用户的需要播放相应的视频节目，这是互联网视音频服务最主要的方式。绝大部分视频网站都提供了。点播服务。直播意即互联网视音频平台直接将视频内容实时发送给用户，目前还处于发展阶段。直播在网络电视台，社交视频网站较为常见。

直播服务普遍采用了RTMP作为流媒体协议，FLV作为封装格式，H.264作为视频编码格式，AAC作为音频编码格式。采用RTMP作为直播协议的好处在于其被Flash播放器支持。而Flash播放器如今已经安装在全球99%的电脑上，并且与浏览器结合的很好。因此这种流媒体直播平台可以实现“无插件直播”，极大的简化了客户端的操作。封装格式，视频编码，音频编码方面，无一例外的使用了FLV + H.264 +AAC的组合。FLV是RTMP使用的封装格式，H.264是当今实际应用中编码效率最高的视频编码标准，AAC则是当今实际应用中编码效率最高的音频编码标准。视频播放器方面，都使用了Flash播放器

点播服务普遍采用了HTTP作为流媒体协议，H.264作为视频编码格式，AAC作为音频编码格式。采用HTTP作为点播协议有以下两点优势：一方面，HTTP是基于TCP协议的应用层协议，媒体传输过程中不会出现丢包等现象，从而保证了视频的质量；另一方面，HTTP被绝大部分的Web服务器支持，因而流媒体服务机构不必投资购买额外的流媒体服务器，从而节约了开支。点播服务采用的封装格式有多种：MP4，FLV，F4V等，它们之间的区别不是很大。视频编码标准和音频编码标准是H.264和AAC。这两种标准分别是当今实际应用中编码效率最高的视频标准和音频标准。视频播放器方面，无一例外的都使用了Flash播放器

作者：leotongxue
链接：https://www.jianshu.com/p/bd4d725feebb

 

=========================================

https://blog.csdn.net/xiejiashu/article/details/78653913

EasyRTMPClient 简介

EasyRTMPClient是EasyDarwin流媒体团队开发、提供的一套非常稳定、易用、支持重连接的RTMPClient工具，以SDK形式提供，接口调用非常简单。该EasyRTMPClient库未使用或参考现有的任何RTMP库，完全由EasyDarwin团队自主实现，因此，EasyRTMPClient更易于维护，稳定性、可扩展性得以提升，同时，本RTMP库全平台支持（包括windows/linux 32&64，ARM各平台，android, ios）!

相关连接

EasyRTMPClient调用示例地址：https://github.com/EasyDSS/EasyRTMPClient

由EasyDarwin团队推出的 RTMP协议教程：初级部分 进阶部分 高级部分

谈谈RTMP窗口大小

RTMP窗口大小基本概念

RTMP消息包一共分成三种类型。一类是命令（通知）消息，一类是音频消息，一类是视频消息。而窗口大小则属于第一种消息，即命令消息。窗口大小的本意是让对端了解与本端的通信状况，用以控制媒体传输流量的一种方案。通常，我们从RTMP服务器中进行拉取RTMP流到本地时，在协商的过程当中，会发送0x05,0x06消息包，即带宽值通知，通常设为2.5M。在实际的拉流过程中，我们通常隔一段时间就得向服务器报告，我们已经从服务中收到了多少数据量，此种报告，就是开篇所提到的窗口大小，即ack size确认。我在实际开发的过程当中，通常，当接收的数据量接近于3倍带宽值（2.5M*3）时，向服务器报告一下目前已接收了多少数据。经测试，针对于Flash Media Server（FMS）对该消息是比较敏感的（其它RTMP服务器，各方实现不同，对该窗口大小的确认或许没有如此敏感）。如果客户端未能及时向FMS回馈该数据，即使在正常的拉收数据流的过程当中，FMS也会断开与客户的连接。

由RTMP窗口大小引发的问题

上述，基本对RTMP窗口大小做了一个介绍。根据RTMP协议标准来看，RTMP窗口大小是通过0x03类型来标识的，其负载通常是四个字节，用大端序来表示当前窗口大小，即当前已接收的数据总量。前面，我们说过，FMS对窗口大小这条消息是十分敏感的，除了按上述方法，及时向FMS反馈0x03消息包（窗口大小确认）外，仍须注意另一个问题，即4字节溢出的情况。我们知道，4字节无符号，大概能表示4.29G左右的数据量，当从RTMP服务器所接收的数据量即将达到4.29G时，应及时的向RTMP服务器进行一次窗口大小的置零反馈。该bug是经过大量时间分析而得来，据后来查验，librtmp库也同样存在该bug（该Bug于2013/2014年左右遇到并分析处理），由于我没用librtmp库，因此，暂不能确认当前版本是否有修正该bug（应该没有修正 ^_^）。

EasyRTMPClient 中的处理

在实际的开发过程当中，当我们接收的数据量接近于4.29G时，我们及时将该值提前置0，反馈给FMS服务器即可。如果过早的置0，或直接等待其溢出，FMS同样会立即断开RTMP客户端。下面贴出EasyRTMPClient对上述Bug的处理代码：

int SendWindowAcknowledgementSize( MSRtmpSession * msrs )
{
    int ret = 0;
    MRPKT * pkt = NULL;
    MPARASITICAL_BUFS * bufs = NULL;

    pkt = allocRMPkt();
    if ( !pkt )
    {
        return -1;
    }

    writeMessageHdr( 0x02, 0, 0, 0x03, -1, pkt );

    bufs = msrs->msr->hdr.alloc( msrs->msr->hdr.hdr );
    *( ( unsigned int * )bufs->buf ) = htonl( msrs->msr->info.recvInfo.bytes );
    bufs->len = sizeof( unsigned int );
    msrs->msr->info.ackSize = msrs->msr->info.recvInfo.bytes;                          // reference for next send ack size

    fillPayload( bufs, pkt, msrs->msr ); 
    commitMRPkt( pkt, msrs->msr );

    ret = MRSendChunks( msrs, &pkt, -1 );

    if ( msrs->msr->info.recvInfo.bytes + msrs->msr->info.clientBW * 3 > 4294967295 )  // stream bytes > 4.2G, ack clean.
    {
        msrs->msr->info.recvInfo.bytes = 0;                                            // Improve by Inpilen.
        msrs->msr->info.ackSize = 0;
    }

    return ret;
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33

获取更多信息

邮件：[email protected]

WEB：www.EasyDarwin.org

EasyRTMPClient交流群：544917793

Copyright © EasyDarwin.org 2012-2017

來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。