Video sending method and device, electronic equipment and medium
Patent Information
- Application Number
- CN202210663157.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-06-13
- Publication Date
- 2026-10-09
- Estimated Expiration
- 2042-06-13
AI Technical Summary
如在监控场景中,会根据每个用户的请求,向摄像装置请求对应的视频,这样一来,会对视频源进行频繁的视频调取,使得视频源承接了大量的视频请求而导致宕机,并且也浪费了较多的网络资源
[0040]In this embodiment, for multiple viewing terminals with overlapping time periods, the video of the overlapping time period can be sent to the multiple viewing terminals through a first channel; in response to the target viewing terminal sending an advance playback request for the overlapping time period, a second channel is created based on the playback start time of the advance playback request; the video starting at the playback start time is sent to the target viewing terminal through the second channel.
Smart Images

Figure CN115209190B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network communication technology, and in particular to a video transmission method, apparatus, electronic device, and medium. Background Technology
[0002] Currently, with the development of network technology, users are accustomed to watching videos online. These videos include live streams and surveillance footage, as well as recorded videos, such as movies and TV dramas. Generally, the server sends the video requested by the user to the user's viewing device.
[0003] In related technologies, when providing video scheduling services to user viewing terminals, the system typically requests the corresponding video from the video source based on the needs of each user's viewing terminal. For example, in a surveillance scenario, the system requests the corresponding video from the camera device based on each user's request. This results in frequent video retrieval from the video source, causing the video source to be overwhelmed by a large number of video requests, leading to system crashes and wasting significant network resources.
[0004] To reduce the load on the video source, a shared channel approach is provided, where multiple users can use the same channel to watch videos. In this way, the video only needs to be scheduled to the video source once and sent to multiple users. However, in this approach, if one user in the same channel drags the progress bar forward, meaning that the user wants to watch the later part of the video ahead, the video will be retrieved from the dragged time point. This causes other users to start watching from the re-retrieved video, thus missing some video frames. Summary of the Invention
[0005] In view of the above problems, embodiments of the present invention provide a video transmission method, apparatus, electronic device, and storage medium to overcome or at least partially solve the above problems.
[0006] A first aspect of this invention discloses a video transmission method, the method comprising:
[0007] For multiple viewing terminals where the requested time period overlaps with the target time period, the video of the overlapping time period is sent to each of the multiple viewing terminals through the first channel corresponding to the target time period;
[0008] In response to an advance playback request sent by a target viewing terminal among the multiple viewing terminals for the overlapping time period, a second channel is created based on the playback start time of the advance playback request;
[0009] The video, starting at the specified playback start time, is sent to the target viewing device via the second channel.
[0010] Optionally, when there are multiple target viewing terminals, in response to an advance playback request sent by one of the target viewing terminals, a second channel is created based on the playback start time of the advance playback request, including:
[0011] In response to advance playback requests sent by multiple target viewing terminals, a corresponding second channel is created according to the playback start time of each advance playback request;
[0012] Among them, target viewing terminals whose playback start times are within a preset gap correspond to the same second channel.
[0013] Optionally, the method further includes:
[0014] When the release condition of the first channel is met, the first channel is released;
[0015] The second channel is released when the release condition of the second channel is met.
[0016] Optionally, the first channel is a live streaming channel. When the release conditions for the first channel are met, the first channel is released, including:
[0017] If the first duration between the current live broadcast time and the playback start time of the first channel is less than the second duration between the playback start time and the playback end time of the overlapping period, the first channel is released when the current live broadcast time of the first channel reaches the playback start time.
[0018] The method further includes:
[0019] The receiving end in the first channel is migrated to the second channel.
[0020] Optionally, the method further includes:
[0021] If the first channel is released, check if the second channel exists;
[0022] If so, if there are still viewers in the first channel who have not finished watching, then the viewers who have not finished watching will be moved to the second channel.
[0023] Optionally, the method further includes:
[0024] If the second channel is released, check whether the first channel still exists;
[0025] If so, the video cached in the second channel is directed to the first channel; wherein the video cached in the second channel is obtained by caching the video data sent to the target viewing terminal;
[0026] When the playback time of the video data currently retrieved in the first channel is the playback start time, multiple videos required by each of the viewing terminals are extracted from the cached videos.
[0027] Optionally, the first channel is a live streaming channel, and the method further includes:
[0028] In response to the advanced playback request, determine the temporal relationship between the playback start time and the current live broadcast time of the first channel;
[0029] Creating a second channel based on the playback start time of the aforementioned advanced playback request includes:
[0030] If the playback start time is later than the current live broadcast time, then the second channel is created based on the playback start time.
[0031] A second aspect of this application provides a video transmitting apparatus, the apparatus comprising:
[0032] The first sending module is used to send videos of the overlapping time periods to multiple viewing terminals through the first channel corresponding to the target time period.
[0033] A creation module is established in response to an advance playback request sent by a target viewing terminal among the multiple viewing terminals for the overlapping time period, and a second channel is created based on the playback start time of the advance playback request.
[0034] The second sending module is used to send the video starting at the playback start time to the target viewing terminal through the second channel.
[0035] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0036] Memory, used to store computer programs;
[0037] The processor, when executing a program stored in memory, implements the video transmission method as described in the first aspect of the embodiments of the present invention.
[0038] This invention also discloses a computer-readable storage medium storing a computer program that causes a processor to execute the video transmission method as described in the first aspect of this invention.
[0039] The embodiments of the present invention have the following advantages:
[0040] In this embodiment, for multiple viewing terminals with overlapping time periods, the video of the overlapping time period can be sent to the multiple viewing terminals through a first channel; in response to the target viewing terminal sending an advance playback request for the overlapping time period, a second channel is created based on the playback start time of the advance playback request; the video starting at the playback start time is sent to the target viewing terminal through the second channel.
[0041] By adopting the technical solution of this application, on the one hand, since multiple viewing terminals with overlapping time periods between the requested and target time periods can send videos of the overlapping time periods through the first channel, videos of the overlapping time periods can be sent to multiple viewing terminals through the same channel. Therefore, for videos of the overlapping time periods, it is unnecessary to request video retrieval from the video source for each viewing terminal, thereby reducing the load on the video source. On the other hand, based on the fact that videos of the overlapping time periods are sent to multiple viewing terminals through the same channel, for the advanced playback request of the target viewing terminal in the first channel, a new second channel can be created to send the fast-forwarded video to the target viewing terminal. This satisfies the viewing needs of viewing terminals that require fast-forwarding, without affecting the normal viewing of other viewing terminals in the first channel, ensuring that other viewing terminals do not miss video footage.
[0042] On the other hand, since the first channel can be used to send videos of overlapping time periods to multiple viewing terminals, there is no need to create a new channel for viewing terminals that have overlapping time periods with the requested time period. This allows multiple viewing terminals to share the channel, thereby saving channel resources and improving the utilization rate of channel resources. Attached Figure Description
[0043] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0044] Figure 1 This is an implementation environment diagram of the video sending method according to an embodiment of the present invention;
[0045] Figure 2 This is a flowchart of the steps of a video sending method according to an embodiment of the present invention;
[0046] Figure 3 This is a schematic diagram illustrating the process of sending video data for a specific time period to different terminals in turn within the same channel, as described in an embodiment of the present invention.
[0047] Figure 4 This is a schematic diagram of the structure of a video sending device according to an embodiment of the present invention. Detailed Implementation
[0048] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0049] In related technologies, online video viewing includes live video and recorded video. Generally, this application targets video viewing with specific time slot requirements. For example, when there is a need to view video captured by a camera device, the video captured by the camera device will be retrieved. The retrieved video is generally based on the time slot requested by the viewing end, specifically retrieving video from the corresponding time slot. For example, if the user's viewing end wants to watch video captured by the camera device between 15:00 and 16:00, then the video captured between 15:00 and 16:00 will be retrieved and sent to the viewing end. Of course, depending on the viewing time slot, the retrieved video can be live video captured by the camera device, or it can be video recorded and stored on the viewing end device in the control room.
[0050] In related technologies, it is necessary to initiate a retrieval request to the camera device and establish a new channel for each viewing end. This results in the waste of channel resources, and each end will re-retrieve video from the dispatch room or camera device. This not only wastes channel resources but also increases the load on the viewing end equipment of the camera device or dispatch room.
[0051] To conserve channel resources, a single channel is typically used to send video for a target time slot to multiple viewers. However, this method is similar to live streaming, where all viewers in the channel are watching live data, making it impossible to tailor video viewing to individual needs. Consequently, when one viewer requests advance playback, the video watched by other viewers will be moved forward by a playback time. For example, for a video scheduled from 15:00 to 16:00, if the live stream is currently at 15:10, and user 1 drags to 15:30, it will request the video source to start playing from 15:30. The video in that channel will then jump to 15:30. As a result, users 2 and 3 will see their video feed jump directly from 15:10 to 15:30, causing them to miss the video content between 15:10 and 15:30.
[0052] In view of this, the applicant proposes a solution that can reduce the load on video source devices and meet the viewing needs of different users, especially the fast-forwarding needs of individual users. The core concept is as follows: for multiple viewing terminals whose requested time period overlaps with the target time period, the video of the overlapping time period is sent to multiple viewing terminals through a channel of the target time period. When a request for advance playback is received from the target viewing terminal for the overlapping time period, a second channel is created; the video starting from the playback start time is sent to the target viewing terminal through the second channel.
[0053] Therefore, for a user's request to advance playback among users sharing the same channel, a new channel can be created to send the fast-forwarded video to the corresponding user. In this way, the video viewing needs of users who need to fast forward can be met, while other users can continue watching the video in the original channel, so they will not miss the video.
[0054] Reference Figure 1 The diagram illustrates an implementation environment of the video transmission method according to an embodiment of this application. Figure 1 As shown, the system includes: a server, camera devices, a control room, and multiple viewing terminals. Each camera device is typically connected to its corresponding control room. When the server needs to retrieve video from the camera device, if it needs to capture real-time video, it can retrieve it from the camera device; if it needs to capture recorded video, it can retrieve it from the terminal device in the control room. The terminal device in the control room generally stores the recorded video from the camera device. Typically, the video is stored on a daily basis. For example, if the camera device started operating on January 1st and the current date is January 3rd, then the control room will store the video captured on January 1st and January 2nd. The video from January 3rd will remain stored in the camera device because it is still recording.
[0055] Among them, multiple viewing terminals are located on the user side, which are used to request the video captured by the camera device from the server and play the received video.
[0056] Because the hardware of the camera devices themselves has limited support for large-scale video scheduling, and the terminal equipment in the scheduling room is generally limited in configuration and cannot handle a large number of video scheduling requests in a short period of time, and the channel resources of the network are also generally limited. For example, when transmitting data within a video network, it is generally necessary to provide a corresponding video network virtual terminal (hereinafter referred to as virtual viewing terminal) for each viewing end. One virtual terminal generally identifies a viewing end within the video network, and data is transmitted through the virtual terminal corresponding to the viewing end. Thus, when multiple different viewing ends request the same cached video, establishing a video transmission channel for each viewing end would require many virtual terminals, but the number of virtual terminals within a video network is limited.
[0057] Therefore, on the one hand, there is the issue of conserving channel resources; on the other hand, even after conserving channel resources, other users may miss the video feed when a user fast-forwards. In view of this, the video transmission method of this application is proposed to improve upon the aforementioned problems.
[0058] by Figure 1 Taking the aforementioned implementation environment as an example, the video sending method of this application embodiment will be introduced. Of course, in practical applications, this video sending method can be used for more than just... Figure 1 In the implementation environment, it is also applicable to other video service scenarios, such as watching live product broadcasts or watching TV series (a series can be considered as a time segment).
[0059] Reference Figure 2 The diagram illustrates a flowchart of the video transmission method according to an embodiment of this application. Specifically, the following steps can be performed by the server: Figure 2 As shown, it includes the following steps:
[0060] Step S201: For multiple viewing terminals where the requested time period overlaps with the target time period, send the video of the overlapping time period to the multiple viewing terminals through the first channel corresponding to the target time period.
[0061] In this embodiment, multiple viewing terminals have their own requested time periods. When the requested time periods of multiple viewing terminals overlap with the target time period of the first channel, the overlapping time period is called the overlapping time period. Thus, the video of the overlapping time period can be sent to multiple viewing terminals through the first channel.
[0062] In one specific implementation, when a video for a given time period is requested for the first time, the video for that time period can be scheduled to the corresponding viewing end through a channel. After the channel is created, if there are multiple viewing ends whose requested time period overlaps with the time period of the channel, the corresponding overlapping time period video can be sent directly to multiple viewing ends through the channel.
[0063] For example, if the target time period is 15:00-16:00, and multiple viewing terminals include Viewer 1, Viewer 2, and Viewer 3, with Viewer 1 requesting a time period of 14:00-15:30, Viewer 2 requesting a time period of 15:00-15:30, and Viewer 3 requesting a time period of 15:30-16:30, then the overlapping time periods for Viewer 1 and Viewer 2 are 15:00-15:30, and the overlapping time period for Viewer 3 is 15:30-16:00. Therefore, the first channel sends video from 15:00-15:30 to Viewer 1 and Viewer 2, and sends video from 15:30-16:00 to Viewer 3.
[0064] In one alternative example, different channels can be used to schedule video for different time slots; that is, different channels will send video for different time slots to the corresponding viewers. The time slots corresponding to each channel (hereinafter referred to as channel time slots) can be independent of each other, so the video sent by multiple channels is separated on the timeline. For example, three channels, each corresponding to a different time slot, can be independent of each other, such as 15:00-16:00, 14:00-15:00, and 12:00-13:00 respectively. In this way, each channel can be responsible for sending video for one time slot.
[0065] like Figure 1 As shown, when sending videos of overlapping time periods through the channel, in the case of a pre-recorded video, the server can retrieve the video of the corresponding time period from the terminal device in the dispatch room, and then send the retrieved video to multiple viewing terminals, enabling multiple viewing terminals to watch the recorded video; in the case of a live video, the server can retrieve the video captured in real time by the camera device, and then broadcast the retrieved video to multiple viewing terminals, enabling multiple viewing terminals to watch the live video.
[0066] In one optional example, for each viewing device, the video of the overlapping period between the requested and target periods can be sent using the first channel, while for the video of the periods outside the overlapping period within the requested time frame, a new channel can be created for sending. Alternatively, in another optional example, the video of the overlapping period between the requested and target periods can be sent using the first channel, as well as the video of the periods outside the overlapping period within the requested time frame can be sent via the first channel.
[0067] In one alternative example, during the process of sending overlapping video segments to multiple viewers via the first channel, the first channel can be used in turn to send the video each viewer needs at that moment. That is, at any given time, only one viewer occupies the first channel to receive the video it needs. Each time a viewer receives video data, the received video data is offset from its own start time within the target time segment. For example, for viewer 2, its start time is 15:30, and for viewer 3, its start time is 15:00.
[0068] Reference Figure 3The diagram illustrates how video data for different time periods is sent to different terminals in turn on the same channel. For example, the first channel is for the video from 15:00 to 16:00. Viewer 4 is a terminal with live streaming needs. The time period requested by viewer 2 overlaps with 15:00 to 16:00, and the overlapping time period is 15:00 to 15:30. The time period requested by viewer 3 overlaps with 15:00 to 16:00, and the overlapping time period is 15:30 to 16:00.
[0069] The current playback time is 15:10. Before 15:10, live video is sent to viewer 4. At the playback time of 15:10, video data from 15:10 to 15:11 is sent to viewer 4 through the first channel. After that, video data from 15:00 to 15:01 is sent to viewer 2. Then, video data from 15:11 to 15:12 is sent to viewer 4. After that, video data from 15:02 to 15:03 is sent to viewer 2, and so on. When the playback time of 15:30 arrives, the video data from 15:30 to 16:00 is broadcast live to viewer 4 and viewer 3 through the first channel. During the live broadcast, for viewer 2, the video starting from 15:20 is still sent according to the previous pattern.
[0070] It can be seen that in this mode, if a viewing terminal, say viewing terminal 4, jumps directly to 15:40 to start playing the live broadcast at the current time of 15:10, the channel will jump to retrieve the video starting at 15:40, which will inevitably cause viewing terminals 3 and 2 to miss the video.
[0071] Step S202: In response to an advance playback request sent by a target viewing terminal among the multiple viewing terminals for the overlapping time period, a second channel is created based on the playback start time of the advance playback request.
[0072] Step S203: Send the video starting at the playback start time to the target viewing terminal through the second channel.
[0073] In this embodiment, among the multiple viewing terminals added to the first channel, if one of the target viewing terminals sends an advance playback request within its corresponding overlapping time period, that is, jumps from the current playback time to another playback time later than the current playback time, in order to satisfy the advance playback of the target viewing terminal without affecting the video viewing of other viewing terminals, a second channel can be created. The newly created second channel can be directly used to send the video starting from the playback start time to the target viewing terminal.
[0074] In one alternative example, the playback start time can be understood as the playback point reached after the user drags the progress bar. Generally, a progress bar is set on the playback page of the viewing device, and when the user drags the progress bar, the playback time of the video is readjusted. Specifically, to allow users to adjust the playback start time, when each viewing device is added to the first channel, a corresponding progress bar can be generated based on the overlapping time period of that viewing device, and then displayed on the playback page of the viewing device. This allows users to manipulate the progress bar to adjust the playback start time, such as allowing them to rewind or advance the playback.
[0075] Specifically, the video data sent to the viewing end can be adjusted based on the type of user operation on the progress bar. If the user's operation on the progress bar is a rewind operation, then historical video data that has already been played in the first channel will be sent to the viewing end. Generally speaking, the first channel will cache the retrieved video. A rewind operation indicates that the user needs to watch historical video data again. Therefore, the video starting from the rewind position can be sent directly to the user through the first channel.
[0076] If the user's operation on the progress bar is an advance playback operation, it indicates that the user wants to watch the video after the current playback time. In this case, in order to avoid the problem of other viewing terminals missing the video screen due to the video being retrieved again, a second channel can be created. After creating the second channel, the video starting from the playback start time can be sent to the target viewing terminal through the second channel.
[0077] In one alternative example, a video request starting from the playback start time can be sent to the video source to obtain the video starting from the playback start time, and then the video can be sent to the target viewing end via a second channel.
[0078] By employing the technical solution of this embodiment, on the one hand, overlapping video segments can be sent to multiple viewing terminals through the same channel, eliminating the need for each viewing terminal to request video retrieval from the video source, thereby reducing the load on the video source. On the other hand, for the advanced playback request of the target viewing terminal in the first channel, a new second channel can be created to send the fast-forwarded video to the target viewing terminal. In this way, video can be sent to viewing terminals with fast-forwarding needs through a separate channel, thus not affecting the normal viewing of video by other viewing terminals in the first channel, and other viewing terminals will not miss the video footage.
[0079] Overall, the video transmission method of this application mainly involves two improvements. The first is to meet the different viewing needs of different users on the same channel while saving channel resources. The second is to make full use of and save channel resources in the network. These two improvements are described below:
[0080] (1) Save network channel resources.
[0081] Generally speaking, network channel resources are limited. Therefore, it is necessary to release existing channels in a timely manner or to fully share existing channels for newly triggered video viewing needs.
[0082] Accordingly, as described in the above embodiments, the video retrieved by the first channel can be cached. Then, for viewers who join the first channel later and whose start time is before the time corresponding to the currently retrieved video in the first channel, video data can be obtained from the cached video and sent. Thus, in one embodiment, for an advance playback request from a target viewer, a second channel can be created if the playback start time meets the conditions for creating a new channel; otherwise, the first channel is still used to respond to the advance playback request. Specifically, if the playback start time is before the current live broadcast time of the first channel, the conditions for creating a new channel are not met, because in this case, video data can still be obtained from the cached video in the first channel and sent.
[0083] In practice, the temporal relationship between the playback start time and the current playback time of the first channel can be determined; when the playback start time is earlier than the current live broadcast time, the video starting from the playback start time is sent to the target viewing end through the first channel.
[0084] In this embodiment, the first channel is understood as the live streaming channel, which sends the required video to multiple viewing terminals according to the live streaming mode. The current live streaming time refers to the playback time of the video retrieved from the video source in the target time period. In practice, it can be represented by the playback moment. Therefore, when determining the time sequence between the playback start time and the current live streaming time, the time sequence of their respective playback moments can be determined.
[0085] If the playback start time is earlier than the current live stream position, it means that the user's fast-forwarded start time is before the current live stream time, and the first channel has already cached that part of the video. For example, if the target time period is 15:00-16:00, the current live stream time is 15:20, and the playback start time is 15:10, then the corresponding video is already cached on the server. Therefore, there is no need to create a new channel and re-request the video; the video starting from the playback start time can be directly extracted from the cached video and sent to the target viewer.
[0086] Accordingly, if the playback start time is later than the current live broadcast time, it means that the playback time fast-forwarded to by the user is after the current live broadcast time, and the first channel does not cache that part of the video. For example, if the target time period is 15:00-16:00, the current live broadcast time is 15:20, and the playback start time is 15:30, then the corresponding video is not cached in the server. In this case, a new second channel is created, and a new video retrieval request is sent to the video source according to the process described in the above embodiment to obtain the video starting from the playback start time, and then sent to the target viewing end through the second channel.
[0087] In this implementation method, a new channel is created only when the conditions for creating a new channel are met, and the video starting from the playback start time is sent using an existing channel when the conditions for creating a new channel are not met. This reduces the number of new channels and saves channel resources.
[0088] In another alternative example, if there are multiple target viewers, the playback start times of the advanced playback requests from multiple target viewers may be different from each other, or the playback start times of some target viewers may be similar. Generally, a corresponding second channel can be created based on the playback start times of the advanced playback requests of each of the multiple target viewers.
[0089] Different playback start times can correspond to different second channels, meaning the second channel is established based on the playback start time. To conserve channels, a second channel can be created for target viewers whose playback start times differ by a preset margin. In this case, these target viewers with similar playback start times can watch the video starting at the same second channel.
[0090] The preset gap can be set according to needs, for example, to a duration within 1 second. In this way, target viewing devices with playback start times differing by less than 1 second can share the same dual-channel.
[0091] In one embodiment, after creating the second channel, the first and second channels can be released based on the viewing progress of the target end using the second channel and the current playback progress of the first channel. Specifically, if the target end of the second channel finishes watching, the second channel can be released directly; if all ends of the first channel finish watching, the first channel can be released.
[0092] In practice, the first channel can be released when the release condition for the first channel is met, and the second channel can be released when the release condition for the second channel is met. The release condition for the first channel can be that all viewers on the first channel stop watching, and the release condition for the second channel can be that all viewers on the second channel stop watching.
[0093] In another embodiment, in order to ensure that users of the first channel do not miss video footage and to fully conserve channel resources, the first and second channels can be merged at an appropriate playback time point so that the hierarchical playback of the viewing ends in the two channels can be satisfied through one channel.
[0094] In specific implementation, the release conditions for the first channel can be set as follows: the first duration from the current live broadcast time to the start time of playback is less than the second duration from the start time of playback to the end time of the overlapping period; and all viewing terminals of the first channel stop watching.
[0095] Specifically, when sending the retrieved video data using each channel (including the first and second channels), the retrieved video data can be cached. This allows us to determine, based on the relationship between the first and second durations, whether the cached video from the first channel can be spliced together with the cached video from the second channel before the target viewer finishes watching. If so, the first channel is merged into the second channel, effectively releasing the first channel and migrating viewers who haven't finished watching from the first channel to the second channel, thus sending video to multiple viewers through the second channel.
[0096] For example, the target time period is 15:00-16:00, and the overlapping time period of the target viewing end is also 15:00-16:00. The current live broadcast position of the first channel is 15:10, while the playback start time of the target viewing end is 15:20. Generally speaking, the first duration is 10 minutes, and the second duration is 40 minutes. It can be seen that the first duration is shorter than the second duration, which means that the cached video of the first channel can be spliced together with the cached video of the second channel before the target viewing end finishes watching. In this case, the first channel can be released at the start of the advanced playback request, and after splicing the cached videos of the two channels into a complete video, the viewing end of the first channel is migrated to the second channel, and the required video is sent to each viewing end through the second channel.
[0097] In this case, the process of the second channel sending the required video to each viewing terminal can be referred to the process of the first channel sending the required video to each viewing terminal, and will not be repeated here.
[0098] In practice, the first channel can be released when the live broadcast time of the first channel reaches the start time, and the viewers who have not finished watching in the first channel can be migrated to the second channel.
[0099] Of course, in some embodiments, the playback rate of the video during the overlapping period in the first channel may be different from the playback rate of the video in the second channel. For example, the playback rate of the first channel may be slower. There may be a situation where users who need live streaming in the first channel finish watching the video first, while users in the second channel have not finished watching the video. In this case, to improve the utilization rate of channel resources, when releasing the first channel, it can be determined whether the second channel still exists. If so, if there are still viewing terminals that have not finished watching in the first channel (non-live streaming viewing terminals, such as replay viewing terminals), the viewing terminals that have not finished watching will be migrated to the second channel.
[0100] In one optional example, if the viewing end of the first channel is migrated to the second channel, and the end time of the overlapping period corresponding to the target viewing end is before the end time of the target period, for example, the target period is 15:00-16:00, and the overlapping period of the target viewing end is 15:00-15:50; in this case, the first cached video and the second cached video, after being spliced together, are not a complete video of the target period. In this case, the default video can be retrieved through the second channel and sent to the corresponding migrated viewing end.
[0101] In this embodiment, for video data caching, GOP (Group of Pictures) data can be cached, and then the video can be sent based on the GOP data. Specifically, when the retrieved video frame is an I-frame, the corresponding GOP data can be cached in a storage queue; and based on the GOP data cached in the storage queue and the corresponding playback time, a mapping relationship between each GOP data and the playback time can be constructed.
[0102] In this embodiment, GOP stands for Group of Pictures, and a GOP is a group of consecutive pictures. Therefore, generally speaking, a picture needs an I-frame (keyframe, which is the frame that shows the key change in the picture) to be presented. In this embodiment, when an I-frame video frame is retrieved, the I-frame can be cached. The P-frames and B-frames after the I-frame will also be cached accordingly. When the next I-frame is received, the cached I-frames, P-frames, B-frames and other video frames are saved as a GOP. In this way, multiple GOP data will be cached in the storage queue. Each GOP data corresponds to a group of consecutive pictures. Since the playback of the picture has a time limit, each GOP data corresponds to a playback moment. In this embodiment, a mapping relationship between each GOP data and the playback moment can be established.
[0103] In this embodiment, when releasing the second channel, the existence of the first channel can also be detected. If it exists, it indicates that the second channel is released before the first channel. In this case, since each channel caches video, and the cached video cannot be spliced together, the video cached in the second channel can be directed to the first channel first. When the current playback time of the first channel is the playback start time, the videos required by each of the multiple viewing terminals are extracted from the cached video.
[0104] In this embodiment, if the second channel is released before the first channel, meaning the cached video in the first channel and the cached video in the second channel cannot be spliced together, and the target viewing end ends watching first, then since the second channel already caches a portion of the video for the target time period, the cached video in the second channel can be stored in the cache queue corresponding to the first channel. When the time when the video data retrieved by the first channel is the start time of the cached video in the second channel, video retrieval from the video source is stopped. This is because, in this case, the video after that time (the cached video in the second channel) already exists in the cache queue corresponding to the first channel, and there is no need to retrieve it from the video source again. Therefore, multiple viewing ends can directly extract the videos they need from the cached video in the second channel and send them.
[0105] For example, the target time period is 15:00-16:00, and the overlapping time period of the target viewing terminal is also 15:00-16:00. The current playback time (live broadcast time) of the first channel is 15:10, while the playback start time of the target viewing terminal is 15:40. Generally speaking, the second channel ends playback before the first channel, so the second channel can be released. The moment the second channel is released is the end playback time of the second channel. The video of the second channel from 15:40 to 16:00 is cached in the cache queue of the first channel. When the first channel plays to 15:40, it can directly extract the corresponding video from the video of 15:40-16:00 and send it to the viewing terminal without having to retrieve the video.
[0106] In this implementation, on the one hand, the first and second channels can be released in a timely manner, and the first and second channels can be merged without affecting the video viewing of the receiving end on the first channel, thus fully conserving channel resources. On the other hand, since the video data retrieved by the first channel is at the start of playback, video retrieval from the video source is stopped, and instead, multiple videos required by each receiving end are retrieved from the cached video in the second channel and sent. This avoids repeatedly requesting videos that have already been requested from the video source (the cached video in the second channel), thereby reducing the number of video retrievals and lowering the load on the terminal device of the video source.
[0107] (2) To meet the different viewing needs of different users in the channel.
[0108] In related technologies, when using a video transmission method similar to live streaming to meet the viewing needs of multiple users for a certain time period, multiple users can simultaneously watch the video of the same time period. However, it cannot achieve differentiated playback for these users. For example, regarding the recording of a camera from 15:00 to 16:00, if user 1 requests to watch ten minutes later, and user 2 then requests to watch the recording from 15:00 to 16:00, user 1 should be watching the monitoring footage from 15:10, and user 2 should be watching the footage from 15:00. However, in reality, user 2 enters the camera and simultaneously watches the footage starting from 15:10 with user 1.
[0109] As described in the above embodiments, this can be achieved by sending video to multiple viewing terminals in turn, thus satisfying the requirement of the same channel sending video data to different viewing terminals. In an optional example, when the first channel is a live channel, video can be sent to each viewing terminal starting from the start time of its corresponding overlapping time period.
[0110] In some implementation scenarios, the first channel needs to send videos of the corresponding overlapping time periods to the viewing terminals. In some cases, the overlapping time periods may be in the middle or later of the target time period. In this case, it is necessary to add the ability for each viewing terminal in the first channel to watch the videos they need according to their own viewing needs. For example, each terminal may start watching the videos from different starting times, that is, users may need to start watching the video from different times within the same time period.
[0111] For example, if the target time period is 15:00-16:00, and User 1 requests to watch for ten minutes, then User 2 joins the first channel. User 2's overlapping time period is 15:00-15:30. At this time, User 2 should start watching the video from 15:00, while User 1 continues to watch the video from 15:10.
[0112] Therefore, to allow different users to start watching videos from different starting times, the retrieved video data can be cached. That is, for each channel, the video data retrieved for that channel can be cached, and the video can be extracted from the cached video data and sent to the corresponding viewing terminal. Taking the first channel as an example, the specific explanation is as follows:
[0113] Specifically, when sending the retrieved video data using the first channel, the retrieved video data is cached; then for videos in overlapping time periods, the corresponding video can be extracted from the cached video or the video retrieved in real time, and sent using the first channel.
[0114] In some specific implementation scenarios, the cached video may not yet contain all the video data from overlapping time periods. For example, if the first channel is for 15:00-16:00, and the overlapping time period is 15:30-16:00, but only up to 15:40 is currently cached (not yet fully cached), then the cached video data from the overlapping time period can be sent first. For example, send a portion of the video data from 15:30-15:40. Then, as the real-time video stream is continuously retrieved, the cached video data is continuously improved, and the remaining video data from the overlapping time period is dynamically sent, thus achieving complete transmission.
[0115] If the cached video has not yet reached the start time of the overlapping period, that is, the videos being retrieved have not yet reached the overlapping period, for example, the target period is 15:00-16:00, the overlapping period is 15:30-16:00, and the currently retrieved video is at 15:20, in this case, the real-time retrieved video can be sent to the corresponding viewing terminal when the video in the overlapping period is retrieved.
[0116] In this implementation, since the first channel corresponds to multiple viewing terminals, each viewing terminal that has joined the first channel can obtain the video it needs as required, which not only saves channel resources but also enables layered playback of videos.
[0117] Of course, for the target viewing end and each viewing end in the first channel, the requested time period of the viewing end may overlap with the target time period. This can include three situations: the requested time period completely overlaps with the target time period, the requested time period partially overlaps with the target time period, and the requested time period is a part of the target time period. In the case where the requested time period partially overlaps with the target time period, in addition to the overlapping time period, the requested time period also includes the remaining time period that does not overlap with the target time period. For the video of the remaining time period, an existing channel can be used to send it. If no existing channel can be used to send it, a new channel will be created to send the video of the remaining time period.
[0118] Taking the target viewing terminal as an example, in specific implementation, when the target viewing terminal finishes watching the overlapping period, it is detected whether the requested period of the target viewing terminal also includes the remaining period after the overlapping period; if so, it is determined whether there is a third channel that overlaps with the remaining period; if so, the video of the remaining period is sent using at least the third channel; if not, a new fourth channel is created to send the video of the remaining period.
[0119] In one implementation, for overlapping time periods corresponding to the target viewing end, the first channel of the overlapping time period can be used to send the video of the overlapping time period. When the target viewing end sends an advance playback request, a second channel can be created to send the fast-forwarded video through the second channel. For the remaining time periods in the request period of the target viewing end other than the overlapping time periods, in order to save channel resources, the existing channel can still be used to send the video if the channel sharing conditions are met.
[0120] In practice, if a third channel exists that overlaps with the remaining time period, the video for the remaining time period will be sent directly using the third channel; otherwise, the video for the remaining time period will be retrieved from the video source and sent using the fourth channel.
[0121] For example, if the target time period is 15:00-16:00 and the target viewing terminal requests the time period of 15:30-16:40, then the remaining time period is 16:00-16:40. It can be determined whether there is a channel that includes 16:00-16:40 (i.e., the third channel). If there is, the video of 16:00-16:40 is sent directly using that channel. If not, a new channel is created (i.e., the fourth channel), and the video of 16:00-16:40 is scheduled from the camera device or terminal device and sent to the target viewing terminal.
[0122] Of course, under the core technical idea of this application, once the fourth channel corresponding to the remaining time period is established, another new time period will have a channel, thereby expanding the coverage of the time period. The fourth channel can still be reused for subsequent new request services.
[0123] When this implementation method is adopted, the video of the remaining time period of the target viewing terminal can be sent using the existing channel, thereby avoiding the waste of channel resources caused by creating a new channel; and since the video of the remaining time period of the target viewing terminal is sent through the newly created channel, the newly created channel can be shared by other viewing terminals, so that each created channel can be fully utilized, thereby further saving channel resources.
[0124] The following is a general explanation of the video sending method on the server side, specifically including the following process:
[0125] S1: Receive a video playback request from the target viewing terminal for the requested time period. If the requested time period does not overlap with any existing channel's corresponding time period, create a separate channel corresponding to the target viewing terminal and proceed to step S2.
[0126] If the requested time period overlaps with the time period corresponding to an existing channel, the first channel of the overlapping time period is used as the channel of the overlapping time period of the target viewing end, and the video of the overlapping time period is sent to the target viewing end through the first channel, and then proceeds to step S3.
[0127] S2: If an advance playback request is received from the target viewing terminal, determine whether the channel of the target viewing terminal is being reused by other viewing terminals. If not, directly use the channel to send the video starting at the playback start time to the target viewing terminal. If so, create a second channel and send the video starting at the playback start time to the target viewing terminal through the second channel, and proceed to S4.
[0128] S3: If an advance playback request is received from the target viewing terminal while watching a video during the overlapping time period, and the start time of the advance playback request is later than the current live broadcast time of the first channel, a second channel is created, and the video starting at the start time is sent to the target viewing terminal through the second channel, and then proceed to S4; otherwise, the video starting at the start time is sent to the target viewing terminal using the first channel.
[0129] S4: Determine whether the release conditions of the first channel and the second channel are met, specifically:
[0130] Determine whether the first duration from the current live broadcast time to the playback start time of the first channel is less than the second duration from the playback start time to the playback end time of the overlapping period. If yes, proceed to step S5; otherwise, proceed to step S6.
[0131] S5: When the current live broadcast time of the first channel reaches the playback start time, the first channel is released, the current viewing terminal in the first channel is migrated to the second channel, and the beginning and end of the cached video of the first channel are spliced into the cached video of the second channel, so as to send the required video to multiple viewing terminals through the second channel.
[0132] S6: Detect whether the live streaming client (the client with the earliest playback time) of the first channel has finished watching. If so, release the first channel and proceed to step S7; and detect whether the target client of the second channel has finished watching. If so, release the second channel and proceed to step S8; and detect whether the second channel exists.
[0133] S7: Check if a second channel exists. If it exists, migrate any viewers in the first channel who have not yet finished watching to the second channel. If a second channel does not exist, directly release the first channel and all viewers in the first channel.
[0134] S8: Check if the first channel still exists; if so, redirect the video cached in the second channel to the first channel; and when the current playback time of the first channel is the playback start time, extract the videos required by each of the multiple viewing terminals from the cached video, and return to step S4 to continue to determine whether the first channel meets the release conditions. If the first channel does not exist, directly release the first channel and all viewing terminals in the first channel.
[0135] In practice, the above process can be combined in combination to obtain specific implementations that are suitable for different application scenarios.
[0136] Below, with Figure 1 Taking the implementation environment shown as an example, and combining it with a specific example, the video sending method of this application will be explained in general:
[0137] 1. Users 1, 2, 3, and 4 enter the first channel at different times to watch the video during the target time period of 15:00-16:00. In this channel A1, users 1, 2, 3, and 4 all start watching the video at 15:00. Among them, user 1 watches the video in live mode, that is, user 1's viewing progress is synchronized with the progress of the video retrieved by the first channel.
[0138] Specifically, User 1 is currently watching the 15:20 segment, User 2 is watching the 15:10 segment, User 3 is watching the 15:05 segment, and User 4 is watching the 15:01 segment.
[0139] 2. If user 3 drags the progress bar directly and needs to advance the playback, determine whether to create a new channel based on the start time of the advance playback.
[0140] Specifically, the following situations apply:
[0141] Scenario 1: If the playback start time is before 15:20, there is no need to create a new channel. The video can still be sent using channel A1, because channel A1 already has videos before 15:20 cached. The video can be directly retrieved from the cached video and sent to user 3.
[0142] Scenario 2: If the playback start time is after 15:20, create a new channel A2, request the video after 15:20 from the video source again, and send it to user 3 using channel A2.
[0143] In this second scenario, the first or second channel can be released as appropriate, as detailed below:
[0144] 3. Determine how long it will take for the cached videos in channels A1 and A2 to be spliced together end to end.
[0145] Scenario 3: If the playback starts at 15:30, the first duration is shorter than the second duration, and the viewing on channel A2 has not ended by 15:30, then channel A1 is released, and users 1, 2, and 4 are migrated to channel A2. Videos are then sent to the four users as needed through channel A2.
[0146] Scenario 4: If the playback starts at 15:50 and the first duration is longer than the second duration, then 30 minutes of cached video from channels A1 and A2 are needed to splice the beginning and end. If channel A2 has already finished watching at 15:50, then channel A2 will be released directly when user 3 finishes watching.
[0147] In this fourth scenario, the cached video (15:50-16:00) from channel A2 can be merged into channel A1. When channel A1 plays to 15:50, that is, when user 1 watches to 15:50, the server can directly extract the corresponding video from the cached video and send it to user 1 without having to retrieve the video from the video source again.
[0148] Based on the same inventive concept, a second aspect of the present invention discloses a video transmitting device, with reference to... Figure 4 The present invention discloses a video transmission method apparatus, which may specifically include the following modules:
[0149] The first sending module 401 is used to send the video of the overlapping time period to multiple viewing terminals through the first channel corresponding to the target time period.
[0150] Module 402 is created in response to an advance playback request sent by a target viewing terminal among the multiple viewing terminals for the overlapping time period, and creates a second channel based on the playback start time of the advance playback request.
[0151] The second sending module 403 is used to send the video starting at the playback start time to the target viewing terminal through the second channel.
[0152] Optionally, when there are multiple target viewing terminals, the creation module 402 is specifically used to respond to the advance playback requests sent by multiple target viewing terminals and create corresponding second channels according to the playback start time of the advance playback requests.
[0153] Among them, target viewing terminals whose playback start times are within a preset gap correspond to the same second channel.
[0154] Optionally, the device further includes a release module, which is specifically used for:
[0155] When the release condition of the first channel is met, the first channel is released;
[0156] The second channel is released when the release condition of the second channel is met.
[0157] Optionally, the first channel is a live streaming channel, and the release module is specifically used to release the first channel when the current live streaming time of the first channel reaches the playback start time, provided that the first duration between the current live streaming time of the first channel and the playback start time is less than the second duration between the playback start time and the playback end time of the overlapping period.
[0158] The device further includes a first migration module for migrating the receiving end in the first channel to the second channel.
[0159] Optionally, the device further includes:
[0160] The first detection module is used to detect whether the second channel exists when the first channel is released;
[0161] The second migration module is used to migrate the viewers who have not finished watching to the second channel if, in the case that, there are still viewers in the first channel, the viewers who have not finished watching.
[0162] Optionally,
[0163] Optionally, the device further includes:
[0164] The second detection module is used to detect whether the first channel still exists when the second channel is released;
[0165] The third migration module is used to redirect the video cached in the second channel to the first channel if the condition is met; wherein the video cached in the second channel is obtained by caching video data sent to the target viewing terminal; and when the playback time of the video data currently retrieved in the first channel is the playback start time, extract multiple videos required by each viewing terminal from the cached video.
[0166] Optionally, the first channel is a live streaming channel, and the device further includes:
[0167] The sequence relationship determination module is used to determine the temporal sequence relationship between the playback start time and the current live broadcast time of the first channel in response to the advanced playback request.
[0168] The creation module 402 is specifically used to create the second channel based on the super-play start time if the playback start time is later than the current live broadcast time.
[0169] It should be noted that the device embodiments are similar to the method embodiments, so the description is relatively simple. For relevant details, please refer to the method embodiments.
[0170] This invention also provides a server, which includes a remote service module for executing the video sending method described in any of the above embodiments.
[0171] This invention also provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0172] Memory, used to store computer programs;
[0173] The processor, when executing a program stored in memory, implements the video transmission method as described in the first aspect of the embodiments of the present invention.
[0174] This invention also provides a computer-readable storage medium storing a computer program that causes a processor to execute the video transmission method as described in any of the above embodiments of this invention.
[0175] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0176] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0177] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0178] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0179] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0180] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.
[0181] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.
[0182] The present invention has provided a detailed description of a video transmission method, apparatus, electronic device, and storage medium. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.
Claims
1. A video transmission method, characterized in that, The method includes: For multiple viewing terminals where the requested time period overlaps with the target time period, the video of the overlapping time period is sent to each of the multiple viewing terminals through the first channel corresponding to the target time period; In response to an advance playback request sent by a target viewing terminal among the multiple viewing terminals for the overlapping time period, a second channel is created based on the playback start time of the advance playback request; The video, starting at the playback start time, is sent to the target viewing terminal via the second channel. The method further includes: When the release condition of the first channel is met, the first channel is released; When the release condition of the second channel is met, the second channel is released; The first channel is a live streaming channel. When the release conditions for the first channel are met, the first channel is released, including: If the first duration between the current live broadcast time and the playback start time of the first channel is less than the second duration between the playback start time and the playback end time of the overlapping period, the first channel is released when the current live broadcast time of the first channel reaches the playback start time. The method further includes: The receiving end in the first channel is moved to the second channel.
2. The method according to claim 1, characterized in that, When there are multiple target viewing terminals, in response to an advance playback request sent by one of the target viewing terminals, a second channel is created based on the playback start time of the advance playback request, including: In response to advance playback requests sent by multiple target viewing terminals, a corresponding second channel is created according to the playback start time of each advance playback request; Among them, target viewing terminals whose playback start times are within a preset gap correspond to the same second channel.
3. The method according to claim 1, characterized in that, The method further includes: If the first channel is released, check if the second channel exists; If so, if there are still viewers in the first channel who have not finished watching, then the viewers who have not finished watching will be moved to the second channel.
4. The method according to claim 1, characterized in that, The method further includes: If the second channel is released, check whether the first channel still exists; If so, the video cached in the second channel is directed to the first channel; wherein the video cached in the second channel is obtained by caching the video data sent to the target viewing terminal; When the playback time of the video data currently retrieved in the first channel is the playback start time, multiple videos required by each of the viewing terminals are extracted from the cached videos.
5. The method according to claim 1, characterized in that, The method further includes: In response to the advanced playback request, determine the temporal relationship between the playback start time and the current live broadcast time of the first channel; Creating a second channel based on the playback start time of the aforementioned advanced playback request includes: If the playback start time is later than the current live broadcast time, then the second channel is created based on the playback start time.
6. A video transmitting device, characterized in that, The device includes: The first sending module is used to send videos of the overlapping time periods to multiple viewing terminals through the first channel corresponding to the target time period. A creation module is established in response to an advance playback request sent by a target viewing terminal among the multiple viewing terminals for the overlapping time period, and a second channel is created based on the playback start time of the advance playback request. The second sending module is used to send the video starting at the playback start time to the target viewing terminal through the second channel; The device further includes a release module, the release module being used for: When the release condition of the first channel is met, the first channel is released; When the release condition of the second channel is met, the second channel is released; The first channel is a live streaming channel. The release module is used to release the first channel when the current live streaming time of the first channel reaches the playback start time, provided that the first duration between the current live streaming time of the first channel and the playback start time is less than the second duration between the playback start time and the playback end time of the overlapping period. The device further includes a first migration module for migrating the viewing end in the first channel to the second channel.
7. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the video transmission method according to any one of claims 1-5.
8. A computer-readable storage medium, characterized in that, The stored computer program causes the processor to execute the video transmission method as described in any one of claims 1-5.
Citation Information
Patent Citations
Method and device for playing live program based on Internet protocol television
CN105933798A
Method for switching from unicast to multicast for time-shifted program
CN107277554A
Playing jump processing method and device, electronic equipment and medium
CN115209226A