CN112153022B - 一种rtmp快速发布和订阅方法 - Google Patents

一种rtmp快速发布和订阅方法 Download PDF

Info

Publication number
CN112153022B
CN112153022B CN202010955088.8A CN202010955088A CN112153022B CN 112153022 B CN112153022 B CN 112153022B CN 202010955088 A CN202010955088 A CN 202010955088A CN 112153022 B CN112153022 B CN 112153022B
Authority
CN
China
Prior art keywords
tag
data
rtmp
type
handshake
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010955088.8A
Other languages
English (en)
Other versions
CN112153022A (zh
Inventor
刘岩
谢然
吴文治
徐强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Qiniu Information Technology Co ltd
Original Assignee
Shanghai Qiniu Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Qiniu Information Technology Co ltd filed Critical Shanghai Qiniu Information Technology Co ltd
Priority to CN202010955088.8A priority Critical patent/CN112153022B/zh
Publication of CN112153022A publication Critical patent/CN112153022A/zh
Application granted granted Critical
Publication of CN112153022B publication Critical patent/CN112153022B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures

Abstract

本发明涉及音视频回源技术领域，具体地说，涉及一种RTMP快速发布和订阅方法，包括：一、TCP传输层握手和RTMP应用层握手：应用层握手由客户端发送固定的一个字节给服务端，来标记双方握手成功；二、业务建连：客户端发送类型为18的tag数据给服务端，tag数据内部含有标记业务类型的字段；三、数据传输；四、关断：双方通过发送类型为66的tag数据来完成通知或反馈。本发明能够大大简化了节点间建连、发布/订阅流程，且数据包封包/解包简单，保证了数据传输过程的可靠性。

Description

一种RTMP快速发布和订阅方法
技术领域
本发明涉及音视频回源技术领域，具体地说，涉及一种RTMP快速发布和订阅方法。
背景技术
音视频直播内容分发系统涉及到常见的系统回源，多节点间分发媒体数据，业界CDN厂商基本上采用RTMP或者基于TCP/UDP等自家开发的私有协议来完成。其他私有协议暂不在本专利讨论范围。采用标准RTMP协议，会存在建连的复杂性，完成一次音视频流的发布或订阅业务需经历多个阶段，如TCP握手、RTMP复杂握手/简单握手、RTMP建连、RTMP流通道准备、RTMP发布/订阅等。且在音视频传输阶段，会涉及到较复杂的消息块(chunk)拆包/组包等操作。这样可能会引入节点间回源复杂低效、延迟较高等缺陷，在回源中转节点为多个时，劣势会更加明显。
发明内容
本发明的内容是提供一种RTMP快速发布和订阅方法，其能够克服现有技术的某种或某些缺陷。
根据本发明的一种RTMP快速发布方法，其包括以下步骤：
一、TCP传输层握手和RTMP应用层握手：应用层握手由客户端发送固定的一个字节给服务端，来标记双方握手成功；
二、业务建连：客户端发送类型为18的tag数据给服务端，tag数据内部含有标记业务类型的字段，标记业务类型的字段为url＝rtmp：//127.0.0.1/live/test？xxx publish＝1；
三、数据传输：客户端主动发送媒体数据到服务端，媒体数据的tag类型为8、9和18；
四、关断：双方通过发送类型为66的tag数据来完成通知或反馈，类型为66的tag数据为{“closeReason”：“RootDisconnected”，“closeBecauseIdle”：null}。
作为优选，tag的格式为：Tag header+Tag body+Pre tag size，Tag header占11字节，Pre tag size占4字节，Tag header的格式为：Tag type+Data len+Pts+Stream id，Tag type占1字节，Data len占3字节，Pts占4字节，Stream id占3字节。
作为优选，步骤四中，服务端无数据下发时，或者因网络等其他原因主动或被动断连时，执行步骤四。
作为优选，类型为8的tag为音频数据，具体格式为：08(000007)(00001000)(000000)+具体内容，stream id为3个0。
作为优选，类型为9的tag为视频数据，具体格式为：09(000034)(00000000)(000000)+具体内容，stream id为3个0。
作为优选，类型为18的tag为metadata元数据，用来业务建连和传送metadata元数据，具体格式为：12(00020d)(00000000)(000000)+具体内容，pts和stream id均固定为0。
作为优选，metadata元数据中的具体内容为AMF0格式。
作为优选，类型为66的tag为自定义JSON数据或文本数据，是一种控制信令，具体格式为：42(00003e)(00000000)(002333)+(23333335)+json数据，pts固定为0，stream id固定为002333。
作为优选，(23333335)表示数据部分为json格式，json格式为{“closeReason”：null，“closeBecauseIdle”：false}。
如图2所示，本实施例提供了一种RTMP快速订阅方法，其包括以下步骤：
a、TCP传输层握手和RTMP应用层握手：应用层握手由客户端发送固定的一个字节给服务端，来标记双方握手成功；
b、业务建连：客户端发送类型为18的tag数据给服务端，tag数据内部含有标记业务类型的字段，标记业务类型的字段为url＝rtmp：//127.0.0.1/live/test？xxx publish＝0；
c、数据传输：服务端被动接收客户端的媒体数据，媒体数据的tag类型为8、9和18；
d、关断：双方通过发送类型为66的tag数据来完成通知或反馈，类型为66的tag数据为{“closeReason”：“RootDisconnected”，“closeBecauseIdle”：null}。
本发明大大简化了节点间建连、发布/订阅流程，且数据包封包/解包简单，数据格式与flv tag保持一致，底层又是基于TCP协议，保证了数据传输过程的可靠性。本发明简化了RTMP握手流程，提升了握手效率；简化了业务交互，一个完整的发布或订阅请求，只需少数的特定的数据包交互即可完成；简化了媒体数据的传输以及信令层交互。本发明极大简化了回源时的信令交互以及媒体数据打包传输，不需要额外的数据包头，提升多节点间的回源效率，进一步改善直播场景下的播放首屏时间以及延迟。
附图说明
图1为实施例1中一种RTMP快速发布方法的流程图；
图2为实施例1中一种RTMP快速订阅方法的流程图。
具体实施方式
为进一步了解本发明的内容，结合附图和实施例对本发明作详细描述。应当理解的是，实施例仅仅是对本发明进行解释而并非限定。
实施例1
如图1所示，本实施例提供了一种RTMP快速发布方法，其包括以下步骤：
一、TCP传输层握手和RTMP应用层握手：应用层握手由客户端发送固定的一个字节给服务端，来标记双方握手成功；
二、业务建连：客户端发送类型为18的tag数据给服务端，tag数据内部含有标记业务类型的字段，标记业务类型的字段为url＝rtmp：//127.0.0.1/live/test？xxx publish＝1；在这里publish固定为1；
三、数据传输：客户端主动发送媒体数据到服务端，媒体数据的tag类型为8、9和18；
四、关断：双方通过发送类型为66的tag数据来完成通知或反馈，类型为66的tag数据为{“closeReason”：“RootDisconnected”，“closeBecauseIdle”：null}。
图1中的Client为客户端，Server为服务端；Handshake C0为握手步骤，Publish为发布。
本实施例中，tag的格式为：Tag header+Tag body+Pre tag size，Tag header占11字节，Pre tag size占4字节，Tag header的格式为：Tag type+Data len+Pts+Streamid，Tag type占1字节，Data len占3字节，Pts占4字节，Stream id占3字节。
本实施例中，步骤四中，服务端无数据下发时，或者因网络等其他原因主动或被动断连时，执行步骤四。
本实施例中，类型为8的tag为音频数据，具体格式为：08(00 00 07)(00 00 1000)(00 00 00)+具体内容，stream id为3个0。
本实施例中，类型为9的tag为视频数据，具体格式为：09(00 00 34)(00 00 0000)(00 00 00)+具体内容，stream id为3个0。
本实施例中，类型为18的tag为metadata元数据，用来业务建连和传送metadata元数据，具体格式为：12(00 02 0d)(00 00 00 00)(00 00 00)+具体内容，pts和stream id均固定为0。
本实施例中，metadata元数据中的具体内容为AMF0格式。
本实施例中，类型为66的tag为自定义JSON数据或文本数据，是一种控制信令，具体格式为：42(00 00 3e)(00 00 00 00)(00 23 33)+(23 33 33 35)+json数据，pts固定为0，stream id固定为002333。
本实施例中，(23 33 33 35)表示数据部分为json格式，json格式为{“closeReason”：null，“closeBecauseIdle”：false}。
如图2所示，本实施例提供了一种RTMP快速订阅方法，其包括以下步骤：
a、TCP传输层握手和RTMP应用层握手：应用层握手由客户端发送固定的一个字节给服务端，来标记双方握手成功；
b、业务建连：客户端发送类型为18的tag数据给服务端，tag数据内部含有标记业务类型的字段，标记业务类型的字段为url＝rtmp：//127.0.0.1/live/test？xxx publish＝0；在这里publish固定为0；
c、数据传输：服务端被动接收客户端的媒体数据，媒体数据的tag类型为8、9和18；
d、关断：双方通过发送类型为66的tag数据来完成通知或反馈，类型为66的tag数据为{“closeReason”：“RootDisconnected”，“closeBecauseIdle”：null}。
本实施例有如下效果：
1)简化握手流程，包括TCP握手与RTMP握手，由标准的2个RTT优化为不到1个RTT；
2)简化RTMP业务交互流程，包括RTMP建连、RTMP流通道准备、发布/订阅；一个完整的RTMP发布或订阅流程，只需不到一个RTT完成；
3)简化媒体数据、信令的传输，数据格式采用标准flv tag格式，信令采用标准json格式；去掉了较为复杂的消息块(chunk)格式，即不再将tag拆分为chunk，也不用将不同类型的chunk组装成完整tag；
4)可与现有标准RTMP复用同一个端口，如1935，即同时监听标准RTMP客户端与fastRTMP客户端上来，处理不同类型的连接业务。
图2中Play为订阅。
如下表所示，回源涉及到的数据分为两部分，一个是媒体，一个是信令，在网络传输中采用flv tag封装格式，该格式适用于网络实时流传输。标准tag本身支持类型为8，9，18的数据，即音频、视频和metadata元数据。在此基础之上扩展了适用于业务控制的信令tag，即类型为66，数据部分是标准json格式，方便封装和解析，用于通信双方交换私有数据或者通知反馈，如通知一端断流的原因，是因为流本身的源断了还是其他原因引起的。另外在业务建连时，复用了类型为18的数据，该类型数据部分是AMF0格式，便于编码与解析，用于标记发布还是订阅一个流，以及提供一个完整的RTMP URL，用于后续流相关信息的提取以及校验等。
Figure BDA0002678333230000061
表1媒体数据与信令具体封装格式
以上示意性的对本发明及其实施方式进行了描述，该描述没有限制性，附图中所示的也只是本发明的实施方式之一，实际的结构并不局限于此。所以，如果本领域的普通技术人员受其启示，在不脱离本发明创造宗旨的情况下，不经创造性的设计出与该技术方案相似的结构方式及实施例，均应属于本发明的保护范围。

Claims (10)

1.一种RTMP快速发布方法，其特征在于：包括以下步骤：
一、TCP传输层握手和RTMP应用层握手：应用层握手由客户端发送固定的一个字节给服务端，来标记双方握手成功；
二、业务建连：客户端发送类型为18的tag数据给服务端，tag数据内部含有标记业务类型的字段，标记业务类型的字段为url＝rtmp：//127.0.0.1/live/test？xxx publish＝1；
三、数据传输：客户端主动发送媒体数据到服务端，媒体数据的tag类型为8、9和18；
四、关断：双方通过发送类型为66的tag数据来完成通知或反馈，类型为66的tag数据为{“closeReason”：“RootDisconnected”，“closeBecauseIdle”：null}。
2.根据权利要求1中所述的一种RTMP快速发布方法，其特征在于：tag的格式为：Tagheader+Tag body+Pre tag size，Tag header占11字节，Pre tag size占4字节，Tagheader的格式为：Tag type+Data len+Pts+Stream id，Tag type占1字节，Data len占3字节，Pts占4字节，Stream id占3字节。
3.根据权利要求1中所述的一种RTMP快速发布方法，其特征在于：步骤四中，服务端无数据下发时，或者因网络的原因主动或被动断连时，执行步骤四。
4.根据权利要求1中所述的一种RTMP快速发布方法，其特征在于：类型为8的tag为音频数据，具体格式为：08(00 00 07)(00 00 10 00)(00 00 00)+具体内容，stream id为3个0。
5.根据权利要求1中所述的一种RTMP快速发布方法，其特征在于：类型为9的tag为视频数据，具体格式为：09(00 00 34)(00 00 00 00)(00 00 00)+具体内容，stream id为3个0。
6.根据权利要求1中所述的一种RTMP快速发布方法，其特征在于：类型为18的tag为metadata元数据，用来业务建连和传送metadata元数据，具体格式为：12(00 02 0d)(00 0000 00)(00 00 00)+具体内容，pts和stream id均固定为0。
7.根据权利要求6中所述的一种RTMP快速发布方法，其特征在于：metadata元数据中的具体内容为AMF0格式。
8.根据权利要求1中所述的一种RTMP快速发布方法，其特征在于：类型为66的tag为自定义JSON数据或文本数据，是一种控制信令，具体格式为：42(00 00 3e)(00 00 00 00)(0023 33)+(23 33 33 35)+json数据，pts固定为0，stream id固定为00 23 33。
9.根据权利要求8中所述的一种RTMP快速发布方法，其特征在于：(23 3333 35)表示数据部分为json格式，json格式为{“closeReason”：null，“closeBecauseIdle”：false}。
10.一种RTMP快速订阅方法，其特征在于：包括以下步骤：
a、TCP传输层握手和RTMP应用层握手：应用层握手由客户端发送固定的一个字节给服务端，来标记双方握手成功；
b、业务建连：客户端发送类型为18的tag数据给服务端，tag数据内部含有标记业务类型的字段，标记业务类型的字段为url＝rtmp：//127.0.0.1/live/test？xxx publish＝0；
c、数据传输：服务端被动接收客户端的媒体数据，媒体数据的tag类型为8、9和18；
d、关断：双方通过发送类型为66的tag数据来完成通知或反馈，类型为66的tag数据为{“closeReason”：“RootDisconnected”，“closeBecauseIdle”：null}。
CN202010955088.8A 2020-09-11 2020-09-11 一种rtmp快速发布和订阅方法 Active CN112153022B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010955088.8A CN112153022B (zh) 2020-09-11 2020-09-11 一种rtmp快速发布和订阅方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010955088.8A CN112153022B (zh) 2020-09-11 2020-09-11 一种rtmp快速发布和订阅方法

Publications (2)

Publication Number Publication Date
CN112153022A CN112153022A (zh) 2020-12-29
CN112153022B true CN112153022B (zh) 2022-09-13

Family

ID=73890334

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010955088.8A Active CN112153022B (zh) 2020-09-11 2020-09-11 一种rtmp快速发布和订阅方法

Country Status (1)

Country Link
CN (1) CN112153022B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114501049B (zh) * 2022-01-18 2023-10-27 上海哔哩哔哩科技有限公司 直播连接的建立方法、装置及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108243173A (zh) * 2016-12-27 2018-07-03 北京视联动力国际信息技术有限公司 一种基于视联网的rtmp视频推送方法及装置
CN108270768A (zh) * 2017-11-28 2018-07-10 北京文香信息技术有限公司 一种基于rtsp/rtmp协议的单端口双向交互协议
CN110519641A (zh) * 2019-09-10 2019-11-29 深圳市同洲电子股份有限公司 一种多源多协议的视频融合传输交换系统及方法
CN111193936A (zh) * 2019-12-27 2020-05-22 腾讯科技（深圳）有限公司 视频流传输方法、装置、电子设备及计算机可读存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107995187A (zh) * 2017-11-30 2018-05-04 上海哔哩哔哩科技有限公司 基于html5浏览器的视频主播、直播方法、终端和系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108243173A (zh) * 2016-12-27 2018-07-03 北京视联动力国际信息技术有限公司 一种基于视联网的rtmp视频推送方法及装置
CN108270768A (zh) * 2017-11-28 2018-07-10 北京文香信息技术有限公司 一种基于rtsp/rtmp协议的单端口双向交互协议
CN110519641A (zh) * 2019-09-10 2019-11-29 深圳市同洲电子股份有限公司 一种多源多协议的视频融合传输交换系统及方法
CN111193936A (zh) * 2019-12-27 2020-05-22 腾讯科技（深圳）有限公司 视频流传输方法、装置、电子设备及计算机可读存储介质

Also Published As

Publication number Publication date
CN112153022A (zh) 2020-12-29

Similar Documents

Publication Publication Date Title
KR101366803B1 (ko) Ｈｔｔｐ를 이용한 통신 방법 및 장치
EP2890133B1 (en) System and method for distributing live broadcast content
US20160337424A1 (en) Transferring media data using a websocket subprotocol
US7587507B2 (en) Media recording functions in a streaming media server
CN102075338B (zh) 基于分布式网络的直播方法和装置
CN101174995B (zh) 一种多媒体服务性能监测的方法和系统
CN110049353B (zh) 用于在广播系统中传输多媒体数据的装置及方法
CN106911699B (zh) 一种基于rtp协议实现i帧重传的方法
WO2012094916A1 (zh) 一种流媒体数据包的封装、传输方法及流媒体处理装置
CN106464932A (zh) 多播流传输
US20150046568A1 (en) Method and system for playing multicast over-the-top (ott) content streams
TW201828709A (zh) 在無清單檔案媒體串流期間偵測及發信新初始化區段
CN102347947A (zh) 一种流媒体适配器、流媒体网络交互的系统及方法
WO2013173683A1 (en) Synchronizing multiple transcoding devices utilizing simultaneity of receipt of multicast packets
CN109257620B (zh) 基于多路径传输的网络直播方法及其系统
CN112153022B (zh) 一种rtmp快速发布和订阅方法
CN110933470B (zh) 一种视频数据的共享方法
CN113890869A (zh) 一种流媒体分发方法
WO2016119464A1 (zh) 一种卫星网络环境下实现tcp传输的方法及相应的网关
CN106790030B (zh) 多屏协同音频传输服务端、客户端、系统及其处理方法
CN110138729B (zh) 一种数据获取方法和视联网系统
CN107517202B (zh) 一种sip信令的二进制化发送和接收方法
WO2015043170A1 (zh) 端点信息交互处理方法、装置及远程呈现端点
CN100479460C (zh) 跨平台的端到端rtp协议栈设计方法
CN109451030B (zh) 一种视联网文件的下载方法和系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant