CN109889766B - 基于浏览器实现屏幕传输功能的方法 - Google Patents
基于浏览器实现屏幕传输功能的方法 Download PDFInfo
- Publication number
- CN109889766B CN109889766B CN201910316800.7A CN201910316800A CN109889766B CN 109889766 B CN109889766 B CN 109889766B CN 201910316800 A CN201910316800 A CN 201910316800A CN 109889766 B CN109889766 B CN 109889766B
- Authority
- CN
- China
- Prior art keywords
- mcu
- browser
- key frame
- data
- background
- 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
Links
Images
Abstract
本发明涉及一种基于浏览器实现屏幕传输功能的方法，包括(1)后台采集屏幕，将加入序列号和帧类型的码流发送至MCU，MCU接收数据并发送至前端；(2)前端接收MCU的视频数据，解码后发送帧序列至所述的MCU；(3)所述的MCU根据帧类型清理缓存，MCU将反馈转发至后台；(4)后台判断采集的序列号和前端反馈的序列号是否相差过大，如果是，则停止采集，等待传输和解码完成；否则，继续采集。采用了本发明的基于浏览器实现屏幕传输功能的方法，得用户可以在浏览器中直接打开云应用或者云桌面，不需要下载任何插件，同时，针对屏幕传输的场景，提出了新的解决方案，可以大大减小延迟和操作的卡顿感，提高用户体验。
Description
技术领域
本发明涉及音视频编解码领域，尤其涉及流量控制算法领域，具体是指一种基于浏览器实现屏幕传输功能的方法。
背景技术
随着前端技术和云计算的发展，越来越多的公司和个人开始把系统和应用搬到云端，让云端来负责计算功能，同时，把云端的计算结果，通过公有或者私有的协议，在前端呈现出来。这样做的好处是方便了用户，用户不必安装复杂的系统或者应用，只需要通过一台浏览器，即可实现原来在本机中所有的操作，并且可以实时得到结果。
云端计算结果的呈现方式多种多样，最普遍也是最方便的一种，就是把远程的应用或者桌面抓屏，通过各种编码协议发送到前端，前端再做解码和渲染。目前浏览器能够支持的，除了Webrtc，就是一些私有化的协议，本发明讨论的就是私有化协议中的一种。
Webrtc可以用来做屏幕传输，但是对于屏幕传输，Webrtc有以下缺点：
1、系统太过复杂，集成了太多的屏幕传输不需要的算法，使得深度优化难度很大。
2、延迟很高，webrtc是针对视频会议的，在屏幕传输的场景下，延迟往往很高，特别是在带宽不足的情况下。
3、升级频繁，维护工作量很大。由于webrtc是内置在浏览器中的，开发者不可控制，只能针对每个版本做升级和维护，带来的工作量很大。
私有化协议往往很难取得浏览器的支持，使得开发者需要采用插件或者客户端的形式提供给用户，使得体验大大下降。
本发明就是吸取了webrtc的优点，使得用户可以在浏览器中直接打开云应用或者云桌面，不需要下载任何插件，同时，针对屏幕传输的场景，提出了新的解决方案，可以大大减小延迟和操作的卡顿感，提高用户体验。
发明内容
本发明的目的是克服了上述现有技术的缺点，提供了一种满足即时性强、延时小、操作简便的基于浏览器实现屏幕传输功能的方法。
为了实现上述目的，本发明的基于浏览器实现屏幕传输功能的方法如下：
该基于浏览器实现屏幕传输功能的方法，其主要特点是，所述的方法包括以下步骤：
(1)后台采集屏幕，将加入序列号和帧类型的码流发送至MCU，MCU接收数据并发送至前端；
(2)前端接收MCU的视频数据，解码后发送帧序列至所述的MCU；
(3)所述的MCU根据帧类型清理缓存，MCU将反馈转发至后台；
(4)后台判断采集的序列号和前端反馈的序列号是否相差过大，如果是，则停止采集，等待传输和解码完成；否则，继续采集。
较佳地，所述的步骤(1)中所述的码流根据h264编码器得到。
较佳地，所述的步骤(2)还包括前端定期根据帧类型清理缓存的步骤，具体包括以下步骤：
(2.1)前端根据帧类型判断是否需要发送关键帧请求，如果是，则发送关键帧请求；否则，前端丢弃后续所有帧数据，直至获取关键帧数据。
较佳地，所述的步骤(3)具体包括以下步骤：
(3.1)MCU清除所有的p帧数据，只保留关键帧数据；
(3.2)判断MCU是否有缓存关键帧，如果是，则丢弃后续所有帧数据，直至获取关键帧数据；否则，向后台申请关键帧；
(3.3)MCU将反馈转发至后台。
较佳地，所述的步骤(3)还包括以下步骤：
(3.4)MCU对来自不同通道的关键帧请求进行合并处理。
较佳地，所述的前端通过Webassembly技术进行视频解码。
采用了本发明的基于浏览器实现屏幕传输功能的方法，得用户可以在浏览器中直接打开云应用或者云桌面，不需要下载任何插件，同时，针对屏幕传输的场景，提出了新的解决方案，可以大大减小延迟和操作的卡顿感，提高用户体验。
附图说明
图1为本发明的基于浏览器实现屏幕传输功能的方法的MCU清理缓存的示意流程图。
图2为本发明的基于浏览器实现屏幕传输功能的方法的MCU处理来自前端的关键帧请求的示意流程图。
图3为本发明的基于浏览器实现屏幕传输功能的方法的MCU合并相同的关键帧请求的示意流程图。
具体实施方式
为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。
本发明的该基于浏览器实现屏幕传输功能的方法，其中包括：
(1)后台采集屏幕，将加入序列号和帧类型的码流发送至MCU，MCU接收数据并发送至前端；
(2)前端接收MCU的视频数据，解码后发送帧序列至所述的MCU；
(2.1)前端根据帧类型判断是否需要发送关键帧请求，如果是，则发送关键帧请求；
否则，前端丢弃后续所有帧数据，直至获取关键帧数据；
(3)所述的MCU根据帧类型清理缓存，MCU将反馈转发至后台；
(3.1)MCU清除所有的p帧数据，只保留关键帧数据；
(3.2)判断MCU是否有缓存关键帧，如果是，则丢弃后续所有帧数据，直至获取关键帧数据；否则，向后台申请关键帧；
(3.3)MCU将反馈转发至后台；
(3.4)MCU对来自不同通道的关键帧请求进行合并处理；
(4)后台判断采集的序列号和前端反馈的序列号是否相差过大，如果是，则停止采集，等待传输和解码完成；否则，继续采集。
作为本发明的优选实施方式，所述的步骤(1)中所述的码流根据h264编码器得到。
作为本发明的优选实施方式，所述的前端通过Webassembly技术进行视频解码。
本发明的具体实施方式中，包括编译h264的代码到Webassembly；根据算法协议实现前端；根据算法协议实现MCU；后台集成h264codec，采集和编码；部署前端后台和MCU。
后台技术如下：
后台负责采集屏幕，并且利用h264编码器编成码流发送给MCU，在发送的每一帧的码流中，加上序列号和帧类型。
同时，后台对屏幕的采集依赖前端的反馈，如果采集的序列号和前端反馈的序列号相差过大，则停止采集，等待传输和解码完成。后台在处理多人协作。
MCU技术如下：
MCU作为中间件，负责接收后台的数据，并且发送给前端，由于后台和MCU在同一个局域网，数据传输比较快，在前端带宽不足的情况下，MCU负责自动清理缓存数据。MCU根据帧类型来清理数据，每次清理的时候，清除所有的p帧数据，只保留关键帧。如果MCU上没有缓存的关键帧，则MCU负责像后台申请关键帧。如果MCU已经请求了关键帧，则后续所有的帧数据都会被丢弃，直到关键帧来了为止。同时，MCU上为了避免发送太多的关键帧导致负载变重，对来自不同通道的关键帧请求做了合并处理。
前端技术如下：
前端利用Webassembly，把h264的codec翻译成webassembly，并用websocket接收来自MCU的视频数据，在解码完成后，发送帧序列反馈给MCU，MCU把反馈转发给后台。在前端解码能力不足的情况下，前端会定期地根据帧类型来清理缓存，并决定是否需要发送关键帧请求。同样，如果关键帧请求发送出去了，前端会持续丢弃所有后面的帧数据，直到关键帧来了为止。
具体步骤如下：
1、前端发送帧序列号给后台，后台根据前端反馈的帧序列决定是否需要继续采集。
2、MCU中根据帧类型来决定如何清理缓存。
3、前端在解码能力不足时，根据帧类型来决定如何清理缓存。
本发明采用的跳帧策略是在发送端完成的，和视频采集严格绑定。本发明中的跳帧策略是利用接收端直接发送反馈的方法，和时间无关。本发明使用Webassembly技术是用来做视频解码，包括但不限于h264，vp8，vp9，使用浏览器提供的WebGL进行渲染，不产生mp4文件。
本领域中，视频传输一般不是以帧的形式，而是以RTP包的形式进行传输，每一帧会分包成一个或多个RTP包，MCU收到并且转发的通常都是RTP包，根据RTP协议，在RTP包中，无法获知帧类型，所以也无法进行这样的清理缓存操作。
采用了本发明的基于浏览器实现屏幕传输功能的方法，得用户可以在浏览器中直接打开云应用或者云桌面，不需要下载任何插件，同时，针对屏幕传输的场景，提出了新的解决方案，可以大大减小延迟和操作的卡顿感，提高用户体验。
在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。
Claims (6)
1.一种基于浏览器实现屏幕传输功能的方法，其特征在于，所述的方法包括以下步骤：
(1)后台采集屏幕，将加入序列号和帧类型的码流发送至微控制单元MCU，MCU接收数据并发送至前端；
(2)前端接收MCU的视频数据，解码后将包含序列号的帧序列作为反馈发送至所述的MCU；
(3)所述的MCU根据帧类型清理缓存，清除非关键帧数据而保留关键帧数据，MCU将来自前端的反馈转发至后台；
(4)后台判断采集的序列号和前端反馈的序列号是否相差过大，如果是，则停止采集屏幕，等待传输和解码完成；否则，继续采集屏幕。
2.根据权利要求1所述的基于浏览器实现屏幕传输功能的方法，其特征在于，所述的步骤(1)中所述的码流根据h264编码器得到。
3.根据权利要求1所述的基于浏览器实现屏幕传输功能的方法，其特征在于，所述的步骤(2)还包括前端定期根据帧类型清理缓存的步骤，具体包括以下步骤：
(2.1)前端根据帧类型判断是否需要发送关键帧请求，如果是，则发送关键帧请求；否则，前端丢弃后续所有帧数据，直至获取关键帧数据。
4.根据权利要求1所述的基于浏览器实现屏幕传输功能的方法，其特征在于，所述的步骤(3)具体包括以下步骤：
(3.1)MCU清除所有的p帧数据，只保留关键帧数据；
(3.2)判断MCU是否有缓存关键帧，如果是，则丢弃后续所有帧数据，直至获取关键帧数据；否则，向后台申请关键帧；
(3.3)MCU将反馈转发至后台。
5.根据权利要求1所述的基于浏览器实现屏幕传输功能的方法，其特征在于，所述的步骤(3)还包括以下步骤：
(3.4)MCU对来自不同通道的关键帧请求进行合并处理。
6.根据权利要求1所述的基于浏览器实现屏幕传输功能的方法，其特征在于，所述的前端通过Webassembly技术进行视频解码。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910316800.7A CN109889766B (zh) | 2019-04-19 | 2019-04-19 | 基于浏览器实现屏幕传输功能的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910316800.7A CN109889766B (zh) | 2019-04-19 | 2019-04-19 | 基于浏览器实现屏幕传输功能的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109889766A CN109889766A (zh) | 2019-06-14 |
| CN109889766B true CN109889766B (zh) | 2021-02-02 |
Family
ID=66937872
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910316800.7A Active CN109889766B (zh) | 2019-04-19 | 2019-04-19 | 基于浏览器实现屏幕传输功能的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109889766B (zh) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5820281B2 (ja) * | 2012-01-12 | 2015-11-24 | キヤノン株式会社 | 情報処理装置、その処理方法及びプログラム |
| CN103237191B (zh) * | 2013-04-16 | 2016-04-06 | 成都飞视美视频技术有限公司 | 在视频会议中同步推送音视频的方法 |
| CN104780387B (zh) * | 2014-01-13 | 2018-05-01 | 北京兆维电子(集团)有限责任公司 | 一种视频传输方法及系统 |
| CN112492118B (zh) * | 2018-06-21 | 2023-11-17 | 深圳市道通智能航空技术股份有限公司 | 数据传输控制方法、信息发送端、接收端及飞行器图传系统 |
-
2019
- 2019-04-19 CN CN201910316800.7A patent/CN109889766B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN109889766A (zh) | 2019-06-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108810636B (zh) | 视频播放方法、虚拟现实设备、服务器、系统及存储介质 | |
| CN107231328B (zh) | 实时视频传输方法、装置、设备及系统 | |
| EP2789120B1 (en) | Collaboration system and method | |
| JP5268915B2 (ja) | マルチメディア音声会議向け視覚的構成の管理技術 | |
| EP1566038B1 (en) | Methods and systems for transferring events including multimedia data | |
| CN113423018A (zh) | 一种游戏数据处理方法、装置及存储介质 | |
| CN100581257C (zh) | 基于视频帧拆分的实时流媒体传输方法及系统 | |
| US20080100694A1 (en) | Distributed caching for multimedia conference calls | |
| CN105635636B (zh) | 一种视频会议系统及其实现视频图像传输控制的方法 | |
| RU2011124074A (ru) | Согласование скорости при видеоконференциях | |
| US8189492B2 (en) | Error recovery in an audio-video multipoint control component | |
| KR20120082434A (ko) | 짧은 대기 시간의 전송 프로토콜을 위한 방법 및 시스템 | |
| JP2008544615A (ja) | スケーラブルビデオ符号化における符号化依存性の表示 | |
| JP2015501098A5 (zh) | ||
| JP2015501098A (ja) | 復号化されたピクチャのバッファおよび基準ピクチャのリストのための状態情報の信号化 | |
| CN100420299C (zh) | 一种屏幕广播方法 | |
| CN104685873B (zh) | 编码控制设备以及编码控制方法 | |
| KR20100103558A (ko) | 변화하는 비주얼 컨텐트 통신 | |
| CN103179431A (zh) | Vdi环境下音视频重定向转码分离方法 | |
| JP2022510325A (ja) | 符号化ビデオストリームを復号するための方法、システム、及びコンピュータプログラム | |
| CN103209204A (zh) | 一种用于医学影像教学系统的计算机屏幕远程控制方法 | |
| CN110730364B (zh) | 一种云手机数据传输方法、装置及存储介质 | |
| EP1162806A3 (en) | Simultaneous viewing and/or listening to a plurality of transmitted multimedia streams through a centralized processing space | |
| CN109889766B (zh) | 基于浏览器实现屏幕传输功能的方法 | |
| CN109963110A (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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200903 Address after: 501-3, 5 / F, building 6, 54 courtyard, Shijingshan Road, Shijingshan District, Beijing 100041 Applicant after: Diankeyun (Beijing) Technology Co.,Ltd. Address before: 230031 West Lake International A1307, 69 Wangjiangxi Road, Hefei City, Anhui Province Applicant before: HEFEI XIETONG TECHNOLOGY Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |