A multi-screen interaction method suitable for multiple teaching scenarios based on dynamic network adjustment

Abstract

The application provides a multi-screen interaction method based on dynamic network adjustment, which is suitable for various teaching scenes and realizes screen sharing and real-time interaction between a teacher and multiple student electronic devices by using an Android device. The method dynamically adjusts the sending frequency of heartbeat information by comprehensively considering real-time network conditions and preset teaching interaction requirements, and gradually optimizes adaptive code rate and multicast protocol selection, so as to adapt to different network conditions and teaching scene requirements, and ensure the efficiency, low delay and high-quality display of content synchronization. The method is free of dependence on special hardware, significantly reduces the system cost, enhances the expansibility of the system and the user interaction experience, and provides a flexible and reliable interaction solution for large-scale and multi-terminal teaching scenes.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a multi-screen interaction method based on dynamic network adjustment applicable to multiple teaching scenarios. Background Technology

[0002] With the rapid development of digital teaching and distance learning, the demand for multi-screen interaction in teaching environments is increasing. Multi-screen interaction technology allows teachers, students, and other participants to share and synchronize content across multiple devices, enhancing the interactivity and learning experience of classroom teaching. However, traditional multi-screen interaction systems often rely on dedicated hardware, resulting in high equipment costs, insufficient scalability, and significant shortcomings in real-time performance, synchronization accuracy, and network transmission stability, greatly impacting the effectiveness of classroom teaching. Especially in different teaching scenarios, such as traditional classrooms, large lectures, and remote teaching in remote areas, the adaptability and performance of these systems vary considerably, making it difficult to meet complex and ever-changing needs.

[0003] Therefore, there is an urgent need for a multi-screen interaction solution that optimizes data transmission and display technologies to address issues such as insufficient real-time performance, low synchronization accuracy, and high cost in existing technologies, while also being able to flexibly adapt to various teaching scenarios. The multi-screen interaction method in this application not only reduces reliance on hardware but also adjusts the heartbeat information transmission frequency based on real-time network conditions and the preset level of interaction in the teaching scenario. It then sequentially performs adaptive bitrate adjustment and selects diverse network protocols, thereby ensuring that the system provides efficient, real-time, and reliable multi-screen interaction under different network environments, improving its applicability and stability in various teaching scenarios. Summary of the Invention

[0004] The main objective of this application is to provide a multi-screen interaction method based on dynamic network adjustment applicable to various teaching scenarios, addressing the limitations of existing multi-screen interaction systems in terms of limited applicability, insufficient real-time performance, and low synchronization accuracy. This application adjusts the heartbeat information transmission frequency, data transmission method, and adaptive bit rate based on real-time network conditions and the preset interaction level of the teaching scenario. This ensures the system operates efficiently in different teaching scenarios such as regular classrooms, large lectures, and remote teaching, meeting the needs of various network environments and teaching requirements. It provides a stable, low-latency, and high-quality interactive experience, thereby improving adaptability and reliability in complex and ever-changing teaching scenarios.

[0005] A multi-screen interaction method based on dynamic network adjustment is provided, applicable to various teaching scenarios. This method enables multi-screen interaction between teachers and multiple students' electronic devices in different teaching scenarios, and specifically includes the following steps:

[0006] S1. Device activation: Teacher's electronic devices and student's electronic devices are activated using the same activation code. Each device generates and stores network configuration information containing a unique device identifier (MAC address) and IP address.

[0007] S2. A heartbeat message is periodically sent from the teacher's electronic device to each student's electronic device. Each student's electronic device determines whether the teacher's electronic device and other student electronic devices are online by verifying the timestamp of the heartbeat message.

[0008] S3. Based on real-time network conditions and the preset level of interaction in the teaching scenario, determine whether the heartbeat information sending frequency meets the requirements. If it does, proceed to step S4; if not, adjust the heartbeat information sending frequency until it meets the requirements.

[0009] S4. Upon receiving a broadcast instruction from the teacher's electronic device, each student's electronic device joins a multicast group identified by a multicast address and port to receive the teacher's screen content. The teacher's electronic device uses Android's MediaProjection API to initiate screen capture, encodes the screen content using a hardware encoder, and sends the encoded frame data to the multicast group. Each student's electronic device listens to the multicast stream, decodes the video data, and displays the teacher's screen content on the student's electronic device.

[0010] S5. Based on the image quality and heartbeat information of the electronic device, further determine whether the adaptive bitrate meets the requirements. If it does, proceed to step S6; if it does not, adjust the adaptive bitrate until the image quality requirements of the teaching content are met.

[0011] S6. Based on the adjusted heartbeat information transmission frequency and adaptive bitrate, further determine whether the multicast protocol used is suitable. If it is suitable, proceed to step S7; if it is not suitable, adjust the multicast protocol until the image quality requirements of the teaching content are met.

[0012] S7. The teacher's electronic device executes step S4 again to check whether the image quality of the teaching content meets the requirements. If it does, proceed to step S8; otherwise, proceed to step S5 again.

[0013] S8. The teacher's electronic device sends a request, specifying a particular student's electronic device to send its screen content via unicast. Upon receiving the request, the student's electronic device uses Android's MediaProjection API to capture its screen content and encodes it into the format required by the teacher. After encoding, the student's electronic device transmits the encoded content to the teacher's electronic device. The teacher's electronic device receives and decodes this content, ultimately displaying the student's screen content on its own screen.

[0014] S9. Continuously monitor the online status of each device to ensure that all devices in the classroom environment remain synchronized and meet teaching requirements.

[0015] The multi-screen interaction method of this application can flexibly optimize the system performance according to different teaching scenarios (such as high-demand scenarios, standard usage scenarios, and low-bandwidth environments) by dynamically adjusting the heartbeat information frequency, adaptive bit rate, and multicast protocol selection, thereby improving the user's interactive experience.

[0016] The beneficial technical effects of this application are as follows.

[0017] 1. Adaptability optimization for various teaching scenarios.

[0018] The method described in this application is adaptable to various teaching scenarios, including regular classrooms, large lectures, and remote teaching in remote areas, and further optimizes the ability to switch and adapt across scenarios. By dynamically identifying the current teaching scenario and real-time user interaction needs, the system can automatically switch to the optimal settings between scenarios, achieving efficient real-time interaction and content synchronization. Furthermore, the system can achieve synchronous interaction across multiple devices without additional hardware support, and effectively reduces latency in large-scale, multi-device scenarios, ensuring high-quality content sharing and a smooth classroom experience.

[0019] 2. The frequency of sending heartbeat information was adjusted and optimized by comprehensively considering the level of teaching interaction and the real-time network status.

[0020] The method described in this application dynamically adjusts the heartbeat information transmission frequency by comprehensively considering the preset level of teaching interaction and real-time network conditions, ensuring that the system manages device status more efficiently in different interaction scenarios. For example, in high-interaction scenarios, the system appropriately increases the heartbeat information transmission frequency based on network latency and the number of devices to ensure rapid response and smooth content transmission; in low-interaction or bandwidth-limited scenarios, the system intelligently reduces the heartbeat information transmission frequency, reducing network load while ensuring real-time monitoring of device status. This method, which combines interaction needs with network conditions for dynamic adjustment, improves the system's adaptability and resource utilization efficiency, effectively ensuring the stable synchronization of classroom content.

[0021] 3. Optimize and adjust the heartbeat information frequency, adaptive bit rate, and multicast protocol one by one.

[0022] This application employs a phased, step-by-step optimization approach to enable more efficient collaboration between the heartbeat information transmission frequency, adaptive bitrate, and multicast protocol. First, the system uses the heartbeat information transmission frequency to determine device status and network stability, providing data for subsequent adaptive bitrate adjustments. Then, the adaptive bitrate automatically adjusts video clarity and transmission smoothness based on network quality, feeding back to the multicast protocol selection module to choose the most suitable protocol to ensure the stability and efficiency of large-scale device synchronization. This step-by-step adjustment improves synchronization accuracy while reducing network pressure, ensuring the continuity and high-quality display of teaching content, effectively avoiding latency and content loss even in unstable networks. This step-by-step optimization strategy dynamically balances transmission efficiency and display quality, providing users with a smooth interactive experience.

[0023] 4. Improve the real-time nature and reliability of interactive teaching.

[0024] By flexibly adjusting the combination of heartbeat message sending frequency and multicast protocol, the system can quickly monitor device status in scenarios with high interaction requirements (such as real-time Q&A and operation demonstrations), ensuring real-time content synchronization. In scenarios involving large-scale device synchronization, the system effectively prevents devices from desynchronizing, ensuring efficient and reliable interaction.

[0025] 5. Improve network bandwidth utilization and equipment synchronization accuracy.

[0026] By combining adaptive bitrate and multicast protocol, this application reduces bandwidth consumption and improves device synchronization accuracy. In environments with sufficient bandwidth, the system can seamlessly transmit high-definition content; when bandwidth is limited, dynamically adjusting the adaptive bitrate and multicast protocol effectively reduces network pressure, ensuring that all devices receive optimized content synchronously and avoiding image desynchronization or loss.

[0027] 6. The combined effect of avoiding device disconnection and reducing transmission latency.

[0028] The system effectively reduces device disconnections and transmission latency by combining heartbeat information sending frequency, adaptive bitrate, and multicast protocol. In high-interaction scenarios, the heartbeat frequency is increased to ensure content synchronization; in low-interaction scenarios, the heartbeat frequency and bitrate are optimized, and multicast protocol is used to reduce disconnections and data loss, ensuring the stability of content transmission and display.

[0029] 7. Improve the system's scalability and cost-effectiveness.

[0030] The method described in this application enables multi-screen interaction, avoiding reliance on dedicated hardware devices and significantly reducing system deployment costs. This Android-based solution offers excellent scalability, flexibly adapting to various scenarios from small classrooms to large lectures and remote teaching, and is not limited by hardware, facilitating future expansion and updates. It not only supports synchronous interaction across multiple devices but also allows for the rapid addition or removal of connected devices based on teaching needs, enhancing its applicability and scalability.

[0031] 8. Intelligent dynamic fault handling and equipment status monitoring.

[0032] This application features an intelligent device status monitoring and fault handling mechanism. The system monitors the online status of each device in real time through heartbeat messages and employs flexible error handling algorithms (such as dynamic threshold adjustment and event-driven algorithms) to address device malfunctions or network issues. When a heartbeat times out or network conditions are poor, the system will promptly issue warnings and adjust network strategies to ensure the continuity of the teaching process and reliable device connectivity. Even in scenarios with significant network fluctuations, the system can maintain the synchronization and stability of the teaching content. Attached Figure Description

[0033] The accompanying drawings are provided for a better understanding of this solution and do not constitute a limitation of this application. Wherein:

[0034] Figure 1 This is a flowchart illustrating the multi-screen interaction method according to this application. Detailed Implementation

[0035] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details of multiple embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0036] This application provides a multi-screen interaction method based on dynamic network adjustment applicable to various teaching scenarios. This method runs on devices with Android 6.0 and above systems. It can optimize the heartbeat information sending frequency, adaptive bit rate, and multicast protocol more efficiently through phased optimization and adjustment. Combined with efficient encoding technology, it significantly improves the efficiency of multi-screen interaction in the classroom environment, adapts to various network conditions from high bandwidth to low bandwidth, and ensures smooth interaction and high-quality display in different teaching scenarios such as ordinary classrooms, large lectures or presentations, and remote teaching in remote areas.

[0037] This application provides a multi-screen interaction method based on dynamic network adjustment suitable for multiple teaching scenarios, such as... Figure 1 As shown, the first embodiment specifically involves: S1, activating the teacher's electronic device and the student's electronic device using the same activation code. Each device generates and stores network configuration information containing a unique device identifier.

[0038] Specifically, network configuration information includes the device's MAC address, IP address, and network configuration status (such as subnet mask, gateway, etc.). Furthermore, it can be combined with information such as device identifier (UUID), device type, and device name to enable device activation.

[0039] In some embodiments, teacher electronic devices typically refer to high-configuration electronic devices fixed in specific teaching locations (such as classrooms, lecture halls, etc.) for use by the instructor. These devices generally include large-screen displays, consoles, sound systems, and interactive tools (such as electronic whiteboards or touchscreens). Student electronic devices can be fixed group screens and portable devices distributed throughout the teaching location, designed to interconnect with teacher electronic devices. They can exchange content, such as receiving teaching content from teacher devices, sending interactive feedback, and participating in various interactive activities, such as voting, roll call, quizzes, file uploads, and remote teaching. For example, in a typical classroom, a classroom can be equipped with multiple fixed smart screens (generally up to eight), one for the teacher and the others for group discussions, while also supporting Bring Your Own Device (BYOD), allowing students to use their own mobile phones, tablets, or laptops in class. This approach enhances learning flexibility, allowing students to access teaching resources, submit assignments, and participate in class discussions at any time, thereby increasing interactivity and engagement.

[0040] S2. Send heartbeat messages periodically from the teacher's electronic device to each student's electronic device. Each student's electronic device determines whether the teacher's electronic device and other student electronic devices are online by verifying the timestamp of the heartbeat message.

[0041] Specifically, the heartbeat message includes the MAC address, IP address, and timestamp of the source device (i.e., the teacher's electronic device). Generally, the timestamp refers to the exact time the message was generated and sent within the heartbeat message. This timestamp uses UTC (Coordinated Universal Time) format to ensure time consistency across devices. The timestamp typically includes: transmission time, time format, and time zone information. The transmission time indicates the moment the heartbeat message was generated; the time format uses the ISO 8601 standard for easy time parsing and comparison between devices; and the time zone information ensures accuracy and consistency when devices may be located in different geographical locations.

[0042] Furthermore, if the received heartbeat message timestamp is invalid or no heartbeat message is received within the predetermined time, the device status is marked as "offline," the error is recorded, and a notification is sent to the teacher's electronic device; if the number of consecutive heartbeat timeouts exceeds the threshold, it is marked as "fault," and the corresponding fault handling process is initiated.

[0043] Generally, various algorithms can be used for device status monitoring and fault handling, including: Dynamic threshold algorithms: These dynamically adjust the heartbeat timeout threshold based on network conditions and the device's historical online status to adapt to different usage scenarios and environments. Weighted heartbeat algorithms: These assign different weights to different types of devices, affecting the frequency and tolerance of heartbeat detection. Important devices may have stricter heartbeat monitoring requirements. Event-driven algorithms: These use an event-driven approach to process and monitor heartbeat messages only when the device status changes, thereby reducing unnecessary checks. Machine learning algorithms: These apply machine learning techniques to analyze historical heartbeat data, identify abnormal patterns, and automatically adjust the logic and thresholds of heartbeat detection. Redundancy detection algorithms: These use multiple independent heartbeat signal sources to improve the reliability of fault detection; fault handling is only performed when multiple signal sources simultaneously indicate that the device is "offline."

[0044] This embodiment allows selection of any of the above algorithms based on actual needs to achieve efficient, stable, and high-quality multi-screen interaction. These algorithms not only adapt to different network conditions and teaching scenarios but also effectively improve user experience. Therefore, all of the above algorithms fall within the protection scope of this application, ensuring their application and implementation in multi-screen interaction systems.

[0045] S3. Based on real-time network conditions and the level of interaction in the preset teaching scenario, determine whether the heartbeat information sending frequency meets the requirements. If it does, proceed to step S4; if not, adjust the heartbeat information sending frequency until it meets the requirements.

[0046] Furthermore, in step S3, the heartbeat message sending frequency can be set from 100 milliseconds to 30 seconds. Different frequency values ​​will produce different effects and impacts. For example, more frequent heartbeat messages (e.g., every 1 second) ensure rapid response but increase network load; lower frequency heartbeats (e.g., every 8 seconds) are suitable for low-bandwidth environments and can effectively reduce network pressure. Real-time network conditions generally include factors such as network load, network latency, jitter, and packet loss rate. Network load involves bandwidth utilization and the number of connections; high load will lead to a decrease in data transmission speed. Network latency includes transmission latency, processing latency, and queuing latency; excessively high latency may affect the performance of real-time applications. Meanwhile, jitter reflects changes in latency, and packet loss rate refers to the proportion of data packets lost during transmission; a high packet loss rate will lead to incomplete information and affect user experience. The heartbeat message sending frequency will be adjusted according to the above real-time network conditions and the preset level of interaction in the teaching scenario to adapt to different operating conditions and needs. Therefore, the heartbeat message sending frequency should be reasonably selected according to network conditions and teaching scenarios to ensure that both timely monitoring of device status and teaching quality can be guaranteed in different scenarios. In this embodiment, the heartbeat message is sent at a frequency of once every 1 second.

[0047] Generally, the level of interactivity in a teaching setting refers to the frequency and quality of communication between teachers and students, specifically including real-time question-and-answer sessions, the speed of student feedback, participation in group discussions, and the frequency of interaction using electronic devices. High interactivity indicates frequent communication and participation, while low interactivity means less communication. This indicator helps adjust technology support strategies to ensure the effectiveness of teaching. Therefore, this indicator can be preset to adjust the frequency of heartbeat message transmission.

[0048] Furthermore, taking a typical classroom as an example, the level of interaction is presumably high, with more than 10 questions and answers or interactions between teachers and students, and a feedback response time of less than 1 minute. In contrast, in large lectures, due to the large number of participants, the level of interaction is presumably moderate, with an interaction frequency between 5 and 10 times and a feedback response time between 1 and 3 minutes. Finally, in remote teaching scenarios in remote areas, due to network limitations and other factors, the level of interaction is presumably low, with fewer interactions, such as fewer than 5 times, and a feedback response time exceeding 3 minutes.

[0049] Furthermore, when adjusting the heartbeat message sending frequency in step S3, it can be dynamically adjusted based on real-time network conditions and the preset level of interaction. In a typical classroom, where the preset level of interaction is high and network conditions are good, the heartbeat message sending frequency can be increased to ensure good device performance and high-quality transmission of teaching content. Secondly, in large lectures, where the preset level of interaction is moderate, the heartbeat frequency can be appropriately increased if network conditions are good to maintain the stability of content transmission; if network conditions are poor, the heartbeat frequency should be decreased to reduce network load. Finally, for remote teaching in remote areas, even with a lower preset level of interaction, the heartbeat frequency should be reduced if network bandwidth is limited to ensure smooth transmission of teaching content under limited network conditions and to guarantee teaching quality.

[0050] This adjustment strategy, which combines real-time network conditions with preset levels of interaction, helps to effectively balance the need for real-time monitoring with network load, thereby optimizing teaching effectiveness.

[0051] S4. Upon receiving a broadcast command from the teacher's electronic device, each student's electronic device joins a multicast group identified by a multicast address and port to receive the teacher's screen content. The teacher's electronic device initiates screen capture using Android's MediaProjection API, encodes the screen content using a hardware encoder, and sends the encoded frame data to the multicast group. Each student's electronic device listens to the multicast stream, decodes the video data, and displays the teacher's screen content on the student's electronic device.

[0052] In some embodiments, step S4 may be further as follows: S401: The teacher's electronic device joins the multicast address A and binds to the multicast port a1, and sends instructions to all student electronic devices in the teaching scenario. The instruction information includes the MAC address of the device, the IP address of the device, the MAC address of the target device, the IP address of the target device, the multicast address A, the multicast port a1, the timestamp (in UTC format), the action command, and some optional parameters.

[0053] S402: After receiving the instruction, the student electronic device creates a Surface instance for displaying the interface, and simultaneously creates a hardware decoder supporting H.265, binding the Surface instance to the decoder's output. At this point, it adds multicast address A to multicast port a1 and begins listening for video stream data. If video data is detected, it starts the decoding task.

[0054] S403: The teacher's electronic device requests a screen recording instance by calling the Android system function `((MediaProjectionManager)getSystemService(Context.MEDIA_PROJECTION_SERVICE)).createScreenCaptureIntent()` and requests user authorization. An encoder is created using the Android system's MediaCodec, followed by an encoding input area Surface (the encoder controls the quality of screen recording, such as frame rate and bitrate). At this point, a virtual display is generated from the screen recording instance, and the virtual display is associated with the encoding input area Surface. Data from the virtual display is input into the encoding input area Surface, and the encoder is started. The real-time screen image is then obtained from the encoder's callback function `onOutputBufferAvailable`.

[0055] S404: Encodes each frame output by the encoder in real time using H265 and ensures video quality based on encoding parameters (such as resolution, frame rate, etc.).

[0056] S405: Encapsulates the H265 encoded frame data into Nalu units, disassembles and packets according to rules, and transmits the packets using a proprietary transmission protocol.

[0057] S406: After the student electronic device in step S402 listens to the transmitted data stream, it merges the received packet data into frames and performs integrity verification.

[0058] S407: The complete frame data is sent to the decoder of the group screen in step S402 for decoding. At this time, the teacher's screen image is displayed on the group screen.

[0059] In some embodiments, step S406 may employ various integrity verification algorithms to ensure the reliability of data transmission during multi-screen interaction. Specifically, these include: Cyclic Redundancy Check (CRC), used to detect any bit errors in data packets sent from the teacher's electronic device to the student's electronic device, ensuring data integrity; Hash functions (such as SHA-256 or MD5) that generate hash values ​​for transmitted frame data, allowing the receiving student electronic device to verify data integrity by comparing the calculated hash value with the sent hash value; Parity checks providing a simple and effective method for detecting single-bit errors, especially important in scenarios requiring rapid response; Implementing packet sequence numbers allowing the student electronic device to track the order of received data packets, thereby identifying lost or duplicate packets; and finally, Forward Error Correction (FEC) sending redundant data, enabling the student device to reconstruct complete frames even in the event of data loss.

[0060] This embodiment allows selection of any of the above-mentioned verification algorithms based on actual needs to achieve efficient, stable, and high-quality multi-screen interaction. These algorithms not only adapt to different network conditions and teaching scenarios but also effectively improve user experience. Therefore, all of the above algorithms fall within the protection scope of this application, ensuring their application and implementation in multi-screen interaction systems.

[0061] In some embodiments, encoding and decoding can employ different decoders such as H.264, H.265, VP8, VP9, ​​and AV1. Specifically, this embodiment employs an H.265 encoder, which, through the application of an optimized compression algorithm, can significantly reduce bandwidth requirements while maintaining high image quality.

[0062] S5. Based on the image quality of the electronic device and the determined heartbeat information transmission frequency, further determine whether the adaptive bitrate meets the requirements. If it does, proceed to step S6; if it does not, adjust the adaptive bitrate until the image quality requirements of the teaching content are met.

[0063] Further, in step S5, when determining whether the adaptive bitrate meets the requirements, the following steps are taken: First, the highest resolution supported by the device is evaluated. For example, a teacher's electronic device may support 4K, while a student's electronic device may support 1080p. The clarity and smoothness of playback are monitored through a real-time feedback mechanism, and a comprehensive evaluation is performed in conjunction with received image quality data (such as user feedback, playback stutters, and video quality metrics). Second, online status and network latency are monitored through periodically sent heartbeat messages. If the heartbeat message latency is less than 200 milliseconds and the packet loss rate is low, it indicates good network conditions. In this case, the adaptive bitrate can be appropriately increased, for example, by selecting 1080p (16Mbps) to improve image quality. Conversely, if the heartbeat latency exceeds 500 milliseconds or the packet loss rate increases, the bitrate needs to be reduced, for example, by adjusting it to 720p (8Mbps) to ensure smooth playback. Finally, the received image quality metrics and heartbeat information are considered together, and corresponding thresholds are set to dynamically and in real-time adjust the adaptive bitrate, thereby optimizing the user experience of multi-screen interaction.

[0064] In some embodiments, adaptive bitrate (ABR) streaming is configured to target different resolutions and bitrates, typically ranging from 120p to 4K and from 1Mbps to 40Mbps, respectively. The quality of the teaching content is dynamically adjusted based on network conditions to ensure the best viewing experience. These settings can be configured via the teacher's electronic device, capturing the teacher's screen content in real time and automatically adjusting the video stream's resolution and bitrate based on current network bandwidth and terminal device conditions. In this embodiment, the adaptive bitrate could be: 4K resolution and 20Mbps bitrate.

[0065] S6. Based on the adjusted heartbeat information transmission frequency and adaptive bitrate, further determine whether the multicast protocol used is suitable. If it is suitable, proceed to step S7; if it is not suitable, adjust the multicast protocol until the image quality requirements of the teaching content are met.

[0066] Furthermore, when determining whether a multicast protocol meets the requirements, the following points should be considered: First, the frequency of heartbeat message transmission reflects the stability and load of the network. A high heartbeat message transmission frequency indicates a good network condition, making it suitable to choose an efficient multicast protocol, such as Internet Group Management Protocol (IGMP), Simple Multicast Protocol (SMP), or User Datagram Protocol (UDP), to ensure timely data transmission and a high-quality viewing experience. Conversely, a low heartbeat message transmission frequency indicates a poor network condition, requiring the selection of a more adaptable multicast protocol, such as Protocol Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), or Real-Time Transport Protocol (RTP), to ensure effective data transmission even under unstable network conditions.

[0067] Secondly, the adaptive bitrate directly affects the quality of the video stream. For example, if the current adaptive bitrate is high (such as 4K (20Mbps) or 1080p (16Mbps)), a multicast protocol that supports higher bandwidth, such as Internet Group Management Protocol (IGMP) or Multiprotocol Label Switching (MPLS), needs to be selected to ensure the quality of the teaching content and transmission efficiency. For lower adaptive bitrates (such as 720p (8Mbps)), it is reasonable to choose simpler multicast protocols such as Protocol Independent Multicast (PIM) or Distance Vector Multicast Routing Protocol (DVMRP), because these protocols can work effectively in medium or low bandwidth environments.

[0068] Ultimately, by comprehensively evaluating the transmission frequency and adaptive bitrate of heartbeat information, corresponding selection criteria were set to ensure that the adopted multicast protocol could effectively support the needs of multi-screen interaction in different teaching scenarios, thereby improving user experience and teaching effectiveness. This allows for dynamic adjustment of the multicast protocol to adapt to different network environments and device characteristics, thus guaranteeing efficient data transmission and reliable teaching content quality.

[0069] In some embodiments, the multicast protocol may be, but is not limited to: Internet Group Management Protocol (IGMP), Protocol Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), Multiprotocol Label Switching (MPLS), Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP), Simple Multicast Protocol (SMP), and Source Specific Multicast (SSM). Based on different teaching scenarios and usage areas (e.g., regular classrooms, high-definition lectures, or large-scale events, such as remote cross-border or remote areas, rural areas, etc.), and combined with the heartbeat information transmission frequency and adaptive rate code, the above-mentioned multicast protocol is rationally selected to meet the requirements of efficient transmission, high-quality image quality, and multi-screen interaction, thereby improving the teaching experience. Specifically, in this embodiment, the multicast protocol adopted is Internet Group Management Protocol (IGMP).

[0070] In some embodiments, the teacher's electronic device is responsible for creating a multicast stream and broadcasting the screen content to the student's electronic device according to a selected multicast protocol.

[0071] S7. The teacher's electronic device executes step S4 again to check whether the image quality of the teaching content meets the requirements. If it does, proceed to step S8; otherwise, proceed to step S5 again.

[0072] Furthermore, the teacher's electronic device executes step S4 again and checks whether the image quality received by the student's electronic device meets the requirements. Specifically, if the image quality meets the requirements, the system proceeds to step S8, where the teacher can request a specific student device to share its screen content. If the image quality does not meet the requirements, the system returns to step S5 to readjust the adaptive bitrate, and then proceeds to step S6 to further adjust the multicast protocol. After multiple adjustments, the system ensures that all devices can synchronously receive high-quality teaching content, improving classroom interaction.

[0073] S8. The teacher's electronic device sends a request, specifying a particular student's electronic device to send its screen content via unicast. Upon receiving the request, the student's electronic device uses Android's MediaProjection API to capture its screen content and encodes it into the format required by the teacher. After encoding, the student's electronic device transmits the encoded content to the teacher's electronic device. The teacher's electronic device receives and decodes this content, ultimately displaying the student's screen content on its own screen.

[0074] In some embodiments, multiple request methods are associated with different teaching scenarios, allowing teachers to access students' screen content in various ways. Specifically, in regular classrooms, teachers can use instant messaging tools (such as WeChat groups, QQ, etc.) to send requests, and students can quickly respond and share their screens. In large lecture scenarios, teachers can utilize dedicated mobile applications (such as the official app of the teaching platform) that provide a "Request Screen Sharing" button, allowing students to send requests simply by clicking. Furthermore, the application can integrate real-time feedback, allowing students to select the application or screen area to share after clicking the request, simplifying the process and improving classroom interaction efficiency. Simultaneously, the application displays the request status in real time, ensuring smooth communication between teachers and students. In remote teaching in remote areas, teachers can use voice recognition technology to request students to share screen content via voice commands. Student devices can recognize the teacher's voice requests in real time and provide feedback, reducing reliance on complex operations and enhancing the convenience of interaction. In summary, these different request mechanisms can be flexibly applied according to specific teaching scenarios, improving the interactivity and effectiveness of teaching.

[0075] In some embodiments, after receiving students' screen content, teachers can conduct multi-content comparison and collaborative feedback to enhance classroom interaction and learning outcomes. For example, in a regular classroom, teachers can simultaneously display the screen content of multiple students, comparing their problem-solving approaches in real time, helping students learn from each other and identify differences in understanding. In large lectures, teachers can collect student feedback through online voting tools and aggregate screen content from different groups for discussion and analysis to promote in-depth intellectual exchange. In remote teaching in remote areas, students can answer orally through microphones, and teachers can use speech recognition technology to convert this speech into text to understand students' viewpoints or questions. Teachers can then combine this content with the screen content shared by students to provide more targeted feedback. For example, if a student displays their problem-solving process on screen, the teacher can directly point out errors in their thinking or provide further explanations based on the student's voice feedback.

[0076] Furthermore, teachers can annotate students' screen content in real time, providing specific suggestions, while students can also provide feedback, thus achieving two-way interaction. Finally, teachers can save screen content from different time periods for historical analysis, compare student progress, and develop personalized learning plans to improve teaching effectiveness. Through these mechanisms, teachers can optimize teaching strategies and promote more efficient student learning.

[0077] S9. Continuously monitor the online status of each device to ensure that all devices in the classroom environment remain synchronized and meet teaching requirements.

[0078] In some embodiments, during real-time monitoring, the performance of each device is comprehensively evaluated by periodically exchanging heartbeat information and monitoring adaptive bitrate, among other multi-dimensional metrics. Heartbeat information reflects the device's online status and network connection quality, while adaptive bitrate displays the current quality of the video stream and bandwidth usage. For example, teachers can monitor the heartbeat frequency of student devices to determine network stability; simultaneously, by observing the adaptive bitrate, if a student's bitrate is low, the teacher can proactively inquire whether the student is experiencing network problems or technical difficulties. Through these multi-dimensional monitoring metrics, teachers can promptly identify and resolve potential technical issues, ensuring smooth classroom interaction.

[0079] Furthermore, by collecting data on device battery levels, CPU usage, and memory consumption, classroom management can be further optimized. For example, teachers can check the battery status of each student's device and promptly determine whether to remind students to charge it to avoid device shutdowns or lag due to insufficient power. If a device's CPU usage is too high, the system can automatically suggest that students close unnecessary applications to free up resources, ensuring smooth video playback and classroom interaction. Through these comprehensive measures, teachers can better maintain the classroom environment and improve teaching effectiveness.

[0080] Furthermore, an intelligent early warning mechanism can be set up to automatically send a notification to the teacher when a device loses heartbeat messages more than three times, indicating that the device may have a network problem. For example, if a student's device experiences frequent heartbeat loss, the teacher can proactively inquire with the student and help them resolve the network connection issue, preventing class interruptions.

[0081] Furthermore, the system can automatically adjust teaching strategies based on real-time monitoring data. For example, if a student's network latency reaches 500 milliseconds, the system can temporarily disable that student's screen sharing function to ensure that other students' experience is not affected. This dynamic adjustment can maintain the overall stability of the classroom.

[0082] Furthermore, heart rate messages and device status data can be collected regularly to generate usage reports. For example, teachers can review the performance reports of each device after class to understand which devices are performing well and which are experiencing problems, thereby optimizing future device configurations and teaching arrangements. Such data analysis can help teachers better adapt to students' needs.

[0083] Furthermore, instant feedback tools can be introduced, allowing students to quickly report their experiences or problems during class. For example, at the end of each class, students can submit their feelings through the in-app feedback button, such as "the screen was choppy" or "the sound was unclear." Teachers can then view this feedback instantly and make targeted adjustments.

[0084] Furthermore, heartbeat messages and device status data can be stored in the cloud for teachers to analyze and replay lessons later. For example, teachers can view classroom monitoring data from the past week to identify periods when devices performed poorly, allowing them to make targeted improvements to teaching methods and technical support.

[0085] The second embodiment of the above method is as follows: S1, activate the teacher's electronic device and the student's electronic device using the same activation code. Each device generates and stores network configuration information containing a unique device identifier.

[0086] Specifically, network configuration information includes the device's MAC address, IP address, and network configuration status (such as subnet mask, gateway, etc.). Furthermore, it can be combined with information such as device identifier (UUID), device type, and device name to enable device activation.

[0087] In some embodiments, teacher electronic devices typically refer to high-configuration electronic devices fixed in specific teaching locations (such as classrooms, lecture halls, etc.) for use by the instructor. These devices generally include large-screen displays, consoles, sound systems, and interactive tools (such as electronic whiteboards or touchscreens). Student electronic devices can be fixed group screens and portable devices distributed throughout the teaching location, designed to interconnect with teacher electronic devices. They can exchange content, such as receiving teaching content from teacher devices, sending interactive feedback, and participating in various interactive activities, such as voting, roll call, quizzes, file uploads, and remote teaching. For example, in a typical classroom, a classroom can be equipped with multiple fixed smart screens (generally up to eight), one for the teacher and the others for group discussions, while also supporting Bring Your Own Device (BYOD), allowing students to use their own mobile phones, tablets, or laptops in class. This approach enhances learning flexibility, allowing students to access teaching resources, submit assignments, and participate in class discussions at any time, thereby increasing interactivity and engagement.

[0088] S2. Send heartbeat messages periodically from the teacher's electronic device to each student's electronic device. Each student's electronic device determines whether the teacher's electronic device and other student electronic devices are online by verifying the timestamp of the heartbeat message.

[0089] Specifically, the heartbeat message includes the MAC address, IP address, and timestamp of the source device (i.e., the teacher's electronic device). Generally, the timestamp refers to the exact time the message was generated and sent within the heartbeat message. This timestamp uses UTC (Coordinated Universal Time) format to ensure time consistency across devices. The timestamp typically includes: transmission time, time format, and time zone information. The transmission time indicates the moment the heartbeat message was generated; the time format uses the ISO 8601 standard for easy time parsing and comparison between devices; and the time zone information ensures accuracy and consistency when devices may be located in different geographical locations.

[0090] Furthermore, if the received heartbeat message timestamp is invalid or no heartbeat message is received within the predetermined time, the device status is marked as "offline," the error is recorded, and a notification is sent to the teacher's electronic device; if the number of consecutive heartbeat timeouts exceeds the threshold, it is marked as "fault," and the corresponding fault handling process is initiated.

[0091] Generally, various algorithms can be used for device status monitoring and fault handling, including: Dynamic threshold algorithms: These dynamically adjust the heartbeat timeout threshold based on network conditions and the device's historical online status to adapt to different usage scenarios and environments. Weighted heartbeat algorithms: These assign different weights to different types of devices, affecting the frequency and tolerance of heartbeat detection. Important devices may have stricter heartbeat monitoring requirements. Event-driven algorithms: These use an event-driven approach to process and monitor heartbeat messages only when the device status changes, thereby reducing unnecessary checks. Machine learning algorithms: These apply machine learning techniques to analyze historical heartbeat data, identify abnormal patterns, and automatically adjust the logic and thresholds of heartbeat detection. Redundancy detection algorithms: These use multiple independent heartbeat signal sources to improve the reliability of fault detection; fault handling is only performed when multiple signal sources simultaneously indicate that the device is "offline."

[0092] This embodiment allows selection of any of the above algorithms based on actual needs to achieve efficient, stable, and high-quality multi-screen interaction. These algorithms not only adapt to different network conditions and teaching scenarios but also effectively improve user experience. Therefore, all of the above algorithms fall within the protection scope of this application, ensuring their application and implementation in multi-screen interaction systems.

[0093] S3. Based on real-time network conditions and the level of interaction in the preset teaching scenario, determine whether the heartbeat information sending frequency meets the requirements. If it does, proceed to step S4; if not, adjust the heartbeat information sending frequency until it meets the requirements.

[0094] Furthermore, in step S3, the heartbeat message sending frequency can be set from 100 milliseconds to 30 seconds. Different frequency values ​​will produce different effects and impacts. For example, more frequent heartbeat messages (e.g., every 1 second) ensure rapid response but increase network load; lower frequency heartbeats (e.g., every 8 seconds) are suitable for low-bandwidth environments and can effectively reduce network pressure. Real-time network conditions generally include factors such as network load, network latency, jitter, and packet loss rate. Network load involves bandwidth utilization and the number of connections; high load will lead to a decrease in data transmission speed. Network latency includes transmission latency, processing latency, and queuing latency; excessively high latency may affect the performance of real-time applications. Meanwhile, jitter reflects changes in latency, and packet loss rate refers to the proportion of data packets lost during transmission; a high packet loss rate will lead to incomplete information and affect user experience. The heartbeat message sending frequency will be adjusted according to the above real-time network conditions and the preset level of interaction in the teaching scenario to adapt to different operating conditions and needs. Therefore, the heartbeat message sending frequency should be reasonably selected according to network conditions and teaching scenarios to ensure that both timely monitoring of device status and teaching quality can be guaranteed in different scenarios. In this embodiment, the heartbeat message is sent every 3 seconds.

[0095] Generally, the level of interactivity in a teaching setting refers to the frequency and quality of communication between teachers and students, specifically including real-time question-and-answer sessions, the speed of student feedback, participation in group discussions, and the frequency of interaction using electronic devices. High interactivity indicates frequent communication and participation, while low interactivity means less communication. This indicator helps adjust technology support strategies to ensure the effectiveness of teaching. Therefore, this indicator can be preset to adjust the frequency of heartbeat message transmission.

[0096] Furthermore, taking a typical classroom as an example, the level of interaction is presumably high, with more than 10 questions and answers or interactions between teachers and students, and a feedback response time of less than 1 minute. In contrast, in large lectures, due to the large number of participants, the level of interaction is presumably moderate, with an interaction frequency between 5 and 10 times and a feedback response time between 1 and 3 minutes. Finally, in remote teaching scenarios in remote areas, due to network limitations and other factors, the level of interaction is presumably low, with fewer interactions, such as fewer than 5 times, and a feedback response time exceeding 3 minutes.

[0097] Furthermore, when adjusting the heartbeat message sending frequency in step S3, it can be dynamically adjusted based on real-time network conditions and the preset level of interaction. In a typical classroom, where the preset level of interaction is high and network conditions are good, the heartbeat message sending frequency can be increased to ensure good device performance and high-quality transmission of teaching content. Secondly, in large lectures, where the preset level of interaction is moderate, the heartbeat frequency can be appropriately increased if network conditions are good to maintain the stability of content transmission; if network conditions are poor, the heartbeat frequency should be decreased to reduce network load. Finally, for remote teaching in remote areas, even with a lower preset level of interaction, the heartbeat frequency should be reduced if network bandwidth is limited to ensure smooth transmission of teaching content under limited network conditions and to guarantee teaching quality.

[0098] This adjustment strategy, which combines real-time network conditions with preset levels of interaction, helps to effectively balance the need for real-time monitoring with network load, thereby optimizing teaching effectiveness.

[0099] S4. Upon receiving a broadcast command from the teacher's electronic device, each student's electronic device joins a multicast group identified by a multicast address and port to receive the teacher's screen content. The teacher's electronic device initiates screen capture using Android's MediaProjection API, encodes the screen content using a hardware encoder, and sends the encoded frame data to the multicast group. Each student's electronic device listens to the multicast stream, decodes the video data, and displays the teacher's screen content on the student's electronic device.

[0100] In some embodiments, step S4 may be further as follows: S401: The teacher's electronic device joins the multicast address A and binds to the multicast port a1, and sends instructions to all student electronic devices in the teaching scenario. The instruction information includes the MAC address of the device, the IP address of the device, the MAC address of the target device, the IP address of the target device, the multicast address A, the multicast port a1, the timestamp (in UTC format), the action command, and some optional parameters.

[0101] S402: After receiving the instruction, the student electronic device creates a Surface instance for displaying the interface, and simultaneously creates a hardware decoder supporting H.265, binding the Surface instance to the decoder's output. At this point, it adds multicast address A to multicast port a1 and begins listening for video stream data. If video data is detected, it starts the decoding task.

[0102] S403: The teacher's electronic device requests a screen recording instance by calling the Android system function `((MediaProjectionManager)getSystemService(Context.MEDIA_PROJECTION_SERVICE)).createScreenCaptureIntent()` and requests user authorization. An encoder is created using the Android system's MediaCodec, followed by an encoding input area Surface (the encoder controls the quality of screen recording, such as frame rate and bitrate). At this point, a virtual display is generated from the screen recording instance, and the virtual display is associated with the encoding input area Surface. Data from the virtual display is input into the encoding input area Surface, and the encoder is started. The real-time screen image is then obtained from the encoder's callback function `onOutputBufferAvailable`.

[0103] S404: Encodes each frame output by the encoder in real time using H265 and ensures video quality based on encoding parameters (such as resolution, frame rate, etc.).

[0104] S405: Encapsulates the H265 encoded frame data into Nalu units, disassembles and packets according to rules, and transmits the packets using a proprietary transmission protocol.

[0105] S406: After the student electronic device in step S402 listens to the transmitted data stream, it merges the received packet data into frames and performs integrity verification.

[0106] S407: The complete frame data is sent to the decoder of the group screen in step S402 for decoding. At this time, the teacher's screen image is displayed on the group screen.

[0107] In some embodiments, step S406 may employ various integrity verification algorithms to ensure the reliability of data transmission during multi-screen interaction. Specifically, these include: Cyclic Redundancy Check (CRC), used to detect any bit errors in data packets sent from the teacher's electronic device to the student's electronic device, ensuring data integrity; Hash functions (such as SHA-256 or MD5) that generate hash values ​​for transmitted frame data, allowing the receiving student electronic device to verify data integrity by comparing the calculated hash value with the sent hash value; Parity checks providing a simple and effective method for detecting single-bit errors, especially important in scenarios requiring rapid response; Implementing packet sequence numbers allowing the student electronic device to track the order of received data packets, thereby identifying lost or duplicate packets; and finally, Forward Error Correction (FEC) sending redundant data, enabling the student device to reconstruct complete frames even in the event of data loss.

[0108] This embodiment allows selection of any of the above-mentioned verification algorithms based on actual needs to achieve efficient, stable, and high-quality multi-screen interaction. These algorithms not only adapt to different network conditions and teaching scenarios but also effectively improve user experience. Therefore, all of the above algorithms fall within the protection scope of this application, ensuring their application and implementation in multi-screen interaction systems.

[0109] In some embodiments, encoding and decoding can employ different decoders such as H.264, H.265, VP8, VP9, ​​and AV1. Specifically, this embodiment employs an H.265 encoder, which, through the application of an optimized compression algorithm, can significantly reduce bandwidth requirements while maintaining high image quality.

[0110] S5. Based on the image quality of the electronic device and the determined heartbeat information transmission frequency, further determine whether the adaptive bitrate meets the requirements. If it does, proceed to step S6; if it does not, adjust the adaptive bitrate until the image quality requirements of the teaching content are met.

[0111] Further, in step S5, when determining whether the adaptive bitrate meets the requirements, the following steps are taken: First, the highest resolution supported by the device is evaluated. For example, a teacher's electronic device may support 4K, while a student's electronic device may support 1080p. The clarity and smoothness of playback are monitored through a real-time feedback mechanism, and a comprehensive evaluation is performed in conjunction with received image quality data (such as user feedback, playback stutters, and video quality metrics). Second, online status and network latency are monitored through periodically sent heartbeat messages. If the heartbeat message latency is less than 200 milliseconds and the packet loss rate is low, it indicates good network conditions. In this case, the adaptive bitrate can be appropriately increased, for example, by selecting 1080p (16Mbps) to improve image quality. Conversely, if the heartbeat latency exceeds 500 milliseconds or the packet loss rate increases, the bitrate needs to be reduced, for example, by adjusting it to 720p (8Mbps) to ensure smooth playback. Finally, the received image quality metrics and heartbeat information are considered together, and corresponding thresholds are set to dynamically and in real-time adjust the adaptive bitrate, thereby optimizing the user experience of multi-screen interaction.

[0112] In some embodiments, adaptive bitrate (ABR) streaming is configured to target different resolutions and bitrates, typically ranging from 120p to 4K and from 1Mbps to 40Mbps, respectively. The quality of the teaching content is dynamically adjusted based on network conditions to ensure the best viewing experience. These settings can be configured via the teacher's electronic device, capturing the teacher's screen content in real time and automatically adjusting the video stream's resolution and bitrate based on current network bandwidth and terminal device conditions. In this embodiment, the adaptive bitrate could be: a resolution of 1080p and a bitrate of 16Mbps.

[0113] S6. Based on the adjusted heartbeat information transmission frequency and adaptive bitrate, further determine whether the multicast protocol used is suitable. If it is suitable, proceed to step S7; if it is not suitable, adjust the multicast protocol until the image quality requirements of the teaching content are met.

[0114] Furthermore, when determining whether a multicast protocol meets the requirements, the following points should be considered: First, the frequency of heartbeat message transmission reflects the stability and load of the network. A high heartbeat message transmission frequency indicates a good network condition, making it suitable to choose an efficient multicast protocol, such as Internet Group Management Protocol (IGMP), Simple Multicast Protocol (SMP), or User Datagram Protocol (UDP), to ensure timely data transmission and a high-quality viewing experience. Conversely, a low heartbeat message transmission frequency indicates a poor network condition, requiring the selection of a more adaptable multicast protocol, such as Protocol Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), or Real-Time Transport Protocol (RTP), to ensure effective data transmission even under unstable network conditions.

[0115] Secondly, the adaptive bitrate directly affects the quality of the video stream. For example, if the current adaptive bitrate is high (such as 4K (20Mbps) or 1080p (16Mbps)), a multicast protocol that supports higher bandwidth, such as Internet Group Management Protocol (IGMP) or Multiprotocol Label Switching (MPLS), needs to be selected to ensure the quality of the teaching content and transmission efficiency. For lower adaptive bitrates (such as 720p (8Mbps)), it is reasonable to choose simpler multicast protocols such as Protocol Independent Multicast (PIM) or Distance Vector Multicast Routing Protocol (DVMRP), because these protocols can work effectively in medium or low bandwidth environments.

[0116] Ultimately, by comprehensively evaluating the transmission frequency and adaptive bitrate of heartbeat information, corresponding selection criteria were set to ensure that the adopted multicast protocol could effectively support the needs of multi-screen interaction in different teaching scenarios, thereby improving user experience and teaching effectiveness. This allows for dynamic adjustment of the multicast protocol to adapt to different network environments and device characteristics, thus guaranteeing efficient data transmission and reliable teaching content quality.

[0117] In some embodiments, the multicast protocol may be, but is not limited to: Internet Group Management Protocol (IGMP), Protocol Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), Multiprotocol Label Switching (MPLS), Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP), Simple Multicast Protocol (SMP), and Source Specific Multicast (SSM). Based on different teaching scenarios and usage areas (e.g., regular classrooms, high-definition lectures or large-scale events, such as remote cross-border or remote areas, rural areas, etc.), and combined with the heartbeat information transmission frequency and adaptive rate code, the above-mentioned multicast protocol is rationally selected to meet the requirements of efficient transmission, high-quality image quality, and multi-screen interaction, thereby improving the teaching experience. Specifically, in this embodiment, the multicast protocol adopted is Protocol Independent Multicast (PIM).

[0118] In some embodiments, the teacher's electronic device is responsible for creating a multicast stream and broadcasting the screen content to the student's electronic device according to a selected multicast protocol.

[0119] S7. The teacher's electronic device executes step S4 again to check whether the image quality of the teaching content meets the requirements. If it does, proceed to step S8; otherwise, proceed to step S5 again.

[0120] Furthermore, the teacher's electronic device executes step S4 again and checks whether the image quality received by the student's electronic device meets the requirements. Specifically, if the image quality meets the requirements, the system proceeds to step S8, where the teacher can request a specific student device to share its screen content. If the image quality does not meet the requirements, the system returns to step S5 to readjust the adaptive bitrate, and then proceeds to step S6 to further adjust the multicast protocol. After multiple adjustments, the system ensures that all devices can synchronously receive high-quality teaching content, improving classroom interaction.

[0121] S8. The teacher's electronic device sends a request, specifying a particular student's electronic device to send its screen content via unicast. Upon receiving the request, the student's electronic device uses Android's MediaProjection API to capture its screen content and encodes it into the format required by the teacher. After encoding, the student's electronic device transmits the encoded content to the teacher's electronic device. The teacher's electronic device receives and decodes this content, ultimately displaying the student's screen content on its own screen.

[0122] In some embodiments, multiple request methods are associated with different teaching scenarios, allowing teachers to access students' screen content in various ways. Specifically, in regular classrooms, teachers can use instant messaging tools (such as WeChat groups, QQ, etc.) to send requests, and students can quickly respond and share their screens. In large lecture scenarios, teachers can utilize dedicated mobile applications (such as the official app of the teaching platform) that provide a "Request Screen Sharing" button, allowing students to send requests simply by clicking. Furthermore, the application can integrate real-time feedback, allowing students to select the application or screen area to share after clicking the request, simplifying the process and improving classroom interaction efficiency. Simultaneously, the application displays the request status in real time, ensuring smooth communication between teachers and students. In remote teaching in remote areas, teachers can use voice recognition technology to request students to share screen content via voice commands. Student devices can recognize the teacher's voice requests in real time and provide feedback, reducing reliance on complex operations and enhancing the convenience of interaction. In summary, these different request mechanisms can be flexibly applied according to specific teaching scenarios, improving the interactivity and effectiveness of teaching.

[0123] In some embodiments, after receiving students' screen content, teachers can conduct multi-content comparison and collaborative feedback to enhance classroom interaction and learning outcomes. For example, in a regular classroom, teachers can simultaneously display the screen content of multiple students, comparing their problem-solving approaches in real time, helping students learn from each other and identify differences in understanding. In large lectures, teachers can collect student feedback through online voting tools and aggregate screen content from different groups for discussion and analysis to promote in-depth intellectual exchange. In remote teaching in remote areas, students can answer orally through microphones, and teachers can use speech recognition technology to convert this speech into text to understand students' viewpoints or questions. Teachers can then combine this content with the screen content shared by students to provide more targeted feedback. For example, if a student displays their problem-solving process on screen, the teacher can directly point out errors in their thinking or provide further explanations based on the student's voice feedback.

[0124] Furthermore, teachers can annotate students' screen content in real time, providing specific suggestions, while students can also provide feedback, thus achieving two-way interaction. Finally, teachers can save screen content from different time periods for historical analysis, compare student progress, and develop personalized learning plans to improve teaching effectiveness. Through these mechanisms, teachers can optimize teaching strategies and promote more efficient student learning.

[0125] S9. Continuously monitor the online status of each device to ensure that all devices in the classroom environment remain synchronized and meet teaching requirements.

[0126] In some embodiments, during real-time monitoring, the performance of each device is comprehensively evaluated by periodically exchanging heartbeat information and monitoring adaptive bitrate, among other multi-dimensional metrics. Heartbeat information reflects the device's online status and network connection quality, while adaptive bitrate displays the current quality of the video stream and bandwidth usage. For example, teachers can monitor the heartbeat frequency of student devices to determine network stability; simultaneously, by observing the adaptive bitrate, if a student's bitrate is low, the teacher can proactively inquire whether the student is experiencing network problems or technical difficulties. Through these multi-dimensional monitoring metrics, teachers can promptly identify and resolve potential technical issues, ensuring smooth classroom interaction.

[0127] Furthermore, by collecting data on device battery levels, CPU usage, and memory consumption, classroom management can be further optimized. For example, teachers can check the battery status of each student's device and promptly determine whether to remind students to charge it to avoid device shutdowns or lag due to insufficient power. If a device's CPU usage is too high, the system can automatically suggest that students close unnecessary applications to free up resources, ensuring smooth video playback and classroom interaction. Through these comprehensive measures, teachers can better maintain the classroom environment and improve teaching effectiveness.

[0128] Furthermore, an intelligent early warning mechanism can be set up to automatically send a notification to the teacher when a device loses heartbeat messages more than three times, indicating that the device may have a network problem. For example, if a student's device experiences frequent heartbeat loss, the teacher can proactively inquire with the student and help them resolve the network connection issue, preventing class interruptions.

[0129] Furthermore, the system can automatically adjust teaching strategies based on real-time monitoring data. For example, if a student's network latency reaches 500 milliseconds, the system can temporarily disable that student's screen sharing function to ensure that other students' experience is not affected. This dynamic adjustment can maintain the overall stability of the classroom.

[0130] Furthermore, heart rate messages and device status data can be collected regularly to generate usage reports. For example, teachers can review the performance reports of each device after class to understand which devices are performing well and which are experiencing problems, thereby optimizing future device configurations and teaching arrangements. Such data analysis can help teachers better adapt to students' needs.

[0131] Furthermore, instant feedback tools can be introduced, allowing students to quickly report their experiences or problems during class. For example, at the end of each class, students can submit their feelings through the in-app feedback button, such as "the screen was choppy" or "the sound was unclear." Teachers can then view this feedback instantly and make targeted adjustments.

[0132] Furthermore, heartbeat messages and device status data can be stored in the cloud for teachers to analyze and replay lessons later. For example, teachers can view classroom monitoring data from the past week to identify periods when devices performed poorly, allowing them to make targeted improvements to teaching methods and technical support.

[0133] The third embodiment of the above method is as follows: S1, activate the teacher's electronic device and the student's electronic device using the same activation code. Each device generates and stores network configuration information containing a unique device identifier.

[0134] Specifically, network configuration information includes the device's MAC address, IP address, and network configuration status (such as subnet mask, gateway, etc.). Furthermore, it can be combined with information such as device identifier (UUID), device type, and device name to enable device activation.

[0135] In some embodiments, teacher electronic devices typically refer to high-configuration electronic devices fixed in specific teaching locations (such as classrooms, lecture halls, etc.) for use by the instructor. These devices generally include large-screen displays, consoles, sound systems, and interactive tools (such as electronic whiteboards or touchscreens). Student electronic devices can be fixed group screens and portable devices distributed throughout the teaching location, designed to interconnect with teacher electronic devices. They can exchange content, such as receiving teaching content from teacher devices, sending interactive feedback, and participating in various interactive activities, such as voting, roll call, quizzes, file uploads, and remote teaching. For example, in a typical classroom, a classroom can be equipped with multiple fixed smart screens (generally up to eight), one for the teacher and the others for group discussions, while also supporting Bring Your Own Device (BYOD), allowing students to use their own mobile phones, tablets, or laptops in class. This approach enhances learning flexibility, allowing students to access teaching resources, submit assignments, and participate in class discussions at any time, thereby increasing interactivity and engagement.

[0136] S2. Send heartbeat messages periodically from the teacher's electronic device to each student's electronic device. Each student's electronic device determines whether the teacher's electronic device and other student electronic devices are online by verifying the timestamp of the heartbeat message.

[0137] Specifically, the heartbeat message includes the MAC address, IP address, and timestamp of the source device (i.e., the teacher's electronic device). Generally, the timestamp refers to the exact time the message was generated and sent within the heartbeat message. This timestamp uses UTC (Coordinated Universal Time) format to ensure time consistency across devices. The timestamp typically includes: transmission time, time format, and time zone information. The transmission time indicates the moment the heartbeat message was generated; the time format uses the ISO 8601 standard for easy time parsing and comparison between devices; and the time zone information ensures accuracy and consistency when devices may be located in different geographical locations.

[0138] Furthermore, if the received heartbeat message timestamp is invalid or no heartbeat message is received within the predetermined time, the device status is marked as "offline," the error is recorded, and a notification is sent to the teacher's electronic device; if the number of consecutive heartbeat timeouts exceeds the threshold, it is marked as "fault," and the corresponding fault handling process is initiated.

[0139] Generally, various algorithms can be used for device status monitoring and fault handling, including: Dynamic threshold algorithms: These dynamically adjust the heartbeat timeout threshold based on network conditions and the device's historical online status to adapt to different usage scenarios and environments. Weighted heartbeat algorithms: These assign different weights to different types of devices, affecting the frequency and tolerance of heartbeat detection. Important devices may have stricter heartbeat monitoring requirements. Event-driven algorithms: These use an event-driven approach to process and monitor heartbeat messages only when the device status changes, thereby reducing unnecessary checks. Machine learning algorithms: These apply machine learning techniques to analyze historical heartbeat data, identify abnormal patterns, and automatically adjust the logic and thresholds of heartbeat detection. Redundancy detection algorithms: These use multiple independent heartbeat signal sources to improve the reliability of fault detection; fault handling is only performed when multiple signal sources simultaneously indicate that the device is "offline."

[0140] This embodiment allows selection of any of the above algorithms based on actual needs to achieve efficient, stable, and high-quality multi-screen interaction. These algorithms not only adapt to different network conditions and teaching scenarios but also effectively improve user experience. Therefore, all of the above algorithms fall within the protection scope of this application, ensuring their application and implementation in multi-screen interaction systems.

[0141] S3. Based on real-time network conditions and the level of interaction in the preset teaching scenario, determine whether the heartbeat information sending frequency meets the requirements. If it does, proceed to step S4; if not, adjust the heartbeat information sending frequency until it meets the requirements.

[0142] Furthermore, in step S3, the heartbeat message sending frequency can be set from 100 milliseconds to 30 seconds. Different frequency values ​​will produce different effects and impacts. For example, more frequent heartbeat messages (e.g., every 1 second) ensure rapid response but increase network load; lower frequency heartbeats (e.g., every 8 seconds) are suitable for low-bandwidth environments and can effectively reduce network pressure. Real-time network conditions generally include factors such as network load, network latency, jitter, and packet loss rate. Network load involves bandwidth utilization and the number of connections; high load will lead to a decrease in data transmission speed. Network latency includes transmission latency, processing latency, and queuing latency; excessively high latency may affect the performance of real-time applications. Meanwhile, jitter reflects changes in latency, and packet loss rate refers to the proportion of data packets lost during transmission; a high packet loss rate will lead to incomplete information and affect user experience. The heartbeat message sending frequency will be adjusted according to the above real-time network conditions and the preset level of interaction in the teaching scenario to adapt to different operating conditions and needs. Therefore, the heartbeat message sending frequency should be reasonably selected according to network conditions and teaching scenarios to ensure that both timely monitoring of device status and teaching quality can be guaranteed in different scenarios. In this embodiment, the heartbeat message is sent every 6 seconds.

[0143] Generally, the level of interactivity in a teaching setting refers to the frequency and quality of communication between teachers and students, specifically including real-time question-and-answer sessions, the speed of student feedback, participation in group discussions, and the frequency of interaction using electronic devices. High interactivity indicates frequent communication and participation, while low interactivity means less communication. This indicator helps adjust technology support strategies to ensure the effectiveness of teaching. Therefore, this indicator can be preset to adjust the frequency of heartbeat message transmission.

[0144] Furthermore, taking a typical classroom as an example, the level of interaction is presumably high, with more than 10 questions and answers or interactions between teachers and students, and a feedback response time of less than 1 minute. In contrast, in large lectures, due to the large number of participants, the level of interaction is presumably moderate, with an interaction frequency between 5 and 10 times and a feedback response time between 1 and 3 minutes. Finally, in remote teaching scenarios in remote areas, due to network limitations and other factors, the level of interaction is presumably low, with fewer interactions, such as fewer than 5 times, and a feedback response time exceeding 3 minutes.

[0145] Furthermore, when adjusting the heartbeat message sending frequency in step S3, it can be dynamically adjusted based on real-time network conditions and the preset level of interaction. In a typical classroom, where the preset level of interaction is high and network conditions are good, the heartbeat message sending frequency can be increased to ensure good device performance and high-quality transmission of teaching content. Secondly, in large lectures, where the preset level of interaction is moderate, the heartbeat frequency can be appropriately increased if network conditions are good to maintain the stability of content transmission; if network conditions are poor, the heartbeat frequency should be decreased to reduce network load. Finally, for remote teaching in remote areas, even with a lower preset level of interaction, the heartbeat frequency should be reduced if network bandwidth is limited to ensure smooth transmission of teaching content under limited network conditions and to guarantee teaching quality.

[0146] This adjustment strategy, which combines real-time network conditions with preset levels of interaction, helps to effectively balance the need for real-time monitoring with network load, thereby optimizing teaching effectiveness.

[0147] S4. Upon receiving a broadcast command from the teacher's electronic device, each student's electronic device joins a multicast group identified by a multicast address and port to receive the teacher's screen content. The teacher's electronic device initiates screen capture using Android's MediaProjection API, encodes the screen content using a hardware encoder, and sends the encoded frame data to the multicast group. Each student's electronic device listens to the multicast stream, decodes the video data, and displays the teacher's screen content on the student's electronic device.

[0148] In some embodiments, step S4 may be further as follows: S401: The teacher's electronic device joins the multicast address A and binds to the multicast port a1, and sends instructions to all student electronic devices in the teaching scenario. The instruction information includes the MAC address of the device, the IP address of the device, the MAC address of the target device, the IP address of the target device, the multicast address A, the multicast port a1, the timestamp (in UTC format), the action command, and some optional parameters.

[0149] S402: After receiving the instruction, the student electronic device creates a Surface instance for displaying the interface, and simultaneously creates a hardware decoder supporting H.265, binding the Surface instance to the decoder's output. At this point, it adds multicast address A to multicast port a1 and begins listening for video stream data. If video data is detected, it starts the decoding task.

[0150] S403: The teacher's electronic device requests a screen recording instance by calling the Android system function `((MediaProjectionManager)getSystemService(Context.MEDIA_PROJECTION_SERVICE)).createScreenCaptureIntent()` and requests user authorization. An encoder is created using the Android system's MediaCodec, followed by an encoding input area Surface (the encoder controls the quality of screen recording, such as frame rate and bitrate). At this point, a virtual display is generated from the screen recording instance, and the virtual display is associated with the encoding input area Surface. Data from the virtual display is input into the encoding input area Surface, and the encoder is started. The real-time screen image is then obtained from the encoder's callback function `onOutputBufferAvailable`.

[0151] S404: Encodes each frame output by the encoder in real time using H265 and ensures video quality based on encoding parameters (such as resolution, frame rate, etc.).

[0152] S405: Encapsulates the H265 encoded frame data into Nalu units, disassembles and packets according to rules, and transmits the packets using a proprietary transmission protocol.

[0153] S406: After the student electronic device in step S402 listens to the transmitted data stream, it merges the received packet data into frames and performs integrity verification.

[0154] S407: The complete frame data is sent to the decoder of the group screen in step S402 for decoding. At this time, the teacher's screen image is displayed on the group screen.

[0155] In some embodiments, step S406 may employ various integrity verification algorithms to ensure the reliability of data transmission during multi-screen interaction. Specifically, these include: Cyclic Redundancy Check (CRC), used to detect any bit errors in data packets sent from the teacher's electronic device to the student's electronic device, ensuring data integrity; Hash functions (such as SHA-256 or MD5) that generate hash values ​​for transmitted frame data, allowing the receiving student electronic device to verify data integrity by comparing the calculated hash value with the sent hash value; Parity checks providing a simple and effective method for detecting single-bit errors, especially important in scenarios requiring rapid response; Implementing packet sequence numbers allowing the student electronic device to track the order of received data packets, thereby identifying lost or duplicate packets; and finally, Forward Error Correction (FEC) sending redundant data, enabling the student device to reconstruct complete frames even in the event of data loss.

[0156] This embodiment allows selection of any of the above-mentioned verification algorithms based on actual needs to achieve efficient, stable, and high-quality multi-screen interaction. These algorithms not only adapt to different network conditions and teaching scenarios but also effectively improve user experience. Therefore, all of the above algorithms fall within the protection scope of this application, ensuring their application and implementation in multi-screen interaction systems.

[0157] In some embodiments, encoding and decoding can employ different decoders such as H.264, H.265, VP8, VP9, ​​and AV1. Specifically, this embodiment employs an H.265 encoder, which, through the application of an optimized compression algorithm, can significantly reduce bandwidth requirements while maintaining high image quality.

[0158] S5. Based on the image quality of the electronic device and the determined heartbeat information transmission frequency, further determine whether the adaptive bitrate meets the requirements. If it does, proceed to step S6; if it does not, adjust the adaptive bitrate until the image quality requirements of the teaching content are met.

[0159] Further, in step S5, when determining whether the adaptive bitrate meets the requirements, the following steps are taken: First, the highest resolution supported by the device is evaluated. For example, a teacher's electronic device may support 4K, while a student's electronic device may support 1080p. The clarity and smoothness of playback are monitored through a real-time feedback mechanism, and a comprehensive evaluation is performed in conjunction with received image quality data (such as user feedback, playback stutters, and video quality metrics). Second, online status and network latency are monitored through periodically sent heartbeat messages. If the heartbeat message latency is less than 200 milliseconds and the packet loss rate is low, it indicates good network conditions. In this case, the adaptive bitrate can be appropriately increased, for example, by selecting 1080p (16Mbps) to improve image quality. Conversely, if the heartbeat latency exceeds 500 milliseconds or the packet loss rate increases, the bitrate needs to be reduced, for example, by adjusting it to 720p (8Mbps) to ensure smooth playback. Finally, the received image quality metrics and heartbeat information are considered together, and corresponding thresholds are set to dynamically and in real-time adjust the adaptive bitrate, thereby optimizing the user experience of multi-screen interaction.

[0160] In some embodiments, adaptive bitrate (ABR) streaming is configured to target different resolutions and bitrates, typically ranging from 120p to 4K and from 1Mbps to 40Mbps, respectively. The quality of the teaching content is dynamically adjusted based on network conditions to ensure the best viewing experience. These settings can be configured via the teacher's electronic device, capturing the teacher's screen content in real time and automatically adjusting the video stream's resolution and bitrate based on current network bandwidth and terminal device conditions. In this embodiment, the adaptive bitrate could be: a resolution of 720p and a bitrate of 8 Mbps.

[0161] S6. Based on the adjusted heartbeat information transmission frequency and adaptive bitrate, further determine whether the multicast protocol used is suitable. If it is suitable, proceed to step S7; if it is not suitable, adjust the multicast protocol until the image quality requirements of the teaching content are met.

[0162] Furthermore, when determining whether a multicast protocol meets the requirements, the following points should be considered: First, the frequency of heartbeat message transmission reflects the stability and load of the network. A high heartbeat message transmission frequency indicates a good network condition, making it suitable to choose an efficient multicast protocol, such as Internet Group Management Protocol (IGMP), Simple Multicast Protocol (SMP), or User Datagram Protocol (UDP), to ensure timely data transmission and a high-quality viewing experience. Conversely, a low heartbeat message transmission frequency indicates a poor network condition, requiring the selection of a more adaptable multicast protocol, such as Protocol Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), or Real-Time Transport Protocol (RTP), to ensure effective data transmission even under unstable network conditions.

[0163] Secondly, the adaptive bitrate directly affects the quality of the video stream. For example, if the current adaptive bitrate is high (such as 4K (20Mbps) or 1080p (16Mbps)), a multicast protocol that supports higher bandwidth, such as Internet Group Management Protocol (IGMP) or Multiprotocol Label Switching (MPLS), needs to be selected to ensure the quality of the teaching content and transmission efficiency. For lower adaptive bitrates (such as 720p (8Mbps)), it is reasonable to choose simpler multicast protocols such as Protocol Independent Multicast (PIM) or Distance Vector Multicast Routing Protocol (DVMRP), because these protocols can work effectively in medium or low bandwidth environments.

[0164] Ultimately, by comprehensively evaluating the transmission frequency and adaptive bitrate of heartbeat information, corresponding selection criteria were set to ensure that the adopted multicast protocol could effectively support the needs of multi-screen interaction in different teaching scenarios, thereby improving user experience and teaching effectiveness. This allows for dynamic adjustment of the multicast protocol to adapt to different network environments and device characteristics, thus guaranteeing efficient data transmission and reliable teaching content quality.

[0165] In some embodiments, the multicast protocol may be, but is not limited to: Internet Group Management Protocol (IGMP), Protocol Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), Multiprotocol Label Switching (MPLS), Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP), Simple Multicast Protocol (SMP), and Source Specific Multicast (SSM). Based on different teaching scenarios and usage areas (e.g., regular classrooms, high-definition lectures, or large-scale events, such as remote cross-border or remote areas, rural areas, etc.), and combined with the heartbeat information transmission frequency and adaptive rate code, the above-mentioned multicast protocol is rationally selected to meet the requirements of efficient transmission, high-quality image quality, and multi-screen interaction, thereby improving the teaching experience. Specifically, in this embodiment, the multicast protocol adopted is the Distance Vector Multicast Routing Protocol (DVMRP).

[0166] In some embodiments, the teacher's electronic device is responsible for creating a multicast stream and broadcasting the screen content to the student's electronic device according to a selected multicast protocol.

[0167] S7. The teacher's electronic device executes step S4 again to check whether the image quality of the teaching content meets the requirements. If it does, proceed to step S8; otherwise, proceed to step S5 again.

[0168] Furthermore, the teacher's electronic device executes step S4 again and checks whether the image quality received by the student's electronic device meets the requirements. Specifically, if the image quality meets the requirements, the system proceeds to step S8, where the teacher can request a specific student device to share its screen content. If the image quality does not meet the requirements, the system returns to step S5 to readjust the adaptive bitrate, and then proceeds to step S6 to further adjust the multicast protocol. After multiple adjustments, the system ensures that all devices can synchronously receive high-quality teaching content, improving classroom interaction.

[0169] S8. The teacher's electronic device sends a request, specifying a particular student's electronic device to send its screen content via unicast. Upon receiving the request, the student's electronic device uses Android's MediaProjection API to capture its screen content and encodes it into the format required by the teacher. After encoding, the student's electronic device transmits the encoded content to the teacher's electronic device. The teacher's electronic device receives and decodes this content, ultimately displaying the student's screen content on its own screen.

[0170] In some embodiments, multiple request methods are associated with different teaching scenarios, allowing teachers to access students' screen content in various ways. Specifically, in regular classrooms, teachers can use instant messaging tools (such as WeChat groups, QQ, etc.) to send requests, and students can quickly respond and share their screens. In large lecture scenarios, teachers can utilize dedicated mobile applications (such as the official app of the teaching platform) that provide a "Request Screen Sharing" button, allowing students to send requests simply by clicking. Furthermore, the application can integrate real-time feedback, allowing students to select the application or screen area to share after clicking the request, simplifying the process and improving classroom interaction efficiency. Simultaneously, the application displays the request status in real time, ensuring smooth communication between teachers and students. In remote teaching in remote areas, teachers can use voice recognition technology to request students to share screen content via voice commands. Student devices can recognize the teacher's voice requests in real time and provide feedback, reducing reliance on complex operations and enhancing the convenience of interaction. In summary, these different request mechanisms can be flexibly applied according to specific teaching scenarios, improving the interactivity and effectiveness of teaching.

[0171] In some embodiments, after receiving students' screen content, teachers can conduct multi-content comparison and collaborative feedback to enhance classroom interaction and learning outcomes. For example, in a regular classroom, teachers can simultaneously display the screen content of multiple students, comparing their problem-solving approaches in real time, helping students learn from each other and identify differences in understanding. In large lectures, teachers can collect student feedback through online voting tools and aggregate screen content from different groups for discussion and analysis to promote in-depth intellectual exchange. In remote teaching in remote areas, students can answer orally through microphones, and teachers can use speech recognition technology to convert this speech into text to understand students' viewpoints or questions. Teachers can then combine this content with the screen content shared by students to provide more targeted feedback. For example, if a student displays their problem-solving process on screen, the teacher can directly point out errors in their thinking or provide further explanations based on the student's voice feedback.

[0172] Furthermore, teachers can annotate students' screen content in real time, providing specific suggestions, while students can also provide feedback, thus achieving two-way interaction. Finally, teachers can save screen content from different time periods for historical analysis, compare student progress, and develop personalized learning plans to improve teaching effectiveness. Through these mechanisms, teachers can optimize teaching strategies and promote more efficient student learning.

[0173] S9. Continuously monitor the online status of each device to ensure that all devices in the classroom environment remain synchronized and meet teaching requirements.

[0174] In some embodiments, during real-time monitoring, the performance of each device is comprehensively evaluated by periodically exchanging heartbeat information and monitoring adaptive bitrate, among other multi-dimensional metrics. Heartbeat information reflects the device's online status and network connection quality, while adaptive bitrate displays the current quality of the video stream and bandwidth usage. For example, teachers can monitor the heartbeat frequency of student devices to determine network stability; simultaneously, by observing the adaptive bitrate, if a student's bitrate is low, the teacher can proactively inquire whether the student is experiencing network problems or technical difficulties. Through these multi-dimensional monitoring metrics, teachers can promptly identify and resolve potential technical issues, ensuring smooth classroom interaction.

[0175] Furthermore, by collecting data on device battery levels, CPU usage, and memory consumption, classroom management can be further optimized. For example, teachers can check the battery status of each student's device and promptly determine whether to remind students to charge it to avoid device shutdowns or lag due to insufficient power. If a device's CPU usage is too high, the system can automatically suggest that students close unnecessary applications to free up resources, ensuring smooth video playback and classroom interaction. Through these comprehensive measures, teachers can better maintain the classroom environment and improve teaching effectiveness.

[0176] Furthermore, an intelligent early warning mechanism can be set up to automatically send a notification to the teacher when a device loses heartbeat messages more than three times, indicating that the device may have a network problem. For example, if a student's device experiences frequent heartbeat loss, the teacher can proactively inquire with the student and help them resolve the network connection issue, preventing class interruptions.

[0177] Furthermore, the system can automatically adjust teaching strategies based on real-time monitoring data. For example, if a student's network latency reaches 500 milliseconds, the system can temporarily disable that student's screen sharing function to ensure that other students' experience is not affected. This dynamic adjustment can maintain the overall stability of the classroom.

[0178] Furthermore, heart rate messages and device status data can be collected regularly to generate usage reports. For example, teachers can review the performance reports of each device after class to understand which devices are performing well and which are experiencing problems, thereby optimizing future device configurations and teaching arrangements. Such data analysis can help teachers better adapt to students' needs.

[0179] Furthermore, instant feedback tools can be introduced, allowing students to quickly report their experiences or problems during class. For example, at the end of each class, students can submit their feelings through the in-app feedback button, such as "the screen was choppy" or "the sound was unclear." Teachers can then view this feedback instantly and make targeted adjustments.

[0180] Furthermore, heartbeat messages and device status data can be stored in the cloud for teachers to analyze and replay lessons later. For example, teachers can view classroom monitoring data from the past week to identify periods when devices performed poorly, allowing them to make targeted improvements to teaching methods and technical support.

[0181] In summary, the optimizations to the adaptive bit rate, multicast protocol, and heartbeat message transmission frequency in the three embodiments are adapted to different teaching scenarios, as shown in Table 1:

[0182]

[0183] Therefore, this method significantly improves the effectiveness of multi-screen interaction in different teaching scenarios by optimizing the heartbeat information transmission frequency, adaptive bitrate, and multicast protocol. Specifically, the effective combination of heartbeat information transmission frequency, adaptive bitrate, and multicast protocol provides optimal technical support for different scenarios. In high-demand scenarios (such as large lectures or events), the configuration of Example 1 (4K (20Mbps), IGMP, heartbeat information transmission frequency of 1 second) ensures efficient synchronization and high-definition display of multiple devices, while monitoring device status in real time, minimizing network latency and the risk of device disconnection. In standard classroom scenarios, Example 2 (1080 (16Mbps), PIM, heartbeat information transmission frequency of 3 seconds) ensures stable and efficient transmission of teaching content through appropriate parameters, meeting the needs of classroom interaction. In low-bandwidth environments, Example 3 (720p (8Mbps), DVMRP, heartbeat information transmission frequency of 6 seconds) effectively reduces network transmission pressure by lowering the heartbeat frequency and adaptive bitrate, ensuring stable interactive smoothness and guaranteeing the smooth progress of teaching.

[0184] Therefore, the flexible combination of the above three elements enables the system to be precisely optimized for teaching scenarios in different environments and regions, thereby improving classroom interactivity and the efficiency of teaching content transmission, and ensuring the best user experience under various network environments and device conditions.

[0185] It should be understood that the steps shown above can be rearranged, added, or deleted. For example, the steps described in this application can be performed in parallel or sequentially, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0186] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A multi-screen interaction method based on dynamic network adjustment suitable for multiple teaching scenarios, characterized in that, Includes the following steps: S1. Activate both teacher's and student's electronic devices using the same activation code; S2. Periodically send heartbeat information from the teacher's electronic device to each of the student's electronic devices to verify whether each device is online; S3. Determine whether the transmission frequency of the heartbeat information meets the requirements. If it does, proceed to step S4. If it does not meet the requirements, adjust the frequency of heartbeat information transmission and record the adjustment details; The adjustment of the heartbeat information transmission frequency includes: dynamically adjusting the heartbeat information transmission frequency according to real-time network conditions and the preset level of interaction in the teaching scenario; the preset level of interaction in the teaching scenario represents the frequency and quality of communication between teachers and students, including: real-time question and answer, the speed of student feedback, the degree of participation in group discussions, and the frequency of interaction using electronic devices. S4. The teacher's electronic device sends teaching content to each student's electronic device via a multicast protocol; S5. Determine whether the adaptive bit rate meets the requirements. If it does, proceed to step S6. If it does not, adjust the adaptive bit rate and record the adjustment. S6. Based on the heartbeat information transmission frequency and adaptive bit rate, determine whether the multicast protocol meets the requirements. If it does, proceed to step S7; if it does not, select a multicast protocol reasonably from the multicast protocols supported by the device and record the selection. S7. The teacher's electronic device executes step S4 again to check whether the image quality displayed by the student's electronic device meets the requirements. If it does, proceed to step S8; if it does not, proceed to step S5 again. S8. The teacher electronic device sends a request to the designated student electronic device. Upon receiving the request, the student electronic device transmits its screen content to the teacher electronic device. S9. Continuously monitor the online status of each of the aforementioned electronic devices to ensure that all devices in the classroom environment remain online and meet teaching requirements.

2. The method according to claim 1, characterized in that, The adjustment of the adaptive bitrate includes: The adaptive bitrate is dynamically adjusted based on the image quality of the electronic device and the adjusted heartbeat information transmission frequency.

3. The method according to claim 2, characterized in that, The selection of a suitable multicast protocol from those supported by the device is used to further optimize the quality of the teaching content.

4. The method according to claim 1, characterized in that, In step S2, verifying whether each device is online includes: If the timestamp of the received heartbeat information is invalid or no heartbeat information is received within the predetermined time, the status of the device is marked as "offline", the error is recorded and a notification is sent to the teacher's electronic device; if the number of consecutive heartbeat timeouts exceeds the threshold, it is marked as "fault" and the corresponding fault handling process is initiated.

5. The method according to claim 1, characterized in that, The teaching scenarios include: regular classrooms, large lectures, or remote teaching in remote areas.

6. The method according to claim 1, characterized in that, The adaptive bitrate has a resolution range of 120p to 4K and a bitrate range of 1 Mbps to 40 Mbps.

7. The method according to claim 1, characterized in that, The heartbeat information is sent at a frequency ranging from 100 milliseconds to 30 seconds.

8. The method according to claim 1, characterized in that, Step S4 further includes: the teacher's electronic device requests screen recording by calling an Android system function and creates an encoder.

9. The method according to claim 8, characterized in that, The encoder is H.265.

Images