rtmp流媒体协议书范本
rtmp协议
rtmp协议第一篇：RTMP协议的基础概念及特点RTMP（Real Time Messaging Protocol）是一种实时消息传递协议，属于Adobe公司开发的一种流媒体协议。
RTMP 协议使用TCP进行数据传输，适用于音视频流的实时播放、互动、互传等方面，被广泛应用于视频直播、在线教育、网络会议等领域。
RTMP协议具有以下特点：1. 实时传输：RTMP协议传输数据的速度非常快，能够满足实时传输音视频流的要求。
2. 跨平台：RTMP协议支持多种操作系统和平台，包括Windows、Mac OS X、Linux等。
3. 支持多种编码方式：RTMP协议支持多种编码方式，如H.264、VP6、Sorenson Spark等，可以适应不同的数据类型和网络环境。
4. 安全性高：RTMP协议支持加密传输，可以保证数据的安全性。
5. 支持多种传输方式：RTMP协议支持多种传输方式，包括点对点传输、客户端和服务器之间的传输等。
6. 支持多种数据格式：RTMP协议支持多种数据格式，如FLV、MP4等，可以适应不同的数据类型和网络环境。
总之，RTMP协议具有高效、可靠、跨平台、安全等特点，是现今流媒体传输的主流协议之一。
第二篇：RTMP协议的工作原理及实现RTMP协议的工作原理是，客户端向服务器发送连接请求，并进行握手验证，验证通过后，建立连接，开始实时传输数据。
在建立连接后，客户端可以向服务器发送控制信息、元数据和音视频数据。
控制信息包括连接控制、流控制、消息控制等，用于控制数据的传输。
元数据包含音视频的标题、格式、描述等信息。
音视频数据则包含音视频的编码数据。
RTMP协议的传输方式有三种：直接传输、容器传输和点对点传输。
直接传输和容器传输都是通过服务器进行流媒体传输，只不过采用的传输方法不同。
点对点传输则是直接将数据传输到接收端，实现点对点传输。
实现RTMP协议需要以下步骤：1. 与服务器建立连接首先需要与服务器建立连接，进行握手验证，验证通过后方可进入数据传输阶段。
视频流媒体服务合同(范本)
视频流媒体服务合同甲方：____________乙方：____________第一条服务内容1.1 概述甲方同意向乙方提供视频流媒体服务，包括但不限于视频内容的发布、存储、传输、展示和分销。
乙方同意接受甲方的服务并按照本合同的约定支付相应的费用。
1.2 服务范围1.甲方应确保视频流媒体服务的稳定性，保证服务的正常运行。
2.甲方应提供用户注册、内容上传、视频播放等功能。
3.甲方应对乙方上传的视频内容进行安全保护，防止内容被未经授权的访问、篡改和删除。
4.甲方有权对乙方上传的视频内容进行审核，确保内容符合国家法律法规及社会主义核心价值观，不得含有违法违规信息。
5.甲方应按照乙方的要求，提供视频内容的统计分析数据。
第二条服务期限本合同自双方签字（或盖章）之日起生效，有效期为____年，自____年__月__日至____年__月__日。
第三条费用及支付3.1 费用1.乙方应按照甲方的收费标准支付服务费用。
收费标准详见附件一。
2.甲方应按照本合同的约定提供服务，确保服务质量和效果。
3.2 支付方式1.乙方同意通过银行转账的方式支付服务费用。
2.乙方应在合同生效后七个工作日内支付首期服务费用。
3.乙方应在每个服务周期结束前支付下一个服务周期的服务费用。
第四条知识产权1.乙方保证对其上传的视频内容拥有合法的知识产权，包括但不限于著作权、专利权、商标权等。
2.甲方有权对乙方上传的视频内容进行使用、展示、推广和宣传，但不得侵犯乙方的知识产权。
3.双方在合作过程中产生的包括但不限于著作权、专利权、商标权等知识产权，归双方共同所有。
第五条保密条款1.双方在签订和履行本合同过程中所获悉的对方商业秘密、技术秘密、市场信息等，应予以严格保密。
2.保密期限自本合同签订之日起算，至本合同终止或履行完毕之日止。
第六条违约责任1.任何一方违反本合同的约定，导致合同无法履行或者造成对方损失的，应承担违约责任，向对方支付违约金，并赔偿损失。
RTMP协议
RTMP协议协议名称：Real-Time Messaging Protocol (RTMP) 协议1. 引言本协议描述了 Real-Time Messaging Protocol (RTMP) 的标准格式。
RTMP 是一种用于实时数据传输的协议，最初由 Adobe Systems 开发，用于在 Adobe Flash 平台上传输音频、视频和数据流。
随着时间的推移，RTMP 也被应用于其他实时流媒体应用程序。
2. 目的本协议的目的是规范 RTMP 的通信过程和数据格式，以确保在不同平台和设备之间的兼容性和互操作性。
3. 协议规范3.1 连接建立- 客户端通过 TCP/IP 连接到 RTMP 服务器的默认端口 1935。
- 客户端发送 C0 和 C1 数据包，其中 C0 是一个字节，表示 RTMP 版本号，C1 是一个 1536 字节的随机数据块。
- 服务器接收到 C0 和 C1 数据包后，发送 S0 和 S1 数据包作为响应，其中 S0 是一个字节，表示 RTMP 版本号，S1 是一个 1536 字节的随机数据块。
- 客户端接收到 S0 和 S1 数据包后，发送 C2 数据包，其中包含 S1 数据块的哈希值。
- 服务器验证 C2 数据包，如果匹配成功，连接建立成功。
3.2 握手过程- 客户端发送 C0 和 C1 数据包后，等待服务器响应。
- 服务器接收到 C0 和 C1 数据包后，发送 S0 和 S1 数据包作为响应，等待客户端发送 C2 数据包。
- 客户端接收到 S0 和 S1 数据包后，发送 C2 数据包，等待服务器验证。
- 服务器验证 C2 数据包，如果匹配成功，握手成功。
3.3 数据传输- RTMP 使用消息进行数据传输，每个消息由一个消息头和一个消息体组成。
- 消息头包含了消息的类型、长度、时间戳和流 ID 等信息。
- 消息体包含了实际的数据，可以是音频、视频或其他自定义数据。
- RTMP 支持多种消息类型，如音频消息、视频消息、命令消息等。
RTMP协议
RTMP协议协议名称：实时消息传输协议（RTMP）1. 引言实时消息传输协议（RTMP）是一种用于在互联网上进行实时数据传输的协议。
它最初由Adobe Systems开发，用于在Adobe Flash平台上进行音频、视频和数据的传输。
RTMP协议通过建立持久的连接，实现了低延迟、高可靠性的数据传输。
本协议旨在规定RTMP协议的标准格式，以便各方在实施RTMP协议时能够一致地进行操作。
2. 范围本协议适用于所有使用RTMP协议进行实时数据传输的应用程序和系统。
3. 定义3.1 RTMP协议：指实时消息传输协议，用于在互联网上进行实时数据传输。
3.2 客户端：指使用RTMP协议进行数据传输的终端设备或应用程序。
3.3 服务器：指提供RTMP协议服务的主机或系统。
4. 协议规范4.1 连接建立4.1.1 客户端向服务器发起RTMP连接请求。
4.1.2 服务器接收到连接请求后，返回连接响应，包括连接成功与否的状态码。
4.1.3 客户端接收到连接响应后，根据状态码判断连接是否成功。
4.2 数据传输4.2.1 客户端向服务器发送数据请求。
4.2.2 服务器接收到数据请求后，返回相应的数据。
4.2.3 客户端接收到服务器返回的数据后，进行相应的处理。
4.3 数据格式4.3.1 RTMP协议支持多种数据格式，包括音频、视频和数据。
4.3.2 音频数据采用AAC编码格式，视频数据采用H.264编码格式。
4.3.3 数据格式由数据包头部的标识字段指定。
4.4 错误处理4.4.1 客户端在数据传输过程中发生错误时，应向服务器发送错误报告。
4.4.2 服务器接收到错误报告后，根据错误类型进行相应的处理。
4.4.3 客户端接收到服务器返回的错误处理结果后，进行相应的处理。
5. 安全性5.1 RTMP协议支持数据加密和身份验证。
5.2 客户端和服务器可以通过SSL/TLS协议进行数据加密。
5.3 客户端和服务器可以通过用户名和密码进行身份验证。
视频流媒体服务定制协议
20XX 标准合同模板范本PERSONAL RESUME甲方：XXX乙方：XXX视频流媒体服务定制协议合同编号_________一、合同主体甲方（委托方）：名称：____________________地址：____________________联系人：__________________联系电话：________________乙方（服务方）：名称：____________________地址：____________________联系人：__________________联系电话：________________二、合同前言2.1 背景和目的鉴于甲方需要定制视频流媒体服务，以提高其业务竞争力及扩大市场份额；乙方拥有专业的视频流媒体技术和服务团队，能够为甲方提供优质、高效的视频流媒体服务。
为明确双方的权利义务，确保合同顺利履行，双方经友好协商，特订立本合同。
2.2 合同依据中华人民共和国合同法、计算机信息网络国际联网安全保护管理办法等相关法律法规。
三、定义与解释3.1 专业术语（1）视频流媒体服务：指乙方根据甲方需求，提供视频内容的采集、编辑、存储、传输、播放等一站式服务。
（2）定制服务：指乙方根据甲方提出的特定需求，为甲方提供个性化的视频流媒体服务。
3.2 关键词解释（1）合同履行期间：自合同生效之日起至合同终止之日止。
（2）合同履行地点：甲方指定的地点。
四、权利与义务4.1 甲方的权利和义务（1）甲方有权按照合同约定，要求乙方提供视频流媒体定制服务。
（2）甲方应向乙方提供定制服务所需的技术、设备、资料等，并确保提供的资料真实、准确、完整。
（3）甲方应按照约定时间、地点支付合同款项。
（4）甲方不得将乙方提供的视频流媒体服务用于违法活动。
4.2 乙方的权利和义务（1）乙方有权按照合同约定，收取甲方支付的服务费用。
（2）乙方应按照甲方需求，提供专业的视频流媒体定制服务。
（3）乙方应确保提供的视频流媒体服务符合国家相关法律法规及行业标准。
网络流媒体协议书范文
网络流媒体协议书范文网络流媒体协议书一、引言网络流媒体协议书旨在规范网络流媒体服务提供商（以下简称“服务商”）与用户之间的权益和义务关系。
本协议书包括流媒体服务的内容、费用结算、隐私保护等方面的规定。
二、双方权益和义务1. 服务商的权益和义务（1）根据用户需求，提供稳定、高效的网络流媒体服务；（2）确保网络服务的安全性和用户数据的保密性；（3）与用户协商拟定服务费用，并帮助用户解决支付问题；（4）根据用户反馈，及时更新和改进网络流媒体服务；（5）对于用户存在违法行为，有权终止其服务。
2. 用户的权益和义务（1）享受流媒体服务的权益；（2）按时支付服务费用；（3）遵守网络流媒体服务提供方的使用规则；（4）保护个人隐私，不将个人账号提供给他人使用；（5）对于网络服务商提供的用户反馈及时给予回应。
三、流媒体服务内容1. 流媒体内容包括但不限于音频、视频、网络电视等形式，并按照服务商提供的流媒体服务规则开展。
2. 服务商保留调整服务内容、修改规则的权利，但应提前通知用户，并经用户同意或在合理期限内接受用户提出的异议。
四、服务费用结算1. 服务费用由服务商提前公布，并明确标明有效期、支付方式等信息。
2. 用户在享受流媒体服务时，按照服务费用规定的金额和期限进行支付。
服务商有权决定提前收取服务费用，并提供相应的优惠政策。
3. 用户应确保支付信息准确完整，如果由于用户提供信息错误而导致费用未能支付或支付失效，由用户自行承担责任。
4. 对于费用支付的争议，双方应协商解决。
如协商不成，可向有关部门投诉。
五、隐私保护和安全性1. 服务商应采取合理的技术手段，保护用户的个人隐私信息，并建立信息保护机制。
2. 服务商不得非法获取用户个人隐私信息，并不得将用户信息提供给其他公司或个人，除非得到用户明确的同意。
3. 用户应正确使用个人账号和密码。
对于因未妥善保管账号和密码而造成的损失，由用户自行承担。
六、争议解决1. 双方应通过友好协商解决因执行本协议而发生的争议。
流服务合同模板
流服务合同模板这是小编精心编写的合同文档，其中清晰明确的阐述了合同的各项重要内容与条款，请基于您自己的需求，在此基础上再修改以得到最终合同版本，谢谢！流服务合同模板甲方（以下简称“甲方”）与乙方（以下简称“乙方”）本着平等互利的原则，就甲方购买乙方提供的流媒体服务事宜，达成如下合同：一、服务内容1.1 乙方同意向甲方提供稳定的流媒体服务，包括直播、点播等功能。
1.2 乙方应确保服务的稳定性和安全性，保证甲方在使用过程中不受黑客攻击和其他网络故障的影响。
二、服务期限2.1 本合同自双方签订之日起生效，有效期为____年。
2.2 除非一方提前终止本合同，否则本合同将在有效期届满后自动续约____年。
三、服务费用3.1 甲方应按照乙方提供的收费标准，支付服务费用。
3.2 乙方应向甲方提供合法的发票等财务凭证。
四、技术支持和维护4.1 乙方应提供7x24小时的技术支持，确保甲方在使用过程中遇到的问题能够及时得到解决。
4.2 乙方应定期对服务进行维护和升级，提前通知甲方，并确保甲方业务的正常运行。
五、保密条款5.1 除非依法应当向行政机关、司法机关提供本合同外，双方应对本合同的内容和签订过程予以保密，未经对方同意不得向第三方披露。
5.2 乙方应对甲方的所有商业秘密和机密信息予以保密，未经甲方同意不得向第三方披露。
六、违约责任6.1 任何一方违反本合同的约定，导致合同无法履行或者造成对方损失的，应承担违约责任，向对方支付违约金，并赔偿损失。
七、争议解决7.1 对于因本合同引起的或与本合同有关的一切争议，双方应友好协商解决。
协商不成的，任何一方均有权向合同签订地人民法院提起诉讼。
八、其他8.1 本合同一式两份，甲乙双方各执一份。
8.2 本合同自双方签字（或盖章）之日起生效。
甲方（盖章）：____________________ 乙方（盖章）：____________________代表（签名）：____________________ 代表（签名）：____________________签订日期：____________________ 签订日期：____________________。
视频流媒体服务定制协议
编号：__________视频流媒体服务定制协议第一篇：通用版范文第二篇：中介版范文第三篇：甲方主导版范文第四篇：乙方主导版范文第五篇：纯商业化应用场景版范文甲方：___________________乙方：___________________签订日期：_____年_____月_____日视频流媒体服务定制协议本合同目录一览第一条协议定义1.1 定义1.2 术语解释第二条服务内容2.1 服务概述2.2 服务范围2.3 服务期限第三条技术要求与标准3.1 技术支持3.2 技术更新3.3 技术培训第四条合作双方的权利与义务4.1 甲方权利与义务4.2 乙方权利与义务第五条费用与支付5.1 费用标准5.2 支付方式5.3 费用调整第六条保密条款6.1 保密内容6.2 保密期限6.3 泄密责任第七条知识产权7.1 知识产权归属7.2 知识产权保护第八条违约责任8.1 违约行为8.2 违约责任承担第九条争议解决9.1 争议解决方式9.2 仲裁机构第十条合同的生效、变更与终止10.1 合同生效条件10.2 合同变更10.3 合同终止第十一条法律适用与争议解决11.1 法律适用11.2 争议解决第十二条合同的签订与生效12.1 签订地点与时间12.2 合同副本第十三条其他约定13.1 合作推广13.2 信息反馈第十四条附则14.1 合同附件14.2 附件说明第一部分：合同如下：第一条协议定义甲方：（甲方全称）乙方：（乙方全称）1.2 本协议所述“视频流媒体服务”是指乙方根据甲方需求，提供包括但不限于视频内容发布、视频内容管理、视频内容分发、视频播放器定制等在内的系列服务。
1.3 本协议所述“技术支持”是指乙方在服务期限内，为甲方提供关于视频流媒体服务的技术咨询、技术解答、技术指导等服务。
第二条服务内容2.1 乙方根据甲方的需求提供定制化的视频流媒体服务，具体服务内容详见附件一。
（1）视频播放流畅，画质清晰；（2）支持多终端观看，包括但不限于电脑、手机、平板等；（3）提供完善的内容管理系统，方便甲方进行内容管理；（4）提供可靠的内容分发网络，确保内容传输的安全和稳定。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
H5视频直播扫盲1 H5到底能不能做视频直播？当然可以， H5火了这么久，涵盖了各个方面的技术。
对于视频录制，可以使用强大的webRTC（Web Real-Time Communication）是一个支持网页浏览器进行实时语音对话或视频对话的技术，缺点是只在PC的chrome上支持较好，移动端支持不太理想。
对于视频播放，可以使用HLS(HTTP Live Streaming)协议播放直播流，ios和android都天然支持这种协议，配置简单，直接使用video标签即可。
webRTC兼容性：video标签播放hls协议视频：1 2 3 4 <video controls autoplay> <source src="10.66.69.77:8080/hls/mystream.m3u8" type="applicati /> <p class="warning">Your browser does not support HTML5 video.</p </video>2 到底什么是HLS 协议？简单讲就是把整个流分成一个个小的，基于HTTP 的文件来下载，每次只下载一些，前面提到了用于H5播放直播视频时引入的一个.m3u8的文件，这个文件就是基于HLS 协议，存放视频流元数据的文件。
每一个.m3u8文件，分别对应若干个ts 文件，这些ts 文件才是真正存放视频的数据，m3u8文件只是存放了一些ts 文件的配置信息和相关路径，当视频播放时，.m3u8是动态改变的，video 标签会解析这个文件，并找到对应的ts 文件来播放，所以一般为了加快速度，.m3u8放在web 服务器上，ts 文件放在cdn 上。
.m3u8文件，其实就是以UTF-8编码的m3u 文件，这个文件本身不能播放，只是存放了播放信息的文本文件：1 2 3 4 5 6 7 #EXTM3U m3u 文件头 #EXT-X-MEDIA-SEQUENCE 第一个TS 分片的序列号 #EXT-X-TARGETDURATION 每个分片TS 的最大的时长 #EXT-X-ALLOW-CACHE 是否允许cache #EXT-X-ENDLIST m3u8文件结束符 #EXTINF 指定每个媒体段(ts)的持续（秒），仅对其后面的URI 有效 mystream-12.tsts文件：HLS的请求流程是：1 http请求m3u8的url。
2 服务端返回一个m3u8的播放列表，这个播放列表是实时更新的，一般一次给出5段数据的url。
3 客户端解析m3u8的播放列表，再按序请求每一段的url，获取ts数据流。
简单流程：3 HLS直播延时我们知道hls协议是将直播流分成一段一段的小段视频去下载播放的，所以假设列表里面的包含5个ts文件，每个TS文件包含5秒的视频容，那么整体的延迟就是25秒。
因为当你看到这些视频时，主播已经将视频录制好上传上去了，所以时这样产生的延迟。
当然可以缩短列表的长度和单个ts文件的大小来降低延迟，极致来说可以缩减列表长度为1，并且ts的时长为1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲，所以苹果官方推荐的ts时长时10s，所以这样就会大改有30s的延迟。
参考资料：https://developer.apple./library/ios/documentation/ NetworkingInternet/Conceptual/StreamingMediaGuide/F requentlyAskedQuestions/FrequentlyAskedQuestions.ht ml4 视频直播的整个流程是什么？当视频直播可大致分为：1 视频录制端：一般是电脑上的音视频输入设备或者手机端的摄像头或者麦克风，目前以移动端的手机视频为主。
2 视频播放端：可以是电脑上的播放器，手机端的native播放器，还有就是h5的video标签等，目前还是已手机端的native播放器为主。
3 视频服务器端：一般是一台nginx服务器，用来接受视频录制端提供的视频源，同时提供给视频播放端流服务。
简单流程：5 怎样进行音视频采集？当首先明确几个概念：视频编码：所谓视频编码就是指通过特定的压缩技术，将某个视频格式的文件转换成另一种视频格式文件的方式，我们使用的iphone录制的视频，必须要经过编码，上传，解码，才能真正的在用户端的播放器里播放。
编解码标准：视频流传输中最为重要的编解码标准有国际电联的H.261、H.263、H.264，其中HLS协议支持H.264格式的编码。
音频编码：同视频编码类似，将原始的音频流按照一定的标准进行编码，上传，解码，同时在播放器里播放，当然音频也有许多编码标准，例如PCM编码，WMA编码，AAC编码等等，这里我们HLS协议支持的音频编码方式是AAC编码。
下面将利用ios上的摄像头，进行音视频的数据采集，主要分为以下几个步骤：1 音视频的采集，ios中，利用AVCaptureSession和AVCaptureDevice可以采集到原始的音视频数据流。
2 对视频进行H264编码，对音频进行AAC编码，在ios中分别有已经封装好的编码库来实现对音视频的编码。
3 对编码后的音、视频数据进行组装封包；4 建立RTMP连接并上推到服务端。
ps：由于编码库大多使用c语言编写，需要自己使用时编译，对于ios，可以使用已经编译好的编码库。
x264编码：https://github./kewlbear/x264-iosfaac编码：https://github./fflydev/faac-ios-build ffmpeg编码：https://github./kewlbear/FFmpeg-iOS-build-script关于如果想给视频增加一些特殊效果，例如增加滤镜等，一般在编码前给使用滤镜库，但是这样也会造成一些耗时，导致上传视频数据有一定延时。
简单流程：6 前面提到的ffmpeg是什么？和之前的x264一样，ffmpeg其实也是一套编码库，类似的还有Xvid，Xvid是基于MPEG4协议的编解码器，x264是基于H.264协议的编码器，ffmpeg集合了各种音频，视频编解码协议，通过设置参数可以完成基于MPEG4,H.264等协议的编解码，demo这里使用的是x264编码库。
7 什么是RTMP？Real Time Messaging Protocol（简称 RTMP）是 Macromedia 开发的一套视频直播协议，现在属于 Adobe。
和HLS一样都可以应用于视频直播，区别是RTMP基于flash无法在ios的浏览器里播放，但是实时性比HLS要好。
所以一般使用这种协议来上传视频流，也就是视频流推送到服务器。
这里列举一下hls和rtmp对比：8 推流简所谓推流，就是将我们已经编码好的音视频数据发往视频流服务器中，一般常用的是使用rtmp推流，可以使用第三方库librtmp-iOS进行推流，librtmp封装了一些核心的api供使用者调用，如果觉得麻烦，可以使用现成的ios视频推流sdk，也是基于rtmp的，https://github./runner365/LiveVideoCoreSDK9 推流服务器搭建简简单的推流服务器搭建，由于我们上传的视频流都是基于rtmp 协议的，所以服务器也必须要支持rtmp 才行，大概需要以下几个步骤：1 安装一台nginx 服务器。
2 安装nginx 的rtmp 扩展，目前使用比较多的是https://github./arut/nginx-rtmp-module3 配置nginx 的conf 文件：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 rtmp {server {listen 1935; #监听的端口chunk_size 4000;application hls{ #rtmp 推流请求路径live on;hls on;hls_path/usr/local/var//hls;hls_fragment5s;}}}4 重启nginx ，将rtmp 的推流地址写为rtmp://ip:1935/hls/mystream ，其中hls_path 表示生成的.m3u8和ts 文件所存放的地址，hls_fragment 表示切片时长，mysteam 表示一个实例，即将来要生成的文件名可以先自己随便设置一个。
更多配置可以参考：https://github./arut/nginx-rtmp-module/wiki/根据以上步骤基本上已经实现了一个支持rtmp 的视频服务器了。
10 在html5页面进行播放直播视频？简单来说，直接使用video 标签即可播放hls 协议的直播视频：1 2 3 4 <video autoplay webkit-playsinline> <source src="10.66.69.77:8080/hls/mystream.m3u8" type="applicati /> <p class="warning">Your browser does not support HTML5 video.</p </video>需要注意的是，给video 标签增加webkit-playsinline 属性，这个属性是为了让video 视频在ios 的uiwebview 里面可以不全屏播放，默认ios 会全屏播放视频，需要给uiwebview 设置allowsInlineMediaPlayback ＝YES 。
业界比较成熟的videojs ，可以根据不同平台选择不同的策略，例如ios 使用video 标签，pc 使用flash 等。
11 坑点总结简根据以上步骤，笔者写了一个demo ，从实现ios 视频录制，采集，上传，nginx 服务器下发直播流，h5页面播放直播视频者一整套流程，总结出以下几点比较坑的地方：1 在使用AVCaptureSession进行采集视频时，需要实现AVCaptureVideoDataOutputSampleBufferDelegate协议，同时在- (void)captureOutput:(AVCaptureOutput*)captureOutputdidOutputSampleBuffer:(CMSampleBufferRef)sampleBuff er fromConnection:(AVCaptureConnection *)connection 捕获到视频流，要注意的是didOutputSampleBuffer这个方法不是didDropSampleBuffer方法，后者只会触发一次，当时开始写的是didDropSampleBuffer方法，差了半天才发现方法调用错了。