Front-end multi-video virtual synthesis playing method and device and storage medium

Abstract

This application discloses a front-end multi-video virtual composite playback method, device, and storage medium, relating to the field of video generation technology. The method includes: obtaining the target slice object currently pointed to by the playback pointer in an initial slice list; determining the target video source address of the target slice object; if the target slice object is in the playable slice list, determining the target video source address as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource; and controlling the video player to perform playback operations based on the slice resource. This ensures that only valid and usable video slices are loaded, avoiding playback errors and stuttering caused by invalid addresses or abnormal slices, thus improving the overall playback flexibility and user experience.

Description

Technical Field

[0001] This application relates to the field of video generation technology, and in particular to a front-end multi-video virtual synthesis playback method, device and storage medium. Background Technology

[0002] In video applications, it is often necessary to process complete video content composed of multiple video clips. The common approach is to stitch, encode, and combine multiple independent video clips into a single complete video file on the server side, and then transmit the combined complete video to the client for playback. However, video merging processing consumes a significant amount of server computing resources and processing time, increases server load, and introduces long response latency. Furthermore, it does not support jumping to or combining specific clips for playback, resulting in poor playback flexibility.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a front-end multi-video virtual synthesis playback method, which aims to solve the technical problem of how to improve the convenience of multi-video playback.

[0005] To address the aforementioned problems, this application provides a front-end multi-video virtual composite playback method, which includes: Obtain the target slice object currently pointed to by the playback pointer in the initial slice list, and determine the target video source address of the target slice object; If the target slice object is in the playable slice list, the target video source address is determined as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource; The video player is controlled to perform playback operations based on the sliced ​​resources.

[0006] In one embodiment, the front-end multi-video virtual synthesis playback method further includes: Get the video source address, slice duration, and slice status of the video segment to be played; The sequence index is determined according to the preset playback order, and the initial slice list is generated by combining the sequence index, the video source address, the slice duration, and the slice status.

[0007] In one embodiment, before the step of determining the target video source address as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource, the front-end multi-video virtual composite playback method further includes: Obtain the target state field of the target slice object in the initial slice list, and determine whether the target slice object meets the preset playable state; If the conditions are met, the target slice object is added to the playable slice list.

[0008] In one embodiment, after the step of controlling the video player to perform playback operations based on the slice resources, the front-end multi-video virtual synthesis playback method further includes: Obtain the playback progress of the video player and the target slice duration of the target slice object; When the playback progress is greater than or equal to the target slice duration, the target slice object is determined to have finished playing. Update the index value of the target slice object. If the updated index value is less than the total number of slices, then determine the next slice object based on the updated index value.

[0009] In one embodiment, after the step of controlling the video player to perform playback operations based on the slice resources, the front-end multi-video virtual synthesis playback method further includes: Iterate through the playable slices in the playable slice list, and sum the first slice duration of each playable slice to obtain the total slice duration; Get the second segment duration of the played segment, determine the real-time played time of the current segment as the third segment duration, and add the second segment duration and the third segment duration to get the total playback duration; The playback progress percentage is determined based on the ratio of the total playback duration to the total segment duration. The global playback progress is determined based on the playback progress percentage, and the global playback progress is rendered and displayed on the virtual timeline.

[0010] In one embodiment, after the steps of determining the global playback progress based on the playback progress percentage and rendering and displaying the global playback progress on a virtual timeline, the front-end multi-video virtual composite playback method further includes: In response to a user's click on the virtual timeline progress bar, the offset pixel value corresponding to the click operation is obtained; The ratio of the offset pixel value to the total width pixel value of the progress bar is determined as the target playback progress percentage; Based on the target playback progress percentage and total duration, determine the target virtual time point; The target virtual time point is matched to the time interval of the corresponding slice to determine the slice to be jumped to, and the video source address of the slice to be jumped to is assigned to the video player.

[0011] In one embodiment, the front-end multi-video virtual synthesis playback method further includes: Compare the slice sequence snapshot with the real-time slice list to determine if there are any slice change events; If the aforementioned change event exists, and the changed slice is after the currently playing slice, then the current playback state is maintained; If the change event exists, and the changed slice is after the current playback slice, or the changed slice is the current playback slice, then the playback pointer is reset.

[0012] In one embodiment, the slice change event includes changes in the total number of slices, changes in the slice order, and additions or removals of slices. The step of comparing the slice sequence snapshot with the real-time slice snapshot to determine whether a slice change event exists includes: Compare the total number of slices in the slice sequence snapshot with the total number of slices in the real-time slice list. If they are inconsistent, then confirm that the total number of slices has changed. Compare the slice sequence snapshot with the slice identifier at the same position in the real-time slice list. If they are inconsistent, it is confirmed that the slice order has changed. If the slice identifier in the slice sequence snapshot is not in the real-time slice list, or the slice identifier in the real-time slice list is not in the slice sequence snapshot, then it is confirmed that a slice has been added or removed.

[0013] In addition, to achieve the above objectives, this application also proposes a front-end multi-video virtual synthesis playback method device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the front-end multi-video virtual synthesis playback method as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the front-end multi-video virtual synthesis playback method described above.

[0015] This application provides a front-end multi-video virtual composite playback method. By locating the target slice corresponding to the playback pointer in the initial slice list and obtaining its video source address, and then verifying whether the slice is in the playable slice list, the player's src attribute is updated only for valid playable slices to load resources and execute playback. This ensures that only valid and usable video slices are loaded, avoiding playback errors and stuttering caused by invalid addresses and abnormal slices. At the same time, it achieves precise binding between the playback pointer and slice resources, ensuring a stable and controllable playback process, and improving the overall playback flexibility and user experience. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A first flowchart illustrating the front-end multi-video virtual synthesis and playback method of this application; Figure 2 This is a second flowchart illustrating the front-end multi-video virtual synthesis and playback method of this application; Figure 3 This is a schematic diagram of the hardware operating environment involved in the front-end multi-video virtual synthesis and playback method in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] To achieve the above objectives, this application proposes a front-end multi-video virtual composite playback method, which includes: obtaining the target slice object pointed to by the current playback pointer in the initial slice list, and determining the target video source address of the target slice object; if the target slice object is in the playable slice list, determining the target video source address as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource; and controlling the video player to perform a playback operation based on the slice resource.

[0023] In video applications, it is often necessary to process complete video content composed of multiple video clips. The common approach is to stitch, encode, and combine multiple independent video clips into a single complete video file on the server side, and then transmit the combined complete video to the client for playback. However, video merging processing consumes a significant amount of server computing resources and processing time, increases server load, and introduces long response latency. Furthermore, it does not support jumping to or combining specific clips for playback, resulting in poor playback flexibility.

[0024] This application provides a front-end multi-video virtual composite playback method. By first locating the target slice corresponding to the playback pointer in the initial slice list and obtaining its video source address, and then verifying whether the slice is in the playable slice list, the player's src attribute is updated only for valid playable slices to load resources and execute playback. This ensures that only valid and usable video slices are loaded, avoiding playback errors and stuttering caused by invalid addresses and abnormal slices. At the same time, it achieves precise binding between the playback pointer and slice resources, ensuring a stable and controllable playback process. In scenarios with dynamic switching of multiple slices, it always outputs valid and playable content, improving the overall playback continuity and user experience.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with network communication and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or apparatus capable of performing the above functions. The following description uses a front-end multi-video virtual synthesis playback method device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide a front-end multi-video virtual synthesis and playback method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the front-end multi-video virtual synthesis playback method of this application.

[0027] In this embodiment, the front-end multi-video virtual synthesis playback method includes steps S10~S30: Step S10: Obtain the target slice object currently pointed to by the playback pointer in the initial slice list, and determine the target video source address of the target slice object.

[0028] In this embodiment, pre-stored playback pointer data is obtained. The playback pointer data is a numeric index used to mark the position of the segment to be played in the ordered playable segment sequence. The ordered playable segment sequence after sorting and status filtering is obtained. This sequence only contains segment objects whose status is "completed" and are sorted in ascending order by the index field (order field). The playback pointer index value is compared with the length of the ordered playable segment sequence to confirm that the index value is within a valid range, i.e., greater than or equal to 0 and less than the total number of segments in the sequence.

[0029] Based on the valid playback pointer index, position matching is performed within the ordered playable slice sequence to locate the slice data corresponding to that index value. The playback pointer index value is mapped to a position subscript in the ordered playable slice sequence according to a mapping rule. For example, the mapping rule is: index 0 corresponds to the 1st slice in the sequence, index 1 corresponds to the 2nd slice, index 2 corresponds to the 3rd slice, and index N corresponds to the (N+1)th slice. A location lookup is performed within the sequence based on the index subscript. Using the playback pointer index as the subscript, a direct addressing operation is performed within the ordered playable slice sequence. Starting from the beginning storage position of the sequence, the slice data storage unit containing the target position is located by offsetting the index value by the corresponding length. From the located storage unit, the complete slice information stored at that position is read, including all fields such as source_url, duration, status, and order. The read slice data is marked as the target slice object to be loaded and played.

[0030] Retrieve the `source_url` field content stored in the identified target slice object. The `source_url` field is a string type and records the video resource path corresponding to the current slice. Perform format validation on the `source_url` content, checking if it is an empty string, contains a valid resource location protocol header, and conforms to the standard format specification of resource addresses. If the validation passes, the address is determined as the target video source address used for this slice's playback; if the validation fails, the slice is marked as invalid, triggering playback exception handling logic. Processing result: A valid target video source address is obtained.

[0031] Before step S10, steps S01~S02 are also included: Step S01: Obtain the video source address, slice duration, and slice status of the video segment to be played.

[0032] Step S02: Determine the sequence index according to the preset playback order, and generate the initial slice list by combining the sequence index, the video source address, the slice duration, and the slice status.

[0033] In this implementation, a single HTML5 video element is created on the front end as a unified player, and different video slices are loaded by dynamically switching the src attribute of this video element.

[0034] The system retrieves the built-in object interface information of the front-end runtime environment. By identifying the existence status of interfaces related to the standard Document Object Model (DOM), it determines whether the current environment has the basic processing capabilities for creating, querying, modifying, and mounting DOM nodes. It checks whether the environment exposes standard node construction interfaces, node attribute manipulation interfaces, and node mounting interfaces to determine the availability of DOM manipulation capabilities. If the runtime environment supports DOM node creation, it traverses the complete DOM node tree structure formed after page parsing and performs a full search and matching of the node tree according to the preset global player unique identifier information. It then compares the type attribute and unique identifier attribute of each node to determine whether there is a video type node that is completely consistent with the preset identifier.

[0035] If the determination result indicates that a global video player instance already exists, the system uses a pre-defined globally unique identifier to call the DOM node precise query interface to locate and extract the existing video player object in the page's DOM tree. If no global video player instance exists, the system calls the standard DOM node construction interface, passing in the node type parameter corresponding to the video element, triggering the node instantiation logic to generate a video type DOM node object with an initial empty state and no resource address or style attributes set. The system reads a pre-defined, fixed globally unique player identifier string and writes this identifier string into the identifier attribute of the generated video node through the DOM node attribute setting interface. Basic attribute configurations are performed on the video node with the unique identifier, including disabling the automatic display of the default playback control bar, disabling automatic playback behavior after resource loading, configuring default prompt rules for playback errors, and disabling the default audio and video preloading strategy. Finally, the system locates the pre-specified player container node within the page and adds the video node with the unique identifier and basic attribute configuration as a child node to the container node's child node list through the DOM node mounting interface, thus formally incorporating the video node into the page's DOM tree structure and making it a valid element recognizable by the page rendering system. The video player object that has been successfully mounted to the DOM tree is stored in the global memory reference space, establishing a globally accessible object reference relationship. At the same time, a singleton lock flag is set to prevent subsequent logic from executing the creation, destruction, and reconstruction operations of the video node, ensuring that the player object exists uniquely throughout the entire page lifecycle.

[0036] The system reads a set of raw video clip data from an external data source or local configuration. This raw data is unsorted and unindexed, with each data entry containing a video source URL, slice duration, and slice status. Based on a preset playback order rule (fixed order rule), each video clip is assigned a numeric order index (order). The order index identifies the playback order; a smaller index indicates earlier playback. The assigned order index for each video clip is combined with the video source URL, slice duration, and slice status. This combination forms a complete slice data object. All generated slice data objects are then arranged in ascending order according to their order index values. After arrangement, a linear, ordered, and iterable data set is formed—the initial slice list.

[0037] Step S20: If the target slice object is in the playable slice list, the target video source address is determined as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource.

[0038] In this embodiment, a pre-created HTML5 video player object is obtained. This HTML5 video player object is a unique video element instance in the page's DOM structure, and no other similar player nodes exist. The attribute setting interface of the player object is called to write the validated target video source address into the player's src attribute, replacing the old video address stored in the previous round. The video player's src attribute is then updated to the resource address corresponding to the current target slice. The above process only modifies the attribute data of the player object and does not perform DOM structure change operations such as destroying, rebuilding, or moving the player node, nor does it generate any additional data interaction with the server.

[0039] In one feasible implementation, before step S20, the method may further include: obtaining the target state field of the target slice object in the initial slice list, determining whether the target slice object meets a preset playable state; if it does, adding the target slice object to the playable slice list.

[0040] In this implementation, an initial slice list is obtained. The memory collection creation interface is called to initialize a playable slice list in the front-end's local memory. This list stores playable slices that meet the filtering criteria; initially, the container contains no slice data. The traversal index value is initialized, initially set to 0, to mark the position of the slice currently undergoing state judgment within the ordered slice list. Using the current traversal index as the subscript, a location and matching operation is performed in the complete ordered slice list to obtain the single slice object at the corresponding position, which is then used as the processing object for this state judgment.

[0041] The system parses the fields of the currently located slice object, extracting the status identifier field `status` to obtain the corresponding status string, including types such as "Completed," "In Generation," and "Failed." The read `status` field value is compared with the preset playable status, with "Completed" being the only valid preset playable status. If the `status` field value is "Completed," the slice is determined to be playable; if the `status` field value is "In Generation" or "Failed," it is determined to be unplayable. If the result is a playable slice, the current slice object is fully added to the playable slice list, retaining all field information of the slice, including `order`, `source_url`, `duration`, and `status`. If the result is an unplayable slice, the current slice object is discarded and not added to the playable slice list, remaining only in the original complete slice list.

[0042] Step S30: Control the video player to perform playback operations based on the sliced ​​resources.

[0043] In this embodiment, after the src attribute of the video player is updated, the resource loading module inside the player is automatically activated, initiating the resource request process. Based on the target video source address pointed to by the src attribute, the player initiates a network data request or a local file read operation to obtain the original audio and video data of the corresponding resource location. During data transmission, the player performs internal processing actions such as data reception, data caching, format detection, audio and video separation, and initial decoding preparation, and updates information such as loading status, buffering progress, and network status in real time.

[0044] Continuously monitor various status events from the video player, including resource loading progress events, buffer sufficient events, loading complete events, and loading error events. Based on the amount of buffered data returned by the player, determine if the currently loaded data is sufficient to support continuous playback, avoiding playback stuttering or interruptions due to insufficient data. Simultaneously monitor for loading errors such as missing resources, network issues, or unsupported formats. When the buffered data reaches the playable threshold and no errors are detected, determine that the segmented resources are ready and playback can begin.

[0045] Optionally, when determining whether the currently loaded data is sufficient to support continuous playback based on the amount of buffered data returned by the player, the buffer status event of the HTML5 video player is listened to. The set of buffered time ranges and the current actual playback time of the video are obtained from within the player. The set of buffered time ranges consists of one or more buffer time periods returned by the player, each containing a start time point and an end time point, indicating that the video data within that time period has been fully loaded. The current actual playback time point is the time position the player has currently reached. Using the current playback time point as a reference, a buffer segment is searched consecutively within the buffered time range that connects to that playback point. The buffer end time is extracted from the consecutive buffer segments, and the bufferable duration is calculated: Bufferable duration = Buffer end time. The buffer duration value at the current playback time represents how long playback can continue without buffering from now on, thus obtaining the continuous playback buffer duration. A pre-set minimum playable buffer threshold is obtained. This threshold is an empirical safety duration, such as 2 seconds, 3 seconds, or 5 seconds, used to ensure uninterrupted playback. This threshold can be dynamically adjusted according to the network environment, but it is a fixed internal system configuration. The actual buffer duration is compared with the minimum buffer threshold. If the actual buffer duration is greater than or equal to the minimum buffer threshold, the buffer data is considered sufficient, meeting the continuous playback condition; if the actual buffer duration is less than the minimum buffer threshold, the buffer is considered insufficient, and the continuous playback condition is not met.

[0046] After confirming that the sliced ​​resources are ready, a playback execution command is sent to the video player via the player control interface. This command includes a playback start flag. Upon receiving the playback command, the player activates its internal decoding engine to decode the cached audio and video data frame by frame. The decoded video frame data is transmitted to the page rendering layer for image rendering, and the audio data is transmitted to the audio output module for sound playback. Simultaneously, audio and video timestamps are synchronized to ensure consistent playback quality. During playback, the player continuously reads buffered data and supplements the decoding, maintaining uninterrupted playback.

[0047] During segment playback, the system monitors the player's playback progress update events in real time to obtain the current played duration. The current played duration is compared with the `duration` field in the target segment object to determine if the segment's end point has been reached. Simultaneously, the system listens for the player's playback end trigger event; when the playback progress reaches the end of the segment duration or the player actively triggers the end event, the current segment is considered complete.

[0048] After step 40, steps S50 to S70 may also be included: Step S50: Obtain the playback progress of the video player and the target slice duration of the target slice object; Step S60: When the playback progress is greater than or equal to the target slice duration, it is determined that the target slice object has finished playing. Step S70: Update the index value of the target slice object. If the updated index value is less than the total number of slices, then determine the next slice object based on the updated index value.

[0049] In this implementation, the currently playing segment object is obtained, and its duration is extracted. Simultaneously, the real-time running status data of the video player object is read. The player's built-in progress monitoring interface is invoked to create a continuously running real-time monitoring task, which reads the player's current played duration at fixed time intervals. Simultaneously, listening for the player's native playback end event is enabled to capture the automatically triggered end signal. The real-time acquired played duration is compared with the total duration of the current segment; if the played duration is greater than or equal to the total segment duration, the playback end point is determined to have been reached. Monitoring is also performed to detect whether the player's native playback end trigger event is captured; the process is effective if any condition is met.

[0050] Upon determining that the playback end point has been reached, the index value stored in the current playback pointer is read. This index marks the position of the completed slice in the ordered playable sequence. The current pointer index is incremented by 1 to obtain the candidate index value for the next playable slice. The total number of segments in the ordered playable slice sequence is read to obtain the total number of playable slices in the sequence. The candidate index is compared with the total number of playable slices. If the candidate index is less than the total number of slices, the candidate index is considered valid and points to the next slice; if the candidate index is greater than or equal to the total number of slices, it is out of range, and the last slice has been played.

[0051] If the candidate index is valid, the system directly assigns the playback pointer to the candidate index, pointing to the next slice in the sequence. If the candidate index is out of range, a preset playback strategy is executed. Optionally, the playback strategy can be a loop mode, resetting the playback pointer to 0 and returning to the first slice; or a non-loop mode, marking the pointer as finished. The updated playback pointer index is then used to restart the complete playback flow for the next slice.

[0052] In this embodiment, by first locating the target slice corresponding to the playback pointer in the initial slice list and obtaining its video source address, and then verifying whether the slice is in the playable slice list, the player's src attribute is updated only for valid playable slices to load resources and execute playback. This ensures that only valid and usable video slices are loaded, avoiding playback errors and stuttering caused by invalid addresses and abnormal slices. At the same time, it achieves precise binding between the playback pointer and slice resources, ensuring a stable and controllable playback process. In scenarios with dynamic switching of multiple slices, it always outputs valid and playable content, improving the overall playback continuity and user experience.

[0053] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Furthermore, before step S10, steps A10 to A40 are included: Step A10: Traverse the playable slices in the playable slice list, and sum the first slice duration of each playable slice to obtain the total slice duration.

[0054] Step A20: Obtain the second segment duration of the played segment, determine the real-time played time of the current segment as the third segment duration, and add the second segment duration and the third segment duration to obtain the total playback duration.

[0055] In this embodiment, a list of playable segments is obtained, and a linear data structure is created in the front-end local memory as a globally unified virtual timeline. The virtual timeline has basic functions such as segment mapping, duration accumulation, and progress positioning. It does not rely on any external server interaction and is maintained only in local memory. During the construction process, according to the playback order of the ordered playable segment sequence, each playable segment is mapped to the corresponding position on the virtual timeline in sequence. The starting position of each segment is the sum of the durations of all preceding segments, and the ending position is its own starting position plus its own duration. All segments are seamlessly connected without gaps, integrating multiple independent segment durations into a continuous and unified virtual playback duration system, completely simulating the timeline logic of a single complete video.

[0056] Initialize a total duration accumulator variable, initially set to 0, to store the sum of the durations of all playable segments. Iterate through the list of playable segments, following the same order as the segments' sorting in the sequence. During iteration, for each segment, read its `duration` field value (i.e., the duration of the first segment), add this duration to the current accumulator variable, and update the variable's value. After iteration, the final value of the accumulator variable is the total duration of all playable segments. This total duration matches the total length of the global virtual timeline and corresponds to the end point of the virtual timeline.

[0057] The current playback pointer index is obtained, which identifies the position of the currently playing slice within the ordered playable slice sequence. This index is precisely matched against the indices of the ordered playable slice sequence to confirm the slice object corresponding to that index, which is the currently playing slice. The specific position of this slice in the sequence is also recorded, such as the 3rd slice. A preceding duration accumulation variable is initialized, initially set to 0, to store the total duration of all playable slices before the currently playing slice. The ordered playable slice sequence is traversed, including all slices with indices less than the current playing slice's index, starting from index 0 and incrementing sequentially to the current slice's index - 1. During traversal, for each preceding slice, the `duration` field value is read, and the `duration` value is added to the current preceding duration accumulation variable, updating the variable's value. After traversal, the final value of the preceding duration accumulation variable yields the duration of the third slice, corresponding to the starting position of the currently playing slice on the global virtual timeline.

[0058] Step A30: Determine the playback progress percentage based on the ratio of the total playback duration to the total slice duration.

[0059] Step A40: Determine the global playback progress based on the playback progress percentage, and render and display the global playback progress on the virtual timeline.

[0060] In this embodiment, the real-time progress monitoring interface of the video player is called to read the current playback progress data of the player. This data is the local playback time of the currently playing segment, which represents the duration from the start of playback to the current moment within the current segment. The current playback progress data is used as the basis for the relative progress of the current segment on the virtual timeline.

[0061] Based on the total duration of the preceding sequence and the real-time playback time of the current segment, the calculation formula is: Global Total Playback Time = Total Duration of the Preceding Sequence + Real-time Playback Time of the Current Segment. The total duration of the preceding sequence corresponds to the starting position of the current segment on the virtual timeline, and the real-time playback time of the current segment corresponds to the progress offset within the current segment. The sum of these two values ​​represents the absolute time elapsed from the beginning of the virtual finale to the current playback screen on the global virtual timeline. Progress Percentage = (Global Total Playback Time / Global Total Duration) × 100%. The final value is the global playback progress percentage in finale mode, representing the overall completion rate of the virtual finale.

[0062] Optionally, a playback mode configuration item is pre-configured. This configuration item is a preset status indicator, including continuous playback mode and single segment mode. The continuous playback mode corresponds to the overall continuous playback logic, which needs to display the global progress of the virtual block. The progress bar continuously increases, does not reset, and does not fall back. The single segment mode corresponds to the independent playback logic of a single segment, which only displays the progress of the currently playing segment. After switching segments, the progress bar is reset to 0 and starts increasing again.

[0063] If the current mode is a full-length simulation, the global playback progress percentage is directly used without any additional modifications or adjustments, and this percentage is taken as the final real-time playback progress. This progress percentage is also mapped to the global virtual timeline, marking the current progress's specific position on the virtual timeline. If the current mode is a single-segment preview, an independent progress percentage is calculated based solely on the data of the currently playing segment, determining the real-time playback time of the current segment and the `duration` field value of the currently playing segment. Single segment progress = (current segment's real-time playback time / current segment duration) × 100%.

[0064] Based on the determined playback mode, the corresponding progress percentage is output and stored in the progress cache area in memory, marking it as the current real-time playback progress. This progress value is synchronously provided to the front-end progress bar control, time display control, drag-and-drop positioning control, etc., for visual display and interactive operation. The progress bar control renders the fill length of the progress bar according to the progress percentage, continuously increasing in full-length mode and resetting after switching segments in single-segment mode; the time display control converts the progress percentage into the format of played time / total duration, displaying the virtual full-length duration in continuous playback mode and the total duration of the current segment in single-segment mode; the drag-and-drop positioning control maps to the corresponding position on the global virtual timeline or the current segment according to the progress percentage, allowing users to drag the progress bar to switch playback positions. Simultaneously, the player continuously monitors changes in playback progress, dynamically updating the real-time playback progress to ensure that the progress display is synchronized with the actual playback screen.

[0065] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 The above method also includes steps A50 to A80: Step A50: In response to a user's click operation on the progress bar of the virtual timeline, obtain the offset pixel value corresponding to the click operation.

[0066] Step A60: The ratio of the offset pixel value to the total width pixel value of the progress bar is determined as the target playback progress percentage.

[0067] Step A70: Determine the target virtual time point based on the target playback progress percentage and total duration.

[0068] Step A80: Match the target virtual time point to the time interval of the corresponding slice, determine the slice to be jumped to, and assign the video source address of the slice to be jumped to to the video player.

[0069] In this embodiment, a click event listening mechanism is registered and activated for the visual progress bar control corresponding to the global virtual timeline through a front-end interaction listening interface. When a user performs a click operation within the progress bar display area, the click event is captured, and the click position coordinate information carried by the click event is obtained, including: the horizontal offset pixel value of the click position relative to the left starting point of the progress bar, the total width pixel value of the progress bar control itself, and the boundary information of the current display area of ​​the progress bar. The click position is validated to determine whether the click coordinates fall within the valid area of ​​the progress bar; if the click is outside the area, the operation is ignored.

[0070] Based on the obtained effective click offset and the total width of the progress bar, a proportional calculation is performed: Target progress percentage = (Click horizontal offset pixel value / Total progress bar width pixel value) × 100%. The target progress percentage represents the global virtual final progress position that the user expects to jump to. The total duration of the virtual timeline is obtained, which is the sum of the total durations of all playable segments. The target virtual time point = Global total duration × (Target progress percentage / 100). The target virtual time point is an absolute time value, representing the total number of milliseconds from the beginning of the virtual final piece to the target position, and is the basis for cross-segment positioning. The playable segment list is traversed, and time interval information is calculated and constructed for each segment, including: the segment's start time on the virtual timeline, the segment's end time on the virtual timeline, and the segment's corresponding index value. All segments are arranged in playback order to form a continuous, non-overlapping, and seamlessly connected array of time intervals.

[0071] Based on the number of slices, either a sequential accumulation algorithm or a binary search algorithm is selected to locate which slice's time interval the target virtual time point falls within. In one feasible implementation, the slice to which the target virtual time point belongs is determined based on the sequential accumulation algorithm. The cumulative duration variable is initialized to 0. Starting from the first slice, the time interval array is traversed sequentially. The slice duration of the current slice is read, and the end time of the current slice is calculated as current_end = current_total + current slice duration. If the target virtual time point is less than or equal to the end time of the current slice, the current slice is the slice to be jumped to; otherwise, current_total = current_end, and the process continues to the next slice. When a slice that meets the condition is encountered, its index is recorded, which is the index of the slice to be jumped to.

[0072] In one feasible implementation, the segment to be jumped to is determined based on a binary search algorithm. The end times of all segments are extracted from the time interval array to generate a monotonically increasing array. The left boundary is left=0, and the right boundary is right=total number of playable segments - 1. The middle position is calculated as mid=(left+right) / / 2. The end time of the segment corresponding to the middle position is obtained. The target virtual time point is compared with the end time. If the target time ≤ the end time, the target is in the left half of the interval, and right=mid; if the target time > the end time, the target is in the right half of the interval, and left=mid+1. The above steps are repeated until the left and right boundaries coincide. The segment corresponding to the index is the segment to be jumped to.

[0073] Read the start time of the slice to be jumped to on the virtual timeline; the jump time point within the slice equals the virtual time point to be jumped to. The start time of the segment to be jumped to is determined. A pause command is sent to the video player to stop the current playback. The playback pointer index in memory is modified to the obtained index of the segment to be jumped to, completing the logical locking of the playback position. The `source_url` field is read from the segment to be jumped to obtain the video source address. The player's attribute setting interface is called to assign this address to the player's `src` attribute, triggering the player to load the resource of the segment to be jumped to. When the resource is loaded to a playable state and the buffer is sufficient, the player's time setting interface is called to set the playback time to the target time point within the obtained segment to be jumped to, and the player continues playback from the target time point.

[0074] Based on the first embodiment of this application, in the fourth embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. In addition, steps B10 to B30 are also included: B10 compares the slice sequence snapshot with the real-time slice list to determine if there are any slice change events.

[0075] B20. If the change event exists and the changed slice is after the currently playing slice, then the current playback state is maintained.

[0076] B30, if the change event exists, and the changed slice is after the current playback slice, or the changed slice is the current playback slice, then the playback pointer is reset.

[0077] In this embodiment, a `timeupdate` event listener callback is pre-registered with the HTML5 video player element. The `timeupdate` event is automatically triggered by the player at a preset trigger frequency to notify players of playback progress changes in real time. When the `timeupdate` event is triggered, the playback time of the current segment is extracted from the player, and its validity is verified to ensure that the current segment playback time is ≥0 and ≤ the current segment duration. The total duration of all segments preceding the current segment and the real-time playback time of the current segment are obtained, and the global total playback time is calculated using the formula: Global Total Playback Time = Total Duration of Preceding Segments + Current Segment Playback Time, resulting in the latest global absolute playback time on the virtual timeline. The global playback progress percentage is recalculated as: Progress Percentage = (Global Total Playback Time / Global Total Duration) × 100%.

[0078] Each time a segment sequence reaches a stable state—whether it's in playback, loaded, or after an operation—a snapshot of the segment sequence is generated for subsequent comparison to check for changes. The snapshot includes the following: the total number of segments, a unique identifier for each segment, the order index for each segment, the status for each segment, and the duration for each segment. The current sequence is compared with the snapshot based on a preset trigger strategy. Optionally, the trigger strategy can be a timed polling comparison, comparing the current real-time segment sequence with the previous snapshot item by item at fixed preset intervals. Alternatively, the trigger strategy can be an operation hook that triggers the comparison when the user adds or deletes segments, reorders segments, changes segment status, replaces segments, modifies addresses, or reloads the segment list.

[0079] In one feasible implementation, step B10 includes steps B11 to B13: Step B11: Compare the total number of slices in the slice sequence snapshot with the total number of slices in the real-time slice list. If they are inconsistent, confirm that the total number of slices has changed. Step B12: Compare the slice sequence snapshot with the slice identifier at the same position in the real-time slice list. If they are inconsistent, confirm that the slice order has changed. Step B13: If the slice identifier in the slice sequence snapshot is not in the real-time slice list, or the slice identifier in the real-time slice list is not in the slice sequence snapshot, then it is confirmed that a slice has been added or removed.

[0080] The process involves comparing the total number of slices, checking for changes in slice order, deletions, additions, and changes in slice content. Any discrepancy indicates a change event. The process also includes comparing the total number of slices in the snapshot with the total number in the current slice sequence; a difference in the two indicates a change in the number of slices. Next, the process compares the unique identifier of the i-th slice in the snapshot with the unique identifier of the i-th slice in the current sequence; a discrepancy indicates a change in slice order, either a change in order or a replacement of a slice. Finally, the process iterates through the unique identifiers of slices in the snapshot; if an identifier is missing in the current sequence, a slice has been deleted. Similarly, it iterates through the unique identifiers of slices in the current sequence; if an identifier is missing in the snapshot, a slice has been added. For slices with the same index and identifier, the process compares their status, duration, and source URL; a change in any of these indicates a change in slice content. Any discrepancy in these comparisons indicates a change event has occurred in the current slice sequence. And mark the change type.

[0081] If a change occurs, it is further determined whether the change occurred before, within, or after the current playback segment. If the changed segment index is less than the current playback index, the current playback position is affected; if the changed segment index equals the current playback index, the current segment is modified or deleted; if the changed segment index is greater than the current playback index, only subsequent segments are changed, and the current playback is not affected.

[0082] If the change does not affect the currently playing segment, maintain the playback state, do not modify the playback pointer, do not modify the current playback position (currentTime) within the current segment, do not pause or interrupt playback, and continue playing from the current position. If the current segment does not exist in the new sequence, is deleted, is replaced, or its URL or duration changes, and one or more of the above conditions are met, then the current playing segment is considered deleted or replaced. Reset the playback position, setting the playback pointer to 0, which is the starting position of the new sequence, and the player loads the first segment of the new sequence. Assign the real-time global playback progress percentage to the front-end progress bar control; the progress bar automatically updates its width, position, and fill length based on the percentage.

[0083] This application provides a front-end multi-video virtual synthesis playback method device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the front-end multi-video virtual synthesis playback method in the above embodiment 1.

[0084] The following is for reference. Figure 3This document illustrates a structural schematic diagram of a device suitable for implementing the front-end multi-video virtual synthesis playback method embodiments of this application. The front-end multi-video virtual synthesis playback method device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, personal digital assistants (PDAs), tablet computers (PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as main positioning terminals such as digital TVs and desktop computers. Figure 3 The front-end multi-video virtual synthesis playback method device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0085] like Figure 3 As shown, the front-end multi-video virtual synthesis playback method device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that performs various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the front-end multi-video virtual synthesis playback method device. The processing unit 1001, the read-only memory 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the front-end multi-video virtual synthesis playback method device to wirelessly or wiredly communicate with other devices to exchange data. Although a front-end multi-video virtual synthesis playback method device with various systems is shown in the figures, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0086] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0087] The front-end multi-video virtual synthesis playback method device provided in this application, employing the front-end multi-video virtual synthesis playback method in the above embodiments, can solve the technical problem of how to improve the convenience of multi-video playback. Compared with the prior art, the beneficial effects of the front-end multi-video virtual synthesis playback method device provided in this application are the same as those of the front-end multi-video virtual synthesis playback method provided in the above embodiments, and other technical features in this front-end multi-video virtual synthesis playback method device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0088] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0089] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0090] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the front-end multi-video virtual synthesis playback method in the above embodiments.

[0091] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0092] The aforementioned computer-readable storage medium may be included in the front-end multi-video virtual composite playback method device; or it may exist independently and not assembled into the front-end multi-video virtual composite playback method device. The aforementioned computer-readable storage medium carries one or more programs that, when executed by the front-end multi-video virtual composite playback method device, cause the front-end multi-video virtual composite playback device to: obtain the target slice object pointed to by the current playback pointer in the initial slice list, and determine the target video source address of the target slice object; if the target slice object is in the playable slice list, determine the target video source address as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource; and control the video player to perform playback operations based on the slice resource.

[0093] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the client computer, partially on the client computer, as a standalone software package, partially on the client computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the client computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0095] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0096] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned front-end multi-video virtual composite playback method, thereby solving the technical problem of how to improve the convenience of multi-video playback. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the front-end multi-video virtual composite playback method provided in the above embodiments, and will not be repeated here.

[0097] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A front-end multi-video virtual synthesis and playback method, characterized in that, The front-end multi-video virtual synthesis and playback method includes: Obtain the target slice object currently pointed to by the playback pointer in the initial slice list, and determine the target video source address of the target slice object; If the target slice object is in the playable slice list, the target video source address is determined as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource; The video player is controlled to perform playback operations based on the sliced ​​resources.

2. The front-end multi-video virtual synthesis and playback method as described in claim 1, characterized in that, The front-end multi-video virtual synthesis and playback method also includes: Get the video source address, slice duration, and slice status of the video segment to be played; The sequence index is determined according to the preset playback order, and the initial slice list is generated by combining the sequence index, the video source address, the slice duration, and the slice status.

3. The front-end multi-video virtual synthesis and playback method as described in claim 1, characterized in that, Before the step of determining the target video source address as the target src attribute value of the video player to trigger the video player to load the corresponding slice resource, the front-end multi-video virtual composite playback method further includes: Obtain the target state field of the target slice object in the initial slice list, and determine whether the target slice object meets the preset playable state; If the conditions are met, the target slice object is added to the playable slice list.

4. The front-end multi-video virtual synthesis and playback method as described in claim 1, characterized in that, After the step of controlling the video player to perform playback operations based on the slice resources, the front-end multi-video virtual synthesis playback method further includes: Obtain the playback progress of the video player and the target slice duration of the target slice object; When the playback progress is greater than or equal to the target slice duration, the target slice object is determined to have finished playing. Update the index value of the target slice object. If the updated index value is less than the total number of slices, then determine the next slice object based on the updated index value.

5. The front-end multi-video virtual synthesis and playback method as described in claim 1, characterized in that, Following the step of controlling the video player to perform playback operations based on the slice resources, the front-end multi-video virtual synthesis playback method further includes: Iterate through the playable slices in the playable slice list, and sum the first slice duration of each playable slice to obtain the total slice duration; Get the second segment duration of the played segment, determine the real-time played time of the current segment as the third segment duration, and add the second segment duration and the third segment duration to get the total playback duration; The playback progress percentage is determined based on the ratio of the total playback duration to the total segment duration. The global playback progress is determined based on the playback progress percentage, and the global playback progress is rendered and displayed on the virtual timeline.

6. The front-end multi-video virtual synthesis and playback method as described in claim 5, characterized in that, After the steps of determining the global playback progress based on the playback progress percentage and rendering and displaying the global playback progress on a virtual timeline, the front-end multi-video virtual composite playback method further includes: In response to a user's click operation on the progress bar of the virtual timeline, the offset pixel value corresponding to the click operation is obtained; The ratio of the offset pixel value to the total width pixel value of the progress bar is determined as the target playback progress percentage; Based on the target playback progress percentage and total duration, determine the target virtual time point; The target virtual time point is matched to the time interval of the corresponding slice to determine the slice to be jumped to, and the video source address of the slice to be jumped to is assigned to the video player.

7. The front-end multi-video virtual synthesis and playback method as described in claim 1, characterized in that, The front-end multi-video virtual synthesis and playback method also includes: Compare the slice sequence snapshot with the real-time slice list to determine if there are any slice change events; If the aforementioned change event exists, and the changed slice is after the currently playing slice, then the current playback state is maintained; If the change event exists, and the changed slice is after the current playback slice, or the changed slice is the current playback slice, then the playback pointer is reset.

8. The front-end multi-video virtual synthesis and playback method as described in claim 7, characterized in that, The slice change events include changes in the total number of slices, changes in the slice order, and additions or removals of slices. The step of comparing the slice sequence snapshot with the real-time slice snapshot to determine whether a slice change event exists includes: Compare the total number of slices in the slice sequence snapshot with the total number of slices in the real-time slice list. If they are inconsistent, then confirm that the total number of slices has changed. Compare the slice sequence snapshot with the slice identifier at the same position in the real-time slice list. If they are inconsistent, it is confirmed that the slice order has changed. If the slice identifier in the slice sequence snapshot is not in the real-time slice list, or the slice identifier in the real-time slice list is not in the slice sequence snapshot, then it is confirmed that a slice has been added or removed.

9. A front-end multi-video virtual synthesis playback device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the front-end multi-video virtual synthesis playback method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, it implements the steps of the front-end multi-video virtual synthesis playback method as described in any one of claims 1 to 8.

Images