A method and system for quality control of finished films based on big data playback

Abstract

This invention discloses a method and system for quality control of finished products based on big data playback, belonging to the field of intelligent playback data analysis technology. The method includes collecting player events, CDN segmentation, and transcoding / encapsulation pipeline data; uniformly labeling these data with content, version, session, segment, and scene identifiers; merging them into a scene library and fixing version snapshots; reconstructing event time series by session; slicing by segment or time window; writing timecodes, level change summaries, and event occurrence counts; training a generation model using version snapshots, scene conditions, and segment boundaries; generating virtual segments and statistically analyzing them; comparing differences with the proportion of real events in the early stages of deployment; and retrieving cases to generate action orders with action and segment ranges. The method of this invention achieves unified modeling of playback, distribution, and transcoding data; precise segment-level anomaly localization; and accelerates calibration and rectification through virtual sampling and case action orders, improving quality control efficiency and consistency.

Description

Technical Field

[0001] This invention relates to the field of intelligent analysis technology of playback data, specifically to a method and system for quality control of finished films based on big data playback. Background Technology

[0002] In recent years, with the large-scale distribution of long-form videos, short-form videos, and ultra-high-definition content, the playback chain has gradually formed an integrated system of transcoding and encapsulation, CDN distribution, and terminal playback. Quality control has evolved from traditional subjective sampling and offline bitstream verification to experience measurement and intelligent analysis centered on big data from the playback side. Data such as player SDK embeddings, CDN access and segmentation logs, and transcoding pipeline parameter snapshots are widely used to characterize experience events such as first-frame latency, stuttering, bitrate switching, and error code triggering, and support quality assessment based on statistical thresholds, rule engines, and machine learning. At the same time, G06N-related methods such as generative learning, contrastive learning, and multi-source data consistency modeling are gradually being applied to distribution fitting and anomaly identification in complex scenarios, making it possible to perform fine-grained judgment and localization of final video quality under multi-terminal, multi-network, and multi-node conditions.

[0003] Existing quality control technologies for finished products still have significant limitations: First, common solutions mainly rely on global aggregation of playback metrics or simple threshold alarms, failing to establish a consistent identification system for content, version, session, segment, and scene. This makes it difficult to establish a traceable correlation between experience events and transcoding configurations and segment boundaries, often limiting problems to coarse-grained judgments at the version or content level, and failing to address changes in timecode segments and specific time slots. Second, existing methods generally rely on the accumulation of real traffic after deployment for stable evaluation, lacking sufficient risk identification capabilities during the cold start phase of new versions. Furthermore, they struggle to establish a comparable distribution baseline under varying scenario conditions (terminal capabilities, network type, carrier, CDN node clusters, etc.), easily confusing link fluctuations with version configuration defects. Third, existing machine learning methods mostly remain at the classification and scoring level, lacking a mechanism to use version snapshots, scenario conditions, and segment boundaries as unified inputs to generate virtual session segment records and calibrate them against the real early distribution, thus making it difficult to achieve stable quantification of segment-level event proportion differences. Fourth, existing handling methods usually rely on manual experience or single-point rules, lacking a parameterized handling order generation path based on similar case database retrieval. This makes it difficult to standardize and solidify rectification actions and the scope of segments. When quality problems recur, repeated diagnosis and configuration are still required, making it difficult to form a reusable and traceable handling chain in engineering. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention is proposed.

[0005] Therefore, the technical problem solved by this invention is that existing video quality control methods based on playback data have problems such as inconsistent data identification leading to difficulty in traceability and correlation, coarse evaluation granularity making it difficult to locate timecode segments and changes in gear, insufficient ability to identify risks in early versions of new versions and to compare and calibrate under different scenarios, and how to generate executable handling actions and clarify the corresponding segment range under multiple scenario conditions.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a method for quality control of finished products based on playback big data, comprising collecting playback events from the player, CDN segmentation request records, and transcoding and encapsulation pipeline records, and marking each record with content, version, session, segment, and scene identifiers, merging them according to conditions to form a scene library, and simultaneously fixing the configuration as a version snapshot; stringing events together in chronological order by session, and cutting sessions into continuous segments according to segment sequence number or fixed time window, writing a timecode range, resolution level change summary, and whether and how many times various events appear in the segment for each segment; using the version snapshot, scene conditions, and segment boundaries as model input, and processing the segments... The event occurrence marker, event occurrence count, and process indicator summary are used as model outputs to train a virtual session fragment generation model. Based on a specified scenario and a specified fragment, the virtual session fragment generation model is invoked to generate virtual session fragment records with the same field structure as real session fragment records. The virtual occurrence count and virtual occurrence ratio of each event type in the virtual session fragment records are counted. The real occurrence ratio of each event type in the real session fragment records under the same scenario and the same fragment is counted. The real occurrence ratio is compared with the corresponding virtual occurrence ratio to form a difference record. Similar cases are retrieved from the case library to generate a handling order containing the handling action, action parameters, and fragment timecode range.

[0007] As a preferred embodiment of the video quality control method based on playback big data described in this invention, the following steps are included: The collection of playback events, CDN segmentation request records, and transcoding / encapsulation pipeline records from the player end includes storing these records in a database using a unified field dictionary. The field dictionary includes event type, event timestamp, playback tier identifier, error code field, segment sequence number or segment start / end timecode field, node identifier, operator and region field, and assigns a fixed content identifier, version identifier, session identifier, segment identifier, and scene identifier to each record. For events of the same type repeatedly reported within the same session, they are merged according to event type, timestamp tolerance, and tier identifier. Records with out-of-order or missing timestamps are corrected or removed according to preset rules, and the corresponding merge and missing marker fields are retained.

[0008] As a preferred embodiment of the video quality control method based on playback big data described in this invention, the following steps are included: the scene library is formed by merging the scene library according to terminal model or terminal capability level, system version, network access type, operator, region, CDN node cluster and time period characteristics to generate scene identifiers; the terminal model and CDN node are combined in a hierarchical or clustered manner to form scene condition fields; each scene identifier corresponds to a fixed set of scene condition fields and rule version number; when the original scene condition combination results in insufficient sample size, the scene is reverted to the previous level scene cluster according to the clustering rules of the scene library, and the revert level and revert reason fields are fixed in the scene record.

[0009] As a preferred embodiment of the video quality control method based on playback big data described in this invention, the method of simultaneously solidifying the configuration into a version snapshot includes solidifying the transcoding and encapsulation configuration fields of the version snapshot using the version identifier as an index; the configuration fields include a set of resolution levels and bitrate gradients, keyframe strategy and keyframe intervals, slice duration and slicing method, encapsulation format and protocol type, audio track and subtitle track fields, manifest generation strategy fields, DRM and encryption strategy fields, and transcoding toolchain version fields; when the same content undergoes re-transcoding, re-release, or parameter changes, a new version identifier is generated and a new version snapshot is formed, which is saved in parallel with the existing version snapshot; the effective time and release scope fields are solidified in the version snapshot record, and the snapshot hash or snapshot version number is written in the sample record.

[0010] As a preferred embodiment of the video quality control method based on playback big data described in this invention, the following steps are taken: First, events are sequentially linked together by session, and sessions are divided into continuous segments according to segment numbers or fixed time windows. This includes using segment numbers to generate segment identifiers when dividing sessions into segments, reading segment requests or manifest indexes to obtain segment numbers and segment start / end timecode ranges, and solidifying them as segment boundary fields. Second, when segment numbers are unavailable, continuous window numbers are generated based on the session start time and a fixed window length as segment identifiers, and the window start / end timestamps and the mappable playback timecode range are solidified. Third, for continuous events spanning more than one segment, events are split according to the event start / end time and written to corresponding segment records. The split records retain the original event number and split sequence number to maintain link consistency.

[0011] As a preferred embodiment of the video quality control method based on playback big data described in this invention, the following steps are taken: For each segment, the timecode range, resolution level change summary, and the occurrence and frequency of various events within the segment are recorded using a unified event set for event judgment and counting. The event set is configured by the platform event dictionary and includes first frame timeout anomalies, buffer occurrences and buffer over-thresholds, resolution fallback, bitrate oscillation, decoding errors, segment 404 or timeouts, manifest parsing failures, DRM authorization failures, black screen or recovery anomalies after seek, and audio-visual desynchronization prompts. For discrete events, the occurrence judgment and frequency are solidified; for continuous events, the duration and number of segments are solidified and mapped to discrete event markers according to the threshold rules of the event dictionary. For resolution fallback and bitrate oscillation events, the resolution level change sequence within and at the segment boundaries is judged, and the switching sequence summary and key time point list are solidified.

[0012] As a preferred embodiment of the video quality control method based on playback big data described in this invention, the generation of a disposal order containing disposal actions, action parameters, and segment timecode ranges includes a case library storing historical problem entries indexed by case numbers. Each problem entry has a fixed content identifier, version identifier, version snapshot field, a set of scene identifiers and a set of segment identifiers corresponding to the problem, and event count and duration statistics fields in the event set. The disposal actions also record the action type, action parameters, execution order, and configuration version number. When generating the current profile for the current version, a field structure consistent with the case entries is used. The version snapshot field, scene distribution summary, and segment distribution summary are aligned and encoded. Missing fields are filled with unknown placeholders and missing markers are retained. During the retrieval phase, the similarity between the current profile and the case profiles is calculated, and candidate cases are selected. The disposal action chains of the candidate cases are extracted to generate a disposal order, which includes the action type, action parameters, target scene identifier set, and target segment timecode range.

[0013] Another objective of this invention is to provide a video quality control system based on playback big data. This system can train a generative model using version snapshots, scene conditions, and segment boundaries as inputs. It can then generate virtual session segment records on specified scenes and segments and statistically analyze the results. The system can also compare the event ratio of real session segment records with the virtual occurrence ratio of each event type in the virtual session segment records to form a difference record. Finally, it can find similar cases from a case library to generate a handling order containing the action and segment range. This solves the problem that current video quality control methods based on playback data have insufficient ability to identify early risks in new versions and to perform comparative calibration under scene differences.

[0014] As a preferred embodiment of the video quality control system based on playback big data described in this invention, it includes: a data modeling module, a segment sampling module, and a calibration processing module; The data modeling module is used to collect and uniformly identify playback events on the player side, CDN sharding request records, and transcoding and encapsulation pipeline records. It assigns a content identifier, version identifier, session identifier, fragment identifier, and scene identifier to each record, and forms a scene library and version snapshot. The fragment sampling module is used to reconstruct the time series according to the session and segment it into fragments. It assigns fragment timecodes and event counts. At the same time, based on the version snapshot, scene conditions, and fragment boundaries, it calls the virtual session fragment generation model to generate virtual session fragment records with the same field structure as real session fragment records on specified scenes and specified fragments. It also summarizes the occurrence frequency and occurrence ratio of each event type in the virtual session fragment records. The calibration and handling module is used to statistically analyze the actual occurrence ratio of each event type in the real session fragment records under the same scene and the same fragment in the early stage of version launch. It compares the actual occurrence ratio with the virtual occurrence ratio of each event type in the corresponding virtual session fragment records to form a difference record. Then, it retrieves the case library to generate a handling order containing handling actions, action parameters, and fragment timecode ranges.

[0015] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement a method for quality control of finished films based on large amounts of playback data.

[0016] A computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the steps of a video quality control method based on large amounts of playback data.

[0017] The beneficial effects of this invention are as follows: The video quality control method based on playback big data provided by this invention collects playback events from the player, CDN segmentation request records, and transcoding and encapsulation pipeline records. Each record is uniformly and permanently identified by content, version, session, segment, and scene identifiers. Simultaneously, it categorizes these records according to terminal capabilities, network type, operator, node cluster, and time period to form a scene library, and permanently stores the transcoding and encapsulation configuration as a version snapshot. This achieves a consistent and structured binding of playback experience, distribution links, and production configurations, establishing a traceable association between experience events, segmentation acquisition behavior, and version parameter status. This avoids inconsistencies in statistical standards and location drift caused by fragmented multi-source data. Furthermore, events are sequentially linked by session and divided into continuous segments by segment number or fixed time window. At the segment level, timecode ranges, resolution level changes summaries, and the occurrence and frequency of various events are written, transforming playback anomalies from coarse-grained phenomena into quantifiable evidence that can be traced back to specific timecodes and segment boundaries. This supports precise identification and reproduction verification of problematic segments. Furthermore, the model is trained using version snapshots, scene conditions, and fragment boundaries as inputs. Virtual session fragment records are generated on specified scenes and fragments, and the results are statistically analyzed. Then, the actual occurrence ratio of each event type in the early online real session fragment records and the virtual occurrence ratio of each event type in the virtual session fragment records are used to form a difference record. The abnormal offset is placed on the two-dimensional structure of scene and fragment. Subsequently, a similarity search of the case library is used to generate a disposal order containing the disposal action and fragment range, so that the rectification action is parameterized, scoped, and traceable. This forms a closed-loop process from data modeling, fragment evidence solidification to calibration comparison and disposal output. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 The first embodiment of the present invention provides an overall flowchart of a video quality control method based on playback big data. Detailed Implementation

[0020] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0021] Example 1, referring to Figure 1 As an embodiment of the present invention, a method for quality control of finished films based on playback big data is provided, comprising: S1: Collect playback events from the player, CDN sharding request records, and transcoding and encapsulation pipeline records. Mark each record with content, version, session, segment, and scene identifiers. Merge them according to conditions to form a scene library, and solidify the configuration into a version snapshot.

[0022] Furthermore, the player-side uses SDK or player kernel embeddings to collect playback experience-related event sequences, recording and archiving these events chronologically. Events should at least cover initiating playback, first frame rendering, buffering start and end, resolution or bitrate level switching, seek behavior and post-seek recovery status, decoding errors and playback error codes, DRM authorization failures, audio-visual desynchronization prompts, and exiting playback. Each event record should include the event type, timestamp, current playback level information, error code, or reason for the exception, and ideally, fields for segment location, such as segment number, playback timestamp, or current segment identifier. On the content distribution chain side, CDN / edge node access logs and origin logs are collected, embedding fields such as request time, response status, TTFB, download time, hit or origin flag, node identifier, region, and carrier for segment requests, enabling a correspondence between experience events and the segment acquisition process. The production side collects logs from the transcoding, encapsulation, slicing, and publishing pipelines, and solidifies key parameters that affect playback experience and compatibility, such as the set of resolution levels and bitrate gradient, keyframe strategy and keyframe interval, slice duration and slicing method, encapsulation format and protocol type, number and language identifiers of audio and subtitle tracks, manifest generation strategy and version number, DRM and encryption strategy, and transcoding toolchain version, etc.

[0023] Based on unified collection of multi-source data, a consistent cross-source identification system is established to achieve alignment and traceability. A unique ContentID is assigned to each piece of content, used throughout the entire production, distribution, and playback chain. A unique VersionID is assigned to each release or transcoding / encapsulation product, and the corresponding encoding, encapsulation, slicing, and security policy configurations are fixed as a version parameter snapshot, serving as proof of the version's technical status. A unique SessionID is assigned to each actual playback session, and external condition fields such as device information, system version, player version, network type, carrier, region, and CDN node are bound at the session level. The playback process within a session is segmented according to segment boundaries or fixed time windows, and a SegmentID is assigned to each segment, allowing it to be mapped to the timecode range of the final piece. The segment identifier should be consistent with the platform's slicing and segmentation rules, prioritizing the use of segment sequence numbers or segment start and end timecodes.

[0024] Building upon the aforementioned identifier system, a playback scenario library is constructed. Complex external playback conditions are compressed into enumerable scenario identifiers (ScenarioIDs) to control for differences in external conditions during statistical analysis and comparison. Playback scenarios are constructed based on fields that significantly impact the user experience and are reliably obtainable. Terminal model and system version, terminal decoding capability level, network access type (e.g., WiFi / 4G / 5G), carrier, region, CDN node cluster, and time period characteristics are grouped or clustered to form several representative scenario categories. The generation rules and field ranges for each scenario category are then standardized. For fields with high cardinality and large fluctuations (e.g., terminal model, CDN node), capability classification or clustering should be performed first, followed by combination with carrier, network type, and time period to form ScenarioIDs, to avoid fragmented scenarios leading to sparse samples. Simultaneously, the scenario library should retain scenario coverage and sample size statistics.

[0025] Simultaneously, a version parameter snapshot library is constructed, creating a recalculated, comparable, and traceable structured snapshot for each VersionID. Version parameter snapshots should be permanently bound to the version identifier and record their effective date and release scope information. In cases where the same ContentID undergoes re-encoding, re-issuance, or parameter changes, a new VersionID should be generated, forming a new snapshot, which is saved in parallel with the old version snapshot, thus supporting cross-version comparison and version regression identification. Snapshot content should fully cover parameter fields that affect user experience and compatibility.

[0026] Through the above processing, two types of basic assets are ultimately formed: one is a playback scene library, which provides ScenarioID and its generation rules, so that each real session segment can be mapped to a specific scene; the other is a version parameter snapshot library, which provides VersionID and its complete parameter snapshot, so that each real session segment can be mapped to a specific version.

[0027] It should be noted that, using the unique SessionID as an index, playback experience events reported by the player and CDN / edge node sharding request logs are merged within the same session, combining records under the same SessionID into a reconstructable session timeline. The session timeline is sorted by event timestamps. Player-side events include at least: playback start, first frame presentation, buffer start and end, resolution or bitrate level switching, seek behavior and recovery after seek, decoding errors and playback error codes, DRM authorization failure, audio-visual desynchronization prompts, and playback exit. Link-side records include at least: sharding request time, response status code, TTFB, download time, hit / origin flag, node identifier, and region and carrier fields. For duplicate reports of the same type of event within the same session, they are merged according to event type, timestamp tolerance, and level identifier rules. Records with obviously disordered timestamps are corrected or removed according to the session start and end time range and event sequence constraints, and the removal flag and reason field are retained in the session record.

[0028] After the session timeline is formed, the playback process within the session is segmented at the segment level, and segment identifiers (SegmentIDs) are permanently assigned. Segment segmentation prioritizes segment numbering: for each segment request record within the session, the segment number or segment start / end timecode is read, and player events and link request records corresponding to the same segment number are grouped into the same segment. When segment numbers are unavailable, a fixed window length segmentation method is used: consecutive window numbers are generated based on the session start time and a fixed window length; the window number serves as the SegmentID, and the window start / end timestamps and the mappable playback timecode range field are synchronously permanently assigned to the segment record. For events that occur continuously across segments (e.g., buffering spans multiple segments or windows), they are split according to the event's start and end times and recorded separately in the intersecting SegmentIDs; the split records retain the original event number and the split sequence number to maintain event chain traceability.

[0029] For each SegmentID segment, the basic and associated fields of the segment are fixed. The basic fields include at least: ContentID, VersionID, SessionID, SegmentID, segment start and end timestamps, the playback timecode range corresponding to the segment, the main playback level identifier within the segment (resolution level / bitrate level), the number of level switches within the segment, and the list and occurrence count of error codes within the segment. The associated fields include at least: ScenarioID and the corresponding terminal model and system version, terminal decoding capability level, network access type (WiFi / 4G / 5G), carrier, region, CDN node cluster, time period characteristics, and other conditional fields; the version parameter snapshot field corresponding to the VersionID is read from the snapshot database according to the VersionID, and the snapshot version number or snapshot hash value is fixed in the segment record to ensure that the corresponding version parameter status can be determined when the same segment record is written to the database.

[0030] At the segment level, events are determined and counted using a unified event set. This event set, configured by the platform's event dictionary, includes at least the following: first frame timeout or abnormal first frame duration, buffering occurrence, buffering duration exceeding a threshold, resolution regression, bitrate oscillation, decoding error, segment 404 or timeout, manifest parsing failure, DRM authorization failure, black screen after seek or recovery anomaly, and audio-visual desynchronization prompts. For each event, two types of information are fixed in each segment record: one is the discrete occurrence determination and occurrence count (e.g., number of decoding errors, number of segment 404s, number of DRM failures, number of manifest failures); the other is the duration and occurrence count of continuous events (e.g., total buffering time, number of buffer segments), which are then mapped to discrete event determinations (e.g., buffering duration exceeding a threshold) according to threshold rules in the event dictionary. For events such as resolution regression and bitrate oscillation that require determination based on bit sequence, read the bit change sequence within the segment and at the segment boundary, and determine and count according to the rules of bit level descent number, number of repeated switching between adjacent segments, and number of round-trip switching within a certain time period, and solidify the determination basis fields (such as switching sequence summary and key time point list) in the segment record.

[0031] Before samples are written to the database, consistency and missing data processing are performed on the fragment records. Records lacking ContentID or VersionID, or unable to map ScenarioID, are marked as unusable and removed. Records lacking the SegmentID key positioning field are completed according to the rules of parsing the fragment sequence number from the fragment URL and inferring the window number from the timecode reported by the player; if completion fails, the record is removed. Abnormal fragment records that are repeated within a short period under the same SessionID are merged and counted according to the rules of consistent fragment timecode range, consistent event set, and consistent error code to avoid duplicate writing. For records with missing fields but whose events can still be determined, the missing dimension fields are filled with unknown identifier values, and the missing marker field is retained to ensure that the field structure of the written records is fixed.

[0032] After completing the above processing, the segment-level samples are written into the sample table or quality event ledger in the form of structured records. Each record contains at least ContentID, VersionID, SessionID, SegmentID, ScenarioID, segment timecode range, segment start and end timestamps, playback level information, occurrence determination and count / duration fields for each event in the event set E, as well as necessary deduplication and merging flags and missing flag fields.

[0033] S2: Sequence events chronologically by session, and cut sessions into continuous segments by segment number or fixed time window. Write timecode range, resolution level change summary, and whether and how many times each type of event appears in the segment for each segment.

[0034] Furthermore, segment-level records that meet the field integrity requirements are extracted from historical playback samples as the training dataset. Each record in the training dataset contains at least ContentID, VersionID, SegmentID, ScenarioID, segment timecode range, playback sequence summary within the segment, occurrence determination and count / duration fields for each event in the event set E, and structured fields for the version parameter snapshot. The training dataset is segmented according to the effective time of VersionID, and samples with missing version parameter snapshots or unresolvable snapshot hashes are removed. For scenarios with insufficient ScenarioID samples, the clustering rules of the scenario library are used to fall back to the next higher-level scenario cluster to ensure that each scenario category has a trainable sample size. For cases where there are multiple duplicate session segment records for the same ContentID and the same SegmentID, all samples are retained, but the session source identifier and deduplication marker fields are retained in the sample records to control the duplication weight during training.

[0035] The input to the learning model is defined as a structured vector consisting of three parts: the first part is a snapshot field vector of version parameters, including the resolution tier set, bitrate gradient, keyframe strategy and keyframe interval, slice duration, container format, audio / subtitle track field, manifest strategy field, DRM strategy field, and transcoding toolchain version field; the second part is a scene condition field vector, including terminal model or terminal capability level, system version, network access type, operator, region, CDN node cluster and time period cluster, etc.; the third part is a segment boundary and segment context field vector, including SegmentID, segment start and end timestamps, segment timecode range, main playback tier identifier within the segment, tier switching sequence summary, and segment segment request status distribution summary, etc. Discrete fields are encoded using dictionary encoding and the encoding table version number is fixed; continuous fields are normalized and the normalization parameter version number is fixed; missing fields are encoded using a unified unknown placeholder encoding and the missing flag bit is retained, thus fixing the dimension of the input vector.

[0036] The output of the learning model is defined as two types of objectives: event distribution vectors and process index vectors. The event distribution vectors, with the event set E as their dimension, record the probability representation of each event occurring in the segment under corresponding conditions. The process index vectors record numerical indicators that can be directly obtained from the segment records, such as the total buffering time, the number of buffer segments, the first frame latency interval, the number of resolution downtimes, the number of bitrate oscillations, and the number of error code family triggers. For the construction of the event distribution vectors, the event occurrence count / duration field in the segment records is first mapped to discrete event labels according to the event dictionary rules, and then the labels are converted into multi-hot vectors or frequency vectors. For the construction of the process index vectors, statistical fields in the segment records are used directly, and extreme values ​​are processed according to quantile truncation rules to avoid the training process being dominated by outliers.

[0037] A conditional generative architecture is used to train the virtual playback simulator, enabling it to generate an output format consistent with real session segment records when given input version parameter snapshot field vectors, scene condition field vectors, and segment boundary field vectors. This output includes event distribution vectors and process indicator vectors. During training, samples with different ContentIDs, ScenarioIDs, and SegmentIDs are mixed-sampled to ensure coverage of multiple scenes and segment locations within a batch. For event categories with extremely low occurrence but significant impact (e.g., segmentation 404, manifest failure, DRM failure, decoding error), class resampling or loss weighting is used to enable the model to learn the occurrence patterns of these events under specific conditions. During training, the model structure version, parameter version, and training data slice range are fixed, and the trained model is saved in a deployable format. The input encoding table version number and normalized parameter version number are also fixed to ensure consistency between the input and output fields during inference and those during training.

[0038] After training, a consistency constraint check is performed on the model output. This requires that the dimensions of the generated event distribution vector match the event set, and that each dimension of the event distribution vector be non-negative and meet normalization conditions. For the generated process indicator vectors, each indicator must fall within a reasonable observable range on the platform, and truncation or backoff strategies are implemented for samples that violate this range. A fixed number of sample inputs are extracted from each ScenarioID and common SegmentID location for offline generation testing. Statistical summaries of the generated outputs (e.g., event distribution mean, variance, extreme values) are recorded, and these summaries, along with statistical summaries from the training set under the same conditions, are solidified as model acceptance records.

[0039] It should be noted that after determining the finished version that needs to be virtually sampled, the ContentID and VersionID corresponding to that finished version are read, and the complete snapshot fields of that VersionID are loaded from the version parameter snapshot library. These fields include the resolution level set and bitrate gradient, keyframe strategy and keyframe interval, slice duration and slicing method, container format and protocol type, audio track and subtitle track fields, manifest generation strategy field, DRM and encryption strategy field, and transcoding toolchain version field. Simultaneously, the effective date and release scope information of that version are read. The snapshot fields are then structured and encoded. Discrete fields are converted to encoded values ​​according to a fixed dictionary encoding table, continuous fields are converted to normalized values ​​according to fixed normalization parameters, and missing fields are encoded using a unified unknown placeholder and a missing flag is set, ensuring that the input field dimensions are fixed and consistent with the field definitions used during model training.

[0040] The system selects a set of scenes from the playback scene library and loads the scene condition fields corresponding to the ScenarioID. These scene condition fields must include at least the terminal model or capability level, system version, network access type, carrier, region, CDN node cluster, and time period cluster. The high-cardinality digital segments are clustered according to the rules fixed in the scene library, and the scene cluster identifier is read. The selection of the scene set adopts a coverage-based set generation method, generating a scene list based on the sample size and coverage weights statistically obtained from the scene library. Scenes with insufficient sample size but belonging to key terminal capability levels or key carriers are supplemented with additional samples to ensure that the field combinations for each selected scene are complete and usable. For each ScenarioID, its field version number or rule version number is loaded to solidify the scene definition criteria in the sampling records.

[0041] Determine the set of segments to be sampled and generate segment boundary inputs. The segment set consists of SegmentIDs, which are preferentially generated using the segment sequence number: read the manifest or slice index corresponding to the ContentID, parse to obtain the segment sequence number and the segment start and end timecode range, and use the segment sequence number as the SegmentID, while also fixing the segment start and end timestamp or timecode range field; when the manifest is unavailable or parsing fails, a fixed window length segmentation method is used to generate SegmentIDs: generate consecutive window numbers based on the segment start time and a fixed window length, use the window number as the SegmentID, and fix the window start and end timestamp and the mappable playback timecode range field in the segment record. The size of the segment set is determined according to the sampling configuration parameters, and can be selected to cover all segments or extract subsets according to segment length and key paragraph strategy, and the extraction strategy identifier and extraction parameters are written into the sampling record.

[0042] Virtual sampling is performed for each ScenarioID and SegmentID combination. The total number of simulation samples for this combination is set, and a virtual session fragment process is generated for each sample. The input for each sample consists of three parts: the version parameter snapshot encoding vector corresponding to the VersionID, the scene condition encoding vector corresponding to the ScenarioID, and the fragment boundary and fragment context field encoding vector corresponding to the SegmentID. The above input is fed into the virtual playback simulator to obtain the output, which at least includes the event distribution representation and process index representation of the event set E. The event distribution representation of the output is parsed according to the event set dimension to generate the occurrence mark or occurrence count of each event in this sample, and accumulated in the simulation count of the ScenarioID and SegmentID combination. The process index representation of the output is written into the sampling record according to the index field, and the mean, variance, extreme values ​​and other summary fields are accumulated and statistically analyzed. Index values ​​that violate the range constraints in the model output are processed according to the preset truncation rules, and the truncation mark field is recorded for traceability.

[0043] The simulation sampling results for each ScenarioID and SegmentID combination are stored in a database. The stored data includes at least: ContentID, VersionID, ScenarioID, SegmentID, total number of simulation samples, the number of simulation occurrences for each event in the event set, and a summary of the corresponding process metrics. Simultaneously, the model version number, input encoding table version number, normalization parameter version number, scene rule version number, and fragment generation strategy identifier and parameters used in this sampling are stored to ensure that the sampling records can be regenerated using the same criteria during recalculation. For multiple virtual sampling operations performed on the same ContentID and VersionID, the sampling batch number is stored, and different batches of scene sets and fragment sets are distinguished to avoid data confusion caused by overwriting.

[0044] S3: The virtual session fragment generation model is trained by taking the version snapshot, scene conditions, and fragment boundaries as inputs and the event occurrence markers, event occurrence counts, and process indicator summaries within the fragment as outputs. Based on the specified scene and fragment, the virtual session fragment generation model is invoked to generate virtual session fragment records with the same field structure as the real session fragment records. The virtual occurrence counts and virtual occurrence ratios of each event type in the virtual session fragment records are counted. The real occurrence ratios of each event type in the real session fragment records under the same scene and fragment are counted. The real occurrence ratios are compared with the corresponding virtual occurrence ratios to form difference records. Similar cases are retrieved from the case library to generate a handling order containing the handling action, action parameters, and fragment timecode range.

[0045] In this embodiment, the virtual session fragment record refers to a structured fragment record generated by the virtual session fragment generation model based on version snapshots, scene conditions, and fragment boundaries. Its field structure is consistent with that of the real session fragment record, including at least content identifier, version identifier, scene identifier, fragment identifier, fragment timecode range, event type, event occurrence marker, event occurrence count, and process indicator summary. The process indicator summary includes one or more of the following: buffer duration, number of buffer segments, first frame latency interval, number of resolution downtimes, number of bitrate oscillations, and number of error code family triggers.

[0046] When generating virtual session fragment records, the version snapshot field corresponding to the target version, the scene condition field corresponding to the target scene, and the fragment boundary field corresponding to the target fragment are read first, and the model input vector is generated according to the field encoding table and normalization parameters fixed in the training phase. Then, the model input vector is input into the virtual session fragment generation model to obtain the event occurrence marker, the number of events, and the process indicator summary. Finally, the virtual session fragment record is written according to the field structure of the real session fragment record.

[0047] Furthermore, in the early stages after the final version is released, in order to avoid misjudgment due to relying solely on the results of the virtual sampling inspection before the release, and also to avoid discovering quality problems only after a large amount of real traffic, the results of the virtual sampling inspection before the release are calibrated based on a small amount of real playback data covering multiple scenarios, and the calibrated deviation distribution is used to distinguish between version-side defects and link-side anomalies.

[0048] The term "real early sample" refers to real user playback session data collected within a pre-defined early observation window on a platform after a new version is launched. This early observation window can be terminated by any stopping condition. 1) Time window condition: The cumulative duration after launch reaches the preset time. ; 2) Sample size condition: The cumulative number of valid sessions must reach the preset threshold. .

[0049] By setting both time and scale conditions, we can ensure that we can obtain sufficient early statistical information for content with different levels of popularity, without having to wait indefinitely.

[0050] To ensure that real early samples can stably reflect the real playback process, validity constraints are set for session segments during collection. For example, the session must have at least a certain number of segments or the playback duration must exceed a threshold; the session event sequence can be mapped to a clear segment identifier and version identifier; event reports have a reconstructable time sequence; and abnormal reports with obvious duplication are deduplicated according to rules to avoid statistical bias caused by repeated reports from a single device.

[0051] Virtual sampling refers to the process of calling a virtual playback simulator to generate virtual playback session segments under the same version conditions, segment conditions, and playback scenario conditions before (or immediately after) going live. The purpose of virtual sampling is not to replace real data, but to provide prior expectations based on historical big data learning, so that the platform can still obtain a relatively stable reference baseline when real traffic is still low.

[0052] Virtual sampling is performed based on a combination of scenes and segments: for each playback scene With fragments Fixed number of samplings Each sampling generates a virtual session fragment process, and determines whether various events occur in the process according to a unified event set, thereby obtaining structured statistical results of the occurrence frequency and total number of samples that are consistent with the statistical caliber of the real early samples.

[0053] To ensure direct comparison between real early-stage and virtual sampling, three types of statistical objects are unified: 1) Event set This refers to a set of discrete event types monitored during final quality control. These events can be configured using the platform's event dictionary and include, but are not limited to: first frame timeout / abnormal first frame duration, buffering occurrence, buffering duration exceeding a threshold, resolution regression, bitrate oscillation, decoding error, segmentation 404 / timeout, manifest parsing failure, DRM authorization failure, black screen or recovery anomaly after seek, and audio-visual desynchronization warnings. The principles for setting this event set are that it should be directly identifiable from playback logs / link logs, objectively countable, and reproducible.

[0054] 2) Play scene identifier ScenarioID: A scenario identifier obtained by clustering based on conditions such as terminal model and system version, network type and operator, CDN node cluster, region, and time period. The internal playback environment is similar, which is used to control differences in external conditions.

[0055] 3) Fragment identifier The segment ID, obtained from the segment sequence number or fixed window length slice number, can be mapped to the timecode range of the finished product. It is used to locate the high-risk interval and support the executable output of re-transcoding, re-slicing and grayscale strategies.

[0056] For each scene and segment combination The actual early count and the virtual sampling count were performed separately.

[0057] True early count: In real early samples, the scene falls into And the corresponding fragment The total number of valid session segments; In the above valid session fragment, the event The number of occurrences (which can be obtained directly from the log count according to the event determination rules).

[0058] Virtual sampling count: In virtual sampling inspections, for The total number of simulation samples performed in combination is usually equal to ; In the above simulation sampling, the event The number of occurrences (obtained by statistically analyzing the event sequences generated by simulation according to the same decision rule).

[0059] The above statistics show that both real early-stage and virtual sampling yielded the same set of events, the same scene, and the same segment of counting structures, thus laying the foundation for a strictly meaningful distribution comparison.

[0060] To retain the intuitive meaning of the event occurrence ratio, and to avoid the problem of an event not occurring in the simulation and thus having a probability of 0, making the logarithm uncomputable when the sample size is limited, a smoothing ratio based on counting is adopted, expressed as:

[0061]

[0062] in, This indicates that in real early samples, the scenario is... The fragment is In that batch of conversation snippets, the event The proportion of occurrence, This indicates that in the virtual sampling sample, for the same scenario With fragments In multiple virtual session fragment records obtained through simulation sampling using a generative model, events... The proportion of occurrence.

[0063] Based on the above probability definition, for each Calculate the bias strength between the real early distribution and the virtual sampling distribution:

[0064] in, In the same scenario And the same fragment Under the given conditions, the strength of the deviation between the actual early event distribution and the virtual sampling event distribution.

[0065] exist Smaller, that is, the scene With fragments The proportions of various events in the early stages of the actual event were generally close to those in the virtual sampling, showing that the proportions of the main event types were similar: for example, key events such as buffering exceeding the threshold, resolution regression, decoding errors, and 404 fragmentation were all low or similar in both reality and simulation. There was no situation where a certain type of event suddenly increased significantly in reality but was almost non-existent in simulation.

[0066] Similar event structures: The early event structure in reality is similar to that generated in simulation. For example, in reality, there are mainly a few bit rate switching and very few error codes, and the simulation is also the same; or in reality, there is mainly slight buffering, and the simulation can also generate a similar buffering distribution.

[0067] No obvious new abnormal patterns: In the early stages of the actual simulation, there were no abnormal combinations that were not covered by the simulation, such as a large number of 404 errors in a certain segment, a sudden increase in DRM failures in a certain segment, or a large number of black screens after seek.

[0068] The source of bias is more likely to be random fluctuations: even if a certain event increases slightly, the increase will not increase the overall bias after being distributed across the event dimensions. It is usually a natural fluctuation caused by the limited sample size.

[0069] The existence of the above four situations indicates that the virtual sampling inspection is highly consistent with the actual early performance, and the sampling inspection conclusions before the launch can be directly used. when Larger, that is, in the scene With fragments The distribution of events in the early stages of the actual data differed systematically from that in the virtual sampling. Specifically, a certain type of key event was significantly higher in reality than in the simulation. For example, in the early stages of the actual data, there were frequent occurrences of 404 / timeout errors, manifest parsing failures, DRM failures, decoding errors, or a significant increase in the proportion of buffering exceeding the threshold. In contrast, the proportion of the corresponding events given by the virtual sampling in the same scene and the same segment was significantly lower.

[0070] The biases are concentrated and patterned: they are not random scattering points, but rather exhibit regularity, such as multiple adjacent segments of the same segment timing out consecutively, the same segment repeatedly triggering the same error code family in multiple sessions, and the same segment continuously regressing and oscillating in clarity from a high level. These patterns will form a consistent offset in the event set dimension.

[0071] Combination anomalies that are not covered or underestimated in simulation may occur: For example, a combination of buffering exceeding the threshold, bit rate oscillation, and seek recovery anomalies may occur simultaneously in the early stages of the real event, while simulation samples rarely generate this combination, causing multiple event dimensions to deviate simultaneously.

[0072] The existence of the above three situations indicates that there were abnormal deviations in the early stages that the virtual sampling could not fully explain, and further root cause differentiation and handling decisions are needed.

[0073] Calculated It is not used directly for single-point alarms, but rather for analyzing their clustering patterns at the scene and segment dimensions to distinguish root cause directions: 1) The criterion for link-side anomalies: If The significant increase was mainly concentrated in a few scenarios. The phenomenon is concentrated in specific carriers, specific CDN node clusters, specific geographical areas and time periods, or specific network types, and is not common in other scenarios, while the number of segments that increase simultaneously is also high. If the distribution is relatively scattered or drifts with changes in link conditions, it is likely to be judged as a link-side anomaly (scheduling, node congestion, origin-to-origin jitter, regional network fluctuations, etc.). In this case, the platform is more suitable to trigger node scheduling, origin-to-origin policy adjustment, regional gray-scale deployment, and rate limiting, rather than directly judging that the entire version has inherent defects.

[0074] 2) Identification morphology of version-side defects: If The elevation is generally high in most scenarios, and the elevation is concentrated in the same segments. If the occurrence of the same timecode range is repeatedly mapped to a specific feature (such as keyframe intervals, slicing strategies, audio track encapsulation strategies, etc.) in the version parameter snapshot, it is likely to be judged as a version-side defect (encoding / encapsulation / slicing / manifest / audio track subtitle issues). In this case, the platform prioritizes outputting re-transcoding or parameter adjustment suggestions and provides an executable timecode range for the concentrated segments.

[0075] It should be noted that when establishing the case library, historically confirmed quality issues and handling records were organized into structured case entries and written into the case library. Each case entry has a fixed CaseID, bound to the corresponding ContentID and VersionID. It also includes the snapshot field of the version parameters at the time the issue occurred, the ScenarioID set and SegmentID set corresponding to the issue, and the occurrence count and duration statistics fields of key events in the event set E. The case entry also records a complete parameterized description of the handling action, including the action type identifier (e.g., re-transcoding, re-encapsulation, re-slicing, manifest repair, audio / subtitle track correction, DRM policy adjustment, gradient adjustment, keyframe policy adjustment, CDN node scheduling adjustment, origin server policy adjustment, grayscale range adjustment, etc.), action trigger time, action executor or system trigger identifier, action execution configuration parameters, and the version identifier or configuration version number at which the action takes effect. In cases where the same issue has multiple handling actions, each handling is recorded as an independent action and fixed in chronological order to form an action chain within the case entry.

[0076] For each case entry, a case profile field is generated for similarity comparison with the new version of the risk profile. The case profile is stored with a fixed field structure, containing at least three types of information: first, the encoded vector or hash digest of the version parameter snapshot field, representing the version parameter state at the time the case occurred; second, a scene distribution digest, recording the set and proportion of high-frequency ScenarioIDs or scene clusters in the case; and third, a fragment distribution digest, recording the set of high-risk SegmentIDs in the case and their corresponding timecode ranges, and solidifying the occurrence pattern summary of key events in the event set E (e.g., fragment 404 sets, DRM failure sets, buffer over-threshold sets, bitrate oscillation sets, decoding error sets, etc.) at the fragment dimension. To enable direct comparison of profiles, all discrete fields are encoded using a dictionary encoding table version consistent with the sample database, and this encoding table version number is solidified in the case entry; all continuous fields are normalized using a normalized parameter version consistent with the sample database, and this normalized parameter version number is solidified in the case entry.

[0077] When an action needs to be output for a specific ContentID and VersionID, the version parameter snapshot field, virtual sampling statistics field, and the fixed ScenarioID set, SegmentID set, and event count statistics field from the current record are read. These fields are used to generate the current profile according to the same field structure as the case profile, and missing fields are handled and aligned: missing discrete fields are filled with a unified unknown placeholder code and the missing flag is retained; missing consecutive fields are filled with the default values ​​of the corresponding fields and the missing flag is retained; if the ScenarioID and SegmentID sets are too large, the Top set is truncated according to preset rules and the truncation rule identifier field is retained to ensure that the profile dimensions are fixed.

[0078] During the case retrieval phase, the similarity between the current profile and each case profile in the case library is calculated, and Top-K candidate cases are selected. Similarity calculation employs a field-level combination method, calculating the distance for the version parameter snapshot field, scene distribution summary field, and fragment distribution summary field separately, and then weighted and fused to obtain the total similarity. The distance for the version parameter field is calculated based on the discrete matching degree and continuous difference of the corresponding field, while the distance for scene distribution and fragment distribution is calculated based on set overlap and distribution difference. For each candidate case, its similarity decomposition information is output, including at least the version parameter field with the highest matching degree to the current profile, the ScenarioID or scene cluster with the highest overlap, and the SegmentID or timecode range with the highest overlap, serving as reference fields during action assembly.

[0079] During the action generation phase, the action chains of the Top-K candidate cases are read, and the action types and parameters are extracted sequentially according to the similarity of the candidate cases to form an action candidate set for the current version. Mutual exclusion and dependency constraints are applied to the action candidate set: For mutually exclusive actions of the same type (e.g., rollback to an old version and re-transcoding to generate a new version), only one is retained according to priority rules; for actions with pre-dependent dependencies (e.g., re-transcoding requires determining keyframe strategies and bitrate gradient parameters), necessary parameter fields are completed according to the dependency relationship; for actions requiring limited execution range (e.g., only performing level blocking or downgrading on terminal clusters with a specific ScenarioID), the target scene set is written into the action, and its selection criteria field is fixed. For parameters involving segment ranges in the action, SegmentID and corresponding timecode range are uniformly used for expression, and the start and end ranges are written according to the segment boundary fields in the sampling records to avoid outputting ambiguous unexecutable intervals.

[0080] The finalized actions are output as structured action orders. Each action order includes at least an action order number, ContentID, VersionID, action type, action parameters, target ScenarioID set, target SegmentID set and timecode range, execution sequence number, mutual exclusion / dependency processing flags, a list of source case IDs and their similarity summaries, and the version number of the encoding table and normalization parameters used to generate the action order. For actions requiring new versions (e.g., re-encoding, re-encapsulation, re-slicing), the generation rules or reserved fields for the new version's VersionID are fixed in the action order, and the new VersionID is written back to the action order record after the new version is produced, thus establishing the association between the action chain and the version chain. For actions involving changes to release or scheduling configurations, the configuration version number, configuration effective time, and effective scope fields are fixed in the action order to ensure that action execution records are traceable and recalculated.

[0081] Example 2, one embodiment of the present invention, provides a method for quality control of finished films based on big data playback. In order to verify the beneficial effects of the present invention, scientific demonstration is carried out through economic benefit calculation and simulation experiments.

[0082] First, three finished videos awaiting release on a video platform were selected as test subjects, denoted as Video A, Video B, and Video C, respectively. Two release versions were prepared for each video: one using the common "threshold aggregation quality control method" (denoted as the old method), and the other using the process of this invention (denoted as the new invention). The platform enabled a unified collection channel for player SDK data entry, CDN edge segmentation request logs, and transcoding / encapsulation pipeline logs. Upon data entry, each record was assigned a content identifier, version identifier, session identifier, segment identifier, and scene identifier. The scene identifier was obtained by merging terminal capability level, system version, network access type, operator, region, CDN node cluster, and time segment characteristics to ensure that playback conditions of the same type could be grouped into the same scene. The version snapshot was automatically fixed by transcoding / encapsulation parameters, including the resolution level set and bitrate gradient, keyframe strategy and interval, slice duration and slicing method, encapsulation format, audio / subtitle track information, manifest strategy, and DRM strategy, and was bound and saved with the version identifier.

[0083] During the session processing phase, player events and segment request logs are merged using session identifiers as indexes, and events are concatenated into a reconstructable session timeline by timestamps. Subsequently, segments are divided into continuous segments based on segment sequence numbers. If individual terminals lack segment sequence numbers, the segmentation reverts to a fixed time window, maintaining a fixed start and end timecode range. For each segment, a segment timecode range and a resolution level change summary (including summaries of segment position changes due to rollback and oscillation) are written. Segment-level judgments are performed on events such as first frame timeout anomalies, buffering occurrence and threshold exceeding, resolution rollback, bitrate oscillation, decoding errors, segment 404 / timeout, manifest parsing failure, DRM failure, seek recovery anomalies, and audio-visual desynchronization prompts, forming structured records of "occurrence" and "occurrence frequency / duration." Subsequently, a generative model is obtained using version snapshots, scene conditions, and segment boundary fields as training inputs and a conditional generative training method. In the virtual sampling phase, multiple samples are taken for specified scene and segment combinations to generate virtual session segment records and summarize event counts and statistical summaries. After the version is launched, a small number of real conversation fragment records covering multiple scenarios are collected in the early window. The actual occurrence ratio of each event type in the real conversation fragment records and the virtual occurrence ratio of each event type in the virtual conversation fragment records are registered to distinguish them. Finally, the current profile is formed based on the difference registration, similar cases are searched in the case library and the action chain is assembled to generate a disposal order containing action type, action parameters and a clear fragment time code range to ensure that the disposal record has an executable fragment boundary description.

[0084] Table 1 Experimental Data

[0085] As can be seen from the pre-launch risk segment coverage, the old method struggled to achieve usable risk segment coverage before release (all were 0%). This is because the old method primarily relied on real playback aggregation metrics and threshold alarms after launch, lacking calculable sampling criteria for scenarios and segments before release. In contrast, this invention, through version snapshots, scene conditions, and segment boundary-driven virtual segment generation and statistics, achieved pre-launch risk segment coverage of A / B / C segments at 88%, 85%, and 90% respectively, indicating that risk segments could be structurally labeled into the segment range before release. Further observation of the latency of the first high-risk location after launch reveals that the old method took 210 / 240 / 180 minutes, while this invention took 18 / 22 / 15 minutes. This difference reflects the different capabilities of the two methods in handling the sparsity of information in the early stages: the old method required a longer period to accumulate playback volume before stably triggering aggregation alarms, while this invention could register the difference between the real occurrence ratio of each event type in the real session segment record and the virtual occurrence ratio of each event type in the virtual session segment record into the scene and segment dimensions within the early window, thus significantly shortening the high-risk location latency.

[0086] In terms of granularity, the segment localization error shows a significant difference: the old method is on the order of 38–45 seconds, while the present invention is on the order of 5–7 seconds. This difference stems from the different recording methods: the old method often focuses on content-level or version-level statistics, and segment boundaries and timecodes are not forcibly fixed as decision objects, resulting in only a broad range. The present invention binds event judgment, frequency, and timecode range to segment records at the session slicing stage, and makes virtual sampling and comparison with the real early stages follow the same segment boundaries, so the error is stably converged to the segment or fixed window length level. Correspondingly, the false positive rate and false negative rate reach 14.2%–18.0% and 23.8%–29.5% respectively in the old method, while the present invention reduces them to 4.6%–6.0% and 9.0%–12.0% respectively. This shows that after the present invention adopts the difference registration method of scene merging, segment event ratio, and comparison of the virtual occurrence ratio of each event type in the virtual session segment record, the anomaly judgment is no longer amplified by single network fluctuations or individual terminal disturbances, and segment-level evidence can reduce false negatives caused by aggregation and dilution.

[0087] Regarding the implementation of handling procedures, the hit rate of handling orders using the old method was only 38%–45%, while this invention improves it to 78%–85%. Simultaneously, the "manual review time" decreased from 7.8–9.2 hours per content to 2.3–3.1 hours per content, and the "number of unnecessary re-coding / rollbacks" decreased from 3–4 times per content to 1–2 times per content. These indicators collectively point to the standardization differences in the handling process: the old method relied heavily on manual selection of actions based on alarm experience, making it difficult to solidify the scope of actions and segments, resulting in trial and error and repeated reviews; this invention generates a current profile after registering differences and extracts the handling action chain through similarity retrieval from the case library, while simultaneously writing a clear segment timecode range into the handling order, thus ensuring a consistent structure for action selection and scope definition, reducing invalid handling and repeated verification. Finally, the number of user complaints (per 100,000 views) decreased from 34 / 40 / 28 to 12 / 15 / 10 for finished videos A / B / C, respectively. This is consistent with the aforementioned improvement trend in location latency, false alarms and missed alarms, and handling hit rate. This indicates that the chain process from recording standards and fragmented evidence to case retrieval and handling orders has resulted in quantifiable improvements in the exposure and handling pace of online experience issues.

[0088] Example 3, an embodiment of the present invention, provides a final film quality control system based on playback big data, including a data modeling module, a segment sampling module, and a calibration processing module.

[0089] The data modeling module collects and uniformly identifies playback events on the player, CDN sharding request records, and transcoding and encapsulation pipeline records. It assigns content identifiers, version identifiers, session identifiers, fragment identifiers, and scene identifiers to each record, forming a scene library and version snapshots. The fragment sampling module reconstructs time series according to sessions and segments them, fixing fragment timecodes and event counts. It also generates virtual session fragment records on specified scenes and fragments and summarizes the statistical results. The calibration and handling module summarizes the actual occurrence ratio of each event type in the early real session fragment records and forms a difference record with the virtual occurrence ratio of each event type in the virtual session fragment records. It then retrieves the case library to generate a handling order containing handling actions and fragment ranges.

[0090] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0091] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0092] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0093] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc. It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

[0094] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for quality control of finished films based on big data playback, characterized in that, include: Collect playback events from the player, CDN sharding request records, and transcoding and encapsulation pipeline records. Mark each record with content, version, session, segment, and scene identifiers. Merge them according to conditions to form a scene library. At the same time, solidify the configuration into a version snapshot. Events are strung together chronologically by session, and sessions are cut into continuous segments by segment number or fixed time window. For each segment, a timecode range, a summary of resolution changes, and whether and how many times various events appear in the segment are written. The virtual session fragment generation model is trained by taking the version snapshot, scene conditions and fragment boundaries as model inputs and the event occurrence markers, event occurrence counts and process indicator summaries within the fragment as model outputs. Based on a specified scenario and a specified segment, the virtual session segment generation model is invoked to generate a virtual session segment record with the same field structure as the real session segment record, and the number of virtual occurrences and the proportion of virtual occurrences of each event type in the virtual session segment record are counted. The system calculates the actual occurrence rate of each event type in real conversation segments under the same scenario and segment, compares the actual occurrence rate with the corresponding virtual occurrence rate to form a difference record, retrieves similar cases from the case library, and generates a handling order containing the handling action, action parameters, and segment timecode range.

2. The final product quality control method based on playback big data as described in claim 1, characterized in that: The collection of player-side playback events, CDN shard request records, and transcoding / encapsulation pipeline records includes storing these records in a database using a unified field dictionary. The field dictionary includes event type, event timestamp, playback level identifier, error code field, segment sequence number or segment start and end timecode field, node identifier, carrier and region fields, and assigns content identifier, version identifier, session identifier, segment identifier and scene identifier to each record; For the same type of event reported repeatedly within the same session, merge them according to event type, timestamp tolerance and level identifier. Correct or remove records with out-of-order or missing timestamps according to preset rules, and retain the corresponding merge mark and missing mark fields.

3. The final product quality control method based on playback big data as described in claim 2, characterized in that: The process of merging scenarios into a scenario library based on conditions includes merging the scenario library according to terminal model or terminal capability level, system version, network access type, operator, region, CDN node cluster and time period characteristics to generate scenario identifiers. The terminal model and CDN node are combined in a hierarchical or clustered manner to form scenario condition fields. Each scene identifier corresponds to a fixed set of scene condition fields and a rule version number; When the original scene conditions result in insufficient sample size, the scene is reverted to the next higher-level scene cluster according to the clustering rules of the scene library, and the revert level and revert reason fields are fixed in the scene record.

4. The final product quality control method based on playback big data as described in claim 3, characterized in that: Simultaneously, the configuration is solidified into a version snapshot, which includes solidifying and transcoding the configuration fields using the version identifier as an index. The configuration fields include the set of resolution levels and bitrate gradient, keyframe strategy and keyframe interval, slice duration and slicing method, container format and protocol type, audio track and subtitle track fields, manifest generation strategy field, DRM and encryption strategy field, and transcoding toolchain version field. When the same content is re-encoded, re-sent, or the parameters are changed, a new version identifier is generated and a new version snapshot is formed, which is saved in parallel with the existing version snapshot. The effective time and release scope fields are fixed in the version snapshot record, and the snapshot hash or snapshot version number is written in the sample record.

5. The final product quality control method based on playback big data as described in claim 4, characterized in that: The process of stringing events together in chronological order on a session-by-session basis and dividing the session into continuous segments according to the segment number or a fixed time window includes using the segment number to generate segment identifiers when dividing a session into segments, reading the segment request or manifest index to obtain the segment number and the segment start and end time code range, and fixing it as a segment boundary field. When the segment sequence number is unavailable, a continuous window number is generated based on the session start time and a fixed window length as the segment identifier, and the start and end timestamps of the window and the range of the playable timecode are fixed. For continuous events that span more than one segment, the event is split according to the start and end times and written separately to the intersecting segment records. The split records retain the original event number and the split sequence number to maintain the consistency of the link.

6. The final product quality control method based on playback big data as described in claim 5, characterized in that: The process of writing timecode range, resolution level change summary, and whether and how many events occur within each segment includes segment records using a unified event set for event judgment and counting. The event set is configured by the platform event dictionary and includes first frame timeout anomaly, buffer occurrence and buffer over-threshold, resolution fallback, bitrate oscillation, decoding error, segment 404 or timeout, manifest parsing failure, DRM authorization failure, black screen or recovery anomaly after seek, and audio-visual desynchronization prompts. For discrete events, the occurrence determination and occurrence frequency are fixed; for continuous events, the duration and number of segments are fixed, and they are mapped to discrete event tags according to the threshold rules of the event dictionary. The system determines the bit rate change sequence within and at the boundaries of the read segment for clarity regression and bit rate oscillation events, and solidifies the switching sequence summary and key time point list.

7. The final product quality control method based on playback big data as described in claim 6, characterized in that: The generation of a disposal order, which includes disposal actions, action parameters, and fragment timecode ranges, includes a case library that stores historical issue entries indexed by case number. The issue entries have fixed content identifiers, version identifiers, version snapshot fields, a set of scene identifiers and a set of fragment identifiers corresponding to the issue, and event count and duration statistics fields in the event set. The disposal actions also record the action type, action parameters, execution order, and configuration version number. When generating the current profile for the current version, the same field structure as the case entries is used. The version snapshot field, scene distribution summary and fragment distribution summary are aligned and encoded. Missing fields are filled with unknown placeholders and missing markers are retained. During the retrieval phase, the similarity between the current profile and the case profile is calculated and candidate cases are selected. The action chain of the candidate cases is extracted to generate a action order. The action order contains the action type, action parameters, target scene identifier set and target segment time code range.

8. A system employing the video quality control method based on playback big data as described in any one of claims 1 to 7, characterized in that: Includes a data modeling module, a fragment sampling module, and a calibration and processing module; The data modeling module is used to collect and uniformly identify playback events on the player, CDN sharding request records and transcoding and encapsulation pipeline records, and to solidify content identifiers, version identifiers, session identifiers, fragment identifiers and scene identifiers for each record, and to form a scene library and version snapshots; The segment sampling module is used to reconstruct the time series by session and segment it into segments, solidify the segment time code and event count, and call the virtual session segment generation model based on version snapshot, scene conditions and segment boundaries to generate virtual session segment records with the same field structure as real session segment records on specified scenes and specified segments, and summarize the occurrence frequency and occurrence ratio of each event type in the virtual session segment records. The calibration and handling module is used to statistically analyze the actual occurrence ratio of each event type in the real session fragment records under the same scenario and the same segment in the early stage of version launch, compare the actual occurrence ratio with the virtual occurrence ratio of each event type in the corresponding virtual session fragment records to form a difference record, and then retrieve the case library to generate a handling order containing the handling action, action parameters and fragment timecode range.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the video quality control method based on big data playback as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the video quality control method based on big data playback as described in any one of claims 1 to 7.

Images