CN115706829A - 一种多窗口视频通信方法、设备及系统 - Google Patents

一种多窗口视频通信方法、设备及系统 Download PDF

Info

Publication number
CN115706829A
CN115706829A CN202110887044.0A CN202110887044A CN115706829A CN 115706829 A CN115706829 A CN 115706829A CN 202110887044 A CN202110887044 A CN 202110887044A CN 115706829 A CN115706829 A CN 115706829A
Authority
CN
China
Prior art keywords
audio
window
video
bandwidth
definition
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.)
Pending
Application number
CN202110887044.0A
Other languages
English (en)
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202110887044.0A priority Critical patent/CN115706829A/zh
Priority to PCT/CN2022/109423 priority patent/WO2023011408A1/zh
Publication of CN115706829A publication Critical patent/CN115706829A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems

Abstract

本申请公开了一种多窗口视频通信方法、设备及系统，涉及通信技术领域，可以在多方视频通话的过程中，充分利用带宽资源以避免网络拥塞，从而保障视频的流畅度和/或清晰度。本申请中，接收端的界面上显示有多个窗口，在带宽资源不足以满足多个音视频流的带宽需求(即处于弱网环境)时，接收端可以根据多个窗口对应的具体优先级进行降级订阅。例如降低视频清晰度、取消订阅视频流或延迟订阅视频流等，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。

Description

一种多窗口视频通信方法、设备及系统
技术领域
本申请实施例涉及通信技术领域，尤其涉及一种多窗口视频通信方法、设备及系统。
背景技术
随着线上学习、线上会议、线上聊天的普及，多窗口视频通信的应用场景越来越多样化。例如多窗口视频通信以多方视频通话的形式用于专业的会议场景(例如多方会议场景)，生活场景(例如群视频聊天场景)或网上教育场景等。
在多窗口视频通信时，作为一种实现方案，发送端可以通过云侧向接收端转发音视频流。云侧向接收端转发来自发送端的音视频流，以及对转发音视频流的通信链路进行带宽预测。其中，云侧预测的带宽用于在网络较差时进行通信决策(例如抽帧决策等)。
可以理解，上述常规技术在网络较差时，对于通信多方的处理是平等的。但是，不同多窗口视频通信场景的侧重点不同，例如网上教育场景需优先保障课件/白板的流程度，其次为讲师的人像画面；又如多方会议场景需优先保障当前的主讲人(如声音音量值最大的人)的视频和音频，其次为其他会议参与者，因此基于上述常规技术，在网络较差时，接收端无法根据具体需求适应性处理，会导致重要的视频在弱网时出现卡顿。
发明内容
本申请提供一种多窗口视频通信方法、设备及系统，可以在多方视频通话的过程中，充分利用带宽资源以避免网络拥塞，从而保障视频的流畅度和/或清晰度。
为达到上述目的，本申请实施例采用如下技术方案：
第一方面，提供一种多窗口视频通信方法，该方法应用于多个第一设备与第二设备视频通话的过程中，该方法包括：第二设备接收分别来自多个第一设备的多个音视频流；其中，上述多个音视频流对应的音频和视频分别在第二设备界面上的多个窗口中播放；第二设备确定带宽资源不足以满足多个音视频流的带宽需求；第二设备根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略。示例性的，第二设备调整订阅策略可以包括但不限于取消订阅、恢复订阅、延迟订阅、降低清晰度或提高清晰度中的一种或多种。
上述第一方面提供的方案，接收端在带宽资源不足以满足多个音视频流的带宽需求(即弱网环境)时，例如在用于表征带宽资源的总带宽预测值小于个音视频流的带宽需求时，可以根据多个窗口对应的具体优先级进行降级订阅，例如降低视频清晰度、取消订阅视频流或延迟订阅视频流等，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。其中，窗口对应的优先级可以用于表征具体业务需求或者用户的偏好等。
在一种可能的实现方式中，上述第二设备接收分别来自多个第一设备的多个音视频流，包括：第二设备接收第三设备转发的，分别来自多个第一设备的多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于第三设备转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述方法还包括：上述第二设备从第三设备接收对多条链路的多个带宽预测结果；第二设备根据多个带宽预测结果确定带宽资源不足以满足多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第三设备进行带宽预测。例如，第三设备可以在向第二设备转发音视频流时进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，上述方法还包括：第二设备测量得到对多条链路的多个带宽预测结果；第二设备根据上述多个带宽预测结果确定带宽资源不足以满足上述多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第二设备进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，第一窗口以第一清晰度播放对应音视频流；该第一窗口是上述多个窗口中；第二设备根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略，包括：第二设备为第一窗口订阅第二清晰度的音视频流；第二清晰度小于第一清晰度。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行降低视频清晰度的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二设备为第一窗口订阅第二清晰度的音视频流之后，上述方法还包括：在满足第一预设条件时，第二设备为第一窗口订阅第一清晰度的音视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二设备为第一窗口订阅第二清晰度的音视频流之后，上述方法还包括：在满足第一预设条件预设时间段时，第二设备为第一窗口订阅第一清晰度的音视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，第二窗口以第二清晰度播放音视频流，上述第二清晰度小于或等于预设值，第二窗口是上述多个窗口中、优先级最低的窗口；上述第二设备根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略，包括：第二设备取消订阅第二窗口对应的视频流。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行取消订阅的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二窗口取消订阅之后，上述方法还包括：第二设备在第二窗口上显示蒙层。通过显示蒙层，可以提醒用户当前处于弱网环境，提高用户体验。
在一种可能的实现方式中，在上述第二设备取消订阅第二窗口对应的视频流之后，上述方法还包括：在满足第二预设条件时，第二设备为第二窗口恢复订阅第二清晰度的视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二设备取消订阅第二窗口对应的视频流之后，上述方法还包括：在满足第二预设条件预设时间段时，第二设备为第二窗口恢复订阅第二清晰度的视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述多个窗口对应的优先级由第二设备根据以下中的一个或多个确定：多个窗口对应的音频的初始音量；多个窗口对应的音频的播放音量；多个窗口中业务的功能。其中，音频的初始音量用于表征第二设备接收到音频流时，音频流的原始音量。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由第二设备自行根据多个窗口对应的初始/播放音频的音量和/或多个窗口中业务的功能确定多个窗口对应的优先级。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述多个窗口对应的优先级由第二设备根据用户的自定义指定操作确定。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由用户自定义。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述第二设备接收第三设备转发的，分别来自多个第一设备的多个音视频流，包括：第二设备从第一云端设备接收第一音视频流；第二设备从第二云端设备接收第二音视频流和第三音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于分布式的云端设备(即第三设备)转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述第三设备是选择性转发单元(selectiveforwarding unit，SFU)。通过该方案，可以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
第二方面，提供一种电子设备(如第二设备)，该电子设备包括：收发单元，用于接收分别来自多个第一设备的多个音视频流；其中，上述多个音视频流对应的音频和视频分别在第二设备界面上的多个窗口中播放；显示单元，用于通过上述多个窗口播放上述多个音视频流；处理单元，用于确定带宽资源不足以满足多个音视频流的带宽需求；以及根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略。示例性的，第二设备调整订阅策略可以包括但不限于取消订阅、恢复订阅、延迟订阅、降低清晰度或提高清晰度中的一种或多种。
上述第二方面提供的方案，接收端在带宽资源不足以满足多个音视频流的带宽需求(即弱网环境)时，例如在用于表征带宽资源的总带宽预测值小于个音视频流的带宽需求时，可以根据多个窗口对应的具体优先级进行降级订阅，例如降低视频清晰度、取消订阅视频流或延迟订阅视频流等，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。其中，窗口对应的优先级可以用于表征具体业务需求或者用户的偏好等。
在一种可能的实现方式中，上述收发单元具体用于：接收第三设备转发的，分别来自多个第一设备的多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于第三设备转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述收发单元还用于：从第三设备接收对多条链路的多个带宽预测结果；上述处理单元还用于：根据多个带宽预测结果确定带宽资源不足以满足多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第三设备进行带宽预测。例如，第三设备可以在向第二设备转发音视频流时进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，上述处理单元还用于：测量得到对多条链路的多个带宽预测结果；以及，根据上述多个带宽预测结果确定带宽资源不足以满足上述多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第二设备进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，第一窗口以第一清晰度播放对应音视频流；该第一窗口是上述多个窗口中；上述处理单元具体用于：为第一窗口订阅第二清晰度的音视频流；第二清晰度小于第一清晰度。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行降低视频清晰度的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理单元还用于，在满足第一预设条件时，为第一窗口订阅第一清晰度的音视频流。例如，处理单元可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理单元还用于：在满足第一预设条件预设时间段时，为第一窗口订阅第一清晰度的音视频流。例如，处理单元可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，第二窗口以第二清晰度播放音视频流，上述第二清晰度小于或等于预设值，第二窗口是上述多个窗口中、优先级最低的窗口；上述处理单元具体用于：取消订阅第二窗口对应的视频流。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行取消订阅的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二窗口取消订阅之后，上述显示单元还用于：在第二窗口上显示蒙层。
在一种可能的实现方式中，上述处理单元还用于：在满足第二预设条件时，为第二窗口恢复订阅第二清晰度的视频流。例如，处理单元可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理单元还用于：在满足第二预设条件预设时间段时，处理单元为第二窗口恢复订阅第二清晰度的视频流。例如，处理单元可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理单元还用于根据下中的一个或多个确定多个窗口对应的优先级：多个窗口对应的音频的初始音量；多个窗口对应的音频的播放音量；多个窗口中业务的功能。其中，音频的初始音量用于表征第二设备接收到音频流时，音频流的原始音量。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由第二设备自行根据多个窗口对应的初始/播放音频的音量和/或多个窗口中业务的功能确定多个窗口对应的优先级。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述处理单元还用于，根据用户的自定义指定操作确定多个窗口对应的优先级。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由用户自定义。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述收发单元具体用于：从第一云端设备接收第一音视频流；以及，从第二云端设备接收第二音视频流和第三音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于分布式的云端设备(即第三设备)转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述第三设备是SFU。通过该方案，可以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
第三方面，提供一种电子设备(如第二设备)，该电子设备包括：存储器，用于存储计算机程序；收发器，用于接收或发送无线电信号；显示器，用于显示界面；处理器，用于执行所述计算机程序，使得电子设备通过收发器接收分别来自多个第一设备的多个音视频流；其中，上述多个音视频流对应的音频和视频分别在第二设备界面上的多个窗口中播放；确定带宽资源不足以满足多个音视频流的带宽需求；以及根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略。示例性的，第二设备调整订阅策略可以包括但不限于取消订阅、恢复订阅、延迟订阅、降低清晰度或提高清晰度中的一种或多种。
上述第三方面提供的方案，接收端在带宽资源不足以满足多个音视频流的带宽需求(即弱网环境)时，例如在用于表征带宽资源的总带宽预测值小于个音视频流的带宽需求时，可以根据多个窗口对应的具体优先级进行降级订阅，例如降低视频清晰度、取消订阅视频流或延迟订阅视频流等，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。其中，窗口对应的优先级可以用于表征具体业务需求或者用户的偏好等。
在一种可能的实现方式中，上述收发器具体用于：接收第三设备转发的，分别来自多个第一设备的多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于第三设备转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述收发器还用于：从第三设备接收对多条链路的多个带宽预测结果；上述处理器还用于：根据多个带宽预测结果确定带宽资源不足以满足多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第三设备进行带宽预测。例如，第三设备可以在向第二设备转发音视频流时进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，上述处理器还用于：测量得到对多条链路的多个带宽预测结果；以及，根据上述多个带宽预测结果确定带宽资源不足以满足上述多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第二设备进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，第一窗口以第一清晰度播放对应音视频流；该第一窗口是上述多个窗口中；上述处理器具体用于：为第一窗口订阅第二清晰度的音视频流；第二清晰度小于第一清晰度。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行降低视频清晰度的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理器还用于：在满足第一预设条件时，为第一窗口订阅第一清晰度的音视频流。例如，处理器可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理器还用于：在满足第一预设条件预设时间段时，为第一窗口订阅第一清晰度的音视频流。例如，处理器可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，第二窗口以第二清晰度播放音视频流，上述第二清晰度小于或等于预设值，第二窗口是上述多个窗口中、优先级最低的窗口；上述处理器具体用于：取消订阅第二窗口对应的视频流。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行取消订阅的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二窗口取消订阅之后，上述显示器还用于，在第二窗口上显示蒙层。
在一种可能的实现方式中，上述处理器还用于：在满足第二预设条件时，为第二窗口恢复订阅第二清晰度的视频流。例如，处理器可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理器还用于：在满足第二预设条件预设时间段时，处理单元为第二窗口恢复订阅第二清晰度的视频流。例如，处理器可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述处理器还用于根据下中的一个或多个确定多个窗口对应的优先级：多个窗口对应的音频的初始音量；多个窗口对应的音频的播放音量；多个窗口中业务的功能。其中，音频的初始音量用于表征第二设备接收到音频流时，音频流的原始音量。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由第二设备自行根据多个窗口对应的初始/播放音频的音量和/或多个窗口中业务的功能确定多个窗口对应的优先级。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述处理器还用于：根据用户的自定义指定操作确定多个窗口对应的优先级。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由用户自定义。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述收发器具体用于：从第一云端设备接收第一音视频流；以及，从第二云端设备接收第二音视频流和第三音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于分布式的云端设备(即第三设备)转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述第三设备是SFU。通过该方案，可以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
第四方面，提供一种多窗口视频通信方法，该方法应用于通信系统中的多个第一设备与第二设备视频通话的过程中，该方法包括：多个第一设备向第二设备发送音视频流；其中，上述多个音视频流对应的音频和视频分别在第二设备界面上的多个窗口中播放；第二设备确定带宽资源不足以满足多个音视频流的带宽需求；第二设备根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略。示例性的，第二设备调整订阅策略可以包括但不限于取消订阅、恢复订阅、延迟订阅、降低清晰度或提高清晰度中的一种或多种。
上述第四方面提供的方案，接收端在带宽资源不足以满足多个音视频流的带宽需求(即弱网环境)时，例如在用于表征带宽资源的总带宽预测值小于个音视频流的带宽需求时，可以根据多个窗口对应的具体优先级进行降级订阅，例如降低视频清晰度、取消订阅视频流或延迟订阅视频流等，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。其中，窗口对应的优先级可以用于表征具体业务需求或者用户的偏好等。
在一种可能的实现方式中，上述通信系统还包括：一个或多个第三设备，用于从上述多个第一设备接收上述多个音视频流，以及向第二设备转发上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于第三设备转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述第三设备还用于：在向第二设备转发上述多个音视频流的过程中，测量以得到对多条链路的多个带宽预测结果；第二设备具体用于：根据多个带宽预测结果确定带宽资源不足以满足多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第三设备进行带宽预测。例如，第三设备可以在向第二设备转发音视频流时进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，第二设备还用于：在接收上述多个音视频流的过程中，测量以得到对多条链路的多个带宽预测结果；第二设备具体用于：根据上述多个带宽预测结果确定带宽资源不足以满足上述多个音视频流的带宽需求。其中，上述多条链路与上述多个音视频流对应。例如上述多条链路分别用于传输上述多个音视频流。作为一种示例，本申请提供的多窗口视频通信方法中，可以由第二设备进行带宽预测，通过该方案，可以提高本申请提供的方法与不同网络架构的兼容性。
在一种可能的实现方式中，上述第二设备还用于：通过第一窗口以第一清晰度播放对应音视频流；该第一窗口是上述多个窗口中；第二设备根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略，包括：第二设备为第一窗口订阅第二清晰度的音视频流；第二清晰度小于第一清晰度。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行降低视频清晰度的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二设备为第一窗口订阅第二清晰度的音视频流之后，上述第二设备还用于：在满足第一预设条件时，为第一窗口订阅第一清晰度的音视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二设备为第一窗口订阅第二清晰度的音视频流之后，上述第二设备还用于：在满足第一预设条件预设时间段时，为第一窗口订阅第一清晰度的音视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第一预设条件。例如，第一预设条件可以是最新的总带宽预测值满足第一窗口恢复以第一清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复清晰度的带宽需求时，恢复被降级的视频的清晰度，以最大限度的保证视频的流畅度和/或清晰度
在一种可能的实现方式中，上述第二设备还用于：通过第二窗口以第二清晰度播放音视频流，上述第二清晰度小于或等于预设值，第二窗口是上述多个窗口中、优先级最低的窗口；上述第二设备根据多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略，包括：第二设备取消订阅第二窗口对应的视频流。本申请中，接收端在弱网环境时，可以对低优先级的窗口进行取消订阅的订阅策略调整，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二窗口取消订阅之后，上述第二设备还用于：在第二窗口上显示蒙层。通过显示蒙层，可以提醒用户当前处于弱网环境，提高用户体验。
在一种可能的实现方式中，在上述第二设备取消订阅第二窗口对应的视频流之后，上述第二设备还用于：在满足第二预设条件时，为第二窗口恢复订阅第二清晰度的视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，在上述第二设备取消订阅第二窗口对应的视频流之后，上述第二设备还用于：在满足第二预设条件预设时间段时，为第二窗口恢复订阅第二清晰度的视频流。例如，第二设备可以通过进行总带宽预测值监测以判断是否满足第二预设条件。例如，第二预设条件可以是最新的总带宽预测值满足第二窗口恢复以第二清晰度播放音视频流。本申请中，接收端可以根据实时带宽情况进行订阅策略调整。例如在满足恢复订阅的带宽需求时，恢复对被取消订阅的窗口对应的音视频流的订阅，以最大限度的保证视频的流畅度和/或清晰度。
在一种可能的实现方式中，上述第二设备还用于根据以下中的一个或多个确定上述多个窗口对应的优先级由第二设备：多个窗口对应的音频的初始音量；多个窗口对应的音频的播放音量；多个窗口中业务的功能。其中，音频的初始音量用于表征第二设备接收到音频流时，音频流的原始音量。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由第二设备自行根据多个窗口对应的初始/播放音频的音量和/或多个窗口中业务的功能确定多个窗口对应的优先级。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述第二设备还用于：根据用户的自定义指定操作确定多个窗口对应的优先级。在本申请中，可以支持多样化的窗口优先级设置。例如，可以由用户自定义。该多样化的窗口优先级设置可以方便用户多样化操作，提供用户的体验度。
在一种可能的实现方式中，上述一个或多个第三设备包括第一云端设备和第二云端设备，其中，第一云端设备用于向第二设备转发第一音视频流，第二云端设备用于向第二设备转发第二音视频流和第三音视频流。作为一种示例，本申请提供的多窗口视频通信方法可以适用于分布式的云端设备(即第三设备)转发音视频流的网络架构，以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
在一种可能的实现方式中，上述第三设备是SFU。通过该方案，可以提高本申请提供的方法的适用度和与不同网络架构的兼容性。
第五方面，提供一种通信系统，该通信系统包括：多个第一设备和如第二方面或第三方面任一种可能的实现方式中的电子设备。其中，上述多个第一设备向第二设备发送音视频流，用于分别在第二设备界面上的多个窗口中播放。该通信系统用于实现如第四方面任一种可能的实现方式中的方法。
在一种可能的实现方式中，上述通信系统还包括：一个或多个第三设备，用于将来自上述多个第一设备的音视频流转发至电子设备。
第六方面，提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序代码，该计算机程序代码被处理器执行时，使得处理器实现如第一方面任一种可能的实现方式中的方法。
第七方面，提供一种芯片系统，该芯片系统包括处理器、存储器，存储器中存储有计算机程序代码；所述计算机程序代码被所述处理器执行时，使得处理器实现如第一方面任一种可能的实现方式中的方法。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。
第八方面，提供一种计算机程序产品，该计算机程序产品包括计算机指令。当该计算机指令在计算机上运行时，使得计算机实现如第一方面任一种可能的实现方式中的方法。
附图说明
图1为本申请实施例提供的一种选择性转发单元(selective forwarding unit，SFU)转发方案示例图；
图2为本申请实施例提供的一种基于SFU抽帧的视频通信交互图；
图3为本申请实施例提供的一种分层编码示意图；
图4为本申请实施例提供的一种多窗口视频通信场景示例图；
图5A为本申请实施例提供的一种电子设备的硬件结构示意图；
图5B为本申请实施例提供的一种电子设备的软件架构图；
图6为本申请实施例提供的一种基于实时通信(real time communication，RTC)的通话业务架构示意图；
图7为本申请实施例提供的一种多窗口视频通信架构图；
图8为本申请实施例提供的一种多窗口视频通信方法流程图；
图9为本申请实施例提供的一种多窗口视频通信方法交互图；
图10为本申请实施例提供的三种多窗口显示示例图；
图11为本申请实施例提供的一种多窗口显示示例图；
图12为本申请实施例提供的一种弱网时显示蒙层的示例图；
图13为本申请实施例提供的另一种多窗口视频通信方法流程图；
图14为本申请实施例提供的一种弱网时显示弱网提示的示例图；
图15为本申请实施例提供的窗口对应的优先级的设置方法示例图一；
图16为本申请实施例提供的窗口对应的优先级的设置方法示例图二；
图17为本申请实施例提供的一种电子设备的结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。
以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
本申请实施例提供一种多窗口视频通信方法，该方法应用于多个用户进行多方实时视频通话的过程中。
作为一种示例，本申请实施例提供的一种多窗口视频通信方法可以应用于多方会议场景。例如，用户A、用户B和用户C加入会议进行多方实时视频通话，其中用户A是会议主讲人，用户B和用户C是会议参与者。
作为另一种示例，本申请实施例提供的一种多窗口视频通信方法可以应用于群视频聊天场景。例如，用户A、用户B和用户C加入群聊进行多方实时视频通话，其中在群聊过程中，用户A、用户B和用户C均进行随意发言。
作为另一种示例，本申请实施例提供的一种多窗口视频通信方法可以应用于网上教育场景。例如，用户A、用户B和用户C加入网课群组进行多方实时视频通话，其中用户A是老师，用户B和用户C是学生。用户A在授课讲解的同时，向用户B和用户C展示课件/白板等。
在例如上述多方会议场景、群视频聊天场景或网上教育场景等多窗口视频通信场景中，作为一种实现方案，发送端(如第一设备)可以通过第三设备(如云端设备)向接收端(如第二设备)转发音视频流。例如，第三设备可以基于音视频流的发布、订阅关系等，完成音视频流的转发。其中，第三设备支持端到端加密特性，无需解析发送端的音视频流。示例性的，发送端与接收端保存有密钥(例如公钥和私钥)，该密钥不被第三设备所知，因此第三设备无法解析用户的音视频流，安全性高。
示例性的，发送端可以通过选择性转发单元(selective forwarding unit，SFU)向接收端转发音视频流。在一些实施例中，多个SFU可以采用分布式部署，以提升网络的可扩展性。请参考图1，图1示出了一种SFU转发方案示例图。如图1所示，设备1和设备2分别选择SFU 1和SFU 2向设备4转发音视频流，设备3选择SFU3向设备4和设备5发送音视频流。
在一些实施例中，在SFU转发方案中，发送端可以自行选择最优的SFU进行音视频流转发。例如，发送端可以根据网络情况(如运营商、地区等)选择最优的SFU，本申请不限定。
进一步的，上述转发方案中，第三设备(如云端设备)在转发时还可以对转发音视频流的下行链路进行带宽预测，并将预测结果发送给接收端，用于接收端在网络较差时进行通信决策。
以视频分层编码为例，第三设备(如SFU)可以在网络较差时进行抽帧决策。其中，抽帧可以减少下行带宽消耗，避免网络拥塞，保障弱网环境下的音视频流畅度和/或清晰度。
请参考图2，图2以SFU通过带宽预测模块进行带宽预测为例，示出了一种基于SFU抽帧的视频通信交互图。如图2所示，基于SFU抽帧的视频通信过程主要可以包括以下五个步骤：
步骤1：发送端进行音视频数据的采集、编码和加密；
步骤2：发送端将帧数据、帧类型等发送至SFU；
步骤3：SFU的转发模块向接收端转发帧数据，同时SFU的带宽预测模块进行下行带宽预测；
步骤4：SFU根据带宽预测值进行抽帧决策；
步骤5：接收端接收到帧数据后，进行解密、解码和渲染。
在一些示例中，带宽预测模块进行带宽预测可以包括：带宽预测模块根据下行数据发送的时延、丢包等数据计算得来，下行的带宽预测值。关于下行带宽预测的具体方法，可以参考常规技术，本申请不做限定。
以分层编码为例，如图3所示，在对视频流中的连续动态图像帧编码时，连续的图像帧可以分别压缩成即时解码刷新(instantaneous decoding refresh，IDR)帧，前向预测编码帧(P帧)，双向预测内插编码帧(B帧)三种类型。其中，图3是以画面组(group ofpictures，GOP)＝30作为示例，其中，GOP即一组连续的画面。在一些实施例中，IDR帧压缩可以得到6：1而不产生任何可觉察的模糊现象。IDR帧压缩的同时使用P帧压缩，可以达到更高的压缩比而无可觉察的模糊现象。B帧压缩可以达到200：1的压缩比，其文件尺寸一般为IDR帧压缩尺寸的15％，不到P帧压缩尺寸的一半。其中，IDR帧压缩可以去掉图像的空间冗余度，P帧和B帧压缩可以去掉时间冗余度。
其中，IDR帧压缩采用全帧压缩编码，即将全帧图像信息进行联合图象专家组(joint photographic experts group，JPEG)压缩编码。IDR帧描述了图像背景和运动主体的详情，因此，IDR帧也叫关键帧。基于此，IDR帧可以独立进行解码和渲染。在解码视频流时，仅用IDR帧的数据就可重构完整图像。
IDR帧可以作为P帧和B帧的参考。例如，IDR帧可以在分别进行帧内预测、残差确定、残差变换和量化、变长编码和算术编码、重构图像和滤波之后，作为P帧和B帧的参考。其中，残差可以通过像素值减去预测值确定。
P帧是IDR帧后面相隔1～2帧的编码帧。P帧属于前向预测的帧间编码，因此它只参考前面最靠近它的IDR帧或P帧进行预测。例如，P帧采用运动补偿的方法，预测当前帧与前面最近的IDR帧或P帧的差别及运动矢量。在解码P帧时，必须将IDR帧中的预测值与预测误差求和后才能重构完整的P帧图像。如图3所示，P帧基于它前面的IDR帧预测而来。P帧可以是其后面P帧的参考帧，也可以是其前后的B帧的参考帧。
B帧为双向帧间编码。B帧从前面和后面的IDR帧或P帧中提取数据。B帧基于当前帧与前一帧和后一帧图像之间的差别进行压缩，完成解码和渲染。例如，B帧预测当前帧与前面的IDR帧或P帧和后面的P帧之间的预测误差及运动矢量。如图3所示，B帧基于它前面的IDR帧和P帧预测而来，或者基于它前后的P帧预测而来。B帧不被其他帧参考。
可以理解，在类似图3所示分层编码中，B帧不被其他帧参考，因此B帧的丢弃不会影响视频帧的参考关系。基于此，接收端在网络较差时，可以根据带宽预测值以及各种类型编码帧的带宽需求决策是否抽B帧。其中，B帧的剔除可以达到减少下行带宽负载的目的。
作为一种示例，在本申请实施例中，可以通过统计来自发送端的原始帧数据，以得到各种类型编码帧(如IDR帧、P帧和B帧)的带宽需求。
示例性的，以图4所示包括大窗口和小窗口的多窗口视频通信场景为例，以下表1示出了一种带宽需求示例。其中，大窗中播放高清视频，大窗中视频的分辨率是540P；小窗中播放普清视频，小窗中视频的分辨率是360P。
表1
Figure BDA0003194525480000121
如表1所示，图4所示大窗中播放的视频流在抽帧前所需带宽是700千比特每秒(kilobits per second，kbps)；在抽B帧之后所需带宽是400kbps。图4所示小窗1和小窗2中播放的视频流在抽帧前所需带宽是500kbps；在抽B帧之后所需带宽是300kbps。
其中，在本申请实施例中，音视频流所需带宽受编解码器(Codec)、上行带宽的码率控制、分层编码的层数、视频的分辨率/帧率等影响，本申请实施例不限定音视频流所需带宽的具体计算策略和具体算法。
请参考以下表2，表2示出了一种SFU抽帧策略示例。
表2
Figure BDA0003194525480000122
如表2所示，若预测的带宽满足IDR帧、P帧和B帧的带宽需求，即带宽预测值≥IDR帧所需带宽+P帧所需带宽+B帧所需带宽，则接收端决策不抽帧。
若预测的带宽满足抽B帧之后，IDR帧和P帧的带宽需求，但是不满足IDR帧、P帧和B帧的带宽需求，即IDR帧所需带宽+P帧所需带宽≤带宽预测值<IDR帧所需带宽+P帧所需带宽+B帧所需带宽，或者预测的带宽不满足IDR帧和P帧的带宽需求，即带宽预测值<IDR帧所需带宽+P帧所需带宽，则接收端决策抽B帧。
需要说明的是，对于带宽预测值<IDR帧所需带宽+P帧所需带宽的情况，即使抽B帧，预测的带宽仍然满足不了抽帧之后所需带宽，因此，抽帧之后仍然存在网络拥塞。网络拥塞会造成时延增加，从而导致音视频卡顿。
也就是说，以表1所示带宽需求为例，若采用表2所示SFU抽帧策略，如表3所示，当带宽预测值≥1700kbps时，预测的带宽可以满足3个窗口的最大所需带宽，对于这种情况，接收端决策不抽帧。当1000kbps≤带宽预测值<1700kbps时，预测的带宽虽然不满足3个窗口的最大所需带宽，但是可以满足3个窗口的最小所需带宽，对于这种情况，接收端决策抽B帧。当带宽预测值＜1000kbps时，预测的带宽不能满足3个窗口的最小所需带宽，对于这种情况，即使抽B帧，预测的带宽仍然满足不了抽帧之后所需带宽，因此，抽帧之后仍然存在图4所示大窗、小窗1和小窗2的音视频卡顿。
表3
Figure BDA0003194525480000131
基于上述示例，可以理解，在网络较差时，采用常规技术对于通信多方的处理是平等的。但是，由于不同多窗口视频通信场景的侧重点不同，例如多方会议场景需优先保障当前的主讲人(如声音音量值最大的人，又如图4所示大窗对应的用户)的视频和音频，其次为其他会议参与者；又如网上教育场景需优先保障课件/白板的流畅度和/或清晰度，其次为讲师的人像画面；因此采用上述常规技术，在网络较差时，接收端无法根据具体需求适应性处理，会导致重要的视频在弱网环境时出现卡顿。
以表3为例，当1000kbps≤带宽预测值＜1700kbps时，接收端决策对图4所示大窗、小窗1和小窗2均抽B帧，因此大窗、小窗1和小窗2中视频的流畅度均有所降低。又如，当带宽预测值＜1000kbps时，接收端决策对图4所示大窗、小窗1和小窗2均抽B帧，但是由于抽帧后预测带宽仍然不能满足3个窗口的最小所需带宽，因此3个窗口均存在网络拥塞。网络拥塞会造成时延增加，从而导致图4所示大窗、小窗1和小窗2均出现音视频卡顿的问题。
为解决上述问题，本申请实施例提供一种多窗口视频通信方法，该方法中，接收端在弱网环境时可以根据多个视频通话用户的具体业务场景和诉求调整终端数据流，以优先保障高优先级的视频流的正常播放。例如，在图4所示场景中，优先保障大窗中的视频流畅度和/或清晰度。又如，在网上教育场景中，优先保障课件/白板的视频流畅度和/或清晰度。
其中，在本申请实施例中，弱网是指带宽资源不足以满足音视频流的带宽需求。
示例性的，在下行带宽受限或带宽波动较大的场景，例如高铁场景、远离无线局域网(wireless local area networks，WLAN)(如WiFi网络)热点的场景、偏远地区或者人群密集区的带宽受限场景等，采用本申请实施例提供的方法，基于具体优先级对视频流进行降级订阅，可以细化视频流控制的梯度，在充分利用下行带宽的同时，避免网络拥塞，从而最大程度地保障视频的流畅度和/或清晰度。
本申请实施例提供的多窗口视频通信方法可以应用但不限于智能手机、上网本、平板电脑、智能手表、智能手环、电话手表、智能相机、掌上电脑、个人计算机(personalcomputer，PC)、个人数字助理(personal digital assistant，PDA)、便携式多媒体播放器(portable multimedia player，PMP)、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、电视机、投影设备或人机交互场景中的体感游戏机等。或者，该方法还可以应用于其他类型或结构的电子设备，本申请不限定。
请参考图5A，图5A以智能手机为例，示出了本申请实施例提供的一种电子设备的硬件结构示意图。如图5A所示，电子设备可以包括处理器510，存储器(包括外部存储器接口520和内部存储器521)，通用串行总线(universal serial bus，USB)接口530，充电管理模块540，电源管理模块541，电池542，天线1，天线2，移动通信模块550，无线通信模块560，音频模块570，扬声器570A，受话器570B，麦克风570C，耳机接口570D，传感器模块580，按键590，马达591，指示器592，摄像头593，显示屏594，以及用户标识模块(subscriberidentification module，SIM)卡接口595等。其中传感器模块580可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。
可以理解的是，本发明实施例示意的结构并不构成对电子设备的具体限定。在本申请另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器510可以包括一个或多个处理单元。例如：处理器510可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，飞行控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
处理器510中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器510中的存储器为高速缓冲存储器。该存储器可以保存处理器510刚用过或循环使用的指令或数据。如果处理器510需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器510的等待时间，因而提高了系统的效率。
在一些实施例中，处理器510可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。
充电管理模块540用于从充电器接收充电输入。电源管理模块541用于连接电池542，充电管理模块540与处理器510。电源管理模块541接收电池542和/或充电管理模块540的输入，为处理器510，内部存储器521，显示屏594，摄像组件593，和无线通信模块560等供电。
电子设备的无线通信功能可以通过天线1，天线2，移动通信模块550，无线通信模块560，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频段。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
移动通信模块550可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块550可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块550可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块550还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块550的至少部分功能模块可以被设置于处理器510中。在一些实施例中，移动通信模块550的至少部分功能模块可以与处理器510的至少部分模块被设置在同一个器件中。
在本申请实施例中，电子设备可以通过移动通信模块550与云端设备通信，例如发送音视频流等。
调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器570A、受话器570B等)输出声音信号，或通过显示屏594显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器510，与移动通信模块550或其他功能模块设置在同一个器件中。
在本申请实施例中，电子设备可以通过音频设备播放多个窗口对应的音频，通过显示屏594上的多个窗口播放对应的视频。
无线通信模块560可以提供应用在电子设备上的包括无线局域网(wirelesslocal area networks，WLAN)(如WiFi网络)，蓝牙BT，全球导航卫星系统(globalnavigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块560可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块560经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器510。无线通信模块560还可以从处理器510接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
在一些实施例中，电子设备的天线1和移动通信模块550耦合，天线2和无线通信模块560耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code divisionmultiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(globalnavigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigationsatellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。
电子设备通过GPU，显示屏594，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏594和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器510可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏594用于显示图像，视频等。显示屏594包括显示面板。在一些实施例中，电子设备可以包括1个或N个显示屏594，N为大于1的正整数。
在本申请实施例中，电子设备可以通过GPU进行多个窗口中视频的渲染，显示屏594用于通过多个窗口播放对应的视频。
电子设备可以通过ISP，摄像组件593，视频编解码器，GPU，显示屏594以及应用处理器等实现拍摄功能。
外部存储器接口520可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口520与处理器510通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
内部存储器521可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器521可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器521可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器510通过运行存储在内部存储器521的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备的各种功能应用以及数据处理。
电子设备可以通过音频模块570，扬声器570A，受话器570B，麦克风570C以及应用处理器等实现音频功能。例如音乐播放，录音等。关于音频模块570、扬声器570A、受话器570B和麦克风570C的具体工作原理和作用，以及按键590、马达591、指示器592和SIM卡接口595等的具体工作原理和作用，可以参考常规技术中的介绍。
需要说明的是，图5A所示电子设备包括的硬件模块只是示例性地描述，并不对电子设备的具体结构做出限定。例如，电子设备还可以包括其他功能模块。
以包括分层架构的Android系统的端侧设备(如发送端和接收端)为例，如图5B所示，电子设备的软件可以分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。如图5B所示，电子设备的软件结构从上至下可以分为三层：应用程序层(简称应用层)，应用程序框架层(简称框架层)，系统库，安卓运行时和内核层(也称为驱动层)。
其中，应用程序层可以包括一系列应用程序包，例如相机，图库，日历，通话，地图，导航，蓝牙，音乐，视频，短信息等应用程序。为方便描述，以下将应用程序简称为应用。如图5B所示，应用程序层还可以包括RTC软件开发工具包(software development kit，SDK)和通话SDK。
其中，通话应用主要用于完成用户界面(user interface，UI)和交互逻辑。通话SDK主要用于对接通信云，提供账号管理、联系人管理、信令通信等能力，完成音视频数据的采播、编解码，对接RTC SDK，完成通话过程中媒体流的互通等。RTC SDK主要用于负责与RTC云交互，以提供媒体流(如音视频流)的发送能力。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。如图5B所示，应用程序框架层可以包括窗口管理服务器(window manager service，WMS)，活动管理服务器(activity manager service，AMS)和输入事件管理服务器(input manager service，IMS)。在一些实施例中，应用程序框架层还可以包括内容提供器，视图系统，电话管理器，资源管理器，通知管理器等(图5B中未示出)。
系统库和安卓运行时包含FWK所需要调用的功能函数，Android的核心库，以及Android虚拟机。系统库可以包括多个功能模块。例如：浏览器内核，三维(3dimensional，3D)图形，字体库等。
系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。
内核层是硬件和软件之间的层。内核层可以包含显示驱动，输入/输出设备驱动(例如，键盘、触摸屏、耳机、扬声器、麦克风等)，设备节点，摄像头驱动，音频驱动以及传感器驱动等。用户通过输入设备进行输入操作，内核层可以根据输入操作产生相应的原始输入事件，并存储在设备节点中。输入/输出设备驱动可以检测到用户的输入事件。例如，用户通过拖动窗口设置窗口优先级的操作。
进一步的，如图5B所示，端侧设备(如接收端)还包括弱网决策模块和编/解码器。弱网决策模块用于根据预测带宽预测整体带宽，根据整体带宽和多个音视频流的带宽需求判定是否处于弱网环境的，在确定处于弱网环境时进行弱网决策与处理。
编/解码模块用于负责音视频流的解码工作。
需要说明的是，图5B仅以弱网决策模块和编/解码模块位于应用程序框架层作为示例。事实上，在本申请实施例中，弱网决策模块和编/解码模块可以位于端侧设备(如接收端)的任意软件架构层。例如，上述弱网决策模块和编/解码模块还可以位于端侧设备(如接收端)的应用程序层、内核层或系统库等软件架构层。
作为一种示例，本申请实施例提供的一种多窗口视频通信方法可以基于实时通信(real time communication，RTC)的通话业务架构实现。
请参考图6，图6示出了一种基于RTC的通话业务架构示意图。如图6所示，端侧设备通过云端设备进行通信。需要说明的是，图6以架构中包括2个端侧设备为例，但是本申请实施例不限定多窗口视频通信中端侧设备的具体数量。
如图6所示，云端设备包括通信云和RTC云。通信云包括账号服务器和信令服务器。RTC云包括RTC服务器和RTC SFU。
其中，账号服务器主要用于负责账号信息、联系人信息、推送(Push)信息的存储和信息维护等。信令服务器主要用于负责呼叫信息和通话控制信令的转发等。RTC服务器主要用于负责房间(Room)接入鉴权、SFU资源分配、路由策略和Room操作/交互等。RTC SFU主要用于负责媒体流的发布/订阅关系维护、媒体流(如音视频流)的转发和网络适应性等。
其中，端侧设备如发送端(如第一设备)或接收端(如第二设备)。如图6所示，端侧设备中安装有通话应用、通话SDK和RTC SDK。
其中，通话应用主要用于完成UI和交互逻辑。通话SDK主要用于对接通信云，提供账号管理、联系人管理、信令通信等能力，完成音视频数据的采播、编解码，对接RTC SDK，完成通话过程中媒体流的互通等。RTC SDK主要用于负责与RTC云交互，以提供媒体流(如音视频流)的发送能力。
如图6所示，端侧设备中还包括编/解码模块。示例性的，在端侧设备是发送端时，编码模块用于对音视频流进行编码；在端侧设备是接收端时，解码模块用于对音视频流进行解码。
作为一种示例，图6所示通话业务架构中RTC SFU的结构可以如图2所示SFU的结构。其中，RTC SFU可以包括转发模块和带宽预测模块。在本申请实施例中，转发模块用于进行音视频流的转发。带宽预测模块用于进行带宽预测。
如图6所示，为了实现本申请实施例提供的多窗口视频通信方法，端侧设备(如接收端)还包括弱网决策模块。弱网决策模块用于预测整体带宽(即预测带宽资源)，根据整体带宽和多个音视频流的带宽需求判定是否处于弱网环境的，在确定处于弱网环境时进行弱网决策与处理。关于弱网决策模块的具体作用，可以参考下文中的具体介绍。
以图6所示通话业务架构为例，请参考图7，图7示出了本申请实施例提供的一种多窗口视频通信架构图。
如图7所示，RTC SFU 1和RTC SFU 2分布式部署，以提升网络的可扩展性。图7所示各发送端可以自行选择最优的RTC SFU进行音视频流转发，例如根据网络情况(如运营商、地区等)选择最优的RTC SFU。例如，如图7所示，发送端A选择通过RTC SFU 1向接收端D发送音视频流1；发送端B和发送端C选择通过RTC SFU 2向接收端D分别发送音视频流2和音视频流3。
其中，图7所示RTC SFU 1的带宽预测模块根据下行数据(如图7所示音视频流1)进行带宽预测，以及向接收端D的弱网决策模块发送带宽预测结果。例如，带宽预测模块根据图7所示音视频流1发送的时延、丢包等数据计算得到带宽预测值1。同理，图7所示RTC SFU2的带宽预测模块根据图7所示音视频流2发送的时延、丢包等数据计算得到带宽预测值2，以及根据图7所示音视频流3发送的时延、丢包等数据计算得到带宽预测值3。
图7所示接收端D包括解码模块和弱网决策模块。其中，接收端D的解码模块用于对接收到的音视频流(如图7所示音视频流1&音视频流2&音视频流3)进行解码。作为一种示例，解码模块中可以包括多个解码器，该多个解码器用于分担音视频流的解码工作。例如解码模块包括解码器A、解码器B和解码器C，解码器A用于解码音视频流1，解码器B用于解码音视频流2，解码器C用于解码音视频流3。
图7所示弱网决策模块用于根据来自RTC SFU 1的带宽预测模块的带宽预测值1、来自RTC SFU 2的带宽预测模块的带宽预测值2和带宽预测值3进行整体带宽预测(即带宽资源预测)，得到总带宽预测值。进一步的，图7所示弱网决策模块还用于根据总带宽预测值和音视频流的带宽需求进行弱网判断，在确定处于弱网环境时优先对优先级较低的窗口中的视频进行降级订阅，以保障优先级较高的窗口中的视频的流畅播放。
示例性的，弱网决策模块对优先级较低的窗口中的视频进行降级订阅可以包括但不限于以下中的一种或多种：取消订阅、恢复订阅、延迟订阅、降低清晰度、提高清晰度等。
需要说明的是，上述图7仅以第三设备是SFU作为示例，本申请实施例不限定第三设备的具体结构、功能和形态等。例如，第三设备还可以是例如智能手机等电子设备。例如第三设备可以与第一设备、第二设备组成点对点(peer-to-peer，P2P)的网络架构，其中，第一设备、第二设备和第三设备均既可以作为发送端，也可以作为接收端。作为一种示例，在多窗口视频通信场景中，第三设备还可以作为转发设备，将来自第一设备的音视频流转发至第二设备。
以下将以图7所示多窗口视频通信架构为例，即以多个发送端(即第一设备)通过第三设备(如SFU)向接收端(即第二设备)发送音视频流为例，以接收端的显示界面包括如图4所示大窗、小窗1和小窗2为例，结合附图，对本申请实施例提供的一种多窗口视频通信方法进行具体介绍。
如图8所示，本申请实施例提供的多窗口视频通信方法可以包括以下步骤S801-S804：
S801、多个发送端(即第一设备)向第三设备(如SFU)发送音视频流。
其中，音视频流中除包括音视频信息外，还携带有接收端(如第二设备)的标识(identification，ID)，用于第三设备(如SFU)根据接收端的ID向接收端转发音视频流。进一步的，在一些实施例中，音视频流中携带的接收端的ID还用于SFU预测对应下行路径的下行带宽。
在本申请实施例中，音视频流中还携带有发送端的ID。
以图7所示多窗口视频通信架构为例，如图9所示，上述步骤S801具体可以包括：发送端A向RTC SFU 1发送音视频流1，发送端B和发送端C分别向RTC SFU 2发送音视频流2和音视频流3。其中，音视频流1、音视频流2和音视频流3中携带有发送端D的ID。进一步的，音视频流1中携带有发送端A的ID，音视频流2中携带有发送端B的ID，音视频流3中携带有发送端C的ID。
作为一种示例，本申请实施例中的音视频流中还可以携带有以下信息：流分辨率信息、帧率信息、编码Codec、流等级等。
示例性的，图9所示音视频流1、音视频流2和音视频流3中除了包括有音视频信息外，还携带有如以下表4所示信息：
表4
音视频流 发送端ID 流分辨率 帧率(FPS) 编码Codec 流等级
音视频流1 发送端A的ID 960P/540P 30 H.265编码 高清
音视频流2 发送端B的ID 640P/360P 20 H.265编码 普清
音视频流3 发送端C的ID 640P/360P 20 H.265编码 普清
需要说明的是，本申请实施例对多个发送端发送音视频流的具体顺序和时机等不作限定。例如，图7所示发送端A、发送端B和发送端C可以同时发送音视频流，也可以以任意时间顺序发送音视频流。
S802、第三设备(如SFU)向接收端(如第二设备)转发音视频流，预测下行带宽，并向接收端发送带宽预测结果。
以图7所示多窗口视频通信架构为例，如图9所示，上述步骤S802具体可以包括：RTC SFU 1向接收端D转发音视频流1，同时进行带宽预测得到带宽预测值1，并向接收端D发送带宽预测值1；RTC SFU 2向接收端D转发音视频流2，同时进行带宽预测得到带宽预测值2，并向接收端D发送带宽预测值2；RTC SFU 2向接收端D转发音视频流3，同时进行带宽预测得到带宽预测值3，并向接收端D发送带宽预测值3。例如，图9所示带宽预测值1、带宽预测值2和带宽预测值3均是500kbps。
示例性的，第三设备(如SFU)可以根据音视频流中携带的接收端的ID向接收端转发音视频流。
例如，图9所示RTC SFU 1可以根据来自发送端A的音视频流1中携带的接收端D的ID，向接收端D转发音视频流1；图9所示RTC SFU 2可以根据来自发送端B的音视频流2中携带的接收端D的ID，向接收端D转发音视频流2；以及RTC SFU 2根据来自发送端C的音视频流3中携带的接收端D的ID，向接收端D转发音视频流3。
进一步的，在一些实施例中，第三设备(如SFU)可以根据音视频流中携带的接收端的ID，预测对应下行路径的下行带宽。
其中，在本申请实施例中，多个发送端通过第三设备(如SFU)向接收端转发的音视频流对应的音频和视频分别在接收端显示屏上显示的多个窗口中播放。
请参考图10，图10示出了几种多窗口显示示例图。其中，图10中的(a)和图10中的(b)示出了多窗口视频通信场景(如多方会议场景或群视频聊天场景)下，接收端的多窗口显示界面。图10中的(c)示出了网上教育场景下，接收端的多窗口显示界面。
需要说明的是，图10仅示出了与本申请相关的窗口，在一些示例中，接收端界面上还可以显示有功能键、菜单栏、导航键/栏等，本申请不限定。
以图7所示接收端D的显示界面包括如图4所示大窗、小窗1和小窗2为例，图7所示发送端A、发送端B和发送端C分别向接收端D发送的音视频流1、音视频流2和音视频流3用于分别在接收端D的大窗、小窗1和小窗2中播放。
进一步的，在一些实施例中，SFU还可以向接收端发送带宽需求。例如，图9所示音视频流1、音视频流2和音视频流3所需带宽分别为600kbps、500kbps和500kbps。
进一步的，在一些实施例中，例如对于可抽帧的视频编码方式，第三设备(如SFU)还可以向接收端发送抽帧状态和对应的带宽需求。其中，抽帧状态用于表征视频编码方式抽帧还是不抽帧。例如，图9所示音视频流1、音视频流2和音视频流3的抽帧状态信息和对应的带宽需求如以下表5所示：
表5
音视频流 抽帧状态 带宽需求
音视频流1 不抽帧 400kbps
音视频流2 抽帧 300kbps
音视频流3 抽帧 300kbps
S803、接收端根据来自一个或多个第三设备(如SFU)的带宽预测结果，得到总带宽预测值。
其中，总带宽预测值的大小可以用于表征带宽资源的多少。例如，总带宽预测值越大，则说明带宽资源越充足；总带宽预测值越小，则说明带宽资源越少。
以图7所示多窗口视频通信架构为例，如图9所示，上述步骤S803具体可以包括：接收端D根据来自RTC SFU 1的带宽预测值1，来自RTC SFU 2的带宽预测值2和带宽预测值3，得到总带宽预测值。
作为一种示例，总带宽预测值＝带宽预测值1+带宽预测值2+带宽预测值3。例如，假设图9所示带宽预测值1、带宽预测值2和带宽预测值3均是500kbps，则可以得到总带宽预测值是1500kbps。
需要说明的是，本申请不限定接收端根据来自一个或多个SFU的带宽预测结果，得到总带宽预测值的具体算法，关于这部分内容，可以参考常规技术中的计算方法。
S804、在根据总带宽预测值确定弱网时，接收端根据多个窗口对应的优先级，调整对一个或多个窗口中音视频流的订阅策略。
以图7所示多窗口视频通信架构为例，如图9所示，上述步骤S804具体可以包括：在根据总带宽预测值确定弱网时，接收端D根据大窗、小窗1和小窗2对应的优先级，调整对大窗、小窗1和小窗2中一个或多个窗口中音视频流的订阅策略。
可以理解，在本申请实施例中，为了优先保证重要视频的播放流畅度和/或清晰度，接收端显示屏上的多个窗口可以具有优先级属性。
其中，窗口对应的优先级用于表征窗口中播放的视频对接收端的用户的重要程度。例如，相对重要的窗口的优先级高于相对次要的窗口的优先级。
例如，图11所示多窗口视频通信场景的显示界面上，大窗以较高分辨率(540P)播放高清视频，小窗1和小窗2以较低分辨率(360P)播放普清视频。则可以理解，大窗中播放的视频相比于小窗1和小窗2中播放的视频而言，对用户更加重要。因此，图11所示大窗的优先级高于小窗1和小窗2。
需要说明的是，本申请上述示例仅以高清视频对应的分辨率为540P，普清视频对应的分辨率为360P作为示例，本申请并不限定不同清晰度视频的具体清晰度的规定。
又如，图10中的(c)所示多窗口视频通信场景的显示界面上，课件/白板/屏幕共享窗口是网上教育的核心，而讲师人像相对而言不重要。因此，课件/白板/屏幕共享窗口对应的优先级高于讲师人像所在的窗口。关于优先级的具体确定方法，将在下文中介绍。
其中，在本申请实施例中，弱网是指当前网络环境下，带宽资源不足以满足音视频流的带宽需求。示例性的，弱网是指当前网络环境下，接收端得到的总带宽预测值(例如300kbps-1000kbps)小于音视频流所需的带宽值(如1200kbps)。
可以理解，相比于视频流，音频流所需的通信资源很少，因此，在本申请实施例中，还可以仅基于视频流的带宽需求判定是否处于弱网环境。
以基于视频流的带宽需求判定是否处于弱网环境为例，在一些实施例中，例如对于不抽帧的视频编码方式，弱网是指当前网络环境下，带宽资源不足以满足视频流抽帧前的带宽需求。
例如，接收端D上显示的大窗对应的视频流抽帧前所需的带宽是700kbps，小窗1和小窗2对应的视频流抽帧前所需的带宽是500kbps，则视频流所需的总带宽值是700kbps+500kbps+500kbps＝1700kbps。假设总带宽预测值是1500kbps，由于总带宽预测值1500kbps小于视频流所需的总带宽值，因此接收端可以确定当前处于弱网环境。
在另一些实施例中，例如对于抽帧的视频编码方式，弱网是指当前网络环境下，带宽资源不足以满足视频流抽帧后的带宽需求。
例如，接收端D上显示的大窗对应的视频流抽帧后所需的带宽是400kbps，小窗1和小窗2对应的视频流抽帧前所需的带宽是300kbps，则视频流所需的总带宽值是400kbps+300kbps+300kbps＝1000kbps。假设总带宽预测值是900kbps，由于总带宽预测值900kbps小于视频流所需的总带宽值，因此接收端可以确定处于弱网环境。
需要说明的是，本申请实施例是以分层编码作为示例，对于其他视频编码方式，本申请实施例提供的多窗口视频通信方法同样适用。以及，本申请实施例是以IDR帧+P帧+B帧，或者IDR帧+P帧的分层编码作为示例，对于其他分层编码类型，本申请实施例提供的多窗口视频通信方法同样适用。
作为一种示例，在本申请实施例中，接收端调整订阅策略可以包括但不限于以下中的一种或多种：取消订阅、恢复订阅、延迟订阅、降低清晰度、提高清晰度等。
在一些实施例中，接收端调整订阅策略时，可以仅对视频流进行订阅策略调整，保持音频流的正常播放，以保证用户正常的语音沟通和交流，确保用户的体验。
以对视频流进行订阅策略调整为例，其中，取消订阅是指取消订阅对应视频流，以取消窗口中的视频显示。恢复订阅是指恢复订阅对应视频流，以恢复窗口中的视频显示。延迟订阅是指延迟订阅对应视频流，以延迟窗口中的视频显示。降低清晰度是指为窗口订阅降低清晰度后的视频流，例如从订阅高清视频流切换为订阅普清视频流。提高清晰度是指为窗口订阅提高清晰度后的视频流，例如从订阅普清视频流切换为订阅高清视频流。
以下以接收端的显示界面包括m个窗口(m≥3，m为整数)，m个窗口均显示高清视频为例，具体举例说明接收端根据多个窗口对应的优先级进行取消订阅、恢复订阅、延迟订阅、降低清晰度或提高清晰度的过程。需要说明的是，本申请实施例不限定接收端的显示界面上的窗口数量，例如，接收端的显示界面上还可以包括2个窗口。
(1)、降低清晰度
示例性的，假设接收端的显示界面包括窗口W1、W2……Wm(其中m表示窗口对应的优先级)，窗口W1、W2……Wm中，W1对应的优先级最高，W2对应的优先级次之，Wm对应的优先级最低，若带宽资源不足以满足保持窗口W1、W2……Wm以当前清晰度显示的带宽需求，但是满足保持窗口W1、W2……Wm-1以当前参数显示且窗口Wm降低清晰度显示的带宽需求，则接收端决策为窗口Wm订阅降低清晰度后的视频流，以保证高优先级窗口(如窗口W1、W2……Wm-1)中视频的清晰度。例如，接收端决策由为窗口订阅第一清晰度的音视频流，降低为窗口订阅第二清晰度的音视频流。其中，第二清晰度小于第一清晰度。
例如，假设当前窗口W1、W2……Wm均显示高清视频(即第一清晰度的视频)，RW1/高清+RW2/高清+……+RWm/高清＞总带宽预测值≥RW1/高清+RW2/高清+……+RWm/普清，则接收端决策降低窗口Wm中视频的清晰度，以保证窗口W1、W2……Wm-1中视频的高清显示。即，接收端决策为窗口Wm订阅普清视频流(即第二清晰度的视频流)。其中，RW1、RW2……RWm分别是窗口W1、W2……Wm的带宽需求。示例性的，高清视频的分辨率可以是540P，普清视频的分辨率可以是360P。
在一些实施例中，在接收端降低窗口Wm中视频的清晰度后，若RW1/高清+RW2/高清+……+RWm-1/高清+RWm/普清＞总带宽预测值≥RW1/高清+RW2/高清+……+RWm-1/普清+RWm/普清，则接收端可以进一步决策为窗口Wm-1订阅普清视频流(即第二清晰度的视频流)，从而降低窗口Wm-1中视频的清晰度，以保证窗口W1、W2……Wm-2中视频的高清显示，以此类推。
在另一些实施例中，在接收端降低窗口Wm中的视频清晰度后，若RW1/高清+RW2/高清+……+RWm-1/高清+RWm/普清＞总带宽预测值≥RW1/高清+RW2/高清+……+RWm-1/普清+RWm/普清，接收端还可以进一步决策取消为窗口Wm订阅视频流，从而取消窗口Wm中的视频显示，以保证窗口W1、W2……Wm-2中视频的高清显示。
需要说明的是，上述举例仅以清晰度包括高清和普清两档作为示例，本申请并不限定清晰度的设定规则，例如，清晰度还可能包括超清、高清和普清三档，对于这种情况，在一些实施例中，在降低清晰度时，可以按照超清→高清→普清的梯度依次降低。
(2)、取消订阅
示例性的，假设接收端的显示界面包括窗口W1、W2……Wm(其中m表示窗口对应的优先级)，若带宽资源不足以满足保持窗口W1、W2……Wm以当前清晰度显示的带宽需求，但是满足保持窗口W1、W2……Wm-1以当前参数显示且窗口Wm不显示视频的带宽需求，则接收端决策取消为优先级最低的窗口Wm订阅视频流，从而取消优先级最低的窗口中视频的显示，以保证其他窗口以第一清晰度显示。。
例如，接收端决策由为优先级最低的窗口订阅第二清晰度的音视频流，改为取消为该窗口订阅视频流(即取消为该窗口订阅视频流)。其中，第二清晰度小于或等于预设值。
例如，假设当前窗口W1、W2……Wm-1均显示高清视频，窗口Wm显示普清视频(即第二清晰度的视频)，若RW1/高清+RW2/高清+……+RWm普清＞总带宽预测值，则接收端决策取消为窗口Wm订阅视频流，从而取消窗口Wm中的视频显示，以保证窗口W1、W2……Wm-1中视频的高清显示。在一些实施例中，在接收端取消为窗口Wm订阅视频流后，若RW1/高清+RW2/高清+……+RWm-1/高清＞总带宽预测值≥RW1/高清+RW2/高清+……+RWm-1/普清，则接收端可以进一步决策为窗口Wm-1订阅降低清晰度后(如普清)的视频流，从而降低窗口Wm-1中视频的清晰度，或者，接收端也可以进一步决策取消为窗口Wm-1订阅视频流，以保证窗口W1、W2……Wm-2中视频的高清显示，以此类推。
作为一种实现方式，在本申请实施例中，取消订阅的窗口可以显示取消订阅前的最后一帧图像。
作为另一种实现方式，在本申请实施例中，取消订阅的窗口可以显示蒙层。例如，图12示出了处于弱网环境时，优先级较低(优先级为2)的小窗2取消订阅后，窗口中显示蒙层的示例。
作为另一种实现方式，在本申请实施例中，取消订阅的窗口可以在取消订阅前的最后一帧图像上叠加显示蒙层。
需要说明的是，在本申请实施例中，为了维持第三设备(如SFU)对下行传输的带宽预测，至少要保证窗口W1、W2……Wm中至少一个窗口中视频的显示。例如，至少要保证窗口W1中的视频以最低清晰度显示。
需要说明的是，本申请不限定处于弱网环境时，接收端设备所采取的对音视频流订阅的具体调整策略。在带宽资源不足以满足所有窗口保持视频流以第一清晰度显示的带宽需求，但是满足取消优先级最低的窗口中的视频显示后，其他窗口以第一清晰度显示所需带宽，则接收端也可以决策取消为优先级最低的窗口订阅视频流，从而取消优先级最低的窗口中视频的显示，以保证其他窗口以第一清晰度显示。
例如，假设当前窗口W1、W2……Wm均显示高清视频，若RW1/高清+RW2/高清+……+RWm/高清＞总带宽预测值，则接收端决策取消为窗口Wm订阅视频流，从而取消窗口Wm中的视频显示，以保证窗口W1、W2……Wm-1中视频的高清显示。
(3)、恢复订阅
在一些实施例中，若接收端经过总带宽预测值监测(即带宽资源监测)，确定最新的总带宽预测值满足已取消订阅的窗口中，优先级最高的窗口恢复订阅且其他窗口保持当前显示的带宽需求(即第二预设条件)，则接收端决策恢复为已取消订阅的窗口中，优先级最高的窗口订阅视频流，以恢复对应视频的显示。
在另一些实施例中，若接收端经过总带宽预测值监测(即带宽资源监测)，确定在预设时间内(如6秒)，最新的总带宽预测值满足已取消订阅的窗口中，优先级最高的窗口恢复订阅且其他窗口保持当前显示的带宽需求，则接收端决策恢复为已取消订阅的窗口中，优先级最高的窗口订阅视频流，以恢复对应视频的显示。
例如，假设当前窗口W1、W2……Wm-1均显示高清视频(即第一清晰度的视频)，窗口Wm不显示视频，若接收端经过总带宽预测值监测，确定连续6秒内，总带宽预测值≥RW1/高清+RW2/高清+……+RWm普清，则接收端决策恢复为窗口Wm订阅视频流，以恢复窗口Wm中的视频显示。例如，接收端决策恢复为窗口Wm订阅第二清晰度的视频。
又如，假设当前窗口W1、W2……Wm-2均显示高清视频(即第一清晰度的视频)，窗口Wm-1和Wm不显示视频，若接收端经过总带宽预测值监测，确定连续6秒内，RW1/高清+RW2/高清+……+RWm-1普清+RWm普清＞总带宽预测值≥RW1/高清+RW2/高清+……+RWm-1普清，则接收端决策恢复为窗口Wm-1订阅视频流，以恢复窗口Wm-1中的视频显示，但是窗口Wm的状态仍然是取消订阅。
(4)、延迟订阅
延迟订阅是指在优先级高于某一窗口的窗口处于取消订阅的状态时，延迟为该窗口订阅视频流，以延迟恢复该窗口中的视频显示。
例如，假设当前窗口W1、W2……Wm-2均显示高清视频，窗口Wm-1和Wm不显示视频，则在窗口Wm-1未恢复订阅之前，窗口Wm的状态仍然是取消订阅。
(5)、提高清晰度
在一些实施例中，在降低清晰度之后，若接收端经过总带宽预测值监测(即带宽资源监测)，确定最新的总带宽预测值满足多个已被降低清晰度的窗口中，优先级最高的窗口提高清晰度显示且其他窗口保持当前显示的带宽需求(即第一预设条件)，则接收端决策提高多个已被降低清晰度的窗口中，优先级最高的窗口中视频的清晰度，以保证高优先级窗口中视频的清晰度。
在另一些实施例中，在降低清晰度之后，若接收端经过总带宽预测值监测(即带宽资源监测)，确定在预设时间内(如6秒)，最新的总带宽预测值满足多个已被降低清晰度的窗口中，优先级最高的窗口提高清晰度显示且其他窗口保持当前显示的带宽需求，则接收端决策提高多个已被降低清晰度的窗口中，优先级最高的窗口中视频的清晰度，以保证高优先级窗口中视频的清晰度。
例如，假设当前窗口W1、W2……Wm-1均显示高清视频(即第一清晰度的视频)，窗口Wm显示普清视频(即第二清晰度的视频)，若接收端经过总带宽预测值监测，确定连续6秒内，总带宽预测值≥RW1/高清+RW2/高清+……+RWm-1高清，则接收端决策提高窗口Wm-1的清晰度，例如由普清显示(即以第二清晰度显示)切换为高清显示(即以第一清晰度显示)。
又如，假设当前窗口W1、W2……Wm-2均显示高清视频(即第一清晰度的视频)，窗口Wm-1和Wm显示普清视频(即第二清晰度的视频)，若接收端经过总带宽预测值监测，确定连续6秒内，RW1/高清+RW2/高清+……+RWm-1高清+RWm高清＞总带宽预测值≥RW1/高清+RW2/高清+……+RWm-1高清，则接收端决策提高窗口Wm-1的清晰度，例如由普清显示(即以第二清晰度显示)切换为高清显示(即以第一清晰度显示)，但是窗口Wm仍显示普清视频(即第二清晰度的视频)。
需要说明的是，上述(1)-(5)仅作为几种订阅策略调整示例，在一些实施例中，接收端可以根据多个窗口对应的优先级，调整多个窗口中音视频流的订阅策略。
例如，接收端可以决策在为窗口Wm取消订阅的同时，降低窗口Wm-1中视频的清晰度(例如由第一清晰度显示切换为第二清晰度显示。)
又如，接收端可以决策在降低窗口Wm中视频的清晰度的同时，降低窗口Wm-1中视频的清晰度。例如由第一清晰度显示切换为第二清晰度显示。
同样，在网络好转时，接收端可以决策在恢复窗口Wm以第二清晰度显示的同时，提高窗口Wm-1中视频的清晰度(例如由第二清晰度显示切换为第一清晰度显示。)
又如，在网络好转时，接收端可以决策在提高窗口Wm中视频的清晰度的同时，提高窗口Wm-1中视频的清晰度。例如由第二清晰度显示切换为第一清晰度显示。
进一步的，接收端在确定对一个或多个窗口中音视频流的订阅策略之后，如图13所示，本申请实施例提供的方法还包括步骤S805：
S805、接收端根据最新订阅策略向多个发送端订阅音视频流。
以图7所示多窗口视频通信架构为例，如图9所示，上述步骤S801具体可以包括：接收端D根据确定的最新订阅策略向发送端A、发送端B和发送端C订阅音视频流。
例如，接收端可以向第三设备发送以下信息，以请求第三设备向第一设备订阅对应音视频流：发送端的标识(ID)、窗口对应的优先级、原订阅参数、目标订阅参数、窗口标识(Surface ID)。
示例性的，假设接收端确定由为窗口Wm订阅高清视频流，切换为为窗口Wm订阅普清视频流，其中窗口Wm对应的音视频流的发送端是发送端A，窗口Wm对应的优先级是3，则接收端可以向第三设备发送以下信息，以请求第三设备向第一设备订阅对应参数的音视频流：发送端A的ID、3(优先级)、高清(原订阅参数)、普清(目标订阅参数)、窗口Wm的ID。
需要说明的是，本申请上述图8和图9所示实施例仅以第三设备(如SFU)预测下行带宽以及向接收端发送带宽预测结果作为示例，本申请不限定负责下行带宽预测的具体设备。例如，在本申请实施例中，接收端(即第二设备)还可以在接收多个音视频流的过程中，测量得到对多条链路的带宽预测结果。其中，上述多条链路与多个音视频流对应。例如，上述多条链路分别用于传输上述多个音视频流。
作为另一种实现方式，在本申请实施例中，若由于处于弱网环境导致有窗口降低清晰度、取消订阅或延迟订阅等，电子设备显示屏上可以显示提示信息，以提示用户当前网络较差。例如，图14示出了处于弱网环境时，优先级较低(优先级为2)的小窗2取消订阅后，显示弱网提示的示例。
在本申请实施例中，窗口对应的优先级可以由用户指定，也可以由电子设备自行确定，以下将结合附图，举例介绍几种窗口对应的优先级的确定方法：
(a)、窗口对应的优先级由用户指定。
示例性的，作为一种实现方式，用户可以通过改变窗口的尺寸，以进行优先权自定义设置。例如，将小窗增大为大窗，以提高窗口对应的优先级。如图15所示，图15中的(a)所示窗口A、窗口B、窗口C和窗口D的优先级均为2，响应于用户将窗口A拉伸为大窗的操作1401，如图15中的(b)所示，电子设备在屏幕中间显示大窗口D，以及电子设备将窗口D对应的优先级设置为1。
作为另一种实现方式，用户可以通过拖动窗口，以改变窗口的排序，以进行优先权自定义设置。例如，将窗口拖动至屏幕中间，以提高窗口对应的优先级。如图16所示，图16中的(a)所示窗口B、窗口C和窗口D的优先级均为2，响应于用户将窗口D拖动至屏幕中间的操作1501，如图16中的(b)所示，电子设备在屏幕中间显示窗口D，以及电子设备将窗口D对应的优先级设置为1。
需要说明的是，本申请实施例不对用户指定窗口对应的优先级的具体方式和方法。例如，用户还可以在菜单中设置窗口的优先级。
(b)、窗口对应的优先级由电子设备根据多个窗口对应的音频的音量确定。
作为一种实现方式，电子设备可以根据多个窗口对应的音频的初始音量确定窗口对应的优先级。其中，音频的初始音量用于表征电子设备接收到音频流时，音频流的原始音量。
可以理解，多个用户进行多方实时视频通话的时候，当前发言人的音量通常是比较大的。例如在多方会议场景中，当前会议主讲人的音量通常是比较大的。又如在群视频聊天场景中，当前说话的用户的音量通常是比较大的。因此，在本申请实施例中，电子设备可以根据多个窗口对应的音频的初始音量适应性调整窗口对应的优先级。
作为另一种实现方式，电子设备可以根据多个窗口对应的音频的播放音量确定窗口对应的优先级。
可以理解，在多个用户进行多方实时视频通话的时候，接收端的用户可以根据其关注点和兴趣点个性化设置不同窗口对应的音频的播放音量。例如对用户最关注的窗口，用户可以将播放音量调高，而对于用户不关注的窗口，用户可以将播放音量调低。基于此，在本申请实施例中，电子设备可以根据多个窗口对应的音频的播放音量适应性调整窗口对应的优先级。
(c)、窗口对应的优先级由电子设备根据多个窗口中业务的功能确定。
以图10中的(c)所示网上教育场景为例，图10中的(c)所示界面包括课件/白板/屏幕共享窗口和讲师人像所在的窗口，其中，课件/白板/屏幕共享窗口用于显示课件/白板或者展示共享界面，讲师人像所在的窗口用于实时播放讲师视频。可以理解，网上教育的核心功能在于课堂内容的展示，讲师人像是否流畅、清晰不会影响课堂内容的获取，因此，课件/白板/屏幕共享窗口对应的优先级高于讲师人像所在的窗口。
需要说明的是，上述电子设备根据多个窗口对应的音频的音量或多个窗口中业务的功能确定窗口对应的优先级仅作为两种示例，本申请实施例对于电子设备确定窗口对应的优先级的具体规则和方法不做限定。例如，窗口对应的优先级还可以由电子设备根据多个窗口中视频的属性等其他因素确定。
在本申请实施例提供的方法中，在不同的业务场景下或者不同的用户需求下，多个窗口可以对应不同的优先级。电子设备可以在下行带宽受限或带宽波动较大时，基于具体优先级对视频流进行降级订阅，例如降低视频清晰度、取消订阅视频流或延迟订阅视频流等，以避免网络拥塞，同时保证高优先级的视频的流畅度和/或清晰度。
进一步的，在电子设备确定网络情况好转时，可以恢复被取消订阅的视频(即恢复订阅)或者恢复被降级订阅的视频的清晰度(即提高清晰度)，以最大程度地保障多个窗口中视频播放的流畅度和/或清晰度。
应理解，本申请实施例的各个方案可以进行合理的组合使用，并且实施例中出现的各个术语的解释或说明可以在各个实施例中互相参考或解释，对此不作限定。
还应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
可以理解的是，电子设备(如第一设备、第二设备或第三设备)为了实现上述任一个实施例的功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以对电子设备(如第一设备、第二设备或第三设备)进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
比如，以采用集成的方式划分各个功能模块的情况下，如图17所示，为本申请实施例提供的一种电子设备的结构框图。例如，该电子设备可以是第一设备、第二设备或第三设备。如图17所示，该电子设备可以包括收发单元1710、处理单元1720和存储单元1730。
其中，在电子设备为第二设备时，收发单元1710用于支持第二设备接收来自多个第一设备的音视频流。例如，收发单元1710用于支持第二设备接收第三设备转发的，来自多个第一设备的音视频流。在一些实施例中，收发单元1710还可以用于支持第二设备从第三设备接收多个音视频流对应的带宽预测值。进一步的，收发单元1710还可以用于支持第二设备向第一设备订阅音视频流，和/或与本申请实施例相关的其他过程。
处理单元1720用于支持第二设备根据多个带宽预测结果得到总带宽预测值，根据总带宽预测值确定处于弱网环境，以及调整对一个或多个窗口中音视频流的订阅策略。在一些实施例中，处理单元1720还用于支持第二设备测量多个音视频流对应的带宽预测结果，和/或与本申请实施例相关的其他过程。
存储单元1730用于存储计算机程序和实现本申请实施例提供的方法中的处理数据和/或处理结果等。
需要说明的是，上述收发单元1710可以包括射频电路。具体的，电子设备可以通过射频电路进行无线信号的接收和发送。通常，射频电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器、双工器等。此外，射频电路还可以通过无线通信和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统、通用分组无线服务、码分多址、宽带码分多址、长期演进、电子邮件、短消息服务等。
应理解，电子设备中的各个模块可以通过软件和/或硬件形式实现，对此不作具体限定。换言之，电子设备是以功能模块的形式来呈现。这里的“模块”可以指特定应用集成电路ASIC、电路、执行一个或多个软件或固件程序的处理器和存储器、集成逻辑电路，和/或其他可以提供上述功能的器件。
在一种可选的方式中，当使用软件实现数据传输时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地实现本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线((digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如软盘、硬盘、磁带)、光介质(例如数字化视频光盘(digital video disk，DVD))、或者半导体介质(例如固态硬盘solid state disk(SSD))等。
结合本申请实施例所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于电子设备中。当然，处理器和存储介质也可以作为分立组件存在于电子设备中。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

Claims (20)

1.一种通信系统，其特征在于，所述通信系统包括：
多个第一设备，用于：向所述第二设备发送多个音视频流，所述多个音视频流对应的音频和视频分别在所述第二设备界面上的多个窗口中播放；
第二设备，用于：确定带宽资源不足以满足所述多个音视频流的带宽需求；
根据所述多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略。
2.根据权利要求1所述的通信系统，其特征在于，所述通信系统还包括：一个或多个第三设备；
所述一个或多个第三设备用于：从所述多个第一设备接收所述多个音视频流；
向所述第二设备转发所述多个音视频流。
3.根据权利要求2所述的通信系统，其特征在于，所述一个或多个第三设备还用于：在向所述第二设备转发来自所述多个第一设备的多个音视频流的过程中，测量得到对多条链路的多个带宽预测结果，所述多条链路与所述多个音视频流对应；
所述第二设备用于：根据所述多个带宽预测结果确定所述带宽资源不足以满足所述多个音视频流的带宽需求。
4.根据权利要求1所述的通信系统，其特征在于，所述第二设备还用于：在接收所述多个音视频流的过程中，测量得到对多条链路的多个带宽预测结果，所述多条链路与所述多个音视频流对应；
所述第二设备用于：根据所述多个带宽预测结果确定所述带宽资源不足以满足所述多个音视频流的带宽需求。
5.根据权利要求1-4中任一项所述的通信系统，其特征在于，所述第二设备用于：
所述第二设备根据所述多个窗口对应的优先级，降低一个或多个窗口对应的视频流的清晰度和/或取消订阅一个或多个窗口对应的视频流。
6.一种多窗口视频通信方法，其特征在于，所述方法包括：
所述第二设备接收分别来自多个第一设备的多个音视频流，所述多个音视频流对应的音频和视频分别在所述第二设备界面上的多个窗口中播放；
所述第二设备确定带宽资源不足以满足所述多个音视频流的带宽需求；
所述第二设备根据所述多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略。
7.根据权利要求6所述的方法，其特征在于，所述第二设备接收分别来自所述多个第一设备的多个音视频流，包括：
所述第二设备接收第三设备转发的，分别来自所述多个第一设备的多个音视频流。
8.根据权利要求7所述的方法，其特征在于，所述方法还包括：
所述第二设备从所述第三设备接收对多条链路的多个带宽预测结果，所述多条链路与所述多个音视频流对应；
所述第二设备确定所述带宽资源不足以满足所述多个音视频流的带宽需求，包括：
所述第二设备根据所述多个带宽预测结果确定所述带宽资源不足以满足所述多个音视频流的带宽需求。
9.根据权利要求6或7所述的方法，其特征在于，所述方法还包括：
所述第二设备测量得到对多条链路的带宽预测结果，所述多条链路与所述多个音视频流对应；
所述第二设备确定所述带宽资源不足以满足所述多个音视频流的带宽需求，包括：
所述第二设备根据所述多个带宽预测结果确定所述带宽资源不足以满足所述多个音视频流的带宽需求。
10.根据权利要求6-9中任一项所述的方法，其特征在于，第一窗口以第一清晰度播放对应音视频流，所述第一窗口是所述多个窗口中优先级最低的窗口；
所述第二设备根据所述多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略，包括：
所述第二设备为所述第一窗口订阅第二清晰度的音视频流，所述第二清晰度小于所述第一清晰度。
11.根据权利要求10所述的方法，其特征在于，在所述第二设备为所述第一窗口订阅第二清晰度的音视频流之后，所述方法还包括：
在满足第一预设条件时，所述第二设备为所述第一窗口订阅所述第一清晰度的音视频流。
12.根据权利要求6-9中任一项所述的方法，其特征在于，第二窗口以第二清晰度播放音视频流，所述第二清晰度小于或等于预设值，所述第二窗口是所述多个窗口中、优先级最低的窗口，所述第二设备根据所述多个窗口对应的优先级调整对一个或多个窗口中音视频流的订阅策略，包括：
所述第二设备取消订阅所述第二窗口对应的视频流。
13.根据权利要求12所述的方法，其特征在于，在所述第二设备取消订阅所述第二窗口对应的视频流之后，所述方法还包括：
所述第二设备在所述第二窗口上显示蒙层。
14.根据权利要求12或13所述的方法，其特征在于，在所述第二设备取消订阅第二窗口对应的视频流之后，所述方法还包括：
在满足第二预设条件时，所述第二设备为所述第二窗口恢复订阅所述第二清晰度的视频流。
15.根据权利要求6-14中任一项所述的方法，其特征在于，所述多个窗口对应的优先级由所述第二设备根据以下中的一个或多个确定：
所述多个窗口对应的音频的初始音量；所述音频的初始音量用于表征所述第二设备接收到所述音频流时，所述音频流的原始音量；
所述多个窗口对应的音频的播放音量；
所述多个窗口中业务的功能。
16.根据权利要求6-14中任一项所述的方法，其特征在于，所述多个窗口对应的优先级由所述第二设备根据用户的自定义指定操作确定。
17.根据权利要求7-16中任一项所述的方法，其特征在于，所述第三设备是选择性转发单元SFU。
18.一种电子设备，其特征在于，所述电子设备包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序，使得所述电子设备实现如权利要求6-17中任一项所述的方法。
19.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序代码，所述计算机程序代码被处理电路执行时实现如权利要求6-17中任一项所述的方法。
20.一种芯片系统，其特征在于，所述芯片系统包括处理电路、存储介质，所述存储介质中存储有计算机程序代码；所述计算机程序代码被所述处理电路执行时实现如权利要求6-17中任一项所述的方法。
CN202110887044.0A 2021-08-03 2021-08-03 一种多窗口视频通信方法、设备及系统 Pending CN115706829A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202110887044.0A CN115706829A (zh) 2021-08-03 2021-08-03 一种多窗口视频通信方法、设备及系统
PCT/CN2022/109423 WO2023011408A1 (zh) 2021-08-03 2022-08-01 一种多窗口视频通信方法、设备及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110887044.0A CN115706829A (zh) 2021-08-03 2021-08-03 一种多窗口视频通信方法、设备及系统

Publications (1)

Publication Number Publication Date
CN115706829A true CN115706829A (zh) 2023-02-17

Family

ID=85154361

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110887044.0A Pending CN115706829A (zh) 2021-08-03 2021-08-03 一种多窗口视频通信方法、设备及系统

Country Status (2)

Country Link
CN (1) CN115706829A (zh)
WO (1) WO2023011408A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117135364B (zh) * 2023-10-26 2024-02-02 深圳市宏辉智通科技有限公司 一种视频解码方法和系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009033348A (ja) * 2007-07-25 2009-02-12 Toshiba Corp ビデオ会議アプリケーションサーバ、ビデオ会議方法およびプログラム
CN101557495B (zh) * 2009-05-18 2011-01-26 上海华平信息技术股份有限公司 视频会议系统的带宽控制方法
US9781385B2 (en) * 2013-03-15 2017-10-03 Blue Jeans Network User interfaces for presentation of audio/video streams
CN109218653B (zh) * 2018-09-30 2021-03-19 广州视源电子科技股份有限公司 一种视频会议的多窗口显示方法、装置、设备和系统
US10999344B1 (en) * 2020-06-15 2021-05-04 Google Llc Dynamic video resolution and quality for improved video conferencing
CN112104880A (zh) * 2020-08-31 2020-12-18 广州华多网络科技有限公司 网络连线直播控制、显示方法及装置、设备、存储介质
CN113014858A (zh) * 2021-03-05 2021-06-22 深圳壹秘科技有限公司 一种改变分辨率的方法、系统和装置

Also Published As

Publication number Publication date
WO2023011408A1 (zh) 2023-02-09

Similar Documents

Publication Publication Date Title
US11184584B2 (en) Method for image decoding, method for image encoding, apparatus for image decoding, apparatus for image encoding
CN111295884B (zh) 图像处理装置及图像处理方法
US9172979B2 (en) Experience or “sentio” codecs, and methods and systems for improving QoE and encoding based on QoE experiences
RU2662731C2 (ru) Устройство серверного узла и способ
CN112714327B (zh) 基于直播应用程序的互动方法、装置、设备及存储介质
Huang et al. Utility-oriented resource allocation for 360-degree video transmission over heterogeneous networks
CN110865782B (zh) 数据传输方法、装置及设备
CN114073097A (zh) 通过边缘计算促进视频流式传输和处理
CN113395477B (zh) 基于视频会议的共享方法、装置、电子设备和计算机介质
CN103051864A (zh) 移动视频会议方法及其系统
CN114610253A (zh) 一种投屏方法及设备
JP2015513717A (ja) データ、マルチメディアおよびビデオの送信の更新システム
CN114600468A (zh) 将复合视频流中的视频流与元数据组合
JP2017520940A (ja) 階層符号化されたコンテンツを多重化するための方法および装置
CN114363649B (zh) 视频处理方法、装置、设备及存储介质
CN113676404A (zh) 数据传输方法、装置、设备、存储介质及程序
WO2023011408A1 (zh) 一种多窗口视频通信方法、设备及系统
CN113726815B (zh) 一种动态调整视频的方法、电子设备、芯片系统和存储介质
CN112203126B (zh) 投屏方法、投屏装置及存储介质
CN110602440A (zh) 一种音视频数据流的传输方法、装置及终端
CN112165598A (zh) 数据处理的方法、装置、终端和存储介质
CN106506326B (zh) 一种视频通话方法、终端及系统
CN114598853A (zh) 视频数据的处理方法、装置及网络侧设备
CN117193685A (zh) 投屏数据的处理方法、电子设备及存储介质
CN114257771A (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