Display apparatus and recording playback method

Abstract

The application provides a display device and a recording playback method. In response to a user's playback operation on a recording file, channel information and program information are extracted from the recording file without obtaining key events of the recording file, an event obtaining request carrying the channel information and the program information is sent to a cloud server, a first key event list returned by the cloud server is received, key events not located in a recording time period are filtered out, absolute time stamps of the key events are converted into playing positions to obtain a third key event list, and finally, key event markers are marked on a playback time axis in a playback interface according to the third key event list. The method obtains key events from the cloud server and performs time filtering and time conversion, so that the key event markers are accurately corresponded to the playback picture, intuitive visual navigation is provided for the user, and the convenience of the playback operation is improved.

Description

Technical Field

[0001] This application relates to the field of display device technology, and in particular to a display device and a recording and playback method. Background Technology

[0002] Display devices refer to terminal devices capable of outputting specific display images, such as smart TVs, communication terminals, smart advertising screens, and projectors. Taking smart TVs as an example, smart TVs are television products based on Internet application technologies, possessing open operating systems and chips, and having open application platforms. They enable two-way human-computer interaction and integrate multiple functions such as audio-visual, entertainment, and data to meet diverse and personalized user needs.

[0003] Display devices offer recording functions, including scheduled recording or intelligent recommended recording, allowing users to record programs of interest to local storage for later playback. In replay scenarios of long programs such as sports events, users often only focus on the highlights (such as goals, red cards, substitutions, etc.), but traditional replay methods lack intelligent navigation. When replaying recorded programs, users can only manually perform fast forward or rewind to locate the highlights, which is cumbersome and time-consuming. Summary of the Invention

[0004] This application provides a display device and a recording and playback method to solve the problem of cumbersome operation when playing back recorded files.

[0005] In a first aspect, this application provides a display device, comprising: monitor; The communication device is configured to communicate with a cloud server. The controller is configured as follows: In response to a user's playback operation on a recorded file, channel information and program information are extracted from the recorded file without obtaining key events of the recorded file; Send an event retrieval request to the cloud server; the event retrieval request carries the channel information and the program information, and is used to request the cloud server to retrieve the first key event list corresponding to the channel information and the program information; Receive the first list of key events returned by the cloud server based on the event acquisition request; Filter out key events that are not located within the recording time period of the recorded file from the first key event list to obtain the second key event list; The absolute timestamps of each key event in the second key event list are converted into playback positions to obtain the third key event list; the playback position is the time offset of the absolute timestamp relative to the recording start time of the recording file. The system controls the display to show the playback interface of the recorded file, and marks key events on the playback timeline of the playback interface according to the third key event list.

[0006] The above technical solution has the following beneficial effects or advantages: In this embodiment, when a user plays back a recorded file, a list of key events can be requested from the cloud server. The returned list is then filtered by time to remove invalid events outside the recording time period, preventing interference with annotation. Furthermore, by converting the absolute timestamps of the key events into offsets relative to the recording start time, the annotation misalignment problem caused by inconsistent time bases is resolved, ensuring that key event markers accurately correspond to the playback screen. Finally, by marking key events on the playback timeline, intuitive visual navigation is provided to the user, allowing them to quickly locate content segments of interest and improving the convenience of playback operations.

[0007] In some embodiments of this application, the controller is further configured to: Acquire key event acquisition flags of the recorded file; the key event acquisition flags are either a first flag or a second flag, the first flag is used to indicate that key events of the recorded file have been acquired, and the second flag is used to indicate that key events of the recorded file have not been acquired; If the key event acquisition flag is the first flag, it is determined that the key event of the recorded file has been acquired; If the key event acquisition flag is the second flag, it is determined that the key event of the recorded file has not been acquired; After receiving the first list of key events returned by the cloud server, the key event acquisition flag is changed to the first flag.

[0008] The above technical solution has the following beneficial effects or advantages: By introducing a dual-state identification mechanism for key event acquisition flags, a clear record of key event acquisition status is established for each recorded file. Upon playback triggering, this flag can be read to quickly determine whether a key event has already been acquired. After receiving the key event list from the cloud, the flag is changed to the first flag, ensuring that repeated acquisitions are not triggered subsequently, reducing redundant operations.

[0009] In some embodiments of this application, the controller, in response to a user's playback operation on a recorded file, is further configured to: Detect the recording source of the recorded file; In the absence of key events in the recorded file and if the recording source is intelligent recommendation recording, extract channel information and program information from the recorded file.

[0010] The above technical solution has the following beneficial effects or advantages: By introducing the intelligent recommendation recording as a trigger condition, fine-grained control over the acquisition of key events can be achieved. Intelligent recommendation recordings typically consist of programs automatically recorded by the system based on user profiles, programs that users may be interested in. These programs exhibit distinct key event distribution characteristics, and users have the strongest demand for key event annotation. By limiting the trigger for key event acquisition to intelligent recommendation recordings, the number of invalid requests to the cloud server can be effectively reduced, network load and server pressure can be lowered, and the targeting of the annotation function can be improved, all while ensuring user experience.

[0011] In some embodiments of this application, the controller is further configured to: In the absence of key events in the recorded file, a key event acquisition task is created; the key event acquisition task includes the recording file identifier of the recorded file; the key event acquisition task is a task to request the cloud server to obtain the first list of key events. The critical event acquisition task is added to a bounded deduplication queue; the bounded deduplication queue is used to deduplicate critical event acquisition tasks corresponding to the same recording file based on the recording file identifier when the critical event acquisition task is enqueued. The critical event retrieval task in the bounded deduplication queue is executed by the worker thread corresponding to the bounded deduplication queue.

[0012] The above technical solution has the following beneficial effects or advantages: By introducing a bounded deduplication queue and an asynchronous processing mechanism using worker threads, the critical event acquisition task is decoupled from the main playback process. By using the bounded deduplication queue as a task buffer, deduplication is performed based on the recording file identifier when tasks are enqueued, effectively preventing multiple submissions of the same recording file and avoiding waste of cloud resources. Simultaneously, the bounded nature ensures that the queue capacity has an upper limit. When a large number of playback operations trigger multiple acquisition tasks in a short period, the queue can control the system load by discarding the oldest task or rejecting new tasks, preventing unlimited task backlog that could lead to memory overflow or system crashes. Furthermore, by using independent worker threads to asynchronously consume tasks in the queue, the entire critical event acquisition process (including cloud requests, data reception, filtering, and transformation) is executed in a background thread, without blocking the main user playback process. Users can start normal playback without waiting for the critical event acquisition to complete, ensuring the immediacy and smoothness of the playback operation.

[0013] In some embodiments of this application, the controller converts the absolute timestamps of each key event in the second key event list into playback positions, specifically configured as follows: Obtain the recording start time of the recorded file; Calculate the time difference between the absolute timestamp of each key event and the recording start time; The time difference is converted into the time unit value corresponding to the recorded file to obtain the playback position.

[0014] The above technical solution has the following beneficial effects or advantages: This embodiment ensures the accuracy and operability of the conversion process through explicit time base conversion calculation logic, and ensures the accuracy of the labeled positions.

[0015] In some embodiments of this application, after obtaining the third key event list, the controller is further configured to: In response to an instruction to display the associated event list, control the display to show the third key event list; In response to the user's selection of a target key event from the third key event list, the target playback position corresponding to the target key event is determined; The system jumps from the current playback position of the recorded file to the target playback position, so that the display plays the playback screen corresponding to the target playback position.

[0016] The above technical solution has the following beneficial effects or advantages: By providing a list of key events and interactive navigation through the list, a structured and visual navigation entry point for key events is offered to users. This list-based navigation shortens the user's search path and reduces time costs, making it particularly suitable for scenarios with a large number of key events, allowing users to quickly browse and select events of interest for viewing.

[0017] In some embodiments of this application, after the controller marks key events on the playback timeline in the playback interface according to the third key event list, it is further configured to: In response to the user's selection operation of the target key event marker on the playback timeline, the system jumps from the current playback position of the recorded file to the target playback position corresponding to the target key event marker, so that the display plays the playback screen corresponding to the target playback position.

[0018] The above technical solution has the following beneficial effects or advantages: By providing the ability to select and jump to key event markers on the playback timeline, a more intuitive and natural interaction method is offered to users. Users can click on markers on the timeline at any time during playback to jump to the next point, resulting in a shorter operation path and more intuitive interaction.

[0019] In some embodiments of this application, after the controller obtains the third list of key events, it is further configured to: The third list of key events is written to the playback memory instance to render key event markers in real time during the playback of the recorded file; The third key event list is written to an event data file for persistent storage, so that the third key event list can be directly retrieved from the event data file when the recording file is played back next time. The list of the third key events is written into the media database for querying and reading by the business modules in the display device.

[0020] The above technical solution has the following beneficial effects or advantages: By simultaneously writing the third key event list to three storage levels—the playback memory instance, the event data file, and the media database—multi-level redundant storage and differentiated applications of key event data are achieved. Writing to the playback memory instance allows key event markers during the current playback process to be rendered onto the playback timeline in real time, eliminating the need for frequent disk or database reads and writes, ensuring the immediacy and smoothness of annotation. Persistent storage in the event data file binds key event data to the recording file itself, allowing it to be loaded directly from the local file during subsequent playbacks without requesting the cloud server again. Writing to the media database provides a unified query interface for other business modules (such as program recommendation, user behavior analysis, and intelligent search), enabling flexible access to key event data by upper-layer applications.

[0021] In some embodiments of this application, the controller is further configured to: After obtaining the third list of key events, if the display is showing the playback interface of the recorded file, the playback timeline in the playback interface is refreshed to display the key event markers.

[0022] The above technical solution has the following beneficial effects or advantages: By introducing a real-time refresh mechanism, the interface update problem in scenarios where the user is replaying the recording file while the key event acquisition is complete is solved. After the background worker thread completes the acquisition, filtering, and transformation of the key events, if the user is replaying the recording file, the playback timeline can be refreshed to display the newly acquired key event markers, without requiring the user to exit and reopen or manually refresh.

[0023] Secondly, this application provides a recording and playback method, including: In response to a user's playback operation on a recorded file, channel information and program information are extracted from the recorded file without obtaining key events of the recorded file; Send an event retrieval request to the cloud server; the event retrieval request carries the channel information and the program information, and is used to request the cloud server to retrieve the first key event list corresponding to the channel information and the program information; Receive the first list of key events returned by the cloud server based on the event acquisition request; Filter out key events that are not located within the recording time period of the recorded file from the first key event list to obtain the second key event list; The absolute timestamps of each key event in the second key event list are converted into playback positions to obtain the third key event list; the playback position is the time offset of the absolute timestamp relative to the recording start time of the recording file. Display the playback interface of the recorded file, and mark key events on the playback timeline of the playback interface according to the third key event list.

[0024] The above technical solution has the following beneficial effects or advantages: In this embodiment, when a user plays back a recorded file, a list of key events can be requested from the cloud server. The returned list is then filtered by time to remove invalid events outside the recording time period, preventing interference with annotation. Furthermore, by converting the absolute timestamps of the key events into offsets relative to the recording start time, the annotation misalignment problem caused by inconsistent time bases is resolved, ensuring that key event markers accurately correspond to the playback screen. Finally, by marking key events on the playback timeline, intuitive visual navigation is provided to the user, allowing them to quickly locate content segments of interest and improving the convenience of playback operations. Attached Figure Description

[0025] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram illustrating an operational scenario between a display device and a control device provided in some embodiments of this application; Figure 2 This is a schematic diagram of the hardware configuration of a display device provided in some embodiments of this application; Figure 3 This is a schematic diagram of the software configuration of a display device provided in some embodiments of this application; Figure 4 A flowchart illustrating the recording and playback method provided in some embodiments of this application; Figure 5 This application provides a schematic diagram of the key event acquisition and flag determination process for some embodiments; Figure 6 A schematic diagram illustrating the processing flow of a key event acquisition task provided in some embodiments of this application; Figure 7 A schematic diagram illustrating the timestamp conversion process provided for some embodiments of this application; Figure 8 A schematic diagram of key event markers in a playback interface provided in some embodiments of this application; Figure 9 A schematic diagram showing a list of key events provided for some embodiments of this application; Figure 10System architecture diagrams for recording and playback provided in some embodiments of this application; Figure 11 Timing diagrams for recording and playback provided for some embodiments of this application. Detailed Implementation

[0027] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described below do not represent all embodiments consistent with this application. They are merely examples of systems and methods consistent with some aspects of this application as detailed in the claims.

[0028] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0029] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0030] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0031] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0032] In this embodiment, the display device 200 generally refers to a device with screen display and data processing capabilities. For example, the display device 200 includes, but is not limited to, smart TVs, mobile terminals, computers, monitors, advertising screens, wearable devices, virtual reality devices, augmented reality devices, etc.

[0033] Figure 1 This is a schematic diagram illustrating an operational scenario between a display device and a control device provided in some embodiments of this application. For example... Figure 1As shown, a user can operate the display device 200 via touch operation, a mobile terminal 300, and a control device 100. The control device 100 receives user input commands and converts them into control commands that the display device 200 can recognize and respond to. For example, the control device 100 can be a remote control, a stylus, a gamepad, etc.

[0034] The mobile terminal 300 can function as a control device for human-computer interaction between the user and the display device 200. It can also function as a communication device for establishing a communication connection with the display device 200 and exchanging data. In some embodiments, the mobile terminal 300 can have software applications installed on it and communicate with the display device 200 via network communication protocols to achieve one-to-one control and data communication. Furthermore, it can transmit audio and video content displayed on the mobile terminal 300 to the display device 200 for synchronized display.

[0035] In some embodiments, the mobile terminal 300 or other electronic devices may also simulate the functions of the control device 100 by running an application that controls the display device 200.

[0036] like Figure 1 The diagram also shows that the display device 200 communicates with the server 400 via various communication methods. This allows the display device 200 to communicate via a local area network (LAN), a wireless local area network (WLAN), and other networks.

[0037] Display device 200 can provide broadcast television reception function, and can also be equipped with intelligent network television function that provides computer support, including but not limited to network television, smart television, Internet Protocol television (IPTV), etc.

[0038] Figure 2 Provided for some embodiments of this application Figure 1 Hardware configuration block diagram of display device 200.

[0039] In some embodiments, the display device 200 may include at least one of a tuner 210, a communication device 220, a detector 230, a device interface 240, a controller 250, a display 260, an audio output device 270, a memory, a power supply, and a user input interface 280.

[0040] In some embodiments, detector 230 is used to acquire signals from the external environment or to interact with the outside world. For example, detector 230 includes a light receiver, a sensor for acquiring ambient light intensity; or, detector 230 includes an image acquisition device, such as a camera, which can be used to acquire external environmental scenes, user attributes, or user interaction gestures; or, detector 230 includes a sound acquisition device, such as a microphone, for receiving external sounds.

[0041] In some embodiments, the display 260 includes display function components for presenting images and driving components for driving image display. The display 260 is used to receive and display image signals output from the controller 250. For example, the display 260 can be used to display video content, image content, menu control interface components, and user control UI interfaces, etc.

[0042] In some embodiments, the communication device 220 is a component used to communicate with external devices or the server 400 according to various communication protocol types. The display device 200 may have multiple communication devices 220 depending on the supported communication methods. For example, when the display device 200 supports wireless network communication, it may have a communication device 220 with WiFi functionality. When the display device 200 supports Bluetooth connectivity, it needs to have a communication device 220 with Bluetooth functionality.

[0043] The communication device 220 enables the display device 200 to communicate with external devices or the server 400 via wireless or wired connections. Wired connections utilize data cables, interfaces, or other components to connect the display device 200 to external devices. Wireless connections utilize wireless signals or wireless networks. The display device 200 can directly establish a connection with external devices or indirectly through gateways, routers, or other connection devices.

[0044] In some embodiments, the controller 250 may include at least one of a central processing unit, a video processor, an audio processor, a graphics processor, and a power processor, and a first to an nth interface for input / output. The controller 250 controls the operation of the display device and responds to user operations through various software control programs stored in memory. The controller 250 controls the overall operation of the display device 200.

[0045] In some embodiments, the controller 250 and the tuner 210 may be located in different separate devices, that is, the tuner 210 may also be located in an external device of the main device where the controller 250 is located, such as an external set-top box.

[0046] In some embodiments, a user can input user commands through a graphical user interface (GUI) displayed on a display 260, and the user input interface 280 receives the user input commands through the graphical user interface (GUI).

[0047] In some embodiments, the audio output device 270 can be a built-in speaker of the display device 200 or an external audio output device connected to the display device 200. For the external audio output device connected to the display device 200, the display device 200 may also be provided with an external audio output terminal, through which the audio output device can be connected to the display device 200 to output sound from the display device 200.

[0048] In some embodiments, the user input interface 280 can be used to receive instructions from user input.

[0049] To enable user interaction, in some embodiments, the display device 200 may run an operating system. The operating system is a computer program used to manage and control the hardware and software resources of the display device 200. The operating system can control the display device to provide a user interface; for example, the operating system can directly control the display device to provide a user interface, or it can provide a user interface by running an application. The operating system also allows users to interact with the display device 200.

[0050] It should be noted that the operating system can be a native operating system based on a specific operating platform, a third-party operating system that is deeply customized based on a specific operating platform, or an independent operating system specifically developed for display devices.

[0051] An operating system can be divided into different modules or levels based on the functions it implements, for example... Figure 3 As shown, in some embodiments, the system is divided into three layers, from top to bottom: the Applications layer (referred to as the "application layer"), the middleware layer, and the hardware layer.

[0052] In some embodiments, the application layer provides services and interfaces for applications, enabling the display device 200 to run applications and interact with the user based on the applications. The application layer may contain at least one application, which may be a built-in Windows program, system settings program, or clock program of the operating system; or it may be an application developed by a third-party developer. In specific implementations, the application packages in the application layer are not limited to the examples above.

[0053] The framework layer provides application programming interfaces (APIs) and a programming framework for applications. The application framework layer includes predefined functions. It acts as a central processing unit, determining the actions taken by applications within the application layer. Through the API, applications can access system resources and obtain system services during execution.

[0054] like Figure 3 As shown, Figure 3 Provided for some embodiments of this application Figure 1 The diagram shows the software configuration of the display device. In some embodiments, the system of the display device 200 can be divided into three layers, from top to bottom: the application layer, the middleware layer, and the hardware layer.

[0055] The application layer mainly includes commonly used applications on TVs, as well as the application framework. The commonly used applications are mainly browser-based applications, such as HTML5 apps, and native apps. An application framework is a complete program model that has all the basic functions required by standard application software, such as file access, data exchange, and the user interface for these functions (toolbar, status bar, menu, dialog box).

[0056] Native apps can support online or offline access, push notifications, or access to local resources.

[0057] The middleware layer includes various television protocols, multimedia protocols, and system components. Middleware can use the basic services (functions) provided by system software to connect different parts of application systems or different applications on the network, achieving resource sharing and function sharing.

[0058] The hardware layer mainly includes the Hardware Abstraction Layer (HAL) interface, hardware, and drivers. The HAL interface serves as a unified interface for all TV chips, with the specific logic implemented by each individual chip. Drivers primarily include: audio drivers, display drivers, Bluetooth drivers, camera drivers, Wi-Fi drivers, USB drivers, HDMI drivers, sensor drivers (such as fingerprint sensors, temperature sensors, pressure sensors, etc.), and power drivers.

[0059] It should be noted that the above examples are merely a simple division of operating system functions and do not limit the specific form of the operating system of the display device 200 in this application embodiment. Depending on the function of the display device, the type of operating system, and other factors, the number of levels and the specific level type of the operating system may be expressed in other forms.

[0060] Display device 200 can provide recording functions, including timed recording or intelligent recommended recording, to record programs that users are interested in to local storage devices for later playback. In replay scenarios of long programs such as sports events, users often only focus on the highlights (such as goals, red cards, substitutions, etc.), but traditional replay methods lack intelligent navigation. When replaying recorded programs, users can only manually perform fast forward or rewind operations to locate the highlights, which is cumbersome and time-consuming.

[0061] To address the aforementioned issues, the display device 200 provided in this embodiment can execute a recording and playback method. When a user plays back a recorded file, it automatically requests a list of key events corresponding to the recorded file from a cloud server. After filtering and converting the obtained key events by time, it marks the key events on the playback timeline, providing the user with intuitive visual navigation. This allows the user to quickly locate content segments of interest and improves the convenience of playback operations.

[0062] The display device 200 capable of applying the recording and playback method includes at least a display 260, a communication device 220, and a controller 250. The display 260 is configured to display a user interface. The communication device 220 is configured to communicate with a cloud server. The controller 250 is configured to execute the specific steps of the recording and playback method. Figure 4 The diagram shown is a flowchart of the recording and playback method provided in this application embodiment, which specifically includes the following steps: S401, in response to a user's playback operation on a recorded file, extracts channel information and program information from the recorded file without obtaining key events of the recorded file.

[0063] During the operation of the display device 200, the user can perform playback operations on the recorded file through touch operation, control device 100 or mobile terminal 300 to trigger the display device 200 to play the media content of the recorded file.

[0064] When the display device 200 receives a user's playback request for a recorded file, it first checks whether the key events of the recorded file have been acquired. Key events refer to events with significant value that occur during program recording, such as goals, red cards, substitutions, and timeouts in sports events; and weather forecasts, stock market updates, and headlines in news programs. Key events are matched and provided by a cloud server based on program and channel information. The cloud server maintains a key event database, which can be built based on real-time data collection during program broadcast and manual annotation.

[0065] If it is determined that no key events have been obtained from the recording file, channel and program information are extracted from the recording file to facilitate a subsequent request for the key event list from the cloud server. If it is determined that the key events have been obtained from the recording file, the list of obtained key events is read directly from local storage without needing to request it from the cloud server again, thus reducing network requests.

[0066] The channel information includes channel number, channel name, frequency, and other attribute information used to identify the channel corresponding to the recorded file. The program information includes program name, program broadcast time, program type, and other attribute information used to identify the program corresponding to the recorded file. The channel information and program information can be extracted from the metadata of the recorded file or retrieved from the media database of the display device 200.

[0067] S402, send an event retrieval request to the cloud server. The event retrieval request carries channel information and program information and is used to request the cloud server to retrieve the list of the first key events corresponding to the channel information and program information.

[0068] After extracting channel and program information from the recording file, the display device 200 sends an event retrieval request to the cloud server via the communication device 220. The event retrieval request carries the channel and program information. After receiving the event retrieval request, the cloud server matches the corresponding key events in its key event database based on the channel and program information, and returns a first key event list composed of the matched key events to the display device 200.

[0069] In some embodiments, event retrieval requests can be transmitted using HTTP or HTTPS protocols, and request parameters can be encapsulated in JSON or XML format. The first list of critical events returned by the cloud server may include fields such as event name, event type, and absolute timestamp for each critical event. The absolute timestamp refers to the actual time the critical event occurred, expressed in Coordinated Universal Time (UTC) or local time.

[0070] In some embodiments, after receiving an event retrieval request, the cloud server may also query key event data from a third-party database. The third-party database maintains key event information for various programs. After retrieving the key event data from the third-party database, the cloud server integrates it into a first key event list and returns it to the display device 200.

[0071] S403 receives the first list of critical events returned by the cloud server based on the event retrieval request.

[0072] Display device 200 receives a first key event list returned by cloud server via communication device 220. The first key event list contains all key events matched by the cloud server based on channel and program information. The absolute timestamps of these key events may fall within or outside the recording time period of the recorded file. Therefore, subsequent time-filtering processing of the first key event list is required.

[0073] S404: Filter out key events that are not located within the recording time period of the recording file from the first key event list to obtain the second key event list.

[0074] After obtaining the first list of key events, the display device 200 compares the absolute timestamps of each key event in the first list with the recording time period of the recording file. The recording time period is determined by the start and end times of the recording file. If the absolute timestamp of a key event falls within the recording time period, the key event is retained; if the absolute timestamp of a key event does not fall within the recording time period, the key event is filtered out. After time filtering, a second list of key events is obtained. The absolute timestamps of all key events in the second list fall within the recording time period of the recording file, ensuring that the subsequent key event markers correspond to the playback screen.

[0075] S405, convert the absolute timestamps of each key event in the second key event list into the playback position to obtain the third key event list.

[0076] The playback position is the time offset of the absolute timestamp of the key event relative to the recording start time of the recording file. Since the absolute timestamps of the key events returned by the cloud server are expressed in actual time, while the playback timeline is expressed as a time offset relative to the recording start time, the two time bases are inconsistent. Therefore, it is necessary to convert the absolute timestamps of each key event in the second key event list into playback positions, that is, to calculate the time offset of the absolute timestamp relative to the recording start time of the recording file, so that the key event markers can accurately correspond to the playback screen.

[0077] S406, control the display 260 to display the playback interface of the recorded file, and mark key events on the playback timeline in the playback interface according to the third key event list.

[0078] After receiving the third key event list, the display device 200 controls the monitor 260 to display the playback interface of the recorded file, and marks key events on the playback timeline of the playback interface according to the playback position of each key event in the third key event list. During playback, users can quickly understand the distribution of exciting segments by browsing the key event marks on the playback timeline, and jump to the corresponding playback screen by selecting a key event mark, without having to manually perform fast forward or rewind operations to locate exciting segments, thus simplifying the operation process.

[0079] like Figure 5 The diagram shown illustrates the key event acquisition and flag determination process provided in this application embodiment, which specifically includes the following steps: S501, acquire key event flags of the recorded file.

[0080] The display device 200 maintains a key event acquisition flag for each recorded file to indicate whether key events of the recorded file have been acquired. The key event acquisition flag is either a first flag or a second flag; the first flag indicates that key events of the recorded file have been acquired, and the second flag indicates that key events of the recorded file have not been acquired. The key event acquisition flag can be stored in the metadata of the recorded file or in the media database of the display device 200.

[0081] S502, if the key event acquisition flag is the first flag, determine that the key events of the recorded file have been acquired.

[0082] If the key event acquisition flag is set to the first flag, it means that the key events of the recording file have already been acquired. The display device 200 can directly read the acquired key event list from the local storage without having to request it from the cloud server again, thus reducing network requests and waiting time.

[0083] S503, if the critical event acquisition flag is the second flag, determine that the critical event of the recording file has not been acquired.

[0084] If the critical event acquisition flag is the second flag, it means that the critical events of the recording file have not yet been acquired, and the display device 200 needs to send an event acquisition request to the cloud server to obtain the list of critical events.

[0085] S504, after receiving the first list of key events returned by the cloud server, changes the key event acquisition flag to the first flag.

[0086] After receiving the first list of key events returned by the cloud server, the display device 200 changes the key event acquisition flag of the recording file from the second flag to the first flag to indicate that the key events of the recording file have been acquired, ensuring that repeated acquisition will not be triggered when the recording file is played back later.

[0087] To decouple the critical event acquisition task from the main playback process, the display device 200 uses a bounded deduplication queue to asynchronously process the critical event acquisition task. For example... Figure 6 The diagram shown is a schematic of the processing flow for the critical event acquisition task provided in an embodiment of this application, specifically including the following steps: S601, create a critical event acquisition task if critical events in a recorded file are not acquired.

[0088] After determining that a key event for which a recording file has not been retrieved, the display device 200 creates a key event retrieval task. This task contains a recording file identifier, such as the filename, file path, or unique ID, and is used to request a list of the first key events for the corresponding recording file from the cloud server.

[0089] S602 adds the critical event acquisition task to a bounded deduplication queue.

[0090] The display device 200 adds the created critical event retrieval tasks to a bounded deduplication queue. This bounded deduplication queue is a task queue with a fixed capacity limit and deduplication functionality. When a task is enqueued, the display device 200 can determine whether a critical event retrieval task corresponding to the same recording file already exists in the bounded deduplication queue based on the recording file identifier. If it does, the task is rejected, preventing duplicate retrieval requests for the same recording file from being submitted multiple times. When the bounded deduplication queue is full, a strategy of discarding the oldest task or rejecting new tasks can be adopted to ensure that the queue capacity always has an upper limit, preventing a large number of playback operations in a short period from triggering too many retrieval tasks, leading to infinite task backlog and memory overflow.

[0091] In some embodiments, the capacity of the bounded deduplication queue can be configured based on system resources and usage scenarios, for example, set to 50 or 100. When the queue is full, discarding the earliest enqueued task ensures that the latest retrieval requests are processed first, while rejecting new tasks can prevent system overload.

[0092] S603 executes the critical event retrieval task in the bounded deduplication queue through the corresponding worker thread.

[0093] The display device 200 asynchronously executes tasks in a bounded deduplication queue via an independent worker thread. After retrieving a key event retrieval task from the bounded deduplication queue, the worker thread executes the entire key event retrieval process, including sending an event retrieval request to the cloud server, receiving the returned first list of key events, and performing operations such as time filtering and position conversion. Because the entire key event retrieval process is executed in a background thread, it does not block the main flow of the user's playback operation. The user does not need to wait for the key event retrieval to complete before starting normal playback, ensuring the immediacy and smoothness of the playback operation.

[0094] Specifically, after retrieving the key event retrieval task from the bounded deduplication queue, the worker thread first queries the local Electronic Program Guide (EPG) information through the metadata management module, extracting channel information (including channel number, channel name, frequency, etc.) and program information (including program name, broadcast time, program type, etc.) from the recording file. Then, the worker thread assembles the channel and program information into a JSON-formatted request message to construct the event retrieval request. Next, the worker thread sends the event retrieval request to the cloud server via communication device 220 using an HTTP POST method. Upon receiving the event retrieval request, the cloud server matches the corresponding key events in its key event database based on the channel and program information, and returns a JSON-formatted response message containing the matched key events to the worker thread. The worker thread parses the JSON data returned from the cloud, extracts the first key event list, and then sends the first key event list to the recording control module via inter-process communication (IPC) messages. The recording control module then performs subsequent time filtering, position conversion, sorting, and multi-level storage operations.

[0095] In this embodiment, communication between the worker thread and the cloud server uses the HTTP POST protocol. The request message is encapsulated in JSON format, and the request body includes fields such as channel number, channel name, frequency, program name, and program broadcast time. The response message returned by the cloud server is also encapsulated in JSON format, and the response body contains a list of the first matched key events. Each key event includes fields such as event name, event type, and absolute timestamp. After parsing the JSON response message, the worker thread sends the key event data to the corresponding recording control module via IPC messages, realizing data transfer between the business logic layer and the service layer.

[0096] In some embodiments, in response to a user's playback operation of a recorded file, the display device 200 can also detect the recording source of the recorded file. If the key events of the recorded file are not obtained and the recording source is intelligent recommendation recording, the device will then proceed with the step of requesting the cloud server to obtain the first list of key events. Intelligent recommendation recording refers to programs automatically recorded for users by the display device 200 based on user profiles and program recommendation algorithms. These programs typically have obvious key event distribution characteristics, and users have the strongest demand for labeling their key events. By limiting the acquisition of key events to intelligent recommendation recording, the number of invalid requests to the cloud server can be effectively reduced, thereby lowering network load and server pressure, while ensuring user experience.

[0097] In some embodiments, the recording source includes two methods: scheduled recording and intelligent recommendation recording. The display device 200 detects the recording source of the recording file in response to the user's playback operation. When the recording source is detected as intelligent recommendation recording, and the key event acquisition flag is the second flag (not acquired), the key event acquisition process is triggered. When the recording source is detected as scheduled recording, even if the key event acquisition flag is the second flag, the key event acquisition process is not triggered; normal playback is performed, and no request for key events is made from the cloud server.

[0098] like Figure 7 The diagram shown illustrates the timestamp conversion process provided in this application embodiment, specifically including the following steps: S701, obtain the recording start time of the recording file.

[0099] Display device 200 obtains the recording start time from the metadata of the recording file. The recording start time refers to the actual time when recording of the recording file begins, expressed in UTC time or local time. The recording start time can be recorded at the start of recording and stored in the metadata of the recording file.

[0100] S702 calculates the time difference between the absolute timestamp of each key event and the recording start time.

[0101] Display device 200 calculates the time difference between the absolute timestamp of each key event in the second key event list and the recording start time. The time difference represents the time offset of the key event relative to the recording start time, and the unit can be seconds, milliseconds, etc.

[0102] S703 converts the time difference into the time unit value corresponding to the recorded file to obtain the playback position.

[0103] The display device 200 converts the time difference into the corresponding time unit value of the recorded file to obtain the playback position. For example, if the time unit of the recorded file is milliseconds, the time difference is converted into a millisecond value as the playback position; if the time unit of the recorded file is a frame number, the time difference is converted into the corresponding frame number as the playback position. The playback position represents the location of the key event on the playback timeline. By converting the absolute timestamp into the playback position, the key event markers can be accurately mapped to the playback screen, solving the problem of misalignment caused by inconsistent time bases.

[0104] In some embodiments, after the display device 200 marks key events on the playback timeline in the playback interface, the user can select a target key event mark on the playback timeline during playback via the control device 100 or touch operation. In response to the user's selection of the target key event mark on the playback timeline, the display device 200 jumps from the current playback position of the recorded file to the target playback position corresponding to the target key event mark, causing the display 260 to play the playback screen corresponding to the target playback position. In this way, the user can select a mark on the timeline to jump at any time during playback, resulting in a shorter operation path and more intuitive interaction.

[0105] For example, such as Figure 8 The diagram shows key event markers in the playback interface provided in this embodiment. After receiving a user's playback operation for a recorded file, the display device 200 controls the display 260 to display the playback interface. The playback interface includes a playback screen area 810 and a playback timeline 820. On the playback timeline 820, key event markers 821 are placed according to the playback position of each key event in the third key event list. Key event markers 821 can be displayed as hotspot icons or color bars, allowing users to intuitively identify the location and distribution of key events. At the corresponding position on the playback timeline 820, descriptive information 822 of the key events, such as event names, can also be displayed, allowing users to obtain the specific content of the key events while browsing the playback timeline. Simultaneously, the key event marker corresponding to the current playback position can be highlighted, enabling users to perceive the key event corresponding to the current playback progress in real time.

[0106] In some embodiments, a user can trigger an instruction to display the associated event list by pressing a specific button on a remote control or through interface operations. The display device 200 can respond to the instruction by controlling the display 260 to display the third key event list in the form of a pop-up window, sidebar, or similar format. The third key event list contains the event name and corresponding time point of each key event, and the key events can be arranged in ascending or descending order according to their playback position.

[0107] Users can browse the event names and timestamps of each key event in the third key event list and select the target key event of interest. The display device 200 responds to the user's selection, determines the target playback position corresponding to the target key event, and jumps from the current playback position of the recorded file to the target playback position, causing the monitor 260 to play the playback screen corresponding to the target playback position. By providing an interactive method of displaying a key event list and selecting from the list, a structured and visual key event navigation entry is provided to the user. This is particularly suitable for scenarios with a large number of key events, enabling users to quickly browse and select events of interest for viewing.

[0108] For example, such as Figure 9 The diagram illustrates the display of a key event list provided in this embodiment. When a user triggers a command to display the associated event list via a remote control or interface operation, the display device 200 controls the display 260 to display the key event list 910 in a pop-up window. The key event list 910 includes the event name, event description information, and corresponding time point for each key event, arranged in ascending order of playback position. The user can browse the key event list 910, select a target key event of interest, and the display device 200, in response to the user's selection, jumps from the current playback position of the recorded file to the target playback position corresponding to the target key event to play the corresponding playback screen.

[0109] In some embodiments, after obtaining the third key event list, the display device 200 can write it to a playback memory instance to render key event markers in real time during the playback of the recorded file. The playback memory instance is a memory data structure created during the playback of the recorded file to store the data required for the current playback. After writing the third key event list to the playback memory instance, the key event data can be directly read from memory for real-time rendering during playback, displaying the key event markers on the playback timeline without frequent disk or database reads and writes, ensuring the immediacy and smoothness of the annotation.

[0110] In some embodiments, after obtaining the list of third key events, the display device 200 can write it to an event data file for persistent storage, so that the list of third key events can be retrieved directly from the event data file the next time the recording file is played back. The event data file is stored bound to the recording file and can use JSON, XML, or a custom binary format. The next time the recording file is played back, the display device 200 can directly load the list of third key events from the local event data file without requesting the cloud server again, reducing network requests and waiting time, and improving the playback experience.

[0111] In some embodiments, after obtaining the third key event list, the display device 200 can write it into a media database for querying and reading by various business modules within the display device 200. The media database is a structured database in the display device 200 used to manage media resources. After the third key event list is written into the media database, other business modules in the display device 200 (such as program recommendation, user behavior analysis, intelligent search, etc.) can read the key event data through a unified query interface, enabling the key event data to be flexibly invoked by upper-layer applications and expanding the application scenarios of the key event data.

[0112] In some embodiments, after obtaining the third list of key events, if the display 260 is currently displaying the playback interface of a recorded file, the display device 200 refreshes the playback timeline in the playback interface to display the key event markers. By introducing a real-time refresh mechanism, the interface update problem in scenarios where the user is playing back the recorded file after the key events have been acquired is solved. When the background worker thread completes the acquisition, filtering, and conversion of key events, if the user is playing back the recorded file, the playback timeline can be refreshed to display the newly acquired key event markers, without requiring the user to exit and reopen the program or manually refresh.

[0113] In some embodiments, after converting the absolute timestamps of each key event in the second key event list into playback positions, the display device 200 can sort the key events in the second key event list according to the ascending or descending order of the playback positions to obtain a third key event list. This sorting process arranges the key events in the third key event list in chronological order, facilitating subsequent sequential marking of key events on the playback timeline and allowing users to browse and select key events in chronological order within the key event list.

[0114] Specifically, after receiving the first list of key events sent by the worker thread via IPC messages, the recording control module first reads the recording information of the recording file, including metadata such as the recording start time and recording end time. Then, it sets an event acquisition flag, changes the key event acquisition flag to the first flag, and writes it back to the corresponding recording information file to persist the flag, ensuring that repeated acquisition is not triggered during subsequent playback of the recording file. Next, it performs time filtering, comparing the absolute timestamps of each key event in the first list with the recording time period of the recording file, filtering out key events not within the recording time period, resulting in the second list of key events. Subsequently, it performs timestamp conversion, converting the absolute timestamps of each key event in the second list to millisecond offsets relative to the recording start time (i.e., playback position), resulting in the third list of key events. The key events in the third list are then sorted in ascending or descending order of playback position. The third list of key events is then synchronously written to the playback memory instance, the event data file, and the media database. Finally, a refresh notification is sent to the application layer to refresh the playback timeline in the playback interface to display the key event flags.

[0115] In some embodiments, the three types of persistent storage media in the storage layer have different storage formats and uses. The recording information file can be in .bin format, used to store basic recording metadata and record a key event acquisition flag indicating whether an event has been acquired. Each time the display device 200 plays back a recording file, it first reads the key event acquisition flag in the recording information file to determine whether it needs to request key events from the cloud server, ensuring that key events are not repeatedly acquired after they have been acquired for each recording file. The event data file can be in .jmzn format, used to store key event data, and is stored bound to the recording file. The next time the recording file is played back, the key event list can be directly loaded from the event data file without requesting the cloud server again, reducing network requests and waiting time. The media database can be a global media resource database for the entire device using SQLite format, persistently storing key event data. Other business modules of the entire device can read key event data through a unified query interface, realizing global sharing and cross-module access to key event data.

[0116] In some embodiments, if the cloud server does not return the list of first critical events within a preset timeout period, a retry strategy is executed. The preset timeout period can be configured based on the network environment and server performance, for example, set to 5 seconds or 10 seconds. The retry strategy employs an exponential backoff approach, meaning the waiting time for each retry increases exponentially, for example, the first retry waits 2 seconds, the second retry waits 4 seconds, the third retry waits 8 seconds, and so on. This exponential backoff approach avoids excessive pressure on the cloud server from a dense stream of requests within a short period.

[0117] When the number of retries exceeds the preset retry threshold (e.g., set to 3 or 5 times), the current acquisition process is terminated. After the retry is terminated, the display device 200 can provide a manual retry button on the playback interface, allowing users to manually re-trigger the critical event acquisition process after the network is restored, ensuring the final availability of the critical event annotation function in abnormal scenarios.

[0118] like Figure 10 The diagram shown is a system architecture diagram for recording and playback provided in an embodiment of this application. The system architecture adopts a top-down four-layer software architecture design, including an application layer, a business logic layer, a service layer, and a storage layer.

[0119] The application layer includes a playback interface management module. This module is responsible for rendering playback footage, displaying key event markers and a list of key events on the playback progress line, and receiving refresh notifications from underlying modules to update the interface.

[0120] The business logic layer includes a playback trigger detection module, a task queue management module, and a communication module. The playback trigger detection module performs conditional checks upon playback initiation to determine whether a request for critical event data from the cloud server is necessary. The task queue management module maintains a bounded, deduplicated asynchronous task queue, schedules background worker threads, and prevents duplicate requests and multiple tasks from preempting the main playback thread. The communication module handles network interaction, communicating with the cloud server and receiving and parsing the critical event data returned by the cloud server.

[0121] The service layer includes a recording control module, a metadata management module, and a media database service module. The recording control module receives IPC messages and performs tasks such as reading recording information, filtering events, time conversion, event sorting, updating playback memory instances, outputting event data files, and setting acquired flags. The metadata management module reads metadata such as channel information and program information corresponding to the recorded files. The media database service module is responsible for writing and updating the entire system's media database.

[0122] The storage layer comprises three types of persistent storage media: recording information files, event data files, and a media database. Recording information files store the basic metadata of the recorded files and indicate whether an event has been successfully recorded. Event data files store critical event data. The media database, serving as a global media resource database for the entire system, persistently stores critical event data, enabling global sharing of this data.

[0123] In the four-layer architecture described above, the application layer is responsible for user interaction and interface rendering, the business logic layer is responsible for task scheduling and network communication, the service layer is responsible for data processing and storage management, and the storage layer is responsible for persistent data storage. The layers collaborate through API calls and message notification mechanisms to achieve automatic acquisition and annotation of key events.

[0124] like Figure 11 The diagram shown is a timing diagram of the recording and playback provided in an embodiment of this application. After the user triggers the playback operation of the recorded file through the application layer, the playback operation is passed to the business logic layer. The business logic layer performs playback trigger detection, detects the key event acquisition flag and recording source of the recorded file. If the key event acquisition flag is the second flag (e.g., 0) and the recording source is intelligent recommendation recording, a key event acquisition task is generated, added to the bounded deduplication queue, and the worker thread is notified.

[0125] After retrieving the critical event retrieval task from the bounded deduplication queue, the worker thread first queries the local EPG information through the metadata management module to obtain metadata such as channel information and program information corresponding to the recorded file. Then, it assembles and constructs an event retrieval request in JSON format and sends the event retrieval request to the cloud server via the communication module using the HTTP POST method.

[0126] After receiving an event retrieval request, the cloud server performs event matching processing. Based on the channel and program information in the request, it matches the corresponding key events from the key event database maintained in the cloud and returns the list of key events to the worker thread in JSON format.

[0127] The worker thread parses the JSON data returned by the cloud server, extracts the list of key events, and sends the list of key events to the recording control module via IPC messages, thus ending the acquisition task.

[0128] After receiving the IPC message, the recording control module reads the recording information file, sets the key event acquisition flag of the recording file to the first flag (e.g., 1), and writes it back to the recording information file to persist the flag. Then, it performs timestamp conversion processing, converting absolute timestamps to relative offsets and sorting the key event list in ascending order of playback position. Next, it updates the playback memory instance to ensure quick navigation afterward, exports the data to the event data file for persistent storage, and triggers the media database service module to perform a database write operation, writing the key event list to the media database for querying and reading by other business modules of the system.

[0129] Then, the recording control module sends a UI refresh notification to the application layer, which then marks key events on the playback timeline and updates the list of key events. Users can quickly jump to the next event by selecting a key event marker or an event from the list.

[0130] Based on the display device 200 described above, this application embodiment also provides a recording and playback method, which may include the following steps: In response to a user's playback operation on a recorded file, channel and program information can be extracted from the recorded file without obtaining key events related to the recorded file.

[0131] Send an event retrieval request to the cloud server; the event retrieval request carries channel information and program information, and is used to request the cloud server to retrieve the list of the first key events corresponding to the channel information and program information.

[0132] Receive the first list of key events returned by the cloud server based on the event retrieval request.

[0133] Filter out key events that are not located within the recording time period of the recording file from the first key event list to obtain the second key event list.

[0134] The absolute timestamps of each key event in the second key event list are converted into playback positions to obtain the third key event list; the playback position is the time offset of the absolute timestamp relative to the recording start time of the recording file.

[0135] Display the playback interface of the recorded file, and mark key events on the playback timeline in the playback interface according to the third key event list.

[0136] The same or similar parts among the various embodiments in this specification can be referred to mutually, and will not be repeated here.

[0137] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0138] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

Claims

1. A display device, characterized in that, include: monitor; The communication device is configured to communicate with a cloud server. The controller is configured as follows: In response to a user's playback operation on a recorded file, channel information and program information are extracted from the recorded file without obtaining key events of the recorded file; Send an event retrieval request to the cloud server; the event retrieval request carries the channel information and the program information, and is used to request the cloud server to retrieve the first key event list corresponding to the channel information and the program information; Receive the first list of key events returned by the cloud server based on the event acquisition request; Filter out key events that are not located within the recording time period of the recorded file from the first key event list to obtain the second key event list; Convert the absolute timestamps of each key event in the second key event list into playback positions to obtain the third key event list; The playback position is the time offset of the absolute timestamp relative to the recording start time of the recorded file; The system controls the display to show the playback interface of the recorded file, and marks key events on the playback timeline of the playback interface according to the third key event list.

2. The display device according to claim 1, characterized in that, The controller is also configured to: Acquire key event acquisition flags of the recorded file; the key event acquisition flags are either a first flag or a second flag, the first flag is used to indicate that key events of the recorded file have been acquired, and the second flag is used to indicate that key events of the recorded file have not been acquired; If the key event acquisition flag is the first flag, it is determined that the key event of the recorded file has been acquired; If the key event acquisition flag is the second flag, it is determined that the key event of the recorded file has not been acquired; After receiving the first list of key events returned by the cloud server, the key event acquisition flag is changed to the first flag.

3. The display device according to claim 1, characterized in that, The controller, in response to a user's playback operation on a recorded file, is also configured to: Detect the recording source of the recorded file; In the absence of key events in the recorded file and if the recording source is intelligent recommendation recording, extract channel information and program information from the recorded file.

4. The display device according to claim 1, characterized in that, The controller is also configured to: In the absence of key events in the recorded file, a key event acquisition task is created; the key event acquisition task includes the recording file identifier of the recorded file; the key event acquisition task is a task to request the cloud server to obtain the first list of key events. Add the critical event acquisition task to a bounded deduplication queue; The bounded deduplication queue is used to deduplicatize key event acquisition tasks corresponding to the same recording file based on the recording file identifier when the key event acquisition task is enqueued. The critical event retrieval task in the bounded deduplication queue is executed by the worker thread corresponding to the bounded deduplication queue.

5. The display device according to claim 1, characterized in that, The controller converts the absolute timestamps of each key event in the second key event list into playback positions, specifically configured as follows: Obtain the recording start time of the recorded file; Calculate the time difference between the absolute timestamp of each key event and the recording start time; The time difference is converted into the time unit value corresponding to the recorded file to obtain the playback position.

6. The display device according to claim 1, characterized in that, After obtaining the third list of key events, the controller is further configured as follows: In response to an instruction to display the associated event list, control the display to show the third key event list; In response to the user's selection of a target key event from the third key event list, the target playback position corresponding to the target key event is determined; The system jumps from the current playback position of the recorded file to the target playback position, so that the display plays the playback screen corresponding to the target playback position.

7. The display device according to claim 1, characterized in that, After the controller marks key events on the playback timeline in the playback interface according to the third key event list, it is further configured to: In response to the user's selection operation of the target key event marker on the playback timeline, the system jumps from the current playback position of the recorded file to the target playback position corresponding to the target key event marker, so that the display plays the playback screen corresponding to the target playback position.

8. The display device according to claim 1, characterized in that, After obtaining the third list of key events, the controller is further configured as follows: The third list of key events is written to the playback memory instance to render key event markers in real time during the playback of the recorded file; The third key event list is written to an event data file for persistent storage, so that the third key event list can be directly retrieved from the event data file when the recording file is played back next time. The list of the third key events is written into the media database for querying and reading by the business modules in the display device.

9. The display device according to claim 1, characterized in that, The controller is also configured to: After obtaining the third list of key events, if the display is showing the playback interface of the recorded file, the playback timeline in the playback interface is refreshed to display the key event markers.

10. A recording and playback method, characterized in that, include: In response to a user's playback operation on a recorded file, channel information and program information are extracted from the recorded file without obtaining key events of the recorded file; Send an event retrieval request to the cloud server; The event acquisition request carries the channel information and the program information, and is used to request the cloud server to obtain the first key event list corresponding to the channel information and the program information; Receive the first list of key events returned by the cloud server based on the event acquisition request; Filter out key events that are not located within the recording time period of the recorded file from the first key event list to obtain the second key event list; Convert the absolute timestamps of each key event in the second key event list into playback positions to obtain the third key event list; The playback position is the time offset of the absolute timestamp relative to the recording start time of the recorded file; Display the playback interface of the recorded file, and mark key events on the playback timeline of the playback interface according to the third key event list.

Images